[GIT PULL LTSI-4.14] LTSI-v4.14 Backport or I2C R-Car Fix
Hi,
This is intended as a submission to LTSI-4.14. It is the backport
of a fixes for safe DMA buffer handling for the SH-Mobile I2C driver
and I2C code. All patches are present in v4.19-rc3.
This pull-request is based on
"[GIT PULL LTSI-4.14] LTSI-v4.14 Backport or I2C R-Car Fix"
tagged as backport/v4.14.61/snapshot-to-v4.18+fixes-flattened,
which I have already sent a pull-request for.
There are 10 patches.
I have performed build testing of this backports on a wide range of
defconfigs and I am not aware of any regressions over v4.14.40 (the
baseline chosen when this work began).
The following changes since commit 4d4605e5c137ed9a53582e573118cbc16b82cbf1:
i2c: rcar: implement STOP and REP_START according to docs (2018-08-28
13:35:06 +0200)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git
backport/v4.14.61/snapshot-to-v4.18+fixes-v2-flattened
for you to fetch changes up to 720043a4efbb3356db116d084c7b877ad41ee51a:
i2c: sh_mobile: fix leak when using DMA bounce buffer (2018-09-17 15:54:30
+0200)
Second Round of LTSI-v4.14 Backports of I2C R-Car Fixes
Base:
* v4.14.61
* Backports of components for Renesas SoCs to v4.18
* First round of Backports of I2C R-Car Fixes
Backport of post-v4.18 fix for i2c-shmobile and I2C core
The focus of these fixes is to make DMA buffer handling safe
Peter Rosin (1):
i2c: smbus: kill memory leak on emulated and failed DMA SMBus xfers
Wenwen Wang (1):
i2c: core: smbus: fix a potential missing-check bug
Wolfram Sang (8):
i2c: dev: mark RDWR buffers as DMA_SAFE
i2c: refactor i2c_master_{send_recv}
i2c: add i2c_master_{send|recv}_dmasafe
i2c: smbus: use DMA safe buffers for emulated SMBus transactions
i2c: add docs to clarify DMA handling
i2c: refactor function to release a DMA safe buffer
i2c: sh_mobile: define start_ch() void as it only returns 0 anyhow
i2c: sh_mobile: fix leak when using DMA bounce buffer
Documentation/i2c/DMA-considerations | 71 ++
drivers/i2c/busses/i2c-sh_mobile.c | 15
drivers/i2c/i2c-core-base.c | 75
drivers/i2c/i2c-core-smbus.c | 57 ++-
drivers/i2c/i2c-dev.c| 2 +
include/linux/i2c.h | 68 +---
6 files changed, 215 insertions(+), 73 deletions(-)
create mode 100644 Documentation/i2c/DMA-considerations
[RFC PATCH] arm64: dts: renesas: gen3: use 400kHz for I2C DVFS bus
The PMIC and EEPROM can operate at 400kHz, so use this speed.
Signed-off-by: Wolfram Sang
---
RFC because I couldn't find docs for the PMIC. Tests showed that it does
work at 400kHz (checksuming over 256 byte reads). Geert, do you happen
to have docs? Other than that, for the EEPROM it also works and is also
documented and BSP uses 400kHz as well. Tested on Salvator XS, not ULCB.
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 ++
arch/arm64/boot/dts/renesas/ulcb.dtsi| 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index d298f7c9ada1..7f91ff524109 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -474,6 +474,8 @@
_dvfs {
status = "okay";
+ clock-frequency = <40>;
+
pmic: pmic@30 {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/renesas/ulcb.dtsi
b/arch/arm64/boot/dts/renesas/ulcb.dtsi
index 7e6078508ba0..30506c5ba4e9 100644
--- a/arch/arm64/boot/dts/renesas/ulcb.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi
@@ -241,6 +241,8 @@
_dvfs {
status = "okay";
+ clock-frequency = <40>;
+
pmic: pmic@30 {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
--
2.18.0
Re: [GIT PULL LTSI-4.14] LTSI-v4.14 Backport or I2C R-Car Fix
Hi Simon,
On Tue, Sep 18, 2018 at 10:51 AM Simon Horman wrote:
> This is intended as a submission to LTSI-4.14. It is the backport
> of a fixes for safe DMA buffer handling for the SH-Mobile I2C driver
> and I2C code. All patches are present in v4.19-rc3.
>
> This pull-request is based on
> "[GIT PULL LTSI-4.14] LTSI-v4.14 Backport or I2C R-Car Fix"
> tagged as backport/v4.14.61/snapshot-to-v4.18+fixes-flattened,
> which I have already sent a pull-request for.
>
> There are 10 patches.
>
> I have performed build testing of this backports on a wide range of
> defconfigs and I am not aware of any regressions over v4.14.40 (the
> baseline chosen when this work began).
>
>
> The following changes since commit 4d4605e5c137ed9a53582e573118cbc16b82cbf1:
>
> i2c: rcar: implement STOP and REP_START according to docs (2018-08-28
> 13:35:06 +0200)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git
> backport/v4.14.61/snapshot-to-v4.18+fixes-v2-flattened
>
> for you to fetch changes up to 720043a4efbb3356db116d084c7b877ad41ee51a:
>
> i2c: sh_mobile: fix leak when using DMA bounce buffer (2018-09-17 15:54:30
> +0200)
Thank, this all looks fine to me.
I subjected this to the same testing I do for each renesas-drivers release.
I have detected no regressions[*].
[*] The only regression I'm aware of is a regression in 4.14-stable, which can
be fixed by "tick/nohz: Prevent bogus softirq pending warning".
(https://lore.kernel.org/patchwork/patch/979451/).
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 RFT] serial: sh-sci: Add r8a77990 support
From: Hiromitsu Yamasaki This patch adds the R-Car E3 serial documentation. Signed-off-by: Hiromitsu Yamasaki Signed-off-by: Wolfram Sang --- I cannot test this. But we have other devices added for E3 meanwhile, so people surely used a console to do that? Can somebody confirm this? After that I'll send a proper patch to linux-serial list, too. Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index eaca9da79d83..0873dc043d4d 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt @@ -50,6 +50,8 @@ Required properties: - "renesas,hscif-r8a77970" for R8A77970 (R-Car V3M) HSCIF compatible UART. - "renesas,scif-r8a77980" for R8A77980 (R-Car V3H) SCIF compatible UART. - "renesas,hscif-r8a77980" for R8A77980 (R-Car V3H) HSCIF compatible UART. +- "renesas,scif-r8a77990" for R8A77990 (R-Car E3) SCIF compatible UART. +- "renesas,hscif-r8a77990" for R8A77990 (R-Car E3) HSCIF compatible UART. - "renesas,scif-r8a77995" for R8A77995 (R-Car D3) SCIF compatible UART. - "renesas,hscif-r8a77995" for R8A77995 (R-Car D3) HSCIF compatible UART. - "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART. -- 2.18.0
Re: [PATCH][RFC] PCI: rcar: Add bus notifier so we can limit the DMA range
On Tue, May 22, 2018 at 12:05:14AM +0200, Marek Vasut wrote:
> From: Phil Edworthy
>
> The PCIe DMA controller on RCar Gen2 and earlier is on 32bit bus,
> so limit the DMA range to 32bit.
>
> Signed-off-by: Phil Edworthy
> Signed-off-by: Marek Vasut
> Cc: Arnd Bergmann
> Cc: Geert Uytterhoeven
> Cc: Phil Edworthy
> Cc: Simon Horman
> Cc: Wolfram Sang
> Cc: linux-renesas-soc@vger.kernel.org
> To: linux-...@vger.kernel.org
> ---
> NOTE: I'm aware of https://patchwork.kernel.org/patch/9495895/ , but the
> discussion seems to have gone way off, so I'm sending this as a
> RFC. Any feedback on how to do this limiting properly would be nice.
> ---
> drivers/pci/host/pcie-rcar.c | 28
> 1 file changed, 28 insertions(+)
The issue solved by this patch was solved in a more generic way through
this series:
https://lists.linuxfoundation.org/pipermail/iommu/2018-July/028792.html
I will therefore drop this patch from the PCI patch queue.
Thanks,
Lorenzo
> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index c3eab0b95290..db2b16f40bc1 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -1325,3 +1325,31 @@ static struct platform_driver rcar_pcie_driver = {
> .probe = rcar_pcie_probe,
> };
> builtin_platform_driver(rcar_pcie_driver);
> +
> +static int rcar_pcie_pci_notifier(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct device *dev = data;
> +
> + switch (action) {
> + case BUS_NOTIFY_BOUND_DRIVER:
> + /* Force the DMA mask to lower 32-bits */
> + dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
> + break;
> + default:
> + return NOTIFY_DONE;
> + }
> +
> + return NOTIFY_OK;
> +}
> +
> +static struct notifier_block device_nb = {
> + .notifier_call = rcar_pcie_pci_notifier,
> +};
> +
> +static int __init register_rcar_pcie_pci_notifier(void)
> +{
> + return bus_register_notifier(_bus_type, _nb);
> +}
> +
> +arch_initcall(register_rcar_pcie_pci_notifier);
> --
> 2.16.2
>
Re: [PATCH 1/3] clk: renesas: Add r8a774c0 CPG Core Clock Definitions
On Wed, Sep 12, 2018 at 12:42 PM Fabrizio Castro
wrote:
> Add all RZ/G2E (a.k.a. R8A774C0) Clock Pulse Generator Core
> Clock Outputs, as listed in Table 8.2g ("List of Clocks
> [RZ/G2E]") of the RZ/G2 Hardware User's Manual.
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Biju Das
Reviewed-by: Geert Uytterhoeven
i.e. will queue in clk-renesas-for-v4.20.
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/3] dt-bindings: clock: renesas: cpg-mssr: Document r8a774c0
On Wed, Sep 12, 2018 at 12:42 PM Fabrizio Castro
wrote:
> This patch documents RZ/G2E (a.k.a. R8A774C0) bindings for the
> Clock Pulse Generator driver.
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Biju Das
Reviewed-by: Geert Uytterhoeven
i.e. will queue in clk-renesas-for-v4.20.
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] clocksource/drivers/ostm: Delay driver registration
Hi Chris,
CC linux-clk
On Mon, Sep 17, 2018 at 8:57 PM Chris Brandt wrote:
> On Friday, September 14, 2018, Geert Uytterhoeven wrote:
> > > Just FYI, for the heck of it, I tried and hacked in registering the
> > > clock driver using CLK_OF_DECLARE since that happens before the
> > > TIMER_OF_DECLARE timers are probed.
> > >
> > > But, I got this result:
> > >
> > > [0.00] Driver 'renesas-cpg-mssr' was unable to register with
> > bus_type 'platform' because the bus was not initialized.
> >
> > Indeed, you cannot register a platform device from CLK_OF_DECLARE().
> > Instead, you have to operate on the passed struct device_node pointer,
> > cfr. the old RZ/A1 clock driver.
>
> How about this proposal:
>
> I leave the current OSTM timer driver as it is today with
> TIMER_OF_DECLARE.
>
> But, I modify the clock driver so it registers a mini driver with
> CLK_OF_DECLARE that can enable individual HW module clocks using
> clk_register_fixed_rate. Once those modules/clocks are enabled, they are
> enabled
> forever.
>
> Also, later on when the full platform driver is probed, for any of those
> early clocks that were created, it basically ignores them.
>
>
> To use this early clock, you add this to your board's .dts file as such:
>
>
> /* Special Early CPG clocks */
> / {
> cpg_early: clock-controller@early {
> #clock-cells = <2>;
> compatible = "renesas,r7s9210-cpg-mssr-early";
> };
> };
>
> /* High resolution System tick timers */
> {
> status = "okay";
> clocks = <_early CPG_MOD 36>; /* replace .dtsi setting */
> power-domains = <_early>; /* replace .dtsi setting */
> };
> {
> status = "okay";
> clocks = <_early CPG_MOD 35>; /* replace .dtsi setting */
> power-domains = <_early>; /* replace .dtsi setting */
> };
>
>
> I've coded this up and it works fine.
While I don't doubt this works fine, your DT is no longer describing
hardware, but also software policy.
I think the proper solution, maximizing code reuse, is to:
- Split off early clocks from cpg_mssr_info.core_clks[] and .mod_clk[] into
cpg_mssr_info.early_core_clks[] and .early_mod_clks[],
- Split off early handling from cpg_mssr_probe(), to be called
a. from CLK_OF_DECLARE() in r7s9210-cpg-mssr.c, OR
b. from cpg_mssr_probe() if !cpg_mssr_info.early_core_clks.
BTW, this will also be needed for migrating other CA9-based SoCs to
renesas-cpg-mssr.c, as these don't have an ARM architectured timer,
just like RZ/A2.
Ideally (in the long term), Linux should learn to track dependencies properly,
so it initialized all components in the required order, automatically.
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] clocksource/drivers/ostm: Delay driver registration
Hi Geert, On Tuesday, September 18, 2018 1, Geert Uytterhoeven wrote: > > So I see what the mediatek is doing, but I can't seem to reproduce it. > I > > must be missing something. > > It's using CLK_OF_DECLARE_DRIVER(), which clears OF_POPULATED: Yup, that's what I was missing. Works now. Thanks! So at this point, I guess I'll move away from patching the timer driver and go back to focusing on the clock driver. Chris
RE: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration
Hi Geert, On Tuesday, September 18, 2018 1, Geert Uytterhoeven wrote: > > What do you see the .dtsi and .dts looking like? > > The part using CLK_OF_DECLARE() is not a platform driver. It does not > operate on a device (struct platform_device), but on a device node > (struct > device_node). Hence it would match against the same DT node, but map it > using of_iomap(). So you just need the existing "renesas,r7s9210-cpg- > mssr" > node. So...I tried that...and it doesn't work. Basically, this: CLK_OF_DECLARE(cpg_mstp_early_clks, "renesas,r7s9210-cpg-mssr", rza2_cpg_mssr_early_init); But, what happens is that rza2_cpg_mssr_early_init gets called because it find a match against "renesas,r7s9210-cpg-mssr". But later after cpg_mssr_init gets call, cpg_mssr_probe never gets called. I assume that is because device "renesas,r7s9210-cpg-mssr" has already been matched to a driver. > Please have a look at e.g. "mediatek,mt2712-topckgen". One thing I don't understand is that in the early init, it registers a of_clk_add_provider. But then later in the probe, it register of_clk_add_provider again (on the same DT node). I guess you can do that So I see what the mediatek is doing, but I can't seem to reproduce it. I must be missing something. Chris
Re: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration
Hi Chris,
On Tue, Sep 18, 2018 at 5:52 PM Chris Brandt wrote:
> On Tuesday, September 18, 2018 1, Geert Uytterhoeven wrote:
> > > What do you see the .dtsi and .dts looking like?
> >
> > The part using CLK_OF_DECLARE() is not a platform driver. It does not
> > operate on a device (struct platform_device), but on a device node
> > (struct
> > device_node). Hence it would match against the same DT node, but map it
> > using of_iomap(). So you just need the existing "renesas,r7s9210-cpg-
> > mssr"
> > node.
>
> So...I tried that...and it doesn't work.
>
> Basically, this:
> CLK_OF_DECLARE(cpg_mstp_early_clks, "renesas,r7s9210-cpg-mssr",
>rza2_cpg_mssr_early_init);
>
> But, what happens is that rza2_cpg_mssr_early_init gets called because
> it find a match against "renesas,r7s9210-cpg-mssr". But later after
> cpg_mssr_init gets call, cpg_mssr_probe never gets called. I assume that is
> because device "renesas,r7s9210-cpg-mssr" has already been matched to a
> driver.
>
> > Please have a look at e.g. "mediatek,mt2712-topckgen".
>
> One thing I don't understand is that in the early init, it registers a
> of_clk_add_provider. But then later in the probe, it register
> of_clk_add_provider again (on the same DT node). I guess you can do that
Yeah, I noticed that, too.
It just adds the same xlate method and data pointer to the list.
So it's harmless, but unneeded.
> So I see what the mediatek is doing, but I can't seem to reproduce it. I
> must be missing something.
It's using CLK_OF_DECLARE_DRIVER(), which clears OF_POPULATED:
/*
* Use this macro when you have a driver that requires two initialization
* routines, one at of_clk_init(), and one at platform device probe
*/
#define CLK_OF_DECLARE_DRIVER(name, compat, fn) \
static void __init name##_of_clk_init_driver(struct
device_node *np) \
{ \
of_node_clear_flag(np, OF_POPULATED); \
fn(np); \
} \
OF_DECLARE_1(clk, name, compat, name##_of_clk_init_driver)
Sorry for failing to tell you. I did know about that flag, but only remembered
due to your problem report.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH][RFC] PCI: rcar: Add bus notifier so we can limit the DMA range
On Tue, Sep 18, 2018 at 11:15:55AM +0100, Lorenzo Pieralisi wrote: > On Tue, May 22, 2018 at 12:05:14AM +0200, Marek Vasut wrote: > > From: Phil Edworthy > > > > The PCIe DMA controller on RCar Gen2 and earlier is on 32bit bus, > > so limit the DMA range to 32bit. > > > > Signed-off-by: Phil Edworthy > > Signed-off-by: Marek Vasut > > Cc: Arnd Bergmann > > Cc: Geert Uytterhoeven > > Cc: Phil Edworthy > > Cc: Simon Horman > > Cc: Wolfram Sang > > Cc: linux-renesas-soc@vger.kernel.org > > To: linux-...@vger.kernel.org > > --- > > NOTE: I'm aware of https://patchwork.kernel.org/patch/9495895/ , but the > > discussion seems to have gone way off, so I'm sending this as a > > RFC. Any feedback on how to do this limiting properly would be nice. > > --- > > drivers/pci/host/pcie-rcar.c | 28 > > 1 file changed, 28 insertions(+) > > The issue solved by this patch was solved in a more generic way through > this series: > > https://lists.linuxfoundation.org/pipermail/iommu/2018-July/028792.html > > I will therefore drop this patch from the PCI patch queue. Cool. Thanks for this series and thanks for the heads up! Marek, can you confirm our issue is fixed (if you haven't done already)? signature.asc Description: PGP signature
Re: [PATCH RFT] serial: sh-sci: Add r8a77990 support
Hi Wolfram,
On Tue, Sep 18, 2018 at 12:09 PM Wolfram Sang
wrote:
> From: Hiromitsu Yamasaki
>
> This patch adds the R-Car E3 serial documentation.
>
> Signed-off-by: Hiromitsu Yamasaki
> Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
> ---
>
> I cannot test this. But we have other devices added for E3 meanwhile, so
> people surely used a console to do that? Can somebody confirm this?
> After that I'll send a proper patch to linux-serial list, too.
SCIF is definitely working.
HSCIF0 can be muxed to the same pins as the console (SCIF2), so you
can actually test this using remote access, after upporting the pfc part ;-)
For local users: on E3, the QSPI pins (on 2.54mm headers on Ebisu) are
not single-use, but can be muxed to HSCIF, too.
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 V5] ARM: shmobile: Rework the PMIC IRQ line quirk
On 09/05/2018 01:55 PM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Mon, Jun 11, 2018 at 2:15 PM Marek Vasut wrote:
>> Rather than hard-coding the quirk topology, which stopped scaling,
>> parse the information from DT. The code looks for all compatible
>> PMICs -- da9063 and da9210 -- and checks if their IRQ line is tied
>> to the same pin. If so, the code sends a matching sequence to the
>> PMIC to deassert the IRQ.
>>
>> Signed-off-by: Marek Vasut
>> Cc: Geert Uytterhoeven
>> Cc: Kuninori Morimoto
>> Cc: Simon Horman
>> Cc: Wolfram Sang
>> Cc: linux-renesas-soc@vger.kernel.org
>> Acked-by: Wolfram Sang
>> Tested-by: Geert Uytterhoeven (on Koelsch)
>> ---
>> V2: - Replace the DT shared IRQ check loop with memcmp()
>> - Send the I2C message to deassert the IRQ line to all PMICs
>> in the list with shared IRQ line instead of just one
>> - Add comment that this works only in case all the PMICs are
>> on the same I2C bus
>> V3: - Drop the addr = 0x00 init
>> - Drop reinit of argsa in rcar_gen2_regulator_quirk
>> V4: - Squash regulator_quirk on single line
>> - Drop !np check in for_each_matching_node_and_match()
>> - Use argsa in of_irq_parse_one
>> V5: - Check kzalloc failure
>> - Rename da_msgs to da_msg
>> - Don't reinit quirk->shared
>
> Thanks for the update!
>
>> --- a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
>> +++ b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
>
>> @@ -122,7 +142,12 @@ static struct notifier_block regulator_quirk_nb = {
>>
>> static int __init rcar_gen2_regulator_quirk(void)
>> {
>> - u32 mon;
>> + struct regulator_quirk *quirk, *pos, *tmp;
>> + struct of_phandle_args *argsa, *argsb;
>> + const struct of_device_id *id;
>> + struct device_node *np;
>> + u32 mon, addr;
>> + int ret;
>>
>> if (!of_machine_is_compatible("renesas,koelsch") &&
>> !of_machine_is_compatible("renesas,lager") &&
>> @@ -130,22 +155,76 @@ static int __init rcar_gen2_regulator_quirk(void)
>> !of_machine_is_compatible("renesas,gose"))
>> return -ENODEV;
>>
>> + for_each_matching_node_and_match(np, rcar_gen2_quirk_match, ) {
>> + if (!of_device_is_available(np))
>> + break;
>> +
>> + quirk = kzalloc(sizeof(*quirk), GFP_KERNEL);
>> + if (!quirk) {
>> + ret = -ENOMEM;
>> + goto err_mem;
>> + }
>> +
>> + argsa = >irq_args;
>> + memcpy(>i2c_msg, id->data, sizeof(quirk->i2c_msg));
>> +
>> + ret = of_property_read_u32(np, "reg", );
>> + if (ret)
>> + return ret;
>
> I think it's safer to skip this entry and continue, after calling
> kfree(quirk), of course.
This can be shifted above the kzalloc() . That said, I sent V6, so
please review it one more time.
--
Best regards,
Marek Vasut
[PATCH V6] ARM: shmobile: Rework the PMIC IRQ line quirk
Rather than hard-coding the quirk topology, which stopped scaling,
parse the information from DT. The code looks for all compatible
PMICs -- da9063 and da9210 -- and checks if their IRQ line is tied
to the same pin. If so, the code sends a matching sequence to the
PMIC to deassert the IRQ.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Kuninori Morimoto
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
Acked-by: Wolfram Sang
Tested-by: Geert Uytterhoeven (on Koelsch)
---
V2: - Replace the DT shared IRQ check loop with memcmp()
- Send the I2C message to deassert the IRQ line to all PMICs
in the list with shared IRQ line instead of just one
- Add comment that this works only in case all the PMICs are
on the same I2C bus
V3: - Drop the addr = 0x00 init
- Drop reinit of argsa in rcar_gen2_regulator_quirk
V4: - Squash regulator_quirk on single line
- Drop !np check in for_each_matching_node_and_match()
- Use argsa in of_irq_parse_one
V5: - Check kzalloc failure
- Rename da_msgs to da_msg
- Don't reinit quirk->shared
V6: - Skip invalid entries instead of aborting on them
---
.../mach-shmobile/regulator-quirk-rcar-gen2.c | 139 ++
1 file changed, 110 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
index 21ebc7678ffd..8e50daa99151 100644
--- a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
@@ -23,11 +23,12 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
-
#define IRQC_BASE 0xe61c
#define IRQC_MONITOR 0x104 /* IRQn Signal Level Monitor Register */
@@ -36,34 +37,45 @@
/* start of DA9210 System Control and Event Registers */
#define DA9210_REG_MASK_A 0x54
+struct regulator_quirk {
+ struct list_headlist;
+ const struct of_device_id *id;
+ struct of_phandle_args irq_args;
+ struct i2c_msg i2c_msg;
+ boolshared; /* IRQ line is shared */
+};
+
+static LIST_HEAD(quirk_list);
static void __iomem *irqc;
/* first byte sets the memory pointer, following are consecutive reg values */
static u8 da9063_irq_clr[] = { DA9063_REG_IRQ_MASK_A, 0xff, 0xff, 0xff, 0xff };
static u8 da9210_irq_clr[] = { DA9210_REG_MASK_A, 0xff, 0xff };
-static struct i2c_msg da9xxx_msgs[3] = {
- {
- .addr = 0x58,
- .len = ARRAY_SIZE(da9063_irq_clr),
- .buf = da9063_irq_clr,
- }, {
- .addr = 0x68,
- .len = ARRAY_SIZE(da9210_irq_clr),
- .buf = da9210_irq_clr,
- }, {
- .addr = 0x70,
- .len = ARRAY_SIZE(da9210_irq_clr),
- .buf = da9210_irq_clr,
- },
+static struct i2c_msg da9063_msg = {
+ .len = ARRAY_SIZE(da9063_irq_clr),
+ .buf = da9063_irq_clr,
+};
+
+static struct i2c_msg da9210_msg = {
+ .len = ARRAY_SIZE(da9210_irq_clr),
+ .buf = da9210_irq_clr,
+};
+
+static const struct of_device_id rcar_gen2_quirk_match[] = {
+ { .compatible = "dlg,da9063", .data = _msg },
+ { .compatible = "dlg,da9210", .data = _msg },
+ {},
};
static int regulator_quirk_notify(struct notifier_block *nb,
unsigned long action, void *data)
{
+ struct regulator_quirk *pos, *tmp;
struct device *dev = data;
struct i2c_client *client;
static bool done;
+ int ret;
u32 mon;
if (done)
@@ -80,17 +92,20 @@ static int regulator_quirk_notify(struct notifier_block *nb,
client = to_i2c_client(dev);
dev_dbg(dev, "Detected %s\n", client->name);
- if ((client->addr == 0x58 && !strcmp(client->name, "da9063")) ||
- (client->addr == 0x68 && !strcmp(client->name, "da9210")) ||
- (client->addr == 0x70 && !strcmp(client->name, "da9210"))) {
- int ret, len;
+ /*
+* Send message to all PMICs that share an IRQ line to deassert it.
+*
+* WARNING: This works only if all the PMICs are on the same I2C bus.
+*/
+ list_for_each_entry(pos, _list, list) {
+ if (!pos->shared)
+ continue;
- /* There are two DA9210 on Stout, one on the other boards. */
- len = of_machine_is_compatible("renesas,stout") ? 3 : 2;
+ dev_info(>dev, "clearing %s@0x%02x interrupts\n",
+pos->id->compatible, pos->i2c_msg.addr);
- dev_info(>dev, "clearing da9063/da9210 interrupts\n");
- ret = i2c_transfer(client->adapter, da9xxx_msgs, len);
- if (ret != len)
+ ret = i2c_transfer(client->adapter, >i2c_msg, 1);
+ if (ret != 1)
Re: [PATCH 2/3] clk: renesas: cpg-mssr: Add r8a774c0 support
On Wed, Sep 12, 2018 at 12:42 PM Fabrizio Castro
wrote:
> Add RZ/G2E (R8A774C0) Clock Pulse Generator / Module Standby and
> Software Reset support.
>
> Based on Table 8.2g of "RZ/G Series, 2nd Generation User's Manual:
> Hardware (Rev. 0.61, June 12, 2018)".
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Biju Das
Reviewed-by: Geert Uytterhoeven
i.e. will queue in clk-renesas-for-v4.20.
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] clocksource/drivers/ostm: Delay driver registration
Hi Geert, On Tuesday, September 18, 2018, linux-renesas-soc-ow...@vger.kernel.org wrote: > > I've coded this up and it works fine. > > While I don't doubt this works fine, your DT is no longer describing > hardware, but also software policy. > > I think the proper solution, maximizing code reuse, is to: > - Split off early clocks from cpg_mssr_info.core_clks[] and .mod_clk[] > into > cpg_mssr_info.early_core_clks[] and .early_mod_clks[], This is where I got into trouble. I originally just tried to register all the core clocks in the early init. But then I had issues when the platform probe came in later and wanted to do the same thing. For example, the clock tree for OSTM is: EXTAL -> PLL -> P1C -> OSTM Of course there are other non-early module that use the P1C clock. Do you think it would be OK if I just registers all the core clock in early init, then just pass back the clk pointers to cpg_mssr_probe later (to let the platform driver manage them)? Chris
[PATCH 0/5] Add I2C4/DU0/QSPI0/SDHI2/USB to r8a77470
Dear All, this series adds I2C4/DU0/QSPI0/SDHI2/USB0/USB1 pin groups and functions to the RZ/G1C (a.k.a. r8a77470). Thanks, Fab Fabrizio Castro (5): pinctrl: sh-pfc: r8a77470: Add I2C4 pin groups pinctrl: sh-pfc: r8a77470: Add DU0 pin groups pinctrl: sh-pfc: r8a77470: Add QSPI0 pin groups pinctrl: sh-pfc: r8a77470: Add SDHI2 pin groups pinctrl: sh-pfc: r8a77470: Add USB pin groups drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 275 ++ 1 file changed, 275 insertions(+) -- 2.7.4
[PATCH 1/5] pinctrl: sh-pfc: r8a77470: Add I2C4 pin groups
Add I2C4 pin groups and function to the R8A77470 SoC.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
index 995c959..d4de404 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
@@ -1197,6 +1197,42 @@ static const unsigned int avb_avtp_capture_b_pins[] = {
static const unsigned int avb_avtp_capture_b_mux[] = {
AVB_AVTP_CAPTURE_B_MARK,
};
+/* - I2C4 ---
*/
+static const unsigned int i2c4_a_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(4, 10), RCAR_GP_PIN(4, 11),
+};
+static const unsigned int i2c4_a_mux[] = {
+ SCL4_A_MARK, SDA4_A_MARK,
+};
+static const unsigned int i2c4_b_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(5, 30), RCAR_GP_PIN(5, 31),
+};
+static const unsigned int i2c4_b_mux[] = {
+ SCL4_B_MARK, SDA4_B_MARK,
+};
+static const unsigned int i2c4_c_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(5, 4), RCAR_GP_PIN(5, 5),
+};
+static const unsigned int i2c4_c_mux[] = {
+ SCL4_C_MARK, SDA4_C_MARK,
+};
+static const unsigned int i2c4_d_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(2, 16), RCAR_GP_PIN(2, 17),
+};
+static const unsigned int i2c4_d_mux[] = {
+ SCL4_D_MARK, SDA4_D_MARK,
+};
+static const unsigned int i2c4_e_pins[] = {
+ /* SCL, SDA */
+ RCAR_GP_PIN(5, 7), RCAR_GP_PIN(5, 6),
+};
+static const unsigned int i2c4_e_mux[] = {
+ SCL4_E_MARK, SDA4_E_MARK,
+};
/* - MMC
*/
static const unsigned int mmc_data1_pins[] = {
/* D0 */
@@ -1487,6 +1523,11 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(avb_avtp_capture_a),
SH_PFC_PIN_GROUP(avb_avtp_match_b),
SH_PFC_PIN_GROUP(avb_avtp_capture_b),
+ SH_PFC_PIN_GROUP(i2c4_a),
+ SH_PFC_PIN_GROUP(i2c4_b),
+ SH_PFC_PIN_GROUP(i2c4_c),
+ SH_PFC_PIN_GROUP(i2c4_d),
+ SH_PFC_PIN_GROUP(i2c4_e),
SH_PFC_PIN_GROUP(mmc_data1),
SH_PFC_PIN_GROUP(mmc_data4),
SH_PFC_PIN_GROUP(mmc_data8),
@@ -1541,6 +1582,15 @@ static const char * const avb_groups[] = {
"avb_avtp_match_b",
"avb_avtp_capture_b",
};
+
+static const char * const i2c4_groups[] = {
+ "i2c4_a",
+ "i2c4_b",
+ "i2c4_c",
+ "i2c4_d",
+ "i2c4_e",
+};
+
static const char * const mmc_groups[] = {
"mmc_data1",
"mmc_data4",
@@ -1604,6 +1654,7 @@ static const char * const scif_clk_groups[] = {
static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(avb),
+ SH_PFC_FUNCTION(i2c4),
SH_PFC_FUNCTION(mmc),
SH_PFC_FUNCTION(scif0),
SH_PFC_FUNCTION(scif1),
--
2.7.4
[PATCH 3/5] pinctrl: sh-pfc: r8a77470: Add QSPI0 pin groups
Add QSPI0 pin groups and function to the R8A77470 SoC.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
index a16a010..33661f8 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
@@ -1357,6 +1357,30 @@ static const unsigned int mmc_ctrl_pins[] = {
static const unsigned int mmc_ctrl_mux[] = {
MMC0_CLK_SDHI1_CLK_MARK, MMC0_CMD_SDHI1_CMD_MARK,
};
+/* - QSPI ---
*/
+static const unsigned int qspi0_ctrl_pins[] = {
+ /* SPCLK, SSL */
+ RCAR_GP_PIN(1, 16), RCAR_GP_PIN(1, 21),
+};
+static const unsigned int qspi0_ctrl_mux[] = {
+ QSPI0_SPCLK_MARK, QSPI0_SSL_MARK,
+};
+static const unsigned int qspi0_data2_pins[] = {
+ /* MOSI_IO0, MISO_IO1 */
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+};
+static const unsigned int qspi0_data2_mux[] = {
+ QSPI0_MOSI_QSPI0_IO0_MARK, QSPI0_MISO_QSPI0_IO1_MARK,
+};
+static const unsigned int qspi0_data4_pins[] = {
+ /* MOSI_IO0, MISO_IO1, IO2, IO3 */
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18), RCAR_GP_PIN(1, 19),
+ RCAR_GP_PIN(1, 20),
+};
+static const unsigned int qspi0_data4_mux[] = {
+ QSPI0_MOSI_QSPI0_IO0_MARK, QSPI0_MISO_QSPI0_IO1_MARK,
+ QSPI0_IO2_MARK, QSPI0_IO3_MARK,
+};
/* - SCIF0 --
*/
static const unsigned int scif0_data_a_pins[] = {
/* RX, TX */
@@ -1628,6 +1652,9 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(mmc_data4),
SH_PFC_PIN_GROUP(mmc_data8),
SH_PFC_PIN_GROUP(mmc_ctrl),
+ SH_PFC_PIN_GROUP(qspi0_ctrl),
+ SH_PFC_PIN_GROUP(qspi0_data2),
+ SH_PFC_PIN_GROUP(qspi0_data4),
SH_PFC_PIN_GROUP(scif0_data_a),
SH_PFC_PIN_GROUP(scif0_data_b),
SH_PFC_PIN_GROUP(scif0_data_c),
@@ -1706,6 +1733,12 @@ static const char * const mmc_groups[] = {
"mmc_ctrl",
};
+static const char * const qspi0_groups[] = {
+ "qspi0_ctrl",
+ "qspi0_data2",
+ "qspi0_data4",
+};
+
static const char * const scif0_groups[] = {
"scif0_data_a",
"scif0_data_b",
@@ -1765,6 +1798,7 @@ static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(du0),
SH_PFC_FUNCTION(i2c4),
SH_PFC_FUNCTION(mmc),
+ SH_PFC_FUNCTION(qspi0),
SH_PFC_FUNCTION(scif0),
SH_PFC_FUNCTION(scif1),
SH_PFC_FUNCTION(scif2),
--
2.7.4
[PATCH 2/5] pinctrl: sh-pfc: r8a77470: Add DU0 pin groups
Add DU0 pin groups and function to the R8A77470 SoC.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 109 ++
1 file changed, 109 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
index d4de404..a16a010 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
@@ -1197,6 +1197,93 @@ static const unsigned int avb_avtp_capture_b_pins[] = {
static const unsigned int avb_avtp_capture_b_mux[] = {
AVB_AVTP_CAPTURE_B_MARK,
};
+/* - DU -
*/
+static const unsigned int du0_rgb666_pins[] = {
+ /* R[7:2], G[7:2], B[7:2] */
+ RCAR_GP_PIN(2, 7), RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 5),
+ RCAR_GP_PIN(2, 4), RCAR_GP_PIN(2, 3), RCAR_GP_PIN(2, 2),
+ RCAR_GP_PIN(2, 15), RCAR_GP_PIN(2, 14), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 11), RCAR_GP_PIN(2, 10),
+ RCAR_GP_PIN(2, 23), RCAR_GP_PIN(2, 22), RCAR_GP_PIN(2, 21),
+ RCAR_GP_PIN(2, 20), RCAR_GP_PIN(2, 19), RCAR_GP_PIN(2, 18),
+};
+static const unsigned int du0_rgb666_mux[] = {
+ DU0_DR7_MARK, DU0_DR6_MARK, DU0_DR5_MARK, DU0_DR4_MARK,
+ DU0_DR3_MARK, DU0_DR2_MARK,
+ DU0_DG7_MARK, DU0_DG6_MARK, DU0_DG5_MARK, DU0_DG4_MARK,
+ DU0_DG3_MARK, DU0_DG2_MARK,
+ DU0_DB7_MARK, DU0_DB6_MARK, DU0_DB5_MARK, DU0_DB4_MARK,
+ DU0_DB3_MARK, DU0_DB2_MARK,
+};
+static const unsigned int du0_rgb888_pins[] = {
+ /* R[7:0], G[7:0], B[7:0] */
+ RCAR_GP_PIN(2, 7), RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 5),
+ RCAR_GP_PIN(2, 4), RCAR_GP_PIN(2, 3), RCAR_GP_PIN(2, 2),
+ RCAR_GP_PIN(2, 1), RCAR_GP_PIN(2, 0),
+ RCAR_GP_PIN(2, 15), RCAR_GP_PIN(2, 14), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 11), RCAR_GP_PIN(2, 10),
+ RCAR_GP_PIN(2, 9), RCAR_GP_PIN(2, 8),
+ RCAR_GP_PIN(2, 23), RCAR_GP_PIN(2, 22), RCAR_GP_PIN(2, 21),
+ RCAR_GP_PIN(2, 20), RCAR_GP_PIN(2, 19), RCAR_GP_PIN(2, 18),
+ RCAR_GP_PIN(2, 17), RCAR_GP_PIN(2, 16),
+};
+static const unsigned int du0_rgb888_mux[] = {
+ DU0_DR7_MARK, DU0_DR6_MARK, DU0_DR5_MARK, DU0_DR4_MARK,
+ DU0_DR3_MARK, DU0_DR2_MARK, DU0_DR1_MARK, DU0_DR0_MARK,
+ DU0_DG7_MARK, DU0_DG6_MARK, DU0_DG5_MARK, DU0_DG4_MARK,
+ DU0_DG3_MARK, DU0_DG2_MARK, DU0_DG1_MARK, DU0_DG0_MARK,
+ DU0_DB7_MARK, DU0_DB6_MARK, DU0_DB5_MARK, DU0_DB4_MARK,
+ DU0_DB3_MARK, DU0_DB2_MARK, DU0_DB1_MARK, DU0_DB0_MARK,
+};
+static const unsigned int du0_clk0_out_pins[] = {
+ /* DOTCLKOUT0 */
+ RCAR_GP_PIN(2, 25),
+};
+static const unsigned int du0_clk0_out_mux[] = {
+ DU0_DOTCLKOUT0_MARK
+};
+static const unsigned int du0_clk1_out_pins[] = {
+ /* DOTCLKOUT1 */
+ RCAR_GP_PIN(2, 26),
+};
+static const unsigned int du0_clk1_out_mux[] = {
+ DU0_DOTCLKOUT1_MARK
+};
+static const unsigned int du0_clk_in_pins[] = {
+ /* CLKIN */
+ RCAR_GP_PIN(2, 24),
+};
+static const unsigned int du0_clk_in_mux[] = {
+ DU0_DOTCLKIN_MARK
+};
+static const unsigned int du0_sync_pins[] = {
+ /* EXVSYNC/VSYNC, EXHSYNC/HSYNC */
+ RCAR_GP_PIN(2, 28), RCAR_GP_PIN(2, 27),
+};
+static const unsigned int du0_sync_mux[] = {
+ DU0_EXVSYNC_DU0_VSYNC_MARK, DU0_EXHSYNC_DU0_HSYNC_MARK
+};
+static const unsigned int du0_oddf_pins[] = {
+ /* EXODDF/ODDF/DISP/CDE */
+ RCAR_GP_PIN(2, 29),
+};
+static const unsigned int du0_oddf_mux[] = {
+ DU0_EXODDF_DU0_ODDF_DISP_CDE_MARK,
+};
+static const unsigned int du0_cde_pins[] = {
+ /* CDE */
+ RCAR_GP_PIN(2, 31),
+};
+static const unsigned int du0_cde_mux[] = {
+ DU0_CDE_MARK,
+};
+static const unsigned int du0_disp_pins[] = {
+ /* DISP */
+ RCAR_GP_PIN(2, 30),
+};
+static const unsigned int du0_disp_mux[] = {
+ DU0_DISP_MARK
+};
/* - I2C4 ---
*/
static const unsigned int i2c4_a_pins[] = {
/* SCL, SDA */
@@ -1523,6 +1610,15 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(avb_avtp_capture_a),
SH_PFC_PIN_GROUP(avb_avtp_match_b),
SH_PFC_PIN_GROUP(avb_avtp_capture_b),
+ SH_PFC_PIN_GROUP(du0_rgb666),
+ SH_PFC_PIN_GROUP(du0_rgb888),
+ SH_PFC_PIN_GROUP(du0_clk0_out),
+ SH_PFC_PIN_GROUP(du0_clk1_out),
+ SH_PFC_PIN_GROUP(du0_clk_in),
+ SH_PFC_PIN_GROUP(du0_sync),
+ SH_PFC_PIN_GROUP(du0_oddf),
+ SH_PFC_PIN_GROUP(du0_cde),
+ SH_PFC_PIN_GROUP(du0_disp),
SH_PFC_PIN_GROUP(i2c4_a),
SH_PFC_PIN_GROUP(i2c4_b),
SH_PFC_PIN_GROUP(i2c4_c),
@@ -1583,6 +1679,18 @@ static const char * const avb_groups[] = {
"avb_avtp_capture_b",
};
+static const char * const du0_groups[] = {
+ "du0_rgb666",
+ "du0_rgb888",
+ "du0_clk0_out",
+
[PATCH 4/5] pinctrl: sh-pfc: r8a77470: Add SDHI2 pin groups
Add SDHI2 pin groups and functions to the R8A77470 SoC.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
index 33661f8..43ad702 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
@@ -1619,6 +1619,43 @@ static const unsigned int scif_clk_b_pins[] = {
static const unsigned int scif_clk_b_mux[] = {
SCIF_CLK_B_MARK,
};
+/* - SDHI2 --
*/
+static const unsigned int sdhi2_data1_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(4, 16),
+};
+static const unsigned int sdhi2_data1_mux[] = {
+ SD2_DAT0_MARK,
+};
+static const unsigned int sdhi2_data4_pins[] = {
+ /* D[0:3] */
+ RCAR_GP_PIN(4, 16), RCAR_GP_PIN(4, 17),
+ RCAR_GP_PIN(4, 18), RCAR_GP_PIN(4, 19),
+};
+static const unsigned int sdhi2_data4_mux[] = {
+ SD2_DAT0_MARK, SD2_DAT1_MARK, SD2_DAT2_MARK, SD2_DAT3_MARK,
+};
+static const unsigned int sdhi2_ctrl_pins[] = {
+ /* CLK, CMD */
+ RCAR_GP_PIN(4, 14), RCAR_GP_PIN(4, 15),
+};
+static const unsigned int sdhi2_ctrl_mux[] = {
+ SD2_CLK_MARK, SD2_CMD_MARK,
+};
+static const unsigned int sdhi2_cd_pins[] = {
+ /* CD */
+ RCAR_GP_PIN(4, 20),
+};
+static const unsigned int sdhi2_cd_mux[] = {
+ SD2_CD_MARK,
+};
+static const unsigned int sdhi2_wp_pins[] = {
+ /* WP */
+ RCAR_GP_PIN(4, 21),
+};
+static const unsigned int sdhi2_wp_mux[] = {
+ SD2_WP_MARK,
+};
static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(avb_col),
@@ -1688,6 +1725,11 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(scif5_data_f),
SH_PFC_PIN_GROUP(scif_clk_a),
SH_PFC_PIN_GROUP(scif_clk_b),
+ SH_PFC_PIN_GROUP(sdhi2_data1),
+ SH_PFC_PIN_GROUP(sdhi2_data4),
+ SH_PFC_PIN_GROUP(sdhi2_ctrl),
+ SH_PFC_PIN_GROUP(sdhi2_cd),
+ SH_PFC_PIN_GROUP(sdhi2_wp),
};
static const char * const avb_groups[] = {
@@ -1793,6 +1835,14 @@ static const char * const scif_clk_groups[] = {
"scif_clk_b",
};
+static const char * const sdhi2_groups[] = {
+ "sdhi2_data1",
+ "sdhi2_data4",
+ "sdhi2_ctrl",
+ "sdhi2_cd",
+ "sdhi2_wp",
+};
+
static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(avb),
SH_PFC_FUNCTION(du0),
@@ -1806,6 +1856,7 @@ static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(scif4),
SH_PFC_FUNCTION(scif5),
SH_PFC_FUNCTION(scif_clk),
+ SH_PFC_FUNCTION(sdhi2),
};
static const struct pinmux_cfg_reg pinmux_config_regs[] = {
--
2.7.4
[PATCH 5/5] pinctrl: sh-pfc: r8a77470: Add USB pin groups
Add USB[01] pin groups and functions to the R8A77470 SoC.
Signed-off-by: Fabrizio Castro
Reviewed-by: Biju Das
---
drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
index 43ad702..3d36e5f 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
@@ -1656,6 +1656,24 @@ static const unsigned int sdhi2_wp_pins[] = {
static const unsigned int sdhi2_wp_mux[] = {
SD2_WP_MARK,
};
+/* - USB0 ---
*/
+static const unsigned int usb0_pins[] = {
+ RCAR_GP_PIN(0, 0), /* PWEN */
+ RCAR_GP_PIN(0, 1), /* OVC */
+};
+static const unsigned int usb0_mux[] = {
+ USB0_PWEN_MARK,
+ USB0_OVC_MARK,
+};
+/* - USB1 ---
*/
+static const unsigned int usb1_pins[] = {
+ RCAR_GP_PIN(0, 2), /* PWEN */
+ RCAR_GP_PIN(0, 3), /* OVC */
+};
+static const unsigned int usb1_mux[] = {
+ USB1_PWEN_MARK,
+ USB1_OVC_MARK,
+};
static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(avb_col),
@@ -1730,6 +1748,8 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(sdhi2_ctrl),
SH_PFC_PIN_GROUP(sdhi2_cd),
SH_PFC_PIN_GROUP(sdhi2_wp),
+ SH_PFC_PIN_GROUP(usb0),
+ SH_PFC_PIN_GROUP(usb1),
};
static const char * const avb_groups[] = {
@@ -1843,6 +1863,14 @@ static const char * const sdhi2_groups[] = {
"sdhi2_wp",
};
+static const char * const usb0_groups[] = {
+ "usb0",
+};
+
+static const char * const usb1_groups[] = {
+ "usb1",
+};
+
static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(avb),
SH_PFC_FUNCTION(du0),
@@ -1857,6 +1885,8 @@ static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(scif5),
SH_PFC_FUNCTION(scif_clk),
SH_PFC_FUNCTION(sdhi2),
+ SH_PFC_FUNCTION(usb0),
+ SH_PFC_FUNCTION(usb1),
};
static const struct pinmux_cfg_reg pinmux_config_regs[] = {
--
2.7.4
Re: [PATCH V6] ARM: shmobile: Rework the PMIC IRQ line quirk
On Tue, Sep 18, 2018 at 2:23 PM Marek Vasut wrote:
> Rather than hard-coding the quirk topology, which stopped scaling,
> parse the information from DT. The code looks for all compatible
> PMICs -- da9063 and da9210 -- and checks if their IRQ line is tied
> to the same pin. If so, the code sends a matching sequence to the
> PMIC to deassert the IRQ.
>
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Kuninori Morimoto
> Cc: Simon Horman
> Cc: Wolfram Sang
> Cc: linux-renesas-soc@vger.kernel.org
> Acked-by: Wolfram Sang
> Tested-by: Geert Uytterhoeven (on Koelsch)
> ---
> V2: - Replace the DT shared IRQ check loop with memcmp()
> - Send the I2C message to deassert the IRQ line to all PMICs
> in the list with shared IRQ line instead of just one
> - Add comment that this works only in case all the PMICs are
> on the same I2C bus
> V3: - Drop the addr = 0x00 init
> - Drop reinit of argsa in rcar_gen2_regulator_quirk
> V4: - Squash regulator_quirk on single line
> - Drop !np check in for_each_matching_node_and_match()
> - Use argsa in of_irq_parse_one
> V5: - Check kzalloc failure
> - Rename da_msgs to da_msg
> - Don't reinit quirk->shared
> V6: - Skip invalid entries instead of aborting on them
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/2] clocksource/drivers/ostm: Delay driver registration
Hi Chris,
On Tue, Sep 18, 2018 at 1:55 PM Chris Brandt wrote:
> On Tuesday, September 18, 2018, linux-renesas-soc-ow...@vger.kernel.org wrote:
> > > I've coded this up and it works fine.
> >
> > While I don't doubt this works fine, your DT is no longer describing
> > hardware, but also software policy.
> >
> > I think the proper solution, maximizing code reuse, is to:
> > - Split off early clocks from cpg_mssr_info.core_clks[] and .mod_clk[]
> > into
> > cpg_mssr_info.early_core_clks[] and .early_mod_clks[],
>
> This is where I got into trouble.
> I originally just tried to register all the core clocks in the early
> init. But then I had issues when the platform probe came in later and
> wanted to do the same thing.
>
> For example, the clock tree for OSTM is:
> EXTAL -> PLL -> P1C -> OSTM
>
> Of course there are other non-early module that use the P1C clock.
>
> Do you think it would be OK if I just registers all the core clock in
> early init, then just pass back the clk pointers to cpg_mssr_probe later
> (to let the platform driver manage them)?
Just move EXTAL, PLL, and P1C from cpg_mssr_info.core_clks[] to
.early_core_clks[], and move OSTM[01] from .mod_clks[] to
.early_mod_clks[]?
Then the early init from CLK_OF_DECLARE() will just register the
early clocks, and cpg_mssr_probe() can take care of the remaining parts?
Does that make sense?
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 1/2] clocksource/drivers/ostm: Delay driver registration
Hi Geert,
On Tuesday, September 18, 2018, Geert Uytterhoeven wrote:
> Then the early init from CLK_OF_DECLARE() will just register the
> early clocks, and cpg_mssr_probe() can take care of the remaining parts?
What is not clear to me is what goes in DT
I will have this in .dtsi for cpg_mssr_probe():
cpg: clock-controller@fcfe0020 {
compatible = "renesas,r7s9210-cpg-mssr";
reg = <0xfcfe0010 0x455>; /* --- FCFE0010 - FCFE0465 */
clocks = <_clk>;
clock-names = "extal";
But, I also need /something/ for CLK_OF_DECLARE().
That means a second DT node (which means 2 different devices, 2
different drivers)
What do you see the .dtsi and .dts looking like?
Thanks,
Chris
Re: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration
Hi Chris,
On Tue, Sep 18, 2018 at 5:04 PM Chris Brandt wrote:
> On Tuesday, September 18, 2018, Geert Uytterhoeven wrote:
> > Then the early init from CLK_OF_DECLARE() will just register the
> > early clocks, and cpg_mssr_probe() can take care of the remaining parts?
>
> What is not clear to me is what goes in DT
>
> I will have this in .dtsi for cpg_mssr_probe():
>
> cpg: clock-controller@fcfe0020 {
> compatible = "renesas,r7s9210-cpg-mssr";
> reg = <0xfcfe0010 0x455>; /* --- FCFE0010 - FCFE0465
> */
> clocks = <_clk>;
> clock-names = "extal";
>
>
> But, I also need /something/ for CLK_OF_DECLARE().
> That means a second DT node (which means 2 different devices, 2
> different drivers)
>
> What do you see the .dtsi and .dts looking like?
The part using CLK_OF_DECLARE() is not a platform driver. It does not
operate on a device (struct platform_device), but on a device node (struct
device_node). Hence it would match against the same DT node, but map it
using of_iomap(). So you just need the existing "renesas,r7s9210-cpg-mssr"
node.
Please have a look at e.g. "mediatek,mt2712-topckgen".
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
