[PATCH] ARM: shmobile: Fix R-Car Gen2 regulator quirk
The quirk code currently detects all compatible I2C chips with a shared
IRQ line on all I2C busses, adds them into a list, and registers a bus
notifier. For every chip for which the bus notifier triggers, the quirk
code performs I2C transfer on that I2C bus for all addresses in the list.
The problem is that this may generate transfers to non-existing chips on
systems with multiple I2C busses.
This patch adds a check to verify that the I2C bus to which the chip with
shared IRQ is attached to matches the I2C bus of the chip which triggered
the bus notifier and only starts the I2C transfer if they match.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Kuninori Morimoto
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
index d4774d8ff997..f78e5348bd4c 100644
--- a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
@@ -40,6 +40,7 @@
struct regulator_quirk {
struct list_headlist;
const struct of_device_id *id;
+ struct device_node *np;
struct of_phandle_args irq_args;
struct i2c_msg i2c_msg;
boolshared; /* IRQ line is shared */
@@ -102,6 +103,9 @@ static int regulator_quirk_notify(struct notifier_block *nb,
if (!pos->shared)
continue;
+ if (pos->np->parent != client->dev.parent->of_node)
+ continue;
+
dev_info(>dev, "clearing %s@0x%02x interrupts\n",
pos->id->compatible, pos->i2c_msg.addr);
@@ -167,6 +171,7 @@ static int __init rcar_gen2_regulator_quirk(void)
memcpy(>i2c_msg, id->data, sizeof(quirk->i2c_msg));
quirk->id = id;
+ quirk->np = np;
quirk->i2c_msg.addr = addr;
ret = of_irq_parse_one(np, 0, argsa);
--
2.18.0
Re: [PATCH 1/2] ARM: dts: stout: Convert to new LVDS DT bindings
On 12/05/2018 06:41 AM, Laurent Pinchart wrote:
> Hi Marek,
>
> On Wednesday, 5 December 2018 03:10:18 EET Marek Vasut wrote:
>> On 12/03/2018 11:48 PM, Laurent Pinchart wrote:
>>> On Tuesday, 4 December 2018 00:24:32 EET Marek Vasut wrote:
>>>> On 12/03/2018 10:48 PM, Laurent Pinchart wrote:
>>>>> On Monday, 3 December 2018 17:12:41 EET Geert Uytterhoeven wrote:
>>>>>> 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.
>>>>>
>>>>> I can't test the patch either but it looks fine to me.
>>>>>
>>>>> Reviewed-by: Laurent Pinchart
>>>>>
>>>>> I assume you will send this directly to Simon, so I don't plan to take
>>>>> the patch in my tree.
>>>>
>>>> I have a Stout if you need me to test something.
>>>
>>> Could you test HDMI output ? We just need to ensure that everything is
>>> probed correctly, so display anything on the HDMI output will do.
>>
>> Sure, can you push me a branch somewhere, so I don't have to hunt down
>> patches ?
>
> Only this patch should be needed. You can get it from https://
> patchwork.kernel.org/patch/10709781/ and apply it on top of v4.19. Please
> don't use v4.20-rc is there's one missing regression fix there (it has been
> merged in the media tree and should make it to the final release).
On R8A7790 H2 ES3.0 Stout
Tested-by: Marek Vasut
--
Best regards,
Marek Vasut
Re: [PATCH 1/2] arm64: dts: renesas: r8a77965: Add CAN controller nodes
On 11/21/2018 08:37 AM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Wed, Nov 21, 2018 at 12:33 AM Marek Vasut wrote:
>> On 11/19/2018 10:00 AM, Geert Uytterhoeven wrote:
>>> On Mon, Nov 19, 2018 at 12:46 AM Marek Vasut wrote:
>>>> On 11/19/2018 12:02 AM, Wolfram Sang wrote:
>>>>> On Sun, Nov 18, 2018 at 06:33:26PM +0100, Marek Vasut wrote:
>>>>>> From: Takeshi Kihara
>>>>>>
>>>>>> This patch adds CAN{0,1} controller nodes for the R8A77965 SoC.
>>>>>>
>>>>>> Based on several similar patches of the R8A7795 device tree
>>>>>> by Ramesh Shanmugasundaram
>>>>>> and Geert Uytterhoeven .
>>>>>>
>>>>>> Signed-off-by: Takeshi Kihara
>>>>>> Signed-off-by: Marek Vasut
>>>>>> Cc: Geert Uytterhoeven
>>>>>> Cc: Marc Kleine-Budde
>>>>>> Cc: Rob Herring
>>>>>> Cc: Simon Horman
>>>>>> Cc: Wolfram Sang
>>>>>> Cc: linux-renesas-soc@vger.kernel.org
>>>>>> Cc: linux-arm-ker...@lists.infradead.org
>>>>>
>>>>> Were you able to do some testing using EXIO connectors? Would be nice to
>>>>> know what was tested.
>>>>
>>>> Not on the M3N, since I don't see it broken out on the EXIO ; is it
>>>> really there ? It'd be easy to test on M3NSK with KF, but I don't have
>>>> either KF or M3NSK.
>>>
>>> Please have a look at EXIO Connector D, pins 13/14/15.
>>
>> That's LBSC WE1n/WE0n/CS0n on S-XS . Is there something I obviously
>> don't see ?
>
> Unless you connect an expansion card to the Ex Memory Connector,
> these signals are free to use, and can be pinmuxed to a CAN function.
Tested-by: Marek Vasut
on M3N Salvator-XS with a rats-nest MCP2551 setup on EXIO-D and Peak
CANFD USB.
--
Best regards,
Marek Vasut
Re: [PATCH 14/14] gpio: pca953x: Restore registers after suspend/resume cycle
On 12/05/2018 03:39 PM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> 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?
Yes
--
Best regards,
Marek Vasut
Re: [PATCH] clk: vc5: Add suspend/resume support
On 12/05/2018 02:54 PM, Laurent Pinchart wrote:
> Hi Marek,
Hi,
> On Wednesday, 5 December 2018 14:29:22 EET Marek Vasut wrote:
>> On 12/05/2018 06:21 AM, Laurent Pinchart wrote:
>>> On Wednesday, 5 December 2018 01:48:01 EET Marek Vasut wrote:
>>>> On 12/04/2018 09:52 PM, Stephen Boyd wrote:
>>>>> Quoting Marek Vasut (2018-12-04 10:27:21)
>>>>>
>>>>>> diff --git a/drivers/clk/clk-versaclock5.c
>>>>>> b/drivers/clk/clk-versaclock5.c
>>>>>> index decffb3826ec..ac90fb36af1a 100644
>>>>>> --- a/drivers/clk/clk-versaclock5.c
>>>>>> +++ b/drivers/clk/clk-versaclock5.c
>>>>>> @@ -906,6 +906,39 @@ static int vc5_remove(struct i2c_client *client)
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> +#ifdef CONFIG_PM_SLEEP
>>>>>> +static int vc5_suspend(struct device *dev)
>>>>>
>>>>> Please mark as __maybe_unused and drop the #ifdef CONFIG_PM_SLEEP
>>>>>
>>>>>> +{
>>>>>> + struct vc5_driver_data *vc5 = dev_get_drvdata(dev);
>>>>>> + int ret;
>>>>>> +
>>>>>> + ret = regcache_sync(vc5->regmap);
>>>>>> + if (ret != 0) {
>>>>>> + dev_err(dev, "Failed to save register map: %d\n", ret);
>>>>>> + return ret;
>>>>>
>>>>> Do we need to block suspend if we can't save the register map away? Or
>>>>> can we just throw up our hands and not restore on resume?
>>>>
>>>> Some hardware will fail on resume, so I'd say -- yes ?
>>>
>>> But why do you need to sync on suspend in the first place ? What could
>>> cause the map to be dirty at this stage, and require syncing before
>>> suspend, that couldn't work with the sync be delayed to resume time ?
>>
>> Possibly a configuration coming from eg. bootloader time , or some other
>> configuration not done by Linux.
>
> I still don't get it. As far as I know, regcache_sync() will write the
> content
> of the regmap to the hardware, not the other way around. You call it at
> resume
> time, so the hardware should be programmed properly, regardless of what the
> boot loader or the firmware does when resuming.
>
> Could you please explain why this is needed at suspend time ?
It is not, can be dropped.
--
Best regards,
Marek Vasut
Re: [PATCH] clk: vc5: Add suspend/resume support
On 12/05/2018 06:21 AM, Laurent Pinchart wrote:
> Hi Marek,
>
> On Wednesday, 5 December 2018 01:48:01 EET Marek Vasut wrote:
>> On 12/04/2018 09:52 PM, Stephen Boyd wrote:
>>> Quoting Marek Vasut (2018-12-04 10:27:21)
>>>
>>>> diff --git a/drivers/clk/clk-versaclock5.c
>>>> b/drivers/clk/clk-versaclock5.c
>>>> index decffb3826ec..ac90fb36af1a 100644
>>>> --- a/drivers/clk/clk-versaclock5.c
>>>> +++ b/drivers/clk/clk-versaclock5.c
>>>> @@ -906,6 +906,39 @@ static int vc5_remove(struct i2c_client *client)
>>>>
>>>> return 0;
>>>>
>>>> }
>>>>
>>>> +#ifdef CONFIG_PM_SLEEP
>>>> +static int vc5_suspend(struct device *dev)
>>>
>>> Please mark as __maybe_unused and drop the #ifdef CONFIG_PM_SLEEP
>>>
>>>> +{
>>>> + struct vc5_driver_data *vc5 = dev_get_drvdata(dev);
>>>> + int ret;
>>>> +
>>>> + ret = regcache_sync(vc5->regmap);
>>>> + if (ret != 0) {
>>>> + dev_err(dev, "Failed to save register map: %d\n", ret);
>>>> + return ret;
>>>
>>> Do we need to block suspend if we can't save the register map away? Or
>>> can we just throw up our hands and not restore on resume?
>>
>> Some hardware will fail on resume, so I'd say -- yes ?
>
> But why do you need to sync on suspend in the first place ? What could cause
> the map to be dirty at this stage, and require syncing before suspend, that
> couldn't work with the sync be delayed to resume time ?
Possibly a configuration coming from eg. bootloader time , or some other
configuration not done by Linux.
--
Best regards,
Marek Vasut
Re: [PATCH] clk: vc5: Add suspend/resume support
On 12/04/2018 09:52 PM, Stephen Boyd wrote:
> Quoting Marek Vasut (2018-12-04 10:27:21)
>> diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
>> index decffb3826ec..ac90fb36af1a 100644
>> --- a/drivers/clk/clk-versaclock5.c
>> +++ b/drivers/clk/clk-versaclock5.c
>> @@ -906,6 +906,39 @@ static int vc5_remove(struct i2c_client *client)
>> return 0;
>> }
>>
>> +#ifdef CONFIG_PM_SLEEP
>> +static int vc5_suspend(struct device *dev)
>
> Please mark as __maybe_unused and drop the #ifdef CONFIG_PM_SLEEP
>
>> +{
>> + struct vc5_driver_data *vc5 = dev_get_drvdata(dev);
>> + int ret;
>> +
>> + ret = regcache_sync(vc5->regmap);
>> + if (ret != 0) {
>> + dev_err(dev, "Failed to save register map: %d\n", ret);
>> + return ret;
>
> Do we need to block suspend if we can't save the register map away? Or
> can we just throw up our hands and not restore on resume?
Some hardware will fail on resume, so I'd say -- yes ?
The rest is fixed.
>> + }
>> + regcache_cache_only(vc5->regmap, true);
>> + regcache_mark_dirty(vc5->regmap);
>> +
>> + return 0;
>> +}
>> +
>> +static int vc5_resume(struct device *dev)
>> +{
>> + struct vc5_driver_data *vc5 = dev_get_drvdata(dev);
>> + int ret;
>> +
>> + regcache_cache_only(vc5->regmap, false);
>> + ret = regcache_sync(vc5->regmap);
>> + if (ret != 0) {
>> + dev_err(dev, "Failed to restore register map: %d\n", ret);
>> + return ret;
>> + }
>
> Simplify to
>
> if (ret)
> dev_err()
> retun ret;
>
>> +
>> + return 0;
>> +}
>> +#endif
>> +
>> static const struct vc5_chip_info idt_5p49v5923_info = {
>> .model = IDT_VC5_5P49V5923,
>> .clk_fod_cnt = 2,
--
Best regards,
Marek Vasut
Re: [PATCH 1/2] ARM: dts: stout: Convert to new LVDS DT bindings
On 12/03/2018 11:48 PM, Laurent Pinchart wrote:
> Hi Marek,
>
> On Tuesday, 4 December 2018 00:24:32 EET Marek Vasut wrote:
>> On 12/03/2018 10:48 PM, Laurent Pinchart wrote:
>>> On Monday, 3 December 2018 17:12:41 EET Geert Uytterhoeven wrote:
>>>> 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.
>>>
>>> I can't test the patch either but it looks fine to me.
>>>
>>> Reviewed-by: Laurent Pinchart
>>>
>>> I assume you will send this directly to Simon, so I don't plan to take the
>>> patch in my tree.
>>
>> I have a Stout if you need me to test something.
>
> Could you test HDMI output ? We just need to ensure that everything is probed
> correctly, so display anything on the HDMI output will do.
Sure, can you push me a branch somewhere, so I don't have to hunt down
patches ?
--
Best regards,
Marek Vasut
Re: [PATCH 1/2] dt-bindings: can: rcar_canfd: document r8a77965 support
On 12/04/2018 11:56 PM, Rob Herring wrote: > On Sun, Nov 18, 2018 at 06:32:00PM +0100, Marek Vasut wrote: >> Document the support for rcar_canfd on R8A77965 SoC devices. >> >> Signed-off-by: Marek Vasut >> Cc: Eugeniu Rosca >> Cc: Geert Uytterhoeven >> Cc: Marc Kleine-Budde >> Cc: Rob Herring >> Cc: Simon Horman >> Cc: Wolfram Sang >> Cc: linux-renesas-soc@vger.kernel.org >> --- >> .../devicetree/bindings/net/can/rcar_canfd.txt | 13 +++-- >> 1 file changed, 7 insertions(+), 6 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt >> b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt >> index ac71daa46195..4720e916fbdd 100644 >> --- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt >> +++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt >> @@ -6,6 +6,7 @@ Required properties: >>- "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller. >>- "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller. >>- "renesas,r8a7796-canfd" for R8A7796 (R-Car M3-W) compatible controller. >> + - "renesas,r8a77965-canfd" for R8A77965 (R-Car M3-N) compatible >> controller. >>- "renesas,r8a77970-canfd" for R8A77970 (R-Car V3M) compatible controller. >>- "renesas,r8a77980-canfd" for R8A77980 (R-Car V3H) compatible controller. >> >> @@ -26,12 +27,12 @@ The name of the child nodes are "channel0" and >> "channel1" respectively. Each >> child node supports the "status" property only, which is used to >> enable/disable the respective channel. >> >> -Required properties for "renesas,r8a7795-canfd" and "renesas,r8a7796-canfd" >> -compatible: >> -In R8A7795 and R8A7796 SoCs, canfd clock is a div6 clock and can be used by >> both >> -CAN and CAN FD controller at the same time. It needs to be scaled to maximum >> -frequency if any of these controllers use it. This is done using the below >> -properties: >> +Required properties for "renesas,r8a7795-canfd", "renesas,r8a7796-canfd" and >> +"renesas,r8a77965-canfd" compatible: >> +In R8A7795, R8A7796 and R8A77965 SoCs, canfd clock is a div6 clock and can > > Do we have to list the SoCs twice so that the paragraph has to be > reformatted every time? Just the compatibles above should be enough. We don't , but that's about it for the SoCs that need this. >> +be used by both CAN and CAN FD controller at the same time. It needs to be >> +scaled to maximum frequency if any of these controllers use it. This is done >> +using the below properties: >> >> - assigned-clocks: phandle of canfd clock. >> - assigned-clock-rates: maximum frequency of this clock. >> -- >> 2.18.0 >> -- Best regards, Marek Vasut
[PATCH] clk: vc5: Add suspend/resume support
Add simple suspend/resume handlers to the driver to restore the chip
configuration after resume. It is possible that the chip was configured
with non-default values before suspend-resume cycle and that the chip
is powered down during this cycle, so the configuration could get lost.
Signed-off-by: Marek Vasut
Cc: Alexey Firago
Cc: Laurent Pinchart
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/clk/clk-versaclock5.c | 36 +++
1 file changed, 36 insertions(+)
diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index decffb3826ec..ac90fb36af1a 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -906,6 +906,39 @@ static int vc5_remove(struct i2c_client *client)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int vc5_suspend(struct device *dev)
+{
+ struct vc5_driver_data *vc5 = dev_get_drvdata(dev);
+ int ret;
+
+ ret = regcache_sync(vc5->regmap);
+ if (ret != 0) {
+ dev_err(dev, "Failed to save register map: %d\n", ret);
+ return ret;
+ }
+ regcache_cache_only(vc5->regmap, true);
+ regcache_mark_dirty(vc5->regmap);
+
+ return 0;
+}
+
+static int vc5_resume(struct device *dev)
+{
+ struct vc5_driver_data *vc5 = dev_get_drvdata(dev);
+ int ret;
+
+ regcache_cache_only(vc5->regmap, false);
+ ret = regcache_sync(vc5->regmap);
+ if (ret != 0) {
+ dev_err(dev, "Failed to restore register map: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
static const struct vc5_chip_info idt_5p49v5923_info = {
.model = IDT_VC5_5P49V5923,
.clk_fod_cnt = 2,
@@ -961,9 +994,12 @@ static const struct of_device_id clk_vc5_of_match[] = {
};
MODULE_DEVICE_TABLE(of, clk_vc5_of_match);
+static SIMPLE_DEV_PM_OPS(vc5_pm_ops, vc5_suspend, vc5_resume);
+
static struct i2c_driver vc5_driver = {
.driver = {
.name = "vc5",
+ .pm = _pm_ops,
.of_match_table = clk_vc5_of_match,
},
.probe = vc5_probe,
--
2.18.0
Re: [PATCH 1/2] ARM: dts: stout: Convert to new LVDS DT bindings
On 12/03/2018 10:48 PM, Laurent Pinchart wrote:
> Hi Geert,
Hi,
> Thank you for the patch.
>
> On Monday, 3 December 2018 17:12:41 EET Geert Uytterhoeven wrote:
>> 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.
>
> I can't test the patch either but it looks fine to me.
>
> Reviewed-by: Laurent Pinchart
>
> I assume you will send this directly to Simon, so I don't plan to take the
> patch in my tree.
I have a Stout if you need me to test something.
--
Best regards,
Marek Vasut
Re: [PATCH 14/14] gpio: pca953x: Restore registers after suspend/resume cycle
On 12/03/2018 06:55 PM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> 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!
Yes!
http://paste.debian.net/1054228/
> This could still be an issue in the sata_rcar driver.
I wonder if this has to do with the SATA link being cut off by the GPIO
mux at a bad time OR restored at a bad time.
--
Best regards,
Marek Vasut
Re: [PATCH 01/14] gpio: pca953x: Deduplicate the bank_size
On 12/03/2018 10:36 AM, Bartosz Golaszewski wrote: > niedz., 2 gru 2018 o 20:36 Marek Vasut napisał(a): >> >> The bank_size = fls(...) code was duplicated in the driver 5 times, >> pull it into separate function. >> > > Shouldn't it be bank_shift in the commit message? It should, fixed -- Best regards, Marek Vasut
[PATCH 13/14] gpio: pca953x: Zap single use of pca953x_read_single()
Drop pca953x_write_single() which is used in one place.
Signed-off-by: Marek Vasut
Cc: Linus Walleij
Cc: Bartosz Golaszewski
---
drivers/gpio/gpio-pca953x.c | 22 +-
1 file changed, 5 insertions(+), 17 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 8155f1dd667b..7c0122fac383 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -324,21 +324,6 @@ static u8 pca953x_recalc_addr(struct pca953x_chip *chip,
int reg, int off,
return regaddr;
}
-static int pca953x_read_single(struct pca953x_chip *chip, int reg, u32 *val,
- int off)
-{
- u8 regaddr = pca953x_recalc_addr(chip, reg, off, false, false);
- int ret;
-
- ret = regmap_read(chip->regmap, regaddr, val);
- if (ret < 0) {
- dev_err(>client->dev, "failed reading register\n");
- return ret;
- }
-
- return 0;
-}
-
static int pca953x_write_regs(struct pca953x_chip *chip, int reg, u8 *val)
{
u8 regaddr = pca953x_recalc_addr(chip, reg, 0, true, true);
@@ -408,11 +393,14 @@ static int pca953x_gpio_direction_output(struct gpio_chip
*gc,
static int pca953x_gpio_get_value(struct gpio_chip *gc, unsigned off)
{
struct pca953x_chip *chip = gpiochip_get_data(gc);
+ u8 inreg = pca953x_recalc_addr(chip, chip->regs->input, off,
+ true, false);
+ u8 bit = BIT(off % BANK_SZ);
u32 reg_val;
int ret;
mutex_lock(>i2c_lock);
- ret = pca953x_read_single(chip, chip->regs->input, _val, off);
+ ret = regmap_read(chip->regmap, inreg, _val);
mutex_unlock(>i2c_lock);
if (ret < 0) {
/* NOTE: diagnostic already emitted; that's all we should
@@ -422,7 +410,7 @@ static int pca953x_gpio_get_value(struct gpio_chip *gc,
unsigned off)
return 0;
}
- return (reg_val & (1u << (off % BANK_SZ))) ? 1 : 0;
+ return !!(reg_val & bit);
}
static void pca953x_gpio_set_value(struct gpio_chip *gc, unsigned off, int val)
--
2.18.0
[PATCH 14/14] gpio: pca953x: Restore registers after suspend/resume cycle
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
Cc: Linus Walleij
Cc: Bartosz Golaszewski
---
drivers/gpio/gpio-pca953x.c | 92 +
1 file changed, 92 insertions(+)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 7c0122fac383..e2c2e97b7321 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -972,6 +972,95 @@ static int pca953x_remove(struct i2c_client *client)
return ret;
}
+#ifdef CONFIG_PM_SLEEP
+static int pca953x_regcache_sync(struct device *dev)
+{
+ struct pca953x_chip *chip = dev_get_drvdata(dev);
+ int ret;
+
+ /*
+* The ordering between direction and output is important,
+* sync these registers first and only then sync the rest.
+*/
+ ret = regcache_sync_region(chip->regmap, chip->regs->direction,
+ chip->regs->direction + NBANK(chip));
+ if (ret != 0) {
+ dev_err(dev, "Failed to sync GPIO dir registers: %d\n", ret);
+ return ret;
+ }
+
+ ret = regcache_sync_region(chip->regmap, chip->regs->output,
+ chip->regs->output + NBANK(chip));
+ if (ret != 0) {
+ dev_err(dev, "Failed to sync GPIO out registers: %d\n", ret);
+ return ret;
+ }
+
+#ifdef CONFIG_GPIO_PCA953X_IRQ
+ if (chip->driver_data & PCA_PCAL) {
+ pca953x_write_regs(chip, PCAL953X_IN_LATCH, chip->irq_mask);
+ pca953x_write_regs(chip, PCAL953X_INT_MASK, invert_irq_mask);
+
+ ret = regcache_sync_region(chip->regmap, PCAL953X_IN_LATCH,
+ PCAL953X_IN_LATCH + NBANK(chip));
+ if (ret != 0) {
+ dev_err(dev, "Failed to sync INT latch registers: %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = regcache_sync_region(chip->regmap, PCAL953X_INT_MASK,
+ PCAL953X_INT_MASK + NBANK(chip));
+ if (ret != 0) {
+ dev_err(dev, "Failed to sync INT mask registers: %d\n",
+ ret);
+ return ret;
+ }
+ }
+#endif
+
+ return 0;
+}
+
+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);
+
+ regulator_disable(chip->regulator);
+
+ return 0;
+}
+
+static int pca953x_resume(struct device *dev)
+{
+ struct pca953x_chip *chip = dev_get_drvdata(dev);
+ int ret;
+
+ ret = regulator_enable(chip->regulator);
+ if (ret != 0) {
+ dev_err(dev, "Failed to enable regulator: %d\n", ret);
+ return 0;
+ }
+
+ regcache_cache_only(chip->regmap, false);
+ ret = pca953x_regcache_sync(dev);
+ if (ret)
+ return ret;
+
+ ret = regcache_sync(chip->regmap);
+ if (ret != 0) {
+ dev_err(dev, "Failed to restore register map: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
/* convenience to stop overlong match-table lines */
#define OF_953X(__nrgpio, __int) (void *)(__nrgpio | PCA953X_TYPE | __int)
#define OF_957X(__nrgpio, __int) (void *)(__nrgpio | PCA957X_TYPE | __int)
@@ -1015,9 +1104,12 @@ static const struct of_device_id pca953x_dt_ids[] = {
MODULE_DEVICE_TABLE(of, pca953x_dt_ids);
+static SIMPLE_DEV_PM_OPS(pca953x_pm_ops, pca953x_suspend, pca953x_resume);
+
static struct i2c_driver pca953x_driver = {
.driver = {
.name = "pca953x",
+ .pm = _pm_ops,
.of_match_table = pca953x_dt_ids,
.acpi_match_table = ACPI_PTR(pca953x_acpi_ids),
},
--
2.18.0
[PATCH 11/14] gpio: pca953x: Zap ad-hoc reg_direction cache
Replace the ad-hoc reg_direction direction register caching with generic
regcache cache. This reduces code duplication.
Signed-off-by: Marek Vasut
Cc: Linus Walleij
Cc: Bartosz Golaszewski
---
drivers/gpio/gpio-pca953x.c | 52 -
1 file changed, 28 insertions(+), 24 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 389fa891f342..a01e9f158439 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -142,7 +142,6 @@ static const struct pca953x_reg_config pca957x_regs = {
struct pca953x_chip {
unsigned gpio_start;
u8 reg_output[MAX_BANK];
- u8 reg_direction[MAX_BANK];
struct mutex i2c_lock;
struct regmap *regmap;
@@ -387,18 +386,13 @@ static int pca953x_read_regs(struct pca953x_chip *chip,
int reg, u8 *val)
static int pca953x_gpio_direction_input(struct gpio_chip *gc, unsigned off)
{
struct pca953x_chip *chip = gpiochip_get_data(gc);
- u8 reg_val;
+ u8 dirreg = pca953x_recalc_addr(chip, chip->regs->direction, off,
+ true, false);
+ u8 bit = BIT(off % BANK_SZ);
int ret;
mutex_lock(>i2c_lock);
- reg_val = chip->reg_direction[off / BANK_SZ] | (1u << (off % BANK_SZ));
-
- ret = pca953x_write_single(chip, chip->regs->direction, reg_val, off);
- if (ret)
- goto exit;
-
- chip->reg_direction[off / BANK_SZ] = reg_val;
-exit:
+ ret = regmap_write_bits(chip->regmap, dirreg, bit, bit);
mutex_unlock(>i2c_lock);
return ret;
}
@@ -407,6 +401,9 @@ static int pca953x_gpio_direction_output(struct gpio_chip
*gc,
unsigned off, int val)
{
struct pca953x_chip *chip = gpiochip_get_data(gc);
+ u8 dirreg = pca953x_recalc_addr(chip, chip->regs->direction, off,
+ true, false);
+ u8 bit = BIT(off % BANK_SZ);
u8 reg_val;
int ret;
@@ -426,12 +423,7 @@ static int pca953x_gpio_direction_output(struct gpio_chip
*gc,
chip->reg_output[off / BANK_SZ] = reg_val;
/* then direction */
- reg_val = chip->reg_direction[off / BANK_SZ] & ~(1u << (off % BANK_SZ));
- ret = pca953x_write_single(chip, chip->regs->direction, reg_val, off);
- if (ret)
- goto exit;
-
- chip->reg_direction[off / BANK_SZ] = reg_val;
+ ret = regmap_write_bits(chip->regmap, dirreg, bit, 0);
exit:
mutex_unlock(>i2c_lock);
return ret;
@@ -483,16 +475,19 @@ static void pca953x_gpio_set_value(struct gpio_chip *gc,
unsigned off, int val)
static int pca953x_gpio_get_direction(struct gpio_chip *gc, unsigned off)
{
struct pca953x_chip *chip = gpiochip_get_data(gc);
+ u8 dirreg = pca953x_recalc_addr(chip, chip->regs->direction, off,
+ true, false);
+ u8 bit = BIT(off % BANK_SZ);
u32 reg_val;
int ret;
mutex_lock(>i2c_lock);
- ret = pca953x_read_single(chip, chip->regs->direction, _val, off);
+ ret = regmap_read(chip->regmap, dirreg, _val);
mutex_unlock(>i2c_lock);
if (ret < 0)
return ret;
- return !!(reg_val & (1u << (off % BANK_SZ)));
+ return !!(reg_val & bit);
}
static void pca953x_gpio_set_multiple(struct gpio_chip *gc,
@@ -580,6 +575,9 @@ static void pca953x_irq_bus_sync_unlock(struct irq_data *d)
u8 new_irqs;
int level, i;
u8 invert_irq_mask[MAX_BANK];
+ u8 reg_direction[MAX_BANK];
+
+ regmap_read(chip->regmap, chip->regs->direction, reg_direction);
if (chip->driver_data & PCA_PCAL) {
/* Enable latch on interrupt-enabled inputs */
@@ -595,7 +593,7 @@ static void pca953x_irq_bus_sync_unlock(struct irq_data *d)
/* Look for any newly setup interrupt */
for (i = 0; i < NBANK(chip); i++) {
new_irqs = chip->irq_trig_fall[i] | chip->irq_trig_raise[i];
- new_irqs &= ~chip->reg_direction[i];
+ new_irqs &= reg_direction[i];
while (new_irqs) {
level = __ffs(new_irqs);
@@ -660,6 +658,7 @@ static bool pca953x_irq_pending(struct pca953x_chip *chip,
u8 *pending)
bool pending_seen = false;
bool trigger_seen = false;
u8 trigger[MAX_BANK];
+ u8 reg_direction[MAX_BANK];
int ret, i;
if (chip->driver_data & PCA_PCAL) {
@@ -690,8 +689,9 @@ static bool pca953x_irq_pending(struct pca953x_chip *chip,
u8 *pending)
return false;
/* Remove output pins from the equation */
+ regmap_read(chip->regmap, chip->regs->direction, reg_direction);
for (i = 0; i < NBANK(chip); i++)
- cur_stat[i
[PATCH 12/14] gpio: pca953x: Zap ad-hoc reg_output cache
Replace the ad-hoc reg_output output register caching with generic
regcache cache. Drop pca953x_write_single() which is no longer used.
This reduces code duplication.
Signed-off-by: Marek Vasut
Cc: Linus Walleij
Cc: Bartosz Golaszewski
---
drivers/gpio/gpio-pca953x.c | 65 +
1 file changed, 15 insertions(+), 50 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index a01e9f158439..8155f1dd667b 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -141,7 +141,6 @@ static const struct pca953x_reg_config pca957x_regs = {
struct pca953x_chip {
unsigned gpio_start;
- u8 reg_output[MAX_BANK];
struct mutex i2c_lock;
struct regmap *regmap;
@@ -340,21 +339,6 @@ static int pca953x_read_single(struct pca953x_chip *chip,
int reg, u32 *val,
return 0;
}
-static int pca953x_write_single(struct pca953x_chip *chip, int reg, u32 val,
- int off)
-{
- u8 regaddr = pca953x_recalc_addr(chip, reg, off, true, false);
- int ret;
-
- ret = regmap_write(chip->regmap, regaddr, val);
- if (ret < 0) {
- dev_err(>client->dev, "failed writing register\n");
- return ret;
- }
-
- return 0;
-}
-
static int pca953x_write_regs(struct pca953x_chip *chip, int reg, u8 *val)
{
u8 regaddr = pca953x_recalc_addr(chip, reg, 0, true, true);
@@ -403,25 +387,17 @@ static int pca953x_gpio_direction_output(struct gpio_chip
*gc,
struct pca953x_chip *chip = gpiochip_get_data(gc);
u8 dirreg = pca953x_recalc_addr(chip, chip->regs->direction, off,
true, false);
+ u8 outreg = pca953x_recalc_addr(chip, chip->regs->output, off,
+ true, false);
u8 bit = BIT(off % BANK_SZ);
- u8 reg_val;
int ret;
mutex_lock(>i2c_lock);
/* set output level */
- if (val)
- reg_val = chip->reg_output[off / BANK_SZ]
- | (1u << (off % BANK_SZ));
- else
- reg_val = chip->reg_output[off / BANK_SZ]
- & ~(1u << (off % BANK_SZ));
-
- ret = pca953x_write_single(chip, chip->regs->output, reg_val, off);
+ ret = regmap_write_bits(chip->regmap, outreg, bit, val ? bit : 0);
if (ret)
goto exit;
- chip->reg_output[off / BANK_SZ] = reg_val;
-
/* then direction */
ret = regmap_write_bits(chip->regmap, dirreg, bit, 0);
exit:
@@ -452,23 +428,12 @@ static int pca953x_gpio_get_value(struct gpio_chip *gc,
unsigned off)
static void pca953x_gpio_set_value(struct gpio_chip *gc, unsigned off, int val)
{
struct pca953x_chip *chip = gpiochip_get_data(gc);
- u8 reg_val;
- int ret;
+ u8 outreg = pca953x_recalc_addr(chip, chip->regs->output, off,
+ true, false);
+ u8 bit = BIT(off % BANK_SZ);
mutex_lock(>i2c_lock);
- if (val)
- reg_val = chip->reg_output[off / BANK_SZ]
- | (1u << (off % BANK_SZ));
- else
- reg_val = chip->reg_output[off / BANK_SZ]
- & ~(1u << (off % BANK_SZ));
-
- ret = pca953x_write_single(chip, chip->regs->output, reg_val, off);
- if (ret)
- goto exit;
-
- chip->reg_output[off / BANK_SZ] = reg_val;
-exit:
+ regmap_write_bits(chip->regmap, outreg, bit, val ? bit : 0);
mutex_unlock(>i2c_lock);
}
@@ -500,7 +465,10 @@ static void pca953x_gpio_set_multiple(struct gpio_chip *gc,
int ret;
mutex_lock(>i2c_lock);
- memcpy(reg_val, chip->reg_output, NBANK(chip));
+ ret = pca953x_read_regs(chip, chip->regs->output, reg_val);
+ if (ret)
+ goto exit;
+
for (bank = 0; bank < NBANK(chip); bank++) {
bank_mask = mask[bank / sizeof(*mask)] >>
((bank % sizeof(*mask)) * 8);
@@ -512,11 +480,7 @@ static void pca953x_gpio_set_multiple(struct gpio_chip *gc,
}
}
- ret = pca953x_write_regs(chip, chip->regs->output, reg_val);
- if (ret)
- goto exit;
-
- memcpy(chip->reg_output, reg_val, NBANK(chip));
+ pca953x_write_regs(chip, chip->regs->output, reg_val);
exit:
mutex_unlock(>i2c_lock);
}
@@ -815,8 +779,9 @@ static int device_pca95xx_init(struct pca953x_chip *chip,
u32 invert)
int ret;
u8 val[MAX_BANK];
- ret = pca953x_read_regs(chip, chip->regs->output, chip->reg_output);
- if (ret)
+ ret = regcache_sync_region(chip->regmap, chip->regs->output,
+ chip->regs->output + NBANK(chip));
+ if (ret != 0)
goto out;
ret = regcache_sync_region(chip->regmap, chip->regs->direction,
--
2.18.0
[PATCH 10/14] gpio: pca953x: Perform basic regmap conversion
Convert the driver to use regmap to access the chips. Due to the convoluted
register mapping scheme, implement read/write/volatile check functions that
untangle the mess and perform check accordingly. This patch does not zap the
internal register cache of the PCA953x driver, nor does it push the regmap
access down into the gpiochip accessors to simplify the review. All that is
in subsequent patches.
Signed-off-by: Marek Vasut
Cc: Linus Walleij
Cc: Bartosz Golaszewski
---
drivers/gpio/gpio-pca953x.c | 159 ++--
1 file changed, 151 insertions(+), 8 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 7e66f46b41b2..389fa891f342 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -30,6 +31,8 @@
#define PCA953X_INVERT 0x02
#define PCA953X_DIRECTION 0x03
+#define REG_ADDR_MASK 0x3f
+#define REG_ADDR_EXT 0x40
#define REG_ADDR_AI0x80
#define PCA957X_IN 0x00
@@ -141,6 +144,7 @@ struct pca953x_chip {
u8 reg_output[MAX_BANK];
u8 reg_direction[MAX_BANK];
struct mutex i2c_lock;
+ struct regmap *regmap;
#ifdef CONFIG_GPIO_PCA953X_IRQ
struct mutex irq_lock;
@@ -164,6 +168,141 @@ static int pca953x_bank_shift(struct pca953x_chip *chip)
return fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
}
+#define PCA953x_BANK_INPUT BIT(0)
+#define PCA953x_BANK_OUTPUTBIT(1)
+#define PCA953x_BANK_POLARITY BIT(2)
+#define PCA953x_BANK_CONFIGBIT(3)
+
+#define PCA957x_BANK_INPUT BIT(0)
+#define PCA957x_BANK_POLARITY BIT(1)
+#define PCA957x_BANK_BUSHOLD BIT(2)
+#define PCA957x_BANK_CONFIGBIT(4)
+#define PCA957x_BANK_OUTPUTBIT(5)
+
+#define PCAL9xxx_BANK_IN_LATCH BIT(8 + 2)
+#define PCAL9xxx_BANK_IRQ_MASK BIT(8 + 5)
+#define PCAL9xxx_BANK_IRQ_STAT BIT(8 + 6)
+
+/*
+ * We care about the following registers:
+ * - Standard set, below 0x40, each port can be replicated up to 8 times
+ * - PCA953x standard
+ * Input port 0x00 + 0 * bank_sizeR
+ * Output port 0x00 + 1 * bank_sizeRW
+ * Polarity Inversion port 0x00 + 2 * bank_sizeRW
+ * Configuration port 0x00 + 3 * bank_sizeRW
+ * - PCA957x with mixed up registers
+ * Input port 0x00 + 0 * bank_sizeR
+ * Polarity Inversion port 0x00 + 1 * bank_sizeRW
+ * Bus hold port 0x00 + 2 * bank_sizeRW
+ * Configuration port 0x00 + 4 * bank_sizeRW
+ * Output port 0x00 + 5 * bank_sizeRW
+ *
+ * - Extended set, above 0x40, often chip specific.
+ * - PCAL6524/PCAL9555A with custom PCAL IRQ handling:
+ * Input latch register0x40 + 2 * bank_sizeRW
+ * Interrupt mask register 0x40 + 5 * bank_sizeRW
+ * Interrupt status register 0x40 + 6 * bank_sizeR
+ *
+ * - Registers with bit 0x80 set, the AI bit
+ * The bit is cleared and the registers fall into one of the
+ * categories above.
+ */
+
+static bool pca953x_check_register(struct pca953x_chip *chip, unsigned int reg,
+ u32 checkbank)
+{
+ int bank_shift = pca953x_bank_shift(chip);
+ int bank = (reg & REG_ADDR_MASK) >> bank_shift;
+ int offset = reg & (BIT(bank_shift) - 1);
+
+ /* Special PCAL extended register check. */
+ if (reg & REG_ADDR_EXT) {
+ if (!(chip->driver_data & PCA_PCAL))
+ return false;
+ bank += 8;
+ }
+
+ /* Register is not in the matching bank. */
+ if (!(BIT(bank) & checkbank))
+ return false;
+
+ /* Register is not within allowed range of bank. */
+ if (offset >= NBANK(chip))
+ return false;
+
+ return true;
+}
+
+static bool pca953x_readable_register(struct device *dev, unsigned int reg)
+{
+ struct pca953x_chip *chip = dev_get_drvdata(dev);
+ u32 bank;
+
+ if (PCA_CHIP_TYPE(chip->driver_data) == PCA953X_TYPE) {
+ bank = PCA953x_BANK_INPUT | PCA953x_BANK_OUTPUT |
+ PCA953x_BANK_POLARITY | PCA953x_BANK_CONFIG;
+ } else {
+ bank = PCA957x_BANK_INPUT | PCA957x_BANK_OUTPUT |
+ PCA957x_BANK_POLARITY | PCA957x_BANK_CONFIG |
+ PCA957x_BANK_BUSHOLD;
+ }
+
+ if (chip->driver_data & PCA_PCAL) {
+ bank |= PCAL9xxx_BANK_IN_LATCH | PCAL9xxx_BANK_IRQ_MASK |
+ PCAL9xxx_BANK_IRQ_STAT;
+ }
+
+ return pca953x_check_register(chip, reg, bank);
+}
+
+static bool pca953x_writeable_register(struct device *dev, unsigned int reg)
+{
+ struct pca953x_chip *
[PATCH 09/14] gpio: pca953x: Extract the register address mangling to single function
Instead of having the I2C register calculation function spread across
multiple accessor functions, pull it out into a single function which
returns the adjusted register address.
Signed-off-by: Marek Vasut
Cc: Linus Walleij
Cc: Bartosz Golaszewski
---
drivers/gpio/gpio-pca953x.c | 59 ++---
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index b3386819c550..7e66f46b41b2 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -164,17 +164,37 @@ static int pca953x_bank_shift(struct pca953x_chip *chip)
return fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
}
+static u8 pca953x_recalc_addr(struct pca953x_chip *chip, int reg, int off,
+ bool write, bool addrinc)
+{
+ int bank_shift = pca953x_bank_shift(chip);
+ int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
+ int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
+ u8 regaddr = pinctrl | addr | (off / BANK_SZ);
+
+ /* Single byte read doesn't need AI bit set. */
+ if (!addrinc)
+ return regaddr;
+
+ /* Chips with 24 and more GPIOs always support Auto Increment */
+ if (write && NBANK(chip) > 2)
+ regaddr |= REG_ADDR_AI;
+
+ /* PCA9575 needs address-increment on multi-byte writes */
+ if (PCA_CHIP_TYPE(chip->driver_data) == PCA957X_TYPE)
+ regaddr |= REG_ADDR_AI;
+
+ return regaddr;
+}
+
static int pca953x_read_single(struct pca953x_chip *chip, int reg, u32 *val,
int off)
{
+ u8 regaddr = pca953x_recalc_addr(chip, reg, off, false, false);
int ret;
- int bank_shift = pca953x_bank_shift(chip);
- int offset = off / BANK_SZ;
- ret = i2c_smbus_read_byte_data(chip->client,
- (reg << bank_shift) + offset);
+ ret = i2c_smbus_read_byte_data(chip->client, regaddr);
*val = ret;
-
if (ret < 0) {
dev_err(>client->dev, "failed reading register\n");
return ret;
@@ -186,13 +206,10 @@ static int pca953x_read_single(struct pca953x_chip *chip,
int reg, u32 *val,
static int pca953x_write_single(struct pca953x_chip *chip, int reg, u32 val,
int off)
{
+ u8 regaddr = pca953x_recalc_addr(chip, reg, off, true, false);
int ret;
- int bank_shift = pca953x_bank_shift(chip);
- int offset = off / BANK_SZ;
-
- ret = i2c_smbus_write_byte_data(chip->client,
- (reg << bank_shift) + offset, val);
+ ret = i2c_smbus_write_byte_data(chip->client, regaddr, val);
if (ret < 0) {
dev_err(>client->dev, "failed writing register\n");
return ret;
@@ -203,20 +220,9 @@ static int pca953x_write_single(struct pca953x_chip *chip,
int reg, u32 val,
static int pca953x_write_regs(struct pca953x_chip *chip, int reg, u8 *val)
{
- int bank_shift = pca953x_bank_shift(chip);
- int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
- int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
- u8 regaddr = pinctrl | addr;
+ u8 regaddr = pca953x_recalc_addr(chip, reg, 0, true, true);
int ret;
- /* Chips with 24 and more GPIOs always support Auto Increment */
- if (NBANK(chip) > 2)
- regaddr |= REG_ADDR_AI;
-
- /* PCA9575 needs address-increment on multi-byte writes */
- if (PCA_CHIP_TYPE(chip->driver_data) == PCA957X_TYPE)
- regaddr |= REG_ADDR_AI;
-
ret = i2c_smbus_write_i2c_block_data(chip->client, regaddr,
NBANK(chip), val);
if (ret < 0) {
@@ -229,16 +235,9 @@ static int pca953x_write_regs(struct pca953x_chip *chip,
int reg, u8 *val)
static int pca953x_read_regs(struct pca953x_chip *chip, int reg, u8 *val)
{
- int bank_shift = pca953x_bank_shift(chip);
- int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
- int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
- u8 regaddr = pinctrl | addr;
+ u8 regaddr = pca953x_recalc_addr(chip, reg, 0, false, true);
int ret;
- /* Chips with 24 and more GPIOs always support Auto Increment */
- if (NBANK(chip) > 2)
- regaddr |= REG_ADDR_AI;
-
ret = i2c_smbus_read_i2c_block_data(chip->client, regaddr,
NBANK(chip), val);
if (ret < 0) {
--
2.18.0
[PATCH 01/14] gpio: pca953x: Deduplicate the bank_size
The bank_size = fls(...) code was duplicated in the driver 5 times,
pull it into separate function.
Signed-off-by: Marek Vasut
Cc: Linus Walleij
Cc: Bartosz Golaszewski
---
drivers/gpio/gpio-pca953x.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 023a32cfac42..31e3b1b52330 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -159,11 +159,16 @@ struct pca953x_chip {
int (*read_regs)(struct pca953x_chip *, int, u8 *);
};
+static int pca953x_bank_shift(struct pca953x_chip *chip)
+{
+ return fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
+}
+
static int pca953x_read_single(struct pca953x_chip *chip, int reg, u32 *val,
int off)
{
int ret;
- int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
+ int bank_shift = pca953x_bank_shift(chip);
int offset = off / BANK_SZ;
ret = i2c_smbus_read_byte_data(chip->client,
@@ -182,7 +187,7 @@ static int pca953x_write_single(struct pca953x_chip *chip,
int reg, u32 val,
int off)
{
int ret;
- int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
+ int bank_shift = pca953x_bank_shift(chip);
int offset = off / BANK_SZ;
ret = i2c_smbus_write_byte_data(chip->client,
@@ -221,7 +226,7 @@ static int pca957x_write_regs_16(struct pca953x_chip *chip,
int reg, u8 *val)
static int pca953x_write_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
{
- int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
+ int bank_shift = pca953x_bank_shift(chip);
int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
@@ -265,7 +270,7 @@ static int pca953x_read_regs_16(struct pca953x_chip *chip,
int reg, u8 *val)
static int pca953x_read_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
{
- int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
+ int bank_shift = pca953x_bank_shift(chip);
int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
@@ -402,13 +407,12 @@ static void pca953x_gpio_set_multiple(struct gpio_chip
*gc,
unsigned long *mask, unsigned long *bits)
{
struct pca953x_chip *chip = gpiochip_get_data(gc);
+ int bank_shift = pca953x_bank_shift(chip);
unsigned int bank_mask, bank_val;
- int bank_shift, bank;
+ int bank;
u8 reg_val[MAX_BANK];
int ret;
- bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
-
mutex_lock(>i2c_lock);
memcpy(reg_val, chip->reg_output, NBANK(chip));
for (bank = 0; bank < NBANK(chip); bank++) {
--
2.18.0
[PATCH 04/14] gpio: pca953x: Unify pca95{3,7}x_write_regs_16()
At this point, these two functions only differ in whether they do or do not
set the address increment bit on PCA9575. Merge these two functions together
to simplify the code a bit.
Signed-off-by: Marek Vasut
Cc: Linus Walleij
Cc: Bartosz Golaszewski
---
drivers/gpio/gpio-pca953x.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 479fa376bd18..2e02b3a9ac48 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -208,14 +208,11 @@ static int pca953x_write_regs_8(struct pca953x_chip
*chip, int reg, u8 *val)
static int pca953x_write_regs_16(struct pca953x_chip *chip, int reg, u8 *val)
{
- u16 word = get_unaligned((u16 *)val);
+ u32 regaddr = (reg << 1);
- return i2c_smbus_write_word_data(chip->client, reg << 1, word);
-}
-
-static int pca957x_write_regs_16(struct pca953x_chip *chip, int reg, u8 *val)
-{
- u32 regaddr = (reg << 1) | REG_ADDR_AI;
+ /* PCA9575 needs address-increment on multi-byte writes */
+ if (PCA_CHIP_TYPE(chip->driver_data) == PCA957X_TYPE)
+ regaddr |= REG_ADDR_AI;
return i2c_smbus_write_i2c_block_data(chip->client, regaddr,
NBANK(chip), val);
@@ -892,10 +889,7 @@ static int pca953x_probe(struct i2c_client *client,
chip->write_regs = pca953x_write_regs_24;
chip->read_regs = pca953x_read_regs_24;
} else {
- if (PCA_CHIP_TYPE(chip->driver_data) == PCA953X_TYPE)
- chip->write_regs = pca953x_write_regs_16;
- else
- chip->write_regs = pca957x_write_regs_16;
+ chip->write_regs = pca953x_write_regs_16;
chip->read_regs = pca953x_read_regs_16;
}
--
2.18.0
[PATCH 06/14] gpio: pca953x: Unify pca953x_{read,write}_regs_{8,mul}()
At this point, the pca953x_{read,write}_regs_mul() can read single bank
PCA953x GPIO chips as well. Merge the _8 and _mul functions together to
simplify the code a bit.
Signed-off-by: Marek Vasut
Cc: Linus Walleij
Cc: Bartosz Golaszewski
---
drivers/gpio/gpio-pca953x.c | 54 ++---
1 file changed, 8 insertions(+), 46 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 551fa69661b2..09fd8cde9ca9 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -154,9 +154,6 @@ struct pca953x_chip {
struct regulator *regulator;
const struct pca953x_reg_config *regs;
-
- int (*write_regs)(struct pca953x_chip *, int, u8 *);
- int (*read_regs)(struct pca953x_chip *, int, u8 *);
};
static int pca953x_bank_shift(struct pca953x_chip *chip)
@@ -201,17 +198,13 @@ static int pca953x_write_single(struct pca953x_chip
*chip, int reg, u32 val,
return 0;
}
-static int pca953x_write_regs_8(struct pca953x_chip *chip, int reg, u8 *val)
-{
- return i2c_smbus_write_byte_data(chip->client, reg, *val);
-}
-
-static int pca953x_write_regs_mul(struct pca953x_chip *chip, int reg, u8 *val)
+static int pca953x_write_regs(struct pca953x_chip *chip, int reg, u8 *val)
{
int bank_shift = pca953x_bank_shift(chip);
int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
u8 regaddr = pinctrl | addr;
+ int ret;
/* Chips with 24 and more GPIOs always support Auto Increment */
if (NBANK(chip) > 2)
@@ -221,15 +214,8 @@ static int pca953x_write_regs_mul(struct pca953x_chip
*chip, int reg, u8 *val)
if (PCA_CHIP_TYPE(chip->driver_data) == PCA957X_TYPE)
regaddr |= REG_ADDR_AI;
- return i2c_smbus_write_i2c_block_data(chip->client, regaddr,
- NBANK(chip), val);
-}
-
-static int pca953x_write_regs(struct pca953x_chip *chip, int reg, u8 *val)
-{
- int ret = 0;
-
- ret = chip->write_regs(chip, reg, val);
+ ret = i2c_smbus_write_i2c_block_data(chip->client, regaddr,
+NBANK(chip), val);
if (ret < 0) {
dev_err(>client->dev, "failed writing register\n");
return ret;
@@ -238,36 +224,20 @@ static int pca953x_write_regs(struct pca953x_chip *chip,
int reg, u8 *val)
return 0;
}
-static int pca953x_read_regs_8(struct pca953x_chip *chip, int reg, u8 *val)
-{
- int ret;
-
- ret = i2c_smbus_read_byte_data(chip->client, reg);
- *val = ret;
-
- return ret;
-}
-
-static int pca953x_read_regs_mul(struct pca953x_chip *chip, int reg, u8 *val)
+static int pca953x_read_regs(struct pca953x_chip *chip, int reg, u8 *val)
{
int bank_shift = pca953x_bank_shift(chip);
int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
u8 regaddr = pinctrl | addr;
+ int ret;
/* Chips with 24 and more GPIOs always support Auto Increment */
if (NBANK(chip) > 2)
regaddr |= REG_ADDR_AI;
- return i2c_smbus_read_i2c_block_data(chip->client, regaddr,
-NBANK(chip), val);
-}
-
-static int pca953x_read_regs(struct pca953x_chip *chip, int reg, u8 *val)
-{
- int ret;
-
- ret = chip->read_regs(chip, reg, val);
+ ret = i2c_smbus_read_i2c_block_data(chip->client, regaddr,
+ NBANK(chip), val);
if (ret < 0) {
dev_err(>client->dev, "failed reading register\n");
return ret;
@@ -872,14 +842,6 @@ static int pca953x_probe(struct i2c_client *client,
*/
pca953x_setup_gpio(chip, chip->driver_data & PCA_GPIO_MASK);
- if (chip->gpio_chip.ngpio <= 8) {
- chip->write_regs = pca953x_write_regs_8;
- chip->read_regs = pca953x_read_regs_8;
- } else {
- chip->write_regs = pca953x_write_regs_mul;
- chip->read_regs = pca953x_read_regs_mul;
- }
-
if (PCA_CHIP_TYPE(chip->driver_data) == PCA953X_TYPE)
ret = device_pca953x_init(chip, invert);
else
--
2.18.0
[PATCH 02/14] gpio: pca953x: Fix AI overflow on PCAL6524
The PCAL_PINCTRL_MASK is too large. The extended register block on PCAL6524, which is the largest chip with this block, has the block limited to address range 0x40..0x7f. This is because the bit 7 in the command register is used for the Address Increment functionality. Trim the mask to 0x60 to match the datasheet and to prevent accidental overwrite of the AI bit. Signed-off-by: Marek Vasut Cc: Linus Walleij Cc: Bartosz Golaszewski --- drivers/gpio/gpio-pca953x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c index 31e3b1b52330..4e9c79ca69c5 100644 --- a/drivers/gpio/gpio-pca953x.c +++ b/drivers/gpio/gpio-pca953x.c @@ -58,7 +58,7 @@ #define PCA_GPIO_MASK 0x00FF #define PCAL_GPIO_MASK 0x1f -#define PCAL_PINCTRL_MASK 0xe0 +#define PCAL_PINCTRL_MASK 0x60 #define PCA_INT0x0100 #define PCA_PCAL 0x0200 -- 2.18.0
[PATCH 05/14] gpio: pca953x: Unify pca953x_{read,write}_regs_{16,24}()
At this point, these two functions only differ in whether they do or do not
set the address increment bit. The 16 GPIO case does not need to set the AI
bit, except for PCA9575 on write, while the 24 GPIO and more case does set
the AI bit always. Merge these two functions together to simplify the code
a bit.
Signed-off-by: Marek Vasut
Cc: Linus Walleij
Cc: Bartosz Golaszewski
---
drivers/gpio/gpio-pca953x.c | 49 ++---
1 file changed, 18 insertions(+), 31 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 2e02b3a9ac48..551fa69661b2 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -206,9 +206,16 @@ static int pca953x_write_regs_8(struct pca953x_chip *chip,
int reg, u8 *val)
return i2c_smbus_write_byte_data(chip->client, reg, *val);
}
-static int pca953x_write_regs_16(struct pca953x_chip *chip, int reg, u8 *val)
+static int pca953x_write_regs_mul(struct pca953x_chip *chip, int reg, u8 *val)
{
- u32 regaddr = (reg << 1);
+ int bank_shift = pca953x_bank_shift(chip);
+ int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
+ int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
+ u8 regaddr = pinctrl | addr;
+
+ /* Chips with 24 and more GPIOs always support Auto Increment */
+ if (NBANK(chip) > 2)
+ regaddr |= REG_ADDR_AI;
/* PCA9575 needs address-increment on multi-byte writes */
if (PCA_CHIP_TYPE(chip->driver_data) == PCA957X_TYPE)
@@ -218,17 +225,6 @@ static int pca953x_write_regs_16(struct pca953x_chip
*chip, int reg, u8 *val)
NBANK(chip), val);
}
-static int pca953x_write_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
-{
- int bank_shift = pca953x_bank_shift(chip);
- int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
- int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
-
- return i2c_smbus_write_i2c_block_data(chip->client,
- pinctrl | addr | REG_ADDR_AI,
- NBANK(chip), val);
-}
-
static int pca953x_write_regs(struct pca953x_chip *chip, int reg, u8 *val)
{
int ret = 0;
@@ -252,24 +248,18 @@ static int pca953x_read_regs_8(struct pca953x_chip *chip,
int reg, u8 *val)
return ret;
}
-static int pca953x_read_regs_16(struct pca953x_chip *chip, int reg, u8 *val)
-{
- int ret;
-
- ret = i2c_smbus_read_word_data(chip->client, reg << 1);
- put_unaligned(ret, (u16 *)val);
-
- return ret;
-}
-
-static int pca953x_read_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
+static int pca953x_read_regs_mul(struct pca953x_chip *chip, int reg, u8 *val)
{
int bank_shift = pca953x_bank_shift(chip);
int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
+ u8 regaddr = pinctrl | addr;
+
+ /* Chips with 24 and more GPIOs always support Auto Increment */
+ if (NBANK(chip) > 2)
+ regaddr |= REG_ADDR_AI;
- return i2c_smbus_read_i2c_block_data(chip->client,
-pinctrl | addr | REG_ADDR_AI,
+ return i2c_smbus_read_i2c_block_data(chip->client, regaddr,
NBANK(chip), val);
}
@@ -885,12 +875,9 @@ static int pca953x_probe(struct i2c_client *client,
if (chip->gpio_chip.ngpio <= 8) {
chip->write_regs = pca953x_write_regs_8;
chip->read_regs = pca953x_read_regs_8;
- } else if (chip->gpio_chip.ngpio >= 24) {
- chip->write_regs = pca953x_write_regs_24;
- chip->read_regs = pca953x_read_regs_24;
} else {
- chip->write_regs = pca953x_write_regs_16;
- chip->read_regs = pca953x_read_regs_16;
+ chip->write_regs = pca953x_write_regs_mul;
+ chip->read_regs = pca953x_read_regs_mul;
}
if (PCA_CHIP_TYPE(chip->driver_data) == PCA953X_TYPE)
--
2.18.0
[PATCH 07/14] gpio: pca953x: Factor out common code from device_pca95xx_init()
The PCA957x and PCA953x init functions are almost the same, except for
the different register mapping and one extra write to BKEN register in
case of PCA957x. Factor out the common code.
Signed-off-by: Marek Vasut
Cc: Linus Walleij
Cc: Bartosz Golaszewski
---
drivers/gpio/gpio-pca953x.c | 35 ---
1 file changed, 12 insertions(+), 23 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 09fd8cde9ca9..dc691bd52a79 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -119,18 +119,21 @@ struct pca953x_reg_config {
int direction;
int output;
int input;
+ int invert;
};
static const struct pca953x_reg_config pca953x_regs = {
.direction = PCA953X_DIRECTION,
.output = PCA953X_OUTPUT,
.input = PCA953X_INPUT,
+ .invert = PCA953X_INVERT,
};
static const struct pca953x_reg_config pca957x_regs = {
.direction = PCA957X_CFG,
.output = PCA957X_OUT,
.input = PCA957X_IN,
+ .invert = PCA957X_INVRT,
};
struct pca953x_chip {
@@ -679,13 +682,11 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
}
#endif
-static int device_pca953x_init(struct pca953x_chip *chip, u32 invert)
+static int device_pca95xx_init(struct pca953x_chip *chip, u32 invert)
{
int ret;
u8 val[MAX_BANK];
- chip->regs = _regs;
-
ret = pca953x_read_regs(chip, chip->regs->output, chip->reg_output);
if (ret)
goto out;
@@ -701,7 +702,7 @@ static int device_pca953x_init(struct pca953x_chip *chip,
u32 invert)
else
memset(val, 0, NBANK(chip));
- ret = pca953x_write_regs(chip, PCA953X_INVERT, val);
+ ret = pca953x_write_regs(chip, chip->regs->invert, val);
out:
return ret;
}
@@ -711,22 +712,7 @@ static int device_pca957x_init(struct pca953x_chip *chip,
u32 invert)
int ret;
u8 val[MAX_BANK];
- chip->regs = _regs;
-
- ret = pca953x_read_regs(chip, chip->regs->output, chip->reg_output);
- if (ret)
- goto out;
- ret = pca953x_read_regs(chip, chip->regs->direction,
- chip->reg_direction);
- if (ret)
- goto out;
-
- /* set platform specific polarity inversion */
- if (invert)
- memset(val, 0xFF, NBANK(chip));
- else
- memset(val, 0, NBANK(chip));
- ret = pca953x_write_regs(chip, PCA957X_INVRT, val);
+ ret = device_pca95xx_init(chip, invert);
if (ret)
goto out;
@@ -842,10 +828,13 @@ static int pca953x_probe(struct i2c_client *client,
*/
pca953x_setup_gpio(chip, chip->driver_data & PCA_GPIO_MASK);
- if (PCA_CHIP_TYPE(chip->driver_data) == PCA953X_TYPE)
- ret = device_pca953x_init(chip, invert);
- else
+ if (PCA_CHIP_TYPE(chip->driver_data) == PCA953X_TYPE) {
+ chip->regs = _regs;
+ ret = device_pca95xx_init(chip, invert);
+ } else {
+ chip->regs = _regs;
ret = device_pca957x_init(chip, invert);
+ }
if (ret)
goto err_exit;
--
2.18.0
[PATCH 03/14] gpio: pca953x: Repair multi-byte IO address increment on PCA9575
The multi-byte IO on various pca953x chips requires the auto-increment bit,
while other chips toggle the LSbit automatically. Note that LSbit toggling
only alternates between two registers during the IO, it is not the same as
address auto-increment. The driver currently assumes that #gpios > 16 implies
auto-increment, while #gpios <= 16 implies LSbit toggling. This is incorrect
at there are chips with 16 GPIOs which require the auto-increment bit.
The PCA9575, according to NXP datasheet rev. 4.2 from 16 April 2015, section
7.3 Command Register, the bit 7 in command register is the auto-increment
bit, which allows programming multiple registers sequentially.
Set this bit both in pca953x_gpio_set_multiple(), where it fixes the multi
register programming, and in pca957x_write_regs_16(), where is simplifies
the function. In fact, the pca957x_write_regs_16() now looks rather similar
to pca953x_write_regs_24() and pca953x_write_regs_16(), which is intended
for subsequent patches.
Signed-off-by: Marek Vasut
Cc: Linus Walleij
Cc: Bartosz Golaszewski
---
drivers/gpio/gpio-pca953x.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 4e9c79ca69c5..479fa376bd18 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -215,13 +215,10 @@ static int pca953x_write_regs_16(struct pca953x_chip
*chip, int reg, u8 *val)
static int pca957x_write_regs_16(struct pca953x_chip *chip, int reg, u8 *val)
{
- int ret;
-
- ret = i2c_smbus_write_byte_data(chip->client, reg << 1, val[0]);
- if (ret < 0)
- return ret;
+ u32 regaddr = (reg << 1) | REG_ADDR_AI;
- return i2c_smbus_write_byte_data(chip->client, (reg << 1) + 1, val[1]);
+ return i2c_smbus_write_i2c_block_data(chip->client, regaddr,
+ NBANK(chip), val);
}
static int pca953x_write_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
@@ -408,6 +405,7 @@ static void pca953x_gpio_set_multiple(struct gpio_chip *gc,
{
struct pca953x_chip *chip = gpiochip_get_data(gc);
int bank_shift = pca953x_bank_shift(chip);
+ u32 regaddr = chip->regs->output << bank_shift;
unsigned int bank_mask, bank_val;
int bank;
u8 reg_val[MAX_BANK];
@@ -426,8 +424,13 @@ static void pca953x_gpio_set_multiple(struct gpio_chip *gc,
}
}
- ret = i2c_smbus_write_i2c_block_data(chip->client,
-chip->regs->output << bank_shift,
+ /* PCA9575 needs address-increment on multi-byte writes */
+ if ((PCA_CHIP_TYPE(chip->driver_data) == PCA957X_TYPE) &&
+ (NBANK(chip) > 1)) {
+ regaddr |= REG_ADDR_AI;
+ }
+
+ ret = i2c_smbus_write_i2c_block_data(chip->client, regaddr,
NBANK(chip), reg_val);
if (ret)
goto exit;
--
2.18.0
[PATCH 08/14] gpio: pca953x: Zap ad-hoc I2C block write in multi GPIO set
The ad-hoc i2c block write can be replaced by standard register accessor
function, which correctly handles all the chip details and differences.
Do so to simplify the code.
Signed-off-by: Marek Vasut
Cc: Linus Walleij
Cc: Bartosz Golaszewski
---
drivers/gpio/gpio-pca953x.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index dc691bd52a79..b3386819c550 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -364,8 +364,6 @@ static void pca953x_gpio_set_multiple(struct gpio_chip *gc,
unsigned long *mask, unsigned long *bits)
{
struct pca953x_chip *chip = gpiochip_get_data(gc);
- int bank_shift = pca953x_bank_shift(chip);
- u32 regaddr = chip->regs->output << bank_shift;
unsigned int bank_mask, bank_val;
int bank;
u8 reg_val[MAX_BANK];
@@ -384,14 +382,7 @@ static void pca953x_gpio_set_multiple(struct gpio_chip *gc,
}
}
- /* PCA9575 needs address-increment on multi-byte writes */
- if ((PCA_CHIP_TYPE(chip->driver_data) == PCA957X_TYPE) &&
- (NBANK(chip) > 1)) {
- regaddr |= REG_ADDR_AI;
- }
-
- ret = i2c_smbus_write_i2c_block_data(chip->client, regaddr,
-NBANK(chip), reg_val);
+ ret = pca953x_write_regs(chip, chip->regs->output, reg_val);
if (ret)
goto exit;
--
2.18.0
Re: [PATCH 4/4] pinctrl: sh-pfc: r8a77990: Add CAN FD pins, groups and functions
On 11/21/2018 08:39 AM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Wed, Nov 21, 2018 at 12:33 AM Marek Vasut wrote:
>> On 11/19/2018 10:47 AM, Geert Uytterhoeven wrote:
>>> On Mon, Nov 19, 2018 at 10:06 AM Geert Uytterhoeven
>>> wrote:
>>>> On Sun, Nov 18, 2018 at 6:29 PM Marek Vasut wrote:
>>>>> From: Takeshi Kihara
>>>>>
>>>>> This patch adds CAN FD{0,1} pins, groups and functions to the R8A77990
>>>>> SoC.
>>>>>
>>>>> Signed-off-by: Takeshi Kihara
>>>>> Signed-off-by: Marek Vasut
>>>>
>>>> Reviewed-by: Geert Uytterhoeven
>>>> i.e. will queue in sh-pfc-for-v4.21.
>>>
>>> Upon second look, the canfd groups and functions should be moved from
>>> the common to the automotive section, as RZ/G2E does not have them.
>>> As I have to update the array sizes anyway (my branch already has more
>>> patches applied), I moved them while applying.
>>>
>>> Please check the result later today, after I have pushed.
>>
>> Looks OK to me. Incrementing the array sizes in the driver is kinda icky
>
> Thanks!
>
>> though.
>
> Unfortunately I see no way to avoid that, as both arrays need to be
> consecutive
> in memory. Do you see a better solution?
U-Boot uses linker-generated lists , but I think this might be an
overkill here.
--
Best regards,
Marek Vasut
Re: [PATCH 2/2] arm64: dts: renesas: r8a77965: Add CAN FD controller node
On 11/19/2018 11:44 AM, Simon Horman wrote: > On Mon, Nov 19, 2018 at 12:29:37AM +0100, Marek Vasut wrote: >> On 11/19/2018 12:10 AM, Wolfram Sang wrote: >>> On Sun, Nov 18, 2018 at 06:33:27PM +0100, Marek Vasut wrote: >>>> From: Takeshi Kihara >>>> >>>> This patch adds CAN FD controller nodes for the R8A77965 SoC. >>>> >>>> Signed-off-by: Takeshi Kihara >>>> Signed-off-by: Marek Vasut >>>> Cc: Geert Uytterhoeven >>>> Cc: Marc Kleine-Budde >>>> Cc: Rob Herring >>>> Cc: Simon Horman >>>> Cc: Wolfram Sang >>>> Cc: linux-renesas-soc@vger.kernel.org >>>> Cc: linux-arm-ker...@lists.infradead.org >>> >>> Why seperate patches for CAN and CANFD here while they are merged for >>> r8a77990 into one patch? >> >> Because they are two different IP blocks, but I can merge the patches >> together if that's what you want. > > Merging these patches makes sense to me. Done -- Best regards, Marek Vasut
Re: [PATCH V3] arm64: dts: r8a77990: ebisu: Add and enable SDHI device nodes
On 11/20/2018 11:16 AM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Tue, Nov 6, 2018 at 9:46 PM Marek Vasut wrote:
>> From: Takeshi Kihara
>>
>> This patch adds SDHI{0,1,3} device nodes for the r8a77990 SoC
>> and enables SD card slot connected to SDHI0, micro SD card slot
>> connected to SDHI1 and eMMC connected to SDHI3 on the Ebisu board
>> using the R8A77990 SoC.
>>
>> Signed-off-by: Takeshi Kihara
>> Signed-off-by: Marek Vasut
>
>> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
>> +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
>> @@ -129,6 +129,15 @@
>> };
>> };
>>
>> + reg_1p8v: regulator0 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "fixed-1.8V";
>> + regulator-min-microvolt = <180>;
>> + regulator-max-microvolt = <180>;
>> + regulator-boot-on;
>> + regulator-always-on;
>> + };
>> +
>> reg_3p3v: regulator1 {
>> compatible = "regulator-fixed";
>> regulator-name = "fixed-3.3V";
>> @@ -180,6 +189,54 @@
>> #clock-cells = <0>;
>> clock-frequency = <7425>;
>> };
>> +
>> + vcc_sdhi0: regulator-vcc-sdhi0 {
>> + compatible = "regulator-fixed";
>> +
>> + regulator-name = "SDHI0 Vcc";
>> + regulator-min-microvolt = <330>;
>> + regulator-max-microvolt = <330>;
>> +
>> + gpio = < 17 GPIO_ACTIVE_HIGH>;
>> + enable-active-high;
>> + };
>> +
>> + vccq_sdhi0: regulator-vccq-sdhi0 {
>> + compatible = "regulator-gpio";
>> +
>> + regulator-name = "SDHI0 VccQ";
>> + regulator-min-microvolt = <180>;
>> + regulator-max-microvolt = <330>;
>> +
>> + gpios = < 18 GPIO_ACTIVE_HIGH>;
>> + gpios-states = <1>;
>> + states = <330 1
>> + 180 0>;
>
> I know this is how it's done in the example in
> Documentation/devicetree/bindings/regulator/gpio-regulator.txt,
> but usually brackets are used to group tuples, like:
>
> states = <330 1>, <180 0>;
>
> Perhaps the example should be changed?
Well, looking through the DTS, I don't see anyone using tuples for the
GPIO regulator states. Then again, it could be updated.
+CC Mark and Liam, let's see what their opinion on changing that is.
--
Best regards,
Marek Vasut
Re: [PATCH 4/4] pinctrl: sh-pfc: r8a77990: Add CAN FD pins, groups and functions
On 11/19/2018 10:47 AM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Mon, Nov 19, 2018 at 10:06 AM Geert Uytterhoeven
> wrote:
>> On Sun, Nov 18, 2018 at 6:29 PM Marek Vasut wrote:
>>> From: Takeshi Kihara
>>>
>>> This patch adds CAN FD{0,1} pins, groups and functions to the R8A77990
>>> SoC.
>>>
>>> Signed-off-by: Takeshi Kihara
>>> Signed-off-by: Marek Vasut
>>
>> Reviewed-by: Geert Uytterhoeven
>> i.e. will queue in sh-pfc-for-v4.21.
>
> Upon second look, the canfd groups and functions should be moved from
> the common to the automotive section, as RZ/G2E does not have them.
> As I have to update the array sizes anyway (my branch already has more
> patches applied), I moved them while applying.
>
> Please check the result later today, after I have pushed.
Looks OK to me. Incrementing the array sizes in the driver is kinda icky
though.
--
Best regards,
Marek Vasut
Re: [PATCH 1/2] arm64: dts: renesas: r8a77965: Add CAN controller nodes
On 11/19/2018 10:00 AM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Mon, Nov 19, 2018 at 12:46 AM Marek Vasut wrote:
>> On 11/19/2018 12:02 AM, Wolfram Sang wrote:
>>> On Sun, Nov 18, 2018 at 06:33:26PM +0100, Marek Vasut wrote:
>>>> From: Takeshi Kihara
>>>>
>>>> This patch adds CAN{0,1} controller nodes for the R8A77965 SoC.
>>>>
>>>> Based on several similar patches of the R8A7795 device tree
>>>> by Ramesh Shanmugasundaram
>>>> and Geert Uytterhoeven .
>>>>
>>>> Signed-off-by: Takeshi Kihara
>>>> Signed-off-by: Marek Vasut
>>>> Cc: Geert Uytterhoeven
>>>> Cc: Marc Kleine-Budde
>>>> Cc: Rob Herring
>>>> Cc: Simon Horman
>>>> Cc: Wolfram Sang
>>>> Cc: linux-renesas-soc@vger.kernel.org
>>>> Cc: linux-arm-ker...@lists.infradead.org
>>>
>>> Were you able to do some testing using EXIO connectors? Would be nice to
>>> know what was tested.
>>
>> Not on the M3N, since I don't see it broken out on the EXIO ; is it
>> really there ? It'd be easy to test on M3NSK with KF, but I don't have
>> either KF or M3NSK.
>
> Please have a look at EXIO Connector D, pins 13/14/15.
That's LBSC WE1n/WE0n/CS0n on S-XS . Is there something I obviously
don't see ?
--
Best regards,
Marek Vasut
[PATCH V2] arm64: dts: renesas: r8a77965: Add CAN and CANFD controller nodes
From: Takeshi Kihara
This patch adds CAN{0,1} and CANFD controller nodes for the R8A77965 SoC.
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Marc Kleine-Budde
Cc: Rob Herring
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
V2: Squash the CAN and CANFD addition patches together.
---
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 51 ++-
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 3a958fb25245..1c86e6f4dc71 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -907,13 +907,60 @@
};
can0: can@e6c3 {
+ compatible = "renesas,can-r8a77965",
+"renesas,rcar-gen3-can";
reg = <0 0xe6c3 0 0x1000>;
- /* placeholder */
+ interrupts = ;
+ clocks = < CPG_MOD 916>,
+ < CPG_CORE R8A77965_CLK_CANFD>,
+ <_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ assigned-clocks = < CPG_CORE R8A77965_CLK_CANFD>;
+ assigned-clock-rates = <4000>;
+ power-domains = < R8A77965_PD_ALWAYS_ON>;
+ resets = < 916>;
+ status = "disabled";
};
can1: can@e6c38000 {
+ compatible = "renesas,can-r8a77965",
+"renesas,rcar-gen3-can";
reg = <0 0xe6c38000 0 0x1000>;
- /* placeholder */
+ interrupts = ;
+ clocks = < CPG_MOD 915>,
+ < CPG_CORE R8A77965_CLK_CANFD>,
+ <_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ assigned-clocks = < CPG_CORE R8A77965_CLK_CANFD>;
+ assigned-clock-rates = <4000>;
+ power-domains = < R8A77965_PD_ALWAYS_ON>;
+ resets = < 915>;
+ status = "disabled";
+ };
+
+ canfd: can@e66c {
+ compatible = "renesas,r8a77965-canfd",
+"renesas,rcar-gen3-canfd";
+ reg = <0 0xe66c 0 0x8000>;
+ interrupts = ,
+ ;
+ clocks = < CPG_MOD 914>,
+ < CPG_CORE R8A77965_CLK_CANFD>,
+ <_clk>;
+ clock-names = "fck", "canfd", "can_clk";
+ assigned-clocks = < CPG_CORE R8A77965_CLK_CANFD>;
+ assigned-clock-rates = <4000>;
+ power-domains = < R8A77965_PD_ALWAYS_ON>;
+ resets = < 914>;
+ status = "disabled";
+
+ channel0 {
+ status = "disabled";
+ };
+
+ channel1 {
+ status = "disabled";
+ };
};
pwm0: pwm@e6e3 {
--
2.18.0
Re: [PATCH 2/2] dt-binding: spi: Document Renesas R-Car RPC controller bindings
On 11/19/2018 03:43 PM, Boris Brezillon wrote: > On Mon, 19 Nov 2018 15:14:07 +0100 > Marek Vasut wrote: > >> On 11/19/2018 03:10 PM, Boris Brezillon wrote: >>> On Mon, 19 Nov 2018 14:49:31 +0100 >>> Marek Vasut wrote: >>> >>>> On 11/19/2018 11:01 AM, Mason Yang wrote: >>>>> Document the bindings used by the Renesas R-Car D3 RPC controller. >>>>> >>>>> Signed-off-by: Mason Yang >>>>> --- >>>>> .../devicetree/bindings/spi/spi-renesas-rpc.txt| 33 >>>>> ++ >>>>> 1 file changed, 33 insertions(+) >>>>> create mode 100644 >>>>> Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt >>>>> b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt >>>>> new file mode 100644 >>>>> index 000..8286cc8 >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt >>>>> @@ -0,0 +1,33 @@ >>>>> +Renesas R-Car D3 RPC controller Device Tree Bindings >>>>> + >>>>> + >>>>> +Required properties: >>>>> +- compatible: should be "renesas,rpc-r8a77995" >>>>> +- #address-cells: should be 1 >>>>> +- #size-cells: should be 0 >>>>> +- reg: should contain 2 entries, one for the registers and one for the >>>>> direct >>>>> + mapping area >>>>> +- reg-names: should contain "rpc_regs" and "dirmap" >>>>> +- interrupts: interrupt line connected to the RPC SPI controller >>>> >>>> Do you also plan to support the RPC HF mode ? And if so, how would that >>>> look in the bindings ? >>> >>> Not sure this approach is still accepted, but that's how we solved the >>> problem for the flexcom block [1]. >>> >>> [1]https://elixir.bootlin.com/linux/v4.20-rc3/source/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt >>> >> >> That looks pretty horrible. >> >> In U-Boot we check whether the device hanging under the controller node >> is JEDEC SPI flash or CFI flash and based on that decide what the config >> of the controller should be (SPI or HF). Not sure that's much better,but >> at least it doesn't need extra nodes which do not really represent any >> kind of real hardware. >> > > The subnodes are not needed, you can just have a property that tells in > which mode the controller is supposed to operate, and the MFD would > create a sub-device that points to the same device_node. Do you even need a dedicated property ? I think you can decide purely on what node is hanging under the controller (jedec spi nor or cfi nor). > Or we can have > a single driver that decides what to declare (a spi_controller or flash > controller), but you'd still have to decide where to place this > driver... I'd definitely prefer a single driver. -- Best regards, Marek Vasut
Re: [PATCH] dt-bindings: can: rcar_can: document r8a77990 support
On 11/19/2018 10:38 AM, Geert Uytterhoeven wrote:
> Hi Marek, Wolfram,
Hi,
> On Mon, Nov 19, 2018 at 12:46 AM Marek Vasut wrote:
>> On 11/19/2018 12:14 AM, Wolfram Sang wrote:
>>> On Sun, Nov 18, 2018 at 06:30:56PM +0100, Marek Vasut wrote:
>>>> Document the support for rcar_can on R8A77990 SoC devices.
>>>> Add R8A77990 to the list of SoCs which require the "assigned-clocks"
>>>> and "assigned-clock-rates" properties.
>>>>
>>>> Signed-off-by: Marek Vasut
>
>>>> --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
>>>> +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
>>>> @@ -16,6 +16,7 @@ Required properties:
>>>>"renesas,can-r8a7795" if CAN controller is a part of R8A7795
>>>> SoC.
>>>>"renesas,can-r8a7796" if CAN controller is a part of R8A7796
>>>> SoC.
>>>>"renesas,can-r8a77965" if CAN controller is a part of R8A77965
>>>> SoC.
>>>
>>> I was wondering why you didn't have a patch adding support for R8A77965.
>>> I see it is already added here but can't find a tree where this line
>>> exists (no linus/master or renesas-drivers/master). Did you maybe forgot
>>> to send out a patch?
>>
>> Try and grep for 'renesas,rcar-gen3-can' , the drivers are in
>> drivers/net/can/rcar/ . They both match on the generic compatible.
>
> Marek: I think you misunderstood Wolfram's question.
> He asked about the DT bindings, not about the driver.
Ha, yes, I think I did.
> Wolfram: Eugenu's commit 4f145f14f6b98b5a ("dt-bindings: can:
> rcar_can: document r8a77965 support") is in next as of next-20181115 .
> However, it's not part of linux-can-next. Seems to be destined for v4.20 as
> a fix.
I'm always building on top of next, so that's why I didn't quite
understand the question.
--
Best regards,
Marek Vasut
Re: [PATCH 2/2] dt-binding: spi: Document Renesas R-Car RPC controller bindings
On 11/19/2018 03:10 PM, Boris Brezillon wrote: > On Mon, 19 Nov 2018 14:49:31 +0100 > Marek Vasut wrote: > >> On 11/19/2018 11:01 AM, Mason Yang wrote: >>> Document the bindings used by the Renesas R-Car D3 RPC controller. >>> >>> Signed-off-by: Mason Yang >>> --- >>> .../devicetree/bindings/spi/spi-renesas-rpc.txt| 33 >>> ++ >>> 1 file changed, 33 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt >>> >>> diff --git a/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt >>> b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt >>> new file mode 100644 >>> index 000..8286cc8 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt >>> @@ -0,0 +1,33 @@ >>> +Renesas R-Car D3 RPC controller Device Tree Bindings >>> + >>> + >>> +Required properties: >>> +- compatible: should be "renesas,rpc-r8a77995" >>> +- #address-cells: should be 1 >>> +- #size-cells: should be 0 >>> +- reg: should contain 2 entries, one for the registers and one for the >>> direct >>> + mapping area >>> +- reg-names: should contain "rpc_regs" and "dirmap" >>> +- interrupts: interrupt line connected to the RPC SPI controller >> >> Do you also plan to support the RPC HF mode ? And if so, how would that >> look in the bindings ? > > Not sure this approach is still accepted, but that's how we solved the > problem for the flexcom block [1]. > > [1]https://elixir.bootlin.com/linux/v4.20-rc3/source/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt That looks pretty horrible. In U-Boot we check whether the device hanging under the controller node is JEDEC SPI flash or CFI flash and based on that decide what the config of the controller should be (SPI or HF). Not sure that's much better,but at least it doesn't need extra nodes which do not really represent any kind of real hardware. -- Best regards, Marek Vasut
Re: [PATCH 1/2] spi: Add Renesas R-Car RPC SPI controller driver
> + rpc->smenr |= RPC_SMENR_SPIDE(rpc_bits_xfer
> + (xfer[2].len)) | RPC_SMENR_SPIDB(fls
> + (xfer[2].tx_nbits >> 1));
> + rpc->smcr = RPC_SMCR_SPIWE;
> + rpc->xfer_dir = SPI_MEM_DATA_OUT;
> + }
> +
> + break;
> +
> + case 4:
> + if (xfer[2].len && xfer[2].tx_buf) {
> + rpc->smenr |= RPC_SMENR_DME;
> + rpc->dummy = RPC_SMDMCR_DMCYC(xfer[2].len);
> + writel(rpc->dummy, rpc->regs + RPC_SMDMCR);
> + }
> +
> + if (xfer[3].len && xfer[3].rx_buf) {
> + rpc->smenr |= RPC_SMENR_SPIDE(rpc_bits_xfer
> + (xfer[3].len)) | RPC_SMENR_SPIDB(fls
> + (xfer[3].rx_nbits >> 1));
> + rpc->smcr = RPC_SMCR_SPIRE;
> + rpc->xfer_dir = SPI_MEM_DATA_IN;
> + }
> +
> + break;
> +
> + default:
> + break;
> + }
> +}
> +
> +static int rpc_spi_xfer_message(struct rpc_spi *rpc, struct spi_transfer *t)
> +{
> + int ret;
> +
> + ret = rpc_spi_set_freq(rpc, t->speed_hz);
> + if (ret)
> + return ret;
> +
> + ret = rpc_spi_io_xfer(rpc,
> + rpc->xfer_dir == SPI_MEM_DATA_OUT ?
> + t->tx_buf : NULL,
> + rpc->xfer_dir == SPI_MEM_DATA_IN ?
> + t->rx_buf : NULL);
> +
> + return ret;
> +}
> +
> +static int rpc_spi_transfer_one_message(struct spi_master *master,
> + struct spi_message *msg)
> +{
> + struct rpc_spi *rpc = spi_master_get_devdata(master);
> + struct spi_transfer *t;
> + int ret;
> +
> + rpc_spi_transfer_setup(rpc, msg);
> +
> + list_for_each_entry(t, >transfers, transfer_list) {
> + if (list_is_last(>transfer_list, >transfers)) {
if (!list...)
continue;
to reduce the indent level.
> + ret = rpc_spi_xfer_message(rpc, t);
> + if (ret)
> + goto out;
> + }
> + }
> +
> + msg->status = 0;
> + msg->actual_length = rpc->totalxferlen;
> +out:
> + spi_finalize_current_message(master);
> + return 0;
> +}
> +
> +static int __maybe_unused rpc_spi_runtime_suspend(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct spi_master *master = platform_get_drvdata(pdev);
> + struct rpc_spi *rpc = spi_master_get_devdata(master);
> +
> + clk_disable_unprepare(rpc->clk_rpc);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused rpc_spi_runtime_resume(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct spi_master *master = platform_get_drvdata(pdev);
> + struct rpc_spi *rpc = spi_master_get_devdata(master);
> + int ret;
> +
> + ret = clk_prepare_enable(rpc->clk_rpc);
> + if (ret)
> + dev_err(dev, "Can't enable rpc->clk_rpc\n");
> +
> + return ret;
> +}
> +
> +static const struct dev_pm_ops rpc_spi_dev_pm_ops = {
> + SET_RUNTIME_PM_OPS(rpc_spi_runtime_suspend,
> +rpc_spi_runtime_resume, NULL)
> +};
> +
> +static int rpc_spi_probe(struct platform_device *pdev)
> +{
> + struct spi_master *master;
> + struct resource *res;
> + struct rpc_spi *rpc;
> + int ret;
> +
> + master = spi_alloc_master(>dev, sizeof(struct rpc_spi));
> + if (!master)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, master);
> +
> + rpc = spi_master_get_devdata(master);
> +
> + master->dev.of_node = pdev->dev.of_node;
> +
> + rpc->clk_rpc = devm_clk_get(>dev, "clk_rpc");
> + if (IS_ERR(rpc->clk_rpc))
> + return PTR_ERR(rpc->clk_rpc);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "rpc_regs");
> + rpc->regs = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(rpc->regs))
> + return PTR_ERR(rpc->regs);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dirmap");
> + rpc->linear.map = devm_ioremap_resource(>dev, res);
> + if (!IS_ERR(rpc->linear.map)) {
> + rpc->linear.dma = res->start;
> + rpc->linear.size = resource_size(res);
> + } else {
> + rpc->linear.map = NULL;
> + }
> +
> + pm_runtime_enable(>dev);
> + master->auto_runtime_pm = true;
> +
> + master->num_chipselect = 1;
> + master->mem_ops = _spi_mem_ops;
> + master->transfer_one_message = rpc_spi_transfer_one_message;
> +
> + master->bits_per_word_mask = SPI_BPW_MASK(8);
> + master->mode_bits = SPI_CPOL | SPI_CPHA |
> + SPI_RX_DUAL | SPI_TX_DUAL |
> + SPI_RX_QUAD | SPI_TX_QUAD;
> +
> + rpc_spi_hw_init(rpc);
> +
> + ret = spi_register_master(master);
> + if (ret) {
> + dev_err(>dev, "spi_register_master failed\n");
> + goto err_put_master;
> + }
> + return 0;
> +
> +err_put_master:
> + spi_master_put(master);
> + pm_runtime_disable(>dev);
> +
> + return ret;
> +}
> +
> +static int rpc_spi_remove(struct platform_device *pdev)
> +{
> + struct spi_master *master = platform_get_drvdata(pdev);
> +
> + pm_runtime_disable(>dev);
> + spi_unregister_master(master);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id rpc_spi_of_ids[] = {
> + { .compatible = "renesas,rpc-r8a77995", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, rpc_spi_of_ids);
> +
> +static struct platform_driver rpc_spi_driver = {
> + .probe = rpc_spi_probe,
> + .remove = rpc_spi_remove,
> + .driver = {
> + .name = "rpc-spi",
> + .of_match_table = rpc_spi_of_ids,
> + .pm = _spi_dev_pm_ops,
> + },
> +};
> +module_platform_driver(rpc_spi_driver);
> +
> +MODULE_AUTHOR("Mason Yang ");
> +MODULE_DESCRIPTION("Renesas R-Car D3 RPC SPI controller driver");
This is not D3 specific and not SPI-only controller btw.
> +MODULE_LICENSE("GPL v2");
>
--
Best regards,
Marek Vasut
Re: [PATCH 2/2] dt-binding: spi: Document Renesas R-Car RPC controller bindings
On 11/19/2018 11:01 AM, Mason Yang wrote:
> Document the bindings used by the Renesas R-Car D3 RPC controller.
>
> Signed-off-by: Mason Yang
> ---
> .../devicetree/bindings/spi/spi-renesas-rpc.txt| 33
> ++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
> b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
> new file mode 100644
> index 000..8286cc8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
> @@ -0,0 +1,33 @@
> +Renesas R-Car D3 RPC controller Device Tree Bindings
> +
> +
> +Required properties:
> +- compatible: should be "renesas,rpc-r8a77995"
> +- #address-cells: should be 1
> +- #size-cells: should be 0
> +- reg: should contain 2 entries, one for the registers and one for the direct
> + mapping area
> +- reg-names: should contain "rpc_regs" and "dirmap"
> +- interrupts: interrupt line connected to the RPC SPI controller
Do you also plan to support the RPC HF mode ? And if so, how would that
look in the bindings ? I'd like to avoid having to redesign the bindings
later to handle both the SPI and HF modes.
The HF is roughly a CFI flash with different bus interface.
btw U-Boot has drivers for both the HF and SPI mode:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mtd/renesas_rpc_hf.c
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/spi/renesas_rpc_spi.c
> +- clock-names: should contain "clk_rpc"
> +- clocks: should contain 1 entries for the CPG Module 917 clocks
> +
> +Example:
> +
> + rpc: spi@ee20 {
> + compatible = "renesas,rpc-r8a77995";
> + reg = <0 0xee20 0 0x8100>, <0 0x0800 0 0x400>;
> + reg-names = "rpc_regs", "dirmap";
> + clocks = < CPG_MOD 917>;
> + clock-names = "clk_rpc";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <4000>;
> + spi-tx-bus-width = <1>;
> + spi-rx-bus-width = <1>;
> + };
> + };
>
--
Best regards,
Marek Vasut
Re: [PATCH] arm64: dts: renesas: r8a77990: ebisu: Add and enable CAN,FD device nodes
On 11/19/2018 12:03 AM, Wolfram Sang wrote: > On Sun, Nov 18, 2018 at 06:34:24PM +0100, Marek Vasut wrote: >> This patch adds CAN0,1 and CANFD device nodes for the r8a77990 SoC >> and enables CANFD connected to CN10 on the E3 Ebisu board using the >> R8A77990 SoC. >> >> Signed-off-by: Marek Vasut >> Cc: Geert Uytterhoeven >> Cc: Marc Kleine-Budde >> Cc: Rob Herring >> Cc: Simon Horman >> Cc: Wolfram Sang >> Cc: Yoshihiro Shimoda >> Cc: linux-arm-ker...@lists.infradead.org >> Cc: linux-renesas-soc@vger.kernel.org > > Same here, what was tested? I connected the CN10 to Peak CANFD, brought both interfaces up at 125kBd/250kBd for FD $ ip link set canX up type can bitrate 125000 dbitrate 25 fd on And ran on either side: $ cangen -m canX and $ candump -t d -dex canX This should give a good mix of CAN messages. -- Best regards, Marek Vasut
Re: [PATCH 1/2] dt-bindings: can: rcar_canfd: document r8a77965 support
On 11/19/2018 12:18 AM, Wolfram Sang wrote: > >> + - "renesas,r8a77965-canfd" for R8A77965 (R-Car M3-N) compatible >> controller. > > Eeeks, the 'canfd' is a suffix here not a prefix :( Not your issue, > of course. But Simon, shall we fix that for all CANFD? > >> -Required properties for "renesas,r8a7795-canfd" and "renesas,r8a7796-canfd" >> -compatible: >> -In R8A7795 and R8A7796 SoCs, canfd clock is a div6 clock and can be used by >> both >> -CAN and CAN FD controller at the same time. It needs to be scaled to maximum >> -frequency if any of these controllers use it. This is done using the below >> -properties: >> +Required properties for "renesas,r8a7795-canfd", "renesas,r8a7796-canfd" and >> +"renesas,r8a77965-canfd" compatible: >> +In R8A7795, R8A7796 and R8A77965 SoCs, canfd clock is a div6 clock and can >> +be used by both CAN and CAN FD controller at the same time. It needs to be >> +scaled to maximum frequency if any of these controllers use it. This is done >> +using the below properties: > > I think updating this paragraph does not scale. Maybe we should reformat > it the way as for plain CAN, so only in the header the new SoC gets > added? We can fix this incrementally, though, doesn't need to be > addressed within this patch. Sure, although I don't expect it to grow much more than this. -- Best regards, Marek Vasut
Re: [PATCH 2/2] arm64: dts: renesas: r8a77965: Add CAN FD controller node
On 11/19/2018 12:10 AM, Wolfram Sang wrote: > On Sun, Nov 18, 2018 at 06:33:27PM +0100, Marek Vasut wrote: >> From: Takeshi Kihara >> >> This patch adds CAN FD controller nodes for the R8A77965 SoC. >> >> Signed-off-by: Takeshi Kihara >> Signed-off-by: Marek Vasut >> Cc: Geert Uytterhoeven >> Cc: Marc Kleine-Budde >> Cc: Rob Herring >> Cc: Simon Horman >> Cc: Wolfram Sang >> Cc: linux-renesas-soc@vger.kernel.org >> Cc: linux-arm-ker...@lists.infradead.org > > Why seperate patches for CAN and CANFD here while they are merged for > r8a77990 into one patch? Because they are two different IP blocks, but I can merge the patches together if that's what you want. -- Best regards, Marek Vasut
Re: [PATCH 1/2] arm64: dts: renesas: r8a77965: Add CAN controller nodes
On 11/19/2018 12:02 AM, Wolfram Sang wrote:
> On Sun, Nov 18, 2018 at 06:33:26PM +0100, Marek Vasut wrote:
>> From: Takeshi Kihara
>>
>> This patch adds CAN{0,1} controller nodes for the R8A77965 SoC.
>>
>> Based on several similar patches of the R8A7795 device tree
>> by Ramesh Shanmugasundaram
>> and Geert Uytterhoeven .
>>
>> Signed-off-by: Takeshi Kihara
>> Signed-off-by: Marek Vasut
>> Cc: Geert Uytterhoeven
>> Cc: Marc Kleine-Budde
>> Cc: Rob Herring
>> Cc: Simon Horman
>> Cc: Wolfram Sang
>> Cc: linux-renesas-soc@vger.kernel.org
>> Cc: linux-arm-ker...@lists.infradead.org
>
> Were you able to do some testing using EXIO connectors? Would be nice to
> know what was tested.
Not on the M3N, since I don't see it broken out on the EXIO ; is it
really there ? It'd be easy to test on M3NSK with KF, but I don't have
either KF or M3NSK.
--
Best regards,
Marek Vasut
Re: [PATCH] dt-bindings: can: rcar_can: document r8a77990 support
On 11/19/2018 12:14 AM, Wolfram Sang wrote: > On Sun, Nov 18, 2018 at 06:30:56PM +0100, Marek Vasut wrote: >> Document the support for rcar_can on R8A77990 SoC devices. >> Add R8A77990 to the list of SoCs which require the "assigned-clocks" >> and "assigned-clock-rates" properties. >> >> Signed-off-by: Marek Vasut >> Cc: Eugeniu Rosca >> Cc: Geert Uytterhoeven >> Cc: Marc Kleine-Budde >> Cc: Rob Herring >> Cc: Simon Horman >> Cc: Wolfram Sang >> Cc: linux-renesas-soc@vger.kernel.org >> --- >> Documentation/devicetree/bindings/net/can/rcar_can.txt | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt >> b/Documentation/devicetree/bindings/net/can/rcar_can.txt >> index 9936b9ee67c3..d962138d5b50 100644 >> --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt >> +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt >> @@ -16,6 +16,7 @@ Required properties: >>"renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC. >>"renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC. >>"renesas,can-r8a77965" if CAN controller is a part of R8A77965 >> SoC. > > I was wondering why you didn't have a patch adding support for R8A77965. > I see it is already added here but can't find a tree where this line > exists (no linus/master or renesas-drivers/master). Did you maybe forgot > to send out a patch? Try and grep for 'renesas,rcar-gen3-can' , the drivers are in drivers/net/can/rcar/ . They both match on the generic compatible. -- Best regards, Marek Vasut
[PATCH] arm64: dts: renesas: r8a77990: ebisu: Add and enable CAN,FD device nodes
This patch adds CAN0,1 and CANFD device nodes for the r8a77990 SoC
and enables CANFD connected to CN10 on the E3 Ebisu board using the
R8A77990 SoC.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Marc Kleine-Budde
Cc: Rob Herring
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
---
.../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 15 +
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 64 +++
2 files changed, 79 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 2ef9067616ee..e282ef51 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -260,6 +260,16 @@
};
};
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ channel0 {
+ status = "okay";
+ };
+};
+
{
status = "okay";
@@ -460,6 +470,11 @@
};
};
+ canfd0_pins: canfd0 {
+ groups = "canfd0_data";
+ function = "canfd0";
+ };
+
du_pins: du {
groups = "du_rgb888", "du_sync", "du_disp", "du_clk_out_0";
function = "du";
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 46868dacbeef..b0398e05e8ed 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -48,6 +48,13 @@
clock-frequency = <0>;
};
+ /* External CAN clock - to be overridden by boards that provide it */
+ can_clk: can {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -773,6 +780,63 @@
status = "disabled";
};
+ can0: can@e6c3 {
+ compatible = "renesas,can-r8a77990",
+"renesas,rcar-gen3-can";
+ reg = <0 0xe6c3 0 0x1000>;
+ interrupts = ;
+ clocks = < CPG_MOD 916>,
+ < CPG_CORE R8A77990_CLK_CANFD>,
+ <_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ assigned-clocks = < CPG_CORE R8A77990_CLK_CANFD>;
+ assigned-clock-rates = <4000>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 916>;
+ status = "disabled";
+ };
+
+ can1: can@e6c38000 {
+ compatible = "renesas,can-r8a77990",
+"renesas,rcar-gen3-can";
+ reg = <0 0xe6c38000 0 0x1000>;
+ interrupts = ;
+ clocks = < CPG_MOD 915>,
+ < CPG_CORE R8A77990_CLK_CANFD>,
+ <_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ assigned-clocks = < CPG_CORE R8A77990_CLK_CANFD>;
+ assigned-clock-rates = <4000>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 915>;
+ status = "disabled";
+ };
+
+ canfd: can@e66c {
+ compatible = "renesas,r8a77990-canfd",
+"renesas,rcar-gen3-canfd";
+ reg = <0 0xe66c 0 0x8000>;
+ interrupts = ,
+ ;
+ clocks = < CPG_MOD 914>,
+ < CPG_CORE R8A77990_CLK_CANFD>,
+ <_clk>;
+ clock-names = "fck", "canfd", "can_clk";
+ assigned-clocks = < CPG_CORE R8A77990_CLK_CANFD>;
+ assigned-clock-rates = <4000>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 914>;
+ status = "disabled";
+
+ channel0 {
+ status = "disabled";
+ };
+
+ channel1 {
+ status = "disabled";
+ };
+ };
+
pwm0: pwm@e6e3 {
compatible = "renesas,pwm-r8a77990", "renesas,pwm-rcar";
reg = <0 0xe6e3 0 0x8>;
--
2.18.0
[PATCH 2/2] arm64: dts: renesas: r8a77965: Add CAN FD controller node
From: Takeshi Kihara
This patch adds CAN FD controller nodes for the R8A77965 SoC.
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Marc Kleine-Budde
Cc: Rob Herring
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 25 +++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 3485624921bf..1c86e6f4dc71 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -938,6 +938,31 @@
status = "disabled";
};
+ canfd: can@e66c {
+ compatible = "renesas,r8a77965-canfd",
+"renesas,rcar-gen3-canfd";
+ reg = <0 0xe66c 0 0x8000>;
+ interrupts = ,
+ ;
+ clocks = < CPG_MOD 914>,
+ < CPG_CORE R8A77965_CLK_CANFD>,
+ <_clk>;
+ clock-names = "fck", "canfd", "can_clk";
+ assigned-clocks = < CPG_CORE R8A77965_CLK_CANFD>;
+ assigned-clock-rates = <4000>;
+ power-domains = < R8A77965_PD_ALWAYS_ON>;
+ resets = < 914>;
+ status = "disabled";
+
+ channel0 {
+ status = "disabled";
+ };
+
+ channel1 {
+ status = "disabled";
+ };
+ };
+
pwm0: pwm@e6e3 {
compatible = "renesas,pwm-r8a77965", "renesas,pwm-rcar";
reg = <0 0xe6e3 0 8>;
--
2.18.0
[PATCH 1/2] arm64: dts: renesas: r8a77965: Add CAN controller nodes
From: Takeshi Kihara
This patch adds CAN{0,1} controller nodes for the R8A77965 SoC.
Based on several similar patches of the R8A7795 device tree
by Ramesh Shanmugasundaram
and Geert Uytterhoeven .
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Marc Kleine-Budde
Cc: Rob Herring
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 26 +--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 3a958fb25245..3485624921bf 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -907,13 +907,35 @@
};
can0: can@e6c3 {
+ compatible = "renesas,can-r8a77965",
+"renesas,rcar-gen3-can";
reg = <0 0xe6c3 0 0x1000>;
- /* placeholder */
+ interrupts = ;
+ clocks = < CPG_MOD 916>,
+ < CPG_CORE R8A77965_CLK_CANFD>,
+ <_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ assigned-clocks = < CPG_CORE R8A77965_CLK_CANFD>;
+ assigned-clock-rates = <4000>;
+ power-domains = < R8A77965_PD_ALWAYS_ON>;
+ resets = < 916>;
+ status = "disabled";
};
can1: can@e6c38000 {
+ compatible = "renesas,can-r8a77965",
+"renesas,rcar-gen3-can";
reg = <0 0xe6c38000 0 0x1000>;
- /* placeholder */
+ interrupts = ;
+ clocks = < CPG_MOD 915>,
+ < CPG_CORE R8A77965_CLK_CANFD>,
+ <_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ assigned-clocks = < CPG_CORE R8A77965_CLK_CANFD>;
+ assigned-clock-rates = <4000>;
+ power-domains = < R8A77965_PD_ALWAYS_ON>;
+ resets = < 915>;
+ status = "disabled";
};
pwm0: pwm@e6e3 {
--
2.18.0
[PATCH 2/2] dt-bindings: can: rcar_canfd: document r8a77990 support
Document the support for rcar_canfd on R8A77990 SoC devices. Signed-off-by: Marek Vasut Cc: Eugeniu Rosca Cc: Geert Uytterhoeven Cc: Marc Kleine-Budde Cc: Rob Herring Cc: Simon Horman Cc: Wolfram Sang Cc: linux-renesas-soc@vger.kernel.org To: devicet...@vger.kernel.org --- .../devicetree/bindings/net/can/rcar_canfd.txt | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt index 4720e916fbdd..41049fed5872 100644 --- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt +++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt @@ -9,6 +9,7 @@ Required properties: - "renesas,r8a77965-canfd" for R8A77965 (R-Car M3-N) compatible controller. - "renesas,r8a77970-canfd" for R8A77970 (R-Car V3M) compatible controller. - "renesas,r8a77980-canfd" for R8A77980 (R-Car V3H) compatible controller. + - "renesas,r8a77990-canfd" for R8A77990 (R-Car E3) compatible controller. When compatible with the generic version, nodes must list the SoC-specific version corresponding to the platform first, followed by the @@ -27,12 +28,12 @@ The name of the child nodes are "channel0" and "channel1" respectively. Each child node supports the "status" property only, which is used to enable/disable the respective channel. -Required properties for "renesas,r8a7795-canfd", "renesas,r8a7796-canfd" and -"renesas,r8a77965-canfd" compatible: -In R8A7795, R8A7796 and R8A77965 SoCs, canfd clock is a div6 clock and can -be used by both CAN and CAN FD controller at the same time. It needs to be -scaled to maximum frequency if any of these controllers use it. This is done -using the below properties: +Required properties for "renesas,r8a7795-canfd", "renesas,r8a7796-canfd", +"renesas,r8a77965-canfd" and "renesas,r8a77990-canfd" compatible: +In R8A7795, R8A7796, R8A77965 and R8A77990 SoCs, canfd clock is a div6 clock +and can be used by both CAN and CAN FD controller at the same time. It needs +to be scaled to maximum frequency if any of these controllers use it. This is +done using the below properties: - assigned-clocks: phandle of canfd clock. - assigned-clock-rates: maximum frequency of this clock. -- 2.18.0
[PATCH 1/2] dt-bindings: can: rcar_canfd: document r8a77965 support
Document the support for rcar_canfd on R8A77965 SoC devices. Signed-off-by: Marek Vasut Cc: Eugeniu Rosca Cc: Geert Uytterhoeven Cc: Marc Kleine-Budde Cc: Rob Herring Cc: Simon Horman Cc: Wolfram Sang Cc: linux-renesas-soc@vger.kernel.org --- .../devicetree/bindings/net/can/rcar_canfd.txt | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt index ac71daa46195..4720e916fbdd 100644 --- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt +++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt @@ -6,6 +6,7 @@ Required properties: - "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller. - "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller. - "renesas,r8a7796-canfd" for R8A7796 (R-Car M3-W) compatible controller. + - "renesas,r8a77965-canfd" for R8A77965 (R-Car M3-N) compatible controller. - "renesas,r8a77970-canfd" for R8A77970 (R-Car V3M) compatible controller. - "renesas,r8a77980-canfd" for R8A77980 (R-Car V3H) compatible controller. @@ -26,12 +27,12 @@ The name of the child nodes are "channel0" and "channel1" respectively. Each child node supports the "status" property only, which is used to enable/disable the respective channel. -Required properties for "renesas,r8a7795-canfd" and "renesas,r8a7796-canfd" -compatible: -In R8A7795 and R8A7796 SoCs, canfd clock is a div6 clock and can be used by both -CAN and CAN FD controller at the same time. It needs to be scaled to maximum -frequency if any of these controllers use it. This is done using the below -properties: +Required properties for "renesas,r8a7795-canfd", "renesas,r8a7796-canfd" and +"renesas,r8a77965-canfd" compatible: +In R8A7795, R8A7796 and R8A77965 SoCs, canfd clock is a div6 clock and can +be used by both CAN and CAN FD controller at the same time. It needs to be +scaled to maximum frequency if any of these controllers use it. This is done +using the below properties: - assigned-clocks: phandle of canfd clock. - assigned-clock-rates: maximum frequency of this clock. -- 2.18.0
[PATCH] dt-bindings: can: rcar_can: document r8a77990 support
Document the support for rcar_can on R8A77990 SoC devices. Add R8A77990 to the list of SoCs which require the "assigned-clocks" and "assigned-clock-rates" properties. Signed-off-by: Marek Vasut Cc: Eugeniu Rosca Cc: Geert Uytterhoeven Cc: Marc Kleine-Budde Cc: Rob Herring Cc: Simon Horman Cc: Wolfram Sang Cc: linux-renesas-soc@vger.kernel.org --- Documentation/devicetree/bindings/net/can/rcar_can.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt index 9936b9ee67c3..d962138d5b50 100644 --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt @@ -16,6 +16,7 @@ Required properties: "renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC. "renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC. "renesas,can-r8a77965" if CAN controller is a part of R8A77965 SoC. + "renesas,can-r8a77990" if CAN controller is a part of R8A77990 SoC. "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device. "renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1 compatible device. @@ -37,7 +38,7 @@ Required properties: - pinctrl-0: pin control group to be used for this controller. - pinctrl-names: must be "default". -Required properties for R8A7795, R8A7796 and R8A77965: +Required properties for R8A7795, R8A7796, R8A77965 and R8A77990: For the denoted SoCs, "clkp2" can be CANFD clock. This is a div6 clock and can be used by both CAN and CAN FD controller at the same time. It needs to be scaled to maximum frequency if any of these controllers use it. This is done -- 2.18.0
[PATCH 4/4] pinctrl: sh-pfc: r8a77990: Add CAN FD pins, groups and functions
From: Takeshi Kihara
This patch adds CAN FD{0,1} pins, groups and functions to the R8A77990
SoC.
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 35 +--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index db000acc880c..96c2f4fcdb8e 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -1404,6 +1404,25 @@ static const unsigned int can_clk_mux[] = {
CAN_CLK_MARK,
};
+/* - CAN FD --- */
+static const unsigned int canfd0_data_pins[] = {
+ /* TX, RX */
+ RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13),
+};
+
+static const unsigned int canfd0_data_mux[] = {
+ CANFD0_TX_MARK, CANFD0_RX_MARK,
+};
+
+static const unsigned int canfd1_data_pins[] = {
+ /* TX, RX */
+ RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 7),
+};
+
+static const unsigned int canfd1_data_mux[] = {
+ CANFD1_TX_MARK, CANFD1_RX_MARK,
+};
+
/* - DU -
*/
static const unsigned int du_rgb666_pins[] = {
/* R[7:2], G[7:2], B[7:2] */
@@ -2635,7 +2654,7 @@ static const unsigned int usb30_id_mux[] = {
};
static const struct {
- struct sh_pfc_pin_group common[143];
+ struct sh_pfc_pin_group common[145];
struct sh_pfc_pin_group automotive[0];
} pinmux_groups = {
.common = {
@@ -2649,6 +2668,8 @@ static const struct {
SH_PFC_PIN_GROUP(can0_data),
SH_PFC_PIN_GROUP(can1_data),
SH_PFC_PIN_GROUP(can_clk),
+ SH_PFC_PIN_GROUP(canfd0_data),
+ SH_PFC_PIN_GROUP(canfd1_data),
SH_PFC_PIN_GROUP(du_rgb666),
SH_PFC_PIN_GROUP(du_rgb888),
SH_PFC_PIN_GROUP(du_clk_in_0),
@@ -2807,6 +2828,14 @@ static const char * const can_clk_groups[] = {
"can_clk",
};
+static const char * const canfd0_groups[] = {
+ "canfd0_data",
+};
+
+static const char * const canfd1_groups[] = {
+ "canfd1_data",
+};
+
static const char * const du_groups[] = {
"du_rgb666",
"du_rgb888",
@@ -3034,7 +3063,7 @@ static const char * const usb30_groups[] = {
};
static const struct {
- struct sh_pfc_function common[35];
+ struct sh_pfc_function common[37];
struct sh_pfc_function automotive[0];
} pinmux_functions = {
.common = {
@@ -3042,6 +3071,8 @@ static const struct {
SH_PFC_FUNCTION(can0),
SH_PFC_FUNCTION(can1),
SH_PFC_FUNCTION(can_clk),
+ SH_PFC_FUNCTION(canfd0),
+ SH_PFC_FUNCTION(canfd1),
SH_PFC_FUNCTION(du),
SH_PFC_FUNCTION(i2c1),
SH_PFC_FUNCTION(i2c2),
--
2.18.0
[PATCH 3/4] pinctrl: sh-pfc: r8a77990: Add CAN pins, groups and functions
From: Takeshi Kihara
This patch adds CAN{0,1} pins, groups and functions to the R8A77990 SoC.
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 51 +--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index 95d478353627..db000acc880c 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -1375,6 +1375,35 @@ static const unsigned int avb_avtp_capture_a_mux[] = {
AVB_AVTP_CAPTURE_A_MARK,
};
+/* - CAN -- */
+static const unsigned int can0_data_pins[] = {
+ /* TX, RX */
+ RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13),
+};
+
+static const unsigned int can0_data_mux[] = {
+ CAN0_TX_MARK, CAN0_RX_MARK,
+};
+
+static const unsigned int can1_data_pins[] = {
+ /* TX, RX */
+ RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 7),
+};
+
+static const unsigned int can1_data_mux[] = {
+ CAN1_TX_MARK, CAN1_RX_MARK,
+};
+
+/* - CAN Clock --
*/
+static const unsigned int can_clk_pins[] = {
+ /* CLK */
+ RCAR_GP_PIN(0, 14),
+};
+
+static const unsigned int can_clk_mux[] = {
+ CAN_CLK_MARK,
+};
+
/* - DU -
*/
static const unsigned int du_rgb666_pins[] = {
/* R[7:2], G[7:2], B[7:2] */
@@ -2606,7 +2635,7 @@ static const unsigned int usb30_id_mux[] = {
};
static const struct {
- struct sh_pfc_pin_group common[140];
+ struct sh_pfc_pin_group common[143];
struct sh_pfc_pin_group automotive[0];
} pinmux_groups = {
.common = {
@@ -2617,6 +2646,9 @@ static const struct {
SH_PFC_PIN_GROUP(avb_avtp_pps),
SH_PFC_PIN_GROUP(avb_avtp_match_a),
SH_PFC_PIN_GROUP(avb_avtp_capture_a),
+ SH_PFC_PIN_GROUP(can0_data),
+ SH_PFC_PIN_GROUP(can1_data),
+ SH_PFC_PIN_GROUP(can_clk),
SH_PFC_PIN_GROUP(du_rgb666),
SH_PFC_PIN_GROUP(du_rgb888),
SH_PFC_PIN_GROUP(du_clk_in_0),
@@ -2763,6 +2795,18 @@ static const char * const avb_groups[] = {
"avb_avtp_capture_a",
};
+static const char * const can0_groups[] = {
+ "can0_data",
+};
+
+static const char * const can1_groups[] = {
+ "can1_data",
+};
+
+static const char * const can_clk_groups[] = {
+ "can_clk",
+};
+
static const char * const du_groups[] = {
"du_rgb666",
"du_rgb888",
@@ -2990,11 +3034,14 @@ static const char * const usb30_groups[] = {
};
static const struct {
- struct sh_pfc_function common[32];
+ struct sh_pfc_function common[35];
struct sh_pfc_function automotive[0];
} pinmux_functions = {
.common = {
SH_PFC_FUNCTION(avb),
+ SH_PFC_FUNCTION(can0),
+ SH_PFC_FUNCTION(can1),
+ SH_PFC_FUNCTION(can_clk),
SH_PFC_FUNCTION(du),
SH_PFC_FUNCTION(i2c1),
SH_PFC_FUNCTION(i2c2),
--
2.18.0
[PATCH 2/4] pinctrl: sh-pfc: r8a77965: Add CAN FD pins, groups and functions
From: Takeshi Kihara
This patch adds CAN FD{0,1} pins, groups and functions to the R8A77965
SoC.
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 42 +++
1 file changed, 42 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
index 759b10e91d74..e26d101fe51c 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
@@ -1822,6 +1822,34 @@ static const unsigned int can_clk_mux[] = {
CAN_CLK_MARK,
};
+/* - CAN FD --- */
+static const unsigned int canfd0_data_a_pins[] = {
+ /* TX, RX */
+ RCAR_GP_PIN(1, 23), RCAR_GP_PIN(1, 24),
+};
+
+static const unsigned int canfd0_data_a_mux[] = {
+ CANFD0_TX_A_MARK, CANFD0_RX_A_MARK,
+};
+
+static const unsigned int canfd0_data_b_pins[] = {
+ /* TX, RX */
+ RCAR_GP_PIN(2, 0), RCAR_GP_PIN(2, 1),
+};
+
+static const unsigned int canfd0_data_b_mux[] = {
+ CANFD0_TX_B_MARK, CANFD0_RX_B_MARK,
+};
+
+static const unsigned int canfd1_data_pins[] = {
+ /* TX, RX */
+ RCAR_GP_PIN(1, 22), RCAR_GP_PIN(1, 26),
+};
+
+static const unsigned int canfd1_data_mux[] = {
+ CANFD1_TX_MARK, CANFD1_RX_MARK,
+};
+
/* - DU -
*/
static const unsigned int du_rgb666_pins[] = {
/* R[7:2], G[7:2], B[7:2] */
@@ -3796,6 +3824,9 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(can0_data_b),
SH_PFC_PIN_GROUP(can1_data),
SH_PFC_PIN_GROUP(can_clk),
+ SH_PFC_PIN_GROUP(canfd0_data_a),
+ SH_PFC_PIN_GROUP(canfd0_data_b),
+ SH_PFC_PIN_GROUP(canfd1_data),
SH_PFC_PIN_GROUP(du_rgb666),
SH_PFC_PIN_GROUP(du_rgb888),
SH_PFC_PIN_GROUP(du_clk_out_0),
@@ -4091,6 +4122,15 @@ static const char * const can_clk_groups[] = {
"can_clk",
};
+static const char * const canfd0_groups[] = {
+ "canfd0_data_a",
+ "canfd0_data_b",
+};
+
+static const char * const canfd1_groups[] = {
+ "canfd1_data",
+};
+
static const char * const du_groups[] = {
"du_rgb666",
"du_rgb888",
@@ -4453,6 +4493,8 @@ static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(can0),
SH_PFC_FUNCTION(can1),
SH_PFC_FUNCTION(can_clk),
+ SH_PFC_FUNCTION(canfd0),
+ SH_PFC_FUNCTION(canfd1),
SH_PFC_FUNCTION(du),
SH_PFC_FUNCTION(hscif0),
SH_PFC_FUNCTION(hscif1),
--
2.18.0
[PATCH 1/4] pinctrl: sh-pfc: r8a77965: Add CAN pins, groups and functions
From: Takeshi Kihara
This patch adds CAN{0,1} pins, groups and functions to the R8A77965 SoC.
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 58 +++
1 file changed, 58 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
index dfdd982984d4..759b10e91d74 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
@@ -1784,6 +1784,44 @@ static const unsigned int avb_avtp_capture_b_mux[] = {
AVB_AVTP_CAPTURE_B_MARK,
};
+/* - CAN -- */
+static const unsigned int can0_data_a_pins[] = {
+ /* TX, RX */
+ RCAR_GP_PIN(1, 23), RCAR_GP_PIN(1, 24),
+};
+
+static const unsigned int can0_data_a_mux[] = {
+ CAN0_TX_A_MARK, CAN0_RX_A_MARK,
+};
+
+static const unsigned int can0_data_b_pins[] = {
+ /* TX, RX */
+ RCAR_GP_PIN(2, 0), RCAR_GP_PIN(2, 1),
+};
+
+static const unsigned int can0_data_b_mux[] = {
+ CAN0_TX_B_MARK, CAN0_RX_B_MARK,
+};
+
+static const unsigned int can1_data_pins[] = {
+ /* TX, RX */
+ RCAR_GP_PIN(1, 22), RCAR_GP_PIN(1, 26),
+};
+
+static const unsigned int can1_data_mux[] = {
+ CAN1_TX_MARK, CAN1_RX_MARK,
+};
+
+/* - CAN Clock --
*/
+static const unsigned int can_clk_pins[] = {
+ /* CLK */
+ RCAR_GP_PIN(1, 25),
+};
+
+static const unsigned int can_clk_mux[] = {
+ CAN_CLK_MARK,
+};
+
/* - DU -
*/
static const unsigned int du_rgb666_pins[] = {
/* R[7:2], G[7:2], B[7:2] */
@@ -3754,6 +3792,10 @@ 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(can0_data_a),
+ SH_PFC_PIN_GROUP(can0_data_b),
+ SH_PFC_PIN_GROUP(can1_data),
+ SH_PFC_PIN_GROUP(can_clk),
SH_PFC_PIN_GROUP(du_rgb666),
SH_PFC_PIN_GROUP(du_rgb888),
SH_PFC_PIN_GROUP(du_clk_out_0),
@@ -4036,6 +4078,19 @@ static const char * const avb_groups[] = {
"avb_avtp_capture_b",
};
+static const char * const can0_groups[] = {
+ "can0_data_a",
+ "can0_data_b",
+};
+
+static const char * const can1_groups[] = {
+ "can1_data",
+};
+
+static const char * const can_clk_groups[] = {
+ "can_clk",
+};
+
static const char * const du_groups[] = {
"du_rgb666",
"du_rgb888",
@@ -4395,6 +4450,9 @@ static const char * const usb30_groups[] = {
static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(audio_clk),
SH_PFC_FUNCTION(avb),
+ SH_PFC_FUNCTION(can0),
+ SH_PFC_FUNCTION(can1),
+ SH_PFC_FUNCTION(can_clk),
SH_PFC_FUNCTION(du),
SH_PFC_FUNCTION(hscif0),
SH_PFC_FUNCTION(hscif1),
--
2.18.0
Re: [PATCH] arm64: defconfig: Enable CONFIG_PHY_RCAR_GEN3_PCIE
On 11/15/2018 03:33 PM, Simon Horman wrote: > On Wed, Nov 14, 2018 at 04:32:05PM +0100, Marek Vasut wrote: >> On 11/13/2018 04:22 PM, Geert Uytterhoeven wrote: >>> Enable R-Car Gen3 PCIe PHY support, which is needed for PCIe to function >>> on the Renesas Condor board. >>> >>> Signed-off-by: Geert Uytterhoeven >> >> This helps >> >> Reviewed-by: Marek Vasut > > Thanks, would it be better to use enable this driver as a module rather > than a built-in? I think not, since the pcie-rcar cannot be compiled in as module, so the associated phy driver shouldn't be compiled in as module either. >>> --- >>> arch/arm64/configs/defconfig | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig >>> index 9d0b42d96f03156e..77f98a7e860b8850 100644 >>> --- a/arch/arm64/configs/defconfig >>> +++ b/arch/arm64/configs/defconfig >>> @@ -657,6 +657,7 @@ CONFIG_PHY_HISI_INNO_USB2=y >>> CONFIG_PHY_MVEBU_CP110_COMPHY=y >>> CONFIG_PHY_QCOM_QMP=m >>> CONFIG_PHY_QCOM_USB_HS=y >>> +CONFIG_PHY_RCAR_GEN3_PCIE=y >>> CONFIG_PHY_RCAR_GEN3_USB2=y >>> CONFIG_PHY_RCAR_GEN3_USB3=m >>> CONFIG_PHY_ROCKCHIP_EMMC=y >>> >> >> >> -- >> Best regards, >> Marek Vasut >> -- Best regards, Marek Vasut
Re: [PATCH] arm64: defconfig: Enable CONFIG_PHY_RCAR_GEN3_PCIE
On 11/13/2018 04:22 PM, Geert Uytterhoeven wrote: > Enable R-Car Gen3 PCIe PHY support, which is needed for PCIe to function > on the Renesas Condor board. > > Signed-off-by: Geert Uytterhoeven This helps Reviewed-by: Marek Vasut > --- > arch/arm64/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index 9d0b42d96f03156e..77f98a7e860b8850 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -657,6 +657,7 @@ CONFIG_PHY_HISI_INNO_USB2=y > CONFIG_PHY_MVEBU_CP110_COMPHY=y > CONFIG_PHY_QCOM_QMP=m > CONFIG_PHY_QCOM_USB_HS=y > +CONFIG_PHY_RCAR_GEN3_PCIE=y > CONFIG_PHY_RCAR_GEN3_USB2=y > CONFIG_PHY_RCAR_GEN3_USB3=m > CONFIG_PHY_ROCKCHIP_EMMC=y > -- Best regards, Marek Vasut
[PATCH] arm64: dts: renesas: r8a77990: ebisu: Add and enable PCIe device node
From: Takeshi Kihara
This patch adds PCI express channel 0 device node to the R8A77990 SoC
and enables PCIEC0 PCI express controller on the Ebisu board.
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
To: devicet...@vger.kernel.org
---
.../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 8 +
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 34 +++
2 files changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 447e9831104a..2ef9067616ee 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -444,6 +444,14 @@
status = "okay";
};
+_bus_clk {
+ clock-frequency = <1>;
+};
+
+ {
+ status = "okay";
+};
+
{
avb_pins: avb {
mux {
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index a2524fc138a2..46868dacbeef 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -85,6 +85,13 @@
clock-frequency = <0>;
};
+ /* External PCIe clock - can be overridden by the board */
+ pcie_bus_clk: pcie_bus {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
pmu_a53 {
compatible = "arm,cortex-a53-pmu";
interrupts-extended = < GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
@@ -1610,6 +1617,33 @@
};
};
+ pciec0: pcie@fe00 {
+ compatible = "renesas,pcie-r8a77990",
+"renesas,pcie-rcar-gen3";
+ reg = <0 0xfe00 0 0x8>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ ranges = <0x0100 0 0x 0 0xfe10 0
0x0010
+ 0x0200 0 0xfe20 0 0xfe20 0
0x0020
+ 0x0200 0 0x3000 0 0x3000 0
0x0800
+ 0x4200 0 0x3800 0 0x3800 0
0x0800>;
+ /* Map all possible DDR as inbound ranges */
+ dma-ranges = <0x4200 0 0x4000 0 0x4000 0
0x4000>;
+ interrupts = ,
+ ,
+ ;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 GIC_SPI 116
IRQ_TYPE_LEVEL_HIGH>;
+ clocks = < CPG_MOD 319>, <_bus_clk>;
+ clock-names = "pcie", "pcie_bus";
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 319>;
+ status = "disabled";
+ };
+
prr: chipid@fff00044 {
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
--
2.18.0
Re: [renesas:arm64-dt-for-v4.21 25/25] Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:622.1-7 Label or path sdhi0 not found
On 11/08/2018 11:33 AM, Simon Horman wrote: > On Wed, Nov 07, 2018 at 03:04:51PM +0100, Marek Vasut wrote: >> On 11/07/2018 02:57 PM, kbuild test robot wrote: >>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git >>> arm64-dt-for-v4.21 >>> head: 3e8f76c61511f3c4f0c25c36172605d6aeaec37c >>> commit: 3e8f76c61511f3c4f0c25c36172605d6aeaec37c [25/25] arm64: dts: >>> r8a77990: ebisu: Add and enable SDHI device nodes >>> config: arm64-defconfig (attached as .config) >>> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 >>> reproduce: >>> wget >>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O >>> ~/bin/make.cross >>> chmod +x ~/bin/make.cross >>> git checkout 3e8f76c61511f3c4f0c25c36172605d6aeaec37c >>> # save the attached .config to linux build tree >>> GCC_VERSION=7.2.0 make.cross ARCH=arm64 >>> >>> All errors (new ones prefixed by >>): >>> >>>>> Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:622.1-7 Label or >>>>> path sdhi0 not found >>>>> Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:637.1-7 Label or >>>>> path sdhi1 not found >>>>> Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:651.1-7 Label or >>>>> path sdhi3 not found >>>>> FATAL ERROR: Syntax error parsing input tree >> >> Commit 3e8f76c61511f3c4f0c25c36172605d6aeaec37c seems to be missing the >> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 36 + >> part from >> [PATCH V3] arm64: dts: r8a77990: ebisu: Add and enable SDHI device nodes >> thus the error. > > Sorry about that, will fix ASAP. No problem, thanks! -- Best regards, Marek Vasut
Re: [PATCH V3] arm64: dts: r8a77990: ebisu: Add and enable SDHI device nodes
On 11/07/2018 08:23 PM, Wolfram Sang wrote: > >> We discussed this on IRC already, which is why I need to look into that. >> The HS200 works well on the M3N though. > > Can you push the branch you used somewhere? I retested the branch from > Dunbar with my M3N and it works fine with my tests. Sure. btw I think this might even have something to do with ATF 1.0.24 or mainline U-Boot, which switches the eMMC card to HS200 mode. -- Best regards, Marek Vasut
Re: [renesas:arm64-dt-for-v4.21 25/25] Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:622.1-7 Label or path sdhi0 not found
On 11/07/2018 02:57 PM, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git > arm64-dt-for-v4.21 > head: 3e8f76c61511f3c4f0c25c36172605d6aeaec37c > commit: 3e8f76c61511f3c4f0c25c36172605d6aeaec37c [25/25] arm64: dts: > r8a77990: ebisu: Add and enable SDHI device nodes > config: arm64-defconfig (attached as .config) > compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > git checkout 3e8f76c61511f3c4f0c25c36172605d6aeaec37c > # save the attached .config to linux build tree > GCC_VERSION=7.2.0 make.cross ARCH=arm64 > > All errors (new ones prefixed by >>): > >>> Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:622.1-7 Label or path >>> sdhi0 not found >>> Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:637.1-7 Label or path >>> sdhi1 not found >>> Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:651.1-7 Label or path >>> sdhi3 not found >>> FATAL ERROR: Syntax error parsing input tree Commit 3e8f76c61511f3c4f0c25c36172605d6aeaec37c seems to be missing the arch/arm64/boot/dts/renesas/r8a77990.dtsi | 36 + part from [PATCH V3] arm64: dts: r8a77990: ebisu: Add and enable SDHI device nodes thus the error. -- Best regards, Marek Vasut
Re: [PATCH V3] arm64: dts: r8a77990: ebisu: Add and enable SDHI device nodes
On 11/07/2018 02:08 PM, Wolfram Sang wrote: > >> Nope. I tried that patchset on M3N again yesterday and got error -84 >> while initing the eMMC, so I need to look into that first. Then I'll >> try it on E3. > > Hmmm, we tried M3N at the hackfest and it worked great there. > > First idea: are you sure you have all depending patch series applied as > well? > > @Niklas: Have you/can you push a publich branch out with everything > included. We discussed this on IRC already, which is why I need to look into that. The HS200 works well on the M3N though. -- Best regards, Marek Vasut
Re: [PATCH V3] arm64: dts: r8a77990: ebisu: Add and enable SDHI device nodes
On 11/07/2018 09:50 AM, Wolfram Sang wrote:
> On Tue, Nov 06, 2018 at 09:46:47PM +0100, Marek Vasut wrote:
>> From: Takeshi Kihara
>>
>> This patch adds SDHI{0,1,3} device nodes for the r8a77990 SoC
>> and enables SD card slot connected to SDHI0, micro SD card slot
>> connected to SDHI1 and eMMC connected to SDHI3 on the Ebisu board
>> using the R8A77990 SoC.
>>
>> Signed-off-by: Takeshi Kihara
>> Signed-off-by: Marek Vasut
>
> Acked-by: Wolfram Sang
>
> Out of curiosity: have you tested HS400 on that board based on Niklas'
> recent patches as well?
Nope. I tried that patchset on M3N again yesterday and got error -84
while initing the eMMC, so I need to look into that first. Then I'll
try it on E3.
--
Best regards,
Marek Vasut
Re: [PATCH 1/2] arm64: dts: r8a77990: Add SDHI device nodes
On 11/06/2018 11:35 AM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Tue, Nov 6, 2018 at 11:32 AM Marek Vasut wrote:
>> On 11/06/2018 06:26 AM, Yoshihiro Shimoda wrote:
>>>> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:41 AM
>>>>
>>>> From: Takeshi Kihara
>>>>
>>>> This patch adds SDHI{0,1,3} device nodes for the r8a77990 SoC.
>>>>
>>>> Signed-off-by: Takeshi Kihara
>>>> Signed-off-by: Marek Vasut
>>>> Cc: Geert Uytterhoeven
>>>> Cc: Simon Horman
>>>> Cc: Wolfram Sang
>>>> Cc: Yoshihiro Shimoda
>>>> Cc: linux-renesas-soc@vger.kernel.org
>>>> Cc: linux-arm-ker...@lists.infradead.org
>>>> ---
>>>
>>> Thank you for the patch!
>>>
>>> Reviewed-by: Yoshihiro Shimoda
>>>
>>> I guess this patch and the 2/2 patch for ebisu have to be merged into a
>>> patch though.
>>
>> I wonder about that, 1/2 is adding SDHI DT nodes for an SoC, 2/2 is
>> enabling SDHI on a particular board, which I think should be separate.
>
> The arm-soc maintainers tend to disagree, that's why Shimoda-san asked
> to combine them.
Combined patch is out.
--
Best regards,
Marek Vasut
[PATCH V3] arm64: dts: r8a77990: ebisu: Add and enable SDHI device nodes
From: Takeshi Kihara
This patch adds SDHI{0,1,3} device nodes for the r8a77990 SoC
and enables SD card slot connected to SDHI0, micro SD card slot
connected to SDHI1 and eMMC connected to SDHI3 on the Ebisu board
using the R8A77990 SoC.
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
V2: - Deduplicated regular and UHS pins
- Added sdhi3_ds pin pinmux
V3: - Squash two patches, one adding SDHI nodes to R8A77990 E3 DTSI
and another enabling them on E3 Ebisu, together.
---
.../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 130 ++
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 36 +
2 files changed, 166 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 0b5aead76077..306b35f0f541 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -129,6 +129,15 @@
};
};
+ reg_1p8v: regulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
reg_3p3v: regulator1 {
compatible = "regulator-fixed";
regulator-name = "fixed-3.3V";
@@ -180,6 +189,54 @@
#clock-cells = <0>;
clock-frequency = <7425>;
};
+
+ vcc_sdhi0: regulator-vcc-sdhi0 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI0 Vcc";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+
+ gpio = < 17 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vccq_sdhi0: regulator-vccq-sdhi0 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI0 VccQ";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = < 18 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <330 1
+ 180 0>;
+ };
+
+ vcc_sdhi1: regulator-vcc-sdhi1 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI1 Vcc";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+
+ gpio = < 4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vccq_sdhi1: regulator-vccq-sdhi1 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI1 VccQ";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = < 15 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <330 1
+ 180 0>;
+ };
};
_clk_a {
@@ -415,6 +472,36 @@
function = "scif2";
};
+ sdhi0_pins: sd0 {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <3300>;
+ };
+
+ sdhi0_pins_uhs: sd0_uhs {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <1800>;
+ };
+
+ sdhi1_pins: sd1 {
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
+ power-source = <3300>;
+ };
+
+ sdhi1_pins_uhs: sd1_uhs {
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
+ power-source = <1800>;
+ };
+
+ sdhi3_pins: sd3 {
+ groups = "sdhi3_data8", "sdhi3_ctrl", "sdhi3_ds";
+ function = "sdhi3";
+ power-source = <1800>;
+ };
+
sound_pins: sound {
groups = "ssi01239_ctrl", "ssi0_data", "ssi1_data";
function = "ssi";
@@ -531,3 +618,46 @@
status = "okay";
};
+
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-1 = <_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
Re: [PATCH 1/2] pinctrl: sh-pfc: r8a77990: Add SDHI pins, groups and functions
On 11/06/2018 12:14 PM, Wolfram Sang wrote:
>
>> static const struct {
>> -struct sh_pfc_pin_group common[123];
>> +struct sh_pfc_pin_group common[140];
>> struct sh_pfc_pin_group automotive[0];
>> } pinmux_groups = {
>
> ...
>
>> static const struct {
>> -struct sh_pfc_function common[29];
>> +struct sh_pfc_function common[32];
>> struct sh_pfc_function automotive[0];
>> } pinmux_functions = {
>
>
> It is Geert's call, but maybe those are a seperate patch?
These must be part of this patch, since adding
+ SH_PFC_PIN_GROUP(sdhi0_data1),
entries grows the size of the array. If you were to split this patch,
the PFC driver would break, as the size of the array won't match the
size of the content.
--
Best regards,
Marek Vasut
Re: [RFC][PATCH] PCI: Avoid PCI device removing/rescanning through sysfs triggers a deadlock
On 11/06/2018 09:13 AM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> Thanks for your patch!
>
> On Tue, Nov 6, 2018 at 12:25 AM Marek Vasut wrote:
>> From: Tho Vu
>>
>> This patch fixes deadlock warning in removing/rescanning through sysfs
>> when CONFIG_PROVE_LOCKING is enabled.
>>
>> The issue can be reproduced by these steps:
>> 1. Enable CONFIG_PROVE_LOCKING via defconfig or menuconfig
>> 2. Insert Ethernet card into PCIe CH0 and start up.
>>After kernel starting up, execute the following command.
>>echo 1 > /sys/class/pci_bus/\:00/device/\:00\:00.0/remove
>> 3. Rescan PCI device by this command
>>echo 1 > /sys/class/pci_bus/\:00/rescan
>>
>> The deadlock warnings will occur.
>>
>> WARNING: possible recursive locking detected
>> 4.14.70-ltsi-yocto-standard #27 Not tainted
>>
>> sh/3402 is trying to acquire lock:
>> (kn->count#78){}, at: kernfs_remove_by_name_ns+0x50/0xa8
>>
>> but task is already holding lock:
>> (kn->count#78){}, at: kernfs_remove_self+0xe0/0x130
>>
>> other info that might help us debug this:
>> Possible unsafe locking scenario:
>>
>>CPU0
>>
>> lock(kn->count#78);
>> lock(kn->count#78);
>>
>> *** DEADLOCK ***
>>
>> May be due to missing lock nesting notation
>>
>> 4 locks held by sh/3402:
>> #0: (sb_writers#4){.+.+}, at: vfs_write+0x198/0x1b0
>> #1: (>mutex){+.+.}, at: kernfs_fop_write+0x108/0x210
>> #2: (kn->count#78){}, at: kernfs_remove_self+0xe0/0x130
>> #3: (pci_rescan_remove_lock){+.+.}, at: pci_lock_rescan_remove+0x1c/0x28
>>
>> stack backtrace:
>> CPU: 3 PID: 3402 Comm: sh Not tainted 4.14.70-ltsi-yocto-standard #27
>> Hardware name: Renesas Salvator-X 2nd version board based on r8a7795
>> ES3.0+ with 8GiB (4 x 2 GiB) (DT)
>> Call trace:
>> dump_backtrace+0x0/0x3d8
>> show_stack+0x14/0x20
>> dump_stack+0xbc/0xf4
>> __lock_acquire+0x930/0x18a8
>> lock_acquire+0x48/0x68
>> __kernfs_remove+0x280/0x2f8
>> kernfs_remove_by_name_ns+0x50/0xa8
>> remove_files.isra.0+0x38/0x78
>> sysfs_remove_group+0x4c/0xa0
>> sysfs_remove_groups+0x38/0x60
>> device_remove_attrs+0x54/0x78
>> device_del+0x1ac/0x308
>> pci_remove_bus_device+0x78/0xf8
>> pci_remove_bus_device+0x34/0xf8
>> pci_stop_and_remove_bus_device_locked+0x24/0x38
>> remove_store+0x6c/0x78
>> dev_attr_store+0x18/0x28
>> sysfs_kf_write+0x4c/0x78
>> kernfs_fop_write+0x138/0x210
>> __vfs_write+0x18/0x118
>> vfs_write+0xa4/0x1b0
>> SyS_write+0x48/0xb0
>>
>> This warning occurs due to a self-deletion attribute using in the sysfs
>
> used
>
>> PCI device directory. This kind of attribute is really tricky,
>> it does not allow pci framework drop this attribute until all active
>
> to drop
>
>> .show() and .store() callbacks have finished unless
>
> finished, unless
>
>> sysfs_break_active_protection() is called.
>> Hence this patch avoids writing into this attribute triggers a deadlock.
>
> and trigger a deadlock.
>
>>
>> Referrence commit 5b55b24cec4c ("scsi: core: Avoid that SCSI device
>> removal through sysfs triggers a deadlock")
>> of scsi driver
>>
>> Signed-off-by: Tho Vu
>
> You forgot to append your own SoB?
>
>> --- a/drivers/pci/pci-sysfs.c
>> +++ b/drivers/pci/pci-sysfs.c
>> @@ -470,12 +470,22 @@ static ssize_t remove_store(struct device *dev, struct
>> device_attribute *attr,
>> const char *buf, size_t count)
>> {
>> unsigned long val;
>> + struct kernfs_node *kn;
>> +
>> + kn = sysfs_break_active_protection(>kobj, >attr);
>> + WARN_ON_ONCE(!kn);
>
> What's the purpose of the WARN_ON_ONCE? Just copied from the SCSI solution?
> Can this ever happen?
I sent the patch as-is from the BSP after a short discussion with Bjorn
on IRC, mostly because it contains the description of the problem. I
don't think this is the right solution, it feels more like a hack to me,
which is why I flagged it as RFC.
Or do you think this is the correct way of solving the problem ?
--
Best regards,
Marek Vasut
Re: [PATCH 1/2] arm64: dts: r8a77990: Add SDHI device nodes
On 11/06/2018 06:26 AM, Yoshihiro Shimoda wrote:
> Hello Marek-san,
Hello Shimoda-san,
>> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:41 AM
>>
>> From: Takeshi Kihara
>>
>> This patch adds SDHI{0,1,3} device nodes for the r8a77990 SoC.
>>
>> Signed-off-by: Takeshi Kihara
>> Signed-off-by: Marek Vasut
>> Cc: Geert Uytterhoeven
>> Cc: Simon Horman
>> Cc: Wolfram Sang
>> Cc: Yoshihiro Shimoda
>> Cc: linux-renesas-soc@vger.kernel.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> ---
>
> Thank you for the patch!
>
> Reviewed-by: Yoshihiro Shimoda
>
> I guess this patch and the 2/2 patch for ebisu have to be merged into a patch
> though.
I wonder about that, 1/2 is adding SDHI DT nodes for an SoC, 2/2 is
enabling SDHI on a particular board, which I think should be separate.
--
Best regards,
Marek Vasut
Re: [PATCH 2/2] arm64: dts: r8a77990: ebisu: Enable SDHI interfaces
On 11/06/2018 09:34 AM, Wolfram Sang wrote:
>
>> +sdhi3_pins: sd3 {
>> +groups = "sdhi3_data8", "sdhi3_ctrl";
>> +function = "sdhi3";
>> +power-source = <1800>;
>> +};
>> +
>> +sdhi3_pins_uhs: sd3_uhs {
>> +groups = "sdhi3_data8", "sdhi3_ctrl";
>> +function = "sdhi3";
>> +power-source = <1800>;
>> +};
>
> Shouldn't we have only one pinctrl config here, like you did recently
> for the other Gen3 SoCs?
We should, thanks for pointing it out, fixed in V2.
--
Best regards,
Marek Vasut
Re: [PATCH 2/2] arm64: dts: r8a77990: ebisu: Enable SDHI interfaces
On 11/06/2018 06:29 AM, Yoshihiro Shimoda wrote:
> Hello Marek-san,
Hello Shimoda-san,
>> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:41 AM
>>
>> From: Takeshi Kihara
>>
>> This patch enables SD card slot connected to SDHI0, micro SD card slot
>> connected to SDHI1 and eMMC connected to SDHI3 on the Ebisu board using
>> the R8A77990 SoC.
>>
>> Signed-off-by: Takeshi Kihara
>> Signed-off-by: Marek Vasut
>> Cc: Geert Uytterhoeven
>> Cc: Simon Horman
>> Cc: Wolfram Sang
>> Cc: Yoshihiro Shimoda
>> Cc: linux-renesas-soc@vger.kernel.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> ---
>
> Thank you for the patch!
>
> Reviewed-by: Yoshihiro Shimoda
>
> I have a few nit comments below.
>
>> .../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 136 ++
>> 1 file changed, 136 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
>> b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
>> index 611f0265fcc5..bda1765dcdbd 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
>> +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
>
>> +sdhi3_pins: sd3 {
>> +groups = "sdhi3_data8", "sdhi3_ctrl";
>> +function = "sdhi3";
>> +power-source = <1800>;
>> +};
>> +
>> +sdhi3_pins_uhs: sd3_uhs {
>> +groups = "sdhi3_data8", "sdhi3_ctrl";
>> +function = "sdhi3";
>> +power-source = <1800>;
>> +};
>
> I assumed that we will add "sdhi3_ds" into these groups when we add support
> for HS400 mode.
That's a good point, I think we can add it right away, so added in V2.
--
Best regards,
Marek Vasut
[RFC][PATCH] PCI: Avoid PCI device removing/rescanning through sysfs triggers a deadlock
From: Tho Vu
This patch fixes deadlock warning in removing/rescanning through sysfs
when CONFIG_PROVE_LOCKING is enabled.
The issue can be reproduced by these steps:
1. Enable CONFIG_PROVE_LOCKING via defconfig or menuconfig
2. Insert Ethernet card into PCIe CH0 and start up.
After kernel starting up, execute the following command.
echo 1 > /sys/class/pci_bus/\:00/device/\:00\:00.0/remove
3. Rescan PCI device by this command
echo 1 > /sys/class/pci_bus/\:00/rescan
The deadlock warnings will occur.
WARNING: possible recursive locking detected
4.14.70-ltsi-yocto-standard #27 Not tainted
sh/3402 is trying to acquire lock:
(kn->count#78){}, at: kernfs_remove_by_name_ns+0x50/0xa8
but task is already holding lock:
(kn->count#78){}, at: kernfs_remove_self+0xe0/0x130
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(kn->count#78);
lock(kn->count#78);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by sh/3402:
#0: (sb_writers#4){.+.+}, at: vfs_write+0x198/0x1b0
#1: (>mutex){+.+.}, at: kernfs_fop_write+0x108/0x210
#2: (kn->count#78){}, at: kernfs_remove_self+0xe0/0x130
#3: (pci_rescan_remove_lock){+.+.}, at: pci_lock_rescan_remove+0x1c/0x28
stack backtrace:
CPU: 3 PID: 3402 Comm: sh Not tainted 4.14.70-ltsi-yocto-standard #27
Hardware name: Renesas Salvator-X 2nd version board based on r8a7795
ES3.0+ with 8GiB (4 x 2 GiB) (DT)
Call trace:
dump_backtrace+0x0/0x3d8
show_stack+0x14/0x20
dump_stack+0xbc/0xf4
__lock_acquire+0x930/0x18a8
lock_acquire+0x48/0x68
__kernfs_remove+0x280/0x2f8
kernfs_remove_by_name_ns+0x50/0xa8
remove_files.isra.0+0x38/0x78
sysfs_remove_group+0x4c/0xa0
sysfs_remove_groups+0x38/0x60
device_remove_attrs+0x54/0x78
device_del+0x1ac/0x308
pci_remove_bus_device+0x78/0xf8
pci_remove_bus_device+0x34/0xf8
pci_stop_and_remove_bus_device_locked+0x24/0x38
remove_store+0x6c/0x78
dev_attr_store+0x18/0x28
sysfs_kf_write+0x4c/0x78
kernfs_fop_write+0x138/0x210
__vfs_write+0x18/0x118
vfs_write+0xa4/0x1b0
SyS_write+0x48/0xb0
This warning occurs due to a self-deletion attribute using in the sysfs
PCI device directory. This kind of attribute is really tricky,
it does not allow pci framework drop this attribute until all active
.show() and .store() callbacks have finished unless
sysfs_break_active_protection() is called.
Hence this patch avoids writing into this attribute triggers a deadlock.
Referrence commit 5b55b24cec4c ("scsi: core: Avoid that SCSI device
removal through sysfs triggers a deadlock")
of scsi driver
Signed-off-by: Tho Vu
---
drivers/pci/pci-sysfs.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 9ecfe13157c0..d522bd8368d9 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -470,12 +470,22 @@ static ssize_t remove_store(struct device *dev, struct
device_attribute *attr,
const char *buf, size_t count)
{
unsigned long val;
+ struct kernfs_node *kn;
+
+ kn = sysfs_break_active_protection(>kobj, >attr);
+ WARN_ON_ONCE(!kn);
if (kstrtoul(buf, 0, ) < 0)
return -EINVAL;
- if (val && device_remove_file_self(dev, attr))
+ if (val) {
+ device_remove_file(dev, attr);
pci_stop_and_remove_bus_device_locked(to_pci_dev(dev));
+ }
+
+ if (kn)
+ sysfs_unbreak_active_protection(kn);
+
return count;
}
static struct device_attribute dev_remove_attr = __ATTR(remove,
@@ -487,11 +497,15 @@ static ssize_t dev_bus_rescan_store(struct device *dev,
const char *buf, size_t count)
{
unsigned long val;
+ struct kernfs_node *kn;
struct pci_bus *bus = to_pci_bus(dev);
if (kstrtoul(buf, 0, ) < 0)
return -EINVAL;
+ kn = sysfs_break_active_protection(>kobj, >attr);
+ WARN_ON_ONCE(!kn);
+
if (val) {
pci_lock_rescan_remove();
if (!pci_is_root_bus(bus) && list_empty(>devices))
@@ -500,6 +514,10 @@ static ssize_t dev_bus_rescan_store(struct device *dev,
pci_rescan_bus(bus);
pci_unlock_rescan_remove();
}
+
+ if (kn)
+ sysfs_unbreak_active_protection(kn);
+
return count;
}
static DEVICE_ATTR(rescan, (S_IWUSR|S_IWGRP), NULL, dev_bus_rescan_store);
--
2.18.0
[PATCH 1/2] arm64: dts: r8a77990: Add SDHI device nodes
From: Takeshi Kihara
This patch adds SDHI{0,1,3} device nodes for the r8a77990 SoC.
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 36 +++
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 9509dc05665f..fb0818d07cdb 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -826,6 +826,42 @@
status = "disabled";
};
+ sdhi0: sd@ee10 {
+ compatible = "renesas,sdhi-r8a77990",
+"renesas,rcar-gen3-sdhi";
+ reg = <0 0xee10 0 0x2000>;
+ interrupts = ;
+ clocks = < CPG_MOD 314>;
+ max-frequency = <2>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 314>;
+ status = "disabled";
+ };
+
+ sdhi1: sd@ee12 {
+ compatible = "renesas,sdhi-r8a77990",
+"renesas,rcar-gen3-sdhi";
+ reg = <0 0xee12 0 0x2000>;
+ interrupts = ;
+ clocks = < CPG_MOD 313>;
+ max-frequency = <2>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 313>;
+ status = "disabled";
+ };
+
+ sdhi3: sd@ee16 {
+ compatible = "renesas,sdhi-r8a77990",
+"renesas,rcar-gen3-sdhi";
+ reg = <0 0xee16 0 0x2000>;
+ interrupts = ;
+ clocks = < CPG_MOD 311>;
+ max-frequency = <2>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 311>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@f101 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
--
2.18.0
[PATCH 2/2] arm64: dts: r8a77990: ebisu: Enable SDHI interfaces
From: Takeshi Kihara
This patch enables SD card slot connected to SDHI0, micro SD card slot
connected to SDHI1 and eMMC connected to SDHI3 on the Ebisu board using
the R8A77990 SoC.
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
.../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 136 ++
1 file changed, 136 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 611f0265fcc5..bda1765dcdbd 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -119,6 +119,15 @@
};
};
+ reg_1p8v: regulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
reg_3p3v: regulator1 {
compatible = "regulator-fixed";
regulator-name = "fixed-3.3V";
@@ -133,6 +142,54 @@
#clock-cells = <0>;
clock-frequency = <7425>;
};
+
+ vcc_sdhi0: regulator-vcc-sdhi0 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI0 Vcc";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+
+ gpio = < 17 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vccq_sdhi0: regulator-vccq-sdhi0 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI0 VccQ";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = < 18 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <330 1
+ 180 0>;
+ };
+
+ vcc_sdhi1: regulator-vcc-sdhi1 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI1 Vcc";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+
+ gpio = < 4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vccq_sdhi1: regulator-vccq-sdhi1 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI1 VccQ";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = < 15 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <330 1
+ 180 0>;
+ };
};
{
@@ -326,6 +383,42 @@
function = "scif2";
};
+ sdhi0_pins: sd0 {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <3300>;
+ };
+
+ sdhi0_pins_uhs: sd0_uhs {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <1800>;
+ };
+
+ sdhi1_pins: sd1 {
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
+ power-source = <3300>;
+ };
+
+ sdhi1_pins_uhs: sd1_uhs {
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
+ power-source = <1800>;
+ };
+
+ sdhi3_pins: sd3 {
+ groups = "sdhi3_data8", "sdhi3_ctrl";
+ function = "sdhi3";
+ power-source = <1800>;
+ };
+
+ sdhi3_pins_uhs: sd3_uhs {
+ groups = "sdhi3_data8", "sdhi3_ctrl";
+ function = "sdhi3";
+ power-source = <1800>;
+ };
+
usb0_pins: usb {
groups = "usb0_b";
function = "usb0";
@@ -380,3 +473,46 @@
status = "okay";
};
+
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-1 = <_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <_sdhi0>;
+ vqmmc-supply = <_sdhi0>;
+ cd-gpios = < 12 GPIO_ACTIVE_LOW>;
+ wp-gpios = < 13 GPIO_ACTIVE_HIGH>;
+ bus-w
[PATCH 2/2] pinctrl: sh-pfc: r8a77990: Add voltage switch operations for SDHI
From: Takeshi Kihara
This patch supports the {get,set}_io_voltage operations of SDHI.
This operates the IOCTRL30 register on the R8A77990 SoC and makes
1.8V/3.3V signal voltage switch possible.
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 35 +--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index 97aba270a515..95d478353627 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -23,8 +23,12 @@
PORT_GP_CFG_18(0, fn, sfx, CFG_FLAGS), \
PORT_GP_CFG_23(1, fn, sfx, CFG_FLAGS), \
PORT_GP_CFG_26(2, fn, sfx, CFG_FLAGS), \
- PORT_GP_CFG_16(3, fn, sfx, CFG_FLAGS), \
- PORT_GP_CFG_11(4, fn, sfx, CFG_FLAGS), \
+ PORT_GP_CFG_12(3, fn, sfx, CFG_FLAGS | SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(3, 12, fn, sfx, CFG_FLAGS), \
+ PORT_GP_CFG_1(3, 13, fn, sfx, CFG_FLAGS), \
+ PORT_GP_CFG_1(3, 14, fn, sfx, CFG_FLAGS), \
+ PORT_GP_CFG_1(3, 15, fn, sfx, CFG_FLAGS), \
+ PORT_GP_CFG_11(4, fn, sfx, CFG_FLAGS | SH_PFC_PIN_CFG_IO_VOLTAGE), \
PORT_GP_CFG_20(5, fn, sfx, CFG_FLAGS), \
PORT_GP_CFG_18(6, fn, sfx, CFG_FLAGS)
/*
@@ -3494,6 +3498,31 @@ static const struct pinmux_cfg_reg pinmux_config_regs[]
= {
{ },
};
+enum ioctrl_regs {
+ IOCTRL30,
+};
+
+static const struct pinmux_ioctrl_reg pinmux_ioctrl_regs[] = {
+ [IOCTRL30] = { 0xe6060380, },
+ { /* sentinel */ },
+};
+
+static int r8a77990_pin_to_pocctrl(struct sh_pfc *pfc, unsigned int pin,
+ u32 *pocctrl)
+{
+ int bit = -EINVAL;
+
+ *pocctrl = pinmux_ioctrl_regs[IOCTRL30].reg;
+
+ if (pin >= RCAR_GP_PIN(3, 0) && pin <= RCAR_GP_PIN(3, 11))
+ bit = pin & 0x1f;
+
+ if (pin >= RCAR_GP_PIN(4, 0) && pin <= RCAR_GP_PIN(4, 10))
+ bit = (pin & 0x1f) + 19;
+
+ return bit;
+}
+
static const struct pinmux_bias_reg pinmux_bias_regs[] = {
{ PINMUX_BIAS_REG("PUEN0", 0xe6060400, "PUD0", 0xe6060440) {
[0] = RCAR_GP_PIN(2, 23), /* RD# */
@@ -3744,6 +3773,7 @@ static void r8a77990_pinmux_set_bias(struct sh_pfc *pfc,
unsigned int pin,
}
static const struct sh_pfc_soc_operations r8a77990_pinmux_ops = {
+ .pin_to_pocctrl = r8a77990_pin_to_pocctrl,
.get_bias = r8a77990_pinmux_get_bias,
.set_bias = r8a77990_pinmux_set_bias,
};
@@ -3790,6 +3820,7 @@ const struct sh_pfc_soc_info r8a77990_pinmux_info = {
.cfg_regs = pinmux_config_regs,
.bias_regs = pinmux_bias_regs,
+ .ioctrl_regs = pinmux_ioctrl_regs,
.pinmux_data = pinmux_data,
.pinmux_data_size = ARRAY_SIZE(pinmux_data),
--
2.18.0
[PATCH 1/2] pinctrl: sh-pfc: r8a77990: Add SDHI pins, groups and functions
From: Takeshi Kihara
This patch adds SDHI{0,1,3} pins, groups and functions to the R8A77990
SoC.
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 218 +-
1 file changed, 216 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index 1fdafa48479c..97aba270a515 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -2386,6 +2386,174 @@ static const unsigned int scif_clk_b_mux[] = {
SCIF_CLK_B_MARK,
};
+/* - SDHI0 --
*/
+static const unsigned int sdhi0_data1_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(3, 2),
+};
+
+static const unsigned int sdhi0_data1_mux[] = {
+ SD0_DAT0_MARK,
+};
+
+static const unsigned int sdhi0_data4_pins[] = {
+ /* D[0:3] */
+ RCAR_GP_PIN(3, 2), RCAR_GP_PIN(3, 3),
+ RCAR_GP_PIN(3, 4), RCAR_GP_PIN(3, 5),
+};
+
+static const unsigned int sdhi0_data4_mux[] = {
+ SD0_DAT0_MARK, SD0_DAT1_MARK,
+ SD0_DAT2_MARK, SD0_DAT3_MARK,
+};
+
+static const unsigned int sdhi0_ctrl_pins[] = {
+ /* CLK, CMD */
+ RCAR_GP_PIN(3, 0), RCAR_GP_PIN(3, 1),
+};
+
+static const unsigned int sdhi0_ctrl_mux[] = {
+ SD0_CLK_MARK, SD0_CMD_MARK,
+};
+
+static const unsigned int sdhi0_cd_pins[] = {
+ /* CD */
+ RCAR_GP_PIN(3, 12),
+};
+
+static const unsigned int sdhi0_cd_mux[] = {
+ SD0_CD_MARK,
+};
+
+static const unsigned int sdhi0_wp_pins[] = {
+ /* WP */
+ RCAR_GP_PIN(3, 13),
+};
+
+static const unsigned int sdhi0_wp_mux[] = {
+ SD0_WP_MARK,
+};
+
+/* - SDHI1 --
*/
+static const unsigned int sdhi1_data1_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(3, 8),
+};
+
+static const unsigned int sdhi1_data1_mux[] = {
+ SD1_DAT0_MARK,
+};
+
+static const unsigned int sdhi1_data4_pins[] = {
+ /* D[0:3] */
+ RCAR_GP_PIN(3, 8), RCAR_GP_PIN(3, 9),
+ RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 11),
+};
+
+static const unsigned int sdhi1_data4_mux[] = {
+ SD1_DAT0_MARK, SD1_DAT1_MARK,
+ SD1_DAT2_MARK, SD1_DAT3_MARK,
+};
+
+static const unsigned int sdhi1_ctrl_pins[] = {
+ /* CLK, CMD */
+ RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
+};
+
+static const unsigned int sdhi1_ctrl_mux[] = {
+ SD1_CLK_MARK, SD1_CMD_MARK,
+};
+
+static const unsigned int sdhi1_cd_pins[] = {
+ /* CD */
+ RCAR_GP_PIN(3, 14),
+};
+
+static const unsigned int sdhi1_cd_mux[] = {
+ SD1_CD_MARK,
+};
+
+static const unsigned int sdhi1_wp_pins[] = {
+ /* WP */
+ RCAR_GP_PIN(3, 15),
+};
+
+static const unsigned int sdhi1_wp_mux[] = {
+ SD1_WP_MARK,
+};
+
+/* - SDHI3 --
*/
+static const unsigned int sdhi3_data1_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(4, 2),
+};
+
+static const unsigned int sdhi3_data1_mux[] = {
+ SD3_DAT0_MARK,
+};
+
+static const unsigned int sdhi3_data4_pins[] = {
+ /* D[0:3] */
+ RCAR_GP_PIN(4, 2), RCAR_GP_PIN(4, 3),
+ RCAR_GP_PIN(4, 4), RCAR_GP_PIN(4, 5),
+};
+
+static const unsigned int sdhi3_data4_mux[] = {
+ SD3_DAT0_MARK, SD3_DAT1_MARK,
+ SD3_DAT2_MARK, SD3_DAT3_MARK,
+};
+
+static const unsigned int sdhi3_data8_pins[] = {
+ /* D[0:7] */
+ RCAR_GP_PIN(4, 2), RCAR_GP_PIN(4, 3),
+ RCAR_GP_PIN(4, 4), RCAR_GP_PIN(4, 5),
+ RCAR_GP_PIN(4, 6), RCAR_GP_PIN(4, 7),
+ RCAR_GP_PIN(4, 8), RCAR_GP_PIN(4, 9),
+};
+
+static const unsigned int sdhi3_data8_mux[] = {
+ SD3_DAT0_MARK, SD3_DAT1_MARK,
+ SD3_DAT2_MARK, SD3_DAT3_MARK,
+ SD3_DAT4_MARK, SD3_DAT5_MARK,
+ SD3_DAT6_MARK, SD3_DAT7_MARK,
+};
+
+static const unsigned int sdhi3_ctrl_pins[] = {
+ /* CLK, CMD */
+ RCAR_GP_PIN(4, 0), RCAR_GP_PIN(4, 1),
+};
+
+static const unsigned int sdhi3_ctrl_mux[] = {
+ SD3_CLK_MARK, SD3_CMD_MARK,
+};
+
+static const unsigned int sdhi3_cd_pins[] = {
+ /* CD */
+ RCAR_GP_PIN(3, 12),
+};
+
+static const unsigned int sdhi3_cd_mux[] = {
+ SD3_CD_MARK,
+};
+
+static const unsigned int sdhi3_wp_pins[] = {
+ /* WP */
+ RCAR_GP_PIN(3, 13),
+};
+
+static const unsigned int sdhi3_wp_mux[] = {
+ SD3_WP_MARK,
+};
+
+static const unsigned int sdhi3_ds_pins[] = {
+ /* DS */
+ RCAR_GP_PIN(4, 10),
+};
+
+static const unsigned int sdhi3_ds_mux[] = {
+ SD3_DS_MARK,
+};
+
/* - USB0 ---
*/
static const unsigned int usb0_a_pins[] = {
/* PWEN, OVC */
@@ -2434,7 +2602,7 @@ static const unsigned int usb30_id_mux[] = {
};
static const struct {
- struct
[PATCH] mmc: renesas_sdhi: Whitelist R8A77990 SDHI
Whitelist R8A77990 E3 SoC in the SDHI driver. The SDHI core
present in the SoC is an 8tap variant of the Gen3 SDHI core.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: Ulf Hansson
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index b6f54102bfdd..ede7eec9b9aa 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -304,6 +304,7 @@ static const struct soc_device_attribute soc_whitelist[] = {
{ .soc_id = "r8a77965" },
{ .soc_id = "r8a77970" },
{ .soc_id = "r8a77980" },
+ { .soc_id = "r8a77990" },
{ .soc_id = "r8a77995" },
{ /* sentinel */ }
};
--
2.18.0
[PATCH] arm64: dts: r8a77990: ebisu: Add serial console pins
From: Takeshi Kihara
This patch adds pin control for SCIF2 on R8A77990 E3 Ebisu.
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index f342dd85b152..611f0265fcc5 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -321,6 +321,11 @@
function = "pwm5";
};
+ scif2_pins: scif2 {
+ groups = "scif2_data_a";
+ function = "scif2";
+ };
+
usb0_pins: usb {
groups = "usb0_b";
function = "usb0";
@@ -352,6 +357,9 @@
};
{
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
status = "okay";
};
--
2.18.0
Re: [PATCH 2/2] arm64: dts: renesas: salvator: Switch eMMC bus to 1V8
On 10/31/2018 02:14 PM, Wolfram Sang wrote: > >> But can we discuss this in the context of describing the hardware? > > The SDHI node needs two kinds of pinmux settings, one for normal speeds > and one for highspeeds. They might differ in supplied voltage, i.e. 3v3 > and 1v8. This eMMC always works with 1v8, so both settings needed by the > SDHI node are the same currently. That might change if we add new > features to pinmux nodes like TDSEL/capacity support. My guess is that > this is not so likely to happen so I suggested using just one node. > > But it has a taste of bike-shedding to it :) V2 is out, including the deduplication. -- Best regards, Marek Vasut
[PATCH V2] arm64: dts: renesas: Switch eMMC bus to 1V8 on Salvator-X and ULCB
The eMMC card has two supplies, VCC and VCCQ. The VCC supplies the NAND
array and the VCCQ supplies the bus. On Salvator-X and ULCB, the VCC is
connected to 3.3V rail, while the VCCQ is connected to 1.8V rail. Adjust
the pinmux to match the bus, which is always operating in 1.8V mode.
While at it, deduplicate the pinmux entries, which are now the same for
both default and UHS modes. We still need the two pinctrl entries to
match the bindings though.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
V2: - Squash patches for multiple boards together
- Deduplicate pinmux entries
---
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 8 +---
arch/arm64/boot/dts/renesas/ulcb.dtsi| 8 +---
2 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index 7f91ff524109..69775a201b4d 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -605,12 +605,6 @@
};
sdhi2_pins: sd2 {
- groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
- function = "sdhi2";
- power-source = <3300>;
- };
-
- sdhi2_pins_uhs: sd2_uhs {
groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
function = "sdhi2";
power-source = <1800>;
@@ -760,7 +754,7 @@
{
/* used for on-board 8bit eMMC */
pinctrl-0 = <_pins>;
- pinctrl-1 = <_pins_uhs>;
+ pinctrl-1 = <_pins>;
pinctrl-names = "default", "state_uhs";
vmmc-supply = <_3p3v>;
diff --git a/arch/arm64/boot/dts/renesas/ulcb.dtsi
b/arch/arm64/boot/dts/renesas/ulcb.dtsi
index 89daca7356df..de694fdae067 100644
--- a/arch/arm64/boot/dts/renesas/ulcb.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi
@@ -330,12 +330,6 @@
};
sdhi2_pins: sd2 {
- groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
- function = "sdhi2";
- power-source = <3300>;
- };
-
- sdhi2_pins_uhs: sd2_uhs {
groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
function = "sdhi2";
power-source = <1800>;
@@ -426,7 +420,7 @@
{
/* used for on-board 8bit eMMC */
pinctrl-0 = <_pins>;
- pinctrl-1 = <_pins_uhs>;
+ pinctrl-1 = <_pins>;
pinctrl-names = "default", "state_uhs";
vmmc-supply = <_3p3v>;
--
2.18.0
Re: [PATCH 2/2] arm64: dts: renesas: salvator: Switch eMMC bus to 1V8
On 10/31/2018 01:46 PM, Simon Horman wrote: > On Mon, Oct 29, 2018 at 08:57:21AM +, Wolfram Sang wrote: >> >>>> <_pins>;". So, basically the same phandles for both pinctrls. We >>>> can re-add the second one when we need it. >>> >>> I wonder if removing the sdhi2_pins_uhs is what we want to do, given >>> that we might need to adjust TDSEL or pull resistor configurations for >>> the HS200/HS400 modes in the future. >> >> Well, quoting myself "We can re-add the second one when we need it". It >> is possible but a tad unlikely. That's my take on it but it is >> ultimately up to Simon, of course. > > I agree we can add stuff later if we need it. > But can we discuss this in the context of describing the hardware? I'm not sure I understand this remark. Anyway, I'll be spinning a V2 of the patchset, which will be a single patch. -- Best regards, Marek Vasut
Re: [PATCH 1/2] pinctrl: sh-pfc: r8a7790: initialize TDSEL register
On 10/28/2018 10:24 PM, Wolfram Sang wrote:
> Documentation says that some bits in TDSEL must be set (ch 5.3.39 in R-Car H2
> v0.91). However, the reset value of the register is 0, so software has to do
> it. Add this to the kernel driver to ensure this is really done independent of
> firmware versions.
>
> This is needed for some SD cards supporting SDR104 transfer mode. For
> me, TDSEL was not initialized by the firmware and I had problems with
> the card when re-inserting it.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Marek Vasut
> ---
> drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
> b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
> index ab7a35392cd8..c0e679105df9 100644
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
> @@ -11,6 +11,7 @@
> #include
> #include
>
> +#include "core.h"
> #include "sh_pfc.h"
>
> /*
> @@ -5691,7 +5692,16 @@ static int r8a7790_pin_to_pocctrl(struct sh_pfc *pfc,
> unsigned int pin, u32 *poc
> return 31 - (pin & 0x1f);
> }
>
> +static int r8a7790_pinmux_soc_init(struct sh_pfc *pfc)
> +{
> + /* Initialize TDSEL according to datasheet */
> + sh_pfc_write(pfc, 0xe6060088, 0x0014);
> +
> + return 0;
> +}
> +
> static const struct sh_pfc_soc_operations r8a7790_pinmux_ops = {
> + .init = r8a7790_pinmux_soc_init,
> .pin_to_pocctrl = r8a7790_pin_to_pocctrl,
> };
>
>
--
Best regards,
Marek Vasut
Re: [PATCH 2/2] pinctrl: sh-pfc: r8a7794: initialize TDSEL register
On 10/28/2018 10:24 PM, Wolfram Sang wrote:
> Documentation says that some bits in TDSEL must be set (ch 5.3.35 in
> R-Car E2 v0.5). However, the reset value of the register is 0, so
> software has to do it. Add this to the kernel driver to ensure this is
> really done independent of firmware versions. This is needed for some SD
> cards supporting SDR104 transfer mode.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Marek Vasut
> ---
> drivers/pinctrl/sh-pfc/pfc-r8a7794.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7794.c
> b/drivers/pinctrl/sh-pfc/pfc-r8a7794.c
> index 6d1e5fdc03f8..8a16053d2bec 100644
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a7794.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a7794.c
> @@ -5560,7 +5560,16 @@ static int r8a7794_pin_to_pocctrl(struct sh_pfc *pfc,
> unsigned int pin, u32 *poc
> return -EINVAL;
> }
>
> +static int r8a7794_pinmux_soc_init(struct sh_pfc *pfc)
> +{
> + /* Initialize TDSEL according to datasheet */
> + sh_pfc_write(pfc, 0xe6060068, 0x5500);
> +
> + return 0;
> +}
> +
> static const struct sh_pfc_soc_operations r8a7794_pinmux_ops = {
> + .init = r8a7794_pinmux_soc_init,
> .pin_to_pocctrl = r8a7794_pin_to_pocctrl,
> };
>
>
--
Best regards,
Marek Vasut
Re: [PATCH 2/2] arm64: dts: renesas: salvator: Switch eMMC bus to 1V8
On 10/28/2018 10:34 PM, Wolfram Sang wrote:
> Hi Marek,
Hi,
> On Sat, Oct 27, 2018 at 06:34:10PM +0200, Marek Vasut wrote:
>> The eMMC card has two supplies, VCC and VCCQ. The VCC supplies the NAND
>> array and the VCCQ supplies the bus. On this particular board, the VCC is
>> connected to 3.3V rail, while the VCCQ is connected to 1.8V rail. Adjust
>> the pinmux to match the bus, which is always operating in 1.8V mode.
>>
>> Signed-off-by: Marek Vasut
>
> Thanks for this!
>
> I think Olof (and thus, Simon ;)) will be happy if those two patches are
> merged.
Fine by me.
> Other than that, I think we should remove sdhi2_pins_uhs then because it
> is the same as sdhi2_pins. And then use later "pinctrl-1 =
> <_pins>;". So, basically the same phandles for both pinctrls. We
> can re-add the second one when we need it.
I wonder if removing the sdhi2_pins_uhs is what we want to do, given
that we might need to adjust TDSEL or pull resistor configurations for
the HS200/HS400 modes in the future.
Thoughts ?
>> Cc: Geert Uytterhoeven
>> Cc: Simon Horman
>> Cc: Wolfram Sang
>> Cc: Yoshihiro Shimoda
>> Cc: linux-renesas-soc@vger.kernel.org
>> ---
>> arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
>> b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
>> index 7d3d866a0063..d9a309b28fcf 100644
>> --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
>> @@ -602,7 +602,7 @@
>> sdhi2_pins: sd2 {
>> groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
>> function = "sdhi2";
>> -power-source = <3300>;
>> +power-source = <1800>;
>> };
>>
>> sdhi2_pins_uhs: sd2_uhs {
>> --
>> 2.17.1
>>
--
Best regards,
Marek Vasut
[PATCH 2/2] arm64: dts: renesas: salvator: Switch eMMC bus to 1V8
The eMMC card has two supplies, VCC and VCCQ. The VCC supplies the NAND
array and the VCCQ supplies the bus. On this particular board, the VCC is
connected to 3.3V rail, while the VCCQ is connected to 1.8V rail. Adjust
the pinmux to match the bus, which is always operating in 1.8V mode.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index 7d3d866a0063..d9a309b28fcf 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -602,7 +602,7 @@
sdhi2_pins: sd2 {
groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
function = "sdhi2";
- power-source = <3300>;
+ power-source = <1800>;
};
sdhi2_pins_uhs: sd2_uhs {
--
2.17.1
[PATCH 1/2] arm64: dts: renesas: ulcb: Switch eMMC bus to 1V8
The eMMC card has two supplies, VCC and VCCQ. The VCC supplies the NAND
array and the VCCQ supplies the bus. On this particular board, the VCC is
connected to 3.3V rail, while the VCCQ is connected to 1.8V rail. Adjust
the pinmux to match the bus, which is always operating in 1.8V mode.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/ulcb.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/ulcb.dtsi
b/arch/arm64/boot/dts/renesas/ulcb.dtsi
index 0ead552d7eae..f2fabead5031 100644
--- a/arch/arm64/boot/dts/renesas/ulcb.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi
@@ -329,7 +329,7 @@
sdhi2_pins: sd2 {
groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
function = "sdhi2";
- power-source = <3300>;
+ power-source = <1800>;
};
sdhi2_pins_uhs: sd2_uhs {
--
2.17.1
[PATCH V2] iio: adc: Fix Renesas GyroADC MAINTAINERS entry
Fix the F: entry in MAINTAINERS file, point it to the correct file. While at it, add DT binding doc F: entry too. Signed-off-by: Marek Vasut Cc: Geert Uytterhoeven Cc: Joe Perches Cc: Jonathan Cameron Cc: Simon Horman Cc: Wolfram Sang Cc: linux-renesas-soc@vger.kernel.org --- V2: Add DT binding doc F: entry --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1cd17e09970c..3f0abbfe1dd2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12471,7 +12471,8 @@ RENESAS R-CAR GYROADC DRIVER M: Marek Vasut L: linux-...@vger.kernel.org S: Supported -F: drivers/iio/adc/rcar_gyro_adc.c +F: Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt +F: drivers/iio/adc/rcar-gyroadc.c RENESAS R-CAR I2C DRIVERS M: Wolfram Sang -- 2.18.0
Re: [PATCH] iio: adc: Fix Renesas GyroADC MAINTAINERS entry
On 10/01/2018 02:20 PM, Jonathan Cameron wrote: > On Mon, 1 Oct 2018 14:17:40 +0200 > Wolfram Sang wrote: > >> On Mon, Oct 01, 2018 at 01:58:26PM +0200, Marek Vasut wrote: >>> On 10/01/2018 01:55 PM, Wolfram Sang wrote: >>>> On Mon, Oct 01, 2018 at 12:58:04PM +0200, Marek Vasut wrote: >>>>> Fix the F: entry in MAINTAINERS file, point it to the correct file. >>>> >>>> Right... >>>> >>>>> @@ -12471,7 +12471,7 @@ RENESAS R-CAR GYROADC DRIVER >>>>> M: Marek Vasut >>>>> L: linux-...@vger.kernel.org >>>>> S: Supported >>>>> -F: drivers/iio/adc/rcar_gyro_adc.c >>>>> +F: drivers/iio/adc/rcar-gyroadc.c >>>> >>>> Add the bindings, too? >>>> >>>> Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt >>>> >>> Separate patch or V2 ? >> >> I'd say V2, but I am not the IIO maintainer. >> >> > > v2 please given I haven't done anything with v1 yet. Done -- Best regards, Marek Vasut
Re: [PATCH][RFC] PCI: rcar: Add bus notifier so we can limit the DMA range
On 09/22/2018 07:06 PM, Marek Vasut wrote: > On 09/18/2018 12:51 PM, Wolfram Sang wrote: >> 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)? > > I assembled a setup with NVMe controller, which should be triggering > this issue according to [1], but I'm not having much success getting it > to work with or without this patchset. Logs are below, nvme smart-log > seems to produce completely bogus results, although the device is at > least recognized. > > Maybe there's something else that's broken ? > > [1] https://patchwork.kernel.org/patch/9495895/ > > # dmesg | egrep '(pci|nvm)' > rcar-pcie fe00.pcie: host bridge /soc/pcie@fe00 ranges: > rcar-pcie fe00.pcie: Parsing ranges property... > rcar-pcie fe00.pcie:IO 0xfe10..0xfe1f -> 0x > rcar-pcie fe00.pcie: MEM 0xfe20..0xfe3f -> 0xfe20 > rcar-pcie fe00.pcie: MEM 0x3000..0x37ff -> 0x3000 > rcar-pcie fe00.pcie: MEM 0x3800..0x3fff -> 0x3800 > rcar-pcie fe00.pcie: PCIe x1: link up > rcar-pcie fe00.pcie: Current link speed is 5 GT/s > rcar-pcie fe00.pcie: PCI host bridge to bus :00 > pci_bus :00: root bus resource [bus 00-ff] > pci_bus :00: root bus resource [io 0x-0xf] > pci_bus :00: root bus resource [mem 0xfe20-0xfe3f] > pci_bus :00: root bus resource [mem 0x3000-0x37ff] > pci_bus :00: root bus resource [mem 0x3800-0x3fff pref] > pci_bus :00: scanning bus > pci :00:00.0: [1912:0025] type 01 class 0x060400 > pci :00:00.0: enabling Extended Tags > pci :00:00.0: PME# supported from D0 D3hot D3cold > pci :00:00.0: PME# disabled > pci_bus :00: fixups for bus > pci :00:00.0: scanning [bus 01-01] behind bridge, pass 0 > pci :00:00.0: scanning [bus 00-00] behind bridge, pass 1 > pci_bus :01: scanning bus > pci :01:00.0: [8086:f1a5] type 00 class 0x010802 > pci :01:00.0: reg 0x10: [mem 0x-0x3fff 64bit] > pci :01:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5 GT/s > x1 link at :00:00.0 (capable of 31.504 Gb/s with 8 GT/s x4 link) > pci_bus :01: fixups for bus > pci_bus :01: bus scan returning with max=01 > pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 > pci_bus :00: bus scan returning with max=01 > pci :00:00.0: BAR 14: assigned [mem 0xfe20-0xfe2f] > pci :01:00.0: BAR 0: assigned [mem 0xfe20-0xfe203fff 64bit] > pci :00:00.0: PCI bridge to [bus 01] > pci :00:00.0: bridge window [mem 0xfe20-0xfe2f] > pcieport :00:00.0: assign IRQ: got 0 > pcieport :00:00.0: enabling device ( -> 0002) > pcieport :00:00.0: enabling bus mastering > pcieport :00:00.0: Signaling PME with IRQ 198 > rcar-pcie ee80.pcie: host bridge /soc/pcie@ee80 ranges: > rcar-pcie ee80.pcie: Parsing ranges property... > rcar-pcie ee80.pcie:IO 0xee90..0xee9f -> 0x > rcar-pcie ee80.pcie: MEM 0xeea0..0xeebf -> 0xeea0 > rcar-pcie ee80.pcie: MEM 0xc000..0xc7ff -> 0xc000 > rcar-pcie ee80.pcie: MEM 0xc800..0xcfff -> 0xc800 > rcar-pcie ee80.pci
Re: [PATCH] iio: adc: Fix Renesas GyroADC MAINTAINERS entry
On 10/01/2018 01:55 PM, Wolfram Sang wrote: > On Mon, Oct 01, 2018 at 12:58:04PM +0200, Marek Vasut wrote: >> Fix the F: entry in MAINTAINERS file, point it to the correct file. > > Right... > >> @@ -12471,7 +12471,7 @@ RENESAS R-CAR GYROADC DRIVER >> M: Marek Vasut >> L: linux-...@vger.kernel.org >> S: Supported >> -F: drivers/iio/adc/rcar_gyro_adc.c >> +F: drivers/iio/adc/rcar-gyroadc.c > > Add the bindings, too? > > Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt > Separate patch or V2 ? -- Best regards, Marek Vasut
[PATCH] iio: adc: Fix Renesas GyroADC MAINTAINERS entry
Fix the F: entry in MAINTAINERS file, point it to the correct file. Signed-off-by: Marek Vasut Cc: Geert Uytterhoeven Cc: Joe Perches Cc: Jonathan Cameron Cc: Simon Horman Cc: Wolfram Sang Cc: linux-renesas-soc@vger.kernel.org --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1cd17e09970c..c945cacdee4a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12471,7 +12471,7 @@ RENESAS R-CAR GYROADC DRIVER M: Marek Vasut L: linux-...@vger.kernel.org S: Supported -F: drivers/iio/adc/rcar_gyro_adc.c +F: drivers/iio/adc/rcar-gyroadc.c RENESAS R-CAR I2C DRIVERS M: Wolfram Sang -- 2.18.0
Re: [PATCH][RFC] PCI: rcar: Add bus notifier so we can limit the DMA range
On 09/18/2018 12:51 PM, Wolfram Sang wrote: > 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)? I assembled a setup with NVMe controller, which should be triggering this issue according to [1], but I'm not having much success getting it to work with or without this patchset. Logs are below, nvme smart-log seems to produce completely bogus results, although the device is at least recognized. Maybe there's something else that's broken ? [1] https://patchwork.kernel.org/patch/9495895/ # dmesg | egrep '(pci|nvm)' rcar-pcie fe00.pcie: host bridge /soc/pcie@fe00 ranges: rcar-pcie fe00.pcie: Parsing ranges property... rcar-pcie fe00.pcie:IO 0xfe10..0xfe1f -> 0x rcar-pcie fe00.pcie: MEM 0xfe20..0xfe3f -> 0xfe20 rcar-pcie fe00.pcie: MEM 0x3000..0x37ff -> 0x3000 rcar-pcie fe00.pcie: MEM 0x3800..0x3fff -> 0x3800 rcar-pcie fe00.pcie: PCIe x1: link up rcar-pcie fe00.pcie: Current link speed is 5 GT/s rcar-pcie fe00.pcie: PCI host bridge to bus :00 pci_bus :00: root bus resource [bus 00-ff] pci_bus :00: root bus resource [io 0x-0xf] pci_bus :00: root bus resource [mem 0xfe20-0xfe3f] pci_bus :00: root bus resource [mem 0x3000-0x37ff] pci_bus :00: root bus resource [mem 0x3800-0x3fff pref] pci_bus :00: scanning bus pci :00:00.0: [1912:0025] type 01 class 0x060400 pci :00:00.0: enabling Extended Tags pci :00:00.0: PME# supported from D0 D3hot D3cold pci :00:00.0: PME# disabled pci_bus :00: fixups for bus pci :00:00.0: scanning [bus 01-01] behind bridge, pass 0 pci :00:00.0: scanning [bus 00-00] behind bridge, pass 1 pci_bus :01: scanning bus pci :01:00.0: [8086:f1a5] type 00 class 0x010802 pci :01:00.0: reg 0x10: [mem 0x-0x3fff 64bit] pci :01:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5 GT/s x1 link at :00:00.0 (capable of 31.504 Gb/s with 8 GT/s x4 link) pci_bus :01: fixups for bus pci_bus :01: bus scan returning with max=01 pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 pci_bus :00: bus scan returning with max=01 pci :00:00.0: BAR 14: assigned [mem 0xfe20-0xfe2f] pci :01:00.0: BAR 0: assigned [mem 0xfe20-0xfe203fff 64bit] pci :00:00.0: PCI bridge to [bus 01] pci :00:00.0: bridge window [mem 0xfe20-0xfe2f] pcieport :00:00.0: assign IRQ: got 0 pcieport :00:00.0: enabling device ( -> 0002) pcieport :00:00.0: enabling bus mastering pcieport :00:00.0: Signaling PME with IRQ 198 rcar-pcie ee80.pcie: host bridge /soc/pcie@ee80 ranges: rcar-pcie ee80.pcie: Parsing ranges property... rcar-pcie ee80.pcie:IO 0xee90..0xee9f -> 0x rcar-pcie ee80.pcie: MEM 0xeea0..0xeebf -> 0xeea0 rcar-pcie ee80.pcie: MEM 0xc000..0xc7ff -> 0xc000 rcar-pcie ee80.pcie: MEM 0xc800..0xcfff -> 0xc800 rcar-pcie ee80.pcie: PCIe link down nvme :01:00.0: assign IRQ: got 171 nvme nvme0: pci function :01:00.0 nvme :01:00.0: enabling device ( -> 0002) nvme :01:00.0: enabling bus mastering nvme nvme0: Shutdown timeout set to 60 seconds # lspci -nvvvs 01:00.0 01:00.0 0108: 8086:f1a5 (rev 03) (prog-if 02 [NVM Express]) Subsystem: 8086:390a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-
[PATCH] DT: pci: rcar-pci: document R8A77990 bindings
From: Tho Vu Document the R-Car E3 (R8A77990) SoC in the R-Car PCIe bindings. Signed-off-by: Tho Vu Signed-off-by: Kazuya Mizuguchi Signed-off-by: Marek Vasut Cc: Geert Uytterhoeven Cc: Lorenzo Pieralisi Cc: Phil Edworthy Cc: Rob Herring Cc: Sergei Shtylyov Cc: Simon Horman Cc: Wolfram Sang Cc: linux-renesas-soc@vger.kernel.org --- Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt index a5f7fc62d10e..5f2f9e380efb 100644 --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt @@ -9,6 +9,7 @@ compatible: "renesas,pcie-r8a7743" for the R8A7743 SoC; "renesas,pcie-r8a7795" for the R8A7795 SoC; "renesas,pcie-r8a7796" for the R8A7796 SoC; "renesas,pcie-r8a77980" for the R8A77980 SoC; + "renesas,pcie-r8a77990" for the R8A77990 SoC; "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 or RZ/G1 compatible device. "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device. -- 2.18.0
Re: [PATCH V6] ARM: shmobile: Rework the PMIC IRQ line quirk
On 09/19/2018 11:30 AM, Geert Uytterhoeven wrote: > Hi Marek, > > On Wed, Sep 19, 2018 at 11:28 AM Geert Uytterhoeven > wrote: >> On Wed, Sep 19, 2018 at 11:22 AM Marek Vasut wrote: >>> On 09/19/2018 11:13 AM, Simon Horman wrote: >>>> Marek, these days checkpatch complains if the author of the patch does not >>>> have a signed offline, and the inconsistency between your >>>> from and Sign-off the email address trips that check. >>>> >>>> Could you consider either a) enhancing checkpatch or b) using >> >> I'm the one who enhanced checkpatch with the new check ;-) >> >>>> the same address twice? No need to take any action for this patch. >>> >>> Sure, do you know if there's some tweak to git config , so git >>> send-email uses the m.v+foo@ From address ? >> >> Git send-email uses the address from user.email in gitconfig, just >> like git commit. >> >> However, I see you're using Gmail's SMTP server. That one replaces the >> From-line in the header by your primary email address as configured in Gmail >> (even if you have configured Gmail to know the other address is yours, too). >> >> I use my ISP's SMTP server to work around that. > > Another trick that should work: > > If you run git send-email in a repo with a different user.email > config, it should > add the original From to the email's body, as it will detect you're submitting > patches on behalf of "someone else". Or I can just patch in the From field myself before sending , just like Cc: and SoB ? -- Best regards, Marek Vasut
Re: [PATCH V6] ARM: shmobile: Rework the PMIC IRQ line quirk
On 09/19/2018 11:13 AM, Simon Horman wrote: > On Tue, Sep 18, 2018 at 02:52:53PM +0200, Geert Uytterhoeven wrote: >> 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 > > Thanks, applied for v4.20. > > Marek, these days checkpatch complains if the author of the patch does not > have a signed offline, and the inconsistency between your > from and Sign-off the email address trips that check. > > Could you consider either a) enhancing checkpatch or b) using > the same address twice? No need to take any action for this patch. Sure, do you know if there's some tweak to git config , so git send-email uses the m.v+foo@ From address ? -- Best regards, Marek Vasut
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
[PATCH] ARM: dts: stout: Add DA9063 OnKey node
Add DA9063 OnKey subnode to DA9063 PMIC node on Stout.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Kuninori Morimoto
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm/boot/dts/r8a7790-stout.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790-stout.dts
b/arch/arm/boot/dts/r8a7790-stout.dts
index a13a92c26645..629da4cee1b9 100644
--- a/arch/arm/boot/dts/r8a7790-stout.dts
+++ b/arch/arm/boot/dts/r8a7790-stout.dts
@@ -318,6 +318,10 @@
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
+ onkey {
+ compatible = "dlg,da9063-onkey";
+ };
+
rtc {
compatible = "dlg,da9063-rtc";
};
--
2.16.2
Re: [PATCH V2] ARM: dts: silk: Add DA9063 PMIC node
On 08/10/2018 01:57 PM, Simon Horman wrote:
> On Tue, Aug 07, 2018 at 10:16:16AM +0200, Geert Uytterhoeven wrote:
>> Hi Marek,
>>
>> On Sat, Aug 4, 2018 at 6:38 PM Marek Vasut wrote:
>>> Add DA9063 PMIC node to the I2C bus.
>>>
>>> Signed-off-by: Marek Vasut
>>> Cc: Geert Uytterhoeven
>>> Cc: Kuninori Morimoto
>>> Cc: Simon Horman
>>> Cc: Wolfram Sang
>>> Cc: linux-renesas-soc@vger.kernel.org
>>> ---
>>> V2: - Replace shmobile with dts since it's a DT patch in subject
>>> - Connect the 9063_IRQ# line to GP3_31
>>> - Since the DA9063 is connected to both i2c1 and i2c7, connect
>>> it to i2c7, which is the dedicated dvfs i2c.
>>
>> Thanks for the update!
>>
>>> --- a/arch/arm/boot/dts/r8a7794-silk.dts
>>> +++ b/arch/arm/boot/dts/r8a7794-silk.dts
>>> @@ -405,6 +405,23 @@
>>> clock-frequency = <40>;
>>> };
>>>
>>> + {
>>> + status = "okay";
>>> + clock-frequency = <10>;
>>> +
>>> + pmic@58 {
>>> + compatible = "dlg,da9063";
>>> + reg = <0x58>;
>>> + interrupt-parent = <>;
>>> + interrupts = <31 IRQ_TYPE_LEVEL_LOW>;
>>> + interrupt-controller;
>>> +
>>> + wdt {
>>> + compatible = "dlg,da9063-watchdog";
>>> + };
>>
>> Given Silk has the full da9063 (unlike the "L" version on Porter), shouldn't
>> you add an rtc subnode?
>>
>> Oh, Silk also has the onkey pin wired, so perhaps you want to add an onkey
>> subnode, too? Does that feature work?
>>
>> BTW, Stout also has the onkey wired, but lacks the onkey subnode.
>>
>>> + };
>>> +};
>>> +
>>
>> Nevertheless:
>> Reviewed-by: Geert Uytterhoeven
>
> Thanks, I have applied this patch for v4.20.
>
> Marek,
>
> please consider some follow-up patches to address the issues
> raised by Geert.
Thanks for the reminder, I missed the email. Patch is out.
--
Best regards,
Marek Vasut
[PATCH] ARM: dts: silk: Add DA9063 RTC and OnKey node
Add DA9063 RTC and OnKey subnode to DA9063 PMIC node on Silk.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Kuninori Morimoto
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
---
NOTE: Pressing the POWER Switch SW11 triggers KEY_POWER event, which
ie. systemd interprets as shutdown command.
NOTE: The RTC is verified to work with hwclock -w / hwclock -r .
---
arch/arm/boot/dts/r8a7794-silk.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7794-silk.dts
b/arch/arm/boot/dts/r8a7794-silk.dts
index 6ea60e1faf75..60e91ebfa65d 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -416,6 +416,14 @@
interrupts = <31 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
+ onkey {
+ compatible = "dlg,da9063-onkey";
+ };
+
+ rtc {
+ compatible = "dlg,da9063-rtc";
+ };
+
wdt {
compatible = "dlg,da9063-watchdog";
};
--
2.16.2
Re: [PATCH V2 4/5] PCI: rcar: Support runtime PM, link state L1 handling
On 07/25/2018 11:08 PM, Marek Vasut wrote:
> On 06/13/2018 07:25 PM, Bjorn Helgaas wrote:
>> On Wed, Jun 13, 2018 at 04:52:52PM +0100, Lorenzo Pieralisi wrote:
>>> On Wed, Jun 13, 2018 at 08:53:08AM -0500, Bjorn Helgaas wrote:
>>>> On Wed, Jun 13, 2018 at 01:54:51AM +0200, Marek Vasut wrote:
>>>>> On 06/11/2018 03:59 PM, Bjorn Helgaas wrote:
>>>>>> On Sun, Jun 10, 2018 at 03:57:10PM +0200, Marek Vasut wrote:
>>>>>>> On 11/17/2017 06:49 PM, Lorenzo Pieralisi wrote:
>>>>>>>> On Fri, Nov 10, 2017 at 10:58:42PM +0100, Marek Vasut wrote:
>>>>>>>>> From: Phil Edworthy
>>>>>>>>>
>>>>>>>>> Most PCIe host controllers support L0s and L1 power states via ASPM.
>>>>>>>>> The R-Car hardware only supports L0s, so when the system suspends and
>>>>>>>>> resumes we have to manually handle L1.
>>>>>>>>> When the system suspends, cards can put themselves into L1 and send a
>>>>>>>>
>>>>>>>> I assumed L1 entry has to be negotiated depending upon the PCIe
>>>>>>>> hierarchy capabilities, I would appreciate if you can explain to
>>>>>>>> me what's the root cause of the issue please.
>>>>>>>
>>>>>>> You should probably ignore the suspend/resume part altogether. The issue
>>>>>>> here is that the cards can enter L1 state, while the controller won't do
>>>>>>> that automatically, it can only detect that the link went into L1 state.
>>>>>>> If that happens,the driver must manually put the controller to L1 state.
>>>>>>> The controller can transition out of L1 state automatically though.
>>>>>>
>>>>>> From earlier discussion I thought the R-Car root port did not
>>>>>> advertise L1 support.
>>>>>
>>>>> Which discussion ? This one or somewhere else ?
>>>>
>>>> https://lkml.kernel.org/r/hk2pr0601mb1393d917d343e6363484ca68f5...@hk2pr0601mb1393.apcprd06.prod.outlook.com
>>>>
>>>> Re-reading that, I think I see my misunderstanding. I was only
>>>> considering L1 in the ASPM context. I didn't realize the L1
>>>> implications of devices being in states other than D0.
>>>>
>>>> Obviously L1 support for ASPM is optional and advertised via Link
>>>> Capabilities. But per PCIe r4.0, sec 5.2, L1 support is required for
>>>> PCI-PM compatible power management, and is entered "whenever all
>>>> Functions ... are programmed to a D-state other than D0."
>>>>
>>>> So I guess this means *every* device is supposed to support L1 when it
>>>> is in a non-D0 power state. I think *this* is the case you're
>>>> solving.
>>>>
>>>> A little more of this detail, e.g., that this issue has nothing to do
>>>> with ASPM, it's probably an R-Car erratum that the RC can't transition
>>>> from L1 to L0, etc., in the changelog would really help clear things
>>>> up for me.
>>>
>>> I think that the issue is related to the L0->L1 transition upon system
>>> suspend (ie the kernel must force the controller into L1 when all
>>> devices are in a sleep state) and for this specific reason I still think
>>> that checking for a PM_Enter_L1 DLLP reception and doing the L0->L1
>>> transition within a config access is wrong and prone to error (what's
>>> the rationale behind that ?), this ought to be done using PM methods in
>>> the host controller driver.
>>
>> But doesn't the problem happen whenever the link goes to L1, for any
>> reason? E.g., runtime power management might put an endpoint in D3
>> even if we're not doing a whole system suspend. A user could even
>> force the endpoint to D3 by writing to PCI_PM_CTRL with "setpci". If
>> that's the case, I don't think the host controller PM methods will be
>> enough to work around the issue.
>
> I think so, it's the link that goes into L1 state and this can happen
> without any action from the controller side.
>
>> The comment in the patch ("If we are not in L1 link state and we have
>> received PM_ENTER_L1 DLLP, transition to L1 link state") suggests that
>> the R-Car host doesn't handle step 10 in PCIe r4.0, sec 5.3.2.1
>> correctly, i.e., it doesn't complete the transition of the link to L1.
>>
>> Putting this work
[PATCH V2] ARM: dts: silk: Add DA9063 PMIC node
Add DA9063 PMIC node to the I2C bus.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Kuninori Morimoto
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
---
V2: - Replace shmobile with dts since it's a DT patch in subject
- Connect the 9063_IRQ# line to GP3_31
- Since the DA9063 is connected to both i2c1 and i2c7, connect
it to i2c7, which is the dedicated dvfs i2c.
---
arch/arm/boot/dts/r8a7794-silk.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7794-silk.dts
b/arch/arm/boot/dts/r8a7794-silk.dts
index daec965889d3..6ea60e1faf75 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -405,6 +405,23 @@
clock-frequency = <40>;
};
+ {
+ status = "okay";
+ clock-frequency = <10>;
+
+ pmic@58 {
+ compatible = "dlg,da9063";
+ reg = <0x58>;
+ interrupt-parent = <>;
+ interrupts = <31 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+
+ wdt {
+ compatible = "dlg,da9063-watchdog";
+ };
+ };
+};
+
{
pinctrl-0 = <_pins>;
pinctrl-names = "default";
--
2.16.2
Re: [PATCH] ARM: shmobile: silk: Add DA9063 PMIC node
On 08/03/2018 12:48 PM, Wolfram Sang wrote: > >>> Wolfram: do you like i2c slaves connected to multiple buses? > > 'Like' would be an exaggeration, but if they are connected to multiple > busses, this might be a reason to describe that. People could then in > userspace bind/unbind to the bus they want? Not pretty, but there might > be reasons for that? Would that be useful for a PMIC ? I suspect it'd create quite a few problems if the user could move PMIC between I2C busses at will and I don't see any benefits. -- Best regards, Marek Vasut
