Re: ravb: Possible Regression In "net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS"

[Simon Horman]

Hi Florian,

On Mon, Feb 15, 2016 at 09:08:46PM -0800, Florian Fainelli wrote:
> On February 15, 2016 7:26:46 PM PST, Simon Horman  wrote:
> >Hi Florian,
> >
> >I have observed what appears to be a regression in the ravb ethernet
> >driver
> >caused by d5c3d84657db ("net: phy: Avoid polling PHY with
> >PHY_IGNORE_INTERRUPTS").
> >
> >When booting net-next configured with the ARM64 defconfig on the
> >Renesas
> >r8a7795/salvator-x I see the following and the ravb is unable to access
> >the
> >network. With the above mentioned patch reverted I am able to boot to
> >user-space using nfsroot.
> 
> Thanks for the report, I will take a closer look tomorrow, can you test 
> patches easily on top of 4.5-rc on this platform?

Thanks.

Yes, I can easily test patches. The platform is supported in mainline as of
v4.5-rc (this problem aside) and I have access to a board.

ravb: Possible Regression In "net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS"

[Simon Horman]

Hi Florian,

I have observed what appears to be a regression in the ravb ethernet driver
caused by d5c3d84657db ("net: phy: Avoid polling PHY with
PHY_IGNORE_INTERRUPTS").

When booting net-next configured with the ARM64 defconfig on the Renesas
r8a7795/salvator-x I see the following and the ravb is unable to access the
network. With the above mentioned patch reverted I am able to boot to
user-space using nfsroot.


[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.5.0-rc2+ 
(ho...@ayumi.isobedori.kobe.vergenet.net) (gcc version 4.8.5 (Linaro GCC 
4.8-2015.06) ) #90 SMP PREEMPT Tue Feb 16 12:22:08 JST 2016
[0.00] Boot CPU: AArch64 Processor [411fd073]
[0.00] debug: ignoring loglevel setting.
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 16 MiB at 0x7f00
[0.00] On node 0 totalpages: 229376
[0.00]   DMA zone: 3584 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 229376 pages, LIFO batch:31
[0.00] psci: probing for conduit method from DT.
[0.00] psci: PSCIv1.0 detected in firmware.
[0.00] psci: Using standard PSCI v0.2 function IDs
[0.00] psci: Trusted OS migration not required
[0.00] PERCPU: Embedded 20 pages/cpu @ffc036f8f000 s42496 r8192 
d31232 u81920
[0.00] pcpu-alloc: s42496 r8192 d31232 u81920 alloc=20*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
[0.00] Detected PIPT I-cache on CPU0
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 225792
[0.00] Kernel command line: ignore_loglevel rw root=/dev/nfs ip=dhcp 
nfsroot=10.3.3.135:/srv/nfs/salvator-x-arm64
[0.00] log_buf_len individual max cpu contribution: 4096 bytes
[0.00] log_buf_len total cpu_extra contributions: 12288 bytes
[0.00] log_buf_len min size: 16384 bytes
[0.00] log_buf_len: 32768 bytes
[0.00] early log buf free: 14796(90%)
[0.00] PID hash table entries: 4096 (order: 3, 32768 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[0.00] software IO TLB [mem 0x79c0-0x7dc0] (64MB) mapped at 
[ffc031c0-ffc035bf]
[0.00] Memory: 805744K/917504K available (6468K kernel code, 593K 
rwdata, 2900K rodata, 724K init, 242K bss, 95376K reserved, 16384K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] vmalloc : 0xff80 - 0xffbdbfff   (   246 
GB)
[0.00] vmemmap : 0xffbdc000 - 0xffbfc000   ( 8 
GB maximum)
[0.00]   0xffbdc120 - 0xffbdc200   (14 
MB actual)
[0.00] fixed   : 0xffbffa7fd000 - 0xffbffac0   (  4108 
KB)
[0.00] PCI I/O : 0xffbffae0 - 0xffbffbe0   (16 
MB)
[0.00] modules : 0xffbffc00 - 0xffc0   (64 
MB)
[0.00] memory  : 0xffc0 - 0xffc03800   (   896 
MB)
[0.00]   .init : 0xffc0009a9000 - 0xffc000a5e000   (   724 
KB)
[0.00]   .text : 0xffc8 - 0xffc0009a8244   (  9377 
KB)
[0.00]   .data : 0xffc000a5e000 - 0xffc000af2600   (   594 
KB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] Preemptible hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 64.
[0.00]  RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=4
[0.00] NR_IRQS:64 nr_irqs:64 0
[0.00] Architected cp15 timer(s) running at 16.66MHz (virt).
[0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0x3d7a162dd, max_idle_ns: 440795202225 ns
[0.01] sched_clock: 56 bits at 16MHz, resolution 60ns, wraps every 
219902321ns
[0.55] Console: colour dummy device 80x25
[0.000217] console [tty0] enabled
[0.000229] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 33.32 BogoMIPS (lpj=66640)
[0.000238] pid_max: default: 32768 minimum: 301
[0.000263] Security Framework initialized
[0.000278] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
[0.000283] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes)
[0.000678] ASID allocator initialised with 65536 entries
[0.020145] EFI services will not be available.
[0.036098] Detected PIPT I-cache on CPU1
[0.036121] CPU1: Booted secondary processor [411fd073]
[0.048089] Detected PIPT I-cache on CPU2
[0.048097] CPU2: Booted secondary processor [411fd073]
[0.060095] Detected PIPT I-cache on CPU3
[0.060104] CPU3: Booted secondary processor 

[PATCH/RFC] arm64: dts: r8a7795: Salvator-X INTC-EX IRQ2 test prototype

[Magnus Damm]

From: Magnus Damm 

This patch is a prototype hack that can be used to test INTC-EX
using the IRQ2 signal on r8a7795 Salvator-X with a loop back
adapter.

The external loop back adapter is connected to EXIO_D and
connects pin 9 (IRQ2/GP2_02) and pin 26 (ExA22/GP2_06).

To test enable CONFIG_GPIO_SYSFS and CONFIG_KEYBOARD_GPIO and
export GP2_06 via /sys/class/gpio/export and then change the
value of the pin and see how interrupt debug messages are
output on the console from the irq-renesas-irqc.c driver.

Not for upstream merge.

Not-Yet-Signed-off-by: Magnus Damm 
---

Written on top of renesas-drivers-2016-02-09-v4.5-rc3 and

 [PATCH 00/02] arm64: r8a7795 INTC-EX support using RENESAS_IRQC
 [PATCH 01/02] arm64: dts: r8a7795: Add INTC-EX device node
 [PATCH 02/02] arm64: renesas: Enable RENESAS_IRQC
 [PATCH] pinctrl: sh-pfc: r8a7795: Add support for INTC-EX IRQ pins
 [PATCH] clk: shmobile: r8a7795: Add INTC-EX clock

 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |   31 
 drivers/irqchip/irq-renesas-irqc.c |2 -
 2 files changed, 32 insertions(+), 1 deletion(-)

--- 0001/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ work/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 2016-02-16 
11:32:50.420513000 +0900
@@ -33,6 +33,8 @@
 
 /dts-v1/;
 #include "r8a7795.dtsi"
+#include 
+#include 
 
 / {
model = "Renesas Salvator-X board based on r8a7795";
@@ -55,6 +57,30 @@
reg = <0x0 0x4800 0x0 0x3800>;
};
 
+   keyboard {
+   compatible = "gpio-keys";
+
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   button@1 {
+   linux,code = ;
+   label = "SW21";
+   wakeup-source;
+   debounce-interval = <20>;
+   gpios = < 12 GPIO_ACTIVE_LOW>;
+   };
+   button@2 {
+   linux,code = ;
+   label = "SW22";
+   wakeup-source;
+   debounce-interval = <20>;
+   gpios = < 13 GPIO_ACTIVE_LOW>;
+   interrupt-parent = <_ex>;
+   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+   };
+   };
+
x12_clk: x12_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -96,6 +122,11 @@
pinctrl-0 = <_clk_pins>;
pinctrl-names = "default";
 
+   gpiokey_pins: gpiokey1 {
+   renesas,groups = "intc_ex_irq2";
+   renesas,function = "intc_ex";
+   };
+
scif1_pins: scif1 {
renesas,groups = "scif1_data_a", "scif1_ctrl";
renesas,function = "scif1";
--- 0001/drivers/irqchip/irq-renesas-irqc.c
+++ work/drivers/irqchip/irq-renesas-irqc.c 2016-02-16 11:32:13.130513000 
+0900
@@ -16,7 +16,7 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
-
+#define DEBUG
 #include 
 #include 
 #include 

[PATCH 02/02] arm64: renesas: Enable RENESAS_IRQC

[Magnus Damm]

From: Magnus Damm 

Select RENESAS_IRQC for Arm64 SoCs from Renesas to enable
build of drivers/irqchip/irq-renesas-irqc.c.

Signed-off-by: Magnus Damm 
---

 arch/arm64/Kconfig.platforms |1 +
 1 file changed, 1 insertion(+)

--- 0001/arch/arm64/Kconfig.platforms
+++ work/arch/arm64/Kconfig.platforms   2016-02-16 11:02:55.040513000 +0900
@@ -77,6 +77,7 @@ config ARCH_RENESAS
select ARCH_SHMOBILE
select PINCTRL
select PM_GENERIC_DOMAINS if PM
+   select RENESAS_IRQC
help
  This enables support for the ARMv8 based Renesas SoCs.
 

[PATCH 00/02] arm64: r8a7795 INTC-EX support using RENESAS_IRQC

[Magnus Damm]

arm64: r8a7795 INTC-EX support using RENESAS_IRQC

[PATCH 01/02] arm64: dts: r8a7795: Add INTC-EX device node
[PATCH 02/02] arm64: renesas: Enable RENESAS_IRQC

These two patches add the INTC-EX device node to the r8a7795 DTSI
file and selects RENESAS_IRQC to enable the irqchip driver. Those
two together allow r8a7795 based platforms to use external interrupt
pins IRQ0 -> IRQ5.

The patches in this series can be merged independently in any order,
but for complete run time support the following two patches are also
required:

[PATCH] pinctrl: sh-pfc: r8a7795: Add support for INTC-EX IRQ pins
[PATCH] clk: shmobile: r8a7795: Add INTC-EX clock

The DT compat string "renesas,intc-ex-r8a7795" is already included in
Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt

Tested on r8a7795 Salvator-X by toggling IRQ2 using an external GPIO
connected via a loop back adapter on EXIO_D.

Signed-off-by: Magnus Damm 
---

 Developed on top of renesas-drivers-2016-02-09-v4.5-rc3

 arch/arm64/Kconfig.platforms |1 +
 arch/arm64/boot/dts/renesas/r8a7795.dtsi |   15 +++
 2 files changed, 16 insertions(+)

Re: [PATCH] ravb: Update DT binding example for final CPG/MSSR bindings

[Simon Horman]

On Mon, Feb 15, 2016 at 01:41:31PM +0100, Geert Uytterhoeven wrote:
> The example in the DT binding documentation uses the preliminary DT
> bindings for the r8a7795 MSTP clocks, which never went upstream.
> Update the example to use the DT bindings for the upstream Clock Pulse
> Generator / Module Standby and Software Reset hardware block.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 

Re: [PATCH 2/2] sh_eth: kill useless *switch* defaults

[Simon Horman]

On Sun, Feb 14, 2016 at 10:56:33PM +0300, Sergei Shtylyov wrote:
> The driver often has the *default* cases doing nothing in the *switch*
> statements with  the integer expressions -- remove them.
> 
> Signed-off-by: Sergei Shtylyov 

Reviewed-by: Simon Horman 

Re: [PATCH 1/2] ravb: kill useless *switch* defaults

[Simon Horman]

On Sun, Feb 14, 2016 at 10:56:03PM +0300, Sergei Shtylyov wrote:
> The  driver has the *default* case doing nothing in the *switch* statement
> with an integer expression -- remove it.
> 
> Signed-off-by: Sergei Shtylyov 

Reviewed-by: Simon Horman 

Re: [PATCH/RFC v2 01/11] PM / Domains: Add DT bindings for the R-Car System Controller

[Laurent Pinchart]

On Tuesday 16 February 2016 01:08:18 Laurent Pinchart wrote:
> On Monday 15 February 2016 22:16:50 Geert Uytterhoeven wrote:
> > The Renesas R-Car System Controller provides power management for the
> > CPU cores and various coprocessors, following the generic PM domain
> > bindings in Documentation/devicetree/bindings/power/power_domain.txt.
> > 
> > This supports R-Car Gen1, Gen2, and Gen3.
> > 
> > Signed-off-by: Geert Uytterhoeven 
> > ---

[snip]
> > 
> >  .../bindings/power/renesas,sysc-rcar.txt   | 87 +
> >  1 file changed, 87 insertions(+) create mode 100644
> > 
> > Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt
> > b/Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt new file
> > mode 100644
> > index ..92ddc0da7b755215
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt
> > @@ -0,0 +1,87 @@

[snip]

> > +  - pm-domains: This node contains a hierarchy of PM Domain Nodes.
> 
> Can't it be an issue that the node happens to have the same name as the
> standard pm-domains property ?

Scratch this, it's power-domains, not pm-domains, mybad.

> > +Dependencies (e.g. parent SCUs should not be powered off while child
> > CPUs
> > +are on) should be reflected using subnodes.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clk: shmobile: cpg-mssr: Update serial port clock in example

[Michael Turquette]

Quoting Geert Uytterhoeven (2016-02-15 04:39:37)
> Cfr. commit a9ec81f4ed5c05db ("serial: sh-sci: Drop the interface
> clock").
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> I plan to queue this up with the other clk-shmobile patches in
> clk-shmobile-for-v4.6 and send a pull request later.

Ack.

Regards,
Mike

> 
>  Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt 
> b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> index 59297d34b2084429..fefb8023020f1a54 100644
> --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> @@ -61,7 +61,7 @@ Examples
> reg = <0 0xe6e88000 0 64>;
> interrupts = ;
> clocks = < CPG_MOD 310>;
> -   clock-names = "sci_ick";
> +   clock-names = "fck";
> dmas = < 0x13>, < 0x12>;
> dma-names = "tx", "rx";
> power-domains = <>;
> -- 
> 1.9.1
> 

Re: [PATCH/RFC v2 04/11] soc: renesas: rcar: Add DT support for SYSC PM domains

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Monday 15 February 2016 22:16:53 Geert Uytterhoeven wrote:
> Populate the SYSC PM domains from DT.
> 
> Special cases, like PM domains containing CPU cores or SCUs, are
> handled by scanning the DT topology.
> 
> The SYSCIER register value is derived from the PM domains found in DT,
> which will allow to get rid of the hardcoded values in pm-rcar-gen2.c.
> However, this means we have to scan for PM domains even if CONFIG_PM=n.
> 
> FIXME:
>   - This needs better integration with the PM code in pm-rcar-gen2, the
> SMP code in smp-r8a7790, and Magnus' DT APMU series.

Have you given this some thoughts already ? Unfortunately smp_prepare_cpus() 
is called before any initcall :-/ How do the other platforms handle this ?

> Signed-off-by: Geert Uytterhoeven 
> ---
> v2:
>   - Add missing definitions for SYSC_PWR_CA15_CPU and SYSC_PWR_CA7_CPU,
>   - Add R-Car H3 (r8a7795) support,
>   - Drop tests for CONFIG_ARCH_SHMOBILE_LEGACY,
>   - Add missing break statements in rcar_sysc_pwr_on_off(),
>   - Add missing calls to of_node_put() in error paths,
>   - Fix build if CONFIG_PM=n,
>   - Update compatible values,
>   - Update copyright.
> ---
>  drivers/soc/renesas/pm-rcar.c | 327 +++
>  1 file changed, 327 insertions(+)
> 
> diff --git a/drivers/soc/renesas/pm-rcar.c b/drivers/soc/renesas/pm-rcar.c
> index cc684e9cc8db5d1c..c0540934126e58eb 100644
> --- a/drivers/soc/renesas/pm-rcar.c
> +++ b/drivers/soc/renesas/pm-rcar.c
> @@ -2,6 +2,7 @@
>   * R-Car SYSC Power management support
>   *
>   * Copyright (C) 2014  Magnus Damm
> + * Copyright (C) 2015-2016 Glider bvba
>   *
>   * This file is subject to the terms and conditions of the GNU General
> Public * License.  See the file "COPYING" in the main directory of this
> archive @@ -11,6 +12,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -38,6 +42,18 @@
>  #define PWRONSR_OFFS 0x10/* Power Resume Status Register */
>  #define PWRER_OFFS   0x14/* Power Shutoff/Resume Error */
> 
> +/*
> + * SYSC Power Control Register Base Addresses (R-Car Gen2)
> + */
> +#define SYSC_PWR_CA15_CPU0x40/* CA15 cores (incl. L1C) (H2/M2/V2H) */
> +#define SYSC_PWR_CA7_CPU 0x1c0   /* CA7 cores (incl. L1C) (H2/E2) */
> +
> +/*
> + * SYSC Power Control Register Base Addresses (R-Car Gen3)
> + */
> +#define SYSC_PWR_CA57_CPU0x80/* CA57 cores (incl. L1C) (H3) */
> +#define SYSC_PWR_CA53_CPU0x200   /* CA53 cores (incl. L1C) (H3) */
> +
> 
>  #define SYSCSR_RETRIES   100
>  #define SYSCSR_DELAY_US  1
> @@ -51,11 +67,40 @@
>  static void __iomem *rcar_sysc_base;
>  static DEFINE_SPINLOCK(rcar_sysc_lock); /* SMP CPUs + I/O devices */
> 
> +static unsigned int rcar_gen;
> +
>  static int rcar_sysc_pwr_on_off(const struct rcar_sysc_ch *sysc_ch, bool
> on)
> {
>   unsigned int sr_bit, reg_offs;
>   int k;
> 
> + /*
> +  * Only R-Car H1 can control power to CPUs
> +  * Use WFI to power off, CPG/APMU to resume ARM cores on later R-Car
> +  * Generations
> +  */
> + switch (rcar_gen) {
> + case 2:
> + /* FIXME Check rcar_pm_domain.cpu instead? */
> + switch (sysc_ch->chan_offs) {
> + case SYSC_PWR_CA15_CPU:
> + case SYSC_PWR_CA7_CPU:
> + pr_err("%s: Cannot control power to CPU\n", __func__);
> + return -EINVAL;
> + }
> + break;
> +
> + case 3:
> + /* FIXME Check rcar_pm_domain.cpu instead? */
> + switch (sysc_ch->chan_offs) {
> + case SYSC_PWR_CA57_CPU:
> + case SYSC_PWR_CA53_CPU:
> + pr_err("%s: Cannot control power to CPU\n", __func__);
> + return -EINVAL;
> + }
> + break;
> + }
> +
>   if (on) {
>   sr_bit = SYSCSR_PONENB;
>   reg_offs = PWRONCR_OFFS;
> @@ -162,3 +207,285 @@ void __iomem *rcar_sysc_init(phys_addr_t base)
> 
>   return rcar_sysc_base;
>  }
> +
> +#ifdef CONFIG_PM_GENERIC_DOMAINS
> +struct rcar_pm_domain {
> + struct generic_pm_domain genpd;
> + struct dev_power_governor *gov;
> + struct rcar_sysc_ch ch;
> + unsigned busy:1;/* Set if always -EBUSY */
> + unsigned cpu:1; /* Set if domain contains CPU */
> + char name[0];
> +};
> +
> +static inline struct rcar_pm_domain *to_rcar_pd(struct generic_pm_domain
> *d)
> +{
> + return container_of(d, struct rcar_pm_domain, genpd);
> +}
> +
> +static bool rcar_pd_active_wakeup(struct device *dev)
> +{
> + return true;
> +}
> +
> +static int rcar_pd_power_down(struct generic_pm_domain *genpd)
> +{
> + struct rcar_pm_domain *rcar_pd = to_rcar_pd(genpd);
> +
> + pr_debug("%s: %s\n", __func__, genpd->name);
> +
> + if 

Re: [PATCH 1/2] pinctrl: sh-pfc: r8a7794: add SSI pin groups

[Linus Walleij]

On Wed, Feb 10, 2016 at 11:38 PM, Sergei Shtylyov
 wrote:

> From: Ryo Kataoka 
>
> Add the SSI pin groups to the R8A7794 PFC driver.
>
> [Sergei: fixed inconsistent alternate pin group naming, split SSI5/6 pin
> groups into data/control ones, moved SSI7 data B group to its proper place,
> fixed  pin names in  the comments to *_pins[], extended Cogent Embedded's
> copyright, added the changelog, renamed the patch.]
>
> Signed-off-by: Ryo Kataoka 
> Signed-off-by: Sergei Shtylyov 

These look fine to me, Acked-by for both.

Geert, will you & Laurent review and queue this please.

Yours,
Linus Walleij

Re: [PATCH/RFC v2 03/11] soc: renesas: Improve rcar_sysc_power() debug info

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Monday 15 February 2016 22:16:52 Geert Uytterhoeven wrote:
> Print requested power domain state.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Laurent Pinchart 

> ---
> v2:
>   - New.
> ---
>  drivers/soc/renesas/pm-rcar.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/renesas/pm-rcar.c b/drivers/soc/renesas/pm-rcar.c
> index bc605d9fbc6ce79c..cc684e9cc8db5d1c 100644
> --- a/drivers/soc/renesas/pm-rcar.c
> +++ b/drivers/soc/renesas/pm-rcar.c
> @@ -128,7 +128,7 @@ static int rcar_sysc_power(const struct rcar_sysc_ch
> *sysc_ch, bool on) out:
>   spin_unlock_irqrestore(_sysc_lock, flags);
> 
> - pr_debug("sysc power domain %d: %08x -> %d\n",
> + pr_debug("sysc power %s domain %d: %08x -> %d\n", on ? "on" : "off",
>sysc_ch->isr_bit, ioread32(rcar_sysc_base + SYSCISR), ret);
>   return ret;
>  }

-- 
Regards,

Laurent Pinchart

Re: [PATCH/RFC] gpio: rcar: Add Runtime PM handling for interrupts

[Linus Walleij]

On Tue, Feb 9, 2016 at 4:19 PM, Geert Uytterhoeven
 wrote:

Quoting in verbatim as we add new recipients.

I don't know about any runtime_pm_get():s from the irqchip functions:
Ulf and others are discussing with Thomas Gleixner about a more general
solution here.

But since it's a regression I guess we need quick decisions.

> The R-Car GPIO driver handles Runtime PM for requested GPIOs only.
>
> When using a GPIO purely as an interrupt source, no Runtime PM handling
> is done, and the GPIO module's clock may not be enabled.
>
> To fix this:
>   - Add .irq_request_resources() and .irq_release_resources() callbacks
> to handle Runtime PM when an interrupt is requested,

This is pretty OK since they are slowpath.

>   - Runtime-resume the device before writing to the GPIO module's
> registers for disabling/enabling an interrupt, or for configuring
> the interrupt type,

Will that have *any* effect now that .irq_request_resources has increased
usecount to 1?

Isn't it enough with the patches to .irq_request/release_resources to get
this working?

>   - Add checks to warn when the GPIO module's registers are accessed
> while the device is runtime-suspended.
>
> Signed-off-by: Geert Uytterhoeven 
> ---
> This fixes ravb Ethernet on r8a7795/Salvator-X, which was "broken" by
> commit d5c3d84657db57bd ("net: phy: Avoid polling PHY with
> PHY_IGNORE_INTERRUPTS").
>
> Does it also fix the HDMI interrupt on r8a7791/Koelsch?
>
> Notes:
>   1. I assume gpio_rcar_irq_{dis,en}able() may be called from contexts
>  where pm_runtime_get_sync() may not be called.
>  However, so far I didn't see any reports from the might_sleep_if()
>  check in __pm_runtime_resume(),
>   2. gpio_rcar_irq_disable() is called from the IRQ core before
>  gpio_rcar_irq_set_type().
>  Else an alternative solution could be to just runtime-resume the
>  device from gpio_rcar_irq_set_type() when an interrupt is setup,
>  and never call pm_runtime_put() again. That would cause issues when
>  compiling gpio-rcar as a module, though.
> ---
>  drivers/gpio/gpio-rcar.c | 42 ++
>  1 file changed, 42 insertions(+)
>
> diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
> index cf41440aff91971e..63b679b3af5d6d16 100644
> --- a/drivers/gpio/gpio-rcar.c
> +++ b/drivers/gpio/gpio-rcar.c
> @@ -59,12 +59,18 @@ struct gpio_rcar_priv {
>
>  static inline u32 gpio_rcar_read(struct gpio_rcar_priv *p, int offs)
>  {
> +   WARN(pm_runtime_suspended(>pdev->dev),
> + "%s: %s is runtime-suspended\n", __func__,
> + dev_name(>pdev->dev));
> return ioread32(p->base + offs);
>  }
>
>  static inline void gpio_rcar_write(struct gpio_rcar_priv *p, int offs,
>u32 value)
>  {
> +   WARN(pm_runtime_suspended(>pdev->dev),
> + "%s: %s is runtime-suspended\n", __func__,
> + dev_name(>pdev->dev));
> iowrite32(value, p->base + offs);
>  }
>
> @@ -86,7 +92,11 @@ static void gpio_rcar_irq_disable(struct irq_data *d)
> struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> struct gpio_rcar_priv *p = gpiochip_get_data(gc);
>
> +   if (pm_runtime_get_sync(>pdev->dev) < 0)
> +   return;
> +
> gpio_rcar_write(p, INTMSK, ~BIT(irqd_to_hwirq(d)));
> +   pm_runtime_put(>pdev->dev);
>  }
>
>  static void gpio_rcar_irq_enable(struct irq_data *d)
> @@ -94,7 +104,11 @@ static void gpio_rcar_irq_enable(struct irq_data *d)
> struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> struct gpio_rcar_priv *p = gpiochip_get_data(gc);
>
> +   if (pm_runtime_get_sync(>pdev->dev) < 0)
> +   return;
> +
> gpio_rcar_write(p, MSKCLR, BIT(irqd_to_hwirq(d)));
> +   pm_runtime_put(>pdev->dev);
>  }
>
>  static void gpio_rcar_config_interrupt_input_mode(struct gpio_rcar_priv *p,
> @@ -105,6 +119,9 @@ static void gpio_rcar_config_interrupt_input_mode(struct 
> gpio_rcar_priv *p,
>  {
> unsigned long flags;
>
> +   if (pm_runtime_get_sync(>pdev->dev) < 0)
> +   return;
> +
> /* follow steps in the GPIO documentation for
>  * "Setting Edge-Sensitive Interrupt Input Mode" and
>  * "Setting Level-Sensitive Interrupt Input Mode"
> @@ -130,6 +147,8 @@ static void gpio_rcar_config_interrupt_input_mode(struct 
> gpio_rcar_priv *p,
> gpio_rcar_write(p, INTCLR, BIT(hwirq));
>
> spin_unlock_irqrestore(>lock, flags);
> +
> +   pm_runtime_put(>pdev->dev);
>  }
>
>  static int gpio_rcar_irq_set_type(struct irq_data *d, unsigned int type)
> @@ -196,6 +215,27 @@ static int gpio_rcar_irq_set_wake(struct irq_data *d, 
> unsigned int on)
> return 0;
>  }
>
> +static int gpio_rcar_irq_request_resources(struct irq_data *d)
> +{
> +  

Re: [PATCH/RFC v2 05/11] soc: renesas: rcar: Handle clock domain devices in SYSC PM domains

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Monday 15 February 2016 22:16:54 Geert Uytterhoeven wrote:
> R-Car H3 contains some hardware modules (e.g. VSP and FCP_V) that are
> not only located in a power area controlled by the SYSC system
> controller, but that are also part of the generic CPG/MSSR clock domain.
> Make sure both are handled by enabling module clock PM when the device
> for such a hardware module is attached to the SYSC PM Domain.

Can't we specify both power domains in the DT power-domains attribute instead 
?

> FIXME Share code with the renesas-cpg-mssr driver.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> v2:
>   - New.
> ---
> drivers/soc/renesas/pm-rcar.c | 68 +
> 1 file changed, 68 insertions(+)
> 
> diff --git a/drivers/soc/renesas/pm-rcar.c b/drivers/soc/renesas/pm-rcar.c
> index c0540934126e58eb..d1bf8c231540b11d 100644
> --- a/drivers/soc/renesas/pm-rcar.c
> +++ b/drivers/soc/renesas/pm-rcar.c
> @@ -9,16 +9,20 @@
>   * for more details.
>   */
> 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> 
> +#include 
> +
>  /* SYSC Common */
>  #define SYSCSR   0x00/* SYSC Status Register */
>  #define SYSCISR  0x04/* Interrupt Status Register */
> @@ -248,11 +252,75 @@ static int rcar_pd_power_up(struct generic_pm_domain
> *genpd) return rcar_sysc_power_up(_rcar_pd(genpd)->ch);
>  }
> 
> +#ifdef CONFIG_ARCH_R8A7795
> +static int rcar_clk_pd_attach_dev(struct generic_pm_domain *genpd,
> +   struct device *dev)
> +{
> + struct device_node *np = dev->of_node;
> + struct of_phandle_args clkspec;
> + struct clk *clk;
> + int i = 0;
> + int error;
> +
> + while (!of_parse_phandle_with_args(np, "clocks", "#clock-cells", i,
> +)) {
> + if (clkspec.args_count == 2 && clkspec.args[0] == CPG_MOD &&
> + of_device_is_compatible(clkspec.np,
> + "renesas,r8a7795-cpg-mssr"))
> + goto found;
> +
> + of_node_put(clkspec.np);
> + i++;
> + }
> +
> + return 0;
> +
> +found:
> + clk = of_clk_get_from_provider();
> + of_node_put(clkspec.np);
> +
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> +
> + error = pm_clk_create(dev);
> + if (error) {
> + dev_err(dev, "pm_clk_create failed %d\n", error);
> + goto fail_put;
> + }
> +
> + error = pm_clk_add_clk(dev, clk);
> + if (error) {
> + dev_err(dev, "pm_clk_add_clk %pC failed %d\n", clk, error);
> + goto fail_destroy;
> + }
> +
> + return 0;
> +
> +fail_destroy:
> + pm_clk_destroy(dev);
> +fail_put:
> + clk_put(clk);
> + return error;
> +}
> +
> +static void rcar_clk_pd_detach_dev(struct generic_pm_domain *genpd,
> +struct device *dev)
> +{
> + if (!list_empty(>power.subsys_data->clock_list))
> + pm_clk_destroy(dev);
> +}
> +#endif /* CONFIG_ARCH_R8A7795 */
> +
>  static void rcar_init_pm_domain(struct rcar_pm_domain *rcar_pd)
>  {
>   struct generic_pm_domain *genpd = _pd->genpd;
>   struct dev_power_governor *gov = rcar_pd->gov;
> 
> +#ifdef CONFIG_ARCH_R8A7795
> + genpd->flags = GENPD_FLAG_PM_CLK;
> + genpd->attach_dev = rcar_clk_pd_attach_dev;
> + genpd->detach_dev = rcar_clk_pd_detach_dev;
> +#endif
>   pm_genpd_init(genpd, gov ? : _qos_governor, false);
>   genpd->dev_ops.active_wakeup= rcar_pd_active_wakeup;
>   genpd->power_off= rcar_pd_power_down;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 0/2] ARM: shmobile: Avoid writing to .text

[Simon Horman]

On Mon, Feb 15, 2016 at 01:20:06PM +0100, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
> 
> When CONFIG_DEBUG_RODATA=y, the kernel crashes during system suspend:
> 
> Freezing user space processes ... (elapsed 0.004 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.002 seconds)
> done.
> PM: suspend of devices complete after 111.948 msecs
> PM: late suspend of devices complete after 1.086 msecs
> PM: noirq suspend of devices complete after 11.576 msecs
> Disabling non-boot CPUs ...
> Kernel panic - not syncing: Attempted to kill the idle task!
> 1014ec ---[ end Kernel panic - not syncing: Attempted to kill the idle 
> task!
> CPU0: stopping
> 
> This happens because the shmobile assembler sources have several
> variables that are written to in the .text section, while .text is
> mapped read-only after kernel bootup if CONFIG_DEBUG_RODATA=y.
> 
> This series fixes this by moving variables from .text to .bss, or just
> removing them.
> Note that there's still an issue with shmobile_boot_fn in
> arch/arm/mach-shmobile/headsmp.S.  So far I didn't manage to fix this
> (the code and data are copied to SRAM on some SoCs).  However, currently
> this is mostly harmless, as this is written to during early kernel boot
> up only, before .text is marked read-only. It does matter for XIP
> (anyone using that with SMP?), so we do want to fix that in the long
> run, too.
> 
> These issues were uncovered by "[PATCH v2] ARM: mm: flip priority of
> CONFIG_DEBUG_RODATA". As that patch is already queued in arm/for-next, I
> think all these fixes should be queued for v4.5, to avoid a dependency
> with the arm tree.

Thanks Geert,

I have queued these up.

Re: [PATCH v2] arm64: dts: r8a7795: use GIC_* defines

[Simon Horman]

On Mon, Feb 15, 2016 at 09:21:29AM +0100, Geert Uytterhoeven wrote:
> On Tue, Feb 2, 2016 at 2:31 PM, Simon Horman  
> wrote:
> > Use GIC_* defines for GIC interrupt cells in r8a7795 device tree.
> >
> > Signed-off-by: Simon Horman 
> 
> Acked-by: Geert Uytterhoeven 

Thanks, I have queued this up.

[PATCH] ARM: dts: r8a7794: replace gpio-key,wakeup with wakeup-source property

[Simon Horman]

Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
check for/support the legacy "gpio-key,wakeup" boolean property to
enable gpio buttons as wakeup source, "wakeup-source" is the new
standard binding.

This patch replaces the legacy "gpio-key,wakeup" with the unified
"wakeup-source" property in order to avoid any futher copy-paste
duplication.

Changelog text from a similar patch by Sudeep Holla.

Cc: Sudeep Holla 
Reported-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7793-gose.dts | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts 
b/arch/arm/boot/dts/r8a7793-gose.dts
index cfe142c2ba38..87e89ec9dd47 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -67,77 +67,77 @@
gpios = < 0 GPIO_ACTIVE_LOW>;
linux,code = ;
label = "SW2-1";
-   gpio-key,wakeup;
+   wakeup-source;
debounce-interval = <20>;
};
key-2 {
gpios = < 1 GPIO_ACTIVE_LOW>;
linux,code = ;
label = "SW2-2";
-   gpio-key,wakeup;
+   wakeup-source;
debounce-interval = <20>;
};
key-3 {
gpios = < 2 GPIO_ACTIVE_LOW>;
linux,code = ;
label = "SW2-3";
-   gpio-key,wakeup;
+   wakeup-source;
debounce-interval = <20>;
};
key-4 {
gpios = < 3 GPIO_ACTIVE_LOW>;
linux,code = ;
label = "SW2-4";
-   gpio-key,wakeup;
+   wakeup-source;
debounce-interval = <20>;
};
key-a {
gpios = < 0 GPIO_ACTIVE_LOW>;
linux,code = ;
label = "SW30";
-   gpio-key,wakeup;
+   wakeup-source;
debounce-interval = <20>;
};
key-b {
gpios = < 1 GPIO_ACTIVE_LOW>;
linux,code = ;
label = "SW31";
-   gpio-key,wakeup;
+   wakeup-source;
debounce-interval = <20>;
};
key-c {
gpios = < 2 GPIO_ACTIVE_LOW>;
linux,code = ;
label = "SW32";
-   gpio-key,wakeup;
+   wakeup-source;
debounce-interval = <20>;
};
key-d {
gpios = < 3 GPIO_ACTIVE_LOW>;
linux,code = ;
label = "SW33";
-   gpio-key,wakeup;
+   wakeup-source;
debounce-interval = <20>;
};
key-e {
gpios = < 4 GPIO_ACTIVE_LOW>;
linux,code = ;
label = "SW34";
-   gpio-key,wakeup;
+   wakeup-source;
debounce-interval = <20>;
};
key-f {
gpios = < 5 GPIO_ACTIVE_LOW>;
linux,code = ;
label = "SW35";
-   gpio-key,wakeup;
+   wakeup-source;
debounce-interval = <20>;
};
key-g {
gpios = < 6 GPIO_ACTIVE_LOW>;
linux,code = ;
label = "SW36";
-   gpio-key,wakeup;
+   wakeup-source;
debounce-interval = <20>;
};
};
-- 
2.7.0.rc3.207.g0ac5344

[PATCH/RFC v2 04/11] soc: renesas: rcar: Add DT support for SYSC PM domains

[Geert Uytterhoeven]

Populate the SYSC PM domains from DT.

Special cases, like PM domains containing CPU cores or SCUs, are
handled by scanning the DT topology.

The SYSCIER register value is derived from the PM domains found in DT,
which will allow to get rid of the hardcoded values in pm-rcar-gen2.c.
However, this means we have to scan for PM domains even if CONFIG_PM=n.

FIXME:
  - This needs better integration with the PM code in pm-rcar-gen2, the
SMP code in smp-r8a7790, and Magnus' DT APMU series.

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Add missing definitions for SYSC_PWR_CA15_CPU and SYSC_PWR_CA7_CPU,
  - Add R-Car H3 (r8a7795) support,
  - Drop tests for CONFIG_ARCH_SHMOBILE_LEGACY,
  - Add missing break statements in rcar_sysc_pwr_on_off(),
  - Add missing calls to of_node_put() in error paths,
  - Fix build if CONFIG_PM=n,
  - Update compatible values,
  - Update copyright.
---
 drivers/soc/renesas/pm-rcar.c | 327 ++
 1 file changed, 327 insertions(+)

diff --git a/drivers/soc/renesas/pm-rcar.c b/drivers/soc/renesas/pm-rcar.c
index cc684e9cc8db5d1c..c0540934126e58eb 100644
--- a/drivers/soc/renesas/pm-rcar.c
+++ b/drivers/soc/renesas/pm-rcar.c
@@ -2,6 +2,7 @@
  * R-Car SYSC Power management support
  *
  * Copyright (C) 2014  Magnus Damm
+ * Copyright (C) 2015-2016 Glider bvba
  *
  * This file is subject to the terms and conditions of the GNU General Public
  * License.  See the file "COPYING" in the main directory of this archive
@@ -11,6 +12,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -38,6 +42,18 @@
 #define PWRONSR_OFFS   0x10/* Power Resume Status Register */
 #define PWRER_OFFS 0x14/* Power Shutoff/Resume Error */
 
+/*
+ * SYSC Power Control Register Base Addresses (R-Car Gen2)
+ */
+#define SYSC_PWR_CA15_CPU  0x40/* CA15 cores (incl. L1C) (H2/M2/V2H) */
+#define SYSC_PWR_CA7_CPU   0x1c0   /* CA7 cores (incl. L1C) (H2/E2) */
+
+/*
+ * SYSC Power Control Register Base Addresses (R-Car Gen3)
+ */
+#define SYSC_PWR_CA57_CPU  0x80/* CA57 cores (incl. L1C) (H3) */
+#define SYSC_PWR_CA53_CPU  0x200   /* CA53 cores (incl. L1C) (H3) */
+
 
 #define SYSCSR_RETRIES 100
 #define SYSCSR_DELAY_US1
@@ -51,11 +67,40 @@
 static void __iomem *rcar_sysc_base;
 static DEFINE_SPINLOCK(rcar_sysc_lock); /* SMP CPUs + I/O devices */
 
+static unsigned int rcar_gen;
+
 static int rcar_sysc_pwr_on_off(const struct rcar_sysc_ch *sysc_ch, bool on)
 {
unsigned int sr_bit, reg_offs;
int k;
 
+   /*
+* Only R-Car H1 can control power to CPUs
+* Use WFI to power off, CPG/APMU to resume ARM cores on later R-Car
+* Generations
+*/
+   switch (rcar_gen) {
+   case 2:
+   /* FIXME Check rcar_pm_domain.cpu instead? */
+   switch (sysc_ch->chan_offs) {
+   case SYSC_PWR_CA15_CPU:
+   case SYSC_PWR_CA7_CPU:
+   pr_err("%s: Cannot control power to CPU\n", __func__);
+   return -EINVAL;
+   }
+   break;
+
+   case 3:
+   /* FIXME Check rcar_pm_domain.cpu instead? */
+   switch (sysc_ch->chan_offs) {
+   case SYSC_PWR_CA57_CPU:
+   case SYSC_PWR_CA53_CPU:
+   pr_err("%s: Cannot control power to CPU\n", __func__);
+   return -EINVAL;
+   }
+   break;
+   }
+
if (on) {
sr_bit = SYSCSR_PONENB;
reg_offs = PWRONCR_OFFS;
@@ -162,3 +207,285 @@ void __iomem *rcar_sysc_init(phys_addr_t base)
 
return rcar_sysc_base;
 }
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS
+struct rcar_pm_domain {
+   struct generic_pm_domain genpd;
+   struct dev_power_governor *gov;
+   struct rcar_sysc_ch ch;
+   unsigned busy:1;/* Set if always -EBUSY */
+   unsigned cpu:1; /* Set if domain contains CPU */
+   char name[0];
+};
+
+static inline struct rcar_pm_domain *to_rcar_pd(struct generic_pm_domain *d)
+{
+   return container_of(d, struct rcar_pm_domain, genpd);
+}
+
+static bool rcar_pd_active_wakeup(struct device *dev)
+{
+   return true;
+}
+
+static int rcar_pd_power_down(struct generic_pm_domain *genpd)
+{
+   struct rcar_pm_domain *rcar_pd = to_rcar_pd(genpd);
+
+   pr_debug("%s: %s\n", __func__, genpd->name);
+
+   if (rcar_pd->busy) {
+   pr_debug("%s: %s busy\n", __func__, genpd->name);
+   return -EBUSY;
+   }
+
+   return rcar_sysc_power_down(_pd->ch);
+}
+
+static int rcar_pd_power_up(struct generic_pm_domain *genpd)
+{
+   pr_debug("%s: %s\n", __func__, genpd->name);
+   return rcar_sysc_power_up(_rcar_pd(genpd)->ch);
+}
+
+static void rcar_init_pm_domain(struct rcar_pm_domain *rcar_pd)
+{
+   struct 

[PATCH/RFC v2 01/11] PM / Domains: Add DT bindings for the R-Car System Controller

[Geert Uytterhoeven]

The Renesas R-Car System Controller provides power management for the
CPU cores and various coprocessors, following the generic PM domain
bindings in Documentation/devicetree/bindings/power/power_domain.txt.

This supports R-Car Gen1, Gen2, and Gen3.

Signed-off-by: Geert Uytterhoeven 
---
Alternatives I considered:

  - Using a single node per power register block, even if it contains
multiple domains, e.g.:

pd_ca15_scu: ca15_scu@180 {
reg = <0x180 0x20>;
#address-cells = <1>;
#size-cells = <0>;
#power-domain-cells = <0>;
renesas,interrupt-bits = <12>;

pd_ca15_cpu: ca15_cpu@40 {
reg = <0x40 0x20>;
#power-domain-cells = <1>;
renesas,pm-domain-indices = <0 1>;
renesas,pm-domain-names =
"ca15_cpu0", "ca15_cpu1";
renesas,interrupt-bits = <0 1>;
};
};

Notes:
  - You cannot just have a property with the number of domains, as
index 0 is not used on R-Car H1. Hence the need for
"renesas,pm-domain-indices" and "renesas,interrupt-bits",
  - "#power-domain-cells = <1>" for nodes with multiple domains,
which allows typos in "power-domains = <_ca15_cpu n>", using
an invalid value of "n".

  - Using a linear description in DT:
  - Needs parent links for subdomains,
  - More complicated to parse (lesson learned from R-Mobile PM
Domain support).

  - Keeping the power register block offset and the bit number as separate
"reg" cells, increasing "#address-cells" from 2 to 3,

  - Merging the interrupt bit (which needs only 5 bits) in the other "reg"
cell, decreasing "#address-cells" from 2 to 1.

v2:
  - Add R-Car H3 (r8a7795) support,
  - Use "renesas,-sysc" instead of "renesas,sysc-",
  - Add fallback compatibility strings for R-Car Gen2 and Gen3.
---
 .../bindings/power/renesas,sysc-rcar.txt   | 87 ++
 1 file changed, 87 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt

diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt 
b/Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt
new file mode 100644
index ..92ddc0da7b755215
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt
@@ -0,0 +1,87 @@
+DT bindings for the Renesas R-Car System Controller
+
+== System Controller Node ==
+
+The R-Car System Controller provides power management for the CPU cores and
+various coprocessors.
+
+Required properties:
+  - compatible: Must contain one or more of the following:
+  - "renesas,r8a7779-sysc" (R-Car H1)
+  - "renesas,r8a7790-sysc" (R-Car H2)
+  - "renesas,r8a7791-sysc" (R-Car M2-W)
+  - "renesas,r8a7792-sysc" (R-Car V2H)
+  - "renesas,r8a7793-sysc" (R-Car M2-N)
+  - "renesas,r8a7794-sysc" (R-Car E2)
+  - "renesas,r8a7795-sysc" (R-Car H3)
+  - "renesas,rcar-gen2-sysc" (Generic R-Car Gen2)
+  - "renesas,rcar-gen3-sysc" (Generic R-Car Gen3)
+When compatible with the generic version, nodes must list the SoC-specific
+version corresponding to the platform first, followed by the generic
+version.
+  - reg: Address start and address range for the device.
+  - pm-domains: This node contains a hierarchy of PM Domain Nodes.
+Dependencies (e.g. parent SCUs should not be powered off while child CPUs
+are on) should be reflected using subnodes.
+
+
+== PM Domain Nodes ==
+
+Each of the PM domain nodes represents a PM domain, as documented by the
+generic PM domain bindings in
+Documentation/devicetree/bindings/power/power_domain.txt.
+
+Required properties:
+  - #power-domain-cells: Must be 0.
+  - reg: This property must contain 2 values:
+  - The first value is the number of the interrupt bit representing
+the power area in the various Interrupt Registers (e.g. SYSCISR,
+Interrupt Status Register),
+  - The second value encodes the power register block offset (which is
+a multiple of 64), and the number of the bit representing the
+power area in the various Power Control Registers (e.g. PWROFFSR,
+Power Shutoff Status Register). This value is created by ORing
+these two numbers.
+The parent's node must contain the following two properties:
+  - #address-cells: Must be 2,
+  - #size-cells: Must be 0.
+
+
+Example:
+
+   sysc: system-controller@e618 {
+   compatible = "renesas,r8a7791-sysc", "renesas,rcar-gen2-sysc";
+   reg = <0 0xe618 0 0x0200>;
+
+   pm-domains {
+   #address-cells = <2>;
+   #size-cells = 

[PATCH/RFC v2 09/11] ARM: dts: r8a7793: Add SYSC PM domains

[Geert Uytterhoeven]

Add a device node for the System Controller, with subnodes that
represent the hardware power area hierarchy.
Hook up the first Cortex-A15 CPU core and the Cortex-A15 L2 cache/SCU to
their respective PM domains.

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Change one-line summary prefix to match current arm-soc practices,
  - Update compatible values.
---
 arch/arm/boot/dts/r8a7793.dtsi | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 9a30f650aa515b80..843fd3306f35ebb0 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -43,6 +43,7 @@
voltage-tolerance = <1>; /* 1% */
clocks = <_clocks R8A7793_CLK_Z>;
clock-latency = <30>; /* 300 us */
+   power-domains = <_ca15_cpu0>;
 
/* kHz - uV - OPPs unknown yet */
operating-points = <150 100>,
@@ -57,6 +58,7 @@
 
L2_CA15: cache-controller@0 {
compatible = "cache";
+   power-domains = <_ca15_scu>;
cache-unified;
cache-level = <2>;
};
@@ -1144,6 +1146,43 @@
};
};
 
+   sysc: system-controller@e618 {
+   compatible = "renesas,r8a7793-sysc", "renesas,rcar-gen2-sysc";
+   reg = <0 0xe618 0 0x0200>;
+
+   pm-domains {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   pd_ca15_scu: scu@12 {
+   reg = <12 0x180>;
+   #address-cells = <2>;
+   #size-cells = <0>;
+   #power-domain-cells = <0>;
+
+   pd_ca15_cpu0: cpu@0 {
+   reg = <0 0x40>;
+   #power-domain-cells = <0>;
+   };
+
+   pd_ca15_cpu1: cpu@1 {
+   reg = <1 0x41>;
+   #power-domain-cells = <0>;
+   };
+   };
+
+   pd_sh: sh@16 {
+   reg = <16 0x80>;
+   #power-domain-cells = <0>;
+   };
+
+   pd_sgx: sgx@20 {
+   reg = <20 0xc0>;
+   #power-domain-cells = <0>;
+   };
+   };
+   };
+
ipmmu_sy0: mmu@e628 {
compatible = "renesas,ipmmu-r8a7793", "renesas,ipmmu-vmsa";
reg = <0 0xe628 0 0x1000>;
-- 
1.9.1

[PATCH/RFC v2 11/11] arm64: dts: r8a7795: Add SYSC PM domains

[Geert Uytterhoeven]

Add a device node for the System Controller, with subnodes that
represent the hardware power area hierarchy.
Hook up the Cortex-A57 CPU cores and the Cortex-A57 and Cortex A53 L2
caches/SCUs to their respective PM domains.

Signed-off-by: Geert Uytterhoeven 
---
The SH core was dropped in datasheet rev. 0.5E?

v2:
  - New.
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 142 +++
 1 file changed, 142 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index c572527afec3403a..69f400e0d478b285 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -39,6 +39,7 @@
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0x0>;
device_type = "cpu";
+   power-domains = <_ca57_cpu0>;
next-level-cache = <_CA57>;
enable-method = "psci";
};
@@ -47,6 +48,7 @@
compatible = "arm,cortex-a57","arm,armv8";
reg = <0x1>;
device_type = "cpu";
+   power-domains = <_ca57_cpu1>;
next-level-cache = <_CA57>;
enable-method = "psci";
};
@@ -54,6 +56,7 @@
compatible = "arm,cortex-a57","arm,armv8";
reg = <0x2>;
device_type = "cpu";
+   power-domains = <_ca57_cpu2>;
next-level-cache = <_CA57>;
enable-method = "psci";
};
@@ -61,6 +64,7 @@
compatible = "arm,cortex-a57","arm,armv8";
reg = <0x3>;
device_type = "cpu";
+   power-domains = <_ca57_cpu3>;
next-level-cache = <_CA57>;
enable-method = "psci";
};
@@ -68,12 +72,14 @@
 
L2_CA57: cache-controller@0 {
compatible = "cache";
+   power-domains = <_ca57_scu>;
cache-unified;
cache-level = <2>;
};
 
L2_CA53: cache-controller@1 {
compatible = "cache";
+   power-domains = <_ca53_scu>;
cache-unified;
cache-level = <2>;
};
@@ -968,5 +974,141 @@
#dma-cells = <1>;
dma-channels = <2>;
};
+
+   sysc: system-controller@e618 {
+   compatible = "renesas,r8a7795-sysc",
+"renesas,rcar-gen3-sysc";
+   reg = <0 0xe618 0 0x0400>;
+
+   pm-domains {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   pd_ca57_scu: ca57_scu@12 {
+   reg = <12 0x1c0>;
+   #address-cells = <2>;
+   #size-cells = <0>;
+   #power-domain-cells = <0>;
+
+   pd_ca57_cpu0: ca57_cpu@0 {
+   reg = <0 0x80>;
+   #power-domain-cells = <0>;
+   };
+
+   pd_ca57_cpu1: ca57_cpu@1 {
+   reg = <1 0x81>;
+   #power-domain-cells = <0>;
+   };
+
+   pd_ca57_cpu2: ca57_cpu@2 {
+   reg = <2 0x82>;
+   #power-domain-cells = <0>;
+   };
+
+   pd_ca57_cpu3: ca57_cpu@3 {
+   reg = <3 0x83>;
+   #power-domain-cells = <0>;
+   };
+   };
+
+   pd_ca53_scu: ca53_scu@21 {
+   reg = <21 0x140>;
+   #address-cells = <2>;
+   #size-cells = <0>;
+   #power-domain-cells = <0>;
+
+   pd_ca53_cpu0: ca53_cpu@5 {
+   reg = <5 0x200>;
+   #power-domain-cells = <0>;
+   };
+
+   pd_ca53_cpu1: ca53_cpu@6 {
+  

[PATCH v3 5/7] ARM: dts: r8a7794: Add L2 cache-controller node

[Geert Uytterhoeven]

Add a device node for the L2 cache, and link the CPU nodes to it.

The L2 cache for the Cortex-A7 CPU cores is 512 KiB large (organized as
64 KiB x 8 ways).

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Change one-line summary prefix to match current arm-soc practices,

v2:
  - Drop (incorrect) optional cache-{size,sets,{block,line}-size}
properties, as this information is auto-detected,
  - Integrate linking CPUs to L2 cache into this patch,
  - Extracted from series "[PATCH/RFC 00/15] ARM: shmobile: R-Car: Add
SYSC PM Domain DT Support".
---
 arch/arm/boot/dts/r8a7794.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index df0861e84a4b81eb..21a02df3609b24aa 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -40,6 +40,7 @@
compatible = "arm,cortex-a7";
reg = <0>;
clock-frequency = <10>;
+   next-level-cache = <_CA7>;
};
 
cpu1: cpu@1 {
@@ -47,9 +48,16 @@
compatible = "arm,cortex-a7";
reg = <1>;
clock-frequency = <10>;
+   next-level-cache = <_CA7>;
};
};
 
+   L2_CA7: cache-controller@1 {
+   compatible = "cache";
+   cache-unified;
+   cache-level = <2>;
+   };
+
gic: interrupt-controller@f1001000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
-- 
1.9.1

[PATCH v3 6/7] arm64: dts: r8a7795: Add missing properties to CA57 L2 cache node

[Geert Uytterhoeven]

Add the missing "cache-unified" and "cache-level" properties to the
Cortex-A57 cache-controller node.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Remaining part of "[PATCH v2 6/6] arm64: renesas: r8a7795: Add L2
cache-controller nodes", after dropping the "arm,data-latency" and
"arm,tag-latency" properties.
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index b5e46e4ff72ad003..c07f4e83b988ba42 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -68,6 +68,8 @@
 
L2_CA57: cache-controller@0 {
compatible = "cache";
+   cache-unified;
+   cache-level = <2>;
};
 
extal_clk: extal {
-- 
1.9.1

[PATCH v3 1/7] ARM: dts: r8a73a4: Add L2 cache-controller nodes

[Geert Uytterhoeven]

Add device nodes for the L2 caches, and link the CPU node to its L2
cache node.

The L2 cache for the Cortex-A15 CPU cores is 1 MiB large (organized as
64 KiB x 16 ways), and located in PM domain A3SM.

The L2 cache for the Cortex-A7 CPU cores is 512 KiB large (organized as
64 KiB x 8 ways), and located in PM domain A3KM.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Drop "arm,data-latency" and "arm,tag-latency" properties, as they
may not be valid when using virtualization,
  - Change one-line summary prefix to match current arm-soc practices,

v2:
  - New.
---
 arch/arm/boot/dts/r8a73a4.dtsi | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 138414a7d1703781..6583a1dfca1f64c6 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -29,6 +29,7 @@
reg = <0>;
clock-frequency = <15>;
power-domains = <_a2sl>;
+   next-level-cache = <_CA15>;
};
};
 
@@ -45,6 +46,22 @@
 ;
};
 
+   L2_CA15: cache-controller@0 {
+   compatible = "cache";
+   clocks = <_clocks R8A73A4_CLK_Z>;
+   power-domains = <_a3sm>;
+   cache-unified;
+   cache-level = <2>;
+   };
+
+   L2_CA7: cache-controller@1 {
+   compatible = "cache";
+   clocks = <_clocks R8A73A4_CLK_Z2>;
+   power-domains = <_a3km>;
+   cache-unified;
+   cache-level = <2>;
+   };
+
dbsc1: memory-controller@e679 {
compatible = "renesas,dbsc-r8a73a4";
reg = <0 0xe679 0 0x1>;
-- 
1.9.1

Re: ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8] arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)

[Marc Zyngier]

On 15/02/16 18:53, Dirk Behme wrote:
> On 15.02.2016 11:55, Marc Zyngier wrote:
>> On 15/02/16 10:35, Geert Uytterhoeven wrote:
>>> Hi Marc,
>>>
>>> On Mon, Feb 15, 2016 at 9:45 AM, Marc Zyngier  wrote:
 On 15/02/16 08:16, Geert Uytterhoeven wrote:
> On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven  
> wrote:
>> On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland  
>> wrote:
>>> On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
 On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland  
 wrote:
>>> +   gic: interrupt-controller@0xf101 {
>> + compatible = "arm,gic-400";
>> + #interrupt-cells = <3>;
>> + #address-cells = <0>;
>> + interrupt-controller;
>> + reg = <0x0 0xf101 0 0x1000>,
>> +   <0x0 0xf102 0 0x2000>;
>> + interrupts = > + (GIC_CPU_MASK_SIMPLE(1) | 
>> IRQ_TYPE_LEVEL_HIGH)>;
>> + };
>
> No GICH and GICV?

 These seem to be defined in the "arm,gic-v3" DT bindings only, while 
 this is
 an "arm,gic-400" (GICD_IIDR 0x0200043b)?
>>>
>>> See the "GIC virtualization extensions (VGIC)" section in
>>> Documentation/devicetree/bindings/arm/gic.txt
>>
>> DDI0471B_gic400_r0p1_trm.pdf says:
>>
>>  Address range GIC-400 functional block
>>  A. 0x - 0x0FFF Reserved
>>  B. 0x1000 - 0x1FFF Distributor
>>  C. 0x2000 - 0x3FFF CPU interfaces
>>  D. 0x4000 - 0x4FFF Virtual interface control block, for the 
>> processor that
>> is performing the access
>>  E. 0x5000 - 0x5FFF Virtual interface control block, for the 
>> processor
>> selected by address bits [11:9]
>>  F. 0x6000 - 0x7FFF Virtual CPU interfaces
>>
>> The DT binding document says:
>>1. The  first region is the GIC distributor register base and size.
>>2. The 2nd region is the GIC cpu interface register base and size.
>>3. The first additional region is the GIC virtual interface control 
>> register
>>   base and size.
>>4. The 2nd additional region is the GIC virtual cpu interface 
>> register base
>>   and size.
>>
>> Matching with the example:
>>
>>  interrupt-controller@2c001000 {
>>  compatible = "arm,cortex-a15-gic";
>>  #interrupt-cells = <3>;
>>  interrupt-controller;
>>  reg = <0x2c001000 0x1000>,
>><0x2c002000 0x1000>,
>><0x2c004000 0x2000>,
>><0x2c006000 0x2000>;
>>  interrupts = <1 9 0xf04>;
>>  };
>>
>> This means:
>>- reg entry 1. covers address range B,
>>- reg entry 2. covers address range C,
>>- reg entry 3. covers address ranges D _and_ E,
>>- reg entry 4. covers address range F.
>>
>> On R-Car Gen3, the base addresses are:
>>
>>  Distributor : 0xF101_
>>  CPU interfaces  : 0xF102_
>>  Virtual interfaces  : 0xF104_
>>  Virtual interfaces  : 0xF105_
>>  Virtual CPU interfaces  : 0xF106_
>>
>> Note the additional multiplication factor of 16 in the offsets relative 
>> to
>> the base address 0xf100 (e.g. 0x5 instead of 0x5000).
>>
>> As address ranges D and E are merged in a single reg entry, how is the 
>> GIC
>> driver supposed to know about this multiplication factor?

 The answer is very simple, the GIC driver doesn't give a damn about the
 second part of the GICH region, because it is absolutely unusable for
 any realistic use-case. Only the banked version of GICH is of any
 relevance (the first 512 bytes, in essence).

 Aligning the GIC regions on 64kB boundaries is documented in the SBSA
 specification, independently of the GIC400 documentation.
>>>
>>> If I understand the SBSA spec correctly (BTW, arm,gic.txt doesn't use the
>>> "GICC" terminology, unlike arm,gic-v3.txt), that means reg entry 3 should be
>>> "<0xf104f000 0x2000>", so it covers the aliased last 4 KiB of address range 
>>> D,
>>> and the first 4 KiB of address range E. I.e.
>>>
>>>  reg = <0x0 0xf101 0 0x1000>,
>>>   <0x0 0xf102 0 0x2000>,
>>>   <0x0 0xf104f000 0 0x2000>,
>>>   <0x0 0xf106 0 0x2000>;
>>>
>>> Is that correct?
>>
>> My preference 

Re: ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8] arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)

[Dirk Behme]

On 15.02.2016 11:55, Marc Zyngier wrote:

On 15/02/16 10:35, Geert Uytterhoeven wrote:

Hi Marc,

On Mon, Feb 15, 2016 at 9:45 AM, Marc Zyngier  wrote:

On 15/02/16 08:16, Geert Uytterhoeven wrote:

On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven  wrote:

On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland  wrote:

On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:

On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland  wrote:

+   gic: interrupt-controller@0xf101 {

+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x0 0xf101 0 0x1000>,
+   <0x0 0xf102 0 0x2000>;
+ interrupts = ;
+ };


No GICH and GICV?


These seem to be defined in the "arm,gic-v3" DT bindings only, while this is
an "arm,gic-400" (GICD_IIDR 0x0200043b)?


See the "GIC virtualization extensions (VGIC)" section in
Documentation/devicetree/bindings/arm/gic.txt


DDI0471B_gic400_r0p1_trm.pdf says:

 Address range GIC-400 functional block
 A. 0x - 0x0FFF Reserved
 B. 0x1000 - 0x1FFF Distributor
 C. 0x2000 - 0x3FFF CPU interfaces
 D. 0x4000 - 0x4FFF Virtual interface control block, for the processor that
is performing the access
 E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
selected by address bits [11:9]
 F. 0x6000 - 0x7FFF Virtual CPU interfaces

The DT binding document says:
   1. The  first region is the GIC distributor register base and size.
   2. The 2nd region is the GIC cpu interface register base and size.
   3. The first additional region is the GIC virtual interface control register
  base and size.
   4. The 2nd additional region is the GIC virtual cpu interface register base
  and size.

Matching with the example:

 interrupt-controller@2c001000 {
 compatible = "arm,cortex-a15-gic";
 #interrupt-cells = <3>;
 interrupt-controller;
 reg = <0x2c001000 0x1000>,
   <0x2c002000 0x1000>,
   <0x2c004000 0x2000>,
   <0x2c006000 0x2000>;
 interrupts = <1 9 0xf04>;
 };

This means:
   - reg entry 1. covers address range B,
   - reg entry 2. covers address range C,
   - reg entry 3. covers address ranges D _and_ E,
   - reg entry 4. covers address range F.

On R-Car Gen3, the base addresses are:

 Distributor : 0xF101_
 CPU interfaces  : 0xF102_
 Virtual interfaces  : 0xF104_
 Virtual interfaces  : 0xF105_
 Virtual CPU interfaces  : 0xF106_

Note the additional multiplication factor of 16 in the offsets relative to
the base address 0xf100 (e.g. 0x5 instead of 0x5000).

As address ranges D and E are merged in a single reg entry, how is the GIC
driver supposed to know about this multiplication factor?


The answer is very simple, the GIC driver doesn't give a damn about the
second part of the GICH region, because it is absolutely unusable for
any realistic use-case. Only the banked version of GICH is of any
relevance (the first 512 bytes, in essence).

Aligning the GIC regions on 64kB boundaries is documented in the SBSA
specification, independently of the GIC400 documentation.


If I understand the SBSA spec correctly (BTW, arm,gic.txt doesn't use the
"GICC" terminology, unlike arm,gic-v3.txt), that means reg entry 3 should be
"<0xf104f000 0x2000>", so it covers the aliased last 4 KiB of address range D,
and the first 4 KiB of address range E. I.e.

 reg = <0x0 0xf101 0 0x1000>,
  <0x0 0xf102 0 0x2000>,
  <0x0 0xf104f000 0 0x2000>,
  <0x0 0xf106 0 0x2000>;

Is that correct?


My preference would be to expose the full 128kB of the region



That would be

<0x0 0xf104 0 0x2>

then? Ok?

Best regards

Dirk

Re: [PATCH] dmaengine: use phys_addr_t for slave configuration

[Vinod Koul]

On Tue, Feb 09, 2016 at 11:57:24PM +0100, Wolfram Sang wrote:
> 
> > This is a dependency for adding iommu support to the rcar-dmac driver, cfr.
> > "[PATCH v2 0/5] dmaengine: rcar-dmac: add iommu support for slave 
> > transfers".
> > http://www.spinics.net/lists/linux-renesas-soc/msg00066.html
> > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg00108.html
> > 
> > Thank you for applying!
> 
> Yup, we really need it. Anything we can do to help?

I have done this change and discussing wider changes
I will send CFT hopefully before EOW, pls test :)

-- 
~Vinod


signature.asc
Description: Digital signature

Re: [PATCH 0/2] ARM: shmobile: use Lager as reference for I2C slave and core switch

[Geert Uytterhoeven]

Hi Wolfram

On Mon, Feb 15, 2016 at 1:57 PM, Wolfram Sang  wrote:
> This series provides the necessary preparation to use Lager for testing the
> above mentioned features. After this, the rest is done at runtime as described
> in the upstream documentation.

Thanks for your series!

> This series depends on the i2c-demux-pinctrl driver which is in linux-next
> already. Because IIC0/I2C0 is unpopulated and even so, IIC0 is used as default
> like before, chances of a regression are extremly unlikely. The only 
> regression
> I can think of is someone using:
> a) IIC0 with an external board
> b) the Lager DTS from upstream unmodified
> c) a private .config and forgot to activate the i2c-demux-pinctrl 
> driver
>
> We could point this person to the working shmobile_defconfig, though. However,
> I'd think that someone using IIC0 externally will also have a private Lager 
> DTS
> and in that case will be made aware by the merge conflict.

Should this become a DT overlay to avoid such issues?

If yes, the question remains where to store DT overlays (apart from my
topic/renesas-overlays branch ;-)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] pinctrl: sh-pfc: Rework PFC GPIO support

[Geert Uytterhoeven]

On Mon, Feb 15, 2016 at 1:55 PM, Laurent Pinchart
 wrote:
>> --- 0001/drivers/pinctrl/sh-pfc/Makefile
>> +++ work/drivers/pinctrl/sh-pfc/Makefile  2016-02-15 19:56:50.720513000
> +0900
>> @@ -1,11 +1,8 @@
>>  sh-pfc-objs  = core.o pinctrl.o
>> -ifeq ($(CONFIG_GPIO_SH_PFC),y)
>> -sh-pfc-objs  += gpio.o
>> -endif
>>  obj-$(CONFIG_PINCTRL_SH_PFC) += sh-pfc.o
>>  obj-$(CONFIG_PINCTRL_PFC_EMEV2)  += pfc-emev2.o
>> -obj-$(CONFIG_PINCTRL_PFC_R8A73A4)+= pfc-r8a73a4.o
>> -obj-$(CONFIG_PINCTRL_PFC_R8A7740)+= pfc-r8a7740.o
>> +obj-$(CONFIG_PINCTRL_PFC_R8A73A4)+= pfc-r8a73a4.o gpio.o
>> +obj-$(CONFIG_PINCTRL_PFC_R8A7740)+= pfc-r8a7740.o gpio.o
>
> Instead of duplicating gpio.o for every PFC entry that uses it, how about
> keeping it above and just using CONFIG_PINCTRL_SH_PFC_GPIO in the ifeq ?

Or not using the ifeq, but using

 obj-$(CONFIG_PINCTRL_SH_PFC_GPIO) += gpio.o

instead?

Is there any specific reason for the existence of the sh-pfc-objs intermediate?
It's not like we can/want to have a modular pinctrl driver...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH RESEND 0/3] arm64: salvator-x: enable SD card slots

[Wolfram Sang]

These are the remaining patches needed to get the SD slots on a Salvator-X
board working. I decided to collect and resend them as a separate series to
make it more clear where we are and to ensure everyone is in the loop :)

There are no changes to patch 1 since it was originally posted. This one should
go via MMC. Patches 2+3 have never been posted but were available in my branch
and people tested them. Dirk, maybe you can add your Tested-by again? Those
patches should go via renesas-soc.

Would be great to have this in 4.6.

Thanks,

   Wolfram


Ai Kyuse (2):
  arm64: dts: r8a7795: Add SDHI support to dtsi
  arm64: dts: r8a7795: salvator-x: enable SDHI0 & 3

Wolfram Sang (1):
  mmc: sdhi: Add r8a7795 support

 Documentation/devicetree/bindings/mmc/tmio_mmc.txt |  1 +
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 83 ++
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   | 38 ++
 drivers/mmc/host/Kconfig   |  2 +-
 drivers/mmc/host/sh_mobile_sdhi.c  | 47 
 5 files changed, 157 insertions(+), 14 deletions(-)

-- 
2.1.4

[PATCH RESEND 1/3] mmc: sdhi: Add r8a7795 support

[Wolfram Sang]

From: Wolfram Sang 

Registers are 64bit apart, so we refactor bus_shift handling a little and set
it based on the DT compatible. Also, EXT_ACC is different. It has been tested
on a Salvator-X (Gen3) and, to check for regressions, on a Lager (Gen2).

Signed-off-by: Ai Kyuse 
Signed-off-by: Wolfram Sang 
---
 Documentation/devicetree/bindings/mmc/tmio_mmc.txt |  1 +
 drivers/mmc/host/Kconfig   |  2 +-
 drivers/mmc/host/sh_mobile_sdhi.c  | 47 --
 3 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt 
b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
index 400b640fabc768..7fb746dd1a68ca 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -22,6 +22,7 @@ Required properties:
"renesas,sdhi-r8a7792" - SDHI IP on R8A7792 SoC
"renesas,sdhi-r8a7793" - SDHI IP on R8A7793 SoC
"renesas,sdhi-r8a7794" - SDHI IP on R8A7794 SoC
+   "renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC
 
 Optional properties:
 - toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 4a35ebf5165d83..d9a9d92fa8379a 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -560,7 +560,7 @@ config MMC_TMIO
 
 config MMC_SDHI
tristate "SH-Mobile SDHI SD/SDIO controller support"
-   depends on SUPERH || ARM
+   depends on SUPERH || ARM || ARM64
depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
select MMC_TMIO_CORE
help
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c 
b/drivers/mmc/host/sh_mobile_sdhi.c
index 557e2b9dadeec7..9aa147959276d0 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -1,6 +1,8 @@
 /*
  * SuperH Mobile SDHI
  *
+ * Copyright (C) 2016 Sang Engineering, Wolfram Sang
+ * Copyright (C) 2015-16 Renesas Electronics Corporation
  * Copyright (C) 2009 Magnus Damm
  *
  * This program is free software; you can redistribute it and/or modify
@@ -43,6 +45,7 @@ struct sh_mobile_sdhi_of_data {
unsigned long capabilities2;
enum dma_slave_buswidth dma_buswidth;
dma_addr_t dma_rx_offset;
+   unsigned bus_shift;
 };
 
 static const struct sh_mobile_sdhi_of_data sh_mobile_sdhi_of_cfg[] = {
@@ -65,6 +68,13 @@ static const struct sh_mobile_sdhi_of_data 
of_rcar_gen2_compatible = {
.dma_rx_offset  = 0x2000,
 };
 
+static const struct sh_mobile_sdhi_of_data of_rcar_gen3_compatible = {
+   .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
+ TMIO_MMC_CLK_ACTUAL | TMIO_MMC_FAST_CLK_CHG,
+   .capabilities   = MMC_CAP_SD_HIGHSPEED,
+   .bus_shift  = 2,
+};
+
 static const struct of_device_id sh_mobile_sdhi_of_match[] = {
{ .compatible = "renesas,sdhi-shmobile" },
{ .compatible = "renesas,sdhi-sh7372" },
@@ -78,6 +88,7 @@ static const struct of_device_id sh_mobile_sdhi_of_match[] = {
{ .compatible = "renesas,sdhi-r8a7792", .data = 
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7793", .data = 
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7794", .data = 
_rcar_gen2_compatible, },
+   { .compatible = "renesas,sdhi-r8a7795", .data = 
_rcar_gen3_compatible, },
{},
 };
 MODULE_DEVICE_TABLE(of, sh_mobile_sdhi_of_match);
@@ -103,6 +114,15 @@ static void sh_mobile_sdhi_sdbuf_width(struct 
tmio_mmc_host *host, int width)
case 0xCB0D:
val = (width == 32) ? 0x : 0x0001;
break;
+   case 0xCC10: /* Gen3, SD only */
+   case 0xCD10: /* Gen3, SD + MMC */
+   if (width == 64)
+   val = 0x;
+   else if (width == 32)
+   val = 0x0101;
+   else
+   val = 0x0001;
+   break;
default:
/* nothing to do */
return;
@@ -233,16 +253,26 @@ static int sh_mobile_sdhi_probe(struct platform_device 
*pdev)
goto eprobe;
}
 
+   if (of_id && of_id->data) {
+   const struct sh_mobile_sdhi_of_data *of_data = of_id->data;
+
+   mmc_data->flags |= of_data->tmio_flags;
+   mmc_data->capabilities |= of_data->capabilities;
+   mmc_data->capabilities2 |= of_data->capabilities2;
+   mmc_data->dma_rx_offset = of_data->dma_rx_offset;
+   dma_priv->dma_buswidth = of_data->dma_buswidth;
+   host->bus_shift = of_data->bus_shift;
+   }
+
host->dma   = dma_priv;
host->write16_hook  = sh_mobile_sdhi_write16_hook;
host->clk_enable= sh_mobile_sdhi_clk_enable;
 

[PATCH RESEND 3/3] arm64: dts: r8a7795: salvator-x: enable SDHI0 & 3

[Wolfram Sang]

From: Ai Kyuse 

Add the exposed SD card slots. The on-board eMMC needs to wait until we
fixed the 8bit support (it works with 4bit if you really want it now).

Signed-off-by: Ai Kyuse 
Signed-off-by: Wolfram Sang 
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 83 ++
 1 file changed, 83 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 1cb1dcb5d4ad30..e5af6fd79731af 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -33,6 +33,7 @@
 
 /dts-v1/;
 #include "r8a7795.dtsi"
+#include 
 
 / {
model = "Renesas Salvator-X board based on r8a7795";
@@ -61,6 +62,54 @@
clock-frequency = <24576000>;
};
 
+   vcc_sdhi0: regulator@1 {
+   compatible = "regulator-fixed";
+
+   regulator-name = "SDHI0 Vcc";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+
+   gpio = < 2 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   vccq_sdhi0: regulator@2 {
+   compatible = "regulator-gpio";
+
+   regulator-name = "SDHI0 VccQ";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+
+   gpios = < 1 GPIO_ACTIVE_HIGH>;
+   gpios-states = <1>;
+   states = <330 1
+ 180 0>;
+   };
+
+   vcc_sdhi3: regulator@3 {
+   compatible = "regulator-fixed";
+
+   regulator-name = "SDHI3 Vcc";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+
+   gpio = < 15 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   vccq_sdhi3: regulator@4 {
+   compatible = "regulator-gpio";
+
+   regulator-name = "SDHI3 VccQ";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+
+   gpios = < 14 GPIO_ACTIVE_HIGH>;
+   gpios-states = <1>;
+   states = <330 1
+ 180 0>;
+   };
+
audio_clkout: audio_clkout {
/*
 * This is same as <_sound 0>
@@ -119,6 +168,16 @@
renesas,function = "avb";
};
 
+   sdhi0_pins: sd0 {
+   renesas,groups = "sdhi0_data4", "sdhi0_ctrl";
+   renesas,function = "sdhi0";
+   };
+
+   sdhi3_pins: sd3 {
+   renesas,groups = "sdhi3_data4", "sdhi3_ctrl";
+   renesas,function = "sdhi3";
+   };
+
sound_pins: sound {
renesas,groups = "ssi01239_ctrl", "ssi0_data", "ssi1_data_a";
renesas,function = "ssi";
@@ -262,6 +321,30 @@
};
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   vmmc-supply = <_sdhi0>;
+   vqmmc-supply = <_sdhi0>;
+   cd-gpios = < 12 GPIO_ACTIVE_LOW>;
+   wp-gpios = < 13 GPIO_ACTIVE_HIGH>;
+   bus-width = <4>;
+   status = "okay";
+};
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   vmmc-supply = <_sdhi3>;
+   vqmmc-supply = <_sdhi3>;
+   cd-gpios = < 15 GPIO_ACTIVE_LOW>;
+   wp-gpios = < 16 GPIO_ACTIVE_HIGH>;
+   bus-width = <4>;
+   status = "okay";
+};
+
 _bus_clk {
status = "okay";
 };
-- 
2.1.4

Re: [PATCH RESEND 0/3] arm64: salvator-x: enable SD card slots

[Wolfram Sang]

On Mon, Feb 15, 2016 at 02:34:34PM +0100, Wolfram Sang wrote:
> These are the remaining patches needed to get the SD slots on a Salvator-X
> board working. I decided to collect and resend them as a separate series to
> make it more clear where we are and to ensure everyone is in the loop :)

Sorry, my mobile internet connection is crap at the moment. Will send
again a bit later today when I'm back home.



signature.asc
Description: Digital signature

Re: [PATCH] serial: sh-sci: Remove redundant instances of EARLYCON_DECLARE()

[Sergei Shtylyov]

Hello.

On 2/15/2016 3:36 PM, Geert Uytterhoeven wrote:


As of commit 2eaa790989e03900 ("earlycon: Use common framework for


   12-digt ID is enough


earlycon declarations") it is no longer needer to specify both


   Needed?


EARLYCON_DECLARE() and OF_EARLYCON_DECLARE().

Signed-off-by: Geert Uytterhoeven 


[...]

MBR, Sergei

[PATCH 2/2] ARM: shmobile: r8a7790: lager: use demuxer for IIC0/I2C0

[Wolfram Sang]

From: Wolfram Sang 

Make it possible to select which I2C IP core you want to run on the
EXIO-A connector. This is the reference how to use this feature. Update
the copyright while we are here.

Signed-off-by: Wolfram Sang 
---
 arch/arm/boot/dts/r8a7790-lager.dts | 32 ++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 08eef61ffad1af..a776aa37daa00e 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -3,6 +3,7 @@
  *
  * Copyright (C) 2013-2014 Renesas Solutions Corp.
  * Copyright (C) 2014 Cogent Embedded, Inc.
+ * Copyright (C) 2015-2016 Renesas Electronics Corporation
  *
  * This file is licensed under the terms of the GNU General Public License
  * version 2.  This program is licensed "as is" without any warranty of any
@@ -49,6 +50,7 @@
aliases {
serial0 = 
serial1 = 
+   i2c8 = "i2cexio";
};
 
chosen {
@@ -252,6 +254,23 @@
#clock-cells = <0>;
clock-frequency = <14850>;
};
+
+   /*
+* IIC0/I2C0 is routed to EXIO connector A, pins 114 (SCL) + 116 (SDA) 
only.
+* We use the I2C demuxer, so the desired IP core can be selected at 
runtime
+* depending on the use case (e.g. DMA with IIC0 or slave support with 
I2C0).
+* Note: For testing the I2C slave feature, it is convenient to connect 
this
+* bus with IIC3 on pins 110 (SCL) + 112 (SDA), select I2C0 at runtime, 
and
+* instantiate the slave device at runtime according to the 
documentation.
+* You can then communicate with the slave via IIC3.
+*/
+   i2cexio: i2c@8 {
+   compatible = "i2c-demux-pinctrl";
+   i2c-parent = <>, <>;
+   i2c-bus-name = "i2c-exio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
 };
 
  {
@@ -364,6 +383,11 @@
renesas,function = "msiof1";
};
 
+   i2c0_pins: i2c0 {
+   renesas,groups = "i2c0";
+   renesas,function = "i2c0";
+   };
+
iic0_pins: iic0 {
renesas,groups = "iic0";
renesas,function = "iic0";
@@ -555,10 +579,14 @@
cpu0-supply = <_dvfs>;
 };
 
+  {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "i2c-exio";
+};
+
   {
-   status = "okay";
pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+   pinctrl-names = "i2c-exio";
 };
 
   {
-- 
2.1.4

[PATCH 1/2] ARM: shmobile: defconfig: enable I2C demultiplexer and slave eeprom

[Wolfram Sang]

From: Wolfram Sang 

The Lager board shall be the reference platform for the runtime I2C IP
core switcher and for I2C slave support. Enable the needed drivers for
this.

Signed-off-by: Wolfram Sang 
---
 arch/arm/configs/shmobile_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/shmobile_defconfig 
b/arch/arm/configs/shmobile_defconfig
index b7b714c3958c2f..e06acb9b38ce60 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -99,11 +99,14 @@ CONFIG_SERIAL_SH_SCI=y
 CONFIG_SERIAL_SH_SCI_NR_UARTS=20
 CONFIG_SERIAL_SH_SCI_CONSOLE=y
 CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_MUX=y
+CONFIG_I2C_DEMUX_PINCTRL=y
 CONFIG_I2C_EMEV2=y
 CONFIG_I2C_GPIO=y
 CONFIG_I2C_RIIC=y
 CONFIG_I2C_SH_MOBILE=y
 CONFIG_I2C_RCAR=y
+CONFIG_I2C_SLAVE_EEPROM=y
 CONFIG_SPI=y
 CONFIG_SPI_RSPI=y
 CONFIG_SPI_SH_MSIOF=y
-- 
2.1.4

[PATCH] clk: shmobile: cpg-mssr: Update serial port clock in example

[Geert Uytterhoeven]

Cfr. commit a9ec81f4ed5c05db ("serial: sh-sci: Drop the interface
clock").

Signed-off-by: Geert Uytterhoeven 
---
I plan to queue this up with the other clk-shmobile patches in
clk-shmobile-for-v4.6 and send a pull request later.

 Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt 
b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
index 59297d34b2084429..fefb8023020f1a54 100644
--- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
@@ -61,7 +61,7 @@ Examples
reg = <0 0xe6e88000 0 64>;
interrupts = ;
clocks = < CPG_MOD 310>;
-   clock-names = "sci_ick";
+   clock-names = "fck";
dmas = < 0x13>, < 0x12>;
dma-names = "tx", "rx";
power-domains = <>;
-- 
1.9.1

[PATCH] serial: sh-sci: Remove redundant instances of EARLYCON_DECLARE()

[Geert Uytterhoeven]

As of commit 2eaa790989e03900 ("earlycon: Use common framework for
earlycon declarations") it is no longer needer to specify both
EARLYCON_DECLARE() and OF_EARLYCON_DECLARE().

Signed-off-by: Geert Uytterhoeven 
---
 drivers/tty/serial/sh-sci.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 4678d8f2dd7d1da5..0130feb069aee02f 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -3071,15 +3071,10 @@ static int __init hscif_early_console_setup(struct 
earlycon_device *device,
return early_console_setup(device, PORT_HSCIF);
 }
 
-EARLYCON_DECLARE(sci, sci_early_console_setup);
 OF_EARLYCON_DECLARE(sci, "renesas,sci", sci_early_console_setup);
-EARLYCON_DECLARE(scif, scif_early_console_setup);
 OF_EARLYCON_DECLARE(scif, "renesas,scif", scif_early_console_setup);
-EARLYCON_DECLARE(scifa, scifa_early_console_setup);
 OF_EARLYCON_DECLARE(scifa, "renesas,scifa", scifa_early_console_setup);
-EARLYCON_DECLARE(scifb, scifb_early_console_setup);
 OF_EARLYCON_DECLARE(scifb, "renesas,scifb", scifb_early_console_setup);
-EARLYCON_DECLARE(hscif, hscif_early_console_setup);
 OF_EARLYCON_DECLARE(hscif, "renesas,hscif", hscif_early_console_setup);
 #endif /* CONFIG_SERIAL_SH_SCI_EARLYCON */
 
-- 
1.9.1

Re: [PATCH/RFC 3/9] v4l: Add Renesas R-Car FCP driver

[Laurent Pinchart]

Hi Geert,

Thank you for the review.

On Monday 15 February 2016 10:32:35 Geert Uytterhoeven wrote:
> On Fri, Feb 12, 2016 at 3:00 AM, Laurent Pinchart wrote:
> > The FCP is a companion module of video processing modules in the
> > Renesas R-Car Gen3 SoCs. It provides data compression and decompression,
> > data caching, and converting of AXI transaction in order to reduce the
> 
> "conversion"?

Of course. Can you submit a similar patch to the Gen3 datasheet ? ;-)

> > memory bandwidth.
> > 
> > The driver is not meant to be used standalone but provides an API to the
> > video processing modules to control the FCP.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> 
> Thanks for your patch!
> 
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,fcp.txt
> > @@ -0,0 +1,24 @@
> > +Renesas R-Car Frame Compression Processor (FCP)
> > +---
> > +
> > +The FCP is a companion module of video processing modules in the Renesas
> > R-Car
> > +Gen3 SoCs. It provides data compression and decompression, data caching,
> > and
> > +converting of AXI transaction in order to reduce the memory bandwidth.
>
> "conversion"?
> 
> > +
> > +There are three types of FCP whose configuration and behaviour highly
> > depend +on the module they are paired with.
> > +
> > + - compatible: Must be one of the following
> > +   - "renesas,fcpv" for the 'FCP for VSP' device
> 
> Any chance this module can turn up in another SoC later? I guess yes.

It's not just that it can, it will.

> What about future-proofing using "renesas,r8a7795-fcpv" and "renesas,rcar-
> gen3-fcpv"?

Given that the device currently has registers and clock only, I wanted to keep 
the DT bindings simple. My plan is to introduce new compat strings later as 
needed, if needed, when incompatible FCP instances will be introduced. Feel 
free to challenge that :-)

> > diff --git a/drivers/media/platform/Kconfig
> > b/drivers/media/platform/Kconfig index fd4fcd5a7184..cbb4e5735bf8 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -255,6 +255,19 @@ config VIDEO_RENESAS_JPU
> >   To compile this driver as a module, choose M here: the module
> >   will be called rcar_jpu.
> > 
> > +config VIDEO_RENESAS_FCP
> > +   tristate "Renesas Frame Compression Processor"
> > +   depends on ARCH_SHMOBILE || COMPILE_TEST
> 
> ARCH_RENESAS

Ah, that's finally merged, great.

> > diff --git a/drivers/media/platform/rcar-fcp.c
> > b/drivers/media/platform/rcar-fcp.c new file mode 100644
> > index ..cf8cb629ae4f
> > --- /dev/null
> > +++ b/drivers/media/platform/rcar-fcp.c
> > 
> > +struct rcar_fcp_device *rcar_fcp_get(const struct device_node *np)
> > +{
> > +   struct rcar_fcp_device *fcp;
> > +
> > +   mutex_lock(_lock);
> > +
> > +   list_for_each_entry(fcp, _devices, list) {
> > +   if (fcp->dev->of_node != np)
> > +   continue;
> > +
> > +   /*
> > +* Make sure the module won't be unloaded behind our back.
> > This
> > +* is a poor's man safety net, the module should really
> > not be
>
> poor man's
> 
> > diff --git a/include/media/rcar-fcp.h b/include/media/rcar-fcp.h
> > new file mode 100644
> > index ..4260cf48d3b1
> > --- /dev/null
> > +++ b/include/media/rcar-fcp.h
> > @@ -0,0 +1,34 @@
> > +/*
> > + * rcar-fcp.h  --  R-Car Frame Compression Processor Driver
> > + *
> > + * Copyright (C) 2016 Renesas Electronics Corporation
> > + *
> > + * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +#ifndef __MEDIA_RCAR_FCP_H__
> > +#define __MEDIA_RCAR_FCP_H__
> > +
> > +struct device_node;
> > +struct rcar_fcp_device;
> > +
> > +#if IS_ENABLED(CONFIG_VIDEO_RENESAS_FCP)
> > +struct rcar_fcp_device *rcar_fcp_get(const struct device_node *np);
> > +void rcar_fcp_put(struct rcar_fcp_device *fcp);
> > +void rcar_fcp_enable(struct rcar_fcp_device *fcp);
> > +void rcar_fcp_disable(struct rcar_fcp_device *fcp);
> > +#else
> > +static inline struct rcar_fcp_device *rcar_fcp_get(const struct
> > device_node *np)
> > +{
> > +   return ERR_PTR(-ENOENT);
> > +}
> > +static inline void rcar_fcp_put(struct rcar_fcp_device *fcp) { }
> > +static inline void rcar_fcp_enable(struct rcar_fcp_device *fcp) { }
> > +static inline void rcar_fcp_disable(struct rcar_fcp_device *fcp) { }
> 
> Given the dummies, the vsp driver can also work when FCP support is not
> enabled?
> Or is this meant purely to avoid #ifdefs in the vsp driver when compiling
> for R-Car Gen2?
> 
> In case of the latter, you may want to enforce this in 

Re: [PATCH/RFC 1/9] clk: shmobile: r8a7795: Add FCP clocks

[Laurent Pinchart]

Hi Geert,

On Monday 15 February 2016 10:22:22 Geert Uytterhoeven wrote:
> On Fri, Feb 12, 2016 at 3:00 AM, Laurent Pinchart wrote:
> > The parent clock isn't documented in the datasheet, use S2D1 as a best
> > guess for now.
> 
> Looks like a good guess...
> I assume the driver doesn't depend on the clock rate?

Correct.

> > Signed-off-by: Laurent Pinchart
> > 
> 
> Reviewed-by: Geert Uytterhoeven 

Thank you.

-- 
Regards,

Laurent Pinchart

[PATCH v3 2/2] ARM: shmobile: Remove shmobile_boot_arg

[Geert Uytterhoeven]

CPU boot configuration writes to shmobile_boot_arg, which is located in
the .text section, and thus should not be written to.

As of commit 1d33a354bbb618ba ("ARM: shmobile: Per-CPU SMP boot / sleep
code for SCU SoCs"), and ignoring accidental remainings,
shmobile_boot_arg is always set to MPIDR_HWID_BITMASK by C code.
Hence we can just hardcode this in the assembler code, and remove the
variable, and thus also remove the need to write to this variable.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Nicolas Pitre 
---
v3:
  - Add Acked-by,

v2:
  - New.
---
 arch/arm/mach-shmobile/common.h   | 1 -
 arch/arm/mach-shmobile/headsmp.S  | 8 ++--
 arch/arm/mach-shmobile/platsmp-apmu.c | 1 -
 arch/arm/mach-shmobile/platsmp-scu.c  | 1 -
 4 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/common.h b/arch/arm/mach-shmobile/common.h
index 225c12bb3de91e76..5464b7a75e3028a7 100644
--- a/arch/arm/mach-shmobile/common.h
+++ b/arch/arm/mach-shmobile/common.h
@@ -4,7 +4,6 @@
 extern void shmobile_init_delay(void);
 extern void shmobile_boot_vector(void);
 extern unsigned long shmobile_boot_fn;
-extern unsigned long shmobile_boot_arg;
 extern unsigned long shmobile_boot_size;
 extern void shmobile_smp_boot(void);
 extern void shmobile_smp_sleep(void);
diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index 94d86ed164144cdf..32e0bf6e3ccb9bd3 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -24,7 +24,6 @@
.arm
.align  12
 ENTRY(shmobile_boot_vector)
-   ldr r0, 2f
ldr r1, 1f
bx  r1
 
@@ -34,9 +33,6 @@ ENDPROC(shmobile_boot_vector)
.globl  shmobile_boot_fn
 shmobile_boot_fn:
 1: .space  4
-   .globl  shmobile_boot_arg
-shmobile_boot_arg:
-2: .space  4
.globl  shmobile_boot_size
 shmobile_boot_size:
.long   . - shmobile_boot_vector
@@ -46,9 +42,9 @@ shmobile_boot_size:
  */
 
 ENTRY(shmobile_smp_boot)
-   @ r0 = MPIDR_HWID_BITMASK
mrc p15, 0, r1, c0, c0, 5   @ r1 = MPIDR
-   and r0, r1, r0  @ r0 = cpu_logical_map() value
+   and r0, r1, #0xff   @ MPIDR_HWID_BITMASK
+   @ r0 = cpu_logical_map() value
mov r1, #0  @ r1 = CPU index
adr r2, 1f
ldmia   r2, {r5, r6, r7}
diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c 
b/arch/arm/mach-shmobile/platsmp-apmu.c
index 911884f7e28b174c..aba75c89f9c1c5eb 100644
--- a/arch/arm/mach-shmobile/platsmp-apmu.c
+++ b/arch/arm/mach-shmobile/platsmp-apmu.c
@@ -123,7 +123,6 @@ void __init shmobile_smp_apmu_prepare_cpus(unsigned int 
max_cpus,
 {
/* install boot code shared by all CPUs */
shmobile_boot_fn = virt_to_phys(shmobile_smp_boot);
-   shmobile_boot_arg = MPIDR_HWID_BITMASK;
 
/* perform per-cpu setup */
apmu_parse_cfg(apmu_init_cpu, apmu_config, num);
diff --git a/arch/arm/mach-shmobile/platsmp-scu.c 
b/arch/arm/mach-shmobile/platsmp-scu.c
index 4c7d2caf3730f644..8d478f1da265d55e 100644
--- a/arch/arm/mach-shmobile/platsmp-scu.c
+++ b/arch/arm/mach-shmobile/platsmp-scu.c
@@ -46,7 +46,6 @@ void __init shmobile_smp_scu_prepare_cpus(phys_addr_t 
scu_base_phys,
 {
/* install boot code shared by all CPUs */
shmobile_boot_fn = virt_to_phys(shmobile_smp_boot);
-   shmobile_boot_arg = MPIDR_HWID_BITMASK;
 
/* enable SCU and cache coherency on booting CPU */
shmobile_scu_base_phys = scu_base_phys;
-- 
1.9.1

[PATCH] pinctrl: sh-pfc: r8a7795: Add support for INTC-EX IRQ pins

[Magnus Damm]

From: Magnus Damm 

Most pins on the r8a7795 SoC can be configured in GPIO mode for
interrupt and GPIO functionality, while a couple of them can also
be routed to the INTC-EX hardware block (formerly known as IRQC).

On r8a7795 the INTC-EX hardware handles pins IRQ0 -> IRQ5 and
this patch adds support for them to the PFC driver as "intc_ex_irqN".

Tested on r8a7795 Salvator-X with an external loop back adapter on
EXIO_D that connects pin 9 (IRQ2/GP2_02) and pin 26 (ExA22/GP2_06).

Signed-off-by: Magnus Damm 
---

 Developed on top of renesas-drivers-2016-02-09-v4.5-rc3

 drivers/pinctrl/sh-pfc/pfc-r8a7795.c |   60 ++
 1 file changed, 60 insertions(+)

--- 0001/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
+++ work/drivers/pinctrl/sh-pfc/pfc-r8a7795.c   2016-02-15 21:05:24.500513000 
+0900
@@ -1835,6 +1835,50 @@ static const unsigned int i2c6_c_mux[] =
SDA6_C_MARK, SCL6_C_MARK,
 };
 
+/* - INTC-EX  
*/
+static const unsigned int intc_ex_irq0_pins[] = {
+   /* IRQ0 */
+   RCAR_GP_PIN(2, 0),
+};
+static const unsigned int intc_ex_irq0_mux[] = {
+   IRQ0_MARK,
+};
+static const unsigned int intc_ex_irq1_pins[] = {
+   /* IRQ1 */
+   RCAR_GP_PIN(2, 1),
+};
+static const unsigned int intc_ex_irq1_mux[] = {
+   IRQ1_MARK,
+};
+static const unsigned int intc_ex_irq2_pins[] = {
+   /* IRQ2 */
+   RCAR_GP_PIN(2, 2),
+};
+static const unsigned int intc_ex_irq2_mux[] = {
+   IRQ2_MARK,
+};
+static const unsigned int intc_ex_irq3_pins[] = {
+   /* IRQ3 */
+   RCAR_GP_PIN(2, 3),
+};
+static const unsigned int intc_ex_irq3_mux[] = {
+   IRQ3_MARK,
+};
+static const unsigned int intc_ex_irq4_pins[] = {
+   /* IRQ4 */
+   RCAR_GP_PIN(2, 4),
+};
+static const unsigned int intc_ex_irq4_mux[] = {
+   IRQ4_MARK,
+};
+static const unsigned int intc_ex_irq5_pins[] = {
+   /* IRQ5 */
+   RCAR_GP_PIN(2, 5),
+};
+static const unsigned int intc_ex_irq5_mux[] = {
+   IRQ5_MARK,
+};
+
 /* - MSIOF0 - 
*/
 static const unsigned int msiof0_clk_pins[] = {
/* SCK */
@@ -3173,6 +3217,12 @@ static const struct sh_pfc_pin_group pin
SH_PFC_PIN_GROUP(i2c6_a),
SH_PFC_PIN_GROUP(i2c6_b),
SH_PFC_PIN_GROUP(i2c6_c),
+   SH_PFC_PIN_GROUP(intc_ex_irq0),
+   SH_PFC_PIN_GROUP(intc_ex_irq1),
+   SH_PFC_PIN_GROUP(intc_ex_irq2),
+   SH_PFC_PIN_GROUP(intc_ex_irq3),
+   SH_PFC_PIN_GROUP(intc_ex_irq4),
+   SH_PFC_PIN_GROUP(intc_ex_irq5),
SH_PFC_PIN_GROUP(msiof0_clk),
SH_PFC_PIN_GROUP(msiof0_sync),
SH_PFC_PIN_GROUP(msiof0_ss1),
@@ -3439,6 +3489,15 @@ static const char * const i2c6_groups[]
"i2c6_c",
 };
 
+static const char * const intc_ex_groups[] = {
+   "intc_ex_irq0",
+   "intc_ex_irq1",
+   "intc_ex_irq2",
+   "intc_ex_irq3",
+   "intc_ex_irq4",
+   "intc_ex_irq5",
+};
+
 static const char * const msiof0_groups[] = {
"msiof0_clk",
"msiof0_sync",
@@ -3686,6 +3745,7 @@ static const struct sh_pfc_function pinm
SH_PFC_FUNCTION(i2c1),
SH_PFC_FUNCTION(i2c2),
SH_PFC_FUNCTION(i2c6),
+   SH_PFC_FUNCTION(intc_ex),
SH_PFC_FUNCTION(msiof0),
SH_PFC_FUNCTION(msiof1),
SH_PFC_FUNCTION(msiof2),

[PATCH] pinctrl: sh-pfc: Rework PFC GPIO support

[Magnus Damm]

From: Magnus Damm 

The sh-pfc Pinctrl driver is currently handling SoC-specific
PFC hardware blocks on Arm64, Arm and SH architectures.

For older SoCs using SH cores and some 32-bit Arm SoCs the PFC
hardware also provides GPIO functionality. On the majority of
32-bit Arm SoCs from Renesas and so far all Arm64 SoCs the GPIO
feature is provided by separate hardware blocks.

So far GPIO support in the PFC driver has been compiled-in for
the majority of the SoCs, but with this patch applied the SoCs
with PFC support may select from one of the following:
 - CONFIG_PINCTRL_SH_PFC - Used if PFC lacks GPIO hardware
 - CONFIG_PINCTRL_SH_PFC_GPIO - Used if PFC includes GPIO support

This patch results in the following changes:
 - The GPIO functionality is only compiled-in on relevant SoCs
 - The number of lines of code is reduced

Build tested using the following configurations:
 - r8a7795 -> CONFIG_PINCTRL_SH_PFC_GPIO=n -> Ok (Arm64)
 - r8a7790 -> CONFIG_PINCTRL_SH_PFC_GPIO=n -> Ok (Arm)
 - r8a7790 + r8a7740 -> CONFIG_PINCTRL_SH_PFC_GPIO=y -> Ok (Arm)
 - r8a7740 -> CONFIG_PINCTRL_SH_PFC_GPIO=y -> Ok (Arm)

Signed-off-by: Magnus Damm 
---

 drivers/pinctrl/sh-pfc/Kconfig  |   54 ++-
 drivers/pinctrl/sh-pfc/Makefile |   33 ++-
 drivers/pinctrl/sh-pfc/core.c   |4 +-
 3 files changed, 37 insertions(+), 54 deletions(-)

--- 0001/drivers/pinctrl/sh-pfc/Kconfig
+++ work/drivers/pinctrl/sh-pfc/Kconfig 2016-02-15 19:59:35.080513000 +0900
@@ -5,7 +5,6 @@
 if ARCH_SHMOBILE || SUPERH
 
 config PINCTRL_SH_PFC
-   select GPIO_SH_PFC if ARCH_REQUIRE_GPIOLIB
select PINMUX
select PINCONF
select GENERIC_PINCONF
@@ -13,12 +12,12 @@ config PINCTRL_SH_PFC
help
  This enables pin control drivers for SH and SH Mobile platforms
 
-config GPIO_SH_PFC
-   bool "SuperH PFC GPIO support"
-   depends on PINCTRL_SH_PFC && GPIOLIB
+config PINCTRL_SH_PFC_GPIO
+   select GPIOLIB
+   select PINCTRL_SH_PFC
+   def_bool n
help
- This enables support for GPIOs within the SoC's pin function
- controller.
+ This enables pin control and GPIO drivers for SH/SH Mobile platforms
 
 config PINCTRL_PFC_EMEV2
def_bool y
@@ -28,12 +27,12 @@ config PINCTRL_PFC_EMEV2
 config PINCTRL_PFC_R8A73A4
def_bool y
depends on ARCH_R8A73A4
-   select PINCTRL_SH_PFC
+   select PINCTRL_SH_PFC_GPIO
 
 config PINCTRL_PFC_R8A7740
def_bool y
depends on ARCH_R8A7740
-   select PINCTRL_SH_PFC
+   select PINCTRL_SH_PFC_GPIO
 
 config PINCTRL_PFC_R8A7778
def_bool y
@@ -73,79 +72,66 @@ config PINCTRL_PFC_R8A7795
 config PINCTRL_PFC_SH7203
def_bool y
depends on CPU_SUBTYPE_SH7203
-   depends on GPIOLIB
-   select PINCTRL_SH_PFC
+   select PINCTRL_SH_PFC_GPIO
 
 config PINCTRL_PFC_SH7264
def_bool y
depends on CPU_SUBTYPE_SH7264
-   depends on GPIOLIB
-   select PINCTRL_SH_PFC
+   select PINCTRL_SH_PFC_GPIO
 
 config PINCTRL_PFC_SH7269
def_bool y
depends on CPU_SUBTYPE_SH7269
-   depends on GPIOLIB
-   select PINCTRL_SH_PFC
+   select PINCTRL_SH_PFC_GPIO
 
 config PINCTRL_PFC_SH73A0
def_bool y
depends on ARCH_SH73A0
-   select PINCTRL_SH_PFC
+   select PINCTRL_SH_PFC_GPIO
select REGULATOR
 
 config PINCTRL_PFC_SH7720
def_bool y
depends on CPU_SUBTYPE_SH7720
-   depends on GPIOLIB
-   select PINCTRL_SH_PFC
+   select PINCTRL_SH_PFC_GPIO
 
 config PINCTRL_PFC_SH7722
def_bool y
depends on CPU_SUBTYPE_SH7722
-   depends on GPIOLIB
-   select PINCTRL_SH_PFC
+   select PINCTRL_SH_PFC_GPIO
 
 config PINCTRL_PFC_SH7723
def_bool y
depends on CPU_SUBTYPE_SH7723
-   depends on GPIOLIB
-   select PINCTRL_SH_PFC
+   select PINCTRL_SH_PFC_GPIO
 
 config PINCTRL_PFC_SH7724
def_bool y
depends on CPU_SUBTYPE_SH7724
-   depends on GPIOLIB
-   select PINCTRL_SH_PFC
+   select PINCTRL_SH_PFC_GPIO
 
 config PINCTRL_PFC_SH7734
def_bool y
depends on CPU_SUBTYPE_SH7734
-   depends on GPIOLIB
-   select PINCTRL_SH_PFC
+   select PINCTRL_SH_PFC_GPIO
 
 config PINCTRL_PFC_SH7757
def_bool y
depends on CPU_SUBTYPE_SH7757
-   depends on GPIOLIB
-   select PINCTRL_SH_PFC
+   select PINCTRL_SH_PFC_GPIO
 
 config PINCTRL_PFC_SH7785
def_bool y
depends on CPU_SUBTYPE_SH7785
-   depends on GPIOLIB
-   select PINCTRL_SH_PFC
+   select PINCTRL_SH_PFC_GPIO
 
 config PINCTRL_PFC_SH7786
def_bool y
depends on CPU_SUBTYPE_SH7786
-   depends on GPIOLIB
-   select PINCTRL_SH_PFC
+   select PINCTRL_SH_PFC_GPIO
 
 config PINCTRL_PFC_SHX3
def_bool y
depends on CPU_SUBTYPE_SHX3
-   depends on GPIOLIB
-   

Re: ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8] arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)

[Marc Zyngier]

On 15/02/16 10:35, Geert Uytterhoeven wrote:
> Hi Marc,
> 
> On Mon, Feb 15, 2016 at 9:45 AM, Marc Zyngier  wrote:
>> On 15/02/16 08:16, Geert Uytterhoeven wrote:
>>> On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven  
>>> wrote:
 On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland  wrote:
> On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
>> On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland  
>> wrote:
> +   gic: interrupt-controller@0xf101 {
 + compatible = "arm,gic-400";
 + #interrupt-cells = <3>;
 + #address-cells = <0>;
 + interrupt-controller;
 + reg = <0x0 0xf101 0 0x1000>,
 +   <0x0 0xf102 0 0x2000>;
 + interrupts = >>> + (GIC_CPU_MASK_SIMPLE(1) | 
 IRQ_TYPE_LEVEL_HIGH)>;
 + };
>>>
>>> No GICH and GICV?
>>
>> These seem to be defined in the "arm,gic-v3" DT bindings only, while 
>> this is
>> an "arm,gic-400" (GICD_IIDR 0x0200043b)?
>
> See the "GIC virtualization extensions (VGIC)" section in
> Documentation/devicetree/bindings/arm/gic.txt

 DDI0471B_gic400_r0p1_trm.pdf says:

 Address range GIC-400 functional block
 A. 0x - 0x0FFF Reserved
 B. 0x1000 - 0x1FFF Distributor
 C. 0x2000 - 0x3FFF CPU interfaces
 D. 0x4000 - 0x4FFF Virtual interface control block, for the processor 
 that
is performing the access
 E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
selected by address bits [11:9]
 F. 0x6000 - 0x7FFF Virtual CPU interfaces

 The DT binding document says:
   1. The  first region is the GIC distributor register base and size.
   2. The 2nd region is the GIC cpu interface register base and size.
   3. The first additional region is the GIC virtual interface control 
 register
  base and size.
   4. The 2nd additional region is the GIC virtual cpu interface register 
 base
  and size.

 Matching with the example:

 interrupt-controller@2c001000 {
 compatible = "arm,cortex-a15-gic";
 #interrupt-cells = <3>;
 interrupt-controller;
 reg = <0x2c001000 0x1000>,
   <0x2c002000 0x1000>,
   <0x2c004000 0x2000>,
   <0x2c006000 0x2000>;
 interrupts = <1 9 0xf04>;
 };

 This means:
   - reg entry 1. covers address range B,
   - reg entry 2. covers address range C,
   - reg entry 3. covers address ranges D _and_ E,
   - reg entry 4. covers address range F.

 On R-Car Gen3, the base addresses are:

 Distributor : 0xF101_
 CPU interfaces  : 0xF102_
 Virtual interfaces  : 0xF104_
 Virtual interfaces  : 0xF105_
 Virtual CPU interfaces  : 0xF106_

 Note the additional multiplication factor of 16 in the offsets relative to
 the base address 0xf100 (e.g. 0x5 instead of 0x5000).

 As address ranges D and E are merged in a single reg entry, how is the GIC
 driver supposed to know about this multiplication factor?
>>
>> The answer is very simple, the GIC driver doesn't give a damn about the
>> second part of the GICH region, because it is absolutely unusable for
>> any realistic use-case. Only the banked version of GICH is of any
>> relevance (the first 512 bytes, in essence).
>>
>> Aligning the GIC regions on 64kB boundaries is documented in the SBSA
>> specification, independently of the GIC400 documentation.
> 
> If I understand the SBSA spec correctly (BTW, arm,gic.txt doesn't use the
> "GICC" terminology, unlike arm,gic-v3.txt), that means reg entry 3 should be
> "<0xf104f000 0x2000>", so it covers the aliased last 4 KiB of address range D,
> and the first 4 KiB of address range E. I.e.
> 
> reg = <0x0 0xf101 0 0x1000>,
>  <0x0 0xf102 0 0x2000>,
>  <0x0 0xf104f000 0 0x2000>,
>  <0x0 0xf106 0 0x2000>;
> 
> Is that correct?

My preference would be to expose the full 128kB of the region - assuming
your HW actually supports the SBSA aliasing.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8] arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)

[Geert Uytterhoeven]

Hi Marc,

On Mon, Feb 15, 2016 at 9:45 AM, Marc Zyngier  wrote:
> On 15/02/16 08:16, Geert Uytterhoeven wrote:
>> On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven  
>> wrote:
>>> On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland  wrote:
 On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
> On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland  
> wrote:
 +   gic: interrupt-controller@0xf101 {
>>> + compatible = "arm,gic-400";
>>> + #interrupt-cells = <3>;
>>> + #address-cells = <0>;
>>> + interrupt-controller;
>>> + reg = <0x0 0xf101 0 0x1000>,
>>> +   <0x0 0xf102 0 0x2000>;
>>> + interrupts = >> + (GIC_CPU_MASK_SIMPLE(1) | 
>>> IRQ_TYPE_LEVEL_HIGH)>;
>>> + };
>>
>> No GICH and GICV?
>
> These seem to be defined in the "arm,gic-v3" DT bindings only, while this 
> is
> an "arm,gic-400" (GICD_IIDR 0x0200043b)?

 See the "GIC virtualization extensions (VGIC)" section in
 Documentation/devicetree/bindings/arm/gic.txt
>>>
>>> DDI0471B_gic400_r0p1_trm.pdf says:
>>>
>>> Address range GIC-400 functional block
>>> A. 0x - 0x0FFF Reserved
>>> B. 0x1000 - 0x1FFF Distributor
>>> C. 0x2000 - 0x3FFF CPU interfaces
>>> D. 0x4000 - 0x4FFF Virtual interface control block, for the processor 
>>> that
>>>is performing the access
>>> E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
>>>selected by address bits [11:9]
>>> F. 0x6000 - 0x7FFF Virtual CPU interfaces
>>>
>>> The DT binding document says:
>>>   1. The  first region is the GIC distributor register base and size.
>>>   2. The 2nd region is the GIC cpu interface register base and size.
>>>   3. The first additional region is the GIC virtual interface control 
>>> register
>>>  base and size.
>>>   4. The 2nd additional region is the GIC virtual cpu interface register 
>>> base
>>>  and size.
>>>
>>> Matching with the example:
>>>
>>> interrupt-controller@2c001000 {
>>> compatible = "arm,cortex-a15-gic";
>>> #interrupt-cells = <3>;
>>> interrupt-controller;
>>> reg = <0x2c001000 0x1000>,
>>>   <0x2c002000 0x1000>,
>>>   <0x2c004000 0x2000>,
>>>   <0x2c006000 0x2000>;
>>> interrupts = <1 9 0xf04>;
>>> };
>>>
>>> This means:
>>>   - reg entry 1. covers address range B,
>>>   - reg entry 2. covers address range C,
>>>   - reg entry 3. covers address ranges D _and_ E,
>>>   - reg entry 4. covers address range F.
>>>
>>> On R-Car Gen3, the base addresses are:
>>>
>>> Distributor : 0xF101_
>>> CPU interfaces  : 0xF102_
>>> Virtual interfaces  : 0xF104_
>>> Virtual interfaces  : 0xF105_
>>> Virtual CPU interfaces  : 0xF106_
>>>
>>> Note the additional multiplication factor of 16 in the offsets relative to
>>> the base address 0xf100 (e.g. 0x5 instead of 0x5000).
>>>
>>> As address ranges D and E are merged in a single reg entry, how is the GIC
>>> driver supposed to know about this multiplication factor?
>
> The answer is very simple, the GIC driver doesn't give a damn about the
> second part of the GICH region, because it is absolutely unusable for
> any realistic use-case. Only the banked version of GICH is of any
> relevance (the first 512 bytes, in essence).
>
> Aligning the GIC regions on 64kB boundaries is documented in the SBSA
> specification, independently of the GIC400 documentation.

If I understand the SBSA spec correctly (BTW, arm,gic.txt doesn't use the
"GICC" terminology, unlike arm,gic-v3.txt), that means reg entry 3 should be
"<0xf104f000 0x2000>", so it covers the aliased last 4 KiB of address range D,
and the first 4 KiB of address range E. I.e.

reg = <0x0 0xf101 0 0x1000>,
 <0x0 0xf102 0 0x2000>,
 <0x0 0xf104f000 0 0x2000>,
 <0x0 0xf106 0 0x2000>;

Is that correct?

Thanks again!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH/RFC 3/9] v4l: Add Renesas R-Car FCP driver

[Geert Uytterhoeven]

Hi Laurent,

On Fri, Feb 12, 2016 at 3:00 AM, Laurent Pinchart
 wrote:
> The FCP is a companion module of video processing modules in the
> Renesas R-Car Gen3 SoCs. It provides data compression and decompression,
> data caching, and converting of AXI transaction in order to reduce the

"conversion"?

> memory bandwidth.
>
> The driver is not meant to be used standalone but provides an API to the
> video processing modules to control the FCP.
>
> Signed-off-by: Laurent Pinchart 

Thanks for your patch!

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,fcp.txt
> @@ -0,0 +1,24 @@
> +Renesas R-Car Frame Compression Processor (FCP)
> +---
> +
> +The FCP is a companion module of video processing modules in the Renesas 
> R-Car
> +Gen3 SoCs. It provides data compression and decompression, data caching, and
> +converting of AXI transaction in order to reduce the memory bandwidth.

"conversion"?

> +
> +There are three types of FCP whose configuration and behaviour highly depend
> +on the module they are paired with.
> +
> + - compatible: Must be one of the following
> +   - "renesas,fcpv" for the 'FCP for VSP' device

Any chance this module can turn up in another SoC later? I guess yes.
What about future-proofing using "renesas,r8a7795-fcpv" and
"renesas,rcar-gen3-fcpv"?

> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index fd4fcd5a7184..cbb4e5735bf8 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -255,6 +255,19 @@ config VIDEO_RENESAS_JPU
>   To compile this driver as a module, choose M here: the module
>   will be called rcar_jpu.
>
> +config VIDEO_RENESAS_FCP
> +   tristate "Renesas Frame Compression Processor"
> +   depends on ARCH_SHMOBILE || COMPILE_TEST

ARCH_RENESAS

> diff --git a/drivers/media/platform/rcar-fcp.c 
> b/drivers/media/platform/rcar-fcp.c
> new file mode 100644
> index ..cf8cb629ae4f
> --- /dev/null
> +++ b/drivers/media/platform/rcar-fcp.c

> +struct rcar_fcp_device *rcar_fcp_get(const struct device_node *np)
> +{
> +   struct rcar_fcp_device *fcp;
> +
> +   mutex_lock(_lock);
> +
> +   list_for_each_entry(fcp, _devices, list) {
> +   if (fcp->dev->of_node != np)
> +   continue;
> +
> +   /*
> +* Make sure the module won't be unloaded behind our back. 
> This
> +* is a poor's man safety net, the module should really not be

poor man's

> diff --git a/include/media/rcar-fcp.h b/include/media/rcar-fcp.h
> new file mode 100644
> index ..4260cf48d3b1
> --- /dev/null
> +++ b/include/media/rcar-fcp.h
> @@ -0,0 +1,34 @@
> +/*
> + * rcar-fcp.h  --  R-Car Frame Compression Processor Driver
> + *
> + * Copyright (C) 2016 Renesas Electronics Corporation
> + *
> + * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#ifndef __MEDIA_RCAR_FCP_H__
> +#define __MEDIA_RCAR_FCP_H__
> +
> +struct device_node;
> +struct rcar_fcp_device;
> +
> +#if IS_ENABLED(CONFIG_VIDEO_RENESAS_FCP)
> +struct rcar_fcp_device *rcar_fcp_get(const struct device_node *np);
> +void rcar_fcp_put(struct rcar_fcp_device *fcp);
> +void rcar_fcp_enable(struct rcar_fcp_device *fcp);
> +void rcar_fcp_disable(struct rcar_fcp_device *fcp);
> +#else
> +static inline struct rcar_fcp_device *rcar_fcp_get(const struct device_node 
> *np)
> +{
> +   return ERR_PTR(-ENOENT);
> +}
> +static inline void rcar_fcp_put(struct rcar_fcp_device *fcp) { }
> +static inline void rcar_fcp_enable(struct rcar_fcp_device *fcp) { }
> +static inline void rcar_fcp_disable(struct rcar_fcp_device *fcp) { }

Given the dummies, the vsp driver can also work when FCP support is not
enabled?
Or is this meant purely to avoid #ifdefs in the vsp driver when compiling for
R-Car Gen2?

In case of the latter, you may want to enforce this in Kconfig.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [RFC/PATCH] [media] rcar-vin: add Renesas R-Car VIN IP core

[Hans Verkuil]

On 02/14/2016 05:55 PM, Niklas Söderlund wrote:
> A V4L2 driver for Renesas R-Car VIN IP cores that do not depend on
> soc_camera. The driver is heavily based on its predecessor and aims to
> replace the soc_camera driver.

Fantastic! I've been hoping that this would be done at some point. It
was very unfortunate that Renesas went with soc-camera initially.

> Signed-off-by: Niklas Söderlund 
> ---
> 
> The driver is tested on Koelsch and can grab frames using yavta.  It
> also passes a v4l2-compliance (1.10.0) run without failures.

Did you compile v4l2-compliance from the master branch of the v4l-utils.git
repo? I always recommend that.

Can you post the output of 'v4l2-compliance -s' and ideally also 
'v4l2-compliance -f'?

I always like to see that for new drivers.

> There is
> however a issues sometimes if one first run v4l2-compliance and then
> yavta the grabbed frames are a bit fuzzy. I'm working on it. Also I
> could only get frames if the video signal on the composite IN was NTSC,
> but this also applied to the soc_camera driver, it might be my test
> setup.
> 
> As stated in commit message the driver is based on its soc_camera
> version but some features have been drooped (for now?).
>  - The driver no longer try to use the subdev for cropping (using
>cropcrop/s_crop).
>  - Do not interrogate the subdev using g_mbus_config.
> 
> The goal is to replace the soc_camera driver completely to prepare for
> Gen3 enablement.  Is it a good idea to aim for inheriting
> CONFIG_VIDEO_RCAR_VIN in such case?  I'm thinking down the road if this
> driver is good enough to simply rename the old CONFIG_VIDEO_RCAR_VIN to
> something like CONFIG_VIDEO_SOC_CAMERA_RCAR_VIN mark is at deprecated
> and use this one as a drop in replacement.

We probably want to have both for some time with the soc-camera version
marked as 'DEPRECATED'. Especially as long as they aren't at feature parity.

> The main feature missing at this point is vidioc_[gs]_selection. The
> driver can crop/scale but it's not exposed to the user. However this
> will be different on Gen3 HW where not all channels have scalers.

Do you plan to add this in the next version?

> More stress testing is also needed for example streaming over longer
> periods.
> 

Review comments follow:

>  drivers/media/platform/rcar-vin/rcar-dma.c   |  942 
>  drivers/media/platform/rcar-vin/rcar-vin.h   |  178 +++
>  drivers/media/platform/rcar-vin/rcar-vinip.c | 1552 
> ++
>  3 files changed, 2672 insertions(+)
>  create mode 100644 drivers/media/platform/rcar-vin/rcar-dma.c
>  create mode 100644 drivers/media/platform/rcar-vin/rcar-vin.h
>  create mode 100644 drivers/media/platform/rcar-vin/rcar-vinip.c
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> new file mode 100644
> index 000..8041e0d
> --- /dev/null
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -0,0 +1,942 @@
> +/*
> + * Driver for Renesas R-Car VIN IP
> + *
> + * Copyright (C) 2016 Renesas Solutions Corp.
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "rcar-vin.h"
> +
> +#define VIN_MAX_WIDTH2048
> +#define VIN_MAX_HEIGHT   2048
> +#define TIMEOUT_MS   100
> +
> +struct rvin_buffer {
> + struct vb2_v4l2_buffer vb;
> + struct list_head list;
> +};
> +
> +#define to_buf_list(vb2_buffer) (_of(vb2_buffer, \
> + struct rvin_buffer, \
> + vb)->list)
> +
> +/* 
> -
> + * DMA Functions
> + */
> +
> +static int rvin_get_free_hw_slot(struct rvin_dev *vin)
> +{
> + int slot;
> +
> + for (slot = 0; slot < vin->nr_hw_slots; slot++)
> + if (vin->queue_buf[slot] == NULL)
> + return slot;
> +
> + return -1;
> +}
> +
> +static int rvin_hw_ready(struct rvin_dev *vin)
> +{
> + /* Ensure all HW slots are filled */
> + return rvin_get_free_hw_slot(vin) < 0 ? 1 : 0;
> +}
> +
> +/* Moves a buffer from the queue to the HW slots */
> +static int rvin_fill_hw_slot(struct rvin_dev *vin)
> +{
> + struct rvin_buffer *buf;
> + struct vb2_v4l2_buffer *vbuf;
> + dma_addr_t phys_addr_top;
> + int slot;
> +
> + if (list_empty(>buf_list))
> + return 0;
> +
> + /* Search for free HW slot */
> + slot = rvin_get_free_hw_slot(vin);
> + if (slot < 0)
> + return 0;
> +
> + /* Keep track of buffer we give to HW */
> + buf = list_entry(vin->buf_list.next, struct rvin_buffer, list);
> + 

Re: [PATCH/RFC 2/9] clk: shmobile: r8a7795: Add LVDS module clock

[Geert Uytterhoeven]

On Fri, Feb 12, 2016 at 3:00 AM, Laurent Pinchart
 wrote:
> The parent clock hasn't been validated yet.

I assume the driver doesn't depend on the clock rate?

> Signed-off-by: Laurent Pinchart 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH/RFC 1/9] clk: shmobile: r8a7795: Add FCP clocks

[Geert Uytterhoeven]

On Fri, Feb 12, 2016 at 3:00 AM, Laurent Pinchart
 wrote:
> The parent clock isn't documented in the datasheet, use S2D1 as a best
> guess for now.

Looks like a good guess...
I assume the driver doesn't depend on the clock rate?

> Signed-off-by: Laurent Pinchart 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8] arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)

[Marc Zyngier]

On 15/02/16 08:16, Geert Uytterhoeven wrote:
> Cc Marz Zyngier
> Cc Dirk Behme
> Cc devicetree
> Cc linux-renesas-soc
> Drop linux-sh
> 
> On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven  
> wrote:
>> On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland  wrote:
>>> On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
 On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland  
 wrote:
>>> +   gic: interrupt-controller@0xf101 {
>> + compatible = "arm,gic-400";
>> + #interrupt-cells = <3>;
>> + #address-cells = <0>;
>> + interrupt-controller;
>> + reg = <0x0 0xf101 0 0x1000>,
>> +   <0x0 0xf102 0 0x2000>;
>> + interrupts = > + (GIC_CPU_MASK_SIMPLE(1) | 
>> IRQ_TYPE_LEVEL_HIGH)>;
>> + };
>
> No GICH and GICV?

 These seem to be defined in the "arm,gic-v3" DT bindings only, while this 
 is
 an "arm,gic-400" (GICD_IIDR 0x0200043b)?
>>>
>>> See the "GIC virtualization extensions (VGIC)" section in
>>> Documentation/devicetree/bindings/arm/gic.txt
>>
>> DDI0471B_gic400_r0p1_trm.pdf says:
>>
>> Address range GIC-400 functional block
>> A. 0x - 0x0FFF Reserved
>> B. 0x1000 - 0x1FFF Distributor
>> C. 0x2000 - 0x3FFF CPU interfaces
>> D. 0x4000 - 0x4FFF Virtual interface control block, for the processor 
>> that
>>is performing the access
>> E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
>>selected by address bits [11:9]
>> F. 0x6000 - 0x7FFF Virtual CPU interfaces
>>
>> The DT binding document says:
>>   1. The  first region is the GIC distributor register base and size.
>>   2. The 2nd region is the GIC cpu interface register base and size.
>>   3. The first additional region is the GIC virtual interface control 
>> register
>>  base and size.
>>   4. The 2nd additional region is the GIC virtual cpu interface register base
>>  and size.
>>
>> Matching with the example:
>>
>> interrupt-controller@2c001000 {
>> compatible = "arm,cortex-a15-gic";
>> #interrupt-cells = <3>;
>> interrupt-controller;
>> reg = <0x2c001000 0x1000>,
>>   <0x2c002000 0x1000>,
>>   <0x2c004000 0x2000>,
>>   <0x2c006000 0x2000>;
>> interrupts = <1 9 0xf04>;
>> };
>>
>> This means:
>>   - reg entry 1. covers address range B,
>>   - reg entry 2. covers address range C,
>>   - reg entry 3. covers address ranges D _and_ E,
>>   - reg entry 4. covers address range F.
>>
>> On R-Car Gen3, the base addresses are:
>>
>> Distributor : 0xF101_
>> CPU interfaces  : 0xF102_
>> Virtual interfaces  : 0xF104_
>> Virtual interfaces  : 0xF105_
>> Virtual CPU interfaces  : 0xF106_
>>
>> Note the additional multiplication factor of 16 in the offsets relative to
>> the base address 0xf100 (e.g. 0x5 instead of 0x5000).
>>
>> As address ranges D and E are merged in a single reg entry, how is the GIC
>> driver supposed to know about this multiplication factor?

The answer is very simple, the GIC driver doesn't give a damn about the
second part of the GICH region, because it is absolutely unusable for
any realistic use-case. Only the banked version of GICH is of any
relevance (the first 512 bytes, in essence).

Aligning the GIC regions on 64kB boundaries is documented in the SBSA
specification, independently of the GIC400 documentation.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v2] arm64: dts: r8a7795: use GIC_* defines

[Geert Uytterhoeven]

On Tue, Feb 2, 2016 at 2:31 PM, Simon Horman  wrote:
> Use GIC_* defines for GIC interrupt cells in r8a7795 device tree.
>
> Signed-off-by: Simon Horman 

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8] arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)

[Geert Uytterhoeven]

Cc Marz Zyngier
Cc Dirk Behme
Cc devicetree
Cc linux-renesas-soc
Drop linux-sh

On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven  wrote:
> On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland  wrote:
>> On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
>>> On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland  wrote:
>>> >> > +   gic: interrupt-controller@0xf101 {
>>> >> + compatible = "arm,gic-400";
>>> >> + #interrupt-cells = <3>;
>>> >> + #address-cells = <0>;
>>> >> + interrupt-controller;
>>> >> + reg = <0x0 0xf101 0 0x1000>,
>>> >> +   <0x0 0xf102 0 0x2000>;
>>> >> + interrupts = >> >> + (GIC_CPU_MASK_SIMPLE(1) | 
>>> >> IRQ_TYPE_LEVEL_HIGH)>;
>>> >> + };
>>> >
>>> > No GICH and GICV?
>>>
>>> These seem to be defined in the "arm,gic-v3" DT bindings only, while this is
>>> an "arm,gic-400" (GICD_IIDR 0x0200043b)?
>>
>> See the "GIC virtualization extensions (VGIC)" section in
>> Documentation/devicetree/bindings/arm/gic.txt
>
> DDI0471B_gic400_r0p1_trm.pdf says:
>
> Address range GIC-400 functional block
> A. 0x - 0x0FFF Reserved
> B. 0x1000 - 0x1FFF Distributor
> C. 0x2000 - 0x3FFF CPU interfaces
> D. 0x4000 - 0x4FFF Virtual interface control block, for the processor that
>is performing the access
> E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
>selected by address bits [11:9]
> F. 0x6000 - 0x7FFF Virtual CPU interfaces
>
> The DT binding document says:
>   1. The  first region is the GIC distributor register base and size.
>   2. The 2nd region is the GIC cpu interface register base and size.
>   3. The first additional region is the GIC virtual interface control register
>  base and size.
>   4. The 2nd additional region is the GIC virtual cpu interface register base
>  and size.
>
> Matching with the example:
>
> interrupt-controller@2c001000 {
> compatible = "arm,cortex-a15-gic";
> #interrupt-cells = <3>;
> interrupt-controller;
> reg = <0x2c001000 0x1000>,
>   <0x2c002000 0x1000>,
>   <0x2c004000 0x2000>,
>   <0x2c006000 0x2000>;
> interrupts = <1 9 0xf04>;
> };
>
> This means:
>   - reg entry 1. covers address range B,
>   - reg entry 2. covers address range C,
>   - reg entry 3. covers address ranges D _and_ E,
>   - reg entry 4. covers address range F.
>
> On R-Car Gen3, the base addresses are:
>
> Distributor : 0xF101_
> CPU interfaces  : 0xF102_
> Virtual interfaces  : 0xF104_
> Virtual interfaces  : 0xF105_
> Virtual CPU interfaces  : 0xF106_
>
> Note the additional multiplication factor of 16 in the offsets relative to
> the base address 0xf100 (e.g. 0x5 instead of 0x5000).
>
> As address ranges D and E are merged in a single reg entry, how is the GIC
> driver supposed to know about this multiplication factor?
>
> Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds