* [PATCH V3 2/2] scsi: hpsa: drop shutdown callback
From: Don Brace @ 2018-05-30 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51bb7b82-c4a1-435c-7668-639db96d76e1@finnie.org>
> -----Original Message-----
> From: Ryan Finnie [mailto:ryan at finnie.org]
> Sent: Tuesday, May 29, 2018 8:50 PM
> To: Sinan Kaya <okaya@codeaurora.org>; linux-pci at vger.kernel.org;
> timur at codeaurora.org
> Cc: linux-arm-msm at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> stable at vger.kernel.org; Don Brace <don.brace@microsemi.com>; James E.J.
> Bottomley <jejb@linux.vnet.ibm.com>; Martin K. Petersen
> <martin.petersen@oracle.com>; esc.storagedev
> <esc.storagedev@microsemi.com>; open list:HEWLETT-PACKARD SMART ARRAY
> RAID DRIVER (hpsa) <linux-scsi@vger.kernel.org>; open list <linux-
> kernel at vger.kernel.org>
> Subject: Re: [PATCH V3 2/2] scsi: hpsa: drop shutdown callback
>
> EXTERNAL EMAIL
>
>
> On 05/28/2018 02:21 PM, Sinan Kaya wrote:
> > 'Commit cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during
> > shutdown")' has been added to kernel to shutdown pending PCIe port
> > service interrupts during reboot so that a newly started kexec kernel
> > wouldn't observe pending interrupts.
> >
> > pcie_port_device_remove() is disabling the root port and switches by
> > calling pci_disable_device() after all PCIe service drivers are shutdown.
> >
> > This has been found to cause crashes on HP DL360 Gen9 machines during
> > reboot due to hpsa driver not clearing the bus master bit during the
> > shutdown procedure by calling pci_disable_device().
> >
> > Drop the shutdown API and do an orderly clean up by using the remove.
> >
> > Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=199779
> > Fixes: cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown")
> > Cc: stable at vger.kernel.org
> > Reported-by: Ryan Finnie <ryan@finnie.org>
>
> Tested successfully on DL360 Gen9 and DL380 Gen9.
>
> Tested-by: Ryan Finnie <ryan@finnie.org>
The shutdown path issues a cache flush to the controller.
Without this flush, you will see "Dirty Cache" messages at POST.
It is best to keep the shutdown path.
Thanks,
Don Brace
ESC - Smart Storage
Microsemi Corporation
^ permalink raw reply
* [PATCH V3 2/6] hwmon: Add support for RPi voltage sensor
From: Eric Anholt @ 2018-05-30 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525193717.GA24967@roeck-us.net>
Guenter Roeck <linux@roeck-us.net> writes:
> On Fri, May 25, 2018 at 09:24:35PM +0200, Stefan Wahren wrote:
>> Currently there is no easy way to detect undervoltage conditions on a
>> remote Raspberry Pi. This hwmon driver retrieves the state of the
>> undervoltage sensor via mailbox interface. The handling based on
>> Noralf's modifications to the downstream firmware driver. In case of
>> an undervoltage condition only an entry is written to the kernel log.
>>
>> CC: "Noralf Tr?nnes" <noralf@tronnes.org>
>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>
> Acked-by: Guenter Roeck <linux@roeck-us.net>
>
> ... assuming this will go through some arm tree.
That's fine with me, I can pull this whole set for 4.19. Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/0d120acc/attachment.sig>
^ permalink raw reply
* [PATCH 4/9] clk: davinci: pll-dm646x: keep PLL2 SYSCLK1 always enabled
From: David Lechner @ 2018-05-30 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530172239.982.48723@harbor.lan>
On 05/30/2018 12:22 PM, Michael Turquette wrote:
> Quoting David Lechner (2018-05-25 11:11:45)
>> From: Sekhar Nori <nsekhar@ti.com>
>>
>> PLL2 SYSCLK1 on DM646x is connected to DDR2 PHY and cannot
>> be disabled. Mark it so to prevent unused clock disable
>> infrastructure from disabling it.
>>
>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>> Reviewed-by: David Lechner <david@lechnology.com>
>> ---
>> drivers/clk/davinci/pll-dm646x.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/davinci/pll-dm646x.c b/drivers/clk/davinci/pll-dm646x.c
>> index a61cc3256418..0ae827e3ce80 100644
>> --- a/drivers/clk/davinci/pll-dm646x.c
>> +++ b/drivers/clk/davinci/pll-dm646x.c
>> @@ -72,7 +72,7 @@ static const struct davinci_pll_clk_info dm646x_pll2_info = {
>> .flags = 0,
>> };
>>
>> -SYSCLK(1, pll2_sysclk1, pll2_pllen, 4, 0);
>> +SYSCLK(1, pll2_sysclk1, pll2_pllen, 4, SYSCLK_ALWAYS_ENABLED);
>
> Nitpick: I dislike setting a platform-specific flag that just sets a
> framework-specific flag during clk registration.
>
> I know there is some legacy here so I'll take this patch as-is, but
> perhaps cleaning this up to directly use CLK_IS_CRITICAL can be added to
> someone's todo list?
I can see how this would be better in general, but I don't think it would
be an improvement in this case. We have other platform-specific flags that
don't correspond to common framework flags (only the one you pointed out
does). So, we would have to introduce a second flags variable for the
common framework flags (unless I am missing something, like a reserved
range of bits for platform-specific flags that would allow platform-specific
flags and common framework flags to coexist in a single 32 or 64-bit field).
Then we would have to add comments saying that CLK_IS_CRITICAL is the only
flag that you can use for this field because we really don't want someone
to try to use any other common framework flags. This seems like quite a bit
of effort just to try to avoid one redundant flag.
^ permalink raw reply
* [PATCH v2] spi: bcm2835aux: ensure interrupts are enabled for shared handler
From: Eric Anholt @ 2018-05-30 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523205220.7394-1-robh@kernel.org>
Rob Herring <robh@kernel.org> writes:
> The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
> Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
> DT change which breaks compatibility with older kernels. The AUX irqchip
> was already rejected for upstream[1] and the DT change would break
> working systems if the DTB is updated to a newer one. The latter issue
> was brought to my attention by Alex Graf.
>
> The root cause however is a bug in the shared handler. A shared handler
> must correctly identify it actually handled an interrupt. The handler
> here was processing data whether interrupts were enabled or not.
> It would return IRQ_HANDLED if there was any data and not only when
> there was an actual interrupt pending. The result is that another
> device's IRQ could cause the SPI's IRQ handler to run and process data
> when the the SPI driver working in polled mode. Fix this by adding a
> check in the IRQ handler that the TXEMPTY or IDLE interrupts are enabled
> and always return IRQ_NONE when they are not.
FWIW, I see v1 already applied in -next.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/0171381b/attachment.sig>
^ permalink raw reply
* [PATCH v4] rtc: sun6i: Fix bit_idx value for clk_register_gate
From: Jagan Teki @ 2018-05-30 18:27 UTC (permalink / raw)
To: linux-arm-kernel
From: Michael Trimarchi <michael@amarulasolutions.com>
clk-gate core will take bit_idx through clk_register_gate
and then do clk_gate_ops by using BIT(bit_idx), but rtc-sun6i
is passing bit_idx as BIT(bit_idx) it becomes BIT(BIT(bit_idx)
which is wrong and eventually external gate clock is not enabling.
This patch fixed by passing bit index and the original change
introduced from below commit.
"rtc: sun6i: Add support for the external oscillator gate"
(sha1: 17ecd246414b3a0fe0cb248c86977a8bda465b7b)
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Fixes: 17ecd246414b ("rtc: sun6i: Add support for the external oscillator gate")
Cc: stable at vger.kernel.org
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v4:
- Cc to stable tree
Changes for v3:
- add fixes tag
- Cced stable ML
Changes for v2:
- add suffix _OFFSET with macro name to distinguish b/w
register actual values vs offset.
drivers/rtc/rtc-sun6i.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index 2e6fb275acc8..2cd5a7b1a2e3 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -74,7 +74,7 @@
#define SUN6I_ALARM_CONFIG_WAKEUP BIT(0)
#define SUN6I_LOSC_OUT_GATING 0x0060
-#define SUN6I_LOSC_OUT_GATING_EN BIT(0)
+#define SUN6I_LOSC_OUT_GATING_EN_OFFSET 0
/*
* Get date values
@@ -255,7 +255,7 @@ static void __init sun6i_rtc_clk_init(struct device_node *node)
&clkout_name);
rtc->ext_losc = clk_register_gate(NULL, clkout_name, rtc->hw.init->name,
0, rtc->base + SUN6I_LOSC_OUT_GATING,
- SUN6I_LOSC_OUT_GATING_EN, 0,
+ SUN6I_LOSC_OUT_GATING_EN_OFFSET, 0,
&rtc->lock);
if (IS_ERR(rtc->ext_losc)) {
pr_crit("Couldn't register the LOSC external gate\n");
--
2.14.3
^ permalink raw reply related
* [PATCH] usb: chipidea: Fix ULPI on imx51
From: Fabio Estevam @ 2018-05-30 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530173414.6121-1-andrew.smirnov@gmail.com>
On Wed, May 30, 2018 at 2:34 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> Workaround introduced for i.MX53 in be9cae2479f48 ("usb: chipidea:
> imx: Fix ULPI on imx53") seems to be applicable in case of i.MX51 as
> well. Running latest kernel on ZII RDU1 Board (imx51-zii-rdu1.dts)
> exhibits a kernel frozen on PORTSC access and applying the workaround
> resolves the issue.
>
> Cc: Peter Chen <peter.chen@nxp.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Chris Healy <cphealy@gmail.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-usb at vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* arch_wb_cache_pmem on ARM64
From: Mark Rutland @ 2018-05-30 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <92b97864-52af-88d1-f18d-c6f6764072b0@arm.com>
On Wed, May 30, 2018 at 06:31:42PM +0100, Robin Murphy wrote:
> On 30/05/18 18:00, Mikulas Patocka wrote:
> > Hi
> >
> > I'd like to ask what's the purpose of dmb(osh) in the function
> > arch_wb_cache_pmem in arch/arm64/mm/flush.c?
> >
> > void arch_wb_cache_pmem(void *addr, size_t size)
> > {
> > /* Ensure order against any prior non-cacheable writes */
> > dmb(osh);
> > __clean_dcache_area_pop(addr, size);
> > }
> >
> > The processor may flush the cache spontaneously, that means that all the
> > flushing may actually happen before the dmb(osh) instruction - so what
> > does that dmb instruction guard against?
>
> IIRC the (very subtle) problem was to do with the odd case of a transparent
> (i.e. beyond the PoC) system cache - if data has been written to the pmem
> region via some non-cacheable alias, then the barrier was necessary to
> ensure that cache maintenance via the inner-shareable kernel mapping can
> push any data already at the PoC further along to the PoP.
I think it's simpler than that: the cache maintenance operations
naturally hazard against cacheable memory accesses, but they don't
hazard against non-cacheable accesses.
Thus, we need a barrier between the two to ensure ordering.
Non-cacheable accesses are Outer Shareable, so thus the barrier must be
at least Outer Shareable.
We *might* be able to get away with OSHST, though.
For example, Without the barrier, prior non-cacheable stores could sit
in a store buffer while the cache maintenance was performed, and could
subsequently be written out after the cache maintenance was complete.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] drm/bridge/synopsys: dw-hdmi: fix dw_hdmi_setup_rx_sense
From: Sean Paul @ 2018-05-30 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527673438-20643-1-git-send-email-narmstrong@baylibre.com>
On Wed, May 30, 2018 at 11:43:58AM +0200, Neil Armstrong wrote:
> The dw_hdmi_setup_rx_sense exported function should not use struct device
> to recover the dw-hdmi context using drvdata, but take struct dw_hdmi
> directly like other exported functions.
>
> This caused a regression using Meson DRM on S905X since v4.17-rc1 :
>
> Internal error: Oops: 96000007 [#1] PREEMPT SMP
> [...]
> CPU: 0 PID: 124 Comm: irq/32-dw_hdmi_ Not tainted 4.17.0-rc7 #2
> Hardware name: Libre Technology CC (DT)
> [...]
> pc : osq_lock+0x54/0x188
> lr : __mutex_lock.isra.0+0x74/0x530
> [...]
> Process irq/32-dw_hdmi_ (pid: 124, stack limit = 0x00000000adf418cb)
> Call trace:
> osq_lock+0x54/0x188
> __mutex_lock_slowpath+0x10/0x18
> mutex_lock+0x30/0x38
> __dw_hdmi_setup_rx_sense+0x28/0x98
> dw_hdmi_setup_rx_sense+0x10/0x18
> dw_hdmi_top_thread_irq+0x2c/0x50
> irq_thread_fn+0x28/0x68
> irq_thread+0x10c/0x1a0
> kthread+0x128/0x130
> ret_from_fork+0x10/0x18
> Code: 34000964 d00050a2 51000484 9135c042 (f864d844)
> ---[ end trace 945641e1fbbc07da ]---
> note: irq/32-dw_hdmi_[124] exited with preempt_count 1
> genirq: exiting task "irq/32-dw_hdmi_" (124) is an active IRQ thread (irq 32)
>
> Fixes: eea034af90c6 ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata")
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> Tested-by: Koen Kooi <koen@dominion.thruhere.net>
Thanks for your patch, Neil. I've applied it to -misc-fixes and will send it to
Dave in hope it can sneak into 4.17.
Sean
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 15 ++++-----------
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +-
> include/drm/bridge/dw_hdmi.h | 2 +-
> 3 files changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index ec8d000..3c136f2b 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2077,7 +2077,7 @@ static irqreturn_t dw_hdmi_hardirq(int irq, void *dev_id)
> return ret;
> }
>
> -void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
> +void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
> {
> mutex_lock(&hdmi->mutex);
>
> @@ -2103,13 +2103,6 @@ void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
> }
> mutex_unlock(&hdmi->mutex);
> }
> -
> -void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense)
> -{
> - struct dw_hdmi *hdmi = dev_get_drvdata(dev);
> -
> - __dw_hdmi_setup_rx_sense(hdmi, hpd, rx_sense);
> -}
> EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
>
> static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> @@ -2145,9 +2138,9 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> */
> if (intr_stat &
> (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
> - __dw_hdmi_setup_rx_sense(hdmi,
> - phy_stat & HDMI_PHY_HPD,
> - phy_stat & HDMI_PHY_RX_SENSE);
> + dw_hdmi_setup_rx_sense(hdmi,
> + phy_stat & HDMI_PHY_HPD,
> + phy_stat & HDMI_PHY_RX_SENSE);
>
> if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
> cec_notifier_set_phys_addr(hdmi->cec_notifier,
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index a393095..c9ad456 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -529,7 +529,7 @@ static irqreturn_t dw_hdmi_top_thread_irq(int irq, void *dev_id)
> if (stat & HDMITX_TOP_INTR_HPD_RISE)
> hpd_connected = true;
>
> - dw_hdmi_setup_rx_sense(dw_hdmi->dev, hpd_connected,
> + dw_hdmi_setup_rx_sense(dw_hdmi->hdmi, hpd_connected,
> hpd_connected);
>
> drm_helper_hpd_irq_event(dw_hdmi->encoder.dev);
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index dd2a8cf..ccb5aa8 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -151,7 +151,7 @@ struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
> struct drm_encoder *encoder,
> const struct dw_hdmi_plat_data *plat_data);
>
> -void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense);
> +void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense);
>
> void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);
> void dw_hdmi_audio_enable(struct dw_hdmi *hdmi);
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Sean Paul, Software Engineer, Google / Chromium OS
^ permalink raw reply
* [PATCH] usb: chipidea: Fix ULPI on imx51
From: Andrey Smirnov @ 2018-05-30 17:34 UTC (permalink / raw)
To: linux-arm-kernel
Workaround introduced for i.MX53 in be9cae2479f48 ("usb: chipidea:
imx: Fix ULPI on imx53") seems to be applicable in case of i.MX51 as
well. Running latest kernel on ZII RDU1 Board (imx51-zii-rdu1.dts)
exhibits a kernel frozen on PORTSC access and applying the workaround
resolves the issue.
Cc: Peter Chen <peter.chen@nxp.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Chris Healy <cphealy@gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-usb at vger.kernel.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
drivers/usb/chipidea/ci_hdrc_imx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
index e431c5aafe35..19f5f5f2a48a 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -291,7 +291,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
pdata.usb_phy = data->phy;
- if (of_device_is_compatible(np, "fsl,imx53-usb") && pdata.usb_phy &&
+ if ((of_device_is_compatible(np, "fsl,imx53-usb") ||
+ of_device_is_compatible(np, "fsl,imx51-usb")) && pdata.usb_phy &&
of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI) {
pdata.flags |= CI_HDRC_OVERRIDE_PHY_CONTROL;
data->override_phy_control = true;
--
2.17.0
^ permalink raw reply related
* arch_wb_cache_pmem on ARM64
From: Robin Murphy @ 2018-05-30 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LRH.2.02.1805301254340.25056@file01.intranet.prod.int.rdu2.redhat.com>
On 30/05/18 18:00, Mikulas Patocka wrote:
> Hi
>
> I'd like to ask what's the purpose of dmb(osh) in the function
> arch_wb_cache_pmem in arch/arm64/mm/flush.c?
>
> void arch_wb_cache_pmem(void *addr, size_t size)
> {
> /* Ensure order against any prior non-cacheable writes */
> dmb(osh);
> __clean_dcache_area_pop(addr, size);
> }
>
> The processor may flush the cache spontaneously, that means that all the
> flushing may actually happen before the dmb(osh) instruction - so what
> does that dmb instruction guard against?
IIRC the (very subtle) problem was to do with the odd case of a
transparent (i.e. beyond the PoC) system cache - if data has been
written to the pmem region via some non-cacheable alias, then the
barrier was necessary to ensure that cache maintenance via the
inner-shareable kernel mapping can push any data already at the PoC
further along to the PoP.
Robin.
^ permalink raw reply
* [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client
From: Radhey Shyam Pandey @ 2018-05-30 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <99581088-7ef8-6fac-c934-91eadddfb04e@ti.com>
Hi,
> -----Original Message-----
> From: Peter Ujfalusi [mailto:peter.ujfalusi at ti.com]
> Sent: Tuesday, May 29, 2018 8:35 PM
> To: Radhey Shyam Pandey <radheys@xilinx.com>; Vinod Koul
> <vinod.koul@intel.com>
> Cc: Lars-Peter Clausen <lars@metafoo.de>; michal.simek at xilinx.com; linux-
> kernel at vger.kernel.org; dmaengine at vger.kernel.org;
> dan.j.williams at intel.com; Appana Durga Kedareswara Rao
> <appanad@xilinx.com>; linux-arm-kernel at lists.infradead.org
> Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words
> to netdev dma client
>
> Hi,
>
> On 2018-05-17 09:39, Radhey Shyam Pandey wrote:
> >> Well, let's see where this is going to go when I can send the patches
> >> for review.
> > Thanks all. @Peter: If we have metadata patchset ready may be good
> > to send an RFC?
>
> Sorry for the delay, I got distracted by this:
> http://www.ti.com/lit/pdf/spruid7 Chapter 10.
>
> I have given some tough to the metadata attach patches.
> In my case the 'metadata' is more like private data section within the
> DMA descriptor (10.1.2.2.1) which is used by the remote peripheral and
> the driver for the given peripheral and it is optional.
>
> I liked the idea of treating it as metadata as it gives more generic API
> which can be adopted by other drivers if they need something similar.
>
> Another issue I have with the attach metadata way is that it would
> require one memcpy to copy the data to the DMA descriptor and in high
> throughput case it is not acceptable.
I think memcpy is needed (alternative?) if dma engine doesn?t directly
update metadata buffers i.e in RX, we need to copy metadata from
dma descriptor fields to client allocated metadata buffer (sideband/
metadata info is part of Buffer descriptor fields)
memcpy(app_w, hw->app, sizeof(u32) * XILINX_DMA_NUM_APP_WORDS);
Descriptor Fields
Address Space Offset Name Description
20h APP0 User Application Field 0
24h APP1 User Application Field 1
...
30h APP5 User Application Field 5
>
> For me probably a .get_private_area / .put_private_area like API would
> be desirable where I can give the pointer of the 'metadata' are (and
> size) to the user.
>
> But these can co-exist in my opinion and DMA drivers can opt to
> implement none, either or both of the callbacks.
>
> In couple of days I can update the metadata patches I have atm and send
> as RFC.
>
> Is there anything from your side I should take into account when doing that?
I think a generic interface to attach/share metadata buffer b/w client and the
dmaengine driver is good enough. Is metadata patchset (early version)
available in TI external repos?
Thanks,
Radhey
>
> - P?ter
>
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* [PATCH 2/6] PCI: iproc: Add INTx support with better modeling
From: Ray Jui @ 2018-05-30 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VfwfKbikfat3tTbMzSfNgt4v9nFpExyDvhOdX9ko1Z4Fw@mail.gmail.com>
Hi Andy,
On 5/29/2018 5:59 PM, Andy Shevchenko wrote:
> On Wed, May 30, 2018 at 12:58 AM, Ray Jui <ray.jui@broadcom.com> wrote:
>> Add PCIe legacy interrupt INTx support to the iProc PCIe driver by
>> modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC,
>> INTD share the same interrupt line connected to the GIC in the system,
>> while the status of each INTx can be obtained through the INTX CSR
>> register
>
>> + while ((status = iproc_pcie_read_reg(pcie, IPROC_PCIE_INTX_CSR) &
>> + SYS_RC_INTX_MASK) != 0) {
>> + for_each_set_bit(bit, &status, PCI_NUM_INTX) {
>> + virq = irq_find_mapping(pcie->irq_domain, bit + 1);
>> + if (virq)
>> + generic_handle_irq(virq);
>> + else
>> + dev_err(dev, "unexpected INTx%u\n", bit);
>> + }
>> + }
>
> do {
> status = ...;
> for_each_set_bit() {
> ...
> }
> } while (status);
>
> would look slightly better for my opinion.
>
Indeed. I agree with you. I'll wait for comments before sending out v2
which will include this improvement.
Thanks,
Ray
^ permalink raw reply
* [PATCH v2 1/2] ARM: debug: Add Iproc UART3 debug addresses
From: Ray Jui @ 2018-05-30 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530131956.13972-1-peron.clem@gmail.com>
Hi Cl?ment,
Correct me if I'm wrong, but I thought the trend is to move to use
earlycon that can be activated from kernel command line for early print
before the serial driver is loaded.
Have you tried earlcon?
Thanks,
Ray
On 5/30/2018 6:19 AM, Cl?ment P?ron wrote:
> From: Cl?ment Peron <clement.peron@devialet.com>
>
> Broadcom Iproc SoCs typically use the UART3 for
> debug/console, provide a known good location for that.
>
> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> ---
>
> arch/arm/Kconfig.debug | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 199ebc1c4538..4ea9d5793b91 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -207,6 +207,14 @@ choice
> depends on ARCH_BCM_HR2
> select DEBUG_UART_8250
>
> + config DEBUG_BCM_IPROC_UART3
> + bool "Kernel low-level debugging on BCM IPROC UART3"
> + depends on ARCH_BCM_CYGNUS
> + select DEBUG_UART_8250
> + help
> + Say Y here if you want the debug print routines to direct
> + their output to the third serial port on these devices.
> +
> config DEBUG_BCM_KONA_UART
> bool "Kernel low-level debugging messages via BCM KONA UART"
> depends on ARCH_BCM_MOBILE
> @@ -1557,6 +1565,7 @@ config DEBUG_UART_PHYS
> default 0x18000400 if DEBUG_BCM_HR2
> default 0x18010000 if DEBUG_SIRFATLAS7_UART0
> default 0x18020000 if DEBUG_SIRFATLAS7_UART1
> + default 0x18023000 if DEBUG_BCM_IPROC_UART3
> default 0x1c090000 if DEBUG_VEXPRESS_UART0_RS1
> default 0x20001000 if DEBUG_HIP01_UART
> default 0x20060000 if DEBUG_RK29_UART0
> @@ -1676,6 +1685,7 @@ config DEBUG_UART_VIRT
> default 0xf1002000 if DEBUG_MT8127_UART0
> default 0xf1006000 if DEBUG_MT6589_UART0
> default 0xf1009000 if DEBUG_MT8135_UART3
> + default 0xf1023000 if DEBUG_BCM_IPROC_UART3
> default 0xf11f1000 if DEBUG_VERSATILE
> default 0xf1600000 if DEBUG_INTEGRATOR
> default 0xf1c28000 if DEBUG_SUNXI_UART0
> @@ -1791,7 +1801,7 @@ config DEBUG_UART_8250_WORD
> DEBUG_KEYSTONE_UART0 || DEBUG_KEYSTONE_UART1 || \
> DEBUG_ALPINE_UART0 || \
> DEBUG_DAVINCI_DMx_UART0 || DEBUG_DAVINCI_DA8XX_UART1 || \
> - DEBUG_DAVINCI_DA8XX_UART2 || \
> + DEBUG_DAVINCI_DA8XX_UART2 || DEBUG_BCM_IPROC_UART3 || \
> DEBUG_BCM_KONA_UART || DEBUG_RK32_UART2
>
> config DEBUG_UART_8250_PALMCHIP
>
^ permalink raw reply
* [PATCH 4/9] clk: davinci: pll-dm646x: keep PLL2 SYSCLK1 always enabled
From: Michael Turquette @ 2018-05-30 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525181150.17873-5-david@lechnology.com>
Quoting David Lechner (2018-05-25 11:11:45)
> From: Sekhar Nori <nsekhar@ti.com>
>
> PLL2 SYSCLK1 on DM646x is connected to DDR2 PHY and cannot
> be disabled. Mark it so to prevent unused clock disable
> infrastructure from disabling it.
>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> Reviewed-by: David Lechner <david@lechnology.com>
> ---
> drivers/clk/davinci/pll-dm646x.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/davinci/pll-dm646x.c b/drivers/clk/davinci/pll-dm646x.c
> index a61cc3256418..0ae827e3ce80 100644
> --- a/drivers/clk/davinci/pll-dm646x.c
> +++ b/drivers/clk/davinci/pll-dm646x.c
> @@ -72,7 +72,7 @@ static const struct davinci_pll_clk_info dm646x_pll2_info = {
> .flags = 0,
> };
>
> -SYSCLK(1, pll2_sysclk1, pll2_pllen, 4, 0);
> +SYSCLK(1, pll2_sysclk1, pll2_pllen, 4, SYSCLK_ALWAYS_ENABLED);
Nitpick: I dislike setting a platform-specific flag that just sets a
framework-specific flag during clk registration.
I know there is some legacy here so I'll take this patch as-is, but
perhaps cleaning this up to directly use CLK_IS_CRITICAL can be added to
someone's todo list?
Thanks,
Mike
>
> int dm646x_pll2_init(struct device *dev, void __iomem *base)
> {
> --
> 2.17.0
>
^ permalink raw reply
* arch_wb_cache_pmem on ARM64
From: Mikulas Patocka @ 2018-05-30 17:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi
I'd like to ask what's the purpose of dmb(osh) in the function
arch_wb_cache_pmem in arch/arm64/mm/flush.c?
void arch_wb_cache_pmem(void *addr, size_t size)
{
/* Ensure order against any prior non-cacheable writes */
dmb(osh);
__clean_dcache_area_pop(addr, size);
}
The processor may flush the cache spontaneously, that means that all the
flushing may actually happen before the dmb(osh) instruction - so what
does that dmb instruction guard against?
Mikulas
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-30 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=V1gGccKr1mHM0zx_-FFdLU1vrzUChwx6KTUyTGzj39Tw@mail.gmail.com>
On Wed, May 30, 2018 at 09:41:55AM -0700, Doug Anderson wrote:
> On Wed, May 30, 2018 at 9:36 AM, Mark Brown <broonie@kernel.org> wrote:
> > Yeah, and I don't think that's unreasonable for the core to do - just
> > drop the voltage to the constraint minimum after it has turned off the
> > regulator, then recheck and raise if needed before it enables again.
> Would it do this for all regulators, though? Most regulators are
> hooked up over a slow i2c bus, so that means that every regulator
> disable would now do an extra i2c transfer even though for all
> regulators (other than RPMh) the voltage of a regulator doesn't matter
> when it's been "disabled' (from Linux's point of view).
It'd only affect regulators that can vary in voltage and actually get
disabled which is a pretty small subset. Most regulators are either
fixed voltage or always on.
> Hrmmm, I suppose maybe it'd be OK though because for most regulators
> we'd use "regcache" and most regulators that we enabled/disable a lot
> are not expected to change voltage in Linux (so the regcache write
> would hopefully be a noop), so maybe it wouldn't be _that_
> inefficient...
Even if the regulator lacks a cache we'd at least skip out on the write
when we're not changing voltage as we'd do a read/modify/update cycle
and stop at the modify.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/af4e9b3f/attachment-0001.sig>
^ permalink raw reply
* [PATCH] ARM: dts: exynos: Add missing CPU clocks to secondary CPUs on Exynos542x
From: Krzysztof Kozlowski @ 2018-05-30 16:49 UTC (permalink / raw)
To: linux-arm-kernel
Secondary CPUs should have the same information in DeviceTree as booting
CPU from both correctness point of view and for possible hotplug
scenarios.
Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm/boot/dts/exynos5420-cpus.dtsi | 6 ++++++
arch/arm/boot/dts/exynos5422-cpus.dtsi | 8 +++++++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi
index a8e449471304..0ee6e92a3c29 100644
--- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
@@ -38,6 +38,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -49,6 +50,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -60,6 +62,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -83,6 +86,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
@@ -94,6 +98,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x102>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
@@ -105,6 +110,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x103>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi b/arch/arm/boot/dts/exynos5422-cpus.dtsi
index 7c130a00d1a8..e4a5857c135f 100644
--- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
@@ -37,6 +37,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
@@ -48,6 +49,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x102>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
@@ -59,6 +61,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x103>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
@@ -69,8 +72,8 @@
cpu4: cpu at 0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
- clocks = <&clock CLK_ARM_CLK>;
reg = <0x0>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -82,6 +85,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -93,6 +97,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -104,6 +109,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
--
2.14.1
^ permalink raw reply related
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530163644.GW6920@sirena.org.uk>
Hi,
On Wed, May 30, 2018 at 9:36 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 30, 2018 at 09:31:55AM -0700, Doug Anderson wrote:
>> On Wed, May 30, 2018 at 9:13 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > If we're just going to use the most recently set voltage then hopefully
>> > the hardware already knew that, and it might not be the lowest available
>> > voltage if the last consumer to get turned off was holding the voltage
>> > higher.
>
>> To circle back to the original point: the problem is that (IMHO) the
>> hardware is doing the wrong thing by still counting Linux's vote for a
>> voltage even though Linux also voted that the regulator should be
>> disabled. So basically we're working around the hardware by
>> pretending to vote for a dummy lower voltage whenever Linux wants the
>> regulator disabled. From Linux's point of view everything works as
>> normal--we just tell the hardware a falsehood so it doesn't count our
>> vote for a voltage while the regulator is disabled.
>
> Yeah, and I don't think that's unreasonable for the core to do - just
> drop the voltage to the constraint minimum after it has turned off the
> regulator, then recheck and raise if needed before it enables again.
Would it do this for all regulators, though? Most regulators are
hooked up over a slow i2c bus, so that means that every regulator
disable would now do an extra i2c transfer even though for all
regulators (other than RPMh) the voltage of a regulator doesn't matter
when it's been "disabled' (from Linux's point of view).
Hrmmm, I suppose maybe it'd be OK though because for most regulators
we'd use "regcache" and most regulators that we enabled/disable a lot
are not expected to change voltage in Linux (so the regcache write
would hopefully be a noop), so maybe it wouldn't be _that_
inefficient...
-Doug
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-30 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=UpWEMSPUYOHmLQ0g_mF990kwn4_zm=ZCNttLKZiz7i=Q@mail.gmail.com>
On Wed, May 30, 2018 at 09:31:55AM -0700, Doug Anderson wrote:
> On Wed, May 30, 2018 at 9:13 AM, Mark Brown <broonie@kernel.org> wrote:
> > If we're just going to use the most recently set voltage then hopefully
> > the hardware already knew that, and it might not be the lowest available
> > voltage if the last consumer to get turned off was holding the voltage
> > higher.
> To circle back to the original point: the problem is that (IMHO) the
> hardware is doing the wrong thing by still counting Linux's vote for a
> voltage even though Linux also voted that the regulator should be
> disabled. So basically we're working around the hardware by
> pretending to vote for a dummy lower voltage whenever Linux wants the
> regulator disabled. From Linux's point of view everything works as
> normal--we just tell the hardware a falsehood so it doesn't count our
> vote for a voltage while the regulator is disabled.
Yeah, and I don't think that's unreasonable for the core to do - just
drop the voltage to the constraint minimum after it has turned off the
regulator, then recheck and raise if needed before it enables again.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/aed2a9fd/attachment.sig>
^ permalink raw reply
* [PATCH v4 0/2] regulator: add QCOM RPMh regulator driver
From: Mark Brown @ 2018-05-30 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1527040878.git.collinsd@codeaurora.org>
On Tue, May 22, 2018 at 07:43:16PM -0700, David Collins wrote:
> This patch series adds a driver and device tree binding documentation for
> PMIC regulator control via Resource Power Manager-hardened (RPMh) on some
> Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block
So, this is a very big driver and obviously it being RPM based it
doesn't look like other regulators which is causing problems, especially
when coupled with the desire to implement a bunch of more exotic
features like the mode setting. I think this review is going to go a
lot more smoothly if you split this up into a base driver with just
normal, standard stuff that doesn't add too many custom properties or
unusual ways of working and then a series of patches on top of that
adding things like the mode adjustment and interaction with other RPM
clients.
We've got other RPM based regulators in tree already so the baseline bit
shouldn't be too hard, that'll make the rest of the patches much smaller
and easier to review and mean that the bits that are simpler and easier
to cope with don't need to be reposted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/fd8d3adf/attachment.sig>
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530161311.GT6920@sirena.org.uk>
Hi,
On Wed, May 30, 2018 at 9:13 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 30, 2018 at 09:09:02AM -0700, Doug Anderson wrote:
>> On Wed, May 30, 2018 at 9:07 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > It needs something to tell it what the new voltage to set is.
>
>> The regulator driver has its own cache of what voltage was most
>> recently requested by Linux. It can use that, can't it?
>
> If we're just going to use the most recently set voltage then hopefully
> the hardware already knew that, and it might not be the lowest available
> voltage if the last consumer to get turned off was holding the voltage
> higher.
To circle back to the original point: the problem is that (IMHO) the
hardware is doing the wrong thing by still counting Linux's vote for a
voltage even though Linux also voted that the regulator should be
disabled. So basically we're working around the hardware by
pretending to vote for a dummy lower voltage whenever Linux wants the
regulator disabled. From Linux's point of view everything works as
normal--we just tell the hardware a falsehood so it doesn't count our
vote for a voltage while the regulator is disabled.
-Doug
^ permalink raw reply
* [PATCH v2 0/5] crypto: ccree: cleanup, fixes and R-Car enabling
From: Herbert Xu @ 2018-05-30 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527171551-21979-1-git-send-email-gilad@benyossef.com>
On Thu, May 24, 2018 at 03:19:05PM +0100, Gilad Ben-Yossef wrote:
> The patch set enables the use of CryptoCell found in some Renesas R-Car
> Salvator-X boards and fixes some driver issues uncovered that prevented
> to work properly.
>
> Changes from v1:
> - Properly fix the bug that caused us to read a bad signature register
> rather than dropping the check
> - Proper DT fields as indicated by Geert Uytterhoeven.
> - Better clock enabling as suggested by Geert Uytterhoeven.
>
> Note! the last two patches in the set depend on the
> "clk: renesas: r8a7795: Add CR clock" patch from Geert Uytterhoeven.
Patches 1-3 applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530162007.GU6920@sirena.org.uk>
Hi,
On Wed, May 30, 2018 at 9:20 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 30, 2018 at 09:12:25AM -0700, Doug Anderson wrote:
>> On Wed, May 30, 2018 at 8:50 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > No, I'm saying that I don't know why that property exists at all. This
>> > sounds like it's intended to be the amount of current the regulator can
>> > deliver in each mode which is normally a design property of the silicon.
>
>> Ah, got it. So the whole point here is to be able to implement either
>> the function "set_load" or the function "get_optimum_mode". We need
>> some sort of table to convert from current to mode. That's what this
>> table does.
>
> We do need that table, my expectation would be that this table would be
> in the driver as it's not something I'd expect to vary between different
> systems but rather be a property of the silicon design. No sense in
> every single board having to copy it in.
Ah, got it! I'd be OK with it being hardcoded in the driver.
At one point I think David was making the argument that some boards
have different noise needs for the rails and thus you might want to
change modes at different currents. I don't know if this is realistic
but I believe it was part of his original argument for why this needed
to be specified. If we can hardcode this in the driver I'm fine with
it... That would actually solve many of my objections too...
-Doug
^ permalink raw reply
* [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-30 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WVUmvPPd5BxXv9Sa_2CRPrrjQvYFyqroY-3fRr4f0Bzg@mail.gmail.com>
On Wed, May 30, 2018 at 09:12:25AM -0700, Doug Anderson wrote:
> On Wed, May 30, 2018 at 8:50 AM, Mark Brown <broonie@kernel.org> wrote:
> > No, I'm saying that I don't know why that property exists at all. This
> > sounds like it's intended to be the amount of current the regulator can
> > deliver in each mode which is normally a design property of the silicon.
> Ah, got it. So the whole point here is to be able to implement either
> the function "set_load" or the function "get_optimum_mode". We need
> some sort of table to convert from current to mode. That's what this
> table does.
We do need that table, my expectation would be that this table would be
in the driver as it's not something I'd expect to vary between different
systems but rather be a property of the silicon design. No sense in
every single board having to copy it in.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/e99e0527/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-30 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WVGu0f+=q-C9kiEmaLEUJqGY+Jbns83h72uF-9iasrUw@mail.gmail.com>
On Wed, May 30, 2018 at 09:09:02AM -0700, Doug Anderson wrote:
> On Wed, May 30, 2018 at 9:07 AM, Mark Brown <broonie@kernel.org> wrote:
> > It needs something to tell it what the new voltage to set is.
> The regulator driver has its own cache of what voltage was most
> recently requested by Linux. It can use that, can't it?
If we're just going to use the most recently set voltage then hopefully
the hardware already knew that, and it might not be the lowest available
voltage if the last consumer to get turned off was holding the voltage
higher.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/10a575f9/attachment.sig>
^ 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