Re: [PATCH v2 2/2] i2c: mux: demux-pinctrl: add symlinks to the demux device in sysfs
On 2018-05-21 09:29, Wolfram Sang wrote: > Similar to mux devices, create special symlinks to connect the demuxed > bus with the demux device. Hmm, now that I have slept on it, I find this a bit odd. For muxes, all channels and the parent are always present. Here, that is not the case. And don't get me wrong, I see why that is the case, but that doesn't mean that I like it. It would be so much nicer and less disruptive if the client devices were not unbound and rebound (which I think they are, right?) on every master switch. In some cases I think it might be possible to make the switch automatic and seamless, e.g. if there are two masters and one of them is faster but has some glitch(es), and the other is slower but complete (or at least complete enough). The demuxer could then switch to the slower master automatically, on a transaction-by-transaction basis, in order to avoid the glitch(es). Yes, it would have to work a bit differently etc etc, but I don't see any reason why it can't be done. But you probably know more than I on that part of the I2C code... Anyway, since this is ABI (and should be documented) I think it would be good if it could accommodate the automatic master switch case too. And for that to work, the "channel-0" name is wrong. I think channel-N should be reserved for the actual masters, in the order given in the devicetree (I know that you currently can't establish these links since you unbind the inactive masters, but that unbind can probably not happen for the automatic switch case?). There could then be some other symlink, e.g. "current" or "master" or something like that, that reflects the present situation (your "channel-0"). What do you think? Cheers, Peter > Signed-off-by: Wolfram Sang > --- > > Changes since v1: > * check sysfs_create_link and print WARN if something fails > > drivers/i2c/muxes/i2c-demux-pinctrl.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/i2c/muxes/i2c-demux-pinctrl.c > b/drivers/i2c/muxes/i2c-demux-pinctrl.c > index 035032e20327..13d1461703f3 100644 > --- a/drivers/i2c/muxes/i2c-demux-pinctrl.c > +++ b/drivers/i2c/muxes/i2c-demux-pinctrl.c > @@ -116,6 +116,13 @@ static int i2c_demux_activate_master(struct > i2c_demux_pinctrl_priv *priv, u32 ne > if (ret < 0) > goto err_with_put; > > + WARN(sysfs_create_link(&priv->cur_adap.dev.kobj, &priv->dev->kobj, > +"demux_device"), > + "can't create symlink to mux device\n"); > + WARN(sysfs_create_link(&priv->dev->kobj, &priv->cur_adap.dev.kobj, > +"channel-0"), > + "can't create symlink to channel 0\n"); > + > return 0; > > err_with_put: > @@ -135,6 +142,9 @@ static int i2c_demux_deactivate_master(struct > i2c_demux_pinctrl_priv *priv) > if (cur < 0) > return 0; > > + sysfs_remove_link(&priv->dev->kobj, "channel-0"); > + sysfs_remove_link(&priv->cur_adap.dev.kobj, "demux_device"); > + > i2c_del_adapter(&priv->cur_adap); > i2c_put_adapter(priv->chan[cur].parent_adap); > >
Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
Hi Gilad,
On Mon, May 21, 2018 at 3:43 PM, Gilad Ben-Yossef wrote:
> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven
> wrote:
>> Indeed. From a quick glance, it looks like drivers/crypto/ccree/cc_driver.c
>> does not distinguish between the absence of the clock property, and an
>> actual error in getting the clock, and never considers any error a failure
>> (incl. -PROBE_DEFER).
>>
>> As of_clk_get() returns -ENOENT for both a missing clock property and a
>> missing clock, you should use (devm_)clk_get() instead, and distinguish
>> between NULL (no clock property) and IS_ERR() (actual failure -> abort).
>
> I was trying to do as you suggested but I didn't quite get what is the
> dev_id (2nd) parameter to devm_clk_get parameter is supposed to be.
It's the (optional) name of the clock, helpful in case there is more than one.
In your case, NULL is fine.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH][RFC] PCI: rcar: Add bus notifier so we can limit the DMA range
On Tue, May 22, 2018 at 12:05 AM, Marek Vasut wrote: > From: Phil Edworthy > > The PCIe DMA controller on RCar Gen2 and earlier is on 32bit bus, > so limit the DMA range to 32bit. > > Signed-off-by: Phil Edworthy > Signed-off-by: Marek Vasut > Cc: Arnd Bergmann > Cc: Geert Uytterhoeven > Cc: Phil Edworthy > Cc: Simon Horman > Cc: Wolfram Sang > Cc: linux-renesas-soc@vger.kernel.org > To: linux-...@vger.kernel.org > --- > NOTE: I'm aware of https://patchwork.kernel.org/patch/9495895/ , but the > discussion seems to have gone way off, so I'm sending this as a > RFC. Any feedback on how to do this limiting properly would be nice. Doing it in the driver is clearly not appropriate, we must do this in common code. If I remember correctly, it's specifically ARM64 that is broken here, it incorrectly allows setting a DMA mask to 64 bit when that is not available. Arnd
Re: [PATCH 5/6] ARM: dts: rcar-gen2: Remove unused VIN properties
On Thu, May 17, 2018 at 11:01:10AM +0200, jacopo mondi wrote:
> Hi Niklas,
>
> On Thu, May 17, 2018 at 12:13:07AM +0200, Niklas Söderlund wrote:
> > Hi Jacopo,
> >
> > Thanks for your work.
> >
> > On 2018-05-16 18:32:31 +0200, Jacopo Mondi wrote:
> > > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> > > driver and only confuse users. Remove them in all Gen2 SoC that used
> > > them.
> > >
> > > Signed-off-by: Jacopo Mondi
> > > ---
> > > arch/arm/boot/dts/r8a7790-lager.dts | 3 ---
> > > arch/arm/boot/dts/r8a7791-koelsch.dts | 3 ---
> > > arch/arm/boot/dts/r8a7791-porter.dts | 1 -
> > > arch/arm/boot/dts/r8a7793-gose.dts| 3 ---
> > > arch/arm/boot/dts/r8a7794-alt.dts | 1 -
> > > arch/arm/boot/dts/r8a7794-silk.dts| 1 -
> > > 6 files changed, 12 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
> > > b/arch/arm/boot/dts/r8a7790-lager.dts
> > > index 063fdb6..b56b309 100644
> > > --- a/arch/arm/boot/dts/r8a7790-lager.dts
> > > +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> > > @@ -873,10 +873,8 @@
> > > port {
> > > vin0ep2: endpoint {
> > > remote-endpoint = <&adv7612_out>;
> > > - bus-width = <24>;
> >
> > I can't really make up my mind if this is a good thing or not. Device
> > tree describes the hardware and not what the drivers make use of. And
> > the fact is that this bus is 24 bits wide. So I'm not sure we should
> > remove these properties. But I would love to hear what others think
> > about this.
> >
>
> Just to point out those properties are not even documented in rcar-vin
> bindings (actually, none of them was).
>
> I feel it's wrong to have them here, as someone may think that
> changing their value should actually change the VIN interface behavior,
> which it's not true, leading to massive confusion and quite some code
> digging for no reason (and they will get mad at us at some point, probably :)
I think its fine that the driver doesn't implement something described in
DT - we are describing the hardware not the implementation. But I think its
not fine that DT includes properties not described in the binding.
So I think we should either
a) Fix the binding documentation, but perhaps it is already correct
in which case we should;
b) Apply this patch
Once we have decided what is the correct description of the hardware we
can consider implications on the driver implementation.
Re: [PATCH 1/2] media: arch: sh: ecovec: Remove calls to empty arch_setup_pdev_archdata()
On Fri, May 18, 2018 at 01:06:50PM +0200, Geert Uytterhoeven wrote: > SuperH doesn't implement arch_setup_pdev_archdata(), and falls back to > the default (empty) implementation. As this code is board-specific, the > calls can just be removed. > > Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman
Re: [PATCH 2/2] media: arch: sh: migor: Remove calls to empty arch_setup_pdev_archdata()
On Fri, May 18, 2018 at 01:06:51PM +0200, Geert Uytterhoeven wrote: > SuperH doesn't implement arch_setup_pdev_archdata(), and falls back to > the default (empty) implementation. As this code is board-specific, the > call can just be removed. > > Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman
Re: [PATCH 0/5] ARM: shmobile: rcar-gen2: Remove legacy SMP fallback code
On Fri, May 18, 2018 at 02:48:49PM +0200, Geert Uytterhoeven wrote: > Hi Simon, Magnus, > > R-Car H2 and M2-W have been supporting SMP enablement from DT using the > "renesas,apmu" enable-method since v4.8. A legacy fallback was left in > place for backwards compatibility with old DTBs. > > This patch series removes the legacy SMP fallbacks for R-Car H2 and > M2-W, and consolidates their support in the common R-Car Gen2 machine > definition. > > For testing, this series is available in the > topic/rcar2-legacy-smp-removal-v1 branch of my renesas-drivers git > repository at > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git. > > Thanks for applying! > > Geert Uytterhoeven (5): > ARM: shmobile: r8a7790: Remove legacy SMP fallback code > ARM: shmobile: r8a7790: Use common R-Car Gen2 machine definition > ARM: shmobile: r8a7791: Remove legacy SMP fallback code > ARM: shmobile: r8a7791: Use common R-Car Gen2 machine definition > ARM: shmobile: Remove unused shmobile_smp_init_fallback_ops() Thanks, applied for v4.19.
Re: [PATCH 1/2] arm64: dts: renesas: r8a77980: add GEther support
On Fri, May 18, 2018 at 10:45:36PM +0300, Sergei Shtylyov wrote: > Define the generic R8A77980 part of the GEther device node. > > Based on the original (and large) patch by Vladimir Barinov. > > Signed-off-by: Vladimir Barinov > Signed-off-by: Sergei Shtylyov This looks fine but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH 2/2] arm64: dts: renesas: v3hsk: add GEther support
On Fri, May 18, 2018 at 10:46:19PM +0300, Sergei Shtylyov wrote: > Define the V3H Starter Kit board dependent part of the GEther device node. > > Based on the original (and large) patch by Vladimir Barinov. > > Signed-off-by: Vladimir Barinov > Signed-off-by: Sergei Shtylyov This looks fine but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH] arm64: dts: renesas: r8a77980: add SMP support
On Sat, May 19, 2018 at 08:38:13PM +0300, Sergei Shtylyov wrote:
> On 05/17/2018 11:23 PM, Geert Uytterhoeven wrote:
>
> >> Add the device nodes for 3 more Cortex-A53 CPU cores; adjust the interrupt
> >> delivery masks for the ARM GIC and Architectured Timer.
> >>
> >> Based on the original (and large) patch by Vladimir Barinov.
> >>
> >> Signed-off-by: Vladimir Barinov
> >> Signed-off-by: Sergei Shtylyov
> >
> > Thanks for your patch!
> >
> >> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> >> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> >> @@ -30,6 +30,36 @@
> >> enable-method = "psci";
> >> };
> >>
> >> + a53_1: cpu@1 {
> >> + device_type = "cpu";
> >> + compatible = "arm,cortex-a53","arm,armv8";
> >
> > Please stop copying spaceless lists ;-)
>
>Oops! Simon, do I need to re-post?
No, but Geert, are you otherwise ok with this patch?
Re: [PATCH] arm64: dts: renesas: r8a77980: add SMP support
On Thu, May 17, 2018 at 11:19:44PM +0300, Sergei Shtylyov wrote: > Add the device nodes for 3 more Cortex-A53 CPU cores; adjust the interrupt > delivery masks for the ARM GIC and Architectured Timer. > > Based on the original (and large) patch by Vladimir Barinov. > > Signed-off-by: Vladimir Barinov > Signed-off-by: Sergei Shtylyov > > --- > The patch is against the 'renesas-devel-20180516v2-v4.17-rc5' tag of Simon > Horman's 'renesas.git' repo. Tested successfully on the V3M Starter Kit board > (except offlining CPU0 hangs the kernel). This looks fine but I will wait to see if there are other reviews completed before applying. Reviewed-by: Simon Horman
Re: [PATCH 5/5] arm64: dts: renesas: r8a77995-draak: add X12 input dot clock
On Sun, May 20, 2018 at 11:58:36AM +0300, Laurent Pinchart wrote: > Hi Ulrich, > > Thank you for the patch. > > On Wednesday, 16 May 2018 11:38:22 EEST Simon Horman wrote: > > On Tue, May 15, 2018 at 02:20:40PM +0200, Ulrich Hecht wrote: > > > 74.25 Mhz oscillator X12 is connected to DU_DOTCLKIN0. > > > > > > Signed-off-by: Ulrich Hecht > > Reviewed-by: Laurent Pinchart > > > > --- > > > > > > arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 11 +++ > > > 1 file changed, 11 insertions(+) > > > > This looks fine but I will wait to see if there are other reviews before > > applying. > > > > Reviewed-by: Simon Horman > > As far as I'm concerned this patch can be merged already. I would however > possibly hold off merging patch 3/5 and 4/5 until they can be tested. Thanks, I have applied this patch for v4.19. As per your suggestion, I have marked patches 3/5 and 4/5 as deferred pending testing.
Re: [PATCH v2] v4l: vsp1: Fix vsp1_regs.h license header
On Sun, May 20, 2018 at 10:24:37AM +0300, Laurent Pinchart wrote: > All source files of the vsp1 driver are licensed under the GPLv2+ except > for vsp1_regs.h which is licensed under GPLv2. This is caused by a bad > copy&paste that dates back from the initial version of the driver. Fix > it. > > Cc: Nobuhiro Iwamatsu > Acked-by: Kieran Bingham > Acked-by: Sergei Shtylyov > Acked-by: Niklas Söderlund > Acked-by: Wolfram Sang > Signed-off-by: Laurent Pinchart > --- > Iwamatsu-san, > > While working on the VSP1 driver I noticed that all source files are > licensed under the GPLv2+ except for vsp1_regs.h which is licensed under > GPLv2. I'd like to fix this inconsistency. As you have contributed to > that file, could you please provide your explicit ack if you agree to > this change ? > --- > drivers/media/platform/vsp1/vsp1_regs.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/platform/vsp1/vsp1_regs.h > b/drivers/media/platform/vsp1/vsp1_regs.h > index 0d249ff9f564..e82661216c1d 100644 > --- a/drivers/media/platform/vsp1/vsp1_regs.h > +++ b/drivers/media/platform/vsp1/vsp1_regs.h > @@ -1,4 +1,4 @@ > -/* SPDX-License-Identifier: GPL-2.0 */ > +/* SPDX-License-Identifier: GPL-2.0+ */ While you are changing this line, I believe the correct format is to use a '//' comment. i.e.: // SPDX-License-Identifier: GPL-2.0+ > /* > * vsp1_regs.h -- R-Car VSP1 Registers Definitions > * > -- > Regards, > > Laurent Pinchart >
Re: [PATCH 1/4] PCI: rcar: Rename rcar_pcie_parse_request_of_pci_ranges()
On Mon, May 21, 2018 at 03:11:20PM +0200, Marek Vasut wrote: > The function name is just too confusing, rename it, no functional change. > Rename the function to rcar_pcie_alloc_and_parse_pci_resource_list() as > it's matching failpath function is pci_free_resource_list() so the names > align much better and the new name also describes what the function does > much better. > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Phil Edworthy > Cc: Simon Horman > Cc: Wolfram Sang > Cc: linux-renesas-soc@vger.kernel.org Reviewed-by: Simon Horman
Re: [PATCH 2/4] PCI: rcar: Pull bus clock enable/disable from rcar_pcie_get_resources()
On Mon, May 21, 2018 at 03:11:21PM +0200, Marek Vasut wrote: > The rcar_pcie_get_resources() is another misnomer with a side effect. > The function does not only get resources, but also enables/disables bus > clock. This is forgotten in the probe() function though and if anything > in probe() fails after rcar_pcie_get_resources() is called, the bus > clock are never disabled. > > This patch pulls the clock handling out of the rcar_pcie_get_resources() > and enables clock after all the resources were requested. Moreover, this > patch also always disables the clock in case of failure. > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Phil Edworthy > Cc: Simon Horman > Cc: Wolfram Sang > Cc: linux-renesas-soc@vger.kernel.org Reviewed-by: Simon Horman
Re: [PATCH 3/4] PCI: rcar: Add missing irq_dispose_mapping() into failpath
On Mon, May 21, 2018 at 03:11:22PM +0200, Marek Vasut wrote: > The rcar_pcie_get_resources() is another misnomer with a side effect. > The function does not only get resources, but also maps MSI IRQs via > irq_of_parse_and_map(). In case anything fails afterward, the IRQ > mapping must be disposed through irq_dispose_mapping() which is not > done. > > This patch handles irq_of_parse_and_map() failures in by disposing > of the mapping in rcar_pcie_get_resources() as well as in probe. > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Phil Edworthy > Cc: Simon Horman > Cc: Wolfram Sang > Cc: linux-renesas-soc@vger.kernel.org > --- > drivers/pci/host/pcie-rcar.c | 17 ++--- > 1 file changed, 14 insertions(+), 3 deletions(-) Reviewed-by: Simon Horman
Re: [PATCH 4/4] PCI: rcar: Teardown MSI setup if rcar_pcie_enable() fails
On Mon, May 21, 2018 at 03:11:23PM +0200, Marek Vasut wrote: > If the rcar_pcie_enable() fails and MSIs are enabled, the setup done in > rcar_pcie_enable_msi() is never undone. Add a function to tear down the > MSI setup by disabling the MSI handling in the PCIe block, deallocating > the pages requested for the MSIs and zapping the IRQ mapping. > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Phil Edworthy > Cc: Simon Horman > Cc: Wolfram Sang > Cc: linux-renesas-soc@vger.kernel.org > --- > drivers/pci/host/pcie-rcar.c | 28 +++- > 1 file changed, 27 insertions(+), 1 deletion(-) Reviewed-by: Simon Horman
Re: [PATCH] PCI: rcar: Poll more often in rcar_pcie_wait_for_dl()
Hi Marek,
On Mon, May 21, 2018 at 11:05 PM, Marek Vasut wrote:
> The data link active signal usually takes ~20 uSec to be asserted,
> poll the bit more often to avoid useless delays in this function.
> Use udelay() instead of usleep() for such a small delay as suggested
> by the timer documentation and because this will be used in atomic
> context later on when the suspend/resume patches land.
>
> Signed-off-by: Marek Vasut
Thanks for your patch!
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -529,13 +529,13 @@ static void phy_write_reg(struct rcar_pcie *pcie,
>
> static int rcar_pcie_wait_for_dl(struct rcar_pcie *pcie)
> {
> - unsigned int timeout = 10;
> + unsigned int timeout = 1;
>
> while (timeout--) {
> if ((rcar_pci_read_reg(pcie, PCIETSTR) & DATA_LINK_ACTIVE))
> return 0;
>
> - msleep(5);
> + udelay(5);
+ cpu_relax()?
> }
if this ever happens, it will have blocked for more than 50 ms...
> return -ETIMEDOUT;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] arm64: dts: renesas: r8a77980: add SMP support
On Tue, May 22, 2018 at 10:54 AM, Simon Horman wrote:
> On Sat, May 19, 2018 at 08:38:13PM +0300, Sergei Shtylyov wrote:
>> On 05/17/2018 11:23 PM, Geert Uytterhoeven wrote:
>>
>> >> Add the device nodes for 3 more Cortex-A53 CPU cores; adjust the interrupt
>> >> delivery masks for the ARM GIC and Architectured Timer.
>> >>
>> >> Based on the original (and large) patch by Vladimir Barinov.
>> >>
>> >> Signed-off-by: Vladimir Barinov
>> >> Signed-off-by: Sergei Shtylyov
>> >
>> > Thanks for your patch!
>> >
>> >> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
>> >> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
>> >> @@ -30,6 +30,36 @@
>> >> enable-method = "psci";
>> >> };
>> >>
>> >> + a53_1: cpu@1 {
>> >> + device_type = "cpu";
>> >> + compatible = "arm,cortex-a53","arm,armv8";
>> >
>> > Please stop copying spaceless lists ;-)
>>
>>Oops! Simon, do I need to re-post?
>
> No, but Geert, are you otherwise ok with this patch?
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] PCI: rcar: Poll more often in rcar_pcie_wait_for_dl()
On 05/22/2018 11:42 AM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Mon, May 21, 2018 at 11:05 PM, Marek Vasut wrote:
>> The data link active signal usually takes ~20 uSec to be asserted,
>> poll the bit more often to avoid useless delays in this function.
>> Use udelay() instead of usleep() for such a small delay as suggested
>> by the timer documentation and because this will be used in atomic
>> context later on when the suspend/resume patches land.
>>
>> Signed-off-by: Marek Vasut
>
> Thanks for your patch!
>
>> --- a/drivers/pci/host/pcie-rcar.c
>> +++ b/drivers/pci/host/pcie-rcar.c
>> @@ -529,13 +529,13 @@ static void phy_write_reg(struct rcar_pcie *pcie,
>>
>> static int rcar_pcie_wait_for_dl(struct rcar_pcie *pcie)
>> {
>> - unsigned int timeout = 10;
>> + unsigned int timeout = 1;
>>
>> while (timeout--) {
>> if ((rcar_pci_read_reg(pcie, PCIETSTR) & DATA_LINK_ACTIVE))
>> return 0;
>>
>> - msleep(5);
>> + udelay(5);
>
> + cpu_relax()?
Is it safe to use in atomic context ? Because of that suspend/resume thing.
>> }
>
> if this ever happens, it will have blocked for more than 50 ms...
Well yes, so did the previous thing.
--
Best regards,
Marek Vasut
Re: [PATCH][RFC] PCI: rcar: Add bus notifier so we can limit the DMA range
On 05/22/2018 10:10 AM, Arnd Bergmann wrote: > On Tue, May 22, 2018 at 12:05 AM, Marek Vasut wrote: >> From: Phil Edworthy >> >> The PCIe DMA controller on RCar Gen2 and earlier is on 32bit bus, >> so limit the DMA range to 32bit. >> >> Signed-off-by: Phil Edworthy >> Signed-off-by: Marek Vasut >> Cc: Arnd Bergmann >> Cc: Geert Uytterhoeven >> Cc: Phil Edworthy >> Cc: Simon Horman >> Cc: Wolfram Sang >> Cc: linux-renesas-soc@vger.kernel.org >> To: linux-...@vger.kernel.org >> --- >> NOTE: I'm aware of https://patchwork.kernel.org/patch/9495895/ , but the >> discussion seems to have gone way off, so I'm sending this as a >> RFC. Any feedback on how to do this limiting properly would be nice. > > Doing it in the driver is clearly not appropriate, we must do this in > common code. If I remember correctly, it's specifically ARM64 that is > broken here, it incorrectly allows setting a DMA mask to 64 bit > when that is not available. Yep, that's correct. ARM64 with devices mapping tremendous amounts of memory. So did anything change since that discussion references in the NOTE? -- Best regards, Marek Vasut
[PATCH v6 1/6] dt-bindings: arm: Document the RZN1D-DB board
This documents the RZ/N1 bindings for the RZN1D-DB board. Signed-off-by: Michel Pollet Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/arm/shmobile.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt index d8cf740..89b4a38 100644 --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -51,7 +51,8 @@ SoCs: compatible = "renesas,r8a77990" - R-Car D3 (R8A77995) compatible = "renesas,r8a77995" - + - RZ/N1D (R9A06G032) +compatible = "renesas,r9a06g032" Boards: @@ -112,6 +113,8 @@ Boards: compatible = "renesas,porter", "renesas,r8a7791" - RSKRZA1 (YR0K77210C000BE) compatible = "renesas,rskrza1", "renesas,r7s72100" + - RZN1D-DB (RZ/N1D Demo Board for the RZ/N1D 400 pins package) +compatible = "renesas,rzn1d400-db", "renesas,r9a06g032" - Salvator-X (RTP0RC7795SIPB0010S) compatible = "renesas,salvator-x", "renesas,r8a7795" - Salvator-X (RTP0RC7796SIPB0011S) -- 2.7.4
[PATCH v6 0/6] arm: Base support for Renesas RZN1D-DB Board
This series adds the plain basic support for booting a bare kernel on the RZ/N1D-DB Board. It's been trimmed to the strict minimum as a 'base', further patches that will add the rest of the support. Special note on the clock driver: Current usage of the clocks on Linux involves Linux 'claiming' all of them, disabling the one it doesn't need and so on. On *this* architecture it can't be done, there is at least one other OS running on the CM3 core that claims it's own clock; Linux can claim some others but definitely not start disabling stuff it isn't supposed to. Thanks for the comments on the previous versions! v6: + Fix for suggestion by Geert Uytterhoeven + Removed "renesas,rzn1" from the board bindings + Removed patches already merged. + Removed reboot driver + Added a whole clock infrastructure. + Rebased on next-20180517 v5: + Given the problems I have with getting in some structure around the sysctrl block, I've removed the MFD, I've now attached the reboot driver on it's own pair of registers. + Rebased on next-20180417 v4: + Fixes for suggestions by Simon Horman + Fixes for suggestions by Jacopo Mondi + Fixes for suggestions by Geert Uytterhoeven + Renamed the r9a06g0xx.dtsi file, given up on trying to get a family common file in, so dropped potential RZ/N1S support and now only focus on RZ/N1D for this patchset. + Added 'always-on' to the architected timer node, because it is. + Added ARCH_R9A06G032, to match others patterns like RCAR + Sorted the .dts files, added empty lines as required. + Fixed patch prefixes to match git-log for bindings&dts + Merged board .dts & Makefile changes together + Rebased on next-20180410 v3: + Fixes for suggestions by Geert Uytterhoeven + Removed SoC Specific renesas,r9a06g032-xxx, as it's not needed for now. + Kept renesas,rzn1 as a family/generic for this family. + Fixed a couple of the commit messages. + Added Geert's Reviewed-By where appropriate. v2: + Fixes for suggestions by Simon Horman + Fixes for suggestions by Rob Herring + Fixes for suggestions by Geert Uytterhoeven + Removed the mach file + Added a MFD base for the sysctrl block + Added a regmap based sub driver for the reboot handler + Renamed the files to match shmobile conventions + Adapted the compatible= strings to reflect 'family' vs 'part' distinction. + Removed the sysctrl.h file entirelly. + Fixed every warnings from the DTC compiler on W=12 mode. + Split the device-tree patches from the code. Michel Pollet (6): dt-bindings: arm: Document the RZN1D-DB board dt-bindings: Add the rzn1-clocks.h file dt-bindings: clock: renesas,rzn1-clocks: document RZ/N1 clock driver ARM: dts: Renesas RZ/N1 SoC base device tree file ARM: dts: Renesas RZN1D-DB Board base file clk: renesas: Renesas RZ/N1 clock driver Documentation/devicetree/bindings/arm/shmobile.txt | 5 +- .../bindings/clock/renesas,rzn1-clocks.txt | 44 ++ arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts| 29 + arch/arm/boot/dts/r9a06g032.dtsi | 86 +++ drivers/clk/renesas/Kconfig| 6 + drivers/clk/renesas/Makefile | 1 + drivers/clk/renesas/rzn1-clocks.c | 814 + include/dt-bindings/clock/rzn1-clocks.h| 187 + 9 files changed, 1172 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt create mode 100644 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts create mode 100644 arch/arm/boot/dts/r9a06g032.dtsi create mode 100644 drivers/clk/renesas/rzn1-clocks.c create mode 100644 include/dt-bindings/clock/rzn1-clocks.h -- 2.7.4
[PATCH v6 2/6] dt-bindings: Add the rzn1-clocks.h file
This adds the constants necessary to use the renesas,rzn1-clocks driver. Signed-off-by: Michel Pollet --- include/dt-bindings/clock/rzn1-clocks.h | 187 1 file changed, 187 insertions(+) create mode 100644 include/dt-bindings/clock/rzn1-clocks.h diff --git a/include/dt-bindings/clock/rzn1-clocks.h b/include/dt-bindings/clock/rzn1-clocks.h new file mode 100644 index 000..8a73db2 --- /dev/null +++ b/include/dt-bindings/clock/rzn1-clocks.h @@ -0,0 +1,187 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * RZ/N1 clock IDs + * + * Copyright (C) 2018 Renesas Electronics Europe Limited + * + * Michel Pollet , + * Derived from zx-reboot.c + */ + +#ifndef __DT_BINDINGS_RZN1_CLOCK_H__ +#define __DT_BINDINGS_RZN1_CLOCK_H__ + +#define RZN1_CLKOUT0 +#define RZN1_CLK_PLL_USB 1 +#define RZN1_CLK_481 /* AKA CLK_PLL_USB */ +#define RZN1_CLKOUT_D102 +#define RZN1_CLKOUT_D163 +#define RZN1_MSEBIS_CLK3 /* AKA CLKOUT_D16 */ +#define RZN1_MSEBIM_CLK3 /* AKA CLKOUT_D16 */ +#define RZN1_CLKOUT_D160 4 +#define RZN1_CLKOUT_D1OR2 5 +#define RZN1_CLK_DDRPHY_PLLCLK 5 /* AKA CLKOUT_D1OR2 */ +#define RZN1_CLKOUT_D206 +#define RZN1_CLK50 6 /* AKA CLKOUT_D20 */ +#define RZN1_CLKOUT_D407 +#define RZN1_CLK25 7 /* AKA CLKOUT_D40 */ +#define RZN1_CLKOUT_D5 8 +#define RZN1_CLKOUT_D8 9 +#define RZN1_CLK1259 /* AKA CLKOUT_D8 */ +#define RZN1_DIV_ADC 10 +#define RZN1_DIV_I2C 11 +#define RZN1_DIV_NAND 12 +#define RZN1_DIV_P1_PG 13 +#define RZN1_DIV_P2_PG 14 +#define RZN1_DIV_P3_PG 15 +#define RZN1_DIV_P4_PG 16 +#define RZN1_DIV_P5_PG 17 +#define RZN1_CLK_P5_PG117 /* AKA DIV_P5_PG */ +#define RZN1_DIV_P6_PG 18 +#define RZN1_DIV_QSPI0 19 +#define RZN1_DIV_QSPI1 20 +#define RZN1_DIV_REF_SYNC 21 +#define RZN1_CLK_REF_SYNC 21 /* AKA DIV_REF_SYNC */ +#define RZN1_DIV_SDIO0 22 +#define RZN1_DIV_SDIO1 23 +#define RZN1_DIV_SWITCH24 +#define RZN1_DIV_UART 25 +#define RZN1_CLK_25_PG426 +#define RZN1_CLK_25_PG527 +#define RZN1_CLK_25_PG628 +#define RZN1_CLK_25_PG729 +#define RZN1_CLK_25_PG830 +#define RZN1_CLK_ADC 31 +#define RZN1_CLK_ECAT100 32 +#define RZN1_CLK_HSR10033 +#define RZN1_CLK_I2C0 34 +#define RZN1_CLK_I2C1 35 +#define RZN1_CLK_MII_REF 36 +#define RZN1_CLK_NAND 37 +#define RZN1_CLK_NOUSBP2_PG6 38 +#define RZN1_CLK_P1_PG239 +#define RZN1_CLK_P1_PG340 +#define RZN1_CLK_P1_PG441 +#define RZN1_CLK_P4_PG342 +#define RZN1_CLK_P4_PG443 +#define RZN1_CLK_P6_PG144 +#define RZN1_CLK_P6_PG245 +#define RZN1_CLK_P6_PG346 +#define RZN1_CLK_P6_PG447 +#define RZN1_CLK_PCI_USB 48 +#define RZN1_CLK_QSPI0 49 +#define RZN1_CLK_QSPI1 50 +#define RZN1_CLK_RGMII_REF 51 +#define RZN1_CLK_RMII_REF 52 +#define RZN1_CLK_SDIO0 53 +#define RZN1_CLK_SDIO1 54 +#define RZN1_CLK_SERCOS100 55 +#define RZN1_CLK_SLCD 56 +#define RZN1_CLK_SPI0 57 +#define RZN1_CLK_SPI1 58 +#define RZN1_CLK_SPI2 59 +#define RZN1_CLK_SPI3 60 +#define RZN1_CLK_SPI4 61 +#define RZN1_CLK_SPI5 62 +#define RZN1_CLK_SWITCH63 +#define RZN1_DIV_MOTOR 64 +#define RZN1_HCLK_ECAT125 65 +#define RZN1_HCLK_PINCONFIG66 +#define RZN1_HCLK_SERCOS 67 +#define RZN1_HCLK_SGPIO2 68 +#define RZN1_HCLK_SGPIO3 69 +#define RZN1_HCLK_SGPIO4 70 +#define RZN1_HCLK_TIMER0 71 +#define RZN1_HCLK_TIMER1 72 +#define RZN1_HCLK_USBF 73 +#define RZN1_HCLK_USBH 74 +#define RZN1_HCLK_USBPM75 +#define RZN1_CLK_48_PG_F 76 +#define RZN1_CLK_48_PG477 +#define RZN1_CLK_DDRPHY_PLLCLK_D4 78 +#define RZN1
[PATCH v6 3/6] dt-bindings: clock: renesas,rzn1-clocks: document RZ/N1 clock driver
The Renesas RZ/N1 Family (Part #R9A06G0xx) requires a driver
to provide the SoC clock infrastructure for Linux.
This documents the driver bindings.
Signed-off-by: Michel Pollet
---
.../bindings/clock/renesas,rzn1-clocks.txt | 44 ++
1 file changed, 44 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
diff --git a/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
b/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
new file mode 100644
index 000..0c41137
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
@@ -0,0 +1,44 @@
+* Renesas RZ/N1 Clock Driver
+
+This driver provides the clock infrastructure used by all the other drivers.
+
+One of the 'special' feature of this infrastructure is that Linux doesn't
+necessary 'own' all the clocks on the SoC, some other OS runs on
+the Cortex-M3 core and that OS can access and claim it's own clocks.
+
+Required Properties:
+
+ - compatible: Must be
+- "renesas,r9a06g032-clocks" for the RZ/N1D
+and "renesas,rzn1-clocks" as a fallback.
+ - reg: Base address and length of the memory resource used by the driver
+ - #clock-cells: Must be 1
+
+Examples
+
+
+ - Clock driver device node:
+
+ clock: clocks@4000c000 {
+ compatible = "renesas,r9a06g032-clocks",
+ "renesas,rzn1-clocks";
+ reg = <0x4000c000 0x1000>;
+ status = "okay";
+ #clock-cells = <1>;
+ };
+
+
+ - Other drivers can use the clocks as in:
+
+ uart0: serial@4006 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x4006 0x400>;
+ interrupts = ;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&clock RZN1_CLK_UART0>;
+ clock-names = "baudclk";
+ };
+Note the use of RZN1_CLK_UART0 -- these constants are declared in
+the rzn1-clocks.h header file. These are not hardware based constants
+and are Linux specific.
--
2.7.4
[PATCH v6 6/6] clk: renesas: Renesas RZ/N1 clock driver
This provides a clock driver for the Renesas RZ/N1 parts (#R09A06G0xx).
This uses a structure derived from both the RCAR gen2 driver as well as
the renesas-cpg-mssr driver.
Signed-off-by: Michel Pollet
---
drivers/clk/renesas/Kconfig | 6 +
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/rzn1-clocks.c | 814 ++
3 files changed, 821 insertions(+)
create mode 100644 drivers/clk/renesas/rzn1-clocks.c
diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
index f9ba71311..bdb8129 100644
--- a/drivers/clk/renesas/Kconfig
+++ b/drivers/clk/renesas/Kconfig
@@ -21,6 +21,7 @@ config CLK_RENESAS
select CLK_R8A77980 if ARCH_R8A77980
select CLK_R8A77990 if ARCH_R8A77990
select CLK_R8A77995 if ARCH_R8A77995
+ select CLK_RZN1 if ARCH_RZN1
select CLK_SH73A0 if ARCH_SH73A0
if CLK_RENESAS
@@ -151,6 +152,11 @@ config CLK_RCAR_USB2_CLOCK_SEL
help
This is a driver for R-Car USB2 clock selector
+config CLK_RZN1
+ bool "Renesas RZ/N1 clock driver"
+ help
+ This is a driver for RZ/N1 clocks
+
# Generic
config CLK_RENESAS_CPG_MSSR
bool "CPG/MSSR clock support" if COMPILE_TEST
diff --git a/drivers/clk/renesas/Makefile b/drivers/clk/renesas/Makefile
index fe5bac9..754281c 100644
--- a/drivers/clk/renesas/Makefile
+++ b/drivers/clk/renesas/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_CLK_RCAR_GEN2) += clk-rcar-gen2.o
obj-$(CONFIG_CLK_RCAR_GEN2_CPG)+= rcar-gen2-cpg.o
obj-$(CONFIG_CLK_RCAR_GEN3_CPG)+= rcar-gen3-cpg.o
obj-$(CONFIG_CLK_RCAR_USB2_CLOCK_SEL) += rcar-usb2-clock-sel.o
+obj-$(CONFIG_CLK_RZN1) += rzn1-clocks.o
# Generic
obj-$(CONFIG_CLK_RENESAS_CPG_MSSR) += renesas-cpg-mssr.o
diff --git a/drivers/clk/renesas/rzn1-clocks.c
b/drivers/clk/renesas/rzn1-clocks.c
new file mode 100644
index 000..06c176b
--- /dev/null
+++ b/drivers/clk/renesas/rzn1-clocks.c
@@ -0,0 +1,814 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RZ/N1 clock driver
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ * Michel Pollet ,
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct rzn1_gate {
+ uint16_t gate, reset, ready, midle,
+ scon, mirack, mistat;
+};
+
+/* This is used to describe a clock for instantiation */
+struct rzn1_clkdesc {
+ const char *name;
+ uint32_t type: 3;
+ uint32_t index: 8;
+ uint32_t source : 8; /* source index + 1 (0 == none) */
+ /* these are used to populate the bitsel struct */
+ union {
+ struct rzn1_gate gate;
+ /* for dividers */
+ struct {
+ unsigned int div_min : 10, div_max : 10, reg: 10;
+ uint16_t div_table[4];
+ };
+ /* For fixed-factor ones */
+ uint16_t div;
+ unsigned int factor;
+ unsigned int frequency;
+ /* for dual gate */
+ struct {
+ uint16_t group : 1, index: 3;
+ uint16_t sel, g1, r1, g2, r2;
+ } dual;
+ };
+} __packed;
+
+#define I_GATE(_clk, _rst, _rdy, _midle, _scon, _mirack, _mistat) \
+ { .gate = _clk, .reset = _rst, \
+ .ready = _rdy, .midle = _midle, \
+ .scon = _scon, .mirack = _mirack, .mistat = _mistat }
+#define D_GATE(_idx, _n, _src, ...) \
+ { .type = K_GATE, .index = RZN1_##_idx, \
+ .source = 1 + RZN1_##_src, .name = _n, \
+ .gate = I_GATE(__VA_ARGS__), }
+#define D_FC(_idx, _n, _freq) \
+ { .type = K_FC, .index = RZN1_##_idx, .name = _n, .frequency = _freq, }
+#define D_FFC(_idx, _n, _src, _div) \
+ { .type = K_FFC, .index = RZN1_##_idx, \
+ .source = 1 + RZN1_##_src, .name = _n, \
+ .div = _div, }
+#define D_DIV(_idx, _n, _src, _reg, _min, _max, ...) \
+ { .type = K_DIV, .index = RZN1_##_idx, \
+ .source = 1 + RZN1_##_src, .name = _n, \
+ .reg = _reg, .div_min = _min, .div_max = _max, \
+ .div_table = { __VA_ARGS__ } }
+#define D_UGATE(_idx, _n, _src, _g, _gi, _g1, _r1, _g2, _r2) \
+ { .type = K_DUALGATE, .index = RZN1_##_idx, \
+ .source = 1 + RZN1_##_src, .name = _n, \
+ .dual = { .group = _g, .index = _gi, \
+ .g1 = _g1, .r1 = _r1, .g2 = _g2, .r2 = _r2 }, }
+
+enum { K_GATE = 0, K_FFC, K_FC, K_DIV, K_BITSEL, K_DUALGATE };
+
+static const struct rzn1_clkdesc rzn1_clocks[] __initconst = {
+ D_FC(CLKOUT, "clkout", 10),
+ D_FC(CLK_PLL_USB, "clk_pll_usb", 4800),
+ D_FFC(CLKOUT_D10, "clkout_d10", CLKOUT, 10),
+ D_FFC(CLKOUT_D16, "clkout_d16", CLKOUT, 16),
+ D_FFC(CLKOUT_D160, "clkout_d160", CLKOUT, 160),
+
[PATCH v6 5/6] ARM: dts: Renesas RZN1D-DB Board base file
This adds a base device tree file for the RZN1-DB board, with only the
basic support allowing the system to boot to a prompt. Only one UART is
used, with only a single CPU running.
Signed-off-by: Michel Pollet
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts | 29 +
2 files changed, 30 insertions(+)
create mode 100644 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f4753b0..6157897 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -814,6 +814,7 @@ dtb-$(CONFIG_ARCH_RENESAS) += \
r8a7793-gose.dtb \
r8a7794-alt.dtb \
r8a7794-silk.dtb \
+ r9a06g032-rzn1d400-db.dtb \
sh73a0-kzm9g.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rv1108-evb.dtb \
diff --git a/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
new file mode 100644
index 000..5fc2c40
--- /dev/null
+++ b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the RZN1D-DB Board
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ */
+
+/dts-v1/;
+
+#include "r9a06g032.dtsi"
+
+/ {
+ model = "RZN1D-DB Board";
+ compatible = "renesas,rzn1d400-db",
+ "renesas,r9a06g032", "renesas,rzn1";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ aliases {
+ serial0 = &uart0;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
--
2.7.4
[PATCH v6 4/6] ARM: dts: Renesas RZ/N1 SoC base device tree file
This adds the Renesas RZ/N1D (Part #R9A06G032) SoC bare
bone support.
This currently only handles generic parts (gic, architected timer)
and a UART.
For simplicity sake, this also relies on the bootloader to set the
pinctrl and clocks.
Signed-off-by: Michel Pollet
---
arch/arm/boot/dts/r9a06g032.dtsi | 86
1 file changed, 86 insertions(+)
create mode 100644 arch/arm/boot/dts/r9a06g032.dtsi
diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
new file mode 100644
index 000..c7764c7
--- /dev/null
+++ b/arch/arm/boot/dts/r9a06g032.dtsi
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Base Device Tree Source for the Renesas RZ/N1D (R9A06G032)
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ */
+
+#include
+#include
+
+/ {
+ compatible = "renesas,r9a06g032", "renesas,rzn1";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clock RZN1_DIV_CA7>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <1>;
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&gic>;
+ ranges;
+
+ clock: clocks@4000c000 {
+ compatible = "renesas,r9a06g032-clocks",
+ "renesas,rzn1-clocks";
+ reg = <0x4000c000 0x1000>;
+ status = "okay";
+ #clock-cells = <1>;
+ };
+
+ uart0: serial@4006 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x4006 0x400>;
+ interrupts = ;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&clock RZN1_CLK_UART0>;
+ clock-names = "baudclk";
+ status = "disabled";
+ };
+
+ gic: gic@44101000 {
+ compatible = "arm,cortex-a7-gic", "arm,gic-400";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x44101000 0x1000>, /* Distributer */
+ <0x44102000 0x2000>, /* CPU interface */
+ <0x44104000 0x2000>, /* Virt interface control */
+ <0x44106000 0x2000>; /* Virt CPU interface */
+ interrupts =
+ ;
+ };
+ };
+
+ timer {
+ compatible = "arm,cortex-a7-timer",
+"arm,armv7-timer";
+ interrupt-parent = <&gic>;
+ arm,cpu-registers-not-fw-configured;
+ always-on;
+ interrupts =
+ ,
+ ,
+ ,
+ ;
+ };
+};
--
2.7.4
Re: [PATCH] PCI: rcar: Poll more often in rcar_pcie_wait_for_dl()
Hi Marek,
On Tue, May 22, 2018 at 11:48 AM, Marek Vasut wrote:
> On 05/22/2018 11:42 AM, Geert Uytterhoeven wrote:
>> On Mon, May 21, 2018 at 11:05 PM, Marek Vasut wrote:
>>> The data link active signal usually takes ~20 uSec to be asserted,
>>> poll the bit more often to avoid useless delays in this function.
>>> Use udelay() instead of usleep() for such a small delay as suggested
>>> by the timer documentation and because this will be used in atomic
>>> context later on when the suspend/resume patches land.
>>>
>>> Signed-off-by: Marek Vasut
>>
>> Thanks for your patch!
>>
>>> --- a/drivers/pci/host/pcie-rcar.c
>>> +++ b/drivers/pci/host/pcie-rcar.c
>>> @@ -529,13 +529,13 @@ static void phy_write_reg(struct rcar_pcie *pcie,
>>>
>>> static int rcar_pcie_wait_for_dl(struct rcar_pcie *pcie)
>>> {
>>> - unsigned int timeout = 10;
>>> + unsigned int timeout = 1;
>>>
>>> while (timeout--) {
>>> if ((rcar_pci_read_reg(pcie, PCIETSTR) & DATA_LINK_ACTIVE))
>>> return 0;
>>>
>>> - msleep(5);
>>> + udelay(5);
>>
>> + cpu_relax()?
>
> Is it safe to use in atomic context ? Because of that suspend/resume thing.
Yes.
>>> }
>>
>> if this ever happens, it will have blocked for more than 50 ms...
>
> Well yes, so did the previous thing.
No, the previous thing slept. Big difference.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/4] PCI: rcar: Rename rcar_pcie_parse_request_of_pci_ranges()
On Mon, May 21, 2018 at 3:11 PM, Marek Vasut wrote:
> The function name is just too confusing, rename it, no functional change.
> Rename the function to rcar_pcie_alloc_and_parse_pci_resource_list() as
> it's matching failpath function is pci_free_resource_list() so the names
> align much better and the new name also describes what the function does
> much better.
>
> Signed-off-by: Marek Vasut
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2] v4l: vsp1: Fix vsp1_regs.h license header
Hi Simon,
On Tue, May 22, 2018 at 11:05 AM, Simon Horman wrote:
>> --- a/drivers/media/platform/vsp1/vsp1_regs.h
>> +++ b/drivers/media/platform/vsp1/vsp1_regs.h
>> @@ -1,4 +1,4 @@
>> -/* SPDX-License-Identifier: GPL-2.0 */
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>
> While you are changing this line, I believe the correct format is
> to use a '//' comment.
>
> i.e.:
>
> // SPDX-License-Identifier: GPL-2.0+
Not for C header files, only for C source files.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/2] arm64: dts: renesas: r8a77980: add GEther support
Hi Sergei,
On Fri, May 18, 2018 at 9:45 PM, Sergei Shtylyov
wrote:
> Define the generic R8A77980 part of the GEther device node.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
Thanks for your patch!
With the below addressed:
Reviewed-by: Geert Uytterhoeven
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> @@ -417,6 +417,17 @@
> dma-channels = <16>;
> };
>
> + gether: ethernet@e740 {
> + compatible = "renesas,gether-r8a77980";
> + reg = <0 0xe740 0 0x1000>;
> + interrupts = ;
> + clocks = <&cpg CPG_MOD 813>;
> + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
resets = <&cpg 813>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
Any default phy-mode needed?
> + };
> +
> mmc0: mmc@ee14 {
> compatible = "renesas,sdhi-r8a77980",
> "renesas,rcar-gen3-sdhi";
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 3/5] arm64: dts: renesas: r8a77995: Add LVDS support
Hi Laurent,
On Sun, May 20, 2018 at 10:50 AM, Laurent Pinchart
wrote:
> On Tuesday, 15 May 2018 15:20:38 EEST Ulrich Hecht wrote:
>> From: Kieran Bingham
>>
>> The r8a77995 D3 platform has 2 LVDS channels connected to the DU.
>>
>> Signed-off-by: Kieran Bingham
>> [uli: moved lvds* into the soc node, added PM domains, resets]
>> Signed-off-by: Ulrich Hecht
>> ---
>> arch/arm64/boot/dts/renesas/r8a77995.dtsi | 56
>> 1 file changed, 56 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index ba98865..8e78110d 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
>> @@ -757,12 +757,68 @@
>> port@1 {
>> reg = <1>;
>> du_out_lvds0: endpoint {
>> + remote-endpoint = <&lvds0_in>;
>> };
>> };
>>
>> port@2 {
>> reg = <2>;
>> du_out_lvds1: endpoint {
>> + remote-endpoint = <&lvds1_in>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + lvds0: lvds-encoder@feb9 {
>> + compatible = "renesas,r8a77995-lvds";
>> + reg = <0 0xfeb9 0 0x20>;
>> + clocks = <&cpg CPG_MOD 727>;
>> + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
>> + resets = <&cpg 727>;
>> + status = "disabled";
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + lvds0_in: endpoint {
>> + remote-endpoint =
>> <&du_out_lvds0>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> + lvds0_out: endpoint {
>> + };
>> + };
>> + };
>> + };
>> +
>> + lvds1: lvds-encoder@feb90100 {
>> + compatible = "renesas,r8a77995-lvds";
>> + reg = <0 0xfeb90100 0 0x20>;
>> + clocks = <&cpg CPG_MOD 727>;
>> + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
>> + resets = <&cpg 727>;
>
> While there seems to be a single clock for both LVDS encoders, it appears that
> two separate reset lines are used.
Nice catch!
So you can reset the individual LVDS instances, but not the individual DU
instances. Doh...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH/RFC v4 3/4] usb: gadget: udc: renesas_usb3: use usb role switch API
This patch uses usb role switch APIs if the register suceeeded.
Signed-off-by: Yoshihiro Shimoda
---
drivers/usb/gadget/udc/renesas_usb3.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/renesas_usb3.c
b/drivers/usb/gadget/udc/renesas_usb3.c
index 9667a5e..d6c11c9 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -338,6 +338,8 @@ struct renesas_usb3 {
struct usb_role_switch *role_sw;
struct device *host_dev;
+ struct work_struct role_work;
+ enum usb_role role;
struct renesas_usb3_ep *usb3_ep;
int num_usb3_eps;
@@ -655,7 +657,15 @@ static void usb3_check_vbus(struct renesas_usb3 *usb3)
}
}
-static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
+static void renesas_usb3_role_work(struct work_struct *work)
+{
+ struct renesas_usb3 *usb3 = container_of(work, struct renesas_usb3,
+role_work);
+
+ usb_role_switch_set_role(usb3->role_sw, usb3->role);
+}
+
+static void _usb3_set_mode(struct renesas_usb3 *usb3, bool host)
{
if (host)
usb3_clear_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
@@ -663,6 +673,16 @@ static void usb3_set_mode(struct renesas_usb3 *usb3, bool
host)
usb3_set_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
}
+static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
+{
+ if (usb3->role_sw) {
+ usb3->role = host ? USB_ROLE_HOST : USB_ROLE_DEVICE;
+ schedule_work(&usb3->role_work);
+ } else {
+ _usb3_set_mode(usb3, host);
+ }
+}
+
static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
{
if (enable)
@@ -2328,10 +2348,10 @@ static int renesas_usb3_role_switch_set(struct device
*dev,
pm_runtime_get_sync(dev);
if (cur_role == USB_ROLE_HOST && role == USB_ROLE_DEVICE) {
device_release_driver(host);
- usb3_set_mode(usb3, false);
+ _usb3_set_mode(usb3, false);
} else if (cur_role == USB_ROLE_DEVICE && role == USB_ROLE_HOST) {
/* Must set the mode before device_attach of the host */
- usb3_set_mode(usb3, true);
+ _usb3_set_mode(usb3, true);
/* This device_attach() might sleep */
if (device_attach(host) < 0)
dev_err(dev, "device_attach(usb3_port) failed\n");
@@ -2726,6 +2746,7 @@ static int renesas_usb3_probe(struct platform_device
*pdev)
if (ret < 0)
goto err_dev_create;
+ INIT_WORK(&usb3->role_work, renesas_usb3_role_work);
usb3->role_sw = usb_role_switch_register(&pdev->dev,
&renesas_usb3_role_switch_desc);
if (!IS_ERR(usb3->role_sw)) {
--
1.9.1
[PATCH/RFC v4 4/4] arm64: dts: renesas: r8a7795: add OF graph for usb role switch
This patch adds OF graph properties for usb role switch in r8a7795
into USB3.0 host/peripheral nodes.
TODO:
- need patches for other SoCs.
Signed-off-by: Yoshihiro Shimoda
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 1d5e3ac..50d3312 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1746,6 +1746,12 @@
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
resets = <&cpg 328>;
status = "disabled";
+
+ port {
+ usb3_host0_ep: endpoint {
+ remote-endpoint = <&usb3_peri0_ep>;
+ };
+ };
};
usb3_peri0: usb@ee02 {
@@ -1757,6 +1763,12 @@
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
resets = <&cpg 328>;
status = "disabled";
+
+ port {
+ usb3_peri0_ep: endpoint {
+ remote-endpoint = <&usb3_host0_ep>;
+ };
+ };
};
usb_dmac0: dma-controller@e65a {
--
1.9.1
[PATCH/RFC v4 2/4] usb: gadget: udc: renesas_usb3: Add register of usb role switch
This patch adds role switch support for R-Car SoCs into the USB 3.0
peripheral driver. Some R-Car SoCs (e.g. R-Car H3) have USB 3.0
dual-role device controller which has the USB 3.0 xHCI host and
Renesas USB 3.0 peripheral.
Unfortunately, the mode change register contains the USB 3.0 peripheral
controller side only. So, the USB 3.0 peripheral driver (renesas_usb3)
manages this register now. However, in peripheral mode, the host
should stop. Also the host hardware needs to reinitialize its own
registers when the mode changes from peripheral to host mode.
Otherwise, the host cannot work correctly (e.g. detect a device as
high-speed).
To achieve this by a driver, this role switch driver manages
the mode change register and attach/release the xhci-plat driver.
Signed-off-by: Yoshihiro Shimoda
---
.../devicetree/bindings/usb/renesas_usb3.txt | 15
drivers/usb/gadget/udc/Kconfig | 1 +
drivers/usb/gadget/udc/renesas_usb3.c | 82 ++
3 files changed, 98 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
index 2c071bb5..f6105aa 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
@@ -19,6 +19,9 @@ Required properties:
Optional properties:
- phys: phandle + phy specifier pair
- phy-names: must be "usb"
+ - The connection to a usb3.0 host node needs by using OF graph bindings for
+usb role switch.
+ - port@0 = USB3.0 host port.
Example of R-Car H3 ES1.x:
usb3_peri0: usb@ee02 {
@@ -27,6 +30,12 @@ Example of R-Car H3 ES1.x:
reg = <0 0xee02 0 0x400>;
interrupts = ;
clocks = <&cpg CPG_MOD 328>;
+
+ port {
+ usb3_peri0_ep: endpoint {
+ remote-endpoint = <&usb3_host0_ep>;
+ };
+ };
};
usb3_peri1: usb@ee06 {
@@ -35,4 +44,10 @@ Example of R-Car H3 ES1.x:
reg = <0 0xee06 0 0x400>;
interrupts = ;
clocks = <&cpg CPG_MOD 327>;
+
+ port {
+ usb3_peri1_ep: endpoint {
+ remote-endpoint = <&usb3_host1_ep>;
+ };
+ };
};
diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index b838cae..78823cd 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -193,6 +193,7 @@ config USB_RENESAS_USB3
tristate 'Renesas USB3.0 Peripheral controller'
depends on ARCH_RENESAS || COMPILE_TEST
depends on EXTCON && HAS_DMA
+ select USB_ROLE_SWITCH
help
Renesas USB3.0 Peripheral controller is a USB peripheral controller
that supports super, high, and full speed USB 3.0 data transfers.
diff --git a/drivers/usb/gadget/udc/renesas_usb3.c
b/drivers/usb/gadget/udc/renesas_usb3.c
index 5caf78b..9667a5e 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
/* register definitions */
#define USB3_AXI_INT_STA 0x008
@@ -335,6 +336,9 @@ struct renesas_usb3 {
struct phy *phy;
struct dentry *dentry;
+ struct usb_role_switch *role_sw;
+ struct device *host_dev;
+
struct renesas_usb3_ep *usb3_ep;
int num_usb3_eps;
@@ -2302,6 +2306,41 @@ static int renesas_usb3_set_selfpowered(struct
usb_gadget *gadget, int is_self)
.set_selfpowered= renesas_usb3_set_selfpowered,
};
+static enum usb_role renesas_usb3_role_switch_get(struct device *dev)
+{
+ struct renesas_usb3 *usb3 = dev_get_drvdata(dev);
+ enum usb_role cur_role;
+
+ pm_runtime_get_sync(dev);
+ cur_role = usb3_is_host(usb3) ? USB_ROLE_HOST : USB_ROLE_DEVICE;
+ pm_runtime_put(dev);
+
+ return cur_role;
+}
+
+static int renesas_usb3_role_switch_set(struct device *dev,
+ enum usb_role role)
+{
+ struct renesas_usb3 *usb3 = dev_get_drvdata(dev);
+ struct device *host = usb3->host_dev;
+ enum usb_role cur_role = renesas_usb3_role_switch_get(dev);
+
+ pm_runtime_get_sync(dev);
+ if (cur_role == USB_ROLE_HOST && role == USB_ROLE_DEVICE) {
+ device_release_driver(host);
+ usb3_set_mode(usb3, false);
+ } else if (cur_role == USB_ROLE_DEVICE && role == USB_ROLE_HOST) {
+ /* Must set the mode before device_attach of the host */
+ usb3_set_mode(usb3, true);
+ /* This device_attach() might sleep */
+ if (device_attach(host) < 0)
+ dev_err(dev, "device_attach(usb3_port) failed\n");
+ }
+ pm_runtime_put(dev);
+
+ return 0;
[PATCH/RFC v4 1/4] base: devcon: add graph parse in device_connection_find_match()
This patch adds graph parsing in device_connection_find_match().
The match function will be called with fwnode pointer in struct
device_connection. So, a caller can check the matching by using it.
Signed-off-by: Yoshihiro Shimoda
---
Documentation/driver-api/device_connection.rst | 2 +-
drivers/base/devcon.c | 15 +++
include/linux/device.h | 2 ++
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/driver-api/device_connection.rst
b/Documentation/driver-api/device_connection.rst
index affbc556..cc6b1da 100644
--- a/Documentation/driver-api/device_connection.rst
+++ b/Documentation/driver-api/device_connection.rst
@@ -19,7 +19,7 @@ Device connections alone do not create a dependency between
the two devices.
They are only descriptions which are not tied to either of the devices
directly.
A dependency between the two devices exists only if one of the two endpoint
devices requests a reference to the other. The descriptions themselves can be
-defined in firmware (not yet supported) or they can be built-in.
+defined in firmware or they can be built-in.
Usage
-
diff --git a/drivers/base/devcon.c b/drivers/base/devcon.c
index d427e80..374bb39 100644
--- a/drivers/base/devcon.c
+++ b/drivers/base/devcon.c
@@ -7,6 +7,7 @@
*/
#include
+#include
static DEFINE_MUTEX(devcon_lock);
static LIST_HEAD(devcon_list);
@@ -31,10 +32,24 @@ void *device_connection_find_match(struct device *dev,
const char *con_id,
struct device_connection *con;
void *ret = NULL;
int ep;
+ struct device_connection graph;
+ struct fwnode_handle *fwnode_ep;
+ struct fwnode_handle *remote;
if (!match)
return NULL;
+ fwnode_graph_for_each_endpoint(dev->fwnode, fwnode_ep) {
+ remote = fwnode_graph_get_remote_port_parent(fwnode_ep);
+ if (!remote)
+ continue;
+
+ graph.fwnode = remote;
+ ret = match(&graph, 0, data);
+ if (!IS_ERR(ret))
+ return ret;
+ }
+
mutex_lock(&devcon_lock);
list_for_each_entry(con, &devcon_list, list) {
diff --git a/include/linux/device.h b/include/linux/device.h
index 0059b99..175907b 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -734,11 +734,13 @@ struct device_dma_parameters {
* struct device_connection - Device Connection Descriptor
* @endpoint: The names of the two devices connected together
* @id: Unique identifier for the connection
+ * @fwnode: fwnode pointer for finding a connection from graph
* @list: List head, private, for internal use only
*/
struct device_connection {
const char *endpoint[2];
const char *id;
+ struct fwnode_handle*fwnode;
struct list_headlist;
};
--
1.9.1
[PATCH/RFC v4 0/4] usb: role: rcar-usb3-role-switch: add support for R-Car SoCs
This patch set is based on Felipe's usb.git / testing/next branch (commit id = 47265c067c0d129f3a0e94bc221293a780af9d78). I still marked this patch set as "RFC". I would like to know whether this way is good or not. About last discusstion with Heikki: https://patchwork.kernel.org/patch/10397635/ Changes from RFC v3: - Rebase latest usb.git / testing/next branch. - Add graph parse into device_connection_find_match(). - Use workqueue to call _usb3_set_mode() in patch 3. (I realized renesas_usb3_role_switch_set() cannot run on atomic because device_attach() might sleep.) Changes from RFC v2: - Add registering usb role switch into drivers/usb/gadget/udc/renesas_usb3 because hardware resource (a register) is shared and remove individual usb role switch driver/dt-bindings for R-Car. - Remove "usb_role_switch_get_by_graph" API because the renesas_usb3 driver doesn't need such API now. Changes from RFC: - Remove "device-connection-id" and "usb role switch driver" dt-bingings. - Remove drivers/of code. - Add a new API for find the connection by using graph on devcon.c and roles.c. - Use each new API on the rcar usb role switch and renesas_usb3 drivers. - Update the dtsi file for r8a7795. Yoshihiro Shimoda (4): base: devcon: add graph parse in device_connection_find_match() usb: gadget: udc: renesas_usb3: Add register of usb role switch usb: gadget: udc: renesas_usb3: use usb role switch API arm64: dts: renesas: r8a7795: add OF graph for usb role switch .../devicetree/bindings/usb/renesas_usb3.txt | 15 +++ Documentation/driver-api/device_connection.rst | 2 +- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 12 +++ drivers/base/devcon.c | 15 +++ drivers/usb/gadget/udc/Kconfig | 1 + drivers/usb/gadget/udc/renesas_usb3.c | 105 - include/linux/device.h | 2 + 7 files changed, 150 insertions(+), 2 deletions(-) -- 1.9.1
[PATCH 5/9] ARM: dts: porter: Drop MTD partitioning from DT
Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.
To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:
mtdparts=spi0.0:256k@0(loader_prg),4096k(user_prg),-(flash_fs)
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Laurent Pinchart
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm/boot/dts/r8a7791-porter.dts | 21 -
1 file changed, 21 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791-porter.dts
b/arch/arm/boot/dts/r8a7791-porter.dts
index a01101b49d99..45d89e064407 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -344,27 +344,6 @@
spi-tx-bus-width = <4>;
spi-rx-bus-width = <4>;
m25p,fast-read;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "loader_prg";
- reg = <0x 0x0004>;
- read-only;
- };
- partition@4 {
- label = "user_prg";
- reg = <0x0004 0x0040>;
- read-only;
- };
- partition@44 {
- label = "flash_fs";
- reg = <0x0044 0x03bc>;
- };
- };
};
};
--
2.16.2
[PATCH 1/9] ARM: shmobile: defconfig: Enable MTD command line partition parsing
In preparation for removing MTD partitioning from the DTs and moving it over to kernel command line partition parsing, enable the support for kernel command line MTD partition parsing. The argument for not having MTD partitions in the DT is the same as for not having hard drive partitions in DT, neither describes the hardware itself, so it shouldn't be in the DT. Furthermore, kernel command line MTD partition passing allows greater flexibility in case someone decided to repartition the flash, which is well in the realm of possibility with these systems. Signed-off-by: Marek Vasut Cc: Geert Uytterhoeven Cc: Laurent Pinchart Cc: Simon Horman Cc: Wolfram Sang Cc: linux-renesas-soc@vger.kernel.org --- arch/arm/configs/shmobile_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig index b49887e86a3d..4d0d5a00a188 100644 --- a/arch/arm/configs/shmobile_defconfig +++ b/arch/arm/configs/shmobile_defconfig @@ -64,6 +64,7 @@ CONFIG_DMA_CMA=y CONFIG_CMA_SIZE_MBYTES=64 CONFIG_SIMPLE_PM_BUS=y CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_BLOCK=y CONFIG_MTD_M25P80=y CONFIG_MTD_SPI_NOR=y -- 2.16.2
[PATCH 3/9] ARM: dts: stout: Drop MTD partitioning from DT
Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.
To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:
mtdparts=spi0.0:512k@0(loader),256k(uboot),256k(uboot-env),-(flash)
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Laurent Pinchart
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm/boot/dts/r8a7790-stout.dts | 26 --
1 file changed, 26 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790-stout.dts
b/arch/arm/boot/dts/r8a7790-stout.dts
index a13a92c26645..dc65519d53ab 100644
--- a/arch/arm/boot/dts/r8a7790-stout.dts
+++ b/arch/arm/boot/dts/r8a7790-stout.dts
@@ -211,32 +211,6 @@
spi-cpha;
spi-cpol;
m25p,fast-read;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "loader";
- reg = <0x 0x0008>;
- read-only;
- };
- partition@8 {
- label = "uboot";
- reg = <0x0008 0x0004>;
- read-only;
- };
- partition@c {
- label = "uboot-env";
- reg = <0x000c 0x0004>;
- read-only;
- };
- partition@10 {
- label = "flash";
- reg = <0x0010 0x03f0>;
- };
- };
};
};
--
2.16.2
[PATCH 9/9] ARM: dts: silk: Drop MTD partitioning from DT
Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.
To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:
mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Laurent Pinchart
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm/boot/dts/r8a7794-silk.dts | 21 -
1 file changed, 21 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7794-silk.dts
b/arch/arm/boot/dts/r8a7794-silk.dts
index 7808aaee6644..b8163a0e2190 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -444,27 +444,6 @@
spi-cpol;
spi-cpha;
m25p,fast-read;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "loader";
- reg = <0x 0x0004>;
- read-only;
- };
- partition@4 {
- label = "user";
- reg = <0x0004 0x0040>;
- read-only;
- };
- partition@44 {
- label = "flash";
- reg = <0x0044 0x03bc>;
- };
- };
};
};
--
2.16.2
[PATCH 8/9] ARM: dts: alt: Drop MTD partitioning from DT
Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.
To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:
mtdparts=spi0.0:256k@0(loader),256k(system),-(user)
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Laurent Pinchart
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm/boot/dts/r8a7794-alt.dts | 21 -
1 file changed, 21 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7794-alt.dts
b/arch/arm/boot/dts/r8a7794-alt.dts
index e17027532941..1d044ed598f3 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -419,26 +419,5 @@
spi-cpol;
spi-cpha;
m25p,fast-read;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "loader";
- reg = <0x 0x0004>;
- read-only;
- };
- partition@4 {
- label = "system";
- reg = <0x0004 0x0004>;
- read-only;
- };
- partition@8 {
- label = "user";
- reg = <0x0008 0x03f8>;
- };
- };
};
};
--
2.16.2
[PATCH 4/9] ARM: dts: koelsch: Drop MTD partitioning from DT
Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.
To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:
mtdparts=spi0.0:512k@0(loader),5632k(user),-(flash)
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Laurent Pinchart
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm/boot/dts/r8a7791-koelsch.dts | 21 -
1 file changed, 21 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 8ab793d8b2fd..406d5d29e29c 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -724,27 +724,6 @@
spi-cpha;
spi-cpol;
m25p,fast-read;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "loader";
- reg = <0x 0x0008>;
- read-only;
- };
- partition@8 {
- label = "user";
- reg = <0x0008 0x0058>;
- read-only;
- };
- partition@60 {
- label = "flash";
- reg = <0x0060 0x03a0>;
- };
- };
};
};
--
2.16.2
[PATCH 2/9] ARM: dts: lager: Drop MTD partitioning from DT
Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.
To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:
mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Laurent Pinchart
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm/boot/dts/r8a7790-lager.dts | 21 -
1 file changed, 21 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index 092610e3f953..7c95e62efd46 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -710,27 +710,6 @@
spi-cpha;
spi-cpol;
m25p,fast-read;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "loader";
- reg = <0x 0x0004>;
- read-only;
- };
- partition@4 {
- label = "user";
- reg = <0x0004 0x0040>;
- read-only;
- };
- partition@44 {
- label = "flash";
- reg = <0x0044 0x03bc>;
- };
- };
};
};
--
2.16.2
[PATCH 7/9] ARM: dts: gose: Drop MTD partitioning from DT
Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.
To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:
mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Laurent Pinchart
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm/boot/dts/r8a7793-gose.dts | 21 -
1 file changed, 21 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7793-gose.dts
b/arch/arm/boot/dts/r8a7793-gose.dts
index aa209f6e5d71..b2dd54fbe40c 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -676,27 +676,6 @@
spi-cpol;
spi-cpha;
m25p,fast-read;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "loader";
- reg = <0x 0x0004>;
- read-only;
- };
- partition@4 {
- label = "user";
- reg = <0x0004 0x0040>;
- read-only;
- };
- partition@44 {
- label = "flash";
- reg = <0x0044 0x03bc>;
- };
- };
};
};
--
2.16.2
[PATCH 6/9] ARM: dts: wheat: Drop MTD partitioning from DT
Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.
To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:
mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Laurent Pinchart
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm/boot/dts/r8a7792-wheat.dts | 21 -
1 file changed, 21 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7792-wheat.dts
b/arch/arm/boot/dts/r8a7792-wheat.dts
index db01de7a3811..93f78716225a 100644
--- a/arch/arm/boot/dts/r8a7792-wheat.dts
+++ b/arch/arm/boot/dts/r8a7792-wheat.dts
@@ -217,27 +217,6 @@
spi-cpol;
spi-cpha;
m25p,fast-read;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "loader";
- reg = <0x 0x0004>;
- read-only;
- };
- partition@4 {
- label = "user";
- reg = <0x0004 0x0040>;
- read-only;
- };
- partition@44 {
- label = "flash";
- reg = <0x0044 0x03bc>;
- };
- };
};
};
--
2.16.2
[PATCH V3] PCI: rcar: Poll more often in rcar_pcie_wait_for_dl()
The data link active signal usually takes ~20 uSec to be asserted,
poll the bit more often to avoid useless delays in this function.
Use udelay() instead of usleep() for such a small delay as suggested
by the timer documentation and because this will be used in atomic
context later on when the suspend/resume patches land.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
---
V2: s/content/context in commit message
V3: Add cpu_relax()
---
drivers/pci/host/pcie-rcar.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 5c365f743df5..3aa6fe5f2d64 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -529,13 +529,14 @@ static void phy_write_reg(struct rcar_pcie *pcie,
static int rcar_pcie_wait_for_dl(struct rcar_pcie *pcie)
{
- unsigned int timeout = 10;
+ unsigned int timeout = 1;
while (timeout--) {
if ((rcar_pci_read_reg(pcie, PCIETSTR) & DATA_LINK_ACTIVE))
return 0;
- msleep(5);
+ udelay(5);
+ cpu_relax();
}
return -ETIMEDOUT;
--
2.16.2
Re: [PATCH 1/9] ARM: shmobile: defconfig: Enable MTD command line partition parsing
On Tue, May 22, 2018 at 02:02:49PM +0200, Marek Vasut wrote: > In preparation for removing MTD partitioning from the DTs and moving > it over to kernel command line partition parsing, enable the support > for kernel command line MTD partition parsing. > > The argument for not having MTD partitions in the DT is the same as > for not having hard drive partitions in DT, neither describes the > hardware itself, so it shouldn't be in the DT. Furthermore, kernel > command line MTD partition passing allows greater flexibility in > case someone decided to repartition the flash, which is well in the > realm of possibility with these systems. > > Signed-off-by: Marek Vasut Makes a lot of sense to me. Acked-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH 2/9] ARM: dts: lager: Drop MTD partitioning from DT
On Tue, May 22, 2018 at 02:02:50PM +0200, Marek Vasut wrote: > Drop the MTD partitioning from DT, since it does not describe HW > and to give way to a more flexible kernel command line partition > passing. > > To retain the original partitioning, assure you have enabled > CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the > following to your kernel command line: > > mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash) > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Laurent Pinchart > Cc: Simon Horman > Cc: Wolfram Sang > Cc: linux-renesas-soc@vger.kernel.org Acked-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH 4/9] ARM: dts: koelsch: Drop MTD partitioning from DT
On Tue, May 22, 2018 at 02:02:52PM +0200, Marek Vasut wrote: > Drop the MTD partitioning from DT, since it does not describe HW > and to give way to a more flexible kernel command line partition > passing. > > To retain the original partitioning, assure you have enabled > CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the > following to your kernel command line: > > mtdparts=spi0.0:512k@0(loader),5632k(user),-(flash) > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Laurent Pinchart > Cc: Simon Horman > Cc: Wolfram Sang > Cc: linux-renesas-soc@vger.kernel.org Acked-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH 5/9] ARM: dts: porter: Drop MTD partitioning from DT
On Tue, May 22, 2018 at 02:02:53PM +0200, Marek Vasut wrote: > Drop the MTD partitioning from DT, since it does not describe HW > and to give way to a more flexible kernel command line partition > passing. > > To retain the original partitioning, assure you have enabled > CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the > following to your kernel command line: > > mtdparts=spi0.0:256k@0(loader_prg),4096k(user_prg),-(flash_fs) > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Laurent Pinchart > Cc: Simon Horman > Cc: Wolfram Sang > Cc: linux-renesas-soc@vger.kernel.org Acked-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH 3/9] ARM: dts: stout: Drop MTD partitioning from DT
On Tue, May 22, 2018 at 02:02:51PM +0200, Marek Vasut wrote: > Drop the MTD partitioning from DT, since it does not describe HW > and to give way to a more flexible kernel command line partition > passing. > > To retain the original partitioning, assure you have enabled > CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the > following to your kernel command line: > > mtdparts=spi0.0:512k@0(loader),256k(uboot),256k(uboot-env),-(flash) > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Laurent Pinchart > Cc: Simon Horman > Cc: Wolfram Sang > Cc: linux-renesas-soc@vger.kernel.org Acked-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH 8/9] ARM: dts: alt: Drop MTD partitioning from DT
On Tue, May 22, 2018 at 02:02:56PM +0200, Marek Vasut wrote: > Drop the MTD partitioning from DT, since it does not describe HW > and to give way to a more flexible kernel command line partition > passing. > > To retain the original partitioning, assure you have enabled > CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the > following to your kernel command line: > > mtdparts=spi0.0:256k@0(loader),256k(system),-(user) > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Laurent Pinchart > Cc: Simon Horman > Cc: Wolfram Sang > Cc: linux-renesas-soc@vger.kernel.org Acked-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH 7/9] ARM: dts: gose: Drop MTD partitioning from DT
On Tue, May 22, 2018 at 02:02:55PM +0200, Marek Vasut wrote: > Drop the MTD partitioning from DT, since it does not describe HW > and to give way to a more flexible kernel command line partition > passing. > > To retain the original partitioning, assure you have enabled > CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the > following to your kernel command line: > > mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash) > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Laurent Pinchart > Cc: Simon Horman > Cc: Wolfram Sang > Cc: linux-renesas-soc@vger.kernel.org Acked-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH 9/9] ARM: dts: silk: Drop MTD partitioning from DT
On Tue, May 22, 2018 at 02:02:57PM +0200, Marek Vasut wrote: > Drop the MTD partitioning from DT, since it does not describe HW > and to give way to a more flexible kernel command line partition > passing. > > To retain the original partitioning, assure you have enabled > CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the > following to your kernel command line: > > mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash) > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Laurent Pinchart > Cc: Simon Horman > Cc: Wolfram Sang > Cc: linux-renesas-soc@vger.kernel.org Acked-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH 6/9] ARM: dts: wheat: Drop MTD partitioning from DT
On Tue, May 22, 2018 at 02:02:54PM +0200, Marek Vasut wrote: > Drop the MTD partitioning from DT, since it does not describe HW > and to give way to a more flexible kernel command line partition > passing. > > To retain the original partitioning, assure you have enabled > CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the > following to your kernel command line: > > mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash) > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Laurent Pinchart > Cc: Simon Horman > Cc: Wolfram Sang > Cc: linux-renesas-soc@vger.kernel.org Acked-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH] arm64: dts: renesas: r8a77995: Add IPMMU power domains
On Mon, May 21, 2018 at 11:04:14PM +0900, Magnus Damm wrote: > From: Magnus Damm > > Add power domain information to the R-Car D3 IPMMU device nodes. > As specified by the data sheet, all the IPMMU devices are always on. > > Signed-off-by: Magnus Damm Thanks Magnus, applied.
Re: [PATCH] iommu/ipmmu-vmsa: Document R-Car V3H and E3 IPMMU DT bindings
On Mon, May 21, 2018 at 11:41:33PM +0900, Magnus Damm wrote: > From: Magnus Damm > > Update the IPMMU DT binding documentation to include the compat strings > for the IPMMU devices included in the R-Car V3H and E3 SoCs. > > Signed-off-by: Magnus Damm Reviewed-by: Simon Horman > --- > > Developed on top of renesas-drivers-2018-05-15-v4.17-rc5 > > Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |2 ++ > 1 file changed, 2 insertions(+) > > --- 0001/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > +++ work/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > 2018-05-21 23:37:16.370607110 +0900 > @@ -20,6 +20,8 @@ Required Properties: > - "renesas,ipmmu-r8a7795" for the R8A7795 (R-Car H3) IPMMU. > - "renesas,ipmmu-r8a7796" for the R8A7796 (R-Car M3-W) IPMMU. > - "renesas,ipmmu-r8a77970" for the R8A77970 (R-Car V3M) IPMMU. > +- "renesas,ipmmu-r8a77980" for the R8A77980 (R-Car V3H) IPMMU. > +- "renesas,ipmmu-r8a77990" for the R8A77990 (R-Car E3) IPMMU. > - "renesas,ipmmu-r8a77995" for the R8A77995 (R-Car D3) IPMMU. > - "renesas,ipmmu-vmsa" for generic R-Car Gen2 or RZ/G1 VMSA-compatible > IPMMU. >
Re: [PATCH] PCI: rcar: Poll more often in rcar_pcie_wait_for_dl()
On 05/22/2018 12:33 PM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Tue, May 22, 2018 at 11:48 AM, Marek Vasut wrote:
>> On 05/22/2018 11:42 AM, Geert Uytterhoeven wrote:
>>> On Mon, May 21, 2018 at 11:05 PM, Marek Vasut wrote:
The data link active signal usually takes ~20 uSec to be asserted,
poll the bit more often to avoid useless delays in this function.
Use udelay() instead of usleep() for such a small delay as suggested
by the timer documentation and because this will be used in atomic
context later on when the suspend/resume patches land.
Signed-off-by: Marek Vasut
>>>
>>> Thanks for your patch!
>>>
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -529,13 +529,13 @@ static void phy_write_reg(struct rcar_pcie *pcie,
static int rcar_pcie_wait_for_dl(struct rcar_pcie *pcie)
{
- unsigned int timeout = 10;
+ unsigned int timeout = 1;
while (timeout--) {
if ((rcar_pci_read_reg(pcie, PCIETSTR) & DATA_LINK_ACTIVE))
return 0;
- msleep(5);
+ udelay(5);
>>>
>>> + cpu_relax()?
>>
>> Is it safe to use in atomic context ? Because of that suspend/resume thing.
>
> Yes.
OK, added.
}
>>>
>>> if this ever happens, it will have blocked for more than 50 ms...
>>
>> Well yes, so did the previous thing.
>
> No, the previous thing slept. Big difference.
True
--
Best regards,
Marek Vasut
Re: [PATCH 01/03] arm64: dts: renesas: r8a77965: Add IPMMU devices nodes
On Mon, May 21, 2018 at 11:44:53PM +0900, Magnus Damm wrote: > From: Magnus Damm > > Add IPMMU device nodes for the R-Car M3-N SoC aka r8a77965. > > The r8a77965 IPMMU is quite similar to r8a7796 however VP0 > has been added and PV1 has been removed. Also the IMSSTR > bit assignment has been reworked. > > Signed-off-by: Magnus Damm > --- > > Developed on top of renesas-devel-20180518-v4.17-rc5 > > The DT binding for the M3-N IPMMU has earlier been documented in: > [PATCH] iommu/ipmmu-vmsa: Document R-Car M3-N IPMMU DT bindings This looks fine but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH 02/03] arm64: dts: renesas: r8a77980: Add IPMMU devices nodes
On Mon, May 21, 2018 at 11:45:01PM +0900, Magnus Damm wrote:
> From: Magnus Damm
>
> Add IPMMU device nodes for the R-Car V3H SoC aka r8a77980.
>
> The r8a77980 IPMMU is quite similar to r8a77970 however VC0
> has been added. The IMSSTR bit assignment has also been
> reworked. Power domains are also quite different however the
> the documentation is rather unclear about this topic.
>
> Until we know better VC0 gets assigned to R8A77980_PD_ALWAYS_ON.
>
> Signed-off-by: Magnus Damm
> ---
>
> Developed on top of renesas-devel-20180518-v4.17-rc5
>
> arch/arm64/boot/dts/renesas/r8a77980.dtsi | 49
> +
> 1 file changed, 49 insertions(+)
>
> --- 0001/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> +++ work/arch/arm64/boot/dts/renesas/r8a77980.dtsi2018-05-21
> 22:31:52.460607110 +0900
> @@ -387,6 +387,55 @@
> dma-channels = <16>;
> };
>
> + ipmmu_ds1: mmu@e774 {
> + compatible = "renesas,ipmmu-r8a77980";
> + reg = <0 0xe774 0 0x1000>;
> + renesas,ipmmu-main = <&ipmmu_mm 0>;
> + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
> + #iommu-cells = <1>;
> + };
> +
> + ipmmu_ir: mmu@ff8b {
> + compatible = "renesas,ipmmu-r8a77980";
> + reg = <0 0xff8b 0 0x1000>;
> + renesas,ipmmu-main = <&ipmmu_mm 3>;
> + power-domains = <&sysc R8A77980_PD_A3IR>;
> + #iommu-cells = <1>;
> + };
> +
> + ipmmu_mm: mmu@e67b {
> + compatible = "renesas,ipmmu-r8a77980";
> + reg = <0 0xe67b 0 0x1000>;
> + interrupts = ,
> + ;
> + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
> + #iommu-cells = <1>;
> + };
> +
> + ipmmu_rt: mmu@ffc8 {
> + compatible = "renesas,ipmmu-r8a77980";
> + reg = <0 0xffc8 0 0x1000>;
> + renesas,ipmmu-main = <&ipmmu_mm 10>;
> + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
> + #iommu-cells = <1>;
> + };
> +
> + ipmmu_vc0: mmu@fe6b {
> + compatible = "renesas,ipmmu-r8a77980";
> + reg = <0 0xfe6b 0 0x1000>;
> + renesas,ipmmu-main = <&ipmmu_mm 12>;
> + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
> + #iommu-cells = <1>;
> + };
> +
> + ipmmu_vi0: mmu@febd {
> + compatible = "renesas,ipmmu-r8a77980";
> + reg = <0 0xfebd 0 0x1000>;
> + renesas,ipmmu-main = <&ipmmu_mm 14>;
> + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
> + #iommu-cells = <1>;
> + };
> +
nit: I believe the IPMMU nodes should go above the AVB rather than the
MMC node to preserve the current node sorting order of:
1) bus address
2) IP block
3) alphabetical
> mmc0: mmc@ee14 {
> compatible = "renesas,sdhi-r8a77980",
>"renesas,rcar-gen3-sdhi";
>
Re: [PATCH 03/03] arm64: dts: renesas: r8a77990: Add IPMMU devices nodes
On Mon, May 21, 2018 at 11:45:10PM +0900, Magnus Damm wrote: > From: Magnus Damm > > Add IPMMU device nodes for the R-Car E3 SoC aka r8a77990. > > The r8a77990 IPMMU is similar to r8a77995. Power domains are > however different but the documentation seems unclear. > > As expected VC0 belongs to R8A77990_PD_A3VC however VP0 > is for now assigned to R8A77990_PD_ALWAYS_ON even though > the IPMMU data sheet lists it as part of A3VP. > > What I can tell A3VP is not implemented on E3 so the data > sheet probably needs an update. > > Signed-off-by: Magnus Damm > --- > > Developed on top of renesas-devel-20180518-v4.17-rc5 > > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 82 > + > 1 file changed, 82 insertions(+) This looks fine but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH V3] PCI: rcar: Poll more often in rcar_pcie_wait_for_dl()
On Tue, May 22, 2018 at 02:24:20PM +0200, Marek Vasut wrote: > The data link active signal usually takes ~20 uSec to be asserted, > poll the bit more often to avoid useless delays in this function. > Use udelay() instead of usleep() for such a small delay as suggested > by the timer documentation and because this will be used in atomic > context later on when the suspend/resume patches land. > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Phil Edworthy > Cc: Simon Horman > Cc: Wolfram Sang > Cc: linux-renesas-soc@vger.kernel.org Reviewed-by: Simon Horman
Re: [PATCH] arm64: dts: renesas: r8a77995: don't use deprecated renesas,gpio-rcar
On Mon, May 14, 2018 at 04:35:43PM +0200, Simon Horman wrote: > The compat string renesas,gpio-rcar has been deprecated since v4.14, > the same release that r8a77990 SoC support was added. Thus > renesas,gpio-rcar can safely be removed without any risk of behaviour > changes between old and new mainline kernels and DTBs. > > Signed-off-by: Simon Horman Applied
Re: [PATCH v4 2/3] arm64: dts: renesas: draak: Describe CVBS input
On Mon, May 21, 2018 at 05:50:50PM +0300, Laurent Pinchart wrote: > Hi Jacopo, > > Thank you for the patch. > > On Monday, 21 May 2018 17:45:41 EEST Jacopo Mondi wrote: > > Describe CVBS video input through analog video decoder ADV7180 > > connected to video input interface VIN4. > > > > The video input signal path is shared with HDMI video input, and > > selected by on-board switches SW-53 and SW-54 with CVBS input selected > > by the default switches configuration. > > > > Signed-off-by: Jacopo Mondi > > Reviewed-by: Niklas Söderlund > > Reviewed-by: Laurent Pinchart Thanks Niklas, applied.
Re: [PATCH v4 3/3] arm64: dts: renesas: draak: Describe HDMI input
On Mon, May 21, 2018 at 04:45:42PM +0200, Jacopo Mondi wrote: > Describe HDMI input connector and ADV7612 HDMI decoder installed on > R-Car Gen3 Draak board. > > The video signal routing to the HDMI decoder to the video input interface > VIN4 is multiplexed with CVBS input path, and enabled/disabled through > on-board switches SW-49, SW-50, SW-51 and SW-52. > > As the default board switches configuration connects CVBS input to VIN4, > leave the HDMI decoder unconnected in DTS. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Niklas Söderlund > Reviewed-by: Laurent Pinchart Thanks Jacopo, applied.
Re: [PATCH v4 2/3] arm64: dts: renesas: draak: Describe CVBS input
On Tue, May 22, 2018 at 03:24:13PM +0200, Simon Horman wrote: > On Mon, May 21, 2018 at 05:50:50PM +0300, Laurent Pinchart wrote: > > Hi Jacopo, > > > > Thank you for the patch. > > > > On Monday, 21 May 2018 17:45:41 EEST Jacopo Mondi wrote: > > > Describe CVBS video input through analog video decoder ADV7180 > > > connected to video input interface VIN4. > > > > > > The video input signal path is shared with HDMI video input, and > > > selected by on-board switches SW-53 and SW-54 with CVBS input selected > > > by the default switches configuration. > > > > > > Signed-off-by: Jacopo Mondi > > > Reviewed-by: Niklas Söderlund > > > > Reviewed-by: Laurent Pinchart > > Thanks Niklas, applied. Sorry, I meant thanks Jacopo, Niklas and Laurent!
[PATCH/RFC] ARM: dts: r8a7791: Move enable-method to CPU nodes
According to Documentation/devicetree/bindings/arm/cpus.txt, the
"enable-method" property should be a property of the individual CPU
nodes, not of the parent "cpus" node. However, on R-Car M2-W (and on
several other arm32 SoCs), the property is tied to the "cpus" node
instead.
Secondary CPU bringup and CPU hot (un)plug work regardless, as
arm_dt_init_cpu_maps() falls back to looking in the "cpus" node.
The cpuidle code does not have such a fallback, so it does not detect
the enable-method. Note that cpuidle does not support the
"renesas,apmu" enable-method yet, so for now this does not make any
difference.
Signed-off-by: Geert Uytterhoeven
---
Arm64 and powerpc do not have such a fallback, but SH has, like arm32.
This is marked RFC, as the alternative is to update the DT bindings to
keep the status quo.
---
arch/arm/boot/dts/r8a7791.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index d568bd22d6cbd855..b214cb8f52e47109 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -71,7 +71,6 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
- enable-method = "renesas,apmu";
cpu0: cpu@0 {
device_type = "cpu";
@@ -83,6 +82,7 @@
clock-latency = <30>; /* 300 us */
power-domains = <&sysc R8A7791_PD_CA15_CPU0>;
next-level-cache = <&L2_CA15>;
+ enable-method = "renesas,apmu";
/* kHz - uV - OPPs unknown yet */
operating-points = <150 100>,
@@ -101,6 +101,7 @@
clocks = <&cpg CPG_CORE R8A7791_CLK_Z>;
power-domains = <&sysc R8A7791_PD_CA15_CPU1>;
next-level-cache = <&L2_CA15>;
+ enable-method = "renesas,apmu";
};
L2_CA15: cache-controller-0 {
--
2.7.4
Re: [PATCH 2/2] spi: sh-msiof: Document R-Car D3 support
On Wed, May 16, 2018 at 3:05 PM, Ulrich Hecht
wrote:
> Document support for the MSIOF module in the Renesas D3 (r8a77995) SoC.
>
> No driver update is needed.
>
> Signed-off-by: Ulrich Hecht
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/9] ARM: shmobile: defconfig: Enable MTD command line partition parsing
On Tue, May 22, 2018 at 2:02 PM, Marek Vasut wrote:
> In preparation for removing MTD partitioning from the DTs and moving
> it over to kernel command line partition parsing, enable the support
> for kernel command line MTD partition parsing.
>
> The argument for not having MTD partitions in the DT is the same as
> for not having hard drive partitions in DT, neither describes the
> hardware itself, so it shouldn't be in the DT. Furthermore, kernel
> command line MTD partition passing allows greater flexibility in
> case someone decided to repartition the flash, which is well in the
> realm of possibility with these systems.
>
> Signed-off-by: Marek Vasut
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 4/9] ARM: dts: koelsch: Drop MTD partitioning from DT
On Tue, May 22, 2018 at 2:02 PM, Marek Vasut wrote:
> Drop the MTD partitioning from DT, since it does not describe HW
> and to give way to a more flexible kernel command line partition
> passing.
>
> To retain the original partitioning, assure you have enabled
> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> following to your kernel command line:
>
> mtdparts=spi0.0:512k@0(loader),5632k(user),-(flash)
>
> Signed-off-by: Marek Vasut
Reviewed-by: Geert Uytterhoeven
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v4 2/4] mmc: core: more fine-grained hooks for HS400 tuning
On 18 April 2018 at 11:56, Simon Horman wrote:
> This adds two new HS400 tuning operations:
> * prepare_hs400_tuning_downgrade
> * complete_hs400_tuning
>
> These supplement the existing HS400 operation:
> * prepare_hs400_tuning
>
> This is motivated by a requirement of Renesas SDHI for the following:
> 1. Disabling SCC before selecting to HS if selection of HS400 has occurred.
>This can be done in an implementation of prepare_hs400_tuning_downgrade
> 2. Updating registers after switching to HS400
>This can be done in an implementation of complete_hs400_tuning
>
> After this patch the call sequence is as follows:
>
> * Initial tuning
> i. prepare_hs400_tuning
> 2. Tuning procedure
> 3. Select HS400
> 4. complete_hs400_tuning
>
> * Retune
> 1. prepare_hs400_tuning_downgrade
> 2. Select HS200
> 3. prepare_hs400_tuning
> 4. Tuning procedure
> 5. Select HS400
> 6. complete_hs400_tuning
>
> If prepare_hs400_tuning or complete_hs400_tuning are not implemented they
> are not called. And if neither are called the procedure is the same as
> before this patch.
>
> Design consideration: In the case of Renesas SDHI it is likely that
> prepare_hs400_tuning_downgrade and prepare_hs400_tuning could be combined
> if the latter was called before selecting HS200 during tuning. When I say
> likely, I believe it matches my understanding of the hardware. However, I
> did not test this as I am entirely unsure if moving the
> prepare_hs400_tuning call would work for other hardware that uses this
> operation and I am in no position to test such hardware.
>
> Signed-off-by: Simon Horman
> ---
> v4
> * New patch
> ---
> drivers/mmc/core/host.c | 13 -
> drivers/mmc/core/mmc.c | 19 ++-
> include/linux/mmc/host.h | 26 +-
> 3 files changed, 51 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index 64b03d6eaf18..5e60df7ca11f 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -138,6 +138,10 @@ int mmc_retune(struct mmc_host *host)
> host->doing_retune = 1;
>
> if (host->ios.timing == MMC_TIMING_MMC_HS400) {
> + if (host->ops->prepare_hs400_tuning_downgrade)
> + host->ops->prepare_hs400_tuning_downgrade(host,
> + &host->ios);
> +
Quite a long lame for the callback, perhaps "hs400_downgrade" is sufficient?
Moreover, I suggest you move this new code snippet into
mmc_hs400_to_hs200() instead.
> err = mmc_hs400_to_hs200(host->card);
> if (err)
> goto out;
> @@ -152,8 +156,15 @@ int mmc_retune(struct mmc_host *host)
> if (err)
> goto out;
>
> - if (return_to_hs400)
> + if (return_to_hs400) {
> err = mmc_hs200_to_hs400(host->card);
> + if (err)
> + goto out;
> +
> + if (host->ops->complete_hs400_tuning)
> + host->ops->complete_hs400_tuning(host, &host->ios);
Perhaps rename callback to "hs400_complete"?
And, please move this new code into mmc_select_hs400() (which is
called from mmc_hs200_to_hs400()), as I think it better belongs there.
> + }
> +
> out:
> host->doing_retune = 0;
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 099b327e10ca..a108a1a3e27f 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -1508,22 +1508,31 @@ static int mmc_select_timing(struct mmc_card *card)
> static int mmc_hs200_tuning(struct mmc_card *card)
> {
> struct mmc_host *host = card->host;
> + bool run_hs400_ops;
> int err;
>
> + run_hs400_ops = card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400 &&
> + host->ios.bus_width == MMC_BUS_WIDTH_8;
> +
> /*
> * Timing should be adjusted to the HS400 target
> * operation frequency for tuning process
> */
> - if (card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400 &&
> - host->ios.bus_width == MMC_BUS_WIDTH_8)
> - if (host->ops->prepare_hs400_tuning)
> - host->ops->prepare_hs400_tuning(host, &host->ios);
> + if (run_hs400_ops && host->ops->prepare_hs400_tuning)
> + host->ops->prepare_hs400_tuning(host, &host->ios);
>
> err = mmc_execute_tuning(card);
> if (err)
> return err;
>
> - return mmc_select_hs400(card);
> + err = mmc_select_hs400(card);
> + if (err)
> + return err;
> +
> + if (run_hs400_ops && host->ops->complete_hs400_tuning)
> + host->ops->complete_hs400_tuning(host, &host->ios);
> +
I would suggest you to drop patch 1, then re-base $subject patch on
top of the patch I just sent ("mmc: core: Move calls to
->prepare_hs400_tuning() closer to mmc code").
In this way, we get les
Re: [PATCH 2/9] ARM: dts: lager: Drop MTD partitioning from DT
On Tue, May 22, 2018 at 2:02 PM, Marek Vasut wrote:
> Drop the MTD partitioning from DT, since it does not describe HW
> and to give way to a more flexible kernel command line partition
> passing.
>
> To retain the original partitioning, assure you have enabled
> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> following to your kernel command line:
>
> mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
I guess s/4096k/4m/ works, too?
> Signed-off-by: Marek Vasut
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 3/9] ARM: dts: stout: Drop MTD partitioning from DT
On Tue, May 22, 2018 at 2:02 PM, Marek Vasut wrote:
> Drop the MTD partitioning from DT, since it does not describe HW
> and to give way to a more flexible kernel command line partition
> passing.
>
> To retain the original partitioning, assure you have enabled
> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> following to your kernel command line:
>
> mtdparts=spi0.0:512k@0(loader),256k(uboot),256k(uboot-env),-(flash)
>
> Signed-off-by: Marek Vasut
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 5/9] ARM: dts: porter: Drop MTD partitioning from DT
On Tue, May 22, 2018 at 2:02 PM, Marek Vasut wrote:
> Drop the MTD partitioning from DT, since it does not describe HW
> and to give way to a more flexible kernel command line partition
> passing.
>
> To retain the original partitioning, assure you have enabled
> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> following to your kernel command line:
>
> mtdparts=spi0.0:256k@0(loader_prg),4096k(user_prg),-(flash_fs)
4m?
> Signed-off-by: Marek Vasut
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 6/9] ARM: dts: wheat: Drop MTD partitioning from DT
On Tue, May 22, 2018 at 2:02 PM, Marek Vasut wrote:
> Drop the MTD partitioning from DT, since it does not describe HW
> and to give way to a more flexible kernel command line partition
> passing.
>
> To retain the original partitioning, assure you have enabled
> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> following to your kernel command line:
>
> mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
I think the "@0" can be dropped, as it's optional?
4m?
(Gaining more knowledge during reviewing ;-)
> Signed-off-by: Marek Vasut
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 7/9] ARM: dts: gose: Drop MTD partitioning from DT
On Tue, May 22, 2018 at 2:02 PM, Marek Vasut wrote:
> Drop the MTD partitioning from DT, since it does not describe HW
> and to give way to a more flexible kernel command line partition
> passing.
>
> To retain the original partitioning, assure you have enabled
> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> following to your kernel command line:
>
> mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
Drop @0? 4m?
> Signed-off-by: Marek Vasut
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 8/9] ARM: dts: alt: Drop MTD partitioning from DT
On Tue, May 22, 2018 at 2:02 PM, Marek Vasut wrote:
> Drop the MTD partitioning from DT, since it does not describe HW
> and to give way to a more flexible kernel command line partition
> passing.
>
> To retain the original partitioning, assure you have enabled
> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> following to your kernel command line:
>
> mtdparts=spi0.0:256k@0(loader),256k(system),-(user)
Drop @0?
> Signed-off-by: Marek Vasut
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 9/9] ARM: dts: silk: Drop MTD partitioning from DT
On Tue, May 22, 2018 at 2:02 PM, Marek Vasut wrote:
> Drop the MTD partitioning from DT, since it does not describe HW
> and to give way to a more flexible kernel command line partition
> passing.
>
> To retain the original partitioning, assure you have enabled
> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> following to your kernel command line:
>
> mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
Drop @0?
4m?
> Signed-off-by: Marek Vasut
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/4] PCI: rcar: Pull bus clock enable/disable from rcar_pcie_get_resources()
Hi Marek,
On Mon, May 21, 2018 at 3:11 PM, Marek Vasut wrote:
> The rcar_pcie_get_resources() is another misnomer with a side effect.
> The function does not only get resources, but also enables/disables bus
> clock. This is forgotten in the probe() function though and if anything
> in probe() fails after rcar_pcie_get_resources() is called, the bus
> clock are never disabled.
>
> This patch pulls the clock handling out of the rcar_pcie_get_resources()
> and enables clock after all the resources were requested. Moreover, this
> patch also always disables the clock in case of failure.
>
> Signed-off-by: Marek Vasut
Thanks for your patch!
Reported-by: Geert Uytterhoeven
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 3/4] PCI: rcar: Add missing irq_dispose_mapping() into failpath
Hi Marek,
On Mon, May 21, 2018 at 3:11 PM, Marek Vasut wrote:
> The rcar_pcie_get_resources() is another misnomer with a side effect.
> The function does not only get resources, but also maps MSI IRQs via
> irq_of_parse_and_map(). In case anything fails afterward, the IRQ
> mapping must be disposed through irq_dispose_mapping() which is not
> done.
>
> This patch handles irq_of_parse_and_map() failures in by disposing
> of the mapping in rcar_pcie_get_resources() as well as in probe.
>
> Signed-off-by: Marek Vasut
Reviewed-by: Geert Uytterhoeven
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -923,18 +923,25 @@ static int rcar_pcie_get_resources(struct rcar_pcie
> *pcie)
> i = irq_of_parse_and_map(dev->of_node, 0);
> if (!i) {
> dev_err(dev, "cannot get platform resources for msi
> interrupt\n");
> - return -ENOENT;
> + err = -ENOENT;
> + goto err_irq1;
You could have kept the return here.
> }
> pcie->msi.irq1 = i;
>
> i = irq_of_parse_and_map(dev->of_node, 1);
> if (!i) {
> dev_err(dev, "cannot get platform resources for msi
> interrupt\n");
> - return -ENOENT;
> + err = -ENOENT;
> + goto err_irq2;
> }
> pcie->msi.irq2 = i;
>
> return 0;
> +
> +err_irq2:
> + irq_dispose_mapping(pcie->msi.irq1);
> +err_irq1:
> + return err;
> }
>
> static int rcar_pcie_inbound_ranges(struct rcar_pcie *pcie,
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 1/4] dt-bindings: media: rcar-vin: Describe optional ep properties
Hi Jacopo,
Thanks for your patch.
On 2018-05-21 19:27:40 +0200, Jacopo Mondi wrote:
> Describe the optional properties for endpoint nodes of port@0
> and port@1 of the R-Car VIN driver device tree bindings documentation.
>
> Signed-off-by: Jacopo Mondi
> Acked-by: Niklas Söderlund
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index 5c6f2a7..dab3118 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -54,6 +54,16 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
>from external SoC pins described in video-interfaces.txt[1].
>Describing more then one endpoint in port 0 is invalid. Only VIN
>instances that are connected to external pins should have port 0.
> +
> + - Optional properties for endpoint nodes of port@0:
> +- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH
> + respectively. Default is active high.
> +- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH
> + respectively. Default is active high.
> +
> + If both HSYNC and VSYNC polarities are not specified, embedded
> + synchronization is selected.
> +
> - port 1 - sub-nodes describing one or more endpoints connected to
>the VIN from local SoC CSI-2 receivers. The endpoint numbers must
>use the following schema.
> @@ -63,6 +73,8 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
> - Endpoint 2 - sub-node describing the endpoint connected to CSI40
> - Endpoint 3 - sub-node describing the endpoint connected to CSI41
>
> + Endpoint nodes of port@1 do not support any optional endpoint property.
> +
> Device node example for Gen2 platforms
> --
>
> @@ -113,7 +125,6 @@ Board setup example for Gen2 platforms (vin1 composite
> video input)
>
> vin1ep0: endpoint {
> remote-endpoint = <&adv7180>;
> -bus-width = <8>;
Until we have figured out if we should document or remove the bus-width
parameter maybe move this to 4/4 ?
> };
> };
> };
> --
> 2.7.4
>
--
Regards,
Niklas Söderlund
Re: [PATCH v2 2/4] dt-bindings: media: rcar-vin: Document data-active
Hi Jacopo, Thanks for your patch. On 2018-05-21 19:27:41 +0200, Jacopo Mondi wrote: > Document 'data-active' property in R-Car VIN device tree bindings. > > Signed-off-by: Jacopo Mondi > > v1 -> v2: > - HSYNC is used in place of data enable signal only when running with > explicit synchronizations. > - The property is no more mandatory when running with embedded > synchronizations, and default is selected. > --- > Documentation/devicetree/bindings/media/rcar_vin.txt | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt > b/Documentation/devicetree/bindings/media/rcar_vin.txt > index dab3118..2c144b4 100644 > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt > @@ -64,6 +64,12 @@ from local SoC CSI-2 receivers (port1) depending on SoC. > If both HSYNC and VSYNC polarities are not specified, embedded > synchronization is selected. > > +- data-active: data enable signal line polarity (CLKENB pin). > + 0/1 for LOW/HIGH respectively. If not specified and running with > + embedded synchronization, the default is active high. If not > + specified and running with explicit synchronization, HSYNC is used > + as data enable signal. This indentation looks funny :-) If you check the rest of the rcar_vin.txt file only spaces are used for indentation. > + > - port 1 - sub-nodes describing one or more endpoints connected to >the VIN from local SoC CSI-2 receivers. The endpoint numbers must >use the following schema. > -- > 2.7.4 > -- Regards, Niklas Söderlund
Re: [PATCH v2 3/4] media: rcar-vin: Handle CLOCKENB pin polarity
Hi Jacopo,
Thanks for your patch.
On 2018-05-21 19:27:42 +0200, Jacopo Mondi wrote:
> Handle CLOCKENB pin polarity, or use HSYNC in its place if polarity is
> not specified and we're running on parallel data bus with explicit
> synchronism signals.
>
> While at there, simplify the media bus handling flags logic, inspecting
> flags only if the system is running on parallel media bus type and ignore
> flags when on CSI-2. Also change comments style to remove un-necessary
> camel case and add a full stop at the end of sentences.
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/platform/rcar-vin/rcar-dma.c | 34
> ++
> 1 file changed, 25 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index 17f291f..ffd3d62 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -123,6 +123,8 @@
> /* Video n Data Mode Register 2 bits */
> #define VNDMR2_VPS (1 << 30)
> #define VNDMR2_HPS (1 << 29)
> +#define VNDMR2_CES (1 << 28)
> +#define VNDMR2_CHS (1 << 23)
> #define VNDMR2_FTEV (1 << 17)
> #define VNDMR2_VLV(n)((n & 0xf) << 12)
>
> @@ -684,21 +686,35 @@ static int rvin_setup(struct rvin_dev *vin)
> break;
> }
>
> - /* Enable VSYNC Field Toogle mode after one VSYNC input */
> + /* Enable VSYNC field toggle mode after one VSYNC input. */
> if (vin->info->model == RCAR_GEN3)
> dmr2 = VNDMR2_FTEV;
> else
> dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
>
> - /* Hsync Signal Polarity Select */
> - if (!vin->is_csi &&
> - !(vin->parallel->mbus_flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
> - dmr2 |= VNDMR2_HPS;
> + /* Synchronism signal polarities: only for parallel data bus. */
> + if (!vin->is_csi) {
> + /* Hsync signal polarity select. */
> + if (!(vin->parallel->mbus_flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
> + dmr2 |= VNDMR2_HPS;
>
> - /* Vsync Signal Polarity Select */
> - if (!vin->is_csi &&
> - !(vin->parallel->mbus_flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
> - dmr2 |= VNDMR2_VPS;
> + /* Vsync signal polarity select. */
> + if (!(vin->parallel->mbus_flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
> + dmr2 |= VNDMR2_VPS;
> +
> + /*
> + * Data enable signal polarity select.
> + * Use HSYNC as data-enable if not specified and running
> + * with explicit synchronizations; otherwise default 'high'
> + * is selected.
> + */
> + if (vin->parallel->mbus_flags & V4L2_MBUS_DATA_ACTIVE_LOW)
> + dmr2 |= VNDMR2_CES;
> + else if (!(vin->parallel->mbus_flags &
> + V4L2_MBUS_DATA_ACTIVE_HIGH) &&
> + vin->parallel->mbus_type == V4L2_MBUS_PARALLEL)
> + dmr2 |= VNDMR2_CHS;
As I stated in v1, I think this expression is more complex then is relly
needed here. Would not something like this be much more readable?
/* Clock Enable signal polarity select. */
if (vin->parallel->mbus_flags & V4L2_MBUS_DATA_ACTIVE_LOW)
dmr2 |= VNDMR2_CES;
/* Use HSYNC as clock enable if VIn_CLKENB is not available. */
if (!(vin->parallel->mbus_flags & (V4L2_MBUS_DATA_ACTIVE_LOW |
V4L2_MBUS_DATA_ACTIVE_HIGH)))
dmr2 |= VNDMR2_CHS;
> + }
>
> /*
>* Output format
> --
> 2.7.4
>
--
Regards,
Niklas Söderlund
Re: [PATCH 1/2] arm64: dts: renesas: r8a77980: add GEther support
On 05/22/2018 02:48 PM, Geert Uytterhoeven wrote:
>> Define the generic R8A77980 part of the GEther device node.
>>
>> Based on the original (and large) patch by Vladimir Barinov.
>>
>> Signed-off-by: Vladimir Barinov
>> Signed-off-by: Sergei Shtylyov
>
> Thanks for your patch!
>
> With the below addressed:
> Reviewed-by: Geert Uytterhoeven
Thanks!
>> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
>> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
>> @@ -417,6 +417,17 @@
>> dma-channels = <16>;
>> };
>>
>> + gether: ethernet@e740 {
>> + compatible = "renesas,gether-r8a77980";
>> + reg = <0 0xe740 0 0x1000>;
>> + interrupts = ;
>> + clocks = <&cpg CPG_MOD 813>;
>> + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
>
> resets = <&cpg 813>;
As usual...
>
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + status = "disabled";
>
> Any default phy-mode needed?
A default "phy-mode" IMO make sense when the MAC supports a single
PHY interface mode. In this case, both RMII and RGMII are supported, so
I coulsn't choose a default...
>> + };
>> +
>> mmc0: mmc@ee14 {
>> compatible = "renesas,sdhi-r8a77980",
>> "renesas,rcar-gen3-sdhi";
>
>
> Gr{oetje,eeting}s,
>
> Geert
>
Re: [PATCH v6 2/6] dt-bindings: Add the rzn1-clocks.h file
On Tue, May 22, 2018 at 11:01:22AM +0100, Michel Pollet wrote: > This adds the constants necessary to use the renesas,rzn1-clocks driver. > > Signed-off-by: Michel Pollet > --- > include/dt-bindings/clock/rzn1-clocks.h | 187 > > 1 file changed, 187 insertions(+) > create mode 100644 include/dt-bindings/clock/rzn1-clocks.h Reviewed-by: Rob Herring
Re: [PATCH v6 3/6] dt-bindings: clock: renesas,rzn1-clocks: document RZ/N1 clock driver
On Tue, May 22, 2018 at 11:01:23AM +0100, Michel Pollet wrote:
> The Renesas RZ/N1 Family (Part #R9A06G0xx) requires a driver
> to provide the SoC clock infrastructure for Linux.
>
> This documents the driver bindings.
>
> Signed-off-by: Michel Pollet
> ---
> .../bindings/clock/renesas,rzn1-clocks.txt | 44
> ++
> 1 file changed, 44 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
> b/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
> new file mode 100644
> index 000..0c41137
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
> @@ -0,0 +1,44 @@
> +* Renesas RZ/N1 Clock Driver
> +
> +This driver provides the clock infrastructure used by all the other drivers.
Bindings document h/w not drivers.
> +
> +One of the 'special' feature of this infrastructure is that Linux doesn't
Bindings are not just for Linux.
> +necessary 'own' all the clocks on the SoC, some other OS runs on
> +the Cortex-M3 core and that OS can access and claim it's own clocks.
How is this relevant to the binding?
> +
> +Required Properties:
> +
> + - compatible: Must be
> +- "renesas,r9a06g032-clocks" for the RZ/N1D
> +and "renesas,rzn1-clocks" as a fallback.
Is "clocks" how the chip reference manual refers to this block?
> + - reg: Base address and length of the memory resource used by the driver
> + - #clock-cells: Must be 1
> +
> +Examples
> +
> +
> + - Clock driver device node:
> +
> + clock: clocks@4000c000 {
clock-controller@...
> + compatible = "renesas,r9a06g032-clocks",
> + "renesas,rzn1-clocks";
> + reg = <0x4000c000 0x1000>;
> + status = "okay";
Don't show status in examples. (Plus, I doubt you ever want to have this
disabled, so you don't need the property in your dts files either).
> + #clock-cells = <1>;
> + };
> +
> +
> + - Other drivers can use the clocks as in:
s/drivers/nodes/
> +
> + uart0: serial@4006 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x4006 0x400>;
> + interrupts = ;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&clock RZN1_CLK_UART0>;
> + clock-names = "baudclk";
> + };
> +Note the use of RZN1_CLK_UART0 -- these constants are declared in
> +the rzn1-clocks.h header file. These are not hardware based constants
> +and are Linux specific.
No, they are not Linux specific. They are part of the DT ABI.
While it is not a requirement to base them on some h/w numbering, it is
preferred if you can. That usually only works if you can base them on
bit positions or register offsets.
Rob
Re: [PATCH v4 2/3] dt-bindings: thermal: rcar-thermal: add R8A77995 support
On Sun, May 20, 2018 at 06:26:18PM +0900, Yoshihiro Kaneko wrote: > Signed-off-by: Yoshihiro Kaneko > Reviewed-by: Geert Uytterhoeven > --- > Documentation/devicetree/bindings/thermal/rcar-thermal.txt | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) Reviewed-by: Rob Herring
Re: [PATCH v4 1/3] dt-bindings: media: rcar-vin: Add R8A77995 support
On Mon, May 21, 2018 at 04:45:40PM +0200, Jacopo Mondi wrote: > Add compatible string for R-Car D3 R8A7795 to list of SoCs supported by > rcar-vin driver. > > Signed-off-by: Jacopo Mondi > Acked-by: Niklas Söderlund > Reviewed-by: Laurent Pinchart > Reviewed-by: Simon Horman > --- > Documentation/devicetree/bindings/media/rcar_vin.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring
Re: [PATCH 0/5] R-Car D3 LVDS/HDMI support
Hi Ulrich, On Sunday, 20 May 2018 11:27:02 EEST Laurent Pinchart wrote: > On Tuesday, 15 May 2018 15:20:35 EEST Ulrich Hecht wrote: > > Hi! > > > > This adds D3 support to the DU and LVDS drivers, not including LVDS PLL > > support. > > > > It also adds LVDS encoders to the D3 device tree, and LVDS decoder, HDMI > > encoder and HDMI output connector to the Draak device tree. > > > > In theory that should be good enough to provide HDMI output on the Draak > > board, but in practice the lack of LVDS PLL support prevents generation of > > close-enough dot clock frequencies. > > > > This series is based on renesas-drivers-2018-05-02-v4.17-rc3 and requires > > Jacopo's "drm: bridge: Add thc63lvd1024 LVDS decoder driver" patch. > > As HDMI output isn't functional yet this is difficult to test. Could you add > support for the VGA output (using the DU DPAD) in v2 of the patch series ? > VGA should work without LVDS PLL support as the clock frequency > requirements are not as strict as for HDMI. *sigh* I should really refrain from writing e-mails when I'm jetlagged :-/ VGA is already supported, there's nothing to be done there. Sorry for the noise. > > Kieran Bingham (1): > > arm64: dts: renesas: r8a77995: Add LVDS support > > > > Koji Matsuoka (1): > > drm: rcar-du: Add r8a77995 device support > > > > Ulrich Hecht (3): > > drm: rcar-du: lvds: Add R8A77995 support > > arm64: dts: renesas: r8a77995-draak: add HDMI output > > arm64: dts: renesas: r8a77995-draak: add X12 input dot clock > > > > arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 91 + > > arch/arm64/boot/dts/renesas/r8a77995.dtsi | 56 > > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 26 > > drivers/gpu/drm/rcar-du/rcar_lvds.c| 6 ++ > > 4 files changed, 179 insertions(+) -- Regards, Laurent Pinchart
Re: [PATCH/RFC v4 2/4] usb: gadget: udc: renesas_usb3: Add register of usb role switch
On Tue, May 22, 2018 at 09:01:07PM +0900, Yoshihiro Shimoda wrote: > This patch adds role switch support for R-Car SoCs into the USB 3.0 > peripheral driver. Some R-Car SoCs (e.g. R-Car H3) have USB 3.0 > dual-role device controller which has the USB 3.0 xHCI host and > Renesas USB 3.0 peripheral. > > Unfortunately, the mode change register contains the USB 3.0 peripheral > controller side only. So, the USB 3.0 peripheral driver (renesas_usb3) > manages this register now. However, in peripheral mode, the host > should stop. Also the host hardware needs to reinitialize its own > registers when the mode changes from peripheral to host mode. > Otherwise, the host cannot work correctly (e.g. detect a device as > high-speed). > > To achieve this by a driver, this role switch driver manages > the mode change register and attach/release the xhci-plat driver. > > Signed-off-by: Yoshihiro Shimoda > --- > .../devicetree/bindings/usb/renesas_usb3.txt | 15 Please split bindings to a separate patch. > drivers/usb/gadget/udc/Kconfig | 1 + > drivers/usb/gadget/udc/renesas_usb3.c | 82 > ++ > 3 files changed, 98 insertions(+) > > diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt > b/Documentation/devicetree/bindings/usb/renesas_usb3.txt > index 2c071bb5..f6105aa 100644 > --- a/Documentation/devicetree/bindings/usb/renesas_usb3.txt > +++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt > @@ -19,6 +19,9 @@ Required properties: > Optional properties: >- phys: phandle + phy specifier pair >- phy-names: must be "usb" > + - The connection to a usb3.0 host node needs by using OF graph bindings for > +usb role switch. > + - port@0 = USB3.0 host port. On the host side, this might conflict with the USB connector binding. I would either make sure this can work with the connector binding by having 2 endpoints on the HS or SS port or just use the 'companion' property defined in usb-generic.txt. Rob
Re: [PATCH 4/4] PCI: rcar: Teardown MSI setup if rcar_pcie_enable() fails
Hi Marek,
On Mon, May 21, 2018 at 3:11 PM, Marek Vasut wrote:
> If the rcar_pcie_enable() fails and MSIs are enabled, the setup done in
> rcar_pcie_enable_msi() is never undone. Add a function to tear down the
> MSI setup by disabling the MSI handling in the PCIe block, deallocating
> the pages requested for the MSIs and zapping the IRQ mapping.
>
> Signed-off-by: Marek Vasut
Reported-by: Geert Uytterhoeven
Reviewed-by: Geert Uytterhoeven
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -900,6 +900,28 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
> return err;
> }
>
> +static void rcar_pcie_teardown_msi(struct rcar_pcie *pcie)
> +{
> + struct rcar_msi *msi = &pcie->msi;
> + int irq, i;
> +
> + /* Disable all MSI interrupts */
> + rcar_pci_write_reg(pcie, 0, PCIEMSIIER);
> +
> + /* Disable address decoding of the MSI interrupt, MSIFE */
> + rcar_pci_write_reg(pcie, 0, PCIEMSIALR);
> +
> + free_pages(msi->pages, 0);
> +
> + for (i = 0; i < INT_PCI_MSI_NR; i++) {
> + irq = irq_find_mapping(msi->domain, i);
> + if (irq > 0)
> + irq_dispose_mapping(irq);
> + }
Note that similar calls to irq_dispose_mapping() should be added to the
failure path of rcar_pcie_enable_msi(), too.
> +
> + irq_domain_remove(msi->domain);
> +}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v6 3/6] dt-bindings: clock: renesas,rzn1-clocks: document RZ/N1 clock driver
Hi Michel,
On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
wrote:
> The Renesas RZ/N1 Family (Part #R9A06G0xx) requires a driver
> to provide the SoC clock infrastructure for Linux.
>
> This documents the driver bindings.
>
> Signed-off-by: Michel Pollet
Thanks for your patch!
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
> @@ -0,0 +1,44 @@
> +* Renesas RZ/N1 Clock Driver
> +
> +This driver provides the clock infrastructure used by all the other drivers.
> +
> +One of the 'special' feature of this infrastructure is that Linux doesn't
> +necessary 'own' all the clocks on the SoC, some other OS runs on
> +the Cortex-M3 core and that OS can access and claim it's own clocks.
> +
> +Required Properties:
> +
> + - compatible: Must be
> +- "renesas,r9a06g032-clocks" for the RZ/N1D
> +and "renesas,rzn1-clocks" as a fallback.
Why the fallback? I doubt all existing (and future) RZ/N1D SoCs provide the
exact same clock hierarchy.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v6 2/6] dt-bindings: Add the rzn1-clocks.h file
Hi Michel,
On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
wrote:
> This adds the constants necessary to use the renesas,rzn1-clocks driver.
>
> Signed-off-by: Michel Pollet
Thanks for your patch!
> ---
> include/dt-bindings/clock/rzn1-clocks.h | 187
>
> 1 file changed, 187 insertions(+)
> create mode 100644 include/dt-bindings/clock/rzn1-clocks.h
>
> diff --git a/include/dt-bindings/clock/rzn1-clocks.h
> b/include/dt-bindings/clock/rzn1-clocks.h
> new file mode 100644
> index 000..8a73db2
> --- /dev/null
> +++ b/include/dt-bindings/clock/rzn1-clocks.h
Given this is part of the DT ABI, and there exist multiple different RZ/N1
SoCs (and there are probably planned more), I wouldn't call this header
file "rzn1-clocks.h", but e.g. "r9a06g032-clocks.h".
> @@ -0,0 +1,187 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * RZ/N1 clock IDs
> + *
> + * Copyright (C) 2018 Renesas Electronics Europe Limited
> + *
> + * Michel Pollet ,
> + * Derived from zx-reboot.c
> + */
> +
> +#ifndef __DT_BINDINGS_RZN1_CLOCK_H__
> +#define __DT_BINDINGS_RZN1_CLOCK_H__
> +
> +#define RZN1_CLKOUT0
Similar for the RZN1 prefix.
I'll look at the actual list of clocks later...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 2/2] i2c: mux: demux-pinctrl: add symlinks to the demux device in sysfs
Hi Peter, > Hmm, now that I have slept on it, I find this a bit odd. For muxes, all > channels and the parent are always present. Here, that is not the case. > And don't get me wrong, I see why that is the case, but that doesn't > mean that I like it. It would be so much nicer and less disruptive if > the client devices were not unbound and rebound (which I think they are, > right?) on every master switch. Yes, we rebind on every master switch. In the first iteration of this driver, I tried the on-the-fly approach. It turned out to be very flaky because it was stretching the driver model too much. There is no support for multiple parents and no support for switching the parent at runtime. When trying to do that, you find out that e.g. the whole relationship tree needs to be rebuilt, say to keep PM hierarchy consistent. And even, just for I2C, on-the-fly switching is not really supported. Some Renesas R-Car SoCs have two different I2C IP cores which can be muxed to the same pins. One has DMA, the other slave functionality. I don't see a way to combine both into one "virtual" master. This is why I came to the current approach. The use case that the customers decide on the feature set they want to use after booting was said to be good enough. > In some cases I think it might be possible to make the switch automatic > and seamless, e.g. if there are two masters and one of them is faster > but has some glitch(es), and the other is slower but complete (or at > least complete enough). That might work for some cases, yet I'd favor a generic solution. > What do you think? Given my above experiences, I'd just drop the channel symlink and keep the driver as is :) But thanks for thinking about it! Wolfram signature.asc Description: PGP signature
Re: [PATCH] media: rcar-vin: Drop unnecessary register properties from example vin port
On Wed, May 09, 2018 at 08:45:58PM +0200, Simon Horman wrote: > The example vin port node does not have an address and thus does not > need address-cells or address size-properties. > > Signed-off-by: Simon Horman > --- > Documentation/devicetree/bindings/media/rcar_vin.txt | 3 --- > 1 file changed, 3 deletions(-) Reviewed-by: Rob Herring
Re: [PATCH] media: dt-bindings: media: rcar_vin: add support for r8a77965
On Sun, May 13, 2018 at 08:58:18PM +0200, Niklas Söderlund wrote: > Signed-off-by: Niklas Söderlund > --- > Documentation/devicetree/bindings/media/rcar_vin.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring > > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt > b/Documentation/devicetree/bindings/media/rcar_vin.txt > index a19517e1c669eb35..c2c57dcf73f4851b 100644 > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt > @@ -21,6 +21,7 @@ on Gen3 platforms to a CSI-2 receiver. > - "renesas,vin-r8a7794" for the R8A7794 device > - "renesas,vin-r8a7795" for the R8A7795 device > - "renesas,vin-r8a7796" for the R8A7796 device > + - "renesas,vin-r8a77965" for the R8A77965 device > - "renesas,vin-r8a77970" for the R8A77970 device > - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible > device. > -- > 2.17.0 >
Re: [PATCH 2/2] dmaengine: rcar-dmac: Document R8A77990 bindings
On Wed, May 16, 2018 at 03:06:19PM +0200, Ulrich Hecht wrote: > From: Hiroyuki Yokoyama > > Renesas R-Car E3 (R8A77990) SoC also has the R-Car gen2/3 compatible DMA > controllers, so document the SoC specific binding. > > Signed-off-by: Hiroyuki Yokoyama > Signed-off-by: Ulrich Hecht > --- > Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring
Re: [PATCH 3/4] PCI: rcar: Add missing irq_dispose_mapping() into failpath
On 05/22/2018 05:18 PM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Mon, May 21, 2018 at 3:11 PM, Marek Vasut wrote:
>> The rcar_pcie_get_resources() is another misnomer with a side effect.
>> The function does not only get resources, but also maps MSI IRQs via
>> irq_of_parse_and_map(). In case anything fails afterward, the IRQ
>> mapping must be disposed through irq_dispose_mapping() which is not
>> done.
>>
>> This patch handles irq_of_parse_and_map() failures in by disposing
>> of the mapping in rcar_pcie_get_resources() as well as in probe.
>>
>> Signed-off-by: Marek Vasut
>
> Reviewed-by: Geert Uytterhoeven
>
>> --- a/drivers/pci/host/pcie-rcar.c
>> +++ b/drivers/pci/host/pcie-rcar.c
>> @@ -923,18 +923,25 @@ static int rcar_pcie_get_resources(struct rcar_pcie
>> *pcie)
>> i = irq_of_parse_and_map(dev->of_node, 0);
>> if (!i) {
>> dev_err(dev, "cannot get platform resources for msi
>> interrupt\n");
>> - return -ENOENT;
>> + err = -ENOENT;
>> + goto err_irq1;
>
> You could have kept the return here.
I like the symmetry ;-)
[...]
--
Best regards,
Marek Vasut
