Re: [PATCH] ARM: dts: r8a779[01]: Disable unconnected LVDS encoders
Hello,
On Wednesday, 17 October 2018 20:48:01 EEST Laurent Pinchart wrote:
> The LVDS0 encoder on Koelsh and Porter, and the LVDS1 encoder on Lager,
> are enabled in DT but have no device connected to their output. This
> result in spurious messages being printed to the kernel log such as
>
> rcar-du feb0.display: no connector for encoder /soc/lvds@feb9,
> skipping
>
> Fix it by disabling the encoders.
>
> Fixes: 15a1ff30d8f9 ("ARM: dts: r8a7790: Convert to new LVDS DT bindings")
> Fixes: e5c3f4707f39 ("ARM: dts: r8a7791: Convert to new LVDS DT bindings")
> Reported-by: Simon Horman
This should have read
Reported-by: Geert Uytterhoeven
Sorry for the mistake, I had read the e-mail thread containing the report
incorrectly. Simon, could you fix this when applying to your tree, or should I
send a v2 ?
> Signed-off-by: Laurent Pinchart
> ---
> arch/arm/boot/dts/r8a7790-lager.dts | 2 --
> arch/arm/boot/dts/r8a7791-koelsch.dts | 2 --
> arch/arm/boot/dts/r8a7791-porter.dts | 2 --
> 3 files changed, 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
> b/arch/arm/boot/dts/r8a7790-lager.dts index 50312e752e2f..7b9508e83d46
> 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -489,8 +489,6 @@
> };
>
> {
> - status = "okay";
> -
> ports {
> port@1 {
> lvds_connector: endpoint {
> diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
> b/arch/arm/boot/dts/r8a7791-koelsch.dts index ce22db01fbba..e6580aa0cea3
> 100644
> --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> @@ -479,8 +479,6 @@
> };
>
> {
> - status = "okay";
> -
> ports {
> port@1 {
> lvds_connector: endpoint {
> diff --git a/arch/arm/boot/dts/r8a7791-porter.dts
> b/arch/arm/boot/dts/r8a7791-porter.dts index f02036e5de01..fefdf8238bbe
> 100644
> --- a/arch/arm/boot/dts/r8a7791-porter.dts
> +++ b/arch/arm/boot/dts/r8a7791-porter.dts
> @@ -482,8 +482,6 @@
> };
>
> {
> - status = "okay";
> -
> ports {
> port@1 {
> lvds_connector: endpoint {
--
Regards,
Laurent Pinchart
[PATCH] ARM: dts: r8a779[01]: Disable unconnected LVDS encoders
The LVDS0 encoder on Koelsh and Porter, and the LVDS1 encoder on Lager,
are enabled in DT but have no device connected to their output. This
result in spurious messages being printed to the kernel log such as
rcar-du feb0.display: no connector for encoder /soc/lvds@feb9, skipping
Fix it by disabling the encoders.
Fixes: 15a1ff30d8f9 ("ARM: dts: r8a7790: Convert to new LVDS DT bindings")
Fixes: e5c3f4707f39 ("ARM: dts: r8a7791: Convert to new LVDS DT bindings")
Reported-by: Simon Horman
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7790-lager.dts | 2 --
arch/arm/boot/dts/r8a7791-koelsch.dts | 2 --
arch/arm/boot/dts/r8a7791-porter.dts | 2 --
3 files changed, 6 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index 50312e752e2f..7b9508e83d46 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -489,8 +489,6 @@
};
{
- status = "okay";
-
ports {
port@1 {
lvds_connector: endpoint {
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index ce22db01fbba..e6580aa0cea3 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -479,8 +479,6 @@
};
{
- status = "okay";
-
ports {
port@1 {
lvds_connector: endpoint {
diff --git a/arch/arm/boot/dts/r8a7791-porter.dts
b/arch/arm/boot/dts/r8a7791-porter.dts
index f02036e5de01..fefdf8238bbe 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -482,8 +482,6 @@
};
{
- status = "okay";
-
ports {
port@1 {
lvds_connector: endpoint {
--
Regards,
Laurent Pinchart
RE: Delay between stop condition and start condition
> Subject: Re: Delay between stop condition and start condition > > > > The passthrough mode is not default, it gets activated by the driver so that > > drm_get_edid can then fetch the EDID. One other nasty thing is that to end > > the conversation > > with the monitor you are supposed to write 0x00 to register 0x1a of the > > HDMI transmitter, > > which means the SoC puts address 0x39 on the bus, but the HDMI transmitter > > lets that > > through, the monitor NACKs the address (because its address is 0x50), and > > from that > > moment on the control is back with the HDMI transmitter. > > Unfortunately I don't have any other slave on the same bus, but I wonder > > what happens > > if someone else tries to use the same bus while the pass through mode is > > operating... > > Wouldn't all this really speak for an i2c gate? Do all enablement stuff > in select(), all disablement stuff in deselect(), and make sure > deselect() is called after every transfer. That would mean the > passthrough is only active when the EDID eeprom is accessed. Would that > work? Given the above, it looks quite sane to do it like that in order > to avoid side-effects of the open passthrough. It sounds like an i2c gate could fit the purpose. I'll give it a shot! Thank you All! Fab 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] dt-bindings: thermal: rcar-gen3-thermal: document R8A77980 bindings
On Tue, 9 Oct 2018 22:10:14 +0300, Sergei Shtylyov wrote: > Document the R-Car V3H (R8A77980) SoC in the Renesas R-Car gen3 thermal > bindings. > > Signed-off-by: Sergei Shtylyov > > --- > Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt |4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring
Re: Delay between stop condition and start condition
> The passthrough mode is not default, it gets activated by the driver so that > drm_get_edid can then fetch the EDID. One other nasty thing is that to end > the conversation > with the monitor you are supposed to write 0x00 to register 0x1a of the HDMI > transmitter, > which means the SoC puts address 0x39 on the bus, but the HDMI transmitter > lets that > through, the monitor NACKs the address (because its address is 0x50), and > from that > moment on the control is back with the HDMI transmitter. > Unfortunately I don't have any other slave on the same bus, but I wonder what > happens > if someone else tries to use the same bus while the pass through mode is > operating... Wouldn't all this really speak for an i2c gate? Do all enablement stuff in select(), all disablement stuff in deselect(), and make sure deselect() is called after every transfer. That would mean the passthrough is only active when the EDID eeprom is accessed. Would that work? Given the above, it looks quite sane to do it like that in order to avoid side-effects of the open passthrough. signature.asc Description: PGP signature
RE: Delay between stop condition and start condition
> Subject: Re: Delay between stop condition and start condition > > > > be fixed in its driver. It probably could be a generic driver, or? > > Wishful thinking. Setting the passthrough mode is probably not default, > so it is device specific. The passthrough mode is not default, it gets activated by the driver so that drm_get_edid can then fetch the EDID. One other nasty thing is that to end the conversation with the monitor you are supposed to write 0x00 to register 0x1a of the HDMI transmitter, which means the SoC puts address 0x39 on the bus, but the HDMI transmitter lets that through, the monitor NACKs the address (because its address is 0x50), and from that moment on the control is back with the HDMI transmitter. Unfortunately I don't have any other slave on the same bus, but I wonder what happens if someone else tries to use the same bus while the pass through mode is operating... Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
Re: Delay between stop condition and start condition
On 2018-10-17 14:16, Wolfram Sang wrote: > >> Or, add an I2C gate driver (sort of like an I2C mux with only one child >> bus) in the HDMI transmitter driver and implement the delay there. Then >> move the monitor to this new gate/mux child bus. > > That would actually be my preferred solution. Because it describes the > HW setup best. It is the passthrough creating the problem, so it should > be fixed in its driver. It probably could be a generic driver, or? Don't know about the possibility of a generic driver, but one thing to look out for is that if the "gate" is left open at all times, *other* xfers on the bus might not have the required delay between stop and start, which might lead to the monitor (or other clients on the other side of the HDMI transmitter) seeing potentially nasty things on the distorted bus... Cheers, Peter
Re: Delay between stop condition and start condition
Hi Wolfram,
On Wed, Oct 17, 2018 at 2:21 PM Wolfram Sang wrote:
> > be fixed in its driver. It probably could be a generic driver, or?
>
> Wishful thinking. Setting the passthrough mode is probably not default,
> so it is device specific.
According to the block diagram in
https://www.semiconductorstore.com/pdf/newsite/siliconimage/SiI9022a_pb.pdf,
it has "Registers & Config Logic", and a separate internal "I²C Master".
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: Delay between stop condition and start condition
> be fixed in its driver. It probably could be a generic driver, or? Wishful thinking. Setting the passthrough mode is probably not default, so it is device specific. signature.asc Description: PGP signature
Re: Delay between stop condition and start condition
> Or, add an I2C gate driver (sort of like an I2C mux with only one child > bus) in the HDMI transmitter driver and implement the delay there. Then > move the monitor to this new gate/mux child bus. That would actually be my preferred solution. Because it describes the HW setup best. It is the passthrough creating the problem, so it should be fixed in its driver. It probably could be a generic driver, or? signature.asc Description: PGP signature
Re: [PATCH/RFC v2] serial: sh-sci: Fix fallback to PIO on DMA failure
On Tue, Oct 16, 2018 at 3:24 PM Geert Uytterhoeven
wrote:
> When submitting a DMA request fails, the driver is supposed to fall back
> to PIO. However, this never really worked due to various reasons
> (sh-sci driver issues and dmaengine framework limitations).
>
> There are three places where DMA submission can fail, and the driver
> should fall back to PIO:
> 1. sci_dma_rx_complete(),
> 2. sci_submit_rx(),
> 3. work_fn_tx().
>
> This RFC fixes fallback to PIO in the receive path (cases 1 and 2).
> Fallback to PIO in the transmit path (case 3) already works fine.
>
> Case 1: sci_dma_rx_complete()
>
> A. PIO cannot take over on SCIF if any DMA transactions are pending,
> hence they must be terminated first.
>
> B. The active cookies must be invalidated, else rx_timer_fn() may
> trigger a NULL pointer dereference.
>
> C. Restarting the port is not needed, as it is already running, but
> serial port interrupts must be directed back from the DMA engine to
> the CPU.
>
> Case 2: sci_submit_rx()
>
> D. Some callers of sci_submit_rx() hold the port spinlock, others
> don't. During fallback to PIO, the driver needs to obtain the port
> spinlock. If the lock was already held, spinlock recursion is
> detected, causing a deadlock: BUG: spinlock recursion on CPU#0.
>
> Fix this by adding a flag parameter to sci_submit_rx() for the
> caller to indicate the port spinlock is already held, so spinlock
> recursion can be avoided.
>
> Move the spin_lock_irqsave() up, so all DMA disable steps are
> protected, which is safe as the recently introduced
> dmaengine_terminate_async() can be called in atomic context.
>
> E. When falling back to PIO, active_rx must be set to a different
> value than cookie_rx[i], else sci_dma_rx_find_active() will
> incorrectly find a match, leading to a NULL pointer dereference in
> rx_timer_fn() later.
>
> F. On (H)SCIF, sci_submit_rx() is called in the receive interrupt
> handler. Hence if DMA submission fails, the interrupt handler
> should handle reception using PIO.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Against tty/next + "serial: sh-sci: Fix receive on SCIFA/SCIFB variants
> with DMA".
>
> All testing was done on r8a7791/koelsch using SCIF1 on debug serial 1,
> and SCIFA3 on EXIO-B, by introducing random failures in DMA submission
> code.
>
> Thanks for your comments!
>
> v2:
> - Fix fallback in sci_dma_rx_complete(),
> - Fallback in the transmit path already works fine,
> - Widen audience, but keep RFC.
> ---
> drivers/tty/serial/sh-sci.c | 34 +-
> 1 file changed, 25 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index 3aad48e64b9b71ff..30b2728c20d6e982 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -1272,6 +1272,7 @@ static void sci_dma_rx_complete(void *arg)
> struct dma_async_tx_descriptor *desc;
> unsigned long flags;
> int active, count = 0;
> + unsigned int i;
Oops, there's a "u16 scr;" missing here.
>
> dev_dbg(port->dev, "%s(%d) active cookie %d\n", __func__, port->line,
> s->active_rx);
> @@ -1309,12 +1310,22 @@ static void sci_dma_rx_complete(void *arg)
> return;
>
> fail:
> + dmaengine_terminate_async(chan);
> spin_unlock_irqrestore(>lock, flags);
> dev_warn(port->dev, "Failed submitting Rx DMA descriptor\n");
> /* Switch to PIO */
> spin_lock_irqsave(>lock, flags);
> + for (i = 0; i < 2; i++)
> + s->cookie_rx[i] = -EINVAL;
> + s->active_rx = 0;
> s->chan_rx = NULL;
> - sci_start_rx(port);
> + /* Direct new serial port interrupts back to CPU */
> + scr = serial_port_in(port, SCSCR);
> + if (port->type == PORT_SCIFA || port->type == PORT_SCIFB) {
> + scr &= ~SCSCR_RDRQE;
> + enable_irq(s->irqs[SCIx_RXI_IRQ]);
> + }
> + serial_port_out(port, SCSCR, scr | SCSCR_RIE);
> spin_unlock_irqrestore(>lock, flags);
> }
>
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: Delay between stop condition and start condition
On 2018-10-17 12:32, Wolfram Sang wrote: > Hi Fabrizio, everyone, > > Thanks for bringing this up! > >> What's the best way to address this? I could pull in the HDMI >> transmitter driver the code to read the EDID back from the monitor so >> that I can fit device specific delays without impacting the generic >> implementation of the EDID readback, but that would replicate some >> code and the driver would not benefit from fixes made to the generic >> implementation. I could change the RCar I2C driver in order to fit a >> new DT parameter (i2c-delay-after-stop-us?), and the driver would put >> in the desired delay after every stop condition, but isn't this >> parameter something every I2C controller would benefit from (now that >> we know we have a use case for it)? What are your thoughts and >> recommendations? > > No need for a property. The I2C standard has a clearly defined value for > that which is named 'tbuf' and is in general the same value as the > minimal low period of the SCL signal. So, it must be handled at the I2C > bus master level. > > Currently, we have no rule at what time drivers have to leave the > master_xfer() callback. Some exit when STOP is still processed, some > when STOP has been sent. I am not aware of a driver respecting tbuf. It > seems worth recommending to respect tbuf. > > I think this needs to be completely handled in the bus master driver. We > have USB-to-I2C bridges which we can control only high level and the > firmware of those need to respect tbuf. I don't see how the I2C core > could support individual drivers here. > > So, that's how I see this situation. Other comments? Other ideas? From the looks of the picture, it seems that the SoC does respect 'tbuf', but that the DDC pass-through in the HDMI transmitter then destroys the signals such that the monitor has no chance to interpret stuff correctly. Since this is not related to the specific bus driver in use, and since it would be ugly to add some hook that the HDMI transmitter driver could use, methinks that a sane way to describe that the bus driver needs to slow down is to add some DT property that makes the I2C core apply a quirk and thus force some minimum time between stop and start. Just like Fabrizio suggested... Either that, or add some hook in the generic edid reader code, so that it can slow down on request. Or, add an I2C gate driver (sort of like an I2C mux with only one child bus) in the HDMI transmitter driver and implement the delay there. Then move the monitor to this new gate/mux child bus. Cheers, Peter
RE: Delay between stop condition and start condition
Hello Wolfram, Thank you so much for your feedback! > Subject: Re: Delay between stop condition and start condition > > Hi Fabrizio, everyone, > > Thanks for bringing this up! > > > What's the best way to address this? I could pull in the HDMI > > transmitter driver the code to read the EDID back from the monitor so > > that I can fit device specific delays without impacting the generic > > implementation of the EDID readback, but that would replicate some > > code and the driver would not benefit from fixes made to the generic > > implementation. I could change the RCar I2C driver in order to fit a > > new DT parameter (i2c-delay-after-stop-us?), and the driver would put > > in the desired delay after every stop condition, but isn't this > > parameter something every I2C controller would benefit from (now that > > we know we have a use case for it)? What are your thoughts and > > recommendations? > > No need for a property. The I2C standard has a clearly defined value for > that which is named 'tbuf' and is in general the same value as the > minimal low period of the SCL signal. So, it must be handled at the I2C > bus master level. > > Currently, we have no rule at what time drivers have to leave the > master_xfer() callback. Some exit when STOP is still processed, some > when STOP has been sent. I am not aware of a driver respecting tbuf. It > seems worth recommending to respect tbuf. > > I think this needs to be completely handled in the bus master driver. We > have USB-to-I2C bridges which we can control only high level and the > firmware of those need to respect tbuf. I don't see how the I2C core > could support individual drivers here. > > So, that's how I see this situation. Other comments? Other ideas? My understanding is that when this HDMI transmitter is configured in pass through mode then a bigger 'tbuf' is required. The I2C spec (v2.1) says that in "standard mode" tbuf>=4.7us" and in fast-mode "tbuf>=1.3us", in this particular case the 20us of bus free time between the STOP and START conditions you find in the trace are not enough. This device seems to require an out of spec solution (an hack..), what's the most acceptable solution from an upstreaming perspective? Other platforms may want to use the same HDMI transmitter in their solutions and may stumble across the same problem if the platform is quick enough. I may just put this delay in the driver and call it a day by wrapping writes/reads/modifies and stuff? What do you think? Thanks, Fab > > Thanks, > >Wolfram Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
Re: Delay between stop condition and start condition
Hi Fabrizio, everyone, Thanks for bringing this up! > What's the best way to address this? I could pull in the HDMI > transmitter driver the code to read the EDID back from the monitor so > that I can fit device specific delays without impacting the generic > implementation of the EDID readback, but that would replicate some > code and the driver would not benefit from fixes made to the generic > implementation. I could change the RCar I2C driver in order to fit a > new DT parameter (i2c-delay-after-stop-us?), and the driver would put > in the desired delay after every stop condition, but isn't this > parameter something every I2C controller would benefit from (now that > we know we have a use case for it)? What are your thoughts and > recommendations? No need for a property. The I2C standard has a clearly defined value for that which is named 'tbuf' and is in general the same value as the minimal low period of the SCL signal. So, it must be handled at the I2C bus master level. Currently, we have no rule at what time drivers have to leave the master_xfer() callback. Some exit when STOP is still processed, some when STOP has been sent. I am not aware of a driver respecting tbuf. It seems worth recommending to respect tbuf. I think this needs to be completely handled in the bus master driver. We have USB-to-I2C bridges which we can control only high level and the firmware of those need to respect tbuf. I don't see how the I2C core could support individual drivers here. So, that's how I see this situation. Other comments? Other ideas? Thanks, Wolfram
[PATCH] arm64: defconfig: Enable R-Car thermal driver
Enable the R-Car thermal driver as a module. This driver is used in conjunction with the R-Car V3M (r8a77970), E3 (r8a77990) and D3 (r8a77995) SoCs. Signed-off-by: Simon Horman --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index e6ec9858d33d..205d212eac58 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -365,6 +365,7 @@ CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y CONFIG_CPU_THERMAL=y CONFIG_THERMAL_EMULATION=y CONFIG_ROCKCHIP_THERMAL=m +CONFIG_RCAR_THERMAL=m CONFIG_RCAR_GEN3_THERMAL=y CONFIG_ARMADA_THERMAL=y CONFIG_BRCMSTB_THERMAL=m -- 2.11.0
[PATCH] arm64: renesas_defconfig: Enable R-Car thermal driver
Enable the R-Car thermal driver. This driver is used in conjunction with the R-Car V3M (r8a77970), E3 (r8a77990) and D3 (r8a77995) SoCs. Signed-off-by: Simon Horman --- N.B: This is targeted at the devel branch of the renesas tree but not upstream where renesas_defconfig does not currently exist --- arch/arm64/configs/renesas_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/renesas_defconfig b/arch/arm64/configs/renesas_defconfig index f8fca4a777da..b7298a389568 100644 --- a/arch/arm64/configs/renesas_defconfig +++ b/arch/arm64/configs/renesas_defconfig @@ -154,6 +154,7 @@ CONFIG_THERMAL=y CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y CONFIG_CPU_THERMAL=y CONFIG_THERMAL_EMULATION=y +CONFIG_RCAR_THERMAL=y CONFIG_RCAR_GEN3_THERMAL=y CONFIG_WATCHDOG=y CONFIG_RENESAS_WDT=y -- 2.11.0
Re: [PATCH 1/2] [RFC] arm64: renesas: Move SoC Kconfig symbols to drivers/soc/renesas/
On Wed, Oct 17, 2018 at 11:56:43AM +0200, Geert Uytterhoeven wrote: > Hi Simon, > > On Mon, Oct 15, 2018 at 5:40 PM Simon Horman wrote: > > On Thu, Oct 11, 2018 at 03:54:55PM +0200, Simon Horman wrote: > > > On Thu, Oct 11, 2018 at 10:55:07AM +0200, Geert Uytterhoeven wrote: > > > > For consistency with other vendors, which have a single Kconfig symbol > > > > in arch/arm64/Kconfig.platforms. > > > > > > > > Signed-off-by: Geert Uytterhoeven > > > > --- > > > > Note that drivers/clk/ is included before drivers/soc/. Hence when > > > > COMPILE_TEST=y, questions will be asked about clock drivers before they > > > > can be auto-selected by SoC support. > > > > > > > > Question: Should we introduce a family-specific Kconfig symbol for R-Car > > > > Gen3 (ARCH_RCAR_GEN1), which could be used for enabling > > > > > > s/1/3/? > > Sure. > > > > > > > > > RST_RCAR? > > > > > > Given that it would be consistent with R-Car Gen 1 and 2, > > > that seems like a good idea to me. > > > > there has been no other feedback on this series. > > How would you like to proceed? > > I will add a new symbol ARCH_RCAR_GEN3 for v2? Good plan. > Any comments about PATCH 2/2? Thanks, I have now commented.
Re: [PATCH 2/2] [RFC] ARM: shmobile: Move SoC Kconfig symbols to drivers/soc/renesas/
On Thu, Oct 11, 2018 at 10:55:08AM +0200, Geert Uytterhoeven wrote: > For consistency with arm64, where vendors have a single Kconfig symbol > in arch/arm64/Kconfig.platforms. > > Signed-off-by: Geert Uytterhoeven > --- > Note that drivers/clk/ is included before drivers/soc/. Hence when > COMPILE_TEST=y, questions will be asked about clock drivers before they > can be auto-selected by SoC support. > > Question: Should the family-specific Kconfig symbols be moved, too? > Not much would be left in arch/arm/mach-shmobile/Kconfig, > though. I have no strong opinion either way. But I lean slightly towards moving the family-specific symbols along with the SoC-specific symbols. > --- > arch/arm/mach-shmobile/Kconfig | 101 --- > drivers/soc/renesas/Kconfig| 120 ++--- > 2 files changed, 112 insertions(+), 109 deletions(-) > > diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig > index b100c26a858f9015..50267ad76f990f11 100644 > --- a/arch/arm/mach-shmobile/Kconfig > +++ b/arch/arm/mach-shmobile/Kconfig > @@ -36,104 +36,3 @@ menuconfig ARCH_RENESAS > select PINCTRL > select SOC_BUS > select ZONE_DMA if ARM_LPAE > - > -if ARCH_RENESAS > - > -#comment "Renesas ARM SoCs System Type" > - > -config ARCH_EMEV2 > - bool "Emma Mobile EV2" > - select SYS_SUPPORTS_EM_STI > - > -config ARCH_R7S72100 > - bool "RZ/A1H (R7S72100)" > - select PM > - select PM_GENERIC_DOMAINS > - select SYS_SUPPORTS_SH_MTU2 > - select RENESAS_OSTM > - > -config ARCH_R7S9210 > - bool "RZ/A2 (R7S9210)" > - select PM > - select PM_GENERIC_DOMAINS > - select RENESAS_OSTM > - > -config ARCH_R8A73A4 > - bool "R-Mobile APE6 (R8A73A40)" > - select ARCH_RMOBILE > - select ARM_ERRATA_798181 if SMP > - select HAVE_ARM_ARCH_TIMER > - select RENESAS_IRQC > - > -config ARCH_R8A7740 > - bool "R-Mobile A1 (R8A77400)" > - select ARCH_RMOBILE > - select RENESAS_INTC_IRQPIN > - > -config ARCH_R8A7743 > - bool "RZ/G1M (R8A77430)" > - select ARCH_RCAR_GEN2 > - select ARM_ERRATA_798181 if SMP > - > -config ARCH_R8A7744 > - bool "RZ/G1N (R8A77440)" > - select ARCH_RCAR_GEN2 > - select ARM_ERRATA_798181 if SMP > - > -config ARCH_R8A7745 > - bool "RZ/G1E (R8A77450)" > - select ARCH_RCAR_GEN2 > - > -config ARCH_R8A77470 > - bool "RZ/G1C (R8A77470)" > - select ARCH_RCAR_GEN2 > - > -config ARCH_R8A7778 > - bool "R-Car M1A (R8A77781)" > - select ARCH_RCAR_GEN1 > - > -config ARCH_R8A7779 > - bool "R-Car H1 (R8A77790)" > - select ARCH_RCAR_GEN1 > - > -config ARCH_R8A7790 > - bool "R-Car H2 (R8A77900)" > - select ARCH_RCAR_GEN2 > - select ARM_ERRATA_798181 if SMP > - select I2C > - > -config ARCH_R8A7791 > - bool "R-Car M2-W (R8A77910)" > - select ARCH_RCAR_GEN2 > - select ARM_ERRATA_798181 if SMP > - select I2C > - > -config ARCH_R8A7792 > - bool "R-Car V2H (R8A77920)" > - select ARCH_RCAR_GEN2 > - select ARM_ERRATA_798181 if SMP > - > -config ARCH_R8A7793 > - bool "R-Car M2-N (R8A7793)" > - select ARCH_RCAR_GEN2 > - select ARM_ERRATA_798181 if SMP > - select I2C > - > -config ARCH_R8A7794 > - bool "R-Car E2 (R8A77940)" > - select ARCH_RCAR_GEN2 > - > -config ARCH_R9A06G032 > - bool "RZ/N1D (R9A06G032)" > - select ARCH_RZN1 > - > -config ARCH_RZN1 > - bool "RZ/N1 (R9A06G0xx) Family" > - select ARM_AMBA > - select CPU_V7 > - > -config ARCH_SH73A0 > - bool "SH-Mobile AG5 (R8A73A00)" > - select ARCH_RMOBILE > - select RENESAS_INTC_IRQPIN > -endif > diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig > index 0ab62024fd20be56..5089c65b544909c2 100644 > --- a/drivers/soc/renesas/Kconfig > +++ b/drivers/soc/renesas/Kconfig > @@ -4,17 +4,121 @@ config SOC_RENESAS > default y if ARCH_RENESAS > select SOC_BUS > select RST_RCAR if ARCH_RCAR_GEN1 || ARCH_RCAR_GEN2 > - select SYSC_R8A7743 if ARCH_R8A7743 || ARCH_R8A7744 > - select SYSC_R8A7745 if ARCH_R8A7745 > - select SYSC_R8A77470 if ARCH_R8A77470 > - select SYSC_R8A7779 if ARCH_R8A7779 > - select SYSC_R8A7790 if ARCH_R8A7790 > - select SYSC_R8A7791 if ARCH_R8A7791 || ARCH_R8A7793 > - select SYSC_R8A7792 if ARCH_R8A7792 > - select SYSC_R8A7794 if ARCH_R8A7794 > > if SOC_RENESAS > > +if ARM > + > +#comment "Renesas ARM SoCs System Type" > + > +config ARCH_EMEV2 > + bool "Emma Mobile EV2" > + select SYS_SUPPORTS_EM_STI > + > +config ARCH_R7S72100 > + bool "RZ/A1H (R7S72100)" > + select PM > + select PM_GENERIC_DOMAINS > + select SYS_SUPPORTS_SH_MTU2 > + select RENESAS_OSTM > + > +config ARCH_R7S9210 > + bool "RZ/A2 (R7S9210)" > + select PM > + select PM_GENERIC_DOMAINS > + select RENESAS_OSTM > + > +config ARCH_R8A73A4 > + bool "R-Mobile APE6 (R8A73A40)" > + select
Re: [PATCH/RFT] arm64: dts: renesas: r8a77990: add thermal device support
On Mon, Oct 15, 2018 at 11:12:26PM +0900, Yoshihiro Kaneko wrote: > This patch adds the thermal device node and the thermal-zone for > the R8A77990 SoC. > > Signed-off-by: Yoshihiro Kaneko Thanks, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman Also tested on Ebisu/E3 in conjunction with "[PATCH/RFT 0/2] thermal: add suport for R8A77990" # X=100; while [ "$X" -gt 0 ]; do X=$(($X -1 )); done; cat # /sys/devices/virtual/thermal/thermal_zone0/temp; sleep 1; cat # /sys/devices/virtual/thermal/thermal_zone0/temp 3 25000 Tested-by: Simon Horman
Re: [PATCH 1/2] [RFC] arm64: renesas: Move SoC Kconfig symbols to drivers/soc/renesas/
Hi Simon,
On Mon, Oct 15, 2018 at 5:40 PM Simon Horman wrote:
> On Thu, Oct 11, 2018 at 03:54:55PM +0200, Simon Horman wrote:
> > On Thu, Oct 11, 2018 at 10:55:07AM +0200, Geert Uytterhoeven wrote:
> > > For consistency with other vendors, which have a single Kconfig symbol
> > > in arch/arm64/Kconfig.platforms.
> > >
> > > Signed-off-by: Geert Uytterhoeven
> > > ---
> > > Note that drivers/clk/ is included before drivers/soc/. Hence when
> > > COMPILE_TEST=y, questions will be asked about clock drivers before they
> > > can be auto-selected by SoC support.
> > >
> > > Question: Should we introduce a family-specific Kconfig symbol for R-Car
> > > Gen3 (ARCH_RCAR_GEN1), which could be used for enabling
> >
> > s/1/3/?
Sure.
> > >
> > > RST_RCAR?
> >
> > Given that it would be consistent with R-Car Gen 1 and 2,
> > that seems like a good idea to me.
>
> there has been no other feedback on this series.
> How would you like to proceed?
I will add a new symbol ARCH_RCAR_GEN3 for v2?
Any comments about PATCH 2/2?
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/RFT 0/2] thermal: add suport for R8A77990
On Mon, Oct 15, 2018 at 11:11:57PM +0900, Yoshihiro Kaneko wrote: > This series adds thermal support for R-Car E3 (R8A77990). > > This series is based on the next branch of Eduardo Valentin's > linux-soc-thermal > tree. > > Yoshihiro Kaneko (2): > dt-bindings: thermal: rcar-thermal: add R8A77990 support > thermal: rcar_thermal: add R8A77990 support Tested in conjunction with "[PATCH/RFT] arm64: dts: renesas: r8a77990: add thermal device support". # X=100; while [ "$X" -gt 0 ]; do X=$(($X -1 )); done; cat # /sys/devices/virtual/thermal/thermal_zone0/temp; sleep 1; cat # /sys/devices/virtual/thermal/thermal_zone0/temp 3 25000 Reviewed-by: Simon Horman Tested-by: Simon Horman > > Documentation/devicetree/bindings/thermal/rcar-thermal.txt | 5 +++-- > drivers/thermal/rcar_thermal.c | 4 > 2 files changed, 7 insertions(+), 2 deletions(-) > > -- > 1.9.1 >
Re: [PATCH] arm64: dts: renesas: revise hsusb's reg size
Hi Simon,
On Wed, Oct 17, 2018 at 10:57 AM Simon Horman wrote:
> On Tue, Oct 16, 2018 at 03:04:50PM +0900, Yoshihiro Shimoda wrote:
> > This patch revises the reg size of each hsusb device node for
> > r8a7795, r8a7796 and r8a77965.
> >
> > Reported-by: Biju Das
> > Fixes: d2422e108812 ("arm64: dts: r8a7795: Add HSUSB device node")
> > Fixes: 4725f2b88057 ("arm64: dts: renesas: r8a7795: add hsusb ch3 device
> > node")
> > Fixes: b9535853777f ("arm64: dts: r8a7796: Add HSUSB device node")
> > Fixes: 9e1b00a2ef43 ("arm64: dts: renesas: r8a77965: Add "reg" properties")
> > Signed-off-by: Yoshihiro Shimoda
>
> Thanks Shimoda-san,
>
> This looks fine to me but I will wait to see if there are other reviews
> before applying.
>
> Reviewed-by: Simon Horman
>
>
> Also, could you let me know if this has any run-time effect?
> If so perhaps it should be treated as a fix for v4.20 rather than
> a patch for v4.21.
Probably not, as mapping granularity is PAGE_SIZE (> 0x200) anyway.
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] dt-bindings: PCI: rcar: Add device tree support for r8a7744
On Fri, Oct 12, 2018 at 05:04:08PM +0100, Lorenzo Pieralisi wrote: > On Mon, Oct 08, 2018 at 09:34:45AM +0200, Simon Horman wrote: > > On Thu, Oct 04, 2018 at 05:07:47PM +0100, Biju Das wrote: > > > Add support for r8a7744. The Renesas RZ/G1N (R8A7744) PCIe controller > > > is identical to the R-Car Gen2 family. > > > > > > Signed-off-by: Biju Das > > > Reviewed-by: Chris Paterson > > > > Reviewed-by: Simon Horman > > Simon, Biju, > > I pulled the same binding for rcar2, I would pull this in the PCI tree > too unless you object, please let me know. No objection.
Re: [PATCH RESEND] ARM: dma-mapping: update comment about handling dma_ops when detaching from IOMMU
On Mon, Oct 15, 2018 at 12:55:17PM +0200, Wolfram Sang wrote:
> Update the comment because we don't set the pointer to NULL anymore.
> Also use the correct pointer name 'dma_ops' instead of 'dma_map_ops'.
>
> Fixes: 1874619a7df4 ("ARM: dma-mapping: Set proper DMA ops in
> arm_iommu_detach_device()")
> Signed-off-by: Wolfram Sang
> Reviewed-by: Geert Uytterhoeven
Reviewed-by: Simon Horman
> ---
> arch/arm/mm/dma-mapping.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 66566472c153..e3b04786838f 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -2287,7 +2287,7 @@ EXPORT_SYMBOL_GPL(arm_iommu_attach_device);
> * @dev: valid struct device pointer
> *
> * Detaches the provided device from a previously attached map.
> - * This voids the dma operations (dma_map_ops pointer)
> + * This overwrites the dma_ops pointer with appropriate non-IOMMU ops.
> */
> void arm_iommu_detach_device(struct device *dev)
> {
> --
> 2.11.0
>
RE: [PATCH] arm64: dts: renesas: revise hsusb's reg size
Hi Shimoda-San,
Thanks for the patch.
> -Original Message-
> From: linux-renesas-soc-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Yoshihiro Shimoda
> Sent: 16 October 2018 07:05
> To: ho...@verge.net.au; magnus.d...@gmail.com
> Cc: linux-renesas-soc@vger.kernel.org; Yoshihiro Shimoda
>
> Subject: [PATCH] arm64: dts: renesas: revise hsusb's reg size
>
> This patch revises the reg size of each hsusb device node for r8a7795, r8a7796
> and r8a77965.
>
> Reported-by: Biju Das
> Fixes: d2422e108812 ("arm64: dts: r8a7795: Add HSUSB device node")
> Fixes: 4725f2b88057 ("arm64: dts: renesas: r8a7795: add hsusb ch3 device
> node")
> Fixes: b9535853777f ("arm64: dts: r8a7796: Add HSUSB device node")
> Fixes: 9e1b00a2ef43 ("arm64: dts: renesas: r8a77965: Add "reg" properties")
> Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Biju Das
Regards,
Biju
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH v4 2/6] pinctrl: sh-pfc: r8a77470: Add SDHI support
Hello Simon,
Thank you for your feedback.
> >
> > +static int r8a77470_pin_to_pocctrl(struct sh_pfc *pfc, unsigned int pin,
> > + u32 *pocctrl)
> > +{
> > +int bit = -EINVAL;
> > +
> > +*pocctrl = 0xe60600b0;
> > +
> > +if (pin >= RCAR_GP_PIN(0, 5) && pin <= RCAR_GP_PIN(0, 10))
> > +bit = 0;
>
> Is it intentional that the range above excludes GP0_11 and 12?
Yes, it is, GPO_11 and GPO_12 can't be voltage controlled, they only work at
3.3V
>
> > +
> > +if (pin >= RCAR_GP_PIN(0, 13) && pin <= RCAR_GP_PIN(0, 22))
> > +bit = 2;
> > +
> > +if (pin >= RCAR_GP_PIN(4, 14) && pin <= RCAR_GP_PIN(4, 19))
>
> And likewise GP4_20 and 21 here.
Same thing here, GP4_20 and GP4_21 can't be voltage controlled, they only work
at 3.3V
Thanks, Fab
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
Re: [PATCH v2 3/3] thermal: da9062/61: Prevent hardware access during system suspend
Hi Steve,
On Wed, Oct 17, 2018 at 10:57 AM Steve Twiss
wrote:
> On 12 October 2018 08:20 Geert Uytterhoeven wrote:
> > Subject: [PATCH v2 3/3] thermal: da9062/61: Prevent hardware access during
> > system suspend
> >
> > The workqueue used for monitoring the hardware may run while the device
> > is already suspended. Fix this by using the freezable system workqueue
> > instead, cfr. commit 51e20d0e3a60cf46 ("thermal: Prevent polling from
> > happening during system suspend").
>
> My thinking was: this device is a PMIC and it will power the system. So when
> the device is turned off, the S/W will also not be running.
>
> Although my assumption only works if the PMIC device is the primary system
> power -- this has always been the case so far. And although I don't have any
> evidence this will change, it may become untrue in the future of course.
This is not about powering off the system, but about suspending the system,
which suspends all drivers.
The issue is that the normal workqueue may run while the system is being
suspended. Accessing the DA9062 may or may not work at that time,
depending on the i2c controller being usable or not.
Due to the DA9062 being an i2c device, I agree this is different than
for rcar-thermal, where the rcar-thermal device itself cannot be
accessed because it is suspended.
> > Fixes: 608567aac3206ae8 ("thermal: da9062/61: Thermal junction temperature
> > monitoring driver")
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > Untested due to lack of hardware.
>
> So, I have not been able to make any time to test this patch yet -- and with
> current workloads this might take a bit of time before I get to it.
The main thing to test is what happens when da9062_thermal_poll_on() is
called while the i2c controller is already suspended, and whether that
is mitigated by my patch.
Looking at the function, I guess it starts spewing error messages, and
will continue triggering itself, by virtue of enabling the interrupt again,
without having been able to disable its cause.
> > --- a/drivers/thermal/da9062-thermal.c
> > +++ b/drivers/thermal/da9062-thermal.c
> > @@ -106,7 +106,7 @@ static void da9062_thermal_poll_on(struct work_struct
> > *work)
> > THERMAL_EVENT_UNSPECIFIED);
> >
> > delay = msecs_to_jiffies(thermal->zone->passive_delay);
> > - schedule_delayed_work(>work, delay);
> > + queue_delayed_work(system_freezable_wq, >work,
> > delay);
> > return;
> > }
> >
> > @@ -125,7 +125,7 @@ static irqreturn_t da9062_thermal_irq_handler(int irq,
> > void *data)
> > struct da9062_thermal *thermal = data;
> >
> > disable_irq_nosync(thermal->irq);
> > - schedule_delayed_work(>work, 0);
> > + queue_delayed_work(system_freezable_wq, >work, 0);
> >
> > return IRQ_HANDLED;
> > }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] arm64: dts: renesas: revise hsusb's reg size
On Tue, Oct 16, 2018 at 03:04:50PM +0900, Yoshihiro Shimoda wrote:
> This patch revises the reg size of each hsusb device node for
> r8a7795, r8a7796 and r8a77965.
>
> Reported-by: Biju Das
> Fixes: d2422e108812 ("arm64: dts: r8a7795: Add HSUSB device node")
> Fixes: 4725f2b88057 ("arm64: dts: renesas: r8a7795: add hsusb ch3 device
> node")
> Fixes: b9535853777f ("arm64: dts: r8a7796: Add HSUSB device node")
> Fixes: 9e1b00a2ef43 ("arm64: dts: renesas: r8a77965: Add "reg" properties")
> Signed-off-by: Yoshihiro Shimoda
Thanks Shimoda-san,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Reviewed-by: Simon Horman
Also, could you let me know if this has any run-time effect?
If so perhaps it should be treated as a fix for v4.20 rather than
a patch for v4.21.
Re: [PATCH v2] arm64: dts: renesas: add/enable USB2.0 peripheral for R-Car [DE]3
On Tue, Oct 16, 2018 at 03:05:09PM +0900, Yoshihiro Shimoda wrote: > This patch adds/enables USB2.0 peripheral for R-Car [DE]3 boards. > So, the default mode on each board is: > - R-Car D3 Draak board (has a type-A connector) = host. > - R-Car E3 Ebisu board (has a type-B micro connector) = peripheral. > > Signed-off-by: Yoshihiro Shimoda Thanks Shimoda-san, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH] arm64: dts: renesas: r8a779{7|8}0: add MSIOF support
Hi Simon,
On Wed, Oct 17, 2018 at 10:13 AM Simon Horman wrote:
> On Tue, Oct 16, 2018 at 10:36:33PM +0300, Sergei Shtylyov wrote:
> > Describe MSIOF in the R8A779{7|8}0 device trees.
> >
> > The DMA props are deliberately omitted as the MSIOF DMA doesn't work on
> > R8A77970 (due to IPMMU issue) and the RT-DMAC isn't supported on R8A77980.
>
> For the record: In the short term I'm fine with not enabling DMA if there
> are known problems. But in the long term we should describe DMA in DT as
> the purpose of DT is to describe hardware rather than software.
>
> So please, as follow-up work, lets work towards a solution that allows us
> to describe the hardware in DT.
>
> > Signed-off-by: Sergei Shtylyov
> >
> > ---
> > This patch is against the 'renesas-devel-20181015-v4.19-rc8' branch of
> > Simon Horman's 'renesas.git' repo.
> >
> > The MSIOF bindings patch has just been posted...
> >
> > arch/arm64/boot/dts/renesas/r8a77970.dtsi | 56
> > ++
> > arch/arm64/boot/dts/renesas/r8a77980.dtsi | 56
> > ++
> > 2 files changed, 112 insertions(+)
> >
> > Index: renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> > ===
> > --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> > +++ renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> > @@ -22,6 +22,10 @@
> > i2c2 =
> > i2c3 =
> > i2c4 =
> > + spi1 =
> > + spi2 =
> > + spi3 =
> > + spi4 =
>
> Geert, could you comment on these aliases and the similar ones below?
> I'm not seeing them for any other ARM64-based Renesas SoCs.
I2c and spi aliases are "used, but not recommended", cfr.
https://lore.kernel.org/lkml/20181015180046.GA18294@bogus/
Personally (but I'm biased, referring to an email thread I participated in ;-),
I'd only leave serial0 (+ perhaps a 2nd/3th serial port) and ethernet0.
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 v4 2/6] pinctrl: sh-pfc: r8a77470: Add SDHI support
On Tue, Oct 16, 2018 at 11:33:43AM +0100, 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
>
> v2->v3:
> * No change
>
> v1->v2:
> * Reworked implementation of r8a77470_pin_to_pocctrl as per Wolfram's
> and Geert's comments
> * Added SDHI0 and SDHI1 pins and IO voltage control
> * Added SDHI0 and SDHI1 pin groups and functions
> * Reworked changelog and title
> * Please note that there is some overlapping between mmc pin groups
> and sdhi1 pin groups
> ---
> drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 162
> +-
> 1 file changed, 160 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
> b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
> index 5e29b95..4359aeb 100644
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
> @@ -10,14 +10,45 @@
> #include "sh_pfc.h"
>
> #define CPU_ALL_PORT(fn, sfx)
> \
> - PORT_GP_23(0, fn, sfx), \
> + PORT_GP_4(0, fn, sfx), \
> + PORT_GP_1(0, 4, fn, sfx), \
> + PORT_GP_CFG_1(0, 5, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(0, 6, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(0, 7, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(0, 8, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(0, 9, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(0, 10, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_1(0, 11, fn, sfx), \
> + PORT_GP_1(0, 12, fn, sfx), \
> + PORT_GP_CFG_1(0, 13, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(0, 14, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(0, 15, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(0, 16, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(0, 17, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(0, 18, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(0, 19, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(0, 20, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(0, 21, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(0, 22, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> PORT_GP_23(1, fn, sfx), \
> PORT_GP_32(2, fn, sfx), \
> PORT_GP_17(3, fn, sfx), \
> PORT_GP_1(3, 27, fn, sfx), \
> PORT_GP_1(3, 28, fn, sfx), \
> PORT_GP_1(3, 29, fn, sfx), \
> - PORT_GP_26(4, fn, sfx), \
> + PORT_GP_14(4, fn, sfx), \
> + PORT_GP_CFG_1(4, 14, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(4, 15, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(4, 16, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(4, 17, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(4, 18, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_CFG_1(4, 19, fn, sfx, SH_PFC_PIN_CFG_IO_VOLTAGE), \
> + PORT_GP_1(4, 20, fn, sfx), \
> + PORT_GP_1(4, 21, fn, sfx), \
> + PORT_GP_1(4, 22, fn, sfx), \
> + PORT_GP_1(4, 23, fn, sfx), \
> + PORT_GP_1(4, 24, fn, sfx), \
> + PORT_GP_1(4, 25, fn, sfx), \
> PORT_GP_32(5, fn, sfx)
>
> enum {
> @@ -1865,6 +1896,81 @@ static const unsigned int scif_clk_b_pins[] = {
> static const unsigned int scif_clk_b_mux[] = {
> SCIF_CLK_B_MARK,
> };
> +/* - SDHI0
> -- */
> +static const unsigned int sdhi0_data1_pins[] = {
> + /* D0 */
> + RCAR_GP_PIN(0, 7),
> +};
> +static const unsigned int sdhi0_data1_mux[] = {
> + SD0_DAT0_MARK,
> +};
> +static const unsigned int sdhi0_data4_pins[] = {
> + /* D[0:3] */
> + RCAR_GP_PIN(0, 7), RCAR_GP_PIN(0, 8),
> +
Re: [PATCH] pinctrl: sh-pfc: Reduce kernel size for narrow VIN channels
On Tue, Oct 16, 2018 at 02:00:36PM +0200, Geert Uytterhoeven wrote: > Some VIN channels support less than 24 lanes. As union vin_data always > consumes space for 24 lanes, this wastes memory. > > Hence introduce new smaller unions vin_data12 and vin_data16, to > accommodate VIN channels with only 12 or 16 lanes. > > This reduces the static pin controller driver size by 320 bytes for > R-Car V2H, and by 96 bytes for R-Car E2. > > Signed-off-by: Geert Uytterhoeven > --- > To be queued in sh-pfc-for-v4.21. Reviewed-by: Simon Horman
Re: [PATCH] MAINTAINERS: Remove Laurent Pinchart as Renesas pinctrl maintainer
On Tue, Oct 16, 2018 at 01:33:39PM +0300, Laurent Pinchart wrote: > Geert Uytterhoeven has long taken over and I'm not involved anymore with > the Renesas pinctrl driver. Remove myself from the maintainers list. > > Signed-off-by: Laurent Pinchart Reviewed-by: Simon Horman > --- > MAINTAINERS | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 69373eb328d4..f9d00cc05202 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11515,7 +11515,6 @@ F: > Documentation/devicetree/bindings/pinctrl/qcom,*.txt > F: drivers/pinctrl/qcom/ > > PIN CONTROLLER - RENESAS > -M: Laurent Pinchart > M: Geert Uytterhoeven > L: linux-renesas-soc@vger.kernel.org > T: git > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git sh-pfc > -- > Regards, > > Laurent Pinchart >
Re: [PATCH] dt-bindings: spi: sh-msiof: document R8A779{7|8}0 bindings
On Tue, Oct 16, 2018 at 10:22:05PM +0300, Sergei Shtylyov wrote:
> Document the R-Car V3{M|H} (R8A779{7|8}0) SoCs in the Renesas MSIOF
> bindings.
>
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Simon Horman
>
> ---
> The patch is against the 'for-next' branch of Mark Brown's 'spi.git' repo.
>
> Documentation/devicetree/bindings/spi/sh-msiof.txt |2 ++
> 1 file changed, 2 insertions(+)
>
> Index: spi/Documentation/devicetree/bindings/spi/sh-msiof.txt
> ===
> --- spi.orig/Documentation/devicetree/bindings/spi/sh-msiof.txt
> +++ spi/Documentation/devicetree/bindings/spi/sh-msiof.txt
> @@ -13,6 +13,8 @@ Required properties:
>"renesas,msiof-r8a7795" (R-Car H3)
>"renesas,msiof-r8a7796" (R-Car M3-W)
>"renesas,msiof-r8a77965" (R-Car M3-N)
> + "renesas,msiof-r8a77970" (R-Car V3M)
> + "renesas,msiof-r8a77980" (R-Car V3H)
>"renesas,msiof-r8a77990" (R-Car E3)
>"renesas,msiof-r8a77995" (R-Car D3)
>"renesas,msiof-sh73a0" (SH-Mobile AG5)
>
Re: [PATCH] arm64: dts: renesas: r8a779{7|8}0: add MSIOF support
On Tue, Oct 16, 2018 at 10:36:33PM +0300, Sergei Shtylyov wrote:
> Describe MSIOF in the R8A779{7|8}0 device trees.
>
> The DMA props are deliberately omitted as the MSIOF DMA doesn't work on
> R8A77970 (due to IPMMU issue) and the RT-DMAC isn't supported on R8A77980.
For the record: In the short term I'm fine with not enabling DMA if there
are known problems. But in the long term we should describe DMA in DT as
the purpose of DT is to describe hardware rather than software.
So please, as follow-up work, lets work towards a solution that allows us
to describe the hardware in DT.
> Signed-off-by: Sergei Shtylyov
>
> ---
> This patch is against the 'renesas-devel-20181015-v4.19-rc8' branch of
> Simon Horman's 'renesas.git' repo.
>
> The MSIOF bindings patch has just been posted...
>
> arch/arm64/boot/dts/renesas/r8a77970.dtsi | 56
> ++
> arch/arm64/boot/dts/renesas/r8a77980.dtsi | 56
> ++
> 2 files changed, 112 insertions(+)
>
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> ===
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> @@ -22,6 +22,10 @@
> i2c2 =
> i2c3 =
> i2c4 =
> + spi1 =
> + spi2 =
> + spi3 =
> + spi4 =
Geert, could you comment on these aliases and the similar ones below?
I'm not seeing them for any other ARM64-based Renesas SoCs.
Otherwise I am happy with this patch.
> };
>
> /* External CAN clock - to be overridden by boards that provide it */
> @@ -688,6 +692,58 @@
> status = "disabled";
> };
>
> + msiof0: spi@e6e9 {
> + compatible = "renesas,msiof-r8a77970",
> + "renesas,rcar-gen3-msiof";
> + reg = <0 0xe6e9 0 0x64>;
> + interrupts = ;
> + clocks = < CPG_MOD 211>;
> + power-domains = < R8A77970_PD_ALWAYS_ON>;
> + resets = < 211>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + msiof1: spi@e6ea {
> + compatible = "renesas,msiof-r8a77970",
> + "renesas,rcar-gen3-msiof";
> + reg = <0 0xe6ea 0 0x0064>;
> + interrupts = ;
> + clocks = < CPG_MOD 210>;
> + power-domains = < R8A77970_PD_ALWAYS_ON>;
> + resets = < 210>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + msiof2: spi@e6c0 {
> + compatible = "renesas,msiof-r8a77970",
> + "renesas,rcar-gen3-msiof";
> + reg = <0 0xe6c0 0 0x0064>;
> + interrupts = ;
> + clocks = < CPG_MOD 209>;
> + power-domains = < R8A77970_PD_ALWAYS_ON>;
> + resets = < 209>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + msiof3: spi@e6c1 {
> + compatible = "renesas,msiof-r8a77970",
> + "renesas,rcar-gen3-msiof";
> + reg = <0 0xe6c1 0 0x0064>;
> + interrupts = ;
> + clocks = < CPG_MOD 208>;
> + power-domains = < R8A77970_PD_ALWAYS_ON>;
> + resets = < 208>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> vin0: video@e6ef {
> compatible = "renesas,vin-r8a77970";
> reg = <0 0xe6ef 0 0x1000>;
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> ===
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> @@ -23,6 +23,10 @@
> i2c3 =
> i2c4 =
> i2c5 =
> + spi1 =
> + spi2 =
> + spi3 =
> + spi4 =
> };
>
> /* External CAN clock - to be overridden by boards that provide it */
> @@ -740,6 +744,58 @@
> status = "disabled";
> };
>
> + msiof0: spi@e6e9 {
> + compatible = "renesas,msiof-r8a77980",
> +
