Re: [PATCH 1/2] arm64: dts: r8a77990: Add SDHI device nodes
On 11/06/2018 11:35 AM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Tue, Nov 6, 2018 at 11:32 AM Marek Vasut wrote:
>> On 11/06/2018 06:26 AM, Yoshihiro Shimoda wrote:
From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:41 AM
From: Takeshi Kihara
This patch adds SDHI{0,1,3} device nodes for the r8a77990 SoC.
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
>>>
>>> Thank you for the patch!
>>>
>>> Reviewed-by: Yoshihiro Shimoda
>>>
>>> I guess this patch and the 2/2 patch for ebisu have to be merged into a
>>> patch though.
>>
>> I wonder about that, 1/2 is adding SDHI DT nodes for an SoC, 2/2 is
>> enabling SDHI on a particular board, which I think should be separate.
>
> The arm-soc maintainers tend to disagree, that's why Shimoda-san asked
> to combine them.
Combined patch is out.
--
Best regards,
Marek Vasut
Re: [PATCH] drm: rcar-du: Fix external clock error checks
Hi Laurent,
Thank you for the patch,
On 06/11/2018 15:39, Laurent Pinchart wrote:
> The rcar-du driver supports probe deferral for external clocks, but
> implements it badly by checking the wrong pointer due to a bad copy and
> paste. Fix it.
>
> While at it, reject invalid clocks outright for DU channels that have a
> display PLL, as the external clock is mandatory in that case. This
> avoids a WARN_ON() at runtime.
>
> Fixes: 1b30dbde8596 ("drm: rcar-du: Add support for external pixel clock")
> Reported-by: Kuninori Morimoto
> Signed-off-by: Laurent Pinchart
This looks good to me:
Reviewed-by: Kieran Bingham
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index d18a342626b5..79021d7aa3ce 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -226,9 +226,6 @@ static void rcar_du_crtc_set_display_timing(struct
> rcar_du_crtc *rcrtc)
>* system clock, and have no internal clock divider.
>*/
>
> - if (WARN_ON(!rcrtc->extclock))
> - return;
> -
> /*
>* The H3 ES1.x exhibits dot clock duty cycle stability issues.
>* We can work around them by configuring the DPLL to twice the
> @@ -1113,9 +1110,16 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
> unsigned int swindex,
> clk = devm_clk_get(rcdu->dev, clk_name);
> if (!IS_ERR(clk)) {
> rcrtc->extclock = clk;
> - } else if (PTR_ERR(rcrtc->clock) == -EPROBE_DEFER) {
> - dev_info(rcdu->dev, "can't get external clock %u\n", hwindex);
> + } else if (PTR_ERR(clk) == -EPROBE_DEFER) {
> return -EPROBE_DEFER;
> + } else if (rcdu->info->dpll_mask & BIT(hwindex)) {
> + /*
> + * DU channels that have a display PLL can't use the internal
> + * system clock and thus require an external clock.
> + */
> + ret = PTR_ERR(clk);
> + dev_err(rcdu->dev, "can't get dclkin.%u: %d\n", hwindex, ret);
> + return ret;
> }
>
> init_waitqueue_head(&rcrtc->flip_wait);
>
[PATCH V3] arm64: dts: r8a77990: ebisu: Add and enable SDHI device nodes
From: Takeshi Kihara
This patch adds SDHI{0,1,3} device nodes for the r8a77990 SoC
and enables SD card slot connected to SDHI0, micro SD card slot
connected to SDHI1 and eMMC connected to SDHI3 on the Ebisu board
using the R8A77990 SoC.
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
V2: - Deduplicated regular and UHS pins
- Added sdhi3_ds pin pinmux
V3: - Squash two patches, one adding SDHI nodes to R8A77990 E3 DTSI
and another enabling them on E3 Ebisu, together.
---
.../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 130 ++
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 36 +
2 files changed, 166 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 0b5aead76077..306b35f0f541 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -129,6 +129,15 @@
};
};
+ reg_1p8v: regulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
reg_3p3v: regulator1 {
compatible = "regulator-fixed";
regulator-name = "fixed-3.3V";
@@ -180,6 +189,54 @@
#clock-cells = <0>;
clock-frequency = <7425>;
};
+
+ vcc_sdhi0: regulator-vcc-sdhi0 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI0 Vcc";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+
+ gpio = <&gpio5 17 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vccq_sdhi0: regulator-vccq-sdhi0 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI0 VccQ";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = <&gpio5 18 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <330 1
+ 180 0>;
+ };
+
+ vcc_sdhi1: regulator-vcc-sdhi1 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI1 Vcc";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+
+ gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vccq_sdhi1: regulator-vccq-sdhi1 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI1 VccQ";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = <&gpio3 15 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <330 1
+ 180 0>;
+ };
};
&audio_clk_a {
@@ -415,6 +472,36 @@
function = "scif2";
};
+ sdhi0_pins: sd0 {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <3300>;
+ };
+
+ sdhi0_pins_uhs: sd0_uhs {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <1800>;
+ };
+
+ sdhi1_pins: sd1 {
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
+ power-source = <3300>;
+ };
+
+ sdhi1_pins_uhs: sd1_uhs {
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
+ power-source = <1800>;
+ };
+
+ sdhi3_pins: sd3 {
+ groups = "sdhi3_data8", "sdhi3_ctrl", "sdhi3_ds";
+ function = "sdhi3";
+ power-source = <1800>;
+ };
+
sound_pins: sound {
groups = "ssi01239_ctrl", "ssi0_data", "ssi1_data";
function = "ssi";
@@ -531,3 +618,46 @@
status = "okay";
};
+
+&sdhi0 {
+ pinctrl-0 = <&sdhi0_pins>;
+ pinctrl-1 = <&sdhi0_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <&vcc_sdhi0>;
+ vqmmc-supply = <&vccq_sdhi0>;
+ cd-gpios = <&gpio3 12 GPIO_ACTIVE_LOW>;
+ wp-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
+ bus-width = <4>;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
+
+&sdhi1 {
+ pinctrl-0 = <&sdhi1_pins>;
+ pinctrl-1 = <&sdhi1_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <&vcc_sdhi1>;
+ vqmmc-supply = <&vccq_sdhi1>;
+
Re: IOMMU breakage on arm64
Hi Geert,
On 2018-11-06 7:44 pm, Geert Uytterhoeven wrote:
Hi Christoph et al,
On Tue, Oct 23, 2018 at 1:40 AM Linux Kernel Mailing List
wrote:
Commit: b4ebe6063204da58e48600b810a97c29ae9e5d12
Parent: 7d21ee4c719f00896767ce19c4c01a56374c2ced
Refname:refs/heads/master
Web:
https://git.kernel.org/torvalds/c/b4ebe6063204da58e48600b810a97c29ae9e5d12
Author: Christoph Hellwig
AuthorDate: Thu Sep 20 14:04:08 2018 +0200
Committer: Christoph Hellwig
CommitDate: Mon Oct 1 07:28:03 2018 -0700
dma-direct: implement complete bus_dma_mask handling
Instead of rejecting devices with a too small bus_dma_mask we can handle
by taking the bus dma_mask into account for allocations and bounce
buffering decisions.
Signed-off-by: Christoph Hellwig
I have bisected the following crash to the above commit:
I think that commit mostly just changes the presentation of my
underlying cockup - see here for what should fix it:
https://patchwork.kernel.org/patch/10670177/
I have a feeling we've ironed out crash-on-early-domain-free bugs in the
SMMU drivers already - arm-smmu certainly has an early return in
arm_smmu_destroy_domain_context() which should behave exactly like your
diff below, while I think arm-smmu-v3 gets away with it by virtue of
smmu_domain->cfg being unset, but I'll double-check that when I'm fresh
tomorrow (Jean-Philippe reported SMMUv3 hitting the DMA thing to me
internally, but didn't mention any crash).
Thanks for the report,
Robin.
ipmmu-vmsa e67b.mmu: Cannot accommodate DMA translation for
IOMMU page tables
sata_rcar ee30.sata: Unable to initialize IPMMU context
iommu: Failed to add device ee30.sata to group 0: -22
Unable to handle kernel NULL pointer dereference at virtual
address 0038
Mem abort info:
ESR = 0x9604
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x0004
CM = 0, WnR = 0
[0038] user address but active_mm is swapper
Internal error: Oops: 9604 [#1] PREEMPT SMP
CPU: 2 PID: 51 Comm: kworker/2:1 Not tainted
4.20.0-rc1-arm64-renesas-dirty #74
Hardware name: Renesas Salvator-X 2nd version board based on
r8a7795 ES2.0+ (DT)
Workqueue: events deferred_probe_work_func
pstate: 6005 (nZCv daif -PAN -UAO)
pc : ipmmu_domain_free+0x1c/0xa0
lr : ipmmu_domain_free+0x14/0xa0
sp : 09c9b990
x29: 09c9b990 x28:
x27: 08dff000 x26:
x25: 08dd9000 x24: 0014
x23: 8006fffdbb20 x22: 08dff000
x21: 8006f898e680 x20: 8006f8fa6c00
x19: 8006f8fa6c08 x18: 0037
x17: 0020 x16: 08a8f780
x15: 8006fb096f10 x14: 8006f93731c8
x13: x12: 8006fb096f10
x11: 8006f9372fe8 x10: 08dff708
x9 : 8006fb096f50 x8 : 08dff708
x7 : 089f1858 x6 :
x5 : x4 : 8006f89a3000
x3 : 8006f7131000 x2 : 8006fb2b5700
x1 : x0 : 0028
Process kworker/2:1 (pid: 51, stack limit = 0x(ptrval))
Call trace:
ipmmu_domain_free+0x1c/0xa0
iommu_group_release+0x48/0x68
kobject_put+0x74/0xe8
kobject_del.part.0+0x3c/0x50
kobject_put+0x60/0xe8
iommu_group_get_for_dev+0xa8/0x1f0
ipmmu_add_device+0x1c/0x40
of_iommu_configure+0x118/0x190
of_dma_configure+0xcc/0x1f0
platform_dma_configure+0x18/0x28
really_probe+0x94/0x2a8
driver_probe_device+0x58/0x100
__device_attach_driver+0x90/0xd0
bus_for_each_drv+0x64/0xc8
__device_attach+0xd8/0x130
device_initial_probe+0x10/0x18
bus_probe_device+0x98/0xa0
deferred_probe_work_func+0x74/0xb0
process_one_work+0x294/0x6f0
worker_thread+0x238/0x460
kthread+0x120/0x128
ret_from_fork+0x10/0x1c
Code: aa0003f3 97ffeb1a d1002274 f85f8261 (f9401c20)
---[ end trace 4c46c7fd7cd07245 ]---
Reproducing on v4.20-rc1 requires CONFIG_IPMMU_VMSA=y, and whitelisting
SATA for IOMMU use (https://patchwork.kernel.org/patch/10544059/).
For older versions you also have to backport commit 3a0832d093693ede ("arm64:
dts: renesas: salvator-xs: enable SATA").
Actually there are two issues at hand:
1) drivers/iommu/io-pgtable-arm.c:__arm_lpae_alloc_pages() allocates
memory (above 4 GiB) and maps it for DMA use, but it is rejected due
to:
dma_map_single(dev, pages, size, DMA_TO_DEVICE) != virt_to_phys(pages)
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -27,7 +27,8 @@ static inline bool dma_capable(struct device *dev, dma_addr_t
addr, size_t size)
if (!dev->dma_mask)
return false;
- return addr + size
IOMMU breakage on arm64 (was: Re: dma-direct: implement complete bus_dma_mask handling)
Hi Christoph et al,
On Tue, Oct 23, 2018 at 1:40 AM Linux Kernel Mailing List
wrote:
> Commit: b4ebe6063204da58e48600b810a97c29ae9e5d12
> Parent: 7d21ee4c719f00896767ce19c4c01a56374c2ced
> Refname:refs/heads/master
> Web:
> https://git.kernel.org/torvalds/c/b4ebe6063204da58e48600b810a97c29ae9e5d12
> Author: Christoph Hellwig
> AuthorDate: Thu Sep 20 14:04:08 2018 +0200
> Committer: Christoph Hellwig
> CommitDate: Mon Oct 1 07:28:03 2018 -0700
>
> dma-direct: implement complete bus_dma_mask handling
>
> Instead of rejecting devices with a too small bus_dma_mask we can handle
> by taking the bus dma_mask into account for allocations and bounce
> buffering decisions.
>
> Signed-off-by: Christoph Hellwig
I have bisected the following crash to the above commit:
ipmmu-vmsa e67b.mmu: Cannot accommodate DMA translation for
IOMMU page tables
sata_rcar ee30.sata: Unable to initialize IPMMU context
iommu: Failed to add device ee30.sata to group 0: -22
Unable to handle kernel NULL pointer dereference at virtual
address 0038
Mem abort info:
ESR = 0x9604
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x0004
CM = 0, WnR = 0
[0038] user address but active_mm is swapper
Internal error: Oops: 9604 [#1] PREEMPT SMP
CPU: 2 PID: 51 Comm: kworker/2:1 Not tainted
4.20.0-rc1-arm64-renesas-dirty #74
Hardware name: Renesas Salvator-X 2nd version board based on
r8a7795 ES2.0+ (DT)
Workqueue: events deferred_probe_work_func
pstate: 6005 (nZCv daif -PAN -UAO)
pc : ipmmu_domain_free+0x1c/0xa0
lr : ipmmu_domain_free+0x14/0xa0
sp : 09c9b990
x29: 09c9b990 x28:
x27: 08dff000 x26:
x25: 08dd9000 x24: 0014
x23: 8006fffdbb20 x22: 08dff000
x21: 8006f898e680 x20: 8006f8fa6c00
x19: 8006f8fa6c08 x18: 0037
x17: 0020 x16: 08a8f780
x15: 8006fb096f10 x14: 8006f93731c8
x13: x12: 8006fb096f10
x11: 8006f9372fe8 x10: 08dff708
x9 : 8006fb096f50 x8 : 08dff708
x7 : 089f1858 x6 :
x5 : x4 : 8006f89a3000
x3 : 8006f7131000 x2 : 8006fb2b5700
x1 : x0 : 0028
Process kworker/2:1 (pid: 51, stack limit = 0x(ptrval))
Call trace:
ipmmu_domain_free+0x1c/0xa0
iommu_group_release+0x48/0x68
kobject_put+0x74/0xe8
kobject_del.part.0+0x3c/0x50
kobject_put+0x60/0xe8
iommu_group_get_for_dev+0xa8/0x1f0
ipmmu_add_device+0x1c/0x40
of_iommu_configure+0x118/0x190
of_dma_configure+0xcc/0x1f0
platform_dma_configure+0x18/0x28
really_probe+0x94/0x2a8
driver_probe_device+0x58/0x100
__device_attach_driver+0x90/0xd0
bus_for_each_drv+0x64/0xc8
__device_attach+0xd8/0x130
device_initial_probe+0x10/0x18
bus_probe_device+0x98/0xa0
deferred_probe_work_func+0x74/0xb0
process_one_work+0x294/0x6f0
worker_thread+0x238/0x460
kthread+0x120/0x128
ret_from_fork+0x10/0x1c
Code: aa0003f3 97ffeb1a d1002274 f85f8261 (f9401c20)
---[ end trace 4c46c7fd7cd07245 ]---
Reproducing on v4.20-rc1 requires CONFIG_IPMMU_VMSA=y, and whitelisting
SATA for IOMMU use (https://patchwork.kernel.org/patch/10544059/).
For older versions you also have to backport commit 3a0832d093693ede ("arm64:
dts: renesas: salvator-xs: enable SATA").
Actually there are two issues at hand:
1) drivers/iommu/io-pgtable-arm.c:__arm_lpae_alloc_pages() allocates
memory (above 4 GiB) and maps it for DMA use, but it is rejected due
to:
dma_map_single(dev, pages, size, DMA_TO_DEVICE) != virt_to_phys(pages)
> --- a/include/linux/dma-direct.h
> +++ b/include/linux/dma-direct.h
> @@ -27,7 +27,8 @@ static inline bool dma_capable(struct device *dev,
> dma_addr_t addr, size_t size)
> if (!dev->dma_mask)
> return false;
>
> - return addr + size - 1 <= *dev->dma_mask;
> + return addr + size - 1 <=
> + min_not_zero(*dev->dma_mask, dev->bus_dma_mask);
*dev->dma_mask = 0xff (40-bit)
dev->bus_dma_mask = 0x (32-bit)
Hence before, we had (in __arm_lpae_alloc_pages()):
arm-lpae io-pgtable: pages = 8006f88f3000
arm-lpae io-pgtable: dma = 0x0007388f3000
arm-lpae io-pgtable: virt_to_phys(pages) = 0x0007388f3000
After this change, we have:
arm-lpae io-pgtable: pages = 8006f882b000
arm-lpae io-pgtable: dma = 0x74009000
arm-lpae io-pgtable: virt_to_phys(pages) = 0x00073882b000
And SATA runs without using the IOMMU.
2) The Renesas IPMMU driver doesn't handle the above f
[PATCH] pinctrl: sh-pfc: r8a77970: add QSPI pins, groups, and functions
From: Dmitry Shifrin
Add the QSPI{0|1} pins/groups/functions to the R8A77970 PFC driver.
[Sergei: ported to the upstream driver, fixed up the swapped QSPI0 SPCLK/
SSL pins, fixed up the comments, moved the QSPI pins/groups/functions to
be in the alphanumeric order, removed unneeded empty lines, renamed the
patch.]
Signed-off-by: Dmitry Shifrin
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'sh-pfc' branch of Geert's 'renesas-drivers.git' repo.
drivers/pinctrl/sh-pfc/pfc-r8a77970.c | 70 ++
1 file changed, 70 insertions(+)
Index: renesas-drivers/drivers/pinctrl/sh-pfc/pfc-r8a77970.c
===
--- renesas-drivers.orig/drivers/pinctrl/sh-pfc/pfc-r8a77970.c
+++ renesas-drivers/drivers/pinctrl/sh-pfc/pfc-r8a77970.c
@@ -1382,6 +1382,56 @@ static const unsigned int pwm4_b_mux[] =
PWM4_B_MARK,
};
+/* - QSPI0 --
*/
+static const unsigned int qspi0_ctrl_pins[] = {
+ /* SPCLK, SSL */
+ RCAR_GP_PIN(5, 0), RCAR_GP_PIN(5, 5),
+};
+static const unsigned int qspi0_ctrl_mux[] = {
+ QSPI0_SPCLK_MARK, QSPI0_SSL_MARK,
+};
+static const unsigned int qspi0_data2_pins[] = {
+ /* MOSI_IO0, MISO_IO1 */
+ RCAR_GP_PIN(5, 1), RCAR_GP_PIN(5, 2),
+};
+static const unsigned int qspi0_data2_mux[] = {
+ QSPI0_MOSI_IO0_MARK, QSPI0_MISO_IO1_MARK,
+};
+static const unsigned int qspi0_data4_pins[] = {
+ /* MOSI_IO0, MISO_IO1, IO2, IO3 */
+ RCAR_GP_PIN(5, 1), RCAR_GP_PIN(5, 2),
+ RCAR_GP_PIN(5, 3), RCAR_GP_PIN(5, 4),
+};
+static const unsigned int qspi0_data4_mux[] = {
+ QSPI0_MOSI_IO0_MARK, QSPI0_MISO_IO1_MARK,
+ QSPI0_IO2_MARK, QSPI0_IO3_MARK
+};
+
+/* - QSPI1 --
*/
+static const unsigned int qspi1_ctrl_pins[] = {
+ /* SPCLK, SSL */
+ RCAR_GP_PIN(5, 6), RCAR_GP_PIN(5, 11),
+};
+static const unsigned int qspi1_ctrl_mux[] = {
+ QSPI1_SPCLK_MARK, QSPI1_SSL_MARK,
+};
+static const unsigned int qspi1_data2_pins[] = {
+ /* MOSI_IO0, MISO_IO1 */
+ RCAR_GP_PIN(5, 7), RCAR_GP_PIN(5, 8),
+};
+static const unsigned int qspi1_data2_mux[] = {
+ QSPI1_MOSI_IO0_MARK, QSPI1_MISO_IO1_MARK,
+};
+static const unsigned int qspi1_data4_pins[] = {
+ /* MOSI_IO0, MISO_IO1, IO2, IO3 */
+ RCAR_GP_PIN(5, 7), RCAR_GP_PIN(5, 8),
+ RCAR_GP_PIN(5, 9), RCAR_GP_PIN(5, 10),
+};
+static const unsigned int qspi1_data4_mux[] = {
+ QSPI1_MOSI_IO0_MARK, QSPI1_MISO_IO1_MARK,
+ QSPI1_IO2_MARK, QSPI1_IO3_MARK
+};
+
/* - SCIF Clock -
*/
static const unsigned int scif_clk_a_pins[] = {
/* SCIF_CLK */
@@ -1756,6 +1806,12 @@ static const struct sh_pfc_pin_group pin
SH_PFC_PIN_GROUP(pwm3_b),
SH_PFC_PIN_GROUP(pwm4_a),
SH_PFC_PIN_GROUP(pwm4_b),
+ SH_PFC_PIN_GROUP(qspi0_ctrl),
+ SH_PFC_PIN_GROUP(qspi0_data2),
+ SH_PFC_PIN_GROUP(qspi0_data4),
+ SH_PFC_PIN_GROUP(qspi1_ctrl),
+ SH_PFC_PIN_GROUP(qspi1_data2),
+ SH_PFC_PIN_GROUP(qspi1_data4),
SH_PFC_PIN_GROUP(scif_clk_a),
SH_PFC_PIN_GROUP(scif_clk_b),
SH_PFC_PIN_GROUP(scif0_data),
@@ -1950,6 +2006,18 @@ static const char * const pwm4_groups[]
"pwm4_b",
};
+static const char * const qspi0_groups[] = {
+ "qspi0_ctrl",
+ "qspi0_data2",
+ "qspi0_data4",
+};
+
+static const char * const qspi1_groups[] = {
+ "qspi1_ctrl",
+ "qspi1_data2",
+ "qspi1_data4",
+};
+
static const char * const scif_clk_groups[] = {
"scif_clk_a",
"scif_clk_b",
@@ -2033,6 +2101,8 @@ static const struct sh_pfc_function pinm
SH_PFC_FUNCTION(pwm2),
SH_PFC_FUNCTION(pwm3),
SH_PFC_FUNCTION(pwm4),
+ SH_PFC_FUNCTION(qspi0),
+ SH_PFC_FUNCTION(qspi1),
SH_PFC_FUNCTION(scif_clk),
SH_PFC_FUNCTION(scif0),
SH_PFC_FUNCTION(scif1),
[PATCH v2] gpio: rcar: Request GPIO while enabling interrupt
There are cases when the bootloader configures a pin to work
as a function rather than GPIO, and other cases when the pin
is configured as a function at POR.
This commit makes sure the pin is configured as a GPIO the
moment we need it to work as an interrupt.
Signed-off-by: Fabrizio Castro
---
v1->v2:
* Moved gpio_rcar_request call from gpio_rcar_irq_set_type to
rcar_gpio_irq_request_resources
* Added rcar_gpio_irq_release_resources for calling gpio_rcar_free
Comments very welcome!
drivers/gpio/gpio-rcar.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
index 3c82bb3..c16598b 100644
--- a/drivers/gpio/gpio-rcar.c
+++ b/drivers/gpio/gpio-rcar.c
@@ -344,6 +344,29 @@ static int gpio_rcar_direction_output(struct gpio_chip
*chip, unsigned offset,
return 0;
}
+static int rcar_gpio_irq_request_resources(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct gpio_rcar_priv *p = gpiochip_get_data(gc);
+ unsigned int hwirq = irqd_to_hwirq(d);
+ int err;
+
+ gpio_rcar_direction_input(gc, hwirq);
+ err = gpio_rcar_request(gc, hwirq);
+ if (err)
+ dev_err(&p->pdev->dev, "Can't request GPIO %u from %s\n", hwirq,
+ gc->label);
+ return err;
+}
+
+static void rcar_gpio_irq_release_resources(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ unsigned int hwirq = irqd_to_hwirq(d);
+
+ gpio_rcar_free(gc, hwirq);
+}
+
struct gpio_rcar_info {
bool has_both_edge_trigger;
};
@@ -491,6 +514,8 @@ static int gpio_rcar_probe(struct platform_device *pdev)
irq_chip->irq_set_type = gpio_rcar_irq_set_type;
irq_chip->irq_set_wake = gpio_rcar_irq_set_wake;
irq_chip->flags = IRQCHIP_SET_TYPE_MASKED | IRQCHIP_MASK_ON_SUSPEND;
+ irq_chip->irq_request_resources = rcar_gpio_irq_request_resources;
+ irq_chip->irq_release_resources = rcar_gpio_irq_release_resources;
ret = gpiochip_add_data(gpio_chip, p);
if (ret) {
--
2.7.4
RE: [PATCH] gpio: rcar: Request GPIO while enabling interrupt
Hello Geert,
Thank you for your feedback!
> Subject: Re: [PATCH] gpio: rcar: Request GPIO while enabling interrupt
>
> Hi Fabrizio,
>
> On Fri, Nov 2, 2018 at 8:10 PM Fabrizio Castro
> wrote:
> > There are cases when the bootloader configures a pin to work
> > as a function rather than GPIO, and other cases when the pin
> > is configured as a function at POR.
> > This commit makes sure the pin is configured as a GPIO the
> > moment we need it to work as an interrupt.
> >
> > Signed-off-by: Fabrizio Castro
> > ---
> > RFC->PATCH:
> > * Moved gc->request to the bottom of gpio_rcar_irq_set_type
>
> Thanks for the update!
>
> > --- a/drivers/gpio/gpio-rcar.c
> > +++ b/drivers/gpio/gpio-rcar.c
> > @@ -147,6 +147,7 @@ static int gpio_rcar_irq_set_type(struct irq_data *d,
> > unsigned int type)
> > struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> > struct gpio_rcar_priv *p = gpiochip_get_data(gc);
> > unsigned int hwirq = irqd_to_hwirq(d);
> > + int err;
> >
> > dev_dbg(&p->pdev->dev, "sense irq = %d, type = %d\n", hwirq, type);
> >
> > @@ -176,6 +177,13 @@ static int gpio_rcar_irq_set_type(struct irq_data *d,
> > unsigned int type)
> > default:
> > return -EINVAL;
> > }
> > +
> > + err = gc->request(gc, hwirq);
>
> Call gpio_rcar_request() directly?
Will change
>
> Where should the matching gpio_rcar_free() be called?
That is the question, isn't it?! I have looked around and I couldn't find
anywhere sensible where to
call gpio_rcar_free from in such a way that would be somehow balance
gpio_rcar_request from
gpio_rcar_irq_set_type.
Thank you for suggesting irq_request_resources and irq_release_resources on
IRC, it seems appropriate
to me, and after testing it everything seems to be working fine, I'll send a
new version exploring this
option, and I'll wait for valuable comments.
>
> > + if (err) {
> > + dev_err(&p->pdev->dev, "Can't request GPIO %d from %s\n",
> > hwirq,
>
> %u for unsigned int
Well spotted, will fix
Thanks,
Fab
>
> > + gc->label);
> > + return err;
> > + }
> > return 0;
> > }
>
> 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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [RFC] gpio: rcar: Request GPIO before enabling interrupt
Hello Geert,
Thank you for your feedback!
> Subject: Re: [RFC] gpio: rcar: Request GPIO before enabling interrupt
>
> Hi Fabrizio,
>
> On Fri, Oct 26, 2018 at 9:57 PM Fabrizio Castro
> wrote:
> > There are cases when the bootloader configures a pin to work
> > as a function rather than GPIO, and other cases when the pin
> > is configured as a function at POR.
> > This commit makes sure the pin is configured as a GPIO the
> > moment we need it to work as an interrupt.
> >
> > Signed-off-by: Fabrizio Castro
> > ---
> >
> > Dear All,
> >
> > we have got some issues while trying to bring up the interrupt
> > line of the HDMI transmitter on the iwg23s, as GP2_29 is configured
> > as a function when the kernel starts, and therefore setting up the
> > interrupt from the driver won't have the desired effect.
> > This patch makes sure the pinctrl driver sets GP2[29] to GP-2-29
> > before enabling the interrupt, but it doesn't addresses the
> > "direction problem", as in the pin will be a GPIO after calling
> > gc->request, but the direction would be whatever was previously
> > configured. There could be the option of moving the additional
> > code added by this patch to the bottom of function
> > gpio_rcar_irq_set_type, but is that going to behave properly on
> > every SoC this driver is supporting?
> > Is configuring every gpio with direction input while probing
> > something that should be looked into to reduce concerns over
> > switching from function to GPIO?
>
> Configuring everything to input may cause issues where a GPIO is connected
> to the reset line of an external device, and where the bootloader configured
> the
> line to deassert the reset.
I am going to stay away from this then.
Thanks,
Fab
>
> 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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
Re: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a77470 CMT support
On Fri, 26 Oct 2018 09:36:13 +0100, Biju Das wrote: > Document SoC specific compatible strings for r8a77470. No driver change > is needed as the fallback strings will activate the right code. > > Signed-off-by: Biju Das > --- > This patch is tested against linux-next > --- > Documentation/devicetree/bindings/timer/renesas,cmt.txt | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH] dt-bindings: watchdog: renesas-wdt: Document r8a77470 support
On Fri, 26 Oct 2018 09:55:53 +0100, Biju Das wrote: > RZ/G1C (R8A77470) watchdog implementation is compatible with R-Car > Gen2, therefore add relevant documentation. > > Signed-off-by: Biju Das > --- > This patch is tested against linux-next > --- > Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring
Re: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a7796 CMT support
On Tue, Nov 06, 2018 at 09:54:52AM -0600, Rob Herring wrote: > On Fri, Oct 26, 2018 at 09:01:44AM +0100, Biju Das wrote: > > Document SoC specific bindings for R-Car M3-W (r8a7796) SoC. > > > > Signed-off-by: Biju Das > > --- > > This patch is tested against linu-next > > --- > > Documentation/devicetree/bindings/timer/renesas,cmt.txt | 2 ++ > > 1 file changed, 2 insertions(+) > > Applied. Nevermind. I see there's another timer patch. Daniel should apply. Reviewed-by: Rob Herring
Re: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a7796 CMT support
On Fri, Oct 26, 2018 at 09:01:44AM +0100, Biju Das wrote: > Document SoC specific bindings for R-Car M3-W (r8a7796) SoC. > > Signed-off-by: Biju Das > --- > This patch is tested against linu-next > --- > Documentation/devicetree/bindings/timer/renesas,cmt.txt | 2 ++ > 1 file changed, 2 insertions(+) Applied.
Re: HDMI doesn't work on ULCB board
Hi Morimoto-san, On Tuesday, 6 November 2018 16:30:35 EET Laurent Pinchart wrote: > On Thursday, 18 October 2018 05:12:14 EET Kuninori Morimoto wrote: > > Hi Vladimir, Laurent > > > > I'm testing ULCB board, and I noticed that HDMI doen't work on it. > > > > - Sometimes kernel panic happen (I lost log, but it said "get crc" > > > > something error), - Often, kernel doesn't boot with below log if I > > connected HDMI cable when booting > > > > - Monitor say "No signal" if I connected cable *after* booting > > > > I'm using Geert's renesas-drivers-2018-10-09-v4.19-rc7 branch. > > It seems salvator HDMI is working correctly on it. > > I attached my .config > > I tried to reproduce the problem, starting with drm-next which seems to work > fine, moving to renesas-drivers-2018-10-09-v4.19-rc7 which also didn't > exhibit any issue. I then used your kernel configuration, and got a WARN_ON > \o/ Investigations revealed that you're missing the CONFIG_COMMON_CLK_VC5=y option in your kernel configuration. It also revealed a bug in the error handling code of the DU driver, for which I have just sent "[PATCH] drm: rcar-du: Fix external clock error checks". -- Regards, Laurent Pinchart
Re: [PATCH v2] iommu/ipmmu-vmsa: Hook up r8a77990 DT matching code
On Wed, Oct 17, 2018 at 11:13:22AM +0200, Simon Horman wrote: > From: Hai Nguyen Pham > > Support the R-Car E3 (r8a77990) IPMMU. > > Signed-off-by: Hai Nguyen Pham > Signed-off-by: Kazuya Mizuguchi > [simon: rebased; dropped no longer required IOMMU_OF_DECLARE hunk] > Signed-off-by: Simon Horman Applied, thanks.
[PATCH] drm: rcar-du: Fix external clock error checks
The rcar-du driver supports probe deferral for external clocks, but
implements it badly by checking the wrong pointer due to a bad copy and
paste. Fix it.
While at it, reject invalid clocks outright for DU channels that have a
display PLL, as the external clock is mandatory in that case. This
avoids a WARN_ON() at runtime.
Fixes: 1b30dbde8596 ("drm: rcar-du: Add support for external pixel clock")
Reported-by: Kuninori Morimoto
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index d18a342626b5..79021d7aa3ce 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -226,9 +226,6 @@ static void rcar_du_crtc_set_display_timing(struct
rcar_du_crtc *rcrtc)
* system clock, and have no internal clock divider.
*/
- if (WARN_ON(!rcrtc->extclock))
- return;
-
/*
* The H3 ES1.x exhibits dot clock duty cycle stability issues.
* We can work around them by configuring the DPLL to twice the
@@ -1113,9 +1110,16 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
unsigned int swindex,
clk = devm_clk_get(rcdu->dev, clk_name);
if (!IS_ERR(clk)) {
rcrtc->extclock = clk;
- } else if (PTR_ERR(rcrtc->clock) == -EPROBE_DEFER) {
- dev_info(rcdu->dev, "can't get external clock %u\n", hwindex);
+ } else if (PTR_ERR(clk) == -EPROBE_DEFER) {
return -EPROBE_DEFER;
+ } else if (rcdu->info->dpll_mask & BIT(hwindex)) {
+ /*
+* DU channels that have a display PLL can't use the internal
+* system clock and thus require an external clock.
+*/
+ ret = PTR_ERR(clk);
+ dev_err(rcdu->dev, "can't get dclkin.%u: %d\n", hwindex, ret);
+ return ret;
}
init_waitqueue_head(&rcrtc->flip_wait);
--
Regards,
Laurent Pinchart
Re: HDMI doesn't work on ULCB board
Hi Morimoto-san, On Thursday, 18 October 2018 05:12:14 EET Kuninori Morimoto wrote: > Hi Vladimir, Laurent > > I'm testing ULCB board, and I noticed that HDMI doen't work on it. > > - Sometimes kernel panic happen (I lost log, but it said "get crc" > something error), - Often, kernel doesn't boot with below log if I > connected HDMI cable when booting > - Monitor say "No signal" if I connected cable *after* booting > > I'm using Geert's renesas-drivers-2018-10-09-v4.19-rc7 branch. > It seems salvator HDMI is working correctly on it. > I attached my .config I tried to reproduce the problem, starting with drm-next which seems to work fine, moving to renesas-drivers-2018-10-09-v4.19-rc7 which also didn't exhibit any issue. I then used your kernel configuration, and got a WARN_ON \o/ [1.805110] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [1.811758] [drm] No driver support for vblank timestamp query. [1.878688] WARNING: CPU: 1 PID: 62 at /home/laurent/src/iob/renesas/linux/ drivers/gpu/drm/rcar-du/rcar_du_crtc.c:229 rcar_du_crtc_get+0x604/0x628 [1.878712] CPU: 1 PID: 62 Comm: kworker/1:1 Not tainted 4.19.0-rc7 #2820 [1.878716] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT) [1.878725] Workqueue: events deferred_probe_work_func [1.878734] pstate: 0005 (nzcv daif -PAN -UAO) [1.878739] pc : rcar_du_crtc_get+0x604/0x628 [1.878743] lr : rcar_du_crtc_get+0xa8/0x628 [1.878747] sp : 0a12b330 [1.878750] x29: 0a12b330 x28: [1.878759] x27: 0004 x26: 8006f90fc000 [1.878768] x25: 8006f9de3ad8 x24: 0001 [1.878776] x23: 0001 x22: 06590fa0 [1.878784] x21: 8006f9026818 x20: 08a6e000 [1.878792] x19: 8006f9610770 x18: 1ef4 [1.878799] x17: x16: 8006faee5900 [1.878807] x15: 1eeb x14: 096a9000 [1.878815] x13: 1ef6 x12: 1eeb [1.878823] x11: 8006faee60e0 x10: 08ab5000 [1.878831] x9 : 098ad000 x8 : 8006faee5900 [1.878839] x7 : 08b1a000 x6 : 08b1a308 [1.878847] x5 : 0002 x4 : 0006 [1.878855] x3 : 087d7670 x2 : 8006f9610018 [1.878862] x1 : x0 : 8006f9611cf0 [1.878871] Call trace: [1.878876] rcar_du_crtc_get+0x604/0x628 [1.878880] rcar_du_crtc_atomic_begin+0x2c/0x60 [1.878890] drm_atomic_helper_commit_planes+0x84/0x218 [1.878895] rcar_du_atomic_commit_tail+0x38/0x70 [1.878900] commit_tail+0x4c/0x80 [1.878904] drm_atomic_helper_commit+0xfc/0x178 [1.878911] drm_atomic_commit+0x54/0x60 [1.878918] restore_fbdev_mode_atomic+0x180/0x1f0 [1.878922] restore_fbdev_mode+0x58/0x198 [1.878927] drm_fb_helper_restore_fbdev_mode_unlocked+0x80/0xd8 [1.878932] drm_fb_helper_set_par+0x34/0x68 [1.878939] fbcon_init+0x504/0x558 [1.878945] visual_init+0xa0/0xf0 [1.878950] do_bind_con_driver+0x160/0x338 [1.878955] do_take_over_console+0x128/0x1a8 [1.878959] do_fbcon_takeover+0x80/0x108 [1.878964] fbcon_event_notify+0x9ac/0x9d8 [1.878971] notifier_call_chain+0x5c/0x98 [1.878975] __blocking_notifier_call_chain+0x58/0xa0 [1.878979] blocking_notifier_call_chain+0x3c/0x50 [1.878983] fb_notifier_call_chain+0x30/0x40 [1.878987] register_framebuffer+0x288/0x330 [1.878992] __drm_fb_helper_initial_config_and_unlock+0x24c/0x410 [1.878996] drm_fb_helper_fbdev_setup+0xf0/0x210 [1.879000] drm_fbdev_cma_init+0xa4/0xf0 [1.879005] rcar_du_modeset_init+0x3b4/0x570 [1.879009] rcar_du_probe+0x134/0x210 [1.879016] platform_drv_probe+0x58/0xb8 [1.879020] really_probe+0x20c/0x2a0 [1.879024] driver_probe_device+0x60/0x108 [1.879028] __device_attach_driver+0x9c/0xe0 [1.879031] bus_for_each_drv+0x80/0xe0 [1.879035] __device_attach+0xf0/0x150 [1.879039] device_initial_probe+0x24/0x30 [1.879042] bus_probe_device+0xa0/0xa8 [1.879046] deferred_probe_work_func+0x78/0xb0 [1.879052] process_one_work+0x2c4/0x6c0 [1.879055] worker_thread+0x244/0x438 [1.879060] kthread+0x100/0x130 [1.879067] ret_from_fork+0x10/0x1c [1.879070] irq event stamp: 42150 [1.879080] hardirqs last enabled at (42149): [] _raw_spin_unlock_irqrestore+0x7c/0x88 [1.879086] hardirqs last disabled at (42150): [] do_debug_exception+0x17c/0x1b8 [1.879090] softirqs last enabled at (41936): [] __do_softirq+0x46c/0x51c [1.879097] softirqs last disabled at (41915): [] irq_exit+0x12c/0x138 [1.879100] ---[ end trace ec07bda5b9bd7ef1 ]--- I'm now investigating it. -- Regards, Laurent Pinchart
Re: [PATCH/RFT] arm64: dts: renesas: r8a77990-ebisu: Add serial console pins
On Sun, Oct 21, 2018 at 06:31:28AM +0900, Yoshihiro Kaneko wrote: > From: Takeshi Kihara > > This patch adds pin control for SCIF2. > > Signed-off-by: Takeshi Kihara > Signed-off-by: Yoshihiro Kaneko > --- > > This patch is based on the devel branch of Simon Horman's renesas tree. Hi Kaneko-san, It seems that Marek also, subsequently, posted an upport of this patch. I have arbitrarily taken his version (which is the same).
Re: [PATCH 1/4] spi: rspi: Add r8a77470 to the compatible list
On Thu, Nov 01, 2018 at 12:35:02PM +, Fabrizio Castro wrote: > Add r8a77470 to the list of examples with soctypes. > No driver change is needed as "renesas,qspi" will activate > the right code within the corresponding driver. > > Signed-off-by: Fabrizio Castro Reviewed-by: Simon Horman > > --- > > As per Mark Brown's comment on patch "dt-bindings: spi: rspi: Add > r8a7744 to the compatible list", this patch doesn't come with the > "dt-bindings" prefix in the title. > > Documentation/devicetree/bindings/spi/spi-rspi.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/spi/spi-rspi.txt > b/Documentation/devicetree/bindings/spi/spi-rspi.txt > index fc97ad6..421722b 100644 > --- a/Documentation/devicetree/bindings/spi/spi-rspi.txt > +++ b/Documentation/devicetree/bindings/spi/spi-rspi.txt > @@ -15,6 +15,7 @@ Required properties: > - "renesas,qspi-r8a7743" (RZ/G1M) > - "renesas,qspi-r8a7744" (RZ/G1N) > - "renesas,qspi-r8a7745" (RZ/G1E) > + - "renesas,qspi-r8a77470" (RZ/G1C) > - "renesas,qspi-r8a7790" (R-Car H2) > - "renesas,qspi-r8a7791" (R-Car M2-W) > - "renesas,qspi-r8a7792" (R-Car V2H) > -- > 2.7.4 >
Re: [PATCH v2 6/8] arm64: dts: r8a77990: Add VIN and CSI-2 device nodes
On Mon, Nov 05, 2018 at 11:32:37AM +0100, jacopo mondi wrote:
> Hi Simon,
>
> On Wed, Oct 31, 2018 at 03:37:39PM +0100, Simon Horman wrote:
> > On Wed, Oct 31, 2018 at 02:18:40PM +0100, jacopo mondi wrote:
> > > Hi Simon,
> > >
> > > On Wed, Oct 31, 2018 at 01:48:13PM +0100, Simon Horman wrote:
> > > > On Tue, Oct 30, 2018 at 02:57:59PM +0200, Laurent Pinchart wrote:
> > > > > Hi Jacopo,
> > > > >
> > > > > On Tuesday, 30 October 2018 12:14:31 EET jacopo mondi wrote:
> > > > > > On Mon, Sep 10, 2018 at 05:12:30PM +0300, Laurent Pinchart wrote:
> > > > > > > On Wednesday, 5 September 2018 18:29:43 EEST Jacopo Mondi wrote:
> > > > > > >> From: Koji Matsuoka
> > > > > > >>
> > > > > > >> Add device nodes for VIN4, VIN5 and CSI40 to R-Car E3 R8A77990
> > > > > > >> device
> > > > > > >> tree.
> > > > > > >>
> > > > > > >> Signed-off-by: Koji Matsuoka
> > > > > > >> Signed-off-by: Takeshi Kihara
> > > > > > >> Signed-off-by: Jacopo Mondi
> > > > > > >> ---
> > > > > > >>
> > > > > > >> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 79
> > > > > > >>
> > > > > > >> 1 file changed, 79 insertions(+)
> > > > > > >>
> > > > > > >> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > > > >> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index
> > > > > > >> ae89260..0ae7bbe
> > > > > > >> 100644
> > > > > > >> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > > > >> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > > > >> @@ -337,6 +337,85 @@
> > > > > > >>
> > > > > > >> status = "disabled";
> > > > > > >>
> > > > > > >> };
> > > > > > >>
> > > > > > >> +csi40: csi2@feaa {
> > > > > > >
> > > > > > > I believe Simon would like to keep the nodes sorted by address
> > > > > > >
> > > > > > >> +compatible = "renesas,r8a77990-csi2",
> > > > > > >> "renesas,rcar-gen3-csi2";
> > > > > > >> +reg = <0 0xfeaa 0 0x1>;
> > > > > > >
> > > > > > > 0x1 seems pretty large to me.
> > > > > >
> > > > > > It seems to me that all Gen3 SoC have this lenght specified
> > > > > >
> > > > > > $git grep -A 10 'csi[2|4][0|1]: csi' arch/arm64/boot/dts/renesas/ |
> > > > > > grep reg
> > > > > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfea8 0
> > > > > > 0x1>;
> > > > > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeaa 0
> > > > > > 0x1>;
> > > > > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeab 0
> > > > > > 0x1>;
> > > > > > arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfea8 0
> > > > > > 0x1>;
> > > > > > arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfeaa 0
> > > > > > 0x1>;
> > > > > > arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfea8 0
> > > > > > 0x1>;
> > > > > > arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfeaa 0
> > > > > > 0x1>;
> > > > > > arch/arm64/boot/dts/renesas/r8a77970.dtsi- reg = <0 0xfeaa 0
> > > > > > 0x1>;
> > > > > > arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeaa 0
> > > > > > 0x1>;
> > > > > > arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeab 0
> > > > > > 0x1>;
> > > > > > arch/arm64/boot/dts/renesas/r8a77990.dtsi- reg = <0 0xfeaa 0
> > > > > > 0x1>;
> > > > > >
> > > > > > Am I missing something?
> > > > >
> > > > > Cargo-cult programming ? :-) This will likely not hurt, but such a
> > > > > large
> > > > > memory area is not required, and we'll save a bit of memory if we
> > > > > reduce the
> > > > > mapping from 64kB to 4kB (or less)
> > > >
> > > > Can we please update this patch, and existing dtsi files,
> > > > to use an appropriately small register window?
> > > >
> > >
> > > What if we keep this one as it is and we change all the DTSIs in one
> > > go?
> >
> > I would rather we correct this patch than add it with a known problem.
>
> Sorry, I was confused. This patch is already in v4.20.
>
> If we want to fix this, a single follow-up patch that changes the
> memory area size for all SoCs is required.
Thanks, I was also confused.
Your proposal sounds good to me.
Re: [PATCH v2] arm64: dts: renesas: r8a77990: Fix VIN endpoint numbering
On Mon, Nov 05, 2018 at 02:12:43PM +0100, Jacopo Mondi wrote:
> The VIN driver bindings dictates fixed numbering for VIN endpoints connected
> to CSI-2 endpoints, even when a single endpoint exists.
>
> Without proper endpoint numbering the VIN driver fails to probe.
>
> Based on a patch in BSP from Koji Matsuoka
>
> Fixes: ec70407ae7d7 ("arm64: dts: renesas: r8a77990: Add VIN and CSI-2 device
> nodes")
> Signed-off-by: Koji Matsuoka
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Laurent Pinchart
Thanks,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Reviewed-by: Simon Horman
Re: [PATCH v4 5/6] media: rcar: rcar-csi2: Update V3M/E3 PHTW tables
Hi Jacopo,
Thank you for the patch.
On Tuesday, 6 November 2018 12:54:26 EET Jacopo Mondi wrote:
> Update PHTW tables for V3M and E3 SoCs to the latest datasheet release
> (R-Car Series, 3rd Generation manual rev1.00 20181017).
>
> Signed-off-by: Jacopo Mondi
>
> ---
> v1 -> v2:
> - Limit the PHTW table to 1125 MBps, according to Laurent's comment
Based on the assumption that the values haven't changed between v1 and v2,
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/rcar-vin/rcar-csi2.c | 62 --
> 1 file changed, 31 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
> b/drivers/media/platform/rcar-vin/rcar-csi2.c index 695686b..99f5b76 100644
> --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -152,37 +152,37 @@ static const struct rcsi2_mbps_reg
> phtw_mbps_h3_v3h_m3n[] = { };
>
> static const struct rcsi2_mbps_reg phtw_mbps_v3m_e3[] = {
> - { .mbps = 80, .reg = 0x00 },
> - { .mbps = 90, .reg = 0x20 },
> - { .mbps = 100, .reg = 0x40 },
> - { .mbps = 110, .reg = 0x02 },
> - { .mbps = 130, .reg = 0x22 },
> - { .mbps = 140, .reg = 0x42 },
> - { .mbps = 150, .reg = 0x04 },
> - { .mbps = 170, .reg = 0x24 },
> - { .mbps = 180, .reg = 0x44 },
> - { .mbps = 200, .reg = 0x06 },
> - { .mbps = 220, .reg = 0x26 },
> - { .mbps = 240, .reg = 0x46 },
> - { .mbps = 250, .reg = 0x08 },
> - { .mbps = 270, .reg = 0x28 },
> - { .mbps = 300, .reg = 0x0a },
> - { .mbps = 330, .reg = 0x2a },
> - { .mbps = 360, .reg = 0x4a },
> - { .mbps = 400, .reg = 0x0c },
> - { .mbps = 450, .reg = 0x2c },
> - { .mbps = 500, .reg = 0x0e },
> - { .mbps = 550, .reg = 0x2e },
> - { .mbps = 600, .reg = 0x10 },
> - { .mbps = 650, .reg = 0x30 },
> - { .mbps = 700, .reg = 0x12 },
> - { .mbps = 750, .reg = 0x32 },
> - { .mbps = 800, .reg = 0x52 },
> - { .mbps = 850, .reg = 0x72 },
> - { .mbps = 900, .reg = 0x14 },
> - { .mbps = 950, .reg = 0x34 },
> - { .mbps = 1000, .reg = 0x54 },
> - { .mbps = 1050, .reg = 0x74 },
> + { .mbps = 89, .reg = 0x00 },
> + { .mbps = 99, .reg = 0x20 },
> + { .mbps = 109, .reg = 0x40 },
> + { .mbps = 129, .reg = 0x02 },
> + { .mbps = 139, .reg = 0x22 },
> + { .mbps = 149, .reg = 0x42 },
> + { .mbps = 169, .reg = 0x04 },
> + { .mbps = 179, .reg = 0x24 },
> + { .mbps = 199, .reg = 0x44 },
> + { .mbps = 219, .reg = 0x06 },
> + { .mbps = 239, .reg = 0x26 },
> + { .mbps = 249, .reg = 0x46 },
> + { .mbps = 269, .reg = 0x08 },
> + { .mbps = 299, .reg = 0x28 },
> + { .mbps = 329, .reg = 0x0a },
> + { .mbps = 359, .reg = 0x2a },
> + { .mbps = 399, .reg = 0x4a },
> + { .mbps = 449, .reg = 0x0c },
> + { .mbps = 499, .reg = 0x2c },
> + { .mbps = 549, .reg = 0x0e },
> + { .mbps = 599, .reg = 0x2e },
> + { .mbps = 649, .reg = 0x10 },
> + { .mbps = 699, .reg = 0x30 },
> + { .mbps = 749, .reg = 0x12 },
> + { .mbps = 799, .reg = 0x32 },
> + { .mbps = 849, .reg = 0x52 },
> + { .mbps = 899, .reg = 0x72 },
> + { .mbps = 949, .reg = 0x14 },
> + { .mbps = 999, .reg = 0x34 },
> + { .mbps = 1049, .reg = 0x54 },
> + { .mbps = 1099, .reg = 0x74 },
> { .mbps = 1125, .reg = 0x16 },
> { /* sentinel */ },
> };
--
Regards,
Laurent Pinchart
RE: [PATCH v2 2/2] irqchip: Add support for Renesas RZ/N1 GPIO interrupt multiplexer
Hi Marc, On 31 October 2018 15:39, Phil Edworthy wrote > On 31 October 2018 15:31, Marc Zyngier wrote: > > On 31/10/18 15:09, Phil Edworthy wrote: > > > On 31 October 2018 08:02, Marc Zyngier wote: > > >> On Tue, 30 Oct 2018 10:44:38 +, Phil Edworthy wrote: > > >>> > > >>> On RZ/N1 devices, there are 3 Synopsys DesignWare GPIO blocks each > > >>> configured to have 32 interrupt outputs, so we have a total of 96 > > >>> GPIO interrupts. All of these are passed to the GPIO IRQ Muxer, > > >>> which selects > > >>> 8 of the GPIO interrupts to pass onto the GIC. The interrupt > > >>> signals aren't latched, so there is nothing to do in this driver > > >>> when an interrupt is received, other than tell the corresponding GPIO > block. > > There are two cases: > > 1) there is 1:1 mapping between a used input and an output, leaving > > some input unused > > 2) there is an n:1 mapping between input and output, and all the input > > can be used at any given time > > > > If what you have is (1), you need to implement an hierarchy. > > If what you have is (2), you need to implement a chained controller. > > > > (1) requires you to revisit this driver, making it a lot more like > > ti's irq-crossbar > > (2) requires you to actually do some decoding in the chained handler > > > > I believe you're in configuration (1). Am I right? > Right, it's a 1:1 mapping. The information about which input to be used needs > to be specified in dt. > I didn’t think I could implement a hierarchy that didn’t mask the interrupts, > so I need to go back over that and look again... Ok, I have changed the driver to implement a hierarchy, i.e. call irq_domain_create_hierarchy() in probe, call irq_domain_set_hwirq_and_chip() and irq_domain_alloc_irqs_parent() in the irq_domain_ops.alloc function. I've got a couple of issues that I hope you can provide some input on. First is what to do with irqs that are input to this mux but not selected. If I don't call irq_domain_set_hwirq_and_chip() and irq_domain_alloc_irqs_parent(), it causes the driver for the hardware that generates these interrupts (in this case, Synopsys dwapb_gpio) to throw an exception in irq_set_chained_handler_and_data(). As a hack, I have simply used an unused output irq. Second is specifying the output irqs. Currently, I specify them like this: interrupts = , , ... ; However, I am only reading the property so I can pass the fwspec to irq_domain_alloc_irqs_parent(). I am not using anything that ends up in of_irq_parse_raw(). Rob H has previously said that I should use interrupt-map to describe the relationship between the input and output irqs. Unfortunately, irq hierarchy seems to be somewhat at odds with using interrupt-map. Or at least, I can’t see how the two can be combined. Your feedback on this is greatly appreciated! Thanks Phil
renesas-drivers-2018-11-06-v4.20-rc1
I have pushed renesas-drivers-2018-11-06-v4.20-rc1 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git
This tree is meant to ease development of platform support and drivers
for Renesas ARM SoCs. It is created by merging (a) the for-next branches
of various subsystem trees and (b) branches with driver code submitted
or planned for submission to maintainers into the development branch of
Simon Horman's renesas.git tree.
Today's version is based on renesas-devel-20181105-v4.20-rc1.
Included branches with driver code:
- clk-renesas
- sh-pfc
- topic/pinctrl-rza2-v2
- git://linuxtv.org/pinchartl/media.git#drm-du-iommu-v1-20171115
- git://git.ragnatech.se/linux#for-renesas-drivers
-
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#gmsl/for-renesas-drivers
Included fixes:
- serial: sh-sci: Fix receive on SCIFA/SCIFB variants with DMA
- [LOCAL] arm64: defconfig: Update renesas_defconfig
Included subsystem trees:
- git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git#linux-next
- git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git#clk-next
-
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git#for-next
- git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git#tty-next
- git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#i2c/for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-next
- git://git.freedesktop.org/git/drm/drm.git#drm-next
- git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
- git://linuxtv.org/media_tree.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git#next
-
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next
- git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next
- git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#testing/next
- git://git.infradead.org/users/vkoul/slave-dma.git#next
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git#staging-next
- git://git.armlinux.org.uk/~rmk/linux-arm.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git#for-next
- git://git.infradead.org/users/jcooper/linux.git#irqchip/for-next
- git://github.com/bzolnier/linux.git#fbdev-for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
-
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git#for-next
- git://www.linux-watchdog.org/linux-watchdog-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git#for-next/core
- git://anongit.freedesktop.org/drm/drm-misc#for-linux-next
- git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
- git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git#next
-
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git#next
- git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git#for-mfd-next
- git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git#for-next
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] arm64: dts: r8a77990: ebisu: Add serial console pins
On Tue, Nov 06, 2018 at 05:22:35AM +, Yoshihiro Shimoda wrote: > Hello Marek-san, > > > From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:39 AM > > > > From: Takeshi Kihara > > > > This patch adds pin control for SCIF2 on R8A77990 E3 Ebisu. > > > > Signed-off-by: Takeshi Kihara > > Signed-off-by: Marek Vasut > > Cc: Geert Uytterhoeven > > Cc: Simon Horman > > Cc: Wolfram Sang > > Cc: Yoshihiro Shimoda > > Cc: linux-renesas-soc@vger.kernel.org > > Cc: linux-arm-ker...@lists.infradead.org > > --- > > Thank you for the patch! > > Reviewed-by: Yoshihiro Shimoda Thanks, applied for v4.21.
Re: [PATCH 1/2] ARM: dts: r8a77470: Add watchdog support to SoC dtsi
On Tue, Nov 06, 2018 at 11:18:14AM +0100, Geert Uytterhoeven wrote:
> Hi Biju,
>
> On Fri, Oct 26, 2018 at 11:40 AM Biju Das wrote:
> > This patch adds watchdog support to the r8a77470 SoC dtsi.
> >
> > Signed-off-by: Biju Das
>
> Thanks for your patch!
>
> > --- a/arch/arm/boot/dts/r8a77470.dtsi
> > +++ b/arch/arm/boot/dts/r8a77470.dtsi
> > @@ -196,6 +196,16 @@
> > reg = <0 0xe616 0 0x100>;
> > };
> >
> > + rwdt: watchdog@e602 {
>
> Please follow the sort order rules:
> - By unit-address (if present), per group,
> - Alphabetically.
Thanks for noticing.
As I had already applied this patch I took the liberty of updating
it to preserve node sort order. The updates patch is as follows:
From: Biju Das
Date: Fri, 26 Oct 2018 10:32:26 +0100
Subject: [PATCH] ARM: dts: r8a77470: Add watchdog support to SoC dtsi
This patch adds watchdog support to the r8a77470 SoC dtsi.
Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
[simon: moved node to preserve sort order]
Signed-off-by: Simon Horman
---
arch/arm/boot/dts/r8a77470.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index 6ac7f467065e..a703b74cc1f9 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -79,6 +79,16 @@
#size-cells = <2>;
ranges;
+ rwdt: watchdog@e602 {
+ compatible = "renesas,r8a77470-wdt",
+"renesas,rcar-gen2-wdt";
+ reg = <0 0xe602 0 0x0c>;
+ clocks = <&cpg CPG_MOD 402>;
+ power-domains = <&sysc R8A77470_PD_ALWAYS_ON>;
+ resets = <&cpg 402>;
+ status = "disabled";
+ };
+
gpio0: gpio@e605 {
compatible = "renesas,gpio-r8a77470",
"renesas,rcar-gen2-gpio";
--
2.11.0
Re: [PATCH 1/2] arm64: dts: r8a77990: Add SDHI device nodes
On Tue, Nov 06, 2018 at 11:35:13AM +0100, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Tue, Nov 6, 2018 at 11:32 AM Marek Vasut wrote:
> > On 11/06/2018 06:26 AM, Yoshihiro Shimoda wrote:
> > >> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:41 AM
> > >>
> > >> From: Takeshi Kihara
> > >>
> > >> This patch adds SDHI{0,1,3} device nodes for the r8a77990 SoC.
> > >>
> > >> Signed-off-by: Takeshi Kihara
> > >> Signed-off-by: Marek Vasut
> > >> Cc: Geert Uytterhoeven
> > >> Cc: Simon Horman
> > >> Cc: Wolfram Sang
> > >> Cc: Yoshihiro Shimoda
> > >> Cc: linux-renesas-soc@vger.kernel.org
> > >> Cc: linux-arm-ker...@lists.infradead.org
> > >> ---
> > >
> > > Thank you for the patch!
> > >
> > > Reviewed-by: Yoshihiro Shimoda
> > >
> > > I guess this patch and the 2/2 patch for ebisu have to be merged into a
> > > patch though.
> >
> > I wonder about that, 1/2 is adding SDHI DT nodes for an SoC, 2/2 is
> > enabling SDHI on a particular board, which I think should be separate.
>
> The arm-soc maintainers tend to disagree, that's why Shimoda-san asked
> to combine them.
That is also my understanding.
Please consider combining these patches.
Re: [PATCH V2] arm64: dts: renesas: Switch eMMC bus to 1V8 on Salvator-X and ULCB
On Tue, Nov 06, 2018 at 11:57:17AM +0100, Wolfram Sang wrote: > On Sun, Nov 04, 2018 at 09:37:07PM +0100, Marek Vasut wrote: > > The eMMC card has two supplies, VCC and VCCQ. The VCC supplies the NAND > > array and the VCCQ supplies the bus. On Salvator-X and ULCB, the VCC is > > connected to 3.3V rail, while the VCCQ is connected to 1.8V rail. Adjust > > the pinmux to match the bus, which is always operating in 1.8V mode. > > > > While at it, deduplicate the pinmux entries, which are now the same for > > both default and UHS modes. We still need the two pinctrl entries to > > match the bindings though. > > > > Signed-off-by: Marek Vasut > > Cc: Geert Uytterhoeven > > Cc: Simon Horman > > Cc: Wolfram Sang > > Cc: Yoshihiro Shimoda > > Cc: linux-renesas-soc@vger.kernel.org > > Cc: linux-...@vger.kernel.org > > Tested on M3-N and H3 ES2.0 with HS400 enabled eMMC: > > Reviewed-by: Wolfram Sang > Tested-by: Wolfram Sang Thanks, applied for v4.21.
[PATCH v3] drm/bridge/sii902x: Fix EDID readback
While adding SiI9022A support to the iwg23s board, it came
up that when the HDMI transmitter is in pass through mode the
device is not compliant with the I2C specification anymore,
as it requires a far bigger tbuf, due to a delay the HDMI
transmitter is adding when relaying the STOP condition on the
monitor i2c side of things.
When not providing an appropriate delay after the STOP condition
the i2c bus would get stuck. Also, any other traffic on the bus
while talking to the monitor may cause the transaction to fail
or even cause issues with the i2c bus as well.
I2c-gates seemed to reach consent as a possible way to address
these issues, and as such this patch is implementing a solution
based on that. Since others are clearly relying on the current
implementation of the driver, this patch won't require any DT
changes.
Since we don't want any interference during the DDC Bus
Request/Grant procedure and while talking to the monitor, we
have to use the adapter locking primitives rather than the
i2c-mux locking primitives.
Signed-off-by: Fabrizio Castro
---
v2->v3:
* Incorporated comments from Boris Brezillon and Peter Rosin
v1->v2:
* Incorporated comments from Peter Rosin
drivers/gpu/drm/bridge/sii902x.c | 247 ---
1 file changed, 178 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index e59a135..bfa9020 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -1,4 +1,6 @@
/*
+ * Copyright (C) 2018 Renesas Electronics
+ *
* Copyright (C) 2016 Atmel
* Bo Shen
*
@@ -21,6 +23,7 @@
*/
#include
+#include
#include
#include
#include
@@ -86,8 +89,49 @@ struct sii902x {
struct drm_bridge bridge;
struct drm_connector connector;
struct gpio_desc *reset_gpio;
+ struct i2c_mux_core *i2cmux;
};
+static int sii902x_read_unlocked(struct i2c_client *i2c, u8 reg, u8 *val)
+{
+ union i2c_smbus_data data;
+ int ret;
+
+ ret = __i2c_smbus_xfer(i2c->adapter, i2c->addr, i2c->flags,
+ I2C_SMBUS_READ, reg, I2C_SMBUS_BYTE_DATA, &data);
+
+ if (ret < 0)
+ return ret;
+
+ *val = data.byte;
+ return 0;
+}
+
+static int sii902x_write_unlocked(struct i2c_client *i2c, u8 reg, u8 val)
+{
+ union i2c_smbus_data data;
+
+ data.byte = val;
+
+ return __i2c_smbus_xfer(i2c->adapter, i2c->addr, i2c->flags,
+ I2C_SMBUS_WRITE, reg, I2C_SMBUS_BYTE_DATA,
+ &data);
+}
+
+static int sii902x_update_bits_unlocked(struct i2c_client *i2c, u8 reg, u8
mask,
+ u8 val)
+{
+ int ret;
+ u8 status;
+
+ ret = sii902x_read_unlocked(i2c, reg, &status);
+ if (ret)
+ return ret;
+ status &= ~mask;
+ status |= val & mask;
+ return sii902x_write_unlocked(i2c, reg, status);
+}
+
static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
{
return container_of(bridge, struct sii902x, bridge);
@@ -135,41 +179,11 @@ static const struct drm_connector_funcs
sii902x_connector_funcs = {
static int sii902x_get_modes(struct drm_connector *connector)
{
struct sii902x *sii902x = connector_to_sii902x(connector);
- struct regmap *regmap = sii902x->regmap;
u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
- struct device *dev = &sii902x->i2c->dev;
- unsigned long timeout;
- unsigned int retries;
- unsigned int status;
struct edid *edid;
- int num = 0;
- int ret;
-
- ret = regmap_update_bits(regmap, SII902X_SYS_CTRL_DATA,
-SII902X_SYS_CTRL_DDC_BUS_REQ,
-SII902X_SYS_CTRL_DDC_BUS_REQ);
- if (ret)
- return ret;
-
- timeout = jiffies +
- msecs_to_jiffies(SII902X_I2C_BUS_ACQUISITION_TIMEOUT_MS);
- do {
- ret = regmap_read(regmap, SII902X_SYS_CTRL_DATA, &status);
- if (ret)
- return ret;
- } while (!(status & SII902X_SYS_CTRL_DDC_BUS_GRTD) &&
-time_before(jiffies, timeout));
+ int num = 0, ret;
- if (!(status & SII902X_SYS_CTRL_DDC_BUS_GRTD)) {
- dev_err(dev, "failed to acquire the i2c bus\n");
- return -ETIMEDOUT;
- }
-
- ret = regmap_write(regmap, SII902X_SYS_CTRL_DATA, status);
- if (ret)
- return ret;
-
- edid = drm_get_edid(connector, sii902x->i2c->adapter);
+ edid = drm_get_edid(connector, sii902x->i2cmux->adapter[0]);
drm_connector_update_edid_property(connector, edid);
if (edid) {
num = drm_add_edid_modes(connector, edid);
@@ -181,42 +195,6 @@ static int sii902x_get_modes(struct drm_connector
*connector)
if (ret)
retu
Re: [PATCH 1/2] pinctrl: sh-pfc: r8a77990: Add SDHI pins, groups and functions
On 11/06/2018 12:14 PM, Wolfram Sang wrote:
>
>> static const struct {
>> -struct sh_pfc_pin_group common[123];
>> +struct sh_pfc_pin_group common[140];
>> struct sh_pfc_pin_group automotive[0];
>> } pinmux_groups = {
>
> ...
>
>> static const struct {
>> -struct sh_pfc_function common[29];
>> +struct sh_pfc_function common[32];
>> struct sh_pfc_function automotive[0];
>> } pinmux_functions = {
>
>
> It is Geert's call, but maybe those are a seperate patch?
These must be part of this patch, since adding
+ SH_PFC_PIN_GROUP(sdhi0_data1),
entries grows the size of the array. If you were to split this patch,
the PFC driver would break, as the size of the array won't match the
size of the content.
--
Best regards,
Marek Vasut
Re: [PATCH 2/2] pinctrl: sh-pfc: r8a77990: Add voltage switch operations for SDHI
On 11/06/2018 12:15 PM, Wolfram Sang wrote:
> On Mon, Nov 05, 2018 at 10:40:12PM +0100, Marek Vasut wrote:
>> From: Takeshi Kihara
>>
>> This patch supports the {get,set}_io_voltage operations of SDHI.
>>
>> This operates the IOCTRL30 register on the R8A77990 SoC and makes
>> 1.8V/3.3V signal voltage switch possible.
>>
>> Signed-off-by: Takeshi Kihara
>> Signed-off-by: Marek Vasut
>> Cc: Geert Uytterhoeven
>> Cc: Simon Horman
>> Cc: Wolfram Sang
>> Cc: Yoshihiro Shimoda
>> Cc: linux-renesas-soc@vger.kernel.org
>
> Looks good from a high-level point of view. Didn't check the actual
> values. I trust Shimoda-san and Geert for that:
>
> Acked-by: Wolfram Sang
>
I also checked them in U-Boot :)
--
Best regards,
Marek Vasut
Re: [PATCH 2/2] pinctrl: sh-pfc: r8a77990: Add voltage switch operations for SDHI
On Mon, Nov 05, 2018 at 10:40:12PM +0100, Marek Vasut wrote:
> From: Takeshi Kihara
>
> This patch supports the {get,set}_io_voltage operations of SDHI.
>
> This operates the IOCTRL30 register on the R8A77990 SoC and makes
> 1.8V/3.3V signal voltage switch possible.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Simon Horman
> Cc: Wolfram Sang
> Cc: Yoshihiro Shimoda
> Cc: linux-renesas-soc@vger.kernel.org
Looks good from a high-level point of view. Didn't check the actual
values. I trust Shimoda-san and Geert for that:
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
Re: [PATCH 1/2] pinctrl: sh-pfc: r8a77990: Add SDHI pins, groups and functions
> static const struct {
> - struct sh_pfc_pin_group common[123];
> + struct sh_pfc_pin_group common[140];
> struct sh_pfc_pin_group automotive[0];
> } pinmux_groups = {
...
> static const struct {
> - struct sh_pfc_function common[29];
> + struct sh_pfc_function common[32];
> struct sh_pfc_function automotive[0];
> } pinmux_functions = {
It is Geert's call, but maybe those are a seperate patch?
signature.asc
Description: PGP signature
Re: [PATCH] mmc: renesas_sdhi: Whitelist R8A77990 SDHI
On Mon, Nov 05, 2018 at 10:39:35PM +0100, Marek Vasut wrote: > Whitelist R8A77990 E3 SoC in the SDHI driver. The SDHI core > present in the SoC is an 8tap variant of the Gen3 SDHI core. > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Simon Horman > Cc: Wolfram Sang > Cc: Yoshihiro Shimoda > Cc: Ulf Hansson > Cc: linux-renesas-soc@vger.kernel.org Reviewed-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH V2] arm64: dts: renesas: Switch eMMC bus to 1V8 on Salvator-X and ULCB
On Sun, Nov 04, 2018 at 09:37:07PM +0100, Marek Vasut wrote: > The eMMC card has two supplies, VCC and VCCQ. The VCC supplies the NAND > array and the VCCQ supplies the bus. On Salvator-X and ULCB, the VCC is > connected to 3.3V rail, while the VCCQ is connected to 1.8V rail. Adjust > the pinmux to match the bus, which is always operating in 1.8V mode. > > While at it, deduplicate the pinmux entries, which are now the same for > both default and UHS modes. We still need the two pinctrl entries to > match the bindings though. > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Simon Horman > Cc: Wolfram Sang > Cc: Yoshihiro Shimoda > Cc: linux-renesas-soc@vger.kernel.org > Cc: linux-...@vger.kernel.org Tested on M3-N and H3 ES2.0 with HS400 enabled eMMC: Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang signature.asc Description: PGP signature
[PATCH v4 3/6] media: dt-bindings: rcar-csi2: Add R8A77990
Add compatible string for R-Car E3 R8A77990 to the list of supported SoCs. Signed-off-by: Jacopo Mondi Reviewed-by: Rob Herring Reviewed-by: Simon Horman Reviewed-by: Laurent Pinchart Acked-by: Niklas Söderlund --- Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt index 2d385b6..2824489 100644 --- a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt @@ -12,6 +12,7 @@ Mandatory properties - "renesas,r8a7796-csi2" for the R8A7796 device. - "renesas,r8a77965-csi2" for the R8A77965 device. - "renesas,r8a77970-csi2" for the R8A77970 device. + - "renesas,r8a77990-csi2" for the R8A77990 device. - reg: the register base and size for the device registers - interrupts: the interrupt for the device -- 2.7.4
[PATCH v4 1/6] media: dt-bindings: rcar-vin: Add R8A77990 support
Add compatible string for R-Car E3 R8A77990 to the list of SoCs supported by rcar-vin driver. Signed-off-by: Jacopo Mondi Reviewed-by: Rob Herring Reviewed-by: Simon Horman Reviewed-by: Laurent Pinchart Acked-by: Niklas Söderlund --- Documentation/devicetree/bindings/media/rcar_vin.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt index d329a4e..7c878ca 100644 --- a/Documentation/devicetree/bindings/media/rcar_vin.txt +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt @@ -24,6 +24,7 @@ on Gen3 platforms to a CSI-2 receiver. - "renesas,vin-r8a7796" for the R8A7796 device - "renesas,vin-r8a77965" for the R8A77965 device - "renesas,vin-r8a77970" for the R8A77970 device + - "renesas,vin-r8a77990" for the R8A77990 device - "renesas,vin-r8a77995" for the R8A77995 device - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible device. -- 2.7.4
[PATCH v4 2/6] media: rcar-vin: Add support for R-Car R8A77990
Add R-Car E3 R8A77990 SoC to the rcar-vin supported ones.
Based on the experimental patch from Magnus Damm.
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
Acked-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-core.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index f476b2f..cae2166 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1088,6 +1088,22 @@ static const struct rvin_info rcar_info_r8a77970 = {
.routes = rcar_info_r8a77970_routes,
};
+static const struct rvin_group_route rcar_info_r8a77990_routes[] = {
+ { .csi = RVIN_CSI40, .channel = 0, .vin = 4, .mask = BIT(0) | BIT(3) },
+ { .csi = RVIN_CSI40, .channel = 0, .vin = 5, .mask = BIT(2) },
+ { .csi = RVIN_CSI40, .channel = 1, .vin = 4, .mask = BIT(2) },
+ { .csi = RVIN_CSI40, .channel = 1, .vin = 5, .mask = BIT(1) | BIT(3) },
+ { /* Sentinel */ }
+};
+
+static const struct rvin_info rcar_info_r8a77990 = {
+ .model = RCAR_GEN3,
+ .use_mc = true,
+ .max_width = 4096,
+ .max_height = 4096,
+ .routes = rcar_info_r8a77990_routes,
+};
+
static const struct rvin_group_route rcar_info_r8a77995_routes[] = {
{ /* Sentinel */ }
};
@@ -1146,6 +1162,10 @@ static const struct of_device_id rvin_of_id_table[] = {
.data = &rcar_info_r8a77970,
},
{
+ .compatible = "renesas,vin-r8a77990",
+ .data = &rcar_info_r8a77990,
+ },
+ {
.compatible = "renesas,vin-r8a77995",
.data = &rcar_info_r8a77995,
},
--
2.7.4
[PATCH v4 6/6] media: rcar-csi2: Handle per-SoC number of channels
The R-Car CSI-2 interface has a number of selectable 'channels' that
provides pixel data to the VINs during image acquisition.
Each channel can be used to match a CSI-2 data type and a CSI-2 virtual
channel to be routed to output path.
Different SoCs have different number of channels, with R-Car E3 being the
notable exception supporting only 2 of them.
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
v1 -> v2:
- Use the num_channels variable to decide if VCDT2 has to be written
as suggested by Laurent.
---
drivers/media/platform/rcar-vin/rcar-csi2.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
b/drivers/media/platform/rcar-vin/rcar-csi2.c
index 99f5b76..80ad906 100644
--- a/drivers/media/platform/rcar-vin/rcar-csi2.c
+++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
@@ -342,6 +342,7 @@ struct rcar_csi2_info {
int (*confirm_start)(struct rcar_csi2 *priv);
const struct rcsi2_mbps_reg *hsfreqrange;
unsigned int csi0clkfreqrange;
+ unsigned int num_channels;
bool clear_ulps;
};
@@ -476,13 +477,14 @@ static int rcsi2_start(struct rcar_csi2 *priv)
format = rcsi2_code_to_fmt(priv->mf.code);
/*
-* Enable all Virtual Channels.
+* Enable all supported CSI-2 channels with virtual channel and
+* data type matching.
*
* NOTE: It's not possible to get individual datatype for each
* source virtual channel. Once this is possible in V4L2
* it should be used here.
*/
- for (i = 0; i < 4; i++) {
+ for (i = 0; i < priv->info->num_channels; i++) {
u32 vcdt_part;
vcdt_part = VCDT_SEL_VC(i) | VCDT_VCDTN_EN | VCDT_SEL_DTN_ON |
@@ -511,7 +513,8 @@ static int rcsi2_start(struct rcar_csi2 *priv)
rcsi2_write(priv, FLD_REG, FLD_FLD_NUM(2) | FLD_FLD_EN4 |
FLD_FLD_EN3 | FLD_FLD_EN2 | FLD_FLD_EN);
rcsi2_write(priv, VCDT_REG, vcdt);
- rcsi2_write(priv, VCDT2_REG, vcdt2);
+ if (vcdt2)
+ rcsi2_write(priv, VCDT2_REG, vcdt2);
/* Lanes are zero indexed. */
rcsi2_write(priv, LSWAP_REG,
LSWAP_L0SEL(priv->lane_swap[0] - 1) |
@@ -940,32 +943,38 @@ static const struct rcar_csi2_info rcar_csi2_info_r8a7795
= {
.init_phtw = rcsi2_init_phtw_h3_v3h_m3n,
.hsfreqrange = hsfreqrange_h3_v3h_m3n,
.csi0clkfreqrange = 0x20,
+ .num_channels = 4,
.clear_ulps = true,
};
static const struct rcar_csi2_info rcar_csi2_info_r8a7795es1 = {
.hsfreqrange = hsfreqrange_m3w_h3es1,
+ .num_channels = 4,
};
static const struct rcar_csi2_info rcar_csi2_info_r8a7796 = {
.hsfreqrange = hsfreqrange_m3w_h3es1,
+ .num_channels = 4,
};
static const struct rcar_csi2_info rcar_csi2_info_r8a77965 = {
.init_phtw = rcsi2_init_phtw_h3_v3h_m3n,
.hsfreqrange = hsfreqrange_h3_v3h_m3n,
.csi0clkfreqrange = 0x20,
+ .num_channels = 4,
.clear_ulps = true,
};
static const struct rcar_csi2_info rcar_csi2_info_r8a77970 = {
.init_phtw = rcsi2_init_phtw_v3m_e3,
.confirm_start = rcsi2_confirm_start_v3m_e3,
+ .num_channels = 4,
};
static const struct rcar_csi2_info rcar_csi2_info_r8a77990 = {
.init_phtw = rcsi2_init_phtw_v3m_e3,
.confirm_start = rcsi2_confirm_start_v3m_e3,
+ .num_channels = 2,
};
static const struct of_device_id rcar_csi2_of_table[] = {
--
2.7.4
[PATCH v4 5/6] media: rcar: rcar-csi2: Update V3M/E3 PHTW tables
Update PHTW tables for V3M and E3 SoCs to the latest datasheet release
(R-Car Series, 3rd Generation manual rev1.00 20181017).
Signed-off-by: Jacopo Mondi
---
v1 -> v2:
- Limit the PHTW table to 1125 MBps, according to Laurent's comment
---
drivers/media/platform/rcar-vin/rcar-csi2.c | 62 ++---
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
b/drivers/media/platform/rcar-vin/rcar-csi2.c
index 695686b..99f5b76 100644
--- a/drivers/media/platform/rcar-vin/rcar-csi2.c
+++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
@@ -152,37 +152,37 @@ static const struct rcsi2_mbps_reg phtw_mbps_h3_v3h_m3n[]
= {
};
static const struct rcsi2_mbps_reg phtw_mbps_v3m_e3[] = {
- { .mbps = 80, .reg = 0x00 },
- { .mbps = 90, .reg = 0x20 },
- { .mbps = 100, .reg = 0x40 },
- { .mbps = 110, .reg = 0x02 },
- { .mbps = 130, .reg = 0x22 },
- { .mbps = 140, .reg = 0x42 },
- { .mbps = 150, .reg = 0x04 },
- { .mbps = 170, .reg = 0x24 },
- { .mbps = 180, .reg = 0x44 },
- { .mbps = 200, .reg = 0x06 },
- { .mbps = 220, .reg = 0x26 },
- { .mbps = 240, .reg = 0x46 },
- { .mbps = 250, .reg = 0x08 },
- { .mbps = 270, .reg = 0x28 },
- { .mbps = 300, .reg = 0x0a },
- { .mbps = 330, .reg = 0x2a },
- { .mbps = 360, .reg = 0x4a },
- { .mbps = 400, .reg = 0x0c },
- { .mbps = 450, .reg = 0x2c },
- { .mbps = 500, .reg = 0x0e },
- { .mbps = 550, .reg = 0x2e },
- { .mbps = 600, .reg = 0x10 },
- { .mbps = 650, .reg = 0x30 },
- { .mbps = 700, .reg = 0x12 },
- { .mbps = 750, .reg = 0x32 },
- { .mbps = 800, .reg = 0x52 },
- { .mbps = 850, .reg = 0x72 },
- { .mbps = 900, .reg = 0x14 },
- { .mbps = 950, .reg = 0x34 },
- { .mbps = 1000, .reg = 0x54 },
- { .mbps = 1050, .reg = 0x74 },
+ { .mbps = 89, .reg = 0x00 },
+ { .mbps = 99, .reg = 0x20 },
+ { .mbps = 109, .reg = 0x40 },
+ { .mbps = 129, .reg = 0x02 },
+ { .mbps = 139, .reg = 0x22 },
+ { .mbps = 149, .reg = 0x42 },
+ { .mbps = 169, .reg = 0x04 },
+ { .mbps = 179, .reg = 0x24 },
+ { .mbps = 199, .reg = 0x44 },
+ { .mbps = 219, .reg = 0x06 },
+ { .mbps = 239, .reg = 0x26 },
+ { .mbps = 249, .reg = 0x46 },
+ { .mbps = 269, .reg = 0x08 },
+ { .mbps = 299, .reg = 0x28 },
+ { .mbps = 329, .reg = 0x0a },
+ { .mbps = 359, .reg = 0x2a },
+ { .mbps = 399, .reg = 0x4a },
+ { .mbps = 449, .reg = 0x0c },
+ { .mbps = 499, .reg = 0x2c },
+ { .mbps = 549, .reg = 0x0e },
+ { .mbps = 599, .reg = 0x2e },
+ { .mbps = 649, .reg = 0x10 },
+ { .mbps = 699, .reg = 0x30 },
+ { .mbps = 749, .reg = 0x12 },
+ { .mbps = 799, .reg = 0x32 },
+ { .mbps = 849, .reg = 0x52 },
+ { .mbps = 899, .reg = 0x72 },
+ { .mbps = 949, .reg = 0x14 },
+ { .mbps = 999, .reg = 0x34 },
+ { .mbps = 1049, .reg = 0x54 },
+ { .mbps = 1099, .reg = 0x74 },
{ .mbps = 1125, .reg = 0x16 },
{ /* sentinel */ },
};
--
2.7.4
[PATCH v4 4/6] media: rcar-csi2: Add R8A77990 support
Add support for R-Car E3 R8A77965 to R-Car CSI-2 driver.
Based on the experimental patch from Magnus Damm.
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
Acked-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-csi2.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
b/drivers/media/platform/rcar-vin/rcar-csi2.c
index b0044a0..695686b 100644
--- a/drivers/media/platform/rcar-vin/rcar-csi2.c
+++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
@@ -963,6 +963,11 @@ static const struct rcar_csi2_info rcar_csi2_info_r8a77970
= {
.confirm_start = rcsi2_confirm_start_v3m_e3,
};
+static const struct rcar_csi2_info rcar_csi2_info_r8a77990 = {
+ .init_phtw = rcsi2_init_phtw_v3m_e3,
+ .confirm_start = rcsi2_confirm_start_v3m_e3,
+};
+
static const struct of_device_id rcar_csi2_of_table[] = {
{
.compatible = "renesas,r8a7795-csi2",
@@ -980,6 +985,10 @@ static const struct of_device_id rcar_csi2_of_table[] = {
.compatible = "renesas,r8a77970-csi2",
.data = &rcar_csi2_info_r8a77970,
},
+ {
+ .compatible = "renesas,r8a77990-csi2",
+ .data = &rcar_csi2_info_r8a77990,
+ },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, rcar_csi2_of_table);
--
2.7.4
[PATCH v4 0/6] media: rcar-vin: Add support for R-Car E3
Hello, this series add support for the R-Car E3 R8A77990 SoC to the rcar-vin and rcar-csi2 driver. Compared to v3 (which has been sent out without the 'PATCH v3' subject, sorry about this) I have updated the PHTW tables to match what the datasheet reports and I have included a comment from Laurent in patch [6/6]. Single patches changelog in commit messages. Thanks j Jacopo Mondi (6): media: dt-bindings: rcar-vin: Add R8A77990 support media: rcar-vin: Add support for R-Car R8A77990 media: dt-bindings: rcar-csi2: Add R8A77990 media: rcar-csi2: Add R8A77990 support media: rcar: rcar-csi2: Update V3M/E3 PHTW tables media: rcar-csi2: Handle per-SoC number of channels .../devicetree/bindings/media/rcar_vin.txt | 1 + .../bindings/media/renesas,rcar-csi2.txt | 1 + drivers/media/platform/rcar-vin/rcar-core.c| 20 + drivers/media/platform/rcar-vin/rcar-csi2.c| 86 +- 4 files changed, 74 insertions(+), 34 deletions(-) -- 2.7.4
Re: [PATCH 1/2] arm64: dts: r8a77990: Add SDHI device nodes
Hi Marek,
On Tue, Nov 6, 2018 at 11:32 AM Marek Vasut wrote:
> On 11/06/2018 06:26 AM, Yoshihiro Shimoda wrote:
> >> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:41 AM
> >>
> >> From: Takeshi Kihara
> >>
> >> This patch adds SDHI{0,1,3} device nodes for the r8a77990 SoC.
> >>
> >> Signed-off-by: Takeshi Kihara
> >> Signed-off-by: Marek Vasut
> >> Cc: Geert Uytterhoeven
> >> Cc: Simon Horman
> >> Cc: Wolfram Sang
> >> Cc: Yoshihiro Shimoda
> >> Cc: linux-renesas-soc@vger.kernel.org
> >> Cc: linux-arm-ker...@lists.infradead.org
> >> ---
> >
> > Thank you for the patch!
> >
> > Reviewed-by: Yoshihiro Shimoda
> >
> > I guess this patch and the 2/2 patch for ebisu have to be merged into a
> > patch though.
>
> I wonder about that, 1/2 is adding SDHI DT nodes for an SoC, 2/2 is
> enabling SDHI on a particular board, which I think should be separate.
The arm-soc maintainers tend to disagree, that's why Shimoda-san asked
to combine them.
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 v4 0/4] sh-pfc: Variadic VIN_DATA_PIN_GROUP macro + updates
Hi Geert, thanks to your suggestion I made a variadic macro out of the VIN_DATA_PIN_GROUP one. The macro accepts an optional third argument 'version' and creates properly formatted names in the form of 'vin4_data8_a' in place of the previous 'vin4_data_a8' ones. I included in this series the refactoring of existing users of versioned VIN_DATA_PIN_GROUP macro and upstreaming of VIN4 and VIN5 enablement for both R-Car M3-N and E3, both of them users of versioned VIN groups. Thanks j v3 -> v4: - The series gathers different patch series previously sent separately: [PATCH 0/2] pinctrl: sh-pfc: r8a77965: Add VIN4 and VIN5 [PATCH] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions As E3 patch depends on the M3-N series, I made a single one out of those. Changelog for the E3 patch (which was actually at v3) is included in the single patch commit message. Jacopo Mondi (4): pinctrl: sh-pfc: Add optional arg to VIN_DATA_PIN_GROUP pinctrl: sh-pfc: Fix VIN versioned groups name pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions pinctrl: sh-pfc: r8a77990: Add VIN[4|5] groups/functions drivers/pinctrl/sh-pfc/pfc-r8a7792.c | 6 +- drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 24 ++-- drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 24 ++-- drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 254 ++ drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 244 drivers/pinctrl/sh-pfc/sh_pfc.h | 17 +-- 6 files changed, 534 insertions(+), 35 deletions(-) -- 2.7.4
[PATCH v4 4/4] pinctrl: sh-pfc: r8a77990: Add VIN[4|5] groups/functions
Add pin, mux and functions definitions for VIN4 and VIN5 for R-Car E3.
Signed-off-by: Jacopo Mondi
---
v3 -> v4:
- Use new variadic version of VIN_DATA_PIN_GROUP macro
v2 -> v3:
- Rebased on v4.20-rc1
- Use the newly introduced VIN_DATA_PIN_GROUP_VER macro
Incorporate Geert's comments:
- vin5_data8_b is only used with 8 pins: use regular SH_PFC_PIN_GROUP()
- remove stf groups for vin4/vin5
- confirmed that pins [23-8] of vin4's groups 'a' and 'b' are shared
- confirmed with HW team the synchronism pins in vin5 are only for group 'a'
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 244 ++
1 file changed, 244 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index 1fdafa4..16fd139 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -2433,6 +2433,190 @@ static const unsigned int usb30_id_mux[] = {
USB3HS0_ID_MARK,
};
+/* - VIN4 ---
*/
+static const union vin_data vin4_data_a_pins = {
+ .data24 = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+ },
+};
+
+static const union vin_data vin4_data_a_mux = {
+ .data24 = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+ },
+};
+
+static const union vin_data vin4_data_b_pins = {
+ .data24 = {
+ RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 11),
+ RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
+ RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6),
+ RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 17),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 15),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+ },
+};
+
+static const union vin_data vin4_data_b_mux = {
+ .data24 = {
+ VI4_DATA0_B_MARK, VI4_DATA1_B_MARK,
+ VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
+ VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
+ VI4_DATA6_B_MARK, VI4_DATA7_B_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+ },
+};
+
+static const unsigned int vin4_sync_pins[] = {
+ /* HSYNC, VSYNC */
+ RCAR_GP_PIN(2, 25), RCAR_GP_PIN(2, 24),
+};
+
+static const unsigned int vin4_sync_mux[] = {
+ VI4_HSYNC_N_MARK, VI4_VSYNC_N_MARK,
+};
+
+static const unsigned int vin4_field_pins[] = {
+ RCAR_GP_PIN(2, 23),
+};
+
+static const unsigned int vin4_field_mux[] = {
+ VI4_FIELD_MARK,
+};
+
+static const unsigned int vin4_clkenb_pins[] = {
+ RCAR_GP_PIN(1, 2),
+};
+
+static const unsigned int vin4_clkenb_mux[] = {
+ VI4_CLKENB_MARK,
+};
+
+static const unsigned int vin4_clk_pins[] = {
+ RCAR_GP_PIN(2, 22),
+};
+
+static const unsigned int vin4_clk_mux[] = {
+ VI4_CLK_MARK,
+};
+
+/* - VIN5 ---
*/
+static const union vin_data vin5_data_a_pins = {
+ .data16 = {
+ RCAR_GP_PIN(1, 1), RCAR_GP_PIN(1, 2),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+
[PATCH v4 2/4] pinctrl: sh-pfc: Fix VIN versioned groups name
Versioned VIN groups can appear on different sets of pins. Using the
VIN_DATA_PIN_GROUP macro now supports proper naming of said groups through
an optional 'version' argument.
Use the 'version' argument for said macro to fix naming of versioned
groups for R-Car SoCs that defines them.
Signed-off-by: Jacopo Mondi
---
drivers/pinctrl/sh-pfc/pfc-r8a7792.c | 6 +++---
drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 24
drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 24
3 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
index bf0681b..a8a110d 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
@@ -1744,10 +1744,10 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
VIN_DATA_PIN_GROUP(vin1_data, 12),
VIN_DATA_PIN_GROUP(vin1_data, 10),
VIN_DATA_PIN_GROUP(vin1_data, 8),
- VIN_DATA_PIN_GROUP(vin1_data_b, 24),
- VIN_DATA_PIN_GROUP(vin1_data_b, 20),
+ VIN_DATA_PIN_GROUP(vin1_data, 24, _b),
+ VIN_DATA_PIN_GROUP(vin1_data, 20, _b),
SH_PFC_PIN_GROUP(vin1_data18_b),
- VIN_DATA_PIN_GROUP(vin1_data_b, 16),
+ VIN_DATA_PIN_GROUP(vin1_data, 16, _b),
SH_PFC_PIN_GROUP(vin1_sync),
SH_PFC_PIN_GROUP(vin1_field),
SH_PFC_PIN_GROUP(vin1_clkenb),
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
index 0af737d..20fac0f 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
@@ -4474,20 +4474,20 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(usb2),
SH_PFC_PIN_GROUP(usb2_ch3),
SH_PFC_PIN_GROUP(usb30),
- VIN_DATA_PIN_GROUP(vin4_data_a, 8),
- VIN_DATA_PIN_GROUP(vin4_data_a, 10),
- VIN_DATA_PIN_GROUP(vin4_data_a, 12),
- VIN_DATA_PIN_GROUP(vin4_data_a, 16),
+ VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 10, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 12, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 16, _a),
SH_PFC_PIN_GROUP(vin4_data18_a),
- VIN_DATA_PIN_GROUP(vin4_data_a, 20),
- VIN_DATA_PIN_GROUP(vin4_data_a, 24),
- VIN_DATA_PIN_GROUP(vin4_data_b, 8),
- VIN_DATA_PIN_GROUP(vin4_data_b, 10),
- VIN_DATA_PIN_GROUP(vin4_data_b, 12),
- VIN_DATA_PIN_GROUP(vin4_data_b, 16),
+ VIN_DATA_PIN_GROUP(vin4_data, 20, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 24, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 8, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 10, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 12, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 16, _b),
SH_PFC_PIN_GROUP(vin4_data18_b),
- VIN_DATA_PIN_GROUP(vin4_data_b, 20),
- VIN_DATA_PIN_GROUP(vin4_data_b, 24),
+ VIN_DATA_PIN_GROUP(vin4_data, 20, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 24, _b),
SH_PFC_PIN_GROUP(vin4_sync),
SH_PFC_PIN_GROUP(vin4_field),
SH_PFC_PIN_GROUP(vin4_clkenb),
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
index 3a6d21d..b003abd 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
@@ -4409,20 +4409,20 @@ static const struct {
SH_PFC_PIN_GROUP(usb0),
SH_PFC_PIN_GROUP(usb1),
SH_PFC_PIN_GROUP(usb30),
- VIN_DATA_PIN_GROUP(vin4_data_a, 8),
- VIN_DATA_PIN_GROUP(vin4_data_a, 10),
- VIN_DATA_PIN_GROUP(vin4_data_a, 12),
- VIN_DATA_PIN_GROUP(vin4_data_a, 16),
+ VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 10, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 12, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 16, _a),
SH_PFC_PIN_GROUP(vin4_data18_a),
- VIN_DATA_PIN_GROUP(vin4_data_a, 20),
- VIN_DATA_PIN_GROUP(vin4_data_a, 24),
- VIN_DATA_PIN_GROUP(vin4_data_b, 8),
- VIN_DATA_PIN_GROUP(vin4_data_b, 10),
- VIN_DATA_PIN_GROUP(vin4_data_b, 12),
- VIN_DATA_PIN_GROUP(vin4_data_b, 16),
+ VIN_DATA_PIN_GROUP(vin4_data, 20, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 24, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 8, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 10, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 12, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 16, _b),
SH_PFC_PIN_GROUP(vin4_data18_b),
- VIN_DATA_PIN_GROUP(vin4_data_b, 20),
- VIN_DATA_PIN_GROUP(vin4_data_b, 24),
+ VIN_DATA_PIN_GROUP(vin4_data, 20, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 24, _b),
SH_PFC_PIN_GROUP(vin4_sync),
SH_PFC_PIN_GROUP(vin4_field),
SH_PFC_PIN_GROUP(vin4_clkenb),
--
2.7.
[PATCH v4 3/4] pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions
The VIN4 and VIN5 interfaces supports parallel video input.
Add pin, mux and functions definitions for VIN4 and VIN5 for R-Car M3-N.
Reviewed-by: Ulrich Hecht
Signed-off-by: Jacopo Mondi
---
drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 254 ++
1 file changed, 254 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
index dfdd982..59ad320 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
@@ -3725,6 +3725,216 @@ static const unsigned int usb30_mux[] = {
USB30_PWEN_MARK, USB30_OVC_MARK,
};
+/* - VIN4 ---
*/
+static const unsigned int vin4_data18_a_pins[] = {
+ RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 11),
+ RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13),
+ RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 15),
+ RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3),
+ RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7),
+};
+
+static const unsigned int vin4_data18_a_mux[] = {
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+};
+
+static const union vin_data vin4_data_a_pins = {
+ .data24 = {
+ RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 9),
+ RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 11),
+ RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13),
+ RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 15),
+ RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 1),
+ RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(0, 0), RCAR_GP_PIN(0, 1),
+ RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3),
+ RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7),
+ },
+};
+
+static const union vin_data vin4_data_a_mux = {
+ .data24 = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+ },
+};
+
+static const unsigned int vin4_data18_b_pins[] = {
+ RCAR_GP_PIN(2, 2), RCAR_GP_PIN(2, 3),
+ RCAR_GP_PIN(2, 4), RCAR_GP_PIN(2, 5),
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3),
+ RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7),
+};
+
+static const unsigned int vin4_data18_b_mux[] = {
+ VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
+ VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
+ VI4_DATA6_B_MARK, VI4_DATA7_B_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+};
+
+static const union vin_data vin4_data_b_pins = {
+ .data24 = {
+ RCAR_GP_PIN(2, 0), RCAR_GP_PIN(2, 1),
+ RCAR_GP_PIN(2, 2), RCAR_GP_PIN(2, 3),
+ RCAR_GP_PIN(2, 4), RCAR_GP_PIN(2, 5),
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 1),
+ RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(0, 0), RCAR_GP_PIN(0, 1),
+ RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3),
+ RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7),
+ },
+};
+
+static const union vin_data vin4_data_b_mux = {
+ .data24 = {
+ VI4_DATA0_B_MARK, VI4_DATA1_B_MARK,
+ VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
+ VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
+ VI4_DA
[PATCH v4 1/4] pinctrl: sh-pfc: Add optional arg to VIN_DATA_PIN_GROUP
VIN data groups may appear on different sets of pins, usually named
"vinX_data_[a|b]". The existing VIN_DATA_PIN_GROUP() does not support
appending the '_a' or '_b' suffix, leading to the definition of groups
names not consistent with the ones defined using SH_PFC_PIN_GROUP() macro.
Fix this by adding making the VIN_DATA_PIN_GROUP macro a variadic one,
which accepts an optional 'version' argument.
Signed-off-by: Jacopo Mondi
---
drivers/pinctrl/sh-pfc/sh_pfc.h | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h b/drivers/pinctrl/sh-pfc/sh_pfc.h
index 458ae0a..0e0b4cc 100644
--- a/drivers/pinctrl/sh-pfc/sh_pfc.h
+++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
@@ -54,15 +54,16 @@ struct sh_pfc_pin_group {
/*
* Using union vin_data saves memory occupied by the VIN data pins.
- * VIN_DATA_PIN_GROUP() is a macro used to describe the VIN pin groups
- * in this case.
+ * VIN_DATA_PIN_GROUP() is a macro used to describe the VIN pin groups
+ * in this case. It accepts an optional 'version' argument used when the
+ * same group can appear on a different set of pins.
*/
-#define VIN_DATA_PIN_GROUP(n, s) \
- { \
- .name = #n#s, \
- .pins = n##_pins.data##s, \
- .mux = n##_mux.data##s, \
- .nr_pins = ARRAY_SIZE(n##_pins.data##s),\
+#define VIN_DATA_PIN_GROUP(n, s, ...) \
+ { \
+ .name = #n#s#__VA_ARGS__, \
+ .pins = n##__VA_ARGS__##_pins.data##s, \
+ .mux = n##__VA_ARGS__##_mux.data##s,\
+ .nr_pins = ARRAY_SIZE(n##__VA_ARGS__##_pins.data##s), \
}
union vin_data {
--
2.7.4
Re: [RFC][PATCH] PCI: Avoid PCI device removing/rescanning through sysfs triggers a deadlock
On 11/06/2018 09:13 AM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> Thanks for your patch!
>
> On Tue, Nov 6, 2018 at 12:25 AM Marek Vasut wrote:
>> From: Tho Vu
>>
>> This patch fixes deadlock warning in removing/rescanning through sysfs
>> when CONFIG_PROVE_LOCKING is enabled.
>>
>> The issue can be reproduced by these steps:
>> 1. Enable CONFIG_PROVE_LOCKING via defconfig or menuconfig
>> 2. Insert Ethernet card into PCIe CH0 and start up.
>>After kernel starting up, execute the following command.
>>echo 1 > /sys/class/pci_bus/\:00/device/\:00\:00.0/remove
>> 3. Rescan PCI device by this command
>>echo 1 > /sys/class/pci_bus/\:00/rescan
>>
>> The deadlock warnings will occur.
>>
>> WARNING: possible recursive locking detected
>> 4.14.70-ltsi-yocto-standard #27 Not tainted
>>
>> sh/3402 is trying to acquire lock:
>> (kn->count#78){}, at: kernfs_remove_by_name_ns+0x50/0xa8
>>
>> but task is already holding lock:
>> (kn->count#78){}, at: kernfs_remove_self+0xe0/0x130
>>
>> other info that might help us debug this:
>> Possible unsafe locking scenario:
>>
>>CPU0
>>
>> lock(kn->count#78);
>> lock(kn->count#78);
>>
>> *** DEADLOCK ***
>>
>> May be due to missing lock nesting notation
>>
>> 4 locks held by sh/3402:
>> #0: (sb_writers#4){.+.+}, at: vfs_write+0x198/0x1b0
>> #1: (&of->mutex){+.+.}, at: kernfs_fop_write+0x108/0x210
>> #2: (kn->count#78){}, at: kernfs_remove_self+0xe0/0x130
>> #3: (pci_rescan_remove_lock){+.+.}, at: pci_lock_rescan_remove+0x1c/0x28
>>
>> stack backtrace:
>> CPU: 3 PID: 3402 Comm: sh Not tainted 4.14.70-ltsi-yocto-standard #27
>> Hardware name: Renesas Salvator-X 2nd version board based on r8a7795
>> ES3.0+ with 8GiB (4 x 2 GiB) (DT)
>> Call trace:
>> dump_backtrace+0x0/0x3d8
>> show_stack+0x14/0x20
>> dump_stack+0xbc/0xf4
>> __lock_acquire+0x930/0x18a8
>> lock_acquire+0x48/0x68
>> __kernfs_remove+0x280/0x2f8
>> kernfs_remove_by_name_ns+0x50/0xa8
>> remove_files.isra.0+0x38/0x78
>> sysfs_remove_group+0x4c/0xa0
>> sysfs_remove_groups+0x38/0x60
>> device_remove_attrs+0x54/0x78
>> device_del+0x1ac/0x308
>> pci_remove_bus_device+0x78/0xf8
>> pci_remove_bus_device+0x34/0xf8
>> pci_stop_and_remove_bus_device_locked+0x24/0x38
>> remove_store+0x6c/0x78
>> dev_attr_store+0x18/0x28
>> sysfs_kf_write+0x4c/0x78
>> kernfs_fop_write+0x138/0x210
>> __vfs_write+0x18/0x118
>> vfs_write+0xa4/0x1b0
>> SyS_write+0x48/0xb0
>>
>> This warning occurs due to a self-deletion attribute using in the sysfs
>
> used
>
>> PCI device directory. This kind of attribute is really tricky,
>> it does not allow pci framework drop this attribute until all active
>
> to drop
>
>> .show() and .store() callbacks have finished unless
>
> finished, unless
>
>> sysfs_break_active_protection() is called.
>> Hence this patch avoids writing into this attribute triggers a deadlock.
>
> and trigger a deadlock.
>
>>
>> Referrence commit 5b55b24cec4c ("scsi: core: Avoid that SCSI device
>> removal through sysfs triggers a deadlock")
>> of scsi driver
>>
>> Signed-off-by: Tho Vu
>
> You forgot to append your own SoB?
>
>> --- a/drivers/pci/pci-sysfs.c
>> +++ b/drivers/pci/pci-sysfs.c
>> @@ -470,12 +470,22 @@ static ssize_t remove_store(struct device *dev, struct
>> device_attribute *attr,
>> const char *buf, size_t count)
>> {
>> unsigned long val;
>> + struct kernfs_node *kn;
>> +
>> + kn = sysfs_break_active_protection(&dev->kobj, &attr->attr);
>> + WARN_ON_ONCE(!kn);
>
> What's the purpose of the WARN_ON_ONCE? Just copied from the SCSI solution?
> Can this ever happen?
I sent the patch as-is from the BSP after a short discussion with Bjorn
on IRC, mostly because it contains the description of the problem. I
don't think this is the right solution, it feels more like a hack to me,
which is why I flagged it as RFC.
Or do you think this is the correct way of solving the problem ?
--
Best regards,
Marek Vasut
Re: [PATCH 1/2] arm64: dts: r8a77990: Add SDHI device nodes
On 11/06/2018 06:26 AM, Yoshihiro Shimoda wrote:
> Hello Marek-san,
Hello Shimoda-san,
>> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:41 AM
>>
>> From: Takeshi Kihara
>>
>> This patch adds SDHI{0,1,3} device nodes for the r8a77990 SoC.
>>
>> Signed-off-by: Takeshi Kihara
>> Signed-off-by: Marek Vasut
>> Cc: Geert Uytterhoeven
>> Cc: Simon Horman
>> Cc: Wolfram Sang
>> Cc: Yoshihiro Shimoda
>> Cc: linux-renesas-soc@vger.kernel.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> ---
>
> Thank you for the patch!
>
> Reviewed-by: Yoshihiro Shimoda
>
> I guess this patch and the 2/2 patch for ebisu have to be merged into a patch
> though.
I wonder about that, 1/2 is adding SDHI DT nodes for an SoC, 2/2 is
enabling SDHI on a particular board, which I think should be separate.
--
Best regards,
Marek Vasut
Re: [PATCH 2/2] arm64: dts: r8a77990: ebisu: Enable SDHI interfaces
On 11/06/2018 09:34 AM, Wolfram Sang wrote:
>
>> +sdhi3_pins: sd3 {
>> +groups = "sdhi3_data8", "sdhi3_ctrl";
>> +function = "sdhi3";
>> +power-source = <1800>;
>> +};
>> +
>> +sdhi3_pins_uhs: sd3_uhs {
>> +groups = "sdhi3_data8", "sdhi3_ctrl";
>> +function = "sdhi3";
>> +power-source = <1800>;
>> +};
>
> Shouldn't we have only one pinctrl config here, like you did recently
> for the other Gen3 SoCs?
We should, thanks for pointing it out, fixed in V2.
--
Best regards,
Marek Vasut
Re: [PATCH 2/2] arm64: dts: r8a77990: ebisu: Enable SDHI interfaces
On 11/06/2018 06:29 AM, Yoshihiro Shimoda wrote:
> Hello Marek-san,
Hello Shimoda-san,
>> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:41 AM
>>
>> From: Takeshi Kihara
>>
>> This patch enables SD card slot connected to SDHI0, micro SD card slot
>> connected to SDHI1 and eMMC connected to SDHI3 on the Ebisu board using
>> the R8A77990 SoC.
>>
>> Signed-off-by: Takeshi Kihara
>> Signed-off-by: Marek Vasut
>> Cc: Geert Uytterhoeven
>> Cc: Simon Horman
>> Cc: Wolfram Sang
>> Cc: Yoshihiro Shimoda
>> Cc: linux-renesas-soc@vger.kernel.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> ---
>
> Thank you for the patch!
>
> Reviewed-by: Yoshihiro Shimoda
>
> I have a few nit comments below.
>
>> .../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 136 ++
>> 1 file changed, 136 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
>> b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
>> index 611f0265fcc5..bda1765dcdbd 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
>> +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
>
>> +sdhi3_pins: sd3 {
>> +groups = "sdhi3_data8", "sdhi3_ctrl";
>> +function = "sdhi3";
>> +power-source = <1800>;
>> +};
>> +
>> +sdhi3_pins_uhs: sd3_uhs {
>> +groups = "sdhi3_data8", "sdhi3_ctrl";
>> +function = "sdhi3";
>> +power-source = <1800>;
>> +};
>
> I assumed that we will add "sdhi3_ds" into these groups when we add support
> for HS400 mode.
That's a good point, I think we can add it right away, so added in V2.
--
Best regards,
Marek Vasut
RE: [PATCH v2] drm/bridge/sii902x: Fix EDID readback
Hello Peter,
Thank you for your feedback!
> Subject: Re: [PATCH v2] drm/bridge/sii902x: Fix EDID readback
>
> Hi!
>
> A handful of nitpicks inline...
>
> On 2018-11-05 14:56, Fabrizio Castro wrote:
> > While adding SiI9022A support to the iwg23s board, it came
> > up that when the HDMI transmitter is in pass through mode the
> > device is not compliant with the I2C specification anymore,
> > as it requires a far bigger tbuf, due to a delay the HDMI
> > transmitter is adding when relaying the STOP condition on the
> > monitor i2c side of things.
> >
> > When not providing an appropriate delay after the STOP condition
> > the i2c bus would get stuck. Also, any other traffic on the bus
> > while talking to the monitor may cause the transaction to fail
> > or even cause issues with the i2c bus as well.
> >
> > I2c-gates seemed to reach consent as a possible way to address
> > these issues, and as such this patch is implementing a solution
> > based on that. Since others are clearly relying on the current
> > implementation of the driver, this patch won't require any DT
> > changes.
> >
> > Since we don't want any interference during the DDC Bus
> > Request/Grant procedure and while talking to the monitor, we
> > have to use the adapter locking primitives rather than the
> > i2c-mux locking primitives.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v1->v2:
> > * Incorporated comments from Peter Rosin
> >
> > drivers/gpu/drm/bridge/sii902x.c | 256
> > ---
> > 1 file changed, 188 insertions(+), 68 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/sii902x.c
> > b/drivers/gpu/drm/bridge/sii902x.c
> > index e59a135..dd4318b 100644
> > --- a/drivers/gpu/drm/bridge/sii902x.c
> > +++ b/drivers/gpu/drm/bridge/sii902x.c
> > @@ -1,4 +1,6 @@
> > /*
> > + * Copyright (C) 2018 Renesas Electronics
> > + *
> > * Copyright (C) 2016 Atmel
> > * Bo Shen
> > *
> > @@ -21,6 +23,7 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -86,8 +89,49 @@ struct sii902x {
> > struct drm_bridge bridge;
> > struct drm_connector connector;
> > struct gpio_desc *reset_gpio;
> > +struct i2c_mux_core *i2cmux;
> > };
> >
> > +static int sii902x_read_unlocked(struct i2c_client *i2c, u8 reg, u8 *val)
> > +{
> > +union i2c_smbus_data data;
> > +int ret;
> > +
> > +ret = __i2c_smbus_xfer(i2c->adapter, i2c->addr, i2c->flags,
> > + I2C_SMBUS_READ, reg, I2C_SMBUS_BYTE_DATA, &data);
> > +
> > +if (ret < 0)
> > +return ret;
> > +
> > +*val = data.byte;
> > +return 0;
> > +}
> > +
> > +static int sii902x_write_unlocked(struct i2c_client *i2c, u8 reg, u8 val)
> > +{
> > +union i2c_smbus_data data;
> > +
> > +data.byte = val;
> > +
> > +return __i2c_smbus_xfer(i2c->adapter, i2c->addr, i2c->flags,
> > +I2C_SMBUS_WRITE, reg, I2C_SMBUS_BYTE_DATA,
> > +&data);
> > +}
> > +
> > +static int sii902x_update_bits_unlocked(struct i2c_client *i2c, u8 reg, u8
> > mask,
> > +u8 val)
> > +{
> > +int ret;
> > +u8 status;
> > +
> > +ret = sii902x_read_unlocked(i2c, reg, &status);
> > +if (ret)
> > +return ret;
> > +status &= ~mask;
> > +status |= val & mask;
> > +return sii902x_write_unlocked(i2c, reg, status);
> > +}
> > +
> > static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
> > {
> > return container_of(bridge, struct sii902x, bridge);
> > @@ -135,41 +179,11 @@ static const struct drm_connector_funcs
> > sii902x_connector_funcs = {
> > static int sii902x_get_modes(struct drm_connector *connector)
> > {
> > struct sii902x *sii902x = connector_to_sii902x(connector);
> > -struct regmap *regmap = sii902x->regmap;
> > u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> > -struct device *dev = &sii902x->i2c->dev;
> > -unsigned long timeout;
> > -unsigned int retries;
> > -unsigned int status;
> > struct edid *edid;
> > -int num = 0;
> > -int ret;
> > -
> > -ret = regmap_update_bits(regmap, SII902X_SYS_CTRL_DATA,
> > - SII902X_SYS_CTRL_DDC_BUS_REQ,
> > - SII902X_SYS_CTRL_DDC_BUS_REQ);
> > -if (ret)
> > -return ret;
> > -
> > -timeout = jiffies +
> > - msecs_to_jiffies(SII902X_I2C_BUS_ACQUISITION_TIMEOUT_MS);
> > -do {
> > -ret = regmap_read(regmap, SII902X_SYS_CTRL_DATA, &status);
> > -if (ret)
> > -return ret;
> > -} while (!(status & SII902X_SYS_CTRL_DDC_BUS_GRTD) &&
> > - time_before(jiffies, timeout));
> > -
> > -if (!(status & SII902X_SYS_CTRL_DDC_BUS_GRTD)) {
> > -dev_err(dev, "failed to acquire the i2c bus\n");
> > -return -ETIMEDOUT;
> > -}
> > -
> > -ret = regmap_write(regmap, SII902X_SYS_CTRL_DATA, status);
> > -if (ret)
> > -return ret;
> > +int num = 0, ret;
> >
> > -edid = drm_get_edid(connector, sii902x->i2c->adapter);
> > +edid = drm_get_edid(connector, sii902x->i2cmux->adapter[0]);
> > drm_connector_update_edid_property(connector, edid);
> > if (edid) {
> > num = drm_add_edid_modes(connector, edid);
> > @@ -181,42 +195,6 @@ static int sii902x_get_modes(struct drm_connector
> > *connector)
> > if (ret)
>
RE: [PATCH v2] drm/bridge/sii902x: Fix EDID readback
Hello Boris,
Thank you for your feedback!
> Subject: Re: [PATCH v2] drm/bridge/sii902x: Fix EDID readback
>
> Hi Fabrizio,
>
> Thanks for working on that. I think your solution fixes the issue we had
> on atmel boards [1] in a clean way (still have to find some time to
> test it).
>
> On Mon, 5 Nov 2018 13:56:48 +
> Fabrizio Castro wrote:
>
> > @@ -441,6 +558,9 @@ static int sii902x_remove(struct i2c_client *client)
> > {
> > struct sii902x *sii902x = i2c_get_clientdata(client);
> >
> > +if (sii902x->i2cmux)
> > +i2c_mux_del_adapters(sii902x->i2cmux);
> > +
>
> Just one tiny detail: I think you can safely call i2c_mux_del_adapters()
> unconditionally since ->remove() will only be called if ->probe()
> succeeded, which guarantees that sii902x->i2cmux != NULL.
Fair point, will change in the next version.
Cheers,
Fab
>
>
> > drm_bridge_remove(&sii902x->bridge);
> >
> > return 0;
>
> [1]https://patchwork.kernel.org/patch/9532005/
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
Re: [PATCH 1/2] ARM: dts: r8a77470: Add watchdog support to SoC dtsi
Hi Biju,
On Fri, Oct 26, 2018 at 11:40 AM Biju Das wrote:
> This patch adds watchdog support to the r8a77470 SoC dtsi.
>
> Signed-off-by: Biju Das
Thanks for your patch!
> --- a/arch/arm/boot/dts/r8a77470.dtsi
> +++ b/arch/arm/boot/dts/r8a77470.dtsi
> @@ -196,6 +196,16 @@
> reg = <0 0xe616 0 0x100>;
> };
>
> + rwdt: watchdog@e602 {
Please follow the sort order rules:
- By unit-address (if present), per group,
- Alphabetically.
> + compatible = "renesas,r8a77470-wdt",
> +"renesas,rcar-gen2-wdt";
> + reg = <0 0xe602 0 0x0c>;
> + clocks = <&cpg CPG_MOD 402>;
> + power-domains = <&sysc R8A77470_PD_ALWAYS_ON>;
> + resets = <&cpg 402>;
> + status = "disabled";
> + };
> +
> sysc: system-controller@e618 {
> compatible = "renesas,r8a77470-sysc";
> reg = <0 0xe618 0 0x200>;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 0/2] pinctrl: sh-pfc: r8a77965: Add VIN4 and VIN5
Hi Geert,
On Tue, Nov 06, 2018 at 10:24:30AM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Tue, Nov 6, 2018 at 10:08 AM jacopo mondi wrote:
> > On Mon, Nov 05, 2018 at 06:19:22PM +0100, Geert Uytterhoeven wrote:
> > > On Mon, Oct 29, 2018 at 7:14 PM Jacopo Mondi
> > > wrote:
> > > >this two patches add supports for VIN4 and VIN5 interfaces to R-Car
> > > > M3-N.
> > > >
> > > > On this SoC (and in the forthcoming support for E3 R8A77990) the VIN
> > > > groups
> > > > could appear on different sets of pins, usually the 'a' and 'b' one.
> > > >
> > > > With the existing VIN_DATA_PIN_GROUP macro we have to specify group
> > > > names as:
> > > >
> > > > VIN_DATA_PIN_GROUP(vin4_data_a, 8)
> > > >
> > > > which results in the group being named as "vin4_data_a_8" which is
> > > > un-consistent with the canonical group names (eg. "vin4_data8_a").
> > > >
> > > > This series adds a macro that allows to specify the group 'version'
> > > > along with
> > > > the pin and mux numbers in patch [1/1]. I haven't been able to find a
> > > > better
> > > > term than 'version' as 'group' was already taken. Suggestions welcome.
> > >
> > > Yeah, the datasheet also calls these groups :-(
> > > A possible alternative is to use "variant"?
> > >
> > > Or, what about avoiding the name issue by making the VIN_DATA_PIN_GROUP()
> > > macro varargs, and passing the "variant" as the (optional) third
> > > parameter?
> > > That way existing users work as a before, while you can also write e.g.
> > >
> > > VIN_DATA_PIN_GROUP_VER(vin4_data, 8, _a),
> >
> > Indeed.
> >
> > Would something along the following lines fly for you?
> >
> > #define VIN_DATA_PIN_GROUP(n, s, ...) \
> > { \
> > .name = #n#s#__VA_ARGS__, \
> > .pins = n##__VA_ARGS__##_pins.data##s, \
> > .mux = n##__VA_ARGS__##_mux.data##s,\
> > .nr_pins = ARRAY_SIZE(n##__VA_ARGS__##_pins.data##s), \
> > }
> >
> > It can be used as:
> > VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
> > VIN_DATA_PIN_GROUP(vin5_data, 8),
> >
> > With your ack on this, I'll send v2.
>
> Thank you, that is exactly what I had in mind.
>
> > > > As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are
> > > > not
> > > > wired, I made sure the macro creates correct names and fields not only
> > > > by
> > > > compile testing it, but with a small C program [1] that replicates the
> > > > VIN data
> > > > layout defined in the PFC module and access fields (and has helped me
> > > > testing
> > > > more easily the preprocessor stringification/concatenation process).
> > > >
> > > > Final note: Simon, you took the E3 patches in your tree, and I expect
> > > > them to
> > > > land on v4.20-rc1. They use the old macros, are follow up patches ok?)
> > >
> > > Which patches are using these macro names, and are in v4.20-rc1?
> > >
> > > BTW, "grep vin._data_[a-z][0-9] drivers/pinctrl/sh-pfc/*o" tells me we
> > > already
> > > have broken groups names on r8a7792, r8a7795, and r8a7796.
> > > Fortunately we have no known users of them, so they can be fixed.
> > >
> >
> > On v4.20-rc1 the grep returns none for me :/
> > git grep v4.20-rc1 "vin._data_[a-z][0-9]" drivers/pinctrl/sh-pfc/
>
> I grepped the .o files, to make sure it would see the final strings, which
> obviously works in the build tree only ;-)
Ah yes, stupid me.
>
> For the source tree, please try:
>
> git grep -w VIN_DATA_PIN_GROUP.*_[a-z] v4.20-rc1
Argh, there are quite a few of them, but fortunately no users so far.
Is it ok fixing them in v2 of this series with follow-up patches, or
would you like a single patch that introduces the variadic macro and
replaces all the occurrences in the per-SoC PFC modules in one go?
>
> 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
signature.asc
Description: PGP signature
Re: [PATCH 0/2] pinctrl: sh-pfc: r8a77965: Add VIN4 and VIN5
Hi Jacopo,
On Tue, Nov 6, 2018 at 10:08 AM jacopo mondi wrote:
> On Mon, Nov 05, 2018 at 06:19:22PM +0100, Geert Uytterhoeven wrote:
> > On Mon, Oct 29, 2018 at 7:14 PM Jacopo Mondi
> > wrote:
> > >this two patches add supports for VIN4 and VIN5 interfaces to R-Car
> > > M3-N.
> > >
> > > On this SoC (and in the forthcoming support for E3 R8A77990) the VIN
> > > groups
> > > could appear on different sets of pins, usually the 'a' and 'b' one.
> > >
> > > With the existing VIN_DATA_PIN_GROUP macro we have to specify group names
> > > as:
> > >
> > > VIN_DATA_PIN_GROUP(vin4_data_a, 8)
> > >
> > > which results in the group being named as "vin4_data_a_8" which is
> > > un-consistent with the canonical group names (eg. "vin4_data8_a").
> > >
> > > This series adds a macro that allows to specify the group 'version' along
> > > with
> > > the pin and mux numbers in patch [1/1]. I haven't been able to find a
> > > better
> > > term than 'version' as 'group' was already taken. Suggestions welcome.
> >
> > Yeah, the datasheet also calls these groups :-(
> > A possible alternative is to use "variant"?
> >
> > Or, what about avoiding the name issue by making the VIN_DATA_PIN_GROUP()
> > macro varargs, and passing the "variant" as the (optional) third parameter?
> > That way existing users work as a before, while you can also write e.g.
> >
> > VIN_DATA_PIN_GROUP_VER(vin4_data, 8, _a),
>
> Indeed.
>
> Would something along the following lines fly for you?
>
> #define VIN_DATA_PIN_GROUP(n, s, ...) \
> { \
> .name = #n#s#__VA_ARGS__, \
> .pins = n##__VA_ARGS__##_pins.data##s, \
> .mux = n##__VA_ARGS__##_mux.data##s,\
> .nr_pins = ARRAY_SIZE(n##__VA_ARGS__##_pins.data##s), \
> }
>
> It can be used as:
> VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
> VIN_DATA_PIN_GROUP(vin5_data, 8),
>
> With your ack on this, I'll send v2.
Thank you, that is exactly what I had in mind.
> > > As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not
> > > wired, I made sure the macro creates correct names and fields not only by
> > > compile testing it, but with a small C program [1] that replicates the
> > > VIN data
> > > layout defined in the PFC module and access fields (and has helped me
> > > testing
> > > more easily the preprocessor stringification/concatenation process).
> > >
> > > Final note: Simon, you took the E3 patches in your tree, and I expect
> > > them to
> > > land on v4.20-rc1. They use the old macros, are follow up patches ok?)
> >
> > Which patches are using these macro names, and are in v4.20-rc1?
> >
> > BTW, "grep vin._data_[a-z][0-9] drivers/pinctrl/sh-pfc/*o" tells me we
> > already
> > have broken groups names on r8a7792, r8a7795, and r8a7796.
> > Fortunately we have no known users of them, so they can be fixed.
> >
>
> On v4.20-rc1 the grep returns none for me :/
> git grep v4.20-rc1 "vin._data_[a-z][0-9]" drivers/pinctrl/sh-pfc/
I grepped the .o files, to make sure it would see the final strings, which
obviously works in the build tree only ;-)
For the source tree, please try:
git grep -w VIN_DATA_PIN_GROUP.*_[a-z] v4.20-rc1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 0/2] pinctrl: sh-pfc: r8a77965: Add VIN4 and VIN5
Hi Geert,
On Mon, Nov 05, 2018 at 06:19:22PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Mon, Oct 29, 2018 at 7:14 PM Jacopo Mondi
> wrote:
> >this two patches add supports for VIN4 and VIN5 interfaces to R-Car M3-N.
> >
> > On this SoC (and in the forthcoming support for E3 R8A77990) the VIN groups
> > could appear on different sets of pins, usually the 'a' and 'b' one.
> >
> > With the existing VIN_DATA_PIN_GROUP macro we have to specify group names
> > as:
> >
> > VIN_DATA_PIN_GROUP(vin4_data_a, 8)
> >
> > which results in the group being named as "vin4_data_a_8" which is
> > un-consistent with the canonical group names (eg. "vin4_data8_a").
> >
> > This series adds a macro that allows to specify the group 'version' along
> > with
> > the pin and mux numbers in patch [1/1]. I haven't been able to find a better
> > term than 'version' as 'group' was already taken. Suggestions welcome.
>
> Yeah, the datasheet also calls these groups :-(
> A possible alternative is to use "variant"?
>
> Or, what about avoiding the name issue by making the VIN_DATA_PIN_GROUP()
> macro varargs, and passing the "variant" as the (optional) third parameter?
> That way existing users work as a before, while you can also write e.g.
>
> VIN_DATA_PIN_GROUP_VER(vin4_data, 8, _a),
Indeed.
Would something along the following lines fly for you?
#define VIN_DATA_PIN_GROUP(n, s, ...) \
{ \
.name = #n#s#__VA_ARGS__, \
.pins = n##__VA_ARGS__##_pins.data##s, \
.mux = n##__VA_ARGS__##_mux.data##s,\
.nr_pins = ARRAY_SIZE(n##__VA_ARGS__##_pins.data##s), \
}
It can be used as:
VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
VIN_DATA_PIN_GROUP(vin5_data, 8),
With your ack on this, I'll send v2.
Thanks
j
>
> > As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not
> > wired, I made sure the macro creates correct names and fields not only by
> > compile testing it, but with a small C program [1] that replicates the VIN
> > data
> > layout defined in the PFC module and access fields (and has helped me
> > testing
> > more easily the preprocessor stringification/concatenation process).
> >
> > Final note: Simon, you took the E3 patches in your tree, and I expect them
> > to
> > land on v4.20-rc1. They use the old macros, are follow up patches ok?)
>
> Which patches are using these macro names, and are in v4.20-rc1?
>
> BTW, "grep vin._data_[a-z][0-9] drivers/pinctrl/sh-pfc/*o" tells me we already
> have broken groups names on r8a7792, r8a7795, and r8a7796.
> Fortunately we have no known users of them, so they can be fixed.
>
On v4.20-rc1 the grep returns none for me :/
git grep v4.20-rc1 "vin._data_[a-z][0-9]" drivers/pinctrl/sh-pfc/
Thanks
j
> 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
signature.asc
Description: PGP signature
Re: [PATCH 2/2] arm64: dts: r8a77990: ebisu: Enable SDHI interfaces
> + sdhi3_pins: sd3 {
> + groups = "sdhi3_data8", "sdhi3_ctrl";
> + function = "sdhi3";
> + power-source = <1800>;
> + };
> +
> + sdhi3_pins_uhs: sd3_uhs {
> + groups = "sdhi3_data8", "sdhi3_ctrl";
> + function = "sdhi3";
> + power-source = <1800>;
> + };
Shouldn't we have only one pinctrl config here, like you did recently
for the other Gen3 SoCs?
signature.asc
Description: PGP signature
Re: [PATCH v4 2/6] pinctrl: sh-pfc: r8a77470: Add SDHI support
On Tue, Oct 16, 2018 at 12:33 PM Fabrizio Castro
wrote:
> Add SH_PFC_PIN_CFG_IO_VOLTAGE definition for the SDHI pins
> capable of switching voltage, also add pin groups and functions
> for SDHI0 and SDHI1. Please note that with the RZ/G1C only 1
> bit of the POC Control Register is used to control each interface.
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Biju Das
> Reviewed-by: Geert Uytterhoeven
>
> ---
> v3->v4:
> * Fixed voltage control of GP0_11 and GP0_12
Thanks, queuing in sh-pfc-for-v4.21.
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: [RFC][PATCH] PCI: Avoid PCI device removing/rescanning through sysfs triggers a deadlock
Hi Marek,
Thanks for your patch!
On Tue, Nov 6, 2018 at 12:25 AM Marek Vasut wrote:
> From: Tho Vu
>
> This patch fixes deadlock warning in removing/rescanning through sysfs
> when CONFIG_PROVE_LOCKING is enabled.
>
> The issue can be reproduced by these steps:
> 1. Enable CONFIG_PROVE_LOCKING via defconfig or menuconfig
> 2. Insert Ethernet card into PCIe CH0 and start up.
>After kernel starting up, execute the following command.
>echo 1 > /sys/class/pci_bus/\:00/device/\:00\:00.0/remove
> 3. Rescan PCI device by this command
>echo 1 > /sys/class/pci_bus/\:00/rescan
>
> The deadlock warnings will occur.
>
> WARNING: possible recursive locking detected
> 4.14.70-ltsi-yocto-standard #27 Not tainted
>
> sh/3402 is trying to acquire lock:
> (kn->count#78){}, at: kernfs_remove_by_name_ns+0x50/0xa8
>
> but task is already holding lock:
> (kn->count#78){}, at: kernfs_remove_self+0xe0/0x130
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
>CPU0
>
> lock(kn->count#78);
> lock(kn->count#78);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 4 locks held by sh/3402:
> #0: (sb_writers#4){.+.+}, at: vfs_write+0x198/0x1b0
> #1: (&of->mutex){+.+.}, at: kernfs_fop_write+0x108/0x210
> #2: (kn->count#78){}, at: kernfs_remove_self+0xe0/0x130
> #3: (pci_rescan_remove_lock){+.+.}, at: pci_lock_rescan_remove+0x1c/0x28
>
> stack backtrace:
> CPU: 3 PID: 3402 Comm: sh Not tainted 4.14.70-ltsi-yocto-standard #27
> Hardware name: Renesas Salvator-X 2nd version board based on r8a7795
> ES3.0+ with 8GiB (4 x 2 GiB) (DT)
> Call trace:
> dump_backtrace+0x0/0x3d8
> show_stack+0x14/0x20
> dump_stack+0xbc/0xf4
> __lock_acquire+0x930/0x18a8
> lock_acquire+0x48/0x68
> __kernfs_remove+0x280/0x2f8
> kernfs_remove_by_name_ns+0x50/0xa8
> remove_files.isra.0+0x38/0x78
> sysfs_remove_group+0x4c/0xa0
> sysfs_remove_groups+0x38/0x60
> device_remove_attrs+0x54/0x78
> device_del+0x1ac/0x308
> pci_remove_bus_device+0x78/0xf8
> pci_remove_bus_device+0x34/0xf8
> pci_stop_and_remove_bus_device_locked+0x24/0x38
> remove_store+0x6c/0x78
> dev_attr_store+0x18/0x28
> sysfs_kf_write+0x4c/0x78
> kernfs_fop_write+0x138/0x210
> __vfs_write+0x18/0x118
> vfs_write+0xa4/0x1b0
> SyS_write+0x48/0xb0
>
> This warning occurs due to a self-deletion attribute using in the sysfs
used
> PCI device directory. This kind of attribute is really tricky,
> it does not allow pci framework drop this attribute until all active
to drop
> .show() and .store() callbacks have finished unless
finished, unless
> sysfs_break_active_protection() is called.
> Hence this patch avoids writing into this attribute triggers a deadlock.
and trigger a deadlock.
>
> Referrence commit 5b55b24cec4c ("scsi: core: Avoid that SCSI device
> removal through sysfs triggers a deadlock")
> of scsi driver
>
> Signed-off-by: Tho Vu
You forgot to append your own SoB?
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -470,12 +470,22 @@ static ssize_t remove_store(struct device *dev, struct
> device_attribute *attr,
> const char *buf, size_t count)
> {
> unsigned long val;
> + struct kernfs_node *kn;
> +
> + kn = sysfs_break_active_protection(&dev->kobj, &attr->attr);
> + WARN_ON_ONCE(!kn);
What's the purpose of the WARN_ON_ONCE? Just copied from the SCSI solution?
Can this ever happen?
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
