[PATCH] pinctrl: sh-pfc: r8a77990: Add support for pull-up only pins
The R-Car Gen3 HardWare Manual Errata for Rev. 1.00 (Jul 2, 2018) states
that the USB30_OVC pin supports pull-up only. It has a bit assigned in
the pull-enable register (PUEN5), but not in the pull-up/down control
register (PUD5).
Add a check for this, to prevent configuring a prohibited setting.
Reported-by: Yoshihiro Shimoda
Fixes: 83f6941a42a5e773 ("pinctrl: sh-pfc: r8a77990: Add bias pinconf support")
Signed-off-by: Geert Uytterhoeven
---
To be queued in sh-pfc-for-v4.22.
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index 8c06d72753890e32..784d4400c3e0e7ea 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -4914,6 +4914,17 @@ static const struct pinmux_bias_reg pinmux_bias_regs[] =
{
{ /* sentinel */ },
};
+static bool pin_has_pud(unsigned int pin)
+{
+ /* Some pins are pull-up only */
+ switch (pin) {
+ case RCAR_GP_PIN(6, 9): /* USB30_OVC */
+ return false;
+ }
+
+ return true;
+}
+
static unsigned int r8a77990_pinmux_get_bias(struct sh_pfc *pfc,
unsigned int pin)
{
@@ -4926,7 +4937,7 @@ static unsigned int r8a77990_pinmux_get_bias(struct
sh_pfc *pfc,
if (!(sh_pfc_read(pfc, reg->puen) & BIT(bit)))
return PIN_CONFIG_BIAS_DISABLE;
- else if (sh_pfc_read(pfc, reg->pud) & BIT(bit))
+ else if (!pin_has_pud(pin) || (sh_pfc_read(pfc, reg->pud) & BIT(bit)))
return PIN_CONFIG_BIAS_PULL_UP;
else
return PIN_CONFIG_BIAS_PULL_DOWN;
@@ -4947,11 +4958,13 @@ static void r8a77990_pinmux_set_bias(struct sh_pfc
*pfc, unsigned int pin,
if (bias != PIN_CONFIG_BIAS_DISABLE)
enable |= BIT(bit);
- updown = sh_pfc_read(pfc, reg->pud) & ~BIT(bit);
- if (bias == PIN_CONFIG_BIAS_PULL_UP)
- updown |= BIT(bit);
+ if (pin_has_pud(pin)) {
+ updown = sh_pfc_read(pfc, reg->pud) & ~BIT(bit);
+ if (bias == PIN_CONFIG_BIAS_PULL_UP)
+ updown |= BIT(bit);
- sh_pfc_write(pfc, reg->pud, updown);
+ sh_pfc_write(pfc, reg->pud, updown);
+ }
sh_pfc_write(pfc, reg->puen, enable);
}
--
2.17.1
[git pull] clk: renesas: Updates for v4.21 (take two)
Hi Mike, Stephen,
The following changes since commit eb38c119dd91c61de26f67050671a84064554f7d:
clk: renesas: r7s9210: Add USB clocks (2018-11-13 09:58:51 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
tags/clk-renesas-for-v4.21-tag2
for you to fetch changes up to 36c4da4f552a126bb29a95dc5c9608795491e32a:
clk: renesas: rcar-gen3: Add HS400 quirk for SD clock (2018-12-07 11:45:06
+0100)
clk: renesas: Updates for v4.21 (take two)
- Add support for CPEX (timer) clocks on various R-Car Gen3 and RZ/G2
SoCs,
- Add support for SDHI HS400 clocks on early revisions of R-Car H3 and
M3-W,
- Miscellaneous fixes based on the Hardware Manual Errata.
Thanks for pulling!
Geert Uytterhoeven (12):
dt-bindings: clock: r8a7795: Remove CSIREF clock
dt-bindings: clock: r8a7796: Remove CSIREF clock
clk: renesas: r8a774a1: Add CPEX clock
clk: renesas: r8a7795: Add CPEX clock
clk: renesas: r8a7796: Add CPEX clock
clk: renesas: r8a77965: Add CPEX clock
clk: renesas: r8a77970: Add CPEX clock
clk: renesas: r8a77995: Correct parent clock of DU
clk: renesas: r8a77995: Remove non-existent VIN5-7 module clocks
clk: renesas: r8a77995: Remove non-existent SSP clocks
clk: renesas: r8a77995: Add missing CPEX clock
clk: renesas: r8a77995: Simplify PLL3 multiplier/divider
Niklas Söderlund (3):
clk: renesas: rcar-gen3: Set state when registering SD clocks
clk: renesas: rcar-gen3: Add documentation for SD clocks
clk: renesas: rcar-gen3: Add HS400 quirk for SD clock
Takeshi Kihara (1):
clk: renesas: r8a77990: Correct parent clock of DU
drivers/clk/renesas/r8a774a1-cpg-mssr.c | 1 +
drivers/clk/renesas/r8a7795-cpg-mssr.c| 1 +
drivers/clk/renesas/r8a7796-cpg-mssr.c| 1 +
drivers/clk/renesas/r8a77965-cpg-mssr.c | 1 +
drivers/clk/renesas/r8a77970-cpg-mssr.c | 1 +
drivers/clk/renesas/r8a77990-cpg-mssr.c | 4 +-
drivers/clk/renesas/r8a77995-cpg-mssr.c | 15 +++-
drivers/clk/renesas/rcar-gen3-cpg.c | 55 ---
include/dt-bindings/clock/r8a7795-cpg-mssr.h | 2 +-
include/dt-bindings/clock/r8a7796-cpg-mssr.h | 2 +-
include/dt-bindings/clock/r8a77995-cpg-mssr.h | 5 ++-
11 files changed, 51 insertions(+), 37 deletions(-)
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
[git pull] pinctrl: sh-pfc: Updates for v4.21 (take two)
Hi Linus,
The following changes since commit b59d0e782706785b7042539e820e95df3be4d04c:
pinctrl: Add RZ/A2 pin and gpio controller (2018-11-23 09:30:27 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
tags/sh-pfc-for-v4.21-tag2
for you to fetch changes up to 3f3327dbc5596076f94695d8d4cc66da3d5027fb:
pinctrl: rzn1: Fix of_get_child_count() error check (2018-12-04 10:33:49
+0100)
pinctrl: sh-pfc: Updates for v4.21 (take two)
- Two small fixes for RZ/N1.
Thanks for pulling!
Phil Edworthy (2):
pinctrl: rzn1: Fix check for used MDIO bus
pinctrl: rzn1: Fix of_get_child_count() error check
drivers/pinctrl/pinctrl-rzn1.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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
[git pull] pinctrl: sh-pfc: Updates for v4.21
Hi Linus,
The following changes since commit b59d0e782706785b7042539e820e95df3be4d04c:
pinctrl: Add RZ/A2 pin and gpio controller (2018-11-23 09:30:27 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
tags/sh-pfc-for-v4.21-tag2
for you to fetch changes up to 3f3327dbc5596076f94695d8d4cc66da3d5027fb:
pinctrl: rzn1: Fix of_get_child_count() error check (2018-12-04 10:33:49
+0100)
pinctrl: sh-pfc: Updates for v4.21 (take two)
- Two small fixes for RZ/N1.
Thanks for pulling!
Phil Edworthy (2):
pinctrl: rzn1: Fix check for used MDIO bus
pinctrl: rzn1: Fix of_get_child_count() error check
drivers/pinctrl/pinctrl-rzn1.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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 v3 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
Hi Biju,
On Fri, Dec 7, 2018 at 11:16 AM Biju Das wrote:
> > Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
> > On Fri, Dec 7, 2018 at 10:34 AM Biju Das wrote:
> > > > Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP
> > > > pcf85263 rtc
> > > > I think it is probably better to ensure the nvmem core never passes
> > > > an invalid number of bytes. All the ther RTC drivers make that
> > assumption.
> > >
> > > In that case, I will do following checks in
> > > nvmem_device_{read,write}() before calling nvmem_reg_{read,write}(),
> > >
> > > nvmem_device_read
> > >
> > > /* Stop the user from reading */
> > > if (offset >= nvmem->size)
> > > return 0;
> > >
> > > if (bytes == 0)
> > > return -EINVAL;
> >
> > Why not 0?
>
> Ok. Will merge with above check.
>
> if ((offset >= nvmem->size) && (bytes == 0))
"||" ;-)
> return 0;
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 2/5] pwm: rcar: Add support "atomic" API
Hi Uwe,
On Fri, Dec 7, 2018 at 10:08 AM Uwe Kleine-König
wrote:
> On Fri, Dec 07, 2018 at 05:29:30PM +0900, Yoshihiro Shimoda wrote:
> > This patch adds support for "atomic" API. Behavior is the same as
> > when using legacy APIs.
> >
> > Signed-off-by: Yoshihiro Shimoda
> > ---
> > drivers/pwm/pwm-rcar.c | 32
> > 1 file changed, 32 insertions(+)
> >
> > diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
> > index 9cf4567..a5ea0f3 100644
> > --- a/drivers/pwm/pwm-rcar.c
> > +++ b/drivers/pwm/pwm-rcar.c
> > @@ -200,12 +200,44 @@ static void rcar_pwm_disable(struct pwm_chip *chip,
> > struct pwm_device *pwm)
> > rcar_pwm_update(rp, RCAR_PWMCR_EN0, 0, RCAR_PWMCR);
> > }
> >
> > +static int rcar_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > + struct pwm_state *state)
> > +{
> > + struct rcar_pwm_chip *rp = to_rcar_pwm_chip(chip);
> > + int div, ret;
> > +
> > + div = rcar_pwm_get_clock_division(rp, state->period);
> > + if (div < 0)
> > + return div;
> > +
> > + rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR);
> > +
> > + rcar_pwm_calc_counter(rp, div, state->duty_cycle, state->period);
> > + ret = rcar_pwm_set_counter(rp);
> > + if (!ret)
> > + rcar_pwm_set_clock_control(rp, div);
> > +
> > + /* The SYNC should be set to 0 even if rcar_pwm_set_counter failed */
> > + rcar_pwm_update(rp, RCAR_PWMCR_SYNC, 0, RCAR_PWMCR);
> > +
> > + if (!ret && state->enabled)
> > + ret = rcar_pwm_enable(chip, pwm);
> > +
> > + if (!state->enabled) {
> > + rcar_pwm_disable(chip, pwm);
> > + ret = 0;
> > + }
> > +
> > + return ret;
>
> state->polarity isn't used here which is a bug I think.
>
> Is the documentation for this hardware publically available?
Please check Section 59 of the "User's Manual: Hardware" at
https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rz/rzg/rzg1m.html
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
Re: [PATCH 2/3] arm64: defconfig: Enable scu-simple-card driver
Hi Simon,
On Thu, Dec 6, 2018 at 10:58 PM Simon Horman wrote:
> Enable the scu-simple-card which is used by
> the R-Car E3 (r8a77990) based Ebisu board.
>
> Signed-off-by: Simon Horman
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index f88190463481..9d0b42d96f03 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -491,6 +491,7 @@ CONFIG_SND_SOC_RT5514=m
> CONFIG_SND_SOC_RT5514_SPI=m
> CONFIG_SND_SOC_RT5645=m
> CONFIG_SND_SIMPLE_CARD=m
> +CONFIG_SND_SIMPLE_SCU_CARD=y
Shouldn't this be "m"?
> CONFIG_SND_AUDIO_GRAPH_CARD=m
> CONFIG_I2C_HID=m
> CONFIG_USB=y
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: phandles using absolute paths in DT overlays
Hi David,
Thanks for your answer!
On Fri, Dec 7, 2018 at 2:44 AM David Gibson wrote:
> On Thu, Dec 06, 2018 at 01:56:45PM +0100, Geert Uytterhoeven wrote:
> > Some early revisions of SoCs may have hardware bugs that need to be
> > fixed up in DT. Currently we are handling this by including DTS files
> > and fixing up nodes and properties, to create different DTB files for
> > different SoC revisons (see arch/arm64/boot/dts/renesas/*es1*).
> >
> > As an alternative, I'm envisioning the use of DT overlays and the
> > fdtoverlay tool, in the hope of simplifying the generation of DTBs for
> > the various SoC/board combinations.
> >
> > Ideally, such DTBs would not contain symbols, to avoid inflating DTB
> > size. Hence if fixup overlays would not contain symbolic references,
> > there would be no need for symbols.
> >
> > For anchors, the "&{/path/to/node@address}" syntax is working fine.
> > For phandles, while documented on
> > https://elinux.org/Device_Tree_Mysteries, and while working fine for the
> > non-overlay case, dtc seems to have issues interpreting the DTB:
> >
> > $ scripts/dtc/dtc -I dtb -O dts my.dtb | less
> > : ERROR (property_name_chars):
> > /__fixups__:/path/to/node@deadbeef: Bad character '/' in property
> > name
> > ERROR: Input tree has errors, aborting (use -f to force output)
> >
> > With -f, the fixup generated seems to contain the expected value, though:
> >
> > __fixups__ {
> > /path/to/node@deadbeef = "/fragment@0/__overlay__:power-domains:0";
> > };
> >
> > When using ftdoverlay, the situation is worse:
> >
> > Failed to apply my.dtb (-1)
> >
> > Are these known issues?
>
> Unfortunately, this can't work with the current overlay format. We
> have a specific syntax to allow the target of an overlay fragment to
> specified as a path, but phandle references by path won't work.
>
> The problem is that the encoding of the fixups node has the fixup
> target as a property name, and as the error says '/' is an illegal
> character in property names - for a bunch of good reasons, so we can't
> just go and remove that restriction.
For the uneducated, can you please explain why '/' is an illegal character,
and why it can't be special cased for phandle references by path in overlays?
> So to allow this we'd need to come up with a different encoding for
> path-targeted fixups and add support for it in the various pieces of
> the chain.
>
> One way to do that would be to entirely rework the overlay format to
> something more sensible, which would have a number of other benefits.
IC.
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
Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
Hi Biju,
On Thu, Dec 6, 2018 at 4:24 PM Biju Das wrote:
> > Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
> > CC nvmem maintainer
> >
> > On Thu, Dec 6, 2018 at 10:04 AM Biju Das wrote:
> > > Add support for NXP pcf85263 real-time clock. pcf85263 rtc is
> > > compatible with pcf85363,except that pcf85363 has additional 64 bytes of
> > RAM.
> > > --- a/drivers/rtc/rtc-pcf85363.c
> > > +++ b/drivers/rtc/rtc-pcf85363.c
> > > @@ -120,6 +120,11 @@ struct pcf85363 {
> > > struct regmap *regmap;
> > > };
> > >
> > > +struct pcf85x63_config {
> > > + struct regmap_config regmap;
> > > + unsigned int num_nvram;
> > > +};
> > > +
> > > static int pcf85363_rtc_read_time(struct device *dev, struct rtc_time
> > > *tm) {
> > > struct pcf85363 *pcf85363 = dev_get_drvdata(dev); @@ -311,25
> > > +316,68 @@ static int pcf85363_nvram_write(void *priv, unsigned int
> > offset, void *val,
> > > val, bytes); }
> > >
> > > -static const struct regmap_config regmap_config = {
> > > - .reg_bits = 8,
> > > - .val_bits = 8,
> > > - .max_register = 0x7f,
> > > +static int pcf85x63_nvram_read(void *priv, unsigned int offset, void
> > > *val,
> > > + size_t bytes)
> >
> > Given bytes should be 1, val should be a pointer to a single byte...
> > What if bytes == 0?
>
> I doubt we get "bytes==0" because of the checks in " drivers/nvmem/core.c"
> Function " bin_attr_nvmem_read/ bin_attr_nvmem_write".
Depends. There are other functions calling nvmem_reg_{read,write}(),
e.g. nvmem_device_{read,write}().
>
> > > +{> + struct pcf85363 *pcf85363 = priv;
> > > +
> > > + return regmap_read(pcf85363->regmap, CTRL_RAMBYTE, val);
> >
> > However, regmap_read() has an unsigned int output parameter!
> > So it's writing too many bytes, and only writing the actual data byte to the
> > correct address on little-endian systems.
> > Hence you need to use an intermediate variable to convert from unsigned int
> > to byte.
>
> OK. Will use an intermediate integer variable.
>
> > > +}
> > > +
> > > +static int pcf85x63_nvram_write(void *priv, unsigned int offset, void
> > > *val,
> > > + size_t bytes) {
> > > + struct pcf85363 *pcf85363 = priv;
> > > +
> > > + return regmap_write(pcf85363->regmap, CTRL_RAMBYTE,
> > > + *((unsigned int *)val));
> >
> > Likewise for writing.
> >
> > > +}
> >
> > BTW, while the nvmem_device_{read,write}() public API is documented, the
> > nvmem_device.reg_{read,write}() driver API isn't.
> > And the behavior might be confusing.
> >
> > E.g.
> > * Return: length of successful bytes read on success and negative
> > * error code on error.
> >
> > The public API seems to assume the driver API returns zero on success, and
> > replaces the zero by the number of bytes requested.
> > If the requested number of bytes is too large, a zero success would be
> > converted to a value that's larger than the actual number of bytes
> > transferred!
> > However, the driver API can return a smaller (positive) number, which
> > matches "standard" read/write() APIs.
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 v3 4/4] ARM: dts: iwg23s-sbc: Enable RTC
Hi Biju,
On Thu, Dec 6, 2018 at 1:41 PM Biju Das wrote:
> > Subject: Re: [PATCH v3 4/4] ARM: dts: iwg23s-sbc: Enable RTC
> > On Thu, Dec 6, 2018 at 10:04 AM Biju Das wrote:
> > > Enable NXP pcf85263 real time clock for the iWave SBC based on RZ/G1C.
> > >
> > > Signed-off-by: Biju Das
> >
> > Reviewed-by: Geert Uytterhoeven
> >
> > > --- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> > > +++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> > > @@ -84,12 +84,30 @@
> > > clock-frequency = <2000>;
> > > };
> > >
> > > + {
> > > + pinctrl-0 = <_pins>;
> > > + pinctrl-names = "default";
> > > +
> > > + status = "okay";
> > > + clock-frequency = <40>;
> > > +
> > > + rtc@51 {
> > > + compatible = "nxp,pcf85263";
> > > + reg = <0x51>;
> >
> > You might want to enable the optional interrupt:
>
> I have enabled this but unfortunately it is generating 10 of gpio
> interrupts during boot.
Oh, the DT bindings claim interrupt support hasn't been implement yet ;-)
> The reason is, by default this pin is configured as function(Power on
> reset/at u-boot).
> Currently there is no function available in kernel to convert a pin from
> function to gpio (Similar to the issue Fab is facing for display hot plug
> interrupt)
>
> May be we can add optional interrupt at a later stage, once we have a
> solution for converting pin from function to gpio.
>
> Please share your opinion on this.
IC. In that case, please postpone describing the interrupt until the issue is
fixed.
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
phandles using absolute paths in DT overlays
Hi,
Some early revisions of SoCs may have hardware bugs that need to be
fixed up in DT. Currently we are handling this by including DTS files
and fixing up nodes and properties, to create different DTB files for
different SoC revisons (see arch/arm64/boot/dts/renesas/*es1*).
As an alternative, I'm envisioning the use of DT overlays and the
fdtoverlay tool, in the hope of simplifying the generation of DTBs for
the various SoC/board combinations.
Ideally, such DTBs would not contain symbols, to avoid inflating DTB
size. Hence if fixup overlays would not contain symbolic references,
there would be no need for symbols.
For anchors, the "&{/path/to/node@address}" syntax is working fine.
For phandles, while documented on
https://elinux.org/Device_Tree_Mysteries, and while working fine for the
non-overlay case, dtc seems to have issues interpreting the DTB:
$ scripts/dtc/dtc -I dtb -O dts my.dtb | less
: ERROR (property_name_chars):
/__fixups__:/path/to/node@deadbeef: Bad character '/' in property
name
ERROR: Input tree has errors, aborting (use -f to force output)
With -f, the fixup generated seems to contain the expected value, though:
__fixups__ {
/path/to/node@deadbeef = "/fragment@0/__overlay__:power-domains:0";
};
When using ftdoverlay, the situation is worse:
Failed to apply my.dtb (-1)
Are these known issues?
Thanks for your comments!
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 v3 4/4] ARM: dts: iwg23s-sbc: Enable RTC
Hi Biju,
On Thu, Dec 6, 2018 at 10:04 AM Biju Das wrote:
> Enable NXP pcf85263 real time clock for the iWave SBC based on RZ/G1C.
>
> Signed-off-by: Biju Das
Reviewed-by: Geert Uytterhoeven
> --- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> +++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
> @@ -84,12 +84,30 @@
> clock-frequency = <2000>;
> };
>
> + {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> + clock-frequency = <40>;
> +
> + rtc@51 {
> + compatible = "nxp,pcf85263";
> + reg = <0x51>;
You might want to enable the optional interrupt:
interrupt-parent = <>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
> + };
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 v3 3/4] ARM: shmobile: Enable NXP pcf85363 rtc in shmobile_defconfig
On Thu, Dec 6, 2018 at 10:04 AM Biju Das wrote:
>
> The iWave RZ/G1C SBC supports RTC (NXP pcf85263). To increase hardware
> support enable the driver in the shmobile_defconfig multiplatform
> configuration.
>
> Signed-off-by: Biju Das
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 v3 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
Hi Biju,
CC nvmem maintainer
On Thu, Dec 6, 2018 at 10:04 AM Biju Das wrote:
> Add support for NXP pcf85263 real-time clock. pcf85263 rtc is compatible
> with pcf85363,except that pcf85363 has additional 64 bytes of RAM.
>
> 1 byte of nvmem is supported and exposed in sysfs (# is the instance
> number,starting with 0): /sys/bus/nvmem/devices/pcf85x63-#/nvmem
>
> Signed-off-by: Biju Das
> ---
> V1-->V2
> * Incorporated Alexandre and Geert's review comment.
> V2-->V3
> * Incorporated Geert's review comment.
Thanks for the update!
> --- a/drivers/rtc/rtc-pcf85363.c
> +++ b/drivers/rtc/rtc-pcf85363.c
> @@ -120,6 +120,11 @@ struct pcf85363 {
> struct regmap *regmap;
> };
>
> +struct pcf85x63_config {
> + struct regmap_config regmap;
> + unsigned int num_nvram;
> +};
> +
> static int pcf85363_rtc_read_time(struct device *dev, struct rtc_time *tm)
> {
> struct pcf85363 *pcf85363 = dev_get_drvdata(dev);
> @@ -311,25 +316,68 @@ static int pcf85363_nvram_write(void *priv, unsigned
> int offset, void *val,
> val, bytes);
> }
>
> -static const struct regmap_config regmap_config = {
> - .reg_bits = 8,
> - .val_bits = 8,
> - .max_register = 0x7f,
> +static int pcf85x63_nvram_read(void *priv, unsigned int offset, void *val,
> + size_t bytes)
Given bytes should be 1, val should be a pointer to a single byte...
What if bytes == 0?
> +{> + struct pcf85363 *pcf85363 = priv;
> +
> + return regmap_read(pcf85363->regmap, CTRL_RAMBYTE, val);
However, regmap_read() has an unsigned int output parameter!
So it's writing too many bytes, and only writing the actual data byte to the
correct address on little-endian systems.
Hence you need to use an intermediate variable to convert from unsigned
int to byte.
> +}
> +
> +static int pcf85x63_nvram_write(void *priv, unsigned int offset, void *val,
> + size_t bytes)
> +{
> + struct pcf85363 *pcf85363 = priv;
> +
> + return regmap_write(pcf85363->regmap, CTRL_RAMBYTE,
> + *((unsigned int *)val));
Likewise for writing.
> +}
BTW, while the nvmem_device_{read,write}() public API is documented, the
nvmem_device.reg_{read,write}() driver API isn't.
And the behavior might be confusing.
E.g.
* Return: length of successful bytes read on success and negative
* error code on error.
The public API seems to assume the driver API returns zero on success,
and replaces the zero by the number of bytes requested.
If the requested number of bytes is too large, a zero success would be
converted to a value that's larger than the actual number of bytes
transferred!
However, the driver API can return a smaller (positive) number, which matches
"standard" read/write() APIs.
> +static const struct pcf85x63_config pcf_85263_config = {
> + {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = 0x2f,
> + },
> + 1
The "1" looks funny. Please use C99 initializers for all struct members.
> +};
> +
> +static const struct pcf85x63_config pcf_85363_config = {
> + {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = 0x7f,
> + },
> + 2
Likewise.
The rest looks good to me, so
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 v3 1/4] dt-bindings: rtc: pcf85363: Document pcf85263 real-time clock
On Thu, Dec 6, 2018 at 10:04 AM Biju Das wrote:
> The pcf85263 RTC is compatible with the pcf85363 RTC.
>
> The difference between the pcf85263 and pcf85363 RTC is that the latter has
> 64 bytes more RAM. This renders them incompatible from a DT point of view.
>
> Signed-off-by: Biju Das
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
[RFC PATCH 7/7] soc: renesas: r8a77990-sysc: Fix power request conflicts
Describe the location and contents of the SYSCEXTMASK register on R-Car
E3, to prevent conflicts between internal and external power requests.
Based on a patch in the BSP by Dien Pham .
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a77990-sysc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/soc/renesas/r8a77990-sysc.c
b/drivers/soc/renesas/r8a77990-sysc.c
index 664b244eb1dd9d95..1d2432020b7a15d2 100644
--- a/drivers/soc/renesas/r8a77990-sysc.c
+++ b/drivers/soc/renesas/r8a77990-sysc.c
@@ -5,6 +5,7 @@
* Copyright (C) 2018 Renesas Electronics Corp.
*/
+#include
#include
#include
#include
@@ -50,4 +51,6 @@ const struct rcar_sysc_info r8a77990_sysc_info __initconst = {
.init = r8a77990_sysc_init,
.areas = r8a77990_areas,
.num_areas = ARRAY_SIZE(r8a77990_areas),
+ .extmask_offs = 0x2f8,
+ .extmask_val = BIT(0),
};
--
2.17.1
[RFC PATCH 6/7] soc: renesas: r8a77980-sysc: Fix power request conflicts
Describe the location and contents of the SYSCEXTMASK register on R-Car
V3H, to prevent conflicts between internal and external power requests.
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a77980-sysc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/soc/renesas/r8a77980-sysc.c
b/drivers/soc/renesas/r8a77980-sysc.c
index a8dbe55e8ba82d7e..e3b5ee1b3091dee1 100644
--- a/drivers/soc/renesas/r8a77980-sysc.c
+++ b/drivers/soc/renesas/r8a77980-sysc.c
@@ -6,6 +6,7 @@
* Copyright (C) 2018 Cogent Embedded, Inc.
*/
+#include
#include
#include
@@ -49,4 +50,6 @@ static const struct rcar_sysc_area r8a77980_areas[]
__initconst = {
const struct rcar_sysc_info r8a77980_sysc_info __initconst = {
.areas = r8a77980_areas,
.num_areas = ARRAY_SIZE(r8a77980_areas),
+ .extmask_offs = 0x138,
+ .extmask_val = BIT(0),
};
--
2.17.1
[RFC PATCH 1/7] soc: renesas: rcar-sysc: Prepare for fixing power request conflicts
Recent R-Car Gen3 SoCs added an External Request Mask Register to the
System Controller (SYSC). This register allows to mask external power
requests for CPU or 3DG domains, to prevent conflicts when Linux changes
the state of a power domain through SYSC, which could lead to system
lock-ups.
Add support for making use of this register. Take into account that the
register is optional, and that its location and contents are
SoC-specific.
Inspired by a patch in the BSP by Dien Pham .
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/rcar-sysc.c | 16
drivers/soc/renesas/rcar-sysc.h | 3 +++
2 files changed, 19 insertions(+)
diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index 0c80fab4f8de6bc8..b28955e21a9868e0 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -63,6 +63,7 @@ struct rcar_sysc_ch {
static void __iomem *rcar_sysc_base;
static DEFINE_SPINLOCK(rcar_sysc_lock); /* SMP CPUs + I/O devices */
+static u32 rcar_sysc_extmask_offs, rcar_sysc_extmask_val;
static int rcar_sysc_pwr_on_off(const struct rcar_sysc_ch *sysc_ch, bool on)
{
@@ -105,6 +106,14 @@ static int rcar_sysc_power(const struct rcar_sysc_ch
*sysc_ch, bool on)
spin_lock_irqsave(_sysc_lock, flags);
+ /*
+* Mask external power requests for CPU or 3DG domains
+*/
+ if (rcar_sysc_extmask_val) {
+ iowrite32(rcar_sysc_extmask_val,
+ rcar_sysc_base + rcar_sysc_extmask_offs);
+ }
+
/*
* The interrupt source needs to be enabled, but masked, to prevent the
* CPU from receiving it.
@@ -148,6 +157,9 @@ static int rcar_sysc_power(const struct rcar_sysc_ch
*sysc_ch, bool on)
iowrite32(isr_mask, rcar_sysc_base + SYSCISCR);
out:
+ if (rcar_sysc_extmask_val)
+ iowrite32(0, rcar_sysc_base + rcar_sysc_extmask_offs);
+
spin_unlock_irqrestore(_sysc_lock, flags);
pr_debug("sysc power %s domain %d: %08x -> %d\n", on ? "on" : "off",
@@ -361,6 +373,10 @@ static int __init rcar_sysc_pd_init(void)
rcar_sysc_base = base;
+ /* Optional External Request Mask Register */
+ rcar_sysc_extmask_offs = info->extmask_offs;
+ rcar_sysc_extmask_val = info->extmask_val;
+
domains = kzalloc(sizeof(*domains), GFP_KERNEL);
if (!domains) {
error = -ENOMEM;
diff --git a/drivers/soc/renesas/rcar-sysc.h b/drivers/soc/renesas/rcar-sysc.h
index 485520a5b295c13e..21ee3ff8620bbafe 100644
--- a/drivers/soc/renesas/rcar-sysc.h
+++ b/drivers/soc/renesas/rcar-sysc.h
@@ -44,6 +44,9 @@ struct rcar_sysc_info {
int (*init)(void); /* Optional */
const struct rcar_sysc_area *areas;
unsigned int num_areas;
+ /* Optional External Request Mask Register */
+ u32 extmask_offs; /* SYSCEXTMASK register offset */
+ u32 extmask_val;/* SYSCEXTMASK register mask value */
};
extern const struct rcar_sysc_info r8a7743_sysc_info;
--
2.17.1
[RFC PATCH 0/7] soc: renesas: rcar-gen3-sysc: Fix power request conflicts
Hi Simon, Magnus,
Recent R-Car Gen3 SoCs added an External Request Mask Register to the
System Controller (SYSC). This register allows to mask external power
requests for CPU or 3DG domains, to prevent conflicts when Linux changes
the state of a power domain through SYSC, which could lead to system
lock-ups.
This RFC patch series starts making use of this register. Note that the
register is optional, and that its location and contents are
SoC-specific.
This was inspired by a patch in the BSP by Dien Pham
.
This has been boot-tested on R-Car H3 ES1.0, H3 ES2.0, M3-W ES1.0, M3-N,
V3M, and E3 (only the last 3 have this register!), and regression-tested
on R-Car Gen2.
This has not been tested on R-Car H3 ES3.0, M3-W ES2.0, and V3H.
Thanks for your comments!
Geert Uytterhoeven (7):
soc: renesas: rcar-sysc: Prepare for fixing power request conflicts
soc: renesas: r8a7795-sysc: Fix power request conflicts
soc: renesas: r8a7796-sysc: Fix power request conflicts
soc: renesas: r8a77965-sysc: Fix power request conflicts
soc: renesas: r8a77970-sysc: Fix power request conflicts
soc: renesas: r8a77980-sysc: Fix power request conflicts
soc: renesas: r8a77990-sysc: Fix power request conflicts
drivers/soc/renesas/r8a7795-sysc.c | 32 -
drivers/soc/renesas/r8a7796-sysc.c | 22 +++-
drivers/soc/renesas/r8a77965-sysc.c | 3 +++
drivers/soc/renesas/r8a77970-sysc.c | 3 +++
drivers/soc/renesas/r8a77980-sysc.c | 3 +++
drivers/soc/renesas/r8a77990-sysc.c | 3 +++
drivers/soc/renesas/rcar-sysc.c | 16 +++
drivers/soc/renesas/rcar-sysc.h | 7 +--
8 files changed, 81 insertions(+), 8 deletions(-)
--
2.17.1
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
[RFC PATCH 3/7] soc: renesas: r8a7796-sysc: Fix power request conflicts
Describe the location and contents of the SYSCEXTMASK register on R-Car
M3-W, to prevent conflicts between internal and external power requests.
This register does not exist on R-Car M3-W ES1.x.
Based on a patch in the BSP by Dien Pham .
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a7796-sysc.c | 22 +-
drivers/soc/renesas/rcar-sysc.h| 2 +-
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/renesas/r8a7796-sysc.c
b/drivers/soc/renesas/r8a7796-sysc.c
index 1b06f868b6e81c79..a4eaa8d1f5d0f49d 100644
--- a/drivers/soc/renesas/r8a7796-sysc.c
+++ b/drivers/soc/renesas/r8a7796-sysc.c
@@ -5,8 +5,10 @@
* Copyright (C) 2016 Glider bvba
*/
+#include
#include
#include
+#include
#include
@@ -39,7 +41,25 @@ static const struct rcar_sysc_area r8a7796_areas[]
__initconst = {
{ "a3ir", 0x180, 0, R8A7796_PD_A3IR, R8A7796_PD_ALWAYS_ON },
};
-const struct rcar_sysc_info r8a7796_sysc_info __initconst = {
+
+/* Fixups for R-Car M3-W ES1.x revision */
+static const struct soc_device_attribute r8a7796es1[] __initconst = {
+ { .soc_id = "r8a7796", .revision = "ES1.*" },
+ { /* sentinel */ }
+};
+
+static int __init r8a7796_sysc_init(void)
+{
+ if (soc_device_match(r8a7796es1))
+ r8a7796_sysc_info.extmask_val = 0;
+
+ return 0;
+}
+
+struct rcar_sysc_info r8a7796_sysc_info __initdata = {
+ .init = r8a7796_sysc_init,
.areas = r8a7796_areas,
.num_areas = ARRAY_SIZE(r8a7796_areas),
+ .extmask_offs = 0x2f8,
+ .extmask_val = BIT(0),
};
diff --git a/drivers/soc/renesas/rcar-sysc.h b/drivers/soc/renesas/rcar-sysc.h
index 499797a9e18c2f10..64c2a0fa7945d80b 100644
--- a/drivers/soc/renesas/rcar-sysc.h
+++ b/drivers/soc/renesas/rcar-sysc.h
@@ -60,7 +60,7 @@ extern const struct rcar_sysc_info r8a7791_sysc_info;
extern const struct rcar_sysc_info r8a7792_sysc_info;
extern const struct rcar_sysc_info r8a7794_sysc_info;
extern struct rcar_sysc_info r8a7795_sysc_info;
-extern const struct rcar_sysc_info r8a7796_sysc_info;
+extern struct rcar_sysc_info r8a7796_sysc_info;
extern const struct rcar_sysc_info r8a77965_sysc_info;
extern const struct rcar_sysc_info r8a77970_sysc_info;
extern const struct rcar_sysc_info r8a77980_sysc_info;
--
2.17.1
[RFC PATCH 5/7] soc: renesas: r8a77970-sysc: Fix power request conflicts
Describe the location and contents of the SYSCEXTMASK register on R-Car
V3M, to prevent conflicts between internal and external power requests.
Based on a patch in the BSP by Dien Pham .
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a77970-sysc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/soc/renesas/r8a77970-sysc.c
b/drivers/soc/renesas/r8a77970-sysc.c
index 280c48b80f240424..b3033e3f0fd0b0ff 100644
--- a/drivers/soc/renesas/r8a77970-sysc.c
+++ b/drivers/soc/renesas/r8a77970-sysc.c
@@ -5,6 +5,7 @@
* Copyright (C) 2017 Cogent Embedded Inc.
*/
+#include
#include
#include
@@ -32,4 +33,6 @@ static const struct rcar_sysc_area r8a77970_areas[]
__initconst = {
const struct rcar_sysc_info r8a77970_sysc_info __initconst = {
.areas = r8a77970_areas,
.num_areas = ARRAY_SIZE(r8a77970_areas),
+ .extmask_offs = 0x1b0,
+ .extmask_val = BIT(0),
};
--
2.17.1
[RFC PATCH 4/7] soc: renesas: r8a77965-sysc: Fix power request conflicts
Describe the location and contents of the SYSCEXTMASK register on R-Car
M3-N, to prevent conflicts between internal and external power requests.
Based on a patch in the BSP by Dien Pham .
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a77965-sysc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/soc/renesas/r8a77965-sysc.c
b/drivers/soc/renesas/r8a77965-sysc.c
index e0533beb50fd7063..b5d8230d4bbc1b87 100644
--- a/drivers/soc/renesas/r8a77965-sysc.c
+++ b/drivers/soc/renesas/r8a77965-sysc.c
@@ -7,6 +7,7 @@
* Copyright (C) 2016 Glider bvba
*/
+#include
#include
#include
@@ -33,4 +34,6 @@ static const struct rcar_sysc_area r8a77965_areas[]
__initconst = {
const struct rcar_sysc_info r8a77965_sysc_info __initconst = {
.areas = r8a77965_areas,
.num_areas = ARRAY_SIZE(r8a77965_areas),
+ .extmask_offs = 0x2f8,
+ .extmask_val = BIT(0),
};
--
2.17.1
[RFC PATCH 2/7] soc: renesas: r8a7795-sysc: Fix power request conflicts
Describe the location and contents of the SYSCEXTMASK register on R-Car
H3, to prevent conflicts between internal and external power requests.
This register does not exist on R-Car H3 ES1.x and ES2.x.
Based on a patch in the BSP by Dien Pham .
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a7795-sysc.c | 32 +-
drivers/soc/renesas/rcar-sysc.h| 2 +-
2 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/renesas/r8a7795-sysc.c
b/drivers/soc/renesas/r8a7795-sysc.c
index cda27a67de9876af..7e15cd09c4eb4780 100644
--- a/drivers/soc/renesas/r8a7795-sysc.c
+++ b/drivers/soc/renesas/r8a7795-sysc.c
@@ -5,6 +5,7 @@
* Copyright (C) 2016-2017 Glider bvba
*/
+#include
#include
#include
#include
@@ -51,25 +52,46 @@ static struct rcar_sysc_area r8a7795_areas[] __initdata = {
/*
-* Fixups for R-Car H3 revisions after ES1.x
+* Fixups for R-Car H3 revisions
*/
-static const struct soc_device_attribute r8a7795es1[] __initconst = {
- { .soc_id = "r8a7795", .revision = "ES1.*" },
+#define HAS_A2VC0 BIT(0) /* Power domain A2VC0 is present */
+#define NO_EXTMASK BIT(1) /* Missing SYSCEXTMASK register */
+
+static const struct soc_device_attribute r8a7795_quirks_match[] __initconst = {
+ {
+ .soc_id = "r8a7795", .revision = "ES1.*",
+ .data = (void *)(HAS_A2VC0 | NO_EXTMASK),
+ }, {
+ .soc_id = "r8a7795", .revision = "ES2.*",
+ .data = (void *)(NO_EXTMASK),
+ },
{ /* sentinel */ }
};
static int __init r8a7795_sysc_init(void)
{
- if (!soc_device_match(r8a7795es1))
+ const struct soc_device_attribute *attr;
+ u32 quirks = 0;
+
+ attr = soc_device_match(r8a7795_quirks_match);
+ if (attr)
+ quirks = (uintptr_t)attr->data;
+
+ if (!(quirks & HAS_A2VC0))
rcar_sysc_nullify(r8a7795_areas, ARRAY_SIZE(r8a7795_areas),
R8A7795_PD_A2VC0);
+ if (quirks & NO_EXTMASK)
+ r8a7795_sysc_info.extmask_val = 0;
+
return 0;
}
-const struct rcar_sysc_info r8a7795_sysc_info __initconst = {
+struct rcar_sysc_info r8a7795_sysc_info __initdata = {
.init = r8a7795_sysc_init,
.areas = r8a7795_areas,
.num_areas = ARRAY_SIZE(r8a7795_areas),
+ .extmask_offs = 0x2f8,
+ .extmask_val = BIT(0),
};
diff --git a/drivers/soc/renesas/rcar-sysc.h b/drivers/soc/renesas/rcar-sysc.h
index 21ee3ff8620bbafe..499797a9e18c2f10 100644
--- a/drivers/soc/renesas/rcar-sysc.h
+++ b/drivers/soc/renesas/rcar-sysc.h
@@ -59,7 +59,7 @@ extern const struct rcar_sysc_info r8a7790_sysc_info;
extern const struct rcar_sysc_info r8a7791_sysc_info;
extern const struct rcar_sysc_info r8a7792_sysc_info;
extern const struct rcar_sysc_info r8a7794_sysc_info;
-extern const struct rcar_sysc_info r8a7795_sysc_info;
+extern struct rcar_sysc_info r8a7795_sysc_info;
extern const struct rcar_sysc_info r8a7796_sysc_info;
extern const struct rcar_sysc_info r8a77965_sysc_info;
extern const struct rcar_sysc_info r8a77970_sysc_info;
--
2.17.1
Re: [PATCH 14/14] gpio: pca953x: Restore registers after suspend/resume cycle
Hi Marek,
On Sun, Dec 2, 2018 at 8:36 PM Marek Vasut wrote:
> It is possible that the PCA953x is powered down during suspend.
> Use regmap cache to assure the registers in the PCA953x are in
> line with the driver state after resume.
>
> Signed-off-by: Marek Vasut
> +static int pca953x_suspend(struct device *dev)
> +{
> + struct pca953x_chip *chip = dev_get_drvdata(dev);
> +
> + regcache_mark_dirty(chip->regmap);
> + pca953x_regcache_sync(dev);
> + regcache_cache_only(chip->regmap, true);
Based on the discussion about adding suspend/resume support to the VC5
clock driver, I guess the two sync calls above are not needed here?
> +
> + regulator_disable(chip->regulator);
> +
> + return 0;
> +}
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 2/2] ARM: dts: r7s9210-rza2mevb: Add support for RZ/A2M EVB
Hi Chris,
On Tue, Dec 4, 2018 at 5:25 PM Chris Brandt wrote:
> Besides, this board will only boot as XIP_KERNEL which is an impossible
> configuration in the mainline kernel, so this .dts file is mostly for
> checking the .dtsi file.
Let's hope we can fix that anytime soon.
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 2/2] ARM: dts: r7s9210-rza2mevb: Add support for RZ/A2M EVB
Hi Chris,
On Thu, Nov 29, 2018 at 2:07 PM Chris Brandt wrote:
> Add support for Renesas RZ/A2M evaluation board.
>
> Signed-off-by: Chris Brandt
Thanks for your patch!
> index ..9570aeb8f1ce
> --- /dev/null
> +++ b/arch/arm/boot/dts/r7s9210-rza2mevb.dts
> @@ -0,0 +1,133 @@
> +/*
> + * Device Tree Source for the RZA2MEVB board
> + *
> + * Copyright (C) 2018 Renesas Electronics
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
Let's see about the license...
> +/ {
> + model = "RZA2MEVB";
> + compatible = "renesas,rza2mevb", "renesas,r7s9210";
> +
> + aliases {
> + serial0 =
> + };
> +
> + chosen {
> + bootargs = "ignore_loglevel earlycon rootfstype=cramfs
> root=mtd:rootfs";
I wouldn't put "earlycon" in the default bootargs.
It's meant for debugging.
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory@8000 {
4000
> + device_type = "memory";
> + reg = <0x4000 0x0080>; /* HyperRAM */
> + };
> +
> + lbsc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + };
> +
> + leds {
> + status = "okay";
Please drop this line, "okay" is the default.
> + compatible = "gpio-leds";
> +
> + led0 {
> + gpios = < RZA2_PIN(PORT6, 0)
> GPIO_ACTIVE_HIGH>;
There's a second (yellow green) LED connected to PC_1.
Hence
red {
gpios = < RZA2_PIN(PORT6, 0) GPIO_ACTIVE_HIGH>;
};
green {
gpios = < RZA2_PIN(PORTC, 1) GPIO_ACTIVE_HIGH>;
}
> + };
> + };
> + {
> +
Please drop this blank line.
> + /* Serial Console */
> + scif4_pins: serial4 {
> + pinmux = ,/* TxD4 */
> +;/* RxD4 */
> + };
> +};
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 1/2] ARM: dts: r7s9210: Initial SoC device tree
Hi Chris,
On Thu, Nov 29, 2018 at 2:07 PM Chris Brandt wrote:
> Basic support for the RZ/A2 (R7S9210) SoC.
>
> Signed-off-by: Chris Brandt
Thanks for your patch!
> --- /dev/null
> +++ b/arch/arm/boot/dts/r7s9210.dtsi
> @@ -0,0 +1,211 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for the R7S9210 SoC
> + *
> + * Copyright (C) 2018 Renesas Electronics Corporation
> + *
> + */
> +
> +#include
> +#include
> +
> +/ {
> + clocks {
Please remove the clocks subnode.
These days clocks live at the root node.
> + gic: interrupt-controller@e8221000 {
> + compatible = "arm,gic-400";
> + #interrupt-cells = <3>;
> + #address-cells = <0>;
> + interrupt-controller;
> + reg = <0xe8221000 0x1000>,
> + <0xe8222000 0x1000>;
> + };
> +
> + L2: cache-controller@1f003000 {
Please sort nodes by address (per group of devices).
> + compatible = "arm,pl310-cache";
> + reg = <0x1f003000 0x1000>;
> + interrupts = ;
> + arm,early-bresp-disable;
> + arm,full-line-zero-disable;
> + cache-unified;
> + cache-level = <2>;
> + };
> +
> + cpg: clock-controller@fcfe0020 {
fcfe0010, as pointed out by Simon.
> + compatible = "renesas,r7s9210-cpg-mssr";
> + reg = <0xfcfe0010 0x455>;
> + clocks = <_clk>;
> + clock-names = "extal";
> + #clock-cells = <2>;
> + #power-domain-cells = <0>;
> + #reset-cells = <1>;
Note that resets are not yet supported by the driver.
But probably they will use #reset-cells = <1>, if ever implemented.
> + };
> +
> + ostm0: timer@e803b000 {
> + compatible = "renesas,r7s9210-ostm", "renesas,ostm";
> + reg = <0xe803b000 0x30>;
> + interrupts = ;
> + clocks = < CPG_MOD 36>;
> + clock-names = "ostm0";
The clock-names property is not documented in the DT bindings.
Moreover, using different names for the clock inputs of the different
channels is strange.
> + scif0: serial@e8007000 {
> + compatible = "renesas,scif-r7s9210";
> + reg = <0xe8007000 18>;
0x18 (for all scif instances)
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 17/22] ARM: dts: iwg20d-q7-common: Move cmt/rwdt node out of RZ/G1M SOM
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> The iWave RZ/G1N board is almost identical to RZ/G1M. cmt and rwdt modules
> are SoC specific and should be part of board dts rather than SoM dtsi. By
> moving these nodes to the common dtsi it allows cmt and rwdt to be enabled
> on both of these boards with less lines of code.
>
> Signed-off-by: Biju Das
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 v2 2/2] clk: renesas: rcar-gen3: add HS400 quirk for SD clock
On Thu, Nov 29, 2018 at 1:41 AM Niklas Söderlund
wrote:
> On H3 (ES1.x, ES2.0) and M3-W (ES1.0, ES1.1) the clock setting for HS400
> needs a quirk to function properly. The reason for the quirk is that
> there are two settings which produces same divider value for the SDn
> clock. On the effected boards the one currently selected results in
> HS400 not working.
>
> This change uses the same method as the Gen2 CPG driver and simply
> ignores the first clock setting as this is the offending one when
> selecting the settings. Which of the two possible settings is used have
> no effect for SDR104.
>
> Signed-off-by: Niklas Söderlund
>
> ---
> * Changes since v1
> - Fixed spelling in commit message, thanks Sergei and Geert!
> - Reworked the whole patch per Geerts suggestion. Instead of only
> skipping the first row on the effected boards when setting the clock
> rete totally ignore it. This is made possible by another change to the
> clock driver posted separately from this series and which this patch
> now depends on [1].
>
> 1. [PATCH] clk: renesas: rcar-gen3: set state when registering SD clocks
Thanks for the update!
With s/rete/rate/:
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] clk: renesas: rcar-gen3: set state when registering SD clocks
Hi Niklas,
On Thu, Nov 29, 2018 at 1:16 AM Niklas Söderlund
wrote:
> The driver tries to figure out which state a SD clock is in when the
> clock is register instead of setting a known state. This can be
> problematic for two reasons.
>
> 1. If the clock driver can't figure out the state of the clock
>registration of the clock fails and setting of a known state by a
>clock user is not possible.
>
> 2. The state of the clock depends on if and how the bootloader
>configured it. The driver only checks that the rate is known not if
>the clock is stopped or not for example.
>
> Fix this by setting a known state and make sure the clock is stopped.
>
> Signed-off-by: Niklas Söderlund
Thanks for your patch!
Reviewed-by: Geert Uytterhoeven
One minor nit below.
> --- a/drivers/clk/renesas/rcar-gen3-cpg.c
> +++ b/drivers/clk/renesas/rcar-gen3-cpg.c
> @@ -360,7 +360,7 @@ static struct clk * __init cpg_sd_clk_register(const
> struct cpg_core_clk *core,
> struct sd_clock *clock;
> struct clk *clk;
> unsigned int i;
> - u32 sd_fc;
> + u32 val;
>
> clock = kzalloc(sizeof(*clock), GFP_KERNEL);
> if (!clock)
> @@ -377,17 +377,11 @@ static struct clk * __init cpg_sd_clk_register(const
> struct cpg_core_clk *core,
> clock->div_table = cpg_sd_div_table;
> clock->div_num = ARRAY_SIZE(cpg_sd_div_table);
>
> - sd_fc = readl(clock->csn.reg) & CPG_SD_FC_MASK;
> - for (i = 0; i < clock->div_num; i++)
> - if (sd_fc == (clock->div_table[i].val & CPG_SD_FC_MASK))
> - break;
> -
> - if (WARN_ON(i >= clock->div_num)) {
> - kfree(clock);
> - return ERR_PTR(-EINVAL);
> - }
> + val = readl(clock->csn.reg) & ~CPG_SD_FC_MASK;
> + val |= CPG_SD_STP_MASK | (clock->div_table[0].val & CPG_SD_FC_MASK);
> + writel(val, clock->csn.reg);
>
> - clock->cur_div_idx = i;
> + clock->cur_div_idx = 0;
I think this line can just be dropped, as the object was allocated using
kzalloc().
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] watchdog: renesas_wdt: don't keep timer value during suspend/resume
On Tue, Dec 4, 2018 at 1:02 PM Wolfram Sang
wrote:
> After discussing this mail thread [1] again, we concluded that giving
> userspace enough time to prepare is our favourite option. So, do not
> keep the time value when suspended but reset it when resuming.
>
> [1] https://patchwork.kernel.org/patch/10252209/
>
> Signed-off-by: Wolfram Sang
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
renesas-drivers-2018-12-04-v4.20-rc5
I have pushed renesas-drivers-2018-12-04-v4.20-rc5 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git
This tree is meant to ease development of platform support and drivers
for Renesas ARM SoCs. It is created by merging (a) the for-next branches
of various subsystem trees and (b) branches with driver code submitted
or planned for submission to maintainers into the development branch of
Simon Horman's renesas.git tree.
Today's version is based on renesas-devel-20181130-v4.20-rc4.
Included branches with driver code:
- clk-renesas
- sh-pfc
- topic/clk-rcar3-hs400-v2
- git://linuxtv.org/pinchartl/media.git#drm-du-iommu-v1-20171115
- git://git.ragnatech.se/linux#for-renesas-drivers
-
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#gmsl/for-renesas-drivers
Included fixes:
- [LOCAL] arm64: defconfig: Update renesas_defconfig
Included subsystem trees:
- git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git#linux-next
- git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git#clk-next
-
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git#for-next
- git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git#tty-next
- git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#i2c/for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-next
- git://git.freedesktop.org/git/drm/drm.git#drm-next
- git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
- git://linuxtv.org/media_tree.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git#next
-
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next
- git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next
- git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#testing/next
- git://git.infradead.org/users/vkoul/slave-dma.git#next
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git#staging-next
- git://git.armlinux.org.uk/~rmk/linux-arm.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git#for-next
- git://git.infradead.org/users/jcooper/linux.git#irqchip/for-next
- git://github.com/bzolnier/linux.git#fbdev-for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git#for-next
-
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git#for-next
- git://www.linux-watchdog.org/linux-watchdog-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git#for-next/core
- git://anongit.freedesktop.org/drm/drm-misc#for-linux-next
- git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
- git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git#next
-
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git#next
- git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git#for-mfd-next
- git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git#for-next
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 14/14] gpio: pca953x: Restore registers after suspend/resume cycle
Hi Marek,
On Sun, Dec 2, 2018 at 8:36 PM Marek Vasut wrote:
> It is possible that the PCA953x is powered down during suspend.
> Use regmap cache to assure the registers in the PCA953x are in
> line with the driver state after resume.
>
> Signed-off-by: Marek Vasut
Thanks for your series!
Background info: the main motivation for this series is to make sure SATA
keeps working after system suspend/resume on the Salvator-XS development
board, where the SATA functionality is configured using a gpio hog.
With your series applied, the SATA link seems to be functional after resume.
Dmesg difference:
ata1: link resume succeeded after 1 retries
-ata1: SATA link down (SStatus 0 SControl 300)
-ata1: link resume succeeded after 1 retries
-ata1: SATA link down (SStatus 0 SControl 300)
-ata1: link resume succeeded after 1 retries
-ata1: SATA link down (SStatus 0 SControl 300)
-ata1.00: disabled
-sd 0:0:0:0: rejecting I/O to offline device
+ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
+ata1.00: configured for UDMA/133
However, when trying to read from an attached hard drive, it fails:
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.00: failed command: READ DMA
ata1.00: cmd c8/00:20:00:00:00/00:00:00:00:00/e0 tag 0 dma 16384 in
res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: hard resetting link
ata1: link resume succeeded after 1 retries
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/133
sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00
driverbyte=0x08
sd 0:0:0:0: [sda] tag#0 Sense Key : 0x5 [current]
sd 0:0:0:0: [sda] tag#0 ASC=0x21 ASCQ=0x4
sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 00 00 00 00 20 00
print_req_error: I/O error, dev sda, sector 0
ata1: EH complete
...
Buffer I/O error on dev sda, logical block 0, async page read
Does SATA work for you after resume!
This could still be an issue in the sata_rcar driver.
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
[PATCH 1/2] ARM: dts: stout: Convert to new LVDS DT bindings
As of commit 6d2ca85279becdff ("dt-bindings: display: renesas: Deprecate
LVDS support in the DU bindings"), the internal LVDS encoder has DT
bindings separate from the DU. The Lager device tree was ported over to
the new model, but the Stout device tree was forgotten.
Fixes: 15a1ff30d8f9bd83 ("ARM: dts: r8a7790: Convert to new LVDS DT bindings")
Signed-off-by: Geert Uytterhoeven
---
Compile-tested only.
---
arch/arm/boot/dts/r8a7790-stout.dts | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790-stout.dts
b/arch/arm/boot/dts/r8a7790-stout.dts
index 629da4cee1b971d6..7a7d3b84d1a6b21d 100644
--- a/arch/arm/boot/dts/r8a7790-stout.dts
+++ b/arch/arm/boot/dts/r8a7790-stout.dts
@@ -94,9 +94,8 @@
status = "okay";
clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 722>,
-< CPG_MOD 726>, < CPG_MOD 725>,
<_clk>;
- clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1", "dclkin.0";
+ clock-names = "du.0", "du.1", "du.2", "dclkin.0";
ports {
port@0 {
@@ -104,11 +103,21 @@
remote-endpoint = <_in>;
};
};
+ };
+};
+
+ {
+ ports {
port@1 {
lvds_connector0: endpoint {
};
};
- port@2 {
+ };
+};
+
+ {
+ ports {
+ port@1 {
lvds_connector1: endpoint {
};
};
--
2.17.1
[PATCH 2/2] arm64: dts: renesas: r8a7796: salvator-xs: Convert to new LVDS DT bindings
As of commit 6d2ca85279becdff ("dt-bindings: display: renesas: Deprecate
LVDS support in the DU bindings"), the internal LVDS encoder has DT
bindings separate from the DU. The device trees for all R-Car H3 and
M3-W development boards were ported over to the new model, but
Salvator-XS boards equipped with an R-Car M3-W SoC were forgotten.
Fixes: 58e8ed2ee9abe718 ("arm64: dts: renesas: Convert to new LVDS DT bindings")
Signed-off-by: Geert Uytterhoeven
---
Compile-tested only.
---
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts
b/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts
index 8860be65342e4f38..31f12059355ee02b 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts
@@ -29,11 +29,10 @@
clocks = < CPG_MOD 724>,
< CPG_MOD 723>,
< CPG_MOD 722>,
-< CPG_MOD 727>,
< 1>,
<_clk>,
< 2>;
- clock-names = "du.0", "du.1", "du.2", "lvds.0",
+ clock-names = "du.0", "du.1", "du.2",
"dclkin.0", "dclkin.1", "dclkin.2";
};
--
2.17.1
[PATCH 0/2] arm: dts: renesas: Convert remaining boards to new LVDS DT bindings
Hi Simon, Magnus, Laurent, Marek,
As of commit 6d2ca85279becdff ("dt-bindings: display: renesas: Deprecate
LVDS support in the DU bindings"), the internal LVDS encoder has DT
bindings separate from the DU. Most board device trees were ported over
to the new model, but Stout with R-Car H2 and Salvator-XS with R-Car
M3-W were forgotten.
This patch series converts the remaining boards.
Both patches were compiled-tested only.
Thanks!
Geert Uytterhoeven (2):
ARM: dts: stout: Convert to new LVDS DT bindings
arm64: dts: renesas: r8a7796: salvator-xs: Convert to new LVDS DT
bindings
arch/arm/boot/dts/r8a7790-stout.dts | 15 ---
.../boot/dts/renesas/r8a7796-salvator-xs.dts | 3 +--
2 files changed, 13 insertions(+), 5 deletions(-)
--
2.17.1
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] ARM: dts: r8a7743: Remove legacy "renesas,rcar-thermal" compatibility
The thermal hardware description for the RZ/G1M SoC was added to its DTS
after the introduction of support for thermal zones, and included a
thermal-zones node from the beginning.
Hence there is no need to claim compatibility with
"renesas,rcar-thermal", which would be needed only for backwards
compatibility with kernels predating thermal zone support.
Fixes: 6c76b4f7d89e89f0 ("ARM: dts: r8a7743: Add thermal device to DT")
Signed-off-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7743.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 24715f74ae08c7c2..3cc33f7ff7febae7 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -348,8 +348,7 @@
thermal: thermal@e61f {
compatible = "renesas,thermal-r8a7743",
-"renesas,rcar-gen2-thermal",
-"renesas,rcar-thermal";
+"renesas,rcar-gen2-thermal";
reg = <0 0xe61f 0 0x10>, <0 0xe61f0100 0 0x38>;
interrupts = ;
clocks = < CPG_MOD 522>;
--
2.17.1
Re: [PATCH] mmc: document 'Reliable Write' bit in uapi header
Hi Wolfram,
On Mon, Dec 3, 2018 at 3:27 PM Wolfram Sang
wrote:
> If we use it this way, people should know about it.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
> ---
>
> Still not super happy about shifting into the sign bit, but yeah...
> don't break userspace, I guess.
Indeed.
> include/uapi/linux/mmc/ioctl.h | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/mmc/ioctl.h b/include/uapi/linux/mmc/ioctl.h
> index 45f369dc0a42..ae659333e73f 100644
> --- a/include/uapi/linux/mmc/ioctl.h
> +++ b/include/uapi/linux/mmc/ioctl.h
> @@ -5,7 +5,10 @@
> #include
>
> struct mmc_ioc_cmd {
> - /* Implies direction of data. true = write, false = read */
> + /*
> +* Implies direction of data. true = write, false = read.
nonzero = write, zero = read?
> +* Bit 31 selects 'Reliable Write' for RPMB.
Perhaps having a #define for this would be nice?
Can also be used by the driver, instead of 1 << 31, which some static
analyzers may complain about.
> +*/
> int write_flag;
>
> /* Application-specific command. true = precede with CMD55 */
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/RFT] arm64: dts: renesas: r8a77990-ebisu: Add BD9571 PMIC
Hi Kaneko-san,
On Sat, Dec 1, 2018 at 3:43 PM Yoshihiro Kaneko wrote:
> From: Takeshi Kihara
>
> This patch adds the regulator definition required for operation of
> S2RAM.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Yoshihiro Kaneko
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> @@ -425,6 +425,26 @@
> };
> };
>
> +_dvfs {
> + status = "okay";
> +
> + clock-frequency = <40>;
> +
> + pmic: pmic@30 {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + compatible = "rohm,bd9571mwv";
> + reg = <0x30>;
> + interrupt-parent = <_ex>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + gpio-controller;
> + #gpio-cells = <2>;
Just adding this node is not sufficient to make S2RAM work.
As per Documentation/devicetree/bindings/mfd/bd9571mwv.txt, you also have
to describe the DDR-Backup Power configuration.
On the Ebisu-4D development board, only the DDR0 power rail is used, and
needs to be kept powered when backup mode is enabled.
rohm,ddr-backup-power = <0x1>;
rohm,rstbmode-level;
Unfortunately resume from s2ram doesn't work with this, probably due to an
issue in ATF. This may have been fixed in IPL and Secure Monitor Rev1.0.22,
which claims to add support for the Ebisu-4D board.
I don't know if plain Ebisu needs a different configuration.
> + };
> +};
> +
> {
> status = "okay";
>
The rest is fine, hence with the above fixed and tested:
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 2/2] ARM: dts: r7s9210-rza2mevb: Add support for RZ/A2M EVB
Hi Chris,
On Fri, Nov 30, 2018 at 5:10 PM Chris Brandt wrote:
> On Friday, November 30, 2018 1, Geert wrote:
> > > So in our RZ/A BSP that I release to customers I would use this dual
> > > license. You can see the exact same license in a number of dts files in
> > > mainline.
> >
> > Note that your file includes
> >
> > #include
> > #include
> >
> > both of which are
> >
> >include/dt-bindings/gpio/gpio.h:/* SPDX-License-Identifier: GPL-2.0 */
> >include/dt-bindings/pinctrl/r7s9210-pinctrl.h:/*
> > SPDX-License-Identifier: GPL-2.0 */
>
> After I wrote that, I realized that we'll always have:
> #include "r7s9210.dtsi"
> Which I have as GPL-2.0so the dual license idea in pointless.
>
> So to make things easy, I'll just drop the dual license thing and just
> use SPDX GPL-2.0
That's one solution.
Another solution would be to relicense all DT binding definitions and DTS files.
Cfr. e.g. commit d061864b89c3234b ("ARM: dt: relicense two DT binding IRQ
headers").
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 1/2] ARM: dts: r7s9210: Initial SoC device tree
Hi Simon,
On Fri, Nov 30, 2018 at 1:23 PM Simon Horman wrote:
> On Fri, Nov 30, 2018 at 12:04:57PM +, Chris Brandt wrote:
> > On Friday, November 30, 2018, Simon Horman wrote:
> > > > + ostm0: timer@e803b000 {
> > > > + compatible = "renesas,r7s9210-ostm", "renesas,ostm";
> > > > + reg = <0xe803b000 0x30>;
> > >
> > >
> > > Its not clear to me why the size of the register range is 0x30.
> >
> > Because when reviewing the bindings docs, I was putting in 'exact'
> > values, but Geert said "those are ugly, just round up to make it look
> > nicer".
> > So instead of 0x21, I put 0x30.
> >
> > You know...the standard answer: Throw Geert under the bus ;)
>
> Lets leave 0x30 :)
Pfew...
BTW, I'd be surprised the hardware address decoder would route all
addresses in the range 0xe803b000..0xe803b02f to the OSTM.
0xe803b000..0xe803b03f sounds more logical to me, as it requires less gates.
But hey, who said hardware designers are logical? ;-)
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 2/2] ARM: dts: r7s9210-rza2mevb: Add support for RZ/A2M EVB
Hi Chris,
On Fri, Nov 30, 2018 at 1:20 PM Chris Brandt wrote:
> On Friday, November 30, 2018, Simon Horman wrote:
> > I am wondering about the motivation for dual-licensing this file.
> > It does not seem to be something Renesas has done before with
> > upstream DT.
> >
> > I am also wondering if the dual licence, if it remains, can be
> > described using SPDX.
>
> A while back, I was reading/hearing about how board DT file do not have
> to be GPL and the user should not have to be forced to make this GPL.
> (Maybe at some ELC conference or on LWN or something)
Indeed. Recently there have been some attempts to fix this.
> So in our RZ/A BSP that I release to customers I would use this dual
> license. You can see the exact same license in a number of dts files in
> mainline.
Note that your file includes
#include
#include
both of which are
include/dt-bindings/gpio/gpio.h:/* SPDX-License-Identifier: GPL-2.0 */
include/dt-bindings/pinctrl/r7s9210-pinctrl.h:/*
SPDX-License-Identifier: GPL-2.0 */
> Since there is no SPDX for this, I figure Rob might have some opinion on
> the matter.
> And, if I have to make it GLP for the mainline version, then I will just
> replace the license when I release the customer BSP (since I wrote it,
> I can do that). But, I would be nice to keep the BSP version as close to
> mainline as I can.
Documentation/process/license-rules.rst does have SPDX identifiers for
dual-licensed files. Perhaps they match the license of your file?
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 v2 2/2] clk: renesas: rcar-gen3: add HS400 quirk for SD clock
Hi Wolfram,
On Fri, Nov 30, 2018 at 12:47 PM Wolfram Sang wrote:
> > That should have been rate :-) To elaborate a bit more:
> >
> > The patch is different from v1 as a different approach to solve the
> > issue have been found. Instead of only ignoring the first row of the
> > list of possible settings when selecting which divider to use also
> > ignore it when examining which state the hardware is in. That is the
> > driver is no longer aware the first row exists with this patch.
> >
> > This was in v1 not possible as the first row might be a state the
> > bootloader left the hardware in and then the clock failed to register as
> > it would need to update its own state to match the hardware.
> >
> > As the driver needed to know about the state the hardware was in when
> > probing but not use it when selecting a divider the more complex v1 was
> > needed. When selecting a divider we wish for it to select the second
> > option for the divider value '4' when running on a SoC which needs the
> > quirk.
> >
> > With v2 which depends on [1] this is not needed as the clock driver now
> > sets a know state when registering the clock so this patch can be made
> > much simpler by simply 'removing' the first row from all operations.
>
> Thanks for the elaboration. I still think the above is the way to go and
> I still wonder a little why it was implemented differently beforehand.
Probably the initial implementation didn't care at all about selecting clock
speeds (no fancy SDR/HS modes supported), so just used whatever U-Boot
had set up.
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 v2 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
Hi Alexandre,
On Fri, Nov 30, 2018 at 1:32 PM Alexandre Belloni
wrote:
> On 30/11/2018 12:05:16+0100, Geert Uytterhoeven wrote:
> > On Thu, Nov 29, 2018 at 6:03 PM Biju Das wrote:
> > > Add support for NXP pcf85263 real-time clock. pcf85263 rtc is compatible
> > > with pcf85363,except that pcf85363 has additional 64 bytes of RAM.
> > >
> > > 1 byte of nvmem is supported and exposed in sysfs (# is the instance
> > > number,starting with 0): /sys/bus/nvmem/devices/pcf85x63-#/nvmem
> > >
> > > Signed-off-by: Biju Das
> > > ---
> > > V1-->V2 Incorporated Alexandre and Geert's review comment.
> >
> > Thanks for the update!
> >
> > > --- a/drivers/rtc/rtc-pcf85363.c
> > > +++ b/drivers/rtc/rtc-pcf85363.c
> >
> > > @@ -321,15 +344,25 @@ static int pcf85363_probe(struct i2c_client *client,
> > > const struct i2c_device_id *id)
> > > {
> > > struct pcf85363 *pcf85363;
> > > - struct nvmem_config nvmem_cfg = {
> > > - .name = "pcf85363-",
> > > - .word_size = 1,
> > > - .stride = 1,
> > > - .size = NVRAM_SIZE,
> > > - .reg_read = pcf85363_nvram_read,
> > > - .reg_write = pcf85363_nvram_write,
> > > + const struct regmap_config *regmap_config =
> > > _85363_regmap_config;
> > > + struct nvmem_config nvmem_cfg[] = {
> >
> > static?
> >
> > Although the nvmem_config is copied, and thus static is not needed, I
> > guess using static will decrease kernel size.
> >
>
> Hum, I don't think, this is on the stack anyway.
If you make it static, it's no longer allocated on the stack, and gcc has no
longer to emit code to initialize all members.
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 05/22] ARM: dts: r8a7744-iwg20m: Add eMMC support
Hi Biju,
On Fri, Nov 30, 2018 at 11:43 AM Biju Das wrote:
> > Subject: Re: [PATCH 05/22] ARM: dts: r8a7744-iwg20m: Add eMMC support
> >
> > On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> > > Add eMMC support for iWave RZ/G1N Qseven System On Module.
> > >
> > > Signed-off-by: Biju Das
> >
> > Reviewed-by: Geert Uytterhoeven
> >
> > I assume the PCB is the same for RZ/G1M and RZ/G1N, so perhaps this can
> > be factored out in a common .dtsi file, like we did for Salvator-X(S)?
>
> SoM is different between RZ/G1M and RZ/G1N in terms of memory and PCie/SATA.
>
> The only common part in SoM is eMMC,SDHI0 and QSPI flash. So it doesn't make
> sense to factored it out.
>
> What do you think?
OK, then it's fine for me.
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 v2 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
Hi Biju,
On Thu, Nov 29, 2018 at 6:03 PM Biju Das wrote:
> Add support for NXP pcf85263 real-time clock. pcf85263 rtc is compatible
> with pcf85363,except that pcf85363 has additional 64 bytes of RAM.
>
> 1 byte of nvmem is supported and exposed in sysfs (# is the instance
> number,starting with 0): /sys/bus/nvmem/devices/pcf85x63-#/nvmem
>
> Signed-off-by: Biju Das
> ---
> V1-->V2 Incorporated Alexandre and Geert's review comment.
Thanks for the update!
> --- a/drivers/rtc/rtc-pcf85363.c
> +++ b/drivers/rtc/rtc-pcf85363.c
> @@ -321,15 +344,25 @@ static int pcf85363_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> struct pcf85363 *pcf85363;
> - struct nvmem_config nvmem_cfg = {
> - .name = "pcf85363-",
> - .word_size = 1,
> - .stride = 1,
> - .size = NVRAM_SIZE,
> - .reg_read = pcf85363_nvram_read,
> - .reg_write = pcf85363_nvram_write,
> + const struct regmap_config *regmap_config = _85363_regmap_config;
> + struct nvmem_config nvmem_cfg[] = {
static?
Although the nvmem_config is copied, and thus static is not needed, I
guess using static will decrease kernel size.
> + {
> + .name = "pcf85x63-",
> + .word_size = 1,
> + .stride = 1,
> + .size = 1,
> + .reg_read = pcf85x63_nvram_read,
> + .reg_write = pcf85x63_nvram_write,
> + }, {
> + .name = "pcf85363-",
> + .word_size = 1,
> + .stride = 1,
> + .size = NVRAM_SIZE,
> + .reg_read = pcf85363_nvram_read,
> + .reg_write = pcf85363_nvram_write,
> + },
> };
> - int ret;
> + int ret, i, num_nvmem = 2;
>
> if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
> return -ENODEV;
> @@ -339,7 +372,13 @@ static int pcf85363_probe(struct i2c_client *client,
> if (!pcf85363)
> return -ENOMEM;
>
> - pcf85363->regmap = devm_regmap_init_i2c(client, _config);
> + if (of_device_get_match_data(>dev) ==
> + _85263_regmap_config) {
> + regmap_config = _85263_regmap_config;
> + num_nvmem = 1;
I think it's cleaner if you store the full config (regmap_config + num_nvmem)
in of_device_id.data, instead of just the regmap_config, using
struct pcf85x63_config {
struct regmap_config regmap;
unsigned int num_nvram;
};
static const struct pcf85x63_config pcf85263_config = { ... };
static const struct pcf85x63_config pcf85363_config = { ... };
static const struct of_device_id dev_ids[] = {
{ .compatible = "nxp,pcf85263", .data = _85263_config },
{ .compatible = "nxp,pcf85363", .data = _85363_config },
{ /* sentinel */ }
};
Then you can just do
struct pcf85x63_config *config = _config; /* default
for non-DT */
void *data = of_device_get_match_data(>dev);
if (data)
config = data;
> + }
> +
> + pcf85363->regmap = devm_regmap_init_i2c(client, regmap_config);
> if (IS_ERR(pcf85363->regmap)) {
> dev_err(>dev, "regmap allocation failed\n");
> return PTR_ERR(pcf85363->regmap);
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 19/22] ARM: dts: r8a7744-iwg20m: Add SPI NOR support
Hi Biju,
On Fri, Nov 30, 2018 at 11:34 AM Biju Das wrote:
> > Subject: Re: [PATCH 19/22] ARM: dts: r8a7744-iwg20m: Add SPI NOR support
> > On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> > > Add support for the SPI NOR device used to boot up the system to the
> > > iWave RZ/G1N Qseven System On Module DT.
> > >
> > > Signed-off-by: Biju Das
> >
> > Thanks for your patch!
> >
> > > --- a/arch/arm/boot/dts/r8a7744-iwg20m.dtsi
> > > +++ b/arch/arm/boot/dts/r8a7744-iwg20m.dtsi
> >
> > > @@ -53,6 +58,27 @@
> > > status = "okay";
> > > };
> > >
> > > + {
> > > + pinctrl-0 = <_pins>;
> > > + pinctrl-names = "default";
> > > +
> > > + status = "okay";
> > > +
> > > + /* WARNING - This device contains the bootloader. Handle with
> > > care.
> > */
> > > + flash: flash@0 {
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + compatible = "sst,sst25vf016b", "jedec,spi-nor";
> >
> > According to the schematics, this is an ISSI IS25LP016D?
> > ISSI was acquired by GigaDevice, according to Wikipedia.
> > While SST is now MicroChip.
>
> As per the schematic and BoM, it is.
> IC FLASH 16MBIT 50MHZ 8SOIC SST25VF016B-50-4I-S2AF Microchip Technology 1 U1
Oh, this seems to differ for different revisions of the schematics.
R5.1 has the ISSI part, R3.4 has the SST part.
Due to "jedec,spi-nor", it will auto-detect, but IIRC, the driver will warn
if the compatible doesn't match the detected part, which thus may happen
for some boards.
> > > + reg = <0>;
> > > + spi-max-frequency = <5000>;
> > > + spi-tx-bus-width = <1>;
> > > + spi-rx-bus-width = <1>;
> >
> > <1> is the default, but it's indeed good to make this explicit, as this is
> > a QSPI
> > device with 2 unwired data pins.
> > However, as the device seems to support dual transfers, and dual mode uses
> > the standard MOSI/MISO pins, you should use <2> for both.
> > The RSPI driver supports this.
> >
> > The same applies to the RZ/G1M version.
>
> SST25VF016B this doesn't support dual mode.
OK.
So some boards have a dual-capable part, others don't.
I'm not 100% sure, but I think writing <2> will still work, as the driver
won't use dual mode on the SST25VF016B part, due to lack of
SPI_NOR_DUAL_READ in the entry in the spi-nor 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
Re: [PATCH 12/22] ARM: dts: r8a7744-iwg20d-q7-dbcm-ca: Add device tree for camera DB
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> This patch adds support for the camera daughter board which is
> connected to iWave's RZ/G1N Qseven carrier board.
>
> Signed-off-by: Biju Das
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 19/22] ARM: dts: r8a7744-iwg20m: Add SPI NOR support
Hi Biju,
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Add support for the SPI NOR device used to boot up the system
> to the iWave RZ/G1N Qseven System On Module DT.
>
> Signed-off-by: Biju Das
Thanks for your patch!
> --- a/arch/arm/boot/dts/r8a7744-iwg20m.dtsi
> +++ b/arch/arm/boot/dts/r8a7744-iwg20m.dtsi
> @@ -53,6 +58,27 @@
> status = "okay";
> };
>
> + {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +
> + /* WARNING - This device contains the bootloader. Handle with care. */
> + flash: flash@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "sst,sst25vf016b", "jedec,spi-nor";
According to the schematics, this is an ISSI IS25LP016D?
ISSI was acquired by GigaDevice, according to Wikipedia.
While SST is now MicroChip.
> + reg = <0>;
> + spi-max-frequency = <5000>;
> + spi-tx-bus-width = <1>;
> + spi-rx-bus-width = <1>;
<1> is the default, but it's indeed good to make this explicit, as this is
a QSPI device with 2 unwired data pins.
However, as the device seems to support dual transfers, and dual mode
uses the standard MOSI/MISO pins, you should use <2> for both.
The RSPI driver supports this.
The same applies to the RZ/G1M version.
> + m25p,fast-read;
> + spi-cpol;
> + spi-cpha;
> + };
> +};
Apart from that:
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 06/22] ARM: dts: r8a7744-iwg20m: Enable SDHI10 controller
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Enable the SDHI0 controller on iWave RZ/G1N Qseven System On Module.
>
> Signed-off-by: Biju Das
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 05/22] ARM: dts: r8a7744-iwg20m: Add eMMC support
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Add eMMC support for iWave RZ/G1N Qseven System On Module.
>
> Signed-off-by: Biju Das
Reviewed-by: Geert Uytterhoeven
I assume the PCB is the same for RZ/G1M and RZ/G1N, so perhaps this
can be factored out in a common .dtsi file, like we did for Salvator-X(S)?
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 3/7] ARM: dts: r8a7744-iwg20d-q7: Add support for iWave G20D-Q7 board based on RZ/G1N
On Thu, Nov 22, 2018 at 10:23 AM Biju Das wrote:
> Add support for iWave RainboW-G20D-Qseven board based on RZ/G1N.
>
> Signed-off-by: Biju Das
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 1/7] ARM: dts: r8a7744-iwg20m: Add iWave RZ/G1N Qseven SOM
Hi Biju,
On Thu, Nov 22, 2018 at 10:22 AM Biju Das wrote:
> Add support for iWave RZ/G1N Qseven System On Module.
>
> Signed-off-by: Biju Das
Reviewed-by: Geert Uytterhoeven
> --- /dev/null
> +++ b/arch/arm/boot/dts/r8a7744-iwg20m.dtsi
> @@ -0,0 +1,31 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for the iWave RZ/G1N Qseven SOM
> + *
> + * Copyright (C) 2018 Renesas Electronics Corp.
> + */
> +
> +#include "r8a7744.dtsi"
> +#include
> +
> +/ {
> + compatible = "iwave,g20m", "renesas,r8a7744";
> +
> + memory@4000 {
> + device_type = "memory";
> + reg = <0 0x4000 0 0x4000>;
> + };
I could not verify the memory configuration, but I assume it's correct ;-)
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 5/5] ARM: dts: r8a7744: Add TPU support
On Wed, Nov 28, 2018 at 5:47 PM Biju Das wrote:
> Add TPU support to SoC DT.
>
> Signed-off-by: Biju Das
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 4/5] ARM: dts: r8a7744: Add PWM SoC support
On Wed, Nov 28, 2018 at 5:47 PM Biju Das wrote:
> Add the definitions for pwm[0123456] to the SoC dtsi.
>
> Signed-off-by: Biju Das
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 2/5] ARM: dts: r8a7744: Add VSP support
On Wed, Nov 28, 2018 at 5:47 PM Biju Das wrote:
> Add VSP support to SoC DT.
>
> Signed-off-by: Biju Das
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 3/5] ARM: dts: r8a7744: Add IPMMU DT nodes
On Wed, Nov 28, 2018 at 5:47 PM Biju Das wrote:
> Add the six IPMMU instances found in the r8a7744 to DT with a disabled
> status.
>
> Signed-off-by: Biju Das
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 22/22] ARM: dts: r8a7744: Add PCIe Controller device node
On Tue, Nov 27, 2018 at 1:06 PM Biju Das wrote:
> Add a device node for the PCIe controller on the Renesas
> RZ/G1N (r8a7744) SoC.
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 1/5] ARM: dts: r8a7744: add VIN dt support
On Wed, Nov 28, 2018 at 5:47 PM Biju Das wrote:
> Add VIN[012] support to SoC dt.
>
> Signed-off-by: Biju Das
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 21/22] ARM: dts: r8a7744: Add xhci support
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Add a device node for the xhci controller on the Renesas
> RZ/G1N (r8a7744) SoC.
>
> Signed-off-by: Biju Das
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 20/22] ARM: dts: r8a7744: Add MSIOF[012] support
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Add the DT nodes needed by MSIOF[012] interfaces to the SoC dtsi.
>
> Signed-off-by: Biju Das
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 18/22] ARM: dts: r8a7744: Add QSPI support
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Add the DT node for the QSPI interface to the SoC dtsi.
>
> Signed-off-by: Biju Das
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 14/22] ARM: dts: r8a7744: Add IRQC support
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Describe the IRQC interrupt controller in the r8a7744 device tree.
>
> Signed-off-by: Biju Das
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 15/22] ARM: dts: r8a7744: Add thermal device to DT
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> This patch instantiates the thermal sensor module with thermal-zone
> support.
>
> Signed-off-by: Biju Das
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 16/22] ARM: dts: r8a7744: Add CMT SoC specific support
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Add CMT[01] support to SoC DT.
>
> Signed-off-by: Biju Das
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 13/22] ARM: dts: r8a7744: Add CAN support
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Add the definitions for can0 and can1 to the r8a7744 SoC dtsi.
>
> Signed-off-by: Biju Das
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 11/22] ARM: dts: r8a7744: Add DU support
Hi Biju,
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Add du node to r8a7744 SoC DT. Boards that want to enable the DU
> need to specify the output topology.
>
> Signed-off-by: Biju Das
Thanks for your patch!
> --- a/arch/arm/boot/dts/r8a7744.dtsi
> +++ b/arch/arm/boot/dts/r8a7744.dtsi
> @@ -1300,8 +1300,17 @@
> };
>
> du: display@feb0 {
> + compatible = "renesas,du-r8a7744";
> reg = <0 0xfeb0 0 0x4>,
> <0 0xfeb9 0 0x1c>;
> + reg-names = "du", "lvds.0";
Please use the new DU/LVDS bindings, using a separate node for LVDS.
BTW, I believe the display won't work with a recent tree, unless you've added
a DT live patch drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7744.dts?
The same is true for RZ/G1M.
> + interrupts = ,
> +;
> + clocks = < CPG_MOD 724>,
> +< CPG_MOD 723>,
> +< CPG_MOD 726>;
> + clock-names = "du.0", "du.1", "lvds.0";
> + status = "disabled";
>
> ports {
> #address-cells = <1>;
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 07/22] ARM: dts: r8a7744: USB 2.0 host support
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Describe internal PCI bridge devices, USB phy device and
> link PCI USB devices to USB phy.
>
> Signed-off-by: Biju Das
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 10/22] ARM: dts: r8a7744: Add audio support
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Add sound support for the RZ/G1N SoC (a.k.a. R8A7744).
>
> This work is based on similar work done on the R8A7743 SoC.
>
> Signed-off-by: Biju Das
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 09/22] ARM: dts: r8a7744: Add RWDT node
Hi Biju,
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Add a device node for the Watchdog Timer (RWDT) controller on the Renesas
> RZ/G1N (r8a7744) SoC.
>
> Signed-off-by: Biju Das
Thanks for your patch!
> --- a/arch/arm/boot/dts/r8a7744.dtsi
> +++ b/arch/arm/boot/dts/r8a7744.dtsi
> @@ -293,6 +293,16 @@
> reg = <0 0xe616 0 0x100>;
> };
>
> + rwdt: watchdog@e602 {
Please preserve sort order (by address, per group of devices), by
inserting before gpio@e605.
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 08/22] ARM: dts: r8a7744: Add USB-DMAC and HSUSB device nodes
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Add usb dmac and hsusb device nodes on RZ/G1N SoC dtsi.
>
> Signed-off-by: Biju Das
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 04/22] ARM: dts: r8a7744: Add MMC node
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Add MMC node to the DT of the r8a7744 SoC.
>
> Signed-off-by: Biju Das
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 03/22] ARM: dts: r8a7744: Add SDHI nodes
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Add SDHI nodes to the DT of the r8a7744 SoC.
>
> Signed-off-by: Biju Das
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 02/22] ARM: dts: r8a7744: Add I2C and IIC support
Hi Biju,
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Add the I2C[0-5] and IIC[0,1,3] devices nodes to the R8A7744 device tree.
>
> Signed-off-by: Biju Das
Thanks for your patch!
> --- a/arch/arm/boot/dts/r8a7744.dtsi
> +++ b/arch/arm/boot/dts/r8a7744.dtsi
> @@ -15,6 +15,18 @@
> #address-cells = <2>;
> #size-cells = <2>;
>
> + aliases {
> + i2c0 =
> + i2c1 =
> + i2c2 =
> + i2c3 =
> + i2c4 =
> + i2c5 =
> + i2c6 =
> + i2c7 =
> + i2c8 =
> + };
Please drop the i2c aliases. If needed at all, device aliases are board-specific
(for ports labeled e.g. "i2c0").
> + iic3: i2c@e60b {
> + /* doesn't need pinmux */
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "renesas,iic-r8a7744",
> +"renesas,rcar-gen2-iic",
> +"renesas,rmobile-iic";
It seems iic3 on RZ/G1N is different, in that it does not support
automatic transmission.
This is a bit similar like on R-Car E3, where we dropped compatibility
with the generic version to indicate this. But on RZ/G1N we cannot use
the same solution, as the limitation does not apply to all instances.
RZ/G1H and RZ/G1M have the same issue.
> + reg = <0 0xe60b 0 0x425>;
> + interrupts = ;
> + clocks = < CPG_MOD 926>;
> + dmas = < 0x77>, < 0x78>,
> + < 0x77>, < 0x78>;
> + dma-names = "tx", "rx", "tx", "rx";
> + power-domains = < R8A7744_PD_ALWAYS_ON>;
> + resets = < 926>;
> + status = "disabled";
> };
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 01/22] ARM: dts: r8a7744: Add [H]SCIF{A|B} support
On Tue, Nov 27, 2018 at 1:05 PM Biju Das wrote:
> Describe [H]SCIF{|A|B} ports in the R8A7744 device tree.
>
> Signed-off-by: Biju Das
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 7/7] ARM: dts: r8a7744: Add SMP support
On Thu, Nov 22, 2018 at 10:23 AM Biju Das wrote:
> Add DT node for the Advanced Power Management Unit (APMU), add the
> second CPU core, and use "renesas,apmu" as "enable-method".
>
> Also add cpu1 phandle node to the PMU interrupt-affinity property.
Please change GIC_CPU_MASK_SIMPLE() from 1 to 2 in this patch, too.
> Signed-off-by: Biju Das
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 2/7] ARM: dts: r8a7744: Initial SoC device tree
Hi Biju,
On Thu, Nov 22, 2018 at 10:23 AM Biju Das wrote:
> Basic support for the RZ/G1N (R8A7744) SoC. Added placeholders
> to avoid compilation error with the common platform code.
>
> Signed-off-by: Biju Das
> --- /dev/null
> +++ b/arch/arm/boot/dts/r8a7744.dtsi
> @@ -0,0 +1,369 @@
> + soc {
> + gic: interrupt-controller@f1001000 {
> + compatible = "arm,gic-400";
> + #interrupt-cells = <3>;
> + #address-cells = <0>;
> + interrupt-controller;
> + reg = <0 0xf1001000 0 0x1000>, <0 0xf1002000 0
> 0x2000>,
> + <0 0xf1004000 0 0x2000>, <0 0xf1006000 0
> 0x2000>;
> + interrupts = IRQ_TYPE_LEVEL_HIGH)>;
Tehcnically, this mask should be GIC_CPU_MASK_SIMPLE(1)
until you add the second CPU node.
> + timer {
> + compatible = "arm,armv7-timer";
> + interrupts-extended = < GIC_PPI 13
> (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
> + < GIC_PPI 14
> (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
> + < GIC_PPI 11
> (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
> + < GIC_PPI 10
> (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
Likewise.
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 6/7] ARM: dts: r8a7744: Add Ethernet AVB support
On Thu, Nov 22, 2018 at 10:23 AM Biju Das wrote:
> Add Ethernet AVB support for R8A7744 SoC.
>
> Signed-off-by: Biju Das
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 4/7] ARM: dts: r8a7744: Add SYS-DMAC support
On Thu, Nov 22, 2018 at 10:23 AM Biju Das wrote:
> Describe SYS-DMAC0/1 in the R8A7744 device tree.
>
> Signed-off-by: Biju Das
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 5/7] ARM: dts: r8a7744: Add GPIO support
On Thu, Nov 22, 2018 at 10:23 AM Biju Das wrote:
> Describe GPIO blocks in the R8A7744 device tree.
>
> Signed-off-by: Biju Das
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 2/7] ARM: dts: r8a7744: Initial SoC device tree
Hi Biju,
On Thu, Nov 22, 2018 at 10:23 AM Biju Das wrote:
> Basic support for the RZ/G1N (R8A7744) SoC. Added placeholders
> to avoid compilation error with the common platform code.
>
> Signed-off-by: Biju Das
Thanks for your patch!
> --- /dev/null
> +++ b/arch/arm/boot/dts/r8a7744.dtsi
> + soc {
> + pfc: pin-controller@e606 {
> + compatible = "renesas,pfc-r8a7744";
> + reg = <0 0xe606 0 0x164>;
Given the datasheet mentions (reserved) registers up to offset 0x24c,
you may want to use 0x250 for the register block length.
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] dt-bindings: watchdog: renesas-wdt: Document r8a77470 support
On Fri, Oct 26, 2018 at 11:03 AM Biju Das wrote:
> RZ/G1C (R8A77470) watchdog implementation is compatible with R-Car
> Gen2, therefore add relevant documentation.
>
> Signed-off-by: Biju Das
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
[PATCH 2/2] ARM: shmobile: R-Mobile: Move pm-rmobile to drivers/soc/renesas/
The pm-rmobile driver is really a driver for the System Controller (SYSC) found in R-Mobile SoCs. An equivalent driver for R-Car SoCs is already located under drivers/soc/renesas/. Hence move the pm-rmobile driver from arch/arm/mach-shmobile/ to drivers/soc/renesas/, and rename it to rmobile-sysc. Enable compile-testing on non-ARM and non-R-Mobile SoCs. Signed-off-by: Geert Uytterhoeven --- arch/arm/mach-shmobile/Kconfig | 5 - arch/arm/mach-shmobile/Makefile| 1 - drivers/soc/renesas/Kconfig| 7 ++- drivers/soc/renesas/Makefile | 1 + .../pm-rmobile.c => drivers/soc/renesas/rmobile-sysc.c | 0 5 files changed, 7 insertions(+), 7 deletions(-) rename arch/arm/mach-shmobile/pm-rmobile.c => drivers/soc/renesas/rmobile-sysc.c (100%) diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig index 9b798c9dffe4e94a..3683d6f109730ee7 100644 --- a/arch/arm/mach-shmobile/Kconfig +++ b/arch/arm/mach-shmobile/Kconfig @@ -1,9 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 -config PM_RMOBILE - bool - select PM - select PM_GENERIC_DOMAINS - menuconfig ARCH_RENESAS bool "Renesas ARM SoCs" depends on ARCH_MULTI_V7 && MMU diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile index 5591646cb9bbfd33..f7bf17b7abaef7a9 100644 --- a/arch/arm/mach-shmobile/Makefile +++ b/arch/arm/mach-shmobile/Makefile @@ -35,7 +35,6 @@ smp-$(CONFIG_ARCH_EMEV2) += smp-emev2.o headsmp-scu.o platsmp-scu.o # PM objects obj-$(CONFIG_SUSPEND) += suspend.o -obj-$(CONFIG_PM_RMOBILE) += pm-rmobile.o obj-$(CONFIG_ARCH_RCAR_GEN2) += pm-rcar-gen2.o # Framework support diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig index fe7f58616cdd6cf7..4d8012e1205c5a7f 100644 --- a/drivers/soc/renesas/Kconfig +++ b/drivers/soc/renesas/Kconfig @@ -34,9 +34,11 @@ config ARCH_RCAR_GEN3 config ARCH_RMOBILE bool - select PM_RMOBILE + select PM + select PM_GENERIC_DOMAINS select SYS_SUPPORTS_SH_CMT select SYS_SUPPORTS_SH_TMU + select SYSC_RMOBILE config ARCH_RZN1 bool @@ -297,4 +299,7 @@ config RST_RCAR config SYSC_RCAR bool "R-Car System Controller support" if COMPILE_TEST +config SYSC_RMOBILE + bool "R-Mobile System Controller support" if COMPILE_TEST + endif # SOC_RENESAS diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile index 3bdd7dbc38a9c7a3..00764d5a60b33dfe 100644 --- a/drivers/soc/renesas/Makefile +++ b/drivers/soc/renesas/Makefile @@ -27,3 +27,4 @@ endif # Family obj-$(CONFIG_RST_RCAR) += rcar-rst.o obj-$(CONFIG_SYSC_RCAR)+= rcar-sysc.o +obj-$(CONFIG_SYSC_RMOBILE) += rmobile-sysc.o diff --git a/arch/arm/mach-shmobile/pm-rmobile.c b/drivers/soc/renesas/rmobile-sysc.c similarity index 100% rename from arch/arm/mach-shmobile/pm-rmobile.c rename to drivers/soc/renesas/rmobile-sysc.c -- 2.17.1
[PATCH 1/2] ARM: shmobile: R-Mobile: Clean up struct rmobile_pm_domain
Commit 59b89af1d5551c12 ("ARM: shmobile: sh7372: Remove Legacy C
SoC code") removed the last user of the rmobile_pm_domain.resume()
callback.
Commit 44d88c754e57a6d9 ("ARM: shmobile: Remove legacy SoC code
for R-Mobile A1") removed the last user of the rmobile_pm_domain.no_debug
flag and of the "pm-rmobile.h" header file (outside the actual driver).
Hence remove no longer used rmobile_pm_domain members, and absorb the
header file into the driver.
Signed-off-by: Geert Uytterhoeven
---
arch/arm/mach-shmobile/pm-rmobile.c | 37 ++---
arch/arm/mach-shmobile/pm-rmobile.h | 22 -
2 files changed, 18 insertions(+), 41 deletions(-)
delete mode 100644 arch/arm/mach-shmobile/pm-rmobile.h
diff --git a/arch/arm/mach-shmobile/pm-rmobile.c
b/arch/arm/mach-shmobile/pm-rmobile.c
index c6a11b5ec6dbc704..421ae1c887d824d0 100644
--- a/arch/arm/mach-shmobile/pm-rmobile.c
+++ b/arch/arm/mach-shmobile/pm-rmobile.c
@@ -18,12 +18,11 @@
#include
#include
#include
+#include
#include
#include
-#include "pm-rmobile.h"
-
/* SYSC */
#define SPDCR 0x08/* SYS Power Down Control Register */
#define SWUCR 0x14/* SYS Wakeup Control Register */
@@ -32,6 +31,14 @@
#define PSTR_RETRIES 100
#define PSTR_DELAY_US 10
+struct rmobile_pm_domain {
+ struct generic_pm_domain genpd;
+ struct dev_power_governor *gov;
+ int (*suspend)(void);
+ void __iomem *base;
+ unsigned int bit_shift;
+};
+
static inline
struct rmobile_pm_domain *to_rmobile_pd(struct generic_pm_domain *d)
{
@@ -65,16 +72,13 @@ static int rmobile_pd_power_down(struct generic_pm_domain
*genpd)
}
}
- if (!rmobile_pd->no_debug)
- pr_debug("%s: Power off, 0x%08x -> PSTR = 0x%08x\n",
-genpd->name, mask,
-__raw_readl(rmobile_pd->base + PSTR));
+ pr_debug("%s: Power off, 0x%08x -> PSTR = 0x%08x\n", genpd->name, mask,
+__raw_readl(rmobile_pd->base + PSTR));
return 0;
}
-static int __rmobile_pd_power_up(struct rmobile_pm_domain *rmobile_pd,
-bool do_resume)
+static int __rmobile_pd_power_up(struct rmobile_pm_domain *rmobile_pd)
{
unsigned int mask;
unsigned int retry_count;
@@ -85,7 +89,7 @@ static int __rmobile_pd_power_up(struct rmobile_pm_domain
*rmobile_pd,
mask = BIT(rmobile_pd->bit_shift);
if (__raw_readl(rmobile_pd->base + PSTR) & mask)
- goto out;
+ return ret;
__raw_writel(mask, rmobile_pd->base + SWUCR);
@@ -100,21 +104,16 @@ static int __rmobile_pd_power_up(struct rmobile_pm_domain
*rmobile_pd,
if (!retry_count)
ret = -EIO;
- if (!rmobile_pd->no_debug)
- pr_debug("%s: Power on, 0x%08x -> PSTR = 0x%08x\n",
-rmobile_pd->genpd.name, mask,
-__raw_readl(rmobile_pd->base + PSTR));
-
-out:
- if (ret == 0 && rmobile_pd->resume && do_resume)
- rmobile_pd->resume();
+ pr_debug("%s: Power on, 0x%08x -> PSTR = 0x%08x\n",
+rmobile_pd->genpd.name, mask,
+__raw_readl(rmobile_pd->base + PSTR));
return ret;
}
static int rmobile_pd_power_up(struct generic_pm_domain *genpd)
{
- return __rmobile_pd_power_up(to_rmobile_pd(genpd), true);
+ return __rmobile_pd_power_up(to_rmobile_pd(genpd));
}
static void rmobile_init_pm_domain(struct rmobile_pm_domain *rmobile_pd)
@@ -127,7 +126,7 @@ static void rmobile_init_pm_domain(struct rmobile_pm_domain
*rmobile_pd)
genpd->power_on = rmobile_pd_power_up;
genpd->attach_dev = cpg_mstp_attach_dev;
genpd->detach_dev = cpg_mstp_detach_dev;
- __rmobile_pd_power_up(rmobile_pd, false);
+ __rmobile_pd_power_up(rmobile_pd);
pm_genpd_init(genpd, gov ? : _qos_governor, false);
}
diff --git a/arch/arm/mach-shmobile/pm-rmobile.h
b/arch/arm/mach-shmobile/pm-rmobile.h
deleted file mode 100644
index 69f839259b092002..
--- a/arch/arm/mach-shmobile/pm-rmobile.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0
- *
- * Copyright (C) 2012 Renesas Solutions Corp.
- *
- * Kuninori Morimoto
- */
-#ifndef PM_RMOBILE_H
-#define PM_RMOBILE_H
-
-#include
-
-struct rmobile_pm_domain {
- struct generic_pm_domain genpd;
- struct dev_power_governor *gov;
- int (*suspend)(void);
- void (*resume)(void);
- void __iomem *base;
- unsigned int bit_shift;
- bool no_debug;
-};
-
-#endif /* PM_RMOBILE_H */
--
2.17.1
[PATCH 0/2] ARM: shmobile: R-Mobile: Clean up and move pm-rmobile driver
Hi Simon, Magnus,
This is a patch series for the pm-rmobile driver, used on R-Mobile A1 and
APE6, and on SH-Mobile AG5, to clean up the driver, move it to
drivers/soc/renesas/, and enable compile-testing.
Thanks!
Geert Uytterhoeven (2):
ARM: shmobile: R-Mobile: Clean up struct rmobile_pm_domain
ARM: shmobile: R-Mobile: Move pm-rmobile to drivers/soc/renesas/
arch/arm/mach-shmobile/Kconfig| 5 ---
arch/arm/mach-shmobile/Makefile | 1 -
arch/arm/mach-shmobile/pm-rmobile.h | 22 ---
drivers/soc/renesas/Kconfig | 7 +++-
drivers/soc/renesas/Makefile | 1 +
.../soc/renesas/rmobile-sysc.c| 37 +--
6 files changed, 25 insertions(+), 48 deletions(-)
delete mode 100644 arch/arm/mach-shmobile/pm-rmobile.h
rename arch/arm/mach-shmobile/pm-rmobile.c =>
drivers/soc/renesas/rmobile-sysc.c (93%)
--
2.17.1
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 5/6] soc: renesas: r8a77980-sysc: Correct A3VIP[012] power domain hierarchy
The R-Car Gen3 HardWare Manual Errata for Rev. 0.80 (Feb 28, 2018)
renamed the A3VIP power domain on R-Car V3H to A3VIP0, and clarified the
power domain hierarchy for the A3VIP[012] power domains.
As the definition for the A3VIP0 domain is not yet used from DT, it can
just be renamed.
Fixes: 7755b40d07a8dba7 ("dt-bindings: power: add R8A77980 SYSC power domain
definitions")
Fixes: 41d6d8bd8ae94ca9 ("soc: renesas: rcar-sysc: add R8A77980 support")
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a77980-sysc.c | 6 +++---
include/dt-bindings/power/r8a77980-sysc.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/renesas/r8a77980-sysc.c
b/drivers/soc/renesas/r8a77980-sysc.c
index dbb2621ce4e3ea18..a8dbe55e8ba82d7e 100644
--- a/drivers/soc/renesas/r8a77980-sysc.c
+++ b/drivers/soc/renesas/r8a77980-sysc.c
@@ -41,9 +41,9 @@ static const struct rcar_sysc_area r8a77980_areas[]
__initconst = {
{ "a2dp0", 0x400, 11, R8A77980_PD_A2DP0, R8A77980_PD_A3IR },
{ "a2dp1", 0x400, 12, R8A77980_PD_A2DP1, R8A77980_PD_A3IR },
{ "a2cn", 0x400, 13, R8A77980_PD_A2CN,R8A77980_PD_A3IR },
- { "a3vip", 0x2c0, 0, R8A77980_PD_A3VIP,R8A77980_PD_ALWAYS_ON },
- { "a3vip1", 0x300, 0, R8A77980_PD_A3VIP1, R8A77980_PD_A3VIP },
- { "a3vip2", 0x280, 0, R8A77980_PD_A3VIP2, R8A77980_PD_A3VIP },
+ { "a3vip0", 0x2c0, 0, R8A77980_PD_A3VIP0, R8A77980_PD_ALWAYS_ON },
+ { "a3vip1", 0x300, 0, R8A77980_PD_A3VIP1, R8A77980_PD_ALWAYS_ON },
+ { "a3vip2", 0x280, 0, R8A77980_PD_A3VIP2, R8A77980_PD_ALWAYS_ON },
};
const struct rcar_sysc_info r8a77980_sysc_info __initconst = {
diff --git a/include/dt-bindings/power/r8a77980-sysc.h
b/include/dt-bindings/power/r8a77980-sysc.h
index 7bebe7e8dbdbb68e..e12c8587b87ec8d5 100644
--- a/include/dt-bindings/power/r8a77980-sysc.h
+++ b/include/dt-bindings/power/r8a77980-sysc.h
@@ -22,7 +22,7 @@
#define R8A77980_PD_CA53_CPU2 7
#define R8A77980_PD_CA53_CPU3 8
#define R8A77980_PD_A2CN 10
-#define R8A77980_PD_A3VIP 11
+#define R8A77980_PD_A3VIP0 11
#define R8A77980_PD_A2IR5 12
#define R8A77980_PD_CR713
#define R8A77980_PD_A2IR4 15
--
2.17.1
[PATCH 2/6] soc: renesas: r8a77970-sysc: Remove non-existent CR7 power domain
The R-Car Gen3 HardWare Manual Errata for Rev. 0.80 (Feb 28, 2018)
removed the CR7 power domain on R-Car V3M, as this SoC does not have an
ARM Cortex-R7 Realtime Core.
As this definition was never used from DT, it can just be removed.
Fixes: 833bdb47c826a1a6 ("dt-bindings: power: add R8A77970 SYSC power domain
definitions")
Fixes: bab9b2a74fe9da96 ("soc: renesas: rcar-sysc: add R8A77970 support")
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a77970-sysc.c | 1 -
include/dt-bindings/power/r8a77970-sysc.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/soc/renesas/r8a77970-sysc.c
b/drivers/soc/renesas/r8a77970-sysc.c
index 35b30d6a8958a063..2c6d76490ca096ca 100644
--- a/drivers/soc/renesas/r8a77970-sysc.c
+++ b/drivers/soc/renesas/r8a77970-sysc.c
@@ -20,7 +20,6 @@ static const struct rcar_sysc_area r8a77970_areas[]
__initconst = {
PD_CPU_NOCR },
{ "ca53-cpu1", 0x200, 1, R8A77970_PD_CA53_CPU1, R8A77970_PD_CA53_SCU,
PD_CPU_NOCR },
- { "cr7",0x240, 0, R8A77970_PD_CR7, R8A77970_PD_ALWAYS_ON },
{ "a3ir", 0x180, 0, R8A77970_PD_A3IR, R8A77970_PD_ALWAYS_ON },
{ "a2ir0", 0x400, 0, R8A77970_PD_A2IR0,R8A77970_PD_A3IR },
{ "a2ir1", 0x400, 1, R8A77970_PD_A2IR1,R8A77970_PD_A3IR },
diff --git a/include/dt-bindings/power/r8a77970-sysc.h
b/include/dt-bindings/power/r8a77970-sysc.h
index bf54779d16252a46..5c1ef1398b704ab5 100644
--- a/include/dt-bindings/power/r8a77970-sysc.h
+++ b/include/dt-bindings/power/r8a77970-sysc.h
@@ -16,7 +16,6 @@
#define R8A77970_PD_CA53_CPU0 5
#define R8A77970_PD_CA53_CPU1 6
-#define R8A77970_PD_CR713
#define R8A77970_PD_CA53_SCU 21
#define R8A77970_PD_A2IR0 23
#define R8A77970_PD_A3IR 24
--
2.17.1
[PATCH 0/6] soc: renesas: Miscellaneous fixes
Hi Simon, Magnus,
This patch series contains several fixes for the Renesas SYSC (power
domain) drivers and DT bindings:
- Removal of non-existent power domains,
- Correction of power domain names and hierarchy.
These are the result of skimming the Hardware Manual Errata.
Note that the last patch (marked RFC) cannot be applied yet, as there is
an existing (but incorrect) user of the removed definition.
Thanks!
Geert Uytterhoeven (6):
soc: renesas: r8a77965-sysc: Remove non-existent A3IR power domain
soc: renesas: r8a77970-sysc: Remove non-existent CR7 power domain
soc: renesas: r8a77970-sysc: Correct names of A2DP/A2CN power domains
soc: renesas: r8a77980-sysc: Correct names of A2DP[01] power domains
soc: renesas: r8a77980-sysc: Correct A3VIP[012] power domain hierarchy
[RFC] dt-bindings: power: r8a77965: Remove non-existent A3IR power
domain
drivers/soc/renesas/r8a77965-sysc.c | 1 -
drivers/soc/renesas/r8a77970-sysc.c | 5 ++---
drivers/soc/renesas/r8a77980-sysc.c | 10 +-
include/dt-bindings/power/r8a77965-sysc.h | 1 -
include/dt-bindings/power/r8a77970-sysc.h | 7 +++
include/dt-bindings/power/r8a77980-sysc.h | 6 +++---
6 files changed, 13 insertions(+), 17 deletions(-)
--
2.17.1
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 3/6] soc: renesas: r8a77970-sysc: Correct names of A2DP/A2CN power domains
The R-Car Gen3 HardWare Manual Errata for Rev. 0.80 (Feb 28, 2018)
renamed the A2IR2 and A2IR3 power domains on R-Car V3M to A2DP resp.
A2CN.
As these definitions are not yet used from DT, they can just be renamed.
While at it, fix the indentation of the A3IR definition.
Fixes: 833bdb47c826a1a6 ("dt-bindings: power: add R8A77970 SYSC power domain
definitions")
Fixes: bab9b2a74fe9da96 ("soc: renesas: rcar-sysc: add R8A77970 support")
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a77970-sysc.c | 4 ++--
include/dt-bindings/power/r8a77970-sysc.h | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/renesas/r8a77970-sysc.c
b/drivers/soc/renesas/r8a77970-sysc.c
index 2c6d76490ca096ca..280c48b80f240424 100644
--- a/drivers/soc/renesas/r8a77970-sysc.c
+++ b/drivers/soc/renesas/r8a77970-sysc.c
@@ -23,8 +23,8 @@ static const struct rcar_sysc_area r8a77970_areas[]
__initconst = {
{ "a3ir", 0x180, 0, R8A77970_PD_A3IR, R8A77970_PD_ALWAYS_ON },
{ "a2ir0", 0x400, 0, R8A77970_PD_A2IR0,R8A77970_PD_A3IR },
{ "a2ir1", 0x400, 1, R8A77970_PD_A2IR1,R8A77970_PD_A3IR },
- { "a2ir2", 0x400, 2, R8A77970_PD_A2IR2,R8A77970_PD_A3IR },
- { "a2ir3", 0x400, 3, R8A77970_PD_A2IR3,R8A77970_PD_A3IR },
+ { "a2dp", 0x400, 2, R8A77970_PD_A2DP, R8A77970_PD_A3IR },
+ { "a2cn", 0x400, 3, R8A77970_PD_A2CN, R8A77970_PD_A3IR },
{ "a2sc0", 0x400, 4, R8A77970_PD_A2SC0,R8A77970_PD_A3IR },
{ "a2sc1", 0x400, 5, R8A77970_PD_A2SC1,R8A77970_PD_A3IR },
};
diff --git a/include/dt-bindings/power/r8a77970-sysc.h
b/include/dt-bindings/power/r8a77970-sysc.h
index 5c1ef1398b704ab5..85cc5f23cf9f8e72 100644
--- a/include/dt-bindings/power/r8a77970-sysc.h
+++ b/include/dt-bindings/power/r8a77970-sysc.h
@@ -18,10 +18,10 @@
#define R8A77970_PD_CA53_CPU1 6
#define R8A77970_PD_CA53_SCU 21
#define R8A77970_PD_A2IR0 23
-#define R8A77970_PD_A3IR 24
+#define R8A77970_PD_A3IR 24
#define R8A77970_PD_A2IR1 27
-#define R8A77970_PD_A2IR2 28
-#define R8A77970_PD_A2IR3 29
+#define R8A77970_PD_A2DP 28
+#define R8A77970_PD_A2CN 29
#define R8A77970_PD_A2SC0 30
#define R8A77970_PD_A2SC1 31
--
2.17.1
[PATCH 6/6] [RFC] dt-bindings: power: r8a77965: Remove non-existent A3IR power domain
The R-Car Gen3 HardWare Manual Errata for Rev. 0.80 (Feb 28, 2018)
removed the A3IR power domain on R-Car M3-N, as this SoC does not have
an Image Processing Unit (IMP-X5).
As this definition is no longer used from DT, it can be removed.
Fixes: a527709b78b3c997 ("soc: renesas: rcar-sysc: Add R-Car M3-N support")
Signed-off-by: Geert Uytterhoeven
---
Marked as RFC, as this patch depends on "arm64: dts: renesas:
r8a77965: Remove non-existent IPMMU-IR".
If the dependency goes in first, this patch can be squashed with "soc:
renesas: r8a77965-sysc: Remove non-existent A3IR power domain".
---
include/dt-bindings/power/r8a77965-sysc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/dt-bindings/power/r8a77965-sysc.h
b/include/dt-bindings/power/r8a77965-sysc.h
index 05a4b5917314791a..de82d8a15ea13a85 100644
--- a/include/dt-bindings/power/r8a77965-sysc.h
+++ b/include/dt-bindings/power/r8a77965-sysc.h
@@ -21,7 +21,6 @@
#define R8A77965_PD_A3VC 14
#define R8A77965_PD_3DG_A 17
#define R8A77965_PD_3DG_B 18
-#define R8A77965_PD_A3IR 24
#define R8A77965_PD_A2VC1 26
/* Always-on power area */
--
2.17.1
[PATCH 4/6] soc: renesas: r8a77980-sysc: Correct names of A2DP[01] power domains
The R-Car Gen3 HardWare Manual Errata for Rev. 0.80 (Feb 28, 2018)
renamed the A2PD0 and A2DP0 power domains on R-Car V3H to A2DP0 resp.
A2DP1.
As these definitions are not yet used from DT, they can just be renamed.
Fixes: 7755b40d07a8dba7 ("dt-bindings: power: add R8A77980 SYSC power domain
definitions")
Fixes: 41d6d8bd8ae94ca9 ("soc: renesas: rcar-sysc: add R8A77980 support")
Signed-off-by: Geert Uytterhoeven
---
drivers/soc/renesas/r8a77980-sysc.c | 4 ++--
include/dt-bindings/power/r8a77980-sysc.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/renesas/r8a77980-sysc.c
b/drivers/soc/renesas/r8a77980-sysc.c
index 9265fb525ef34228..dbb2621ce4e3ea18 100644
--- a/drivers/soc/renesas/r8a77980-sysc.c
+++ b/drivers/soc/renesas/r8a77980-sysc.c
@@ -38,8 +38,8 @@ static const struct rcar_sysc_area r8a77980_areas[]
__initconst = {
{ "a2sc2", 0x400, 8, R8A77980_PD_A2SC2,R8A77980_PD_A3IR },
{ "a2sc3", 0x400, 9, R8A77980_PD_A2SC3,R8A77980_PD_A3IR },
{ "a2sc4", 0x400, 10, R8A77980_PD_A2SC4, R8A77980_PD_A3IR },
- { "a2pd0", 0x400, 11, R8A77980_PD_A2PD0, R8A77980_PD_A3IR },
- { "a2pd1", 0x400, 12, R8A77980_PD_A2PD1, R8A77980_PD_A3IR },
+ { "a2dp0", 0x400, 11, R8A77980_PD_A2DP0, R8A77980_PD_A3IR },
+ { "a2dp1", 0x400, 12, R8A77980_PD_A2DP1, R8A77980_PD_A3IR },
{ "a2cn", 0x400, 13, R8A77980_PD_A2CN,R8A77980_PD_A3IR },
{ "a3vip", 0x2c0, 0, R8A77980_PD_A3VIP,R8A77980_PD_ALWAYS_ON },
{ "a3vip1", 0x300, 0, R8A77980_PD_A3VIP1, R8A77980_PD_A3VIP },
diff --git a/include/dt-bindings/power/r8a77980-sysc.h
b/include/dt-bindings/power/r8a77980-sysc.h
index 2c90c12377253e5f..7bebe7e8dbdbb68e 100644
--- a/include/dt-bindings/power/r8a77980-sysc.h
+++ b/include/dt-bindings/power/r8a77980-sysc.h
@@ -15,8 +15,8 @@
#define R8A77980_PD_A2SC2 0
#define R8A77980_PD_A2SC3 1
#define R8A77980_PD_A2SC4 2
-#define R8A77980_PD_A2PD0 3
-#define R8A77980_PD_A2PD1 4
+#define R8A77980_PD_A2DP0 3
+#define R8A77980_PD_A2DP1 4
#define R8A77980_PD_CA53_CPU0 5
#define R8A77980_PD_CA53_CPU1 6
#define R8A77980_PD_CA53_CPU2 7
--
2.17.1
[PATCH 07/13] clk: renesas: r8a77970: Add CPEX clock
Implement support for the CPEX clock on R-Car V3M. This clock can be
selected as a clock source for CMT1 (Compare Match Timer Type 1).
Signed-off-by: Geert Uytterhoeven
---
drivers/clk/renesas/r8a77970-cpg-mssr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/renesas/r8a77970-cpg-mssr.c
b/drivers/clk/renesas/r8a77970-cpg-mssr.c
index 9d845ebd7355add2..cbed3769a100738d 100644
--- a/drivers/clk/renesas/r8a77970-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a77970-cpg-mssr.c
@@ -96,6 +96,7 @@ static const struct cpg_core_clk r8a77970_core_clks[]
__initconst = {
DEF_FIXED("cl", R8A77970_CLK_CL,CLK_PLL1_DIV2, 48, 1),
DEF_FIXED("cp", R8A77970_CLK_CP,CLK_EXTAL, 2, 1),
+ DEF_FIXED("cpex", R8A77970_CLK_CPEX, CLK_EXTAL, 2, 1),
DEF_DIV6P1("canfd", R8A77970_CLK_CANFD, CLK_PLL1_DIV4, 0x244),
DEF_DIV6P1("mso", R8A77970_CLK_MSO, CLK_PLL1_DIV4, 0x014),
--
2.17.1
[PATCH 08/13] clk: renesas: r8a77990: Correct parent clock of DU
From: Takeshi Kihara
According to the R-Car Gen3 Hardware Manual Rev 1.00, the parent clock
of the DU module clocks on R-Car E3 is S1D1.
Signed-off-by: Takeshi Kihara
Fixes: 3570a2af473789c5 ("clk: renesas: cpg-mssr: Add support for R-Car E3")
Signed-off-by: Geert Uytterhoeven
---
drivers/clk/renesas/r8a77990-cpg-mssr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/renesas/r8a77990-cpg-mssr.c
b/drivers/clk/renesas/r8a77990-cpg-mssr.c
index 9eb80180eea0b1a6..9a278c75c918cfa8 100644
--- a/drivers/clk/renesas/r8a77990-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a77990-cpg-mssr.c
@@ -183,8 +183,8 @@ static const struct mssr_mod_clk r8a77990_mod_clks[]
__initconst = {
DEF_MOD("ehci0", 703, R8A77990_CLK_S3D4),
DEF_MOD("hsusb", 704, R8A77990_CLK_S3D4),
DEF_MOD("csi40", 716, R8A77990_CLK_CSI0),
- DEF_MOD("du1", 723, R8A77990_CLK_S2D1),
- DEF_MOD("du0", 724, R8A77990_CLK_S2D1),
+ DEF_MOD("du1", 723, R8A77990_CLK_S1D1),
+ DEF_MOD("du0", 724, R8A77990_CLK_S1D1),
DEF_MOD("lvds", 727, R8A77990_CLK_S2D1),
DEF_MOD("vin5", 806, R8A77990_CLK_S1D2),
--
2.17.1
[PATCH 02/13] dt-bindings: clock: r8a7796: Remove CSIREF clock
The R-Car Gen3 HardWare Manual Errata for Rev. 0.52 (Nov 30, 2016)
removed the CSI reference clock on R-Car M3-W.
As this definition was never used, it can just be removed.
The freed slot in the DT bindings header must not be reused, though.
Fixes: 972610fb23b08dd5 ("clk: renesas: Add r8a7796 CPG Core Clock Definitions")
Signed-off-by: Geert Uytterhoeven
---
include/dt-bindings/clock/r8a7796-cpg-mssr.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/dt-bindings/clock/r8a7796-cpg-mssr.h
b/include/dt-bindings/clock/r8a7796-cpg-mssr.h
index e6087f2f7e3aff4a..c0957cf458403bfb 100644
--- a/include/dt-bindings/clock/r8a7796-cpg-mssr.h
+++ b/include/dt-bindings/clock/r8a7796-cpg-mssr.h
@@ -56,7 +56,7 @@
#define R8A7796_CLK_CANFD 45
#define R8A7796_CLK_HDMI 46
#define R8A7796_CLK_CSI0 47
-#define R8A7796_CLK_CSIREF 48
+/* CLK_CSIREF was removed */
#define R8A7796_CLK_CP 49
#define R8A7796_CLK_CPEX 50
#define R8A7796_CLK_R 51
--
2.17.1
[PATCH 01/13] dt-bindings: clock: r8a7795: Remove CSIREF clock
The R-Car Gen3 HardWare Manual Errata for Rev. 0.52 (Nov 30, 2016)
removed the CSI reference clock on R-Car H3.
As this definition was never used, it can just be removed.
The freed slot in the DT bindings header must not be reused, though.
Fixes: 9d0c3c682033d3f1 ("clk: shmobile: Add r8a7795 CPG Core Clock
Definitions")
Signed-off-by: Geert Uytterhoeven
---
include/dt-bindings/clock/r8a7795-cpg-mssr.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/dt-bindings/clock/r8a7795-cpg-mssr.h
b/include/dt-bindings/clock/r8a7795-cpg-mssr.h
index 9483896415654706..92b3e2a95179d25c 100644
--- a/include/dt-bindings/clock/r8a7795-cpg-mssr.h
+++ b/include/dt-bindings/clock/r8a7795-cpg-mssr.h
@@ -50,7 +50,7 @@
#define R8A7795_CLK_CANFD 39
#define R8A7795_CLK_HDMI 40
#define R8A7795_CLK_CSI0 41
-#define R8A7795_CLK_CSIREF 42
+/* CLK_CSIREF was removed */
#define R8A7795_CLK_CP 43
#define R8A7795_CLK_CPEX 44
#define R8A7795_CLK_R 45
--
2.17.1
[PATCH 04/13] clk: renesas: r8a7795: Add CPEX clock
Implement support for the CPEX clock on R-Car H3. This clock can be
selected as a clock source for CMT1 (Compare Match Timer Type 1).
Signed-off-by: Geert Uytterhoeven
---
drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c
b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index 119c024407263568..86842c9fd314e924 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -104,6 +104,7 @@ static struct cpg_core_clk r8a7795_core_clks[] __initdata =
{
DEF_FIXED("cl", R8A7795_CLK_CL,CLK_PLL1_DIV2, 48, 1),
DEF_FIXED("cr", R8A7795_CLK_CR,CLK_PLL1_DIV4, 2, 1),
DEF_FIXED("cp", R8A7795_CLK_CP,CLK_EXTAL, 2, 1),
+ DEF_FIXED("cpex", R8A7795_CLK_CPEX, CLK_EXTAL, 2, 1),
DEF_DIV6P1("canfd", R8A7795_CLK_CANFD, CLK_PLL1_DIV4, 0x244),
DEF_DIV6P1("csi0", R8A7795_CLK_CSI0, CLK_PLL1_DIV4, 0x00c),
--
2.17.1
[PATCH 11/13] clk: renesas: r8a77995: Remove non-existent SSP clocks
The R-Car Gen3 HardWare Manual Errata for Rev. 0.80 (Dec 22, 2017, and
Feb 28, 2018) removed the SSPSRC, SSP1, and SSP2 clocks on R-Car D3, as
this SoC does not have a Stream and Security Processor.
As these definitions were never used, they can just be removed.
The freed slots in the DT bindings header must not be reused, though.
Fixes: 714c53aa2e2d6d60 ("clk: renesas: Add r8a77995 CPG Core Clock
Definitions")
Fixes: d71e851d82c6cfe5 ("clk: renesas: cpg-mssr: Add R8A77995 support")
Signed-off-by: Geert Uytterhoeven
---
drivers/clk/renesas/r8a77995-cpg-mssr.c | 1 -
include/dt-bindings/clock/r8a77995-cpg-mssr.h | 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/renesas/r8a77995-cpg-mssr.c
b/drivers/clk/renesas/r8a77995-cpg-mssr.c
index 5cbdabc311f73de5..f2636a34c96c08ca 100644
--- a/drivers/clk/renesas/r8a77995-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a77995-cpg-mssr.c
@@ -42,7 +42,6 @@ enum clk_ids {
CLK_S2,
CLK_S3,
CLK_SDSRC,
- CLK_SSPSRC,
CLK_RINT,
CLK_OCO,
diff --git a/include/dt-bindings/clock/r8a77995-cpg-mssr.h
b/include/dt-bindings/clock/r8a77995-cpg-mssr.h
index 1eb11acfa563dbd8..80b3c5ec9118b544 100644
--- a/include/dt-bindings/clock/r8a77995-cpg-mssr.h
+++ b/include/dt-bindings/clock/r8a77995-cpg-mssr.h
@@ -35,8 +35,8 @@
#define R8A77995_CLK_CRD2 24
#define R8A77995_CLK_SD0H 25
#define R8A77995_CLK_SD0 26
-#define R8A77995_CLK_SSP2 27
-#define R8A77995_CLK_SSP1 28
+/* CLK_SSP2 was removed */
+/* CLK_SSP1 was removed */
#define R8A77995_CLK_RPC 29
#define R8A77995_CLK_RPCD2 30
#define R8A77995_CLK_ZA2 31
--
2.17.1
[PATCH 03/13] clk: renesas: r8a774a1: Add CPEX clock
Implement support for the CPEX clock on RZ/G2M. This clock can be
selected as a clock source for CMT1 (Compare Match Timer Type 1).
Signed-off-by: Geert Uytterhoeven
---
drivers/clk/renesas/r8a774a1-cpg-mssr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/renesas/r8a774a1-cpg-mssr.c
b/drivers/clk/renesas/r8a774a1-cpg-mssr.c
index b0da34217bdf428e..10e852518870c9ab 100644
--- a/drivers/clk/renesas/r8a774a1-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a774a1-cpg-mssr.c
@@ -100,6 +100,7 @@ static const struct cpg_core_clk r8a774a1_core_clks[]
__initconst = {
DEF_FIXED("cl", R8A774A1_CLK_CL,CLK_PLL1_DIV2, 48, 1),
DEF_FIXED("cp", R8A774A1_CLK_CP,CLK_EXTAL, 2, 1),
+ DEF_FIXED("cpex", R8A774A1_CLK_CPEX, CLK_EXTAL, 2, 1),
DEF_DIV6P1("csi0", R8A774A1_CLK_CSI0, CLK_PLL1_DIV4, 0x00c),
DEF_DIV6P1("mso", R8A774A1_CLK_MSO, CLK_PLL1_DIV4, 0x014),
--
2.17.1
[PATCH 12/13] clk: renesas: r8a77995: Add missing CPEX clock
The R-Car Gen3 HardWare Manual Errata for Rev. 0.80 (Feb 28, 2018) added
the CPEX clock on R-Car D3. This clock can be selected as a clock
source for CMT1 (Compare Match Timer Type 1).
Add the missing clock to the DT bindings header, and implement support
for it in the clock driver.
Signed-off-by: Geert Uytterhoeven
---
drivers/clk/renesas/r8a77995-cpg-mssr.c | 3 ++-
include/dt-bindings/clock/r8a77995-cpg-mssr.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/renesas/r8a77995-cpg-mssr.c
b/drivers/clk/renesas/r8a77995-cpg-mssr.c
index f2636a34c96c08ca..b9745665731fac7e 100644
--- a/drivers/clk/renesas/r8a77995-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a77995-cpg-mssr.c
@@ -22,7 +22,7 @@
enum clk_ids {
/* Core Clock Outputs exported to DT */
- LAST_DT_CORE_CLK = R8A77995_CLK_CP,
+ LAST_DT_CORE_CLK = R8A77995_CLK_CPEX,
/* External Input Clocks */
CLK_EXTAL,
@@ -92,6 +92,7 @@ static const struct cpg_core_clk r8a77995_core_clks[]
__initconst = {
DEF_FIXED("cl",R8A77995_CLK_CL,CLK_PLL1, 48, 1),
DEF_FIXED("cp",R8A77995_CLK_CP,CLK_EXTAL, 2, 1),
+ DEF_FIXED("cpex", R8A77995_CLK_CPEX, CLK_EXTAL, 4, 1),
DEF_DIV6_RO("osc", R8A77995_CLK_OSC, CLK_EXTAL, CPG_RCKCR, 8),
diff --git a/include/dt-bindings/clock/r8a77995-cpg-mssr.h
b/include/dt-bindings/clock/r8a77995-cpg-mssr.h
index 80b3c5ec9118b544..fd701c4e87cf0e22 100644
--- a/include/dt-bindings/clock/r8a77995-cpg-mssr.h
+++ b/include/dt-bindings/clock/r8a77995-cpg-mssr.h
@@ -49,5 +49,6 @@
#define R8A77995_CLK_LV0 38
#define R8A77995_CLK_LV1 39
#define R8A77995_CLK_CP40
+#define R8A77995_CLK_CPEX 41
#endif /* __DT_BINDINGS_CLOCK_R8A77995_CPG_MSSR_H__ */
--
2.17.1
[PATCH 10/13] clk: renesas: r8a77995: Remove non-existent VIN5-7 module clocks
R-Car Gen3 Hardware Manual Errata for Rev 0.80 of February 28, 2018,
removed the module clocks for the Video Input Module (VIN) channels 5-7
on R-Car D3, as they do not exist on this SoC.
Fixes: d71e851d82c6cfe5 ("clk: renesas: cpg-mssr: Add R8A77995 support")
Signed-off-by: Geert Uytterhoeven
---
drivers/clk/renesas/r8a77995-cpg-mssr.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/clk/renesas/r8a77995-cpg-mssr.c
b/drivers/clk/renesas/r8a77995-cpg-mssr.c
index ad95dc225e9c039a..5cbdabc311f73de5 100644
--- a/drivers/clk/renesas/r8a77995-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a77995-cpg-mssr.c
@@ -149,9 +149,6 @@ static const struct mssr_mod_clk r8a77995_mod_clks[]
__initconst = {
DEF_MOD("du1", 723, R8A77995_CLK_S1D1),
DEF_MOD("du0", 724, R8A77995_CLK_S1D1),
DEF_MOD("lvds", 727, R8A77995_CLK_S2D1),
- DEF_MOD("vin7", 804, R8A77995_CLK_S1D2),
- DEF_MOD("vin6", 805, R8A77995_CLK_S1D2),
- DEF_MOD("vin5", 806, R8A77995_CLK_S1D2),
DEF_MOD("vin4", 807, R8A77995_CLK_S1D2),
DEF_MOD("etheravb", 812, R8A77995_CLK_S3D2),
DEF_MOD("imr0", 823, R8A77995_CLK_S1D2),
--
2.17.1
