Hello,
On Fri, 20 Apr 2018 23:10:11 +0200
Mylène Josserand wrote:
> Hello everyone,
>
> This is a V7 of my series that adds SMP support for Allwinner sun8i-a83t.
> Based on sunxi's tree, sunxi/for-next branch.
> Depends on a patch from Doug Berger that allows to include the "cpu-type"
> header
The R_CPUCFG is a collection of registers needed for SMP bringup
on clusters and cluster's reset.
For the moment, documentation about this register is found in
Allwinner's code only.
Signed-off-by: Mylène Josserand
Reviewed-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +
1 fil
Add CCI-400 node and control-port on CPUs needed by SMP bringup.
Signed-off-by: Mylène Josserand
Reviewed-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 41 +++
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch
As we found in sun9i-a80, CPUCFG is a collection of registers that are
mapped to the SoC's signals from each individual processor core and
associated peripherals.
These registers are used for SMP bringup and CPU hotplugging.
Signed-off-by: Mylène Josserand
Reviewed-by: Chen-Yu Tsai
---
arch/ar
To prepare the support of sun8i-a83t, add a field in the smp_data
structure to know if we are on sun9i-a80 or sun8i-a83t.
Add also a global variable to retrieve which architecture we are
having.
Signed-off-by: Mylène Josserand
---
arch/arm/mach-sunxi/mc_smp.c | 4
1 file changed, 4 inserti
The CNTVOFF register from arch timer is uninitialized.
It should be done by the bootloader but it is currently not the case,
even for boot CPU because this SoC is booting in secure mode.
It leads to an random offset value meaning that each CPU will have a
different time, which isn't working very we
Add the initialization of CNTVOFF for sun8i-a83t.
For boot CPU, create a new machine that handles this
function's call in an "init_early" callback. We need to initialize
CNTVOFF before the arch timer's initialization otherwise, it will
not be taken into account and fails to boot correctly.
Because
To prepare the support for sun8i-a83t, rename the macro that handles
the power-off of clusters because it is different from sun9i-a80 to
sun8i-a83t.
The power off register for clusters are different from a80 and a83t.
Signed-off-by: Mylène Josserand
Acked-by: Maxime Ripard
Reviewed-by: Chen-Yu
Add the support for A83T.
A83T SoC has an additional register than A80 to handle CPU configurations:
R_CPUS_CFG. Information about the register comes from Allwinner's BSP
driver.
An important difference is the Power Off Gating register for clusters
which is BIT(4) in case of SUN9I-A80 and BIT(0) i
Now that a common function is available for CNTVOFF's
initialization, let's convert shmobile-apmu code to use
this function.
Signed-off-by: Mylène Josserand
Reviewed-by: Geert Uytterhoeven
Tested-by: Geert Uytterhoeven
---
arch/arm/mach-shmobile/common.h | 1 -
arch/arm/mach-shmobile
Add the use of enable-method property for SMP support which allows
to handle the SMP support for this specific SoC.
This commit adds enable-method properties to all CPU nodes.
Signed-off-by: Mylène Josserand
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 8
1 file changed, 8 insertions(+)
di
Move the assembly code for cluster cache enabling and resuming
into an assembly file instead of having it directly in C code.
Remove the CFLAGS because we are using the ARM directive "arch"
instead.
Signed-off-by: Mylène Josserand
---
arch/arm/mach-sunxi/Makefile | 4 +--
arch/arm/mach-sunxi/
Hello everyone,
This is a V7 of my series that adds SMP support for Allwinner sun8i-a83t.
Based on sunxi's tree, sunxi/for-next branch.
Depends on a patch from Doug Berger that allows to include the "cpu-type"
header on assembly files:
https://lkml.org/lkml/2018/2/23/1263
(applied on Broadcom's tr
Hello everyone,
This is a V7 of my series that adds SMP support for Allwinner sun8i-a83t.
Based on sunxi's tree, sunxi/for-next branch.
Depends on a patch from Doug Berger that allows to include the "cpu-type"
header on assembly files:
https://lkml.org/lkml/2018/2/23/1263
(applied on Broadcom's tr
On 04/20/2018 12:58 PM, Simon Horman wrote:
>> Define the generic R8A77980 part of the MMC0 (SDHI2) device node.
>>
>> Signed-off-by: Sergei Shtylyov
>>
>> ---
>> arch/arm64/boot/dts/renesas/r8a77980.dtsi | 12
>> 1 file changed, 12 insertions(+)
>>
>> Index: renesas/arch/arm64/bo
On Fri, Apr 20, 2018 at 03:28:26PM +0200, Geert Uytterhoeven wrote:
> The first 6 patches can be applied independently by subsystem
> maintainers.
> The last two patches depend on the first 6 patches, and are thus marked
> RFC.
Would it not make sense to try to apply everything en masse rather th
On 04/20/2018 01:03 PM, Simon Horman wrote:
>> Define the Condor board dependent part of the MMC0 (connected to eMMC chip)
>> device node along with the necessary voltage regulators...
>>
>> Signed-off-by: Sergei Shtylyov
>>
>> ---
>> arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 43
>> ++
On 03/09/2018 03:04 PM, Sergei Shtylyov wrote:
> Here's the set of 3 patches against Simon Horman's 'renesas.git' repo's
> 'renesas-devel-20180308-v4.16-rc4' tag. We're adding the R8A77980 PFC node
> and then describing the pins for SCIF0 and EtherAVB devices declared earlier.
> These patches dep
The patch
spi: simplify getting .drvdata
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the
The patch
ASoC: atmel: simplify getting .drvdata
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
The patch
ASoC: sh: Drop SUPERH platform dependency
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Lin
On Fri, Apr 20, 2018 at 9:00 AM, Vincent Guittot
wrote:
[..]
>
> Le Saturday 14 Apr 2018 à 13:24:20 (+0200), Vincent Guittot a écrit :
>> Hi Niklas,
>>
>> On 13 April 2018 at 00:39, Niklas Söderlund
>> wrote:
>> > Hi Vincent,
>> >
>> > Thanks for helping trying to figure this out.
>> >
>> > On 20
Hi Heiner and Niklas,
Le Saturday 14 Apr 2018 à 13:24:20 (+0200), Vincent Guittot a écrit :
> Hi Niklas,
>
> On 13 April 2018 at 00:39, Niklas Söderlund
> wrote:
> > Hi Vincent,
> >
> > Thanks for helping trying to figure this out.
> >
> > On 2018-04-12 15:30:31 +0200, Vincent Guittot wrote:
> >
Add SCIF DMA support for R8A77470 SoC.
Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
---
arch/arm/boot/dts/r8a77470.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index 39549f2..baec3ca 100644
Describe SCIF ports in the R8A77470 device tree.
Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
---
arch/arm/boot/dts/r8a77470.dtsi | 69 +++--
1 file changed, 67 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boo
This patch series add support for SYS-DMAC, External interrupt
Controller(IRQC) and SCIF wth DMA support to the r8a77470 SoC dtsi
This patch series tested against renesas-dev branch
tag "renesas-dev-20180420-v4.17-rc1"
Biju Das (4):
ARM: dts: r8a77470: Add SYS-DMAC support
Describe the IRQC interrupt controller in the R8A77470 device tree.
Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
---
arch/arm/boot/dts/r8a77470.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dts
Describe SYS-DMAC0/1 in the R8A77470 device tree.
Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
---
arch/arm/boot/dts/r8a77470.dtsi | 66 +
1 file changed, 66 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.
On 04/20/2018 04:28 PM, Geert Uytterhoeven wrote:
> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
> CONFIG_ARCH_SHMOBILE, hence use the former.
>
> Renesas SuperH SH-Mobile SoCs are still covered
On Fri, Apr 20, 2018 at 11:59:13AM +0200, Geert Uytterhoeven wrote:
> Hi Christoph,
>
> On Fri, Apr 20, 2018 at 10:31 AM, Christoph Hellwig
> wrote:
> > On Wed, Apr 18, 2018 at 03:13:14PM +0200, jacopo mondi wrote:
> >> As long as it goes for arch/sh, the only user of dma_alloc_coherent()
> >> i
On 04/20/2018 04:28 PM, Geert Uytterhoeven wrote:
> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is ARCH_RENESAS a more appropriate platform dependency than the legacy
"ARCH_RENESAS is", no?
> ARCH_SHMOBILE, hence use the former.
>
> This will allow to drop ARCH_
The SIU sound peripheral is used only on SuperH SH-Mobile platforms.
As both SUPERH and ARCH_SHMOBILE are set for these platforms, the SUPERH
dependency can be dropped.
Signed-off-by: Geert Uytterhoeven
---
sound/soc/sh/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
Since commit a521422ea4ae6128 ("ARM: shmobile: mackerel: Remove Legacy C
board code"), the only remaining platforms using this driver are SuperH
SH-Mobile SoCs (sh7723). As both SUPERH and ARCH_SHMOBILE are set for
these platforms, the SUPERH dependency can be dropped.
Signed-off-by: Geert Uytter
On Fri, Apr 20, 2018 at 3:28 PM, Geert Uytterhoeven
wrote:
> Hi all,
>
> Commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> started the conversion from ARCH_SHMOBILE to ARCH_RENESAS for Renesas
> ARM SoCs. This patch series completes the conversion, by:
> 1. Updating de
The Kconfig symbol for Renesas 64-bit ARM SoCs has always been
ARCH_RENESAS, with ARCH_SHMOBILE being selected to reuse drivers shared
with Renesas 32-bit ARM and/or Renesas SuperH SH-Mobile SoCs.
Commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
started the conversion from ARCH_SH
All drivers for Renesas ARM SoCs have gained proper ARCH_RENESAS
platform dependencies. Hence finish the conversion from ARCH_SHMOBILE
to ARCH_RENESAS for Renesas 32-bit ARM SoCs, as started by commit
9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS").
Signed-off-by: Geert Uytterhoeven
-
Emma Mobile is a Renesas ARM SoC. Since commit 9b5ba0df4ea4f940 ("ARM:
shmobile: Introduce ARCH_RENESAS") is ARCH_RENESAS a more appropriate
platform dependency than the legacy ARCH_SHMOBILE, hence use the
former.
This will allow to drop ARCH_SHMOBILE on ARM in the near future.
Signed-off-by: Ge
Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is ARCH_RENESAS a more appropriate platform dependency than the legacy
ARCH_SHMOBILE, hence use the former.
This will allow to drop ARCH_SHMOBILE on ARM in the near future.
Signed-off-by: Geert Uytterhoeven
---
arch/arm/Kco
Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
CONFIG_ARCH_SHMOBILE, hence use the former.
Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
check, just like before support for Ren
Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
CONFIG_ARCH_SHMOBILE, hence use the former.
Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
check.
This will allow to drop ARCH_SH
Hi all,
Commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
started the conversion from ARCH_SHMOBILE to ARCH_RENESAS for Renesas
ARM SoCs. This patch series completes the conversion, by:
1. Updating dependencies for drivers that weren't converted yet,
2. Removing the AR
The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs
only. Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce
ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency
than the legacy ARCH_SHMOBILE, hence use the former.
This will allow to drop ARCH_SHMOBILE o
Change the menu title to refer to "Renesas SoCs" instead of "SuperH", as
both SuperH and ARM SoCs are supported.
Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is ARCH_RENESAS a more appropriate platform dependency for Renesas ARM
SoCs than the legacy ARCH_SHMOBILE, hence
Hi Geert,
Thank you for the patches.
For the whole series,
Reviewed-by: Laurent Pinchart
On Friday, 20 April 2018 16:15:39 EEST Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> The last Renesas ARM platform using this driver was removed in commit
> a521422ea4ae6128 ("ARM: shmobile: mac
The last Renesas ARM platform using this driver was removed in commit
a521422ea4ae6128 ("ARM: shmobile: mackerel: Remove Legacy C board
code").
Signed-off-by: Geert Uytterhoeven
---
arch/arm/configs/shmobile_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/shmobile_d
The last Renesas ARM platform using this driver was removed in commit
a521422ea4ae6128 ("ARM: shmobile: mackerel: Remove Legacy C board
code").
Signed-off-by: Geert Uytterhoeven
---
arch/arm/configs/multi_v7_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/multi_v7_d
Hi Simon, Magnus,
The last Renesas ARM platform using this driver was removed in commit
a521422ea4ae6128 ("ARM: shmobile: mackerel: Remove Legacy C board
code"), hence CONFIG_FB_SH_MOBILE_MERAM can be disabled.
Thanks!
Geert Uytterhoeven (2):
ARM: shmobile: defconfig: Disable CONFIG_FB
On 04/20/2018 05:20 AM, Geert Uytterhoeven wrote:
System restart triggered by watchdog time-out works fine on a Koelsch
board with R-Car M2-W ES2.0.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Guenter Roeck
---
Thanks to Magnus and Shimoda-san for providing board access!
---
drivers/w
> Subject: [PATCH] watchdog: renesas-wdt: Remove R-Car M2-W ES2.x from blacklist
>
> System restart triggered by watchdog time-out works fine on a Koelsch
> board with R-Car M2-W ES2.0.
>
> Signed-off-by: Geert Uytterhoeven
Acked-by: Fabrizio Castro
> ---
> Thanks to Magnus and Shimoda-san for
From: Takeshi Kihara
Basic support for the Renesas Ebisu board based on R-Car E3:
- Memory,
- Main crystal,
- Serial console,
Signed-off-by: Takeshi Kihara
[shimoda: rebase and add SPDX-License-Identifier]
Signed-off-by: Yoshihiro Shimoda
---
arch/arm64/boot/dts/renesas/Makefile
This patch adds basic support for the Renesas R-Car E3 (R8A77990) SoC:
- PSCI
- CPU (single)
- Cache controller
- Main clocks and controller
- Interrupt controller
- Timer
- PMU
- Reset controller
- Product register
- System controller
- UART for console
Inspried by a patch b
From: Takeshi Kihara
This patch adds all R-Car E3 Clock Pulse Generator Core Clock Outputs.
Note that internal CPG clocks (S0, S1, S2, S3, SDSRC) are not included,
as they are used as internal clock sources only, and never referenced
from DT.
Signed-off-by: Takeshi Kihara
[shimoda: add SPDX-Li
This patch is based on the renesas-devel-20180418-v4.17-rc1 tag of
renesas.git.
Changes from v1:
- Remove POST3's definition in patch 1.
Discussed on https://patchwork.kernel.org/patch/10335231/
- Fix typo and some errors in patch 2.
- Add Geert-san's Reviewed-by in patch 2.
Discussed on h
This patch is based on the renesas-devel-20180418-v4.17-rc1 tag of
renesas.git.
This code doesn't use dt-bindings definitions to avoid dependency.
Changes from v1:
- Change some nodes places in patch 1.
Discussed on https://patchwork.kernel.org/patch/10335237/
Takeshi Kihara (1):
arm64: dt
Initial support for R-Car E3 (r8a77990), including core and module
clocks.
Based on the Table 8.2g of "R-Car Series, 3rd Generation User's Manual:
Hardware ((Rev. 0.80, Oct 31, 2017) with Manual Errata on Feb. 28, 2018".
Inspried by patches by Takeshi Kihara in the BSP.
Signed-off-by: Yoshihiro
System restart triggered by watchdog time-out works fine on a Koelsch
board with R-Car M2-W ES2.0.
Signed-off-by: Geert Uytterhoeven
---
Thanks to Magnus and Shimoda-san for providing board access!
---
drivers/watchdog/renesas_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Fixes: c6a27fa41fab ("drm: rcar-du: Convert LVDS encoder code to bridge driver")
Fixes: 4bdb7aa7dcd0 ("ARM: dts: r8a7790: add soc node")
Signed-off-by: Laurent Pinchart
Reviewed-by: Nik
Hello,
This patch series fixes LVDS output support on the Lager, Koelsh, Porter and
Gose boards that broke in v4.17-rc1 due to the combination of the R-Car DU
LVDS driver rework and the DT move of all on-SoC peripherals to a /soc node.
We could handle the problem in the R-Car DU LVDS DT backward
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Fixes: c6a27fa41fab ("drm: rcar-du: Convert LVDS encoder code to bridge driver")
Fixes: bb21803ea440 ("ARM: dts: r8a7791: add soc node")
Signed-off-by: Laurent Pinchart
Reviewed-by: Nik
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Fixes: c6a27fa41fab ("drm: rcar-du: Convert LVDS encoder code to bridge driver")
Fixes: bff8f8c2feb7 ("ARM: dts: r8a7793: add soc node")
Signed-off-by: Laurent Pinchart
Reviewed-by: Nik
On 03/14/2018 11:30 PM, Sergei Shtylyov wrote:
> Add the (previously omitted) EtherAVB pin data to the V3M Starter Kit
> board's device tree.
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> The patch is against the 'renesas-devel-20180314-v4.16-rc5' tag of Simon's
> 'renesas.git repo. It depends o
Hello!
On 03/14/2018 10:58 PM, Sergei Shtylyov wrote:
> Add the (previously omitted) EtherAVB pin data to the Eagle board's
> device tree.
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> The patch is against the 'renesas-devel-20180314-v4.16-rc5' tag of Simon's
> 'renesas.git repo. It depends on
Hi Simon-san,
> From: Simon Horman, Sent: Friday, April 20, 2018 6:55 PM
>
> Hi Shimoda-san,
>
> On Wed, Apr 11, 2018 at 06:37:41PM +0900, Yoshihiro Shimoda wrote:
> > This patch adds basic support for the Renesas R-Car E3 (R8A77990) SoC:
> > - PSCI
> > - CPU (single)
> > - Cache controlle
On Wed, Apr 18, 2018 at 04:58:18PM +0200, Geert Uytterhoeven wrote:
> Minor cleanup of artefacts caused by deriving from r8a7795-sysc.c:
> - Remove unused inclusion of ,
> - Make r8a77995_areas[] const.
>
> Signed-off-by: Geert Uytterhoeven
Thanks, applied.
On Sat, Apr 14, 2018 at 10:28:29PM +0300, Sergei Shtylyov wrote:
> Define the Condor board dependent part of the MMC0 (connected to eMMC chip)
> device node along with the necessary voltage regulators...
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> arch/arm64/boot/dts/renesas/r8a77980-condor.dt
Hi Christoph,
On Fri, Apr 20, 2018 at 10:31 AM, Christoph Hellwig wrote:
> On Wed, Apr 18, 2018 at 03:13:14PM +0200, jacopo mondi wrote:
>> As long as it goes for arch/sh, the only user of dma_alloc_coherent()
>> is platform_resource_setup_memory(), and it has been fixed by this
>> patch.
>
> Gre
On Sat, Apr 14, 2018 at 10:27:04PM +0300, Sergei Shtylyov wrote:
> Define the generic R8A77980 part of the MMC0 (SDHI2) device node.
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> arch/arm64/boot/dts/renesas/r8a77980.dtsi | 12
> 1 file changed, 12 insertions(+)
>
> Index: renesas
Hi Shimoda-san,
On Wed, Apr 11, 2018 at 06:37:41PM +0900, Yoshihiro Shimoda wrote:
> This patch adds basic support for the Renesas R-Car E3 (R8A77990) SoC:
> - PSCI
> - CPU (single)
> - Cache controller
> - Main clocks and controller
> - Interrupt controller
> - Timer
> - PMU
> - R
On Thu, Apr 12, 2018 at 10:14:01AM +0200, Jacopo Mondi wrote:
> Enable HDMI output on Renesas R-Car V3M Eagle board.
>
> The HDMI ouput is enabled connecting the DU LVDS output to the
s/ouput/output/
> transparent LVDS converter THC63LVD1024, and successively routing its
> RGB output to the ADV7
On Thu, Apr 12, 2018 at 10:14:00AM +0200, Jacopo Mondi wrote:
> From: Sergei Shtylyov
>
> Define the generic R8A77970 part of the LVDS device node.
>
> Signed-off-by: Sergei Shtylyov
Thanks, applied.
On Thu, Apr 12, 2018 at 10:13:59AM +0200, Jacopo Mondi wrote:
> From: Sergei Shtylyov
>
> Define the generic R8A77970 part of the DU device node.
>
> Based on the original (and large) patch by Daisuke Matsushita
> .
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
> Review
On Thu, Apr 12, 2018 at 10:13:58AM +0200, Jacopo Mondi wrote:
> From: Sergei Shtylyov
>
> Describe VSPD0 in the R8A77970 device tree; it will be used by DU in
> the next patch...
>
> Based on the original (and large) patch by Daisuke Matsushita
> .
>
> Signed-off-by: Vladimir Barinov
> Signed-
On 18.04.2018 16:40, Jacopo Mondi wrote:
> As I have another series which is based on this one + Eagle board display
> support, I'm re-sending this one to fix the small issue I pointed out in my
> reply to v8.
>
> Simon: no changes to Eagle DTS series, so the last one sent is still the good
> one.
On Fri, 20 Apr 2018, Geert Uytterhoeven wrote:
> On Fri, Apr 20, 2018 at 9:49 AM, Lee Jones wrote:
> > On Wed, 18 Apr 2018, Geert Uytterhoeven wrote:
> >> The ROHM BD9571MWV PMIC on the Renesas Salvator-X(S) and ULCB
> >> development boards supports DDR Backup Power, which means that the DDR
> >>
Am Donnerstag, 19. April 2018, 16:06:19 CEST schrieb Wolfram Sang:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
Acked-by: Marc Dietrich
> ---
>
> Build tested only. buildbot is happy. Pleas
Hi Wolfram
On 04/19/2018 04:06 PM, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Build tested only. buildbot is happy. Please apply individually.
>
> drivers/t
Hello!
On 4/20/2018 10:08 AM, Ulf Hansson wrote:
I've successfully tested eMMC on R8A77980/Condor. R8A77980 has a single
SDHI core anyway, so can't be a subject of the known RX DMA errata...
Should have been s/of/to/, I think.
Lucky you ;)
Signed-off-by: Sergei Shtylyov
Reviewed-by:
On Wed, Apr 18, 2018 at 03:13:14PM +0200, jacopo mondi wrote:
> As long as it goes for arch/sh, the only user of dma_alloc_coherent()
> is platform_resource_setup_memory(), and it has been fixed by this
> patch.
Great!
>
> Unfortunately, as Thomas pointed out, there are drivers which calls
> int
On Tue, Apr 17, 2018 at 03:54:07PM +0200, Thomas Petazzoni wrote:
>
> dma_alloc_coherent(&pdev->dev, memsize, &dma_handle, GFP_KERNEL);
>
> and one to switch to the WARN_ON + if(dev) model. But I don't really
> care either way, so:
>
> Reviewed-by: Thomas Petazzoni
Yes, these should be separ
On 19/04/2018 at 16:06, Wolfram Sang wrote:
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
Acked-by: Nicolas Ferre
---
Build tested only. buildbot is happy. Please apply individually.
drivers/
Hi Lee,
On Fri, Apr 20, 2018 at 9:49 AM, Lee Jones wrote:
> On Wed, 18 Apr 2018, Geert Uytterhoeven wrote:
>> The ROHM BD9571MWV PMIC on the Renesas Salvator-X(S) and ULCB
>> development boards supports DDR Backup Power, which means that the DDR
>> power rails can be kept powered while the main S
On 19/04/2018 at 16:06, Wolfram Sang wrote:
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
Acked-by: Nicolas Ferre
---
Build tested only. buildbot is happy. Please apply individually.
sound/so
On Wed, 18 Apr 2018, Geert Uytterhoeven wrote:
> Hi all,
>
> The ROHM BD9571MWV PMIC on the Renesas Salvator-X(S) and ULCB
> development boards supports DDR Backup Power, which means that the DDR
> power rails can be kept powered while the main SoC is powered down.
Should this set be appli
hi,
On Thu, 2018-04-19 at 16:06 +0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Build tested only. buildbot is happy. Please apply individually.
>
> driver
On 19.4.2018 16:06, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Build tested only. buildbot is happy. Please apply individually.
>
> drivers/rtc/rtc-bq4802.c
On 19.4.2018 16:06, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Build tested only. buildbot is happy. Please apply individually.
>
> drivers/tty/serial/imx.c
On 19.4.2018 16:06, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Build tested only. buildbot is happy. Please apply individually.
>
> drivers/spi/spi-cadence.c
On Thu, Apr 19, 2018 at 04:06:17PM +0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
Acked-by: Johan Hovold
On 19.4.2018 16:06, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Build tested only. buildbot is happy. Please apply individually.
>
> drivers/watchdog/cadence_w
Hi Wolfram,
On 19.4.2018 16:05, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Build tested only. buildbot is happy. Please apply individually.
>
> drivers/gpio/
> (I'm not sure what you mean by "Please apply individually")
Right, that is not very precise. "Individually" as "per subsystem
individually". I.e. I don't want to collect tags and push it upstream as
one huge pull-request.
Thanks!
signature.asc
Description: PGP signature
On 19 April 2018 at 16:05, Wolfram Sang
wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
Thanks, applied for next!
Kind regards
Uffe
> ---
>
> Build tested only. buildbot is happy. Please
On 19 April 2018 at 22:09, Wolfram Sang wrote:
> On Thu, Apr 19, 2018 at 11:07:44PM +0300, Sergei Shtylyov wrote:
>> I've successfully tested eMMC on R8A77980/Condor. R8A77980 has a single
>> SDHI core anyway, so can't be a subject of the known RX DMA errata...
>
> Lucky you ;)
>
>> Signed-off-by:
93 matches
Mail list logo