On Wed, Nov 08, 2017 at 06:33:33AM +, Kuninori Morimoto wrote:
>
> Hi Vinod
>
> > > > > This is now commit 847449f23dcbff68 ("dmaengine: rcar-dmac: use TCRB
> > > > > instead of TCR for residue") in slave-dma/next, and breaks serial
> > > > > console
> > > > > input on koelsch (shmobile_defc
No need to do it manually.
Reported-by: Geert Uytterhoeven
Signed-off-by: Wolfram Sang
---
jacopo: can you test this on Migo-R, please, on top of the other I2C patches?
I tested it on a Lager and it worked there. Will try Gen3 later, too.
drivers/i2c/busses/i2c-sh_mobile.c | 2 --
1 file cha
From: Harunobu Kurokawa
Add compatible string for the RCar M3 R8A7796 SoC.
Signed-off-by: Harunobu Kurokawa
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/pci/host/pcie-rcar.c | 1 +
1 file changed, 1 in
From: Dien Pham
The controller clock can be switched off during suspend/resume,
let runtime PM take care of that.
Signed-off-by: Dien Pham
Signed-off-by: Hien Dang
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
---
From: Kazufumi Ikeda
This adds the suspend/resume supports for pcie-rcar. The resume handler
reprogram the hardware based on the software state kept in specific
device structures. Also it doesn't need to save any registers.
Signed-off-by: Kazufumi Ikeda
Signed-off-by: Gaku Inami
Signed-off-by:
From: Phil Edworthy
Most PCIe host controllers support L0s and L1 power states via ASPM.
The R-Car hardware only supports L0s, so when the system suspends and
resumes we have to manually handle L1.
When the system suspends, cards can put themselves into L1 and send a
PM_ENTER_L1 DLLP to the host
Hi Marek,
On Wed, Nov 8, 2017 at 10:15 AM, Marek Vasut wrote:
> From: Harunobu Kurokawa
>
> Add compatible string for the RCar M3 R8A7796 SoC.
>
> Signed-off-by: Harunobu Kurokawa
> Signed-off-by: Marek Vasut
This patch is not needed, as the DT bindings specify that the DTS should use
both "r
Hello!
On 11/8/2017 12:15 PM, Marek Vasut wrote:
From: Harunobu Kurokawa
Add compatible string for the RCar M3 R8A7796 SoC.
It's M3-W.
Signed-off-by: Harunobu Kurokawa
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.ke
From: Kazufumi Ikeda
Reestablish the PCIe link very early in the resume process in case it
went down to prevent PCI accesses from hanging the bus. Such accesses
can happen early in the PCI resume process, in the resume_noirq, thus
the link must be reestablished in the resume_noirq callback of the
Hi Marek,
On Wed, Nov 8, 2017 at 10:19 AM, Marek Vasut wrote:
> From: Dien Pham
>
> The controller clock can be switched off during suspend/resume,
> let runtime PM take care of that.
>
> Signed-off-by: Dien Pham
> Signed-off-by: Hien Dang
> Signed-off-by: Marek Vasut
Thanks for your patch!
On 11/08/2017 10:28 AM, Sergei Shtylyov wrote:
> Hello!
Hi
> On 11/8/2017 12:15 PM, Marek Vasut wrote:
>
>> From: Harunobu Kurokawa
>>
>> Add compatible string for the RCar M3 R8A7796 SoC.
>
> It's M3-W.
>
>> Signed-off-by: Harunobu Kurokawa
>> Signed-off-by: Marek Vasut
>> Cc: Geert Uyt
From: Dien Pham
The controller clock can be switched off during suspend/resume,
let runtime PM take care of that.
Signed-off-by: Dien Pham
Signed-off-by: Hien Dang
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
To:
On 11/08/2017 10:29 AM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Wed, Nov 8, 2017 at 10:15 AM, Marek Vasut wrote:
>> From: Harunobu Kurokawa
>>
>> Add compatible string for the RCar M3 R8A7796 SoC.
>>
>> Signed-off-by: Harunobu Kurokawa
>> Signed-off-by: Marek Vasut
>
> This patch is n
On 11/08/2017 10:36 AM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Wed, Nov 8, 2017 at 10:19 AM, Marek Vasut wrote:
>> From: Dien Pham
>>
>> The controller clock can be switched off during suspend/resume,
>> let runtime PM take care of that.
>>
>> Signed-off-by: Dien Pham
>> Signed-off-by: Hi
Hi Marek,
On Wed, Nov 8, 2017 at 10:58 AM, Marek Vasut wrote:
> From: Dien Pham
>
> The controller clock can be switched off during suspend/resume,
> let runtime PM take care of that.
>
> Signed-off-by: Dien Pham
> Signed-off-by: Hien Dang
> Signed-off-by: Marek Vasut
> --- a/drivers/pci/hos
On 11/8/2017 12:28 PM, Marek Vasut wrote:
From: Kazufumi Ikeda
Reestablish the PCIe link very early in the resume process in case it
went down to prevent PCI accesses from hanging the bus. Such accesses
can happen early in the PCI resume process, in the resume_noirq, thus
the link must be rees
This supports USB2 PHY channel #0 on ULCB Kingfisher board
The dedicated USB0_PWEN pin is used to control CN13 VBUS source from U43
power supply.
MAX3355 can also provide VBUS, hence it should be disabled via OTG_OFFVBUSn
node coming from gpio expander TCA9539.
Set MAX3355 enabled using OTG_EXTLPn
Adds the pfc node for USB3.0 channel 0.
Signed-off-by: Vladimir Barinov
---
arch/arm64/boot/dts/renesas/ulcb-kf.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
index 48a2e8f..2ecb6ac 100644
---
ULCB-KF has a USB2.0 dual-role channel (CN13).
This adds dr_mode property for USB2.0 channel 0 (EHCI/OHCI and HS-USB)
as "otg".
Signed-off-by: Vladimir Barinov
---
arch/arm64/boot/dts/renesas/ulcb-kf.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/ulcb-kf.
Make genpd to take the WAKEUP_POWERED driver flag into account during
system suspend/resume. More precisely, in case the WAKEUP_POWERED flag is
set, let's leave the device in full power state and prevent the PM domain
from being powered off.
Signed-off-by: Ulf Hansson
---
drivers/base/power/doma
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_wakeup(), to fully understand how to treat the device during system
suspend.
One particular case that suffers from this, is the generic
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.
In particular, sometimes the device may need to stay in full power state,
to have wakeup signals enabled for it. Theref
Let's make the code a bit more readable by moving some of the code, which
deals with adjustments for parent devices in __device_suspend(), into its
own function.
Signed-off-by: Ulf Hansson
---
drivers/base/power/main.c | 29 +
1 file changed, 17 insertions(+), 12 dele
On Wed, Nov 8, 2017 at 4:15 PM, Ulf Hansson wrote:
> Let's make the code a bit more readable by moving some of the code, which
> deals with adjustments for parent devices in __device_suspend(), into its
> own function.
>
> Signed-off-by: Ulf Hansson
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eet
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.
>
> In particular, sometimes the device may need to stay in fu
On Wed, Nov 8, 2017 at 4:15 PM, Ulf Hansson wrote:
> Make genpd to take the WAKEUP_POWERED driver flag into account during
> system suspend/resume. More precisely, in case the WAKEUP_POWERED flag is
> set, let's leave the device in full power state and prevent the PM domain
> from being powered of
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_wakeup(), to fully understand how to treat the device during system
>
A memory region for CEU video buffer has to be reserved during machine
initialization.
Originally, it was allocated through DMA API helpers and stored in the
second IORESOURCE_MEM entry, to be later remapped by the CEU driver with
a call to 'dma_declare_coherent_memory()'
As Linux does not allow
Hi Jacopo,
On Wed, Nov 8, 2017 at 7:05 PM, Jacopo Mondi wrote:
> A memory region for CEU video buffer has to be reserved during machine
> initialization.
>
> Originally, it was allocated through DMA API helpers and stored in the
> second IORESOURCE_MEM entry, to be later remapped by the CEU drive
Hi Wolfram,
On Wed, Nov 08, 2017 at 09:50:37AM +0100, Wolfram Sang wrote:
> No need to do it manually.
>
> Reported-by: Geert Uytterhoeven
> Signed-off-by: Wolfram Sang
> ---
>
> jacopo: can you test this on Migo-R, please, on top of the other I2C patches?
Done.
No appreciable differences with
> For this one as well:
> Tested-by: Jacopo Mondi
Thanks, Jacopo!
signature.asc
Description: PGP signature
On Sat, Nov 04, 2017 at 09:20:00PM +0100, Wolfram Sang wrote:
> While previous versions until v3 tried to magically apply bounce buffers when
> needed, it became clear that detecting DMA safe buffers is too fragile. This
> approach is now opt-in, a DMA_SAFE flag needs to be set on an i2c_msg. The
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.
>
> In particular, sometimes the device may need to stay in fu
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.
>
> In particular, sometimes the device may need to stay in fu
Hi Geert,
On Wednesday, 8 November 2017 20:31:22 EET Geert Uytterhoeven wrote:
> On Wed, Nov 8, 2017 at 7:05 PM, Jacopo Mondi wrote:
> > A memory region for CEU video buffer has to be reserved during machine
> > initialization.
> >
> > Originally, it was allocated through DMA API helpers and stor
Hi Jacopo,
Thank you for the patch.
On Wednesday, 8 November 2017 20:05:46 EET Jacopo Mondi wrote:
> A memory region for CEU video buffer has to be reserved during machine
> initialization.
>
> Originally, it was allocated through DMA API helpers and stored in the
> second IORESOURCE_MEM entry,
36 matches
Mail list logo
