* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Santosh Shilimkar @ 2014-01-31 23:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131221553.GF2502@saruman.home>
On Friday 31 January 2014 05:15 PM, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jan 31, 2014 at 02:20:48PM -0500, Santosh Shilimkar wrote:
>
> [ snip ]
>
>>> note that because of pm_runtime_set_active() that first
>>> pm_runtime_get_sync() in probe() will simply increase the reference
>>> counter without calling my ->runtime_resume() callback, which is exactly
>>> what we want, as that would completely avoid situations of bad context
>>> being restored because of that initial pm_runtime_get_sync().
>>>
>> Thanks for making your point bit clear.
>
> no problem.
>
>>> Then, we can even make pm_runtime completely async easily, because
>>> clk_prepare() was called only on probe() (or before it, for that
>>> matter).
>>>
>>> Bottomline is, if you can guarantee me that clk_get(), clk_prepare(),
>>> clk_enable() and pm_runtime_set_active() will be called properly before
>>> my probe, i'll be more than happy to comply with your request above as
>>> that will greatly simplify my driver.
>>>
>> Which is the case at least I see on Keystone. And hence the patch from
>
> I was going over pm_domain.c and drivers/base/power/clock_ops.c and none
> of them enable pm_runtime or make sure pm_runtime_set_active() is
> called.
>
>> Grygorii works. I also noticed your proposal for wider platform to
>> enforce above behavior which seems to be a good idea.
>
> it'll take months to stabilize though ;-)
>
>>> Just make, also, that if this clock is shared between dwc3-keystone
>>> wrapper and dwc3 core, you clk_get() on both driver's probe.
>>>
>> I understand. In summary, whichever patch you pick(yours) or Grygorii's,
>> its completely safe to remove the clock handling from Keystone USB driver.
>
> alright, since I can't really test, I'll take this as a true statement.
> If there are any regressions I can blame you, hehehe.
>
No problem... :D
Grygorii patch has been working well so all good with that
^ permalink raw reply
* [PATCH] ARM: keystone: config: fix build warning when CONFIG_DMADEVICES is not set
From: Olof Johansson @ 2014-01-31 23:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389278226-23071-1-git-send-email-santosh.shilimkar@ti.com>
On Thu, Jan 09, 2014 at 09:37:06AM -0500, Santosh Shilimkar wrote:
> From: Grygorii Strashko <grygorii.strashko@ti.com>
>
> Drop automatic selection of TI_EDMA from Keystone Kconfig file,
> as it produces build warning in case if CONFIG_DMADEVICES is not set:
>
> warning: (ARCH_KEYSTONE) selects TI_EDMA which has unmet direct dependencies (DMADEVICES && (ARCH_DAVINCI || ARCH_OMAP || ARCH_KEYSTONE))
>
> Instead enable TI EDMA support from defconfig.
>
> Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
>
> Kevin, Olof, Arnd,
>
> Please let me know if you can pick this patch in 3.14 arm-soc
> queue or you prefer a pull request for the same. It applies against
> 'next/soc' cleanly.
Seems like it was missed, I've applied it to fixes now.
-Olof
^ permalink raw reply
* [PATCH v2] MAINTAINERS: ARM: SiRF: use regex patterns to involve all SiRF drivers
From: Olof Johansson @ 2014-01-31 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1388719453-12447-1-git-send-email-21cnbao@gmail.com>
On Fri, Jan 03, 2014 at 11:24:13AM +0800, Barry Song wrote:
> From: Barry Song <Baohua.Song@csr.com>
>
> instead of listing drivers one by one, use regex patterns to involve all
> SiRF drivers directly.
> this also adds sirf UART and watchdog drivers automatically from:
> drivers/tty/serial/sirfsoc_uart.*
> drivers/watchdog/sirfsoc_wdt.c
>
> Cc: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> Cc: Wim Van Sebroeck <wim@iguana.be>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
Applied to fixes for 3.14.
-Olof
^ permalink raw reply
* [GIT PULL] Xilinx Zynq dt fixes for v3.14
From: Olof Johansson @ 2014-01-31 22:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA7976.7030709@monstr.eu>
On Thu, Jan 30, 2014 at 05:10:30PM +0100, Michal Simek wrote:
> Hi guys,
>
> please consider to queue this patch to 3.14 because it enables Arasan
> SDHCI driver which has been merged to the tree. It took for a while
> to get it to the mainline that's why I didn't push this patch
> in regular arm-soc merge window. I was talking about it
> with Kevin some weeks ago.
>
> There will be one more patch which I have discussed with Russell but
> I will send it out for reviewed first.
> https://lkml.org/lkml/2014/1/27/212
I ended up cherry-picking the patch instead, since your base is different from
what we have today. But the patch has been applied to our fixes branch now and
will be sent up.
-Olof
^ permalink raw reply
* [PATCH] ARM: hisi: don't select SMP
From: Olof Johansson @ 2014-01-31 22:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391205990-22506-1-git-send-email-robherring2@gmail.com>
On Fri, Jan 31, 2014 at 04:06:30PM -0600, Rob Herring wrote:
> From: Rob Herring <robh@kernel.org>
>
> SMP is a user configurable option, not a hardware feature and should not
> be selected.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
Yep, you're right. applied to fixes.
-Olof
^ permalink raw reply
* [PATCHv3] arm64: Add CONFIG_CC_STACKPROTECTOR
From: Kees Cook @ 2014-01-31 22:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391115944-10183-1-git-send-email-lauraa@codeaurora.org>
On Thu, Jan 30, 2014 at 1:05 PM, Laura Abbott <lauraa@codeaurora.org> wrote:
> arm64 currently lacks support for -fstack-protector. Add
> similar functionality to arm to detect stack corruption.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Thanks!
Acked-by: Kees Cook <keescook@chromium.org>
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* [PATCH 3/3] spi: switch to devm_spi_alloc_master
From: Maxime Ripard @ 2014-01-31 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EBCCCD.301@wwwdotorg.org>
On Fri, Jan 31, 2014 at 09:18:21AM -0700, Stephen Warren wrote:
> On 01/31/2014 03:23 AM, Maxime Ripard wrote:
> > Make the existing users of devm_spi_register_master use the
> > devm_spi_alloc_master function to avoid leaking memory.
>
> > diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
>
> > @@ -1087,14 +1085,13 @@ static int tegra_spi_probe(struct platform_device *pdev)
> > if (ret < 0) {
> > dev_err(&pdev->dev, "Failed to register ISR for IRQ %d\n",
> > tspi->irq);
> > - goto exit_free_master;
> > + return ret;
> > }
> >
> > tspi->clk = devm_clk_get(&pdev->dev, "spi");
> > if (IS_ERR(tspi->clk)) {
> > dev_err(&pdev->dev, "can not get clock\n");
> > - ret = PTR_ERR(tspi->clk);
> > - goto exit_free_irq;
> > + return PTR_ERR(tspi->clk);
> > }
> >
> > tspi->max_buf_size = SPI_FIFO_DEPTH << 2;
> > @@ -1152,8 +1149,6 @@ exit_rx_dma_free:
> > tegra_spi_deinit_dma_param(tspi, true);
> > exit_free_irq:
> > free_irq(spi_irq, tspi);
> > -exit_free_master:
> > - spi_master_put(master);
> > return ret;
>
> Doesn't that s/goto exit_free_irq/return/ leak spi_irq? It's only OK to
> replace goto free_master with a direct return.
>
> The other two Tegra drivers don't seem to have this problem.
Ah, right. Thanks for noticing.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/282a6769/attachment.sig>
^ permalink raw reply
* [PATCH v3 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
From: Maxime Ripard @ 2014-01-31 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131124809.GE22609@sirena.org.uk>
On Fri, Jan 31, 2014 at 12:48:09PM +0000, Mark Brown wrote:
> On Fri, Jan 31, 2014 at 11:55:50AM +0100, Maxime Ripard wrote:
>
> > + master = devm_spi_alloc_master(&pdev->dev, sizeof(struct sun6i_spi));
> > + if (!master) {
> > + dev_err(&pdev->dev, "Unable to allocate SPI Master\n");
> > + return -ENOMEM;
> > + }
>
> This now depends on your other series which as I said doesn't look like
> the best approach.
Indeed, I forgot to mention it in the cover letter. My bad.
>
> > + pm_runtime_enable(&pdev->dev);
> > + if (!pm_runtime_enabled(&pdev->dev)) {
> > + ret = sun6i_spi_runtime_resume(&pdev->dev);
> > + if (ret) {
> > + dev_err(&pdev->dev, "Couldn't resume the device\n");
> > + return ret;
> > + }
> > + }
>
> No, as discussed don't do this - notice how other drivers aren't written
> this way either. Like I said leave the device powered on startup and
> then let it be idled by runtime PM.
Well, some SPI drivers are actually written like that (all the tegra
SPI drivers for example). It's not an excuse, but waking up the device
only to put it back in suspend right away seems kind of
inefficient. Plus, the pm_runtime_idle callback you suggested are
actually calling runtime_idle, while we want to call runtime_suspend.
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/3f2c9212/attachment.sig>
^ permalink raw reply
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Felipe Balbi @ 2014-01-31 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EBF790.3090407@ti.com>
Hi,
On Fri, Jan 31, 2014 at 02:20:48PM -0500, Santosh Shilimkar wrote:
[ snip ]
> > note that because of pm_runtime_set_active() that first
> > pm_runtime_get_sync() in probe() will simply increase the reference
> > counter without calling my ->runtime_resume() callback, which is exactly
> > what we want, as that would completely avoid situations of bad context
> > being restored because of that initial pm_runtime_get_sync().
> >
> Thanks for making your point bit clear.
no problem.
> > Then, we can even make pm_runtime completely async easily, because
> > clk_prepare() was called only on probe() (or before it, for that
> > matter).
> >
> > Bottomline is, if you can guarantee me that clk_get(), clk_prepare(),
> > clk_enable() and pm_runtime_set_active() will be called properly before
> > my probe, i'll be more than happy to comply with your request above as
> > that will greatly simplify my driver.
> >
> Which is the case at least I see on Keystone. And hence the patch from
I was going over pm_domain.c and drivers/base/power/clock_ops.c and none
of them enable pm_runtime or make sure pm_runtime_set_active() is
called.
> Grygorii works. I also noticed your proposal for wider platform to
> enforce above behavior which seems to be a good idea.
it'll take months to stabilize though ;-)
> > Just make, also, that if this clock is shared between dwc3-keystone
> > wrapper and dwc3 core, you clk_get() on both driver's probe.
> >
> I understand. In summary, whichever patch you pick(yours) or Grygorii's,
> its completely safe to remove the clock handling from Keystone USB driver.
alright, since I can't really test, I'll take this as a true statement.
If there are any regressions I can blame you, hehehe.
cheers
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/8ff6eefd/attachment.sig>
^ permalink raw reply
* [PATCH v7 0/7] ARM: rockchip: add smp functionality
From: Rob Herring @ 2014-01-31 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13010296.nzTT2PqdSR@phil>
On Fri, Jan 31, 2014 at 4:03 PM, Heiko St?bner <heiko@sntech.de> wrote:
> On Monday, 20. January 2014 16:41:43 Heiko St?bner wrote:
>> This series enables the use of the additional cores on Rockchip
>> Cortex-A9 SoCs.
>
> So, two weeks without any general complaints, but I guess part of the more
> general patches could use an ack.
>
> Going forward, what would be best way to merge them?
> As one pull request to arm-soc, or for example splitting them into the first
> three patches going through the misc tree and the rockchip specific stuff going
> through arm-soc? Or something else altogether?
>
>
>> Heiko Stuebner (7):
>> of: add functions to count number of elements in a property
>
> One of the intermediate versions of this patch got a
> Reviewed-by: Mark Rutland <mark.rutland@arm.com> .
> Mark, is this still true for this variant addressing some additional wished
> from Rob?
>
> And this final version got a "Looks good" from Rob Herring in the original
> thread, but a more formal "ack" might be nice :-) .
Acked-by: Rob Herring <robh@kernel.org>
Rob
>
>
>> dt-bindings: sram: describe option to reserve parts of the memory
>> misc: sram: implement mmio-sram-reserved option
>
> Philipp, you acked an intermediate version, and this v7 now should also
> contain the two separate loops (1st gathering data and 2nd creating the pool
> parts) you asked for.
>
> Could I persuade you to take a look again?
>
>
> Thanks
> Heiko
>
>
>> ARM: rockchip: add snoop-control-unit
>> ARM: rockchip: add sram dt nodes and documentation
>> ARM: rockchip: add power-management-unit
>> ARM: rockchip: add smp bringup code
>>
>> .../devicetree/bindings/arm/rockchip/pmu.txt | 16 ++
>> .../devicetree/bindings/arm/rockchip/smp-sram.txt | 23 +++
>> Documentation/devicetree/bindings/misc/sram.txt | 8 +
>> arch/arm/boot/dts/rk3066a.dtsi | 6 +
>> arch/arm/boot/dts/rk3188.dtsi | 6 +
>> arch/arm/boot/dts/rk3xxx.dtsi | 10 +
>> arch/arm/mach-rockchip/Kconfig | 1 +
>> arch/arm/mach-rockchip/Makefile | 1 +
>> arch/arm/mach-rockchip/core.h | 22 +++
>> arch/arm/mach-rockchip/headsmp.S | 30 +++
>> arch/arm/mach-rockchip/platsmp.c | 208
>> ++++++++++++++++++++ arch/arm/mach-rockchip/rockchip.c |
>> 2 +
>> drivers/misc/sram.c | 121 +++++++++++-
>> drivers/of/base.c | 32 +++
>> include/linux/of.h | 76 +++++++
>> 15 files changed, 554 insertions(+), 8 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt create mode
>> 100644 arch/arm/mach-rockchip/core.h
>> create mode 100644 arch/arm/mach-rockchip/headsmp.S
>> create mode 100644 arch/arm/mach-rockchip/platsmp.c
>
^ permalink raw reply
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Felipe Balbi @ 2014-01-31 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1401311608590.12368-100000@netrider.rowland.org>
On Fri, Jan 31, 2014 at 04:13:19PM -0500, Alan Stern wrote:
> On Fri, 31 Jan 2014, Felipe Balbi wrote:
>
> > probe()
> > {
> > ...
> >
> > clk_get(dev, "fck");
> > clk_prepare(clk);
> > clk_enable(clk);
> > pm_runtime_set_active(dev);
> > pm_runtime_enable(dev);
> > pm_runtime_get_sync(dev);
> > ...
> > }
>
> > note that because of pm_runtime_set_active() that first
> > pm_runtime_get_sync() in probe() will simply increase the reference
> > counter without calling my ->runtime_resume() callback, which is exactly
> > what we want, as that would completely avoid situations of bad context
> > being restored because of that initial pm_runtime_get_sync().
>
> Very minor note... A slightly better way to do the same thing is:
>
> pm_runtime_set_active(dev);
> pm_runtime_get_noresume(dev);
> pm_runtime_enable(dev);
>
> The get_noresume says that you want to increment the usage counter
> without performing any callbacks, and doing it before the
> pm_runtime_enable avoids any window during which a runtime suspend
> might somehow occur.
aha, that's perfect :-) Thanks Alan.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/f29ba556/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: hisi: don't select SMP
From: Rob Herring @ 2014-01-31 22:06 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <robh@kernel.org>
SMP is a user configurable option, not a hardware feature and should not
be selected.
Signed-off-by: Rob Herring <robh@kernel.org>
---
arch/arm/mach-hisi/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-hisi/Kconfig b/arch/arm/mach-hisi/Kconfig
index 018ad67..8f4649b 100644
--- a/arch/arm/mach-hisi/Kconfig
+++ b/arch/arm/mach-hisi/Kconfig
@@ -12,6 +12,5 @@ config ARCH_HI3xxx
select HAVE_SMP
select PINCTRL
select PINCTRL_SINGLE
- select SMP
help
Support for Hisilicon Hi36xx/Hi37xx processor family
--
1.8.3.2
^ permalink raw reply related
* [PATCH v7 0/7] ARM: rockchip: add smp functionality
From: Heiko Stübner @ 2014-01-31 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4970034.fqvMoHdOyd@phil>
On Monday, 20. January 2014 16:41:43 Heiko St?bner wrote:
> This series enables the use of the additional cores on Rockchip
> Cortex-A9 SoCs.
So, two weeks without any general complaints, but I guess part of the more
general patches could use an ack.
Going forward, what would be best way to merge them?
As one pull request to arm-soc, or for example splitting them into the first
three patches going through the misc tree and the rockchip specific stuff going
through arm-soc? Or something else altogether?
> Heiko Stuebner (7):
> of: add functions to count number of elements in a property
One of the intermediate versions of this patch got a
Reviewed-by: Mark Rutland <mark.rutland@arm.com> .
Mark, is this still true for this variant addressing some additional wished
from Rob?
And this final version got a "Looks good" from Rob Herring in the original
thread, but a more formal "ack" might be nice :-) .
> dt-bindings: sram: describe option to reserve parts of the memory
> misc: sram: implement mmio-sram-reserved option
Philipp, you acked an intermediate version, and this v7 now should also
contain the two separate loops (1st gathering data and 2nd creating the pool
parts) you asked for.
Could I persuade you to take a look again?
Thanks
Heiko
> ARM: rockchip: add snoop-control-unit
> ARM: rockchip: add sram dt nodes and documentation
> ARM: rockchip: add power-management-unit
> ARM: rockchip: add smp bringup code
>
> .../devicetree/bindings/arm/rockchip/pmu.txt | 16 ++
> .../devicetree/bindings/arm/rockchip/smp-sram.txt | 23 +++
> Documentation/devicetree/bindings/misc/sram.txt | 8 +
> arch/arm/boot/dts/rk3066a.dtsi | 6 +
> arch/arm/boot/dts/rk3188.dtsi | 6 +
> arch/arm/boot/dts/rk3xxx.dtsi | 10 +
> arch/arm/mach-rockchip/Kconfig | 1 +
> arch/arm/mach-rockchip/Makefile | 1 +
> arch/arm/mach-rockchip/core.h | 22 +++
> arch/arm/mach-rockchip/headsmp.S | 30 +++
> arch/arm/mach-rockchip/platsmp.c | 208
> ++++++++++++++++++++ arch/arm/mach-rockchip/rockchip.c |
> 2 +
> drivers/misc/sram.c | 121 +++++++++++-
> drivers/of/base.c | 32 +++
> include/linux/of.h | 76 +++++++
> 15 files changed, 554 insertions(+), 8 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt create mode
> 100644 arch/arm/mach-rockchip/core.h
> create mode 100644 arch/arm/mach-rockchip/headsmp.S
> create mode 100644 arch/arm/mach-rockchip/platsmp.c
^ permalink raw reply
* [RFC/PATCH] base: platform: add generic clock handling for platform-bus
From: Felipe Balbi @ 2014-01-31 21:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1401311614100.12368-100000@netrider.rowland.org>
Hi,
On Fri, Jan 31, 2014 at 04:34:27PM -0500, Alan Stern wrote:
> On Fri, 31 Jan 2014, Felipe Balbi wrote:
>
> > Still TODO a commit log. Not for merging!!!!!
> >
> > NYET-Signed-off-by: Felipe Balbi <balbi@ti.com>
> > ---
> >
> > This patch is an idea I've had recently in order to combine several different
> > PM implementations into the platform-bus.
> >
> > This patch is bare minimum for platforms which need to handle functional and
> > interface clocks but the whole thing is made optional.
> >
> > Note that this patch makes sure that by the time a platform_driver's probe is
> > called, we already have clocks enabled and pm_runtime_set_active() has been
> > called, thus making sure that a device driver's pm_runtime_get_sync() will
> > solely increase the pm usage counter.
> >
> > I have *NOT* tested this anywhere *YET*, but I suppose it shouldn't cause any
> > issues since the clock API has ref counting too.
> >
> > Would really like to get some review from several folks involved with ARM SoC
> > PM so that's the reason for the wide audience. If I have missed anybody, please
> > add them to Cc.
> >
> > As mentioned above, this is *NOT* meant for merging, but serves as a starting
> > point for discussing some convergence of several PM domain implementations on
> > different arch/arm/mach-* directories.
>
> You might want to copy the runtime-PM approach used by the PCI
> subsystem. It works like this:
>
> The core invokes a driver's probe routine with runtime PM
> enabled, the device in the ACTIVE state, and the usage counter
> incremented by 1.
>
> If the driver wants to support runtime PM, the probe routine
> can call pm_runtime_put_noidle.
>
> The core does pm_runtime_get_sync before invoking the driver's
> remove routine. At this point a runtime-PM-aware driver whould
> call pm_runtime_get_noresume, to balance the _put during probe.
>
> After invoking the remove routine, the core does a put_noidle
> (to balance the get_sync) and a final put_sync (to balance the
> increment before probe and to leave the device at low power.)
>
> A nice consequence is that everything is transparent for drivers that
> don't support runtime PM. The usage counter remains > 0 the entire
> time the driver is bound.
>
> Conversely, drivers that do support runtime PM merely have to add one
> call during probe and one during remove.
>
> There is one tricky aspect to all this. The driver core sets the
> dev->driver field before calling the subsystem core's probe routine.
> As a result, the subsystem has to be very careful about performing
> runtime PM before invoking the driver's probe routine. Otherwise you
> will end up calling the driver's runtime_resume callback before the
> driver's probe! (And of course, the same problem exists in reverse
> during remove.)
I can, certainly, do that and that would, most likely, simplify a whole
bunch of drivers. But that change, I suppose, would be a whole lot more
invasive. I'll spend some time studying PCI pm_runtime support, thanks
for the tip.
cheers
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/8008aa52/attachment-0001.sig>
^ permalink raw reply
* [RFC/PATCH] base: platform: add generic clock handling for platform-bus
From: Alan Stern @ 2014-01-31 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391191965-31102-1-git-send-email-balbi@ti.com>
On Fri, 31 Jan 2014, Felipe Balbi wrote:
> Still TODO a commit log. Not for merging!!!!!
>
> NYET-Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>
> This patch is an idea I've had recently in order to combine several different
> PM implementations into the platform-bus.
>
> This patch is bare minimum for platforms which need to handle functional and
> interface clocks but the whole thing is made optional.
>
> Note that this patch makes sure that by the time a platform_driver's probe is
> called, we already have clocks enabled and pm_runtime_set_active() has been
> called, thus making sure that a device driver's pm_runtime_get_sync() will
> solely increase the pm usage counter.
>
> I have *NOT* tested this anywhere *YET*, but I suppose it shouldn't cause any
> issues since the clock API has ref counting too.
>
> Would really like to get some review from several folks involved with ARM SoC
> PM so that's the reason for the wide audience. If I have missed anybody, please
> add them to Cc.
>
> As mentioned above, this is *NOT* meant for merging, but serves as a starting
> point for discussing some convergence of several PM domain implementations on
> different arch/arm/mach-* directories.
You might want to copy the runtime-PM approach used by the PCI
subsystem. It works like this:
The core invokes a driver's probe routine with runtime PM
enabled, the device in the ACTIVE state, and the usage counter
incremented by 1.
If the driver wants to support runtime PM, the probe routine
can call pm_runtime_put_noidle.
The core does pm_runtime_get_sync before invoking the driver's
remove routine. At this point a runtime-PM-aware driver whould
call pm_runtime_get_noresume, to balance the _put during probe.
After invoking the remove routine, the core does a put_noidle
(to balance the get_sync) and a final put_sync (to balance the
increment before probe and to leave the device at low power.)
A nice consequence is that everything is transparent for drivers that
don't support runtime PM. The usage counter remains > 0 the entire
time the driver is bound.
Conversely, drivers that do support runtime PM merely have to add one
call during probe and one during remove.
There is one tricky aspect to all this. The driver core sets the
dev->driver field before calling the subsystem core's probe routine.
As a result, the subsystem has to be very careful about performing
runtime PM before invoking the driver's probe routine. Otherwise you
will end up calling the driver's runtime_resume callback before the
driver's probe! (And of course, the same problem exists in reverse
during remove.)
Alan Stern
^ permalink raw reply
* [RFC/PATCH] base: platform: add generic clock handling for platform-bus
From: Felipe Balbi @ 2014-01-31 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131200434.GR27282@n2100.arm.linux.org.uk>
Hi,
On Fri, Jan 31, 2014 at 08:04:35PM +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 31, 2014 at 12:12:45PM -0600, Felipe Balbi wrote:
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index 3a94b79..86aeb5b 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -484,6 +484,21 @@ static int platform_drv_probe(struct device *_dev)
> > if (ACPI_HANDLE(_dev))
> > acpi_dev_pm_attach(_dev, true);
> >
> > + dev->fck = devm_clk_get(_dev, "fck");
> > + dev->ick = devm_clk_get(_dev, "ick");
> > +
> > + if (!IS_ERR(dev->fck))
> > + clk_prepare_enable(dev->fck);
> > + else
> > + dev->fck = NULL;
> > +
> > + if (!IS_ERR(dev->ick))
> > + clk_prepare_enable(dev->ick);
> > + else
> > + dev->ick = NULL;
>
> If people are going to continue doing this (converting error values to
> NULL) can we please have a check in devm_clk_get() which prevents it
> returning NULL if the implementation happens to do so?
>
> It's either that or we force all users to conform to the API which
> specifies that the error values are defined by IS_ERR() returning
> true and everything else must be considered as a potential valid return.
The idea here was just to avoid IS_ERR() checks every time we want to
enable/disable a clock since clk API already copes with NULL pointers.
This also helps with the fact that platform_bus is also used with
platforms which don't have (or otherwise don't need) any clock control
whatsoever, thus made it optional.
If everybody prefers duplication of IS_ERR() all over the place, that's
fine too.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/af65712a/attachment.sig>
^ permalink raw reply
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Alan Stern @ 2014-01-31 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131164534.GL20736@saruman.home>
On Fri, 31 Jan 2014, Felipe Balbi wrote:
> probe()
> {
> ...
>
> clk_get(dev, "fck");
> clk_prepare(clk);
> clk_enable(clk);
> pm_runtime_set_active(dev);
> pm_runtime_enable(dev);
> pm_runtime_get_sync(dev);
> ...
> }
> note that because of pm_runtime_set_active() that first
> pm_runtime_get_sync() in probe() will simply increase the reference
> counter without calling my ->runtime_resume() callback, which is exactly
> what we want, as that would completely avoid situations of bad context
> being restored because of that initial pm_runtime_get_sync().
Very minor note... A slightly better way to do the same thing is:
pm_runtime_set_active(dev);
pm_runtime_get_noresume(dev);
pm_runtime_enable(dev);
The get_noresume says that you want to increment the usage counter
without performing any callbacks, and doing it before the
pm_runtime_enable avoids any window during which a runtime suspend
might somehow occur.
Alan Stern
^ permalink raw reply
* NFS client broken in Linus' tip
From: Trond Myklebust @ 2014-01-31 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130153812.GA15937@n2100.arm.linux.org.uk>
On Thu, 2014-01-30 at 15:38 +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 30, 2014 at 06:32:08AM -0800, Christoph Hellwig wrote:
> > On Thu, Jan 30, 2014 at 02:27:52PM +0000, Russell King - ARM Linux wrote:
> > > Yes and no. I still end up with an empty /etc/mtab, but the file now
> > > exists. However, I can create and echo data into /etc/mtab, but it seems
> > > that can't happen at boot time.
> >
> > Odd. Can you disable CONFIG_NFSD_V3_ACL for now to isolate the issue?
>
> Unfortunately, that results in some problem at boot time, which
> ultimately ends up with the other three CPUs being stopped, and
> hence the original reason scrolls off the screen before it can be
> read... even at 1920p.
>
Hi Russell,
The following patch fixes the issue for me.
Cheers
Trond
8<-------------------------------------------------------------
>From 59bc20fe862bd85fcad61427e8669603e789d163 Mon Sep 17 00:00:00 2001
From: Trond Myklebust <trond.myklebust@primarydata.com>
Date: Fri, 31 Jan 2014 14:25:19 -0500
Subject: [PATCH] fs: get_acl() must be allowed to return EOPNOTSUPP
posix_acl_xattr_get requires get_acl() to return EOPNOTSUPP if the
filesystem cannot support acls. This is needed for NFS, which can't
know whether or not the server supports acls until it tries to get/set
one.
This patch converts posix_acl_chmod and posix_acl_create to deal with
EOPNOTSUPP return values from get_acl().
Reported-by: Russell King <linux@arm.linux.org.uk>
Link: http://lkml.kernel.org/r/20140130140834.GW15937 at n2100.arm.linux.org.uk
Cc: Christoph Hellwig <hch@lst.de>
Cc: Al Viro viro at zeniv.linux.org.uk>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
---
fs/posix_acl.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/fs/posix_acl.c b/fs/posix_acl.c
index 38bae5a0ea25..11c54fd51e16 100644
--- a/fs/posix_acl.c
+++ b/fs/posix_acl.c
@@ -521,8 +521,11 @@ posix_acl_chmod(struct inode *inode, umode_t mode)
return -EOPNOTSUPP;
acl = get_acl(inode, ACL_TYPE_ACCESS);
- if (IS_ERR_OR_NULL(acl))
+ if (IS_ERR_OR_NULL(acl)) {
+ if (acl == ERR_PTR(-EOPNOTSUPP))
+ return 0;
return PTR_ERR(acl);
+ }
ret = __posix_acl_chmod(&acl, GFP_KERNEL, mode);
if (ret)
@@ -544,14 +547,15 @@ posix_acl_create(struct inode *dir, umode_t *mode,
goto no_acl;
p = get_acl(dir, ACL_TYPE_DEFAULT);
- if (IS_ERR(p))
+ if (IS_ERR(p)) {
+ if (p == ERR_PTR(-EOPNOTSUPP))
+ goto apply_umask;
return PTR_ERR(p);
-
- if (!p) {
- *mode &= ~current_umask();
- goto no_acl;
}
+ if (!p)
+ goto apply_umask;
+
*acl = posix_acl_clone(p, GFP_NOFS);
if (!*acl)
return -ENOMEM;
@@ -575,6 +579,8 @@ posix_acl_create(struct inode *dir, umode_t *mode,
}
return 0;
+apply_umask:
+ *mode &= ~current_umask();
no_acl:
*default_acl = NULL;
*acl = NULL;
--
1.8.5.3
--
Trond Myklebust
Linux NFS client maintainer
^ permalink raw reply related
* [PATCH 1/4] ARM: STi: add stid127 soc support
From: Arnd Bergmann @ 2014-01-31 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EB96BB.6070800@st.com>
On Friday 31 January 2014, srinivas kandagatla wrote:
> > Sorry if I missed the initial review, but can you explain
> > why this is needed to start with?
>
> On ST SoCs the default value for L2 AUX_CTRL register is 0x0, so we set
> the way-size explicit here.
Unfortunately, we keep going back and forth on the L2 cache controller
setup between "it should work automatically" and "we don't want to
have configuration data in DT", where my personal opinion is that
the first one is more important here.
Now, there are a couple of properties that are defined in
Documentation/devicetree/bindings/arm/l2cc.txt to let some of the
things get set up automatically already. Can you check which bits
are missing there, if any? Are they better described as "configuration"
or "hardware" settings?
Arnd
^ permalink raw reply
* [PATCH 2/4] arm: qcom: Split Qualcomm support into legacy and multiplatform
From: Rob Herring @ 2014-01-31 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391107002-21470-3-git-send-email-galak@codeaurora.org>
On Thu, Jan 30, 2014 at 12:36 PM, Kumar Gala <galak@codeaurora.org> wrote:
> Introduce a new mach-qcom that will support SoCs that intend to be
> multiplatform compatiable while keeping mach-msm to legacy SoC/board
> support that will not transition over to multiplatform.
>
> As part of this, we move support for MSM8X60, MSM8960 and MSM8974 over
> to mach-qcom.
>
> Signed-off-by: Kumar Gala <galak@codeaurora.org>
> ---
[snip]
> diff --git a/arch/arm/mach-qcom/Kconfig b/arch/arm/mach-qcom/Kconfig
> new file mode 100644
> index 0000000..8830431
> --- /dev/null
> +++ b/arch/arm/mach-qcom/Kconfig
> @@ -0,0 +1,34 @@
> +config ARCH_QCOM
> + bool "Qualcomm Support" if ARCH_MULTI_V7
> + select ARCH_REQUIRE_GPIOLIB
> + select CLKSRC_OF
> + select GENERIC_CLOCKEVENTS
> + select ARM_GIC
> + select CPU_V7
CPU_V7 is already selected by MULTI_V7.
[snip]
> diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-qcom/smp.c
> similarity index 97%
> rename from arch/arm/mach-msm/platsmp.c
> rename to arch/arm/mach-qcom/smp.c
> index 42eb6b7..28364cb 100644
> --- a/arch/arm/mach-msm/platsmp.c
> +++ b/arch/arm/mach-qcom/smp.c
> @@ -2,6 +2,7 @@
> * Copyright (C) 2002 ARM Ltd.
> * All Rights Reserved
> * Copyright (c) 2010, Code Aurora Forum. All rights reserved.
> + * Copyright (c) 2014 The Linux Foundation. All rights reserved.
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> @@ -20,7 +21,6 @@
> #include <asm/smp_plat.h>
>
> #include "scm-boot.h"
> -#include "common.h"
>
> #define VDD_SC1_ARRAY_CLAMP_GFS_CTL 0x35a0
> #define SCSS_CPU1CORE_RESET 0x2d80
> @@ -48,6 +48,15 @@ extern void secondary_startup(void);
>
> static DEFINE_SPINLOCK(boot_lock);
>
> +static void __ref msm_cpu_die(unsigned int cpu)
> +{
> +
> + asm("wfi"
> + :
> + :
> + : "memory", "cc");
> +}
I realize this is just a move, but there is a wfi() macro that can be
used here instead.
Rob
^ permalink raw reply
* [RFC/PATCH] base: platform: add generic clock handling for platform-bus
From: Russell King - ARM Linux @ 2014-01-31 20:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391191965-31102-1-git-send-email-balbi@ti.com>
On Fri, Jan 31, 2014 at 12:12:45PM -0600, Felipe Balbi wrote:
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 3a94b79..86aeb5b 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -484,6 +484,21 @@ static int platform_drv_probe(struct device *_dev)
> if (ACPI_HANDLE(_dev))
> acpi_dev_pm_attach(_dev, true);
>
> + dev->fck = devm_clk_get(_dev, "fck");
> + dev->ick = devm_clk_get(_dev, "ick");
> +
> + if (!IS_ERR(dev->fck))
> + clk_prepare_enable(dev->fck);
> + else
> + dev->fck = NULL;
> +
> + if (!IS_ERR(dev->ick))
> + clk_prepare_enable(dev->ick);
> + else
> + dev->ick = NULL;
If people are going to continue doing this (converting error values to
NULL) can we please have a check in devm_clk_get() which prevents it
returning NULL if the implementation happens to do so?
It's either that or we force all users to conform to the API which
specifies that the error values are defined by IS_ERR() returning
true and everything else must be considered as a potential valid return.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 2/4] arm: qcom: Split Qualcomm support into legacy and multiplatform
From: Kumar Gala @ 2014-01-31 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3511712.H3ChLoqCm7@wuerfel>
On Jan 31, 2014, at 1:34 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 31 January 2014 13:25:25 Kumar Gala wrote:
>>> The hotplug.c change sticks out as something that isn't just a move
>>> of code to another place, but deletion of unused code. It would
>>> be nice to split that out into a separate change, possibly together
>>> with the trivial board.c and smp.c changes.
>>
>> That?s not 100% true, the hotplug.c code implemented msm_cpu_die, which moved into smp.c
>>
>> I can split out scm*/smp* into a patch to enable smp if that is really desired, but not exactly sure what it gets us.
>>
>
> It's not extremely important, I just prefer splitting patches
> that have any kind of functional change from trivial moves.
>
> If something happens to break for an unforseen reason, it's
> easier to bisect to the patch that does the change.
>
> Arnd
I?ll push my change to hotplug.c into the SMP patch set that Stephen started.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 2/4] arm: qcom: Split Qualcomm support into legacy and multiplatform
From: Arnd Bergmann @ 2014-01-31 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2B2190A4-6689-40D8-A3D7-BD2D882A2CF6@codeaurora.org>
On Friday 31 January 2014 13:25:25 Kumar Gala wrote:
> > The hotplug.c change sticks out as something that isn't just a move
> > of code to another place, but deletion of unused code. It would
> > be nice to split that out into a separate change, possibly together
> > with the trivial board.c and smp.c changes.
>
> That?s not 100% true, the hotplug.c code implemented msm_cpu_die, which moved into smp.c
>
> I can split out scm*/smp* into a patch to enable smp if that is really desired, but not exactly sure what it gets us.
>
It's not extremely important, I just prefer splitting patches
that have any kind of functional change from trivial moves.
If something happens to break for an unforseen reason, it's
easier to bisect to the patch that does the change.
Arnd
^ permalink raw reply
* [PATCH 2/4] arm: qcom: Split Qualcomm support into legacy and multiplatform
From: Kumar Gala @ 2014-01-31 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401312020.16984.arnd@arndb.de>
On Jan 31, 2014, at 1:20 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 30 January 2014, Kumar Gala wrote:
>> Introduce a new mach-qcom that will support SoCs that intend to be
>> multiplatform compatiable while keeping mach-msm to legacy SoC/board
>> support that will not transition over to multiplatform.
>>
>> As part of this, we move support for MSM8X60, MSM8960 and MSM8974 over
>> to mach-qcom.
>>
>> Signed-off-by: Kumar Gala <galak@codeaurora.org>
>> ---
>> MAINTAINERS | 7 +++
>> arch/arm/Kconfig | 7 +--
>> arch/arm/Makefile | 1 +
>> arch/arm/boot/dts/Makefile | 6 +--
>> arch/arm/mach-msm/Kconfig | 45 +------------------
>> arch/arm/mach-msm/Makefile | 7 ---
>> arch/arm/mach-msm/hotplug.c | 51 ----------------------
>> arch/arm/mach-qcom/Kconfig | 34 +++++++++++++++
>> arch/arm/mach-qcom/Makefile | 5 +++
>> .../arm/{mach-msm/board-dt.c => mach-qcom/board.c} | 9 ++--
>> arch/arm/{mach-msm => mach-qcom}/scm-boot.c | 0
>> arch/arm/{mach-msm => mach-qcom}/scm-boot.h | 0
>> arch/arm/{mach-msm => mach-qcom}/scm.c | 0
>> arch/arm/{mach-msm => mach-qcom}/scm.h | 0
>> arch/arm/{mach-msm/platsmp.c => mach-qcom/smp.c} | 11 ++++-
>
> The hotplug.c change sticks out as something that isn't just a move
> of code to another place, but deletion of unused code. It would
> be nice to split that out into a separate change, possibly together
> with the trivial board.c and smp.c changes.
That?s not 100% true, the hotplug.c code implemented msm_cpu_die, which moved into smp.c
I can split out scm*/smp* into a patch to enable smp if that is really desired, but not exactly sure what it gets us.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Santosh Shilimkar @ 2014-01-31 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131164534.GL20736@saruman.home>
On Friday 31 January 2014 11:45 AM, Felipe Balbi wrote:
> On Fri, Jan 31, 2014 at 10:50:40AM -0500, Santosh Shilimkar wrote:
>> On Friday 31 January 2014 10:47 AM, Felipe Balbi wrote:
>>> On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote:
>>>> On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote:
>>>>> Hi,
>>>>>
>>>>> On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote:
>>>>>> The Keystone PM management layer has been implemented using PM bus for
>>>>>> power management clocks. As result, most of Keystone drivers don't need
>>>>>> to manage clocks directly. They just need to enable runtime PM and use it
>>>>>> to handle their PM state and clocks.
>>>>>>
>>>>>> Hence, remove clock management code and switch to use runtime PM.
>>>>>>
>>>>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>>>>>
>>>>> quite a few weeks back I sent a series enabling runtime pm for all glue
>>>>> layers. I'll use that version instead, sorry.
>>>>>
>>>> That should be fine but you need to drop clk_*() related code
>>>> from that patch. I assume you will send refresh version of it then.
>>>
>>> why ? it makes no difference if you enable twice and disable twice.
>>>
>> Sure but why do you want to have the clock node handling code in drivers
>> if it is not needed. Isn't that better ?
>
> It might, but then way that I wanted to see it is so that I can make
> assumptions about the device state. From a driver perspective, what I
> would love to see is the ability to assume that when my probe gets
> called the device is already enabled. So if you can make sure that
> clk_enable() happens before my probe and that you call
> pm_runtime_set_active() before my probe too, then I can more than
> hapilly remove clk_* calls from the driver ;-)
>
> either that or maintain the driver like so:
>
> probe()
> {
> ...
>
> clk_get(dev, "fck");
> clk_prepare(clk);
> clk_enable(clk);
> pm_runtime_set_active(dev);
> pm_runtime_enable(dev);
> pm_runtime_get_sync(dev);
> ...
> }
>
> runtime_suspend()
> {
> clk_disable(dev);
> }
>
> runtime_resume()
> {
> clk_enable(dev);
> }
>
> note that because of pm_runtime_set_active() that first
> pm_runtime_get_sync() in probe() will simply increase the reference
> counter without calling my ->runtime_resume() callback, which is exactly
> what we want, as that would completely avoid situations of bad context
> being restored because of that initial pm_runtime_get_sync().
>
Thanks for making your point bit clear.
> Then, we can even make pm_runtime completely async easily, because
> clk_prepare() was called only on probe() (or before it, for that
> matter).
>
> Bottomline is, if you can guarantee me that clk_get(), clk_prepare(),
> clk_enable() and pm_runtime_set_active() will be called properly before
> my probe, i'll be more than happy to comply with your request above as
> that will greatly simplify my driver.
>
Which is the case at least I see on Keystone. And hence the patch from
Grygorii works. I also noticed your proposal for wider platform to
enforce above behavior which seems to be a good idea.
> Just make, also, that if this clock is shared between dwc3-keystone
> wrapper and dwc3 core, you clk_get() on both driver's probe.
>
I understand. In summary, whichever patch you pick(yours) or Grygorii's,
its completely safe to remove the clock handling from Keystone USB driver.
Regards,
Santosh
^ 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