* [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
* [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
* 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
* [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
* [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
* 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] 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
* [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 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 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 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 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 RFC] ARM: dts: add Raspberry Pi Compute Module and IO board
From: Eric Anholt @ 2018-05-30 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1670815145.72020.1526930907735@email.1und1.de>
Stefan Wahren <stefan.wahren@i2se.com> writes:
>> Eric Anholt <eric@anholt.net> hat am 21. Mai 2018 um 20:26 geschrieben:
>>
>>
>> Stefan Wahren <stefan.wahren@i2se.com> writes:
>>
>> > The Raspberry Pi Compute Module (CM1) is a SoM which contains a
>> > BCM2835 processor, 512 MB RAM and a 4 GB eMMC. There is also a carrier
>> > board which is called Compute Module IO Board.
>> >
>> > Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>> > ---
>> > arch/arm/boot/dts/Makefile | 1 +
>> > arch/arm/boot/dts/bcm2835-rpi-cm1-io1.dts | 92 +++++++++++++++++++++++++++++++
>> > arch/arm/boot/dts/bcm2835-rpi-cm1.dtsi | 34 ++++++++++++
>> > 3 files changed, 127 insertions(+)
>> > create mode 100644 arch/arm/boot/dts/bcm2835-rpi-cm1-io1.dts
>> > create mode 100644 arch/arm/boot/dts/bcm2835-rpi-cm1.dtsi
>> >
>> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> > index ec2024e..a9883e8 100644
>> > --- a/arch/arm/boot/dts/Makefile
>> > +++ b/arch/arm/boot/dts/Makefile
>> > @@ -73,6 +73,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
>> > bcm2835-rpi-b-rev2.dtb \
>> > bcm2835-rpi-b-plus.dtb \
>> > bcm2835-rpi-a-plus.dtb \
>> > + bcm2835-rpi-cm1-io1.dtb \
>> > bcm2836-rpi-2-b.dtb \
>> > bcm2837-rpi-3-b.dtb \
>> > bcm2837-rpi-3-b-plus.dtb \
>> > diff --git a/arch/arm/boot/dts/bcm2835-rpi-cm1-io1.dts b/arch/arm/boot/dts/bcm2835-rpi-cm1-io1.dts
>> > new file mode 100644
>> > index 0000000..4d9aa22
>> > --- /dev/null
>> > +++ b/arch/arm/boot/dts/bcm2835-rpi-cm1-io1.dts
>> > @@ -0,0 +1,92 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +/dts-v1/;
>> > +#include "bcm2835-rpi-cm1.dtsi"
>> > +#include "bcm283x-rpi-usb-host.dtsi"
>> > +
>> > +/ {
>> > + compatible = "raspberrypi,compute-module", "brcm,bcm2835";
>> > + model = "Raspberry Pi Compute Module IO board rev1";
>> > +};
>> > +
>> > +&dsi1 {
>> > + status = "okay";
>> > +};
>> > +
>> > +&gpio {
>> > + /*
>> > + * This is based on the official GPU firmware DT blob.
>> > + *
>> > + * Legend:
>> > + * "NC" = not connected (no rail from the SoC)
>> > + * "FOO" = GPIO line named "FOO" on the schematic
>> > + * "FOO_N" = GPIO line named "FOO" on schematic, active low
>> > + */
>> > + gpio-line-names = "GPIO0",
>> > + "GPIO1",
>> > + "GPIO2",
>> > + "GPIO3",
>> > + "GPIO4",
>> > + "GPIO5",
>> > + "GPIO6",
>> > + "GPIO7",
>> > + "GPIO8",
>> > + "GPIO9",
>> > + "GPIO10",
>> > + "GPIO11",
>> > + "GPIO12",
>> > + "GPIO13",
>> > + "GPIO14",
>> > + "GPIO15",
>> > + "GPIO16",
>> > + "GPIO17",
>> > + "GPIO18",
>> > + "GPIO19",
>> > + "GPIO20",
>> > + "GPIO21",
>> > + "GPIO22",
>> > + "GPIO23",
>> > + "GPIO24",
>> > + "GPIO25",
>> > + "GPIO26",
>> > + "GPIO27",
>> > + "GPIO28",
>> > + "GPIO29",
>> > + "GPIO30",
>> > + "GPIO31",
>> > + "GPIO32",
>> > + "GPIO33",
>> > + "GPIO34",
>> > + "GPIO35",
>> > + "GPIO36",
>> > + "GPIO37",
>> > + "GPIO38",
>> > + "GPIO39",
>> > + "GPIO40",
>> > + "GPIO41",
>> > + "GPIO42",
>> > + "GPIO43",
>> > + "GPIO44",
>> > + "GPIO45",
>> > + "HDMI_HPD_N",
>> > + /* Also used as ACT LED */
>> > + "EMMC_EN_N",
>> > + /* Used by eMMC */
>> > + "SD_CLK_R",
>> > + "SD_CMD_R",
>> > + "SD_DATA0_R",
>> > + "SD_DATA1_R",
>> > + "SD_DATA2_R",
>> > + "SD_DATA3_R";
>> > +
>> > + pinctrl-0 = <&gpioout &alt0>;
>> > +};
>> > +
>> > +&hdmi {
>> > + hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>;
>> > +};
>>
>> I think this should be ACTIVE_LOW, since it's "HDMI_HPD_N_1V8", right?
>
> I just copy & paste from the rpi-4.14/bcm2708-rpi-cm.dts. I thought
> the HDMI interface on my IO board is broken, but maybe this is a
> downstream issue.
Downstream gets HDMI wrong pretty frequently, so it's not surprising.
Watching xrandr -q with X11 running and plugging and unplugging HDMI can
help figure out whether we got the polarity right. I think you can also
do this with libdrm's modetest, if you don't have X11 up.
>> > +
>> > +&uart0 {
>> > + pinctrl-names = "default";
>> > + pinctrl-0 = <&uart0_gpio14>;
>> > + status = "okay";
>> > +};
>> > diff --git a/arch/arm/boot/dts/bcm2835-rpi-cm1.dtsi b/arch/arm/boot/dts/bcm2835-rpi-cm1.dtsi
>> > new file mode 100644
>> > index 0000000..ef22c2d
>> > --- /dev/null
>> > +++ b/arch/arm/boot/dts/bcm2835-rpi-cm1.dtsi
>> > @@ -0,0 +1,34 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +/dts-v1/;
>> > +#include "bcm2835.dtsi"
>> > +#include "bcm2835-rpi.dtsi"
>> > +
>> > +/ {
>> > + leds {
>> > + act {
>> > + gpios = <&gpio 47 GPIO_ACTIVE_LOW>;
>> > + };
>> > + };
>> > +
>> > + reg_3v3: fixed-regulator {
>> > + compatible = "regulator-fixed";
>> > + regulator-name = "3V3";
>> > + regulator-min-microvolt = <3300000>;
>> > + regulator-max-microvolt = <3300000>;
>> > + regulator-always-on;
>> > + };
>> > +
>> > + reg_1v8: fixed-regulator {
>> > + compatible = "regulator-fixed";
>> > + regulator-name = "1V8";
>> > + regulator-min-microvolt = <1800000>;
>> > + regulator-max-microvolt = <1800000>;
>> > + regulator-always-on;
>> > + };
>> > +};
>> > +
>> > +&sdhost {
>> > + non-removable;
>> > + vmmc-supply = <®_3v3>;
>> > + vqmmc-supply = <®_1v8>;
>> > +};
>>
>> Also, looking at some datasheets I have laying around, it says "eMMC I/O
>> Voltage fixed at 1V8" -- is this regulator setup right, in that case?
>
> Usually an eMMC has 2 different voltage sources:
> vqmmc-supply -> supply node for IO line power (usually switchable, but fixed on Compute Module)
> vmmc-supply -> supply node for card's power (usually fixed)
>
> Do you have a specific concern (voltage, naming)?
It was just "I was reviewing, and this stood out." That explanation
there seems sufficient to me. 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/a42a5482/attachment.sig>
^ permalink raw reply
* [PATCH 00/12] introduce support for early platform drivers
From: Michael Turquette @ 2018-05-30 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJ=DdkDR3LtnTMHPUpwaUbjPEBgkaCV8ja+p-mTvWZuYA@mail.gmail.com>
Hi Rob,
Quoting Rob Herring (2018-05-14 06:20:57)
> On Mon, May 14, 2018 at 6:38 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > 2018-05-11 22:13 GMT+02:00 Rob Herring <robh+dt@kernel.org>:
> >> On Fri, May 11, 2018 at 11:20 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >>> This series is a follow-up to the RFC[1] posted a couple days ago.
> >>>
> >>> NOTE: this series applies on top of my recent patches[2] that move the previous
> >>> implementation of early platform devices to arch/sh.
> >>>
> >>> Problem:
> >>>
> >>> Certain class of devices, such as timers, certain clock drivers and irq chip
> >>> drivers need to be probed early in the boot sequence. The currently preferred
> >>> approach is using one of the OF_DECLARE() macros. This however does not create
> >>> a platform device which has many drawbacks - such as not being able to use
> >>> devres routines, dev_ log functions or no way of deferring the init OF function
> >>> if some other resources are missing.
> >>
> >> I skimmed though this and it doesn't look horrible (how's that for
> >> positive feedback? ;) ). But before going into the details, I think
> >> first there needs to be agreement this is the right direction.
> >>
> >> The question does remain though as to whether this class of devices
> >> should be platform drivers. They can't be modules. They can't be
> >> hotplugged. Can they be runtime-pm enabled? So the advantage is ...
> >>
> >
> > The main (but not the only) advantage for drivers that can both be
> > platform drivers and OF_DECLARE drivers is that we get a single entry
> > point and can reuse code without resorting to checking if (!dev). It
> > results in more consistent code base. Another big advantage is
> > consolidation of device tree and machine code for SoC drivers used in
> > different boards of which some are still using board files and others
> > are defined in DT (see: DaVinci).
> >
> >> I assume that the clock maintainers had some reason to move clocks to
> >> be platform drivers. It's just not clear to me what that was.
> >>
> >>> For drivers that use both platform drivers and OF_DECLARE the situation is even
> >>> more complicated as the code needs to take into account that there can possibly
> >>> be no struct device present. For a specific use case that we're having problems
> >>> with, please refer to the recent DaVinci common-clock conversion patches and
> >>> the nasty workaround that this problem implies[3].
> >>
> >> So devm_kzalloc will work with this solution? Why did we need
> >> devm_kzalloc in the first place? The clocks can never be removed and
> >> cleaning up on error paths is kind of pointless. The system would be
> >> hosed, right?
> >>
> >
> > It depends - not all clocks are necessary for system to boot.
>
> That doesn't matter. You have a single driver for all/most of the
> clocks, so the driver can't be removed.
-ECANOFWORMS
A couple of quick rebuttals, but I imagine we're going to disagree on
the platform_driver thing as a matter of taste no matter what...
1) There should be multiple clk drivers in a properly modeled system.
Some folks still incorrectly put all clocks in a system into a single
driver because That's How We Used To Do It, and some systems (simpler
ones) really only have a single clock generator IP block.
Excepting those two reasons above, we really should have separate
drivers for clocks controlled by the PMIC, for the (one or more) clock
generator blocks inside of the AP/SoC, and then even more for the
drivers that map to IP blocks that have their own clock gens.
Good examples of the latter are display controllers that generate their
own PLL and pixel clock. Or MMC controllers that have a
runtime-programmable clock divider. Examples of these are merged into
mainline.
2) Stephen and I wanted clock drivers to actually be represented in the
driver model. There were these gigantic clock drivers that exclusively
used CLK_OF_DECLARE and they just sort of floated out there in the
ether... no representation in sysfs, no struct device to map onto a
clock controller struct, etc.
I'd be happy to hear why you think that platform_driver is a bad fit for
a device driver that generally manages memory-mapped system resources
that are part of the system glue and not really tied to a specific bus.
Sounds like a good fit to me.
If platform_driver doesn't handle the early boot thing well, that tells
me that we have a problem to solve in platform_driver, not in the clk
subsystem or drivers.
3) Lots of clock controllers should be loadable modules. E.g. i2c clock
expanders, potentially external PMIC-related drivers, external audio
codecs, etc.
Again, repeating my point #1 above, just because many platforms have a
monolithic clock driver does not mean that this is the Right Way to do
it.
Best regards,
Mike
>
> >>> We also used to have an early platform drivers implementation but they were not
> >>> integrated with the linux device model at all - they merely used the same data
> >>> structures. The users could not use devres, defer probe and the early devices
> >>> never became actual platform devices later on.
> >>>
> >>> Proposed solution:
> >>>
> >>> This series aims at solving this problem by (re-)introducing the concept of
> >>> early platform drivers and devices - this time however in a way that seamlessly
> >>> integrates with the existing platform drivers and also offers device-tree
> >>> support.
> >>>
> >>> The idea is to provide a way for users to probe devices early, while already
> >>> being able to use devres, devices resources and properties and also deferred
> >>> probing.
> >>>
> >>> New structures are introduced: the early platform driver contains the
> >>> early_probe callback which has the same signature as regular platform_device
> >>> probe. This callback is called early on. The user can have both the early and
> >>> regular probe speficied or only one of them and they both receive the same
> >>> platform device object as argument. Any device data allocated early will be
> >>> carried over to the normal probe.
> >>>
> >>> The architecture code is responsible for calling early_platform_start() in
> >>> which the early drivers will be registered and devices populated from DT.
> >>
> >> Can we really do this in one spot for different devices (clk, timers,
> >> irq). The sequence is all very carefully crafted. Platform specific
> >> hooks is another thing to consider.
> >>
> >
> > This is why I added support for early probe deferral - so that we can
> > stop caring for the order as long as the drivers are aware of other
> > resources they need and we call early_platform_start() the moment the
> > earliest of the early devices is needed.
>
> Deferred probe helps for inter-device dependencies, but I am more
> concerned about timing of trying to register clocksources, irqchips,
> etc. What happens if we probe drivers before the infrastructure is
> initialized?
>
> Rob
^ permalink raw reply
* [PATCH 6/9] clk: davinci: pll: allow dev == NULL
From: Michael Turquette @ 2018-05-30 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525181150.17873-7-david@lechnology.com>
Hi David,
Quoting David Lechner (2018-05-25 11:11:47)
> This modifies the TI Davinci PLL clock driver to allow for the case
> when dev == NULL. On some (most) SoCs that use this driver, the PLL
> clock needs to be registered during early boot because it is used
> for clocksource/clkevent and there will be no platform device available.
A lot of this stuff feels like a step backwards. E.g:
> diff --git a/drivers/clk/davinci/pll.c b/drivers/clk/davinci/pll.c
> index 23a24c944f1d..2eb981e61185 100644
> --- a/drivers/clk/davinci/pll.c
> +++ b/drivers/clk/davinci/pll.c
> @@ -11,6 +11,7 @@
>
> #include <linux/clk-provider.h>
> #include <linux/clk.h>
> +#include <linux/clk/davinci.h>
> #include <linux/delay.h>
> #include <linux/err.h>
> #include <linux/io.h>
> @@ -223,6 +224,7 @@ static const struct clk_ops dm365_pll_ops = {
>
> /**
> * davinci_pll_div_register - common *DIV clock implementation
> + * @dev: The PLL platform device or NULL
> * @name: the clock name
> * @parent_name: the parent clock name
> * @reg: the *DIV register
> @@ -240,17 +242,21 @@ static struct clk *davinci_pll_div_register(struct device *dev,
> const struct clk_ops *divider_ops = &clk_divider_ops;
> struct clk_gate *gate;
> struct clk_divider *divider;
> + struct clk *clk;
> + int ret;
>
> - gate = devm_kzalloc(dev, sizeof(*gate), GFP_KERNEL);
> + gate = kzalloc(sizeof(*gate), GFP_KERNEL);
> if (!gate)
> return ERR_PTR(-ENOMEM);
>
> gate->reg = reg;
> gate->bit_idx = DIV_ENABLE_SHIFT;
>
> - divider = devm_kzalloc(dev, sizeof(*divider), GFP_KERNEL);
> - if (!divider)
> - return ERR_PTR(-ENOMEM);
> + divider = kzalloc(sizeof(*divider), GFP_KERNEL);
> + if (!divider) {
> + ret = -ENOMEM;
> + goto err_free_gate;
> + }
>
> divider->reg = reg;
> divider->shift = DIV_RATIO_SHIFT;
Oh no my poor devm_ helpers!
I understand that we need to support early boot drivers better, so this
patch can be merged.
However I'm curious if you're tracking Bartosz's early_platform_driver
efforts? Converting to that if it is ever merged would likely be
cleaner:
https://lkml.kernel.org/r/20180511162028.20616-1-brgl at bgdev.pl
Best regards,
Mike
^ permalink raw reply
* [PATCH 04/13] staging: vc04_services: no need to check debugfs return values
From: Eric Anholt @ 2018-05-30 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529142947.3250-4-gregkh@linuxfoundation.org>
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Clean up the vchiq_arm code by not caring about the value of debugfs
> calls. This ends up removing a number of lines of code that are not
> needed.
>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Dan Carpenter <dan.carpenter@oracle.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Keerthi Reddy <keerthigd4990@gmail.com>
> Cc: linux-rpi-kernel at lists.infradead.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> .../interface/vchiq_arm/vchiq_arm.c | 13 +---
> .../interface/vchiq_arm/vchiq_debugfs.c | 72 +++----------------
> .../interface/vchiq_arm/vchiq_debugfs.h | 4 +-
> 3 files changed, 15 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
> index 766b4fe5f32c..103fec955e2c 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
> @@ -314,31 +284,13 @@ void vchiq_debugfs_remove_instance(VCHIQ_INSTANCE_T instance)
> debugfs_remove_recursive(node->dentry);
> }
>
> -int vchiq_debugfs_init(void)
> +void vchiq_debugfs_init(void)
> {
> - BUG_ON(debugfs_info.vchiq_cfg_dir != NULL);
> -
> debugfs_info.vchiq_cfg_dir = debugfs_create_dir("vchiq", NULL);
> - if (debugfs_info.vchiq_cfg_dir == NULL)
> - goto fail;
> -
I think now that we allow successful probe with this value NULL, module
remove could vchiq_debugfs_deinit() -> vchiq_debugfs_top() -> BUG_ON().
I think the right solution would be to just drop that BUG_ON(). With
that change (and probably just garbage-collecting that function), this
will be enthusiastically:
Reviewed-by: Eric Anholt <eric@anholt.net>
-------------- 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/2fb101af/attachment-0001.sig>
^ permalink raw reply
* [PATCH 6/9] clk: davinci: pll: allow dev == NULL
From: David Lechner @ 2018-05-30 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530194559.982.42844@harbor.lan>
On 05/30/2018 02:46 PM, Michael Turquette wrote:
> Hi David,
>
> Quoting David Lechner (2018-05-25 11:11:47)
>> This modifies the TI Davinci PLL clock driver to allow for the case
>> when dev == NULL. On some (most) SoCs that use this driver, the PLL
>> clock needs to be registered during early boot because it is used
>> for clocksource/clkevent and there will be no platform device available.
>
> A lot of this stuff feels like a step backwards. E.g:
>
>> diff --git a/drivers/clk/davinci/pll.c b/drivers/clk/davinci/pll.c
>> index 23a24c944f1d..2eb981e61185 100644
>> --- a/drivers/clk/davinci/pll.c
>> +++ b/drivers/clk/davinci/pll.c
>> @@ -11,6 +11,7 @@
>>
>> #include <linux/clk-provider.h>
>> #include <linux/clk.h>
>> +#include <linux/clk/davinci.h>
>> #include <linux/delay.h>
>> #include <linux/err.h>
>> #include <linux/io.h>
>> @@ -223,6 +224,7 @@ static const struct clk_ops dm365_pll_ops = {
>>
>> /**
>> * davinci_pll_div_register - common *DIV clock implementation
>> + * @dev: The PLL platform device or NULL
>> * @name: the clock name
>> * @parent_name: the parent clock name
>> * @reg: the *DIV register
>> @@ -240,17 +242,21 @@ static struct clk *davinci_pll_div_register(struct device *dev,
>> const struct clk_ops *divider_ops = &clk_divider_ops;
>> struct clk_gate *gate;
>> struct clk_divider *divider;
>> + struct clk *clk;
>> + int ret;
>>
>> - gate = devm_kzalloc(dev, sizeof(*gate), GFP_KERNEL);
>> + gate = kzalloc(sizeof(*gate), GFP_KERNEL);
>> if (!gate)
>> return ERR_PTR(-ENOMEM);
>>
>> gate->reg = reg;
>> gate->bit_idx = DIV_ENABLE_SHIFT;
>>
>> - divider = devm_kzalloc(dev, sizeof(*divider), GFP_KERNEL);
>> - if (!divider)
>> - return ERR_PTR(-ENOMEM);
>> + divider = kzalloc(sizeof(*divider), GFP_KERNEL);
>> + if (!divider) {
>> + ret = -ENOMEM;
>> + goto err_free_gate;
>> + }
>>
>> divider->reg = reg;
>> divider->shift = DIV_RATIO_SHIFT;
>
> Oh no my poor devm_ helpers!
>
> I understand that we need to support early boot drivers better, so this
> patch can be merged.
>
> However I'm curious if you're tracking Bartosz's early_platform_driver
> efforts? Converting to that if it is ever merged would likely be
> cleaner:
>
> https://lkml.kernel.org/r/20180511162028.20616-1-brgl at bgdev.pl
>
> Best regards,
> Mike
>
Yes. In fact, this is what got Bartosz working on it in the first
place. :-)
^ permalink raw reply
* [PATCH v2] dmaengine: pxa: add a default requestor policy
From: Robert Jarzmik @ 2018-05-30 20:00 UTC (permalink / raw)
To: linux-arm-kernel
As what former drcmr -1 value meant, add a this as a default to each
channel, ie. that by default no requestor line is used.
This is specifically used for network drivers smc91x and smc911x, and
needed for their port to slave maps.
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
Since v1: changed -1 to U32_MAX
---
drivers/dma/pxa_dma.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
index 9505334f9c6e..b31c28b67ad3 100644
--- a/drivers/dma/pxa_dma.c
+++ b/drivers/dma/pxa_dma.c
@@ -762,6 +762,8 @@ static void pxad_free_chan_resources(struct dma_chan *dchan)
dma_pool_destroy(chan->desc_pool);
chan->desc_pool = NULL;
+ chan->drcmr = U32_MAX;
+ chan->prio = PXAD_PRIO_LOWEST;
}
static void pxad_free_desc(struct virt_dma_desc *vd)
@@ -1386,6 +1388,9 @@ static int pxad_init_dmadev(struct platform_device *op,
c = devm_kzalloc(&op->dev, sizeof(*c), GFP_KERNEL);
if (!c)
return -ENOMEM;
+
+ c->drcmr = U32_MAX;
+ c->prio = PXAD_PRIO_LOWEST;
c->vc.desc_free = pxad_free_desc;
vchan_init(&c->vc, &pdev->slave);
init_waitqueue_head(&c->wq_state);
--
2.11.0
^ permalink raw reply related
* [PATCH 0/9] clk: davinci: outstanding fixes
From: Michael Turquette @ 2018-05-30 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525181150.17873-1-david@lechnology.com>
Hi David,
Quoting David Lechner (2018-05-25 11:11:41)
> This is a resend of all of the outstanding DaVinci clock patches plus one new
> patch. All of the patches (except the new one) have been reviewed and tested
> by someone other than me.
>
> The new patch ("clk: davinci: Fix link errors when not all SoCs are enabled")
> should be fairly trivial.
>
> I am resending them all in one series to hopefully make it easier to get them
> picked up by having them in the correct order to avoid merge conflicts. This
> series is based on the clk/clk-davinci-psc-da830 branch.
I picked them all and pushed to clk/clk-davinci based on -rc1. There are
some comments on the individual patches, all of which are of the "please
revisit this and fix it up later" variety.
Going forward I'm happy for you and/or Sekhar to send clk PRs to Stephen
and myself. The same rules apply for PRs: all patches need to be posted
to the list the old fashioned way for review. But PRs make our lives a
bit easier, especially when dealing with chip variants from the same SoC
family like we have with davinci.
Best regards,
Mike
>
> David Lechner (7):
> clk: davinci: pll-dm355: drop pll2_sysclk2
> clk: davinci: pll-dm355: fix SYSCLKn parent names
> clk: davinci: psc-dm355: fix ASP0/1 clkdev lookups
> clk: davinci: pll: allow dev == NULL
> clk: davinci: da850-pll: change PLL0 to CLK_OF_DECLARE
> clk: davinci: psc: allow for dev == NULL
> clk: davinci: Fix link errors when not all SoCs are enabled
>
> Sekhar Nori (2):
> clk: davinci: pll-dm646x: keep PLL2 SYSCLK1 always enabled
> clk: davinci: psc-dm365: fix few clocks
>
> drivers/clk/davinci/pll-da830.c | 5 +-
> drivers/clk/davinci/pll-da850.c | 37 ++--
> drivers/clk/davinci/pll-dm355.c | 22 ++-
> drivers/clk/davinci/pll-dm365.c | 9 +-
> drivers/clk/davinci/pll-dm644x.c | 9 +-
> drivers/clk/davinci/pll-dm646x.c | 11 +-
> drivers/clk/davinci/pll.c | 299 +++++++++++++++++++++----------
> drivers/clk/davinci/pll.h | 41 +++--
> drivers/clk/davinci/psc-dm355.c | 7 +-
> drivers/clk/davinci/psc-dm365.c | 22 ++-
> drivers/clk/davinci/psc-dm644x.c | 3 +-
> drivers/clk/davinci/psc-dm646x.c | 3 +-
> drivers/clk/davinci/psc.c | 72 ++++++--
> drivers/clk/davinci/psc.h | 12 ++
> include/linux/clk/davinci.h | 40 +++++
> 15 files changed, 418 insertions(+), 174 deletions(-)
> create mode 100644 include/linux/clk/davinci.h
>
> --
> 2.17.0
>
^ permalink raw reply
* [RESEND v2] dmaengine: pxa: add a default requestor policy
From: Robert Jarzmik @ 2018-05-30 20:12 UTC (permalink / raw)
To: linux-arm-kernel
As what former drcmr -1 value meant, add a this as a default to each
channel, ie. that by default no requestor line is used.
This is specifically used for network drivers smc91x and smc911x, and
needed for their port to slave maps.
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
Since v1: changed -1 to U32_MAX
---
drivers/dma/pxa_dma.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
index 9505334f9c6e..b31c28b67ad3 100644
--- a/drivers/dma/pxa_dma.c
+++ b/drivers/dma/pxa_dma.c
@@ -762,6 +762,8 @@ static void pxad_free_chan_resources(struct dma_chan *dchan)
dma_pool_destroy(chan->desc_pool);
chan->desc_pool = NULL;
+ chan->drcmr = U32_MAX;
+ chan->prio = PXAD_PRIO_LOWEST;
}
static void pxad_free_desc(struct virt_dma_desc *vd)
@@ -1386,6 +1388,9 @@ static int pxad_init_dmadev(struct platform_device *op,
c = devm_kzalloc(&op->dev, sizeof(*c), GFP_KERNEL);
if (!c)
return -ENOMEM;
+
+ c->drcmr = U32_MAX;
+ c->prio = PXAD_PRIO_LOWEST;
c->vc.desc_free = pxad_free_desc;
vchan_init(&c->vc, &pdev->slave);
init_waitqueue_head(&c->wq_state);
--
2.11.0
^ permalink raw reply related
* [PATCH] kbuild: add machine size to CHEKCFLAGS
From: Luc Van Oostenryck @ 2018-05-30 20:48 UTC (permalink / raw)
To: linux-arm-kernel
By default, sparse assumes a 64bit machine when compiled on x86-64
and 32bit when compiled on anything else.
This can of course create all sort of problems for the other archs, like
issuing false warnings ('shift too big (32) for type unsigned long'), or
worse, failing to emit legitimate warnings.
Fix this by adding the -m32/-m64 flag, depending on CONFIG_64BIT,
to CHECKFLAGS in the main Makefile (and so for all archs).
Also, remove the now unneeded -m32/-m64 in arch specific Makefiles.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
---
Makefile | 3 +++
arch/alpha/Makefile | 2 +-
arch/arm/Makefile | 2 +-
arch/arm64/Makefile | 2 +-
arch/ia64/Makefile | 2 +-
arch/mips/Makefile | 3 ---
arch/parisc/Makefile | 2 +-
arch/sparc/Makefile | 2 +-
arch/x86/Makefile | 2 +-
9 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Makefile b/Makefile
index 6c6610913..18379987c 100644
--- a/Makefile
+++ b/Makefile
@@ -881,6 +881,9 @@ endif
# insure the checker run with the right endianness
CHECKFLAGS += $(if $(CONFIG_CPU_BIG_ENDIAN),-mbig-endian,-mlittle-endian)
+# the checker needs the correct machine size
+CHECKFLAGS += $(if $(CONFIG_64BIT),-m64,-m32)
+
# Default kernel image to build when no specific target is given.
# KBUILD_IMAGE may be overruled on the command line or
# set in the environment
diff --git a/arch/alpha/Makefile b/arch/alpha/Makefile
index 2cc3cc519..c5ec8c09c 100644
--- a/arch/alpha/Makefile
+++ b/arch/alpha/Makefile
@@ -11,7 +11,7 @@
NM := $(NM) -B
LDFLAGS_vmlinux := -static -N #-relax
-CHECKFLAGS += -D__alpha__ -m64
+CHECKFLAGS += -D__alpha__
cflags-y := -pipe -mno-fp-regs -ffixed-8
cflags-y += $(call cc-option, -fno-jump-tables)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index e4e537f27..f32a5468d 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -135,7 +135,7 @@ endif
KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
-CHECKFLAGS += -D__arm__ -m32
+CHECKFLAGS += -D__arm__
#Default value
head-y := arch/arm/kernel/head$(MMUEXT).o
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 87f7d2f9f..3c353b471 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -78,7 +78,7 @@ LDFLAGS += -maarch64linux
UTS_MACHINE := aarch64
endif
-CHECKFLAGS += -D__aarch64__ -m64
+CHECKFLAGS += -D__aarch64__
ifeq ($(CONFIG_ARM64_MODULE_PLTS),y)
KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/arm64/kernel/module.lds
diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile
index 2dd7f519a..45f59808b 100644
--- a/arch/ia64/Makefile
+++ b/arch/ia64/Makefile
@@ -18,7 +18,7 @@ READELF := $(CROSS_COMPILE)readelf
export AWK
-CHECKFLAGS += -m64 -D__ia64=1 -D__ia64__=1 -D_LP64 -D__LP64__
+CHECKFLAGS += -D__ia64=1 -D__ia64__=1 -D_LP64 -D__LP64__
OBJCOPYFLAGS := --strip-all
LDFLAGS_vmlinux := -static
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index 5e9fce076..e2122cca4 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -309,9 +309,6 @@ ifdef CONFIG_MIPS
CHECKFLAGS += $(shell $(CC) $(KBUILD_CFLAGS) -dM -E -x c /dev/null | \
egrep -vw '__GNUC_(|MINOR_|PATCHLEVEL_)_' | \
sed -e "s/^\#define /-D'/" -e "s/ /'='/" -e "s/$$/'/" -e 's/\$$/&&/g')
-ifdef CONFIG_64BIT
-CHECKFLAGS += -m64
-endif
endif
OBJCOPYFLAGS += --remove-section=.reginfo
diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
index 348ae4779..714284ea6 100644
--- a/arch/parisc/Makefile
+++ b/arch/parisc/Makefile
@@ -28,7 +28,7 @@ export LIBGCC
ifdef CONFIG_64BIT
UTS_MACHINE := parisc64
-CHECKFLAGS += -D__LP64__=1 -m64
+CHECKFLAGS += -D__LP64__=1
CC_ARCHES = hppa64
LD_BFD := elf64-hppa-linux
else # 32-bit
diff --git a/arch/sparc/Makefile b/arch/sparc/Makefile
index edac927e4..966a13d2b 100644
--- a/arch/sparc/Makefile
+++ b/arch/sparc/Makefile
@@ -39,7 +39,7 @@ else
# sparc64
#
-CHECKFLAGS += -D__sparc__ -D__sparc_v9__ -D__arch64__ -m64
+CHECKFLAGS += -D__sparc__ -D__sparc_v9__ -D__arch64__
LDFLAGS := -m elf64_sparc
export BITS := 64
UTS_MACHINE := sparc64
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 60135cbd9..f0a6ea224 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -94,7 +94,7 @@ ifeq ($(CONFIG_X86_32),y)
else
BITS := 64
UTS_MACHINE := x86_64
- CHECKFLAGS += -D__x86_64__ -m64
+ CHECKFLAGS += -D__x86_64__
biarch := -m64
KBUILD_AFLAGS += -m64
--
2.17.0
^ permalink raw reply related
* linux-next: manual merge of the regulator tree with the arm-soc tree
From: Janusz Krzysztofik @ 2018-05-30 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530150711.2c7c1fe9@canb.auug.org.au>
On Wednesday, May 30, 2018 7:07:11 AM CEST Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the regulator tree got a conflict in:
>
> arch/arm/mach-omap1/board-ams-delta.c
>
> between commit:
>
> 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables")
>
> from the arm-soc tree and commit:
>
> 6059577cb28d ("regulator: fixed: Convert to use GPIO descriptor only")
>
> from the regulator tree.
>
> I fixed it up (see below - it may be better done) and can carry the fix
> as necessary.
Hi Stephen,
Your fix looks pretty good to me, but anyway, I will test it and confirm in a
day or two, as soon as I have access to the device.
Thanks,
Janusz
^ permalink raw reply
* [PATCH v7 00/10] drivers: Introduce firmware dnd clock river for ZynqMP core
From: Jolly Shah @ 2018-05-30 20:55 UTC (permalink / raw)
To: linux-arm-kernel
v7:
- Removed xilinx specific clock debugfs API support
- Added reviewed-by tags for FW and clock bindings
- Updated clock node name to clock-controller
v6:
- Broke patch series to have base FW driver and Clock driver user
- Incorporated code review comments from last FW and Clock driver patch series. Discussed below:
https://patchwork.kernel.org/patch/10230759/
https://patchwork.kernel.org/patch/10250047/
v5:
- Added ATF version check support
- Updated some functions to be static
- Minor function name corrections
v4:
- Changed clock setrate/getrate API prototype to support 64 bit rate
- Defined macros for get_node_status return values
- Moved DT node as a child of firmware
- Changed debugfs APIs to return data to debugfs buffer instead of dumping to kernel log
- Minor changes to incorporate other review comments from v3 patch series
v3:
- added some fixes to firmware-ggs.c
- updated pinmux get/set function argument names to specify function id instead of node id
- added new pinctrl query macros
- incorporated review comments from v2 patch series
v2:
- change SPDX-License-Identifier license text style
- split patch into multiple patches
- Updated copyrights
- Added ABI documentation
- incorporated logical review comments from previuos patch. Discussed below:
https://patchwork.kernel.org/patch/10150665/
Jolly Shah (1):
drivers: clk: Add ZynqMP clock driver
Rajan Vaja (9):
dt-bindings: firmware: Add bindings for ZynqMP firmware
firmware: xilinx: Add Zynqmp firmware driver
firmware: xilinx: Add zynqmp IOCTL API for device control
firmware: xilinx: Add query data API
firmware: xilinx: Add clock APIs
firmware: xilinx: Add debugfs interface
firmware: xilinx: Add debugfs for IOCTL API
firmware: xilinx: Add debugfs for query data API
dt-bindings: clock: Add bindings for ZynqMP clock driver
.../firmware/xilinx/xlnx,zynqmp-firmware.txt | 82 +++
arch/arm64/Kconfig.platforms | 1 +
drivers/clk/Kconfig | 1 +
drivers/clk/Makefile | 1 +
drivers/clk/zynqmp/Kconfig | 11 +
drivers/clk/zynqmp/Makefile | 4 +
drivers/clk/zynqmp/clk-gate-zynqmp.c | 146 ++++
drivers/clk/zynqmp/clk-mux-zynqmp.c | 150 +++++
drivers/clk/zynqmp/clk-zynqmp.h | 53 ++
drivers/clk/zynqmp/clkc.c | 737 +++++++++++++++++++++
drivers/clk/zynqmp/divider.c | 219 ++++++
drivers/clk/zynqmp/pll.c | 345 ++++++++++
drivers/firmware/Kconfig | 1 +
drivers/firmware/Makefile | 1 +
drivers/firmware/xilinx/Kconfig | 23 +
drivers/firmware/xilinx/Makefile | 5 +
drivers/firmware/xilinx/zynqmp-debug.c | 249 +++++++
drivers/firmware/xilinx/zynqmp-debug.h | 22 +
drivers/firmware/xilinx/zynqmp.c | 562 ++++++++++++++++
include/dt-bindings/clock/xlnx,zynqmp-clk.h | 116 ++++
include/linux/firmware/xlnx-zynqmp.h | 115 ++++
21 files changed, 2844 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
create mode 100644 drivers/clk/zynqmp/Kconfig
create mode 100644 drivers/clk/zynqmp/Makefile
create mode 100644 drivers/clk/zynqmp/clk-gate-zynqmp.c
create mode 100644 drivers/clk/zynqmp/clk-mux-zynqmp.c
create mode 100644 drivers/clk/zynqmp/clk-zynqmp.h
create mode 100644 drivers/clk/zynqmp/clkc.c
create mode 100644 drivers/clk/zynqmp/divider.c
create mode 100644 drivers/clk/zynqmp/pll.c
create mode 100644 drivers/firmware/xilinx/Kconfig
create mode 100644 drivers/firmware/xilinx/Makefile
create mode 100644 drivers/firmware/xilinx/zynqmp-debug.c
create mode 100644 drivers/firmware/xilinx/zynqmp-debug.h
create mode 100644 drivers/firmware/xilinx/zynqmp.c
create mode 100644 include/dt-bindings/clock/xlnx,zynqmp-clk.h
create mode 100644 include/linux/firmware/xlnx-zynqmp.h
--
2.7.4
^ permalink raw reply
* [PATCH v7 01/10] dt-bindings: firmware: Add bindings for ZynqMP firmware
From: Jolly Shah @ 2018-05-30 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527713725-1086-1-git-send-email-jollys@xilinx.com>
From: Rajan Vaja <rajanv@xilinx.com>
Add documentation to describe Xilinx ZynqMP firmware driver
bindings. Firmware driver provides an interface to firmware
APIs. Interface APIs can be used by any driver to communicate
to PMUFW (Platform Management Unit).
Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
Signed-off-by: Jolly Shah <jollys@xilinx.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../firmware/xilinx/xlnx,zynqmp-firmware.txt | 29 ++++++++++++++++++++++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
new file mode 100644
index 0000000..1b431d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
@@ -0,0 +1,29 @@
+-----------------------------------------------------------------
+Device Tree Bindings for the Xilinx Zynq MPSoC Firmware Interface
+-----------------------------------------------------------------
+
+The zynqmp-firmware node describes the interface to platform firmware.
+ZynqMP has an interface to communicate with secure firmware. Firmware
+driver provides an interface to firmware APIs. Interface APIs can be
+used by any driver to communicate to PMUFW(Platform Management Unit).
+These requests include clock management, pin control, device control,
+power management service, FPGA service and other platform management
+services.
+
+Required properties:
+ - compatible: Must contain: "xlnx,zynqmp-firmware"
+ - method: The method of calling the PM-API firmware layer.
+ Permitted values are:
+ - "smc" : SMC #0, following the SMCCC
+ - "hvc" : HVC #0, following the SMCCC
+
+-------
+Example
+-------
+
+firmware {
+ zynqmp_firmware: zynqmp-firmware {
+ compatible = "xlnx,zynqmp-firmware";
+ method = "smc";
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v7 02/10] firmware: xilinx: Add Zynqmp firmware driver
From: Jolly Shah @ 2018-05-30 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527713725-1086-1-git-send-email-jollys@xilinx.com>
From: Rajan Vaja <rajanv@xilinx.com>
This patch is adding communication layer with firmware.
Firmware driver provides an interface to firmware APIs.
Interface APIs can be used by any driver to communicate to
PMUFW(Platform Management Unit). All requests go through ATF.
Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
Signed-off-by: Jolly Shah <jollys@xilinx.com>
---
arch/arm64/Kconfig.platforms | 1 +
drivers/firmware/Kconfig | 1 +
drivers/firmware/Makefile | 1 +
drivers/firmware/xilinx/Kconfig | 16 ++
drivers/firmware/xilinx/Makefile | 4 +
drivers/firmware/xilinx/zynqmp.c | 337 +++++++++++++++++++++++++++++++++++
include/linux/firmware/xlnx-zynqmp.h | 63 +++++++
7 files changed, 423 insertions(+)
create mode 100644 drivers/firmware/xilinx/Kconfig
create mode 100644 drivers/firmware/xilinx/Makefile
create mode 100644 drivers/firmware/xilinx/zynqmp.c
create mode 100644 include/linux/firmware/xlnx-zynqmp.h
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index fbedbd8..6454458 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -274,6 +274,7 @@ config ARCH_ZX
config ARCH_ZYNQMP
bool "Xilinx ZynqMP Family"
+ select ZYNQMP_FIRMWARE
help
This enables support for Xilinx ZynqMP Family
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index b7c7482..f41eb0d 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -257,5 +257,6 @@ source "drivers/firmware/google/Kconfig"
source "drivers/firmware/efi/Kconfig"
source "drivers/firmware/meson/Kconfig"
source "drivers/firmware/tegra/Kconfig"
+source "drivers/firmware/xilinx/Kconfig"
endmenu
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index b248238..f90363e 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_GOOGLE_FIRMWARE) += google/
obj-$(CONFIG_EFI) += efi/
obj-$(CONFIG_UEFI_CPER) += efi/
obj-y += tegra/
+obj-y += xilinx/
diff --git a/drivers/firmware/xilinx/Kconfig b/drivers/firmware/xilinx/Kconfig
new file mode 100644
index 0000000..cce4e4f
--- /dev/null
+++ b/drivers/firmware/xilinx/Kconfig
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0
+# Kconfig for Xilinx firmwares
+
+menu "Zynq MPSoC Firmware Drivers"
+ depends on ARCH_ZYNQMP
+
+config ZYNQMP_FIRMWARE
+ bool "Enable Xilinx Zynq MPSoC firmware interface"
+ help
+ Firmware interface driver is used by different to
+ communicate with the firmware for various platform
+ management services.
+ Say yes to enable ZynqMP firmware interface driver.
+ In doubt, say N
+
+endmenu
diff --git a/drivers/firmware/xilinx/Makefile b/drivers/firmware/xilinx/Makefile
new file mode 100644
index 0000000..29f7bf2
--- /dev/null
+++ b/drivers/firmware/xilinx/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+# Makefile for Xilinx firmwares
+
+obj-$(CONFIG_ZYNQMP_FIRMWARE) += zynqmp.o
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
new file mode 100644
index 0000000..70e335a
--- /dev/null
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -0,0 +1,337 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Zynq MPSoC Firmware layer
+ *
+ * Copyright (C) 2014-2018 Xilinx, Inc.
+ *
+ * Michal Simek <michal.simek@xilinx.com>
+ * Davorin Mista <davorin.mista@aggios.com>
+ * Jolly Shah <jollys@xilinx.com>
+ * Rajan Vaja <rajanv@xilinx.com>
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/compiler.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+
+#include <linux/firmware/xlnx-zynqmp.h>
+
+/**
+ * zynqmp_pm_ret_code() - Convert PMU-FW error codes to Linux error codes
+ * @ret_status: PMUFW return code
+ *
+ * Return: corresponding Linux error code
+ */
+static int zynqmp_pm_ret_code(u32 ret_status)
+{
+ switch (ret_status) {
+ case XST_PM_SUCCESS:
+ case XST_PM_DOUBLE_REQ:
+ return 0;
+ case XST_PM_NO_ACCESS:
+ return -EACCES;
+ case XST_PM_ABORT_SUSPEND:
+ return -ECANCELED;
+ case XST_PM_INTERNAL:
+ case XST_PM_CONFLICT:
+ case XST_PM_INVALID_NODE:
+ default:
+ return -EINVAL;
+ }
+}
+
+static noinline int do_fw_call_fail(u64 arg0, u64 arg1, u64 arg2,
+ u32 *ret_payload)
+{
+ return -ENODEV;
+}
+
+/*
+ * PM function call wrapper
+ * Invoke do_fw_call_smc or do_fw_call_hvc, depending on the configuration
+ */
+static int (*do_fw_call)(u64, u64, u64, u32 *ret_payload) = do_fw_call_fail;
+
+/**
+ * do_fw_call_smc() - Call system-level platform management layer (SMC)
+ * @arg0: Argument 0 to SMC call
+ * @arg1: Argument 1 to SMC call
+ * @arg2: Argument 2 to SMC call
+ * @ret_payload: Returned value array
+ *
+ * Invoke platform management function via SMC call (no hypervisor present).
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static noinline int do_fw_call_smc(u64 arg0, u64 arg1, u64 arg2,
+ u32 *ret_payload)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(arg0, arg1, arg2, 0, 0, 0, 0, 0, &res);
+
+ if (ret_payload) {
+ ret_payload[0] = lower_32_bits(res.a0);
+ ret_payload[1] = upper_32_bits(res.a0);
+ ret_payload[2] = lower_32_bits(res.a1);
+ ret_payload[3] = upper_32_bits(res.a1);
+ }
+
+ return zynqmp_pm_ret_code((enum pm_ret_status)res.a0);
+}
+
+/**
+ * do_fw_call_hvc() - Call system-level platform management layer (HVC)
+ * @arg0: Argument 0 to HVC call
+ * @arg1: Argument 1 to HVC call
+ * @arg2: Argument 2 to HVC call
+ * @ret_payload: Returned value array
+ *
+ * Invoke platform management function via HVC
+ * HVC-based for communication through hypervisor
+ * (no direct communication with ATF).
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static noinline int do_fw_call_hvc(u64 arg0, u64 arg1, u64 arg2,
+ u32 *ret_payload)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_hvc(arg0, arg1, arg2, 0, 0, 0, 0, 0, &res);
+
+ if (ret_payload) {
+ ret_payload[0] = lower_32_bits(res.a0);
+ ret_payload[1] = upper_32_bits(res.a0);
+ ret_payload[2] = lower_32_bits(res.a1);
+ ret_payload[3] = upper_32_bits(res.a1);
+ }
+
+ return zynqmp_pm_ret_code((enum pm_ret_status)res.a0);
+}
+
+/**
+ * zynqmp_pm_invoke_fn() - Invoke the system-level platform management layer
+ * caller function depending on the configuration
+ * @pm_api_id: Requested PM-API call
+ * @arg0: Argument 0 to requested PM-API call
+ * @arg1: Argument 1 to requested PM-API call
+ * @arg2: Argument 2 to requested PM-API call
+ * @arg3: Argument 3 to requested PM-API call
+ * @ret_payload: Returned value array
+ *
+ * Invoke platform management function for SMC or HVC call, depending on
+ * configuration.
+ * Following SMC Calling Convention (SMCCC) for SMC64:
+ * Pm Function Identifier,
+ * PM_SIP_SVC + PM_API_ID =
+ * ((SMC_TYPE_FAST << FUNCID_TYPE_SHIFT)
+ * ((SMC_64) << FUNCID_CC_SHIFT)
+ * ((SIP_START) << FUNCID_OEN_SHIFT)
+ * ((PM_API_ID) & FUNCID_NUM_MASK))
+ *
+ * PM_SIP_SVC - Registered ZynqMP SIP Service Call.
+ * PM_API_ID - Platform Management API ID.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_invoke_fn(u32 pm_api_id, u32 arg0, u32 arg1,
+ u32 arg2, u32 arg3, u32 *ret_payload)
+{
+ /*
+ * Added SIP service call Function Identifier
+ * Make sure to stay in x0 register
+ */
+ u64 smc_arg[4];
+
+ smc_arg[0] = PM_SIP_SVC | pm_api_id;
+ smc_arg[1] = ((u64)arg1 << 32) | arg0;
+ smc_arg[2] = ((u64)arg3 << 32) | arg2;
+
+ return do_fw_call(smc_arg[0], smc_arg[1], smc_arg[2], ret_payload);
+}
+
+static u32 pm_api_version;
+static u32 pm_tz_version;
+
+/**
+ * zynqmp_pm_get_api_version() - Get version number of PMU PM firmware
+ * @version: Returned version value
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_get_api_version(u32 *version)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (!version)
+ return -EINVAL;
+
+ /* Check is PM API version already verified */
+ if (pm_api_version > 0) {
+ *version = pm_api_version;
+ return 0;
+ }
+ ret = zynqmp_pm_invoke_fn(PM_GET_API_VERSION, 0, 0, 0, 0, ret_payload);
+ *version = ret_payload[1];
+
+ return ret;
+}
+
+/**
+ * zynqmp_pm_get_trustzone_version() - Get secure trustzone firmware version
+ * @version: Returned version value
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_get_trustzone_version(u32 *version)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (!version)
+ return -EINVAL;
+
+ /* Check is PM trustzone version already verified */
+ if (pm_tz_version > 0) {
+ *version = pm_tz_version;
+ return 0;
+ }
+ ret = zynqmp_pm_invoke_fn(PM_GET_TRUSTZONE_VERSION, 0, 0,
+ 0, 0, ret_payload);
+ *version = ret_payload[1];
+
+ return ret;
+}
+
+/**
+ * get_set_conduit_method() - Choose SMC or HVC based communication
+ * @np: Pointer to the device_node structure
+ *
+ * Use SMC or HVC-based functions to communicate with EL2/EL3.
+ *
+ * Return: Returns 0 on success or error code
+ */
+static int get_set_conduit_method(struct device_node *np)
+{
+ const char *method;
+
+ if (of_property_read_string(np, "method", &method)) {
+ pr_warn("%s missing \"method\" property\n", __func__);
+ return -ENXIO;
+ }
+
+ if (!strcmp("hvc", method)) {
+ do_fw_call = do_fw_call_hvc;
+ } else if (!strcmp("smc", method)) {
+ do_fw_call = do_fw_call_smc;
+ } else {
+ pr_warn("%s Invalid \"method\" property: %s\n",
+ __func__, method);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static const struct zynqmp_eemi_ops eemi_ops = {
+ .get_api_version = zynqmp_pm_get_api_version,
+};
+
+/**
+ * zynqmp_pm_get_eemi_ops - Get eemi ops functions
+ *
+ * Return: pointer of eemi_ops structure
+ */
+const struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
+{
+ return &eemi_ops;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_eemi_ops);
+
+static int zynqmp_firmware_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+
+ return of_platform_populate(dev->of_node, NULL, NULL, dev);
+}
+
+static const struct of_device_id zynqmp_firmware_of_match[] = {
+ {.compatible = "xlnx,zynqmp-firmware"},
+ {},
+};
+MODULE_DEVICE_TABLE(of, zynqmp_firmware_of_match);
+
+static struct platform_driver zynqmp_firmware_driver = {
+ .driver = {
+ .name = "zynqmp_firmware",
+ .of_match_table = zynqmp_firmware_of_match,
+ },
+ .probe = zynqmp_firmware_probe,
+};
+module_platform_driver(zynqmp_firmware_driver);
+
+static int __init zynqmp_plat_init(void)
+{
+ int ret;
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "xlnx,zynqmp");
+ if (!np)
+ return 0;
+ of_node_put(np);
+
+ /*
+ * We're running on a ZynqMP machine,
+ * the zynqmp-firmware node is mandatory.
+ */
+ np = of_find_compatible_node(NULL, NULL, "xlnx,zynqmp-firmware");
+ if (!np) {
+ pr_warn("%s: zynqmp-firmware node not found\n", __func__);
+ return -ENXIO;
+ }
+
+ ret = get_set_conduit_method(np);
+ if (ret) {
+ of_node_put(np);
+ return ret;
+ }
+
+ /* Check PM API version number */
+ zynqmp_pm_get_api_version(&pm_api_version);
+ if (pm_api_version < ZYNQMP_PM_VERSION) {
+ panic("%s Platform Management API version error. Expected: v%d.%d - Found: v%d.%d\n",
+ __func__,
+ ZYNQMP_PM_VERSION_MAJOR, ZYNQMP_PM_VERSION_MINOR,
+ pm_api_version >> 16, pm_api_version & 0xFFFF);
+ }
+
+ pr_info("%s Platform Management API v%d.%d\n", __func__,
+ pm_api_version >> 16, pm_api_version & 0xFFFF);
+
+ /* Check trustzone version number */
+ ret = zynqmp_pm_get_trustzone_version(&pm_tz_version);
+ if (ret)
+ panic("Legacy trustzone found without version support\n");
+
+ if (pm_tz_version < ZYNQMP_TZ_VERSION)
+ panic("%s Trustzone version error. Expected: v%d.%d - Found: v%d.%d\n",
+ __func__,
+ ZYNQMP_TZ_VERSION_MAJOR, ZYNQMP_TZ_VERSION_MINOR,
+ pm_tz_version >> 16, pm_tz_version & 0xFFFF);
+
+ pr_info("%s Trustzone version v%d.%d\n", __func__,
+ pm_tz_version >> 16, pm_tz_version & 0xFFFF);
+
+ of_node_put(np);
+
+ return ret;
+}
+early_initcall(zynqmp_plat_init);
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
new file mode 100644
index 0000000..cb63bed
--- /dev/null
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Xilinx Zynq MPSoC Firmware layer
+ *
+ * Copyright (C) 2014-2018 Xilinx
+ *
+ * Michal Simek <michal.simek@xilinx.com>
+ * Davorin Mista <davorin.mista@aggios.com>
+ * Jolly Shah <jollys@xilinx.com>
+ * Rajan Vaja <rajanv@xilinx.com>
+ */
+
+#ifndef __FIRMWARE_ZYNQMP_H__
+#define __FIRMWARE_ZYNQMP_H__
+
+#define ZYNQMP_PM_VERSION_MAJOR 1
+#define ZYNQMP_PM_VERSION_MINOR 0
+
+#define ZYNQMP_PM_VERSION ((ZYNQMP_PM_VERSION_MAJOR << 16) | \
+ ZYNQMP_PM_VERSION_MINOR)
+
+#define ZYNQMP_TZ_VERSION_MAJOR 1
+#define ZYNQMP_TZ_VERSION_MINOR 0
+
+#define ZYNQMP_TZ_VERSION ((ZYNQMP_TZ_VERSION_MAJOR << 16) | \
+ ZYNQMP_TZ_VERSION_MINOR)
+
+/* SMC SIP service Call Function Identifier Prefix */
+#define PM_SIP_SVC 0xC2000000
+#define PM_GET_TRUSTZONE_VERSION 0xa03
+
+/* Number of 32bits values in payload */
+#define PAYLOAD_ARG_CNT 4U
+
+enum pm_api_id {
+ PM_GET_API_VERSION = 1,
+};
+
+/* PMU-FW return status codes */
+enum pm_ret_status {
+ XST_PM_SUCCESS = 0,
+ XST_PM_INTERNAL = 2000,
+ XST_PM_CONFLICT,
+ XST_PM_NO_ACCESS,
+ XST_PM_INVALID_NODE,
+ XST_PM_DOUBLE_REQ,
+ XST_PM_ABORT_SUSPEND,
+};
+
+struct zynqmp_eemi_ops {
+ int (*get_api_version)(u32 *version);
+};
+
+#if IS_REACHABLE(CONFIG_ARCH_ZYNQMP)
+const struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void);
+#else
+static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
+{
+ return NULL;
+}
+#endif
+
+#endif /* __FIRMWARE_ZYNQMP_H__ */
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox