* [PATCH v2 5/7] ARM64: dts: meson-gxbb-p20x: add reset for the ethernet PHY
From: Martin Blumenstingl @ 2016-11-25 13:01 UTC (permalink / raw)
To: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, khilman-rdvid1DuHRBWk0Htik3J/w,
mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
alexandre.torgue-qxv4g6HH51o, peppe.cavallaro-qxv4g6HH51o,
will.deacon-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
carlo-KA+7E9HrN00dnm+yROfE0A, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
Martin Blumenstingl
In-Reply-To: <20161125130156.17879-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
This resets the ethernet PHY during boot to get the PHY into a "clean"
state. While here also specify the phy-handle of the ethmac node to
make the PHY configuration similar to the one we have on GXL devices.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 203be28..2abc553 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -134,10 +134,25 @@
pinctrl-names = "default";
};
+&mdio0 {
+ ethernet_phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+};
+
ðmac {
status = "okay";
pinctrl-0 = <ð_rgmii_pins>;
pinctrl-names = "default";
+
+ phy-handle = <ðernet_phy0>;
+
+ snps,reset-gpio = <&gpio GPIOZ_14 0>;
+ snps,reset-delays-us = <0 10000 1000000>;
+ snps,reset-active-low;
+
+ phy-mode = "rgmii";
};
&ir {
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 6/7] ARM64: dts: meson-gxbb-vega-s95: add reset for the ethernet PHY
From: Martin Blumenstingl @ 2016-11-25 13:01 UTC (permalink / raw)
To: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, khilman-rdvid1DuHRBWk0Htik3J/w,
mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
alexandre.torgue-qxv4g6HH51o, peppe.cavallaro-qxv4g6HH51o,
will.deacon-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
carlo-KA+7E9HrN00dnm+yROfE0A, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
Martin Blumenstingl
In-Reply-To: <20161125130156.17879-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
This resets the ethernet PHY during boot to get the PHY into a "clean"
state. While here also specify the phy-handle of the ethmac node to
make the PHY configuration similar to the one we have on GXL devices.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index e59ad30..a0e92e3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -113,10 +113,25 @@
pinctrl-names = "default";
};
+&mdio0 {
+ ethernet_phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-id001c.c916", "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+};
+
ðmac {
status = "okay";
pinctrl-0 = <ð_rgmii_pins>;
pinctrl-names = "default";
+
+ phy-handle = <ðernet_phy0>;
+
+ snps,reset-gpio = <&gpio GPIOZ_14 0>;
+ snps,reset-delays-us = <0 10000 1000000>;
+ snps,reset-active-low;
+
+ phy-mode = "rgmii";
};
&usb0_phy {
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 7/7] ARM64: dts: amlogic: add the ethernet TX delay configuration
From: Martin Blumenstingl @ 2016-11-25 13:01 UTC (permalink / raw)
To: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, khilman-rdvid1DuHRBWk0Htik3J/w,
mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
alexandre.torgue-qxv4g6HH51o, peppe.cavallaro-qxv4g6HH51o,
will.deacon-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
carlo-KA+7E9HrN00dnm+yROfE0A, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
Martin Blumenstingl
In-Reply-To: <20161125130156.17879-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
This adds the amlogic,tx-delay-ns with the old (hardcoded) default value
of 2ns to all boards which are using an RGMII ethernet PHY.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 2 ++
6 files changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index cbaf024..fdade07 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -161,6 +161,8 @@
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
+ amlogic,tx-delay-ns = <2>;
+
phy-mode = "rgmii";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 2abc553..8172e12 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -152,6 +152,8 @@
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
+ amlogic,tx-delay-ns = <2>;
+
phy-mode = "rgmii";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index a0e92e3..ab49712 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -131,6 +131,8 @@
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
+ amlogic,tx-delay-ns = <2>;
+
phy-mode = "rgmii";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
index f66939c..7fd11c6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
@@ -64,6 +64,8 @@
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
+ amlogic,tx-delay-ns = <2>;
+
/* External PHY is in RGMII */
phy-mode = "rgmii";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index d320727..f83d6dc 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -156,6 +156,8 @@
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
+ amlogic,tx-delay-ns = <2>;
+
/* External PHY is in RGMII */
phy-mode = "rgmii";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
index 5dbc660..e428e29 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
@@ -64,6 +64,8 @@
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
+ amlogic,tx-delay-ns = <2>;
+
/* External PHY is in RGMII */
phy-mode = "rgmii";
};
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 6/10] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
From: Ulf Hansson @ 2016-11-25 13:06 UTC (permalink / raw)
To: Ziji Hu
Cc: Adrian Hunter, Gregory CLEMENT, linux-mmc@vger.kernel.org,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Rob Herring,
devicetree@vger.kernel.org, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Jimmy Xu, Jisheng Zhang,
Nadav Haklai, Ryan Gao, Doug Jones, Victor Gu, Wei(SOCP) Liu,
Wilson Ding
In-Reply-To: <07e71ce4-a78e-750c-6325-0a88891519d5@marvell.com>
[...]
>>>>>> +
>>>>>> + /*
>>>>>> + * Xenon Specific property:
>>>>>> + * emmc: explicitly indicate whether this slot is for eMMC
>>>>>> + * slotno: the index of slot. Refer to SDHC_SYS_CFG_INFO register
>>>>>> + * tun-count: the interval between re-tuning
>>>>>> + * PHY type: "sdhc phy", "emmc phy 5.0" or "emmc phy 5.1"
>>>>>> + */
>>>>>> + if (of_property_read_bool(np, "marvell,xenon-emmc"))
>>>>>> + priv->emmc_slot = true;
>>>>>
>>>>> So, you need this because of the eMMC voltage switch behaviour, right?
>>>>>
>>>>> Then I would rather like to describe this a generic DT bindings for
>>>>> the eMMC voltage level support. There have acutally been some earlier
>>>>> discussions for this, but we haven't yet made some changes.
>>>>>
>>>>> I think what is missing is a mmc-ddr-3_3v DT binding, which when set,
>>>>> allows the host driver to accept I/O voltage switches to 3.3V. If not
>>>>> supported the ->start_signal_voltage_switch() ops may return -EINVAL.
>>>>> This would inform the mmc core to move on to the next supported
>>>>> voltage level. There might be some minor additional changes to the mmc
>>>>> card initialization sequence, but those should be simple.
>>>>>
>>>>> I can help out to look into this, unless you want to do it yourself of course!?
>>>>>
>>>> Yes. One of the reasons is to provide eMMC specific voltage setting.
>>>> But in my very own opinion, it should be irrelevant to voltage level.
>>>> The eMMC voltage setting on our SDHC is different from SD/SDIO voltage switch.
>>>> It will become more complex with different SOC implementation details.
>>>
>>> Got it. Although I think we can cope with that fine just by using the
>>> different SD/eMMC speed modes settings defined in DT (or from the
>>> SDHCI caps register)
>>>
>> In my very opinion, I'm not sure if there is any corner case that driver cannot
>> determine the eMMC card type from DT and SDHC caps.
>>
>>>> Unfortunately, MMC driver cannot determine the card type yet when eMMC voltage
>>>> setting should be executed.
>>>> Thus an flag is required here to tell driver to execute eMMC voltage setting.
>>>>
>>>> Besides, additional eMMC specific settings might be implemented in future, besides
>>>> voltage setting. Most of them should be completed before MMC driver recognizes the
>>>> card type. Thus I have to keep this flag to indicate current SDHC is for eMMC.
>>>
>>> I doubt you will need a generic "eMMC" flag, but let's see when we go forward.
>>>
>>> Currently it's clear you don't need such a flag, so I will submit a
>>> change adding a DT binding for "mmc-ddr-3_3v" then we can take it from
>>> there, to see if it suits your needs.
>>>
>
> Another reason for a special "xenon-emmc" property is that our host IP usually can
> support both eMMC and SD. Whether a host is used as eMMC or SD depends on the
> final implementation of the actual product.
> Thus our host driver needs to know whether current SDHC is fixed as eMMC or SD.
> So far, It can only get the information from DT.
As a matter of fact for mounted non-removable cards, such as eMMC, we
already have the option to describe some of their characteristics in
DT. Perhaps that's what you need?
Please have a look at:
Documentation/devicetree/bindings/mmc/mmc-card.txt
>
> After out host driver get the card type information from DT, it can prepare eMMC
> specific voltage, set eMMC specific mmc->caps/caps2 flags and do other
> vendor specific init, before card init procedure.
> Otherwise, our host driver has to wait until card type is determined in mmc_rescan().
>
> A generic "eMMC" flag is unnecessary. I just require a private property,
> which is only used in our host driver and DT.
>
> Thank you.
>
> Best regards,
> Hu Ziji
>
>>
>> Actually, our eMMC is usually fixed as 1.8V.
>>
>> The pair "no-sd" + "no-sdio" can provide the similar information.
>> But I'm not sure if it is proper to use those two property in such a way.
>>
>> Thank you.
>>
>> Best regards
>> Hu Ziji
>>
>>> [...]
>>>
>>> Kind regards
>>> Uffe
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
Kind regards
Uffe
^ permalink raw reply
* [PATCH 0/2] net: phy: realtek: fix RTL8211F TX-delay handling
From: Martin Blumenstingl @ 2016-11-25 13:11 UTC (permalink / raw)
To: f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
sean.wang-NuS5LvNUpcJWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
jbrunet-rdvid1DuHRBWk0Htik3J/w, Martin Blumenstingl
The RTL8211F PHY driver currently enables the TX-delay only when the
phy-mode is PHY_INTERFACE_MODE_RGMII. This is incorrect, because there
are three RGMII variations of the phy-mode which explicitly request the
PHY to enable the RX and/or TX delay, while PHY_INTERFACE_MODE_RGMII
specifies that the PHY should disable the RX and/or TX delays.
Additionally to the RTL8211F PHY driver change this contains a small
update to the phy-mode documentation to clarify the purpose of the
RGMII phy-modes.
While this may not be perfect yet it's at least a start. Please feel
free to drop this patch from this series and send an improved version
yourself.
These patches are the results of recent discussions, see [0]
[0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001688.html
Martin Blumenstingl (2):
Documentation: devicetree: clarify usage of the RGMII phy-modes
net: phy: realtek: fix enabling of the TX-delay for RTL8211F
Documentation/devicetree/bindings/net/ethernet.txt | 24 ++++++++++++++++++----
drivers/net/phy/realtek.c | 20 ++++++++++--------
2 files changed, 32 insertions(+), 12 deletions(-)
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] Documentation: devicetree: clarify usage of the RGMII phy-modes
From: Martin Blumenstingl @ 2016-11-25 13:12 UTC (permalink / raw)
To: f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
sean.wang-NuS5LvNUpcJWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
jbrunet-rdvid1DuHRBWk0Htik3J/w, Martin Blumenstingl
In-Reply-To: <20161125131201.19994-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
RGMII requires special RX and/or TX delays depending on the actual
hardware circuit/wiring. These delays can be added by the MAC, the PHY
or the designer of the circuit (the latter means that no delay has to
be added by PHY or MAC).
There are 4 RGMII phy-modes used describe where a delay should be
applied:
- rgmii: the RX and TX delays are either added by the MAC (where the
exact delay is typically configurable, and can be turned off when no
extra delay is needed) or not needed at all (because the hardware
wiring adds the delay already). The PHY should neither add the RX nor
TX delay in this case.
- rgmii-rxid: configures the PHY to enable the RX delay. The MAC should
not add the RX delay in this case.
- rgmii-txid: configures the PHY to enable the TX delay. The MAC should
not add the TX delay in this case.
- rgmii-id: combines rgmii-rxid and rgmii-txid and thus configures the
PHY to enable the RX and TX delays. The MAC should neither add the RX
nor TX delay in this case.
Document these cases in the ethernet.txt documentation to make it clear
when to use each mode.
If applied incorrectly one might end up with MAC and PHY both enabling
for example the TX delay, which breaks ethernet TX traffic on 1000Mbit/s
links.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
Documentation/devicetree/bindings/net/ethernet.txt | 24 ++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt
index e1d7681..0515095 100644
--- a/Documentation/devicetree/bindings/net/ethernet.txt
+++ b/Documentation/devicetree/bindings/net/ethernet.txt
@@ -9,10 +9,26 @@ The following properties are common to the Ethernet controllers:
- max-speed: number, specifies maximum speed in Mbit/s supported by the device;
- max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than
the maximum frame size (there's contradiction in ePAPR).
-- phy-mode: string, operation mode of the PHY interface; supported values are
- "mii", "gmii", "sgmii", "qsgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id",
- "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii", "trgmii"; this is now a
- de-facto standard property;
+- phy-mode: string, operation mode of the PHY interface. This is now a de-facto
+ standard property; supported values are:
+ * "mii"
+ * "gmii"
+ * "sgmii"
+ * "qsgmii"
+ * "tbi"
+ * "rev-mii"
+ * "rmii"
+ * "rgmii" (RX and TX delays are added by the MAC when required)
+ * "rgmii-id" (RGMII with internal RX and TX delays provided by the PHY, the
+ MAC should not add the RX or TX delays in this case)
+ * "rgmii-rxid" (RGMII with internal RX delay provided by the PHY, the MAC
+ should not add an RX delay in this case)
+ * "rgmii-txid" (RGMII with internal TX delay provided by the PHY, the MAC
+ should not add an TX delay in this case)
+ * "rtbi"
+ * "smii"
+ * "xgmii"
+ * "trgmii"
- phy-connection-type: the same as "phy-mode" property but described in ePAPR;
- phy-handle: phandle, specifies a reference to a node representing a PHY
device; this property is described in ePAPR and so preferred;
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/2] net: phy: realtek: fix enabling of the TX-delay for RTL8211F
From: Martin Blumenstingl @ 2016-11-25 13:12 UTC (permalink / raw)
To: f.fainelli, robh+dt, mark.rutland, davem, sean.wang, netdev,
devicetree
Cc: linux-amlogic, jbrunet, Martin Blumenstingl
In-Reply-To: <20161125131201.19994-1-martin.blumenstingl@googlemail.com>
The old logic always enabled the TX-delay when the phy-mode was set to
PHY_INTERFACE_MODE_RGMII. There are dedicated phy-modes which tell the
PHY driver to enable the RX and/or TX delays:
- PHY_INTERFACE_MODE_RGMII should disable the RX and TX delay in the
PHY (if required, the MAC should add the delays in this case)
- PHY_INTERFACE_MODE_RGMII_ID should enable RX and TX delay in the PHY
- PHY_INTERFACE_MODE_RGMII_TXID should enable the TX delay in the PHY
- PHY_INTERFACE_MODE_RGMII_RXID should enable the RX delay in the PHY
(currently not supported by RTL8211F)
With this patch we enable the TX delay for PHY_INTERFACE_MODE_RGMII_ID
and PHY_INTERFACE_MODE_RGMII_TXID.
Additionally we now explicity disable the TX-delay, which seems to be
enabled automatically after a hard-reset of the PHY (by triggering it's
reset pin) to get a consistent state (as defined by the phy-mode).
This fixes a compatibility problem with some SoCs where the TX-delay was
also added by the MAC. With the TX-delay being applied twice the TX
clock was off and TX traffic was broken or very slow (<10Mbit/s) on
1000Mbit/s links.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/net/phy/realtek.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index aadd6e9..9cbe645 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -102,15 +102,19 @@ static int rtl8211f_config_init(struct phy_device *phydev)
if (ret < 0)
return ret;
- if (phydev->interface == PHY_INTERFACE_MODE_RGMII) {
- /* enable TXDLY */
- phy_write(phydev, RTL8211F_PAGE_SELECT, 0xd08);
- reg = phy_read(phydev, 0x11);
+ phy_write(phydev, RTL8211F_PAGE_SELECT, 0xd08);
+ reg = phy_read(phydev, 0x11);
+
+ /* enable TX-delay for rgmii-id and rgmii-txid, otherwise disable it */
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+ phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
reg |= RTL8211F_TX_DELAY;
- phy_write(phydev, 0x11, reg);
- /* restore to default page 0 */
- phy_write(phydev, RTL8211F_PAGE_SELECT, 0x0);
- }
+ else
+ reg &= ~RTL8211F_TX_DELAY;
+
+ phy_write(phydev, 0x11, reg);
+ /* restore to default page 0 */
+ phy_write(phydev, RTL8211F_PAGE_SELECT, 0x0);
return 0;
}
--
2.10.2
^ permalink raw reply related
* Re: Question regarding clocks in the DW-HDMI DT bindings
From: Laurent Pinchart @ 2016-11-25 13:25 UTC (permalink / raw)
To: Fabio Estevam
Cc: devicetree@vger.kernel.org, Mike Turquette, Stephen Boyd,
DRI mailing list, Andy Yan, Vladimir Zapolskiy
In-Reply-To: <CAOMZO5CgUm39E1hhLrs5SX9ALMj9BGiRKaY874exNWoQhH2AWQ@mail.gmail.com>
Hi Fabio,
On Friday 25 Nov 2016 10:43:04 Fabio Estevam wrote:
> On Thu, Nov 24, 2016 at 9:26 PM, Laurent Pinchart wrote:
> > Another question I have about the bus clock (CC'ing the devicetree mailing
> > list as well as the clock maintainers) is whether it should be made
> > optional. The clock is obviously mandatory from a hardware point of view
> > (given that APB is a synchronous bus and thus requires a clock), but in
> > some SoCs (specifically for the Renesas SoCs) that clock is always on and
> > can't be controlled. We already omit bus clocks in DT for most IP cores
> > when the clock can never be controlled (and we also omit a bunch of other
> > clocks that we don't even know exist), so it could make sense to make the
> > clock optional. Otherwise there would be runtime overhead trying to handle
> > a clock that can't be controlled.
>
> What if you register the clock as a "dummy" clock instead?
In that case I can as well specify the correct clock. My point was that, for
clocks that we know are always on, specifying them in DT will lead to runtime
overhead (registration of the clock, lookup, runtime handling, ...) that we
could as well avoid. I think the question has a broader scope than just the
dw-hdmi driver, hence the widened audience in CC.
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 1/2] mtd: spi-nor: Bindings for Rockchip serial flash controller
From: Marek Vasut @ 2016-11-25 13:30 UTC (permalink / raw)
To: Shawn Lin, David Woodhouse, Brian Norris
Cc: Cyrille Pitchen, Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Heiko Stuebner
In-Reply-To: <1479437945-27918-2-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On 11/18/2016 03:59 AM, Shawn Lin wrote:
> Add binding document for the Rockchip serial flash controller.
>
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
>
> Changes in v2: None
>
> .../devicetree/bindings/mtd/rockchip-sfc.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/rockchip-sfc.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/rockchip-sfc.txt b/Documentation/devicetree/bindings/mtd/rockchip-sfc.txt
> new file mode 100644
> index 0000000..28430ce
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/rockchip-sfc.txt
> @@ -0,0 +1,31 @@
> +Rockchip Serial Flash Controller
> +
> +Required properties:
> +- compatible : Should be
> + "rockchip,rk1108-sfc", "rockchip,sfc" for ROCKCHIP RK1108.
> +- address-cells : Should be 1.
> +- size-cells : Should be 0.
Shouldn't these two props have a # prefix ? I'm not sure they should
even be part of this binding document at all.
> +- clocks: Must contain two entries for each entry in clock-names.
> +- clock-names: Shall be "sfc" for the transfer-clock, and "hsfc" for
> + the peripheral clock.
> +- interrupts : Should contain the interrupt for the device.
> +- reg: Physical base address of the controller and length of memory mapped.
> +
> +Optional properties:
> +- rockchip,sfc-no-dma: Indicate the controller doesn't support dma transfer.
DMA should be in capital letters.
> +Example:
> +nor_flash: sfc@301c0000 {
> + compatible = "rockchip,rk1108-sfc", "rockchip,sfc";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&cru SCLK_SFC>, <&cru HCLK_SFC>;
> + clock-names = "sfc", "hsfc";
> + interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
> + reg = <0x301c0000 0x1000>;
> + spi-nor@0 {
> + compatible = "jedec,spi-nor";
> + spi-max-frequency = <12000000>;
> + reg = <0>;
> + };
> +};
>
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH mmc/next] mmc: sh_mmcif: Document r8a73a4, r8a7778 and sh73a0 DT bindings
From: Ulf Hansson @ 2016-11-25 13:31 UTC (permalink / raw)
To: Simon Horman
Cc: linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
Magnus Damm, Linux-Renesas
In-Reply-To: <20161125075614.GB14431@verge.net.au>
On 25 November 2016 at 08:56, Simon Horman <horms+renesas@verge.net.au> wrote:
> Simply document new compatibility strings as the driver is already
> activated using a fallback compatibility string.
>
> These compat strings are in keeping with those for all other
> Renesas ARM based SoCs with sh_mmcif enabled in mainline.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Thanks, applied for next!
Kind regards
Uffe
> ---
> Reposted with r8a7778 instead of r8a7779 in subject
>
> I have also posted patches to use these new compat strings
> to bring the DT files of the SoCs in question in-line with those
> for other Renesas ARM based SoCs with sh_mmcif enabled in mainline.
> ---
> Documentation/devicetree/bindings/mmc/renesas,mmcif.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> index ff611fa66871..e4ba92aa035e 100644
> --- a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> +++ b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> @@ -8,11 +8,14 @@ Required properties:
>
> - compatible: should be "renesas,mmcif-<soctype>", "renesas,sh-mmcif" as a
> fallback. Examples with <soctype> are:
> + - "renesas,mmcif-r8a73a4" for the MMCIF found in r8a73a4 SoCs
> - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs
> + - "renesas,mmcif-r8a7778" for the MMCIF found in r8a7778 SoCs
> - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs
> - "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs
> - "renesas,mmcif-r8a7793" for the MMCIF found in r8a7793 SoCs
> - "renesas,mmcif-r8a7794" for the MMCIF found in r8a7794 SoCs
> + - "renesas,mmcif-sh73a0" for the MMCIF found in sh73a0 SoCs
>
> - clocks: reference to the functional clock
>
> --
> 2.7.0.rc3.207.g0ac5344
>
^ permalink raw reply
* Re: [PATCH 1/3] pinctrl: sx150x: use correct registers for reg_sense (sx1502 and sx1508)
From: Linus Walleij @ 2016-11-25 13:40 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel@vger.kernel.org, Rob Herring, Mark Rutland,
Andrey Smirnov, Neil Armstrong, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <1480020320-28354-2-git-send-email-peda@axentia.se>
On Thu, Nov 24, 2016 at 9:45 PM, Peter Rosin <peda@axentia.se> wrote:
> All other registers on these chips are 8-bit, but reg_sense is 16-bits
> and therefore needs to be moved down one notch.
> This was apparently overlooked in the conversion to regmap, which only
> updated the register locations for the 16-bit chips.
>
> Fixes: 6489677f86c3 ("pinctrl-sx150x: Replace sx150x_*_cfg by means of regmap API")
> Signed-off-by: Peter Rosin <peda@axentia.se>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* RE: [PATCH v2 0/7] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: David Laight @ 2016-11-25 13:41 UTC (permalink / raw)
To: 'Martin Blumenstingl', linux-amlogic@lists.infradead.org,
devicetree@vger.kernel.org, netdev@vger.kernel.org,
davem@davemloft.net, khilman@baylibre.com, mark.rutland@arm.com,
robh+dt@kernel.org
Cc: f.fainelli@gmail.com, alexandre.torgue@st.com,
catalin.marinas@arm.com, will.deacon@arm.com, carlo@caione.org,
peppe.cavallaro@st.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20161125130156.17879-1-martin.blumenstingl@googlemail.com>
From: Martin Blumenstingl
> Sent: 25 November 2016 13:02
> Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
> cycle TX clock delay. This seems to work fine for many boards (for
> example Odroid-C2 or Amlogic's reference boards) but there are some
> others where TX traffic is simply broken.
> There are probably multiple reasons why it's working on some boards
> while it's broken on others:
> - some of Amlogic's reference boards are using a Micrel PHY
> - hardware circuit design
> - maybe more...
...
Interesting thought.
Can you test phy loopback with different delays?
It might be then possible to default to 'auto'.
David
^ permalink raw reply
* Re: [PATCH 2/3] pinctrl: sx150x: sort chips by part number
From: Linus Walleij @ 2016-11-25 13:41 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel@vger.kernel.org, Rob Herring, Mark Rutland,
Andrey Smirnov, Neil Armstrong, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <1480020320-28354-3-git-send-email-peda@axentia.se>
On Thu, Nov 24, 2016 at 9:45 PM, Peter Rosin <peda@axentia.se> wrote:
> Signed-off-by: Peter Rosin <peda@axentia.se>
Pretty, satisfies my OCD.
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 6/10] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
From: Ziji Hu @ 2016-11-25 13:43 UTC (permalink / raw)
To: Ulf Hansson
Cc: Jimmy Xu, Andrew Lunn, Romain Perier, Hanna Hawa,
linux-kernel@vger.kernel.org, Nadav Haklai, Victor Gu, Doug Jones,
Jisheng Zhang, Yehuda Yitschak, Wei(SOCP) Liu, Kostya Porotchkin,
Sebastian Hesselbarth, devicetree@vger.kernel.org, Jason Cooper,
Rob Herring, Ryan Gao, Gregory CLEMENT, Marcin Wojtas,
linux-arm-kernel@lists.infradead.org, Thomas Petazzoni
In-Reply-To: <CAPDyKFoqyF5QkJy+PmGa-b8JhaUmVXeoqBfv+pdupFiJBgyiLg@mail.gmail.com>
Hi Ulf,
On 2016/11/25 21:06, Ulf Hansson wrote:
> [...]
>
>>>>>>> +
>>>>>>> + /*
>>>>>>> + * Xenon Specific property:
>>>>>>> + * emmc: explicitly indicate whether this slot is for eMMC
>>>>>>> + * slotno: the index of slot. Refer to SDHC_SYS_CFG_INFO register
>>>>>>> + * tun-count: the interval between re-tuning
>>>>>>> + * PHY type: "sdhc phy", "emmc phy 5.0" or "emmc phy 5.1"
>>>>>>> + */
>>>>>>> + if (of_property_read_bool(np, "marvell,xenon-emmc"))
>>>>>>> + priv->emmc_slot = true;
>>>>>>
>>>>>> So, you need this because of the eMMC voltage switch behaviour, right?
>>>>>>
>>>>>> Then I would rather like to describe this a generic DT bindings for
>>>>>> the eMMC voltage level support. There have acutally been some earlier
>>>>>> discussions for this, but we haven't yet made some changes.
>>>>>>
>>>>>> I think what is missing is a mmc-ddr-3_3v DT binding, which when set,
>>>>>> allows the host driver to accept I/O voltage switches to 3.3V. If not
>>>>>> supported the ->start_signal_voltage_switch() ops may return -EINVAL.
>>>>>> This would inform the mmc core to move on to the next supported
>>>>>> voltage level. There might be some minor additional changes to the mmc
>>>>>> card initialization sequence, but those should be simple.
>>>>>>
>>>>>> I can help out to look into this, unless you want to do it yourself of course!?
>>>>>>
>>>>> Yes. One of the reasons is to provide eMMC specific voltage setting.
>>>>> But in my very own opinion, it should be irrelevant to voltage level.
>>>>> The eMMC voltage setting on our SDHC is different from SD/SDIO voltage switch.
>>>>> It will become more complex with different SOC implementation details.
>>>>
>>>> Got it. Although I think we can cope with that fine just by using the
>>>> different SD/eMMC speed modes settings defined in DT (or from the
>>>> SDHCI caps register)
>>>>
>>> In my very opinion, I'm not sure if there is any corner case that driver cannot
>>> determine the eMMC card type from DT and SDHC caps.
>>>
>>>>> Unfortunately, MMC driver cannot determine the card type yet when eMMC voltage
>>>>> setting should be executed.
>>>>> Thus an flag is required here to tell driver to execute eMMC voltage setting.
>>>>>
>>>>> Besides, additional eMMC specific settings might be implemented in future, besides
>>>>> voltage setting. Most of them should be completed before MMC driver recognizes the
>>>>> card type. Thus I have to keep this flag to indicate current SDHC is for eMMC.
>>>>
>>>> I doubt you will need a generic "eMMC" flag, but let's see when we go forward.
>>>>
>>>> Currently it's clear you don't need such a flag, so I will submit a
>>>> change adding a DT binding for "mmc-ddr-3_3v" then we can take it from
>>>> there, to see if it suits your needs.
>>>>
>>
>> Another reason for a special "xenon-emmc" property is that our host IP usually can
>> support both eMMC and SD. Whether a host is used as eMMC or SD depends on the
>> final implementation of the actual product.
>> Thus our host driver needs to know whether current SDHC is fixed as eMMC or SD.
>> So far, It can only get the information from DT.
>
> As a matter of fact for mounted non-removable cards, such as eMMC, we
> already have the option to describe some of their characteristics in
> DT. Perhaps that's what you need?
>
> Please have a look at:
> Documentation/devicetree/bindings/mmc/mmc-card.txt
>
Great!
I will try this mmc-card sub-node.
Thank you very much.
Best regards,
Hu Ziji
>>
>> After out host driver get the card type information from DT, it can prepare eMMC
>> specific voltage, set eMMC specific mmc->caps/caps2 flags and do other
>> vendor specific init, before card init procedure.
>> Otherwise, our host driver has to wait until card type is determined in mmc_rescan().
>>
>> A generic "eMMC" flag is unnecessary. I just require a private property,
>> which is only used in our host driver and DT.
>>
>> Thank you.
>>
>> Best regards,
>> Hu Ziji
>>
>>>
>>> Actually, our eMMC is usually fixed as 1.8V.
>>>
>>> The pair "no-sd" + "no-sdio" can provide the similar information.
>>> But I'm not sure if it is proper to use those two property in such a way.
>>>
>>> Thank you.
>>>
>>> Best regards
>>> Hu Ziji
>>>
>>>> [...]
>>>>
>>>> Kind regards
>>>> Uffe
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>
> Kind regards
> Uffe
>
^ permalink raw reply
* Re: [PATCH 3/3] pinctrl: sx150x: add support for sx1501, sx1504, sx1505 and sx1507
From: Linus Walleij @ 2016-11-25 13:45 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Mark Rutland, Andrey Smirnov, Neil Armstrong,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1480020320-28354-4-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On Thu, Nov 24, 2016 at 9:45 PM, Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org> wrote:
> Untested, register offsets carefully copied from datasheets.
>
> Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
Why not. Nice to support all of them.
Patch applied, fixing the typ you mentioned in the follow
up in the process.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] mtd: spi-nor: add rockchip serial flash controller driver
From: Marek Vasut @ 2016-11-25 13:52 UTC (permalink / raw)
To: Shawn Lin, David Woodhouse, Brian Norris
Cc: Cyrille Pitchen, Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Heiko Stuebner
In-Reply-To: <1479437945-27918-3-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On 11/18/2016 03:59 AM, Shawn Lin wrote:
> Add rockchip serial flash controller driver
>
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
[...]
> +enum rockchip_sfc_iftype {
> + IF_TYPE_STD,
> + IF_TYPE_DUAL,
> + IF_TYPE_QUAD,
> +};
> +
> +struct rockchip_sfc;
> +struct rockchip_sfc_chip_priv {
> + u8 cs;
> + u32 clk_rate;
> + struct spi_nor nor;
> + struct rockchip_sfc *sfc;
> +};
> +
> +struct rockchip_sfc {
> + struct device *dev;
> + struct mutex lock;
> + void __iomem *regbase;
> + struct clk *hclk;
> + struct clk *clk;
> + /* virtual mapped addr for dma_buffer */
> + void *buffer;
> + dma_addr_t dma_buffer;
> + struct completion cp;
> + struct rockchip_sfc_chip_priv flash[SFC_MAX_CHIPSELECT_NUM];
> + u32 num_chip;
> + bool use_dma;
> + /* use negative edge of hclk to latch data */
> + bool negative_edge;
> +};
> +
> +static int get_if_type(enum read_mode flash_read)
> +{
> + enum rockchip_sfc_iftype if_type;
> +
> + switch (flash_read) {
> + case SPI_NOR_DUAL:
> + if_type = IF_TYPE_DUAL;
> + break;
> + case SPI_NOR_QUAD:
> + if_type = IF_TYPE_QUAD;
> + break;
> + case SPI_NOR_NORMAL:
> + case SPI_NOR_FAST:
> + if_type = IF_TYPE_STD;
> + break;
> + default:
> + pr_err("unsupported SPI read mode\n");
I'd switch this to dev_err() , so it's obvious from which device this
error came. It's OK to pass in the sfc pointer.
> + return -EINVAL;
> + }
> +
> + return if_type;
> +}
[...]
> +static int rockchip_sfc_write_reg(struct spi_nor *nor, u8 opcode,
> + u8 *buf, int len)
> +{
> + struct rockchip_sfc_chip_priv *priv = nor->priv;
> + struct rockchip_sfc *sfc = priv->sfc;
> + u32 dwords, i;
> +
> + /* Align bytes to dwords */
> + dwords = (len + 3) >> 2;
> +
> + for (i = 0; i < dwords; i++)
> + writel_relaxed(*(buf + 4 * i), sfc->regbase + SFC_DATA);
Can $buf be unaligned to 4-bytes ? :-)
> + return rockchip_sfc_op_reg(nor, opcode, len, SFC_CMD_DIR_WR);
> +}
> +
> +static inline void rockchip_sfc_setup_transfer(struct spi_nor *nor,
> + loff_t from_to,
> + size_t len, u8 op_type)
> +{
> + struct rockchip_sfc_chip_priv *priv = nor->priv;
> + struct rockchip_sfc *sfc = priv->sfc;
> + u32 reg;
> + u8 if_type = 0;
> +
> + if (op_type == SFC_CMD_DIR_WR)
> + reg = (nor->program_opcode & SFC_CMD_IDX_MASK) <<
> + SFC_CMD_IDX_SHIFT;
> + else
> + reg = (nor->read_opcode & SFC_CMD_IDX_MASK) <<
> + SFC_CMD_IDX_SHIFT;
You can define some SFC_CMD_IDX(foo) to avoid this two-line reg assignment:
#define SFC_CMD_IDX(opc) \
((opc) & SFC_CMD_IDX_MASK) << SFC_CMD_IDX_SHIFT)
reg = SFC_CMD_IDX(nor->read_opcode);
> + reg |= op_type << SFC_CMD_DIR_SHIFT;
> + reg |= (nor->addr_width == 4) ?
> + SFC_CMD_ADDR_32BITS : SFC_CMD_ADDR_24BITS;
> +
> + if_type = get_if_type(nor->flash_read);
> + writel_relaxed((if_type << SFC_CTRL_DATA_BITS_SHIFT) |
> + (if_type << SFC_CTRL_ADDR_BITS_SHIFT) |
> + (if_type << SFC_CTRL_CMD_BITS_SHIFT) |
> + (sfc->negative_edge ? SFC_CTRL_PHASE_SEL_NEGETIVE : 0),
> + sfc->regbase + SFC_CTRL);
> +
> + reg |= (priv->cs & SFC_CMD_CS_MASK) << SFC_CMD_CS_SHIFT;
> + reg |= (len & SFC_CMD_TRAN_BYTES_MASK) << SFC_CMD_TRAN_BYTES_SHIFT;
> +
> + if (op_type == SFC_CMD_DIR_RD)
> + reg |= SFC_CMD_DUMMY(nor->read_dummy);
> +
> + /* Should minus one as 0x0 means 1 bit flash address */
> + writel_relaxed(nor->addr_width * 8 - 1, sfc->regbase + SFC_ABIT);
> + writel_relaxed(reg, sfc->regbase + SFC_CMD);
> + writel_relaxed(from_to, sfc->regbase + SFC_ADDR);
> +}
> +
> +static int rockchip_sfc_dma_transfer(struct spi_nor *nor, loff_t from_to,
> + dma_addr_t dma_buf, size_t len, u8 op_type)
> +{
> + struct rockchip_sfc_chip_priv *priv = nor->priv;
> + struct rockchip_sfc *sfc = priv->sfc;
> + u32 reg;
> + int err = 0;
> +
> + init_completion(&sfc->cp);
> +
> + writel_relaxed(SFC_ICLR_RX_FULL | SFC_ICLR_RX_UFLOW |
> + SFC_ICLR_TX_OFLOW | SFC_ICLR_TX_EMPTY |
> + SFC_ICLR_TRAN_FINISH | SFC_ICLR_BUS_ERR |
> + SFC_ICLR_NSPI_ERR | SFC_ICLR_DMA,
> + sfc->regbase + SFC_ICLR);
> +
> + /* Enable transfer complete interrupt */
> + reg = readl_relaxed(sfc->regbase + SFC_IMR);
> + reg &= ~SFC_IMR_TRAN_FINISH;
> + writel_relaxed(reg, sfc->regbase + SFC_IMR);
> +
> + rockchip_sfc_setup_transfer(nor, from_to, len, op_type);
> + writel_relaxed(dma_buf, sfc->regbase + SFC_DMA_ADDR);
> +
> + /*
> + * Start dma but note that the sfc->dma_buffer is derived from
> + * dmam_alloc_coherent so we don't actually need any sync operations
> + * for coherent dma memory.
> + */
> + writel_relaxed(0x1, sfc->regbase + SFC_DMA_TRIGGER);
> +
> + /* Wait for the interrupt. */
> + if (!wait_for_completion_timeout(&sfc->cp, msecs_to_jiffies(2000))) {
> + dev_err(sfc->dev, "DMA wait for transfer finish timeout\n");
> + err = -ETIMEDOUT;
Don't you want to stop the DMA too ?
> + }
> +
> + /* Disable transfer finish interrupt */
> + reg = readl_relaxed(sfc->regbase + SFC_IMR);
> + reg |= SFC_IMR_TRAN_FINISH;
> + writel_relaxed(reg, sfc->regbase + SFC_IMR);
> +
> + if (err)
> + return err;
> +
> + return rockchip_sfc_wait_op_finish(sfc);
> +}
> +
> +static inline int rockchip_sfc_pio_write(struct rockchip_sfc *sfc, u_char *buf,
> + size_t len)
> +{
> + u32 dwords, tx_wl, count, i;
> + unsigned long timeout;
> + int ret = 0;
> + u32 *tbuf = (u32 *)buf;
> +
> + /*
> + * Align bytes to dwords, although we will write some extra
> + * bytes to fifo but the transfer bytes number in SFC_CMD
> + * register will make sure we just send out the expected
> + * byte numbers and the extra bytes will be clean before
> + * setting up the next transfer. We should always round up
> + * to align to DWORD as the ahb for Rockchip Socs won't
> + * support non-aligned-to-DWORD transfer.
> + */
> + dwords = (len + 3) >> 2;
Kernel has macros for rounding up, like DIV_ROUND_UP().
> + while (dwords) {
> + tx_wl = (readl_relaxed(sfc->regbase + SFC_FSR) >>
> + SFC_FSR_TX_WATER_LVL_SHIFT) &
> + SFC_FSR_TX_WATER_LVL_MASK;
> +
> + if (tx_wl > 0) {
> + count = min_t(u32, dwords, tx_wl);
> + for (i = 0; i < count; i++) {
> + writel_relaxed(*tbuf++,
> + sfc->regbase + SFC_DATA);
> + dwords--;
> + }
> +
> + if (dwords == 0)
> + break;
> + timeout = 0;
> + } else {
> + mdelay(1);
That is a long delay, shouldn't you wait using udelay() here ?
> + if (timeout++ > SFC_MAX_IDLE_RETRY) {
> + ret = -ETIMEDOUT;
> + break;
> + }
> + }
> + }
> +
> + if (ret)
> + return ret;
> + else
> + return rockchip_sfc_wait_op_finish(sfc);
> +}
> +
> +static inline int rockchip_sfc_pio_read(struct rockchip_sfc *sfc, u_char *buf,
> + size_t len)
> +{
> + u32 dwords, rx_wl, count, i, tmp;
> + unsigned long timeout;
> + int ret = 0;
> + u32 *tbuf = (u32 *)buf;
> + u_char *tbuf2;
> +
> + /*
> + * Align bytes to dwords, and get the remained bytes.
> + * We should always round down to DWORD as the ahb for
> + * Rockchip Socs won't support non-aligned-to-DWORD transfer.
> + * So please don't use any APIs that will finally use non-aligned
> + * read, for instance, memcpy_fromio or ioread32_rep etc.
> + */
> + dwords = len >> 2;
> + len = len & 0x3;
Won't this overwrite some bits past the $buf if you write more than $len
bytes into this memory location ?
> + while (dwords) {
> + rx_wl = (readl_relaxed(sfc->regbase + SFC_FSR) >>
> + SFC_FSR_RX_WATER_LVL_SHIFT) &
> + SFC_FSR_RX_WATER_LVL_MASK;
> +
> + if (rx_wl > 0) {
> + count = min_t(u32, dwords, rx_wl);
> + for (i = 0; i < count; i++) {
> + *tbuf++ = readl_relaxed(sfc->regbase +
> + SFC_DATA);
> + dwords--;
> + }
> +
> + if (dwords == 0)
> + break;
> + timeout = 0;
> + } else {
> + mdelay(1);
> + if (timeout++ > SFC_MAX_IDLE_RETRY) {
> + ret = -ETIMEDOUT;
> + break;
> + }
> + }
> + }
> +
> + if (ret)
> + return ret;
> +
> + /* Read the remained bytes */
> + timeout = 0;
> + tbuf2 = (u_char *)tbuf;
> + while (len) {
> + rx_wl = (readl_relaxed(sfc->regbase + SFC_FSR) >>
> + SFC_FSR_RX_WATER_LVL_SHIFT) &
> + SFC_FSR_RX_WATER_LVL_MASK;
> + if (rx_wl > 0) {
> + tmp = readl_relaxed(sfc->regbase + SFC_DATA);
> + for (i = 0; i < len; i++)
> + tbuf2[i] = (u8)((tmp >> (i * 8)) & 0xff);
> + goto done;
> + } else {
> + mdelay(1);
> + if (timeout++ > SFC_MAX_IDLE_RETRY) {
> + ret = -ETIMEDOUT;
> + break;
> + }
> + }
> + }
Seems a lot like the write path, can you unify the code ?
> +done:
> + if (ret)
> + return ret;
> + else
> + return rockchip_sfc_wait_op_finish(sfc);
> +}
> +
> +static int rockchip_sfc_pio_transfer(struct spi_nor *nor, loff_t from_to,
> + size_t len, u_char *buf, u8 op_type)
> +{
> + struct rockchip_sfc_chip_priv *priv = nor->priv;
> + struct rockchip_sfc *sfc = priv->sfc;
> +
> + rockchip_sfc_setup_transfer(nor, from_to, len, op_type);
> +
> + if (op_type == SFC_CMD_DIR_WR)
> + return rockchip_sfc_pio_write(sfc, buf, len);
> + else
> + return rockchip_sfc_pio_read(sfc, buf, len);
> +}
> +
> +static ssize_t rockchip_sfc_read(struct spi_nor *nor, loff_t from, size_t len,
> + u_char *read_buf)
> +{
> + struct rockchip_sfc_chip_priv *priv = nor->priv;
> + struct rockchip_sfc *sfc = priv->sfc;
> + size_t offset;
> + int ret;
> + dma_addr_t dma_addr = 0;
> +
> + if (!sfc->use_dma)
> + goto no_dma;
You should extract this DMA code into rockchip_sfc_dma_read/write()
instead and have this method-agnostic function only do the decision
between calling the PIO one and DMA one. That'd improve the structure
of the code a lot.
> + for (offset = 0; offset < len; offset += SFC_DMA_MAX_LEN) {
> + size_t trans = min_t(size_t, SFC_DMA_MAX_LEN, len - offset);
> +
> + dma_addr = dma_map_single(NULL, (void *)read_buf,
> + trans, DMA_FROM_DEVICE);
> + if (dma_mapping_error(sfc->dev, dma_addr))
> + dma_addr = 0;
> +
> + /* Fail to map dma, use pre-allocated area instead */
> + ret = rockchip_sfc_dma_transfer(nor, from + offset,
> + dma_addr ? dma_addr :
> + sfc->dma_buffer,
> + trans, SFC_CMD_DIR_RD);
> +
> + if (dma_addr) {
> + /* Invalidate the read data from dma_addr */
> + dma_sync_single_for_cpu(sfc->dev, dma_addr,
> + trans, DMA_FROM_DEVICE);
> + dma_unmap_single(NULL, dma_addr,
> + trans, DMA_FROM_DEVICE);
> + }
> +
> + if (ret) {
> + dev_warn(nor->dev, "DMA read timeout\n");
> + return ret;
> + }
> + if (!dma_addr)
> + memcpy(read_buf + offset, sfc->buffer, trans);
> + }
> +
> + return len;
> +
> +no_dma:
> + ret = rockchip_sfc_pio_transfer(nor, from, len,
> + read_buf, SFC_CMD_DIR_RD);
> + if (ret) {
> + dev_warn(nor->dev, "PIO read timeout\n");
> + return ret;
> + }
> + return len;
> +}
> +
> +static ssize_t rockchip_sfc_write(struct spi_nor *nor, loff_t to,
> + size_t len, const u_char *write_buf)
> +{
> + struct rockchip_sfc_chip_priv *priv = nor->priv;
> + struct rockchip_sfc *sfc = priv->sfc;
> + size_t offset;
> + int ret;
> + dma_addr_t dma_addr = 0;
> +
> + if (!sfc->use_dma)
> + goto no_dma;
> +
> + for (offset = 0; offset < len; offset += SFC_DMA_MAX_LEN) {
> + size_t trans = min_t(size_t, SFC_DMA_MAX_LEN, len - offset);
> +
> + dma_addr = dma_map_single(NULL, (void *)write_buf,
> + trans, DMA_TO_DEVICE);
> + if (dma_mapping_error(sfc->dev, dma_addr)) {
> + dma_addr = 0;
> + memcpy(sfc->buffer, write_buf + offset, trans);
> + } else {
> + /* Flush the write data to dma memory */
> + dma_sync_single_for_device(sfc->dev, dma_addr,
> + trans, DMA_TO_DEVICE);
> + }
> +
> + /* Fail to map dma, use pre-allocated area instead */
> + ret = rockchip_sfc_dma_transfer(nor, to + offset,
> + dma_addr ? dma_addr :
> + sfc->dma_buffer,
> + trans, SFC_CMD_DIR_WR);
> + if (dma_addr)
> + dma_unmap_single(NULL, dma_addr,
> + trans, DMA_TO_DEVICE);
> + if (ret) {
> + dev_warn(nor->dev, "DMA write timeout\n");
> + return ret;
> + }
> + }
Again, the read and write looks really similar. I wonder if you cannot
parametrize it and unify the code.
> + return len;
> +no_dma:
> + ret = rockchip_sfc_pio_transfer(nor, to, len,
> + (u_char *)write_buf, SFC_CMD_DIR_WR);
> + if (ret) {
> + dev_warn(nor->dev, "PIO write timeout\n");
> + return ret;
> + }
> + return len;
> +}
> +
> +/**
> + * Get spi flash device information and register it as a mtd device.
> + */
> +static int rockchip_sfc_register(struct device_node *np,
> + struct rockchip_sfc *sfc)
> +{
> + struct device *dev = sfc->dev;
> + struct mtd_info *mtd;
> + int ret;
> +
> + sfc->flash[sfc->num_chip].nor.dev = dev;
> + spi_nor_set_flash_node(&(sfc->flash[sfc->num_chip].nor), np);
> +
> + ret = of_property_read_u8(np, "reg", &sfc->flash[sfc->num_chip].cs);
> + if (ret) {
> + dev_err(dev, "No reg property for %s\n",
> + np->full_name);
> + return ret;
> + }
> +
> + ret = of_property_read_u32(np, "spi-max-frequency",
> + &sfc->flash[sfc->num_chip].clk_rate);
> + if (ret) {
> + dev_err(dev, "No spi-max-frequency property for %s\n",
> + np->full_name);
> + return ret;
> + }
> +
> + sfc->flash[sfc->num_chip].sfc = sfc;
> + sfc->flash[sfc->num_chip].nor.priv = &(sfc->flash[sfc->num_chip]);
You can add nor = sfc->flash[sfc->num_chip].nor; here to avoid
constantly replicating the whole sfc->flash[sfc->num_chip].nor .
> + sfc->flash[sfc->num_chip].nor.prepare = rockchip_sfc_prep;
> + sfc->flash[sfc->num_chip].nor.unprepare = rockchip_sfc_unprep;
> + sfc->flash[sfc->num_chip].nor.read_reg = rockchip_sfc_read_reg;
> + sfc->flash[sfc->num_chip].nor.write_reg = rockchip_sfc_write_reg;
> + sfc->flash[sfc->num_chip].nor.read = rockchip_sfc_read;
> + sfc->flash[sfc->num_chip].nor.write = rockchip_sfc_write;
> + sfc->flash[sfc->num_chip].nor.erase = NULL;
> + ret = spi_nor_scan(&(sfc->flash[sfc->num_chip].nor),
> + NULL, SPI_NOR_QUAD);
> + if (ret)
> + return ret;
> +
> + mtd = &(sfc->flash[sfc->num_chip].nor.mtd);
> + mtd->name = np->name;
> + ret = mtd_device_register(mtd, NULL, 0);
> + if (ret)
> + return ret;
> +
> + sfc->num_chip++;
> + return 0;
> +}
> +
> +static void rockchip_sfc_unregister_all(struct rockchip_sfc *sfc)
> +{
> + int i;
> +
> + for (i = 0; i < sfc->num_chip; i++)
> + mtd_device_unregister(&(sfc->flash[sfc->num_chip].nor.mtd));
Same here. Also, what happens if you have a hole in the SPI NOR
numbering, ie you have only SPI NOR 0 and 2 registered ? This will fail,
so see the cadence qspi how to handle such case.
> +}
> +
> +static int rockchip_sfc_register_all(struct rockchip_sfc *sfc)
> +{
> + struct device *dev = sfc->dev;
> + struct device_node *np;
> + int ret;
> +
> + for_each_available_child_of_node(dev->of_node, np) {
> + ret = rockchip_sfc_register(np, sfc);
> + if (ret)
> + goto fail;
> +
> + if (sfc->num_chip == SFC_MAX_CHIPSELECT_NUM) {
> + dev_warn(dev, "Exceeds the max cs limitation\n");
> + break;
> + }
> + }
> +
> + return 0;
> +
> +fail:
> + dev_err(dev, "Failed to register all chips\n");
> + /* Unregister all the _registered_ nor flash */
> + rockchip_sfc_unregister_all(sfc);
> + return ret;
> +}
[...]
> +static int rockchip_sfc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + struct rockchip_sfc *sfc;
> + int ret;
> +
> + sfc = devm_kzalloc(dev, sizeof(*sfc), GFP_KERNEL);
> + if (!sfc)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, sfc);
> + sfc->dev = dev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + sfc->regbase = devm_ioremap_resource(dev, res);
> + if (IS_ERR(sfc->regbase))
> + return PTR_ERR(sfc->regbase);
> +
> + sfc->clk = devm_clk_get(&pdev->dev, "sfc");
> + if (IS_ERR(sfc->clk)) {
> + dev_err(&pdev->dev, "Failed to get sfc interface clk\n");
> + return PTR_ERR(sfc->clk);
> + }
> +
> + sfc->hclk = devm_clk_get(&pdev->dev, "hsfc");
> + if (IS_ERR(sfc->hclk)) {
> + dev_err(&pdev->dev, "Failed to get sfc ahp clk\n");
> + return PTR_ERR(sfc->hclk);
> + }
> +
> + ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
> + if (ret) {
> + dev_warn(dev, "Unable to set dma mask\n");
> + return ret;
> + }
> +
> + sfc->buffer = dmam_alloc_coherent(dev, SFC_DMA_MAX_LEN,
> + &sfc->dma_buffer, GFP_KERNEL);
> + if (!sfc->buffer)
> + return -ENOMEM;
> +
> + mutex_init(&sfc->lock);
> +
> + ret = clk_prepare_enable(sfc->hclk);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to enable hclk\n");
> + goto err_hclk;
> + }
> +
> + ret = clk_prepare_enable(sfc->clk);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to enable clk\n");
> + goto err_clk;
> + }
> +
> + sfc->use_dma = !of_property_read_bool(sfc->dev->of_node,
> + "rockchip,sfc-no-dma");
> +
> + sfc->negative_edge = of_device_is_compatible(sfc->dev->of_node,
> + "rockchip,rk1108-sfc");
I think this should rather be a boolean property -- but isn't this
something like CPOL or CPHA anyway ?
> + /* Find the irq */
> + ret = platform_get_irq(pdev, 0);
> + if (ret < 0) {
> + dev_err(dev, "Failed to get the irq\n");
> + goto err_irq;
> + }
> +
> + ret = devm_request_irq(dev, ret, rockchip_sfc_irq_handler,
> + 0, pdev->name, sfc);
> + if (ret) {
> + dev_err(dev, "Failed to request irq\n");
> + goto err_irq;
> + }
> +
> + sfc->num_chip = 0;
> + ret = rockchip_sfc_init(sfc);
> + if (ret)
> + goto err_irq;
> +#if 1
> + pm_runtime_get_noresume(&pdev->dev);
> + pm_runtime_set_active(&pdev->dev);
> + pm_runtime_enable(&pdev->dev);
> + pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
> + pm_runtime_use_autosuspend(&pdev->dev);
> +#endif
#if 1, remove, #endif :-)
> + ret = rockchip_sfc_register_all(sfc);
> + if (ret)
> + goto err_register;
> +
> + clk_disable_unprepare(sfc->clk);
> + pm_runtime_put_autosuspend(&pdev->dev);
> + return 0;
> +
> +err_register:
> + pm_runtime_disable(&pdev->dev);
> + pm_runtime_set_suspended(&pdev->dev);
> + pm_runtime_put_noidle(&pdev->dev);
> +err_irq:
> + clk_disable_unprepare(sfc->clk);
> +err_clk:
> + clk_disable_unprepare(sfc->hclk);
> +err_hclk:
> + mutex_destroy(&sfc->lock);
> + return ret;
> +}
> +
> +static int rockchip_sfc_remove(struct platform_device *pdev)
> +{
> + struct rockchip_sfc *sfc = platform_get_drvdata(pdev);
> +
> + pm_runtime_get_sync(&pdev->dev);
> + pm_runtime_disable(&pdev->dev);
> + pm_runtime_put_noidle(&pdev->dev);
> +
> + rockchip_sfc_unregister_all(sfc);
> + mutex_destroy(&sfc->lock);
> + clk_disable_unprepare(sfc->clk);
> + clk_disable_unprepare(sfc->hclk);
> + return 0;
> +}
> +
> +#ifdef CONFIG_PM
> +int rockchip_sfc_runtime_suspend(struct device *dev)
> +{
> + struct rockchip_sfc *sfc = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(sfc->hclk);
> + return 0;
> +}
> +
> +int rockchip_sfc_runtime_resume(struct device *dev)
> +{
> + struct rockchip_sfc *sfc = dev_get_drvdata(dev);
> +
> + clk_prepare_enable(sfc->hclk);
> + return 0;
> +}
> +#endif /* CONFIG_PM */
> +
> +static const struct of_device_id rockchip_sfc_dt_ids[] = {
> + { .compatible = "rockchip,sfc"},
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, rockchip_sfc_dt_ids);
> +
> +static const struct dev_pm_ops rockchip_sfc_dev_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> + pm_runtime_force_resume)
> + SET_RUNTIME_PM_OPS(rockchip_sfc_runtime_suspend,
> + rockchip_sfc_runtime_resume, NULL)
> +};
> +
> +static struct platform_driver rockchip_sfc_driver = {
> + .driver = {
> + .name = "rockchip-sfc",
> + .of_match_table = rockchip_sfc_dt_ids,
> + .pm = &rockchip_sfc_dev_pm_ops,
> + },
> + .probe = rockchip_sfc_probe,
> + .remove = rockchip_sfc_remove,
> +};
> +module_platform_driver(rockchip_sfc_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("Rockchip Serial Flash Controller Driver");
> +MODULE_AUTHOR("Shawn Lin");
Email in MODULE_AUTHOR would be great addition.
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] mtd: spi-nor: add rockchip serial flash controller driver
From: Marek Vasut @ 2016-11-25 13:54 UTC (permalink / raw)
To: Shawn Lin, Rob Herring, David Woodhouse, Brian Norris
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Heiko Stuebner,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <76670120-dacd-ef0e-cf36-cbf549b19853-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On 11/21/2016 03:51 AM, Shawn Lin wrote:
> Hi Marek,
Hi!
[...]
>>> sfc->num_chip stands for how many flashes registered successfully.
>>
>> Does it work if you have a hole in there ? Like if you have a flash on
>> chipselect 0 and chipselect 2 ?
>
> Yes it does, as it won't leave a room for chipselect 1 whose node isn't
> present, which means there isn't a hole in there at all. :)
Ah , because you are not indexing those NORs with their CS number , right ?
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] mtd: spi-nor: add rockchip serial flash controller driver
From: Marek Vasut @ 2016-11-25 13:55 UTC (permalink / raw)
To: Shawn Lin, David Woodhouse, Brian Norris
Cc: Cyrille Pitchen, Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Heiko Stuebner
In-Reply-To: <1479437945-27918-3-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On 11/18/2016 03:59 AM, Shawn Lin wrote:
> Add rockchip serial flash controller driver
>
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
[...]
> +static void rockchip_sfc_unregister_all(struct rockchip_sfc *sfc)
> +{
> + int i;
> +
> + for (i = 0; i < sfc->num_chip; i++)
> + mtd_device_unregister(&(sfc->flash[sfc->num_chip].nor.mtd));
^^^^^^^^^^^^^
This will always unregister the same flash, no ? This cannot work.
> +}
[...]
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] mtd/spi-nor: Add SPI memory controllers for Aspeed SoCs
From: Marek Vasut @ 2016-11-25 13:57 UTC (permalink / raw)
To: Joel Stanley, Cédric Le Goater
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
Brian Norris, Boris Brezillon, Richard Weinberger,
Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Mark Rutland
In-Reply-To: <CACPK8Xc7Dy=4oaZ_+j3hCEkMY+sqZ_-QkCQ9okmUoOjTpuZvvA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/21/2016 05:45 AM, Joel Stanley wrote:
> Hello Marek,
Hi!
> Thank you for the review. I have answered a few of your questions;
> I'll leave the rest to Cedric.
>
> On Mon, Nov 21, 2016 at 8:13 AM, Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
>>> index 4a682ee0f632..96148600fdab 100644
>>> --- a/drivers/mtd/spi-nor/Kconfig
>>> +++ b/drivers/mtd/spi-nor/Kconfig
>>> @@ -76,4 +76,16 @@ config SPI_NXP_SPIFI
>>> Flash. Enable this option if you have a device with a SPIFI
>>> controller and want to access the Flash as a mtd device.
>>>
>>> +config ASPEED_FLASH_SPI
>>
>> Should be SPI_ASPEED , see the other controllers and keep the list sorted.
>
> Perhaps SPI_NOR_ASPEED so it's clear it's not a driver for a generic SPI bus?
But it's not a driver for SPI-NOR only either, it seems it's a driver
for multiple distinct devices.
>>> + tristate "Aspeed flash controllers in SPI mode"
>>> + depends on HAS_IOMEM && OF
>>> + depends on ARCH_ASPEED || COMPILE_TEST
>>> + # IO_SPACE_LIMIT must be equivalent to (~0UL)
>>> + depends on !NEED_MACH_IO_H
>>
>> Why?
>>
>>> + help
>>> + This enables support for the New Static Memory Controller
>>> + (FMC) in the Aspeed SoCs (AST2400 and AST2500) when attached
>>> + to SPI nor chips, and support for the SPI Memory controller
>>> + (SPI) for the BIOS.
>>
>> I think there is a naming chaos between FMC, SMC (as in Static MC) and
>> SMC (as in SPI MC).
>
> Yes, you're spot on. This naming chaos comes form the vendor's documentation.
>
> I think we could re-work this sentence to make it clearer.
Please do before someone's head explodes from this :)
>>> +static int aspeed_smc_read_from_ahb(void *buf, const void __iomem *src,
>>> + size_t len)
>>> +{
>>
>> What if start of buf is unaligned ?
>>
>>> + if ((((unsigned long)src | (unsigned long)buf | len) & 3) == 0) {
>>
>> Uh, should use boolean OR, not bitwise or. Also, if you're testing
>> pointer for NULL, do if (!ptr) .
>>
>> if (!src || !buf || !len)
>> return;
>
> That's a different test. We're testing here that the buffers are
> aligned to see if we can do a word-at-a-time copy.
>
> If not, it falls through to do a byte-at-a-time copy. I think this
> covers your first question about buf being unaligned.
Ah, I see, thanks for clarifying. Comment in the code would be helpful
for why what you're doing is OK. And I think you want to cast to
uintptr_t instead to make this work on 64bit.
> Cedric, perhaps you could create a macro called IS_ALLIGNED to make it
> clear what this is doing?
Yup, thanks!
>>
>> while (...)
>>
>>> + while (len > 3) {
>>> + *(u32 *)buf = readl(src);
>>> + buf += 4;
>>> + src += 4;
>>> + len -= 4;
>>> + }
>>> + }
>>> +
>>> + while (len--) {
>>> + *(u8 *)buf = readb(src);
>>> + buf += 1;
>>> + src += 1;
>>> + }
>>> + return 0;
>>> +}
>>> +/*
>>> + * SPI Flash Configuration Register (AST2400 SPI)
>>> + */
>>> +#define CONFIG_REG 0x0
>>> +#define CONFIG_ENABLE_CE_INACTIVE BIT(1)
>>> +#define CONFIG_WRITE BIT(0)
>>
>> #define[space]FOO[tab]BIT(bar)
>
> These are bits within the CONFIG_REG. It follows the same style as
> other spi-nor drivers, eg. nxp-spifi.
>
> I think it's somewhat clearer, but if you have a strong preference
> against then fair enough.
It triggers my OCD, but I think it's a matter of taste, so I don't care
that much.
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/10] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
From: Adrian Hunter @ 2016-11-25 14:04 UTC (permalink / raw)
To: Ulf Hansson, Ziji Hu
Cc: Jimmy Xu, Andrew Lunn, Romain Perier, Hanna Hawa, Nadav Haklai,
Zhen Huang, Victor Gu, Doug Jones, Jisheng Zhang, Yehuda Yitschak,
Wei(SOCP) Liu, Kostya Porotchkin, Sebastian Hesselbarth,
devicetree@vger.kernel.org, Jason Cooper, Rob Herring, Ryan Gao,
Gregory CLEMENT, Marcin Wojtas,
linux-arm-kernel@lists.infradead.org, Thomas Petazzoni, linux-mmc
In-Reply-To: <CAPDyKFr9uEjVQmTNP0KK8Zj9mxCW3i564E=47vTK0RLvXCjw3Q@mail.gmail.com>
On 24/11/16 15:34, Ulf Hansson wrote:
> On 24 November 2016 at 13:41, Ziji Hu <huziji@marvell.com> wrote:
>> On 2016/11/24 18:43, Ulf Hansson wrote:
>>> On 31 October 2016 at 12:09, Gregory CLEMENT
>>> <gregory.clement@free-electrons.com> wrote:
>>>> From: Ziji Hu <huziji@marvell.com>
>>>> +static int xenon_start_signal_voltage_switch(struct mmc_host *mmc,
>>>> + struct mmc_ios *ios)
>>>> +{
>>>> + struct sdhci_host *host = mmc_priv(mmc);
>>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>>> +
>>>> + /*
>>>> + * Before SD/SDIO set signal voltage, SD bus clock should be
>>>> + * disabled. However, sdhci_set_clock will also disable the Internal
>>>> + * clock in mmc_set_signal_voltage().
>>>
>>> If that's the case then that is wrong in the generic sdhci code.
>>> What's the reason why it can't be fixed there instead of having this
>>> workaround?
>>>
>> In my very own opinion, SD Spec doesn't specify whether SDCLK should be
>> enabled or not during power setting.
>> Enabling SDCLK might be a special condition only required by our SDHC.
>> I try to avoid breaking other vendors' SDHC functionality
>> if their SDHCs require SDCLK disabled.
>> Thus I prefer to keep it inside our SDHC driver.
>
> I let Adrian comment on this.
>
> For sure we should avoid breaking other sdhci variant, but on the
> other hand *if* the generic code is wrong we should fix it!
Yes, this looks like something that could perhaps be fixed in sdhci. I will
look into it.
^ permalink raw reply
* [PATCH v5 0/2] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-25 14:26 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth
Cc: Mark Rutland, devicetree, Tomas Hlavacek, Rob Herring,
linux-arm-kernel, Bedřicha Košatu
Hello,
This is basicly my v3 plus some of the changes that Tomas changed for
his RFC patch (implicitly "v4"). So compared to v3 the following
changed:
- Add more documentation (mostly from Tomas)
- Add more mbus ranges (by Tomas)
- Move link to schematic below copyright header (suggested by Andrew)
- reenable rtc as this is not that broken on production board
- fix spi chip select pinmuxing
Uwe Kleine-König (2):
devicetree: Add vendor prefix for CZ.NIC
ARM: dts: add support for Turris Omnia
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-385-turris-omnia.dts | 334 +++++++++++++++++++++
3 files changed, 336 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts
--
2.10.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 1/2] devicetree: Add vendor prefix for CZ.NIC
From: Uwe Kleine-König @ 2016-11-25 14:26 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth
Cc: Mark Rutland, devicetree, Tomas Hlavacek, Rob Herring,
linux-arm-kernel, Bedřicha Košatu
In-Reply-To: <20161125142658.21690-1-uwe@kleine-koenig.org>
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index f0a48ea78659..ae9fce9fed03 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -67,6 +67,7 @@ creative Creative Technology Ltd
crystalfontz Crystalfontz America, Inc.
cubietech Cubietech, Ltd.
cypress Cypress Semiconductor Corporation
+cznic CZ.NIC, z.s.p.o.
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
davicom DAVICOM Semiconductor, Inc.
delta Delta Electronics, Inc.
--
2.10.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 2/2] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-25 14:26 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth
Cc: Mark Rutland, devicetree, Tomas Hlavacek, Rob Herring,
linux-arm-kernel, Bedřicha Košatu
In-Reply-To: <20161125142658.21690-1-uwe@kleine-koenig.org>
This machine is an open hardware router by cz.nic driven by a
Marvell Armada 385.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-385-turris-omnia.dts | 334 ++++++++++++++++++++++++++
2 files changed, 335 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd2619902..f1d3b9ff257e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-385-db-ap.dtb \
armada-385-linksys-caiman.dtb \
armada-385-linksys-cobra.dtb \
+ armada-385-turris-omnia.dtb \
armada-388-clearfog.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
new file mode 100644
index 000000000000..bcc10c285889
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -0,0 +1,334 @@
+/*
+ * Device Tree file for the Turris Omnia
+ *
+ * Copyright (C) 2016 Uwe Kleine-König <uwe@kleine-koenig.org>
+ * Copyright (C) 2016 Tomas Hlavacek <tmshlvkc@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "armada-385.dtsi"
+
+/ {
+ model = "Turris Omnia";
+ compatible = "cznic,turris-omnia", "marvell,armada385", "marvell,armada380";
+
+ chosen {
+ stdout-path = &uart0;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x40000000>; /* 1024 MB */
+ };
+
+ soc {
+ ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+ MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
+ MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
+ MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
+
+ internal-regs {
+
+ /* USB part of the PCIe2/USB 2.0 port */
+ usb@58000 {
+ status = "okay";
+ };
+
+ sata@a8000 {
+ status = "okay";
+ };
+
+ sdhci@d8000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdhci_pins>;
+ status = "okay";
+
+ bus-width = <8>;
+ no-1-8-v;
+ non-removable;
+ };
+
+ usb3@f0000 {
+ status = "okay";
+ };
+
+ usb3@f8000 {
+ status = "okay";
+ };
+ };
+
+ pcie-controller {
+ status = "okay";
+
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+ };
+
+ pcie@2,0 {
+ /* Port 1, Lane 0 */
+ status = "okay";
+ };
+
+ pcie@3,0 {
+ /* Port 2, Lane 0 */
+ status = "okay";
+ };
+ };
+ };
+};
+
+/* Connected to 88E6176 switch, port 6 */
+ð0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge0_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+/* Connected to 88E6176 switch, port 5 */
+ð1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge1_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+/* WAN port */
+ð2 {
+ status = "okay";
+ phy-mode = "sgmii";
+ phy = <&phy1>;
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "okay";
+
+ i2cmux@70 {
+ compatible = "nxp,pca9547";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+ status = "okay";
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ /* STM32F0 command interface at address 0x2a */
+ /* leds device (in STM32F0) at address 0x2b */
+
+ eeprom@54 {
+ compatible = "at,24c64";
+ reg = <0x54>;
+
+ /* The EEPROM contains data for bootloader.
+ * Contents:
+ * struct omnia_eeprom {
+ * u32 magic; (=0x0341a034 in LE)
+ * u32 ramsize; (in GiB)
+ * char regdomain[4];
+ * u32 crc32;
+ * };
+ */
+ };
+ };
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ /* routed to PCIe0/mSATA connector (CN7A) */
+ };
+
+ i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+
+ /* routed to PCIe1/USB2 connector (CN61A) */
+ };
+
+ i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ /* routed to PCIe2 connector (CN62A) */
+ };
+
+ i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+
+ /* routed to SFP+ */
+ };
+
+ i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+
+ /* ATSHA204A at address 0x64 */
+ };
+
+ i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+
+ /* exposed on pin header */
+ };
+
+ i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+
+ pcawan: gpio@71 {
+ /*
+ * GPIO expander for SFP+ signals and
+ * and phy irq
+ */
+ compatible = "nxp,pca9538";
+ reg = <0x71>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcawan_pins>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+ };
+};
+
+&mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins>;
+ status = "okay";
+
+ phy1: phy@1 {
+ status = "okay";
+ compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+
+ /* irq is connected to &pcawan pin 7 */
+ };
+
+ /* Switch MV88E7176 at address 0x10 */
+};
+
+&pinctrl {
+ pcawan_pins: pcawan-pins {
+ marvell,pins = "mpp46";
+ marvell,function = "gpio";
+ };
+
+ spi0cs0_pins: spi0cs0-pins {
+ marvell,pins = "mpp25";
+ marvell,function = "spi0";
+ };
+
+ spi0cs1_pins: spi0cs1-pins {
+ marvell,pins = "mpp26";
+ marvell,function = "spi0";
+ };
+};
+
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins &spi0cs0_pins>;
+ status = "okay";
+
+ spi-nor@0 {
+ compatible = "spansion,s25fl164k", "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+
+ partition@0 {
+ reg = <0x0 0x00100000>;
+ label = "U-Boot";
+ };
+
+ partition@1 {
+ reg = <0x00100000 0x00700000>;
+ label = "Rescue system";
+ };
+ };
+
+ /* MISO, MOSI, SCLK and CS1 are routed to pin header CN11 */
+};
+
+&uart0 {
+ /* Pin header CN10 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+};
+
+&uart1 {
+ /* Pin header CN11 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+ status = "okay";
+};
--
2.10.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v5 2/2] ARM: dts: add support for Turris Omnia
From: Andrew Lunn @ 2016-11-25 14:32 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jason Cooper, Gregory Clement, Sebastian Hesselbarth,
Tomas Hlavacek, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Bed??icha Ko??atu
In-Reply-To: <20161125142658.21690-3-uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
On Fri, Nov 25, 2016 at 03:26:58PM +0100, Uwe Kleine-König wrote:
> This machine is an open hardware router by cz.nic driven by a
> Marvell Armada 385.
>
> Signed-off-by: Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/2] usb: ohci: s3c2410: add device tree support
From: Sergio Prado @ 2016-11-25 14:47 UTC (permalink / raw)
To: gregkh, robh+dt, mark.rutland, stern, kgene, krzk, javier,
linux-usb, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc
Cc: Sergio Prado
This series adds support for configuring Samsung's s3c2410 and
compatible USB OHCI controller via devicetree.
Tested on FriendlyARM mini2440, based on s3c2440 SoC.
Sergio Prado (2):
dt-bindings: usb: add DT binding for s3c2410 USB OHCI controller
usb: ohci: s3c2410: allow probing from device tree
.../devicetree/bindings/usb/s3c2410-usb.txt | 22 ++++++++++++++++++++++
drivers/usb/host/ohci-s3c2410.c | 8 ++++++++
2 files changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/s3c2410-usb.txt
--
1.9.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox