[PATCH v2 2/2] arm64: dts: r8a7795: add sound MIX support
From: Kuninori Morimoto
This patch adds MIX (= Mixer) supoort.
Signed-off-by: Kuninori Morimoto
---
v1 -> v2
- mix@X -> mix-X
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 1 +
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 7 +++
2 files changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 79334ac..6429b21 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -508,6 +508,7 @@
<&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
<&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
<&audio_clk_a>, <&cs2000>,
<&audio_clk_c>,
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 16aa31f..7799d75 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1156,6 +1156,7 @@
<&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
<&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
<&audio_clk_a>, <&audio_clk_b>,
<&audio_clk_c>,
@@ -1167,6 +1168,7 @@
"src.9", "src.8", "src.7", "src.6",
"src.5", "src.4", "src.3", "src.2",
"src.1", "src.0",
+ "mix.1", "mix.0",
"ctu.1", "ctu.0",
"dvc.0", "dvc.1",
"clk_a", "clk_b", "clk_c", "clk_i";
@@ -1184,6 +1186,11 @@
};
};
+ rcar_sound,mix {
+ mix0: mix-0 { };
+ mix1: mix-1 { };
+ };
+
rcar_sound,ctu {
ctu00: ctu-0 { };
ctu01: ctu-1 { };
--
1.9.1
[PATCH v2 1/2] arm64: dts: r8a7795: add sound CTU support
From: Kuninori Morimoto
This patch adds CTU (= Channel Transfer Unit) supoort which is needed
to sound mixing.
Signed-off-by: Kuninori Morimoto
---
v1 -> v2
- ctu@X -> ctu-X
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 1 +
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 13 +
2 files changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 56f3a91..79334ac 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -507,6 +507,7 @@
<&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
<&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
<&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
+<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
<&audio_clk_a>, <&cs2000>,
<&audio_clk_c>,
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 38cc90f..16aa31f 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1155,6 +1155,7 @@
<&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
<&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
<&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
+<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
<&audio_clk_a>, <&audio_clk_b>,
<&audio_clk_c>,
@@ -1166,6 +1167,7 @@
"src.9", "src.8", "src.7", "src.6",
"src.5", "src.4", "src.3", "src.2",
"src.1", "src.0",
+ "ctu.1", "ctu.0",
"dvc.0", "dvc.1",
"clk_a", "clk_b", "clk_c", "clk_i";
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
@@ -1182,6 +1184,17 @@
};
};
+ 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 { };
+ };
+
rcar_sound,src {
src0: src-0 {
interrupts = ;
--
1.9.1
[PATCH v2 0/2] arm64: dts: r8a7795: add CTU/MIX support
Hi Simon These are v2 of r8a7795 CTU/MIX support patch-set Kuninori Morimoto (2): arm64: dts: r8a7795: add sound CTU support arm64: dts: r8a7795: add sound MIX support arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 2 ++ arch/arm64/boot/dts/renesas/r8a7795.dtsi | 20 2 files changed, 22 insertions(+) -- 1.9.1
RE: [PATCH 12/12] usb: renesas_usbhs: Replace the deprecated extcon API
Hi, > From: Chanwoo Choi > Sent: Wednesday, November 30, 2016 2:58 PM > > This patch replaces the deprecated extcon API as following: > - extcon_get_cable_state_() -> extcon_get_state() > > Signed-off-by: Chanwoo Choi Thank you for the patch! Acked-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda
RE: [PATCH 01/12] phy: rcar-gen3-usb2: Replace the deprecated extcon API
Hi, > From: Chanwoo Choi > Sent: Wednesday, November 30, 2016 2:57 PM > > This patch replaces the deprecated extcon API as following: > - extcon_set_cable_state_() -> extcon_set_state_sync() > > Signed-off-by: Chanwoo Choi Thank you for the patch! Acked-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda
Re: [PATCH 01/12] phy: rcar-gen3-usb2: Replace the deprecated extcon API
Hi Kishon,
Could you review and pick the patch1/2 for phy driver?
Best Regards,
Chanwoo Choi
On 2016년 11월 30일 14:57, Chanwoo Choi wrote:
> This patch replaces the deprecated extcon API as following:
> - extcon_set_cable_state_() -> extcon_set_state_sync()
>
> Signed-off-by: Chanwoo Choi
> ---
> drivers/phy/phy-rcar-gen3-usb2.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/phy/phy-rcar-gen3-usb2.c
> b/drivers/phy/phy-rcar-gen3-usb2.c
> index bd2430d7339c..7f8081f157f4 100644
> --- a/drivers/phy/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/phy-rcar-gen3-usb2.c
> @@ -93,11 +93,11 @@ static void rcar_gen3_phy_usb2_work(struct work_struct
> *work)
>work);
>
> if (ch->extcon_host) {
> - extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, true);
> - extcon_set_cable_state_(ch->extcon, EXTCON_USB, false);
> + extcon_set_state_sync(ch->extcon, EXTCON_USB_HOST, true);
> + extcon_set_state_sync(ch->extcon, EXTCON_USB, false);
> } else {
> - extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, false);
> - extcon_set_cable_state_(ch->extcon, EXTCON_USB, true);
> + extcon_set_state_sync(ch->extcon, EXTCON_USB_HOST, false);
> + extcon_set_state_sync(ch->extcon, EXTCON_USB, true);
> }
> }
>
>
Re: [PATCH 03/12] power_supply: axp288_charger: Replace the extcon API
Hi Sebastian,
Could you please review and pick the patch3/4 for power-supply driver?
Best Regards,
Chanwoo Choi
On 2016년 11월 30일 14:57, Chanwoo Choi wrote:
> This patch uses the resource-managed extcon API for extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
>
> Signed-off-by: Chanwoo Choi
> ---
> drivers/power/supply/axp288_charger.c | 51
> +--
> 1 file changed, 13 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/power/supply/axp288_charger.c
> b/drivers/power/supply/axp288_charger.c
> index 75b8e0c7402b..1115052e9a69 100644
> --- a/drivers/power/supply/axp288_charger.c
> +++ b/drivers/power/supply/axp288_charger.c
> @@ -581,15 +581,15 @@ static void axp288_charger_extcon_evt_worker(struct
> work_struct *work)
> bool old_connected = info->cable.connected;
>
> /* Determine cable/charger type */
> - if (extcon_get_cable_state_(edev, EXTCON_CHG_USB_SDP) > 0) {
> + if (extcon_get_state(edev, EXTCON_CHG_USB_SDP) > 0) {
> dev_dbg(&info->pdev->dev, "USB SDP charger is connected");
> info->cable.connected = true;
> info->cable.chg_type = POWER_SUPPLY_TYPE_USB;
> - } else if (extcon_get_cable_state_(edev, EXTCON_CHG_USB_CDP) > 0) {
> + } else if (extcon_get_state(edev, EXTCON_CHG_USB_CDP) > 0) {
> dev_dbg(&info->pdev->dev, "USB CDP charger is connected");
> info->cable.connected = true;
> info->cable.chg_type = POWER_SUPPLY_TYPE_USB_CDP;
> - } else if (extcon_get_cable_state_(edev, EXTCON_CHG_USB_DCP) > 0) {
> + } else if (extcon_get_state(edev, EXTCON_CHG_USB_DCP) > 0) {
> dev_dbg(&info->pdev->dev, "USB DCP charger is connected");
> info->cable.connected = true;
> info->cable.chg_type = POWER_SUPPLY_TYPE_USB_DCP;
> @@ -686,7 +686,7 @@ static int axp288_charger_handle_otg_evt(struct
> notifier_block *nb,
> struct axp288_chrg_info *info =
> container_of(nb, struct axp288_chrg_info, otg.id_nb);
> struct extcon_dev *edev = info->otg.cable;
> - int usb_host = extcon_get_cable_state_(edev, EXTCON_USB_HOST);
> + int usb_host = extcon_get_state(edev, EXTCON_USB_HOST);
>
> dev_dbg(&info->pdev->dev, "external connector USB-Host is %s\n",
> usb_host ? "attached" : "detached");
> @@ -841,33 +841,27 @@ static int axp288_charger_probe(struct platform_device
> *pdev)
> /* Register for extcon notification */
> INIT_WORK(&info->cable.work, axp288_charger_extcon_evt_worker);
> info->cable.nb.notifier_call = axp288_charger_handle_cable_evt;
> - ret = extcon_register_notifier(info->cable.edev, EXTCON_CHG_USB_SDP,
> - &info->cable.nb);
> + ret = devm_extcon_register_notifier(&pdev->dev, info->cable.edev,
> + EXTCON_CHG_USB_SDP, &info->cable.nb);
> if (ret) {
> dev_err(&info->pdev->dev,
> "failed to register extcon notifier for SDP %d\n", ret);
> return ret;
> }
>
> - ret = extcon_register_notifier(info->cable.edev, EXTCON_CHG_USB_CDP,
> - &info->cable.nb);
> + ret = devm_extcon_register_notifier(&pdev->dev, info->cable.edev,
> + EXTCON_CHG_USB_CDP, &info->cable.nb);
> if (ret) {
> dev_err(&info->pdev->dev,
> "failed to register extcon notifier for CDP %d\n", ret);
> - extcon_unregister_notifier(info->cable.edev,
> - EXTCON_CHG_USB_SDP, &info->cable.nb);
> return ret;
> }
>
> - ret = extcon_register_notifier(info->cable.edev, EXTCON_CHG_USB_DCP,
> - &info->cable.nb);
> + ret = devm_extcon_register_notifier(&pdev->dev, info->cable.edev,
> + EXTCON_CHG_USB_DCP, &info->cable.nb);
> if (ret) {
> dev_err(&info->pdev->dev,
> "failed to register extcon notifier for DCP %d\n", ret);
> - extcon_unregister_notifier(info->cable.edev,
> - EXTCON_CHG_USB_SDP, &info->cable.nb);
> - extcon_unregister_notifier(info->cable.edev,
> - EXTCON_CHG_USB_CDP, &info->cable.nb);
> return ret;
> }
>
> @@ -887,13 +881,13 @@ static int axp288_charger_probe(struct platform_device
> *pdev)
> /* Register for OTG notification */
> INIT_WORK(&info->otg.work, axp288_charger_otg_evt_worker);
> info->otg.id_nb.notifier_call = axp288_charger_handle_otg_evt;
> - ret = extcon_register_notifier(info->otg.cable, EXTCON_USB_HOST,
> -&info->otg.id_nb);
> + ret = devm_extcon_register_notifier(&p
Re: [PATCH 07/12] usb: sunxi: Uses the resource-managed extcon API when registering extcon notifier
On 2016년 12월 06일 01:32, Bin Liu wrote: > On Wed, Nov 30, 2016 at 09:45:03AM +0100, Maxime Ripard wrote: >> On Wed, Nov 30, 2016 at 02:57:35PM +0900, Chanwoo Choi wrote: >>> This patch just uses the resource-managed extcon API when registering >>> the extcon notifier. >>> >>> Signed-off-by: Chanwoo Choi >> >> Acked-by: Maxime Ripard > > It would be ideal if the subject was "usb: musb: sunxi: ...". > > Acked-by: Bin Liu > Thanks for the review. I'll change the subject. -- Best Regards, Chanwoo Choi
[PATCHv2] arm64: dts: r8a7795: salvator-x: Set drive-strength for ravb pins
The EthernetAVB should not depend on the bootloader to setup correct
drive-strength values. Values for drive-strength where found by
examining the registers after the bootloader has configured the
registers and successfully used the EthernetAVB.
Signed-off-by: Niklas Söderlund
---
Changes since v1:
- Only set drive-strength for output pins, thanks Geert.
- Add all used pin groups to the mux section.
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index b1eab68..784ced9 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -225,8 +225,22 @@
};
avb_pins: avb {
- groups = "avb_mdc";
- function = "avb";
+ mux {
+ groups = "avb_link", "avb_phy_int", "avb_mdc",
+"avb_mii";
+ function = "avb";
+ };
+
+ pins_mdc {
+ groups = "avb_mdc";
+ drive-strength = <24>;
+ };
+
+ pins_mii_tx {
+ pins = "PIN_AVB_TX_CTL", "PIN_AVB_TXC", "PIN_AVB_TD0",
+ "PIN_AVB_TD1", "PIN_AVB_TD2", "PIN_AVB_TD3";
+ drive-strength = <12>;
+ };
};
du_pins: du {
--
2.10.2
Re: [PATCH 07/12] usb: sunxi: Uses the resource-managed extcon API when registering extcon notifier
On Wed, Nov 30, 2016 at 09:45:03AM +0100, Maxime Ripard wrote: > On Wed, Nov 30, 2016 at 02:57:35PM +0900, Chanwoo Choi wrote: > > This patch just uses the resource-managed extcon API when registering > > the extcon notifier. > > > > Signed-off-by: Chanwoo Choi > > Acked-by: Maxime Ripard It would be ideal if the subject was "usb: musb: sunxi: ...". Acked-by: Bin Liu Regards, -Bin.
Re: [RFC] New Device Tree property - "bonding"
Hi Rob, On Monday 05 Dec 2016 09:57:32 Rob Herring wrote: > On Mon, Dec 5, 2016 at 8:40 AM, Laurent Pinchart wrote: > > On Monday 05 Dec 2016 08:18:34 Rob Herring wrote: > >> On Fri, Nov 25, 2016 at 10:55 AM, Ramesh Shanmugasundaram wrote: > >>> Hello DT maintainers, > >>> > >>> In one of the Renesas SoCs we have a device called DRIF (Digital Radio > >>> Interface) controller. A DRIF channel contains 4 external pins - SCK, > >>> SYNC, Data pins D0 & D1. > >>> > >>> Internally a DRIF channel is made up of two SPI slave devices (also > >>> called sub-channels here) that share common CLK & SYNC signals but have > >>> their own resource set. The DRIF channel can have either one of the > >>> sub-channel active at a time or both. When both sub-channels are active, > >>> they need to be managed together as one device as they share same CLK & > >>> SYNC. We plan to tie these two sub-channels together with a new property > >>> called "renesas,bonding". > >> > >> Is there no need to describe the master device? No GPIOs, regulators > >> or other sideband controls needed? If that's never needed (which seems > >> doubtful), then I would do something different here probably with the > >> master device as a child of one DRIF and then phandles to master from > >> the other DRIFs. Otherwise, this looks fine to me. > > > > Here's a bit of background. > > > > The DRIF is an SPI receiver. It has three input pins, a clock line, a data > > line and a sync signal. The device is designed to be connected to a > > variety of data sources, usually plain SPI (1 data line), IIS (1 data > > line) but also radio tuners that output I/Q data > > (http://www.ni.com/tutorial/4805/en/) over two data lines. > > > > In the case of IQ each data sample is split in two I and Q values > > (typically 16 to 20 bits each in this case), and the values are > > transmitted serially over one data line each. The synchronization and > > clock signals are common to both data lines. The DRIF is optimized for > > this use case as the DRIF instances in the SoC (each of them having > > independent clocks, interrupts and control registers) are grouped by two, > > and the two instances in a group handle a single data line each but share > > the same clock and sync input. > > > > On the software side we need to group the I and Q values, which are DMA'ed > > to memory by the two DRIF instances, and make them available to > > userspace. The V4L2 API used here in SDR (Software Defined Radio) mode > > supports such use cases and exposes a single device node to userspace > > that allows control of the two DRIF instances as a single device. To be > > able to implement this we need kernel code to be aware of DRIF groups > > and, while binding to the DRIF instances separately, expose only one V4L2 > > device to userspace for each group. > > > > There's no master or slave instance from a hardware point of view, but the > > two instances are not interchangeable as they carry separate information. > > They must thus be identified at the driver level. > > By master, I meant the external master device that generates the IQ > data, not which of the internal DRIF blocks is a master of the other. > So back to my question, does the external master device need to be > described? I worry the answer now for a simple case is no, but then > later people are going to have cases needing to describe more. We need > to answer this question first before we can decide what this binding > should look like. Oh yes the external device certainly needs to be described. As it is controlled through a separate, general-purpose I2C or SPI controller, it should be a child node of that controller. The DRIF handles the data interface only, not the control interface of the external device. > > Back to the DT bindings, the need to expose relationships between (mostly) > > independent devices is quite common nowadays. It has been solved in some > > cases by creating a separate DT node that does not correspond to any > > physical hardware and whose sole purpose is to contain phandles to > > devices that need to be grouped. Drivers then bind to the compatible > > string of that "virtual" DT node. The proposed bonding property is a > > different approach to solve a similar problem. Would it be worth it > > addressing the problem at a more general level and try to design a common > > solution ? > > We already have somewhat standard ways of grouping, but they are per > type of device (display, sound card, etc.). I'm not sure we gain much > standardizing across these devices and to some extent that ship has > sailed. Even within display subsystems, I don't think there is one > style that fits all. Sometimes a parent subsystem node with children > makes sense for the h/w. Sometimes that doesn't make sense and we have > the virtual node with a "ports" property (like sun8i did). I've never > been too happy with that style largely just because it feels like > we're letting DRM define the binding. How
Re: [RFC] New Device Tree property - "bonding"
On Mon, Dec 5, 2016 at 8:40 AM, Laurent Pinchart wrote: > Hi Rob, > > On Monday 05 Dec 2016 08:18:34 Rob Herring wrote: >> On Fri, Nov 25, 2016 at 10:55 AM, Ramesh Shanmugasundaram wrote: >> > Hello DT maintainers, >> > >> > In one of the Renesas SoCs we have a device called DRIF (Digital Radio >> > Interface) controller. A DRIF channel contains 4 external pins - SCK, >> > SYNC, Data pins D0 & D1. >> > >> > Internally a DRIF channel is made up of two SPI slave devices (also called >> > sub-channels here) that share common CLK & SYNC signals but have their >> > own resource set. The DRIF channel can have either one of the sub-channel >> > active at a time or both. When both sub-channels are active, they need to >> > be managed together as one device as they share same CLK & SYNC. We plan >> > to tie these two sub-channels together with a new property called >> > "renesas,bonding". >> >> Is there no need to describe the master device? No GPIOs, regulators >> or other sideband controls needed? If that's never needed (which seems >> doubtful), then I would do something different here probably with the >> master device as a child of one DRIF and then phandles to master from >> the other DRIFs. Otherwise, this looks fine to me. > > Here's a bit of background. > > The DRIF is an SPI receiver. It has three input pins, a clock line, a data > line and a sync signal. The device is designed to be connected to a variety of > data sources, usually plain SPI (1 data line), IIS (1 data line) but also > radio tuners that output I/Q data (http://www.ni.com/tutorial/4805/en/) over > two data lines. > > In the case of IQ each data sample is split in two I and Q values (typically > 16 to 20 bits each in this case), and the values are transmitted serially over > one data line each. The synchronization and clock signals are common to both > data lines. The DRIF is optimized for this use case as the DRIF instances in > the SoC (each of them having independent clocks, interrupts and control > registers) are grouped by two, and the two instances in a group handle a > single data line each but share the same clock and sync input. > > On the software side we need to group the I and Q values, which are DMA'ed to > memory by the two DRIF instances, and make them available to userspace. The > V4L2 API used here in SDR (Software Defined Radio) mode supports such use > cases and exposes a single device node to userspace that allows control of the > two DRIF instances as a single device. To be able to implement this we need > kernel code to be aware of DRIF groups and, while binding to the DRIF > instances separately, expose only one V4L2 device to userspace for each group. > > There's no master or slave instance from a hardware point of view, but the two > instances are not interchangeable as they carry separate information. They > must thus be identified at the driver level. By master, I meant the external master device that generates the IQ data, not which of the internal DRIF blocks is a master of the other. So back to my question, does the external master device need to be described? I worry the answer now for a simple case is no, but then later people are going to have cases needing to describe more. We need to answer this question first before we can decide what this binding should look like. > Back to the DT bindings, the need to expose relationships between (mostly) > independent devices is quite common nowadays. It has been solved in some cases > by creating a separate DT node that does not correspond to any physical > hardware and whose sole purpose is to contain phandles to devices that need to > be grouped. Drivers then bind to the compatible string of that "virtual" DT > node. The proposed bonding property is a different approach to solve a similar > problem. Would it be worth it addressing the problem at a more general level > and try to design a common solution ? We already have somewhat standard ways of grouping, but they are per type of device (display, sound card, etc.). I'm not sure we gain much standardizing across these devices and to some extent that ship has sailed. Even within display subsystems, I don't think there is one style that fits all. Sometimes a parent subsystem node with children makes sense for the h/w. Sometimes that doesn't make sense and we have the virtual node with a "ports" property (like sun8i did). I've never been too happy with that style largely just because it feels like we're letting DRM define the binding. However, it's generally extra data that an OS could just ignore. There have also been many display bindings that started out with a virtual node and we got rid of it. So it's not something I like to encourage and we need to be clear when it is okay or not. To state the problem more generally (at least when using OF graph), I think the problem is simply how do we define and group multiple entry points to an OF graph. Maybe these should be graph nodes themselves rather than phandles to
Re: [RFC] New Device Tree property - "bonding"
Hi Rob, On Monday 05 Dec 2016 08:18:34 Rob Herring wrote: > On Fri, Nov 25, 2016 at 10:55 AM, Ramesh Shanmugasundaram wrote: > > Hello DT maintainers, > > > > In one of the Renesas SoCs we have a device called DRIF (Digital Radio > > Interface) controller. A DRIF channel contains 4 external pins - SCK, > > SYNC, Data pins D0 & D1. > > > > Internally a DRIF channel is made up of two SPI slave devices (also called > > sub-channels here) that share common CLK & SYNC signals but have their > > own resource set. The DRIF channel can have either one of the sub-channel > > active at a time or both. When both sub-channels are active, they need to > > be managed together as one device as they share same CLK & SYNC. We plan > > to tie these two sub-channels together with a new property called > > "renesas,bonding". > > Is there no need to describe the master device? No GPIOs, regulators > or other sideband controls needed? If that's never needed (which seems > doubtful), then I would do something different here probably with the > master device as a child of one DRIF and then phandles to master from > the other DRIFs. Otherwise, this looks fine to me. Here's a bit of background. The DRIF is an SPI receiver. It has three input pins, a clock line, a data line and a sync signal. The device is designed to be connected to a variety of data sources, usually plain SPI (1 data line), IIS (1 data line) but also radio tuners that output I/Q data (http://www.ni.com/tutorial/4805/en/) over two data lines. In the case of IQ each data sample is split in two I and Q values (typically 16 to 20 bits each in this case), and the values are transmitted serially over one data line each. The synchronization and clock signals are common to both data lines. The DRIF is optimized for this use case as the DRIF instances in the SoC (each of them having independent clocks, interrupts and control registers) are grouped by two, and the two instances in a group handle a single data line each but share the same clock and sync input. On the software side we need to group the I and Q values, which are DMA'ed to memory by the two DRIF instances, and make them available to userspace. The V4L2 API used here in SDR (Software Defined Radio) mode supports such use cases and exposes a single device node to userspace that allows control of the two DRIF instances as a single device. To be able to implement this we need kernel code to be aware of DRIF groups and, while binding to the DRIF instances separately, expose only one V4L2 device to userspace for each group. There's no master or slave instance from a hardware point of view, but the two instances are not interchangeable as they carry separate information. They must thus be identified at the driver level. Back to the DT bindings, the need to expose relationships between (mostly) independent devices is quite common nowadays. It has been solved in some cases by creating a separate DT node that does not correspond to any physical hardware and whose sole purpose is to contain phandles to devices that need to be grouped. Drivers then bind to the compatible string of that "virtual" DT node. The proposed bonding property is a different approach to solve a similar problem. Would it be worth it addressing the problem at a more general level and try to design a common solution ? -- Regards, Laurent Pinchart
Re: [RFC] New Device Tree property - "bonding"
On Fri, Nov 25, 2016 at 10:55 AM, Ramesh Shanmugasundaram wrote: > Hello DT maintainers, > > In one of the Renesas SoCs we have a device called DRIF (Digital Radio > Interface) controller. A DRIF channel contains 4 external pins - SCK, SYNC, > Data pins D0 & D1. > > Internally a DRIF channel is made up of two SPI slave devices (also called > sub-channels here) that share common CLK & SYNC signals but have their own > resource set. The DRIF channel can have either one of the sub-channel active > at a time or both. When both sub-channels are active, they need to be managed > together as one device as they share same CLK & SYNC. We plan to tie these > two sub-channels together with a new property called "renesas,bonding". Is there no need to describe the master device? No GPIOs, regulators or other sideband controls needed? If that's never needed (which seems doubtful), then I would do something different here probably with the master device as a child of one DRIF and then phandles to master from the other DRIFs. Otherwise, this looks fine to me. Rob
Re: [PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks
Hi Jose, On Monday 05 Dec 2016 12:31:30 Jose Abreu wrote: > On 05-12-2016 11:32, Laurent Pinchart wrote: > > On Monday 05 Dec 2016 10:50:19 Jose Abreu wrote: > >> On 02-12-2016 15:43, Laurent Pinchart wrote: > >>> On Friday 02 Dec 2016 14:24:01 Russell King - ARM Linux wrote: > On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent Pinchart wrote: > > From: Kieran Bingham > > > > The dw-hdmi driver declares a dev_type to distinguish platform > > specific changes. Replace this with a quirk field, so that the > > platform can specify the required quirks for the driver, rather than > > the driver becoming conditional on multiple platforms. > > > > As part of this, we rename the dw-hdmi 'spare' which is defined as the > > SVSRET bit in later documentation. > > I'd really prefer that we did not go down the broken route of adding > a set of "quirk" flags - look at what a mess SDHCI has become through > allowing that kind of practice. > > I'd much rather we find a saner structure to this - and we know that > the hardware has ID registers in it which can be used (so far) to > identify the buggy hardware. > >>> > >>> I'd much prefer something that would allow runtime identification of the > >>> device and the corresponding actions to be taken. However, the amount of > >>> documentation we have on the DWC HDMI TX IP core (and the associated > >>> PHY) is pretty limited, given that Synopsys doesn't make the > >>> documentation available publicly. Changes made to the IP core by > >>> integrators could complicate this further. I'm trying to gather as much > >>> information as possible to make clean the code up, for instance by > >>> trying to identify the PHYs used on the various platforms we support. > >>> Progress is slow on that front, there isn't enough leaked information > >>> available online :-) I haven't given up though, but I'll need more time. > >>> > >>> I don't like quirks much either. They are however already used today, > >>> even if we trigger them through dev_type instead of quirk flags. This > >>> patch came from a previous version found in a BSP that simply sprinkled > >>> several if (hdmi-> dev_type == RCAR_HDMI) through the code. For > >>> instance, > >>> > >>> - if (hdmi->dev_type == RK3288_HDMI) > >>> + if (hdmi->dev_type == RK3288_HDMI || hdmi->dev_type == RCAR_HDMI) > >>> dw_hdmi_phy_enable_spare(hdmi, 1); > >>> > >>> which I think is worse than flags as it would quickly degenerate to > >>> spaghetti code. > >>> > >>> For this specific case, we've managed to identify that on Renesas > >>> platforms the bit set by this function is called SVSRET. Its usage isn't > >>> clear yet, but I suspect it to control one of the PHY input control > >>> signals, like the other bits in the same register. I'm trying to get > >>> more information to clean the implementation further, hopefully with a > >>> way to determine whether the signal is used based on PHY identification. > >> > >> SVSRET is a low power mode consumption and is a PHY input signal > >> as you suggested. > > > > Thank you for the confirmation. Would you happen to know what SVSRET > > stands for ? > > Have no info about that. Sorry. > > >> Most of the configurable input signals of the PHY are available by the > >> controller regbank. I don't think it is possible to detect this at > >> runtime, I think you have at least to hardcode which version of the PHY > >> you are using. > >> > >> I would suggest that maybe all the PHY logic should be extracted and then > >> use callbacks to glue controller and phy. Then, depending on the PHY you > >> could use empty stubs if, for example, a given PHY did not support > >> SVSRET. Still, I don't know if this is the best option. What I do know is > >> that there are a large number of PHY's with different flavors that can > >> use the same controller. The controller has different versions also, and > >> each version can have quirks but I think it would be easier to manage > >> this driver if we had a clear distinction between PHY and controller. > > > > Agreed, I'd like to go in that direction. What makes it quite difficult is > > the lack of documentation about the PHYs :-) I've found six different PHY > > types that can be identified by the CONFIG2_ID register: > > > > Bits| Field | Description > > -- > > 7-0 | phytype | PHY interface > > | | 0x00: Legacy PHY (HDMI TX PHY) > > | | 0xb2: MHL PHY + HEAC PHY > > | | 0xc2: MHL PHY > > | | 0xe2: HDMI 3D TX PHY + HEAC PHY > > | | 0xf2: HDMI 3D TX PHY > > | | 0xf3: HDMI2 TX PHY > > > > I'm sure there's more than that. In particular I wonder how external > > vendor PHYs are identified. > > 0xFE. Thank you. Th
Re: [PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks
Hi Laurent, On 05-12-2016 11:32, Laurent Pinchart wrote: > Hi Jose, > > On Monday 05 Dec 2016 10:50:19 Jose Abreu wrote: >> On 02-12-2016 15:43, Laurent Pinchart wrote: >>> On Friday 02 Dec 2016 14:24:01 Russell King - ARM Linux wrote: On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent Pinchart wrote: > From: Kieran Bingham > > The dw-hdmi driver declares a dev_type to distinguish platform specific > changes. Replace this with a quirk field, so that the platform can > specify the required quirks for the driver, rather than the driver > becoming conditional on multiple platforms. > > As part of this, we rename the dw-hdmi 'spare' which is defined as the > SVSRET bit in later documentation. I'd really prefer that we did not go down the broken route of adding a set of "quirk" flags - look at what a mess SDHCI has become through allowing that kind of practice. I'd much rather we find a saner structure to this - and we know that the hardware has ID registers in it which can be used (so far) to identify the buggy hardware. >>> I'd much prefer something that would allow runtime identification of the >>> device and the corresponding actions to be taken. However, the amount of >>> documentation we have on the DWC HDMI TX IP core (and the associated PHY) >>> is pretty limited, given that Synopsys doesn't make the documentation >>> available publicly. Changes made to the IP core by integrators could >>> complicate this further. I'm trying to gather as much information as >>> possible to make clean the code up, for instance by trying to identify >>> the PHYs used on the various platforms we support. Progress is slow on >>> that front, there isn't enough leaked information available online :-) I >>> haven't given up though, but I'll need more time. >>> >>> I don't like quirks much either. They are however already used today, even >>> if we trigger them through dev_type instead of quirk flags. This patch >>> came from a previous version found in a BSP that simply sprinkled several >>> if (hdmi-> dev_type == RCAR_HDMI) through the code. For instance, >>> >>> - if (hdmi->dev_type == RK3288_HDMI) >>> + if (hdmi->dev_type == RK3288_HDMI || hdmi->dev_type == RCAR_HDMI) >>> dw_hdmi_phy_enable_spare(hdmi, 1); >>> >>> which I think is worse than flags as it would quickly degenerate to >>> spaghetti code. >>> >>> For this specific case, we've managed to identify that on Renesas >>> platforms the bit set by this function is called SVSRET. Its usage isn't >>> clear yet, but I suspect it to control one of the PHY input control >>> signals, like the other bits in the same register. I'm trying to get more >>> information to clean the implementation further, hopefully with a way to >>> determine whether the signal is used based on PHY identification. >> SVSRET is a low power mode consumption and is a PHY input signal >> as you suggested. > Thank you for the confirmation. Would you happen to know what SVSRET stands > for ? Have no info about that. Sorry. > >> Most of the configurable input signals of the PHY are available by the >> controller regbank. I don't think it is possible to detect this at runtime, >> I think you have at least to hardcode which version of the PHY you are >> using. >> >> I would suggest that maybe all the PHY logic should be extracted and then >> use callbacks to glue controller and phy. Then, depending on the PHY you >> could use empty stubs if, for example, a given PHY did not support SVSRET. >> Still, I don't know if this is the best option. What I do know is that there >> are a large number of PHY's with different flavors that can use the same >> controller. The controller has different versions also, and each version can >> have quirks but I think it would be easier to manage this driver if we had a >> clear distinction between PHY and controller. > Agreed, I'd like to go in that direction. What makes it quite difficult is > the > lack of documentation about the PHYs :-) I've found six different PHY types > that can be identified by the CONFIG2_ID register: > > Bits| Field | Description > -- > 7-0 | phytype | PHY interface > | | 0x00: Legacy PHY (HDMI TX PHY) > | | 0xb2: MHL PHY + HEAC PHY > | | 0xc2: MHL PHY > | | 0xe2: HDMI 3D TX PHY + HEAC PHY > | | 0xf2: HDMI 3D TX PHY > | | 0xf3: HDMI2 TX PHY > > I'm sure there's more than that. In particular I wonder how external vendor > PHYs are identified. 0xFE. > > I'm also wondering whether there's a need to keep support for the legacy PHY > signals (ENTMDS and PDZ in the PHY_CONF0 register). As far as I understand > they're not used by the Gen2 PHYs (including the external vendor PHYs),
Re: [PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks
Hello, On Friday 02 Dec 2016 18:45:46 Laurent Pinchart wrote: > On Friday 02 Dec 2016 16:08:17 Russell King - ARM Linux wrote: > > On Fri, Dec 02, 2016 at 05:43:43PM +0200, Laurent Pinchart wrote: > >> DW_HDMI_QUIRK_FC_INVIDCONF is indeed a bad name, I'll fix that. > >> > >> Do you know why this function needs to write to the HDMI_FC_INVIDCONF > >> register four times in the normal case, and once only for IMX6DL ? > > > > (I don't have much time at present, I'm buried in ARM64 crud trying to > > get a platform to boot, and working out how to debug an ARM64 platform > > that even earlycon doesn't work on... no printascii() types of easy > > debug facilities on ARM64 make this job several orders of magnitude > > harder than it needs to be...) > > Thanks all the more for taking time to reply. > > > It prevents a magenta line down the left hand side of the screen, which > > is caused when the frame composer in the HDMI Tx gets confused - > > according to the errata, it does a load of maths when you write to the > > frame composer registers, and sometimes it doesn't update properly. > > > > So, the four writes (and the number is critical) is there to persuade > > the IP to do the maths with the right values so the internal timings > > are correct. > > > > The rather confusing thing is - it's actually IMX6Q which has the more > > severe errata, not IMX6DL - the workaround of four writes is applied > > in the 6Q case. > > > > It's covered by ERR004308 in the IMX6Q Errata document (search for > > IMX6DQCE). It isn't mentioned in the IMX6DL documentation, but it > > seems that similar workaround of one write is necessary there. > > > > Some of this was determined by experimentation in conjunction with the > > errata documentation - I remember it took a while to get it right so > > that we didn't ever see the magenta line. > > That's interesting. I'll test the different options on my Renesas platform > (no write, one write, four writes) and see what is needed. Could anyone > perform the same tests on a Rockchip RK3288 system ? Daniel Stone has been nice enough to test HDMI output without the errata workaround on RK3288 and hasn't noticed any issue. I've performed the same test on R-Car H3 and haven't noticed any issue either. The i.MX6DL and i.MX6Q use a DWC HDMI TX version 1.31a and 1.30a respectively, while RK3288 and R-Car H3 uses v2.00a and v2.01a. We could enable the workaround based on the HDMI TX version. -- Regards, Laurent Pinchart
Re: [PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks
Hi Jose, On Monday 05 Dec 2016 10:50:19 Jose Abreu wrote: > On 02-12-2016 15:43, Laurent Pinchart wrote: > > On Friday 02 Dec 2016 14:24:01 Russell King - ARM Linux wrote: > >> On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent Pinchart wrote: > >>> From: Kieran Bingham > >>> > >>> The dw-hdmi driver declares a dev_type to distinguish platform specific > >>> changes. Replace this with a quirk field, so that the platform can > >>> specify the required quirks for the driver, rather than the driver > >>> becoming conditional on multiple platforms. > >>> > >>> As part of this, we rename the dw-hdmi 'spare' which is defined as the > >>> SVSRET bit in later documentation. > >> > >> I'd really prefer that we did not go down the broken route of adding > >> a set of "quirk" flags - look at what a mess SDHCI has become through > >> allowing that kind of practice. > >> > >> I'd much rather we find a saner structure to this - and we know that > >> the hardware has ID registers in it which can be used (so far) to > >> identify the buggy hardware. > > > > I'd much prefer something that would allow runtime identification of the > > device and the corresponding actions to be taken. However, the amount of > > documentation we have on the DWC HDMI TX IP core (and the associated PHY) > > is pretty limited, given that Synopsys doesn't make the documentation > > available publicly. Changes made to the IP core by integrators could > > complicate this further. I'm trying to gather as much information as > > possible to make clean the code up, for instance by trying to identify > > the PHYs used on the various platforms we support. Progress is slow on > > that front, there isn't enough leaked information available online :-) I > > haven't given up though, but I'll need more time. > > > > I don't like quirks much either. They are however already used today, even > > if we trigger them through dev_type instead of quirk flags. This patch > > came from a previous version found in a BSP that simply sprinkled several > > if (hdmi-> dev_type == RCAR_HDMI) through the code. For instance, > > > > - if (hdmi->dev_type == RK3288_HDMI) > > + if (hdmi->dev_type == RK3288_HDMI || hdmi->dev_type == RCAR_HDMI) > > dw_hdmi_phy_enable_spare(hdmi, 1); > > > > which I think is worse than flags as it would quickly degenerate to > > spaghetti code. > > > > For this specific case, we've managed to identify that on Renesas > > platforms the bit set by this function is called SVSRET. Its usage isn't > > clear yet, but I suspect it to control one of the PHY input control > > signals, like the other bits in the same register. I'm trying to get more > > information to clean the implementation further, hopefully with a way to > > determine whether the signal is used based on PHY identification. > > SVSRET is a low power mode consumption and is a PHY input signal > as you suggested. Thank you for the confirmation. Would you happen to know what SVSRET stands for ? > Most of the configurable input signals of the PHY are available by the > controller regbank. I don't think it is possible to detect this at runtime, > I think you have at least to hardcode which version of the PHY you are > using. > > I would suggest that maybe all the PHY logic should be extracted and then > use callbacks to glue controller and phy. Then, depending on the PHY you > could use empty stubs if, for example, a given PHY did not support SVSRET. > Still, I don't know if this is the best option. What I do know is that there > are a large number of PHY's with different flavors that can use the same > controller. The controller has different versions also, and each version can > have quirks but I think it would be easier to manage this driver if we had a > clear distinction between PHY and controller. Agreed, I'd like to go in that direction. What makes it quite difficult is the lack of documentation about the PHYs :-) I've found six different PHY types that can be identified by the CONFIG2_ID register: Bits| Field | Description -- 7-0 | phytype | PHY interface | | 0x00: Legacy PHY (HDMI TX PHY) | | 0xb2: MHL PHY + HEAC PHY | | 0xc2: MHL PHY | | 0xe2: HDMI 3D TX PHY + HEAC PHY | | 0xf2: HDMI 3D TX PHY | | 0xf3: HDMI2 TX PHY I'm sure there's more than that. In particular I wonder how external vendor PHYs are identified. I'm also wondering whether there's a need to keep support for the legacy PHY signals (ENTMDS and PDZ in the PHY_CONF0 register). As far as I understand they're not used by the Gen2 PHYs (including the external vendor PHYs), but I can't confirm that without more documentation (although I could test that on the platforms I have access to). > > This
Re: [PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks
Hi Laurent,
On 02-12-2016 15:43, Laurent Pinchart wrote:
> Hi Russell,
>
> On Friday 02 Dec 2016 14:24:01 Russell King - ARM Linux wrote:
>> On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent Pinchart wrote:
>>> From: Kieran Bingham
>>>
>>> The dw-hdmi driver declares a dev_type to distinguish platform specific
>>> changes. Replace this with a quirk field, so that the platform can
>>> specify the required quirks for the driver, rather than the driver
>>> becoming conditional on multiple platforms.
>>>
>>> As part of this, we rename the dw-hdmi 'spare' which is defined as the
>>> SVSRET bit in later documentation.
>> I'd really prefer that we did not go down the broken route of adding
>> a set of "quirk" flags - look at what a mess SDHCI has become through
>> allowing that kind of practice.
>>
>> I'd much rather we find a saner structure to this - and we know that
>> the hardware has ID registers in it which can be used (so far) to
>> identify the buggy hardware.
> I'd much prefer something that would allow runtime identification of the
> device and the corresponding actions to be taken. However, the amount of
> documentation we have on the DWC HDMI TX IP core (and the associated PHY) is
> pretty limited, given that Synopsys doesn't make the documentation available
> publicly. Changes made to the IP core by integrators could complicate this
> further. I'm trying to gather as much information as possible to make clean
> the code up, for instance by trying to identify the PHYs used on the various
> platforms we support. Progress is slow on that front, there isn't enough
> leaked information available online :-) I haven't given up though, but I'll
> need more time.
>
> I don't like quirks much either. They are however already used today, even if
> we trigger them through dev_type instead of quirk flags. This patch came from
> a previous version found in a BSP that simply sprinkled several if (hdmi-
>> dev_type == RCAR_HDMI) through the code. For instance,
> - if (hdmi->dev_type == RK3288_HDMI)
> + if (hdmi->dev_type == RK3288_HDMI || hdmi->dev_type == RCAR_HDMI)
> dw_hdmi_phy_enable_spare(hdmi, 1);
>
> which I think is worse than flags as it would quickly degenerate to spaghetti
> code.
>
> For this specific case, we've managed to identify that on Renesas platforms
> the bit set by this function is called SVSRET. Its usage isn't clear yet, but
> I suspect it to control one of the PHY input control signals, like the other
> bits in the same register. I'm trying to get more information to clean the
> implementation further, hopefully with a way to determine whether the signal
> is used based on PHY identification.
SVSRET is a low power mode consumption and is a PHY input signal
as you suggested. Most of the configurable input signals of the
PHY are available by the controller regbank. I don't think it is
possible to detect this at runtime, I think you have at least to
hardcode which version of the PHY you are using.
I would suggest that maybe all the PHY logic should be extracted
and then use callbacks to glue controller and phy. Then,
depending on the PHY you could use empty stubs if, for example, a
given PHY did not support SVSRET. Still, I don't know if this is
the best option. What I do know is that there are a large number
of PHY's with different flavors that can use the same controller.
The controller has different versions also, and each version can
have quirks but I think it would be easier to manage this driver
if we had a clear distinction between PHY and controller.
>
> This is all work in progress, and if anyone has access to any documentation
> and can provide additional information I'll be grateful.
>
>>> Signed-off-by: Kieran Bingham
>>> Signed-off-by: Laurent Pinchart
>>>
>>> ---
>>>
>>> drivers/gpu/drm/bridge/dw-hdmi.c| 14 ++
>>> drivers/gpu/drm/bridge/dw-hdmi.h| 4 ++--
>>> drivers/gpu/drm/imx/dw_hdmi-imx.c | 3 +--
>>> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
>>> include/drm/bridge/dw_hdmi.h| 12 +---
>>> 5 files changed, 15 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
>>> b/drivers/gpu/drm/bridge/dw-hdmi.c index 06a44a2cdf3b..26607185722f
>>> 100644
>>> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
>>> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
>>> @@ -118,7 +118,6 @@ struct dw_hdmi {
>>> struct drm_bridge bridge;
>>> struct platform_device *audio;
>>>
>>> - enum dw_hdmi_devtype dev_type;
>>> struct device *dev;
>>> struct clk *isfr_clk;
>>> struct clk *iahb_clk;
>>> @@ -896,11 +895,11 @@ static void dw_hdmi_phy_enable_tmds(struct dw_hdmi
>>> *hdmi, u8 enable)
>>> HDMI_PHY_CONF0_ENTMDS_MASK);
>>> }
>>>
>>> -static void dw_hdmi_phy_enable_spare(struct dw_hdmi *hdmi, u8 enable)
>>> +static void dw_hdmi_phy_enable_svsret(struct dw_hdmi *hdmi, u8 enable)
>>> {
>>> hdmi_mask_writeb(hdmi, e
[PATCH v2 4/5] ARM: shmobile: r8a7791: Allow booting secondary CPU cores in debug mode
Now debug resource reset is handled properly, allow booting secondary
CPU cores when hardware debug mode is enabled (MD21=1, SW8-4=OFF on
koelsch) on legacy r8a7791.
Signed-off-by: Geert Uytterhoeven
---
v2:
- No changes.
---
arch/arm/mach-shmobile/smp-r8a7791.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/arch/arm/mach-shmobile/smp-r8a7791.c
b/arch/arm/mach-shmobile/smp-r8a7791.c
index 2d6417af73b5b722..2948c22cfc53026c 100644
--- a/arch/arm/mach-shmobile/smp-r8a7791.c
+++ b/arch/arm/mach-shmobile/smp-r8a7791.c
@@ -42,21 +42,9 @@ static void __init r8a7791_smp_prepare_cpus(unsigned int
max_cpus)
rcar_gen2_pm_init();
}
-static int r8a7791_smp_boot_secondary(unsigned int cpu,
- struct task_struct *idle)
-{
- /* Error out when hardware debug mode is enabled */
- if (rcar_gen2_read_mode_pins() & BIT(21)) {
- pr_warn("Unable to boot CPU%u when MD21 is set\n", cpu);
- return -ENOTSUPP;
- }
-
- return shmobile_smp_apmu_boot_secondary(cpu, idle);
-}
-
const struct smp_operations r8a7791_smp_ops __initconst = {
.smp_prepare_cpus = r8a7791_smp_prepare_cpus,
- .smp_boot_secondary = r8a7791_smp_boot_secondary,
+ .smp_boot_secondary = shmobile_smp_apmu_boot_secondary,
#ifdef CONFIG_HOTPLUG_CPU
.cpu_can_disable= shmobile_smp_cpu_can_disable,
.cpu_die= shmobile_smp_apmu_cpu_die,
--
1.9.1
[PATCH v2 0/5] ARM: shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode
Hi Simon, Magnus,
This patch series allows booting secondary CPU cores on R-Car Gen2 when
hardware debug mode is enabled. In this mode, reset requests derived
from power-shutoff to the AP-system CPU cores must be enabled before the
AP-system CPU cores resume from power-shutoff for the first time.
Else resume may fail, causing the system to hang during boot.
Currently we avoid the hang by prohibiting booting secondary CPU cores
when hardware debug mode is enabled (except on legacy r8a7790, see
below).
On all R-Car Gen2 SoCs, hardware debug mode is enabled by setting
MD21=1. On both Koelsch and Lager, this is done by setting mode switch
SW8-4 to OFF.
Unfortunately the hang is not easy to reproduce: I only saw it (on
Koelsch) during real cold boot (power off during the night), and even
then it's not guaranteed to trigger. Pressing the reset button
afterwards recovers the system, and a subsequent boot will succeed
(incl. secondary CPU core boot).
This series configures the reset requests as documented in the R-Car
Gen2 datasheet, and removes the check for MD21 during secondary CPU
bringup. It was inspired by CPU-specific patches in the BSP by
Nakamura-san.
And finally, we get rid of reading the Mode Monitoring register using
hardcoded addresses in platform code!
This series also fixes a minor regression introduced by adding the
"renesas,apmu" enable-method on Lager, where secondary CPU cores are no
longer available when hardware debug mode is enabled.
This has been boot-tested on r8a7791/koelsch (both debug mode and normal
mode), on r8a7790/lager, r8a7792/blanche, and r8a7793/gose (normal mode
only), and on r8a7794/alt (normal mode UP only). Its core parts have
been in renesas-drivers since renesas-drivers-2016-09-06-v4.8-rc5.
Changes compared to v1:
- Add Tested-by,
- New patch "ARM: shmobile: rcar-gen2: Remove unused
rcar_gen2_read_mode_pins()".
This series is against renesas-devel-20161202-v4.9-rc7, with my
"rcar-rst" branch merged in, which resulted in a merge conflict.
The latter dependency is present in clk-next, and expected to land
upstream in v4.10-rc1.
For your convenience (and for conflict resolution), this series is also
available in the topic/rcar-secondary-booting-in-debug-mode-v2 branch of
my renesas-drivers git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
Thanks for applying!
Geert Uytterhoeven (5):
ARM: shmobile: apmu: Add more register documentation
ARM: shmobile: apmu: Add debug resource reset for secondary CPU boot
ARM: shmobile: apmu: Allow booting secondary CPU cores in debug mode
ARM: shmobile: r8a7791: Allow booting secondary CPU cores in debug
mode
ARM: shmobile: rcar-gen2: Remove unused rcar_gen2_read_mode_pins()
arch/arm/mach-shmobile/platsmp-apmu.c| 41 +++-
arch/arm/mach-shmobile/rcar-gen2.h | 2 --
arch/arm/mach-shmobile/setup-rcar-gen2.c | 18 --
arch/arm/mach-shmobile/smp-r8a7791.c | 14 +--
4 files changed, 25 insertions(+), 50 deletions(-)
--
1.9.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 v2 2/5] ARM: shmobile: apmu: Add debug resource reset for secondary CPU boot
In debug mode (MD21=1), reset requests derived from power-shutoff to the
AP-system CPU cores must be enabled before the AP-system CPU cores
resume from power-shutoff for the first time. Else resume may fail,
causing the system to hang during boot.
As setting these bits is a no-op in normal mode, there's no need to
check the actual state of MD21 first.
Inspired by CPU-specific patches in the BSP by Hisashi Nakamura
.
Signed-off-by: Geert Uytterhoeven
Tested-by: Hiep Cao Minh
---
v2:
- Add Tested-by.
---
arch/arm/mach-shmobile/platsmp-apmu.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c
b/arch/arm/mach-shmobile/platsmp-apmu.c
index 933f9b9024050223..7e4ca6788be521dc 100644
--- a/arch/arm/mach-shmobile/platsmp-apmu.c
+++ b/arch/arm/mach-shmobile/platsmp-apmu.c
@@ -35,12 +35,18 @@
#define PSTR_OFFS 0x40 /* Power Status Register */
#define CPUNCR_OFFS(n) (0x100 + (0x10 * (n)))
/* CPUn Power Status Control Register */
+#define DBGRCR_OFFS0x180 /* Debug Resource Reset Control Reg. */
/* Power Status Register */
#define CPUNST(r, n) (((r) >> (n * 4)) & 3) /* CPUn Status Bit */
#define CPUST_RUN 0 /* Run Mode */
#define CPUST_STANDBY 3 /* CoreStandby Mode */
+/* Debug Resource Reset Control Register */
+#define DBGCPUREN BIT(24) /* CPU Other Reset Request Enable */
+#define DBGCPUNREN(n) BIT((n) + 20) /* CPUn Reset Request Enable */
+#define DBGCPUPREN BIT(19) /* CPU Peripheral Reset Req. Enable */
+
static int __maybe_unused apmu_power_on(void __iomem *p, int bit)
{
/* request power on */
@@ -84,6 +90,8 @@ static int __maybe_unused apmu_wrap(int cpu, int (*fn)(void
__iomem *p, int cpu)
#ifdef CONFIG_SMP
static void apmu_init_cpu(struct resource *res, int cpu, int bit)
{
+ u32 x;
+
if ((cpu >= ARRAY_SIZE(apmu_cpus)) || apmu_cpus[cpu].iomem)
return;
@@ -91,6 +99,11 @@ static void apmu_init_cpu(struct resource *res, int cpu, int
bit)
apmu_cpus[cpu].bit = bit;
pr_debug("apmu ioremap %d %d %pr\n", cpu, bit, res);
+
+ /* Setup for debug mode */
+ x = readl(apmu_cpus[cpu].iomem + DBGRCR_OFFS);
+ x |= DBGCPUREN | DBGCPUNREN(bit) | DBGCPUPREN;
+ writel(x, apmu_cpus[cpu].iomem + DBGRCR_OFFS);
}
static void apmu_parse_cfg(void (*fn)(struct resource *res, int cpu, int bit),
--
1.9.1
[PATCH v2 3/5] ARM: shmobile: apmu: Allow booting secondary CPU cores in debug mode
Now debug resource reset is handled properly, allow booting secondary
CPU cores when hardware debug mode is enabled (MD21=1) on SoCs using the
"renesas,apmu" enable method.
Signed-off-by: Geert Uytterhoeven
Tested-by: Hiep Cao Minh
---
v2:
- Add Tested-by.
---
arch/arm/mach-shmobile/platsmp-apmu.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c
b/arch/arm/mach-shmobile/platsmp-apmu.c
index 7e4ca6788be521dc..e19266844e16126b 100644
--- a/arch/arm/mach-shmobile/platsmp-apmu.c
+++ b/arch/arm/mach-shmobile/platsmp-apmu.c
@@ -216,21 +216,9 @@ static void __init
shmobile_smp_apmu_prepare_cpus_dt(unsigned int max_cpus)
rcar_gen2_pm_init();
}
-static int shmobile_smp_apmu_boot_secondary_md21(unsigned int cpu,
-struct task_struct *idle)
-{
- /* Error out when hardware debug mode is enabled */
- if (rcar_gen2_read_mode_pins() & BIT(21)) {
- pr_warn("Unable to boot CPU%u when MD21 is set\n", cpu);
- return -ENOTSUPP;
- }
-
- return shmobile_smp_apmu_boot_secondary(cpu, idle);
-}
-
static struct smp_operations apmu_smp_ops __initdata = {
.smp_prepare_cpus = shmobile_smp_apmu_prepare_cpus_dt,
- .smp_boot_secondary = shmobile_smp_apmu_boot_secondary_md21,
+ .smp_boot_secondary = shmobile_smp_apmu_boot_secondary,
#ifdef CONFIG_HOTPLUG_CPU
.cpu_can_disable= shmobile_smp_cpu_can_disable,
.cpu_die= shmobile_smp_apmu_cpu_die,
--
1.9.1
[PATCH v2 1/5] ARM: shmobile: apmu: Add more register documentation
Signed-off-by: Geert Uytterhoeven
Tested-by: Hiep Cao Minh
---
v2:
- Add Tested-by.
---
arch/arm/mach-shmobile/platsmp-apmu.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c
b/arch/arm/mach-shmobile/platsmp-apmu.c
index 0c6bb458b7a45128..933f9b9024050223 100644
--- a/arch/arm/mach-shmobile/platsmp-apmu.c
+++ b/arch/arm/mach-shmobile/platsmp-apmu.c
@@ -31,9 +31,15 @@
int bit;
} apmu_cpus[NR_CPUS];
-#define WUPCR_OFFS 0x10
-#define PSTR_OFFS 0x40
-#define CPUNCR_OFFS(n) (0x100 + (0x10 * (n)))
+#define WUPCR_OFFS 0x10 /* Wake Up Control Register */
+#define PSTR_OFFS 0x40 /* Power Status Register */
+#define CPUNCR_OFFS(n) (0x100 + (0x10 * (n)))
+ /* CPUn Power Status Control Register */
+
+/* Power Status Register */
+#define CPUNST(r, n) (((r) >> (n * 4)) & 3) /* CPUn Status Bit */
+#define CPUST_RUN 0 /* Run Mode */
+#define CPUST_STANDBY 3 /* CoreStandby Mode */
static int __maybe_unused apmu_power_on(void __iomem *p, int bit)
{
@@ -59,7 +65,7 @@ static int __maybe_unused apmu_power_off_poll(void __iomem
*p, int bit)
int k;
for (k = 0; k < 1000; k++) {
- if (((readl_relaxed(p + PSTR_OFFS) >> (bit * 4)) & 0x03) == 3)
+ if (CPUNST(readl_relaxed(p + PSTR_OFFS), bit) == CPUST_STANDBY)
return 1;
mdelay(1);
--
1.9.1
[PATCH v2 5/5] ARM: shmobile: rcar-gen2: Remove unused rcar_gen2_read_mode_pins()
After
1. commit 9f5ce39ddb8f68b3 ("ARM: shmobile: rcar-gen2: Obtain extal
frequency from DT"),
2. commit 80951f04c3f92533 ("ARM: shmobile: rcar-gen2: Stop passing
mode pins state to clock driver"),
3. and handling of debug resource reset,
there are no more users of rcar_gen2_read_mode_pins() left.
Remove the function and its support definitions.
Signed-off-by: Geert Uytterhoeven
---
v2:
- New.
---
arch/arm/mach-shmobile/rcar-gen2.h | 2 --
arch/arm/mach-shmobile/setup-rcar-gen2.c | 18 --
2 files changed, 20 deletions(-)
diff --git a/arch/arm/mach-shmobile/rcar-gen2.h
b/arch/arm/mach-shmobile/rcar-gen2.h
index 8a66b4aae03548ce..6792e249cf56d5d5 100644
--- a/arch/arm/mach-shmobile/rcar-gen2.h
+++ b/arch/arm/mach-shmobile/rcar-gen2.h
@@ -2,8 +2,6 @@
#define __ASM_RCAR_GEN2_H__
void rcar_gen2_timer_init(void);
-#define MD(nr) BIT(nr)
-u32 rcar_gen2_read_mode_pins(void);
void rcar_gen2_reserve(void);
void rcar_gen2_pm_init(void);
diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c
b/arch/arm/mach-shmobile/setup-rcar-gen2.c
index ac63fa407b6465d8..52d466b759730d74 100644
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
@@ -29,24 +29,6 @@
#include "common.h"
#include "rcar-gen2.h"
-#define MODEMR 0xe6160060
-
-u32 rcar_gen2_read_mode_pins(void)
-{
- static u32 mode;
- static bool mode_valid;
-
- if (!mode_valid) {
- void __iomem *modemr = ioremap_nocache(MODEMR, 4);
- BUG_ON(!modemr);
- mode = ioread32(modemr);
- iounmap(modemr);
- mode_valid = true;
- }
-
- return mode;
-}
-
static unsigned int __init get_extal_freq(void)
{
struct device_node *cpg, *extal;
--
1.9.1
[RFCv2 1/2] gpio-rz: Port to v3.18
Fix invalid return value in gpio remove function
Signed-off-by: Jacopo Mondi
---
drivers/gpio/gpio-rz.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-rz.c b/drivers/gpio/gpio-rz.c
index a933dab..cb8f785 100644
--- a/drivers/gpio/gpio-rz.c
+++ b/drivers/gpio/gpio-rz.c
@@ -175,7 +175,8 @@ static int rz_gpio_remove(struct platform_device *pdev)
{
struct rz_gpio_priv *p = platform_get_drvdata(pdev);
- return gpiochip_remove(&p->gpio_chip);
+ gpiochip_remove(&p->gpio_chip);
+ return 0;
}
static const struct of_device_id rz_gpio_dt_ids[] = {
--
2.7.4
[RFCv2 2/2] dts: arm: genmai: Add MAXDESREF4x spidev
Add device node for the MAX11100 evaluation board connected to Genmai's
CN2.
The evaluation kit is connected to 3 GPIO lines configured as bitbanged
SPI master interface.
Signed-off-by: Jacopo Mondi
---
arch/arm/boot/dts/r7s72100-genmai.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts
b/arch/arm/boot/dts/r7s72100-genmai.dts
index 233908b..659efbf 100644
--- a/arch/arm/boot/dts/r7s72100-genmai.dts
+++ b/arch/arm/boot/dts/r7s72100-genmai.dts
@@ -46,6 +46,23 @@
};
};
+ spi-gpio {
+ compatible = "spi-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio-miso = <&port11 10 GPIO_ACTIVE_HIGH>;
+ gpio-sck = <&port11 9 GPIO_ACTIVE_HIGH>;
+ num-chipselects = <1>;
+ cs-gpios = <&port11 11 GPIO_ACTIVE_HIGH>;
+ status = "ok";
+
+ maxrefdes4x@0 {
+ compatible = "spidev";
+ reg = <0>;
+ spi-max-frequency = <24>;
+ };
+ };
};
&extal_clk {
@@ -123,3 +140,7 @@
spi-max-frequency = <500>;
};
};
+
+&port11 {
+ status = "okay";
+};
--
2.7.4
Re: [RFC 3/3] spidev: Add back "linux,spidev" as compatible
Hi Geert,
On 03/12/2016 11:30, Geert Uytterhoeven wrote:
Hi Jacopo,
On Fri, Dec 2, 2016 at 4:43 PM, Jacopo Mondi wrote:
spidev is not meant to be configured directly from DTS anymore.
Since we're prototyping, add the "linux,spidev" compatibility string
back
I guess you needed this because you used "linux,spidev" in your DTS?
With "spidev", it should work out-of-the-box.
Oh, yes it does!
I can drop this patch and use "spidev" in [2/3]
Thanks
j
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
[RFCv2 0/3] Enable and test MAXREFDES4# on Genmai board
Hello Magnus and Geert, list, this patch series enable the creation of a spidev device though which interface to a MAXREFDES4# MAX11100-ADC evaluation kit connected to Genmai CON2 expansion header. The series is not intended for inclusion but will probably serve as base for future integration of MAX11100 ADC driver. The series is based on branch "genmai-gpio-and-pfc" of Geert's tree at git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git and target Linux v3.18 The series fix a compilation error for RZ gpio driver and register a spidev device on a gpio based SPI master. The test bed is setup as: P11_11 (CN2 pin 5) connected as CS P11_10 (CN2 pin 6) connected as MISO P11_9 (CN2 pin 7) connected as SCLK P11_8 (CN2 pin 8) connected as AIN The ADC input is connected to gpio port 11 pin 8 (gpio863) and ADC functionalities have been tested reading the results of successive analog-to-digital conversions and verifying they match the gpio863 output value. Thanks j v1 -> v2: * use "spidev" as compatible string in v1 [2/3] and drop [3/3] consequentially. * incorporate Geert's comments in [2/3] DTS file Jacopo Mondi (2): gpio-rz: Port to v3.18 dts: arm: genmai: Add MAXDESREF4x spidev arch/arm/boot/dts/r7s72100-genmai.dts | 21 + drivers/gpio/gpio-rz.c| 3 ++- 2 files changed, 23 insertions(+), 1 deletion(-) -- 2.7.4
Re: [PATCH 1/2] arm64: dts: r8a7795: add sound CTU support
Hi Geert
> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > @@ -1182,6 +1184,17 @@
> > };
> > };
> >
> > + 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 { };
>
> With W=1:
>
> Warning (unit_address_vs_reg): Node
> /sound@ec50/rcar_sound,ctu/ctu@0 has a unit name, but no reg
> property
>
> "ctu00: ctu-0 { };" etc...
Ohh.. indeed.
Thanks. will send v2 patch
Best regards
---
Kuninori Morimoto
Re: [PATCH 2/2] arm64: dts: r8a7795: add sound MIX support
Hi Morimoto-san,
On Mon, Dec 5, 2016 at 5:42 AM, Kuninori Morimoto
wrote:
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -1184,6 +1186,11 @@
> };
> };
>
> + rcar_sound,mix {
> + mix0: mix@0 { };
> + mix1: mix@1 { };
With W=1:
Warning (unit_address_vs_reg): Node
/sound@ec50/rcar_sound,mix/mix@0 has a unit name, but no reg
property
"mix0: mix-0 { };" etc.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/2] arm64: dts: r8a7795: add sound CTU support
Hi Morimoto-san,
On Mon, Dec 5, 2016 at 5:42 AM, Kuninori Morimoto
wrote:
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -1182,6 +1184,17 @@
> };
> };
>
> + 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 { };
With W=1:
Warning (unit_address_vs_reg): Node
/sound@ec50/rcar_sound,ctu/ctu@0 has a unit name, but no reg
property
"ctu00: ctu-0 { };" etc...
> + };
> +
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
