* [PATCH] ARM: dts: nomadik: Set up the CS GPIO right
From: Linus Walleij @ 2019-08-13 7:27 UTC (permalink / raw)
To: arm, soc; +Cc: Linus Walleij, linux-arm-kernel
Now that the SPI GPIO driver knows how to handle these
chip select GPIOs and we get nasty messages about the
core having to enforce active low on the GPIO, fix this
up by actually requesting the CS GPIO line as active
low.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ARM SoC folks: please apply this directly for v5.4, I do
not plan to send more Nomadik patches this merge window.
---
arch/arm/boot/dts/ste-nomadik-nhk15.dts | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/ste-nomadik-nhk15.dts b/arch/arm/boot/dts/ste-nomadik-nhk15.dts
index 04066f9cb8a3..41ed21a4fdc1 100644
--- a/arch/arm/boot/dts/ste-nomadik-nhk15.dts
+++ b/arch/arm/boot/dts/ste-nomadik-nhk15.dts
@@ -212,13 +212,7 @@
*/
gpio-sck = <&gpio0 5 GPIO_ACTIVE_HIGH>;
gpio-mosi = <&gpio0 4 GPIO_ACTIVE_HIGH>;
- /*
- * It's not actually active high, but the frameworks assume
- * the polarity of the passed-in GPIO is "normal" (active
- * high) then actively drives the line low to select the
- * chip.
- */
- cs-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
+ cs-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
num-chipselects = <1>;
/*
--
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: [RESEND PATCH] MAINTAINERS: Update path to physmap-versatile.c
From: Linus Walleij @ 2019-08-13 7:20 UTC (permalink / raw)
To: Denis Efremov
Cc: Joe Perches, Ricardo Ribalda Delgado,
linux-kernel@vger.kernel.org, Linux ARM, Boris Brezillon
In-Reply-To: <20190813063251.21842-1-efremov@linux.com>
On Tue, Aug 13, 2019 at 8:33 AM Denis Efremov <efremov@linux.com> wrote:
> Update MAINTAINERS record to reflect the filename change
> from physmap_of_versatile.c to physmap-versatile.c
>
> Cc: Boris Brezillon <bbrezillon@kernel.org>
> Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Fixes: 6ca15cfa0788 ("mtd: maps: Rename physmap_of_{versatile, gemini} into physmap-{versatile, gemini}")
> Signed-off-by: Denis Efremov <efremov@linux.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
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 v5 03/10] rtc: mt6397: move some common definitions into rtc.h
From: Lee Jones @ 2019-08-13 7:20 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Kate Stewart, Mark Rutland, linux-kernel, Richard Fontana,
Mauro Carvalho Chehab, linux-rtc, Frank Wunderlich,
Allison Randal, devicetree, linux-pm, Sean Wang, Tianping . Fang,
Rob Herring, linux-mediatek, Jonathan Cameron, Matthias Brugger,
Thomas Gleixner, Eddie Huang, linux-arm-kernel, Alessandro Zummo,
Josef Friedl, Greg Kroah-Hartman, Sebastian Reichel,
David S. Miller
In-Reply-To: <20190812153856.GR3600@piout.net>
On Mon, 12 Aug 2019, Alexandre Belloni wrote:
> On 12/08/2019 16:11:29+0100, Lee Jones wrote:
> > On Mon, 12 Aug 2019, Frank Wunderlich wrote:
> >
> > > From: Josef Friedl <josef.friedl@speed.at>
> > >
> > > move code to separate header-file to reuse definitions later
> > > in poweroff-driver (drivers/power/reset/mt6323-poweroff.c)
> > >
> > > Suggested-by: Frank Wunderlich <frank-w@public-files.de>
> > > Signed-off-by: Josef Friedl <josef.friedl@speed.at>
> > > Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> > > ---
> > > changes since v4: none
> > > changes since v3: none
> > > changes since v2: add missing commit-message
> > > ---
> > > drivers/rtc/rtc-mt6397.c | 55 +-------------------------
> > > include/linux/mfd/mt6397/rtc.h | 71 ++++++++++++++++++++++++++++++++++
> >
> > include/linux/rtc/mt6397.h?
> >
>
> It's just a bunch of registers and bit definitions so it may as well
> stay close to include/linux/mfd/mt6397/registers.h
Sure. It was a weak preference.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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/2] ARM: dts: at91: sama5d27_som1_ek: add mmc capabilities for SDMMC0
From: Ludovic Desroches @ 2019-08-13 6:53 UTC (permalink / raw)
To: Eugen.Hristev
Cc: devicetree, alexandre.belloni, linux-kernel, linux-mmc,
adrian.hunter, ulf.hansson, linux-arm-kernel
In-Reply-To: <fa0debbb-b84c-1f74-f8b8-8fdd7812aaee@microchip.com>
On Mon, Aug 12, 2019 at 03:38:34PM +0000, Eugen.Hristev@microchip.com wrote:
> On 09.08.2019 09:23, Ludovic Desroches wrote:
> > On Thu, Aug 08, 2019 at 03:57:30PM +0300, Adrian Hunter wrote:
> >> On 8/08/19 3:42 PM, Ludovic Desroches wrote:
> >>> On Thu, Aug 08, 2019 at 10:35:43AM +0200, Eugen Hristev - M18282 wrote:
> >>>> From: Eugen Hristev <eugen.hristev@microchip.com>
> >>>>
> >>>> Add mmc capabilities for SDMMC0 for this board.
> >>>> With this enabled, eMMC connected card is detected as:
> >>>>
> >>>> mmc0: new DDR MMC card at address 0001
> >>>>
> >>>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> >>> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
> >>>
> >>> I am interested to have the some insights about the use of sd-uhs-*
> >>> properties.
> >>>
> >>> Our IP can't deal with 1V8 by itself. It has a 1V8SEL signal which can
> >>> be used as the logic control input of a mux. So even if the IP claims
> >>> to support UHS modes, it depends on the board.
> >>>
> >>> Are the sd-uhs-* properties a way to deal with this? I tend to think no
> >>> as sdhci_setup_host() will set the caps depending on the content of the
> >>> capabilities register. Do we have to use the SDHCI_QUIRK_MISSING_CAPS
> >>> quirk or sdhci-caps/sdhci-caps-mask?
> >>
> >> There is "no-1-8-v" which it looks like sdhci-of-at91.c already supports:
> >>
> >> sdhci_at91_probe() -> sdhci_get_of_property() -> sdhci_get_property()
> >>
> >> if (device_property_present(dev, "no-1-8-v"))
> >> host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
> >>
> >
> > Right, I forgot this property. Thanks.
> >
> > Eugen, do you see cases we can't cover with this property?
>
> Hi,
>
> For current requirements and driver support, this should be enough.
>
> I noticed one thing regarding SD-Cards, if I add property sd-uhs-sdr104
> the class 10 uhs1 cards are detected as SDR104 . Without this property
> they are detected as DDR50. Any idea why the difference ? The controller
> does not claim to have SDR104 support ? We should add it ?
With the mainline, our tree or both? In our tree, SDR104 is removed from
the capabilities.
Ludovic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv5 2/2] PCI: layerscape: Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately
From: Xiaowei Bao @ 2019-08-13 6:28 UTC (permalink / raw)
To: lorenzo.pieralisi, bhelgaas, minghuan.Lian, mingkai.hu, roy.zang,
l.stach, kishon, tpiepho, leonard.crestez, andrew.smirnov,
yue.wang, hayashi.kunihiko, dwmw, jonnyc, linux-pci, linux-kernel,
linuxppc-dev, linux-arm-kernel
Cc: Xiaowei Bao
In-Reply-To: <20190813062840.2733-1-xiaowei.bao@nxp.com>
Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately.
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
---
v2:
- No change.
v3:
- modify the commit message.
v4:
- send the patch again with '--to'.
v5:
- No change.
drivers/pci/controller/dwc/Kconfig | 20 ++++++++++++++++++--
drivers/pci/controller/dwc/Makefile | 3 ++-
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
index 6ea778a..869c645 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -131,13 +131,29 @@ config PCI_KEYSTONE_EP
DesignWare core functions to implement the driver.
config PCI_LAYERSCAPE
- bool "Freescale Layerscape PCIe controller"
+ bool "Freescale Layerscape PCIe controller - Host mode"
depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
depends on PCI_MSI_IRQ_DOMAIN
select MFD_SYSCON
select PCIE_DW_HOST
help
- Say Y here if you want PCIe controller support on Layerscape SoCs.
+ Say Y here if you want to enable PCIe controller support on Layerscape
+ SoCs to work in Host mode.
+ This controller can work either as EP or RC. The RCW[HOST_AGT_PEX]
+ determines which PCIe controller works in EP mode and which PCIe
+ controller works in RC mode.
+
+config PCI_LAYERSCAPE_EP
+ bool "Freescale Layerscape PCIe controller - Endpoint mode"
+ depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
+ depends on PCI_ENDPOINT
+ select PCIE_DW_EP
+ help
+ Say Y here if you want to enable PCIe controller support on Layerscape
+ SoCs to work in Endpoint mode.
+ This controller can work either as EP or RC. The RCW[HOST_AGT_PEX]
+ determines which PCIe controller works in EP mode and which PCIe
+ controller works in RC mode.
config PCI_HISI
depends on OF && (ARM64 || COMPILE_TEST)
diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile
index b085dfd..824fde7 100644
--- a/drivers/pci/controller/dwc/Makefile
+++ b/drivers/pci/controller/dwc/Makefile
@@ -8,7 +8,8 @@ obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone.o
-obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o pci-layerscape-ep.o
+obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
+obj-$(CONFIG_PCI_LAYERSCAPE_EP) += pci-layerscape-ep.o
obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv5 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
From: Xiaowei Bao @ 2019-08-13 6:28 UTC (permalink / raw)
To: lorenzo.pieralisi, bhelgaas, minghuan.Lian, mingkai.hu, roy.zang,
l.stach, kishon, tpiepho, leonard.crestez, andrew.smirnov,
yue.wang, hayashi.kunihiko, dwmw, jonnyc, linux-pci, linux-kernel,
linuxppc-dev, linux-arm-kernel
Cc: Xiaowei Bao
The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1
is 32bit, BAR2 and BAR4 is 64bit, this is determined by hardware,
so set the bar_fixed_64bit with 0x14.
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
---
v2:
- Replace value 0x14 with a macro.
v3:
- No change.
v4:
- send the patch again with '--to'.
v5:
- fix the commit message.
drivers/pci/controller/dwc/pci-layerscape-ep.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
index be61d96..ca9aa45 100644
--- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
+++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
@@ -44,6 +44,7 @@ static const struct pci_epc_features ls_pcie_epc_features = {
.linkup_notifier = false,
.msi_capable = true,
.msix_capable = false,
+ .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
};
static const struct pci_epc_features*
--
2.9.5
_______________________________________________
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] drm/aspeed: gfc_crtc: Make structure aspeed_gfx_funcs constant
From: Nishka Dasgupta @ 2019-08-13 6:33 UTC (permalink / raw)
To: joel, airlied, daniel, dri-devel, andrew, linux-aspeed,
linux-arm-kernel
Cc: Nishka Dasgupta
The static structure aspeed_gfx_funcs, of type
drm_simple_display_pipe_funcs, is used only as an argument to
drm_simple_display_pipe_init(), which does not modify it. Hence make it
constant to protect it from unintended modification.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
---
drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
index 15db9e426ec4..2184b8be6fd4 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
@@ -215,7 +215,7 @@ static void aspeed_gfx_disable_vblank(struct drm_simple_display_pipe *pipe)
writel(reg | CRT_CTRL_VERTICAL_INTR_STS, priv->base + CRT_CTRL1);
}
-static struct drm_simple_display_pipe_funcs aspeed_gfx_funcs = {
+static const struct drm_simple_display_pipe_funcs aspeed_gfx_funcs = {
.enable = aspeed_gfx_pipe_enable,
.disable = aspeed_gfx_pipe_disable,
.update = aspeed_gfx_pipe_update,
--
2.19.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
* [RESEND PATCH] MAINTAINERS: Update path to physmap-versatile.c
From: Denis Efremov @ 2019-08-13 6:32 UTC (permalink / raw)
To: linux-kernel
Cc: Boris Brezillon, Linus Walleij, Denis Efremov, joe,
Ricardo Ribalda Delgado, linux-arm-kernel
In-Reply-To: <20190813061024.15428-1-efremov@linux.com>
Update MAINTAINERS record to reflect the filename change
from physmap_of_versatile.c to physmap-versatile.c
Cc: Boris Brezillon <bbrezillon@kernel.org>
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Fixes: 6ca15cfa0788 ("mtd: maps: Rename physmap_of_{versatile, gemini} into physmap-{versatile, gemini}")
Signed-off-by: Denis Efremov <efremov@linux.com>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d42b478f2673..eeeb4097d5bd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1221,7 +1221,7 @@ F: arch/arm/boot/dts/versatile*
F: drivers/clk/versatile/
F: drivers/i2c/busses/i2c-versatile.c
F: drivers/irqchip/irq-versatile-fpga.c
-F: drivers/mtd/maps/physmap_of_versatile.c
+F: drivers/mtd/maps/physmap-versatile.c
F: drivers/power/reset/arm-versatile-reboot.c
F: drivers/soc/versatile/
--
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: [EXT] Re: [PATCHv4 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
From: Xiaowei Bao @ 2019-08-13 6:29 UTC (permalink / raw)
To: Kishon Vijay Abraham I, lorenzo.pieralisi@arm.com,
bhelgaas@google.com, M.h. Lian, Mingkai Hu, Roy Zang,
l.stach@pengutronix.de, tpiepho@impinj.com, Leonard Crestez,
andrew.smirnov@gmail.com, yue.wang@amlogic.com,
hayashi.kunihiko@socionext.com, dwmw@amazon.co.uk,
jonnyc@amazon.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <4a456d72-f5b5-e860-0215-dd215e2edf09@ti.com>
> -----Original Message-----
> From: Kishon Vijay Abraham I <kishon@ti.com>
> Sent: 2019年8月13日 12:36
> To: Xiaowei Bao <xiaowei.bao@nxp.com>; lorenzo.pieralisi@arm.com;
> bhelgaas@google.com; M.h. Lian <minghuan.lian@nxp.com>; Mingkai Hu
> <mingkai.hu@nxp.com>; Roy Zang <roy.zang@nxp.com>;
> l.stach@pengutronix.de; tpiepho@impinj.com; Leonard Crestez
> <leonard.crestez@nxp.com>; andrew.smirnov@gmail.com;
> yue.wang@amlogic.com; hayashi.kunihiko@socionext.com;
> dwmw@amazon.co.uk; jonnyc@amazon.com; linux-pci@vger.kernel.org;
> linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> linux-arm-kernel@lists.infradead.org
> Subject: [EXT] Re: [PATCHv4 1/2] PCI: layerscape: Add the bar_fixed_64bit
> property in EP driver.
>
> Caution: EXT Email
>
> On 13/08/19 8:23 AM, Xiaowei Bao wrote:
> > The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1 is
> > 32bit, BAR3 and BAR4 is 64bit, this is determined by hardware,
>
> Do you mean BAR2 instead of BAR3 here?
Yes.
>
> Thanks
> Kishon
>
> > so set the bar_fixed_64bit with 0x14.
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > ---
> > v2:
> > - Replace value 0x14 with a macro.
> > v3:
> > - No change.
> > v4:
> > - send the patch again with '--to'.
> >
> > drivers/pci/controller/dwc/pci-layerscape-ep.c | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > index be61d96..227c33b 100644
> > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > @@ -44,6 +44,7 @@ static int ls_pcie_establish_link(struct dw_pcie *pci)
> > .linkup_notifier = false,
> > .msi_capable = true,
> > .msix_capable = false,
> > + .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> > };
> >
> > static const struct pci_epc_features*
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 00/11] Simple QoS for exynos-bus driver using interconnect
From: Chanwoo Choi @ 2019-08-13 6:19 UTC (permalink / raw)
To: Artur Świgoń, devicetree, linux-arm-kernel,
linux-samsung-soc, linux-kernel, linux-pm, dri-devel
Cc: sw0312.kim, krzk, inki.dae, myungjoo.ham, georgi.djakov,
m.szyprowski
In-Reply-To: <6be31199-a93d-c440-e0cd-7453e3ac1648@samsung.com>
Hi Artur,
On 19. 8. 13. 오후 3:17, Chanwoo Choi wrote:
> Hi Artur.
>
> The patch1-4 in this series depend on other patches[1] on mainline.
> On next v2 version, please make some patches based on patches[1]
> in order to prevent the merge conflict.
>
> [1] [RESEND PATCH v5 0/4] add coupled regulators for Exynos5422/5800
> - https://protect2.fireeye.com/url?k=4f35944fb07b6ba2.4f341f00-9498e831e3c86bfb&u=https://lkml.org/lkml/2019/8/8/217
Add correct reference url as following:
- https://lkml.org/lkml/2019/8/8/217
>
> Also, as I commented, we better to discuss it before sending the v2.
>
> On 19. 7. 23. 오후 9:20, Artur Świgoń wrote:
>> The following patchset adds interconnect[1][2] framework support to the
>> exynos-bus devfreq driver. Extending the devfreq driver with interconnect
>> capabilities started as a response to the issue referenced in [3]. The
>> patches can be subdivided into four logical groups:
>>
>> (a) Refactoring the existing devfreq driver in order to improve readability
>> and accommodate for adding new code (patches 01--04/11).
>>
>> (b) Tweaking the interconnect framework to support the exynos-bus use case
>> (patches 05--07/11). Exporting of_icc_get_from_provider() allows us to
>> avoid hardcoding every single graph edge in the DT or driver source, and
>> relaxing the requirement contained in that function removes the need to
>> provide dummy node IDs in the DT. Adjusting the logic in
>> apply_constraints() (drivers/interconnect/core.c) accounts for the fact
>> that every bus is a separate entity and therefore a separate interconnect
>> provider, albeit constituting a part of a larger hierarchy.
>>
>> (c) Implementing interconnect providers in the exynos-bus devfreq driver
>> and adding required DT properties for one selected platform, namely
>> Exynos4412 (patches 08--09/11). Due to the fact that this aims to be a
>> generic driver for various Exynos SoCs, node IDs are generated dynamically
>> rather than hardcoded. This has been determined to be a simpler approach,
>> but depends on changes described in (b).
>>
>> (d) Implementing a sample interconnect consumer for exynos-mixer targeted
>> at the issue referenced in [3], again with DT info only for Exynos4412
>> (patches 10--11/11).
>>
>> Integration of devfreq and interconnect functionalities comes down to one
>> extra line in the devfreq target() callback, which selects either the
>> frequency calculated by the devfreq governor, or the one requested with the
>> interconnect API, whichever is higher. All new code works equally well when
>> CONFIG_INTERCONNECT is 'n' (as in exynos_defconfig) in which case all
>> interconnect API functions are no-ops.
>>
>> ---
>> Artur Świgoń
>> Samsung R&D Institute Poland
>> Samsung Electronics
>>
>> ---
>> References:
>> [1] Documentation/interconnect/interconnect.rst
>> [2] Documentation/devicetree/bindings/interconnect/interconnect.txt
>> [3] https://patchwork.kernel.org/patch/10861757
>>
>> Artur Świgoń (10):
>> devfreq: exynos-bus: Extract exynos_bus_profile_init()
>> devfreq: exynos-bus: Extract exynos_bus_profile_init_passive()
>> devfreq: exynos-bus: Change goto-based logic to if-else logic
>> devfreq: exynos-bus: Clean up code
>> icc: Export of_icc_get_from_provider()
>> icc: Relax requirement in of_icc_get_from_provider()
>> icc: Relax condition in apply_constraints()
>> arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412
>> devfreq: exynos-bus: Add interconnect functionality to exynos-bus
>> arm: dts: exynos: Add interconnects to Exynos4412 mixer
>>
>> Marek Szyprowski (1):
>> drm: exynos: mixer: Add interconnect support
>>
>> .../boot/dts/exynos4412-odroid-common.dtsi | 1 +
>> arch/arm/boot/dts/exynos4412.dtsi | 10 +
>> drivers/devfreq/exynos-bus.c | 296 ++++++++++++++----
>> drivers/gpu/drm/exynos/exynos_mixer.c | 68 +++-
>> drivers/interconnect/core.c | 12 +-
>> include/linux/interconnect-provider.h | 6 +
>> 6 files changed, 314 insertions(+), 79 deletions(-)
>>
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 00/11] Simple QoS for exynos-bus driver using interconnect
From: Chanwoo Choi @ 2019-08-13 6:17 UTC (permalink / raw)
To: Artur Świgoń, devicetree, linux-arm-kernel,
linux-samsung-soc, linux-kernel, linux-pm, dri-devel
Cc: sw0312.kim, krzk, inki.dae, myungjoo.ham, georgi.djakov,
m.szyprowski
In-Reply-To: <20190723122016.30279-1-a.swigon@partner.samsung.com>
Hi Artur.
The patch1-4 in this series depend on other patches[1] on mainline.
On next v2 version, please make some patches based on patches[1]
in order to prevent the merge conflict.
[1] [RESEND PATCH v5 0/4] add coupled regulators for Exynos5422/5800
- https://lkml.org/lkml/2019/8/8/217
Also, as I commented, we better to discuss it before sending the v2.
On 19. 7. 23. 오후 9:20, Artur Świgoń wrote:
> The following patchset adds interconnect[1][2] framework support to the
> exynos-bus devfreq driver. Extending the devfreq driver with interconnect
> capabilities started as a response to the issue referenced in [3]. The
> patches can be subdivided into four logical groups:
>
> (a) Refactoring the existing devfreq driver in order to improve readability
> and accommodate for adding new code (patches 01--04/11).
>
> (b) Tweaking the interconnect framework to support the exynos-bus use case
> (patches 05--07/11). Exporting of_icc_get_from_provider() allows us to
> avoid hardcoding every single graph edge in the DT or driver source, and
> relaxing the requirement contained in that function removes the need to
> provide dummy node IDs in the DT. Adjusting the logic in
> apply_constraints() (drivers/interconnect/core.c) accounts for the fact
> that every bus is a separate entity and therefore a separate interconnect
> provider, albeit constituting a part of a larger hierarchy.
>
> (c) Implementing interconnect providers in the exynos-bus devfreq driver
> and adding required DT properties for one selected platform, namely
> Exynos4412 (patches 08--09/11). Due to the fact that this aims to be a
> generic driver for various Exynos SoCs, node IDs are generated dynamically
> rather than hardcoded. This has been determined to be a simpler approach,
> but depends on changes described in (b).
>
> (d) Implementing a sample interconnect consumer for exynos-mixer targeted
> at the issue referenced in [3], again with DT info only for Exynos4412
> (patches 10--11/11).
>
> Integration of devfreq and interconnect functionalities comes down to one
> extra line in the devfreq target() callback, which selects either the
> frequency calculated by the devfreq governor, or the one requested with the
> interconnect API, whichever is higher. All new code works equally well when
> CONFIG_INTERCONNECT is 'n' (as in exynos_defconfig) in which case all
> interconnect API functions are no-ops.
>
> ---
> Artur Świgoń
> Samsung R&D Institute Poland
> Samsung Electronics
>
> ---
> References:
> [1] Documentation/interconnect/interconnect.rst
> [2] Documentation/devicetree/bindings/interconnect/interconnect.txt
> [3] https://patchwork.kernel.org/patch/10861757
>
> Artur Świgoń (10):
> devfreq: exynos-bus: Extract exynos_bus_profile_init()
> devfreq: exynos-bus: Extract exynos_bus_profile_init_passive()
> devfreq: exynos-bus: Change goto-based logic to if-else logic
> devfreq: exynos-bus: Clean up code
> icc: Export of_icc_get_from_provider()
> icc: Relax requirement in of_icc_get_from_provider()
> icc: Relax condition in apply_constraints()
> arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412
> devfreq: exynos-bus: Add interconnect functionality to exynos-bus
> arm: dts: exynos: Add interconnects to Exynos4412 mixer
>
> Marek Szyprowski (1):
> drm: exynos: mixer: Add interconnect support
>
> .../boot/dts/exynos4412-odroid-common.dtsi | 1 +
> arch/arm/boot/dts/exynos4412.dtsi | 10 +
> drivers/devfreq/exynos-bus.c | 296 ++++++++++++++----
> drivers/gpu/drm/exynos/exynos_mixer.c | 68 +++-
> drivers/interconnect/core.c | 12 +-
> include/linux/interconnect-provider.h | 6 +
> 6 files changed, 314 insertions(+), 79 deletions(-)
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
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 9/9] arm64: Retrieve stolen time as paravirtualized guest
From: Zenghui Yu @ 2019-08-13 6:06 UTC (permalink / raw)
To: Steven Price
Cc: kvm, linux-doc, Catalin Marinas, Russell King, linux-kernel,
Marc Zyngier, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <07075994-3a32-8f20-23d8-1759ec2874e3@arm.com>
On 2019/8/12 18:39, Steven Price wrote:
> On 09/08/2019 14:51, Zenghui Yu wrote:
> [...]
>> Hi Steven,
>>
>> Since userspace is not involved yet (right?), no one will create the
>> PV_TIME device for guest (and no one will specify the IPA of the shared
>> stolen time region), and I guess we will get a "not supported" error
>> here.
>>
>> So what should we do if we want to test this series now? Any userspace
>> tools? If no, do you have any plans for userspace developing? ;-)
>
> At the moment I have the following patch to kvmtool which creates the
> PV_TIME device - this isn't in a state to go upstream, and Marc has
> asked that I rework the memory allocation, so this will need to change.
>
> It's a little ugly as it simply reserves the first page of RAM to use
> for the PV time structures.
Thanks for sharing the code. It's good enough to show what is required
in user-space.
(I'm not familiar with kvmtool. I will first take some time to move the
steal time part to Qemu and see what will happen.)
Thanks,
zenghui
> ----8<----
> diff --git a/Makefile b/Makefile
> index 3862112..a79956b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -158,7 +158,7 @@ endif
> # ARM
> OBJS_ARM_COMMON := arm/fdt.o arm/gic.o arm/gicv2m.o arm/ioport.o \
> arm/kvm.o arm/kvm-cpu.o arm/pci.o arm/timer.o \
> - arm/pmu.o
> + arm/pmu.o arm/pvtime.o
> HDRS_ARM_COMMON := arm/include
> ifeq ($(ARCH), arm)
> DEFINES += -DCONFIG_ARM
> diff --git a/arm/fdt.c b/arm/fdt.c
> index c80e6da..19eccbc 100644
> --- a/arm/fdt.c
> +++ b/arm/fdt.c
> @@ -119,6 +119,7 @@ static int setup_fdt(struct kvm *kvm)
>
> /* Create new tree without a reserve map */
> _FDT(fdt_create(fdt, FDT_MAX_SIZE));
> + _FDT(fdt_add_reservemap_entry(fdt, kvm->arch.memory_guest_start, 4096));
> _FDT(fdt_finish_reservemap(fdt));
>
> /* Header */
> diff --git a/arm/kvm.c b/arm/kvm.c
> index 1f85fc6..8bbfef1 100644
> --- a/arm/kvm.c
> +++ b/arm/kvm.c
> @@ -11,6 +11,8 @@
> #include <linux/kvm.h>
> #include <linux/sizes.h>
>
> +int pvtime_create(struct kvm *kvm);
> +
> struct kvm_ext kvm_req_ext[] = {
> { DEFINE_KVM_EXT(KVM_CAP_IRQCHIP) },
> { DEFINE_KVM_EXT(KVM_CAP_ONE_REG) },
> @@ -86,6 +88,10 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
> /* Create the virtual GIC. */
> if (gic__create(kvm, kvm->cfg.arch.irqchip))
> die("Failed to create virtual GIC");
> +
> + /* Setup PV time */
> + if (pvtime_create(kvm))
> + die("Failed to initialise PV time");
> }
>
> #define FDT_ALIGN SZ_2M
> diff --git a/arm/pvtime.c b/arm/pvtime.c
> new file mode 100644
> index 0000000..abcaab3
> --- /dev/null
> +++ b/arm/pvtime.c
> @@ -0,0 +1,77 @@
> +#include "kvm/kvm.h"
> +
> +#define KVM_DEV_TYPE_ARM_PV_TIME (KVM_DEV_TYPE_ARM_VGIC_ITS+2)
> +
> +/* Device Control API: PV_TIME */
> +#define KVM_DEV_ARM_PV_TIME_PADDR 0
> +#define KVM_DEV_ARM_PV_TIME_FREQUENCY 3
> +
> +#define KVM_DEV_ARM_PV_TIME_ST 0
> +#define KVM_DEV_ARM_PV_TIME_LPT 1
> +
> +static int pvtime_fd;
> +
> +int pvtime_create(struct kvm *kvm);
> +
> +int pvtime_create(struct kvm *kvm)
> +{
> + int err;
> + u64 lpt_paddr = 0x10000000;
> + u64 st_paddr = lpt_paddr + 4096;
> + u32 frequency = 100 * 1000 * 1000;
> +
> + printf("lpt_paddr=%llx\n", lpt_paddr);
> +
> + struct kvm_create_device pvtime_device = {
> + .type = KVM_DEV_TYPE_ARM_PV_TIME,
> + .flags = 0,
> + };
> +
> + err = ioctl(kvm->vm_fd, KVM_CREATE_DEVICE, &pvtime_device);
> + if (err) {
> + printf("Failed to create PV device\n");
> + return 0;
> + }
> +
> + pvtime_fd = pvtime_device.fd;
> +
> + struct kvm_device_attr lpt_base = {
> + .group = KVM_DEV_ARM_PV_TIME_PADDR,
> + .attr = KVM_DEV_ARM_PV_TIME_LPT,
> + .addr = (u64)(unsigned long)&lpt_paddr
> + };
> + struct kvm_device_attr st_base = {
> + .group = KVM_DEV_ARM_PV_TIME_PADDR,
> + .attr = KVM_DEV_ARM_PV_TIME_ST,
> + .addr = (u64)(unsigned long)&st_paddr
> + };
> +
> + struct kvm_device_attr lpt_freq = {
> + .group = KVM_DEV_ARM_PV_TIME_FREQUENCY,
> + .attr = KVM_DEV_ARM_PV_TIME_LPT,
> + .addr = (u64)(unsigned long)&frequency
> + };
> +
> + err = ioctl(pvtime_fd, KVM_SET_DEVICE_ATTR, &lpt_base);
> + if (err) {
> + perror("ioctl lpt_base failed");
> + printf("Ignoring LPT...\n");
> + }
> + err = ioctl(pvtime_fd, KVM_SET_DEVICE_ATTR, &st_base);
> + if (err) {
> + perror("ioctl st_base failed");
> + goto out_err;
> + }
> + err = ioctl(pvtime_fd, KVM_SET_DEVICE_ATTR, &lpt_freq);
> + if (err) {
> + perror("ioctl lpt_freq failed");
> + printf("Ignoring LPT...\n");
> + }
> +
> + printf("PV time setup\n");
> +
> + return 0;
> +out_err:
> + close(pvtime_fd);
> + return err;
> +}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] MAINTAINERS: Update path to tcb_clksrc.c
From: Denis Efremov @ 2019-08-13 6:10 UTC (permalink / raw)
To: linux-kernel; +Cc: joe, Alexandre Belloni, Denis Efremov, linux-arm-kernel
In-Reply-To: <7cd8d12f59bcacd18a78f599b46dac555f7f16c0.camel@perches.com>
Update MAINTAINERS record to reflect the filename change
from tcb_clksrc.c to timer-atmel-tcb.c
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-arm-kernel@lists.infradead.org
Fixes: a7aae768166e ("clocksource/drivers/tcb_clksrc: Rename the file for consistency")
Signed-off-by: Denis Efremov <efremov@linux.com>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c9ad38a9414f..3ec8154e4630 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10637,7 +10637,7 @@ M: Nicolas Ferre <nicolas.ferre@microchip.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: drivers/misc/atmel_tclib.c
-F: drivers/clocksource/tcb_clksrc.c
+F: drivers/clocksource/timer-atmel-tcb.c
MICROCHIP USBA UDC DRIVER
M: Cristian Birsan <cristian.birsan@microchip.com>
--
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] MAINTAINERS: Update path to physmap-versatile.c
From: Denis Efremov @ 2019-08-13 6:10 UTC (permalink / raw)
To: linux-kernel
Cc: Linus Walleij, Denis Efremov, Boris Brezillon, joe,
Ricardo Ribalda Delgado, linux-arm-kernel
In-Reply-To: <20190325212438.25657-1-joe@perches.com>
Update MAINTAINERS record to reflect the filename change
from physmap_of_versatile.c to physmap-versatile.c
Cc: Boris Brezillon <boris.brezillon@bootlin.com>
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Fixes: 6ca15cfa0788 ("mtd: maps: Rename physmap_of_{versatile, gemini} into physmap-{versatile, gemini}")
Signed-off-by: Denis Efremov <efremov@linux.com>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 590dcebe627f..c9ad38a9414f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1221,7 +1221,7 @@ F: arch/arm/boot/dts/versatile*
F: drivers/clk/versatile/
F: drivers/i2c/busses/i2c-versatile.c
F: drivers/irqchip/irq-versatile-fpga.c
-F: drivers/mtd/maps/physmap_of_versatile.c
+F: drivers/mtd/maps/physmap-versatile.c
F: drivers/power/reset/arm-versatile-reboot.c
F: drivers/soc/versatile/
--
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: [PATCHv2] PM / devfreq: Add dev_pm_qos support
From: Chanwoo Choi @ 2019-08-13 6:14 UTC (permalink / raw)
To: Leonard Crestez, MyungJoo Ham, Viresh Kumar, Saravana Kannan
Cc: Artur Świgoń, linux-pm, Rafael J. Wysocki,
Krzysztof Kozlowski, Lukasz Luba, Kyungmin Park, Alexandre Bailon,
cpgs (cpgs@samsung.com), Georgi Djakov, linux-arm-kernel
In-Reply-To: <e45c28528ff941abb1f72fdb1eedf65fb3345c5a.1565274802.git.leonard.crestez@nxp.com>
Hi,
In case of cpufreq, cpufreq.c replace the body of store_min_freq()
and store_max_freq() by using struct dev_pm_qos_request instancce
with dev_pm_qos_update_request().
If you use the new way with dev_pm_qos_update_request() for
min_freq_store() and max_freq_store(), it doesn't need to
get the final frequency from three candidate frequencies.
In result, We only consider the following two candidate frequencies
as following:
1. "devfreq->scaling_min_freq" will contain the requirement
from devfreq thermal throttling by OPP interface.
2. "devfreq->min_freq" will contain the requirements
from both user input through sysfs and the dev_pm_qos_request.
On 19. 8. 8. 오후 11:39, Leonard Crestez wrote:
> Add dev_pm_qos notifies to devfreq core in order to support frequency
> limits via the dev_pm_qos_add_request.
>
> Unlike the rest of devfreq the dev_pm_qos frequency is measured Khz:
> this is consistent with current dev_pm_qos usage for cpufreq and allows
> frequencies above 2Ghz (pm_qos expresses limits as s32).
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>
> ---
> Changes since v1:
> * Add doxygen comments for min_nb/max_nb
> * Remove notifiers on error/cleanup paths. Keep gotos simple by relying
> on dev_pm_qos_remove_notifier ignoring notifiers which were not added.
> Link to v1: https://patchwork.kernel.org/patch/11078475/
>
> drivers/devfreq/devfreq.c | 83 ++++++++++++++++++++++++++++++++++-----
> include/linux/devfreq.h | 5 +++
> 2 files changed, 79 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 784c08e4f931..7f1f273562f4 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -22,10 +22,11 @@
> #include <linux/platform_device.h>
> #include <linux/list.h>
> #include <linux/printk.h>
> #include <linux/hrtimer.h>
> #include <linux/of.h>
> +#include <linux/pm_qos.h>
> #include "governor.h"
>
> #define CREATE_TRACE_POINTS
> #include <trace/events/devfreq.h>
>
> @@ -96,10 +97,26 @@ static unsigned long find_available_max_freq(struct devfreq *devfreq)
> dev_pm_opp_put(opp);
>
> return max_freq;
> }
>
> +static unsigned long get_effective_min_freq(struct devfreq *devfreq)
> +{
> + return max3(devfreq->scaling_min_freq, devfreq->min_freq,
> + 1000 * (unsigned long)dev_pm_qos_read_value(
> + devfreq->dev.parent,
> + DEV_PM_QOS_MIN_FREQUENCY));
As I commented above, if we use the dev_pm_qos_request, it is not needed.
> +}
> +
> +static unsigned long get_effective_max_freq(struct devfreq *devfreq)
> +{
> + return min3(devfreq->scaling_max_freq, devfreq->max_freq,
> + 1000 * (unsigned long)dev_pm_qos_read_value(
> + devfreq->dev.parent,
> + DEV_PM_QOS_MAX_FREQUENCY));
> +}
ditto.
> +
> /**
> * devfreq_get_freq_level() - Lookup freq_table for the frequency
> * @devfreq: the devfreq instance
> * @freq: the target frequency
> */
> @@ -356,12 +373,12 @@ int update_devfreq(struct devfreq *devfreq)
> *
> * List from the highest priority
> * max_freq
> * min_freq
> */
> - max_freq = min(devfreq->scaling_max_freq, devfreq->max_freq);
> - min_freq = max(devfreq->scaling_min_freq, devfreq->min_freq);
> + max_freq = get_effective_max_freq(devfreq);
> + min_freq = get_effective_min_freq(devfreq);
>
> if (freq < min_freq) {
> freq = min_freq;
> flags &= ~DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use GLB */
> }
> @@ -570,10 +587,31 @@ static int devfreq_notifier_call(struct notifier_block *nb, unsigned long type,
> mutex_unlock(&devfreq->lock);
>
> return ret;
> }
>
> +static int devfreq_qos_notifier_call(struct devfreq *devfreq)
> +{
> + int ret;
> +
> + mutex_lock(&devfreq->lock);
> + ret = update_devfreq(devfreq);
> + mutex_unlock(&devfreq->lock);
> +
> + return ret;
> +}
> +
> +static int devfreq_qos_min_notifier_call(struct notifier_block *nb, unsigned long val, void *ptr)
Please keep the under 80 line if there are no any special reason.
> +{
> + return devfreq_qos_notifier_call(container_of(nb, struct devfreq, nb_min));
ditto.
> +}
> +
> +static int devfreq_qos_max_notifier_call(struct notifier_block *nb, unsigned long val, void *ptr)
ditto.
> +{
> + return devfreq_qos_notifier_call(container_of(nb, struct devfreq, nb_max));
ditto.
> +}
> +
> /**
> * devfreq_dev_release() - Callback for struct device to release the device.
> * @dev: the devfreq device
> *
> * Remove devfreq from the list and release its resources.
> @@ -592,10 +630,14 @@ static void devfreq_dev_release(struct device *dev)
> mutex_unlock(&devfreq_list_lock);
>
> if (devfreq->profile->exit)
> devfreq->profile->exit(devfreq->dev.parent);
>
> + dev_pm_qos_remove_notifier(devfreq->dev.parent, &devfreq->nb_max,
> + DEV_PM_QOS_MAX_FREQUENCY);
> + dev_pm_qos_remove_notifier(devfreq->dev.parent, &devfreq->nb_min,
> + DEV_PM_QOS_MIN_FREQUENCY);
> mutex_destroy(&devfreq->lock);
> kfree(devfreq);
> }
>
> /**
> @@ -636,21 +678,44 @@ struct devfreq *devfreq_add_device(struct device *dev,
> err = -ENOMEM;
> goto err_out;
> }
>
> mutex_init(&devfreq->lock);
> - mutex_lock(&devfreq->lock);
> devfreq->dev.parent = dev;
> devfreq->dev.class = devfreq_class;
> devfreq->dev.release = devfreq_dev_release;
> devfreq->profile = profile;
> strncpy(devfreq->governor_name, governor_name, DEVFREQ_NAME_LEN);
> devfreq->previous_freq = profile->initial_freq;
> devfreq->last_status.current_frequency = profile->initial_freq;
> devfreq->data = data;
> devfreq->nb.notifier_call = devfreq_notifier_call;
>
> + /*
> + * notifier from pm_qos
> + *
> + * initialized outside of devfreq->lock to avoid circular warning
> + * between devfreq->lock and dev_pm_qos_mtx
> + */
> + devfreq->nb_min.notifier_call = devfreq_qos_min_notifier_call;
> + devfreq->nb_max.notifier_call = devfreq_qos_max_notifier_call;
> +
> + err = dev_pm_qos_add_notifier(devfreq->dev.parent, &devfreq->nb_min,
> + DEV_PM_QOS_MIN_FREQUENCY);
> + if (err) {
> + dev_err(dev, "Failed to register MIN QoS notifier: %d\n", err);
> + goto err_dev;
> + }
> +
> + err = dev_pm_qos_add_notifier(devfreq->dev.parent, &devfreq->nb_max,
> + DEV_PM_QOS_MAX_FREQUENCY);
> + if (err) {
> + dev_err(dev, "Failed to register MAX QoS notifier: %d\n", err);
> + goto err_dev;
> + }
> +
> + mutex_lock(&devfreq->lock);
> if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
> mutex_unlock(&devfreq->lock);
> err = set_freq_table(devfreq);
> if (err < 0)
> goto err_dev;
> @@ -741,10 +806,14 @@ struct devfreq *devfreq_add_device(struct device *dev,
> mutex_unlock(&devfreq_list_lock);
> err_devfreq:
> devfreq_remove_device(devfreq);
> devfreq = NULL;
> err_dev:
> + dev_pm_qos_remove_notifier(devfreq->dev.parent, &devfreq->nb_max,
> + DEV_PM_QOS_MAX_FREQUENCY);
> + dev_pm_qos_remove_notifier(devfreq->dev.parent, &devfreq->nb_min,
> + DEV_PM_QOS_MIN_FREQUENCY);
> kfree(devfreq);
> err_out:
> return ERR_PTR(err);
> }
> EXPORT_SYMBOL(devfreq_add_device);
> @@ -1311,13 +1380,11 @@ static ssize_t min_freq_store(struct device *dev, struct device_attribute *attr,
> }
>
> static ssize_t min_freq_show(struct device *dev, struct device_attribute *attr,
> char *buf)
> {
> - struct devfreq *df = to_devfreq(dev);
> -
> - return sprintf(buf, "%lu\n", max(df->scaling_min_freq, df->min_freq));
> + return sprintf(buf, "%lu\n", get_effective_min_freq(to_devfreq(dev)));
> }
>
> static ssize_t max_freq_store(struct device *dev, struct device_attribute *attr,
> const char *buf, size_t count)
> {
> @@ -1356,13 +1423,11 @@ static ssize_t max_freq_store(struct device *dev, struct device_attribute *attr,
> static DEVICE_ATTR_RW(min_freq);
>
> static ssize_t max_freq_show(struct device *dev, struct device_attribute *attr,
> char *buf)
> {
> - struct devfreq *df = to_devfreq(dev);
> -
> - return sprintf(buf, "%lu\n", min(df->scaling_max_freq, df->max_freq));
> + return sprintf(buf, "%lu\n", get_effective_max_freq(to_devfreq(dev)));
> }
> static DEVICE_ATTR_RW(max_freq);
>
> static ssize_t available_frequencies_show(struct device *d,
> struct device_attribute *attr,
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index 2bae9ed3c783..8b92ccbd1962 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -134,10 +134,12 @@ struct devfreq_dev_profile {
> * @total_trans: Number of devfreq transitions
> * @trans_table: Statistics of devfreq transitions
> * @time_in_state: Statistics of devfreq states
> * @last_stat_updated: The last time stat updated
> * @transition_notifier_list: list head of DEVFREQ_TRANSITION_NOTIFIER notifier
> + * @nb_min: Notifier block for DEV_PM_QOS_MIN_FREQUENCY
> + * @nb_max: Notifier block for DEV_PM_QOS_MAX_FREQUENCY
> *
> * This structure stores the devfreq information for a give device.
> *
> * Note that when a governor accesses entries in struct devfreq in its
> * functions except for the context of callbacks defined in struct
> @@ -176,10 +178,13 @@ struct devfreq {
> unsigned int *trans_table;
> unsigned long *time_in_state;
> unsigned long last_stat_updated;
>
> struct srcu_notifier_head transition_notifier_list;
> +
> + struct notifier_block nb_min;
> + struct notifier_block nb_max;
> };
>
> struct devfreq_freqs {
> unsigned long old;
> unsigned long new;
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
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 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
From: Maxime Ripard @ 2019-08-13 6:05 UTC (permalink / raw)
To: Michael Nazzareno Trimarchi
Cc: Mark Rutland, devicetree, David Airlie, Michael Turquette,
linux-sunxi, linux-kernel, dri-devel, Chen-Yu Tsai, Rob Herring,
Jagan Teki, Daniel Vetter, linux-amarula, linux-clk,
linux-arm-kernel
In-Reply-To: <CAOf5uwkvCs62zHcUoFuJwau_ZZFdnVf8ua6JY_wzUb9m8rLTTw@mail.gmail.com>
On Mon, Jul 29, 2019 at 08:59:04AM +0200, Michael Nazzareno Trimarchi wrote:
> Hi
>
> On Wed, Jul 24, 2019 at 11:05 AM Maxime Ripard
> <maxime.ripard@bootlin.com> wrote:
> >
> > On Mon, Jul 22, 2019 at 03:51:04PM +0530, Jagan Teki wrote:
> > > Hi Maxime,
> > >
> > > On Sat, Jul 20, 2019 at 3:02 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > >
> > > > On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote:
> > > > > On Sat, Jul 20, 2019 at 12:28 PM Maxime Ripard
> > > > > <maxime.ripard@bootlin.com> wrote:
> > > > > >
> > > > > > On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno Trimarchi wrote:
> > > > > > > > > tcon-pixel clock is the rate that you want to achive on display side
> > > > > > > > > and if you have 4 lanes 32bit or lanes and different bit number that
> > > > > > > > > you need to have a clock that is able to put outside bits and speed
> > > > > > > > > equal to pixel-clock * bits / lanes. so If you want a pixel-clock of
> > > > > > > > > 40 mhz and you have 32bits and 4 lanes you need to have a clock of
> > > > > > > > > 40 * 32 / 4 in no-burst mode. I think that this is done but most of
> > > > > > > > > the display.
> > > > > > > >
> > > > > > > > So this is what the issue is then?
> > > > > > > >
> > > > > > > > This one does make sense, and you should just change the rate in the
> > > > > > > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu.
> > > > > > > >
> > > > > > > > I'm still wondering why that hasn't been brought up in either the
> > > > > > > > discussion or the commit log before though.
> > > > > > > >
> > > > > > > Something like this?
> > > > > > >
> > > > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +++++++++++---------
> > > > > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 --
> > > > > > > 2 files changed, 11 insertions(+), 11 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > index 64c43ee6bd92..42560d5c327c 100644
> > > > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > @@ -263,10 +263,11 @@ static int sun4i_tcon_get_clk_delay(const struct
> > > > > > > drm_display_mode *mode,
> > > > > > > }
> > > > > > >
> > > > > > > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> > > > > > > - const struct drm_display_mode *mode)
> > > > > > > + const struct drm_display_mode *mode,
> > > > > > > + u32 tcon_mul)
> > > > > > > {
> > > > > > > /* Configure the dot clock */
> > > > > > > - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> > > > > > > + clk_set_rate(tcon->dclk, mode->crtc_clock * tcon_mul * 1000);
> > > > > > >
> > > > > > > /* Set the resolution */
> > > > > > > regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> > > > > > > @@ -335,12 +336,13 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > > > > sun4i_tcon *tcon,
> > > > > > > u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> > > > > > > u8 lanes = device->lanes;
> > > > > > > u32 block_space, start_delay;
> > > > > > > - u32 tcon_div;
> > > > > > > + u32 tcon_div, tcon_mul;
> > > > > > >
> > > > > > > - tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
> > > > > > > - tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;
> > > > > > > + tcon->dclk_min_div = 4;
> > > > > > > + tcon->dclk_max_div = 127;
> > > > > > >
> > > > > > > - sun4i_tcon0_mode_set_common(tcon, mode);
> > > > > > > + tcon_mul = bpp / lanes;
> > > > > > > + sun4i_tcon0_mode_set_common(tcon, mode, tcon_mul);
> > > > > > >
> > > > > > > /* Set dithering if needed */
> > > > > > > sun4i_tcon0_mode_set_dithering(tcon, sun4i_tcon_get_connector(encoder));
> > > > > > > @@ -366,7 +368,7 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > > > > sun4i_tcon *tcon,
> > > > > > > */
> > > > > > > regmap_read(tcon->regs, SUN4I_TCON0_DCLK_REG, &tcon_div);
> > > > > > > tcon_div &= GENMASK(6, 0);
> > > > > > > - block_space = mode->htotal * bpp / (tcon_div * lanes);
> > > > > > > + block_space = mode->htotal * tcon_div * tcon_mul;
> > > > > > > block_space -= mode->hdisplay + 40;
> > > > > > >
> > > > > > > regmap_write(tcon->regs, SUN4I_TCON0_CPU_TRI0_REG,
> > > > > > > @@ -408,7 +410,7 @@ static void sun4i_tcon0_mode_set_lvds(struct
> > > > > > > sun4i_tcon *tcon,
> > > > > > >
> > > > > > > tcon->dclk_min_div = 7;
> > > > > > > tcon->dclk_max_div = 7;
> > > > > > > - sun4i_tcon0_mode_set_common(tcon, mode);
> > > > > > > + sun4i_tcon0_mode_set_common(tcon, mode, 1);
> > > > > > >
> > > > > > > /* Set dithering if needed */
> > > > > > > sun4i_tcon0_mode_set_dithering(tcon, sun4i_tcon_get_connector(encoder));
> > > > > > > @@ -487,7 +489,7 @@ static void sun4i_tcon0_mode_set_rgb(struct
> > > > > > > sun4i_tcon *tcon,
> > > > > > >
> > > > > > > tcon->dclk_min_div = 6;
> > > > > > > tcon->dclk_max_div = 127;
> > > > > > > - sun4i_tcon0_mode_set_common(tcon, mode);
> > > > > > > + sun4i_tcon0_mode_set_common(tcon, mode, 1);
> > > > > > >
> > > > > > > /* Set dithering if needed */
> > > > > > > sun4i_tcon0_mode_set_dithering(tcon, connector);
> > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > > > > > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > > > > > > index 5c3ad5be0690..a07090579f84 100644
> > > > > > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > > > > > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > > > > > > @@ -13,8 +13,6 @@
> > > > > > > #include <drm/drm_encoder.h>
> > > > > > > #include <drm/drm_mipi_dsi.h>
> > > > > > >
> > > > > > > -#define SUN6I_DSI_TCON_DIV 4
> > > > > > > -
> > > > > > > struct sun6i_dsi {
> > > > > > > struct drm_connector connector;
> > > > > > > struct drm_encoder encoder;
> > > > > >
> > > > > > I had more something like this in mind:
> > > > > > http://code.bulix.org/nlp5a4-803511
> > > > >
> > > > > Worth to look at it. was it working on your panel? meanwhile I will check it.
> > > >
> > > > I haven't tested it.
> > > >
> > > > > We have updated with below change [1], seems working on but is
> > > > > actually checking the each divider as before start with 4... till 127.
> > > > >
> > > > > This new approach, is start looking the best divider from 4.. based on
> > > > > the idea vs rounded it will ended up best divider like [2]
> > > >
> > > > But why?
> > > >
> > > > I mean, it's not like it's the first time I'm asking this...
> > > >
> > > > If the issue is what Micheal described, then the divider has nothing
> > > > to do with it. We've had that discussion over and over again.
> > >
> > > This is what Michael is mentioned in above mail "tcon-pixel clock is
> > > the rate that you want to achive on display side and if you have 4
> > > lanes 32bit or lanes and different bit number that you need to have
> > > a clock that is able to put outside bits and speed equal to
> > > pixel-clock * bits / lanes. so If you want a pixel-clock of 40 mhz
> > > and you have 32bits and 4 lanes you need to have a clock of 40 * 32
> > > / 4 in no-burst mode. "
> >
> > Yeah, so we need to change the clock rate.
> >
> > > He is trying to manage the bpp/lanes into dclk_mul (in last mail)
> > > and it can multiply with pixel clock which is rate argument in
> > > sun4i_dclk_round_rate.
> > >
> > > The solution I have mentioned in dclk_min, max is bpp/lanes also
> > > multiple rate in dotclock sun4i_dclk_round_rate.
> > >
> > > In both cases the overall pll_rate depends on dividers, the one that I
> > > have on this patch is based on BSP and the Michael one is more generic
> > > way so-that it can not to touch other functionalities and looping
> > > dividers to find the best one.
> > >
> > > If dclk_min/max is bpp/lanes then dotclock directly using divider 6
> > > (assuming 24-bit and 4 lanes) and return the pll_rate and divider 6
> > > associated.
> > >
> > > if dclk_mul is bpp/lanes, on Michael new change, the dividers start
> > > with 4 and end with 127 but the constant ideal rate which rate *
> > > bpp/lanes but the loop from sun4i_dclk_round_rate computed the divider
> > > as 6 only, ie what I'm mentioned on the above mail.
> >
> > We've been over this a couple of times already.
> >
> > The clock is generated like this:
> >
> > PLL -> TCON Module Clock -> TCON DCLK
> >
> > You want the TCON DCLK to be at the pixel clock rate * bpp /
> > lanes. Fine, that makes sense.
> >
> > Except that the patch you've sent, instead of changing the rate
> > itself, changes the ratio between the module clock and DCLK.
> >
> > And this is where the issue lies. First, from a logical viewpoint, it
> > doesn't make sense. If you want to change the clock rate, then just do
> > it. Don't hack around the multipliers trying to fall back to something
> > that works for you.
> >
> > Then, the ratio itself needs to be set to 4. This is the part that
> > we've discussed way too many times already, but in the Allwinner BSP,
> > that ratio is hardcoded to 4, and we've had panels that need it at
> > that value.
> >
> > So, what you want to do is to have:
> >
> > TCON DCLK = pixel clock * bpp / lanes
> > TCON Module Clock = DCLK * 4
> > PLL = Module Clock * Module Clock Divider (which I believe is 1 in most cases)
>
> pll-mipi 1 1 1 178200000
> 0 0 50000
> tcon0 2 2 1 178200000
> 0 0 50000
> tcon-pixel-clock 1 1 1 29700000
> 0 0 50000
Is this before or after your patches?
> This is an english problem from my side:
> tcon-pixel-clock is DCLK
> tcon0 must be tcon-pixel-clock * bpp / lanes, because the logic need to
> put a bit every cycle.
Again, I'm not saying this is wrong, but each time I've looked at it
the BSP was using a 4 divider between the tcon module clock and the
dotclock.
So, please prove me wrong here.
> One solution can be:
> - set_rate_exclusive to tcon0 and calculate as display pixel clock *
> bpp / lanes
I'm not sure what set_rate_exclusive has to do with it. I mean, it's a
good idea to use it, but it shouldn't really change anything to the
discussion.
> - calculate the tcon-pixel-clock using all divider
I'm not sure what you mean by that.
> Problem is that the function that calculate tcon-pixel-clock does not
> have any constrain on the ideal value.
It does have constraints, but you're right that it will not try to
find an exact match and bail out if it can't do it, but will find the
closest match.
> What you are suggesting is not correct in my opinion or I'm not
> following your suggesstion.
Then prove me wrong.
> What I know is that if we have a pixel-clock of dvi display of 50Mhz
> and we have 4 lanes 32bit we need a clock in the logic of 400Mhz
> (this is the ideal throughtput).
> So tcon-pixel-clock is 50mhz and tcon0 is 400Mhz.
There's one thing to keep in mind though. The TCON dotclock in the
MIPI-DSI case isn't directly tied to the Bit Clock, it's simply an
internal clock in the pipeline to feed the FIFO of the MIPI-DSI
controller. The MIPI-DSI controller itself will generate that clock,
and only that one will have those constraints.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
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/2] dt-bindings: irq: Convert Allwinner NMI Controller to a schema
From: Maxime Ripard @ 2019-08-13 5:47 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Jason Cooper, maz, Chen-Yu Tsai,
Thomas Gleixner, Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqJkTrCuscnWgm5cDmQj5RPGnd3qXkzR40XWKB2skZFwXA@mail.gmail.com>
Hi Rob,
On Tue, Jul 23, 2019 at 10:32:41AM -0600, Rob Herring wrote:
> On Tue, Jul 23, 2019 at 7:27 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > The Allwinner SoCs have an interrupt controller called NMI supported in
> > Linux, with a matching Device Tree binding.
> >
> > Now that we have the DT validation in place, let's convert the device tree
> > bindings for that controller over to a YAML schemas.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> > ---
> > .../allwinner,sun7i-a20-sc-nmi.yaml | 83 +++++++++++++++++++
> > .../allwinner,sunxi-nmi.txt | 29 -------
> > 2 files changed, 83 insertions(+), 29 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
> > delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
> >
> > diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
> > new file mode 100644
> > index 000000000000..cb8077b0c8dd
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
> > @@ -0,0 +1,83 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Allwinner A20 Non-Maskable Interrupt Controller Device Tree Bindings
> > +
> > +maintainers:
> > + - Chen-Yu Tsai <wens@csie.org>
> > + - Maxime Ripard <maxime.ripard@bootlin.com>
> > +
> > +allOf:
> > + - $ref: /schemas/interrupt-controller.yaml#
> > +
> > +select:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - allwinner,sun6i-a31-r-intc
> > + - allwinner,sun7i-a20-sc-nmi
> > + - allwinner,sun9i-a80-sc-nmi
>
> This should have all the possible compatibles in case all are not
> listed.
I'm sorry, but I'm not sure I understood what you meant here :/
>
> > +
> > + # Deprecated
> > + - allwinner,sun6i-a31-sc-nmi
>
> I know we already did things this way before, but perhaps this should
> be listed below with the 'deprecated' property. The tools can include
> it in select, but then remove it from compatible property.
Can we have more than just one of the choice for an enum?
In this particular case, since we have oneOf it's not really too much
of an issue, but there's a significant amount of users of enum for the
compatibles.
Thanks!
Maxime
> > +
> > + required:
> > + - compatible
> > +
> > +properties:
> > + "#interrupt-cells":
> > + const: 2
> > + description:
> > + The first cell is the IRQ number, the second cell the trigger
> > + type as defined in interrupt.txt in this directory.
> > +
> > + compatible:
> > + oneOf:
> > + - const: allwinner,sun6i-a31-r-intc
> > + - const: allwinner,sun7i-a20-sc-nmi
> > + - items:
> > + - const: allwinner,sun8i-a83t-r-intc
> > + - const: allwinner,sun6i-a31-r-intc
> > + - const: allwinner,sun9i-a80-sc-nmi
> > + - items:
> > + - const: allwinner,sun50i-a64-r-intc
> > + - const: allwinner,sun6i-a31-r-intc
> > + - items:
> > + - const: allwinner,sun50i-h6-r-intc
> > + - const: allwinner,sun6i-a31-r-intc
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + interrupt-controller: true
> > +
> > +required:
> > + - "#interrupt-cells"
> > + - compatible
> > + - reg
> > + - interrupts
> > + - interrupt-controller
> > +
> > +# FIXME: We should set it, but it would report all the generic
> > +# properties as additional properties.
> > +# additionalProperties: false
> > +
> > +examples:
> > + - |
> > + interrupt-controller@1c00030 {
> > + compatible = "allwinner,sun7i-a20-sc-nmi";
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > + reg = <0x01c00030 0x0c>;
> > + interrupt-parent = <&gic>;
> > + interrupts = <0 0 4>;
> > + };
> > +
> > +...
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
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] arm64: dts: allwinner: a64: Drop PMU node
From: Maxime Ripard @ 2019-08-13 5:39 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Jared D . McNeill, Chen-Yu Tsai,
Rob Herring, Harald Geyer, Robin Murphy, arm-linux
In-Reply-To: <CA+E=qVchsqOF_hVD-qBuKwi7PTMYtUR-LE2dD_mpptFJcWE_yw@mail.gmail.com>
On Mon, Aug 12, 2019 at 11:01:51AM -0700, Vasily Khoruzhick wrote:
> On Mon, Aug 12, 2019 at 1:04 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Thu, Aug 08, 2019 at 12:59:07PM -0700, Vasily Khoruzhick wrote:
> > > On Thu, Aug 8, 2019 at 9:26 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > >
> > > > On Wed, Aug 07, 2019 at 10:36:08AM -0700, Vasily Khoruzhick wrote:
> > > > > On Wed, Aug 7, 2019 at 4:56 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > > >
> > > > > > On Tue, Aug 06, 2019 at 07:39:26PM -0700, Vasily Khoruzhick wrote:
> > > > > > > On Tue, Aug 6, 2019 at 2:14 PM Robin Murphy <robin.murphy@arm.com> wrote:
> > > > > > > >
> > > > > > > > On 2019-08-06 9:52 pm, Vasily Khoruzhick wrote:
> > > > > > > > > On Tue, Aug 6, 2019 at 1:19 PM Harald Geyer <harald@ccbib.org> wrote:
> > > > > > > > >>
> > > > > > > > >> Vasily Khoruzhick writes:
> > > > > > > > >>> On Tue, Aug 6, 2019 at 7:35 AM Robin Murphy <robin.murphy@arm.com> wrote:
> > > > > > > > >>>>
> > > > > > > > >>>> On 06/08/2019 15:01, Vasily Khoruzhick wrote:
> > > > > > > > >>>>> Looks like PMU in A64 is broken, it generates no interrupts at all and
> > > > > > > > >>>>> as result 'perf top' shows no events.
> > > > > > > > >>>>
> > > > > > > > >>>> Does something like 'perf stat sleep 1' at least count cycles correctly?
> > > > > > > > >>>> It could well just be that the interrupt numbers are wrong...
> > > > > > > > >>>
> > > > > > > > >>> Looks like it does, at least result looks plausible:
> > > > > > > > >>
> > > > > > > > >> I'm using perf stat regularly (cache benchmarks) and it works fine.
> > > > > > > > >>
> > > > > > > > >> Unfortunately I wasn't aware that perf stat is a poor test for
> > > > > > > > >> the interrupts part of the node, when I added it. So I'm not too
> > > > > > > > >> surprised I got it wrong.
> > > > > > > > >>
> > > > > > > > >> However, it would be unfortunate if the node got removed completely,
> > > > > > > > >> because perf stat would not work anymore. Maybe we can only remove
> > > > > > > > >> the interrupts or just fix them even if the HW doesn't work?
> > > > > > > > >
> > > > > > > > > I'm not familiar with PMU driver. Is it possible to get it working
> > > > > > > > > without interrupts?
> > > > > > > >
> > > > > > > > Yup - you get a grumpy message from the driver, it will refuse sampling
> > > > > > > > events (the ones which weren't working anyway), and if you measure
> > > > > > > > anything for long enough that a counter overflows you'll get wonky
> > > > > > > > results. But for counting hardware events over relatively short periods
> > > > > > > > it'll still do the job.
> > > > > > >
> > > > > > > I tried to drop interrupts completely from the node but 'perf top' is
> > > > > > > still broken. Though now in different way: it complains "cycles: PMU
> > > > > > > Hardware doesn't support sampling/overflow-interrupts. Try 'perf
> > > > > > > stat'"
> > > > > >
> > > > > > I have no idea if that's the culprit, but what is the state of the
> > > > > > 0x09010000 register?
> > > > >
> > > > > What register is that and how do I check it?
> > > >
> > > > It's in the CPUX Configuration block, and the bits are labelled as CPU
> > > > Debug Reset.
> > > >
> > > > And if you have busybox, you can use devmem.
> > >
> > > CPUX configuration block is at 0x01700000 according to A64 user
> > > manual, and particular register you're interested in is at 0x01700080,
> > > its value is 0x1110110F.
> > >
> > > Bits 16-19 are not defined in user manual and are not set.
> >
> > Sorry, I somehow thought this was for the H6...
> >
> > I don't have any idea then :/
>
> OK, so what should we do? 'perf top'/'perf record' work fine if PMU
> node is dropped, but they don't work if PMU node is present (even with
> interrupts dropped). I'd prefer to have 'perf top' and 'perf record'
> working instead of 'perf stat'
Well, it doesn't work so we should just remove the node, and if
someone wants it back, they should figure it out.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
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 v2 15/34] staging/vc04_services: convert put_page() to put_user_page*()
From: Stefan Wahren @ 2019-08-13 5:23 UTC (permalink / raw)
To: john.hubbard, Andrew Morton
Cc: linux-fbdev, Jan Kara, kvm, Greg Kroah-Hartman, Dave Hansen,
Dave Chinner, dri-devel, linux-mm, sparclinux, Suniel Mahesh,
Dan Williams, devel, rds-devel, linux-rdma, Ira Weiny, x86,
amd-gfx, Christoph Hellwig, Jason Gunthorpe, John Hubbard,
xen-devel, devel, linux-media, Mihaela Muraru, intel-gfx,
linux-block, Jérôme Glisse, linux-rpi-kernel,
ceph-devel, Sidong Yang, linux-arm-kernel, linux-nfs, Eric Anholt,
netdev, LKML, linux-xfs, linux-crypto, Kishore KP, linux-fsdevel,
Al Viro
In-Reply-To: <20190804224915.28669-16-jhubbard@nvidia.com>
On 05.08.19 00:48, john.hubbard@gmail.com wrote:
> From: John Hubbard <jhubbard@nvidia.com>
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Mihaela Muraru <mihaela.muraru21@gmail.com>
> Cc: Suniel Mahesh <sunil.m@techveda.org>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: Sidong Yang <realwakka@gmail.com>
> Cc: Kishore KP <kishore.p@techveda.org>
> Cc: linux-rpi-kernel@lists.infradead.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: devel@driverdev.osuosl.org
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
_______________________________________________
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 v2] PM / devfreq: passive: Use non-devm notifiers
From: Chanwoo Choi @ 2019-08-13 5:20 UTC (permalink / raw)
To: Leonard Crestez, MyungJoo Ham, Kyungmin Park
Cc: Artur Świgoń, Jacky Bai, Saravana Kannan, linux-pm,
Krzysztof Kozlowski, Alexandre Bailon, cpgs (cpgs@samsung.com),
Georgi Djakov, linux-arm-kernel
In-Reply-To: <074ddc8e211bc7466b5ceec2591cb220a44d8d3a.1565672482.git.leonard.crestez@nxp.com>
Hi,
Why do you miss the 'Fixes' tag as I commented?
Is there any reason?
On 19. 8. 13. 오후 2:06, Leonard Crestez wrote:
> The devfreq passive governor registers and unregisters devfreq
> transition notifiers on DEVFREQ_GOV_START/GOV_STOP using devm wrappers.
>
> If devfreq itself is registered with devm then a warning is triggered on
> rmmod from devm_devfreq_unregister_notifier. Call stack looks like this:
>
> devm_devfreq_unregister_notifier+0x30/0x40
> devfreq_passive_event_handler+0x4c/0x88
> devfreq_remove_device.part.8+0x6c/0x9c
> devm_devfreq_dev_release+0x18/0x20
> release_nodes+0x1b0/0x220
> devres_release_all+0x78/0x84
> device_release_driver_internal+0x100/0x1c0
> driver_detach+0x4c/0x90
> bus_remove_driver+0x7c/0xd0
> driver_unregister+0x2c/0x58
> platform_driver_unregister+0x10/0x18
> imx_devfreq_platdrv_exit+0x14/0xd40 [imx_devfreq]
>
> This happens because devres_release_all will first remove all the nodes
> into a separate todo list so the nested devres_release from
> devm_devfreq_unregister_notifier won't find anything.
>
> Fix the warning by calling the non-devm APIS for frequency notification.
> Using devm wrappers is not actually useful for a governor anyway: it
> relies on the devfreq core to correctly match the GOV_START/GOV_STOP
> notifications.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
> Cc: stable@vger.kernel.org
>
> ---
> Changes since v1:
> * Remove unused variable "dev" and avoid warning
> * Added ack and cc stable
> Link to v1: https://patchwork.kernel.org/patch/11084541/
>
> drivers/devfreq/governor_passive.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/devfreq/governor_passive.c b/drivers/devfreq/governor_passive.c
> index 58308948b863..be6eeab9c814 100644
> --- a/drivers/devfreq/governor_passive.c
> +++ b/drivers/devfreq/governor_passive.c
> @@ -147,11 +147,10 @@ static int devfreq_passive_notifier_call(struct notifier_block *nb,
> }
>
> static int devfreq_passive_event_handler(struct devfreq *devfreq,
> unsigned int event, void *data)
> {
> - struct device *dev = devfreq->dev.parent;
> struct devfreq_passive_data *p_data
> = (struct devfreq_passive_data *)devfreq->data;
> struct devfreq *parent = (struct devfreq *)p_data->parent;
> struct notifier_block *nb = &p_data->nb;
> int ret = 0;
> @@ -163,16 +162,16 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq,
> case DEVFREQ_GOV_START:
> if (!p_data->this)
> p_data->this = devfreq;
>
> nb->notifier_call = devfreq_passive_notifier_call;
> - ret = devm_devfreq_register_notifier(dev, parent, nb,
> + ret = devfreq_register_notifier(parent, nb,
> DEVFREQ_TRANSITION_NOTIFIER);
> break;
> case DEVFREQ_GOV_STOP:
> - devm_devfreq_unregister_notifier(dev, parent, nb,
> - DEVFREQ_TRANSITION_NOTIFIER);
> + WARN_ON(devfreq_unregister_notifier(parent, nb,
> + DEVFREQ_TRANSITION_NOTIFIER));
> break;
> default:
> break;
> }
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
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] PM / devfreq: passive: Use non-devm notifiers
From: Leonard Crestez @ 2019-08-13 5:06 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi
Cc: Artur Świgoń, Jacky Bai, Saravana Kannan, linux-pm,
Krzysztof Kozlowski, Alexandre Bailon, Georgi Djakov,
linux-arm-kernel
The devfreq passive governor registers and unregisters devfreq
transition notifiers on DEVFREQ_GOV_START/GOV_STOP using devm wrappers.
If devfreq itself is registered with devm then a warning is triggered on
rmmod from devm_devfreq_unregister_notifier. Call stack looks like this:
devm_devfreq_unregister_notifier+0x30/0x40
devfreq_passive_event_handler+0x4c/0x88
devfreq_remove_device.part.8+0x6c/0x9c
devm_devfreq_dev_release+0x18/0x20
release_nodes+0x1b0/0x220
devres_release_all+0x78/0x84
device_release_driver_internal+0x100/0x1c0
driver_detach+0x4c/0x90
bus_remove_driver+0x7c/0xd0
driver_unregister+0x2c/0x58
platform_driver_unregister+0x10/0x18
imx_devfreq_platdrv_exit+0x14/0xd40 [imx_devfreq]
This happens because devres_release_all will first remove all the nodes
into a separate todo list so the nested devres_release from
devm_devfreq_unregister_notifier won't find anything.
Fix the warning by calling the non-devm APIS for frequency notification.
Using devm wrappers is not actually useful for a governor anyway: it
relies on the devfreq core to correctly match the GOV_START/GOV_STOP
notifications.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Cc: stable@vger.kernel.org
---
Changes since v1:
* Remove unused variable "dev" and avoid warning
* Added ack and cc stable
Link to v1: https://patchwork.kernel.org/patch/11084541/
drivers/devfreq/governor_passive.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/devfreq/governor_passive.c b/drivers/devfreq/governor_passive.c
index 58308948b863..be6eeab9c814 100644
--- a/drivers/devfreq/governor_passive.c
+++ b/drivers/devfreq/governor_passive.c
@@ -147,11 +147,10 @@ static int devfreq_passive_notifier_call(struct notifier_block *nb,
}
static int devfreq_passive_event_handler(struct devfreq *devfreq,
unsigned int event, void *data)
{
- struct device *dev = devfreq->dev.parent;
struct devfreq_passive_data *p_data
= (struct devfreq_passive_data *)devfreq->data;
struct devfreq *parent = (struct devfreq *)p_data->parent;
struct notifier_block *nb = &p_data->nb;
int ret = 0;
@@ -163,16 +162,16 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq,
case DEVFREQ_GOV_START:
if (!p_data->this)
p_data->this = devfreq;
nb->notifier_call = devfreq_passive_notifier_call;
- ret = devm_devfreq_register_notifier(dev, parent, nb,
+ ret = devfreq_register_notifier(parent, nb,
DEVFREQ_TRANSITION_NOTIFIER);
break;
case DEVFREQ_GOV_STOP:
- devm_devfreq_unregister_notifier(dev, parent, nb,
- DEVFREQ_TRANSITION_NOTIFIER);
+ WARN_ON(devfreq_unregister_notifier(parent, nb,
+ DEVFREQ_TRANSITION_NOTIFIER));
break;
default:
break;
}
--
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: [PATCHv4 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
From: Kishon Vijay Abraham I @ 2019-08-13 4:36 UTC (permalink / raw)
To: Xiaowei Bao, lorenzo.pieralisi, bhelgaas, minghuan.Lian,
mingkai.hu, roy.zang, l.stach, tpiepho, leonard.crestez,
andrew.smirnov, yue.wang, hayashi.kunihiko, dwmw, jonnyc,
linux-pci, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190813025317.48290-1-xiaowei.bao@nxp.com>
On 13/08/19 8:23 AM, Xiaowei Bao wrote:
> The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1
> is 32bit, BAR3 and BAR4 is 64bit, this is determined by hardware,
Do you mean BAR2 instead of BAR3 here?
Thanks
Kishon
> so set the bar_fixed_64bit with 0x14.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> v2:
> - Replace value 0x14 with a macro.
> v3:
> - No change.
> v4:
> - send the patch again with '--to'.
>
> drivers/pci/controller/dwc/pci-layerscape-ep.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> index be61d96..227c33b 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> @@ -44,6 +44,7 @@ static int ls_pcie_establish_link(struct dw_pcie *pci)
> .linkup_notifier = false,
> .msi_capable = true,
> .msix_capable = false,
> + .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> };
>
> static const struct pci_epc_features*
>
_______________________________________________
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 3/7] dma: iop-adma: use correct printk format strings
From: Vinod Koul @ 2019-08-13 4:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Linus Walleij, Russell King, linux-kernel,
Bartosz Golaszewski, soc, linux-i2c, dmaengine, Dan Williams,
linux-arm-kernel
In-Reply-To: <20190809163334.489360-3-arnd@arndb.de>
On 09-08-19, 18:33, Arnd Bergmann wrote:
> When compile-testing on other architectures, we get lots of warnings
> about incorrect format strings, like:
>
> drivers/dma/iop-adma.c: In function 'iop_adma_alloc_slots':
> drivers/dma/iop-adma.c:307:6: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
>
> drivers/dma/iop-adma.c: In function 'iop_adma_prep_dma_memcpy':
> >> drivers/dma/iop-adma.c:518:40: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'size_t {aka long unsigned int}' [-Wformat=]
>
> Use %zu for printing size_t as required, and cast the dma_addr_t
> arguments to 'u64' for printing with %llx. Ideally this should use
> the %pad format string, but that requires an lvalue argument that
> doesn't work here.
Please change title to "dmaengine: iop-adma: use correct printk format strings"
After that:
Acked-by: Vinod Koul <vkoul@kernel.org>
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/dma/iop-adma.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
> index 7857b54770d1..aebdd671651a 100644
> --- a/drivers/dma/iop-adma.c
> +++ b/drivers/dma/iop-adma.c
> @@ -117,9 +117,9 @@ static void __iop_adma_slot_cleanup(struct iop_adma_chan *iop_chan)
> list_for_each_entry_safe(iter, _iter, &iop_chan->chain,
> chain_node) {
> pr_debug("\tcookie: %d slot: %d busy: %d "
> - "this_desc: %#x next_desc: %#x ack: %d\n",
> + "this_desc: %#x next_desc: %#llx ack: %d\n",
> iter->async_tx.cookie, iter->idx, busy,
> - iter->async_tx.phys, iop_desc_get_next_desc(iter),
> + iter->async_tx.phys, (u64)iop_desc_get_next_desc(iter),
> async_tx_test_ack(&iter->async_tx));
> prefetch(_iter);
> prefetch(&_iter->async_tx);
> @@ -307,9 +307,9 @@ iop_adma_alloc_slots(struct iop_adma_chan *iop_chan, int num_slots,
> int i;
> dev_dbg(iop_chan->device->common.dev,
> "allocated slot: %d "
> - "(desc %p phys: %#x) slots_per_op %d\n",
> + "(desc %p phys: %#llx) slots_per_op %d\n",
> iter->idx, iter->hw_desc,
> - iter->async_tx.phys, slots_per_op);
> + (u64)iter->async_tx.phys, slots_per_op);
>
> /* pre-ack all but the last descriptor */
> if (num_slots != slots_per_op)
> @@ -517,7 +517,7 @@ iop_adma_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dma_dest,
> return NULL;
> BUG_ON(len > IOP_ADMA_MAX_BYTE_COUNT);
>
> - dev_dbg(iop_chan->device->common.dev, "%s len: %u\n",
> + dev_dbg(iop_chan->device->common.dev, "%s len: %zu\n",
> __func__, len);
>
> spin_lock_bh(&iop_chan->lock);
> @@ -550,7 +550,7 @@ iop_adma_prep_dma_xor(struct dma_chan *chan, dma_addr_t dma_dest,
> BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT);
>
> dev_dbg(iop_chan->device->common.dev,
> - "%s src_cnt: %d len: %u flags: %lx\n",
> + "%s src_cnt: %d len: %zu flags: %lx\n",
> __func__, src_cnt, len, flags);
>
> spin_lock_bh(&iop_chan->lock);
> @@ -583,7 +583,7 @@ iop_adma_prep_dma_xor_val(struct dma_chan *chan, dma_addr_t *dma_src,
> if (unlikely(!len))
> return NULL;
>
> - dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %u\n",
> + dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %zu\n",
> __func__, src_cnt, len);
>
> spin_lock_bh(&iop_chan->lock);
> @@ -621,7 +621,7 @@ iop_adma_prep_dma_pq(struct dma_chan *chan, dma_addr_t *dst, dma_addr_t *src,
> BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT);
>
> dev_dbg(iop_chan->device->common.dev,
> - "%s src_cnt: %d len: %u flags: %lx\n",
> + "%s src_cnt: %d len: %zu flags: %lx\n",
> __func__, src_cnt, len, flags);
>
> if (dmaf_p_disabled_continue(flags))
> @@ -684,7 +684,7 @@ iop_adma_prep_dma_pq_val(struct dma_chan *chan, dma_addr_t *pq, dma_addr_t *src,
> return NULL;
> BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT);
>
> - dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %u\n",
> + dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %zu\n",
> __func__, src_cnt, len);
>
> spin_lock_bh(&iop_chan->lock);
> --
> 2.20.0
--
~Vinod
_______________________________________________
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/7] dma: iop-adma: include prefetch.h
From: Vinod Koul @ 2019-08-13 4:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: kbuild test robot, linux-gpio, Linus Walleij, Russell King,
linux-kernel, Bartosz Golaszewski, soc, linux-i2c, dmaengine,
Dan Williams, linux-arm-kernel
In-Reply-To: <20190809163334.489360-2-arnd@arndb.de>
On 09-08-19, 18:33, Arnd Bergmann wrote:
> Compile-testing this driver fails on m68k without the
> extra header inclusion.
Please change title to "dmaengine: iop-adma: include prefetch.h"
After that:
Acked-by: Vinod Koul <vkoul@kernel.org>
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/dma/iop-adma.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
> index c6c0143670d9..7857b54770d1 100644
> --- a/drivers/dma/iop-adma.c
> +++ b/drivers/dma/iop-adma.c
> @@ -16,6 +16,7 @@
> #include <linux/spinlock.h>
> #include <linux/interrupt.h>
> #include <linux/platform_device.h>
> +#include <linux/prefetch.h>
> #include <linux/memory.h>
> #include <linux/ioport.h>
> #include <linux/raid/pq.h>
> --
> 2.20.0
--
~Vinod
_______________________________________________
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] PM / devfreq: passive: Use non-devm notifiers
From: Chanwoo Choi @ 2019-08-13 4:23 UTC (permalink / raw)
To: Leonard Crestez, MyungJoo Ham, Kyungmin Park
Cc: Artur Świgoń, Geert Uytterhoeven, Saravana Kannan,
Rafael J. Wysocki, Greg Kroah-Hartman, Bartosz Golaszewski,
linux-pm, Krzysztof Kozlowski, Lukasz Luba, Alexandre Bailon,
cpgs (cpgs@samsung.com), Bjorn Andersson, linux-arm-kernel
In-Reply-To: <38b77bb80d12aa788d4e234e399780a27dcd9e9f.1565282993.git.leonard.crestez@nxp.com>
Hi,
On 19. 8. 9. 오전 1:54, Leonard Crestez wrote:
> The devfreq passive governor registers and unregisters devfreq
> transition notifiers on DEVFREQ_GOV_START/GOV_STOP using devm wrappers.
>
> If devfreq itself is registered with devm then a warning is triggered on
> rmmod from devm_devfreq_unregister_notifier. Call stack looks like this:
>
> devm_devfreq_unregister_notifier+0x30/0x40
> devfreq_passive_event_handler+0x4c/0x88
> devfreq_remove_device.part.8+0x6c/0x9c
> devm_devfreq_dev_release+0x18/0x20
> release_nodes+0x1b0/0x220
> devres_release_all+0x78/0x84
> device_release_driver_internal+0x100/0x1c0
> driver_detach+0x4c/0x90
> bus_remove_driver+0x7c/0xd0
> driver_unregister+0x2c/0x58
> platform_driver_unregister+0x10/0x18
> imx_devfreq_platdrv_exit+0x14/0xd40 [imx_devfreq]
>
> This happens because devres_release_all will first remove all the nodes
> into a separate todo list so the nested devres_release from
> devm_devfreq_unregister_notifier won't find anything.
>
> Fix the warning by calling the non-devm APIS for frequency notification.
> Using devm wrappers is not actually useful for a governor anyway: it
> relies on the devfreq core to correctly match the GOV_START/GOV_STOP
> notifications.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>
> ---
> drivers/devfreq/governor_passive.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> The only current user of passive governor is exynos-bus; does rmmod work
> for you? Maybe I'm missing something.
>
> It also seems that no attempt is made to increase the ref count of
> the passive "parent" so in theory devices can be removed while still
> referenced. However that would be a separate issue.
>
> diff --git a/drivers/devfreq/governor_passive.c b/drivers/devfreq/governor_passive.c
> index 58308948b863..da485477065c 100644
> --- a/drivers/devfreq/governor_passive.c
> +++ b/drivers/devfreq/governor_passive.c
> @@ -163,16 +163,16 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq,
> case DEVFREQ_GOV_START:
> if (!p_data->this)
> p_data->this = devfreq;
>
> nb->notifier_call = devfreq_passive_notifier_call;
> - ret = devm_devfreq_register_notifier(dev, parent, nb,
> + ret = devfreq_register_notifier(parent, nb,
> DEVFREQ_TRANSITION_NOTIFIER);
> break;
> case DEVFREQ_GOV_STOP:
> - devm_devfreq_unregister_notifier(dev, parent, nb,
> - DEVFREQ_TRANSITION_NOTIFIER);
> + WARN_ON(devfreq_unregister_notifier(parent, nb,
> + DEVFREQ_TRANSITION_NOTIFIER));
> break;
> default:
> break;
> }
>
>
Looks good to me. But, you have to add the following fixes tag
and send it to stable mailing list to fix the bug.
- Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
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