Use newly added R-Car SDHI Gen1 fallback compat string
in the DT of the r8a7778 SoC.
This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.
Signed-off-by: Simon Horman
---
arch/arm/boot/dts/r8a7778.dtsi | 9
Use newly added R-Car SDHI Gen2 fallback compat string
in the DT of the r8a7793 SoC.
This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.
Signed-off-by: Simon Horman
---
arch/arm/boot/dts/r8a7793.dtsi | 9
Use newly added R-Car SDHI Gen2 fallback compat string
in the DT of the r8a7794 SoC.
This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.
Signed-off-by: Simon Horman
---
arch/arm/boot/dts/r8a7794.dtsi | 9
Use newly added R-Car SDHI Gen2 fallback compat string
in the DT of the r8a7791 SoC.
This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.
Signed-off-by: Simon Horman
---
arch/arm/boot/dts/r8a7791.dtsi | 9
Use newly added R-Car SDHI Gen1 fallback compat string
in the DT of the r8a7779 SoC.
This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.
Signed-off-by: Simon Horman
---
arch/arm/boot/dts/r8a7779.dtsi | 12 +++
Use recently posted R-Car SDHI Gen 1, 2 and 3 fallback compat strings
in the DT of Renesas ARM and arm64 based SoCs.
Based on renesas-devel-20171016-v4.14-rc5
Has a binding documentation but no run-time dependency on
"[PATCH v3 0/3] mmc: renesas_sdhi: add R-Car Gen[123] fallback
compatib
Use newly added R-Car SDHI Gen2 fallback compat string
in the DT of the r8a7790 SoC.
This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.
Signed-off-by: Simon Horman
---
arch/arm/boot/dts/r8a7790.dtsi | 12 +++
Use newly added R-Car SDHI Gen2 fallback compat string
in the DT of the r8a7792 SoC.
This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.
Signed-off-by: Simon Horman
---
arch/arm/boot/dts/r8a7792.dtsi | 3 ++-
Use newly added R-Car SDHI Gen2 fallback compat string
in the DT of the r8a7745 SoC.
This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.
Signed-off-by: Simon Horman
---
arch/arm/boot/dts/r8a7745.dtsi | 9
Use newly added R-Car SDHI Gen3 fallback compat string
in the DT of the r8a7795 SoC.
This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.
Signed-off-by: Simon Horman
---
arch/arm64/boot/dts/renesas/r8a7795.dts
Use newly added R-Car SDHI Gen2 fallback compat string
in the DT of the r8a7743 SoC.
This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.
Signed-off-by: Simon Horman
---
arch/arm/boot/dts/r8a7743.dtsi | 9
Use newly added R-Car SDHI Gen3 fallback compat string
in the DT of the r8a7796 SoC.
This should have no run-time effect as the driver matches against
the per-SoC compat string before considering the fallback compat string.
Signed-off-by: Simon Horman
---
arch/arm64/boot/dts/renesas/r8a7796.dts
Hi Dirk-san,
> From: Dirk Behme, Sent: Tuesday, October 17, 2017 2:08 PM
>
> Limiting the thread to Renesas only, again, to discuss the other issue:
>
> On 17.10.2017 06:51, Yoshihiro Shimoda wrote:
> > Hi Linus-san,
> >
> >> From: Linus Walleij, Sent: Monday, October 16, 2017 9:22 PM
> >>
> >>
Provide an example of the usage of the DT bindings for TMIO
in their documentation. The example given is for the r8a7790 (R-Car H2).
Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
---
v3
* Updated example to newer upstream DTS which uses newer CPG/MSSR bindings.
v2
* Correct descri
Add fallback compatibility strings for R-Car Gen 1, 2 and 3.
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
between IP blocks might be. For example, I believe that r8a7790 is older
than r8a7791
Add fallback compatibility strings for R-Car Gen 1, 2 and 3 to the SDHI
bindings and driver.
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
between IP blocks might be. For example, I believe th
Implement fallback compatibility strings for R-Car Gen 1, 2 and 3.
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
between IP blocks might be. For example, I believe that r8a7790 is older
than r
Limiting the thread to Renesas only, again, to discuss the other issue:
On 17.10.2017 06:51, Yoshihiro Shimoda wrote:
Hi Linus-san,
From: Linus Walleij, Sent: Monday, October 16, 2017 9:22 PM
On Mon, Oct 16, 2017 at 2:07 PM, Geert Uytterhoeven
wrote:
On Mon, Oct 16, 2017 at 1:41 PM, Linus
Hi Linus-san,
> From: Linus Walleij, Sent: Monday, October 16, 2017 9:22 PM
>
> On Mon, Oct 16, 2017 at 2:07 PM, Geert Uytterhoeven
> wrote:
> > On Mon, Oct 16, 2017 at 1:41 PM, Linus Walleij
> > wrote:
> >> On Mon, Oct 16, 2017 at 11:02 AM, Geert Uytterhoeven
> >> wrote:
> IIUC,
>
Hi Biju-san,
IIUC, when we submitted a patch for dts[i] file,
we don't need to submit such a patch to usb maintainers.
> From: Biju Das, Sent: Monday, October 16, 2017 7:13 PM
>
> From: Fabrizio Castro
>
> Add node for xhci. Boards DT files will enable it if needed.
>
> Signed-off-by: Fabrizi
Hi Biju-san,
(and added Mathias-san of the XHCI maintainer as TO)
Thank you for the patch!
> From: Biju Das, Sent: Monday, October 16, 2017 7:13 PM
>
> From: Fabrizio Castro
>
> Document r8a7743 xhci support. The driver will use the fallback
> compatible string "renesas,rcar-gen2-xhci", theref
On Fri, Oct 13, 2017 at 02:35:28PM +0200, Simon Horman wrote:
> On Fri, Oct 13, 2017 at 01:19:20PM +0200, Geert Uytterhoeven wrote:
> > Hi Simon,
> >
> > On Fri, Oct 13, 2017 at 12:38 PM, Simon Horman
> > wrote:
> > > Provide an example of the usage of the DT bindings for TMIO
> > > in their docu
> + When compatible with the generic version nodes must list
comma after "version"? I had to read it multiple times until I got it :)
> + the SoC-specific version corresponding to the platform
> + first followed by the generic version.
signature.asc
Descript
On Mon, Oct 16, 2017 at 04:52:59PM +0200, Niklas Söderlund wrote:
> The initialization sequence for H3 (r8a7795) ES1.x and ES2.0 is
> different. H3 ES2.0 and later uses the same sequence as M3 (r8a7796)
> ES1.0. Fix this by not looking at compatible strings and instead
> defaulting to the r8a7796 i
On 10/16/2017 04:55 PM, Geert Uytterhoeven wrote:
Currently, if Wake-on-LAN is enabled, the EtherAVB device's module clock
is manually kept running during system suspend, to make sure the device
stays active.
Since "soc: renesas: rcar-sysc: Keep wakeup sources active during system
suspend", thi
Hello!
On 10/16/2017 04:55 PM, Geert Uytterhoeven wrote:
Currently, if Wake-on-LAN is enabled, the SH-ETH device's module clock
It's called Ether (or GEther) in all the manuals I have. Never saw SH-ETH,
I think it's Nobuhiro's invention... :-)
is manually kept running during system sus
Most systems with this i2c are going to have a clock of either 33.33MHz or
32MHz. That 4% difference is not reason enough to warrant that the driver
to completely fail.
Signed-off-by: Chris Brandt
---
v3:
* now check a range of safe frequencies
v2:
* simplified error message.
---
---
drivers/i
Hi Wolfram,
On Friday, October 13, 2017, Wolfram Sang wrote:
> > Technically, to do it right, to calculate the ACTUAL I2C baud rate, you
> > have to take into effect the load resistance and capacitance of the
> > lines in order to factor in the rise and fall times correctly. Of course
>
> We have
Hi Niklas,
On Mon, Oct 16, 2017 at 4:52 PM, Niklas Söderlund
wrote:
> The initialization sequence for H3 (r8a7795) ES1.x and ES2.0 is
> different. H3 ES2.0 and later uses the same sequence as M3 (r8a7796)
> ES1.0. Fix this by not looking at compatible strings and instead
> defaulting to the r8a77
Hi,
I forgot the changes from v1, sorry about that.
On 2017-10-16 16:52:59 +0200, Niklas Söderlund wrote:
> The initialization sequence for H3 (r8a7795) ES1.x and ES2.0 is
> different. H3 ES2.0 and later uses the same sequence as M3 (r8a7796)
> ES1.0. Fix this by not looking at compatible strings
All users of sh_pfc_pin_to_bias_info() and the related data structures
have been converted to sh_pfc_pin_to_bias_reg(), so those can be
removed.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
v2:
- Add Reviewed-by.
---
drivers/pinctrl/sh-pfc/core.c | 15 ---
Move R-Car H3 ES1.x I/O voltage support over to the generic way to
describe IOCTRL registers, which will be needed for suspend/resume
support.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Add a sentinel comment, to make it more explicit that a last zero
entry is required.
---
drivers/pinctr
Move R-Car H3 ES2.0 I/O voltage support over to the generic way to
describe IOCTRL registers, which will be needed for suspend/resume
support.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Add a sentinel comment, to make it more explicit that a last zero
entry is required.
---
drivers/pinctr
Move R-Car M3-W bias support over to the generic way to describe bias
registers, which will be needed for suspend/resume support.
As the new description is more compact, this decreases kernel size by
ca. 304 bytes.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Add a sentinel comment, to make it
During PSCI system suspend, R-Car Gen3 SoCs are powered down, and their
pinctrl register state is lost. Note that as the boot loader skips most
initialization after system resume, pinctrl register state differs from
the state encountered during normal system boot, too.
To fix this, save all GPIO
Add a generic way to describe IOCTRL registers (for e.g. SD I/O voltage
and time delay control), like is already done for config, drive, and
bias registers.
This makes the sh-pfc core code aware of these registers, which will
ease introducing suspend/resume support later.
Signed-off-by: Geert Uyt
As of commit 8682b3c522c639f3 ("sh-pfc: Remove platform device
registration"), plain "sh-pfc" platform devices are no longer created.
Hence remove their match entry, and the now obsolete checks for missing
device IDs and driver data.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
Hi all,
During PSCI system suspend, R-Car Gen3 SoCs are powered down, and their
pinctrl register state is lost. Note that as the boot loader skips most
initialization after system resume, pinctrl register state differs from
the state encountered during normal system boot, too.
To fix thi
Add a generic way to describe bias registers (for pull-up/down control),
like is already done for config and drive registers.
This makes the sh-pfc core code aware of these registers, which will
ease introducing suspend/resume support later.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent
Move R-Car H3 ES1.x bias support over to the generic way to describe
bias registers, which will be needed for suspend/resume support.
As the new description is more compact, this decreases kernel size by
ca. 304 bytes.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
v2:
-
Move R-Car H3 ES2.0 bias support over to the generic way to describe
bias registers, which will be needed for suspend/resume support.
As the new description is more compact, this decreases kernel size by
ca. 308 bytes.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Add a sentinel comment, to make
Move R-Car M1A bias support over to the generic way to describe bias
registers.
As the new description is more compact, this decreases kernel size by
ca. 148 bytes.
Signed-off-by: Geert Uytterhoeven
---
Untested due to lack of hardware.
v2:
- Add a sentinel comment, to make it more explicit t
On modern Renesas SoCs, all PFC registers are 32-bit, and all callers of
sh_pfc_{read,write}_reg() already operate on 32-bit registers only.
Hence make the 32-bit width implicit, and rename the functions to
sh_pfc_{read,write}() to shorten lines.
All accesses to 8-bit or 16-bit registers are still
Move R-Car M3-W I/O voltage support over to the generic way to describe
IOCTRL registers, which will be needed for suspend/resume support.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Add a sentinel comment, to make it more explicit that a last zero
entry is required.
---
drivers/pinctrl/sh
Add a helper to look up bias registers and bit number for a specific
pin, using the generic bias register description.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Use ARRAY_SIZE() instead of hardcoded constant 32,
- Add curly braces to nested for statements.
---
drivers/pinctrl/sh-pfc/core.c
Hi Geert,
On 2017-10-16 15:55:16 +0200, Geert Uytterhoeven wrote:
> Currently, if Wake-on-LAN is enabled, the SH-ETH device's module clock
> is manually kept running during system suspend, to make sure the device
> stays active.
>
> Since "soc: renesas: rcar-sysc: Keep wakeup sources active durin
Hi Geert,
On 2017-10-16 15:55:15 +0200, Geert Uytterhoeven wrote:
> Currently, if Wake-on-LAN is enabled, the EtherAVB device's module clock
> is manually kept running during system suspend, to make sure the device
> stays active.
>
> Since "soc: renesas: rcar-sysc: Keep wakeup sources active dur
The initialization sequence for H3 (r8a7795) ES1.x and ES2.0 is
different. H3 ES2.0 and later uses the same sequence as M3 (r8a7796)
ES1.0. Fix this by not looking at compatible strings and instead
defaulting to the r8a7796 initialization sequence and use
soc_device_match() to check for H3 ES1.x.
On Fri, Oct 13, 2017 at 4:49 PM, Biju Das wrote:
> Voltage switching is the same as on the r8a7794.
>
> Signed-off-by: Biju Das
Reviewed-by: Geert Uytterhoeven
i.e. will queue in sh-pfc-for-v4.15.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux
Set the newly introduced GENPD_FLAG_ACTIVE_WAKEUP, which allows to
remove the driver's own "always true" callback.
Signed-off-by: Geert Uytterhoeven
---
This must not be applied before "PM / Domain: Enable genpd users to
specify default active wakeup behavior" has landed upstream, hence the
"RFC"
Hi all,
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 device is
Set the newly introduced GENPD_FLAG_ACTIVE_WAKEUP, which allows to
remove the driver's own "always true" callback.
Signed-off-by: Geert Uytterhoeven
---
This must not be applied before "PM / Domain: Enable genpd users to
specify default active wakeup behavior" has landed upstream, hence the
"RFC"
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
Set the newly introduced GENPD_FLAG_ACTIVE_WAKEUP, which allows to
remove the driver's own "always true" callback.
Signed-off-by: Geert Uytterhoeven
---
This must not be applied before "PM / Domain: Enable genpd users to
specify default active wakeup behavior" has landed upstream, hence the
"RFC"
Currently, if Wake-on-LAN is enabled, the SH-ETH device's module clock
is manually kept running during system suspend, to make sure the device
stays active.
Since "soc: renesas: rcar-sysc: Keep wakeup sources active during system
suspend" and "clk: renesas: mstp: Keep wakeup sources active during
It is quite common for PM Domains to require slave devices to be kept
active during system suspend if they are to be used as wakeup sources.
To enable this, currently each PM Domain or driver has to provide its
own gpd_dev_ops.active_wakeup() callback.
Introduce a new flag GENPD_FLAG_ACTIVE_WAKEUP
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
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
Set the newly introduced GENPD_FLAG_ACTIVE_WAKEUP, which allows to
remove the driver's own "always true" callback.
Signed-off-by: Geert Uytterhoeven
---
This must not be applied before "PM / Domain: Enable genpd users to
specify default active wakeup behavior" has landed upstream, hence the
"RFC"
Currently, if Wake-on-LAN is enabled, the EtherAVB device's module clock
is manually kept running during system suspend, to make sure the device
stays active.
Since "soc: renesas: rcar-sysc: Keep wakeup sources active during system
suspend", this workaround is no longer needed. Hence remove all
e
Hi Robin,
On Tue, Jun 20, 2017 at 2:19 AM, Robin Murphy wrote:
> On 19/06/17 10:14, Magnus Damm wrote:
>> From: Magnus Damm
>>
>> Add root device handling to the IPMMU driver by allowing certain
>> DT compat strings to enable has_cache_leaf_nodes that in turn will
>> support both root devices wi
Hi Fabrizio,
Thank you for the patch.
On Friday, 13 October 2017 18:22:22 EEST Fabrizio Castro wrote:
> Add support for the R8A7745 DU (which is very similar to the R8A7794 DU);
> it has 2 RGB outputs.
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Biju Das
Reviewed-by: Laurent Pinchart
Hi Fabrizio,
Thank you for the patch.
On Friday, 13 October 2017 18:22:20 EEST Fabrizio Castro wrote:
> Add support for the R8A7743 DU (which is very similar to the R8A7791 DU);
> it has 1 DPAD (RGB) output and 1 LVDS output.
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Biju Das
Reviewed
From: Magnus Damm
The r8a7795 IPMMU supports 40-bit bus mastering. Both
the coherent DMA mask and the streaming DMA mask are
set to unlock the 40-bit address space for coherent
allocations and streaming operations.
Signed-off-by: Magnus Damm
---
Changes since V4:
- None
Changes since V3:
From: Magnus Damm
Introduce support for two bit SL0 bitfield in IMTTBCR
by using a separate feature flag.
Signed-off-by: Magnus Damm
---
Changes since V4:
- Use leaf node mmu instead of root
Changes since V3:
- None
Changes since V2:
- None
Changes since V1:
- None
drivers/iommu/i
From: Magnus Damm
Hook up IOMMU_OF_DECLARE() support in case CONFIG_IOMMU_DMA
is enabled. The only current supported case for 32-bit ARM
is disabled, however for 64-bit ARM usage of OF is required.
Signed-off-by: Magnus Damm
---
Changes since V4:
- Use ipmmu_is_root() instead of now removed
From: Magnus Damm
Write IMCTR both in the root device and the leaf node.
To allow access of IMCTR introduce the following function:
- ipmmu_ctx_write_all()
While at it also rename context functions:
- ipmmu_ctx_read() -> ipmmu_ctx_read_root()
- ipmmu_ctx_write() -> ipmmu_ctx_write_root()
Si
From: Magnus Damm
Add support for up to 8 contexts. Each context is mapped to one
domain. One domain is assigned one or more slave devices. Contexts
are allocated dynamically and slave devices are grouped together
based on which IPMMU device they are connected to. This makes slave
devices tied to
From: Magnus Damm
Tie in r8a7795 features and update the IOMMU_OF_DECLARE
compat string to include the updated compat string.
Signed-off-by: Magnus Damm
---
Changes since V4:
- Got rid of root device availability check in ->xlate()
-> deferred probing is used to make sure the root is alwa
From: Magnus Damm
Introduce a feature to allow opt-out of setting up
IMBUSCR. The default case is unchanged.
Signed-off-by: Magnus Damm
---
Changes since V4:
- Use leaf node mmu instead of root
Changes since V3:
- None
Changes since V2:
- None
Changes since V1:
- Updated the commit
From: Magnus Damm
Introduce struct ipmmu_features to track various hardware
and software implementation changes inside the driver for
different kinds of IPMMU hardware. Add use_ns_alias_offset
as a first example of a feature to control if the secure
register bank offset should be used or not.
Si
From: Magnus Damm
Add root device handling to the IPMMU driver by allowing certain
DT compat strings to enable has_cache_leaf_nodes that in turn will
support both root devices with interrupts and leaf devices that
face the actual IPMMU consumer devices.
Signed-off-by: Magnus Damm
---
Changes
iommu/ipmmu-vmsa: r8a7795 support V5
[PATCH v5 01/09] iommu/ipmmu-vmsa: Introduce features, break out alias
[PATCH v5 02/09] iommu/ipmmu-vmsa: Add optional root device feature
[PATCH v5 03/09] iommu/ipmmu-vmsa: Enable multi context support
[PATCH v5 04/09] iommu/ipmmu-vmsa: Make use of IOMMU_OF_DE
On Sun, Oct 15, 2017 at 10:04:16AM +0200, Geert Uytterhoeven wrote:
> On Sat, Oct 14, 2017 at 4:14 PM, Russell King - ARM Linux
> wrote:
> > Thanks, it would've been good to have known that ahead of time.
> >
> > It's why the patch system has the KernelVersion: tag:
> >
> > 6. Kernel version.
> >
On Mon, Oct 16, 2017 at 2:07 PM, Geert Uytterhoeven
wrote:
> On Mon, Oct 16, 2017 at 1:41 PM, Linus Walleij
> wrote:
>> On Mon, Oct 16, 2017 at 11:02 AM, Geert Uytterhoeven
>> wrote:
IIUC,
- Since the MMC_BOUNCE disappeared in v4.14-rc1, the MMC core will request
a command with
Hi Linus,
On Mon, Oct 16, 2017 at 1:41 PM, Linus Walleij wrote:
> On Mon, Oct 16, 2017 at 11:02 AM, Geert Uytterhoeven
> wrote:
>>> IIUC,
>>> - Since the MMC_BOUNCE disappeared in v4.14-rc1, the MMC core will request
>>> a command with 64kbyte+ size.
>>> - So, swiotlb will got request 64kbyte+
On Mon, Oct 16, 2017 at 11:02 AM, Geert Uytterhoeven
wrote:
>> IIUC,
>> - Since the MMC_BOUNCE disappeared in v4.14-rc1, the MMC core will request a
>> command with 64kbyte+ size.
>> - So, swiotlb will got request 64kbyte+ size. This is different with
>> previous version.
Other people reporte
Hello Kishon,
> From: Biju Das [mailto:biju@bp.renesas.com]
> Sent: 09 October 2017 11:22
>
> Add USB PHY support for r8a7743/5 SoC. Renesas RZ/G1[ME] (R8A7743/5)
> USB PHY is identical to the R-Car Gen2 family.
>
> Signed-off-by: Biju Das
> Acked-by: Simon Horman
> Acked-by: Rob Herring
Hello,
This series aims to add USB XHCI support for iWave RZ/G1M (R8A7743) board.
This series has been tested against renesas-dev tag 20171013-v4.14-rc4.
Regards,
Fabrizio Castro (2):
dt-bindings: usb-xhci: Document r8a7743 support
ARM: dts: r8a7743: Add xhci support to SoC dtsi
Documentat
From: Fabrizio Castro
Document r8a7743 xhci support. The driver will use the fallback
compatible string "renesas,rcar-gen2-xhci", therefore no driver
change is needed.
Signed-off-by: Fabrizio Castro
---
Documentation/devicetree/bindings/usb/usb-xhci.txt | 4 +++-
1 file changed, 3 insertions(+
From: Fabrizio Castro
Add node for xhci. Boards DT files will enable it if needed.
Signed-off-by: Fabrizio Castro
---
arch/arm/boot/dts/r8a7743.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 6
On Thu, Oct 12, 2017 at 11:35:03AM +0200, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> This series improves DT hardware descriptions for Renesas arm32 SoCs by
> adding missing clocks properties to the device nodes corresponding to
> ARM CPU cores.
>
> Notes:
> - This series should ha
On Thu, Oct 12, 2017 at 11:35:11AM +0200, Geert Uytterhoeven wrote:
> Currently only the CPU cores in the CA15 cluster have clocks properties.
> Add the missing clocks properties for the CPU cores in the CA7 cluster
> to fix this.
>
> Signed-off-by: Geert Uytterhoeven
Tested-by: Simon Horman
On Thu, Oct 12, 2017 at 11:35:10AM +0200, Geert Uytterhoeven wrote:
> Currently only the primary CPU in the CA15 cluster has a clocks
> property, while the secondary CPU cores are driven by the same clock.
> Add the missing clocks properties to fix this.
>
> Signed-off-by: Geert Uytterhoeven
Tes
Hi Fabrizio,
Thank you for the patch.
On Friday, 13 October 2017 18:22:19 EEST Fabrizio Castro wrote:
> Add device tree bindings for r8a7743 and r8a7745 DUs.
> r8a7743 DU is similar to the one from r8a7791, r8a7745 DU is similar
> to the one from r8a7794.
>
> Signed-off-by: Fabrizio Castro
> Re
Hi Simon,
On Mon, Oct 16, 2017 at 9:58 AM, Simon Horman
wrote:
> Provide an example of the usage of the DT bindings for TMIO
> in their documentation. The example given is for the r8a7790 (R-Car H2).
>
> Signed-off-by: Simon Horman
> ---
> v2
> * Correct description of example, it is for the r8a
During PSCI system suspend, R-Car Gen3 SoCs are powered down, and their
clock register state is lost. Note that as the boot loader skips most
initialization after system resume, clock register state differs from
the state encountered during normal system boot, too.
Hence after s2ram, some operati
On R-Car Gen3 systems, PSCI system suspend powers down the SoC, possibly
losing clock configuration. Hence add a notifier chain that can be used
by core clocks to save/restore clock state during system suspend/resume.
The implementation of the actual clock state save/restore operations is
clock-s
On R-Car Gen3 systems, PSCI system suspend powers down the SoC, losing
clock configuration. Register an (optional) notifier to restore the
DIV6 clock state during system resume.
As DIV6 clocks can be picky w.r.t. modifying multiple register fields at
once, restore is not implemented by blindly re
Hi Mike, Stephen,
During PSCI system suspend, R-Car Gen3 SoCs are powered down, and their
clock register state is lost. Note that as the boot loader skips most
initialization after resume, clock register state differs from the state
encountered during normal system boot, too.
Hence after
On R-Car Gen3 systems, PSCI system suspend powers down the SoC, losing
clock configuration. Register a notifier to save/restore SDHI clock
registers during system suspend/resume.
This is implemented using the cpg_simple_notifier abstraction, which can
be reused for others clocks that just need to
Add a defconfig for Renesas R-Car Gen3 boards.
Signed-off-by: Geert Uytterhoeven
---
Against renesas-devel-20171013-v4.14-rc4.
Not intended for upstream merge.
Loosely based on arm64 defconfig, with support for non-Renesas SoCs and
boards removed, and missing support added.
Simon, if you includ
On R-Car Gen3 systems, PSCI system suspend powers down the SoC, losing
clock configuration. Register a notifier to save/restore the RCKCR
register during system suspend/resume.
Signed-off-by: Geert Uytterhoeven
Tested-by: Niklas Söderlund
---
v3:
- Drop RFC state,
- Add Tested-by,
v2:
-
CC LinusW, Ulf, linux-mmc
On Mon, Oct 16, 2017 at 10:36 AM, Yoshihiro Shimoda
wrote:
>> From: Dirk Behme, Sent: Thursday, October 12, 2017 6:13 PM
>> On 12.10.2017 10:20, Dirk Behme wrote:
>> > On 11.10.2017 15:20, Geert Uytterhoeven wrote:
>> >> On Wed, Oct 11, 2017 at 2:57 PM, Dirk Behme
>> >>
Hi Dirk-san,
> From: Dirk Behme, Sent: Thursday, October 12, 2017 6:13 PM
>
> On 12.10.2017 10:20, Dirk Behme wrote:
> > On 11.10.2017 15:20, Geert Uytterhoeven wrote:
> >> Hi Dirk,
> >>
> >> On Wed, Oct 11, 2017 at 2:57 PM, Dirk Behme
> >> wrote:
> >>> On 11.10.2017 14:42, Geert Uytterhoeven wr
Hi,
Looks like the chosen node "stdout-path = "serial0:115200n8";" is not updated
with this patch.
So either drop the patch or fix the chosen node.
Regards,
Biju
> -Original Message-
> From: Fabrizio Castro [mailto:fabrizio.cas...@bp.renesas.com]
> Sent: 13 October 2017 14:03
> To: Rob
Add fallback compatibility strings for R-Car Gen 1, 2 and 3 to the SDHI
bindings and driver.
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
between IP blocks might be. For example, I believe th
Add fallback compatibility strings for R-Car Gen 1, 2 and 3.
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
between IP blocks might be. For example, I believe that r8a7790 is older
than r8a7791
Implement fallback compatibility strings for R-Car Gen 1, 2 and 3.
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
between IP blocks might be. For example, I believe that r8a7790 is older
than r
Provide an example of the usage of the DT bindings for TMIO
in their documentation. The example given is for the r8a7790 (R-Car H2).
Signed-off-by: Simon Horman
---
v2
* Correct description of example, it is for the r8a7790 (R-Car H2)
rather than the r8a7779 (R-Car H1)
---
Documentation/device
1 - 100 of 107 matches
Mail list logo
