* Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file
From: Jean-Philippe Brucker @ 2019-09-20 7:18 UTC (permalink / raw)
To: Guo Ren
Cc: aou, Linux Kernel Mailing List, Arnd Bergmann, suzuki.poulose,
Marc Zyngier, Catalin Marinas, Palmer Dabbelt, christoffer.dall,
iommu, Mike Rapoport, Anup Patel, Atish Patra, Julien Grall,
james.morse, gary, Paul Walmsley, linux-riscv, Will Deacon,
kvmarm, linux-arm-kernel
In-Reply-To: <CAJF2gTQtk7VhBgUan6WOZgc3UaQzHL8SxMi=yiHG-8eC207BbQ@mail.gmail.com>
On Fri, Sep 20, 2019 at 08:07:38AM +0800, Guo Ren wrote:
> On Thu, Sep 19, 2019 at 11:18 PM Jean-Philippe Brucker
> <jean-philippe@linaro.org> wrote:
>
> >
> > The SMMU does support PCI Virtual Function - an hypervisor can assign a
> > VF to a guest, and let that guest partition the VF into smaller contexts
> > by using PASID. What it can't support is assigning partitions of a PCI
> > function (VF or PF) to multiple Virtual Machines, since there is a
> > single S2 PGD per function (in the Stream Table Entry), rather than one
> > S2 PGD per PASID context.
> >
> In my concept, the two sentences "The SMMU does support PCI Virtual
> Functio" v.s. "What it can't support is assigning partitions of a PCI
> function (VF or PF) to multiple Virtual Machines" are conflict and I
> don't want to play naming game :)
That's fine. But to prevent the spread of misinformation: Arm SMMU
supports PCI Virtual Functions.
Thanks,
Jean
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] [PATCH v3] serial: imx: adapt rx buffer and dma periods
From: Andy Duan @ 2019-09-20 7:33 UTC (permalink / raw)
To: Philipp Puschmann, linux-kernel@vger.kernel.org
Cc: festevam@gmail.com, linux-serial@vger.kernel.org,
gregkh@linuxfoundation.org, s.hauer@pengutronix.de,
u.kleine-koenig@pengutronix.de, dl-linux-imx,
kernel@pengutronix.de, jslaby@suse.com, Robin Gong,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org,
l.stach@pengutronix.de
In-Reply-To: <ac67f010-1b2c-6996-f542-ab955ca86489@emlix.com>
From: Philipp Puschmann <philipp.puschmann@emlix.com> Sent: Friday, September 20, 2019 3:06 PM
> Am 20.09.19 um 05:42 schrieb Andy Duan:
> > From: Philipp Puschmann <philipp.puschmann@emlix.com> Sent: Thursday,
> > September 19, 2019 10:51 PM
> >> Using only 4 DMA periods for UART RX is very few if we have a high
> >> frequency of small transfers - like in our case using Bluetooth with
> >> many small packets via UART - causing many dma transfers but in each
> >> only filling a fraction of a single buffer. Such a case may lead to
> >> the situation that DMA RX transfer is triggered but no free buffer is
> >> available. When this happens dma channel ist stopped - with the patch
> >> "dmaengine: imx-sdma: fix dma freezes" temporarily only - with the
> >> possible consequences that:
> >> with disabled hw flow control:
> >> If enough data is incoming on UART port the RX FIFO runs over and
> >> characters will be lost. What then happens depends on upper layer.
> >>
> >> with enabled hw flow control:
> >> If enough data is incoming on UART port the RX FIFO reaches a level
> >> where CTS is deasserted and remote device sending the data stops.
> >> If it fails to stop timely the i.MX' RX FIFO may run over and data
> >> get lost. Otherwise it's internal TX buffer may getting filled to
> >> a point where it runs over and data is again lost. It depends on
> >> the remote device how this case is handled and if it is recoverable.
> >>
> >> Obviously we want to avoid having no free buffers available. So we
> >> decrease the size of the buffers and increase their number and the total
> buffer size.
> >>
> >> Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
> >> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> >> ---
> >>
> >> Changelog v3:
> >> - enhance description
> >>
> >> Changelog v2:
> >> - split this patch from series "Fix UART DMA freezes for iMX6"
> >> - add Reviewed-by tag
> >>
> >> drivers/tty/serial/imx.c | 5 ++---
> >> 1 file changed, 2 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> >> index 87c58f9f6390..51dc19833eab 100644
> >> --- a/drivers/tty/serial/imx.c
> >> +++ b/drivers/tty/serial/imx.c
> >> @@ -1034,8 +1034,6 @@ static void imx_uart_timeout(struct timer_list
> *t)
> >> }
> >> }
> >>
> >> -#define RX_BUF_SIZE (PAGE_SIZE)
> >> -
> >> /*
> >> * There are two kinds of RX DMA interrupts(such as in the MX6Q):
> >> * [1] the RX DMA buffer is full.
> >> @@ -1118,7 +1116,8 @@ static void imx_uart_dma_rx_callback(void
> >> *data) }
> >>
> >> /* RX DMA buffer periods */
> >> -#define RX_DMA_PERIODS 4
> >> +#define RX_DMA_PERIODS 16
> >> +#define RX_BUF_SIZE (PAGE_SIZE / 4)
> >>
> > Why to decrease the DMA RX buffer size here ?
> >
> > The current DMA implementation support DMA cyclic mode, one SDMA BD
> > receive one Bluetooth frame can bring better performance.
> > As you know, for L2CAP, a maximum transmission unit (MTU) associated
> > with the largest Baseband payload is 341 bytes for DH5 packets.
> >
> > So I suggest to increase RX_BUF_SIZE along with RX_DMA_PERIODS to
> feasible value.
>
> I debugged and developed this patches on a system with a 4.15 kernel. When
> prepared for upstream i have adapted some details and missed a important
> thing here. It should say:
>
> +#define RX_BUF_SIZE (RX_DMA_PERIODS * PAGE_SIZE / 4)
>
> Yes, i wanted to increase the total buffer size too, even wrote it in the
> description.
> I will prepare a version 4, thanks for the hint.
Okay, thank you for submit the SDMA/uart patch set.
>
> Just for info: A single RX DMA period aka buffer can be filled with mutliple
> packets in regard of the upper layer, here BT.
Yes, that depends on system loading.
>
>
> Regards,
> Philipp
> >
> > Andy
> >
> >> static int imx_uart_start_rx_dma(struct imx_port *sport) {
> >> --
> >> 2.23.0
> >
_______________________________________________
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/3] dt-bindings: power: add Amlogic secure power domains bindings
From: Jianxin Pan @ 2019-09-20 7:37 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: devicetree, Hanjie Lin, Victor Wan, Neil Armstrong, Kevin Hilman,
linux-pm, linux-kernel, Zhiqiang Liang, Rob Herring, Jian Hu,
Xingyu Chen, linux-amlogic, linux-arm-kernel, Jerome Brunet
In-Reply-To: <CAFBinCCxeYgso3WQWqNgWUwwCM835uo_6FftVv0YwYTFJV2Ovw@mail.gmail.com>
Hi Martin,
On 2019/9/20 4:06, Martin Blumenstingl wrote:
> Hi Jianxin,
>
> On Thu, Sep 19, 2019 at 2:11 PM Jianxin Pan <jianxin.pan@amlogic.com> wrote:
>>
>> Add the bindings for the Amlogic Secure power domains, controlling the
>> secure power domains.
>>
>> The bindings targets the Amlogic A1 and C1 compatible SoCs, in which the
>> power domain registers are in secure world.
>>
>> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
>> Signed-off-by: Zhiqiang Liang <zhiqiang.liang@amlogic.com>
>> ---
>> .../bindings/power/amlogic,meson-sec-pwrc.yaml | 32 ++++++++++++++++++++++
>> include/dt-bindings/power/meson-a1-power.h | 32 ++++++++++++++++++++++
>> 2 files changed, 64 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
>> create mode 100644 include/dt-bindings/power/meson-a1-power.h
>>
>> diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
>> new file mode 100644
>> index 00000000..327e0d9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
>> @@ -0,0 +1,32 @@
>> +# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
[...]>> +examples:
>> + - |
>> + pwrc: power-controller {
>> + compatible = "amlogic,meson-a1-pwrc";
>> + };
> not a comment about this binding but about the secure monitor in general:
> there's a recent discussion about the secure monitor in the nvmem bindings: [0]
>
>
> Martin
>
>
> [0] https://www.spinics.net/lists/arm-kernel/msg750010.html
>
Thanks for your remind,I will update and send the second version after Rework of secure-monitor driver is applied.
> .
>
_______________________________________________
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] ARM: aspeed: ast2500 is ARMv6K
From: Arnd Bergmann @ 2019-09-20 7:42 UTC (permalink / raw)
To: Joel Stanley
Cc: Andrew Jeffery, linux-aspeed, Linux ARM,
Linux Kernel Mailing List
In-Reply-To: <CACPK8XcsegR5R0nkiZ-UEMgCqNMggCXjAr2N-6J1S6mEhGLrBQ@mail.gmail.com>
On Fri, Sep 20, 2019 at 7:51 AM Joel Stanley <joel@jms.id.au> wrote:
> On Thu, 19 Sep 2019 at 14:27, Arnd Bergmann <arnd@arndb.de> wrote:
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > arch/arm/mach-aspeed/Kconfig | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-aspeed/Kconfig b/arch/arm/mach-aspeed/Kconfig
> > index a293137f5814..163931a03136 100644
> > --- a/arch/arm/mach-aspeed/Kconfig
> > +++ b/arch/arm/mach-aspeed/Kconfig
> > @@ -26,7 +26,6 @@ config MACH_ASPEED_G4
> > config MACH_ASPEED_G5
> > bool "Aspeed SoC 5th Generation"
> > depends on ARCH_MULTI_V6
> > - select CPU_V6
> > select PINCTRL_ASPEED_G5 if !CC_IS_CLANG
>
> I can't find any trees with !CC_IS_CLANG here. Is there a problem
> building our pinmux driver with Clang?
This was an unrelated change from my local randconfig tree.
Your driver uncovered a bug in clang that is now fixed, the driver
itself is fine, see https://bugs.llvm.org/show_bug.cgi?id=43243
> I tested with this patch:
> --- a/arch/arm/mach-aspeed/Kconfig
> +++ b/arch/arm/mach-aspeed/Kconfig
> @@ -25,8 +25,8 @@ config MACH_ASPEED_G4
>
> config MACH_ASPEED_G5
> bool "Aspeed SoC 5th Generation"
> + # This implies ARMv6K which covers the ARM1176
> depends on ARCH_MULTI_V6
> - select CPU_V6
> select PINCTRL_ASPEED_G5
> select FTTMR010_TIMER
> help
>
> If you want to apply that as a fix for 5.4 I would be happy with that.
>
> Fixes: 8c2ed9bcfbeb ("arm: Add Aspeed machine")
> Reviewed-by: Joel Stanley <joel@jms.id.au>
Applied to arm/fixes now.
Arnd
_______________________________________________
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 V6 0/3] mmc: mmci: add busy detect for stm32 sdmmc variant
From: Ulf Hansson @ 2019-09-20 7:47 UTC (permalink / raw)
To: Ludovic BARRE
Cc: DTML, Alexandre Torgue, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, Rob Herring, Srinivas Kandagatla,
Maxime Coquelin, linux-stm32, Linux ARM
In-Reply-To: <940e3ce8-1a4f-7e03-dfec-25330051ea5f@st.com>
On Wed, 18 Sep 2019 at 11:33, Ludovic BARRE <ludovic.barre@st.com> wrote:
>
> hi Ulf
>
> Just a "gentleman ping" about this series and
> https://lkml.org/lkml/2019/9/4/747
Thanks for pinging, I will come to this as soon as I can. September
has been a busy month, being on the road most of the time.
Apologize for the delays!
[...]
Kind regards
Uffe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 1/2] dt-bindings: add vendor prefix for logic technologies limited
From: Marcel Ziswiler @ 2019-09-20 7:54 UTC (permalink / raw)
To: dri-devel
Cc: Mark Rutland, devicetree, Heiko Stuebner, Marcel Ziswiler,
j.bauer, linux-kernel, Maxime Ripard, info, Rob Herring,
Laurent Pinchart, Hans Verkuil, Shawn Guo, linux-arm-kernel,
Icenowy Zheng
From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Add vendor prefix for Logic Technologies Limited [1] which is a Chinese
display manufacturer e.g. distributed by German Endrich Bauelemente
Vertriebs GmbH [2].
[1] https://logictechno.com/contact-us/
[2] https://www.endrich.com/isi50_isi30_tft-displays/lt170410-1whc_isi30
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 967e78c5ec0a..1441146f394f 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -541,6 +541,8 @@ patternProperties:
description: Linear Technology Corporation
"^logicpd,.*":
description: Logic PD, Inc.
+ "^logictechno,.*":
+ description: Logic Technologies Limited
"^longcheer,.*":
description: Longcheer Technology (Shanghai) Co., Ltd.
"^lsi,.*":
--
2.21.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 v1 2/2] drm/panel: simple: add display timings for logic technologies displays
From: Marcel Ziswiler @ 2019-09-20 7:54 UTC (permalink / raw)
To: dri-devel
Cc: devicetree, Marcel Ziswiler, j.bauer, linux-kernel, David Airlie,
info, Thierry Reding, Daniel Vetter, Sam Ravnborg,
linux-arm-kernel
In-Reply-To: <20190920075411.15735-1-marcel@ziswiler.com>
From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Add display timings for the following 3 display panels manufactured by
Logic Technologies Limited:
- LT161010-2NHC e.g. as found in the Toradex Capacitive Touch Display
7" Parallel [1]
- LT161010-2NHR e.g. as found in the Toradex Resistive Touch Display 7"
Parallel [2]
- LT170410-2WHC e.g. as found in the Toradex Capacitive Touch Display
10.1" LVDS [3]
Those panels may also be distributed by Endrich Bauelemente Vertriebs
GmbH [4].
[1] https://docs.toradex.com/104497-7-inch-parallel-capacitive-touch-display-800x480-datasheet.pdf
[2] https://docs.toradex.com/104498-7-inch-parallel-resistive-touch-display-800x480.pdf
[3] https://docs.toradex.com/105952-10-1-inch-lvds-capacitive-touch-display-1280x800-datasheet.pdf
[4] https://www.endrich.com/isi50_isi30_tft-displays/lt170410-1whc_isi30
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
drivers/gpu/drm/panel/panel-simple.c | 65 ++++++++++++++++++++++++++++
1 file changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 28fa6ba7b767..42bd0de25167 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2034,6 +2034,62 @@ static const struct panel_desc lg_lp129qe = {
},
};
+static const struct display_timing logictechno_lt161010_2nh_timing = {
+ .pixelclock = { 26400000, 33300000, 46800000 },
+ .hactive = { 800, 800, 800 },
+ .hfront_porch = { 16, 210, 354 },
+ .hback_porch = { 46, 46, 46 },
+ .hsync_len = { 1, 20, 40 },
+ .vactive = { 480, 480, 480 },
+ .vfront_porch = { 7, 22, 147 },
+ .vback_porch = { 23, 23, 23 },
+ .vsync_len = { 1, 10, 20 },
+ .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+ DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE |
+ DISPLAY_FLAGS_SYNC_POSEDGE,
+};
+
+static const struct panel_desc logictechno_lt161010_2nh = {
+ .timings = &logictechno_lt161010_2nh_timing,
+ .num_timings = 1,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH |
+ DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
+ DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE,
+};
+
+static const struct display_timing logictechno_lt170410_2whc_timing = {
+ .pixelclock = { 68900000, 71100000, 7340000 },
+ .hactive = { 1280, 1280, 1280 },
+ .hfront_porch = { 23, 60, 71 },
+ .hback_porch = { 23, 60, 71 },
+ .hsync_len = { 15, 40, 47 },
+ .vactive = { 800, 800, 800 },
+ .vfront_porch = { 5, 7, 10 },
+ .vback_porch = { 5, 7, 10 },
+ .vsync_len = { 6, 9, 12 },
+ .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+ DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE |
+ DISPLAY_FLAGS_SYNC_POSEDGE,
+};
+
+static const struct panel_desc logictechno_lt170410_2whc = {
+ .timings = &logictechno_lt170410_2whc_timing,
+ .num_timings = 1,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH |
+ DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
+ DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE,
+};
+
static const struct drm_display_mode mitsubishi_aa070mc01_mode = {
.clock = 30400,
.hdisplay = 800,
@@ -3264,6 +3320,15 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "lg,lp129qe",
.data = &lg_lp129qe,
+ }, {
+ .compatible = "logictechno,lt161010-2nhc",
+ .data = &logictechno_lt161010_2nh,
+ }, {
+ .compatible = "logictechno,lt161010-2nhr",
+ .data = &logictechno_lt161010_2nh,
+ }, {
+ .compatible = "logictechno,lt170410-2whc",
+ .data = &logictechno_lt170410_2whc,
}, {
.compatible = "mitsubishi,aa070mc01-ca1",
.data = &mitsubishi_aa070mc01,
--
2.21.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
* Re: [PATCH 2/3] soc: amlogic: Add support for Secure power domains controller
From: Jianxin Pan @ 2019-09-20 7:58 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: devicetree, Hanjie Lin, Victor Wan, Neil Armstrong, Kevin Hilman,
linux-pm, linux-kernel, Zhiqiang Liang, Rob Herring, Jian Hu,
Xingyu Chen, linux-amlogic, linux-arm-kernel, Jerome Brunet
In-Reply-To: <CAFBinCDv2m_0tP+rdT1tgXhMs-hPE_cJ9TmO8h9ftDvJXvby+g@mail.gmail.com>
Hi Martin,
On 2019/9/20 4:03, Martin Blumenstingl wrote:
> Hi Jianxin,
>
> I added three comments below from a quick glance at this driver (I
> didn't have time for a complete review)
>
> On Thu, Sep 19, 2019 at 2:11 PM Jianxin Pan <jianxin.pan@amlogic.com> wrote:
> [...]
>> + pm_genpd_init(&dom->base, NULL,
>> + (match->domains[i].get_power ?
>> + match->domains[i].get_power(dom) : true));
> .get_power is never NULL in this driver so the ": true" part is
> effectively a no-op
>
OK, I will remove it. Thanks for your time.
> [...]
>> +static const struct of_device_id meson_secure_pwrc_match_table[] = {
>> + {
>> + .compatible = "amlogic,meson-a1-pwrc",
>> + .data = &meson_secure_a1_pwrc_data,
>> + },
>> + { }
> many drivers use a /* sentinel */ comment inside { }
>
OK, I will add this comment line.
> [...]
>> +arch_initcall_sync(meson_secure_pwrc_init);
> why arch_initcall_sync instead of builtin_platform_driver?
> $ grep -R arch_initcall_sync drivers/soc/
> $
>
>
> Martin
>
The power-domain is depended by many other drivers, arch_initcall_sync is used to make power-domain probe earlier.
Maybe I need to switch back to builtin_platform_driver when use APIs from meson_sm.c.
> .
>
_______________________________________________
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 linux-next 0/4] arm/arm64: configs: Convert all CONFIG_REMOTEPROC instances to y
From: Keerthy @ 2019-09-20 7:59 UTC (permalink / raw)
To: arnd, nsekhar, olof, t-kristo, catalin.marinas, will, tony
Cc: j-keerthy, linux-kernel, bjorn.andersson, linux-omap, hch,
linux-arm-kernel
Commit 6334150e9 changes CONFIG_REMOTEPROC to a boolean config
option that inhibits all defconfigs marking CONFIG_REMOTEPROC as
a module in compiling the remoteproc and dependent config options.
So convert all the instances to built in.
Boot tested for omap2plus_defconfig for dra7/am4/am3.
Any quick testing on other boards welcome.
Patches apply on top of linux-next branch
Changes in v2:
Cc the right lists.
Keerthy (4):
arm: configs: omap2plus_defconfig: Change CONFIG_REMOTEPROC from m to
y
arm: configs: davinci_all_defconfig: Change CONFIG_REMOTEPROC from m
to y
arm: configs: multi_v7_defconfig: Change CONFIG_REMOTEPROC from m to
y
arm64: configs: defconfig: Change CONFIG_REMOTEPROC from m to y
arch/arm/configs/davinci_all_defconfig | 2 +-
arch/arm/configs/multi_v7_defconfig | 2 +-
arch/arm/configs/omap2plus_defconfig | 2 +-
arch/arm64/configs/defconfig | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
--
2.17.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 v2 linux-next 1/4] arm: configs: omap2plus_defconfig: Change CONFIG_REMOTEPROC from m to y
From: Keerthy @ 2019-09-20 7:59 UTC (permalink / raw)
To: arnd, nsekhar, olof, t-kristo, catalin.marinas, will, tony
Cc: j-keerthy, linux-kernel, bjorn.andersson, linux-omap, hch,
linux-arm-kernel
In-Reply-To: <20190920075946.13282-1-j-keerthy@ti.com>
Commit 6334150e9a36 ("remoteproc: don't allow modular build")
changes CONFIG_REMOTEPROC to a boolean from a tristate config
option which inhibits all defconfigs marking CONFIG_REMOTEPROC as
a module in compiling the remoteproc and dependent config options.
So fix the omap2plus_defconfig to have CONFIG_REMOTEPROC built in.
Fixes: commit 6334150e9a3646 ("remoteproc: don't allow modular build")
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
arch/arm/configs/omap2plus_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 64eb896907bf..af4069476582 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -481,7 +481,7 @@ CONFIG_RTC_DRV_OMAP=m
CONFIG_RTC_DRV_CPCAP=m
CONFIG_DMADEVICES=y
CONFIG_OMAP_IOMMU=y
-CONFIG_REMOTEPROC=m
+CONFIG_REMOTEPROC=y
CONFIG_OMAP_REMOTEPROC=m
CONFIG_WKUP_M3_RPROC=m
CONFIG_SOC_TI=y
--
2.17.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 v2 linux-next 2/4] arm: configs: davinci_all_defconfig: Change CONFIG_REMOTEPROC from m to y
From: Keerthy @ 2019-09-20 7:59 UTC (permalink / raw)
To: arnd, nsekhar, olof, t-kristo, catalin.marinas, will, tony
Cc: j-keerthy, linux-kernel, bjorn.andersson, linux-omap, hch,
linux-arm-kernel
In-Reply-To: <20190920075946.13282-1-j-keerthy@ti.com>
Commit 6334150e9a36 ("remoteproc: don't allow modular build")
changes CONFIG_REMOTEPROC to a boolean from a tristate config
option which inhibits all defconfigs marking CONFIG_REMOTEPROC as
a module in compiling the remoteproc and dependent config options.
So fix the davinci_all_defconfig to have CONFIG_REMOTEPROC built in.
Fixes: 6334150e9a36 ("remoteproc: don't allow modular build")
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
arch/arm/configs/davinci_all_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index b34970ce6b31..01e3c0f4be92 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -228,7 +228,7 @@ CONFIG_RTC_DRV_OMAP=m
CONFIG_DMADEVICES=y
CONFIG_TI_EDMA=y
CONFIG_COMMON_CLK_PWM=m
-CONFIG_REMOTEPROC=m
+CONFIG_REMOTEPROC=y
CONFIG_DA8XX_REMOTEPROC=m
CONFIG_MEMORY=y
CONFIG_TI_AEMIF=m
--
2.17.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 v2 linux-next 3/4] arm: configs: multi_v7_defconfig: Change CONFIG_REMOTEPROC from m to y
From: Keerthy @ 2019-09-20 7:59 UTC (permalink / raw)
To: arnd, nsekhar, olof, t-kristo, catalin.marinas, will, tony
Cc: j-keerthy, linux-kernel, bjorn.andersson, linux-omap, hch,
linux-arm-kernel
In-Reply-To: <20190920075946.13282-1-j-keerthy@ti.com>
Commit 6334150e9a36 ("remoteproc: don't allow modular build")
changes CONFIG_REMOTEPROC to a boolean from a tristate config
option which inhibits all defconfigs marking CONFIG_REMOTEPROC as
a module in compiling the remoteproc and dependent config options.
So fix the multi_v7_defconfig to have CONFIG_REMOTEPROC built in.
Fixes: 6334150e9a36 ("remoteproc: don't allow modular build")
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
arch/arm/configs/multi_v7_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 13ba53286901..198de8e36d92 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -933,7 +933,7 @@ CONFIG_BCM2835_MBOX=y
CONFIG_ROCKCHIP_IOMMU=y
CONFIG_TEGRA_IOMMU_GART=y
CONFIG_TEGRA_IOMMU_SMMU=y
-CONFIG_REMOTEPROC=m
+CONFIG_REMOTEPROC=y
CONFIG_ST_REMOTEPROC=m
CONFIG_RPMSG_VIRTIO=m
CONFIG_ASPEED_LPC_CTRL=m
--
2.17.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 v2 linux-next 4/4] arm64: configs: defconfig: Change CONFIG_REMOTEPROC from m to y
From: Keerthy @ 2019-09-20 7:59 UTC (permalink / raw)
To: arnd, nsekhar, olof, t-kristo, catalin.marinas, will, tony
Cc: j-keerthy, linux-kernel, bjorn.andersson, linux-omap, hch,
linux-arm-kernel
In-Reply-To: <20190920075946.13282-1-j-keerthy@ti.com>
Commit 6334150e9a36 ("remoteproc: don't allow modular build")
changes CONFIG_REMOTEPROC to a boolean from a tristate config
option which inhibits all defconfigs marking CONFIG_REMOTEPROC as
a module in compiling the remoteproc and dependent config options.
So fix the defconfig to have CONFIG_REMOTEPROC built in.
Fixes: 6334150e9a36 ("remoteproc: don't allow modular build")
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
arch/arm64/configs/defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 8e05c39eab08..c9a867ac32d4 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -723,7 +723,7 @@ CONFIG_TEGRA_IOMMU_SMMU=y
CONFIG_ARM_SMMU=y
CONFIG_ARM_SMMU_V3=y
CONFIG_QCOM_IOMMU=y
-CONFIG_REMOTEPROC=m
+CONFIG_REMOTEPROC=y
CONFIG_QCOM_Q6V5_MSS=m
CONFIG_QCOM_Q6V5_PAS=m
CONFIG_QCOM_SYSMON=m
--
2.17.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 3/3] clk: meson: clk-pll: always enable a critical PLL when setting the rate
From: Neil Armstrong @ 2019-09-20 8:06 UTC (permalink / raw)
To: Stephen Boyd, Jerome Brunet
Cc: linux-amlogic, linux-clk, linux-arm-kernel, linux-kernel
In-Reply-To: <20190919170610.541D620644@mail.kernel.org>
Hi Stephen,
On 19/09/2019 19:06, Stephen Boyd wrote:
> Quoting Jerome Brunet (2019-09-19 06:01:28)
>> On Thu 19 Sep 2019 at 11:38, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>>> Make sure we always enable a PLL on a set_rate() when the PLL is
>>> flagged as critical.
>>>
>>> This fixes the case when the Amlogic G12A SYS_PLL gets disabled by the
>>> PSCI firmware when resuming from suspend-to-memory, in the case
>>> where the CPU was not clocked by the SYS_PLL, but by the fixed PLL
>>> fixed divisors.
>>> In this particular case, when changing the PLL rate, CCF doesn't handle
>>> the fact the PLL could have been disabled in the meantime and set_rate()
>>> only changes the rate and never enables it again.
>>>
>>> Fixes: d6e81845b7d9 ("clk: meson: clk-pll: check if the clock is already enabled')
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>> ---
>>> drivers/clk/meson/clk-pll.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
>>> index ddb1e5634739..8c5adccb7959 100644
>>> --- a/drivers/clk/meson/clk-pll.c
>>> +++ b/drivers/clk/meson/clk-pll.c
>>> @@ -379,7 +379,7 @@ static int meson_clk_pll_set_rate(struct clk_hw *hw, unsigned long rate,
>>> }
>>>
>>> /* If the pll is stopped, bail out now */
>>> - if (!enabled)
>>> + if (!(hw->init->flags & CLK_IS_CRITICAL) && !enabled)
>>
>> This is surely a work around to the issue at hand but:
>>
>> * Enabling the clock, critical or not, should not be done but the
>> set_rate() callback. This is not the purpose of this callback.
>>
>> * Enabling the clock in such way does not walk the tree. So, if there is
>> ever another PSCI Fw which disable we would get into the same issue
>> again. IOW, This is not specific to the PLL driver so it should not have
>> to deal with this.
>
> Exactly.
>
>>
>> Since this clock can change out of CCF maybe it should be marked with
>> CLK_GET_RATE_NOCACHE ?
>
> Yes, or figure out a way to make the clk state match what PSCI leaves it
> in on resume from suspend.
>
>
>>
>> When CCF hits a clock with CLK_GET_RATE_NOCACHE while walking the tree,
>> in addition to to calling get_rate(), CCF could also call is_enabled()
>> if the clock has CLK_IS_CRITICAL and possibly .enable() ?
>
> This logic should go under a new flag. The CLK_GET_RATE_NOCACHE flag
> specifically means get rate shouldn't be a cached operation. It doesn't
> relate to the enable state. I hope that you can implement some sort of
> resume hook that synchronizes the state though so that you don't need to
> rely on clk_set_rate() or clk_get_rate() to trigger a sync.
>
It's exactly the goal of [1] where I resync a clock tree after a resume.
But I don't check the enable state, would you mean that:
if core->ops->enable && core->enable_count > 0 && !clk_core_is_enabled(core)
core->ops->enable(core->hw)
along the parent/rate resync ?
Isn't that dangerous ?
[1] https://patchwork.kernel.org/patch/11152101/
Neil
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] sun4i: axp209: no atomic i2c transfer handler
From: Chen-Yu Tsai @ 2019-09-20 8:39 UTC (permalink / raw)
To: Priit Laes
Cc: Wolfram Sang, linux-kernel, Maxime Ripard, linux-sunxi, linux-i2c,
priit.laes, linux-arm-kernel
In-Reply-To: <20190920083237.GA11657@plaes.org>
On Fri, Sep 20, 2019 at 4:32 PM Priit Laes <plaes@plaes.org> wrote:
>
> Heya!
>
> I have seen following warning message for few times when shutting down the
> machine (Olinuxino Lime2-emmc) running the mainline kernel.
>
> [snip]
> WARNING: CPU: 0 PID: 1 at drivers/i2c/i2c-core.h:41 i2c_transfer+0xe8/0xf4
> No atomic I2C transfer handler for 'i2c-1'
> Modules linked in: enc28j60
> CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.3.0-rc8-paf+ #28
> Hardware name: Allwinner sun7i (A20) Family
> [<c010ee08>] (unwind_backtrace) from [<c010b5b8>] (show_stack+0x10/0x14)
> [<c010b5b8>] (show_stack) from [<c06bf2b4>] (dump_stack+0x88/0x9c)
> [<c06bf2b4>] (dump_stack) from [<c011e044>] (__warn+0xd4/0xf0)
> [<c011e044>] (__warn) from [<c011dbe4>] (warn_slowpath_fmt+0x48/0x6c)
> [<c011dbe4>] (warn_slowpath_fmt) from [<c051ce20>] (i2c_transfer+0xe8/0xf4)
> [<c051ce20>] (i2c_transfer) from [<c051ce78>] (i2c_transfer_buffer_flags+0x4c/0x70)
> [<c051ce78>] (i2c_transfer_buffer_flags) from [<c046c2a4>] (regmap_i2c_write+0x14/0x30)
> [<c046c2a4>] (regmap_i2c_write) from [<c0468180>] (_regmap_raw_write_impl+0x588/0x63c)
> [<c0468180>] (_regmap_raw_write_impl) from [<c0468b50>] (regmap_write+0x3c/0x5c)
> [<c0468b50>] (regmap_write) from [<c046f554>] (axp20x_power_off+0x2c/0x38)
> [<c046f554>] (axp20x_power_off) from [<c013e8a4>] (sys_reboot+0x14c/0x1e0)
> [<c013e8a4>] (sys_reboot) from [<c0101000>] (ret_fast_syscall+0x0/0x54)
> Exception stack(0xef04ffa8 to 0xef04fff0)
> ffa0: 00427954 00000000 fee1dead 28121969 4321fedc 16814300
> ffc0: 00427954 00000000 00000000 00000058 bec15c78 00000000 bec15c10 004266f8
> ffe0: 00000058 bec15b6c b6f69d45 b6eeb746
> [/snip]
>
> The enc28j60 module is SPI, so it has nothing to do with the message.
>
> Any ideas where to look?
This looks like it's complaining that i2c-1 (i2c-mv64xxx) does not have
.master_xfer_atomic , which should be used in atomic contexts.
include/linux/i2c.h says:
@master_xfer_atomic: same as @master_xfer. Yet, only using atomic context
so e.g. PMICs can be accessed very late before shutdown. Optional.
ChenYu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [BUG] sun4i: axp209: no atomic i2c transfer handler
From: Priit Laes @ 2019-09-20 8:32 UTC (permalink / raw)
To: mripard, wens; +Cc: linux-sunxi, linux-kernel, linux-arm-kernel, priit.laes
Heya!
I have seen following warning message for few times when shutting down the
machine (Olinuxino Lime2-emmc) running the mainline kernel.
[snip]
WARNING: CPU: 0 PID: 1 at drivers/i2c/i2c-core.h:41 i2c_transfer+0xe8/0xf4
No atomic I2C transfer handler for 'i2c-1'
Modules linked in: enc28j60
CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.3.0-rc8-paf+ #28
Hardware name: Allwinner sun7i (A20) Family
[<c010ee08>] (unwind_backtrace) from [<c010b5b8>] (show_stack+0x10/0x14)
[<c010b5b8>] (show_stack) from [<c06bf2b4>] (dump_stack+0x88/0x9c)
[<c06bf2b4>] (dump_stack) from [<c011e044>] (__warn+0xd4/0xf0)
[<c011e044>] (__warn) from [<c011dbe4>] (warn_slowpath_fmt+0x48/0x6c)
[<c011dbe4>] (warn_slowpath_fmt) from [<c051ce20>] (i2c_transfer+0xe8/0xf4)
[<c051ce20>] (i2c_transfer) from [<c051ce78>] (i2c_transfer_buffer_flags+0x4c/0x70)
[<c051ce78>] (i2c_transfer_buffer_flags) from [<c046c2a4>] (regmap_i2c_write+0x14/0x30)
[<c046c2a4>] (regmap_i2c_write) from [<c0468180>] (_regmap_raw_write_impl+0x588/0x63c)
[<c0468180>] (_regmap_raw_write_impl) from [<c0468b50>] (regmap_write+0x3c/0x5c)
[<c0468b50>] (regmap_write) from [<c046f554>] (axp20x_power_off+0x2c/0x38)
[<c046f554>] (axp20x_power_off) from [<c013e8a4>] (sys_reboot+0x14c/0x1e0)
[<c013e8a4>] (sys_reboot) from [<c0101000>] (ret_fast_syscall+0x0/0x54)
Exception stack(0xef04ffa8 to 0xef04fff0)
ffa0: 00427954 00000000 fee1dead 28121969 4321fedc 16814300
ffc0: 00427954 00000000 00000000 00000058 bec15c78 00000000 bec15c10 004266f8
ffe0: 00000058 bec15b6c b6f69d45 b6eeb746
[/snip]
The enc28j60 module is SPI, so it has nothing to do with the message.
Any ideas where to look?
Päikest,
Priit :)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [v2 2/2] arm64: dts: ls1028a: Update the DT node definition for dpclk
From: Wen He @ 2019-09-20 8:34 UTC (permalink / raw)
To: linux-devel, Shawn Guo, Li Yang, Rob Herring, Mark Rutland,
devicetree, linux-kernel, linux-arm-kernel
Cc: Wen He
In-Reply-To: <20190920083419.5092-1-wen.he_1@nxp.com>
Update DT node name clock-controller to clock-display, also change
the property #clock-cells value to zero.
This update according the feedback of the Display output interface
clock driver upstream.
Link: https://lore.kernel.org/patchwork/patch/1113832/
Signed-off-by: Wen He <wen.he_1@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 51fa8f57fdac..db1e186352d8 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -79,10 +79,10 @@
clock-output-names = "phy_27m";
};
- dpclk: clock-controller@f1f0000 {
+ dpclk: clock-display@f1f0000 {
compatible = "fsl,ls1028a-plldig";
reg = <0x0 0xf1f0000 0x0 0xffff>;
- #clock-cells = <1>;
+ #clock-cells = <0>;
clocks = <&osc_27m>;
};
@@ -665,7 +665,7 @@
interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
<0 223 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "DE", "SE";
- clocks = <&dpclk 0>, <&clockgen 2 2>, <&clockgen 2 2>,
+ clocks = <&dpclk>, <&clockgen 2 2>, <&clockgen 2 2>,
<&clockgen 2 2>;
clock-names = "pxlclk", "mclk", "aclk", "pclk";
arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
--
2.17.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
* [v2 1/2] arm64: dts: ls1028a: Update the clock providers for the Mali DP500
From: Wen He @ 2019-09-20 8:34 UTC (permalink / raw)
To: linux-devel, Shawn Guo, Li Yang, Rob Herring, Mark Rutland,
devicetree, linux-kernel, linux-arm-kernel
Cc: Wen He
In order to maximise performance of the LCD Controller's 64-bit AXI
bus, for any give speed bin of the device, the AXI master interface
clock(ACLK) clock can be up to CPU_frequency/2, which is already
capable of optimal performance. In general, ACLK is always expected
to be equal to CPU_frequency/2. APB slave interface clock(PCLK) and
Main processing clock(PCLK) both are tied to the same clock as ACLK.
This change followed the LS1028A Architecture Specification Manual.
Signed-off-by: Wen He <wen.he_1@nxp.com>
---
change in v2:
- add details commit description for this change.
- v1: Link: https://lore.kernel.org/patchwork/patch/1119145/
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 17 ++---------------
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 72b9a75976a1..51fa8f57fdac 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -86,20 +86,6 @@
clocks = <&osc_27m>;
};
- aclk: clock-axi {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <650000000>;
- clock-output-names= "aclk";
- };
-
- pclk: clock-apb {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <650000000>;
- clock-output-names= "pclk";
- };
-
reboot {
compatible ="syscon-reboot";
regmap = <&dcfg>;
@@ -679,7 +665,8 @@
interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
<0 223 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "DE", "SE";
- clocks = <&dpclk 0>, <&aclk>, <&aclk>, <&pclk>;
+ clocks = <&dpclk 0>, <&clockgen 2 2>, <&clockgen 2 2>,
+ <&clockgen 2 2>;
clock-names = "pxlclk", "mclk", "aclk", "pclk";
arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
arm,malidp-arqos-value = <0xd000d000>;
--
2.17.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] pwm: mxs: use devm_platform_ioremap_resource() to simplify code
From: Anson Huang @ 2019-09-20 8:49 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Aisheng Dong, linux-pwm@vger.kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, linux-kernel@vger.kernel.org,
thierry.reding@gmail.com, dl-linux-imx, kernel@pengutronix.de,
festevam@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190824002634.nfrhof3kpsrcc742@pengutronix.de>
Ping..., 1 month passed, NOT sure what is the latest status.
Anson
> On Tue, Aug 20, 2019 at 05:56:40AM +0000, Anson Huang wrote:
> > Gentle ping...
>
> My impression[1] is that Thierry collects patches in bulk once or twice per
> release cycle. The last two such bulks were between 5.2-rc6 and
> 5.2-rc7 and in the 5.2 merge window. So given we're at v5.3-rc5 now I expect
> some action soon :-)
>
> > > > From: Anson.Huang@nxp.com <Anson.Huang@nxp.com>
> > > > Sent: Thursday, July 18, 2019 9:32 AM
> > > >
> > > > Use the new helper devm_platform_ioremap_resource() which wraps
> > > > the
> > > > platform_get_resource() and devm_ioremap_resource() together, to
> > > > simplify the code.
> > > >
> > > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > >
> > > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
>
> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>
> Best regards
> Uwe
>
> [1] from git log --committer=Thierry --format=%ci drivers/pwm | cut -d\ -f1 |
> uniq -c
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions |
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.p
> engutronix.de%2F&data=02%7C01%7Canson.huang%40nxp.com%7C34
> ed78e5b90642e6173d08d72829bc65%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7C0%7C637022032026755310&sdata=RM0DjN9B%2FomxSSlGp
> adxX50yYesNjOAFTXaghkxyOCQ%3D&reserved=0 |
_______________________________________________
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 v4 2/3] dmaengine: imx-sdma: fix dma freezes
From: Philipp Puschmann @ 2019-09-20 8:53 UTC (permalink / raw)
To: Jan Lübbe, linux-kernel
Cc: fugang.duan, shawnguo, s.hauer, vkoul, linux-imx, kernel,
dan.j.williams, yibin.gong, festevam, dmaengine, linux-arm-kernel,
l.stach
In-Reply-To: <ad87f175496358adb825240f1de609318ed8204c.camel@pengutronix.de>
Hi Jan,
Am 19.09.19 um 17:19 schrieb Jan Lübbe:
> Hi Philipp,
>
> see below...
>
> On Thu, 2019-09-19 at 16:29 +0200, Philipp Puschmann wrote:
>> For some years and since many kernel versions there are reports that the
>> RX UART SDMA channel stops working at some point. The workaround was to
>> disable DMA for RX. This commit tries to fix the problem itself.
>>
>> Due to its license i wasn't able to debug the sdma script itself but it
>> somehow leads to blocking the scheduling of the channel script when a
>> running sdma script does not find any free descriptor in the ring to put
>> its data into.
>>
>> If we detect such a potential case we manually restart the channel.
>>
>> As sdmac->desc is constant we can move desc out of the loop.
>>
>> Fixes: 1ec1e82f2510 ("dmaengine: Add Freescale i.MX SDMA support")
>> Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
>> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
>> ---
>>
>> Changelog v4:
>> - fixed the fixes tag
>>
>> Changelog v3:
>> - use correct dma_wmb() instead of dma_wb()
>> - add fixes tag
>>
>> Changelog v2:
>> - clarify comment and commit description
>>
>> drivers/dma/imx-sdma.c | 21 +++++++++++++++++----
>> 1 file changed, 17 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
>> index e029a2443cfc..a32b5962630e 100644
>> --- a/drivers/dma/imx-sdma.c
>> +++ b/drivers/dma/imx-sdma.c
>> @@ -775,21 +775,23 @@ static void sdma_start_desc(struct sdma_channel *sdmac)
>> static void sdma_update_channel_loop(struct sdma_channel *sdmac)
>> {
>> struct sdma_buffer_descriptor *bd;
>> - int error = 0;
>> - enum dma_status old_status = sdmac->status;
>> + struct sdma_desc *desc = sdmac->desc;
>> + int error = 0, cnt = 0;
>> + enum dma_status old_status = sdmac->status;
>>
>> /*
>> * loop mode. Iterate over descriptors, re-setup them and
>> * call callback function.
>> */
>> - while (sdmac->desc) {
>> - struct sdma_desc *desc = sdmac->desc;
>> + while (desc) {
>>
>> bd = &desc->bd[desc->buf_tail];
>>
>> if (bd->mode.status & BD_DONE)
>> break;
>>
>> + cnt++;
>> +
>> if (bd->mode.status & BD_RROR) {
>> bd->mode.status &= ~BD_RROR;
>> sdmac->status = DMA_ERROR;
>> @@ -822,6 +824,17 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
>> if (error)
>> sdmac->status = old_status;
>> }
>> +
>> + /* In some situations it may happen that the sdma does not found any
> ^ hasn't
>> + * usable descriptor in the ring to put data into. The channel is
>> + * stopped then. While there is no specific error condition we can
>> + * check for, a necessary condition is that all available buffers for
>> + * the current channel have been written to by the sdma script. In
>> + * this case and after we have made the buffers available again,
>> + * we restart the channel.
>> + */
>
> Are you sure we can't miss cases where we only had to make some buffers
> available again, but the SDMA already ran out of buffers before?
Think so, yes.
>
> A while ago, I was debugging a similar issue triggered by receiving
> data with a wrong baud rate, which leads to all descriptors being
> marked with the error flag very quickly (and the SDMA stalling).
> I noticed that you can check if the channel is still running by
> checking the SDMA_H_STATSTOP register & BIT(sdmac->channel).
I think checking for this register is the better approach. Then i could drop the
cnt variable. And by droppting cnt i would propose to move the check and reenabling
to the end of the while loop to reenable the channel after freeing first buffer.
>
> I also added a flag for the sdmac->flags field to allow stopping the
> channel from the callback (otherwise it would enable the channel
> again).
Could memory and compiler ordering a problem here?
I'm not that into these kind of problems, but is this
sdmac->flags &= ~IMX_DMA_ACTIVE;
writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
guaranteed to be free of race conditions?
Regards,
Philipp
>
> Attached is my current version of that patch for reference.
>
>> + if (cnt >= desc->num_bd)
>> + sdma_enable_channel(sdmac->sdma, sdmac->channel);
>> }
>>
>> static void mxc_sdma_handle_channel_normal(struct sdma_channel *data)
_______________________________________________
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 v6 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Kirill A. Shutemov @ 2019-09-20 9:03 UTC (permalink / raw)
To: Jia He
Cc: Mark Rutland, Catalin Marinas, linux-mm, Punit Agrawal,
Will Deacon, Alex Van Brunt, Marc Zyngier, Anshuman Khandual,
Matthew Wilcox, Jun Yao, Kaly Xin, hejianet, Ralph Campbell,
Suzuki Poulose, Jérôme Glisse, Thomas Gleixner,
linux-arm-kernel, linux-kernel, James Morse, Andrew Morton,
Robin Murphy, Kirill A. Shutemov
In-Reply-To: <20190920022132.149467-4-justin.he@arm.com>
On Fri, Sep 20, 2019 at 10:21:32AM +0800, Jia He wrote:
> When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there
> will be a double page fault in __copy_from_user_inatomic of cow_user_page.
>
> Below call trace is from arm64 do_page_fault for debugging purpose
> [ 110.016195] Call trace:
> [ 110.016826] do_page_fault+0x5a4/0x690
> [ 110.017812] do_mem_abort+0x50/0xb0
> [ 110.018726] el1_da+0x20/0xc4
> [ 110.019492] __arch_copy_from_user+0x180/0x280
> [ 110.020646] do_wp_page+0xb0/0x860
> [ 110.021517] __handle_mm_fault+0x994/0x1338
> [ 110.022606] handle_mm_fault+0xe8/0x180
> [ 110.023584] do_page_fault+0x240/0x690
> [ 110.024535] do_mem_abort+0x50/0xb0
> [ 110.025423] el0_da+0x20/0x24
>
> The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
> [ffff9b007000] pgd=000000023d4f8003, pud=000000023da9b003, pmd=000000023d4b3003, pte=360000298607bd3
>
> As told by Catalin: "On arm64 without hardware Access Flag, copying from
> user will fail because the pte is old and cannot be marked young. So we
> always end up with zeroed page after fork() + CoW for pfn mappings. we
> don't always have a hardware-managed access flag on arm64."
>
> This patch fix it by calling pte_mkyoung. Also, the parameter is
> changed because vmf should be passed to cow_user_page()
>
> Add a WARN_ON_ONCE when __copy_from_user_inatomic() returns error
> in case there can be some obscure use-case.(by Kirill)
>
> [1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
>
> Reported-by: Yibo Cai <Yibo.Cai@arm.com>
> Signed-off-by: Jia He <justin.he@arm.com>
> ---
> mm/memory.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 59 insertions(+), 6 deletions(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index e2bb51b6242e..7c38c1ce5440 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
> 2;
> #endif
>
> +#ifndef arch_faults_on_old_pte
> +static inline bool arch_faults_on_old_pte(void)
> +{
> + return false;
> +}
> +#endif
> +
> static int __init disable_randmaps(char *s)
> {
> randomize_va_space = 0;
> @@ -2140,8 +2147,12 @@ static inline int pte_unmap_same(struct mm_struct *mm, pmd_t *pmd,
> return same;
> }
>
> -static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va, struct vm_area_struct *vma)
> +static inline int cow_user_page(struct page *dst, struct page *src,
> + struct vm_fault *vmf)
> {
> + struct vm_area_struct *vma = vmf->vma;
> + unsigned long addr = vmf->address;
> +
> debug_dma_assert_idle(src);
>
> /*
> @@ -2151,21 +2162,52 @@ static inline void cow_user_page(struct page *dst, struct page *src, unsigned lo
> * fails, we just zero-fill it. Live with it.
> */
> if (unlikely(!src)) {
> - void *kaddr = kmap_atomic(dst);
> - void __user *uaddr = (void __user *)(va & PAGE_MASK);
> + void *kaddr;
> + void __user *uaddr = (void __user *)(addr & PAGE_MASK);
> + pte_t entry;
> +
> + /* On architectures with software "accessed" bits, we would
> + * take a double page fault, so mark it accessed here.
> + */
> + if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) {
> + spin_lock(vmf->ptl);
It's probably okay for arm64, but for archs with highmem it will be
a problem.
Use pte_offset_map_lock() instead.
> + if (likely(pte_same(*vmf->pte, vmf->orig_pte))) {
> + entry = pte_mkyoung(vmf->orig_pte);
> + if (ptep_set_access_flags(vma, addr,
> + vmf->pte, entry, 0))
> + update_mmu_cache(vma, addr, vmf->pte);
> + } else {
> + /* Other thread has already handled the fault
> + * and we don't need to do anything. If it's
> + * not the case, the fault will be triggered
> + * again on the same address.
> + */
> + spin_unlock(vmf->ptl);
And pte_unmap_unlock() here...
> + return -1;
> + }
> + spin_unlock(vmf->ptl);
and here.
> + }
>
> + kaddr = kmap_atomic(dst);
> /*
> * This really shouldn't fail, because the page is there
> * in the page tables. But it might just be unreadable,
> * in which case we just give up and fill the result with
> * zeroes.
> */
> - if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
> + if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) {
> + /* Give a warn in case there can be some obscure
> + * use-case
> + */
> + WARN_ON_ONCE(1);
> clear_page(kaddr);
> + }
> kunmap_atomic(kaddr);
> flush_dcache_page(dst);
> } else
> - copy_user_highpage(dst, src, va, vma);
> + copy_user_highpage(dst, src, addr, vma);
> +
> + return 0;
> }
>
> static gfp_t __get_fault_gfp_mask(struct vm_area_struct *vma)
> @@ -2318,7 +2360,16 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
> vmf->address);
> if (!new_page)
> goto oom;
> - cow_user_page(new_page, old_page, vmf->address, vma);
> +
> + if (cow_user_page(new_page, old_page, vmf)) {
> + /* COW failed, if the fault was solved by other,
> + * it's fine. If not, userspace would re-fault on
> + * the same address and we will handle the fault
> + * from the second attempt.
> + */
> + put_page(new_page);
I think you also need to give the reference on the old page back:
if (old_page)
put_page(old_page);
> + goto normal;
I don't see much point in this goto. Just return 0.
> + }
> }
>
> if (mem_cgroup_try_charge_delay(new_page, mm, GFP_KERNEL, &memcg, false))
> @@ -2420,6 +2471,8 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
> }
> put_page(old_page);
> }
> +
> +normal:
> return page_copied ? VM_FAULT_WRITE : 0;
> oom_free_new:
> put_page(new_page);
> --
> 2.17.1
>
>
--
Kirill A. Shutemov
_______________________________________________
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] ethernet: gemini: Use devm_platform_ioremap_resource() in gemini_ethernet_probe()
From: Markus Elfring @ 2019-09-20 9:23 UTC (permalink / raw)
To: netdev, linux-arm-kernel, David S. Miller, Hans Ulli Kroll,
Linus Walleij, Radhey Shyam Pandey
Cc: kernel-janitors, LKML
In-Reply-To: <CH2PR02MB700047AFFFE08FE5FD563541C78E0@CH2PR02MB7000.namprd02.prod.outlook.com>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 20 Sep 2019 10:52:56 +0200
Simplify this function implementation by using the wrapper function
“devm_platform_ioremap_resource” instead of calling the functions
“platform_get_resource” and “devm_ioremap_resource” directly.
* Thus reduce also a bit of exception handling code here.
* Delete the local variable “res”.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
v2:
Further changes were requested by Radhey Shyam Pandey.
https://lore.kernel.org/r/CH2PR02MB700047AFFFE08FE5FD563541C78E0@CH2PR02MB7000.namprd02.prod.outlook.com/
* Updates for three modules were split into
a separate patch for each driver.
* The commit description was adjusted.
drivers/net/ethernet/cortina/gemini.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c
index e736ce2c58ca..f009415ee4d8 100644
--- a/drivers/net/ethernet/cortina/gemini.c
+++ b/drivers/net/ethernet/cortina/gemini.c
@@ -2549,17 +2549,13 @@ static int gemini_ethernet_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct gemini_ethernet *geth;
unsigned int retry = 5;
- struct resource *res;
u32 val;
/* Global registers */
geth = devm_kzalloc(dev, sizeof(*geth), GFP_KERNEL);
if (!geth)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENODEV;
- geth->base = devm_ioremap_resource(dev, res);
+ geth->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(geth->base))
return PTR_ERR(geth->base);
geth->dev = dev;
--
2.23.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
* Re: [PATCH v4 2/3] dmaengine: imx-sdma: fix dma freezes
From: Lucas Stach @ 2019-09-20 9:26 UTC (permalink / raw)
To: Philipp Puschmann, Jan Lübbe, linux-kernel
Cc: fugang.duan, shawnguo, s.hauer, vkoul, linux-imx, kernel,
dmaengine, dan.j.williams, yibin.gong, festevam, linux-arm-kernel
In-Reply-To: <9305e5ff-f555-3c6e-9e99-36d88edcae0a@emlix.com>
On Fr, 2019-09-20 at 10:53 +0200, Philipp Puschmann wrote:
> Hi Jan,
>
> Am 19.09.19 um 17:19 schrieb Jan Lübbe:
> > Hi Philipp,
> >
> > see below...
> >
> > On Thu, 2019-09-19 at 16:29 +0200, Philipp Puschmann wrote:
> > > For some years and since many kernel versions there are reports that the
> > > RX UART SDMA channel stops working at some point. The workaround was to
> > > disable DMA for RX. This commit tries to fix the problem itself.
> > >
> > > Due to its license i wasn't able to debug the sdma script itself but it
> > > somehow leads to blocking the scheduling of the channel script when a
> > > running sdma script does not find any free descriptor in the ring to put
> > > its data into.
> > >
> > > If we detect such a potential case we manually restart the channel.
> > >
> > > As sdmac->desc is constant we can move desc out of the loop.
> > >
> > > Fixes: 1ec1e82f2510 ("dmaengine: Add Freescale i.MX SDMA support")
> > > Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
> > > Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> > > ---
> > >
> > > Changelog v4:
> > > - fixed the fixes tag
> > >
> > > Changelog v3:
> > > - use correct dma_wmb() instead of dma_wb()
> > > - add fixes tag
> > >
> > > Changelog v2:
> > > - clarify comment and commit description
> > >
> > > drivers/dma/imx-sdma.c | 21 +++++++++++++++++----
> > > 1 file changed, 17 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> > > index e029a2443cfc..a32b5962630e 100644
> > > --- a/drivers/dma/imx-sdma.c
> > > +++ b/drivers/dma/imx-sdma.c
> > > @@ -775,21 +775,23 @@ static void sdma_start_desc(struct sdma_channel *sdmac)
> > > static void sdma_update_channel_loop(struct sdma_channel *sdmac)
> > > {
> > > struct sdma_buffer_descriptor *bd;
> > > - int error = 0;
> > > - enum dma_status old_status = sdmac->status;
> > > + struct sdma_desc *desc = sdmac->desc;
> > > + int error = 0, cnt = 0;
> > > + enum dma_status old_status = sdmac->status;
> > >
> > > /*
> > > * loop mode. Iterate over descriptors, re-setup them and
> > > * call callback function.
> > > */
> > > - while (sdmac->desc) {
> > > - struct sdma_desc *desc = sdmac->desc;
> > > + while (desc) {
> > >
> > > bd = &desc->bd[desc->buf_tail];
> > >
> > > if (bd->mode.status & BD_DONE)
> > > break;
> > >
> > > + cnt++;
> > > +
> > > if (bd->mode.status & BD_RROR) {
> > > bd->mode.status &= ~BD_RROR;
> > > sdmac->status = DMA_ERROR;
> > > @@ -822,6 +824,17 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
> > > if (error)
> > > sdmac->status = old_status;
> > > }
> > > +
> > > + /* In some situations it may happen that the sdma does not found any
> > ^ hasn't
> > > + * usable descriptor in the ring to put data into. The channel is
> > > + * stopped then. While there is no specific error condition we can
> > > + * check for, a necessary condition is that all available buffers for
> > > + * the current channel have been written to by the sdma script. In
> > > + * this case and after we have made the buffers available again,
> > > + * we restart the channel.
> > > + */
> >
> > Are you sure we can't miss cases where we only had to make some buffers
> > available again, but the SDMA already ran out of buffers before?
> Think so, yes.
> > A while ago, I was debugging a similar issue triggered by receiving
> > data with a wrong baud rate, which leads to all descriptors being
> > marked with the error flag very quickly (and the SDMA stalling).
> > I noticed that you can check if the channel is still running by
> > checking the SDMA_H_STATSTOP register & BIT(sdmac->channel).
>
> I think checking for this register is the better approach. Then i could drop the
> cnt variable. And by droppting cnt i would propose to move the check and reenabling
> to the end of the while loop to reenable the channel after freeing first buffer.
You certainly don't want to have a MMIO read at each iteration of the
loop, as that would be quite a bit of overhead. I'm not sure it's worth
it to try to minimize the channel re-enable latency. You are only
getting into this situation because of bad system latencies before this
part of the code run, so the little bit of latency added by cleaning
the descriptors before trying to re-enable the channel will probably
not add much further harm and you don't risk running in the out-of-
descriptors error immediately again. Remember, in a preemptible kernel
the task cleaning the descriptors could be put to sleep immediately
after you you cleaned a single descriptor and kicked the channel back
to life.
> > I also added a flag for the sdmac->flags field to allow stopping the
> > channel from the callback (otherwise it would enable the channel
> > again).
>
> Could memory and compiler ordering a problem here?
> I'm not that into these kind of problems, but is this
> sdmac->flags &= ~IMX_DMA_ACTIVE;
> writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
> guaranteed to be free of race conditions?
In fact the writel_relaxed needs to be replaced by the non-relaxed
version to imply a proper memory barrier before the register write.
Regards,
Lucas
_______________________________________________
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 2/3] mmc: sdhci-of-at91: rework clocks management to support SAM9x60 device
From: Eugen.Hristev @ 2019-09-20 9:34 UTC (permalink / raw)
To: Ludovic.Desroches, linux-arm-kernel, devicetree, linux-mmc
Cc: mark.rutland, ulf.hansson, linux-kernel, adrian.hunter, robh+dt,
Claudiu.Beznea
In-Reply-To: <20190912200908.31318-2-ludovic.desroches@microchip.com>
On 12.09.2019 23:09, Ludovic Desroches wrote:
>
> In the SAM9x60 SoC, there are only two clocks instead of three for the
> SDHCI device. The base clk is no longer provided, it is generated
> internally from the mult clk.
>
> The values of the base clk and mul in the capabilities registers may not
> reflect the reality as the mult clk is a programmable clock which can take
> several rates. As we can't trust those values, take them from the clock
> tree and update the capabilities according to.
>
> As we can have the same pitfall, in some cases, with the SAMA5D2 Soc,
> stop relying on capabilities too.
>
> Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
> ---
> drivers/mmc/host/sdhci-of-at91.c | 104 +++++++++++++++++--------------
> 1 file changed, 57 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-at91.c b/drivers/mmc/host/sdhci-of-at91.c
> index e7d1920729fb..a9c126f14d85 100644
> --- a/drivers/mmc/host/sdhci-of-at91.c
> +++ b/drivers/mmc/host/sdhci-of-at91.c
> @@ -30,7 +30,14 @@
>
> #define SDHCI_AT91_PRESET_COMMON_CONF 0x400 /* drv type B, programmable clock mode */
>
> +struct sdhci_at91_soc_data {
> + const struct sdhci_pltfm_data *pdata;
> + bool baseclk_is_generated_internally;
> + unsigned int divider_for_baseclk;
> +};
> +
> struct sdhci_at91_priv {
> + const struct sdhci_at91_soc_data *soc_data;
> struct clk *hclock;
> struct clk *gck;
> struct clk *mainck;
> @@ -130,12 +137,24 @@ static const struct sdhci_ops sdhci_at91_sama5d2_ops = {
> .set_power = sdhci_at91_set_power,
> };
>
> -static const struct sdhci_pltfm_data soc_data_sama5d2 = {
> +static const struct sdhci_pltfm_data sdhci_sama5d2_pdata = {
> .ops = &sdhci_at91_sama5d2_ops,
> };
>
> +static const struct sdhci_at91_soc_data soc_data_sama5d2 = {
> + .pdata = &sdhci_sama5d2_pdata,
> + .baseclk_is_generated_internally = false,
> +};
> +
> +static const struct sdhci_at91_soc_data soc_data_sam9x60 = {
> + .pdata = &sdhci_sama5d2_pdata,
> + .baseclk_is_generated_internally = true,
> + .divider_for_baseclk = 2,
> +};
> +
> static const struct of_device_id sdhci_at91_dt_match[] = {
> { .compatible = "atmel,sama5d2-sdhci", .data = &soc_data_sama5d2 },
> + { .compatible = "microchip,sam9x60-sdhci", .data = &soc_data_sam9x60 },
> {}
> };
> MODULE_DEVICE_TABLE(of, sdhci_at91_dt_match);
> @@ -145,50 +164,36 @@ static int sdhci_at91_set_clks_presets(struct device *dev)
> struct sdhci_host *host = dev_get_drvdata(dev);
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> struct sdhci_at91_priv *priv = sdhci_pltfm_priv(pltfm_host);
> - int ret;
> unsigned int caps0, caps1;
> unsigned int clk_base, clk_mul;
> - unsigned int gck_rate, real_gck_rate;
> + unsigned int gck_rate, clk_base_rate;
> unsigned int preset_div;
>
> - /*
> - * The mult clock is provided by as a generated clock by the PMC
> - * controller. In order to set the rate of gck, we have to get the
> - * base clock rate and the clock mult from capabilities.
> - */
> clk_prepare_enable(priv->hclock);
> caps0 = readl(host->ioaddr + SDHCI_CAPABILITIES);
> caps1 = readl(host->ioaddr + SDHCI_CAPABILITIES_1);
> - clk_base = (caps0 & SDHCI_CLOCK_V3_BASE_MASK) >> SDHCI_CLOCK_BASE_SHIFT;
> - clk_mul = (caps1 & SDHCI_CLOCK_MUL_MASK) >> SDHCI_CLOCK_MUL_SHIFT;
> - gck_rate = clk_base * 1000000 * (clk_mul + 1);
> - ret = clk_set_rate(priv->gck, gck_rate);
> - if (ret < 0) {
> - dev_err(dev, "failed to set gck");
> - clk_disable_unprepare(priv->hclock);
> - return ret;
> - }
> - /*
> - * We need to check if we have the requested rate for gck because in
> - * some cases this rate could be not supported. If it happens, the rate
> - * is the closest one gck can provide. We have to update the value
> - * of clk mul.
> - */
> - real_gck_rate = clk_get_rate(priv->gck);
> - if (real_gck_rate != gck_rate) {
> - clk_mul = real_gck_rate / (clk_base * 1000000) - 1;
> - caps1 &= (~SDHCI_CLOCK_MUL_MASK);
> - caps1 |= ((clk_mul << SDHCI_CLOCK_MUL_SHIFT) &
> - SDHCI_CLOCK_MUL_MASK);
> - /* Set capabilities in r/w mode. */
> - writel(SDMMC_CACR_KEY | SDMMC_CACR_CAPWREN,
> - host->ioaddr + SDMMC_CACR);
> - writel(caps1, host->ioaddr + SDHCI_CAPABILITIES_1);
> - /* Set capabilities in ro mode. */
> - writel(0, host->ioaddr + SDMMC_CACR);
> - dev_info(dev, "update clk mul to %u as gck rate is %u Hz\n",
> - clk_mul, real_gck_rate);
> - }
> +
> + gck_rate = clk_get_rate(priv->gck);
> + if (priv->soc_data->baseclk_is_generated_internally)
> + clk_base_rate = gck_rate / priv->soc_data->divider_for_baseclk;
> + else
> + clk_base_rate = clk_get_rate(priv->mainck);
> +
> + clk_base = clk_base_rate / 1000000;
> + clk_mul = gck_rate / clk_base_rate - 1;
> +
> + caps0 &= (~SDHCI_CLOCK_V3_BASE_MASK);
> + caps0 |= ((clk_base << SDHCI_CLOCK_BASE_SHIFT) & SDHCI_CLOCK_V3_BASE_MASK);
> + caps1 &= (~SDHCI_CLOCK_MUL_MASK);
> + caps1 |= ((clk_mul << SDHCI_CLOCK_MUL_SHIFT) & SDHCI_CLOCK_MUL_MASK);
> + /* Set capabilities in r/w mode. */
> + writel(SDMMC_CACR_KEY | SDMMC_CACR_CAPWREN, host->ioaddr + SDMMC_CACR);
Hi Ludovic,
I have a feeling that here you may wish to also write the caps0 to the
SDHC_CAPABILITIES:
writel(caps0, host->ioaddr + SDHCI_CAPABILITIES);
You are computing the caps0 but not writing them to register.
Eugen
> + writel(caps1, host->ioaddr + SDHCI_CAPABILITIES_1);
> + /* Set capabilities in ro mode. */
> + writel(0, host->ioaddr + SDMMC_CACR);
> +
> + dev_info(dev, "update clk mul to %u as gck rate is %u Hz and clk base is %u Hz\n",
> + clk_mul, gck_rate, clk_base_rate);
>
> /*
> * We have to set preset values because it depends on the clk_mul
> @@ -196,19 +201,19 @@ static int sdhci_at91_set_clks_presets(struct device *dev)
> * maximum sd clock value is 120 MHz instead of 208 MHz. For that
> * reason, we need to use presets to support SDR104.
> */
> - preset_div = DIV_ROUND_UP(real_gck_rate, 24000000) - 1;
> + preset_div = DIV_ROUND_UP(gck_rate, 24000000) - 1;
> writew(SDHCI_AT91_PRESET_COMMON_CONF | preset_div,
> host->ioaddr + SDHCI_PRESET_FOR_SDR12);
> - preset_div = DIV_ROUND_UP(real_gck_rate, 50000000) - 1;
> + preset_div = DIV_ROUND_UP(gck_rate, 50000000) - 1;
> writew(SDHCI_AT91_PRESET_COMMON_CONF | preset_div,
> host->ioaddr + SDHCI_PRESET_FOR_SDR25);
> - preset_div = DIV_ROUND_UP(real_gck_rate, 100000000) - 1;
> + preset_div = DIV_ROUND_UP(gck_rate, 100000000) - 1;
> writew(SDHCI_AT91_PRESET_COMMON_CONF | preset_div,
> host->ioaddr + SDHCI_PRESET_FOR_SDR50);
> - preset_div = DIV_ROUND_UP(real_gck_rate, 120000000) - 1;
> + preset_div = DIV_ROUND_UP(gck_rate, 120000000) - 1;
> writew(SDHCI_AT91_PRESET_COMMON_CONF | preset_div,
> host->ioaddr + SDHCI_PRESET_FOR_SDR104);
> - preset_div = DIV_ROUND_UP(real_gck_rate, 50000000) - 1;
> + preset_div = DIV_ROUND_UP(gck_rate, 50000000) - 1;
> writew(SDHCI_AT91_PRESET_COMMON_CONF | preset_div,
> host->ioaddr + SDHCI_PRESET_FOR_DDR50);
>
> @@ -303,7 +308,7 @@ static const struct dev_pm_ops sdhci_at91_dev_pm_ops = {
> static int sdhci_at91_probe(struct platform_device *pdev)
> {
> const struct of_device_id *match;
> - const struct sdhci_pltfm_data *soc_data;
> + const struct sdhci_at91_soc_data *soc_data;
> struct sdhci_host *host;
> struct sdhci_pltfm_host *pltfm_host;
> struct sdhci_at91_priv *priv;
> @@ -314,17 +319,22 @@ static int sdhci_at91_probe(struct platform_device *pdev)
> return -EINVAL;
> soc_data = match->data;
>
> - host = sdhci_pltfm_init(pdev, soc_data, sizeof(*priv));
> + host = sdhci_pltfm_init(pdev, soc_data->pdata, sizeof(*priv));
> if (IS_ERR(host))
> return PTR_ERR(host);
>
> pltfm_host = sdhci_priv(host);
> priv = sdhci_pltfm_priv(pltfm_host);
> + priv->soc_data = soc_data;
>
> priv->mainck = devm_clk_get(&pdev->dev, "baseclk");
> if (IS_ERR(priv->mainck)) {
> - dev_err(&pdev->dev, "failed to get baseclk\n");
> - return PTR_ERR(priv->mainck);
> + if (soc_data->baseclk_is_generated_internally) {
> + priv->mainck = NULL;
> + } else {
> + dev_err(&pdev->dev, "failed to get baseclk\n");
> + return PTR_ERR(priv->mainck);
> + }
> }
>
> priv->hclock = devm_clk_get(&pdev->dev, "hclock");
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: SPE capable Arm CPUs in the fields
From: Sudeep Holla @ 2019-09-20 9:40 UTC (permalink / raw)
To: Itaru Kitayama; +Cc: linux-arm-kernel, Sudeep Holla
In-Reply-To: <864D2B3A-E49A-4F9E-9277-E8B64B36E02B@riken.jp>
On Fri, Sep 20, 2019 at 05:23:38AM +0900, Itaru Kitayama wrote:
> Will,
> Though SPE is just an optional feature of the Armv8.2-A extension, I am
> wondering whether CPUs are already out in the fields or some vendors are
> planning to make one of two in the near future.
>
SPE is available on Neoverse-N1 cores.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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