Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
are located between the video sources (CSI-2 transmitters) and the video
grabbers (VIN) on Gen3 of Renesas R-Car SoC.
Each CSI-2 device is connected to more then one VIN device which
simultaneously can receive video from the
Hi,
This is the latest incarnation of R-Car MIPI CSI-2 receiver driver. It's
based on top of the media-tree and are tested on Renesas Salvator-X
together with the out-of-tree patches for rcar-vin to add support for
Gen3 VIN. If anyone is interested to test video grabbing using these out
of tree
A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
hardware blocks are connected between the video sources and the video
grabbers (VIN).
Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.
Signed-off
There is no data when the first WAIT interrupt arrives. No need to read
something then.
Signed-off-by: Wolfram Sang
---
I am not super happy with (real pos >= 0) done twice, but I didn't find a
better solution yet. The compiler will make this cheap anyhow, I guess.
Jacopo: can you please test t
On Thu, Nov 9, 2017 at 3:41 PM, Geert Uytterhoeven wrote:
> Hi Ulf,
>
> On Thu, Nov 9, 2017 at 3:28 PM, Ulf Hansson wrote:
>> [...]
>>
> The Ethernet driver can still call device_set_wakeup_enable(... , false)
> to control this. If WoL is disabled by the user (or deemed not usable,
Hi Ulf,
On Thu, Nov 9, 2017 at 3:28 PM, Ulf Hansson wrote:
> [...]
>
The Ethernet driver can still call device_set_wakeup_enable(... , false)
to control this. If WoL is disabled by the user (or deemed not usable, see
below), it already does so.
>>>
>>> I don't think that API is in
[...]
>>> The Ethernet driver can still call device_set_wakeup_enable(... , false)
>>> to control this. If WoL is disabled by the user (or deemed not usable, see
>>> below), it already does so.
>>
>> I don't think that API is intended to be used like that and I wonder
>> if it even works as expec
Since commit ab82fa7da4dce5c7 ("gpio: rcar: Prevent module clock disable
when wake-up is enabled"), when a GPIO is used for wakeup, the GPIO
block's module clock (if exists) is manually kept running during system
suspend, to make sure the device stays active.
However, this explicit clock handling
Hi all,
If an interrupt controller in a Renesas ARM SoC is part of a Clock
Domain, and it is part of the wakeup path, it must be kept active during
system suspend.
Currently this is handled in all interrupt controller drivers by
explicitly increasing the use count of the module clock when
Since commit 705bc96c2c15313c ("irqchip: renesas-intc-irqpin: Add
minimal runtime PM support"), when an IRQ is used for wakeup, the INTC
block's module clock (if exists) is manually kept running during system
suspend, to make sure the device stays active.
However, this explicit clock handling is m
Since commit 6f46aedb9c85873b ("irqchip: renesas-irqc: Add wake-up
support"), when an IRQ is used for wakeup, the INTC
block's module clock is manually kept running during system suspend, to
make sure the device stays active.
However, this explicit clock handling is merely a workaround for a
failu
If a device is part of the CPG/MSTP Clock Domain and to be used as a
wakeup source, it must be kept active during system suspend.
Currently this is handled in device-specific drivers by explicitly
increasing the use count of the module clock when the device is
configured as a wakeup source. Howev
If a device is part of the CPG/MSSR Clock Domain and to be used as a
wakeup source, it must be kept active during system suspend.
Currently this is handled in device-specific drivers by explicitly
increasing the use count of the module clock when the device is
configured as a wakeup source. Howev
Hi Rafael, Ulf, Kevin,
If a device in a Renesas ARM SoC is part of a Clock Domain, and it is
used as a wakeup source, it must be kept active during system suspend.
Currently this is handled in device-specific drivers by explicitly
increasing the use count of the module clock when the devi
If an R-Car SYSC slave device is part of the CPG/MSTP or CPG/MSSR Clock
Domain and to be used as a wakeup source, it must be kept active during
system suspend.
Currently this is handled in device-specific drivers by explicitly
increasing the use count of the module clock when the device is
configu
On Thu, Nov 9, 2017 at 11:39 AM, Geert Uytterhoeven
wrote:
> From: Yoshihiro Shimoda
>
> This patch adds binding for r8a77995 (R-Car D3). This SoC can use
> "renesas,rcar-gen3-gpio" fallback compatibility. So, this patch
> doesn't modify the gpio-rcar driver.
>
> Signed-off-by: Yoshihiro Shimoda
On Thu, Nov 9, 2017 at 12:59 PM, Rafael J. Wysocki wrote:
> On Thu, Nov 9, 2017 at 11:08 AM, Ulf Hansson wrote:
>> On 9 November 2017 at 10:02, Geert Uytterhoeven wrote:
>>> Hi Ulf,
>>>
>>> On Thu, Nov 9, 2017 at 9:28 AM, Ulf Hansson wrote:
On 8 November 2017 at 16:41, Geert Uytterhoeven
On Thu, Nov 9, 2017 at 11:08 AM, Ulf Hansson wrote:
> On 9 November 2017 at 10:02, Geert Uytterhoeven wrote:
>> Hi Ulf,
>>
>> On Thu, Nov 9, 2017 at 9:28 AM, Ulf Hansson wrote:
>>> On 8 November 2017 at 16:41, Geert Uytterhoeven
>>> wrote:
On Wed, Nov 8, 2017 at 4:15 PM, Ulf Hansson wrot
On Thu, Nov 9, 2017 at 9:53 AM, Ulf Hansson wrote:
> On 9 November 2017 at 01:41, Rafael J. Wysocki wrote:
>> On Wed, Nov 8, 2017 at 4:15 PM, Ulf Hansson wrote:
>>> For some bus types and PM domains, it's not sufficient to only check the
>>> return value from device_may_wakeup(), to fully unders
On Thu, Nov 9, 2017 at 9:44 AM, Ulf Hansson wrote:
> On 9 November 2017 at 01:24, Rafael J. Wysocki wrote:
>> On Wed, Nov 8, 2017 at 4:15 PM, Ulf Hansson wrote:
>>> For some bus types and PM domains, it's not sufficient to only check the
>>> return value from device_may_wakeup(), to fully unders
From: Yoshihiro Shimoda
This patch adds binding for r8a77995 (R-Car D3). This SoC can use
"renesas,rcar-gen3-gpio" fallback compatibility. So, this patch
doesn't modify the gpio-rcar driver.
Signed-off-by: Yoshihiro Shimoda
Acked-by: Simon Horman
Acked-by: Rob Herring
Signed-off-by: Geert Uyt
Hi Ulf,
On Thu, Nov 9, 2017 at 11:08 AM, Ulf Hansson wrote:
> On 9 November 2017 at 10:02, Geert Uytterhoeven wrote:
>> On Thu, Nov 9, 2017 at 9:28 AM, Ulf Hansson wrote:
>>> On 8 November 2017 at 16:41, Geert Uytterhoeven
>>> wrote:
On Wed, Nov 8, 2017 at 4:15 PM, Ulf Hansson wrote:
>>
On 9 November 2017 at 10:02, Geert Uytterhoeven wrote:
> Hi Ulf,
>
> On Thu, Nov 9, 2017 at 9:28 AM, Ulf Hansson wrote:
>> On 8 November 2017 at 16:41, Geert Uytterhoeven wrote:
>>> On Wed, Nov 8, 2017 at 4:15 PM, Ulf Hansson wrote:
The generic problem this series is trying to solve, is th
Hi Simon,
On Wednesday, 8 November 2017 06:48:23 EET Simon Horman wrote:
> On Tue, Nov 07, 2017 at 06:05:37AM +0200, Laurent Pinchart wrote:
> > Hi Fabrizio,
> >
> > Thank you for the patch.
> >
> > On Monday, 6 November 2017 20:26:53 EET Fabrizio Castro wrote:
> > > Add du node to r8a7745 SoC D
Hi Ulf,
On Thu, Nov 9, 2017 at 9:28 AM, Ulf Hansson wrote:
> On 8 November 2017 at 16:41, Geert Uytterhoeven wrote:
>> On Wed, Nov 8, 2017 at 4:15 PM, Ulf Hansson wrote:
>>> The generic problem this series is trying to solve, is that for some bus
>>> types
>>> and PM domains, it's not sufficie
On 9 November 2017 at 01:41, Rafael J. Wysocki wrote:
> On Wed, Nov 8, 2017 at 4:15 PM, Ulf Hansson wrote:
>> For some bus types and PM domains, it's not sufficient to only check the
>> return value from device_may_wakeup(), to fully understand how to treat the
>> device during system suspend.
>>
On 9 November 2017 at 01:24, Rafael J. Wysocki wrote:
> On Wed, Nov 8, 2017 at 4:15 PM, Ulf Hansson wrote:
>> For some bus types and PM domains, it's not sufficient to only check the
>> return value from device_may_wakeup(), to fully understand how to treat the
>> device during system suspend.
>>
On 8 November 2017 at 16:41, Geert Uytterhoeven wrote:
> Hi Ulf,
>
> On Wed, Nov 8, 2017 at 4:15 PM, Ulf Hansson wrote:
>> The generic problem this series is trying to solve, is that for some bus
>> types
>> and PM domains, it's not sufficient to only check the return value from
>> device_may_wa
28 matches
Mail list logo
