RE: [PATCH 5/8] pinctrl: sh-pfc: r8a77995: Add EthernetAVB pins, groups and functions
Hi Geert-san,
> -Original Message-
> From: Yoshihiro Shimoda
> Sent: Wednesday, August 30, 2017 10:14 PM
>
> Hi Geert-san,
>
> Sorry, I also missed this email...
>
> > -Original Message-
> > From: Geert Uytterhoeven
> > Sent: Wednesday, August 16, 2017 8:06 PM
> >
> > Hi Shimoda-san, Kihara-san,
> >
> > On Wed, Aug 9, 2017 at 2:19 PM, Yoshihiro Shimoda
> > wrote:
> > > From: Takeshi Kihara
> > >
> > > Signed-off-by: Takeshi Kihara
> > > Signed-off-by: Yoshihiro Shimoda
> >
> > Reviewed-by: Geert Uytterhoeven
> >
> > But before I apply this, please see my question below...
> >
> > > --- a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
> > > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
> >
> > > +static const char * const avb0_groups[] = {
> > > + "avb0_td",
> > > + "avb0_rd",
> > > + "avb0_tx_ctl",
> > > + "avb0_rx_ctl",
> > > + "avb0_txc",
> > > + "avb0_rxc",
> > > + "avb0_txcrefclk",
> > > + "avb0_link",
> > > + "avb0_magic",
> > > + "avb0_phy_int",
> > > + "avb0_mdc",
> > > + "avb0_mdio",
> > > + "avb0_avtp_pps_a",
> > > + "avb0_avtp_match_a",
> > > + "avb0_avtp_capture_a",
> > > + "avb0_avtp_pps_b",
> > > + "avb0_avtp_match_b",
> > > + "avb0_avtp_capture_b",
> > > +};
> >
> > Is there any specific reason this uses a different split than the
> > EtherAVB groups
> > in pinctrl drivers for other SoCs?
>
> I will check this tomorrow (or later...).
I asked Kihara-san about this and he doesn't know other SoC (r8a7795) has mii
group.
So, I will modify the patch like r8a7795's group.
But...
> > Note that I do understand that the different prefix ("avb0" vs. "avb")
> > was used to
> > match the R-Car D3 datasheet, which is thus OK.
I checked this on the datasheet, but it seems error in it.
PFC section names "AVB0", but Ethernet AVB section names "AVB".
So, I'm asking hw team about this. After I got reply from them,
I will send v2 patch.
Best regards,
Yoshihiro Shimoda
> > 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: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table
Hello Geert,
On Wed, Aug 30, 2017 at 10:15 PM, Geert Uytterhoeven
wrote:
> Hi Javier,
>
> On Wed, Aug 30, 2017 at 9:57 PM, Javier Martinez Canillas
> wrote:
>>> I think we should talk about the same case: Let me repeat what I did:
>>>
>>> 1) I added your patch "eeprom: at24: Add OF device ID table"
>>> 2) I added an EEPROM node to an I2C
>>>
>>> + eeprom@50 {
>>> + compatible = "renesas,24c01";
>>> + reg = <0x50>;
>>> + };
>>>
>>> -> no at24 binding to the device
>>>
>>> 3) I revert your patch
>>>
>>> -> at24 binding to the device
>>>
>>
>> I've tested this and you are right, it fails...
>>
>> The problem is that the patch also changes how the driver obtains the
>> EEPROM parameters (the magic value in the entry's data field).
>>
>> So even when module autoload and device / driver matching works, the
>> driver probe function fails because if (client->dev.of_node) the
>> driver attempts to get the entry data using
>> of_device_get_match_data(), which is obviously wrong since the
>> compatible string in the dev node isn't present in the OF table.
>>
>> The id->driver_data from the I2C table should be used instead since
>> that's the table that matches in this case.
>>
>> One option is to fallback to id->driver_data if
>> of_device_get_match_data() fails, but that's just an (ugly)
>> workaround. So I agree with you that the best option is to wait for
>> the DTS patches to land first.
>
> Which means new kernels won't work with old DTBs. Oops...
> I'm afraid that needs to be fixed. People care about DTB backward
> compatibility on many platforms.
>
Right, I've yet to find one of those mythical platforms that ship old
DTBs with new kernels, but I agree with you since people seem to care
about backward compatibility (at least on theory).
So I see two options then:
1) Use the workaround I mentioned and lookup the I2C device ID table
entry data if of_device_get_match_data() fails
2) Only call of_device_get_match_data() if (dev->of_node &&
of_match_device(dev->driver->of_match_table, dev))
Not sure what's the preferred idiom for these cases.
To good thing about keeping backward compatibility is that Wolfram
would be able to pick the driver patch even before the DTS patches
land.
Best regards,
Javier
Re: [PATCH 2/4] arm: dts: exynos: add exynos5420 cpu capacity-dmips-mhz information
On Wed, Aug 30, 2017 at 03:41:18PM +0100, Dietmar Eggemann wrote:
> The following 'capacity-dmips-mhz' dt property values are used:
>
> Cortex-A15: 1024, Cortex-A7: 539
>
> They have been derived from the cpu_efficiency values:
>
> Cortex-A15: 3891, Cortex-A7: 2048
>
> by scaling them so that the Cortex-A15s (big cores) use 1024.
>
> The cpu_efficiency values were originally derived from the "Big.LITTLE
> Processing with ARM Cortex™-A15 & Cortex-A7" white paper
> (http://www.cl.cam.ac.uk/~rdm34/big.LITTLE.pdf). Table 1 lists 1.9x
> (3891/2048) as the Cortex-A15 vs Cortex-A7 performance ratio for the
> Dhrystone benchmark.
>
> The following platforms are affected once cpu-invariant accounting
> support is re-connected to the task scheduler:
>
> arndale-octa, peach-pi, peach-pit, smdk5420
>
> The patch has been tested on Samsung Chromebook 2 13" (peach-pi, Exynos
> 5800).
>
> $ cat /sys/devices/system/cpu/cpu*/cpu_capacity
> 1024
> 1024
> 1024
> 1024
> 389
> 389
> 389
> 389
I am missing something... shouldn't this be 539? Or is it scaled with
the clock-frequency (1 GHz) value?
Best regards,
Krzysztof
>
> The Cortex-A15 vs Cortex-A7 performance ratio is 1024/389 = 2.63.
>
> The values derived with the 'cpu_efficiency/clock-frequency dt property'
> solution are:
>
> $ cat /sys/devices/system/cpu/cpu*/cpu_capacity
> 1535
> 1535
> 1535
> 1535
> 448
> 448
> 448
> 448
>
> The Cortex-A15 vs Cortex-A7 performance ratio is 1535/448 = 3.43.
>
> The discrepancy between 2.63 and 3.43 is due to the false assumption
> when using the 'cpu_efficiency/clock-frequency dt property' solution
> that the max cpu frequency of the little cpus is 1 GHZ and not 1.3 GHz.
> The Cortex-A7 cluster runs with a max cpu frequency of 1.3 GHZ whereas
> the 'clock-frequency' property value is set to 1 GHz.
>
> 3.43/1.3 = 2.64
>
> $ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
> 180
> 180
> 180
> 180
> 130 <-- max cpu frequency of the Cortex-A7s (little cores)
> 130
> 130
> 130
>
> Running another benchmark (single-threaded sysbench affine to the
> individual cpus) with performance cpufreq governor on the Samsung
> Chromebook 2 13" showed the following numbers:
>
> $ for i in `seq 0 7`; do taskset -c $i sysbench --test=cpu
> --num-threads=1 --max-time=10 run | grep "total number of events:";
> done
>
> total number of events: 1083
> total number of events: 1085
> total number of events: 1085
> total number of events: 1085
> total number of events: 454
> total number of events: 454
> total number of events: 454
> total number of events: 454
>
> The Cortex-A15 vs Cortex-A7 performance ratio is 2.39, i.e. very close
> to the one derived from the Dhrystone based one of the "Big.LITTLE
> Processing with ARM Cortex™-A15 & Cortex-A7" white paper (2.63).
>
> We don't aim for exact values for the cpu capacity values. Besides the
> CPI (Cycles Per Instruction), the instruction mix and whether the system
> runs cpu-bound or memory-bound has an impact on the cpu capacity values
> derived from these benchmark results.
>
> Cc: Rob Herring
> Cc: Mark Rutland
> Cc: Russell King
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Signed-off-by: Dietmar Eggemann
> ---
> arch/arm/boot/dts/exynos5420-cpus.dtsi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi
> b/arch/arm/boot/dts/exynos5420-cpus.dtsi
> index 5c052d7ff554..d7d703aa1699 100644
> --- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
> +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
> @@ -36,6 +36,7 @@
> cooling-min-level = <0>;
> cooling-max-level = <11>;
> #cooling-cells = <2>; /* min followed by max */
> + capacity-dmips-mhz = <1024>;
> };
>
> cpu1: cpu@1 {
> @@ -48,6 +49,7 @@
> cooling-min-level = <0>;
> cooling-max-level = <11>;
> #cooling-cells = <2>; /* min followed by max */
> + capacity-dmips-mhz = <1024>;
> };
>
> cpu2: cpu@2 {
> @@ -60,6 +62,7 @@
> cooling-min-level = <0>;
> cooling-max-level = <11>;
> #cooling-cells = <2>; /* min followed by max */
> + capacity-dmips-mhz = <1024>;
> };
>
> cpu3: cpu@3 {
> @@ -72,6 +75,7 @@
> cooling-min-level = <0>;
> cooling-max-level = <11>;
> #cooling-cells = <2>; /* min followed by max */
> + capacity-dmips-mhz = <1024>;
> };
>
> cpu4: cpu@100 {
> @@ -85,6 +89,7 @@
> cooling-min-level = <0>;
> cooling-max-level = <7>;
> #cooling-cells = <2>; /* min followed by max */
> + capacity-dmips-mhz = <5
Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table
Hi Javier,
On Wed, Aug 30, 2017 at 9:57 PM, Javier Martinez Canillas
wrote:
>> I think we should talk about the same case: Let me repeat what I did:
>>
>> 1) I added your patch "eeprom: at24: Add OF device ID table"
>> 2) I added an EEPROM node to an I2C
>>
>> + eeprom@50 {
>> + compatible = "renesas,24c01";
>> + reg = <0x50>;
>> + };
>>
>> -> no at24 binding to the device
>>
>> 3) I revert your patch
>>
>> -> at24 binding to the device
>>
>
> I've tested this and you are right, it fails...
>
> The problem is that the patch also changes how the driver obtains the
> EEPROM parameters (the magic value in the entry's data field).
>
> So even when module autoload and device / driver matching works, the
> driver probe function fails because if (client->dev.of_node) the
> driver attempts to get the entry data using
> of_device_get_match_data(), which is obviously wrong since the
> compatible string in the dev node isn't present in the OF table.
>
> The id->driver_data from the I2C table should be used instead since
> that's the table that matches in this case.
>
> One option is to fallback to id->driver_data if
> of_device_get_match_data() fails, but that's just an (ugly)
> workaround. So I agree with you that the best option is to wait for
> the DTS patches to land first.
Which means new kernels won't work with old DTBs. Oops...
I'm afraid that needs to be fixed. People care about DTB backward
compatibility on many platforms.
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: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table
>
> I think we should talk about the same case: Let me repeat what I did:
>
> 1) I added your patch "eeprom: at24: Add OF device ID table"
> 2) I added an EEPROM node to an I2C
>
> + eeprom@50 {
> + compatible = "renesas,24c01";
> + reg = <0x50>;
> + };
>
> -> no at24 binding to the device
>
> 3) I revert your patch
>
> -> at24 binding to the device
>
I've tested this and you are right, it fails...
The problem is that the patch also changes how the driver obtains the
EEPROM parameters (the magic value in the entry's data field).
So even when module autoload and device / driver matching works, the
driver probe function fails because if (client->dev.of_node) the
driver attempts to get the entry data using
of_device_get_match_data(), which is obviously wrong since the
compatible string in the dev node isn't present in the OF table.
The id->driver_data from the I2C table should be used instead since
that's the table that matches in this case.
One option is to fallback to id->driver_data if
of_device_get_match_data() fails, but that's just an (ugly)
workaround. So I agree with you that the best option is to wait for
the DTS patches to land first.
It worked for me on my previous tests because the tested drivers
didn't use a table entry data, I'm so sorry for missing this :(
Best regards,
Javier
Re: [PATCH ] PCI: rcar: Add r8a7743/5 support
On Thu, Aug 24, 2017 at 10:35:44AM +0100, Biju Das wrote: > Add internal PCI bridge support for r8a7743/5 SoC. Renesas RZ/G1[ME] > (R8A7743/5) internal PCI bridge is identical to the R-Car Gen2 family. > > Signed-off-by: Biju Das Applied with Simon's ack to pci/host-rcar, thanks! > --- > This patch is tested against Linux next tag next-20170824 and > renesas-dev branch renesas-devel-20170822-v4.13-rc6. > > Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt > b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt > index 07a7509..3d03863 100644 > --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt > +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt > @@ -6,11 +6,14 @@ AHB. There is one bridge instance per USB port connected to > the internal > OHCI and EHCI controllers. > > Required properties: > -- compatible: "renesas,pci-r8a7790" for the R8A7790 SoC; > +- compatible: "renesas,pci-r8a7743" for the R8A7743 SoC; > + "renesas,pci-r8a7745" for the R8A7745 SoC; > + "renesas,pci-r8a7790" for the R8A7790 SoC; > "renesas,pci-r8a7791" for the R8A7791 SoC; > "renesas,pci-r8a7793" for the R8A7793 SoC; > "renesas,pci-r8a7794" for the R8A7794 SoC; > - "renesas,pci-rcar-gen2" for a generic R-Car Gen2 compatible device > + "renesas,pci-rcar-gen2" for a generic R-Car Gen2 or > + RZ/G1 compatible device. > > > When compatible with the generic version, nodes must list the > -- > 1.9.1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table
On Wed, Aug 30, 2017 at 06:19:02PM +0200, Javier Martinez Canillas wrote:
> Hello Wolfram,
>
> On Tue, Aug 29, 2017 at 10:48 AM, Wolfram Sang wrote:
> >
> >> I don't have a DT based system at hand now, but I'll test it again and
> >> let you know probably tomorrow.
> >
> > I will try again today, too. Thanks!
> >
>
> Ok, I had some time to do some tests again. I used an ARM Chromebook
> (Exynos Peach Pi) that has an I2C touchpad (Atmel maXTouch).
I tried again as well and it still fails for me.
> Tested the following cases:
I think we should talk about the same case: Let me repeat what I did:
1) I added your patch "eeprom: at24: Add OF device ID table"
2) I added an EEPROM node to an I2C
+ eeprom@50 {
+ compatible = "renesas,24c01";
+ reg = <0x50>;
+ };
-> no at24 binding to the device
3) I revert your patch
-> at24 binding to the device
I think you should be able to test this DTS snipplet even without a real
eeprom. Especially after applying this to the at24 driver.
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 79c5c39be29cac..f9f547680c53db 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -805,11 +805,6 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
* Perform a one-byte test read to verify that the
* chip is functional.
*/
- err = at24_read(at24, 0, &test_byte, 1);
- if (err) {
- err = -ENODEV;
- goto err_clients;
- }
at24->nvmem_config.name = dev_name(&client->dev);
at24->nvmem_config.dev = &client->dev;
Can you check this?
Thanks,
Wolfram
signature.asc
Description: PGP signature
Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table
Hello Wolfram, On Tue, Aug 29, 2017 at 10:48 AM, Wolfram Sang wrote: > >> I don't have a DT based system at hand now, but I'll test it again and >> let you know probably tomorrow. > > I will try again today, too. Thanks! > Ok, I had some time to do some tests again. I used an ARM Chromebook (Exynos Peach Pi) that has an I2C touchpad (Atmel maXTouch). Tested the following cases: 1) Driver without OF device ID table (only a I2C table with a "maxtouch" entry) and DTS defining a device node with a "atmel,maxtouch" compatible string. This is the case without any of the patches in this series. $ modinfo drivers/input/touchscreen/atmel_mxt_ts.ko | grep maxtouch alias: i2c:maxtouch $ grep maxtouch /sys/devices/platform/soc/12e0.i2c/i2c-8/8-004b/uevent OF_COMPATIBLE_0=atmel,maxtouch MODALIAS=i2c:maxtouch 2) Driver without OF device ID table (only a I2C table with a "maxtouch" entry) and DTS defining a device node with a "atmel,maxtouch", "generic,maxtouch" compatible string. This is the case when platform maintainers merge the DTS patches without the driver patch. $ modinfo drivers/input/touchscreen/atmel_mxt_ts.ko | grep maxtouch alias: i2c:maxtouch $ grep maxtouch /sys/devices/platform/soc/12e0.i2c/i2c-8/8-004b/uevent OF_COMPATIBLE_0=atmel,maxtouch OF_COMPATIBLE_1=generic,maxtouch MODALIAS=i2c:maxtouch 3) Driver with an OF device ID table (with a "generic,maxtouch" entry) and DTS defining a device node with a "atmel,maxtouch" compatible string. This is the case when the driver patch is merged without the DTS patches. $ modinfo drivers/input/touchscreen/atmel_mxt_ts.ko | grep maxtouch alias: of:N*T*Cgeneric,maxtouchC* alias: of:N*T*Cgeneric,maxtouch alias: i2c:maxtouch $ grep maxtouch /sys/devices/platform/soc/12e0.i2c/i2c-8/8-004b/uevent OF_COMPATIBLE_0=atmel,maxtouch MODALIAS=i2c:maxtouch 4) Driver with an OF device ID table (with a "generic,maxtouch" entry) and DTS defining a device node with a "atmel,maxtouch", "generic,maxtouch" compatible string. This is the case when both the DTS and driver patches are merged. $ modinfo drivers/input/touchscreen/atmel_mxt_ts.ko | grep maxtouch alias: of:N*T*Cgeneric,maxtouchC* alias: of:N*T*Cgeneric,maxtouch alias: i2c:maxtouch $ grep maxtouch /sys/devices/platform/soc/12e0.i2c/i2c-8/8-004b/uevent OF_COMPATIBLE_0=atmel,maxtouch OF_COMPATIBLE_1=generic,maxtouch MODALIAS=i2c:maxtouch For all cases module autoload, driver probe and evtest worked for me. You said that (3) doesn't work but I don't understand why is failing for you. Probably I'm missing something. Best regards, Javier
Re: [PATCH v2 3/3] ARM: dts: r7s72100: Add reset handler
On Wed, Aug 30, 2017 at 01:22:32PM +, Chris Brandt wrote: > Hi Simon, > > On Wednesday, August 30, 2017, Simon Horman wrote: > > On Fri, Feb 17, 2017 at 11:29:25AM +0100, Geert Uytterhoeven wrote: > > > On Thu, Feb 16, 2017 at 6:23 PM, Chris Brandt > > wrote: > > > > For the RZ/A1, the only way to do a reset is to overflow the WDT. > > > > > > > > Signed-off-by: Chris Brandt > > > > > > Reviewed-by: Geert Uytterhoeven > > > > Hi Chris, > > > > while going through old patches I noticed that I seem to have missed this > > one. It looks like it needs a rebase. If it is still applicable could you > > please consider doing so and reposting. > > > It's in -next already: > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/r7s72100.dtsi?h=next-20170829&id=69ed50de582eff6307fd3fa050fdc505731f0a2d > > Doesn't that mean it's queued up for 4.14? > > Or, somehow it didn't make it into the pull request for Arnd's tree? Thanks, I now see that it is included in v4.12. Sorry for the noise.
[PATCH ] ARM: dts: iwg22d-sodimm: Add Ethernet AVB support
Define the iWave RainboW-G22D board dependent part of the Ethernet
AVB device node.
On some older versions of the platform (before R4.0) the phy address
may be 1 or 3. The address is fixed to 3 for R4.0 onwards (which
will be the first mainstream release), hence using 3 in the dts.
Signed-off-by: Biju Das
Signed-off-by: Chris Paterson
---
This patch is tested against renesas-dev tag 20170830-v4.13-rc7
arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
index 442a5cb..aac84c6 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
+++ b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
@@ -17,9 +17,11 @@
aliases {
serial0 = &scif4;
+ ethernet0 = &avb;
};
chosen {
+ bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
stdout-path = "serial0:115200n8";
};
};
@@ -29,6 +31,11 @@
groups = "scif4_data_b";
function = "scif4";
};
+
+ avb_pins: avb {
+ groups = "avb_mdio", "avb_gmii";
+ function = "avb";
+ };
};
&scif4 {
@@ -37,3 +44,22 @@
status = "okay";
};
+
+&avb {
+ pinctrl-0 = <&avb_pins>;
+ pinctrl-names = "default";
+
+ phy-handle = <&phy3>;
+ phy-mode = "gmii";
+ renesas,no-ether-link;
+ status = "okay";
+
+ phy3: ethernet-phy@3 {
+ /*
+* On some older versions of the platform (before R4.0) the phy address
+* may be 1 or 3. The address is fixed to 3 for R4.0 onwards.
+*/
+ reg = <3>;
+ micrel,led-mode = <1>;
+ };
+};
--
1.9.1
Applied "ASoC: rsnd: Drop unit-addresses without reg properties" to the asoc tree
The patch
ASoC: rsnd: Drop unit-addresses without reg properties
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From a5702e1cb3c47221419617089d59f9741cf981e4 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven
Date: Wed, 30 Aug 2017 12:01:06 +0200
Subject: [PATCH] ASoC: rsnd: Drop unit-addresses without reg properties
Nodes without reg properties must not have unit addresses:
Warning (unit_address_vs_reg): Node .../rcar_sound,dvc/dvc@0 has a unit
name, but no reg property
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Mark Brown
---
.../devicetree/bindings/sound/renesas,rsnd.txt | 68 +++---
1 file changed, 34 insertions(+), 34 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
index 7246bb268bf9..a1536fdc60e6 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
@@ -199,10 +199,10 @@ Ex)
sound {
compatible = "simple-scu-audio-card";
...
- simple-audio-card,cpu@0 {
+ simple-audio-card,cpu-0 {
sound-dai = <&rcar_sound 0>;
};
- simple-audio-card,cpu@1 {
+ simple-audio-card,cpu-1 {
sound-dai = <&rcar_sound 1>;
};
simple-audio-card,codec {
@@ -441,79 +441,79 @@ rcar_sound: sound@ec50 {
"clk_a", "clk_b", "clk_c", "clk_i";
rcar_sound,dvc {
- dvc0: dvc@0 {
+ dvc0: dvc-0 {
dmas = <&audma0 0xbc>;
dma-names = "tx";
};
- dvc1: dvc@1 {
+ dvc1: dvc-1 {
dmas = <&audma0 0xbe>;
dma-names = "tx";
};
};
rcar_sound,mix {
- mix0: mix@0 { };
- mix1: mix@1 { };
+ mix0: mix-0 { };
+ mix1: mix-1 { };
};
rcar_sound,ctu {
- ctu00: ctu@0 { };
- ctu01: ctu@1 { };
- ctu02: ctu@2 { };
- ctu03: ctu@3 { };
- ctu10: ctu@4 { };
- ctu11: ctu@5 { };
- ctu12: ctu@6 { };
- ctu13: ctu@7 { };
+ ctu00: ctu-0 { };
+ ctu01: ctu-1 { };
+ ctu02: ctu-2 { };
+ ctu03: ctu-3 { };
+ ctu10: ctu-4 { };
+ ctu11: ctu-5 { };
+ ctu12: ctu-6 { };
+ ctu13: ctu-7 { };
};
rcar_sound,src {
- src0: src@0 {
+ src0: src-0 {
interrupts = <0 352 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x85>, <&audma1 0x9a>;
dma-names = "rx", "tx";
};
- src1: src@1 {
+ src1: src-1 {
interrupts = <0 353 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x87>, <&audma1 0x9c>;
dma-names = "rx", "tx";
};
- src2: src@2 {
+ src2: src-2 {
interrupts = <0 354 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x89>, <&audma1 0x9e>;
dma-names = "rx", "tx";
};
- src3: src@3 {
+ src3: src-3 {
interrupts = <0 355 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x8b>, <&audma1 0xa0>;
dma-names = "rx", "tx";
};
- src4: src@4 {
+ src4: src-4 {
interrupts = <0 356 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x8d>, <&audma1 0xb0>;
dma-names = "rx", "tx";
};
- src5: src@5 {
+ src5: src-5 {
interrupts = <0 357 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x8f>, <&
Re: [PATCH 0/3] vsp-tests: Add BRS test
For the series, On Salvator-XS (with minor kernel change to enable .uapi on VSPD entities) root@Ubuntu-ARM64:~/vsp-tests# ./vsp-unit-test-0024.sh Testing BRS in RGB24 with 1 inputs: pass Testing BRS in RGB24 with 2 inputs: pass Testing BRS in YUV444M with 1 inputs: pass Testing BRS in YUV444M with 2 inputs: pass root@Ubuntu-ARM64:~/vsp-tests# Tested-by: Kieran Bingham -- Regards Kieran Interestingly as a side note, while on the Salvator-XS, I ran test-0003 and it went straight through 4 times consecutively! root@Ubuntu-ARM64:~/vsp-tests# ./vsp-unit-test-0003.sh Testing scaling from 640x640 to 640x480 in RGB24: pass Testing scaling from 1024x768 to 640x480 in RGB24: pass Testing scaling from 640x480 to 1024x768 in RGB24: pass Testing scaling from 640x640 to 640x480 in YUV444M: pass Testing scaling from 1024x768 to 640x480 in YUV444M: pass Testing scaling from 640x480 to 1024x768 in YUV444M: pass On 24/08/17 10:30, Laurent Pinchart wrote: > Hello, > > This patch series adds a test to the VSP unit test suite for the BRS module. > > The BRS is the Blend/ROP Secondary unit, a stripped-down version of the BRU > that supports two inputs only. It is present in some VSPD instances, in > particular on the H3 ES2.0. > > As the VSPD is used for display pipelines only the BRS can't be tested through > the V4L2 API with the upstream VSP driver. A simple hack that exposes the VSPD > through V4L2 is needed. > > Laurent Pinchart (3): > vsp-lib: Use the correct media device name to count BRU inputs > vsp-lib: Add support for RPF-BRS-WPF pipelines > tests: Add BRS test > > scripts/vsp-lib.sh | 63 > +++-- > tests/vsp-unit-test-0024.sh | 45 > 2 files changed, 88 insertions(+), 20 deletions(-) > create mode 100755 tests/vsp-unit-test-0024.sh >
[PATCH 1/4] arm: topology: remove cpu_efficiency
Remove the 'cpu_efficiency/clock-frequency dt property' based solution
to set cpu capacity which was only working for Cortex-A15/A7 arm
big.LITTLE systems.
I.e. the 'capacity-dmips-mhz' based solution is now the only one. It is
shared between arm and arm64 and works for every big.LITTLE system no
matter which core types it consists of.
Cc: Russell King
Cc: Vincent Guittot
Cc: Juri Lelli
Signed-off-by: Dietmar Eggemann
---
arch/arm/kernel/topology.c | 113 ++---
1 file changed, 3 insertions(+), 110 deletions(-)
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index bf949a763dbe..04ccfdd94213 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -47,52 +47,10 @@
*/
#ifdef CONFIG_OF
-struct cpu_efficiency {
- const char *compatible;
- unsigned long efficiency;
-};
-
-/*
- * Table of relative efficiency of each processors
- * The efficiency value must fit in 20bit and the final
- * cpu_scale value must be in the range
- * 0 < cpu_scale < 3*SCHED_CAPACITY_SCALE/2
- * in order to return at most 1 when DIV_ROUND_CLOSEST
- * is used to compute the capacity of a CPU.
- * Processors that are not defined in the table,
- * use the default SCHED_CAPACITY_SCALE value for cpu_scale.
- */
-static const struct cpu_efficiency table_efficiency[] = {
- {"arm,cortex-a15", 3891},
- {"arm,cortex-a7", 2048},
- {NULL, },
-};
-
-static unsigned long *__cpu_capacity;
-#define cpu_capacity(cpu) __cpu_capacity[cpu]
-
-static unsigned long middle_capacity = 1;
-static bool cap_from_dt = true;
-
-/*
- * Iterate all CPUs' descriptor in DT and compute the efficiency
- * (as per table_efficiency). Also calculate a middle efficiency
- * as close as possible to (max{eff_i} - min{eff_i}) / 2
- * This is later used to scale the cpu_capacity field such that an
- * 'average' CPU is of middle capacity. Also see the comments near
- * table_efficiency[] and update_cpu_capacity().
- */
static void __init parse_dt_topology(void)
{
- const struct cpu_efficiency *cpu_eff;
- struct device_node *cn = NULL;
- unsigned long min_capacity = ULONG_MAX;
- unsigned long max_capacity = 0;
- unsigned long capacity = 0;
- int cpu = 0;
-
- __cpu_capacity = kcalloc(nr_cpu_ids, sizeof(*__cpu_capacity),
-GFP_NOWAIT);
+ struct device_node *cn;
+ int cpu;
cn = of_find_node_by_path("/cpus");
if (!cn) {
@@ -101,9 +59,6 @@ static void __init parse_dt_topology(void)
}
for_each_possible_cpu(cpu) {
- const u32 *rate;
- int len;
-
/* too early to use cpu->of_node */
cn = of_get_cpu_node(cpu, NULL);
if (!cn) {
@@ -115,73 +70,13 @@ static void __init parse_dt_topology(void)
of_node_put(cn);
continue;
}
-
- cap_from_dt = false;
-
- for (cpu_eff = table_efficiency; cpu_eff->compatible; cpu_eff++)
- if (of_device_is_compatible(cn, cpu_eff->compatible))
- break;
-
- if (cpu_eff->compatible == NULL)
- continue;
-
- rate = of_get_property(cn, "clock-frequency", &len);
- if (!rate || len != 4) {
- pr_err("%s missing clock-frequency property\n",
- cn->full_name);
- continue;
- }
-
- capacity = ((be32_to_cpup(rate)) >> 20) * cpu_eff->efficiency;
-
- /* Save min capacity of the system */
- if (capacity < min_capacity)
- min_capacity = capacity;
-
- /* Save max capacity of the system */
- if (capacity > max_capacity)
- max_capacity = capacity;
-
- cpu_capacity(cpu) = capacity;
}
- /* If min and max capacities are equals, we bypass the update of the
-* cpu_scale because all CPUs have the same capacity. Otherwise, we
-* compute a middle_capacity factor that will ensure that the capacity
-* of an 'average' CPU of the system will be as close as possible to
-* SCHED_CAPACITY_SCALE, which is the default value, but with the
-* constraint explained near table_efficiency[].
-*/
- if (4*max_capacity < (3*(max_capacity + min_capacity)))
- middle_capacity = (min_capacity + max_capacity)
- >> (SCHED_CAPACITY_SHIFT+1);
- else
- middle_capacity = ((max_capacity / 3)
- >> (SCHED_CAPACITY_SHIFT-1)) + 1;
-
- if (cap_from_dt)
- topology_normalize_cpu_scale();
-}
-
-/*
- * Look for a customed capacity of a CPU in the cpu_capacity table during the
- * boot. The update of all CPUs is in
[PATCH 2/4] arm: dts: exynos: add exynos5420 cpu capacity-dmips-mhz information
The following 'capacity-dmips-mhz' dt property values are used:
Cortex-A15: 1024, Cortex-A7: 539
They have been derived from the cpu_efficiency values:
Cortex-A15: 3891, Cortex-A7: 2048
by scaling them so that the Cortex-A15s (big cores) use 1024.
The cpu_efficiency values were originally derived from the "Big.LITTLE
Processing with ARM Cortex™-A15 & Cortex-A7" white paper
(http://www.cl.cam.ac.uk/~rdm34/big.LITTLE.pdf). Table 1 lists 1.9x
(3891/2048) as the Cortex-A15 vs Cortex-A7 performance ratio for the
Dhrystone benchmark.
The following platforms are affected once cpu-invariant accounting
support is re-connected to the task scheduler:
arndale-octa, peach-pi, peach-pit, smdk5420
The patch has been tested on Samsung Chromebook 2 13" (peach-pi, Exynos
5800).
$ cat /sys/devices/system/cpu/cpu*/cpu_capacity
1024
1024
1024
1024
389
389
389
389
The Cortex-A15 vs Cortex-A7 performance ratio is 1024/389 = 2.63.
The values derived with the 'cpu_efficiency/clock-frequency dt property'
solution are:
$ cat /sys/devices/system/cpu/cpu*/cpu_capacity
1535
1535
1535
1535
448
448
448
448
The Cortex-A15 vs Cortex-A7 performance ratio is 1535/448 = 3.43.
The discrepancy between 2.63 and 3.43 is due to the false assumption
when using the 'cpu_efficiency/clock-frequency dt property' solution
that the max cpu frequency of the little cpus is 1 GHZ and not 1.3 GHz.
The Cortex-A7 cluster runs with a max cpu frequency of 1.3 GHZ whereas
the 'clock-frequency' property value is set to 1 GHz.
3.43/1.3 = 2.64
$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
180
180
180
180
130 <-- max cpu frequency of the Cortex-A7s (little cores)
130
130
130
Running another benchmark (single-threaded sysbench affine to the
individual cpus) with performance cpufreq governor on the Samsung
Chromebook 2 13" showed the following numbers:
$ for i in `seq 0 7`; do taskset -c $i sysbench --test=cpu
--num-threads=1 --max-time=10 run | grep "total number of events:";
done
total number of events: 1083
total number of events: 1085
total number of events: 1085
total number of events: 1085
total number of events: 454
total number of events: 454
total number of events: 454
total number of events: 454
The Cortex-A15 vs Cortex-A7 performance ratio is 2.39, i.e. very close
to the one derived from the Dhrystone based one of the "Big.LITTLE
Processing with ARM Cortex™-A15 & Cortex-A7" white paper (2.63).
We don't aim for exact values for the cpu capacity values. Besides the
CPI (Cycles Per Instruction), the instruction mix and whether the system
runs cpu-bound or memory-bound has an impact on the cpu capacity values
derived from these benchmark results.
Cc: Rob Herring
Cc: Mark Rutland
Cc: Russell King
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Signed-off-by: Dietmar Eggemann
---
arch/arm/boot/dts/exynos5420-cpus.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi
b/arch/arm/boot/dts/exynos5420-cpus.dtsi
index 5c052d7ff554..d7d703aa1699 100644
--- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
@@ -36,6 +36,7 @@
cooling-min-level = <0>;
cooling-max-level = <11>;
#cooling-cells = <2>; /* min followed by max */
+ capacity-dmips-mhz = <1024>;
};
cpu1: cpu@1 {
@@ -48,6 +49,7 @@
cooling-min-level = <0>;
cooling-max-level = <11>;
#cooling-cells = <2>; /* min followed by max */
+ capacity-dmips-mhz = <1024>;
};
cpu2: cpu@2 {
@@ -60,6 +62,7 @@
cooling-min-level = <0>;
cooling-max-level = <11>;
#cooling-cells = <2>; /* min followed by max */
+ capacity-dmips-mhz = <1024>;
};
cpu3: cpu@3 {
@@ -72,6 +75,7 @@
cooling-min-level = <0>;
cooling-max-level = <11>;
#cooling-cells = <2>; /* min followed by max */
+ capacity-dmips-mhz = <1024>;
};
cpu4: cpu@100 {
@@ -85,6 +89,7 @@
cooling-min-level = <0>;
cooling-max-level = <7>;
#cooling-cells = <2>; /* min followed by max */
+ capacity-dmips-mhz = <539>;
};
cpu5: cpu@101 {
@@ -97,6 +102,7 @@
cooling-min-level = <0>;
cooling-max-level = <7>;
#cooling-cells = <2>; /* min followed by max */
+ capacity-dmips-mhz = <539>;
};
cpu6: cpu@102 {
@@ -109,6 +115,7 @@
cooling-min-level = <0>;
[PATCH 3/4] arm: dts: exynos: add exynos5422 cpu capacity-dmips-mhz information
The following 'capacity-dmips-mhz' dt property values are used:
Cortex-A15: 1024, Cortex-A7: 539
They have been derived form the cpu_efficiency values:
Cortex-A15: 3891, Cortex-A7: 2048
by scaling them so that the Cortex-A15s (big cores) use 1024.
The cpu_efficiency values were originally derived from the "Big.LITTLE
Processing with ARM Cortex™-A15 & Cortex-A7" white paper
(http://www.cl.cam.ac.uk/~rdm34/big.LITTLE.pdf). Table 1 lists 1.9x
(3891/2048) as the Cortex-A15 vs Cortex-A7 performance ratio for the
Dhrystone benchmark.
The following platforms are affected once cpu-invariant accounting
support is re-connected to the task scheduler:
odroidxu3, odroidxu3-lite, odroidxu4
Cc: Rob Herring
Cc: Mark Rutland
Cc: Russell King
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Signed-off-by: Dietmar Eggemann
---
arch/arm/boot/dts/exynos5422-cpus.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi
b/arch/arm/boot/dts/exynos5422-cpus.dtsi
index bf3c6f1ec4ee..ec01d8020c2d 100644
--- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
@@ -35,6 +35,7 @@
cooling-min-level = <0>;
cooling-max-level = <11>;
#cooling-cells = <2>; /* min followed by max */
+ capacity-dmips-mhz = <539>;
};
cpu1: cpu@101 {
@@ -47,6 +48,7 @@
cooling-min-level = <0>;
cooling-max-level = <11>;
#cooling-cells = <2>; /* min followed by max */
+ capacity-dmips-mhz = <539>;
};
cpu2: cpu@102 {
@@ -59,6 +61,7 @@
cooling-min-level = <0>;
cooling-max-level = <11>;
#cooling-cells = <2>; /* min followed by max */
+ capacity-dmips-mhz = <539>;
};
cpu3: cpu@103 {
@@ -71,6 +74,7 @@
cooling-min-level = <0>;
cooling-max-level = <11>;
#cooling-cells = <2>; /* min followed by max */
+ capacity-dmips-mhz = <539>;
};
cpu4: cpu@0 {
@@ -84,6 +88,7 @@
cooling-min-level = <0>;
cooling-max-level = <15>;
#cooling-cells = <2>; /* min followed by max */
+ capacity-dmips-mhz = <1024>;
};
cpu5: cpu@1 {
@@ -96,6 +101,7 @@
cooling-min-level = <0>;
cooling-max-level = <15>;
#cooling-cells = <2>; /* min followed by max */
+ capacity-dmips-mhz = <1024>;
};
cpu6: cpu@2 {
@@ -108,6 +114,7 @@
cooling-min-level = <0>;
cooling-max-level = <15>;
#cooling-cells = <2>; /* min followed by max */
+ capacity-dmips-mhz = <1024>;
};
cpu7: cpu@3 {
@@ -120,6 +127,7 @@
cooling-min-level = <0>;
cooling-max-level = <15>;
#cooling-cells = <2>; /* min followed by max */
+ capacity-dmips-mhz = <1024>;
};
};
};
--
2.11.0
[PATCH 4/4] arm: dts: r8a7790: add cpu capacity-dmips-mhz information
The following 'capacity-dmips-mhz' dt property values are used:
Cortex-A15: 1024, Cortex-A7: 539
They have been derived form the cpu_efficiency values:
Cortex-A15: 3891, Cortex-A7: 2048
by scaling them so that the Cortex-A15s (big cores) use 1024.
The cpu_efficiency values were originally derived from the "Big.LITTLE
Processing with ARM Cortex™-A15 & Cortex-A7" white paper
(http://www.cl.cam.ac.uk/~rdm34/big.LITTLE.pdf). Table 1 lists 1.9x
(3891/2048) as the Cortex-A15 vs Cortex-A7 performance ratio for the
Dhrystone benchmark.
The following platform is affected once cpu-invariant accounting
support is re-connected to the task scheduler:
r8a7790-lager
Cc: Rob Herring
Cc: Mark Rutland
Cc: Russell King
Signed-off-by: Dietmar Eggemann
---
arch/arm/boot/dts/r8a7790.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 2805a8608d4b..a57c0e170d8b 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -56,6 +56,7 @@
clock-latency = <30>; /* 300 us */
power-domains = <&sysc R8A7790_PD_CA15_CPU0>;
next-level-cache = <&L2_CA15>;
+ capacity-dmips-mhz = <1024>;
/* kHz - uV - OPPs unknown yet */
operating-points = <140 100>,
@@ -73,6 +74,7 @@
clock-frequency = <13>;
power-domains = <&sysc R8A7790_PD_CA15_CPU1>;
next-level-cache = <&L2_CA15>;
+ capacity-dmips-mhz = <1024>;
};
cpu2: cpu@2 {
@@ -82,6 +84,7 @@
clock-frequency = <13>;
power-domains = <&sysc R8A7790_PD_CA15_CPU2>;
next-level-cache = <&L2_CA15>;
+ capacity-dmips-mhz = <1024>;
};
cpu3: cpu@3 {
@@ -91,6 +94,7 @@
clock-frequency = <13>;
power-domains = <&sysc R8A7790_PD_CA15_CPU3>;
next-level-cache = <&L2_CA15>;
+ capacity-dmips-mhz = <1024>;
};
cpu4: cpu@100 {
@@ -100,6 +104,7 @@
clock-frequency = <78000>;
power-domains = <&sysc R8A7790_PD_CA7_CPU0>;
next-level-cache = <&L2_CA7>;
+ capacity-dmips-mhz = <539>;
};
cpu5: cpu@101 {
@@ -109,6 +114,7 @@
clock-frequency = <78000>;
power-domains = <&sysc R8A7790_PD_CA7_CPU1>;
next-level-cache = <&L2_CA7>;
+ capacity-dmips-mhz = <539>;
};
cpu6: cpu@102 {
@@ -118,6 +124,7 @@
clock-frequency = <78000>;
power-domains = <&sysc R8A7790_PD_CA7_CPU2>;
next-level-cache = <&L2_CA7>;
+ capacity-dmips-mhz = <539>;
};
cpu7: cpu@103 {
@@ -127,6 +134,7 @@
clock-frequency = <78000>;
power-domains = <&sysc R8A7790_PD_CA7_CPU3>;
next-level-cache = <&L2_CA7>;
+ capacity-dmips-mhz = <539>;
};
L2_CA15: cache-controller-0 {
--
2.11.0
[PATCH 0/4] arm: remove cpu_efficiency
For Cortex-A15/A7 arm big.LITTLE systems there are currently two ways to
set the cpu capacity.
The first one (commit 06073ee26775 "ARM: 8621/3: parse cpu
capacity-dmips-mhz from DT") is based on dt 'cpu capacity-dmips-mhz'
bindings and the appropriate dt parsing code in
drivers/base/arch_topology.c. It further takes differences in maximum
cpu frequency values into consideration, normalizes the maximum cpu
capacity to SCHED_CAPACITY_SCALE (1024) and scales all the cpus
accordingly.
cpu capacity = (capacity-dmips-mhz * max cpu frequency) /
(max capacity-dmips-mhz * max (max cpu frequency)
This solution is shared between arm and arm64 and works for other
combinations of big and little cpus (besides Cortex-A15/A7) as well.
The second one (commit 339ca09d7ada "ARM: 7463/1: topology: Update
cpu_power according to DT information" is based on the 'struct
cpu_efficiency table_efficiency[]' and the dt parsing code in
arch/arm/kernel/topology.c. It further requires a clock-frequency
property per cpu node, calculates a so called middle frequency for an
average cpu in the system which is as close as possible to
SCHED_CAPACITY_SCALE (1024) and uses this to compute the cpu capacity
values.
cpu capacity = (cpu efficiency * clock frequency) / middle capacity
This solution only works for Cortex-A15/A7 arm big.LITTLE systems.
The aim of this patch-set is to have only one solution for all arm and
arm64 big.LITTLE platforms.
(1) Therefore, it removes the code for the 'cpu_efficiency/
clock-frequency dt property' (second) solution [patch 01/04] and
migrates the arm big.LITTLE platforms currently using this approach
[patch 02-04/04] to use the 'cpu capacity-dmips-mhz' (first)
solution.
(2) Moreover, it will also assure that the highest original cpu capacity
(rq->cpu_capacity_orig) in a non-smt system is SCHED_CAPACITY_SCALE
(1024).
(3) And finally, another advantage is the dynamic detection of the max
cpu frequency which comes with the first solution instead of the
static clock-frequency dt property value.
Currently, the arm dt parsing code in parse_dt_topology() checks if the
dt uses the capacity-dmips-mhz property. If this is the case it uses
the first, otherwise the second solution. This patch-set removes the
code for the second solution from arch/arm/kernel/topology.c.
The following arm big.LITTLE platforms which use cpu node descriptions
with the 'compatible' properties "arm,cortex-a15" and "arm,cortex-a7"
as well as the "clock-frequency" are (theoretically*) affected:
(1) arndale-octa, peach-pi, peach-pit, smdk5420 (exynos5420-cpus.dtsi)
(2) odroidxu3, odroidxu3-lite, odroidxu4 (exynos5422-cpus.dtsi)
(3) r8a7790-lager (r8a7790.dtsi)
TC2 (vexpress-v2p-ca15_a7.dts) already has the capacity-dmips-mhz
properties (it never had "clock-frequency" properties per cpu node
though).
*Currently, these platforms are only theoretically affected. The reason
is because heterogeneous cpu capacity support on arm stopped with commit
8cd5601c5060 ("sched/fair: Convert arch_scale_cpu_capacity() from weak
function to #define") because the arch never defined
arch_scale_cpu_capacity so the task scheduler uses the default
implementation in kernel/sched/sched.h. This will change as soon the
patch "arm: wire cpu-invariant accounting support up to the task
scheduler" [1] is in mainline.
This patch-set has been tested on TC2 and Samsung Chromebook 2 13"
(peach-pi, Exynos 5800).
[1] https://marc.info/?l=linux-kernel&m=150367158111303&w=2
Dietmar Eggemann (4):
arm: topology: remove cpu_efficiency
arm: dts: exynos: add exynos5420 cpu capacity-dmips-mhz information
arm: dts: exynos: add exynos5422 cpu capacity-dmips-mhz information
arm: dts: r8a7790: add cpu capacity-dmips-mhz information
arch/arm/boot/dts/exynos5420-cpus.dtsi | 8 +++
arch/arm/boot/dts/exynos5422-cpus.dtsi | 8 +++
arch/arm/boot/dts/r8a7790.dtsi | 8 +++
arch/arm/kernel/topology.c | 113 +
4 files changed, 27 insertions(+), 110 deletions(-)
--
2.11.0
Re: [PATCH 3/3] tests: Add BRS test
Hi Kieran,
On Wednesday, 30 August 2017 17:31:11 EEST Kieran Bingham wrote:
> Hi Laurent,
>
> Clearly I hit send too early :-D
>
> On 30/08/17 15:16, Kieran Bingham wrote:
> > Hi Laurent,
> >
> > On 24/08/17 10:30, Laurent Pinchart wrote:
> >> Signed-off-by: Laurent Pinchart
> >
> > Nothing scary in here. Just pending testing the other patchset/issues,
> > then I can run this through as well for a tested-by.
> >
> > Meanwhile:
> >
> > Reviewed-by: Kieran Bingham
> >
> >> ---
> >>
> >> tests/vsp-unit-test-0024.sh | 45
> >> + 1 file changed, 45
> >> insertions(+)
> >> create mode 100755 tests/vsp-unit-test-0024.sh
> >>
> >> diff --git a/tests/vsp-unit-test-0024.sh b/tests/vsp-unit-test-0024.sh
> >> new file mode 100755
> >> index ..036429254a8f
> >> --- /dev/null
> >> +++ b/tests/vsp-unit-test-0024.sh
> >> @@ -0,0 +1,45 @@
> >> +#!/bin/sh
> >> +
> >> +#
> >> +# Test composition through the BRS in RGB and YUV formats.
> >> +#
> >> +
> >> +source vsp-lib.sh
>
> Please can this be:
> . ./vsp-lib.sh
Sure, it's now fixed in my tree, I'm just waiting for your Tested-by: tag
before pushing it out.
> >> +
> >> +features="rpf.0 rpf.1 brs wpf.0"
> >> +formats="RGB24 YUV444M"
> >> +
> >> +test_brs() {
> >> + local format=$1
> >> + local ninputs=$2
> >> +
> >> + test_start "BRS in $format with $ninputs inputs"
> >> +
> >> + pipe_configure rpf-brs $ninputs
> >> + format_configure rpf-brs $format 1024x768 $ninputs
> >> +
> >> + local input
> >> + for input in `seq 0 1 $((ninputs-1))` ; do
> >> + vsp_runner rpf.$input &
> >> + done
> >> + vsp_runner wpf.0
> >> +
> >> + local result=$(compare_frames)
> >> +
> >> + test_complete $result
> >> +}
> >> +
> >> +test_main() {
> >> + local num_inputs=2
> >> + local format
> >> + local ninputs
> >> +
> >> + for format in $formats ; do
> >> + for ninputs in `seq $num_inputs` ; do
> >> + test_brs $format $ninputs
> >> + done
> >> + done
> >> +}
> >> +
> >> +test_init $0 "$features"
> >> +test_run
--
Regards,
Laurent Pinchart
Re: [PATCH 3/3] tests: Add BRS test
Hi Laurent,
Clearly I hit send too early :-D
On 30/08/17 15:16, Kieran Bingham wrote:
> Hi Laurent,
>
> On 24/08/17 10:30, Laurent Pinchart wrote:
>> Signed-off-by: Laurent Pinchart
>
> Nothing scary in here. Just pending testing the other patchset/issues, then I
> can run this through as well for a tested-by.
>
> Meanwhile:
>
> Reviewed-by: Kieran Bingham
>
>
>> ---
>> tests/vsp-unit-test-0024.sh | 45
>> +
>> 1 file changed, 45 insertions(+)
>> create mode 100755 tests/vsp-unit-test-0024.sh
>>
>> diff --git a/tests/vsp-unit-test-0024.sh b/tests/vsp-unit-test-0024.sh
>> new file mode 100755
>> index ..036429254a8f
>> --- /dev/null
>> +++ b/tests/vsp-unit-test-0024.sh
>> @@ -0,0 +1,45 @@
>> +#!/bin/sh
>> +
>> +#
>> +# Test composition through the BRS in RGB and YUV formats.
>> +#
>> +
>> +source vsp-lib.sh
Please can this be:
. ./vsp-lib.sh
--
Kieran
>> +
>> +features="rpf.0 rpf.1 brs wpf.0"
>> +formats="RGB24 YUV444M"
>> +
>> +test_brs() {
>> +local format=$1
>> +local ninputs=$2
>> +
>> +test_start "BRS in $format with $ninputs inputs"
>> +
>> +pipe_configure rpf-brs $ninputs
>> +format_configure rpf-brs $format 1024x768 $ninputs
>> +
>> +local input
>> +for input in `seq 0 1 $((ninputs-1))` ; do
>> +vsp_runner rpf.$input &
>> +done
>> +vsp_runner wpf.0
>> +
>> +local result=$(compare_frames)
>> +
>> +test_complete $result
>> +}
>> +
>> +test_main() {
>> +local num_inputs=2
>> +local format
>> +local ninputs
>> +
>> +for format in $formats ; do
>> +for ninputs in `seq $num_inputs` ; do
>> +test_brs $format $ninputs
>> +done
>> +done
>> +}
>> +
>> +test_init $0 "$features"
>> +test_run
>>
Re: [PATCH] pinctrl: sh-pfc: r8a7795: Re-add DRIF support
On Wed, Aug 30, 2017 at 10:05 AM, Dirk Behme wrote:
> DRIF support for r8a7795 was initially added with commit 2d775831988
> ("pinctrl: sh-pfc: r8a7795: Add DRIF support") and later dropped from
> the new pfc-r8a7795.c while re-naming the initial pfc-r8a7795.c to
> pfc-r8a7795-es1.c in commit b205914c8f8 ("pinctrl: sh-pfc: r8a7795:
> Add support for R-Car H3 ES2.0"). As the DRIF doesn't differ, re-add
> it here.
>
> Signed-off-by: Dirk Behme
Reviewed-by: Geert Uytterhoeven
I.e. will queue in sh-pfc-for-v4.15.
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/3] tests: Add BRS test
Hi Laurent,
On 24/08/17 10:30, Laurent Pinchart wrote:
> Signed-off-by: Laurent Pinchart
Nothing scary in here. Just pending testing the other patchset/issues, then I
can run this through as well for a tested-by.
Meanwhile:
Reviewed-by: Kieran Bingham
> ---
> tests/vsp-unit-test-0024.sh | 45
> +
> 1 file changed, 45 insertions(+)
> create mode 100755 tests/vsp-unit-test-0024.sh
>
> diff --git a/tests/vsp-unit-test-0024.sh b/tests/vsp-unit-test-0024.sh
> new file mode 100755
> index ..036429254a8f
> --- /dev/null
> +++ b/tests/vsp-unit-test-0024.sh
> @@ -0,0 +1,45 @@
> +#!/bin/sh
> +
> +#
> +# Test composition through the BRS in RGB and YUV formats.
> +#
> +
> +source vsp-lib.sh
> +
> +features="rpf.0 rpf.1 brs wpf.0"
> +formats="RGB24 YUV444M"
> +
> +test_brs() {
> + local format=$1
> + local ninputs=$2
> +
> + test_start "BRS in $format with $ninputs inputs"
> +
> + pipe_configure rpf-brs $ninputs
> + format_configure rpf-brs $format 1024x768 $ninputs
> +
> + local input
> + for input in `seq 0 1 $((ninputs-1))` ; do
> + vsp_runner rpf.$input &
> + done
> + vsp_runner wpf.0
> +
> + local result=$(compare_frames)
> +
> + test_complete $result
> +}
> +
> +test_main() {
> + local num_inputs=2
> + local format
> + local ninputs
> +
> + for format in $formats ; do
> + for ninputs in `seq $num_inputs` ; do
> + test_brs $format $ninputs
> + done
> + done
> +}
> +
> +test_init $0 "$features"
> +test_run
>
Re: [PATCH v3] pinctrl: sh-pfc: r8a7795: Add SDHI0-3 support
On Tue, Aug 29, 2017 at 5:51 PM, Wolfram Sang
wrote:
> From: Takeshi Kihara
>
> Add SDHI0-3 support for R-Car H3 ES2.0 based on a patch from the Renesas
> BSP. SDHI pin config is identical to H3 ES1.*.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Dirk Behme
> Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
I.e. will queue in sh-pfc-for-v4.15.
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/3] vsp-lib: Add support for RPF-BRS-WPF pipelines
Hi Laurent,
Thankyou for the patch
On 24/08/17 10:30, Laurent Pinchart wrote:
> Reuse the BRU code, using the brx generic name to cover both BRU and
> BRS.
>
> Signed-off-by: Laurent Pinchart
This looks good to me:
Reviewed-by: Kieran Bingham
> ---
> scripts/vsp-lib.sh | 63
> +-
> 1 file changed, 43 insertions(+), 20 deletions(-)
>
> diff --git a/scripts/vsp-lib.sh b/scripts/vsp-lib.sh
> index fa4a6984e1bb..0f3992a7827e 100755
> --- a/scripts/vsp-lib.sh
> +++ b/scripts/vsp-lib.sh
> @@ -53,11 +53,16 @@ vsp1_count_wpfs() {
> $mediactl -d $mdev -p | grep -- '- entity.*wpf.[0-9] [^o]' | wc -l
> }
>
> -vsp1_count_bru_inputs() {
> - local num_pads=`$mediactl -d $mdev -p | grep 'entity.*bru' | sed
> 's/.*(\([0-9]\) pads.*/\1/'`
> +__vsp1_count_brx_inputs() {
> + local name=$1
> + local num_pads=`$mediactl -d $mdev -p | grep "entity.*$name" | sed
> 's/.*(\([0-9]\) pads.*/\1/'`
> echo $((num_pads-1))
> }
>
> +vsp1_count_bru_inputs() {
> + __vsp1_count_brx_inputs "bru"
> +}
> +
> vsp1_entity_subdev() {
> $mediactl -d $mdev -e "$dev $1"
> }
> @@ -105,7 +110,7 @@ reference_frame() {
>
> # gen-image doesn't support processing HSV input images. The good news
> # is that the HSV tests that take HSV images as inputs don't need to
> - # perform any processing. We can set the input format to RGB for HSV
> + # perform any processing. We can set the input format to RGB for HSB
> # reference frame generation.
> case $in_format in
> HSV24 | HSV32)
> @@ -178,7 +183,7 @@ reference_frame() {
> esac
> done
>
> - [ x$__vsp_bru_inputs != x ] && options="$options -c $__vsp_bru_inputs"
> + [ x$__vsp_brx_inputs != x ] && options="$options -c $__vsp_brx_inputs"
>
> $genimage -i $in_format -f $out_format -s $size -a $alpha $options -o
> $file \
> frames/frame-reference-1024x768.pnm
> @@ -363,18 +368,27 @@ pipe_none() {
> return
> }
>
> -pipe_rpf_bru() {
> - local ninputs=$1
> +__pipe_rpf_brx() {
> + local name=$1
> + local ninputs=$2
>
> - local bru_output=$(vsp1_count_bru_inputs)
> + local output=$(__vsp1_count_brx_inputs $name)
>
> for input in `seq 0 1 $((ninputs-1))` ; do
> - $mediactl -d $mdev -l "'$dev rpf.$input':1 -> '$dev bru':$input
> [1]"
> + $mediactl -d $mdev -l "'$dev rpf.$input':1 -> '$dev
> $name':$input [1]"
> done
> - $mediactl -d $mdev -l "'$dev bru':$bru_output -> '$dev wpf.0':0 [1]"
> + $mediactl -d $mdev -l "'$dev $name':$output -> '$dev wpf.0':0 [1]"
> $mediactl -d $mdev -l "'$dev wpf.0':1 -> '$dev wpf.0 output':0 [1]"
>
> - __vsp_bru_inputs=$ninputs
> + __vsp_brx_inputs=$ninputs
> +}
> +
> +pipe_rpf_brs() {
> + __pipe_rpf_brx "brs" $*
> +}
> +
> +pipe_rpf_bru() {
> + __pipe_rpf_brx "bru" $*
> }
>
> pipe_rpf_bru_uds() {
> @@ -468,7 +482,7 @@ pipe_rpf_wpf() {
> pipe_reset() {
> $mediactl -d $mdev -r
>
> - __vsp_bru_inputs=
> + __vsp_brx_inputs=
> __vsp_histo_type=
> __vsp_rpf_format=
> __vsp_wpf_index=0
> @@ -532,26 +546,35 @@ format_rpf() {
> __vsp_rpf_format=$1
> }
>
> -format_rpf_bru() {
> - local format=$(format_v4l2_to_mbus $1)
> - local size=$2
> - local ninputs=$3
> +__format_rpf_brx() {
> + local name=$1
> + local format=$(format_v4l2_to_mbus $2)
> + local size=$3
> + local ninputs=$4
> local offset=0
>
> - local bru_output=$(vsp1_count_bru_inputs)
> + local output=$(__vsp1_count_brx_inputs $name)
>
> for input in `seq 0 1 $((ninputs-1))` ; do
> offset=$((offset+50))
> $mediactl -d $mdev -V "'$dev rpf.$input':0 [fmt:$format/$size]"
> - $mediactl -d $mdev -V "'$dev bru':$input [fmt:$format/$size
> compose:($offset,$offset)/$size]"
> + $mediactl -d $mdev -V "'$dev $name':$input [fmt:$format/$size
> compose:($offset,$offset)/$size]"
> done
>
> - $mediactl -d $mdev -V "'$dev bru':$bru_output [fmt:$format/$size]"
> + $mediactl -d $mdev -V "'$dev $name':$output [fmt:$format/$size]"
> $mediactl -d $mdev -V "'$dev wpf.0':0 [fmt:$format/$size]"
> $mediactl -d $mdev -V "'$dev wpf.0':1 [fmt:$format/$size]"
>
> - __vsp_rpf_format=$1
> - __vsp_wpf_format=$1
> + __vsp_rpf_format=$2
> + __vsp_wpf_format=$2
> +}
> +
> +format_rpf_brs() {
> + __format_rpf_brx "brs" $*
> +}
> +
> +format_rpf_bru() {
> + __format_rpf_brx "bru" $*
> }
>
> format_rpf_bru_uds() {
>
[PATCH 3/5] ARM: dts: r8a7743: Link PCI USB devices to USB PHY
Describe the PCI USB devices that are behind the PCI bridges, adding
necessary links to the USB PHY device.
Signed-off-by: Biju Das
---
arch/arm/boot/dts/r8a7743.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index a81d70e..665a515 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -865,6 +865,18 @@
interrupt-map = <0x 0 0 1 &gic GIC_SPI 108
IRQ_TYPE_LEVEL_HIGH
0x0800 0 0 1 &gic GIC_SPI 108
IRQ_TYPE_LEVEL_HIGH
0x1000 0 0 2 &gic GIC_SPI 108
IRQ_TYPE_LEVEL_HIGH>;
+
+ usb@1,0 {
+ reg = <0x800 0 0 0 0>;
+ phys = <&usb0 0>;
+ phy-names = "usb";
+ };
+
+ usb@2,0 {
+ reg = <0x1000 0 0 0 0>;
+ phys = <&usb0 0>;
+ phy-names = "usb";
+ };
};
pci1: pci@ee0d {
@@ -888,6 +900,18 @@
interrupt-map = <0x 0 0 1 &gic GIC_SPI 113
IRQ_TYPE_LEVEL_HIGH
0x0800 0 0 1 &gic GIC_SPI 113
IRQ_TYPE_LEVEL_HIGH
0x1000 0 0 2 &gic GIC_SPI 113
IRQ_TYPE_LEVEL_HIGH>;
+
+ usb@1,0 {
+ reg = <0x10800 0 0 0 0>;
+ phys = <&usb2 0>;
+ phy-names = "usb";
+ };
+
+ usb@2,0 {
+ reg = <0x11000 0 0 0 0>;
+ phys = <&usb2 0>;
+ phy-names = "usb";
+ };
};
};
--
1.9.1
[PATCH 5/5] ARM: dts: iwg20d-q7: Enable USB PHY
Signed-off-by: Biju Das
---
arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
index 63166f9..0136864 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
+++ b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
@@ -147,3 +147,7 @@
pinctrl-0 = <&usb1_pins>;
pinctrl-names = "default";
};
+
+&usbphy {
+ status = "okay";
+};
--
1.9.1
[PATCH 4/5] ARM: dts: iwg20d-q7: Enable internal PCI
Enable internal AHB-PCI bridges for the USB EHCI/OHCI controllers
attached to them.
Signed-off-by: Biju Das
---
arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
index 2b58b53..63166f9 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
+++ b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
@@ -76,6 +76,16 @@
function = "sdhi1";
power-source = <1800>;
};
+
+ usb0_pins: usb0 {
+ groups = "usb0";
+ function = "usb0";
+ };
+
+ usb1_pins: usb1 {
+ groups = "usb1";
+ function = "usb1";
+ };
};
&scif0 {
@@ -125,3 +135,15 @@
reg = <0x68>;
};
};
+
+&pci0 {
+ status = "okay";
+ pinctrl-0 = <&usb0_pins>;
+ pinctrl-names = "default";
+};
+
+&pci1 {
+ status = "okay";
+ pinctrl-0 = <&usb1_pins>;
+ pinctrl-names = "default";
+};
--
1.9.1
[PATCH 2/5] ARM: dts: r8a7743: Add USB PHY DT support
Define the r8a7743 generic part of the USB PHY device node.
Signed-off-by: Biju Das
---
arch/arm/boot/dts/r8a7743.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 3f1faad..a81d70e 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -822,6 +822,28 @@
status = "disabled";
};
+ usbphy: usb-phy@e6590100 {
+ compatible = "renesas,usb-phy-r8a7743",
+"renesas,rcar-gen2-usb-phy";
+ reg = <0 0xe6590100 0 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cpg CPG_MOD 704>;
+ clock-names = "usbhs";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 704>;
+ status = "disabled";
+
+ usb0: usb-channel@0 {
+ reg = <0>;
+ #phy-cells = <1>;
+ };
+ usb2: usb-channel@2 {
+ reg = <2>;
+ #phy-cells = <1>;
+ };
+ };
+
pci0: pci@ee09 {
compatible = "renesas,pci-r8a7743",
"renesas,pci-rcar-gen2";
--
1.9.1
[PATCH 0/5] Add USB2.0 Host support
Hello, This series aims to add USB2.0 Host support on iWave RZ/G1M(r8a7743) based board. This series has been tested against renesas-dev tag 20170830-v4.13-rc7 This patch has documentation dependency on below patches * PCI: rcar: Add r8a7743/5 support https://patchwork.kernel.org/patch/9919697/ * phy: rcar-gen2: Add r8a7743/5 support https://patchwork.kernel.org/patch/9919727/ Biju Das (5): ARM: dts: r8a7743: Add internal PCI bridge nodes ARM: dts: r8a7743: Add USB PHY DT support ARM: dts: r8a7743: Link PCI USB devices to USB PHY ARM: dts: iwg20d-q7: Enable internal PCI ARM: dts: iwg20d-q7: Enable USB PHY arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 26 ++ arch/arm/boot/dts/r8a7743.dtsi | 92 + 2 files changed, 118 insertions(+) -- 1.9.1
[PATCH 1/5] ARM: dts: r8a7743: Add internal PCI bridge nodes
Add device nodes for the r8a7743 internal PCI bridge devices.
Signed-off-by: Biju Das
---
arch/arm/boot/dts/r8a7743.dtsi | 46 ++
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 6dd9b0b..3f1faad 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -821,6 +821,52 @@
resets = <&cpg 311>;
status = "disabled";
};
+
+ pci0: pci@ee09 {
+ compatible = "renesas,pci-r8a7743",
+"renesas,pci-rcar-gen2";
+ device_type = "pci";
+ reg = <0 0xee09 0 0xc00>,
+ <0 0xee08 0 0x1100>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 703>;
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 703>;
+ status = "disabled";
+
+ bus-range = <0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x0200 0 0xee08 0 0xee08 0
0x0001>;
+ interrupt-map-mask = <0xff00 0 0 0x7>;
+ interrupt-map = <0x 0 0 1 &gic GIC_SPI 108
IRQ_TYPE_LEVEL_HIGH
+0x0800 0 0 1 &gic GIC_SPI 108
IRQ_TYPE_LEVEL_HIGH
+0x1000 0 0 2 &gic GIC_SPI 108
IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ pci1: pci@ee0d {
+ compatible = "renesas,pci-r8a7743",
+"renesas,pci-rcar-gen2";
+ device_type = "pci";
+ reg = <0 0xee0d 0 0xc00>,
+ <0 0xee0c 0 0x1100>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 703>;
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 703>;
+ status = "disabled";
+
+ bus-range = <1 1>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x0200 0 0xee0c 0 0xee0c 0
0x0001>;
+ interrupt-map-mask = <0xff00 0 0 0x7>;
+ interrupt-map = <0x 0 0 1 &gic GIC_SPI 113
IRQ_TYPE_LEVEL_HIGH
+0x0800 0 0 1 &gic GIC_SPI 113
IRQ_TYPE_LEVEL_HIGH
+0x1000 0 0 2 &gic GIC_SPI 113
IRQ_TYPE_LEVEL_HIGH>;
+ };
};
/* External root clock */
--
1.9.1
RE: [PATCH v2 3/3] ARM: dts: r7s72100: Add reset handler
Hi Simon, On Wednesday, August 30, 2017, Simon Horman wrote: > On Fri, Feb 17, 2017 at 11:29:25AM +0100, Geert Uytterhoeven wrote: > > On Thu, Feb 16, 2017 at 6:23 PM, Chris Brandt > wrote: > > > For the RZ/A1, the only way to do a reset is to overflow the WDT. > > > > > > Signed-off-by: Chris Brandt > > > > Reviewed-by: Geert Uytterhoeven > > Hi Chris, > > while going through old patches I noticed that I seem to have missed this > one. It looks like it needs a rebase. If it is still applicable could you > please consider doing so and reposting. It's in -next already: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/r7s72100.dtsi?h=next-20170829&id=69ed50de582eff6307fd3fa050fdc505731f0a2d Doesn't that mean it's queued up for 4.14? Or, somehow it didn't make it into the pull request for Arnd's tree? Chris
RE: [PATCH 5/8] pinctrl: sh-pfc: r8a77995: Add EthernetAVB pins, groups and functions
Hi Geert-san,
Sorry, I also missed this email...
> -Original Message-
> From: Geert Uytterhoeven
> Sent: Wednesday, August 16, 2017 8:06 PM
>
> Hi Shimoda-san, Kihara-san,
>
> On Wed, Aug 9, 2017 at 2:19 PM, Yoshihiro Shimoda
> wrote:
> > From: Takeshi Kihara
> >
> > Signed-off-by: Takeshi Kihara
> > Signed-off-by: Yoshihiro Shimoda
>
> Reviewed-by: Geert Uytterhoeven
>
> But before I apply this, please see my question below...
>
> > --- a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
> > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
>
> > +static const char * const avb0_groups[] = {
> > + "avb0_td",
> > + "avb0_rd",
> > + "avb0_tx_ctl",
> > + "avb0_rx_ctl",
> > + "avb0_txc",
> > + "avb0_rxc",
> > + "avb0_txcrefclk",
> > + "avb0_link",
> > + "avb0_magic",
> > + "avb0_phy_int",
> > + "avb0_mdc",
> > + "avb0_mdio",
> > + "avb0_avtp_pps_a",
> > + "avb0_avtp_match_a",
> > + "avb0_avtp_capture_a",
> > + "avb0_avtp_pps_b",
> > + "avb0_avtp_match_b",
> > + "avb0_avtp_capture_b",
> > +};
>
> Is there any specific reason this uses a different split than the
> EtherAVB groups
> in pinctrl drivers for other SoCs?
I will check this tomorrow (or later...).
Best regards,
Yoshihiro Shimoda
> Note that I do understand that the different prefix ("avb0" vs. "avb")
> was used to
> match the R-Car D3 datasheet, which is thus OK.
>
> 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 6/8] pinctrl: sh-pfc: r8a77995: Add USB2.0 host support
Hi Geert-san,
I'm sorry. I missed this email...
> From: Geert Uytterhoeven
> Sent: Wednesday, August 16, 2017 8:11 PM
>
> Hi Shimoda-san, Kihara-san,
>
> On Wed, Aug 9, 2017 at 2:19 PM, Yoshihiro Shimoda
> wrote:
> > From: Takeshi Kihara
> >
> > Signed-off-by: Takeshi Kihara
> > Signed-off-by: Yoshihiro Shimoda
> > ---
> > drivers/pinctrl/sh-pfc/pfc-r8a77995.c | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
> > b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
> > index 9eb0cef..5c0a94f 100644
> > --- a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
> > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
> > @@ -1302,6 +1302,15 @@ enum {
> > SCIF_CLK_MARK,
> > };
> >
> > +/* - USB0
> > --- */
> > +static const unsigned int usb0_pins[] = {
> > + /* PWEN, OVC */
> > + RCAR_GP_PIN(0, 0), RCAR_GP_PIN(0, 1),
> > +};
> > +static const unsigned int usb0_mux[] = {
> > + USB0_PWEN_MARK, USB0_OVC_MARK,
> > +};
>
> What about USB0_IDPU and USB0_IDIN?
> Are they needed for normal operation, or can they be added later?
I don't know about these pins. The datasheet doesn't mention usage in USB
sections...
So, I'm asking HW team now. (I think they can be added later.)
Best regards,
Yoshihiro Shimoda
> 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: The RZ/A1 pin controller driver will be broken for 4.13
Hi Jacopo,
Thank you for the quick analysis.
On Wednesday, August 30, 2017, jmondi wrote:
> After some investigations, it turns out some register settings
> performed during pin_reset() are invalid and hang the system BUT only
> when performed on Port_9.
>
> Specifically, setting PMC and PIPC registers to 0 (default initial state)
> on Port_9, hangs the system.
>
> There is no mention (none that I've found) in the processor manual of
> specific procedures to be performed when resetting that port to its
> initial state, so I guess this may either be an indication of
> something else going wrong (like writing to some invalid memory
> address) or it's an HW issue not yet documented.
>
> Timur's patch does trigger a "reset" on all Ports during gpiochip
> registration , while before that patch made into -next branch, reset
> was only triggered when actually requesting a gpio or when performing
> muxing on a pin.
>
> Apparently, we never multiplexed any pin on Port_9 nor tested gpio
> functionalities on that port before.
Actually, we did. The QSPI Flash was always on port 9 and set up by
u-boot. Since it's set up in XIP-mode and linearly mapped to internal
address space, the kernel never needed to know about any pins or driver for
it.
So, if you set the QSPI pins back to GPIO, you die pretty quickly
(especially with an XIP kernel).
> This:
>
> @@ -487,8 +491,10 @@ static void rza1_pin_reset(struct rza1_port *port,
> unsigned int pin)
> rza1_set_bit(port, RZA1_PBDC_REG, pin, 0);
>
> rza1_set_bit(port, RZA1_PM_REG, pin, 1);
> - rza1_set_bit(port, RZA1_PMC_REG, pin, 0);
> - rza1_set_bit(port, RZA1_PIPC_REG, pin, 0);
> + if (port->id != 9) {
> + rza1_set_bit(port, RZA1_PMC_REG, pin, 0);
> + rza1_set_bit(port, RZA1_PIPC_REG, pin, 0);
> + }
> spin_unlock_irqrestore(&port->lock, irqflags);
> }
>
> Fixes the issue, but I'm not that satisfied with this as I would like
> to know if the same issue happens on other processors of the RZ/A1 family
> other than RZ/A1H before proposing this as a proper fix.
>
> Chris, do you have RZ/A1* devices where to test this?
RZ/A1H and RZ/A1M are the same part, just with different RAM sizes, so
only RZ/A1L is the different one.
But, if you remember, I have not added the look-up table for the RZ/A1L
in the driver yet.
For the RZ/A1L, QSPI is on port 4.
In general, I disagree with the kernel blindly resetting ports that it
knows nothing about. Maybe there's a reason it doesn't know about them.
What about the external memory connections that is set up in u-boot? Is
it going to reset those pins as well?
Maybe that's why my system was crashing on the init of port 2 (where my
SDRAM connections are) because I was running an XIP_KERNEL + external
SDRAM, so I never even made it to port 9.
Chris
Re: The RZ/A1 pin controller driver will be broken for 4.13
Hi Geert, Chris,
On Wed, Aug 30, 2017 at 10:26:30AM +0200, Geert Uytterhoeven wrote:
> CC Timur, LinusW, gpio
>
> On Tue, Aug 29, 2017 at 8:56 PM, Chris Brandt
> wrote:
> > Just FYI,
> >
> > After pulling Geert's new renesas-drivers-2017-08-29-v4.13-rc7, I tried
> > testing RZ/A1 and it hangs during boot.
> >
> > Basically...
> >
> > [ 110.329579] pinctrl-rza1 fcfe3000.pin-controller: Parsed gpiochip
> > gpio-0-0 with 6 pins
> > [ 112.970056] pinctrl-rza1 fcfe3000.pin-controller: Parsed gpiochip
> > gpio-1-1 with 16 pins
> > (hangs here forever)
> >
> >
> > After some debug, I found that this commit broke the new
> > drivers/pinctrl/pinctrl-rza1.c driver.
> >
> > 108d23e322a2 ("gpiolib: request the gpio before querying its direction")
> >
> > Looks like it was added for -rc5.
> >
> > If I revert that one patch, RZ/A1 boots fine.
> >
> > Since we're at -rc7, I probably won't have time to fix it before the
> > release.
>
> It's not in v4.13-rc5, only in -next, for v4.14.
> So v4.13 will be fine, and we still have plenty of time to fix the issue.
After some investigations, it turns out some register settings
performed during pin_reset() are invalid and hang the system BUT only
when performed on Port_9.
Specifically, setting PMC and PIPC registers to 0 (default initial state)
on Port_9, hangs the system.
There is no mention (none that I've found) in the processor manual of
specific procedures to be performed when resetting that port to its
initial state, so I guess this may either be an indication of
something else going wrong (like writing to some invalid memory
address) or it's an HW issue not yet documented.
Timur's patch does trigger a "reset" on all Ports during gpiochip
registration , while before that patch made into -next branch, reset
was only triggered when actually requesting a gpio or when performing
muxing on a pin.
Apparently, we never multiplexed any pin on Port_9 nor tested gpio
functionalities on that port before.
This:
@@ -487,8 +491,10 @@ static void rza1_pin_reset(struct rza1_port *port,
unsigned int pin)
rza1_set_bit(port, RZA1_PBDC_REG, pin, 0);
rza1_set_bit(port, RZA1_PM_REG, pin, 1);
- rza1_set_bit(port, RZA1_PMC_REG, pin, 0);
- rza1_set_bit(port, RZA1_PIPC_REG, pin, 0);
+ if (port->id != 9) {
+ rza1_set_bit(port, RZA1_PMC_REG, pin, 0);
+ rza1_set_bit(port, RZA1_PIPC_REG, pin, 0);
+ }
spin_unlock_irqrestore(&port->lock, irqflags);
}
Fixes the issue, but I'm not that satisfied with this as I would like
to know if the same issue happens on other processors of the RZ/A1 family
other than RZ/A1H before proposing this as a proper fix.
Chris, do you have RZ/A1* devices where to test this?
Thanks
j
>
> > Poor RZ/A1 pinctrl driver...it took so long to get into mainline, and
> > then it only worked for 1 release.
>
> 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] [media] v4l: vsp1: Use generic node name
Hi Laurent,
On Wed, Aug 30, 2017 at 12:10 PM, Laurent Pinchart
wrote:
> On Wednesday, 30 August 2017 12:57:31 EEST Geert Uytterhoeven wrote:
>> Use the preferred generic node name in the example.
>>
>> Signed-off-by: Geert Uytterhoeven
>> ---
>> Documentation/devicetree/bindings/media/renesas,vsp1.txt | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
>> b/Documentation/devicetree/bindings/media/renesas,vsp1.txt index
>> 9b695bcbf2190bdd..16427017cb45561e 100644
>> --- a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
>> +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
>> @@ -22,7 +22,7 @@ Optional properties:
>>
>> Example: R8A7790 (R-Car H2) VSP1-S node
>>
>> - vsp1@fe928000 {
>> + vsp@fe928000 {
>
> vsp1 isn't an instance name but an IP core name.
I know (cfr. "preferred generic node name", not "numerical suffix").
For the actual DTSes on R-Car Gen3, we settled on the more generic "vsp"
for the vsp2 node names.
R-Car Gen2 DTSes still use "vsp1".
>> compatible = "renesas,vsp1";
>> reg = <0 0xfe928000 0 0x8000>;
>> interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;
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: r8a7795: Drop bogus HDMI node names suffixes
Hi Geert,
Thank you for the patch.
On Wednesday, 30 August 2017 13:03:17 EEST Geert Uytterhoeven wrote:
> Node names should not use numerical suffixes if the nodes can be
> distinguished by unit-address.
>
> Signed-off-by: Geert Uytterhoeven
Acked-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index
> 8b4dbce860001224..e1ced54d11322cb4 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -2702,7 +2702,7 @@
> renesas,fcp = <&fcpf1>;
> };
>
> - hdmi0: hdmi0@fead {
> + hdmi0: hdmi@fead {
> compatible = "renesas,r8a7795-hdmi",
> "renesas,rcar-gen3-hdmi";
> reg = <0 0xfead 0 0x1>;
> interrupts = ;
> @@ -2727,7 +2727,7 @@
> };
> };
>
> - hdmi1: hdmi1@feae {
> + hdmi1: hdmi@feae {
> compatible = "renesas,r8a7795-hdmi",
> "renesas,rcar-gen3-hdmi";
> reg = <0 0xfeae 0 0x1>;
> interrupts = ;
--
Regards,
Laurent Pinchart
Re: [PATCH] [media] v4l: vsp1: Use generic node name
Hi Geert,
Thank you for the patch.
On Wednesday, 30 August 2017 12:57:31 EEST Geert Uytterhoeven wrote:
> Use the preferred generic node name in the example.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Documentation/devicetree/bindings/media/renesas,vsp1.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
> b/Documentation/devicetree/bindings/media/renesas,vsp1.txt index
> 9b695bcbf2190bdd..16427017cb45561e 100644
> --- a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
> +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
> @@ -22,7 +22,7 @@ Optional properties:
>
> Example: R8A7790 (R-Car H2) VSP1-S node
>
> - vsp1@fe928000 {
> + vsp@fe928000 {
vsp1 isn't an instance name but an IP core name.
> compatible = "renesas,vsp1";
> reg = <0 0xfe928000 0 0x8000>;
> interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;
--
Regards,
Laurent Pinchart
Re: [PATCH] dt-bindings: display: renesas: dw-hdmi: Drop bogus node name suffix
Hi Geert,
Thank you for the patch.
On Wednesday, 30 August 2017 12:53:01 EEST Geert Uytterhoeven wrote:
> Node names should not use numerical suffixes if the nodes can be
> distinguished by unit-address.
>
> Signed-off-by: Geert Uytterhoeven
Acked-by: Laurent Pinchart
> ---
> Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> index 83382a422f309dba..19b57f1183f2af3b 100644
> --- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> @@ -37,7 +37,7 @@ Optional properties:
>
> Example:
>
> - hdmi0: hdmi0@fead {
> + hdmi0: hdmi@fead {
> compatible = "renesas,r8a7795-dw-hdmi";
> reg = <0 0xfead 0 0x1>;
> interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
--
Regards,
Laurent Pinchart
[PATCH] arm64: dts: r8a7795: Drop bogus HDMI node names suffixes
Node names should not use numerical suffixes if the nodes can be
distinguished by unit-address.
Signed-off-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 8b4dbce860001224..e1ced54d11322cb4 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -2702,7 +2702,7 @@
renesas,fcp = <&fcpf1>;
};
- hdmi0: hdmi0@fead {
+ hdmi0: hdmi@fead {
compatible = "renesas,r8a7795-hdmi",
"renesas,rcar-gen3-hdmi";
reg = <0 0xfead 0 0x1>;
interrupts = ;
@@ -2727,7 +2727,7 @@
};
};
- hdmi1: hdmi1@feae {
+ hdmi1: hdmi@feae {
compatible = "renesas,r8a7795-hdmi",
"renesas,rcar-gen3-hdmi";
reg = <0 0xfeae 0 0x1>;
interrupts = ;
--
2.7.4
[PATCH] ASoC: rsnd: Drop unit-addresses without reg properties
Nodes without reg properties must not have unit addresses:
Warning (unit_address_vs_reg): Node .../rcar_sound,dvc/dvc@0 has a unit
name, but no reg property
Signed-off-by: Geert Uytterhoeven
---
Despite the example, there don't seem to be any DTSes with multiple
"simple-audio-card,cpu" nodes?
---
.../devicetree/bindings/sound/renesas,rsnd.txt | 68 +++---
1 file changed, 34 insertions(+), 34 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
index 7246bb268bf9bab6..a1536fdc60e62c49 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
@@ -199,10 +199,10 @@ Ex)
sound {
compatible = "simple-scu-audio-card";
...
- simple-audio-card,cpu@0 {
+ simple-audio-card,cpu-0 {
sound-dai = <&rcar_sound 0>;
};
- simple-audio-card,cpu@1 {
+ simple-audio-card,cpu-1 {
sound-dai = <&rcar_sound 1>;
};
simple-audio-card,codec {
@@ -441,79 +441,79 @@ rcar_sound: sound@ec50 {
"clk_a", "clk_b", "clk_c", "clk_i";
rcar_sound,dvc {
- dvc0: dvc@0 {
+ dvc0: dvc-0 {
dmas = <&audma0 0xbc>;
dma-names = "tx";
};
- dvc1: dvc@1 {
+ dvc1: dvc-1 {
dmas = <&audma0 0xbe>;
dma-names = "tx";
};
};
rcar_sound,mix {
- mix0: mix@0 { };
- mix1: mix@1 { };
+ mix0: mix-0 { };
+ mix1: mix-1 { };
};
rcar_sound,ctu {
- ctu00: ctu@0 { };
- ctu01: ctu@1 { };
- ctu02: ctu@2 { };
- ctu03: ctu@3 { };
- ctu10: ctu@4 { };
- ctu11: ctu@5 { };
- ctu12: ctu@6 { };
- ctu13: ctu@7 { };
+ ctu00: ctu-0 { };
+ ctu01: ctu-1 { };
+ ctu02: ctu-2 { };
+ ctu03: ctu-3 { };
+ ctu10: ctu-4 { };
+ ctu11: ctu-5 { };
+ ctu12: ctu-6 { };
+ ctu13: ctu-7 { };
};
rcar_sound,src {
- src0: src@0 {
+ src0: src-0 {
interrupts = <0 352 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x85>, <&audma1 0x9a>;
dma-names = "rx", "tx";
};
- src1: src@1 {
+ src1: src-1 {
interrupts = <0 353 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x87>, <&audma1 0x9c>;
dma-names = "rx", "tx";
};
- src2: src@2 {
+ src2: src-2 {
interrupts = <0 354 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x89>, <&audma1 0x9e>;
dma-names = "rx", "tx";
};
- src3: src@3 {
+ src3: src-3 {
interrupts = <0 355 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x8b>, <&audma1 0xa0>;
dma-names = "rx", "tx";
};
- src4: src@4 {
+ src4: src-4 {
interrupts = <0 356 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x8d>, <&audma1 0xb0>;
dma-names = "rx", "tx";
};
- src5: src@5 {
+ src5: src-5 {
interrupts = <0 357 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x8f>, <&audma1 0xb2>;
dma-names = "rx", "tx";
};
- src6: src@6 {
+ src6: src-6 {
interrupts = <0 358 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x91>, <&audma1 0xb4>;
dma-names = "rx", "tx";
};
- src7: src@7 {
+ src7: src-7 {
interrupts = <0 359 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x93>, <&audma1 0xb6>;
dma-names = "rx", "tx";
};
- src8: src@8 {
+ src8: src-8 {
interrupts = <0 360 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x95>, <&audma1 0xb8>;
dma-names = "rx", "tx";
};
- src9: src@9 {
+ src9: src-9 {
interrupts = <0 361 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x97>, <&audma1 0xba>;
dma-na
[PATCH] [media] v4l: vsp1: Use generic node name
Use the preferred generic node name in the example.
Signed-off-by: Geert Uytterhoeven
---
Documentation/devicetree/bindings/media/renesas,vsp1.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
index 9b695bcbf2190bdd..16427017cb45561e 100644
--- a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
+++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
@@ -22,7 +22,7 @@ Optional properties:
Example: R8A7790 (R-Car H2) VSP1-S node
- vsp1@fe928000 {
+ vsp@fe928000 {
compatible = "renesas,vsp1";
reg = <0 0xfe928000 0 0x8000>;
interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;
--
2.7.4
[PATCH] dt-bindings: pinctrl: sh-pfc: Use generic node name
Use the preferred generic node name in the example.
Signed-off-by: Geert Uytterhoeven
---
Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
index f4d127df980dccbc..b4083787e3ce0af7 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
@@ -112,7 +112,7 @@ Examples
Example 1: SH73A0 (SH-Mobile AG5) pin controller node
- pfc: pfc@e605 {
+ pfc: pin-controller@e605 {
compatible = "renesas,pfc-sh73a0";
reg = <0xe605 0x8000>,
<0xe605801c 0x1c>;
--
2.7.4
[PATCH] dt-bindings: display: renesas: dw-hdmi: Drop bogus node name suffix
Node names should not use numerical suffixes if the nodes can be
distinguished by unit-address.
Signed-off-by: Geert Uytterhoeven
---
Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
index 83382a422f309dba..19b57f1183f2af3b 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
@@ -37,7 +37,7 @@ Optional properties:
Example:
- hdmi0: hdmi0@fead {
+ hdmi0: hdmi@fead {
compatible = "renesas,r8a7795-dw-hdmi";
reg = <0 0xfead 0 0x1>;
interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
--
2.7.4
Re: [PATCH 1/3] vsp-lib: Use the correct media device name to count BRU inputs
Hi Laurent,
Thanks for the patch.
On 24/08/17 10:30, Laurent Pinchart wrote:
> Use the media device under test, not the default media0.
>
> Signed-off-by: Laurent Pinchart
Looks good, and looks like this is the only use of media-ctl directly.
Reviewed-by: Kieran Bingham
> ---
> scripts/vsp-lib.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/vsp-lib.sh b/scripts/vsp-lib.sh
> index 726ff793b2ce..fa4a6984e1bb 100755
> --- a/scripts/vsp-lib.sh
> +++ b/scripts/vsp-lib.sh
> @@ -54,7 +54,7 @@ vsp1_count_wpfs() {
> }
>
> vsp1_count_bru_inputs() {
> - local num_pads=`media-ctl -p | grep 'entity.*bru' | sed 's/.*(\([0-9]\)
> pads.*/\1/'`
> + local num_pads=`$mediactl -d $mdev -p | grep 'entity.*bru' | sed
> 's/.*(\([0-9]\) pads.*/\1/'`
> echo $((num_pads-1))
> }
>
>
Re: [PATCH 20/20] arm64: dts: renesas: salvator: use VC1 for CVBS
On Wed, Aug 30, 2017 at 10:08:24AM +0200, Niklas Söderlund wrote:
> Hi Simon,
>
> On 2017-08-30 09:36:37 +0200, Simon Horman wrote:
> > On Fri, Aug 11, 2017 at 11:57:03AM +0200, Niklas Söderlund wrote:
> > > In order to test Virtual Channels use VC1 for CVBS input from the
> > > adv748x.
> > >
> > > Signed-off-by: Niklas Söderlund
> > > ---
> > > arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > > b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > > index 7b67efcb1d22090a..8047fe1df065d63b 100644
> > > --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > > @@ -41,7 +41,7 @@
> > > };
> > >
> > > chosen {
> > > - bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
> > > + bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp
> > > adv748x.txbvc=1";
> > > stdout-path = "serial0:115200n8";
> > > };
> >
> > Hi Niklas,
> >
> > I'm somewhat surprised to see what appears to be a new module parameter.
> > I'm not going to reject this but did you give consideration to doing this
> > another way?
>
> This is my fault when sending this series out it should be marked as RFC
> as it's stated in the cover-letter. This new module parameter is not
> intended to be unstreamed, not even the driver parts. It's only usage is
> to be able to easy test the multiplexed media pad using the onboard
> Salvator-X components.
>
> >
> > In any case I have marked this as "Deferred" pending acceptance of the
> > driver change. If you think it can go in now then I'm open to discussion.
>
> You can mark it as rejected and forget about it :-)
Thanks for the clarification, I marked it as RFC :)
Re: [PATCH 0/2] arm64: renesas: Add support for R-Car V3M
On Wed, Aug 30, 2017 at 10:21:46AM +0200, Geert Uytterhoeven wrote: > Hi Simon, > > On Wed, Aug 30, 2017 at 9:26 AM, Simon Horman wrote: > > On Mon, Aug 28, 2017 at 09:44:54AM +0200, Simon Horman wrote: > >> On Fri, Aug 25, 2017 at 02:56:48PM +0200, Geert Uytterhoeven wrote: > >> > This patch series adds initial R-Car V3M infrastructure: > >> > 1. SoC DT bindings, > >> > 2. Main Kconfig symbol. > >> > > >> > Both follow the example set by R-Car D3 aka r8a77995, using 5-digit > >> > instead > >> > of 4-digit part numbers. > >> > Alternatively, we could stick to 4-digit part numbers if the fifth digit > >> > is > >> > a zero. > >> > > >> > For your convenience, a branch with more preliminary work (thanks Sergei, > >> > for posting the clock driver!) for testing on v3m/eagle is also available > >> > in the topic/r8a77970-integration branch of my renesas-drivers git > >> > repository at > >> > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git. > >> > > >> > Thanks for your comments! > >> > >> This looks good to me. > >> > >> I am in favour of using the 5-digit scheme for all new R-Car Gen 3 SoCs > >> as it seems the safest option with regards to as yet unknown (to me) part > >> numbers. > > > > Geert, any objections to me applying these? > > I'm happy to wait longer if you prefer. > > It would be good to have an ack from Rob. > No need to hurry. Understood, I will wait.
Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
On Wed, Aug 30, 2017 at 09:35:28AM +0200, jmondi wrote:
> Hi Simon,
>
> On Wed, Aug 30, 2017 at 09:25:42AM +0200, Simon Horman wrote:
> > On Thu, Aug 24, 2017 at 02:53:59PM +0200, jmondi wrote:
> > > Thanks Geert,
> > >
> > > On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> > > > Hi Jacopo,
> > > >
> > >
> > > [snip]
> > >
> > > > > I haven't find any mention in device tree bindings documentation of a
> > > > > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > > > > u-boot and mbed, the interface is reset before any actual
> > > > > configuration is performed. I feel like that should be the place where
> > > > > that gpio is requested and cycled...
> > > >
> > > > Documentation/devicetree/bindings/net/mdio.txt says
> > > >
> > > > These are generic properties that can apply to any MDIO bus.
> > > >
> > >
> > > I have now used mdio defined generic properties
> > >
> > > ðer {
> > > pinctrl-names = "default";
> > > pinctrl-0 = <ðer_pins>;
> > >
> > > status = "okay";
> > >
> > > reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> > > reset-delay-us = <5>;
> > >
> > > renesas,no-ether-link;
> > > phy-handle = <&phy0>;
> > > phy0: ethernet-phy@0 {
> > >reg = <0>;
> > > };
> > > };
> > >
> > > I see the gpio being cycled, but same results as before: device gets
> > > probed, address set, but I cannot ping, device gets probed, address
> > > gets set, but I cannot ping
> > >
> > > --- target ---
> > > [0.00] libphy: sh_mii: probed
> > > [0.00] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000,
> > > 68:14:97:20:97:00, IRQ 22.
> > >
> > > # ifconfig eth0 192.168.100.50
> > > [0.00] Generic PHY e8203000.ethernet-:00: attached PHY
> > > driver [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)
> > >
> > > --- host ---
> > > $ping 192.168.100.50
> > > PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
> > > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > >
> > >
> > > Let's leave this out of the DTS series I've just sent for now, ok?
> >
> > I'm a little confused by this. Am I right in thinking that you don't want
> > this patch applied at this time and may resubmit it or an updated version
> > later? With that understanding I have marked it as "Rejected" for now. Feel
> > free to resubmit when you are ready.
>
> Yes please, you got me right here.
>
> Even if pix muxing is performed "correctly", and I can set ip address
> and probe the interface, not traffic can be exchanged on it.
>
> For this reason, let's not enable it at this time
>
> Is this fine?
Yes, that is fine. Lets not enable things that don't work :)
Re: clk: renesas: rcar-gen3: Status of Z* clocks?
On Wed, Aug 30, 2017 at 11:09:44AM +0200, Geert Uytterhoeven wrote:
> Hi Dirk,
>
> On Tue, Aug 29, 2017 at 12:36 PM, Dirk Behme wrote:
> > On 29.08.2017 11:44, Geert Uytterhoeven wrote:
> >> On Tue, Aug 29, 2017 at 11:15 AM, Dirk Behme
> >> wrote:
> >>>
> >>> But ZG and with this module clock #112 is still missing, no?
> >>>
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.9/rcar-3.5.8&id=aa7b99b06d280e4151e
> >>>
> >>>
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.9/rcar-3.5.8&id=a03bfd8abc9572800fb5043
> >>
> >>
> >> The ZG bits in the FRQCRB register are documented to exist on R-Car D3
> >> only.
> >
> > ... what contradicts
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.9/rcar-3.5.8&id=a03bfd8abc9572800fb5043
> >
> > and the 3DGE module clock in e.g. MSTPSR1 which is documented for H3 and
> > M3-W, too, and Table 8.1a List of Clocks [R-Car H3] ZG -> 3DGE etc.
>
> That commit doesn't use CLK_TYPE_GEN3_ZG, but models ZG as PLL4/4,
> which matches the block diagram and the list of clocks.
> So that one is acceptable (modulo upstream (non)use of the 3DGE module?).
I won't stand in the way of adding ZG support on the basis of non-use.
> Later, ZG is changed to use the non-documented bits, cfr.
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.9/rcar-3.5.8&id=054863e7a5855be9b4652c588c140d49bede4dc4
>
> 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: clk: renesas: rcar-gen3: Status of Z* clocks?
Hi Dirk,
On Tue, Aug 29, 2017 at 12:36 PM, Dirk Behme wrote:
> On 29.08.2017 11:44, Geert Uytterhoeven wrote:
>> On Tue, Aug 29, 2017 at 11:15 AM, Dirk Behme
>> wrote:
>>>
>>> But ZG and with this module clock #112 is still missing, no?
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.9/rcar-3.5.8&id=aa7b99b06d280e4151e
>>>
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.9/rcar-3.5.8&id=a03bfd8abc9572800fb5043
>>
>>
>> The ZG bits in the FRQCRB register are documented to exist on R-Car D3
>> only.
>
> ... what contradicts
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.9/rcar-3.5.8&id=a03bfd8abc9572800fb5043
>
> and the 3DGE module clock in e.g. MSTPSR1 which is documented for H3 and
> M3-W, too, and Table 8.1a List of Clocks [R-Car H3] ZG -> 3DGE etc.
That commit doesn't use CLK_TYPE_GEN3_ZG, but models ZG as PLL4/4,
which matches the block diagram and the list of clocks.
So that one is acceptable (modulo upstream (non)use of the 3DGE module?).
Later, ZG is changed to use the non-documented bits, cfr.
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.9/rcar-3.5.8&id=054863e7a5855be9b4652c588c140d49bede4dc4
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 v1.5 0/6] R-Car DU: Fix IOMMU operation when connected to VSP
On Fri, Dec 09, 2016 at 01:35:06PM +0100, Ulrich Hecht wrote: > Hi! > > This is a slightly updated version of Laurent's series that adds the fix > suggested by Magnus Damm and connects the FCP devices on M3-W to their > IPMMU. It also drops the patches that have already been picked up in the > media tree. > > With this series and an assortment of patches from the renesas-drivers tree ( > iommu/ipmmu-vmsa: Remove platform data handling > iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for context > iommu/ipmmu-vmsa: Break out utlb parsing code > iommu/ipmmu-vmsa: Break out domain allocation code > iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops > iommu/ipmmu-vmsa: ARM and ARM64 archdata access > iommu/ipmmu-vmsa: Drop LPAE Kconfig dependency > iommu/ipmmu-vmsa: Introduce features, break out alias > iommu/ipmmu-vmsa: Add optional root device feature > iommu/ipmmu-vmsa: Enable multi context support > iommu/ipmmu-vmsa: Reuse iommu groups > iommu/ipmmu-vmsa: Make use of IOMMU_OF_DECLARE() > iommu/ipmmu-vmsa: Teach xlate() to skip disabled iommus > iommu/ipmmu-vmsa: IPMMU device is 64-bit bus master > iommu/ipmmu-vmsa: Write IMCTR twice > iommu/ipmmu-vmsa: Make IMBUSCTR setup optional > iommu/ipmmu-vmsa: Allow two bit SL0 > iommu/ipmmu-vmsa: Hook up r8a7795 DT matching code > iommu/ipmmu-vmsa: Add r8a7796 DT binding > iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48 > iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code > arm64: dts: r8a7795: Add IPMMU device nodes > arm64: dts: r8a7795: Hook up SYS-DMAC to IPMMU > arm64: dts: r8a7795: Point FCP devices to IPMMU > arm64: dts: r8a7795: Connect Ethernet AVB to IPMMU > arm64: dts: r8a7796: Add IPMMU device nodes > clk: renesas: r8a7796: Add FCP clocks > clk: renesas: r8a7796: Add VSP clocks > clk: renesas: r8a7796: Add DU and LVDS clocks > drm: rcar-du: Add R8A7796 device support > arm64: dts: renesas: r8a7795: Remove FCP SoC-specific compatible strings > arm64: dts: renesas: r8a7796: Add FCPF and FCPV instances > arm64: dts: renesas: r8a7796: Add VSP instances > arm64: dts: renesas: r8a7796: Add DU device to DT > arm64: dts: renesas: r8a7796-salvator-x: Enable DU > ), I can enable IPMMU on both the H3 and M3-W Salvator-X boards with no ill > effects on the results of the vsp-tests suite. > > CU > Uli > > > Laurent Pinchart (4): > v4l: rcar-fcp: Don't get/put module reference > v4l: rcar-fcp: Add an API to retrieve the FCP device > v4l: vsp1: Add API to map and unmap DRM buffers through the VSP > drm: rcar-du: Map memory through the VSP device > > Ulrich Hecht (2): > v4l: vsp1: Provide display list and VB2 queue with FCP device > arm64: dts: r8a7796: Connect FCP devices to IPMMU Hi Ulrich, I am wondering what the status of this work is.
Re: [PATCH v2 3/3] ARM: dts: r7s72100: Add reset handler
On Fri, Feb 17, 2017 at 11:29:25AM +0100, Geert Uytterhoeven wrote: > On Thu, Feb 16, 2017 at 6:23 PM, Chris Brandt > wrote: > > For the RZ/A1, the only way to do a reset is to overflow the WDT. > > > > Signed-off-by: Chris Brandt > > Reviewed-by: Geert Uytterhoeven Hi Chris, while going through old patches I noticed that I seem to have missed this one. It looks like it needs a rebase. If it is still applicable could you please consider doing so and reposting. Thanks
Re: The RZ/A1 pin controller driver will be broken for 4.13
CC Timur, LinusW, gpio
On Tue, Aug 29, 2017 at 8:56 PM, Chris Brandt wrote:
> Just FYI,
>
> After pulling Geert's new renesas-drivers-2017-08-29-v4.13-rc7, I tried
> testing RZ/A1 and it hangs during boot.
>
> Basically...
>
> [ 110.329579] pinctrl-rza1 fcfe3000.pin-controller: Parsed gpiochip gpio-0-0
> with 6 pins
> [ 112.970056] pinctrl-rza1 fcfe3000.pin-controller: Parsed gpiochip gpio-1-1
> with 16 pins
> (hangs here forever)
>
>
> After some debug, I found that this commit broke the new
> drivers/pinctrl/pinctrl-rza1.c driver.
>
> 108d23e322a2 ("gpiolib: request the gpio before querying its direction")
>
> Looks like it was added for -rc5.
>
> If I revert that one patch, RZ/A1 boots fine.
>
> Since we're at -rc7, I probably won't have time to fix it before the
> release.
It's not in v4.13-rc5, only in -next, for v4.14.
So v4.13 will be fine, and we still have plenty of time to fix the issue.
> Poor RZ/A1 pinctrl driver...it took so long to get into mainline, and
> then it only worked for 1 release.
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 0/2] arm64: renesas: Add support for R-Car V3M
Hi Simon,
On Wed, Aug 30, 2017 at 9:26 AM, Simon Horman wrote:
> On Mon, Aug 28, 2017 at 09:44:54AM +0200, Simon Horman wrote:
>> On Fri, Aug 25, 2017 at 02:56:48PM +0200, Geert Uytterhoeven wrote:
>> > This patch series adds initial R-Car V3M infrastructure:
>> > 1. SoC DT bindings,
>> > 2. Main Kconfig symbol.
>> >
>> > Both follow the example set by R-Car D3 aka r8a77995, using 5-digit instead
>> > of 4-digit part numbers.
>> > Alternatively, we could stick to 4-digit part numbers if the fifth digit is
>> > a zero.
>> >
>> > For your convenience, a branch with more preliminary work (thanks Sergei,
>> > for posting the clock driver!) for testing on v3m/eagle is also available
>> > in the topic/r8a77970-integration branch of my renesas-drivers git
>> > repository at
>> > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
>> >
>> > Thanks for your comments!
>>
>> This looks good to me.
>>
>> I am in favour of using the 5-digit scheme for all new R-Car Gen 3 SoCs
>> as it seems the safest option with regards to as yet unknown (to me) part
>> numbers.
>
> Geert, any objections to me applying these?
> I'm happy to wait longer if you prefer.
It would be good to have an ack from Rob.
No need to hurry.
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 00/09] arm64: dts: r8a7795: IPMMU upstream integration V3
On Mon, Mar 20, 2017 at 05:35:18PM +0900, Magnus Damm wrote: > arm64: dts: r8a7795: IPMMU upstream integration V3 > > [PATCH v3 01/09] arm64: dts: r8a7795: Add IPMMU device nodes > [PATCH v3 02/09] arm64: dts: r8a7795: Tie Audio/SYS-DMAC to IPMMU-DS0/1 and > MP1 > [PATCH v3 03/09] arm64: dts: r8a7795: Point DU/VSPD via FCPVD to IPMMU-VI > [PATCH v3 04/09] arm64: dts: r8a7795: Point FDP1 via FCPF to IPMMU-VP > [PATCH v3 05/09] arm64: dts: r8a7795: Point VSPBC/VSPBD via FCPVB to IPMMU-VP > [PATCH v3 06/09] arm64: dts: r8a7795: Point VSPI via FCPVI to IPMMU-VP > [PATCH v3 07/09] arm64: dts: r8a7795: Connect Ethernet-AVB to IPMMU-DS0 > [PATCH v3 08/09] arm64: dts: r8a7795: Connect SATA to IPMMU-HC > [PATCH v3 09/09] arm64: dts: r8a7795: Enable IPMMU-VI, VP, MP1, DS0, DS1 and > MM > > This series adds DT nodes for IPMMU instances on r8a7795 together with > connections to various r8a7795 on-chip devices such as Audio-DMAC, SYS-DMAC, > Ethernet-AVB, SATA and a bunch of multimedia devices that make use of FCP. > > With these patches applied a white list enabled IPMMU driver may be used > to check silicon revision and then enable IPMMU in the known working cases. > > The recommended IPMMU driver patch stack consists of the following series: > [PATCH v7 00/07] iommu/ipmmu-vmsa: IPMMU multi-arch update V7 > [PATCH v3 00/09] iommu/ipmmu-vmsa: r8a7795 support V3 > [PATCH v3 0/3] iommu/ipmmu-vmsa: r8a7796 support V3 > > The final patch in the series enable IPMMU support for all IPMMU instances > on r8a7795 that are used by IPMMU devices listed above with one exception. > The exception is the SATA device connected to IPMMU-HC which still is disabled > pending IPMMU USB integration support. I expect IPMMU USB integration to be > handled as a second step once this series is agreed on. > > The DT binding for r8a7795 has since long been included in mainline > and this series implements support following such format: > > d4e42e7 iommu/ipmmu-vmsa: Add r8a7795 DT binding > > Changes since V2: > - Added the iommus property before power domains - thanks Geert! > - Added reviewed-by to patch 2 and 3 from Laurent - thanks! > - Re-added Ethernet and FCPVD patches (They were present in V1 but not V2) > - Added remaining FCP devices such as FCPF, FCPVB and FCPVI > - Added SATA device > - Added final patch to enable various IPMMU devices in the DTS file > > Since the DT binding has been merged quite some time ago and the interface > seems stable enough I see no reason not to queue these up for upstream merge. Going through old patches I noticed that I seem to have missed this somehow. I assume its still applicable but wants a rebase. If so could you do so?
Re: [PATCH v2 7/8] arm64: dts: r8a7795-salvator-x: Enable PWM2
On Wed, Aug 30, 2017 at 10:06:30AM +0200, Simon Horman wrote:
> On Thu, Apr 27, 2017 at 05:40:51PM +0300, Laurent Pinchart wrote:
> > Hi Ulrich,
> >
> > Thank you for the patch.
> >
> > On Thursday 27 Apr 2017 16:37:42 Ulrich Hecht wrote:
> > > From: Takeshi Kihara
> > >
> > > This patch enables PWM2 for Salvator-X board on R8A7795 SoC.
> > >
> > > Signed-off-by: Takeshi Kihara
> > > Signed-off-by: Ulrich Hecht
> > > ---
> > > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 12
> > > 1 file changed, 12 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> > > b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index
> > > 8558b27..534b17e
> > > 100644
> > > --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> > > +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> > > @@ -381,6 +381,11 @@
> > > function = "pwm1";
> > > };
> > >
> > > + pwm2_pins: pwm2 {
> > > + groups = "pwm2_a";
> > > + function = "pwm2";
> > > + };
> > > +
> > > sdhi0_pins: sd0 {
> > > groups = "sdhi0_data4", "sdhi0_ctrl";
> > > function = "sdhi0";
> > > @@ -463,6 +468,13 @@
> > > status = "okay";
> > > };
> > >
> > > +&pwm2 {
> > > + /* PMIC DC/DC switching frequency synchronization */
> >
> > Please pardon the stupid question, but if the PWM channel is used by the
> > PMIC,
> > is there a point in enabling it without a PMIC DT node using it ?
>
> Hi Ulrich,
>
> I'm wondering if you have any plans to follow-up on this patch.
And likewise
"[v2,5/8] arm64: dts: r8a7796-salvator-x: Add PWM device support"
Re: [PATCH 20/20] arm64: dts: renesas: salvator: use VC1 for CVBS
Hi Simon,
On 2017-08-30 09:36:37 +0200, Simon Horman wrote:
> On Fri, Aug 11, 2017 at 11:57:03AM +0200, Niklas Söderlund wrote:
> > In order to test Virtual Channels use VC1 for CVBS input from the
> > adv748x.
> >
> > Signed-off-by: Niklas Söderlund
> > ---
> > arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > index 7b67efcb1d22090a..8047fe1df065d63b 100644
> > --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > @@ -41,7 +41,7 @@
> > };
> >
> > chosen {
> > - bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
> > + bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp
> > adv748x.txbvc=1";
> > stdout-path = "serial0:115200n8";
> > };
>
> Hi Niklas,
>
> I'm somewhat surprised to see what appears to be a new module parameter.
> I'm not going to reject this but did you give consideration to doing this
> another way?
This is my fault when sending this series out it should be marked as RFC
as it's stated in the cover-letter. This new module parameter is not
intended to be unstreamed, not even the driver parts. It's only usage is
to be able to easy test the multiplexed media pad using the onboard
Salvator-X components.
>
> In any case I have marked this as "Deferred" pending acceptance of the
> driver change. If you think it can go in now then I'm open to discussion.
You can mark it as rejected and forget about it :-)
--
Regards,
Niklas Söderlund
Re: [PATCH v2 7/8] arm64: dts: r8a7795-salvator-x: Enable PWM2
On Thu, Apr 27, 2017 at 05:40:51PM +0300, Laurent Pinchart wrote:
> Hi Ulrich,
>
> Thank you for the patch.
>
> On Thursday 27 Apr 2017 16:37:42 Ulrich Hecht wrote:
> > From: Takeshi Kihara
> >
> > This patch enables PWM2 for Salvator-X board on R8A7795 SoC.
> >
> > Signed-off-by: Takeshi Kihara
> > Signed-off-by: Ulrich Hecht
> > ---
> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> > b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index 8558b27..534b17e
> > 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> > +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> > @@ -381,6 +381,11 @@
> > function = "pwm1";
> > };
> >
> > + pwm2_pins: pwm2 {
> > + groups = "pwm2_a";
> > + function = "pwm2";
> > + };
> > +
> > sdhi0_pins: sd0 {
> > groups = "sdhi0_data4", "sdhi0_ctrl";
> > function = "sdhi0";
> > @@ -463,6 +468,13 @@
> > status = "okay";
> > };
> >
> > +&pwm2 {
> > + /* PMIC DC/DC switching frequency synchronization */
>
> Please pardon the stupid question, but if the PWM channel is used by the
> PMIC,
> is there a point in enabling it without a PMIC DT node using it ?
Hi Ulrich,
I'm wondering if you have any plans to follow-up on this patch.
[PATCH] pinctrl: sh-pfc: r8a7795: Re-add DRIF support
DRIF support for r8a7795 was initially added with commit 2d775831988
("pinctrl: sh-pfc: r8a7795: Add DRIF support") and later dropped from
the new pfc-r8a7795.c while re-naming the initial pfc-r8a7795.c to
pfc-r8a7795-es1.c in commit b205914c8f8 ("pinctrl: sh-pfc: r8a7795:
Add support for R-Car H3 ES2.0"). As the DRIF doesn't differ, re-add
it here.
Signed-off-by: Dirk Behme
---
Patch based on sh-pfc-for-v4.14-tag1
drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 291 +++
1 file changed, 291 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
index b225bc2f9bea..9e420f7fed72 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
@@ -1659,6 +1659,221 @@ static const unsigned int avb_avtp_capture_b_mux[] = {
AVB_AVTP_CAPTURE_B_MARK,
};
+/* - DRIF0 --- */
+static const unsigned int drif0_ctrl_a_pins[] = {
+ /* CLK, SYNC */
+ RCAR_GP_PIN(6, 8), RCAR_GP_PIN(6, 9),
+};
+static const unsigned int drif0_ctrl_a_mux[] = {
+ RIF0_CLK_A_MARK, RIF0_SYNC_A_MARK,
+};
+static const unsigned int drif0_data0_a_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(6, 10),
+};
+static const unsigned int drif0_data0_a_mux[] = {
+ RIF0_D0_A_MARK,
+};
+static const unsigned int drif0_data1_a_pins[] = {
+ /* D1 */
+ RCAR_GP_PIN(6, 7),
+};
+static const unsigned int drif0_data1_a_mux[] = {
+ RIF0_D1_A_MARK,
+};
+static const unsigned int drif0_ctrl_b_pins[] = {
+ /* CLK, SYNC */
+ RCAR_GP_PIN(5, 0), RCAR_GP_PIN(5, 4),
+};
+static const unsigned int drif0_ctrl_b_mux[] = {
+ RIF0_CLK_B_MARK, RIF0_SYNC_B_MARK,
+};
+static const unsigned int drif0_data0_b_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(5, 1),
+};
+static const unsigned int drif0_data0_b_mux[] = {
+ RIF0_D0_B_MARK,
+};
+static const unsigned int drif0_data1_b_pins[] = {
+ /* D1 */
+ RCAR_GP_PIN(5, 2),
+};
+static const unsigned int drif0_data1_b_mux[] = {
+ RIF0_D1_B_MARK,
+};
+static const unsigned int drif0_ctrl_c_pins[] = {
+ /* CLK, SYNC */
+ RCAR_GP_PIN(5, 12), RCAR_GP_PIN(5, 15),
+};
+static const unsigned int drif0_ctrl_c_mux[] = {
+ RIF0_CLK_C_MARK, RIF0_SYNC_C_MARK,
+};
+static const unsigned int drif0_data0_c_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(5, 13),
+};
+static const unsigned int drif0_data0_c_mux[] = {
+ RIF0_D0_C_MARK,
+};
+static const unsigned int drif0_data1_c_pins[] = {
+ /* D1 */
+ RCAR_GP_PIN(5, 14),
+};
+static const unsigned int drif0_data1_c_mux[] = {
+ RIF0_D1_C_MARK,
+};
+/* - DRIF1 --- */
+static const unsigned int drif1_ctrl_a_pins[] = {
+ /* CLK, SYNC */
+ RCAR_GP_PIN(6, 17), RCAR_GP_PIN(6, 18),
+};
+static const unsigned int drif1_ctrl_a_mux[] = {
+ RIF1_CLK_A_MARK, RIF1_SYNC_A_MARK,
+};
+static const unsigned int drif1_data0_a_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(6, 19),
+};
+static const unsigned int drif1_data0_a_mux[] = {
+ RIF1_D0_A_MARK,
+};
+static const unsigned int drif1_data1_a_pins[] = {
+ /* D1 */
+ RCAR_GP_PIN(6, 20),
+};
+static const unsigned int drif1_data1_a_mux[] = {
+ RIF1_D1_A_MARK,
+};
+static const unsigned int drif1_ctrl_b_pins[] = {
+ /* CLK, SYNC */
+ RCAR_GP_PIN(5, 9), RCAR_GP_PIN(5, 3),
+};
+static const unsigned int drif1_ctrl_b_mux[] = {
+ RIF1_CLK_B_MARK, RIF1_SYNC_B_MARK,
+};
+static const unsigned int drif1_data0_b_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(5, 7),
+};
+static const unsigned int drif1_data0_b_mux[] = {
+ RIF1_D0_B_MARK,
+};
+static const unsigned int drif1_data1_b_pins[] = {
+ /* D1 */
+ RCAR_GP_PIN(5, 8),
+};
+static const unsigned int drif1_data1_b_mux[] = {
+ RIF1_D1_B_MARK,
+};
+static const unsigned int drif1_ctrl_c_pins[] = {
+ /* CLK, SYNC */
+ RCAR_GP_PIN(5, 5), RCAR_GP_PIN(5, 11),
+};
+static const unsigned int drif1_ctrl_c_mux[] = {
+ RIF1_CLK_C_MARK, RIF1_SYNC_C_MARK,
+};
+static const unsigned int drif1_data0_c_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(5, 6),
+};
+static const unsigned int drif1_data0_c_mux[] = {
+ RIF1_D0_C_MARK,
+};
+static const unsigned int drif1_data1_c_pins[] = {
+ /* D1 */
+ RCAR_GP_PIN(5, 10),
+};
+static const unsigned int drif1_data1_c_mux[] = {
+ RIF1_D1_C_MARK,
+};
+/* - DRIF2 --- */
+static const unsigned int drif2_ctrl_a_pins[] = {
+ /* CLK, SYNC */
+ RCAR_GP_PIN(6, 8), RCAR_GP_PIN(6, 9),
+};
+static const unsigned int drif2_ctrl_a_mux[] = {
+ RIF2_CLK_A_MARK, RIF2_SYNC_A_MARK,
+};
+static const unsigned int drif2_data0_a_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(6, 7),
+};
+static const unsigned int drif2_data0_a_mux[] = {
+ RIF2_D0_A_MARK,
Re: [PATCH v2 1/3] ARM: Add definition for monitor mode
On Tue, Jul 18, 2017 at 04:26:25PM +0200, Geert Uytterhoeven wrote: > provides *_MODE definitions for the various processor > modes, but monitor mode was missing. > > Add MON_MODE to avoid code using the hardcoded value. > > Suggested-by: Marc Zyngier > Signed-off-by: Geert Uytterhoeven > --- > ARM maintainers: Please provide your ack, as this is a dependency for a > mach-shmobile patch. > > v2: > - New. > --- > arch/arm/include/uapi/asm/ptrace.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/include/uapi/asm/ptrace.h > b/arch/arm/include/uapi/asm/ptrace.h > index 5af0ed1b825a2aa9..70ff6bf489f31193 100644 > --- a/arch/arm/include/uapi/asm/ptrace.h > +++ b/arch/arm/include/uapi/asm/ptrace.h > @@ -53,6 +53,7 @@ > #endif > #define FIQ_MODE 0x0011 > #define IRQ_MODE 0x0012 > +#define MON_MODE 0x0016 > #define ABT_MODE 0x0017 > #define HYP_MODE 0x001a > #define UND_MODE 0x001b Coming back to this after somewhat of a hiatus. It seems that we are still waiting on an Ack to allow this series to proceed.
RE: [PATCH v2] ARM: dts: r8a7743: add IIC cores to dtsi
> From: Simon Horman [mailto:ho...@verge.net.au] > Sent: 30 August 2017 08:32 > > On Tue, Aug 22, 2017 at 03:23:39PM +0300, Sergei Shtylyov wrote: > > On 08/22/2017 12:10 PM, Chris Paterson wrote: > > > > >>From: Biju Das [mailto:biju@bp.renesas.com] > > >>Sent: 14 August 2017 10:53 > > >> > > >>Signed-off-by: Biju Das > > >>--- > > >>v1-->v2 > > >>Corrected the resets property for i2c6 device node. > > > > > >Are you happy with this version of the patch? > > > > > >Or is the discussion for moving to 'iic' still alive? > > > >Yes, appears so. I'd like the labels to be named iic. > > Chirs, I'm marking this as "Changes Requested" and expecting to see iic in v3 > when you are ready. Sure, thanks.
Re: [PATCH 20/20] arm64: dts: renesas: salvator: use VC1 for CVBS
On Fri, Aug 11, 2017 at 11:57:03AM +0200, Niklas Söderlund wrote:
> In order to test Virtual Channels use VC1 for CVBS input from the
> adv748x.
>
> Signed-off-by: Niklas Söderlund
> ---
> arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> index 7b67efcb1d22090a..8047fe1df065d63b 100644
> --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> @@ -41,7 +41,7 @@
> };
>
> chosen {
> - bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
> + bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp
> adv748x.txbvc=1";
> stdout-path = "serial0:115200n8";
> };
Hi Niklas,
I'm somewhat surprised to see what appears to be a new module parameter.
I'm not going to reject this but did you give consideration to doing this
another way?
In any case I have marked this as "Deferred" pending acceptance of the
driver change. If you think it can go in now then I'm open to discussion.
Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
Hi Simon,
On Wed, Aug 30, 2017 at 09:25:42AM +0200, Simon Horman wrote:
> On Thu, Aug 24, 2017 at 02:53:59PM +0200, jmondi wrote:
> > Thanks Geert,
> >
> > On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> > > Hi Jacopo,
> > >
> >
> > [snip]
> >
> > > > I haven't find any mention in device tree bindings documentation of a
> > > > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > > > u-boot and mbed, the interface is reset before any actual
> > > > configuration is performed. I feel like that should be the place where
> > > > that gpio is requested and cycled...
> > >
> > > Documentation/devicetree/bindings/net/mdio.txt says
> > >
> > > These are generic properties that can apply to any MDIO bus.
> > >
> >
> > I have now used mdio defined generic properties
> >
> > ðer {
> > pinctrl-names = "default";
> > pinctrl-0 = <ðer_pins>;
> >
> > status = "okay";
> >
> > reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> > reset-delay-us = <5>;
> >
> > renesas,no-ether-link;
> > phy-handle = <&phy0>;
> > phy0: ethernet-phy@0 {
> >reg = <0>;
> > };
> > };
> >
> > I see the gpio being cycled, but same results as before: device gets
> > probed, address set, but I cannot ping, device gets probed, address
> > gets set, but I cannot ping
> >
> > --- target ---
> > [0.00] libphy: sh_mii: probed
> > [0.00] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000,
> > 68:14:97:20:97:00, IRQ 22.
> >
> > # ifconfig eth0 192.168.100.50
> > [0.00] Generic PHY e8203000.ethernet-:00: attached PHY
> > driver [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)
> >
> > --- host ---
> > $ping 192.168.100.50
> > PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
> > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> >
> >
> > Let's leave this out of the DTS series I've just sent for now, ok?
>
> I'm a little confused by this. Am I right in thinking that you don't want
> this patch applied at this time and may resubmit it or an updated version
> later? With that understanding I have marked it as "Rejected" for now. Feel
> free to resubmit when you are ready.
Yes please, you got me right here.
Even if pix muxing is performed "correctly", and I can set ip address
and probe the interface, not traffic can be exchanged on it.
For this reason, let's not enable it at this time
Is this fine?
Re: [PATCH v2] ARM: dts: r8a7743: add IIC cores to dtsi
On Tue, Aug 22, 2017 at 03:23:39PM +0300, Sergei Shtylyov wrote: > On 08/22/2017 12:10 PM, Chris Paterson wrote: > > >>From: Biju Das [mailto:biju@bp.renesas.com] > >>Sent: 14 August 2017 10:53 > >> > >>Signed-off-by: Biju Das > >>--- > >>v1-->v2 > >>Corrected the resets property for i2c6 device node. > > > >Are you happy with this version of the patch? > > > >Or is the discussion for moving to 'iic' still alive? > >Yes, appears so. I'd like the labels to be named iic. Chirs, I'm marking this as "Changes Requested" and expecting to see iic in v3 when you are ready.
Re: [PATCH ] ARM: dts: iwg22d-sodimm: Add pinctl support for scif4
On Thu, Aug 17, 2017 at 04:09:09PM +0100, Biju Das wrote: > Adding pinctrl support for scif4 interface. > > Signed-off-by: Biju Das > --- > This patch depends upon the below patch series > [PATCH 0/2] ARM: dts: Add iWave RZ/G1E board support > http://www.spinics.net/lists/devicetree/msg190513.html > > This patch is tested against renesas-dev tag > renesas-devel-20170815-v4.13-rc5 + above dependency patch. Thanks for the dependency and testing details, it is very helpful. I have applied this for v4.15.
Re: [PATCH] arm64: dts: ulcb: Enable display output
On Tue, Aug 22, 2017 at 05:23:26PM +0300, Laurent Pinchart wrote: > The DU is already wired up to the HDMI encoder, all we need to do is > enable it. > > Signed-off-by: Laurent Pinchart > --- > arch/arm64/boot/dts/renesas/ulcb.dtsi | 4 > 1 file changed, 4 insertions(+) > > This patch has been tested on the M3-W ULCB in Magnus' board farm. As no > display is connected to the HDMI output testing was limited, to probing the > device and verifying that it can be accessed from userspace. > > Tests on the H3 ES1.1 and H3 ES2.0 ULCBs were less successful as I couldn't > get the boards to boot properly, but they failed without this patch as well, > so I don't think it should be a blocker. Thanks, applied.
Re: [PATCH 0/2] arm64: renesas: Add support for R-Car V3M
On Mon, Aug 28, 2017 at 09:44:54AM +0200, Simon Horman wrote: > On Fri, Aug 25, 2017 at 02:56:48PM +0200, Geert Uytterhoeven wrote: > > Hi all, > > > > This patch series adds initial R-Car V3M infrastructure: > > 1. SoC DT bindings, > > 2. Main Kconfig symbol. > > > > Both follow the example set by R-Car D3 aka r8a77995, using 5-digit instead > > of 4-digit part numbers. > > Alternatively, we could stick to 4-digit part numbers if the fifth digit is > > a zero. > > > > For your convenience, a branch with more preliminary work (thanks Sergei, > > for posting the clock driver!) for testing on v3m/eagle is also available > > in the topic/r8a77970-integration branch of my renesas-drivers git > > repository at > > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git. > > > > Thanks for your comments! > > This looks good to me. > > I am in favour of using the 5-digit scheme for all new R-Car Gen 3 SoCs > as it seems the safest option with regards to as yet unknown (to me) part > numbers. Geert, any objections to me applying these? I'm happy to wait longer if you prefer.
Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
On Thu, Aug 24, 2017 at 02:53:59PM +0200, jmondi wrote:
> Thanks Geert,
>
> On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> > Hi Jacopo,
> >
>
> [snip]
>
> > > I haven't find any mention in device tree bindings documentation of a
> > > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > > u-boot and mbed, the interface is reset before any actual
> > > configuration is performed. I feel like that should be the place where
> > > that gpio is requested and cycled...
> >
> > Documentation/devicetree/bindings/net/mdio.txt says
> >
> > These are generic properties that can apply to any MDIO bus.
> >
>
> I have now used mdio defined generic properties
>
> ðer {
> pinctrl-names = "default";
> pinctrl-0 = <ðer_pins>;
>
> status = "okay";
>
> reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> reset-delay-us = <5>;
>
> renesas,no-ether-link;
> phy-handle = <&phy0>;
> phy0: ethernet-phy@0 {
>reg = <0>;
> };
> };
>
> I see the gpio being cycled, but same results as before: device gets
> probed, address set, but I cannot ping, device gets probed, address
> gets set, but I cannot ping
>
> --- target ---
> [0.00] libphy: sh_mii: probed
> [0.00] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000,
> 68:14:97:20:97:00, IRQ 22.
>
> # ifconfig eth0 192.168.100.50
> [0.00] Generic PHY e8203000.ethernet-:00: attached PHY driver
> [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)
>
> --- host ---
> $ping 192.168.100.50
> PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
> >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
>
>
> Let's leave this out of the DTS series I've just sent for now, ok?
I'm a little confused by this. Am I right in thinking that you don't want
this patch applied at this time and may resubmit it or an updated version
later? With that understanding I have marked it as "Rejected" for now. Feel
free to resubmit when you are ready.
Re: [PATCH RESEND] mmc: renesas_sdhi: Add r8a7743/5 support
On Tue, Aug 29, 2017 at 03:05:53PM +, Chris Paterson wrote: > > > > From: Wolfram Sang [mailto:w...@the-dreams.de] > > Sent: 29 August 2017 15:59 > > > > On Tue, Aug 29, 2017 at 02:52:06PM +0100, Biju Das wrote: > > > Add support for r8a7743/5 SoC.Renesas RZ/G1[ME] (R8A7743/5) SDHI is > > > identical to the R-Car Gen2 family. > > > > > > Signed-off-by: Biju Das > > > --- > > > DT binding patch for r8a7743/5 SoC is applied for mmc next. But the > > > driver patch is still not applied for mmc next.So resending the driver > > > patch. > > > > Didn't Chris Paterson volunteer to write a new patch introducing Gen2 > > generic > > compatibles? Or did I misunderstand? > > I did :) > > But after some off-ML discussion with Geert/Simon I decided to leave it to > Simon as he's been doing a lot of similar work for all of the R-Car related > drivers. > > This may not happen immediately, and we already have the bindings/DT patches > accepted based on this patch, hence the repost. > > Sorry for the confusion! I confirm the above conversation. In my experience rolling out fallback compat strings takes time as there are often unexpected complications. Perhaps that is not the case here but in my opinion it would be better if support for these new SoCs didn't have an extra dependency. After all the goal of the fallback compat strings is to make adding new SoCs easier not harder.
Re: [PATCH RESEND] mmc: renesas_sdhi: Add r8a7743/5 support
On Tue, Aug 29, 2017 at 02:52:06PM +0100, Biju Das wrote:
> Add support for r8a7743/5 SoC.Renesas RZ/G1[ME] (R8A7743/5) SDHI
> is identical to the R-Car Gen2 family.
>
> Signed-off-by: Biju Das
Acked-by: Simon Horman
> ---
> DT binding patch for r8a7743/5 SoC is applied for mmc next. But the driver
> patch
> is still not applied for mmc next.So resending the driver patch.
>
> This patch is compiled and tested against mmc/next.
>
> drivers/mmc/host/renesas_sdhi_sys_dmac.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> index 160fbb2..df44654 100644
> --- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> @@ -98,6 +98,8 @@
> { .compatible = "renesas,sdhi-r7s72100", .data = &of_rz_compatible, },
> { .compatible = "renesas,sdhi-r8a7778", .data =
> &of_rcar_gen1_compatible, },
> { .compatible = "renesas,sdhi-r8a7779", .data =
> &of_rcar_gen1_compatible, },
> + { .compatible = "renesas,sdhi-r8a7743", .data =
> &of_rcar_gen2_compatible, },
> + { .compatible = "renesas,sdhi-r8a7745", .data =
> &of_rcar_gen2_compatible, },
> { .compatible = "renesas,sdhi-r8a7790", .data =
> &of_rcar_gen2_compatible, },
> { .compatible = "renesas,sdhi-r8a7791", .data =
> &of_rcar_gen2_compatible, },
> { .compatible = "renesas,sdhi-r8a7792", .data =
> &of_rcar_gen2_compatible, },
> --
> 1.9.1
>
Re: [PATCH v2 0/2] ARM: dts: iwg20d-q7: Add Chosen node and RTC support
On Tue, Aug 29, 2017 at 10:56:21AM +0100, Biju Das wrote: > Hello, > > Resending this patches because of the previous merge issues. > > This series has been tested against renesas dev tag > renesas-devel-20170828-v4.13-rc7. > > Biju Das (2): > ARM: dts: iwg20d-q7: Add chosen node > ARM: dts: iwg20d-q7: Add RTC support Thanks, applied.
