Re: [PATCH/RFC 01/02] ravb: Do not announce 100Mbps HDX as supported
Hi Geert, On Fri, Jul 20, 2018 at 2:42 AM, Geert Uytterhoeven wrote: > Hi Magnus, > > On Thu, Jul 19, 2018 at 7:25 PM Magnus Damm wrote: >> On Thu, Jul 19, 2018 at 11:32 PM, Sergei Shtylyov >> wrote: >> > On 07/19/2018 02:51 PM, Magnus Damm wrote: >> >> From: Magnus Damm >> >> >> >> According to the data sheet the Ethernet-AVB hardware in R-Car Gen3 >> >> and R-Car Gen2 SoCs do not support half duplex operation. So update >> >> the driver to mark 100Mbit HDX as unsupported. >> > >> >What about 1000Mbit HDX? >> >> For Twister Pair I believe 10 and 100 Mbps come in HDX and FDX flavors >> while 1 Gbps is HDX-only. > > 1 Gbps is _F_DX-only? Correct, typo from my side! It should be 1 Gbps FDX-only. Cheers, / magnus
Re: [PATCH/RFC 01/02] ravb: Do not announce 100Mbps HDX as supported
Hi Geert, On Fri, Jul 20, 2018 at 5:09 AM, Geert Uytterhoeven wrote: > On Thu, Jul 19, 2018 at 7:56 PM Sergei Shtylyov > wrote: >> On 07/19/2018 08:42 PM, Geert Uytterhoeven wrote: >> From: Magnus Damm >> According to the data sheet the Ethernet-AVB hardware in R-Car Gen3 >> and R-Car Gen2 SoCs do not support half duplex operation. So update >> the driver to mark 100Mbit HDX as unsupported. >> >>> >> >>>What about 1000Mbit HDX? >> >> >> >> For Twister Pair I believe 10 and 100 Mbps come in HDX and FDX flavors >> >> while 1 Gbps is HDX-only. >> > >> > 1 Gbps is _F_DX-only? >> >>No, only higher speeds are FDX only. >> >> >> https://en.wikipedia.org/wiki/Ethernet_over_twisted_pair > > That wiki page says "However, half-duplex operation for gigabit speed isn't > supported by any existing hardware.". Exactly. Also the PHY data sheet might have some additional information about bitmaps for advertised and supported modes. > Running ethtool on a few systems shows that some of them don't support it, > while > others do. Amen. Nice to see that at least someone else is using ethtool to test link configuration. =/ Thanks, / magnus
Re: [PATCH] arm64: dts: renesas: Include R-Car product name in DTSI files
Hi Geert, On Fri, Jul 20, 2018 at 2:37 AM, Geert Uytterhoeven wrote: > Hi Magnus, > > On Thu, Jul 19, 2018 at 7:16 PM Magnus Damm wrote: >> On Thu, Jul 19, 2018 at 9:59 PM, Niklas Söderlund >> wrote: >> > On 2018-07-19 20:19:50 +0900, Magnus Damm wrote: >> >> --- 0001/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi >> >> +++ work/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi 2018-07-19 >> >> 20:04:10.900607110 +0900 >> >> @@ -1,6 +1,6 @@ >> >> // SPDX-License-Identifier: GPL-2.0 >> >> /* >> >> - * Device Tree Source for the r8a7795 ES1.x SoC >> >> + * Device Tree Source for the R-Car H3 (R8A77950) ES1.x SoC >> > >> > I'm just curies why do you append a extra 0 to the part number here and >> > for M3-W? Other then I think this change is good and will help me as >> > well to map part number to product name :-) >> >> Good question! >> >> I should probably have mentioned in the patch description that the >> names and part numbers come from the file >> Documentation/devicetree/bindings/arm/shmobile.txt. > > To add to the confusion: R-Car H3 ES2.0 is actually R8A77951... What a mess! I wonder what ES3.0 is? Cheers, / magnus
Re: [PATCH/RFT 7/7] arm64: dts: renesas: r8a77965: Add Sound MIX support
Hi > From: Takeshi Kihara > > Based on a similar patch of the R8A7796 device tree > by Kuninori Morimoto . > > Signed-off-by: Takeshi Kihara > Signed-off-by: Yoshihiro Kaneko > --- Acked-by: Kuninori Morimoto
Re: [PATCH/RFT 6/7] arm64: dts: renesas: r8a77965: Add Sound CTU support
Hi > From: Takeshi Kihara > > Based on a similar patch of the R8A7796 device tree > by Kuninori Morimoto . > > Signed-off-by: Takeshi Kihara > Signed-off-by: Yoshihiro Kaneko > --- Acked-by: Kuninori Morimoto
Re: [PATCH/RFT 5/7] arm64: dts: renesas: r8a77965: Add Sound DVC device nodes
Hi > From: Takeshi Kihara > > Based on a similar patch of the R8A7796 device tree > by Kuninori Morimoto . > > Signed-off-by: Takeshi Kihara > Signed-off-by: Yoshihiro Kaneko > --- Acked-by: Kuninori Morimoto
Re: [PATCH/RFT 4/7] arm64: dts: renesas: r8a77965: Add Sound SRC support
Hi > From: Takeshi Kihara > > Based on a similar patch of the R8A7796 device tree > by Kuninori Morimoto . > > Signed-off-by: Takeshi Kihara > Signed-off-by: Yoshihiro Kaneko > --- Acked-by: Kuninori Morimoto
Re: [PATCH/RFT 3/7] arm64: dts: renesas: r8a77965: Add Sound device node and SSI support
Hi
> From: Takeshi Kihara
>
> Based on several similar patches of the R8A7796 device tree
> by Kuninori Morimoto .
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Yoshihiro Kaneko
> ---
(snip)
> rcar_sound: sound@ec50 {
> + /*
> + * #sound-dai-cells is required
> + *
> + * Single DAI : #sound-dai-cells = <0>; <_sound>;
> + * Multi DAI : #sound-dai-cells = <1>; <_sound N>;
> + */
> + /*
> + * #clock-cells is required for audio_clkout0/1/2/3
> + *
> + * clkout : #clock-cells = <0>; <_sound>;
> + * clkout0/1/2/3: #clock-cells = <1>; <_sound N>;
> + */
> + compatible = "renesas,rcar_sound-r8a7796",
> "renesas,rcar_sound-gen3";
77965 ?
Acked-by: Kuninori Morimoto
Re: [PATCH/RFT 2/7] ASoC: rsnd: Document R-Car M3-N support
Hi Thnak you for your patch > From: Hiroyuki Yokoyama > > Document support for the sound modules in the Renesas M3-N (r8a77965) > SoC. > > No driver update is needed. > > Signed-off-by: Hiroyuki Yokoyama > Signed-off-by: Yoshihiro Kaneko > --- Acked-by: Kuninori Morimoto But, I think this patch should go to ALSA SoC ML. > Documentation/devicetree/bindings/sound/renesas,rsnd.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt > b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt > index b86d790..9e764270 100644 > --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt > +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt > @@ -352,6 +352,7 @@ Required properties: > - "renesas,rcar_sound-r8a7794" (R-Car E2) > - "renesas,rcar_sound-r8a7795" (R-Car H3) > - "renesas,rcar_sound-r8a7796" (R-Car M3-W) > + - "renesas,rcar_sound-r8a77965" (R-Car M3-N) > - reg: Should contain the register physical > address. > required register is > SRU/ADG/SSI if generation1 > -- > 1.9.1 >
Re: [PATCH/RFC 01/02] ravb: Do not announce 100Mbps HDX as supported
Hi Sergei,
On Thu, Jul 19, 2018 at 7:56 PM Sergei Shtylyov
wrote:
> On 07/19/2018 08:42 PM, Geert Uytterhoeven wrote:
> From: Magnus Damm
> According to the data sheet the Ethernet-AVB hardware in R-Car Gen3
> and R-Car Gen2 SoCs do not support half duplex operation. So update
> the driver to mark 100Mbit HDX as unsupported.
> >>>
> >>>What about 1000Mbit HDX?
> >>
> >> For Twister Pair I believe 10 and 100 Mbps come in HDX and FDX flavors
> >> while 1 Gbps is HDX-only.
> >
> > 1 Gbps is _F_DX-only?
>
>No, only higher speeds are FDX only.
>
> >> https://en.wikipedia.org/wiki/Ethernet_over_twisted_pair
That wiki page says "However, half-duplex operation for gigabit speed isn't
supported by any existing hardware.".
Running ethtool on a few systems shows that some of them don't support it, while
others do.
I don't have any higher speed Ethernet cards yet (do you? ;-)
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 01/02] ravb: Do not announce 100Mbps HDX as supported
On 07/19/2018 08:42 PM, Geert Uytterhoeven wrote:
From: Magnus Damm
According to the data sheet the Ethernet-AVB hardware in R-Car Gen3
and R-Car Gen2 SoCs do not support half duplex operation. So update
the driver to mark 100Mbit HDX as unsupported.
>>>
>>>What about 1000Mbit HDX?
>>
>> For Twister Pair I believe 10 and 100 Mbps come in HDX and FDX flavors
>> while 1 Gbps is HDX-only.
>
> 1 Gbps is _F_DX-only?
No, only higher speeds are FDX only.
>> https://en.wikipedia.org/wiki/Ethernet_over_twisted_pair
>
> Gr{oetje,eeting}s,
>
> Geert
MBR, Sergei
Re: [PATCH/RFC 01/02] ravb: Do not announce 100Mbps HDX as supported
Hi Magnus,
On Thu, Jul 19, 2018 at 7:25 PM Magnus Damm wrote:
> On Thu, Jul 19, 2018 at 11:32 PM, Sergei Shtylyov
> wrote:
> > On 07/19/2018 02:51 PM, Magnus Damm wrote:
> >> From: Magnus Damm
> >>
> >> According to the data sheet the Ethernet-AVB hardware in R-Car Gen3
> >> and R-Car Gen2 SoCs do not support half duplex operation. So update
> >> the driver to mark 100Mbit HDX as unsupported.
> >
> >What about 1000Mbit HDX?
>
> For Twister Pair I believe 10 and 100 Mbps come in HDX and FDX flavors
> while 1 Gbps is HDX-only.
1 Gbps is _F_DX-only?
> https://en.wikipedia.org/wiki/Ethernet_over_twisted_pair
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: Include R-Car product name in DTSI files
Hi Magnus,
On Thu, Jul 19, 2018 at 7:16 PM Magnus Damm wrote:
> On Thu, Jul 19, 2018 at 9:59 PM, Niklas Söderlund
> wrote:
> > On 2018-07-19 20:19:50 +0900, Magnus Damm wrote:
> >> --- 0001/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
> >> +++ work/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi 2018-07-19
> >> 20:04:10.900607110 +0900
> >> @@ -1,6 +1,6 @@
> >> // SPDX-License-Identifier: GPL-2.0
> >> /*
> >> - * Device Tree Source for the r8a7795 ES1.x SoC
> >> + * Device Tree Source for the R-Car H3 (R8A77950) ES1.x SoC
> >
> > I'm just curies why do you append a extra 0 to the part number here and
> > for M3-W? Other then I think this change is good and will help me as
> > well to map part number to product name :-)
>
> Good question!
>
> I should probably have mentioned in the patch description that the
> names and part numbers come from the file
> Documentation/devicetree/bindings/arm/shmobile.txt.
To add to the confusion: R-Car H3 ES2.0 is actually R8A77951...
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 02/02] ravb: Clean up duplex handling
Hi Sergei, On Fri, Jul 20, 2018 at 12:44 AM, Sergei Shtylyov wrote: > On 07/19/2018 02:51 PM, Magnus Damm wrote: > >> From: Magnus Damm >> >> Since only full-duplex operation is supported by the >> hardware, remove duplex handling code and keep the >> register setting of ECMR.DM fixed at 1. >> >> This updates the driver implementation to follow the >> data sheet text "This bit should always be set to 1." >> >> Not-Yet-Signed-off-by: Magnus Damm > >Sounds like a fix, please provide a Fixes: tag (I think we're fixing > the initial driver commit here). Yeah it is a fix if you consider not following the data sheet a bug. The same applies to the first patch but it fixes the issue that we don't setup the PHY correctly. > Reviewed-by: Sergei Shtylyov Thanks! >> --- >> >> Written on top of renesas-drivers-2018-07-17-v4.18-rc5 > >Next time please base atop of DaveM's net.git repo. Yep, will wait a while to see if there is any more feedback before sending an updated version of the series. > [...] >> --- 0003/drivers/net/ethernet/renesas/ravb_main.c >> +++ work/drivers/net/ethernet/renesas/ravb_main.c 2018-07-19 >> 19:44:14.370607110 +0900 > [...] >> @@ -1131,13 +1114,6 @@ static int ravb_set_link_ksettings(struc >> if (error) >> goto error_exit; >> >> - if (cmd->base.duplex == DUPLEX_FULL) >> - priv->duplex = 1; >> - else >> - priv->duplex = 0; >> - >> - ravb_set_duplex(ndev); >> - > >This fragment no longer exists in net.git... Yeah will take care of that when I rebase. Thanks, / magnus
Re: [PATCH/RFC 01/02] ravb: Do not announce 100Mbps HDX as supported
Hi Sergei, Thanks for your reply! On Thu, Jul 19, 2018 at 11:32 PM, Sergei Shtylyov wrote: > Hello! > > On 07/19/2018 02:51 PM, Magnus Damm wrote: > >> From: Magnus Damm >> >> According to the data sheet the Ethernet-AVB hardware in R-Car Gen3 >> and R-Car Gen2 SoCs do not support half duplex operation. So update >> the driver to mark 100Mbit HDX as unsupported. > >What about 1000Mbit HDX? For Twister Pair I believe 10 and 100 Mbps come in HDX and FDX flavors while 1 Gbps is HDX-only. https://en.wikipedia.org/wiki/Ethernet_over_twisted_pair >> Not-Yet-Signed-off-by: Magnus Damm >> --- >> >> Written on top of renesas-drivers-2018-07-17-v4.18-rc5 >> >> drivers/net/ethernet/renesas/ravb_main.c |4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> --- 0001/drivers/net/ethernet/renesas/ravb_main.c >> +++ work/drivers/net/ethernet/renesas/ravb_main.c 2018-07-19 >> 19:18:38.210607110 +0900 >> @@ -1066,8 +1066,8 @@ static int ravb_phy_init(struct net_devi >> netdev_info(ndev, "limited PHY to 100Mbit/s\n"); >> } >> >> - /* 10BASE is not supported */ >> - phydev->supported &= ~PHY_10BT_FEATURES; >> + /* Nether 10BASE nor half duplex is supported */ > >Neither. s/is/are/? > >> + phydev->supported &= ~(PHY_10BT_FEATURES | SUPPORTED_100baseT_Half); > >I think you missed SUPPORTED_1000baseT_Half. Perhaps so, but in reality all our boards use a PHY with Twisted Pair cables so SUPPORTED_1000baseT_Half doesn't exist in reality. That aside, I suspect the PHY layer is designed to support more than just Ethernet-over-TP so that's the reason for that particular constant and all the other stuff in phy.h. > [garbage skipped] You mean the rest of the driver? =) Cheers, / magnus
Re: [PATCH] arm64: dts: renesas: Include R-Car product name in DTSI files
Hi Niklas, On Thu, Jul 19, 2018 at 9:59 PM, Niklas Söderlund wrote: > Hi Magnus, > > Thanks for your patch. > > On 2018-07-19 20:19:50 +0900, Magnus Damm wrote: >> From: Magnus Damm >> >> Browsing the DTS for all the R-Car SoCs with similar part numbers >> makes my head hurt, so to improve the user friendliness of the >> DTS code base include R-Car product name in each DTSI file. >> >> Signed-off-by: Magnus Damm >> --- >> >> Based on renesas-drivers-2018-07-17-v4.18-rc5 >> >> arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi |2 +- >> arch/arm64/boot/dts/renesas/r8a7795.dtsi |2 +- >> arch/arm64/boot/dts/renesas/r8a7796.dtsi |2 +- >> arch/arm64/boot/dts/renesas/r8a77965.dtsi|2 +- >> arch/arm64/boot/dts/renesas/r8a77970.dtsi|2 +- >> arch/arm64/boot/dts/renesas/r8a77980.dtsi|2 +- >> arch/arm64/boot/dts/renesas/r8a77990.dtsi|2 +- >> arch/arm64/boot/dts/renesas/r8a77995.dtsi|2 +- >> 8 files changed, 8 insertions(+), 8 deletions(-) >> >> --- 0001/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi >> +++ work/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi 2018-07-19 >> 20:04:10.900607110 +0900 >> @@ -1,6 +1,6 @@ >> // SPDX-License-Identifier: GPL-2.0 >> /* >> - * Device Tree Source for the r8a7795 ES1.x SoC >> + * Device Tree Source for the R-Car H3 (R8A77950) ES1.x SoC > > I'm just curies why do you append a extra 0 to the part number here and > for M3-W? Other then I think this change is good and will help me as > well to map part number to product name :-) Good question! I should probably have mentioned in the patch description that the names and part numbers come from the file Documentation/devicetree/bindings/arm/shmobile.txt. Thanks for the feedback! Cheers, / magnus
[PATCH v3] drivers/firmware: psci_checker: stash and use topology_core_cpumask for hotplug tests
Commit 7f9545aa1a91 ("arm64: smp: remove cpu and numa topology
information when hotplugging out CPU") updates the cpu topology when
the CPU is hotplugged out. However the PSCI checker code uses the
topology_core_cpumask pointers for some of the cpu hotplug testing.
Since the pointer to the core_cpumask of the first CPU in the group
is used, which when that CPU itself is hotpugged out is just set to
itself, the testing terminates after that particular CPU is tested out.
But the intention of this tests is to cover all the CPU in the group.
In order to support that, we need to stash the topology_core_cpumask
before the start of the test and use that value instead of pointer to
a cpumask which will be updated on CPU hotplug.
Fixes: 7f9545aa1a91a9a4 ("arm64: smp: remove cpu and numa topology
information when hotplugging out CPU")
Reported-by: Geert Uytterhoeven
Tested-by: Geert Uytterhoeven
Cc: Mark Rutland
Cc: Lorenzo Pieralisi
Signed-off-by: Sudeep Holla
---
drivers/firmware/psci_checker.c | 83 -
1 file changed, 49 insertions(+), 34 deletions(-)
v2->v3:
- Got rid of find_cpu_groups as suggested by Lorenzo
diff --git a/drivers/firmware/psci_checker.c b/drivers/firmware/psci_checker.c
index bb1c068bff19..346943657962 100644
--- a/drivers/firmware/psci_checker.c
+++ b/drivers/firmware/psci_checker.c
@@ -77,28 +77,6 @@ static int psci_ops_check(void)
return 0;
}
-static int find_cpu_groups(const struct cpumask *cpus,
- const struct cpumask **cpu_groups)
-{
- unsigned int nb = 0;
- cpumask_var_t tmp;
-
- if (!alloc_cpumask_var(, GFP_KERNEL))
- return -ENOMEM;
- cpumask_copy(tmp, cpus);
-
- while (!cpumask_empty(tmp)) {
- const struct cpumask *cpu_group =
- topology_core_cpumask(cpumask_any(tmp));
-
- cpu_groups[nb++] = cpu_group;
- cpumask_andnot(tmp, tmp, cpu_group);
- }
-
- free_cpumask_var(tmp);
- return nb;
-}
-
/*
* offlined_cpus is a temporary array but passing it as an argument avoids
* multiple allocations.
@@ -166,29 +144,66 @@ static unsigned int down_and_up_cpus(const struct cpumask
*cpus,
return err;
}
+static void free_cpu_groups(int num, cpumask_var_t **pcpu_groups)
+{
+ int i;
+ cpumask_var_t *cpu_groups = *pcpu_groups;
+
+ for (i = 0; i < num; ++i)
+ free_cpumask_var(cpu_groups[i]);
+ kfree(cpu_groups);
+}
+
+static int alloc_init_cpu_groups(cpumask_var_t **pcpu_groups)
+{
+ int num_groups = 0;
+ cpumask_var_t tmp, *cpu_groups;
+
+ if (!alloc_cpumask_var(, GFP_KERNEL))
+ return -ENOMEM;
+
+ cpu_groups = kcalloc(nb_available_cpus, sizeof(cpu_groups),
+GFP_KERNEL);
+ if (!cpu_groups)
+ return -ENOMEM;
+
+ cpumask_copy(tmp, cpu_online_mask);
+
+ while (!cpumask_empty(tmp)) {
+ const struct cpumask *cpu_group =
+ topology_core_cpumask(cpumask_any(tmp));
+
+ if (!alloc_cpumask_var(_groups[num_groups], GFP_KERNEL)) {
+ free_cpu_groups(num_groups, _groups);
+ return -ENOMEM;
+ }
+ cpumask_copy(cpu_groups[num_groups++], cpu_group);
+ cpumask_andnot(tmp, tmp, cpu_group);
+ }
+
+ free_cpumask_var(tmp);
+ *pcpu_groups = cpu_groups;
+
+ return num_groups;
+}
+
static int hotplug_tests(void)
{
- int err;
- cpumask_var_t offlined_cpus;
- int i, nb_cpu_group;
- const struct cpumask **cpu_groups;
+ int i, nb_cpu_group, err = -ENOMEM;
+ cpumask_var_t offlined_cpus, *cpu_groups;
char *page_buf;
- err = -ENOMEM;
if (!alloc_cpumask_var(_cpus, GFP_KERNEL))
return err;
- /* We may have up to nb_available_cpus cpu_groups. */
- cpu_groups = kmalloc_array(nb_available_cpus, sizeof(*cpu_groups),
- GFP_KERNEL);
- if (!cpu_groups)
+
+ nb_cpu_group = alloc_init_cpu_groups(_groups);
+ if (nb_cpu_group < 0)
goto out_free_cpus;
page_buf = (char *)__get_free_page(GFP_KERNEL);
if (!page_buf)
goto out_free_cpu_groups;
err = 0;
- nb_cpu_group = find_cpu_groups(cpu_online_mask, cpu_groups);
-
/*
* Of course the last CPU cannot be powered down and cpu_down() should
* refuse doing that.
@@ -212,7 +227,7 @@ static int hotplug_tests(void)
free_page((unsigned long)page_buf);
out_free_cpu_groups:
- kfree(cpu_groups);
+ free_cpu_groups(nb_cpu_group, _groups);
out_free_cpus:
free_cpumask_var(offlined_cpus);
return err;
--
2.7.4
Re: [PATCH/RFC 02/02] ravb: Clean up duplex handling
On 07/19/2018 02:51 PM, Magnus Damm wrote: > From: Magnus Damm > > Since only full-duplex operation is supported by the > hardware, remove duplex handling code and keep the > register setting of ECMR.DM fixed at 1. > > This updates the driver implementation to follow the > data sheet text "This bit should always be set to 1." > > Not-Yet-Signed-off-by: Magnus Damm Sounds like a fix, please provide a Fixes: tag (I think we're fixing the initial driver commit here). Reviewed-by: Sergei Shtylyov > --- > > Written on top of renesas-drivers-2018-07-17-v4.18-rc5 Next time please base atop of DaveM's net.git repo. [...] > --- 0003/drivers/net/ethernet/renesas/ravb_main.c > +++ work/drivers/net/ethernet/renesas/ravb_main.c 2018-07-19 > 19:44:14.370607110 +0900 [...] > @@ -1131,13 +1114,6 @@ static int ravb_set_link_ksettings(struc > if (error) > goto error_exit; > > - if (cmd->base.duplex == DUPLEX_FULL) > - priv->duplex = 1; > - else > - priv->duplex = 0; > - > - ravb_set_duplex(ndev); > - This fragment no longer exists in net.git... [...] MBR, Sergei
Re: [PATCH v2] drivers/firmware: psci_checker: stash and use topology_core_cpumask for hotplug tests
On 19/07/18 15:20, Lorenzo Pieralisi wrote:
> On Thu, Jul 19, 2018 at 02:35:49PM +0100, Sudeep Holla wrote:
[...]
>> +static cpumask_var_t *alloc_cpu_groups(int num)
>> +{
>> +int i;
>> +cpumask_var_t *cpu_groups;
>> +
>> +cpu_groups = kcalloc(num, sizeof(cpu_groups), GFP_KERNEL);
>> +if (!cpu_groups)
>> +return NULL;
>> +
>> +for (i = 0; i < num; ++i)
>> +if (!alloc_cpumask_var(_groups[i], GFP_KERNEL)) {
>> +free_cpu_groups(num, cpu_groups);
>> +return NULL;
>> +}
>> +
>> +return cpu_groups;
>> +}
>
> Sorry for being a PITA - I meant we could remove find_cpu_groups()
Sorry that's exactly what I understood when I read it, but ...
got distracted with something else and when I returned back to it,
implemented something else.
> entirely and embed it in alloc_cpu_groups(), that takes a cpumask_t
> pointer and return the number of groups, again, to make it more
> readable but that's just my opinion.
>
Sorry for not showing that much love to this, not paying too much
attention as it's test code :).
--
Regards,
Sudeep
Re: [PATCH/RFC 01/02] ravb: Do not announce 100Mbps HDX as supported
Hello! On 07/19/2018 02:51 PM, Magnus Damm wrote: > From: Magnus Damm > > According to the data sheet the Ethernet-AVB hardware in R-Car Gen3 > and R-Car Gen2 SoCs do not support half duplex operation. So update > the driver to mark 100Mbit HDX as unsupported. What about 1000Mbit HDX? > Not-Yet-Signed-off-by: Magnus Damm > --- > > Written on top of renesas-drivers-2018-07-17-v4.18-rc5 > > drivers/net/ethernet/renesas/ravb_main.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > --- 0001/drivers/net/ethernet/renesas/ravb_main.c > +++ work/drivers/net/ethernet/renesas/ravb_main.c 2018-07-19 > 19:18:38.210607110 +0900 > @@ -1066,8 +1066,8 @@ static int ravb_phy_init(struct net_devi > netdev_info(ndev, "limited PHY to 100Mbit/s\n"); > } > > - /* 10BASE is not supported */ > - phydev->supported &= ~PHY_10BT_FEATURES; > + /* Nether 10BASE nor half duplex is supported */ Neither. s/is/are/? > + phydev->supported &= ~(PHY_10BT_FEATURES | SUPPORTED_100baseT_Half); I think you missed SUPPORTED_1000baseT_Half. [garbage skipped] MBR, Sergei
Re: [PATCH v2] drivers/firmware: psci_checker: stash and use topology_core_cpumask for hotplug tests
On Thu, Jul 19, 2018 at 02:35:49PM +0100, Sudeep Holla wrote:
> Commit 7f9545aa1a91 ("arm64: smp: remove cpu and numa topology
> information when hotplugging out CPU") updates the cpu topology when
> the CPU is hotplugged out. However the PSCI checker code uses the
> topology_core_cpumask pointers for some of the cpu hotplug testing.
> Since the pointer to the core_cpumask of the first CPU in the group
> is used, which when that CPU itself is hotpugged out is just set to
> itself, the testing terminates after that particular CPU is tested out.
> But the intention of this tests is to cover all the CPU in the group.
>
> In order to support that, we need to stash the topology_core_cpumask
> before the start of the test and use that value instead of pointer to
> a cpumask which will be updated on CPU hotplug.
>
> Fixes: 7f9545aa1a91a9a4 ("arm64: smp: remove cpu and numa topology
> information when hotplugging out CPU")
> Reported-by: Geert Uytterhoeven
> Tested-by: Geert Uytterhoeven
> Cc: Mark Rutland
> Cc: Lorenzo Pieralisi
> Signed-off-by: Sudeep Holla
> ---
> drivers/firmware/psci_checker.c | 53
> -
> 1 file changed, 42 insertions(+), 11 deletions(-)
>
> v1->v2:
> - Move allocation and freeing of the cpumasks to separate
> routines as suggested by Lorenzo
> - Reduced the allocation to number of groups instead of number
> of cpus in the system by making 2 pass
>
> diff --git a/drivers/firmware/psci_checker.c b/drivers/firmware/psci_checker.c
> index bb1c068bff19..7e6f66b588fd 100644
> --- a/drivers/firmware/psci_checker.c
> +++ b/drivers/firmware/psci_checker.c
> @@ -77,21 +77,23 @@ static int psci_ops_check(void)
> return 0;
> }
>
> -static int find_cpu_groups(const struct cpumask *cpus,
> -const struct cpumask **cpu_groups)
> +static int find_cpu_groups(cpumask_var_t *cpu_groups)
> {
> unsigned int nb = 0;
> cpumask_var_t tmp;
>
> if (!alloc_cpumask_var(, GFP_KERNEL))
> return -ENOMEM;
> - cpumask_copy(tmp, cpus);
> + cpumask_copy(tmp, cpu_online_mask);
>
> while (!cpumask_empty(tmp)) {
> const struct cpumask *cpu_group =
> topology_core_cpumask(cpumask_any(tmp));
>
> - cpu_groups[nb++] = cpu_group;
> + if (cpu_groups && cpu_groups[nb])
> + cpumask_copy(cpu_groups[nb], cpu_group);
> +
> + nb++;
> cpumask_andnot(tmp, tmp, cpu_group);
> }
>
> @@ -166,20 +168,48 @@ static unsigned int down_and_up_cpus(const struct
> cpumask *cpus,
> return err;
> }
>
> +static void free_cpu_groups(int num, cpumask_var_t *cpu_groups)
> +{
> + int i;
> +
> + for (i = 0; i < num; ++i)
> + free_cpumask_var(cpu_groups[i]);
> + kfree(cpu_groups);
> +}
> +
> +static cpumask_var_t *alloc_cpu_groups(int num)
> +{
> + int i;
> + cpumask_var_t *cpu_groups;
> +
> + cpu_groups = kcalloc(num, sizeof(cpu_groups), GFP_KERNEL);
> + if (!cpu_groups)
> + return NULL;
> +
> + for (i = 0; i < num; ++i)
> + if (!alloc_cpumask_var(_groups[i], GFP_KERNEL)) {
> + free_cpu_groups(num, cpu_groups);
> + return NULL;
> + }
> +
> + return cpu_groups;
> +}
Sorry for being a PITA - I meant we could remove find_cpu_groups()
entirely and embed it in alloc_cpu_groups(), that takes a cpumask_t
pointer and return the number of groups, again, to make it more
readable but that's just my opinion.
Regardless:
Acked-by: Lorenzo Pieralisi
> static int hotplug_tests(void)
> {
> int err;
> - cpumask_var_t offlined_cpus;
> + cpumask_var_t offlined_cpus, *cpu_groups;
> int i, nb_cpu_group;
> - const struct cpumask **cpu_groups;
> char *page_buf;
>
> + /* first run to just get the number of cpu groups */
> + nb_cpu_group = find_cpu_groups(NULL);
> +
> err = -ENOMEM;
> if (!alloc_cpumask_var(_cpus, GFP_KERNEL))
> return err;
> - /* We may have up to nb_available_cpus cpu_groups. */
> - cpu_groups = kmalloc_array(nb_available_cpus, sizeof(*cpu_groups),
> -GFP_KERNEL);
> +
> + cpu_groups = alloc_cpu_groups(nb_cpu_group);
> if (!cpu_groups)
> goto out_free_cpus;
> page_buf = (char *)__get_free_page(GFP_KERNEL);
> @@ -187,7 +217,8 @@ static int hotplug_tests(void)
> goto out_free_cpu_groups;
>
> err = 0;
> - nb_cpu_group = find_cpu_groups(cpu_online_mask, cpu_groups);
> + /* second run to populate/copy the cpumask */
> + nb_cpu_group = find_cpu_groups(cpu_groups);
>
> /*
>* Of course the last CPU cannot be powered down and cpu_down() should
> @@ -212,7 +243,7 @@ static int hotplug_tests(void)
>
> free_page((unsigned long)page_buf);
> out_free_cpu_groups:
> -
[PATCH v2] drivers/firmware: psci_checker: stash and use topology_core_cpumask for hotplug tests
Commit 7f9545aa1a91 ("arm64: smp: remove cpu and numa topology
information when hotplugging out CPU") updates the cpu topology when
the CPU is hotplugged out. However the PSCI checker code uses the
topology_core_cpumask pointers for some of the cpu hotplug testing.
Since the pointer to the core_cpumask of the first CPU in the group
is used, which when that CPU itself is hotpugged out is just set to
itself, the testing terminates after that particular CPU is tested out.
But the intention of this tests is to cover all the CPU in the group.
In order to support that, we need to stash the topology_core_cpumask
before the start of the test and use that value instead of pointer to
a cpumask which will be updated on CPU hotplug.
Fixes: 7f9545aa1a91a9a4 ("arm64: smp: remove cpu and numa topology
information when hotplugging out CPU")
Reported-by: Geert Uytterhoeven
Tested-by: Geert Uytterhoeven
Cc: Mark Rutland
Cc: Lorenzo Pieralisi
Signed-off-by: Sudeep Holla
---
drivers/firmware/psci_checker.c | 53 -
1 file changed, 42 insertions(+), 11 deletions(-)
v1->v2:
- Move allocation and freeing of the cpumasks to separate
routines as suggested by Lorenzo
- Reduced the allocation to number of groups instead of number
of cpus in the system by making 2 pass
diff --git a/drivers/firmware/psci_checker.c b/drivers/firmware/psci_checker.c
index bb1c068bff19..7e6f66b588fd 100644
--- a/drivers/firmware/psci_checker.c
+++ b/drivers/firmware/psci_checker.c
@@ -77,21 +77,23 @@ static int psci_ops_check(void)
return 0;
}
-static int find_cpu_groups(const struct cpumask *cpus,
- const struct cpumask **cpu_groups)
+static int find_cpu_groups(cpumask_var_t *cpu_groups)
{
unsigned int nb = 0;
cpumask_var_t tmp;
if (!alloc_cpumask_var(, GFP_KERNEL))
return -ENOMEM;
- cpumask_copy(tmp, cpus);
+ cpumask_copy(tmp, cpu_online_mask);
while (!cpumask_empty(tmp)) {
const struct cpumask *cpu_group =
topology_core_cpumask(cpumask_any(tmp));
- cpu_groups[nb++] = cpu_group;
+ if (cpu_groups && cpu_groups[nb])
+ cpumask_copy(cpu_groups[nb], cpu_group);
+
+ nb++;
cpumask_andnot(tmp, tmp, cpu_group);
}
@@ -166,20 +168,48 @@ static unsigned int down_and_up_cpus(const struct cpumask
*cpus,
return err;
}
+static void free_cpu_groups(int num, cpumask_var_t *cpu_groups)
+{
+ int i;
+
+ for (i = 0; i < num; ++i)
+ free_cpumask_var(cpu_groups[i]);
+ kfree(cpu_groups);
+}
+
+static cpumask_var_t *alloc_cpu_groups(int num)
+{
+ int i;
+ cpumask_var_t *cpu_groups;
+
+ cpu_groups = kcalloc(num, sizeof(cpu_groups), GFP_KERNEL);
+ if (!cpu_groups)
+ return NULL;
+
+ for (i = 0; i < num; ++i)
+ if (!alloc_cpumask_var(_groups[i], GFP_KERNEL)) {
+ free_cpu_groups(num, cpu_groups);
+ return NULL;
+ }
+
+ return cpu_groups;
+}
+
static int hotplug_tests(void)
{
int err;
- cpumask_var_t offlined_cpus;
+ cpumask_var_t offlined_cpus, *cpu_groups;
int i, nb_cpu_group;
- const struct cpumask **cpu_groups;
char *page_buf;
+ /* first run to just get the number of cpu groups */
+ nb_cpu_group = find_cpu_groups(NULL);
+
err = -ENOMEM;
if (!alloc_cpumask_var(_cpus, GFP_KERNEL))
return err;
- /* We may have up to nb_available_cpus cpu_groups. */
- cpu_groups = kmalloc_array(nb_available_cpus, sizeof(*cpu_groups),
- GFP_KERNEL);
+
+ cpu_groups = alloc_cpu_groups(nb_cpu_group);
if (!cpu_groups)
goto out_free_cpus;
page_buf = (char *)__get_free_page(GFP_KERNEL);
@@ -187,7 +217,8 @@ static int hotplug_tests(void)
goto out_free_cpu_groups;
err = 0;
- nb_cpu_group = find_cpu_groups(cpu_online_mask, cpu_groups);
+ /* second run to populate/copy the cpumask */
+ nb_cpu_group = find_cpu_groups(cpu_groups);
/*
* Of course the last CPU cannot be powered down and cpu_down() should
@@ -212,7 +243,7 @@ static int hotplug_tests(void)
free_page((unsigned long)page_buf);
out_free_cpu_groups:
- kfree(cpu_groups);
+ free_cpu_groups(nb_cpu_group, cpu_groups);
out_free_cpus:
free_cpumask_var(offlined_cpus);
return err;
--
2.7.4
Re: [PATCH] arm64: dts: renesas: Include R-Car product name in DTSI files
Hi Magnus, Thanks for your patch. On 2018-07-19 20:19:50 +0900, Magnus Damm wrote: > From: Magnus Damm > > Browsing the DTS for all the R-Car SoCs with similar part numbers > makes my head hurt, so to improve the user friendliness of the > DTS code base include R-Car product name in each DTSI file. > > Signed-off-by: Magnus Damm > --- > > Based on renesas-drivers-2018-07-17-v4.18-rc5 > > arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi |2 +- > arch/arm64/boot/dts/renesas/r8a7795.dtsi |2 +- > arch/arm64/boot/dts/renesas/r8a7796.dtsi |2 +- > arch/arm64/boot/dts/renesas/r8a77965.dtsi|2 +- > arch/arm64/boot/dts/renesas/r8a77970.dtsi|2 +- > arch/arm64/boot/dts/renesas/r8a77980.dtsi|2 +- > arch/arm64/boot/dts/renesas/r8a77990.dtsi|2 +- > arch/arm64/boot/dts/renesas/r8a77995.dtsi|2 +- > 8 files changed, 8 insertions(+), 8 deletions(-) > > --- 0001/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi > +++ work/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi 2018-07-19 > 20:04:10.900607110 +0900 > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0 > /* > - * Device Tree Source for the r8a7795 ES1.x SoC > + * Device Tree Source for the R-Car H3 (R8A77950) ES1.x SoC I'm just curies why do you append a extra 0 to the part number here and for M3-W? Other then I think this change is good and will help me as well to map part number to product name :-) > * > * Copyright (C) 2015 Renesas Electronics Corp. > */ > --- 0001/arch/arm64/boot/dts/renesas/r8a7795.dtsi > +++ work/arch/arm64/boot/dts/renesas/r8a7795.dtsi 2018-07-19 > 20:04:21.030607110 +0900 > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0 > /* > - * Device Tree Source for the r8a7795 SoC > + * Device Tree Source for the R-Car H3 (R8A77950) SoC > * > * Copyright (C) 2015 Renesas Electronics Corp. > */ > --- 0001/arch/arm64/boot/dts/renesas/r8a7796.dtsi > +++ work/arch/arm64/boot/dts/renesas/r8a7796.dtsi 2018-07-19 > 20:04:53.310607110 +0900 > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0 > /* > - * Device Tree Source for the r8a7796 SoC > + * Device Tree Source for the R-Car M3-W (R8A77960) SoC > * > * Copyright (C) 2016-2017 Renesas Electronics Corp. > */ > --- 0001/arch/arm64/boot/dts/renesas/r8a77965.dtsi > +++ work/arch/arm64/boot/dts/renesas/r8a77965.dtsi2018-07-19 > 20:05:24.380607110 +0900 > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0 > /* > - * Device Tree Source for the r8a77965 SoC > + * Device Tree Source for the R-Car M3-N (R8A77965) SoC > * > * Copyright (C) 2018 Jacopo Mondi > * > --- 0001/arch/arm64/boot/dts/renesas/r8a77970.dtsi > +++ work/arch/arm64/boot/dts/renesas/r8a77970.dtsi2018-07-19 > 20:06:31.090607110 +0900 > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0 > /* > - * Device Tree Source for the r8a77970 SoC > + * Device Tree Source for the R-Car V3M (R8A77970) SoC > * > * Copyright (C) 2016-2017 Renesas Electronics Corp. > * Copyright (C) 2017 Cogent Embedded, Inc. > --- 0001/arch/arm64/boot/dts/renesas/r8a77980.dtsi > +++ work/arch/arm64/boot/dts/renesas/r8a77980.dtsi2018-07-19 > 20:06:16.310607110 +0900 > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0 > /* > - * Device Tree Source for the r8a77980 SoC > + * Device Tree Source for the R-Car V3H (R8A77980) SoC > * > * Copyright (C) 2018 Renesas Electronics Corp. > * Copyright (C) 2018 Cogent Embedded, Inc. > --- 0001/arch/arm64/boot/dts/renesas/r8a77990.dtsi > +++ work/arch/arm64/boot/dts/renesas/r8a77990.dtsi2018-07-19 > 20:06:58.970607110 +0900 > @@ -1,6 +1,6 @@ > /* SPDX-License-Identifier: GPL-2.0 */ > /* > - * Device Tree Source for the r8a77990 SoC > + * Device Tree Source for the R-Car E3 (R8A77990) SoC > * > * Copyright (C) 2018 Renesas Electronics Corp. > */ > --- 0005/arch/arm64/boot/dts/renesas/r8a77995.dtsi > +++ work/arch/arm64/boot/dts/renesas/r8a77995.dtsi2018-07-19 > 20:07:20.150607110 +0900 > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0 > /* > - * Device Tree Source for the r8a77995 SoC > + * Device Tree Source for the R-Car D3 (R8A77995) SoC > * > * Copyright (C) 2016 Renesas Electronics Corp. > * Copyright (C) 2017 Glider bvba -- Regards, Niklas Söderlund
RE: [PATCH 2/2] serial: sh-sci: Document r7s9210 bindings
Hi Geert, On Thursday, July 19, 2018, Geert Uytterhoeven wrote: > > The issue that I ran into was the device driver assumed some signals > > were muxed together (TXI and DRI), and that other signals were > individual. > > > > The existing driver wanted interrupts to be specified in this order: > > 1. Error > > 2. RX > > 3. TX (assumes DRI) > > 4. Break First, sorry for my mis-type. DRI mean 'Data Ready Interrupt' and for SCIF it is normally muxed with RX (not TX). > > Of course I have no problem documenting all this, but I first I just > > wanted to make sure I was not going to get push back when I submit a DT > > later that lists the same interrupt twice. > > Listing them twice does make sense to me, as the interrupt controller > source list in the RZ/A2 docs has only four, and explicitly lists how they > are > multiplexed: > base + 0 = ERI/BRI, > base + 1 = RXI, > base + 2 = TXI, > base + 3 = TEI/DRI. > But future SoCS with the same SCIFA variant may wire them differently? This SCIF seems to be related to ones used in H8S devices. It's also been used in RX and RZ/T devices. So I think the order seems to be stable. > For DT backwards compatibility, we have to keep support for the following > 2 schemes: > 1. Single "interrupts" value, no "interrupt-names", for fully > multiplexed > interrupts (SH/R-Mobile, R-Car). > 2. Four "interrupts" values, no "interrupt-names", for ERI/RXI/TXI/TEI > (RZ/A1, H8/300). > > For RZ/A2, I suggest extending the bindings with interrupt-names, > documenting all 6 interrupt sources, and let the driver handle that. > That means there should be 6, not 5, "interrupts" values. > Whether the driver implements all possible combinations, or only what you > need for RZ/A2, is up to you. I agree the interrupt handling in the driver > is already sufficiently complex. > Ideally, you would document support for RZ/A1 with interrupt-names too, > and handle that as well. > > Does this make sense? What about this idea: Since we can't break any old DTs, what if we just say that you simply list all the interrupts in DT, and the driver just registers all those vectors with the same ISR function (sci_mpxed_interrupt) and process everything the same way R-Car devices do with their single interrupt. For this class of device, having separate interrupt vectors probably doesn't buy you that much extra performance. The driver could also check to see if "interrupt-names" was specified, and if it was, the driver could simply use those names when registering the interrupts so everything shows up nicely in /proc/interrupts. What's your thoughts on that idea? Chris
CCREE performance on R-Car H3
Hi Gilad,
I've noticed CCREE is used with a LUKS-formatted disk, so I did some small
performance benchmarks. The disk is an old 160 GiB SATA hard drive,
connected to either Salvator-XS (R-Car H3 ES2.0) or Koelsch (R-Car M2-W).
hdparm -t /dev/sda (unencrypted data): 62 MB/s (both systems)
hdparm -t /dev/dm-0 (encrypted data, LUKS AES):
salvator-xs (CCREE): 15 MB/s
salvator-xs (SW):62 MB/s
koelsch (SW):47 MB/s
I'm a bit disappointment by the results when using crypto acceleration.
Apparently the in-kernel optimized arm64 implementation can decrypt at
raw read speed, while CCREE can't keep up.
Is this expected, and in line with your experiences?
Thanks!
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 01/02] ravb: Do not announce 100Mbps HDX as supported
From: Magnus Damm According to the data sheet the Ethernet-AVB hardware in R-Car Gen3 and R-Car Gen2 SoCs do not support half duplex operation. So update the driver to mark 100Mbit HDX as unsupported. Not-Yet-Signed-off-by: Magnus Damm --- Written on top of renesas-drivers-2018-07-17-v4.18-rc5 drivers/net/ethernet/renesas/ravb_main.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- 0001/drivers/net/ethernet/renesas/ravb_main.c +++ work/drivers/net/ethernet/renesas/ravb_main.c 2018-07-19 19:18:38.210607110 +0900 @@ -1066,8 +1066,8 @@ static int ravb_phy_init(struct net_devi netdev_info(ndev, "limited PHY to 100Mbit/s\n"); } - /* 10BASE is not supported */ - phydev->supported &= ~PHY_10BT_FEATURES; + /* Nether 10BASE nor half duplex is supported */ + phydev->supported &= ~(PHY_10BT_FEATURES | SUPPORTED_100baseT_Half); phy_attached_info(phydev);
[PATCH/RFC 02/02] ravb: Clean up duplex handling
From: Magnus Damm
Since only full-duplex operation is supported by the
hardware, remove duplex handling code and keep the
register setting of ECMR.DM fixed at 1.
This updates the driver implementation to follow the
data sheet text "This bit should always be set to 1."
Not-Yet-Signed-off-by: Magnus Damm
---
Written on top of renesas-drivers-2018-07-17-v4.18-rc5
drivers/net/ethernet/renesas/ravb.h |1 -
drivers/net/ethernet/renesas/ravb_main.c | 26 +-
2 files changed, 1 insertion(+), 26 deletions(-)
--- 0001/drivers/net/ethernet/renesas/ravb.h
+++ work/drivers/net/ethernet/renesas/ravb.h2018-07-19 19:43:11.830607110
+0900
@@ -1027,7 +1027,6 @@ struct ravb_private {
phy_interface_t phy_interface;
int msg_enable;
int speed;
- int duplex;
int emac_irq;
enum ravb_chip_id chip_id;
int rx_irqs[NUM_RX_QUEUE];
--- 0003/drivers/net/ethernet/renesas/ravb_main.c
+++ work/drivers/net/ethernet/renesas/ravb_main.c 2018-07-19
19:44:14.370607110 +0900
@@ -85,13 +85,6 @@ static int ravb_config(struct net_device
return error;
}
-static void ravb_set_duplex(struct net_device *ndev)
-{
- struct ravb_private *priv = netdev_priv(ndev);
-
- ravb_modify(ndev, ECMR, ECMR_DM, priv->duplex ? ECMR_DM : 0);
-}
-
static void ravb_set_rate(struct net_device *ndev)
{
struct ravb_private *priv = netdev_priv(ndev);
@@ -401,13 +394,11 @@ error:
/* E-MAC init function */
static void ravb_emac_init(struct net_device *ndev)
{
- struct ravb_private *priv = netdev_priv(ndev);
-
/* Receive frame limit set register */
ravb_write(ndev, ndev->mtu + ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN, RFLR);
/* EMAC Mode: PAUSE prohibition; Duplex; RX Checksum; TX; RX */
- ravb_write(ndev, ECMR_ZPF | (priv->duplex ? ECMR_DM : 0) |
+ ravb_write(ndev, ECMR_ZPF | ECMR_DM |
(ndev->features & NETIF_F_RXCSUM ? ECMR_RCSC : 0) |
ECMR_TE | ECMR_RE, ECMR);
@@ -982,12 +973,6 @@ static void ravb_adjust_link(struct net_
bool new_state = false;
if (phydev->link) {
- if (phydev->duplex != priv->duplex) {
- new_state = true;
- priv->duplex = phydev->duplex;
- ravb_set_duplex(ndev);
- }
-
if (phydev->speed != priv->speed) {
new_state = true;
priv->speed = phydev->speed;
@@ -1004,7 +989,6 @@ static void ravb_adjust_link(struct net_
new_state = true;
priv->link = 0;
priv->speed = 0;
- priv->duplex = -1;
if (priv->no_avb_link)
ravb_rcv_snd_disable(ndev);
}
@@ -1029,7 +1013,6 @@ static int ravb_phy_init(struct net_devi
priv->link = 0;
priv->speed = 0;
- priv->duplex = -1;
/* Try connecting to PHY */
pn = of_parse_phandle(np, "phy-handle", 0);
@@ -1131,13 +1114,6 @@ static int ravb_set_link_ksettings(struc
if (error)
goto error_exit;
- if (cmd->base.duplex == DUPLEX_FULL)
- priv->duplex = 1;
- else
- priv->duplex = 0;
-
- ravb_set_duplex(ndev);
-
error_exit:
mdelay(1);
[PATCH/RFC 00/02] ravb: Duplex handling update
ravb: Duplex handling update [PATCH/RFC 01/02] ravb: Do not announce 100Mbps HDX as supported [PATCH/RFC 02/02] ravb: Clean up duplex handling This series contains prototype-level code to update the Ethernet-AVB driver to improve duplex handling. Based on the latest data sheet for R-Car Gen3 [1] and R-Car Gen2 [2] the following information is part of the EthernetAVB-IF overview page: Transfer speed: Supports transfer at 100 and 1000 Mbps Mode: Full-duplex mode It seems that the driver implementation is not matching the information provided in the friendly data sheet, and on top of this during run-time when changing PHY configuration of the link partner the Ethernet-AVB PHY seems to want to announce unsupported modes. [1] R-Car Series, 3rd Generation Rev.1.00 (Apr 2018) [2] R-Car Series, 2nd Generation Rev.2.00 (Feb 2016) Not suitable for upstream merge yet - needs more discussion. Not-Yet-Signed-off-by: Magnus Damm --- Written on top of renesas-drivers-2018-07-17-v4.18-rc5 drivers/net/ethernet/renesas/ravb.h |1 - drivers/net/ethernet/renesas/ravb_main.c | 30 +++--- 2 files changed, 3 insertions(+), 28 deletions(-)
[PATCH] arm64: dts: renesas: r8a77995: Attach the SYS-DMAC to the IPMMU
From: Magnus Damm
Hook up SYS-DMAC0, SYS-DMAC1 and SYS-DMAC2 to IPMMU-DS0 and IPMMU-DS1
following the R-Car Gen3 Rev.1.00 (April 2018) datasheet.
Signed-off-by: Magnus Damm
---
Based on renesas-drivers-2018-07-17-v4.18-rc5
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 12
1 file changed, 12 insertions(+)
--- 0001/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ work/arch/arm64/boot/dts/renesas/r8a77995.dtsi 2018-07-19
19:57:01.350607110 +0900
@@ -356,6 +356,10 @@
resets = < 219>;
#dma-cells = <1>;
dma-channels = <8>;
+ iommus = <_ds0 0>, <_ds0 1>,
+ <_ds0 2>, <_ds0 3>,
+ <_ds0 4>, <_ds0 5>,
+ <_ds0 6>, <_ds0 7>;
};
dmac1: dma-controller@e730 {
@@ -380,6 +384,10 @@
resets = < 218>;
#dma-cells = <1>;
dma-channels = <8>;
+ iommus = <_ds1 0>, <_ds1 1>,
+ <_ds1 2>, <_ds1 3>,
+ <_ds1 4>, <_ds1 5>,
+ <_ds1 6>, <_ds1 7>;
};
dmac2: dma-controller@e731 {
@@ -404,6 +412,10 @@
resets = < 217>;
#dma-cells = <1>;
dma-channels = <8>;
+ iommus = <_ds1 16>, <_ds1 17>,
+ <_ds1 18>, <_ds1 19>,
+ <_ds1 20>, <_ds1 21>,
+ <_ds1 22>, <_ds1 23>;
};
ipmmu_ds0: mmu@e674 {
[PATCH] arm64: dts: renesas: Include R-Car product name in DTSI files
From: Magnus Damm Browsing the DTS for all the R-Car SoCs with similar part numbers makes my head hurt, so to improve the user friendliness of the DTS code base include R-Car product name in each DTSI file. Signed-off-by: Magnus Damm --- Based on renesas-drivers-2018-07-17-v4.18-rc5 arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi |2 +- arch/arm64/boot/dts/renesas/r8a7795.dtsi |2 +- arch/arm64/boot/dts/renesas/r8a7796.dtsi |2 +- arch/arm64/boot/dts/renesas/r8a77965.dtsi|2 +- arch/arm64/boot/dts/renesas/r8a77970.dtsi|2 +- arch/arm64/boot/dts/renesas/r8a77980.dtsi|2 +- arch/arm64/boot/dts/renesas/r8a77990.dtsi|2 +- arch/arm64/boot/dts/renesas/r8a77995.dtsi|2 +- 8 files changed, 8 insertions(+), 8 deletions(-) --- 0001/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi +++ work/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi 2018-07-19 20:04:10.900607110 +0900 @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Device Tree Source for the r8a7795 ES1.x SoC + * Device Tree Source for the R-Car H3 (R8A77950) ES1.x SoC * * Copyright (C) 2015 Renesas Electronics Corp. */ --- 0001/arch/arm64/boot/dts/renesas/r8a7795.dtsi +++ work/arch/arm64/boot/dts/renesas/r8a7795.dtsi 2018-07-19 20:04:21.030607110 +0900 @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Device Tree Source for the r8a7795 SoC + * Device Tree Source for the R-Car H3 (R8A77950) SoC * * Copyright (C) 2015 Renesas Electronics Corp. */ --- 0001/arch/arm64/boot/dts/renesas/r8a7796.dtsi +++ work/arch/arm64/boot/dts/renesas/r8a7796.dtsi 2018-07-19 20:04:53.310607110 +0900 @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Device Tree Source for the r8a7796 SoC + * Device Tree Source for the R-Car M3-W (R8A77960) SoC * * Copyright (C) 2016-2017 Renesas Electronics Corp. */ --- 0001/arch/arm64/boot/dts/renesas/r8a77965.dtsi +++ work/arch/arm64/boot/dts/renesas/r8a77965.dtsi 2018-07-19 20:05:24.380607110 +0900 @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Device Tree Source for the r8a77965 SoC + * Device Tree Source for the R-Car M3-N (R8A77965) SoC * * Copyright (C) 2018 Jacopo Mondi * --- 0001/arch/arm64/boot/dts/renesas/r8a77970.dtsi +++ work/arch/arm64/boot/dts/renesas/r8a77970.dtsi 2018-07-19 20:06:31.090607110 +0900 @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Device Tree Source for the r8a77970 SoC + * Device Tree Source for the R-Car V3M (R8A77970) SoC * * Copyright (C) 2016-2017 Renesas Electronics Corp. * Copyright (C) 2017 Cogent Embedded, Inc. --- 0001/arch/arm64/boot/dts/renesas/r8a77980.dtsi +++ work/arch/arm64/boot/dts/renesas/r8a77980.dtsi 2018-07-19 20:06:16.310607110 +0900 @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Device Tree Source for the r8a77980 SoC + * Device Tree Source for the R-Car V3H (R8A77980) SoC * * Copyright (C) 2018 Renesas Electronics Corp. * Copyright (C) 2018 Cogent Embedded, Inc. --- 0001/arch/arm64/boot/dts/renesas/r8a77990.dtsi +++ work/arch/arm64/boot/dts/renesas/r8a77990.dtsi 2018-07-19 20:06:58.970607110 +0900 @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0 */ /* - * Device Tree Source for the r8a77990 SoC + * Device Tree Source for the R-Car E3 (R8A77990) SoC * * Copyright (C) 2018 Renesas Electronics Corp. */ --- 0005/arch/arm64/boot/dts/renesas/r8a77995.dtsi +++ work/arch/arm64/boot/dts/renesas/r8a77995.dtsi 2018-07-19 20:07:20.150607110 +0900 @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Device Tree Source for the r8a77995 SoC + * Device Tree Source for the R-Car D3 (R8A77995) SoC * * Copyright (C) 2016 Renesas Electronics Corp. * Copyright (C) 2017 Glider bvba
Re: [PATCH] drivers/firmware: psci_checker: stash and use topology_core_cpumask for hotplug tests
On Wed, Jul 18, 2018 at 05:49:30PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Jul 18, 2018 at 12:25:32PM +0100, Sudeep Holla wrote:
> > Commit 7f9545aa1a91 ("arm64: smp: remove cpu and numa topology
> > information when hotplugging out CPU") updates the cpu topology when
> > the CPU is hotplugged out. However the PSCI checker code uses the
> > topology_core_cpumask pointers for some of the cpu hotplug testing.
> > Since the pointer to the core_cpumask of the first CPU in the group
> > is used, which when that CPU itself is hotpugged out is just set to
> > itself, the testing terminates after that particular CPU is tested out.
> > But the intention of this tests is to cover all the CPU in the group.
> >
> > In order to support that, we need to stash the topology_core_cpumask
> > before the start of the test and use that value instead of pointer to
> > a cpumask which will be updated on CPU hotplug.
> >
> > Fixes: 7f9545aa1a91a9a4 ("arm64: smp: remove cpu and numa topology
> > information when hotplugging out CPU")
> > Reported-by: Geert Uytterhoeven
> > Tested-by: Geert Uytterhoeven
> > Cc: Mark Rutland
> > Cc: Lorenzo Pieralisi
> > Signed-off-by: Sudeep Holla
> > ---
> > drivers/firmware/psci_checker.c | 30 --
> > 1 file changed, 20 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/firmware/psci_checker.c
> > b/drivers/firmware/psci_checker.c
> > index bb1c068bff19..e330c6cb45f5 100644
> > --- a/drivers/firmware/psci_checker.c
> > +++ b/drivers/firmware/psci_checker.c
> > @@ -77,21 +77,23 @@ static int psci_ops_check(void)
> > return 0;
> > }
> >
> > -static int find_cpu_groups(const struct cpumask *cpus,
> > - const struct cpumask **cpu_groups)
> > +static int find_cpu_groups(cpumask_var_t *cpu_groups)
> > {
> > unsigned int nb = 0;
> > cpumask_var_t tmp;
> >
> > if (!alloc_cpumask_var(, GFP_KERNEL))
> > return -ENOMEM;
> > - cpumask_copy(tmp, cpus);
> > + cpumask_copy(tmp, cpu_online_mask);
> >
> > while (!cpumask_empty(tmp)) {
> > const struct cpumask *cpu_group =
> > topology_core_cpumask(cpumask_any(tmp));
> >
> > - cpu_groups[nb++] = cpu_group;
> > + if (cpu_groups && cpu_groups[nb])
> > + cpumask_copy(cpu_groups[nb], cpu_group);
> > +
> > + nb++;
> > cpumask_andnot(tmp, tmp, cpu_group);
> > }
> >
> > @@ -169,25 +171,31 @@ static unsigned int down_and_up_cpus(const struct
> > cpumask *cpus,
> > static int hotplug_tests(void)
> > {
> > int err;
> > - cpumask_var_t offlined_cpus;
> > + cpumask_var_t offlined_cpus, *cpu_groups;
> > int i, nb_cpu_group;
> > - const struct cpumask **cpu_groups;
> > char *page_buf;
> >
> > + /* first run to just get the number of cpu groups */
> > + nb_cpu_group = find_cpu_groups(NULL);
> > +
> > err = -ENOMEM;
> > if (!alloc_cpumask_var(_cpus, GFP_KERNEL))
> > return err;
> > - /* We may have up to nb_available_cpus cpu_groups. */
> > - cpu_groups = kmalloc_array(nb_available_cpus, sizeof(*cpu_groups),
> > - GFP_KERNEL);
> > + cpu_groups = kcalloc(nb_cpu_group, sizeof(cpu_groups), GFP_KERNEL);
> > if (!cpu_groups)
> > goto out_free_cpus;
> > +
> > + for (i = 0; i < nb_cpu_group; ++i)
> > + if (!alloc_cpumask_var(_groups[i], GFP_KERNEL))
> > + goto out_free_cpu_groups;
> > +
> > page_buf = (char *)__get_free_page(GFP_KERNEL);
> > if (!page_buf)
> > goto out_free_cpu_groups;
> >
> > err = 0;
> > - nb_cpu_group = find_cpu_groups(cpu_online_mask, cpu_groups);
> > + /* second run to populate/copy the cpumask */
> > + nb_cpu_group = find_cpu_groups(cpu_groups);
> >
> > /*
> > * Of course the last CPU cannot be powered down and cpu_down() should
> > @@ -212,6 +220,8 @@ static int hotplug_tests(void)
> >
> > free_page((unsigned long)page_buf);
> > out_free_cpu_groups:
> > + for (i = 0; i < nb_cpu_group; ++i)
> > + free_cpumask_var(cpu_groups[i]);
> > kfree(cpu_groups);
> > out_free_cpus:
> > free_cpumask_var(offlined_cpus);
>
> Hi Sudeep,
>
> thanks for the patch. I reckon that adding two functions, say,
> alloc_cpu_groups() and free_cpu_groups() would make the code
> more readable instead of relying on find_cpu_groups() to first
> count then copy; it is for readability rather than correctness.
>
I agree, I can say I was lazy and started trying to keep delta small.
I will respin.
--
Regards,
Sudeep
Re: [PATCH 2/2] serial: sh-sci: Document r7s9210 bindings
Hi Chris,
On Thu, Jul 19, 2018 at 12:19 AM Chris Brandt wrote:
> On Tuesday, July 17, 2018, Geert Uytterhoeven wrote:
> > On Fri, Jul 13, 2018 at 5:50 PM Geert Uytterhoeven
> > wrote:
> > > On Wed, Jul 11, 2018 at 4:42 PM Chris Brandt
> > wrote:
> > > > Add R7S9210 (RZ/A2) support
> > > >
> > > > Signed-off-by: Chris Brandt
> > >
> > > Reviewed-by: Geert Uytterhoeven
> >
> > Sorry, I spoke too soon.
> > It seems the bindings were never updated for the use of multiple
> > interrupts
> > on RZ/A1. As RZ/A2 adds one new interrupt, can you please document which
> > interrupts are required?
> > Thanks!
>
> The issue that I ran into was the device driver assumed some signals
> were muxed together (TXI and DRI), and that other signals were individual.
>
> The existing driver wanted interrupts to be specified in this order:
> 1. Error
> 2. RX
> 3. TX (assumes DRI)
> 4. Break
Yes, that matches the RZ/A1 SCIFA and interrupt controller docs.
> However, for the SCIF that is present in the RZ/A2M, Error and Break are
> muxed together, and then DRI is not muxed with TX. This is different
> than any other SCIF supported by the driver.
Right, the RZ/A2 SCIFA variant is documented to provide 6 interrupt sources:
1. TEI,
2. TXI,
3. RXI,
4. DRI,
5. ERI,
6. BRI.
> My solution was to list the Error/Break twice, and then add a new
> interrupt for DRI.
>
> As reference, here is what the DT node would look like:
>
> scif0: serial@e8007000 {
> compatible = "renesas,scif-r7s9210", "renesas,scif";
> reg = <0xe8007000 18>;
> interrupts = , /* ERI0/BRI0
> */
> , /* RXI0 */
> , /* TXI0 */
> , /*
> ERI0/BRI0 */
> ; /* TEI/DRI0
> */
> clocks = <_clks R7S9210_CLK_SCIF0>;
> clock-names = "fck";
> power-domains = <_clocks>;
> status = "disabled";
> };
>
> Of course I have no problem documenting all this, but I first I just
> wanted to make sure I was not going to get push back when I submit a DT
> later that lists the same interrupt twice.
Listing them twice does make sense to me, as the interrupt controller
source list in the RZ/A2 docs has only four, and explicitly lists how they are
multiplexed:
base + 0 = ERI/BRI,
base + 1 = RXI,
base + 2 = TXI,
base + 3 = TEI/DRI.
But future SoCS with the same SCIFA variant may wire them differently?
For DT backwards compatibility, we have to keep support for the following
2 schemes:
1. Single "interrupts" value, no "interrupt-names", for fully multiplexed
interrupts (SH/R-Mobile, R-Car).
2. Four "interrupts" values, no "interrupt-names", for ERI/RXI/TXI/TEI
(RZ/A1, H8/300).
For RZ/A2, I suggest extending the bindings with interrupt-names,
documenting all 6 interrupt sources, and let the driver handle that.
That means there should be 6, not 5, "interrupts" values.
Whether the driver implements all possible combinations, or only what you
need for RZ/A2, is up to you. I agree the interrupt handling in the driver
is already sufficiently complex.
Ideally, you would document support for RZ/A1 with interrupt-names too,
and handle that as well.
Does this make sense?
Thanks!
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 v3 4/4] mmc: renesas_sdhi: skip SCC error check when retuning
On Wed, Jul 18, 2018 at 02:22:18PM +0200, Niklas Söderlund wrote:
> Hi Simon,
>
> On 2018-07-18 10:54:08 +0200, Simon Horman wrote:
> > Hi Niklas,
> >
> > On Tue, Jul 17, 2018 at 04:52:16PM +0200, Niklas Söderlund wrote:
> > > From: Masaharu Hayakawa
> > >
> > > Checking for SCC error during retuning is unnecessary.
> > >
> > > Signed-off-by: Masaharu Hayakawa
> > > [Niklas: fix small style issue]
> > > Signed-off-by: Niklas Söderlund
> > > Tested-by: Wolfram Sang
> > > Reviewed-by: Wolfram Sang
> > >
> > > ---
> > >
> > > * Changes since v2
> > > - Added check for HS400 as it's now merged.
> > > - Added tags from Wolfram.
> > > ---
> > > drivers/mmc/host/renesas_sdhi_core.c | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/mmc/host/renesas_sdhi_core.c
> > > b/drivers/mmc/host/renesas_sdhi_core.c
> > > index 777e32b0e410e850..a21b347424f67c52 100644
> > > --- a/drivers/mmc/host/renesas_sdhi_core.c
> > > +++ b/drivers/mmc/host/renesas_sdhi_core.c
> > > @@ -444,6 +444,14 @@ static bool renesas_sdhi_check_scc_error(struct
> > > tmio_mmc_host *host)
> > > {
> > > struct renesas_sdhi *priv = host_to_priv(host);
> > >
> > > + if (!(host->mmc->ios.timing == MMC_TIMING_UHS_SDR104) &&
> > > + !(host->mmc->ios.timing == MMC_TIMING_MMC_HS200) &&
> > > + !(host->mmc->ios.timing == MMC_TIMING_MMC_HS400))
> >
> > According to the BSP this needs to differentiate between 4tap and 8tap
> > variants of HS400 support.
>
> Ahh I see, yes it looks like this patch will require some work to update
> to HS400. I might break this out to a own patch so the rest of the
> patches in this series can progress as they fix other unrelated issues.
>
> Thanks for letting me know about this.
Of course breaking this patch out from the series is fine by me.
