* Re: [PATCH v2 1/2] dt-bindings: iommu: arm,smmu-v3: Add SC8280XP compatible
From: Konrad Dybcio @ 2024-03-27 19:23 UTC (permalink / raw)
To: Robin Murphy, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Will Deacon, Joerg Roedel, Rob Herring
Cc: Marijn Suijten, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, iommu, Johan Hovold
In-Reply-To: <9b2a681e-1191-4cf7-8da7-14aa2c1fa455@arm.com>
On 19.03.2024 2:53 PM, Robin Murphy wrote:
> On 2024-03-09 1:31 pm, Konrad Dybcio wrote:
>> The smmu-v3 binding currently doesn't differentiate the SoCs it's
>> implemented on. This is a poor design choice that may bite in the future,
>> should any quirks surface.
>
> That doesn't seem entirely fair to say - the vast majority of bindings don't have separate compatibles for every known integration of the same implementation in different SoCs. And in this case we don't have per-implementation compatibles for quirks and errata because the implementation is architecturally discoverable from the SMMU_IIDR register.
>
> We have the whole mess for QCom SMMUv2 because the effective *implementation* is a mix of hardware and hypervisor, whose behaviour does seem to vary on almost a per-SoC basis. I'm not at all keen to start repeating that here without very good reason, and that of "documenting" a device which we typically expect to not even be accessible isn't really convincing me...
From my POV as an arch dts maintainer, this often ends up being the only
way to retroactively add some conditional action into the code - the kernel
is supposed to be backwards compatible with older device trees.
And so far it's been almost by luck that all of the smmuv3 implementations
have been a straight copy-and-paste of the reference design (or close enough),
I don't believe this will be for much longer.
Konrad
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 5/9] spi: pxa2xx: Allow number of chip select pins to be read from property
From: Andy Shevchenko @ 2024-03-27 19:29 UTC (permalink / raw)
To: Mark Brown, Andy Shevchenko, linux-spi, linux-kernel,
linux-arm-kernel
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King
In-Reply-To: <20240327193138.2385910-1-andriy.shevchenko@linux.intel.com>
In some cases the number of the chip select pins might come from
the device property. Allow driver to use it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/spi/spi-pxa2xx.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index b01a18c89b6b..f4435c39d096 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1358,6 +1358,7 @@ pxa2xx_spi_init_pdata(struct platform_device *pdev)
struct ssp_device *ssp = NULL;
const void *match;
bool is_lpss_priv;
+ u32 num_cs = 1;
int status;
is_lpss_priv = platform_get_resource_byname(pdev, IORESOURCE_MEM, "lpss_priv");
@@ -1394,8 +1395,11 @@ pxa2xx_spi_init_pdata(struct platform_device *pdev)
pdata->dma_filter = pxa2xx_spi_idma_filter;
}
+ /* Read number of chip select pins, if provided */
+ device_property_read_u32(dev, "num-cs", &num_cs);
+
+ pdata->num_chipselect = num_cs;
pdata->is_target = device_property_read_bool(dev, "spi-slave");
- pdata->num_chipselect = 1;
pdata->enable_dma = true;
pdata->dma_burst_size = 1;
--
2.43.0.rc1.1.gbec44491f096
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/9] spi: pxa2xx: Drop ACPI_PTR() and of_match_ptr()
From: Andy Shevchenko @ 2024-03-27 19:29 UTC (permalink / raw)
To: Mark Brown, Andy Shevchenko, linux-spi, linux-kernel,
linux-arm-kernel
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King
In-Reply-To: <20240327193138.2385910-1-andriy.shevchenko@linux.intel.com>
Drop rather useless use of ACPI_PTR() and of_match_ptr().
It also removes the necessity to be dependent of.h inclusion.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/spi/spi-pxa2xx.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 1d43346b4436..75d208087748 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -19,7 +19,6 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/mod_devicetable.h>
-#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/property.h>
@@ -1725,7 +1724,6 @@ static const struct dev_pm_ops pxa2xx_spi_pm_ops = {
RUNTIME_PM_OPS(pxa2xx_spi_runtime_suspend, pxa2xx_spi_runtime_resume, NULL)
};
-#ifdef CONFIG_ACPI
static const struct acpi_device_id pxa2xx_spi_acpi_match[] = {
{ "80860F0E", LPSS_BYT_SSP },
{ "8086228E", LPSS_BSW_SSP },
@@ -1736,9 +1734,8 @@ static const struct acpi_device_id pxa2xx_spi_acpi_match[] = {
{}
};
MODULE_DEVICE_TABLE(acpi, pxa2xx_spi_acpi_match);
-#endif
-static const struct of_device_id pxa2xx_spi_of_match[] __maybe_unused = {
+static const struct of_device_id pxa2xx_spi_of_match[] = {
{ .compatible = "marvell,mmp2-ssp", .data = (void *)MMP2_SSP },
{}
};
@@ -1748,8 +1745,8 @@ static struct platform_driver driver = {
.driver = {
.name = "pxa2xx-spi",
.pm = pm_ptr(&pxa2xx_spi_pm_ops),
- .acpi_match_table = ACPI_PTR(pxa2xx_spi_acpi_match),
- .of_match_table = of_match_ptr(pxa2xx_spi_of_match),
+ .acpi_match_table = pxa2xx_spi_acpi_match,
+ .of_match_table = pxa2xx_spi_of_match,
},
.probe = pxa2xx_spi_probe,
.remove_new = pxa2xx_spi_remove,
--
2.43.0.rc1.1.gbec44491f096
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 12/14] sh: Add support for suppressing warning backtraces
From: Simon Horman @ 2024-03-27 19:39 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kselftest, David Airlie, Arnd Bergmann, Maíra Canal,
Dan Carpenter, Kees Cook, Daniel Diaz, David Gow, Arthur Grillo,
Brendan Higgins, Naresh Kamboju, Maarten Lankhorst, Andrew Morton,
Maxime Ripard, Ville Syrjälä, Daniel Vetter,
Thomas Zimmermann, dri-devel, kunit-dev, linux-arch,
linux-arm-kernel, linux-doc, linux-kernel, linux-parisc,
linuxppc-dev, linux-riscv, linux-s390, linux-sh, loongarch,
netdev, Linux Kernel Functional Testing
In-Reply-To: <320aacc6-b7e5-4c3d-948e-d0743ab26c5d@roeck-us.net>
On Wed, Mar 27, 2024 at 08:10:51AM -0700, Guenter Roeck wrote:
> On 3/27/24 07:44, Simon Horman wrote:
> > On Mon, Mar 25, 2024 at 10:52:46AM -0700, Guenter Roeck wrote:
> > > Add name of functions triggering warning backtraces to the __bug_table
> > > object section to enable support for suppressing WARNING backtraces.
> > >
> > > To limit image size impact, the pointer to the function name is only added
> > > to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and
> > > CONFIG_DEBUG_BUGVERBOSE are enabled. Otherwise, the __func__ assembly
> > > parameter is replaced with a (dummy) NULL parameter to avoid an image size
> > > increase due to unused __func__ entries (this is necessary because __func__
> > > is not a define but a virtual variable).
> > >
> > > Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
> > > Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
> > > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > > ---
> > > - Rebased to v6.9-rc1
> > > - Added Tested-by:, Acked-by:, and Reviewed-by: tags
> > > - Introduced KUNIT_SUPPRESS_BACKTRACE configuration option
> > >
> > > arch/sh/include/asm/bug.h | 26 ++++++++++++++++++++++----
> > > 1 file changed, 22 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/sh/include/asm/bug.h b/arch/sh/include/asm/bug.h
> > > index 05a485c4fabc..470ce6567d20 100644
> > > --- a/arch/sh/include/asm/bug.h
> > > +++ b/arch/sh/include/asm/bug.h
> > > @@ -24,21 +24,36 @@
> > > * The offending file and line are encoded in the __bug_table section.
> > > */
> > > #ifdef CONFIG_DEBUG_BUGVERBOSE
> > > +
> > > +#ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
> > > +# define HAVE_BUG_FUNCTION
> > > +# define __BUG_FUNC_PTR "\t.long %O2\n"
> > > +#else
> > > +# define __BUG_FUNC_PTR
> > > +#endif /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
> > > +
> >
> > Hi Guenter,
> >
> > a minor nit from my side: this change results in a Kernel doc warning.
> >
> > .../bug.h:29: warning: expecting prototype for _EMIT_BUG_ENTRY(). Prototype was for HAVE_BUG_FUNCTION() instead
> >
> > Perhaps either the new code should be placed above the Kernel doc,
> > or scripts/kernel-doc should be enhanced?
> >
>
> Thanks a lot for the feedback.
>
> The definition block needs to be inside CONFIG_DEBUG_BUGVERBOSE,
> so it would be a bit odd to move it above the documentation
> just to make kerneldoc happy. I am not really sure that to do
> about it.
FWIIW, I agree that would be odd.
But perhaps the #ifdef could also move above the Kernel doc?
Maybe not a great idea, but the best one I've had so far.
> I'll wait for comments from others before making any changes.
>
> Thanks,
> Guenter
>
> > > #define _EMIT_BUG_ENTRY \
> > > "\t.pushsection __bug_table,\"aw\"\n" \
> > > "2:\t.long 1b, %O1\n" \
> > > - "\t.short %O2, %O3\n" \
> > > - "\t.org 2b+%O4\n" \
> > > + __BUG_FUNC_PTR \
> > > + "\t.short %O3, %O4\n" \
> > > + "\t.org 2b+%O5\n" \
> > > "\t.popsection\n"
> > > #else
> > > #define _EMIT_BUG_ENTRY \
> > > "\t.pushsection __bug_table,\"aw\"\n" \
> > > "2:\t.long 1b\n" \
> > > - "\t.short %O3\n" \
> > > - "\t.org 2b+%O4\n" \
> > > + "\t.short %O4\n" \
> > > + "\t.org 2b+%O5\n" \
> > > "\t.popsection\n"
> > > #endif
> > > +#ifdef HAVE_BUG_FUNCTION
> > > +# define __BUG_FUNC __func__
> > > +#else
> > > +# define __BUG_FUNC NULL
> > > +#endif
> > > +
> > > #define BUG() \
> > > do { \
> > > __asm__ __volatile__ ( \
> >
> > ...
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [WIP 0/3] Memory model and atomic API in Rust
From: Kent Overstreet @ 2024-03-27 19:41 UTC (permalink / raw)
To: Linus Torvalds
Cc: comex, Dr. David Alan Gilbert, Philipp Stanner, Boqun Feng,
rust-for-linux, linux-kernel, linux-arch, llvm, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Alan Stern,
Andrea Parri, Will Deacon, Peter Zijlstra, Nicholas Piggin,
David Howells, Jade Alglave, Luc Maranget, Paul E. McKenney,
Akira Yokosawa, Daniel Lustig, Joel Fernandes, Nathan Chancellor,
Nick Desaulniers, kent.overstreet, Greg Kroah-Hartman,
Marco Elver, Mark Rutland, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Catalin Marinas, linux-arm-kernel, linux-fsdevel
In-Reply-To: <CAHk-=wgQy+FRKjO_BvZgZN56w6-+jDO8p-Mt=X=zM70CG=CVBQ@mail.gmail.com>
On Wed, Mar 27, 2024 at 12:07:26PM -0700, Linus Torvalds wrote:
> On Wed, 27 Mar 2024 at 11:51, Kent Overstreet <kent.overstreet@linux.dev> wrote:
> >
> > On Wed, Mar 27, 2024 at 09:16:09AM -0700, comex wrote:
> > > Meanwhile, Rust intentionally lacks strict aliasing.
> >
> > I wasn't aware of this. Given that unrestricted pointers are a real
> > impediment to compiler optimization, I thought that with Rust we were
> > finally starting to nail down a concrete enough memory model to tackle
> > this safely. But I guess not?
>
> Strict aliasing is a *horrible* mistake.
>
> It's not even *remotely* "tackle this safely". It's the exact
> opposite. It's completely broken.
>
> Anybody who thinks strict aliasing is a good idea either
>
> (a) doesn't understand what it means
>
> (b) has been brainwashed by incompetent compiler people.
>
> it's a horrendous crock that was introduced by people who thought it
> was too complicated to write out "restrict" keywords, and that thought
> that "let's break old working programs and make it harder to write new
> programs" was a good idea.
Strict aliasing is crap in C and C++ because we started out with
unrestricetd pointers, and it just doesn't work in C and C++ with the
realities of the kind of code we have to write, and we never got any
kind of a model that would have made it workable. Never mind trying to
graft that onto existing codebases...
(Restrict was crap too... no scoping, nothing but a single f*cking
keyword? Who ever thought _that_ was going to work?)
_But_: the lack of any aliasing guarantees means that writing through
any pointer can invalidate practically anything, and this is a real
problem. A lot of C programmers have stockholm syndrome when it comes to
this, we end up writing a lot of code in weirdly baroque and artificial
styles to partially work around this when we care about performance -
saving things into locals because at least the _stack_ generally can't
alias to avoid forced reloads, or passing and returning things by
reference instead of by value when that's _not the semantics we want_
because otherwise the compiler is going to do an unnecessary copy -
again, that's fundamentally because of aliasing.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ASoC: sun8i-codec: Fix build with CONFIG_SND_JACK_INPUT_DEV disabled
From: Jernej Škrabec @ 2024-03-27 19:43 UTC (permalink / raw)
To: linux-kernel, Ondřej Jirman
Cc: Ondrej Jirman, kernel test robot, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Takashi Iwai, Chen-Yu Tsai, Samuel Holland,
Rob Herring, AngeloGioacchino Del Regno, Claudiu Beznea,
Arnaud Ferraris,
open list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
moderated list:ARM/Allwinner sunXi SoC support,
open list:ARM/Allwinner sunXi SoC support
In-Reply-To: <20240327080542.3649840-1-megi@xff.cz>
Dne sreda, 27. marec 2024 ob 09:05:34 CET je Ondřej Jirman napisal(a):
> From: Ondrej Jirman <megi@xff.cz>
>
> When CONFIG_SND_JACK_INPUT_DEV is disabled, struct snd_jack doesn't
> have 'type' field. We can't rely on this field being always present,
> so store the jack_type in the codec driver itself.
>
> Signed-off-by: Ondrej Jirman <megi@xff.cz>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202403261243.kcXCPAYs-lkp@intel.com/
> ---
> This is a followup for https://lore.kernel.org/lkml/2vhd45kylttgonosdcfn7ugwyy2vx56gijwf3ealz4tel65iqr@cs3kxrl6d2hh/
>
> sound/soc/sunxi/sun8i-codec.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
> index 43795362fed0..b5dafb749c3f 100644
> --- a/sound/soc/sunxi/sun8i-codec.c
> +++ b/sound/soc/sunxi/sun8i-codec.c
> @@ -232,6 +232,7 @@ struct sun8i_codec {
> struct delayed_work jack_work;
> int jack_irq;
> int jack_status;
> + int jack_type;
Where is this variable set? Below I see just usage of its value.
Best regards,
Jernej
> int jack_last_sample;
> ktime_t jack_hbias_ready;
> struct mutex jack_mutex;
> @@ -1352,7 +1353,6 @@ static void sun8i_codec_jack_work(struct work_struct *work)
> struct sun8i_codec *scodec = container_of(work, struct sun8i_codec,
> jack_work.work);
> unsigned int mdata;
> - int type_mask = scodec->jack->jack->type;
> int type;
>
> guard(mutex)(&scodec->jack_mutex);
> @@ -1363,7 +1363,7 @@ static void sun8i_codec_jack_work(struct work_struct *work)
>
> scodec->jack_last_sample = -1;
>
> - if (type_mask & SND_JACK_MICROPHONE) {
> + if (scodec->jack_type & SND_JACK_MICROPHONE) {
> /*
> * If we were in disconnected state, we enable HBIAS and
> * wait 600ms before reading initial HDATA value.
> @@ -1376,7 +1376,7 @@ static void sun8i_codec_jack_work(struct work_struct *work)
> scodec->jack_status = SUN8I_JACK_STATUS_WAITING_HBIAS;
> } else {
> snd_soc_jack_report(scodec->jack, SND_JACK_HEADPHONE,
> - type_mask);
> + scodec->jack_type);
> scodec->jack_status = SUN8I_JACK_STATUS_CONNECTED;
> }
> } else if (scodec->jack_status == SUN8I_JACK_STATUS_WAITING_HBIAS) {
> @@ -1417,17 +1417,17 @@ static void sun8i_codec_jack_work(struct work_struct *work)
> if (type == SND_JACK_HEADPHONE)
> sun8i_codec_set_hmic_bias(scodec, false);
>
> - snd_soc_jack_report(scodec->jack, type, type_mask);
> + snd_soc_jack_report(scodec->jack, type, scodec->jack_type);
> scodec->jack_status = SUN8I_JACK_STATUS_CONNECTED;
> } else if (scodec->jack_status == SUN8I_JACK_STATUS_CONNECTED) {
> if (scodec->last_hmic_irq != SUN8I_HMIC_STS_JACK_OUT_IRQ_ST)
> return;
>
> scodec->jack_status = SUN8I_JACK_STATUS_DISCONNECTED;
> - if (type_mask & SND_JACK_MICROPHONE)
> + if (scodec->jack_type & SND_JACK_MICROPHONE)
> sun8i_codec_set_hmic_bias(scodec, false);
>
> - snd_soc_jack_report(scodec->jack, 0, type_mask);
> + snd_soc_jack_report(scodec->jack, 0, scodec->jack_type);
> }
> }
>
> @@ -1491,7 +1491,7 @@ static irqreturn_t sun8i_codec_jack_irq(int irq, void *dev_id)
> if (scodec->jack_last_sample >= 0 &&
> scodec->jack_last_sample == value)
> snd_soc_jack_report(scodec->jack, type,
> - scodec->jack->jack->type);
> + scodec->jack_type);
>
> scodec->jack_last_sample = value;
> }
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ASoC: sunxi: sun4i-i2s: Enable 32-bit audio formats
From: Jernej Škrabec @ 2024-03-27 19:53 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Chen-Yu Tsai, Samuel Holland, John Watts
Cc: linux-sound, linux-arm-kernel, linux-sunxi, linux-kernel,
John Watts
In-Reply-To: <20240326-sunxi_s32-v1-1-899f71dcb1e6@jookia.org>
Dne torek, 26. marec 2024 ob 04:50:03 CET je John Watts napisal(a):
> The I2S driver already supports and checks for 32-bit sample sizes,
> so indicate this size is available for use in the DAI driver.
>
> This change has been tested on the T113-S3, but it should work just
> fine on older hardware as get_sr checks for sample size support
> correctly according to each core's datasheet.
>
> Signed-off-by: John Watts <contact@jookia.org>
> ---
> This patch enables support for 32-bit audio in the sunxi I2S driver.
>
> I have only tested this on the Allwinner T113 but I'm fairly
> certain it will work on older boards.
> ---
> sound/soc/sunxi/sun4i-i2s.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index a736f632bf0b..aeea852141c1 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -1103,7 +1103,8 @@ static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = {
>
> #define SUN4I_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
> SNDRV_PCM_FMTBIT_S20_LE | \
> - SNDRV_PCM_FMTBIT_S24_LE)
> + SNDRV_PCM_FMTBIT_S24_LE | \
> + SNDRV_PCM_FMTBIT_S32_LE)
I wish it would be that simple. SUN4I_FORMATS is cross section of all I2S
variants that are supported by this driver. If you check A10, you'll see that
it doesn't support S32.
If you want to add support for S32, you'll have to add new quirk for each
variant.
Best regards,
Jernej
>
> static struct snd_soc_dai_driver sun4i_i2s_dai = {
> .capture = {
>
> ---
> base-commit: 72fb52fb0ac44b6a1edd9bc390e44bce3acccd26
> change-id: 20240326-sunxi_s32-f2ab25b8e688
>
> Best regards,
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] arm64: dts: rockchip: Add enable-strobe-pulldown to emmc phy on ROCK 4C+
From: Folker Schwesinger @ 2024-03-27 19:26 UTC (permalink / raw)
To: Vinod Koul, Yogesh Hegde, Heiko Stuebner, Chris Ruehl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Folker Schwesinger, Dragan Simic, Christopher Obbard,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
In-Reply-To: <20240327192641.14220-1-dev@folker-schwesinger.de>
Commit 8b5c2b45b8f0 disabled the internal pull-down for the strobe line
causing I/O errors in HS400 mode for various eMMC modules.
Enable the internal strobe pull-down for the ROCK 4C+ board. Also re-enable
HS400 mode, that was replaced with HS200 mode as a workaround for the
stability issues in:
2bd1d2dd808c ("arm64: dts: rockchip: Disable HS400 for eMMC on ROCK 4C+").
Fixes: 8b5c2b45b8f0 ("phy: rockchip: set pulldown for strobe line in dts")
Signed-off-by: Folker Schwesinger <dev@folker-schwesinger.de>
---
arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts
index 7baf9d1b22fd..972aea843afd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts
@@ -151,6 +151,7 @@ &cpu_b1 {
};
&emmc_phy {
+ rockchip,enable-strobe-pulldown;
status = "okay";
};
@@ -549,7 +550,8 @@ &saradc {
&sdhci {
max-frequency = <150000000>;
bus-width = <8>;
- mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
non-removable;
status = "okay";
};
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 00/14] Unified cross-architecture kernel-mode FPU API
From: Samuel Holland @ 2024-03-27 20:00 UTC (permalink / raw)
To: Andrew Morton, linux-arm-kernel, x86
Cc: linux-kernel, linux-arch, linuxppc-dev, linux-riscv,
Christoph Hellwig, loongarch, amd-gfx, Samuel Holland,
Borislav Petkov, Catalin Marinas, Dave Hansen, Huacai Chen,
Ingo Molnar, Jonathan Corbet, Masahiro Yamada, Nathan Chancellor,
Nicolas Schier, Russell King, Thomas Gleixner, Will Deacon,
linux-doc, linux-kbuild
This series unifies the kernel-mode FPU API across several architectures
by wrapping the existing functions (where needed) in consistently-named
functions placed in a consistent header location, with mostly the same
semantics: they can be called from preemptible or non-preemptible task
context, and are not assumed to be reentrant. Architectures are also
expected to provide CFLAGS adjustments for compiling FPU-dependent code.
For the moment, SIMD/vector units are out of scope for this common API.
This allows us to remove the ifdeffery and duplicated Makefile logic at
each FPU user. It then implements the common API on RISC-V, and converts
a couple of users to the new API: the AMDGPU DRM driver, and the FPU
self test.
The underlying goal of this series is to allow using newer AMD GPUs
(e.g. Navi) on RISC-V boards such as SiFive's HiFive Unmatched. Those
GPUs need CONFIG_DRM_AMD_DC_FP to initialize, which requires kernel-mode
FPU support.
Previous versions:
v2: https://lore.kernel.org/linux-kernel/20231228014220.3562640-1-samuel.holland@sifive.com/
v1: https://lore.kernel.org/linux-kernel/20231208055501.2916202-1-samuel.holland@sifive.com/
v0: https://lore.kernel.org/linux-kernel/20231122030621.3759313-1-samuel.holland@sifive.com/
Changes in v3:
- Rebase on v6.9-rc1
- Limit ARCH_HAS_KERNEL_FPU_SUPPORT to 64BIT
Changes in v2:
- Add documentation explaining the built-time and runtime APIs
- Add a linux/fpu.h header for generic isolation enforcement
- Remove file name from header comment
- Clean up arch/arm64/lib/Makefile, like for arch/arm
- Remove RISC-V architecture-specific preprocessor check
- Split altivec removal to a separate patch
- Use linux/fpu.h instead of asm/fpu.h in consumers
- Declare test_fpu() in a header
Michael Ellerman (1):
drm/amd/display: Only use hard-float, not altivec on powerpc
Samuel Holland (13):
arch: Add ARCH_HAS_KERNEL_FPU_SUPPORT
ARM: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
ARM: crypto: Use CC_FLAGS_FPU for NEON CFLAGS
arm64: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
arm64: crypto: Use CC_FLAGS_FPU for NEON CFLAGS
lib/raid6: Use CC_FLAGS_FPU for NEON CFLAGS
LoongArch: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
powerpc: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
x86: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
riscv: Add support for kernel-mode FPU
drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT
selftests/fpu: Move FP code to a separate translation unit
selftests/fpu: Allow building on other architectures
Documentation/core-api/floating-point.rst | 78 +++++++++++++++++++
Documentation/core-api/index.rst | 1 +
Makefile | 5 ++
arch/Kconfig | 6 ++
arch/arm/Kconfig | 1 +
arch/arm/Makefile | 7 ++
arch/arm/include/asm/fpu.h | 15 ++++
arch/arm/lib/Makefile | 3 +-
arch/arm64/Kconfig | 1 +
arch/arm64/Makefile | 9 ++-
arch/arm64/include/asm/fpu.h | 15 ++++
arch/arm64/lib/Makefile | 6 +-
arch/loongarch/Kconfig | 1 +
arch/loongarch/Makefile | 5 +-
arch/loongarch/include/asm/fpu.h | 1 +
arch/powerpc/Kconfig | 1 +
arch/powerpc/Makefile | 5 +-
arch/powerpc/include/asm/fpu.h | 28 +++++++
arch/riscv/Kconfig | 1 +
arch/riscv/Makefile | 3 +
arch/riscv/include/asm/fpu.h | 16 ++++
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/kernel_mode_fpu.c | 28 +++++++
arch/x86/Kconfig | 1 +
arch/x86/Makefile | 20 +++++
arch/x86/include/asm/fpu.h | 13 ++++
drivers/gpu/drm/amd/display/Kconfig | 2 +-
.../gpu/drm/amd/display/amdgpu_dm/dc_fpu.c | 35 +--------
drivers/gpu/drm/amd/display/dc/dml/Makefile | 36 +--------
drivers/gpu/drm/amd/display/dc/dml2/Makefile | 36 +--------
include/linux/fpu.h | 12 +++
lib/Kconfig.debug | 2 +-
lib/Makefile | 26 +------
lib/raid6/Makefile | 31 ++------
lib/test_fpu.h | 8 ++
lib/{test_fpu.c => test_fpu_glue.c} | 37 ++-------
lib/test_fpu_impl.c | 37 +++++++++
37 files changed, 343 insertions(+), 190 deletions(-)
create mode 100644 Documentation/core-api/floating-point.rst
create mode 100644 arch/arm/include/asm/fpu.h
create mode 100644 arch/arm64/include/asm/fpu.h
create mode 100644 arch/powerpc/include/asm/fpu.h
create mode 100644 arch/riscv/include/asm/fpu.h
create mode 100644 arch/riscv/kernel/kernel_mode_fpu.c
create mode 100644 arch/x86/include/asm/fpu.h
create mode 100644 include/linux/fpu.h
create mode 100644 lib/test_fpu.h
rename lib/{test_fpu.c => test_fpu_glue.c} (71%)
create mode 100644 lib/test_fpu_impl.c
--
2.43.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 02/14] ARM: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
From: Samuel Holland @ 2024-03-27 20:00 UTC (permalink / raw)
To: Andrew Morton, linux-arm-kernel, x86
Cc: linux-kernel, linux-arch, linuxppc-dev, linux-riscv,
Christoph Hellwig, loongarch, amd-gfx, Samuel Holland,
Russell King
In-Reply-To: <20240327200157.1097089-1-samuel.holland@sifive.com>
ARM provides an equivalent to the common kernel-mode FPU API, but in a
different header and using different function names. Add a wrapper
header, and export CFLAGS adjustments as found in lib/raid6/Makefile.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
---
(no changes since v2)
Changes in v2:
- Remove file name from header comment
arch/arm/Kconfig | 1 +
arch/arm/Makefile | 7 +++++++
arch/arm/include/asm/fpu.h | 15 +++++++++++++++
3 files changed, 23 insertions(+)
create mode 100644 arch/arm/include/asm/fpu.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b14aed3a17ab..b1751c2cab87 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -15,6 +15,7 @@ config ARM
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KEEPINITRD
select ARCH_HAS_KCOV
+ select ARCH_HAS_KERNEL_FPU_SUPPORT if KERNEL_MODE_NEON
select ARCH_HAS_MEMBARRIER_SYNC_CORE
select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
select ARCH_HAS_PTE_SPECIAL if ARM_LPAE
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index d82908b1b1bb..71afdd98ddf2 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -130,6 +130,13 @@ endif
# Accept old syntax despite ".syntax unified"
AFLAGS_NOWARN :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
+# The GCC option -ffreestanding is required in order to compile code containing
+# ARM/NEON intrinsics in a non C99-compliant environment (such as the kernel)
+CC_FLAGS_FPU := -ffreestanding
+# Enable <arm_neon.h>
+CC_FLAGS_FPU += -isystem $(shell $(CC) -print-file-name=include)
+CC_FLAGS_FPU += -march=armv7-a -mfloat-abi=softfp -mfpu=neon
+
ifeq ($(CONFIG_THUMB2_KERNEL),y)
CFLAGS_ISA :=-Wa,-mimplicit-it=always $(AFLAGS_NOWARN)
AFLAGS_ISA :=$(CFLAGS_ISA) -Wa$(comma)-mthumb
diff --git a/arch/arm/include/asm/fpu.h b/arch/arm/include/asm/fpu.h
new file mode 100644
index 000000000000..2ae50bdce59b
--- /dev/null
+++ b/arch/arm/include/asm/fpu.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023 SiFive
+ */
+
+#ifndef __ASM_FPU_H
+#define __ASM_FPU_H
+
+#include <asm/neon.h>
+
+#define kernel_fpu_available() cpu_has_neon()
+#define kernel_fpu_begin() kernel_neon_begin()
+#define kernel_fpu_end() kernel_neon_end()
+
+#endif /* ! __ASM_FPU_H */
--
2.43.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 07/14] LoongArch: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
From: Samuel Holland @ 2024-03-27 20:00 UTC (permalink / raw)
To: Andrew Morton, linux-arm-kernel, x86
Cc: linux-kernel, linux-arch, linuxppc-dev, linux-riscv,
Christoph Hellwig, loongarch, amd-gfx, Samuel Holland,
WANG Xuerui, Huacai Chen
In-Reply-To: <20240327200157.1097089-1-samuel.holland@sifive.com>
LoongArch already provides kernel_fpu_begin() and kernel_fpu_end() in
asm/fpu.h, so it only needs to add kernel_fpu_available() and export
the CFLAGS adjustments.
Acked-by: WANG Xuerui <git@xen0n.name>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
---
Changes in v3:
- Rebase on v6.9-rc1
arch/loongarch/Kconfig | 1 +
arch/loongarch/Makefile | 5 ++++-
arch/loongarch/include/asm/fpu.h | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
index a5f300ec6f28..2266c6c41c38 100644
--- a/arch/loongarch/Kconfig
+++ b/arch/loongarch/Kconfig
@@ -18,6 +18,7 @@ config LOONGARCH
select ARCH_HAS_CURRENT_STACK_POINTER
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KCOV
+ select ARCH_HAS_KERNEL_FPU_SUPPORT if CPU_HAS_FPU
select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
select ARCH_HAS_PTE_SPECIAL
diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile
index df6caf79537a..efb5440a43ec 100644
--- a/arch/loongarch/Makefile
+++ b/arch/loongarch/Makefile
@@ -26,6 +26,9 @@ endif
32bit-emul = elf32loongarch
64bit-emul = elf64loongarch
+CC_FLAGS_FPU := -mfpu=64
+CC_FLAGS_NO_FPU := -msoft-float
+
ifdef CONFIG_UNWINDER_ORC
orc_hash_h := arch/$(SRCARCH)/include/generated/asm/orc_hash.h
orc_hash_sh := $(srctree)/scripts/orc_hash.sh
@@ -59,7 +62,7 @@ ld-emul = $(64bit-emul)
cflags-y += -mabi=lp64s
endif
-cflags-y += -pipe -msoft-float
+cflags-y += -pipe $(CC_FLAGS_NO_FPU)
LDFLAGS_vmlinux += -static -n -nostdlib
# When the assembler supports explicit relocation hint, we must use it.
diff --git a/arch/loongarch/include/asm/fpu.h b/arch/loongarch/include/asm/fpu.h
index c2d8962fda00..3177674228f8 100644
--- a/arch/loongarch/include/asm/fpu.h
+++ b/arch/loongarch/include/asm/fpu.h
@@ -21,6 +21,7 @@
struct sigcontext;
+#define kernel_fpu_available() cpu_has_fpu
extern void kernel_fpu_begin(void);
extern void kernel_fpu_end(void);
--
2.43.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 01/14] arch: Add ARCH_HAS_KERNEL_FPU_SUPPORT
From: Samuel Holland @ 2024-03-27 20:00 UTC (permalink / raw)
To: Andrew Morton, linux-arm-kernel, x86
Cc: linux-kernel, linux-arch, linuxppc-dev, linux-riscv,
Christoph Hellwig, loongarch, amd-gfx, Samuel Holland,
Borislav Petkov, Catalin Marinas, Dave Hansen, Huacai Chen,
Ingo Molnar, Jonathan Corbet, Masahiro Yamada, Nathan Chancellor,
Nicolas Schier, Russell King, Thomas Gleixner, Will Deacon,
linux-doc, linux-kbuild
In-Reply-To: <20240327200157.1097089-1-samuel.holland@sifive.com>
Several architectures provide an API to enable the FPU and run
floating-point SIMD code in kernel space. However, the function names,
header locations, and semantics are inconsistent across architectures,
and FPU support may be gated behind other Kconfig options.
Provide a standard way for architectures to declare that kernel space
FPU support is available. Architectures selecting this option must
implement what is currently the most common API (kernel_fpu_begin() and
kernel_fpu_end(), plus a new function kernel_fpu_available()) and
provide the appropriate CFLAGS for compiling floating-point C code.
Suggested-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
---
(no changes since v2)
Changes in v2:
- Add documentation explaining the built-time and runtime APIs
- Add a linux/fpu.h header for generic isolation enforcement
Documentation/core-api/floating-point.rst | 78 +++++++++++++++++++++++
Documentation/core-api/index.rst | 1 +
Makefile | 5 ++
arch/Kconfig | 6 ++
include/linux/fpu.h | 12 ++++
5 files changed, 102 insertions(+)
create mode 100644 Documentation/core-api/floating-point.rst
create mode 100644 include/linux/fpu.h
diff --git a/Documentation/core-api/floating-point.rst b/Documentation/core-api/floating-point.rst
new file mode 100644
index 000000000000..a8d0d4b05052
--- /dev/null
+++ b/Documentation/core-api/floating-point.rst
@@ -0,0 +1,78 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Floating-point API
+==================
+
+Kernel code is normally prohibited from using floating-point (FP) registers or
+instructions, including the C float and double data types. This rule reduces
+system call overhead, because the kernel does not need to save and restore the
+userspace floating-point register state.
+
+However, occasionally drivers or library functions may need to include FP code.
+This is supported by isolating the functions containing FP code to a separate
+translation unit (a separate source file), and saving/restoring the FP register
+state around calls to those functions. This creates "critical sections" of
+floating-point usage.
+
+The reason for this isolation is to prevent the compiler from generating code
+touching the FP registers outside these critical sections. Compilers sometimes
+use FP registers to optimize inlined ``memcpy`` or variable assignment, as
+floating-point registers may be wider than general-purpose registers.
+
+Usability of floating-point code within the kernel is architecture-specific.
+Additionally, because a single kernel may be configured to support platforms
+both with and without a floating-point unit, FPU availability must be checked
+both at build time and at run time.
+
+Several architectures implement the generic kernel floating-point API from
+``linux/fpu.h``, as described below. Some other architectures implement their
+own unique APIs, which are documented separately.
+
+Build-time API
+--------------
+
+Floating-point code may be built if the option ``ARCH_HAS_KERNEL_FPU_SUPPORT``
+is enabled. For C code, such code must be placed in a separate file, and that
+file must have its compilation flags adjusted using the following pattern::
+
+ CFLAGS_foo.o += $(CC_FLAGS_FPU)
+ CFLAGS_REMOVE_foo.o += $(CC_FLAGS_NO_FPU)
+
+Architectures are expected to define one or both of these variables in their
+top-level Makefile as needed. For example::
+
+ CC_FLAGS_FPU := -mhard-float
+
+or::
+
+ CC_FLAGS_NO_FPU := -msoft-float
+
+Normal kernel code is assumed to use the equivalent of ``CC_FLAGS_NO_FPU``.
+
+Runtime API
+-----------
+
+The runtime API is provided in ``linux/fpu.h``. This header cannot be included
+from files implementing FP code (those with their compilation flags adjusted as
+above). Instead, it must be included when defining the FP critical sections.
+
+.. c:function:: bool kernel_fpu_available( void )
+
+ This function reports if floating-point code can be used on this CPU or
+ platform. The value returned by this function is not expected to change
+ at runtime, so it only needs to be called once, not before every
+ critical section.
+
+.. c:function:: void kernel_fpu_begin( void )
+ void kernel_fpu_end( void )
+
+ These functions create a floating-point critical section. It is only
+ valid to call ``kernel_fpu_begin()`` after a previous call to
+ ``kernel_fpu_available()`` returned ``true``. These functions are only
+ guaranteed to be callable from (preemptible or non-preemptible) process
+ context.
+
+ Preemption may be disabled inside critical sections, so their size
+ should be minimized. They are *not* required to be reentrant. If the
+ caller expects to nest critical sections, it must implement its own
+ reference counting.
diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
index 7a3a08d81f11..974beccd671f 100644
--- a/Documentation/core-api/index.rst
+++ b/Documentation/core-api/index.rst
@@ -48,6 +48,7 @@ Library functionality that is used throughout the kernel.
errseq
wrappers/atomic_t
wrappers/atomic_bitops
+ floating-point
Low level entry and exit
========================
diff --git a/Makefile b/Makefile
index 763b6792d3d5..710f65e4249d 100644
--- a/Makefile
+++ b/Makefile
@@ -964,6 +964,11 @@ KBUILD_CFLAGS += $(CC_FLAGS_CFI)
export CC_FLAGS_CFI
endif
+# Architectures can define flags to add/remove for floating-point support
+CC_FLAGS_FPU += -D_LINUX_FPU_COMPILATION_UNIT
+export CC_FLAGS_FPU
+export CC_FLAGS_NO_FPU
+
ifneq ($(CONFIG_FUNCTION_ALIGNMENT),0)
# Set the minimal function alignment. Use the newer GCC option
# -fmin-function-alignment if it is available, or fall back to -falign-funtions.
diff --git a/arch/Kconfig b/arch/Kconfig
index 9f066785bb71..8e34b3acf73d 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1569,6 +1569,12 @@ config ARCH_HAS_NONLEAF_PMD_YOUNG
address translations. Page table walkers that clear the accessed bit
may use this capability to reduce their search space.
+config ARCH_HAS_KERNEL_FPU_SUPPORT
+ bool
+ help
+ Architectures that select this option can run floating-point code in
+ the kernel, as described in Documentation/core-api/floating-point.rst.
+
source "kernel/gcov/Kconfig"
source "scripts/gcc-plugins/Kconfig"
diff --git a/include/linux/fpu.h b/include/linux/fpu.h
new file mode 100644
index 000000000000..2fb63e22913b
--- /dev/null
+++ b/include/linux/fpu.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _LINUX_FPU_H
+#define _LINUX_FPU_H
+
+#ifdef _LINUX_FPU_COMPILATION_UNIT
+#error FP code must be compiled separately. See Documentation/core-api/floating-point.rst.
+#endif
+
+#include <asm/fpu.h>
+
+#endif
--
2.43.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 06/14] lib/raid6: Use CC_FLAGS_FPU for NEON CFLAGS
From: Samuel Holland @ 2024-03-27 20:00 UTC (permalink / raw)
To: Andrew Morton, linux-arm-kernel, x86
Cc: linux-kernel, linux-arch, linuxppc-dev, linux-riscv,
Christoph Hellwig, loongarch, amd-gfx, Samuel Holland,
Catalin Marinas, Russell King, Will Deacon
In-Reply-To: <20240327200157.1097089-1-samuel.holland@sifive.com>
Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
tree, use it instead of duplicating the flags here.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
---
(no changes since v1)
lib/raid6/Makefile | 31 ++++++++-----------------------
1 file changed, 8 insertions(+), 23 deletions(-)
diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
index 385a94aa0b99..c71984e04c4d 100644
--- a/lib/raid6/Makefile
+++ b/lib/raid6/Makefile
@@ -33,25 +33,6 @@ CFLAGS_REMOVE_vpermxor8.o += -msoft-float
endif
endif
-# The GCC option -ffreestanding is required in order to compile code containing
-# ARM/NEON intrinsics in a non C99-compliant environment (such as the kernel)
-ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
-NEON_FLAGS := -ffreestanding
-# Enable <arm_neon.h>
-NEON_FLAGS += -isystem $(shell $(CC) -print-file-name=include)
-ifeq ($(ARCH),arm)
-NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon
-endif
-CFLAGS_recov_neon_inner.o += $(NEON_FLAGS)
-ifeq ($(ARCH),arm64)
-CFLAGS_REMOVE_recov_neon_inner.o += -mgeneral-regs-only
-CFLAGS_REMOVE_neon1.o += -mgeneral-regs-only
-CFLAGS_REMOVE_neon2.o += -mgeneral-regs-only
-CFLAGS_REMOVE_neon4.o += -mgeneral-regs-only
-CFLAGS_REMOVE_neon8.o += -mgeneral-regs-only
-endif
-endif
-
quiet_cmd_unroll = UNROLL $@
cmd_unroll = $(AWK) -v N=$* -f $(srctree)/$(src)/unroll.awk < $< > $@
@@ -75,10 +56,14 @@ targets += vpermxor1.c vpermxor2.c vpermxor4.c vpermxor8.c
$(obj)/vpermxor%.c: $(src)/vpermxor.uc $(src)/unroll.awk FORCE
$(call if_changed,unroll)
-CFLAGS_neon1.o += $(NEON_FLAGS)
-CFLAGS_neon2.o += $(NEON_FLAGS)
-CFLAGS_neon4.o += $(NEON_FLAGS)
-CFLAGS_neon8.o += $(NEON_FLAGS)
+CFLAGS_neon1.o += $(CC_FLAGS_FPU)
+CFLAGS_neon2.o += $(CC_FLAGS_FPU)
+CFLAGS_neon4.o += $(CC_FLAGS_FPU)
+CFLAGS_neon8.o += $(CC_FLAGS_FPU)
+CFLAGS_REMOVE_neon1.o += $(CC_FLAGS_NO_FPU)
+CFLAGS_REMOVE_neon2.o += $(CC_FLAGS_NO_FPU)
+CFLAGS_REMOVE_neon4.o += $(CC_FLAGS_NO_FPU)
+CFLAGS_REMOVE_neon8.o += $(CC_FLAGS_NO_FPU)
targets += neon1.c neon2.c neon4.c neon8.c
$(obj)/neon%.c: $(src)/neon.uc $(src)/unroll.awk FORCE
$(call if_changed,unroll)
--
2.43.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 10/14] riscv: Add support for kernel-mode FPU
From: Samuel Holland @ 2024-03-27 20:00 UTC (permalink / raw)
To: Andrew Morton, linux-arm-kernel, x86
Cc: linux-kernel, linux-arch, linuxppc-dev, linux-riscv,
Christoph Hellwig, loongarch, amd-gfx, Samuel Holland,
Palmer Dabbelt
In-Reply-To: <20240327200157.1097089-1-samuel.holland@sifive.com>
This is motivated by the amdgpu DRM driver, which needs floating-point
code to support recent hardware. That code is not performance-critical,
so only provide a minimal non-preemptible implementation for now.
Support is limited to riscv64 because riscv32 requires runtime (libgcc)
assistance to convert between doubles and 64-bit integers.
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
---
Changes in v3:
- Rebase on v6.9-rc1
- Limit ARCH_HAS_KERNEL_FPU_SUPPORT to 64BIT
Changes in v2:
- Remove RISC-V architecture-specific preprocessor check
arch/riscv/Kconfig | 1 +
arch/riscv/Makefile | 3 +++
arch/riscv/include/asm/fpu.h | 16 ++++++++++++++++
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/kernel_mode_fpu.c | 28 ++++++++++++++++++++++++++++
5 files changed, 49 insertions(+)
create mode 100644 arch/riscv/include/asm/fpu.h
create mode 100644 arch/riscv/kernel/kernel_mode_fpu.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index be09c8836d56..3bcd0d250810 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -27,6 +27,7 @@ config RISCV
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_GIGANTIC_PAGE
select ARCH_HAS_KCOV
+ select ARCH_HAS_KERNEL_FPU_SUPPORT if 64BIT && FPU
select ARCH_HAS_MEMBARRIER_CALLBACKS
select ARCH_HAS_MEMBARRIER_SYNC_CORE
select ARCH_HAS_MMIOWB
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 252d63942f34..76ff4033c854 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -84,6 +84,9 @@ KBUILD_CFLAGS += -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64i
KBUILD_AFLAGS += -march=$(riscv-march-y)
+# For C code built with floating-point support, exclude V but keep F and D.
+CC_FLAGS_FPU := -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64ima)([^v_]*)v?/\1\2/')
+
KBUILD_CFLAGS += -mno-save-restore
KBUILD_CFLAGS += -DCONFIG_PAGE_OFFSET=$(CONFIG_PAGE_OFFSET)
diff --git a/arch/riscv/include/asm/fpu.h b/arch/riscv/include/asm/fpu.h
new file mode 100644
index 000000000000..91c04c244e12
--- /dev/null
+++ b/arch/riscv/include/asm/fpu.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023 SiFive
+ */
+
+#ifndef _ASM_RISCV_FPU_H
+#define _ASM_RISCV_FPU_H
+
+#include <asm/switch_to.h>
+
+#define kernel_fpu_available() has_fpu()
+
+void kernel_fpu_begin(void);
+void kernel_fpu_end(void);
+
+#endif /* ! _ASM_RISCV_FPU_H */
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index 81d94a8ee10f..5b243d46f4b1 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_RISCV_MISALIGNED) += unaligned_access_speed.o
obj-$(CONFIG_RISCV_PROBE_UNALIGNED_ACCESS) += copy-unaligned.o
obj-$(CONFIG_FPU) += fpu.o
+obj-$(CONFIG_FPU) += kernel_mode_fpu.o
obj-$(CONFIG_RISCV_ISA_V) += vector.o
obj-$(CONFIG_RISCV_ISA_V) += kernel_mode_vector.o
obj-$(CONFIG_SMP) += smpboot.o
diff --git a/arch/riscv/kernel/kernel_mode_fpu.c b/arch/riscv/kernel/kernel_mode_fpu.c
new file mode 100644
index 000000000000..0ac8348876c4
--- /dev/null
+++ b/arch/riscv/kernel/kernel_mode_fpu.c
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023 SiFive
+ */
+
+#include <linux/export.h>
+#include <linux/preempt.h>
+
+#include <asm/csr.h>
+#include <asm/fpu.h>
+#include <asm/processor.h>
+#include <asm/switch_to.h>
+
+void kernel_fpu_begin(void)
+{
+ preempt_disable();
+ fstate_save(current, task_pt_regs(current));
+ csr_set(CSR_SSTATUS, SR_FS);
+}
+EXPORT_SYMBOL_GPL(kernel_fpu_begin);
+
+void kernel_fpu_end(void)
+{
+ csr_clear(CSR_SSTATUS, SR_FS);
+ fstate_restore(current, task_pt_regs(current));
+ preempt_enable();
+}
+EXPORT_SYMBOL_GPL(kernel_fpu_end);
--
2.43.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] arm64: dts: rockchip: quartzpro64: Enable the GPU
From: Dragan Simic @ 2024-03-27 20:28 UTC (permalink / raw)
To: Heiko Stübner
Cc: linux-rockchip, linux-arm-kernel, devicetree, robh+dt,
krzysztof.kozlowski+dt, conor+dt, boris.brezillon, linux-kernel,
kernel, sebastian.reichel
In-Reply-To: <6007945.alqRGMn8q6@diego>
Hello Heiko,
On 2024-03-27 11:29, Heiko Stübner wrote:
> Am Montag, 25. März 2024, 17:19:04 CET schrieb Dragan Simic:
>> Following the approach used to enable the Mali GPU on the rk3588-evb1,
>> [1]
>> do the same for the Pine64 QuartzPro64, which uses nearly identical
>> hardware
>> design as the RK3588 EVB1.
>>
>> The slight disadvantage is that the regulator coupling logic requires
>> the
>> regulators to be always on, which is also noted in the comments. This
>> is
>> obviously something to be improved at some point in the future, but
>> should
>> be fine for now, especially because the QuartzPro64 isn't a
>> battery-powered
>> board, so low power consumption isn't paramount.
>>
>> [1]
>> https://lore.kernel.org/linux-rockchip/20240325153850.189128-5-sebastian.reichel@collabora.com/
>>
>> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
>
> as lore.kernel.org and therefore b4 seems to be on vacation today, you
> get a very personal "applied" message ;-) .
>
> So, applied for 6.10 after the core rk3588-gpu-series from Sebastian.
Oh, thank you very much for this special message. :)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: rockchip: enable gpu on rk3588-jaguar
From: Heiko Stübner @ 2024-03-27 20:30 UTC (permalink / raw)
To: Rob Herring
Cc: Heiko Stuebner, linux-rockchip, quentin.schulz, linux-arm-kernel
In-Reply-To: <171155390231.3454263.7417156077347248437.robh@kernel.org>
Am Mittwoch, 27. März 2024, 16:41:16 CET schrieb Rob Herring:
>
> On Wed, 27 Mar 2024 12:21:19 +0100, Heiko Stuebner wrote:
> > From: Heiko Stuebner <heiko.stuebner@cherry.de>
> >
> > Enable the mali gpu node and add the board-specific supply-regulator.
> >
> > Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
> > ---
> > arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
>
>
> My bot found new DTB warnings on the .dts files added or changed in this
> series.
>
> Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
> are fixed by another series. Ultimately, it is up to the platform
> maintainer whether these warnings are acceptable or not. No need to reply
> unless the platform maintainer has comments.
>
> If you already ran DT checks and didn't see these error(s), then
> make sure dt-schema is up to date:
>
> pip3 install dtschema --upgrade
>
>
> New warnings running 'make CHECK_DTBS=y rockchip/rk3588-jaguar.dtb' for 20240327112120.1181570-1-heiko@sntech.de:
>
> Error: arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts:248.1-5 Label or path gpu not found
> FATAL ERROR: Syntax error parsing input tree
> make[3]: *** [scripts/Makefile.lib:427: arch/arm64/boot/dts/rockchip/rk3588-jaguar.dtb] Error 1
> make[2]: *** [scripts/Makefile.build:485: arch/arm64/boot/dts/rockchip] Error 2
> make[2]: Target 'arch/arm64/boot/dts/rockchip/rk3588-jaguar.dtb' not remade because of errors.
> make[1]: *** [/home/rob/proj/linux-dt-testing/Makefile:1387: rockchip/rk3588-jaguar.dtb] Error 2
> make: *** [Makefile:240: __sub-make] Error 2
> make: Target 'rockchip/rk3588-jaguar.dtb' not remade because of errors.
just for the record, that error fixes itself because the patch gets applied only after
the main series adding that gpu node ;-)
Heiko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] iommu/arm-smmu: Fixes for 6.9-rc
From: Will Deacon @ 2024-03-27 18:13 UTC (permalink / raw)
To: joro; +Cc: iommu, linux-arm-kernel, linux-kernel, robin.murphy, kernel-team
Hi Joerg,
Please can you pull these two Arm SMMUv3 fixes for an upcoming 6.9 -rc?
One of them fixes a regression on big-endian machines that was
introduced during the recent merge window, whereas the other fixes a
longer standing bug for hardware that doesn't implement attribute
overrides.
Summary in the tag.
Cheers,
Will
--->8
The following changes since commit 4cece764965020c22cff7665b18a012006359095:
Linux 6.9-rc1 (2024-03-24 14:10:05 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git tags/arm-smmu-fixes
for you to fetch changes up to ec9098d6bffea6e82d63640134c123a3d96e0781:
iommu/arm-smmu-v3: Fix access for STE.SHCFG (2024-03-26 10:47:39 +0000)
----------------------------------------------------------------
Arm SMMU fixes for 6.9
- Fix swabbing of the STE fields in the unlikely event of running on a
big-endian machine.
- Fix setting of STE.SHCFG on hardware that doesn't implement support
for attribute overrides.
----------------------------------------------------------------
Jason Gunthorpe (1):
iommu/arm-smmu-v3: Add cpu_to_le64() around STRTAB_STE_0_V
Mostafa Saleh (1):
iommu/arm-smmu-v3: Fix access for STE.SHCFG
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 38 +++++++++++++++++++----------
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 2 ++
2 files changed, 27 insertions(+), 13 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 0/9] spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h
From: Andy Shevchenko @ 2024-03-27 19:29 UTC (permalink / raw)
To: Mark Brown, Andy Shevchenko, linux-spi, linux-kernel,
linux-arm-kernel
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Arnd Bergmann
As Arnd suggested we may drop linux/spi/pxa2xx_spi.h as most of
its content is being used solely internally to SPI subsystem
(PXA2xx drivers). Hence this refactoring series with the additional
win of getting rid of legacy documentation.
Changelog v2:
- dropped applied patches
- added patch to amend dependencies (Mark)
- amended the second patch accordingly (Mark)
- elaborated purpose of the patch 6 in the commit message (Mark)
Cc: Arnd Bergmann <arnd@arndb.de>
Andy Shevchenko (9):
spi: pxa2xx: Narrow the Kconfig option visibility
spi: pxa2xx: Drop ACPI_PTR() and of_match_ptr()
spi: pxa2xx: Extract pxa2xx_spi_init_ssp() helper
spi: pxa2xx: Skip SSP initialization if it's done elsewhere
spi: pxa2xx: Allow number of chip select pins to be read from property
spi: pxa2xx: Provide num-cs for Sharp PDAs via device properties
spi: pxa2xx: Move contents of linux/spi/pxa2xx_spi.h to a local one
spi: pxa2xx: Remove outdated documentation
spi: pxa2xx: Don't use "proxy" headers
Documentation/spi/pxa2xx.rst | 208 ---------------------------------
arch/arm/mach-pxa/spitz.c | 25 ++--
drivers/spi/Kconfig | 5 +-
drivers/spi/spi-pxa2xx-dma.c | 11 +-
drivers/spi/spi-pxa2xx-pci.c | 10 +-
drivers/spi/spi-pxa2xx.c | 99 ++++++++++------
drivers/spi/spi-pxa2xx.h | 39 ++++++-
include/linux/spi/pxa2xx_spi.h | 48 --------
8 files changed, 133 insertions(+), 312 deletions(-)
delete mode 100644 Documentation/spi/pxa2xx.rst
delete mode 100644 include/linux/spi/pxa2xx_spi.h
--
2.43.0.rc1.1.gbec44491f096
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/2] Enable internal strobe pulldown on Radxa ROCK 4 SBCs
From: Folker Schwesinger @ 2024-03-27 19:26 UTC (permalink / raw)
To: Vinod Koul, Yogesh Hegde, Heiko Stuebner, Chris Ruehl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Folker Schwesinger, Dragan Simic, Christopher Obbard,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
Various RK3399 boards, including the ROCK Pi 4 series showed instabilities
with some eMMC modules when operating in HS400 mode [1]. Later, a missing
pull-down resistor on the eMMC strobe line was identified as the root
cause of these instabilities [2].
This series enables the internal pull-down on the eMMC PHY strobe line
for all ROCK 4 series boards as they all lack an external strobe
pull-down resistor.
Furthermore, HS400 mode is re-enabled for these boards. Previously, to
workaround the instabilities until the issue was investigated further,
HS400 mode was replaced with HS200 mode [1].
[1]: https://lore.kernel.org/all/20230705144255.115299-1-chris.obbard@collabora.com/
[2]: https://lore.kernel.org/all/20220822074139.3810-1-jensenhuang@friendlyarm.com/
Folker Schwesinger (2):
arm64: dts: rockchip: Add enable-strobe-pulldown to emmc phy on ROCK
Pi 4
arm64: dts: rockchip: Add enable-strobe-pulldown to emmc phy on ROCK
4C+
arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts | 4 +++-
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
base-commit: 4cece764965020c22cff7665b18a012006359095
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] arm64: dts: rockchip: Add enable-strobe-pulldown to emmc phy on ROCK Pi 4
From: Folker Schwesinger @ 2024-03-27 19:26 UTC (permalink / raw)
To: Vinod Koul, Yogesh Hegde, Heiko Stuebner, Chris Ruehl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Folker Schwesinger, Dragan Simic, Christopher Obbard,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
In-Reply-To: <20240327192641.14220-1-dev@folker-schwesinger.de>
Commit 8b5c2b45b8f0 disabled the internal pull-down for the strobe line
causing I/O errors in HS400 mode for various eMMC modules.
Enable the internal strobe pull-down for ROCK Pi 4 boards. Also re-enable
HS400 mode, that was replaced with HS200 mode as a workaround for the
stability issues in:
cee572756aa2 ("arm64: dts: rockchip: Disable HS400 for eMMC on ROCK Pi 4").
This was tested on ROCK 4SE and ROCK Pi 4B+.
Fixes: 8b5c2b45b8f0 ("phy: rockchip: set pulldown for strobe line in dts")
Signed-off-by: Folker Schwesinger <dev@folker-schwesinger.de>
---
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
index 281a12180703..b9d6284bb804 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
@@ -194,6 +194,7 @@ &cpu_b1 {
};
&emmc_phy {
+ rockchip,enable-strobe-pulldown;
status = "okay";
};
@@ -648,7 +649,8 @@ &saradc {
&sdhci {
max-frequency = <150000000>;
bus-width = <8>;
- mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
non-removable;
status = "okay";
};
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/9] spi: pxa2xx: Extract pxa2xx_spi_init_ssp() helper
From: Andy Shevchenko @ 2024-03-27 19:29 UTC (permalink / raw)
To: Mark Brown, Andy Shevchenko, linux-spi, linux-kernel,
linux-arm-kernel
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King
In-Reply-To: <20240327193138.2385910-1-andriy.shevchenko@linux.intel.com>
Refactor pxa2xx_spi_init_pdata() by extracting a new
pxa2xx_spi_init_ssp() helper which makes code less
twisted. It will be easier to continue refactoring for
a new coming modification.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/spi/spi-pxa2xx.c | 66 +++++++++++++++++++++++-----------------
1 file changed, 38 insertions(+), 28 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 75d208087748..e7072727c25c 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1314,19 +1314,50 @@ static bool pxa2xx_spi_idma_filter(struct dma_chan *chan, void *param)
return param == chan->device->dev;
}
+static int
+pxa2xx_spi_init_ssp(struct platform_device *pdev, struct ssp_device *ssp, enum pxa_ssp_type type)
+{
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ int status;
+ u64 uid;
+
+ ssp->mmio_base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+ if (IS_ERR(ssp->mmio_base))
+ return PTR_ERR(ssp->mmio_base);
+
+ ssp->phys_base = res->start;
+
+ ssp->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(ssp->clk))
+ return PTR_ERR(ssp->clk);
+
+ ssp->irq = platform_get_irq(pdev, 0);
+ if (ssp->irq < 0)
+ return ssp->irq;
+
+ ssp->type = type;
+ ssp->dev = dev;
+
+ status = acpi_dev_uid_to_integer(ACPI_COMPANION(dev), &uid);
+ if (status)
+ ssp->port_id = -1;
+ else
+ ssp->port_id = uid;
+
+ return 0;
+}
+
static struct pxa2xx_spi_controller *
pxa2xx_spi_init_pdata(struct platform_device *pdev)
{
struct pxa2xx_spi_controller *pdata;
struct device *dev = &pdev->dev;
struct device *parent = dev->parent;
- struct ssp_device *ssp;
- struct resource *res;
enum pxa_ssp_type type = SSP_UNDEFINED;
const void *match;
bool is_lpss_priv;
int status;
- u64 uid;
is_lpss_priv = platform_get_resource_byname(pdev, IORESOURCE_MEM, "lpss_priv");
@@ -1351,14 +1382,6 @@ pxa2xx_spi_init_pdata(struct platform_device *pdev)
if (!pdata)
return ERR_PTR(-ENOMEM);
- ssp = &pdata->ssp;
-
- ssp->mmio_base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
- if (IS_ERR(ssp->mmio_base))
- return ERR_CAST(ssp->mmio_base);
-
- ssp->phys_base = res->start;
-
/* Platforms with iDMA 64-bit */
if (is_lpss_priv) {
pdata->tx_param = parent;
@@ -1366,28 +1389,15 @@ pxa2xx_spi_init_pdata(struct platform_device *pdev)
pdata->dma_filter = pxa2xx_spi_idma_filter;
}
- ssp->clk = devm_clk_get(dev, NULL);
- if (IS_ERR(ssp->clk))
- return ERR_CAST(ssp->clk);
-
- ssp->irq = platform_get_irq(pdev, 0);
- if (ssp->irq < 0)
- return ERR_PTR(ssp->irq);
-
- ssp->type = type;
- ssp->dev = dev;
-
- status = acpi_dev_uid_to_integer(ACPI_COMPANION(dev), &uid);
- if (status)
- ssp->port_id = -1;
- else
- ssp->port_id = uid;
-
pdata->is_target = device_property_read_bool(dev, "spi-slave");
pdata->num_chipselect = 1;
pdata->enable_dma = true;
pdata->dma_burst_size = 1;
+ status = pxa2xx_spi_init_ssp(pdev, &pdata->ssp, type);
+ if (status)
+ return ERR_PTR(status);
+
return pdata;
}
--
2.43.0.rc1.1.gbec44491f096
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/9] spi: pxa2xx: Skip SSP initialization if it's done elsewhere
From: Andy Shevchenko @ 2024-03-27 19:29 UTC (permalink / raw)
To: Mark Brown, Andy Shevchenko, linux-spi, linux-kernel,
linux-arm-kernel
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King
In-Reply-To: <20240327193138.2385910-1-andriy.shevchenko@linux.intel.com>
If SSP has been enumerated elsewhere, skip its initialization
in pxa2xx_spi_init_pdata().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/spi/spi-pxa2xx.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index e7072727c25c..b01a18c89b6b 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1355,6 +1355,7 @@ pxa2xx_spi_init_pdata(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct device *parent = dev->parent;
enum pxa_ssp_type type = SSP_UNDEFINED;
+ struct ssp_device *ssp = NULL;
const void *match;
bool is_lpss_priv;
int status;
@@ -1372,6 +1373,10 @@ pxa2xx_spi_init_pdata(struct platform_device *pdev)
return ERR_PTR(status);
type = (enum pxa_ssp_type)value;
+ } else {
+ ssp = pxa_ssp_request(pdev->id, pdev->name);
+ if (ssp)
+ type = ssp->type;
}
/* Validate the SSP type correctness */
@@ -1394,6 +1399,10 @@ pxa2xx_spi_init_pdata(struct platform_device *pdev)
pdata->enable_dma = true;
pdata->dma_burst_size = 1;
+ /* If SSP has been already enumerated, use it */
+ if (ssp)
+ return pdata;
+
status = pxa2xx_spi_init_ssp(pdev, &pdata->ssp, type);
if (status)
return ERR_PTR(status);
--
2.43.0.rc1.1.gbec44491f096
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/9] spi: pxa2xx: Narrow the Kconfig option visibility
From: Andy Shevchenko @ 2024-03-27 19:29 UTC (permalink / raw)
To: Mark Brown, Andy Shevchenko, linux-spi, linux-kernel,
linux-arm-kernel
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King
In-Reply-To: <20240327193138.2385910-1-andriy.shevchenko@linux.intel.com>
The PCI || ACPI dependency is the historical part of the x86 support.
Narrow the Kconfig option visibility by limiting this dependency to x86.
The drop of x86 for PCI case had happened in the commit 2b49ebda39d6
("spi/pxa2xx: allow building on a 64-bit kernel"), while the ACPI
was specifically added for Intel Lynx Point in the commit a3496855d9f1
("spi/pxa2xx: add support for Lynxpoint SPI controllers").
Note that X86 covers both 32- and 64-bit variants.
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/spi/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 26ba34a4100b..c1bb1895009c 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -817,7 +817,7 @@ config SPI_PPC4xx
config SPI_PXA2XX
tristate "PXA2xx SSP SPI master"
- depends on ARCH_PXA || ARCH_MMP || PCI || ACPI || COMPILE_TEST
+ depends on ARCH_PXA || ARCH_MMP || (X86 && (PCI || ACPI)) || COMPILE_TEST
select PXA_SSP if ARCH_PXA || ARCH_MMP
help
This enables using a PXA2xx or Sodaville SSP port as a SPI master
--
2.43.0.rc1.1.gbec44491f096
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 7/9] spi: pxa2xx: Move contents of linux/spi/pxa2xx_spi.h to a local one
From: Andy Shevchenko @ 2024-03-27 19:29 UTC (permalink / raw)
To: Mark Brown, Andy Shevchenko, linux-spi, linux-kernel,
linux-arm-kernel
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Arnd Bergmann
In-Reply-To: <20240327193138.2385910-1-andriy.shevchenko@linux.intel.com>
There is no user of the linux/spi/pxa2xx_spi.h. Move its contents
to the drivers/spi/spi-pxa2xx.h.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/spi/spi-pxa2xx-dma.c | 1 -
drivers/spi/spi-pxa2xx-pci.c | 4 +--
drivers/spi/spi-pxa2xx.c | 1 -
drivers/spi/spi-pxa2xx.h | 36 ++++++++++++++++++++++++-
include/linux/spi/pxa2xx_spi.h | 48 ----------------------------------
5 files changed, 37 insertions(+), 53 deletions(-)
delete mode 100644 include/linux/spi/pxa2xx_spi.h
diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index be563f0dd03a..26416ced6505 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -12,7 +12,6 @@
#include <linux/scatterlist.h>
#include <linux/sizes.h>
-#include <linux/spi/pxa2xx_spi.h>
#include <linux/spi/spi.h>
#include "spi-pxa2xx.h"
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index 861b21c63504..e11a613bc340 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -10,11 +10,11 @@
#include <linux/pci.h>
#include <linux/platform_device.h>
-#include <linux/spi/pxa2xx_spi.h>
-
#include <linux/dmaengine.h>
#include <linux/platform_data/dma-dw.h>
+#include "spi-pxa2xx.h"
+
#define PCI_DEVICE_ID_INTEL_QUARK_X1000 0x0935
#define PCI_DEVICE_ID_INTEL_BYT 0x0f0e
#define PCI_DEVICE_ID_INTEL_MRFLD 0x1194
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index f4435c39d096..e22d9d29c7e9 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -24,7 +24,6 @@
#include <linux/property.h>
#include <linux/slab.h>
-#include <linux/spi/pxa2xx_spi.h>
#include <linux/spi/spi.h>
#include "spi-pxa2xx.h"
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 45cdbbc71c4b..08296729ea80 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -7,6 +7,7 @@
#ifndef SPI_PXA2XX_H
#define SPI_PXA2XX_H
+#include <linux/dmaengine.h>
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/types.h>
@@ -15,7 +16,40 @@
#include <linux/pxa2xx_ssp.h>
struct gpio_desc;
-struct pxa2xx_spi_controller;
+
+/*
+ * The platform data for SSP controller devices
+ * (resides in device.platform_data).
+ */
+struct pxa2xx_spi_controller {
+ u8 num_chipselect;
+ u8 enable_dma;
+ u8 dma_burst_size;
+ bool is_target;
+
+ /* DMA engine specific config */
+ dma_filter_fn dma_filter;
+ void *tx_param;
+ void *rx_param;
+
+ /* For non-PXA arches */
+ struct ssp_device ssp;
+};
+
+/*
+ * The controller specific data for SPI target devices
+ * (resides in spi_board_info.controller_data),
+ * copied to spi_device.platform_data ... mostly for
+ * DMA tuning.
+ */
+struct pxa2xx_spi_chip {
+ u8 tx_threshold;
+ u8 tx_hi_threshold;
+ u8 rx_threshold;
+ u8 dma_burst_size;
+ u32 timeout;
+};
+
struct spi_controller;
struct spi_device;
struct spi_transfer;
diff --git a/include/linux/spi/pxa2xx_spi.h b/include/linux/spi/pxa2xx_spi.h
deleted file mode 100644
index e5a4a045fb67..000000000000
--- a/include/linux/spi/pxa2xx_spi.h
+++ /dev/null
@@ -1,48 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- * Copyright (C) 2005 Stephen Street / StreetFire Sound Labs
- */
-#ifndef __LINUX_SPI_PXA2XX_SPI_H
-#define __LINUX_SPI_PXA2XX_SPI_H
-
-#include <linux/dmaengine.h>
-#include <linux/types.h>
-
-#include <linux/pxa2xx_ssp.h>
-
-struct dma_chan;
-
-/*
- * The platform data for SSP controller devices
- * (resides in device.platform_data).
- */
-struct pxa2xx_spi_controller {
- u8 num_chipselect;
- u8 enable_dma;
- u8 dma_burst_size;
- bool is_target;
-
- /* DMA engine specific config */
- dma_filter_fn dma_filter;
- void *tx_param;
- void *rx_param;
-
- /* For non-PXA arches */
- struct ssp_device ssp;
-};
-
-/*
- * The controller specific data for SPI target devices
- * (resides in spi_board_info.controller_data),
- * copied to spi_device.platform_data ... mostly for
- * DMA tuning.
- */
-struct pxa2xx_spi_chip {
- u8 tx_threshold;
- u8 tx_hi_threshold;
- u8 rx_threshold;
- u8 dma_burst_size;
- u32 timeout;
-};
-
-#endif /* __LINUX_SPI_PXA2XX_SPI_H */
--
2.43.0.rc1.1.gbec44491f096
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 6/9] spi: pxa2xx: Provide num-cs for Sharp PDAs via device properties
From: Andy Shevchenko @ 2024-03-27 19:29 UTC (permalink / raw)
To: Mark Brown, Andy Shevchenko, linux-spi, linux-kernel,
linux-arm-kernel
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King
In-Reply-To: <20240327193138.2385910-1-andriy.shevchenko@linux.intel.com>
Since driver can parse num-cs device property, replace platform data
with this new approach. This pursues the following objectives:
- getting rid of the public header that barely used outside of
the SPI subsystem (more specifically the SPI PXA2xx drivers)
- making a trampoline for the driver to support non-default number
of the chip select pins in case the original code is going to be
converted to Device Tree model
It's not expected to have more users in board files except this one.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
arch/arm/mach-pxa/spitz.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 318402ad685e..3c5f5a3cb480 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -18,10 +18,10 @@
#include <linux/i2c.h>
#include <linux/platform_data/i2c-pxa.h>
#include <linux/platform_data/pca953x.h>
+#include <linux/property.h>
#include <linux/spi/spi.h>
#include <linux/spi/ads7846.h>
#include <linux/spi/corgi_lcd.h>
-#include <linux/spi/pxa2xx_spi.h>
#include <linux/mtd/sharpsl.h>
#include <linux/mtd/physmap.h>
#include <linux/input-event-codes.h>
@@ -569,10 +569,6 @@ static struct spi_board_info spitz_spi_devices[] = {
},
};
-static struct pxa2xx_spi_controller spitz_spi_info = {
- .num_chipselect = 3,
-};
-
static struct gpiod_lookup_table spitz_spi_gpio_table = {
.dev_id = "spi2",
.table = {
@@ -583,10 +579,20 @@ static struct gpiod_lookup_table spitz_spi_gpio_table = {
},
};
+static const struct property_entry spitz_spi_properties[] = {
+ PROPERTY_ENTRY_U32("num-cs", 3),
+ { }
+};
+
+static const struct software_node spitz_spi_node = {
+ .properties = spitz_spi_properties,
+};
+
static void __init spitz_spi_init(void)
{
struct platform_device *pd;
int id = 2;
+ int err;
if (machine_is_akita())
gpiod_add_lookup_table(&akita_lcdcon_gpio_table);
@@ -601,8 +607,13 @@ static void __init spitz_spi_init(void)
if (pd == NULL) {
pr_err("pxa2xx-spi: failed to allocate device id %d\n", id);
} else {
- pd->dev.platform_data = &spitz_spi_info;
- platform_device_add(pd);
+ err = device_add_software_node(&pd->dev, &spitz_spi_node);
+ if (err) {
+ platform_device_put(pd);
+ pr_err("pxa2xx-spi: failed to add software node\n");
+ } else {
+ platform_device_add(pd);
+ }
}
spi_register_board_info(ARRAY_AND_SIZE(spitz_spi_devices));
--
2.43.0.rc1.1.gbec44491f096
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox