On 01/17/2017 01:58 PM, Laurent Pinchart wrote:
Hello,
This patch series contains the part of my pending dw-hdmi patches that have
been successfully tested on all three supported platforms (i.MX6, RK3288 and
R-Car H3) and have been reviewed without any problem being reported.
All patches here
On Fri, Jan 13, 2017 at 10:50:38AM +0100, Jacopo Mondi wrote:
> Add device tree bindings documentation for Maxim MAX11100 single-channel
> ADC
>
> Signed-off-by: Jacopo Mondi
Acked-by: Wolfram Sang
> + * Copyright (C) 2016 Renesas Electronics Corporation
> + * Copyright (C) 2016 Jacopo Mondi
In case you need to resend: 2016-17?
Hi Chris,
> + struct clk *clk2;
I'd vote for 'clk_cd' since we are explicitly requesting that clock for
it.
> + ret = clk_prepare_enable(priv->clk2);
> + if (ret < 0)
> + return ret;
You need to disable clk when failing.
Regards,
Wolfram
On Tue, Jan 17, 2017 at 02:59:39PM -0500, Chris Brandt wrote:
> In the case of a single clock source, you don't need names. However,
> if the controller has 2 clock sources, you need to name them correctly
> so the driver can find the 2nd one.
>
> Signed-off-by: Chris Brandt
> ---
> Documentatio
From: Wolfram Sang
Create a helper function to disable clocks and use it in remove(), too.
Now, clk_summary in debugfs reports the clocks as disabled and
unprepared after unbinding.
Signed-off-by: Wolfram Sang
---
drivers/mmc/host/tmio_mmc_pio.c | 11 +--
1 file changed, 9 insertions(+
At first this started out as a simple typo fix, until I realized
that the SDHI in the RZ/A1 has 2 clocks per channel and both need
to be turned on/off.
This patch series adds the ability to specify 2 clocks instead of
just 1, and does so for the RZ/A1 r7s72100.
This patch has been tested on an RZ
Some controllers have 2 clock sources instead of 1, so they both need
to be turned on/off.
Signed-off-by: Chris Brandt
---
drivers/mmc/host/sh_mobile_sdhi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
ind
In the case of a single clock source, you don't need names. However,
if the controller has 2 clock sources, you need to name them correctly
so the driver can find the 2nd one.
Signed-off-by: Chris Brandt
---
Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 21 +
1 file ch
The SDHI controller in the RZ/A1 has 2 clock sources per channel and both
need to be enabled/disabled for proper operation. This fixes the fact that
the define for R7S72100_CLK_SDHI1 was not correct to begin with (typo), and
that all 4 clock sources need to be defined an used.
Signed-off-by: Chris
Hi Jithin,
On Tuesday 17 Jan 2017 21:57:39 Jithin T Raj wrote:
> hi all,
> I am on a small research on VSPD in kernel.. I googled it a lot
> but couldn't get a clear explanation..In my knowledge , it is a memory
> to memory maped video processing engine..It can directly interact to
> DU etc...But
> So, should sh_mobile_sdhi_remove() be changed to call
> sh_mobile_sdhi_clk_disable()?
Give me a minute, I already did a patch for this :)
signature.asc
Description: PGP signature
Hi Wolfram,
On Tuesday, January 17, 2017, Wolfram Sang wrote:
> > I have no idea if the SDHI driver disables the module clock when it is
> > idle, but shouldn't the card detect clock be running all the time when
> > the driver is bound to the device?
>
> Yes, it should. And for all instances with
hi all,
I am on a small research on VSPD in kernel.. I googled it a lot
but couldn't get a clear explanation..In my knowledge , it is a memory
to memory maped video processing engine..It can directly interact to
DU etc...But I came accross to know that v4l2 in linux supports
VSPD...is v4l2 a
Hi Wolfram,
On Tuesday, January 17, 2017, Wolfram Sang wrote:
> > I have no idea if the SDHI driver disables the module clock when it is
> > idle, but shouldn't the card detect clock be running all the time when
> > the driver is bound to the device?
>
> Yes, it should. And for all instances with
Hi Ramesh,
On Tue, Jan 17, 2017 at 3:00 PM, Ramesh Shanmugasundaram
wrote:
>> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> @@ -166,6 +166,9 @@
>> <0x0 0xf106 0 0x2>;
>> interrupts = >
Hi Geert,
> Subject: [PATCH 3/4] arm64: dts: r8a7795: Link ARM GIC to clock and clock
> domain
>
> Link the ARM GIC to the INTC-AP module clock, and add it to the SYSC
> "always-on" PM Domain, so it can be power managed using that clock.
>
> Note that currently the GIC-400 driver doesn't support
When the Renesas CPG/MSSR driver was introduced, it was anticipated that
critical clocks would be handled through a new CLK_ENABLE_HAND_OFF flag
soon. However, CLK_ENABLE_HAND_OFF never made it upstream.
Instead, commit 32b9b10961860860 ("clk: Allow clocks to be marked as
CRITICAL") introduced CL
INTC-SYS is the module clock for the GIC. Accessing the GIC while it is
disabled causes:
Unhandled fault: asynchronous external abort (0x1211) at 0x
Currently, the GIC-400 driver cannot enable its module clock for several
reasons:
- It does not use a platform device, so Runtime PM
Hi Mike, Stephen,
This patch series adds support for the CLK_IS_CRITICAL flag to drivers
for module clocks on Renesas ARM SoCs. For now, this is used to prevent
disabling of the ARM GIC module clock, which would lead to a system
lock-up when accessing the GIC's registers.
1. The first
Hi Simon, Magnus,
This patch series improves the topology description in DT of the ARM GIC
on Renesas SoCs using the CPG/MSSR bindings (R-Car Gen3 and RZ/G).
It links the GIC to its module clock, and adds it to the SYSC "always
on" PM Domain.
Note that currently the GIC-400 driver doesn't
Link the ARM GIC to the INTC-SYS module clock, and add it to the SYSC
"always-on" PM Domain, so it can be power managed using that clock.
Note that currently the GIC-400 driver doesn't support module clocks nor
Runtime PM, so this must be handled as a critical clock.
Signed-off-by: Geert Uytterho
Link the ARM GIC to the INTC-SYS module clock, and add it to the SYSC
"always-on" PM Domain, so it can be power managed using that clock.
Note that currently the GIC-400 driver doesn't support module clocks nor
Runtime PM, so this must be handled as a critical clock.
Signed-off-by: Geert Uytterho
Link the ARM GIC to the INTC-AP module clock, and add it to the SYSC
"always-on" PM Domain, so it can be power managed using that clock.
Note that currently the GIC-400 driver doesn't support module clocks nor
Runtime PM, so this must be handled as a critical clock.
Signed-off-by: Geert Uytterhoe
Link the ARM GIC to the INTC-AP module clock, and add it to the SYSC
"always-on" PM Domain, so it can be power managed using that clock.
Note that currently the GIC-400 driver doesn't support module clocks nor
Runtime PM, so this must be handled as a critical clock.
Signed-off-by: Geert Uytterhoe
On 2017-01-12 14:03:24 +0100, Wolfram Sang wrote:
>
> > I'll bring my Koelsch.
>
> Great. I *think* one Koelsch will do, but if it is not too much of a
> problem, double-checking with a second board won't hurt. So, since Geert
> will probably bring all necessary cables and supplies, maybe you can
Hi Wolfram,
On Tue, Jan 17, 2017 at 10:57 AM, Wolfram Sang wrote:
>> If we handle them as one, won't we miss card detect events due to the
>> card detect clock being disabled while SDHI is idle?
>
> You mean this?
>
> 1208 /*
> 1209 * While using internal tmio hardware logic for
> If we handle them as one, won't we miss card detect events due to the
> card detect clock being disabled while SDHI is idle?
You mean this?
1208 /*
1209 * While using internal tmio hardware logic for card detection, we
need
1210 * to ensure it stays powered for it to
Hi Wolfram,
On Tue, Jan 17, 2017 at 10:45 AM, Wolfram Sang wrote:
>> I have no idea if the SDHI driver disables the module clock when it is
>> idle, but shouldn't the card detect clock be running all the time when the
>> driver is bound to the device?
>
> Yes, it should. And for all instances wit
> I have no idea if the SDHI driver disables the module clock when it is
> idle, but shouldn't the card detect clock be running all the time when the
> driver is bound to the device?
Yes, it should. And for all instances with just one clock, this means
this main clock must be running. So, en-/dis
Hi Wolfram,
On Tue, Jan 17, 2017 at 9:21 AM, Wolfram Sang wrote:
>> The reason is that would then keep me from having to modify the existing
>> functions sh_mobile_sdhi_clk_enable/disable.
>
> Why do you prefer this? I may be missing something but a small if-block
> per function are not expensive
On Mon, Jan 16, 2017 at 05:57:53PM +0100, Geert Uytterhoeven wrote:
> This went unnoticed as the sata_rcar driver doesn't support Runtime PM
> yet, but manages module clocks manually.
>
> Signed-off-by: Geert Uytterhoeven
Thanks, I have queued this up for v4.11.
On Mon, Jan 16, 2017 at 05:56:53PM +0100, Geert Uytterhoeven wrote:
> Device nodes representing I/O devices should be marked disabled in the
> SoC-specific DTS, and overridden by board-specific DTSes where needed.
>
> Signed-off-by: Geert Uytterhoeven
Thanks, I have queued this up for v4.11.
Make it clear that the core bridge/dw_hdmi.txt document isn't a device
tree binding by itself but is meant to be referenced by platform device
tree bindings, and update the Rockchip and Freescale DWC HDMI TX
bindings to reference it.
Signed-off-by: Laurent Pinchart
Acked-by: Rob Herring
---
...
Replace the hardcoded register address numerical values with macros to
clarify the code.
This change has been tested by comparing the assembly code before and
after the change.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 35 ---
Bit 0 in CONFIG1_ID tells whether the IP core uses an AHB slave
interface for control. The correct way to identify AHB audio DMA support
is through bit 1 in CONFIG3_ID.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 6 +++---
drivers/gpu/drm/bridg
The field isn't needed, remove it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 2c85b6c07a80..ef
The DRM device is not guaranteed by the bridge API to be available
before the attach callback. The driver performs properly at the moment
as it doesn't use the drm_bridge_add() registration method. As this will
be changed later, move connector creation to attach time to ensure
compatibility with th
Detect the PHY type and use it to handle the PHY type-specific SVSRET
signal.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 68 ++--
include/drm/bridge/dw_hdmi.h | 10 ++
2 files changed, 75 insertions(+), 3 deletions(-)
diff
According to the PHY IP core vendor, the SVSRET signal must be asserted
before resetting the PHY. Tests on RK3288 and R-Car Gen3 showed no
regression, the change should thus be safe.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 10 +-
1
The PHY reset signal is controlled by bit PHYRSTZ in the MC_PHYRSTZ
register. The signal is active low on Gen1 PHYs and active high on Gen2
PHYs. The driver toggles the signal high then low, which is correct for
all currently supported platforms, but the register values macros are
incorrectly named
Use the device version queried at runtime instead of the device type
provided through platform data to handle the overflow workaround. This
will make support of other SoCs integrating the same HDMI TX controller
version easier.
Among the supported platforms only i.MX6DL and i.MX6Q have been
identi
Hotplug events should only be forwarded to the DRM core by the interrupt
handler when the bridge has been attached, otherwise the DRM device
pointer will be NULL, resulting in a crash.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 3 ++-
1 file c
The master argument isn't used. The data argument, a void pointer, is
used by the bind function only where it's cast to a drm_device pointer,
which can easily be obtained from the encoder argument instead. Remove
them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/
The DWC HDMI TX can be recognized by the two product identification
registers. If the registers don't read as expect the IP will be very
different than what the driver has been designed for, or will be
misconfigured in a way that makes it non-operational (invalid memory
address, incorrect clocks, .
From: Kieran Bingham
The 'prep' parameter passed to hdmi_phy_configure() is useless. It is
hardcoded as 0, and if set, simply prevents the configure function from
executing.
Remove it.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/
The bit is documented in a Rockchip BSP as
#define m_SVSRET_SIG (1 << 5) /* depend on PHY_MHL_COMB0=1 */
This is confirmed by a Renesas platform, which uses a 2.0 DWC HDMI TX as
the RK3288. Rename the bit accordingly.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
driv
As an option for drivers not based on the component framework, register
the bridge with the DRM core with the DRM bridge API. Existing drivers
based on dw_hdmi_bind() and dw_hdmi_unbind() are not affected as those
functions are preserved with their current behaviour.
Signed-off-by: Laurent Pinchar
The latter is just an int wrapper around the former void function that
unconditionally returns 0. As the return value is never checked, merge
the two functions into one.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 9 +
1 file changed, 1
The next commit will reference structures and functions in a way that
currently requires forward declarations. Reorder the functions to avoid
that. No functional change to the code is performed.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 72 ++
There's no need to duplicate identical code in multiple drivers (two at
the moment, one more to come soon). Move it to the dw-hdmi core where it
can be shared. If resource allocation ever becomes device-specific later
we'll always have the option of splitting it out again.
While it at pass the pla
The drm_bridge instance is always needed, there's no point in allocating
it separately.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.
From: Kieran Bingham
The current code hard codes the call of hdmi_phy_configure() to be 8bpp
and provides extraneous error checking to verify that this hardcoded
value is correct. Simplify the implementation by removing the argument.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
Hello,
This patch series contains the part of my pending dw-hdmi patches that have
been successfully tested on all three supported platforms (i.MX6, RK3288 and
R-Car H3) and have been reviewed without any problem being reported.
All patches here have been previously posted as part of the "[PATCH
> The reason is that would then keep me from having to modify the existing
> functions sh_mobile_sdhi_clk_enable/disable.
Why do you prefer this? I may be missing something but a small if-block
per function are not expensive IMO.
> Is anyone going to have an issue if I turn the card-detect clock
55 matches
Mail list logo
