Re: [PATCH v2] phy: renesas: rcar-gen3-usb2: follow the hardware manual procedure
On 30/11/18 12:39 PM, Yoshihiro Shimoda wrote: >> From: Yoshihiro Shimoda, Sent: Friday, November 30, 2018 4:01 PM >> > >> Also, this is the first email I send after changing the email server >> to avoid using quoted-printable encoding. > > This seems to work :) > https://lore.kernel.org/lkml/1543561257-27594-1-git-send-email-yoshihiro.shimoda...@renesas.com/raw merged now, thanks. -Kishon > > Best regards, > Yoshihiro Shimoda >
Re: [PATCH v2 0/2] net: phy: micrel: add tobling phy reset
From: Florian Fainelli Date: Mon, 3 Dec 2018 15:24:43 -0800 > Meh! I guess we should be faster at reviewing stuff :/ Sorry, it was posted last Wednesday!
Re: [PATCH v2 0/2] net: phy: micrel: add tobling phy reset
On 12/3/18 3:20 PM, David Miller wrote: > From: Yoshihiro Shimoda > Date: Wed, 28 Nov 2018 09:02:41 + > >> This patch set is for R-Car Gen3 Salvator-XS boards. If we do >> the following method, the phy cannot link up correctly. >> >> 1) Kernel boots by using initramfs. >> --> No open the nic, so phy_device_register() and phy_probe() >> deasserts the reset. >> 2) Kernel enters the suspend. >> --> So, keep the reset signal as deassert. >> --> On R-Car Salvator-XS board, unfortunately, the board power is >> turned off. >> 3) Kernel returns from suspend. >> 4) ifconfig eth0 up >> --> Then, since edge signal of the reset doesn't happen, >> it cannot link up. >> 5) ifconfig eth0 down >> 6) ifconfig eth0 up >> --> In this case, it can link up. >> >> When resolving this issue after I got feedback from Andrew and Heiner, >> I found an issue that the phy_device.c didn't call phy_resume() >> if the PHY was not attached. So, patch 1 fixes it and add toggling >> the phy reset to the micrel phy driver. >> >> Changes from v1 (as RFC): >> - No remove the current code of phy_device.c to avoid any side effects. >> - Fix the mdio_bus_phy_resume() in phy_device.c. >> - Add toggling the phy reset in micrel.c if the PHY is not attached. > > Series applied, thank you. Meh! I guess we should be faster at reviewing stuff :/ -- Florian
Re: [PATCH v2 0/2] net: phy: micrel: add tobling phy reset
From: Yoshihiro Shimoda Date: Wed, 28 Nov 2018 09:02:41 + > This patch set is for R-Car Gen3 Salvator-XS boards. If we do > the following method, the phy cannot link up correctly. > > 1) Kernel boots by using initramfs. > --> No open the nic, so phy_device_register() and phy_probe() > deasserts the reset. > 2) Kernel enters the suspend. > --> So, keep the reset signal as deassert. > --> On R-Car Salvator-XS board, unfortunately, the board power is > turned off. > 3) Kernel returns from suspend. > 4) ifconfig eth0 up > --> Then, since edge signal of the reset doesn't happen, > it cannot link up. > 5) ifconfig eth0 down > 6) ifconfig eth0 up > --> In this case, it can link up. > > When resolving this issue after I got feedback from Andrew and Heiner, > I found an issue that the phy_device.c didn't call phy_resume() > if the PHY was not attached. So, patch 1 fixes it and add toggling > the phy reset to the micrel phy driver. > > Changes from v1 (as RFC): > - No remove the current code of phy_device.c to avoid any side effects. > - Fix the mdio_bus_phy_resume() in phy_device.c. > - Add toggling the phy reset in micrel.c if the PHY is not attached. Series applied, thank you.
Re: [PATCH 1/2] ARM: dts: stout: Convert to new LVDS DT bindings
Hi Marek,
On Tuesday, 4 December 2018 00:24:32 EET Marek Vasut wrote:
> On 12/03/2018 10:48 PM, Laurent Pinchart wrote:
> > On Monday, 3 December 2018 17:12:41 EET Geert Uytterhoeven wrote:
> >> As of commit 6d2ca85279becdff ("dt-bindings: display: renesas: Deprecate
> >> LVDS support in the DU bindings"), the internal LVDS encoder has DT
> >> bindings separate from the DU. The Lager device tree was ported over to
> >> the new model, but the Stout device tree was forgotten.
> >>
> >> Fixes: 15a1ff30d8f9bd83 ("ARM: dts: r8a7790: Convert to new LVDS DT
> >> bindings") Signed-off-by: Geert Uytterhoeven
> >> ---
> >> Compile-tested only.
> >
> > I can't test the patch either but it looks fine to me.
> >
> > Reviewed-by: Laurent Pinchart
> >
> > I assume you will send this directly to Simon, so I don't plan to take the
> > patch in my tree.
>
> I have a Stout if you need me to test something.
Could you test HDMI output ? We just need to ensure that everything is probed
correctly, so display anything on the HDMI output will do.
--
Regards,
Laurent Pinchart
Re: [PATCH 1/2] ARM: dts: stout: Convert to new LVDS DT bindings
On 12/03/2018 10:48 PM, Laurent Pinchart wrote:
> Hi Geert,
Hi,
> Thank you for the patch.
>
> On Monday, 3 December 2018 17:12:41 EET Geert Uytterhoeven wrote:
>> As of commit 6d2ca85279becdff ("dt-bindings: display: renesas: Deprecate
>> LVDS support in the DU bindings"), the internal LVDS encoder has DT
>> bindings separate from the DU. The Lager device tree was ported over to
>> the new model, but the Stout device tree was forgotten.
>>
>> Fixes: 15a1ff30d8f9bd83 ("ARM: dts: r8a7790: Convert to new LVDS DT
>> bindings") Signed-off-by: Geert Uytterhoeven
>> ---
>> Compile-tested only.
>
> I can't test the patch either but it looks fine to me.
>
> Reviewed-by: Laurent Pinchart
>
> I assume you will send this directly to Simon, so I don't plan to take the
> patch in my tree.
I have a Stout if you need me to test something.
--
Best regards,
Marek Vasut
Re: [PATCH v2 00/30] v4l: add support for multiplexed streams
Hi Niklas, On Fri, Nov 02, 2018 at 12:31:14AM +0100, Niklas Söderlund wrote: > Hi all, > > This series adds support for multiplexed streams within a media device > link. The use-case addressed in this series covers CSI-2 Virtual > Channels on the Renesas R-Car Gen3 platforms. The v4l2 changes have been > a joint effort between Sakari and Laurent and floating around for some > time [1]. > > I have added driver support for the devices used on the Renesas Gen3 > platforms, a ADV7482 connected to the R-Car CSI-2 receiver. With these > changes I can control which of the analog inputs of the ADV7482 the > video source is captured from and on which CSI-2 virtual channel the > video is transmitted on to the R-Car CSI-2 receiver. > > The series adds two new subdev IOCTLs [GS]_ROUTING which allows > user-space to get and set routes inside a subdevice. I have added RFC > support for these to v4l-utils [2] which can be used to test this > series, example: > > Check the internal routing of the adv748x csi-2 transmitter: > v4l2-ctl -d /dev/v4l-subdev24 --get-routing > 0/0 -> 1/0 [ENABLED] > 0/0 -> 1/1 [] > 0/0 -> 1/2 [] > 0/0 -> 1/3 [] > > > Select that video should be outputed on VC 2 and check the result: > $ v4l2-ctl -d /dev/v4l-subdev24 --set-routing '0/0 -> 1/2 [1]' > > $ v4l2-ctl -d /dev/v4l-subdev24 --get-routing > 0/0 -> 1/0 [] > 0/0 -> 1/1 [] > 0/0 -> 1/2 [ENABLED] > 0/0 -> 1/3 [] > > This series is tested on R-Car M3-N and for your testing needs this > series is available at > > git://git.ragnatech.se/linux v4l2/mux > > * Changes since v1 > - Rebased on latest media-tree. > - Incorporated changes to patch 'v4l: subdev: compat: Implement handling > for VIDIOC_SUBDEV_[GS]_ROUTING' by Sakari. > - Added review tags. I was looking at the patches and they seem very nice to me. It's not that I've written most of them, but I still. X-) I noticed that the new [GS]_ROUTING interface has no documentation currently. Could you write it? Also what I'd like to see is the media graph of a device that is driven by these drivers. That'd help to better understand the use case also for those who haven't worked with the patches. Thanks. -- Kind regards, Sakari Ailus sakari.ai...@linux.intel.com
Re: [PATCH 2/2] arm64: dts: renesas: r8a7796: salvator-xs: Convert to new LVDS DT bindings
Hi Geert,
Thank you for the patch.
On Monday, 3 December 2018 17:12:42 EET Geert Uytterhoeven wrote:
> As of commit 6d2ca85279becdff ("dt-bindings: display: renesas: Deprecate
> LVDS support in the DU bindings"), the internal LVDS encoder has DT
> bindings separate from the DU. The device trees for all R-Car H3 and
> M3-W development boards were ported over to the new model, but
> Salvator-XS boards equipped with an R-Car M3-W SoC were forgotten.
>
> Fixes: 58e8ed2ee9abe718 ("arm64: dts: renesas: Convert to new LVDS DT
> bindings") Signed-off-by: Geert Uytterhoeven
> ---
> Compile-tested only.
I can't test the patch either but it looks fine to me.
Reviewed-by: Laurent Pinchart
I assume you will send this directly to Simon, so I don't plan to take the
patch in my tree.
> ---
> arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts
> b/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts index
> 8860be65342e4f38..31f12059355ee02b 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts
> @@ -29,11 +29,10 @@
> clocks = <&cpg CPG_MOD 724>,
><&cpg CPG_MOD 723>,
><&cpg CPG_MOD 722>,
> - <&cpg CPG_MOD 727>,
><&versaclock6 1>,
><&x21_clk>,
><&versaclock6 2>;
> - clock-names = "du.0", "du.1", "du.2", "lvds.0",
> + clock-names = "du.0", "du.1", "du.2",
> "dclkin.0", "dclkin.1", "dclkin.2";
> };
--
Regards,
Laurent Pinchart
Re: [PATCH 1/2] ARM: dts: stout: Convert to new LVDS DT bindings
Hi Geert,
Thank you for the patch.
On Monday, 3 December 2018 17:12:41 EET Geert Uytterhoeven wrote:
> As of commit 6d2ca85279becdff ("dt-bindings: display: renesas: Deprecate
> LVDS support in the DU bindings"), the internal LVDS encoder has DT
> bindings separate from the DU. The Lager device tree was ported over to
> the new model, but the Stout device tree was forgotten.
>
> Fixes: 15a1ff30d8f9bd83 ("ARM: dts: r8a7790: Convert to new LVDS DT
> bindings") Signed-off-by: Geert Uytterhoeven
> ---
> Compile-tested only.
I can't test the patch either but it looks fine to me.
Reviewed-by: Laurent Pinchart
I assume you will send this directly to Simon, so I don't plan to take the
patch in my tree.
> ---
> arch/arm/boot/dts/r8a7790-stout.dts | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/r8a7790-stout.dts
> b/arch/arm/boot/dts/r8a7790-stout.dts index
> 629da4cee1b971d6..7a7d3b84d1a6b21d 100644
> --- a/arch/arm/boot/dts/r8a7790-stout.dts
> +++ b/arch/arm/boot/dts/r8a7790-stout.dts
> @@ -94,9 +94,8 @@
> status = "okay";
>
> clocks = <&cpg CPG_MOD 724>, <&cpg CPG_MOD 723>, <&cpg CPG_MOD 722>,
> - <&cpg CPG_MOD 726>, <&cpg CPG_MOD 725>,
><&osc1_clk>;
> - clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1", "dclkin.0";
> + clock-names = "du.0", "du.1", "du.2", "dclkin.0";
>
> ports {
> port@0 {
> @@ -104,11 +103,21 @@
> remote-endpoint = <&adv7511_in>;
> };
> };
> + };
> +};
> +
> +&lvds0 {
> + ports {
> port@1 {
> lvds_connector0: endpoint {
> };
> };
> - port@2 {
> + };
> +};
> +
> +&lvds1 {
> + ports {
> + port@1 {
> lvds_connector1: endpoint {
> };
> };
--
Regards,
Laurent Pinchart
Re: [PATCH 14/14] gpio: pca953x: Restore registers after suspend/resume cycle
On 12/03/2018 06:55 PM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Sun, Dec 2, 2018 at 8:36 PM Marek Vasut wrote:
>> It is possible that the PCA953x is powered down during suspend.
>> Use regmap cache to assure the registers in the PCA953x are in
>> line with the driver state after resume.
>>
>> Signed-off-by: Marek Vasut
>
> Thanks for your series!
>
> Background info: the main motivation for this series is to make sure SATA
> keeps working after system suspend/resume on the Salvator-XS development
> board, where the SATA functionality is configured using a gpio hog.
>
> With your series applied, the SATA link seems to be functional after resume.
> Dmesg difference:
>
> ata1: link resume succeeded after 1 retries
> -ata1: SATA link down (SStatus 0 SControl 300)
> -ata1: link resume succeeded after 1 retries
> -ata1: SATA link down (SStatus 0 SControl 300)
> -ata1: link resume succeeded after 1 retries
> -ata1: SATA link down (SStatus 0 SControl 300)
> -ata1.00: disabled
> -sd 0:0:0:0: rejecting I/O to offline device
> +ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> +ata1.00: configured for UDMA/133
>
> However, when trying to read from an attached hard drive, it fails:
>
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata1.00: failed command: READ DMA
> ata1.00: cmd c8/00:20:00:00:00/00:00:00:00:00/e0 tag 0 dma 16384 in
> res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: hard resetting link
> ata1: link resume succeeded after 1 retries
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: configured for UDMA/133
> sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00
> driverbyte=0x08
> sd 0:0:0:0: [sda] tag#0 Sense Key : 0x5 [current]
> sd 0:0:0:0: [sda] tag#0 ASC=0x21 ASCQ=0x4
> sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 00 00 00 00 20 00
> print_req_error: I/O error, dev sda, sector 0
> ata1: EH complete
> ...
> Buffer I/O error on dev sda, logical block 0, async page read
>
> Does SATA work for you after resume!
Yes!
http://paste.debian.net/1054228/
> This could still be an issue in the sata_rcar driver.
I wonder if this has to do with the SATA link being cut off by the GPIO
mux at a bad time OR restored at a bad time.
--
Best regards,
Marek Vasut
[PATCH v2 26/34] dt-bindings: arm: Convert Renesas board/soc bindings to json-schema
Convert Renesas SoC bindings to DT schema format using json-schema. Cc: Simon Horman Cc: Magnus Damm Cc: Mark Rutland Cc: linux-renesas-soc@vger.kernel.org Cc: devicet...@vger.kernel.org Signed-off-by: Rob Herring --- .../devicetree/bindings/arm/shmobile.txt | 151 .../devicetree/bindings/arm/shmobile.yaml | 218 ++ 2 files changed, 218 insertions(+), 151 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt deleted file mode 100644 index 5f18ce9cdbb8.. --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ /dev/null @@ -1,151 +0,0 @@ -Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings - - -SoCs: - - - Emma Mobile EV2 -compatible = "renesas,emev2" - - RZ/A1H (R7S72100) -compatible = "renesas,r7s72100" - - RZ/A2 (R7S9210) -compatible = "renesas,r7s9210" - - SH-Mobile AG5 (R8A73A00/SH73A0) -compatible = "renesas,sh73a0" - - R-Mobile APE6 (R8A73A40) -compatible = "renesas,r8a73a4" - - R-Mobile A1 (R8A77400) -compatible = "renesas,r8a7740" - - RZ/G1H (R8A77420) -compatible = "renesas,r8a7742" - - RZ/G1M (R8A77430) -compatible = "renesas,r8a7743" - - RZ/G1N (R8A77440) -compatible = "renesas,r8a7744" - - RZ/G1E (R8A77450) -compatible = "renesas,r8a7745" - - RZ/G1C (R8A77470) -compatible = "renesas,r8a77470" - - RZ/G2M (R8A774A1) -compatible = "renesas,r8a774a1" - - RZ/G2E (R8A774C0) -compatible = "renesas,r8a774c0" - - R-Car M1A (R8A77781) -compatible = "renesas,r8a7778" - - R-Car H1 (R8A77790) -compatible = "renesas,r8a7779" - - R-Car H2 (R8A77900) -compatible = "renesas,r8a7790" - - R-Car M2-W (R8A77910) -compatible = "renesas,r8a7791" - - R-Car V2H (R8A77920) -compatible = "renesas,r8a7792" - - R-Car M2-N (R8A77930) -compatible = "renesas,r8a7793" - - R-Car E2 (R8A77940) -compatible = "renesas,r8a7794" - - R-Car H3 (R8A77950) -compatible = "renesas,r8a7795" - - R-Car M3-W (R8A77960) -compatible = "renesas,r8a7796" - - R-Car M3-N (R8A77965) -compatible = "renesas,r8a77965" - - R-Car V3M (R8A77970) -compatible = "renesas,r8a77970" - - R-Car V3H (R8A77980) -compatible = "renesas,r8a77980" - - R-Car E3 (R8A77990) -compatible = "renesas,r8a77990" - - R-Car D3 (R8A77995) -compatible = "renesas,r8a77995" - - RZ/N1D (R9A06G032) -compatible = "renesas,r9a06g032" - -Boards: - - - Alt (RTP0RC7794SEB00010S) -compatible = "renesas,alt", "renesas,r8a7794" - - APE6-EVM -compatible = "renesas,ape6evm", "renesas,r8a73a4" - - Atmark Techno Armadillo-800 EVA -compatible = "renesas,armadillo800eva", "renesas,r8a7740" - - Blanche (RTP0RC7792SEB00010S) -compatible = "renesas,blanche", "renesas,r8a7792" - - BOCK-W -compatible = "renesas,bockw", "renesas,r8a7778" - - Condor (RTP0RC77980SEB0010SS/RTP0RC77980SEB0010SA01) -compatible = "renesas,condor", "renesas,r8a77980" - - Draak (RTP0RC77995SEB0010S) -compatible = "renesas,draak", "renesas,r8a77995" - - Eagle (RTP0RC77970SEB0010S) -compatible = "renesas,eagle", "renesas,r8a77970" - - Ebisu (RTP0RC77990SEB0010S) -compatible = "renesas,ebisu", "renesas,r8a77990" - - Genmai (RTK772100BC0BR) -compatible = "renesas,genmai", "renesas,r7s72100" - - GR-Peach (X28A-M01-E/F) -compatible = "renesas,gr-peach", "renesas,r7s72100" - - Gose (RTP0RC7793SEB00010S) -compatible = "renesas,gose", "renesas,r8a7793" - - H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1)) -H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0)) -compatible = "renesas,h3ulcb", "renesas,r8a7795" - - Henninger -compatible = "renesas,henninger", "renesas,r8a7791" - - iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S) -compatible = "iwave,g23s", "renesas,r8a77470" - - iWave Systems RZ/G1E SODIMM SOM Development Platform (iW-RainboW-G22D) -compatible = "iwave,g22d", "iwave,g22m", "renesas,r8a7745" - - iWave Systems RZ/G1E SODIMM System On Module (iW-RainboW-G22M-SM) -compatible = "iwave,g22m", "renesas,r8a7745" - - iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven) -compatible = "iwave,g20d", "iwave,g20m", "renesas,r8a7743" - - iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven) -compatible = "iwave,g20m", "renesas,r8a7743" - - Kingfisher (SBEV-RCAR-KF-M03) -compatible = "shimafuji,kingfisher" - - Koelsch (RTP0RC7791SEB00010S) -compatible = "renesas,koelsch", "renesas,r8a7791" - - Kyoto Microcomputer Co. KZM-A9-Dual -compatible = "renesas,kzm9d", "renesas,emev2" - - Kyoto Microcomputer Co. KZM-A9-GT -compatible = "renesas,kzm9
[PATCH v2 25/34] dt-bindings: arm: renesas: Move 'renesas,prr' binding to its own doc
In preparation to convert board-level bindings to json-schema, move
various misc SoC bindings out to their own file.
Cc: Mark Rutland
Cc: Simon Horman
Cc: Magnus Damm
Cc: devicet...@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
Signed-off-by: Rob Herring
---
.../devicetree/bindings/arm/renesas,prr.txt | 20 +++
.../devicetree/bindings/arm/shmobile.txt | 18 -
2 files changed, 20 insertions(+), 18 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/renesas,prr.txt
diff --git a/Documentation/devicetree/bindings/arm/renesas,prr.txt
b/Documentation/devicetree/bindings/arm/renesas,prr.txt
new file mode 100644
index ..08e482e953ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/renesas,prr.txt
@@ -0,0 +1,20 @@
+Renesas Product Register
+
+Most Renesas ARM SoCs have a Product Register or Boundary Scan ID Register that
+allows to retrieve SoC product and revision information. If present, a device
+node for this register should be added.
+
+Required properties:
+ - compatible: Must be one of:
+"renesas,prr"
+"renesas,bsid"
+ - reg: Base address and length of the register block.
+
+
+Examples
+
+
+ prr: chipid@ff44 {
+ compatible = "renesas,prr";
+ reg = <0 0xff44 0 4>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt
b/Documentation/devicetree/bindings/arm/shmobile.txt
index 58c4256d37a3..5f18ce9cdbb8 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -149,21 +149,3 @@ Boards:
compatible = "renesas,v3msk", "renesas,r8a77970"
- Wheat (RTP0RC7792ASKBJE)
compatible = "renesas,wheat", "renesas,r8a7792"
-
-
-Most Renesas ARM SoCs have a Product Register or Boundary Scan ID Register that
-allows to retrieve SoC product and revision information. If present, a device
-node for this register should be added.
-
-Required properties:
- - compatible: Must be "renesas,prr" or "renesas,bsid"
- - reg: Base address and length of the register block.
-
-
-Examples
-
-
- prr: chipid@ff44 {
- compatible = "renesas,prr";
- reg = <0 0xff44 0 4>;
- };
--
2.19.1
[PATCH v2] mmc: document 'Reliable Write' bit in uapi header
If we use it this way, people should know about it. Also, replace
true/false with nonzero/zero because the flag is not strictly a bool
anymore.
Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
---
Change since V1:
* reworded first line of comment as well. Thanks, Geert!
Still not super happy about shifting into the sign bit, but yeah...
don't break userspace, I guess.
include/uapi/linux/mmc/ioctl.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/mmc/ioctl.h b/include/uapi/linux/mmc/ioctl.h
index 45f369dc0a42..00c08120f3ba 100644
--- a/include/uapi/linux/mmc/ioctl.h
+++ b/include/uapi/linux/mmc/ioctl.h
@@ -5,7 +5,10 @@
#include
struct mmc_ioc_cmd {
- /* Implies direction of data. true = write, false = read */
+ /*
+* Direction of data: nonzero = write, zero = read.
+* Bit 31 selects 'Reliable Write' for RPMB.
+*/
int write_flag;
/* Application-specific command. true = precede with CMD55 */
--
2.11.0
Re: [PATCH 14/14] gpio: pca953x: Restore registers after suspend/resume cycle
Hi Marek,
On Sun, Dec 2, 2018 at 8:36 PM Marek Vasut wrote:
> It is possible that the PCA953x is powered down during suspend.
> Use regmap cache to assure the registers in the PCA953x are in
> line with the driver state after resume.
>
> Signed-off-by: Marek Vasut
Thanks for your series!
Background info: the main motivation for this series is to make sure SATA
keeps working after system suspend/resume on the Salvator-XS development
board, where the SATA functionality is configured using a gpio hog.
With your series applied, the SATA link seems to be functional after resume.
Dmesg difference:
ata1: link resume succeeded after 1 retries
-ata1: SATA link down (SStatus 0 SControl 300)
-ata1: link resume succeeded after 1 retries
-ata1: SATA link down (SStatus 0 SControl 300)
-ata1: link resume succeeded after 1 retries
-ata1: SATA link down (SStatus 0 SControl 300)
-ata1.00: disabled
-sd 0:0:0:0: rejecting I/O to offline device
+ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
+ata1.00: configured for UDMA/133
However, when trying to read from an attached hard drive, it fails:
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.00: failed command: READ DMA
ata1.00: cmd c8/00:20:00:00:00/00:00:00:00:00/e0 tag 0 dma 16384 in
res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: hard resetting link
ata1: link resume succeeded after 1 retries
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/133
sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00
driverbyte=0x08
sd 0:0:0:0: [sda] tag#0 Sense Key : 0x5 [current]
sd 0:0:0:0: [sda] tag#0 ASC=0x21 ASCQ=0x4
sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 00 00 00 00 20 00
print_req_error: I/O error, dev sda, sector 0
ata1: EH complete
...
Buffer I/O error on dev sda, logical block 0, async page read
Does SATA work for you after resume!
This could still be an issue in the sata_rcar driver.
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] mmc: document 'Reliable Write' bit in uapi header
> > Signed-off-by: Wolfram Sang > > Reviewed-by: Geert Uytterhoeven Thanks, Geert! > > - /* Implies direction of data. true = write, false = read */ > > + /* > > +* Implies direction of data. true = write, false = read. > > nonzero = write, zero = read? Yes, even better. Will update. > > +* Bit 31 selects 'Reliable Write' for RPMB. > > Perhaps having a #define for this would be nice? > Can also be used by the driver, instead of 1 << 31, which some static > analyzers may complain about. Maybe. Should be an incremental patch then, I'd say. signature.asc Description: PGP signature
[PATCH 1/2] ARM: dts: stout: Convert to new LVDS DT bindings
As of commit 6d2ca85279becdff ("dt-bindings: display: renesas: Deprecate
LVDS support in the DU bindings"), the internal LVDS encoder has DT
bindings separate from the DU. The Lager device tree was ported over to
the new model, but the Stout device tree was forgotten.
Fixes: 15a1ff30d8f9bd83 ("ARM: dts: r8a7790: Convert to new LVDS DT bindings")
Signed-off-by: Geert Uytterhoeven
---
Compile-tested only.
---
arch/arm/boot/dts/r8a7790-stout.dts | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790-stout.dts
b/arch/arm/boot/dts/r8a7790-stout.dts
index 629da4cee1b971d6..7a7d3b84d1a6b21d 100644
--- a/arch/arm/boot/dts/r8a7790-stout.dts
+++ b/arch/arm/boot/dts/r8a7790-stout.dts
@@ -94,9 +94,8 @@
status = "okay";
clocks = <&cpg CPG_MOD 724>, <&cpg CPG_MOD 723>, <&cpg CPG_MOD 722>,
-<&cpg CPG_MOD 726>, <&cpg CPG_MOD 725>,
<&osc1_clk>;
- clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1", "dclkin.0";
+ clock-names = "du.0", "du.1", "du.2", "dclkin.0";
ports {
port@0 {
@@ -104,11 +103,21 @@
remote-endpoint = <&adv7511_in>;
};
};
+ };
+};
+
+&lvds0 {
+ ports {
port@1 {
lvds_connector0: endpoint {
};
};
- port@2 {
+ };
+};
+
+&lvds1 {
+ ports {
+ port@1 {
lvds_connector1: endpoint {
};
};
--
2.17.1
[PATCH 0/2] arm: dts: renesas: Convert remaining boards to new LVDS DT bindings
Hi Simon, Magnus, Laurent, Marek,
As of commit 6d2ca85279becdff ("dt-bindings: display: renesas: Deprecate
LVDS support in the DU bindings"), the internal LVDS encoder has DT
bindings separate from the DU. Most board device trees were ported over
to the new model, but Stout with R-Car H2 and Salvator-XS with R-Car
M3-W were forgotten.
This patch series converts the remaining boards.
Both patches were compiled-tested only.
Thanks!
Geert Uytterhoeven (2):
ARM: dts: stout: Convert to new LVDS DT bindings
arm64: dts: renesas: r8a7796: salvator-xs: Convert to new LVDS DT
bindings
arch/arm/boot/dts/r8a7790-stout.dts | 15 ---
.../boot/dts/renesas/r8a7796-salvator-xs.dts | 3 +--
2 files changed, 13 insertions(+), 5 deletions(-)
--
2.17.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH 2/2] arm64: dts: renesas: r8a7796: salvator-xs: Convert to new LVDS DT bindings
As of commit 6d2ca85279becdff ("dt-bindings: display: renesas: Deprecate
LVDS support in the DU bindings"), the internal LVDS encoder has DT
bindings separate from the DU. The device trees for all R-Car H3 and
M3-W development boards were ported over to the new model, but
Salvator-XS boards equipped with an R-Car M3-W SoC were forgotten.
Fixes: 58e8ed2ee9abe718 ("arm64: dts: renesas: Convert to new LVDS DT bindings")
Signed-off-by: Geert Uytterhoeven
---
Compile-tested only.
---
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts
b/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts
index 8860be65342e4f38..31f12059355ee02b 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts
@@ -29,11 +29,10 @@
clocks = <&cpg CPG_MOD 724>,
<&cpg CPG_MOD 723>,
<&cpg CPG_MOD 722>,
-<&cpg CPG_MOD 727>,
<&versaclock6 1>,
<&x21_clk>,
<&versaclock6 2>;
- clock-names = "du.0", "du.1", "du.2", "lvds.0",
+ clock-names = "du.0", "du.1", "du.2",
"dclkin.0", "dclkin.1", "dclkin.2";
};
--
2.17.1
[PATCH] ARM: dts: r8a7743: Remove legacy "renesas,rcar-thermal" compatibility
The thermal hardware description for the RZ/G1M SoC was added to its DTS
after the introduction of support for thermal zones, and included a
thermal-zones node from the beginning.
Hence there is no need to claim compatibility with
"renesas,rcar-thermal", which would be needed only for backwards
compatibility with kernels predating thermal zone support.
Fixes: 6c76b4f7d89e89f0 ("ARM: dts: r8a7743: Add thermal device to DT")
Signed-off-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7743.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 24715f74ae08c7c2..3cc33f7ff7febae7 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -348,8 +348,7 @@
thermal: thermal@e61f {
compatible = "renesas,thermal-r8a7743",
-"renesas,rcar-gen2-thermal",
-"renesas,rcar-thermal";
+"renesas,rcar-gen2-thermal";
reg = <0 0xe61f 0 0x10>, <0 0xe61f0100 0 0x38>;
interrupts = ;
clocks = <&cpg CPG_MOD 522>;
--
2.17.1
Re: [PATCH] mmc: document 'Reliable Write' bit in uapi header
Hi Wolfram,
On Mon, Dec 3, 2018 at 3:27 PM Wolfram Sang
wrote:
> If we use it this way, people should know about it.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
> ---
>
> Still not super happy about shifting into the sign bit, but yeah...
> don't break userspace, I guess.
Indeed.
> include/uapi/linux/mmc/ioctl.h | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/mmc/ioctl.h b/include/uapi/linux/mmc/ioctl.h
> index 45f369dc0a42..ae659333e73f 100644
> --- a/include/uapi/linux/mmc/ioctl.h
> +++ b/include/uapi/linux/mmc/ioctl.h
> @@ -5,7 +5,10 @@
> #include
>
> struct mmc_ioc_cmd {
> - /* Implies direction of data. true = write, false = read */
> + /*
> +* Implies direction of data. true = write, false = read.
nonzero = write, zero = read?
> +* Bit 31 selects 'Reliable Write' for RPMB.
Perhaps having a #define for this would be nice?
Can also be used by the driver, instead of 1 << 31, which some static
analyzers may complain about.
> +*/
> int write_flag;
>
> /* Application-specific command. true = precede with CMD55 */
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] mmc: document 'Reliable Write' bit in uapi header
If we use it this way, people should know about it.
Signed-off-by: Wolfram Sang
---
Still not super happy about shifting into the sign bit, but yeah...
don't break userspace, I guess.
include/uapi/linux/mmc/ioctl.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/mmc/ioctl.h b/include/uapi/linux/mmc/ioctl.h
index 45f369dc0a42..ae659333e73f 100644
--- a/include/uapi/linux/mmc/ioctl.h
+++ b/include/uapi/linux/mmc/ioctl.h
@@ -5,7 +5,10 @@
#include
struct mmc_ioc_cmd {
- /* Implies direction of data. true = write, false = read */
+ /*
+* Implies direction of data. true = write, false = read.
+* Bit 31 selects 'Reliable Write' for RPMB.
+*/
int write_flag;
/* Application-specific command. true = precede with CMD55 */
--
2.11.0
Re: [PATCH mmc-utils] fix GCC7 build by refactoring trimming routines
Hi Avri, hi Chris,
> > I got a compile error with GCC7. When trimming white spaces from strings
> > lsmmc uses strncpy with overlapping memory areas. This is not allowed.
> > In addition, the implementation was not efficient with calling strlen
> > and strncpy once per iteration. Refactor the code to be valid and more
> > effective.
> >
> > Signed-off-by: Wolfram Sang
> > ---
> > lsmmc.c | 16 +++-
> > 1 file changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/lsmmc.c b/lsmmc.c
> > index c4faa00..9737b37 100644
> > --- a/lsmmc.c
> > +++ b/lsmmc.c
> > @@ -316,8 +316,9 @@ int parse_ids(struct config *config)
> > /* MMC/SD file parsing functions */
> > char *read_file(char *name)
> > {
>
> See Uwe's note - https://www.spinics.net/lists/linux-mmc/msg51882.html
Thanks for the pointer. Chris, how do you feel with maintaining
mmc-utils? Would you maybe be willing to share maintenance with someone?
Happy hacking,
Wolfram
signature.asc
Description: PGP signature
[PATCH v3] dmaengine: sh: Remove R-Mobile APE6 support
Renesas R-Mobile APE6 support is currently unused:
- DMA slaves were never enabled in r8a73a4.dtsi,
- The driver relies on legacy filter matching and describing all
slaves and MID/RIDs in a table, unlike modern DMA engine drivers for
similar hardware like rcar-dmac,
- The driver doesn't seem to work well.
Remove the driver, it can be resurrected from git history when needed.
As this was the last user of SH_DMAE_BASE on Renesas ARM SoCs, the
sh-dma-engine driver core is now used on SuperH only.
Note that the DT bindings are still present, as r8a73a4.dtsi uses them.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Ulrich Hecht
Reviewed-by: Simon Horman
---
v3:
- Rebase against slave-dma/topic/sh,
v2:
- Add Reviewed-by,
- Drop RFC.
---
drivers/dma/sh/Kconfig | 11 +
drivers/dma/sh/Makefile| 1 -
drivers/dma/sh/shdma-r8a73a4.c | 74 --
drivers/dma/sh/shdma.h | 7
drivers/dma/sh/shdmac.c| 7
5 files changed, 1 insertion(+), 99 deletions(-)
delete mode 100644 drivers/dma/sh/shdma-r8a73a4.c
diff --git a/drivers/dma/sh/Kconfig b/drivers/dma/sh/Kconfig
index 1c4675425a1eeb15..4d6b02b3b1f18e6f 100644
--- a/drivers/dma/sh/Kconfig
+++ b/drivers/dma/sh/Kconfig
@@ -13,7 +13,7 @@ config RENESAS_DMA
config SH_DMAE_BASE
bool "Renesas SuperH DMA Engine support"
- depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
+ depends on SUPERH || COMPILE_TEST
depends on !SUPERH || SH_DMA
depends on !SH_DMA_API
default y
@@ -31,15 +31,6 @@ config SH_DMAE
help
Enable support for the Renesas SuperH DMA controllers.
-if SH_DMAE
-
-config SH_DMAE_R8A73A4
- def_bool y
- depends on ARCH_R8A73A4
- depends on OF
-
-endif
-
config RCAR_DMAC
tristate "Renesas R-Car Gen2 DMA Controller"
depends on ARCH_RENESAS || COMPILE_TEST
diff --git a/drivers/dma/sh/Makefile b/drivers/dma/sh/Makefile
index 7d7c9491ade1216d..42110dd57a56fda8 100644
--- a/drivers/dma/sh/Makefile
+++ b/drivers/dma/sh/Makefile
@@ -10,7 +10,6 @@ obj-$(CONFIG_SH_DMAE_BASE) += shdma-base.o shdma-of.o
#
shdma-y := shdmac.o
-shdma-$(CONFIG_SH_DMAE_R8A73A4) += shdma-r8a73a4.o
shdma-objs := $(shdma-y)
obj-$(CONFIG_SH_DMAE) += shdma.o
diff --git a/drivers/dma/sh/shdma-r8a73a4.c b/drivers/dma/sh/shdma-r8a73a4.c
deleted file mode 100644
index ddc9a35783534bdd..
--- a/drivers/dma/sh/shdma-r8a73a4.c
+++ /dev/null
@@ -1,74 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Renesas SuperH DMA Engine support for r8a73a4 (APE6) SoCs
- *
- * Copyright (C) 2013 Renesas Electronics, Inc.
- */
-#include
-
-#include "shdma-arm.h"
-
-static const unsigned int dma_ts_shift[] = SH_DMAE_TS_SHIFT;
-
-static const struct sh_dmae_slave_config dma_slaves[] = {
- {
- .chcr = CHCR_TX(XMIT_SZ_32BIT),
- .mid_rid= 0xd1, /* MMC0 Tx */
- }, {
- .chcr = CHCR_RX(XMIT_SZ_32BIT),
- .mid_rid= 0xd2, /* MMC0 Rx */
- }, {
- .chcr = CHCR_TX(XMIT_SZ_32BIT),
- .mid_rid= 0xe1, /* MMC1 Tx */
- }, {
- .chcr = CHCR_RX(XMIT_SZ_32BIT),
- .mid_rid= 0xe2, /* MMC1 Rx */
- },
-};
-
-#define DMAE_CHANNEL(a, b) \
- { \
- .offset = (a) - 0x20, \
- .dmars = (a) - 0x20 + 0x40,\
- .chclr_bit = (b), \
- .chclr_offset = 0x80 - 0x20, \
- }
-
-static const struct sh_dmae_channel dma_channels[] = {
- DMAE_CHANNEL(0x8000, 0),
- DMAE_CHANNEL(0x8080, 1),
- DMAE_CHANNEL(0x8100, 2),
- DMAE_CHANNEL(0x8180, 3),
- DMAE_CHANNEL(0x8200, 4),
- DMAE_CHANNEL(0x8280, 5),
- DMAE_CHANNEL(0x8300, 6),
- DMAE_CHANNEL(0x8380, 7),
- DMAE_CHANNEL(0x8400, 8),
- DMAE_CHANNEL(0x8480, 9),
- DMAE_CHANNEL(0x8500, 10),
- DMAE_CHANNEL(0x8580, 11),
- DMAE_CHANNEL(0x8600, 12),
- DMAE_CHANNEL(0x8680, 13),
- DMAE_CHANNEL(0x8700, 14),
- DMAE_CHANNEL(0x8780, 15),
- DMAE_CHANNEL(0x8800, 16),
- DMAE_CHANNEL(0x8880, 17),
- DMAE_CHANNEL(0x8900, 18),
- DMAE_CHANNEL(0x8980, 19),
-};
-
-const struct sh_dmae_pdata r8a73a4_dma_pdata = {
- .slave = dma_slaves,
- .slave_num = ARRAY_SIZE(dma_slaves),
- .channel= dma_channels,
- .channel_num= ARRAY_SIZE(dma_channels),
- .ts_low_shift = TS_LOW_SHIFT,
- .ts_low_mask= TS_LOW_BIT << TS_LOW_SHIFT,
- .ts_high_shift = TS_HI_SHIFT,
- .ts_high_mask = TS_HI_BIT << TS_HI_SHIFT,
- .ts_shift = dma_ts_shift,
- .ts_shift_num = ARRAY_SIZE(dma_ts_shift),
- .d
Re: [PATCH v2] dmaengine: sh: Remove R-Mobile APE6 support
Hi Vinod,
On Thu, Nov 29, 2018 at 3:25 PM Vinod Koul wrote:
> On 29-11-18, 12:18, Geert Uytterhoeven wrote:
> > Renesas R-Mobile APE6 support is currently unused:
> > - DMA slaves were never enabled in r8a73a4.dtsi,
> > - The driver relies on legacy filter matching and describing all
> > slaves and MID/RIDs in a table, unlike modern DMA engine drivers for
> > similar hardware like rcar-dmac,
> > - The driver doesn't seem to work well.
> >
> > Remove the driver, it can be resurrected from git history when needed.
> >
> > As this was the last user of SH_DMAE_BASE on Renesas ARM SoCs, the
> > sh-dma-engine driver core is now used on SuperH only.
> >
> > Note that the DT bindings are still present, as r8a73a4.dtsi uses them.
>
> Sorry but this doesnt apply for me, can you please rebase on topic/sh
> and resend.
Sorry, will rebase and resend.
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 mmc-utils] fix GCC7 build by refactoring trimming routines
Hi,
>
> I got a compile error with GCC7. When trimming white spaces from strings
> lsmmc uses strncpy with overlapping memory areas. This is not allowed.
> In addition, the implementation was not efficient with calling strlen
> and strncpy once per iteration. Refactor the code to be valid and more
> effective.
>
> Signed-off-by: Wolfram Sang
> ---
> lsmmc.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/lsmmc.c b/lsmmc.c
> index c4faa00..9737b37 100644
> --- a/lsmmc.c
> +++ b/lsmmc.c
> @@ -316,8 +316,9 @@ int parse_ids(struct config *config)
> /* MMC/SD file parsing functions */
> char *read_file(char *name)
> {
See Uwe's note - https://www.spinics.net/lists/linux-mmc/msg51882.html
Cheers,
Avri
Re: [PATCH v2] watchdog: renesas_wdt: Fix typos
On Mon, Nov 05, 2018 at 10:53:47AM +, Fabrizio Castro wrote: > Do not use "," but ";" to separate instructions. This sentence would even be better as $subject, because current $subject sounds like fixing a comment or so. Other than that: Reviewed-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH 0/2] iommu/ipmmu-vmsa: Modify ipmmu_slave_whitelist()
On Wed, Nov 28, 2018 at 09:23:35AM +, Yoshihiro Shimoda wrote: > Yoshihiro Shimoda (2): > iommu/ipmmu-vmsa: Modify ipmmu_slave_whitelist() to check SoC > revisions > iommu/ipmmu-vmsa: add an array of slave devices whitelist Applied, thanks.
[PATCH mmc-utils] fix GCC7 build by refactoring trimming routines
I got a compile error with GCC7. When trimming white spaces from strings
lsmmc uses strncpy with overlapping memory areas. This is not allowed.
In addition, the implementation was not efficient with calling strlen
and strncpy once per iteration. Refactor the code to be valid and more
effective.
Signed-off-by: Wolfram Sang
---
lsmmc.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/lsmmc.c b/lsmmc.c
index c4faa00..9737b37 100644
--- a/lsmmc.c
+++ b/lsmmc.c
@@ -316,8 +316,9 @@ int parse_ids(struct config *config)
/* MMC/SD file parsing functions */
char *read_file(char *name)
{
- char *preparsed;
char line[4096];
+ char *preparsed, *start = line;
+ int len;
FILE *f;
f = fopen(name, "r");
@@ -348,12 +349,17 @@ char *read_file(char *name)
}
line[sizeof(line) - 1] = '\0';
+ len = strlen(line);
- while (isspace(line[strlen(line) - 1]))
- line[strlen(line) - 1] = '\0';
+ while (len > 0 && isspace(line[len - 1]))
+ len--;
- while (isspace(line[0]))
- strncpy(&line[0], &line[1], sizeof(line));
+ while (len > 0 && isspace(*start)) {
+ start++;
+ len--;
+ }
+ memmove(line, start, len);
+ line[len] = '\0';
return strdup(line);
}
--
2.11.0
Re: [PATCH v6 3/6] m68k: coldfire: Add clk_get_optional() function
Hi Christoph, On 30/11/18 2:32 am, Christoph Hellwig wrote: On Thu, Nov 29, 2018 at 09:54:37PM +1000, Greg Ungerer wrote: Hi Phil, On 17/11/18 12:59 am, Phil Edworthy wrote: clk_get_optional() returns NULL if not found instead of -ENOENT, otherwise the behaviour is the same as clk_get(). Signed-off-by: Phil Edworthy Acked-by: Greg Ungerer Looks good. Do you want me to take this in the m68knommu git tree? Or is the whole series going through some other tree? Any chance we could just get coldfire moved over to the common clock framework? Sure, I will have a look at it. Regards Greg
[PATCH] Add support to reset device controls
Provide a new option '--reset-controls' which will enumerate the
available controls on a device or sub-device, and re-initialise them to
defaults.
Signed-off-by: Kieran Bingham
---
This 'extends' the video_list_controls() function with an extra bool
flag for 'reset' to prevent duplicating the iteration functionality.
The patch could also pass the same flag into 'video_print_control()'
rather than implementing 'video_reset_control()' which necessitates
calling query_control() a second time.
I have chosen to add the extra call, as I feel it makes the code
cleaner, and pollutes the existing implementation less. The cost of the
extra query, while a little redundant should be minimal and produces a
simple function to reset the control independently.
---
yavta.c | 41 +++--
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/yavta.c b/yavta.c
index c7986bd9e031..30022c45ed5b 100644
--- a/yavta.c
+++ b/yavta.c
@@ -1186,7 +1186,28 @@ static int video_print_control(struct device *dev,
unsigned int id, bool full)
return query.id;
}
-static void video_list_controls(struct device *dev)
+static int video_reset_control(struct device *dev, unsigned int id)
+{
+ struct v4l2_queryctrl query;
+ int ret;
+
+ ret = query_control(dev, id, &query);
+ if (ret < 0)
+ return ret;
+
+ if (query.flags & V4L2_CTRL_FLAG_DISABLED)
+ return query.id;
+
+ if (query.type == V4L2_CTRL_TYPE_CTRL_CLASS)
+ return query.id;
+
+ printf("Reset control 0x%08x to %d:\n", query.id, query.default_value);
+ set_control(dev, query.id, query.default_value);
+
+ return query.id;
+}
+
+static void video_list_controls(struct device *dev, bool reset)
{
unsigned int nctrls = 0;
unsigned int id;
@@ -1207,6 +1228,12 @@ static void video_list_controls(struct device *dev)
if (ret < 0)
break;
+ if (reset) {
+ ret = video_reset_control(dev, id);
+ if (ret < 0)
+ break;
+ }
+
id = ret;
nctrls++;
}
@@ -1837,6 +1864,7 @@ static void usage(const char *argv0)
printf("--offsetUser pointer buffer offset from
page start\n");
printf("--premultiplied Color components are
premultiplied by alpha value\n");
printf("--queue-lateQueue buffers after streamon,
not before\n");
+ printf("--reset-controlsEnumerate available controls
and reset to defaults\n");
printf("--requeue-last Requeue the last buffers before
streamoff\n");
printf("--timestamp-source Set timestamp source on output
buffers [eof, soe]\n");
printf("--skip nSkip the first n frames\n");
@@ -1860,6 +1888,7 @@ static void usage(const char *argv0)
#define OPT_PREMULTIPLIED 269
#define OPT_QUEUE_LATE 270
#define OPT_DATA_PREFIX271
+#define OPT_RESET_CONTROLS 272
static struct option opts[] = {
{"buffer-size", 1, 0, OPT_BUFFER_SIZE},
@@ -1888,6 +1917,7 @@ static struct option opts[] = {
{"queue-late", 0, 0, OPT_QUEUE_LATE},
{"get-control", 1, 0, 'r'},
{"requeue-last", 0, 0, OPT_REQUEUE_LAST},
+ {"reset-controls", 0, 0, OPT_RESET_CONTROLS},
{"realtime", 2, 0, 'R'},
{"size", 1, 0, 's'},
{"set-control", 1, 0, 'w'},
@@ -1915,6 +1945,7 @@ int main(int argc, char *argv[])
int do_enum_formats = 0, do_set_format = 0;
int do_enum_inputs = 0, do_set_input = 0;
int do_list_controls = 0, do_get_control = 0, do_set_control = 0;
+ int do_reset_controls = 0;
int do_sleep_forever = 0, do_requeue_last = 0;
int do_rt = 0, do_log_status = 0;
int no_query = 0, do_queue_late = 0;
@@ -2107,6 +2138,9 @@ int main(int argc, char *argv[])
case OPT_QUEUE_LATE:
do_queue_late = 1;
break;
+ case OPT_RESET_CONTROLS:
+ do_reset_controls = 1;
+ break;
case OPT_REQUEUE_LAST:
do_requeue_last = 1;
break;
@@ -2185,7 +2219,10 @@ int main(int argc, char *argv[])
set_control(&dev, ctrl_name, ctrl_value);
if (do_list_controls)
- video_list_controls(&dev);
+ video_list_controls(&dev, false);
+
+ if (do_reset_controls)
+ video_list_controls(&dev, true);
if (do_enum_formats) {
printf("- Available formats:\n");
--
2.17.1
Re: [PATCH 01/14] gpio: pca953x: Deduplicate the bank_size
On 12/03/2018 10:36 AM, Bartosz Golaszewski wrote: > niedz., 2 gru 2018 o 20:36 Marek Vasut napisał(a): >> >> The bank_size = fls(...) code was duplicated in the driver 5 times, >> pull it into separate function. >> > > Shouldn't it be bank_shift in the commit message? It should, fixed -- Best regards, Marek Vasut
Re: [PATCH 02/14] gpio: pca953x: Fix AI overflow on PCAL6524
niedz., 2 gru 2018 o 20:36 Marek Vasut napisał(a): > > The PCAL_PINCTRL_MASK is too large. The extended register block on > PCAL6524, which is the largest chip with this block, has the block > limited to address range 0x40..0x7f. This is because the bit 7 in > the command register is used for the Address Increment functionality. > > Trim the mask to 0x60 to match the datasheet and to prevent accidental > overwrite of the AI bit. > > Signed-off-by: Marek Vasut > Cc: Linus Walleij > Cc: Bartosz Golaszewski > --- > drivers/gpio/gpio-pca953x.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c > index 31e3b1b52330..4e9c79ca69c5 100644 > --- a/drivers/gpio/gpio-pca953x.c > +++ b/drivers/gpio/gpio-pca953x.c > @@ -58,7 +58,7 @@ > #define PCA_GPIO_MASK 0x00FF > > #define PCAL_GPIO_MASK 0x1f > -#define PCAL_PINCTRL_MASK 0xe0 > +#define PCAL_PINCTRL_MASK 0x60 > > #define PCA_INT0x0100 > #define PCA_PCAL 0x0200 > -- > 2.18.0 > Reviewed-by: Bartosz Golaszewski
Re: [PATCH 01/14] gpio: pca953x: Deduplicate the bank_size
niedz., 2 gru 2018 o 20:36 Marek Vasut napisał(a):
>
> The bank_size = fls(...) code was duplicated in the driver 5 times,
> pull it into separate function.
>
Shouldn't it be bank_shift in the commit message?
Bart
> Signed-off-by: Marek Vasut
> Cc: Linus Walleij
> Cc: Bartosz Golaszewski
> ---
> drivers/gpio/gpio-pca953x.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index 023a32cfac42..31e3b1b52330 100644
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -159,11 +159,16 @@ struct pca953x_chip {
> int (*read_regs)(struct pca953x_chip *, int, u8 *);
> };
>
> +static int pca953x_bank_shift(struct pca953x_chip *chip)
> +{
> + return fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
> +}
> +
> static int pca953x_read_single(struct pca953x_chip *chip, int reg, u32 *val,
> int off)
> {
> int ret;
> - int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
> + int bank_shift = pca953x_bank_shift(chip);
> int offset = off / BANK_SZ;
>
> ret = i2c_smbus_read_byte_data(chip->client,
> @@ -182,7 +187,7 @@ static int pca953x_write_single(struct pca953x_chip
> *chip, int reg, u32 val,
> int off)
> {
> int ret;
> - int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
> + int bank_shift = pca953x_bank_shift(chip);
> int offset = off / BANK_SZ;
>
> ret = i2c_smbus_write_byte_data(chip->client,
> @@ -221,7 +226,7 @@ static int pca957x_write_regs_16(struct pca953x_chip
> *chip, int reg, u8 *val)
>
> static int pca953x_write_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
> {
> - int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
> + int bank_shift = pca953x_bank_shift(chip);
> int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
> int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
>
> @@ -265,7 +270,7 @@ static int pca953x_read_regs_16(struct pca953x_chip
> *chip, int reg, u8 *val)
>
> static int pca953x_read_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
> {
> - int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
> + int bank_shift = pca953x_bank_shift(chip);
> int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
> int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
>
> @@ -402,13 +407,12 @@ static void pca953x_gpio_set_multiple(struct gpio_chip
> *gc,
> unsigned long *mask, unsigned long
> *bits)
> {
> struct pca953x_chip *chip = gpiochip_get_data(gc);
> + int bank_shift = pca953x_bank_shift(chip);
> unsigned int bank_mask, bank_val;
> - int bank_shift, bank;
> + int bank;
> u8 reg_val[MAX_BANK];
> int ret;
>
> - bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
> -
> mutex_lock(&chip->i2c_lock);
> memcpy(reg_val, chip->reg_output, NBANK(chip));
> for (bank = 0; bank < NBANK(chip); bank++) {
> --
> 2.18.0
>
[PATCH v2 1/2] spi: Add Renesas R-Car Gen3 RPC SPI controller driver
Add a driver for Renesas R-Car Gen3 RPC SPI controller. Signed-off-by: Mason Yang --- drivers/spi/Kconfig | 6 + drivers/spi/Makefile | 1 + drivers/spi/spi-renesas-rpc.c | 808 ++ 3 files changed, 815 insertions(+) create mode 100644 drivers/spi/spi-renesas-rpc.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 7d3a5c9..8f826fe 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -528,6 +528,12 @@ config SPI_RSPI help SPI driver for Renesas RSPI and QSPI blocks. +config SPI_RENESAS_RPC + tristate "Renesas R-Car Gen3 RPC SPI controller" + depends on SUPERH || ARCH_RENESAS || COMPILE_TEST + help + SPI driver for Renesas R-Car Gen3 RPC. + config SPI_QCOM_QSPI tristate "QTI QSPI controller" depends on ARCH_QCOM diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index 3575205..5d5c523 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -81,6 +81,7 @@ obj-$(CONFIG_SPI_QUP) += spi-qup.o obj-$(CONFIG_SPI_ROCKCHIP) += spi-rockchip.o obj-$(CONFIG_SPI_RB4XX)+= spi-rb4xx.o obj-$(CONFIG_SPI_RSPI) += spi-rspi.o +obj-$(CONFIG_SPI_RENESAS_RPC) += spi-renesas-rpc.o obj-$(CONFIG_SPI_S3C24XX) += spi-s3c24xx-hw.o spi-s3c24xx-hw-y := spi-s3c24xx.o spi-s3c24xx-hw-$(CONFIG_SPI_S3C24XX_FIQ) += spi-s3c24xx-fiq.o diff --git a/drivers/spi/spi-renesas-rpc.c b/drivers/spi/spi-renesas-rpc.c new file mode 100644 index 000..ac9094e --- /dev/null +++ b/drivers/spi/spi-renesas-rpc.c @@ -0,0 +1,808 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (C) 2018 ~ 2019 Renesas Solutions Corp. +// Copyright (C) 2018 Macronix International Co., Ltd. +// +// R-Car Gen3 RPC SPI/QSPI/Octa driver +// +// Authors: +// Mason Yang +// + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define RPC_CMNCR 0x /* R/W */ +#define RPC_CMNCR_MD BIT(31) +#define RPC_CMNCR_SFDE BIT(24) +#define RPC_CMNCR_MOIIO3(val) (((val) & 0x3) << 22) +#define RPC_CMNCR_MOIIO2(val) (((val) & 0x3) << 20) +#define RPC_CMNCR_MOIIO1(val) (((val) & 0x3) << 18) +#define RPC_CMNCR_MOIIO0(val) (((val) & 0x3) << 16) +#define RPC_CMNCR_MOIIO_HIZ(RPC_CMNCR_MOIIO0(3) | RPC_CMNCR_MOIIO1(3) | \ +RPC_CMNCR_MOIIO2(3) | RPC_CMNCR_MOIIO3(3)) +#define RPC_CMNCR_IO3FV(val) (((val) & 0x3) << 14) +#define RPC_CMNCR_IO2FV(val) (((val) & 0x3) << 12) +#define RPC_CMNCR_IO0FV(val) (((val) & 0x3) << 8) +#define RPC_CMNCR_IOFV_HIZ (RPC_CMNCR_IO0FV(3) | RPC_CMNCR_IO2FV(3) | \ +RPC_CMNCR_IO3FV(3)) +#define RPC_CMNCR_CPHATBIT(6) +#define RPC_CMNCR_CPHARBIT(5) +#define RPC_CMNCR_SSLP BIT(4) +#define RPC_CMNCR_CPOL BIT(3) +#define RPC_CMNCR_BSZ(val) (((val) & 0x3) << 0) + +#define RPC_SSLDR 0x0004 /* R/W */ +#define RPC_SSLDR_SPNDL(d) (((d) & 0x7) << 16) +#define RPC_SSLDR_SLNDL(d) (((d) & 0x7) << 8) +#define RPC_SSLDR_SCKDL(d) (((d) & 0x7) << 0) + +#define RPC_DRCR 0x000C /* R/W */ +#define RPC_DRCR_SSLN BIT(24) +#define RPC_DRCR_RBURST(v) (((v) & 0x1F) << 16) +#define RPC_DRCR_RCF BIT(9) +#define RPC_DRCR_RBE BIT(8) +#define RPC_DRCR_SSLE BIT(0) + +#define RPC_DRCMR 0x0010 /* R/W */ +#define RPC_DRCMR_CMD(c) (((c) & 0xFF) << 16) +#define RPC_DRCMR_OCMD(c) (((c) & 0xFF) << 0) + +#define RPC_DREAR 0x0014 /* R/W */ +#define RPC_DREAR_EAC BIT(0) + +#define RPC_DROPR 0x0018 /* R/W */ + +#define RPC_DRENR 0x001C /* R/W */ +#define RPC_DRENR_CDB(o) (u32)o) & 0x3) << 30)) +#define RPC_DRENR_OCDB(o) (((o) & 0x3) << 28) +#define RPC_DRENR_ADB(o) (((o) & 0x3) << 24) +#define RPC_DRENR_OPDB(o) (((o) & 0x3) << 20) +#define RPC_DRENR_SPIDB(o) (((o) & 0x3) << 16) +#define RPC_DRENR_DME BIT(15) +#define RPC_DRENR_CDE BIT(14) +#define RPC_DRENR_OCDE BIT(12) +#define RPC_DRENR_ADE(v) (((v) & 0xF) << 8) +#define RPC_DRENR_OPDE(v) (((v) & 0xF) << 4) + +#define RPC_SMCR 0x0020 /* R/W */ +#define RPC_SMCR_SSLKP BIT(8) +#define RPC_SMCR_SPIRE BIT(2) +#define RPC_SMCR_SPIWE BIT(1) +#define RPC_SMCR_SPIE BIT(0) + +#define RPC_SMCMR 0x0024 /* R/W */ +#define RPC_SMCMR_CMD(c) (((c) & 0xFF) << 16) +#define RPC_SMCMR_OCMD(c) (((c) & 0xFF) << 0) + +#define RPC_SMADR 0x0028 /* R/W */ +#define RPC_SMOPR 0x002C /* R/W */ +#define RPC_SMOPR_OPD0(o) (((o) & 0xFF) << 0) +#define RPC_SMOPR_OPD1(o) (((o) & 0xFF) << 8) +#define RPC_SMOPR_OPD2(o) (((o) & 0xFF) << 16) +#define RPC_SMO
[PATCH v2 2/2] dt-binding: spi: Document Renesas R-Car Gen3 RPC controller bindings
Document the bindings used by the Renesas R-Car Gen3 RPC SPI controller.
Signed-off-by: Mason Yang
---
.../devicetree/bindings/spi/spi-renesas-rpc.txt| 35 ++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
new file mode 100644
index 000..c6c6d9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
@@ -0,0 +1,35 @@
+Renesas R-Car Gen3 RPC controller Device Tree Bindings
+--
+
+Required properties:
+- compatible: should be "renesas,r8a77995-rpc"
+- #address-cells: should be 1
+- #size-cells: should be 0
+- reg: should contain 2 entries, one for the registers and one for the direct
+ mapping area
+- reg-names: should contain "rpc_regs" and "dirmap"
+- interrupts: interrupt line connected to the RPC SPI controller
+- clock-names: should contain "clk_rpc"
+- clocks: should contain 1 entries for the module's clock
+
+Example:
+
+ rpc: spi@ee20 {
+ compatible = "renesas,r8a77995-rpc";
+ reg = <0 0xee20 0 0x8100>, <0 0x0800 0 0x400>;
+ reg-names = "rpc_regs", "dirmap";
+ clocks = <&cpg CPG_MOD 917>;
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 917>;
+ clock-names = "clk_rpc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <4000>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ };
+ };
--
1.9.1
[PATCH v2 0/2] spi: Add Renesas R-Car Gen3 RPC SPI driver
Hi Mark, This Renesas R-Car Gen3 RPC SPI driver is based on Boris's new spi-mem direct mapping read/write mode [1][2] and v2 patch is from Marek and Geert's comments including RPC clock control, run time PM, RPC module software reset, regmap and so on. thanks for your review. best regards, Mason [1] https://patchwork.kernel.org/patch/10670753 [2] https://patchwork.kernel.org/patch/10670747 Mason Yang (2): spi: Add Renesas R-Car Gen3 RPC SPI controller driver dt-binding: spi: Document Renesas R-Car Gen3 RPC controller bindings .../devicetree/bindings/spi/spi-renesas-rpc.txt| 35 + drivers/spi/Kconfig| 6 + drivers/spi/Makefile | 1 + drivers/spi/spi-renesas-rpc.c | 808 + 4 files changed, 850 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt create mode 100644 drivers/spi/spi-renesas-rpc.c -- 1.9.1
Re: [PATCH/RFT] arm64: dts: renesas: r8a77990-ebisu: Add BD9571 PMIC
Hi Kaneko-san,
On Sat, Dec 1, 2018 at 3:43 PM Yoshihiro Kaneko wrote:
> From: Takeshi Kihara
>
> This patch adds the regulator definition required for operation of
> S2RAM.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Yoshihiro Kaneko
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> @@ -425,6 +425,26 @@
> };
> };
>
> +&i2c_dvfs {
> + status = "okay";
> +
> + clock-frequency = <40>;
> +
> + pmic: pmic@30 {
> + pinctrl-0 = <&irq0_pins>;
> + pinctrl-names = "default";
> +
> + compatible = "rohm,bd9571mwv";
> + reg = <0x30>;
> + interrupt-parent = <&intc_ex>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + gpio-controller;
> + #gpio-cells = <2>;
Just adding this node is not sufficient to make S2RAM work.
As per Documentation/devicetree/bindings/mfd/bd9571mwv.txt, you also have
to describe the DDR-Backup Power configuration.
On the Ebisu-4D development board, only the DDR0 power rail is used, and
needs to be kept powered when backup mode is enabled.
rohm,ddr-backup-power = <0x1>;
rohm,rstbmode-level;
Unfortunately resume from s2ram doesn't work with this, probably due to an
issue in ATF. This may have been fixed in IPL and Secure Monitor Rev1.0.22,
which claims to add support for the Ebisu-4D board.
I don't know if plain Ebisu needs a different configuration.
> + };
> +};
> +
> &lvds0 {
> status = "okay";
>
The rest is fine, hence with the above fixed and tested:
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
