what VSPD Means

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

Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

> 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

RE: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

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

Re: what VSPD Means

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

[PATCH v2 3/3] ARM: dts: r7s72100: update sdhi clock bindings

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:

Re: [PATCH v2 2/3] mmc: sh_mobile_sdhi: explain clock bindings

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

[PATCH v2 2/3] mmc: sh_mobile_sdhi: explain clock bindings

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

[PATCH v2 0/3] mmc: sh_mobile_sdhi: fix missing r7s72100 clocks

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

Re: [PATCH v4 1/2] iio: adc: Add Maxim MAX11100 driver

> + * Copyright (C) 2016 Renesas Electronics Corporation > + * Copyright (C) 2016 Jacopo Mondi In case you need to resend: 2016-17?

RE: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

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

Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

> 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

[PATCH v3 00/20] dw-hdmi: Cleanups, fixes and updates for v4.11

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

[PATCH v3 04/20] drm: bridge: dw-hdmi: Embed drm_bridge in struct dw_hdmi

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

[PATCH v3 02/20] drm: bridge: dw-hdmi: Remove unneeded arguments to bind/unbind functions

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

[PATCH v3 13/20] drm: bridge: dw-hdmi: Reject invalid product IDs

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,

[PATCH v3 03/20] drm: bridge: dw-hdmi: Remove unused function parameter

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

[PATCH v3 12/20] drm: bridge: dw-hdmi: Rename CONF0 SPARECTRL bit to SVSRET

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

[PATCH v3 20/20] dt-bindings: display: dw-hdmi: Clean up DT bindings documentation

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

[PATCH v3 17/20] drm: bridge: dw-hdmi: Define and use macros for PHY register addresses

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

[PATCH v3 14/20] drm: bridge: dw-hdmi: Detect AHB audio DMA using correct register

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 ---

[PATCH v3 01/20] drm: bridge: dw-hdmi: Merge __hdmi_phy_i2c_write and hdmi_phy_i2c_write

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 ---

[PATCH v3 08/20] drm: bridge: dw-hdmi: Reorder functions to prepare for next commit

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

[PATCH v3 15/20] drm: bridge: dw-hdmi: Handle overflow workaround based on device version

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

[PATCH v3 06/20] drm: bridge: dw-hdmi: Don't forward HPD events to DRM core before attach

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

[PATCH v3 07/20] drm: bridge: dw-hdmi: Move IRQ and IO resource allocation to common code

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

[PATCH 4/4] arm64: dts: r8a7796: 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 module clocks nor Runtime PM, so this must be handled as a critical clock. Signed-off-by: Geert

[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 module clocks nor Runtime PM, so this must be handled as a critical clock. Signed-off-by: Geert

[PATCH 2/4] ARM: dts: r8a7745: Link ARM GIC to clock and clock domain

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

[PATCH 0/4] ARM/arm64: dts: renesas: Link ARM GIC to clock and clock domain

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

[PATCH 1/4] ARM: dts: r8a7743: Link ARM GIC to clock and clock domain

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

[PATCH 2/2] clk: renesas: mstp: Make INTC-SYS a critical clock

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

[PATCH 0/2] clk: renesas: Use CLK_IS_CRITICAL to handle critical clocks

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

[PATCH 1/2] clk: renesas: cpg-mssr: Migrate to CLK_IS_CRITICAL

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

Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

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

Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

> 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

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

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

RE: [PATCH 3/4] arm64: dts: r8a7795: Link ARM GIC to clock and clock domain

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

Re: [PATCH 3/4] arm64: dts: r8a7795: Link ARM GIC to clock and clock domain

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>;