* Re: [PATCH 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.
From: Eric Anholt @ 2017-04-21 22:53 UTC (permalink / raw)
To: Daniel Vetter
Cc: dri-devel, Rob Herring, Mark Rutland, devicetree@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <CAKMK7uHBE1Qtjr2dM3U9edEfZ0mXVEjcw+hs8mF9ZkRP4Vcm=A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]
Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org> writes:
> On Wed, Apr 19, 2017 at 7:55 PM, Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org> wrote:
>> Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org> writes:
>>> On Tue, Apr 18, 2017 at 9:11 PM, Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org> wrote:
>>>> The FBDEV initialization would throw an error in dmesg, when we just
>>>> want to silently not initialize fbdev on a V3D-only VC4 instance.
>>>>
>>>> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
>>>
>>> Hm, this shouldn't be an error really, you might want to hotplug more
>>> connectors later on. What exactly complains?
>>
>> drm_fb_helper_init() throws an error if the passed in connector count is
>> 0, so drm_fb_cma_helper() printks an error.
>
> Oh, _that_ thing. The error in there is correct, but (almost) everyone
> gets this parameter wrong. This isn't the max number of connectors the
> fb helper will light up, but just the max number of connectors _per_
> crtc when driving in hw clone mode. There's two problems with that:
> - fb helpers don't support hw clone mode, we select 1:1 crtcs for each
> active connector
> - I mentioned that everyone gets this wrong?
>
> If you're moderately bored it'd be great to nuke the max_connector
> argument from drm_fb_helper_init, and hard-code it to 1 (with a big
> comment explaining that this needs to be changed, probably with
> dynamic reallocation, once someone gets around to implementing hw
> clone mode).
>
> If you're less bored, just hardcode this to 1 in vc4 and done. Plus a
> TODO.rst entry would be great in that case.
If I'm driving a GPU with no display subsystem at all, it seems like I
shouldn't initialize fbdev for it, right?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* [PATCH 0/4] RTL8211E-specified hacks
From: Icenowy Zheng @ 2017-04-21 23:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Rob Herring
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
Some Pine64 boards are reported to have broken RTL8211E PHYs, which will fail
to work at 1000BASE-T mode if not workarounded.
The workaround is retrieved from Pine64, and is said to be from Realtek
engineer. It's undocumented but effective. (Tested on my Pine64 with GbE
broken)
The first patch is a small tweak for Realtek PHY driver, which removed the
"F" in page select register name, as RTL8211E also uses the same register
as page select (although with some different difinition).
The second patch adds a binding for the PHY, specified for this hack.
The third patch is the real driver part of this hack, which contains
some magic numbers from Pine64/Realtek.
The fourth patch is for reference only and should not be merged -- to
use it you will need sun8i-emac or dwmac-sun8i patchset applied.
Icenowy Zheng (4):
net: phy: realtek: change macro name for page select register
dt-bindings: add binding for RTL8211E Ethernet PHY
net: phy: realtek: add disable RX delay hack for RTL8211E
[DO NOT MERGE] arm64: allwinner: a64: enable RTL8211E PHY workaround
.../devicetree/bindings/net/realtek,rtl8211e.txt | 22 ++++++++++
.../boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 4 ++
drivers/net/phy/realtek.c | 48 +++++++++++++++++++---
3 files changed, 69 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
--
2.12.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/4] net: phy: realtek: change macro name for page select register
From: Icenowy Zheng @ 2017-04-21 23:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Rob Herring
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170421232436.10924-1-icenowy-h8G6r0blFSE@public.gmane.org>
From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
The page select register also exists on RTL8211E PHY (although it
behaves slightly differently).
Change the register macro name to remove the F.
Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
---
drivers/net/phy/realtek.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 9cbe645e3d89..d820d00addf6 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -22,11 +22,13 @@
#define RTL821x_INER 0x12
#define RTL821x_INER_INIT 0x6400
#define RTL821x_INSR 0x13
+
+#define RTL8211_PAGE_SELECT 0x1f
+
#define RTL8211E_INER_LINK_STATUS 0x400
#define RTL8211F_INER_LINK_STATUS 0x0010
#define RTL8211F_INSR 0x1d
-#define RTL8211F_PAGE_SELECT 0x1f
#define RTL8211F_TX_DELAY 0x100
MODULE_DESCRIPTION("Realtek PHY driver");
@@ -46,10 +48,10 @@ static int rtl8211f_ack_interrupt(struct phy_device *phydev)
{
int err;
- phy_write(phydev, RTL8211F_PAGE_SELECT, 0xa43);
+ phy_write(phydev, RTL8211_PAGE_SELECT, 0xa43);
err = phy_read(phydev, RTL8211F_INSR);
/* restore to default page 0 */
- phy_write(phydev, RTL8211F_PAGE_SELECT, 0x0);
+ phy_write(phydev, RTL8211_PAGE_SELECT, 0x0);
return (err < 0) ? err : 0;
}
@@ -102,7 +104,7 @@ static int rtl8211f_config_init(struct phy_device *phydev)
if (ret < 0)
return ret;
- phy_write(phydev, RTL8211F_PAGE_SELECT, 0xd08);
+ phy_write(phydev, RTL8211_PAGE_SELECT, 0xd08);
reg = phy_read(phydev, 0x11);
/* enable TX-delay for rgmii-id and rgmii-txid, otherwise disable it */
@@ -114,7 +116,7 @@ static int rtl8211f_config_init(struct phy_device *phydev)
phy_write(phydev, 0x11, reg);
/* restore to default page 0 */
- phy_write(phydev, RTL8211F_PAGE_SELECT, 0x0);
+ phy_write(phydev, RTL8211_PAGE_SELECT, 0x0);
return 0;
}
--
2.12.2
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: add binding for RTL8211E Ethernet PHY
From: Icenowy Zheng @ 2017-04-21 23:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Rob Herring
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170421232436.10924-1-icenowy-h8G6r0blFSE@public.gmane.org>
From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
Some RTL8211E Ethernet PHY have an issue that needs a workaround
indicated with device tree.
Add the binding for a property that indicates this workaround.
Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
---
.../devicetree/bindings/net/realtek,rtl8211e.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
diff --git a/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt b/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
new file mode 100644
index 000000000000..c1913301bfe8
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
@@ -0,0 +1,22 @@
+Realtek RTL8211E Ethernet PHY
+
+One batch of RTL8211E is slight broken, that needs some special (and
+full of magic numbers) tweaking in order to make GbE to operate properly.
+The only well-known board that used the broken batch is Pine64+.
+Configure it through an Ethernet OF device node.
+
+Optional properties:
+
+- realtek,disable-rx-delay:
+ If set, RX delay will be completely disabled (according to Realtek). This
+ will affect the performance on non-broken boards.
+ default: do not disable RX delay.
+
+Examples:
+Pine64+ with broken RTL8211E:
+&mdio {
+ ext_phy: ethernet-phy@0 {
+ reg = <0>;
+ realtek,disable-rx-delay;
+ };
+};
--
2.12.2
^ permalink raw reply related
* [PATCH 3/4] net: phy: realtek: add disable RX delay hack for RTL8211E
From: Icenowy Zheng @ 2017-04-21 23:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Rob Herring
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170421232436.10924-1-icenowy-h8G6r0blFSE@public.gmane.org>
From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
Some RTL8211E chips have broken GbE function, which needs a hack to
fix. It's said that this fix will affect the performance on not-buggy
PHYs, so it should only be enabled on boards with the broken PHY.
Currently only some Pine64+ boards are known to have this issue.
This hack is said to disable RX relay for RTL8211E according to Realtek.
Enable this hack when a certain device tree property is set.
As this hack is not documented on the datasheet at all, it contains
magic numbers, and could not be revealed. These magic numbers are
received from Realtek via Pine64.
Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
---
drivers/net/phy/realtek.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index d820d00addf6..880022160cd2 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -13,6 +13,7 @@
* option) any later version.
*
*/
+#include <linux/of.h>
#include <linux/phy.h>
#include <linux/module.h>
@@ -26,6 +27,8 @@
#define RTL8211_PAGE_SELECT 0x1f
#define RTL8211E_INER_LINK_STATUS 0x400
+#define RTL8211E_EXT_PAGE_SELECT 0x1e
+#define RTL8211E_EXT_PAGE 0x7
#define RTL8211F_INER_LINK_STATUS 0x0010
#define RTL8211F_INSR 0x1d
@@ -121,6 +124,38 @@ static int rtl8211f_config_init(struct phy_device *phydev)
return 0;
}
+static int rtl8211e_config_init(struct phy_device *phydev)
+{
+ struct device *dev = &phydev->mdio.dev;
+ struct device_node *of_node = dev->of_node;
+ int ret;
+
+ ret = genphy_config_init(phydev);
+ if (ret < 0)
+ return ret;
+
+ if (of_node &&
+ of_property_read_bool(of_node, "realtek,disable-rx-delay")) {
+ /* All these magic numbers are retrieved from Pine64, and
+ * they're said to be originated from Realtek.
+ *
+ * The datasheet of RTL8211E didn't cover this ext page.
+ *
+ * Select extension page 0xa4 here.
+ */
+ phy_write(phydev, RTL8211_PAGE_SELECT, RTL8211E_EXT_PAGE)
+ phy_write(phydev, RTL8211E_EXT_PAGE_SELECT, 0xa4);
+
+ /* Write the magic number */
+ phy_write(phydev, 0x1c, 0xb591);
+
+ /* Restore to default page 0 */
+ phy_write(phydev, RTL8211_PAGE_SELECT, 0);
+ }
+
+ return 0;
+}
+
static struct phy_driver realtek_drvs[] = {
{
.phy_id = 0x00008201,
@@ -159,6 +194,7 @@ static struct phy_driver realtek_drvs[] = {
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_aneg = &genphy_config_aneg,
+ .config_init = rtl8211e_config_init,
.read_status = &genphy_read_status,
.ack_interrupt = &rtl821x_ack_interrupt,
.config_intr = &rtl8211e_config_intr,
--
2.12.2
^ permalink raw reply related
* [PATCH 4/4] [DO NOT MERGE] arm64: allwinner: a64: enable RTL8211E PHY workaround
From: Icenowy Zheng @ 2017-04-21 23:24 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Rob Herring
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170421232436.10924-1-icenowy-h8G6r0blFSE@public.gmane.org>
From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
Some Pine64+ boards are said to have broken RTL8211E PHY.
Enable the workaround in Pine64+ device tree file.
Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
index 790d14daaa6a..1f59ee4f8b45 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
@@ -48,3 +48,7 @@
/* TODO: Camera, Ethernet PHY, touchscreen, etc. */
};
+
+&ext_phy {
+ realtek,disable-rx-delay;
+};
--
2.12.2
^ permalink raw reply related
* Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller
From: Peter Rosin @ 2017-04-21 23:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, Wolfram Sang, Rob Herring, Mark Rutland,
Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Jonathan Corbet, linux-i2c, devicetree,
linux-iio, linux-doc, Andrew Morton, Colin Ian King,
Paul Gortmaker, Philipp Zabel, kernel
In-Reply-To: <0f605429-afa2-2818-96d5-5da0bad122d6@axentia.se>
On 2017-04-20 23:53, Peter Rosin wrote:
> On 2017-04-18 23:53, Peter Rosin wrote:
>> On 2017-04-18 13:44, Greg Kroah-Hartman wrote:
>>> On Tue, Apr 18, 2017 at 12:59:50PM +0200, Peter Rosin wrote:
>>>> On 2017-04-18 10:51, Greg Kroah-Hartman wrote:
>>>>> On Thu, Apr 13, 2017 at 06:43:07PM +0200, Peter Rosin wrote:
>
> *snip*
>
>>>>>> + if (mux->idle_state != MUX_IDLE_AS_IS &&
>>>>>> + mux->idle_state != mux->cached_state)
>>>>>> + ret = mux_control_set(mux, mux->idle_state);
>>>>>> +
>>>>>> + up_read(&mux->lock);
>>>>>
>>>>> You require a lock to be held for a "global" function? Without
>>>>> documentation? Or even a sparse marking? That's asking for trouble...
>>>>
>>>> Documentation I can handle, but where should I look to understand how I
>>>> should add sparse markings?
>>>
>>> Run sparse on the code and see what it says :)
>>
>> Will do.
>
> I just did, and even went through the trouble of getting the bleeding
> edge sparse from the git repo when sparse 0.5.0 came up empty, but it's
> all silence for me. So, how do I add sparse markings?
I looked some more into this, and the markings I find that seem related
are __acquire() and __release(). But neither mutex_lock() nor up_read()
has markings like that, so adding them when using those kinds of locks
in an imbalanced way seems like a sure way of *getting* sparse messages
about context imbalance...
So, either that, or you are talking about __must_check markings?
I feel like I'm missing something, please advise further.
Cheers,
peda
^ permalink raw reply
* Re: [PATCH 2/3] usb: add DT bindings for farady fotg2 host controller
From: Linus Walleij @ 2017-04-22 0:22 UTC (permalink / raw)
To: Hans Ulli Kroll
Cc: Rob Herring, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux USB List, Greg Kroah-Hartman, Mark Rutland
In-Reply-To: <alpine.LNX.2.00.1703302023250.17971@T420s>
On Thu, Mar 30, 2017 at 8:31 PM, Hans Ulli Kroll
<ulli.kroll-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
>> On Tue, Feb 21, 2017 at 3:43 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> > On Fri, Feb 17, 2017 at 4:07 AM, Hans Ulli Kroll
>> > <ulli.kroll-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
>> >> Hi Rob,
>> >>
>> >> On Wed, 15 Feb 2017, Rob Herring wrote:
>> >>
>> >>> On Wed, Feb 08, 2017 at 09:00:09PM +0100, Hans Ulli Kroll wrote:
>> >>> > This adds DT bindings for the Faraday FOTG2 host controller.
>> >>> >
>> >>> > Signed-off-by: Hans Ulli Kroll <ulli.kroll-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>> >>> > ---
>> >>> > Documentation/devicetree/bindings/usb/fotg2-host.txt | 15 +++++++++++++++
>> >>> > 1 file changed, 15 insertions(+)
>> >>> > create mode 100644 Documentation/devicetree/bindings/usb/fotg2-host.txt
>> >>> >
>> >>> > diff --git a/Documentation/devicetree/bindings/usb/fotg2-host.txt b/Documentation/devicetree/bindings/usb/fotg2-host.txt
>> >>> > new file mode 100644
>> >>> > index 000000000000..4c07566a4bf5
>> >>> > --- /dev/null
>> >>> > +++ b/Documentation/devicetree/bindings/usb/fotg2-host.txt
>> >>> > @@ -0,0 +1,15 @@
>> >>> > +Faraday FOTG Host controller
>> >>> > +
>> >>> > +Required properties:
>> >>> > +
>> >>> > +- compatible: should be "faraday,fotg210-hcd"
>> >>>
>> >>> hcd as in "host controller driver"? Bindings describe h/w not drivers.
>> >>>
>> >>> It's an OTG controller or host controller?
>> >>>
>> >>
>> >> here only the host controller part used.
>> >>
>> >> faraday fotg2 is a dual role hcd/otg device and here is only the
>> >> host part used.
>> >
>> > Because you don't care about device mode or restricted by the IP
>> > configuration or SoC integration? The former is a user choice and
>> > shouldn't be part of DT. The latter should be implied by an SoC
>> > specific compatible string. Using only a compatible string for a
>> > licensed IP is not specific enough as vendors use differing versions
>> > and integrate them in different ways.
>>
>> Hans can you add:
>>
>> compatible = "cortina,gemini-fotg", "faraday,fotg210-hcd" or something
>> as composite compatible for our controller?
I hacked on it a bit and sent out. Hope you don't hate it too much.
> I prefer
> "faraday,fotg210-usb2"
I simply named it after the IP core name, which is just "faraday,fotg210".
> I've got rejected by Rob due the fact this is an dual role controller,
> which supports both host and device mode. And DT must reflect this desgn
> pattern.
>
> Currently I'm wrappingt my head around the design of the fsl-mph-dr-of.c
> driver to use this as a blueprint for the Faraday driver.
I don't know how much more of the dual-mode we need to reflect,
I guess it comes up in OTG mode since we don't parse the
host-only or device-only attributes (yet).
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 2/4] dt-bindings: add binding for RTL8211E Ethernet PHY
From: Florian Fainelli @ 2017-04-22 0:22 UTC (permalink / raw)
To: Icenowy Zheng, Andrew Lunn, Rob Herring
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170421232436.10924-3-icenowy-h8G6r0blFSE@public.gmane.org>
On 04/21/2017 04:24 PM, Icenowy Zheng wrote:
> From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>
> Some RTL8211E Ethernet PHY have an issue that needs a workaround
> indicated with device tree.
>
> Add the binding for a property that indicates this workaround.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
> .../devicetree/bindings/net/realtek,rtl8211e.txt | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>
> diff --git a/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt b/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
> new file mode 100644
> index 000000000000..c1913301bfe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
> @@ -0,0 +1,22 @@
> +Realtek RTL8211E Ethernet PHY
> +
> +One batch of RTL8211E is slight broken, that needs some special (and
> +full of magic numbers) tweaking in order to make GbE to operate properly.
> +The only well-known board that used the broken batch is Pine64+.
> +Configure it through an Ethernet OF device node.
> +
> +Optional properties:
> +
> +- realtek,disable-rx-delay:
> + If set, RX delay will be completely disabled (according to Realtek). This
> + will affect the performance on non-broken boards.
> + default: do not disable RX delay.
Please don't introduce custom properties to do that, instead correct
specify the "phy-mode" such that it is e.g: "rgmii-txid" which indicates
that there should be no RX internal delay, but a TX internal delay added
by the PHY.
--
Florian
^ permalink raw reply
* Re: [PATCH 3/4] net: phy: realtek: add disable RX delay hack for RTL8211E
From: Florian Fainelli @ 2017-04-22 0:35 UTC (permalink / raw)
To: Icenowy Zheng, Andrew Lunn, Rob Herring
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170421232436.10924-4-icenowy-h8G6r0blFSE@public.gmane.org>
On 04/21/2017 04:24 PM, Icenowy Zheng wrote:
> From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>
> Some RTL8211E chips have broken GbE function, which needs a hack to
> fix. It's said that this fix will affect the performance on not-buggy
> PHYs, so it should only be enabled on boards with the broken PHY.
> Currently only some Pine64+ boards are known to have this issue.
>
> This hack is said to disable RX relay for RTL8211E according to Realtek.
>
> Enable this hack when a certain device tree property is set.
>
> As this hack is not documented on the datasheet at all, it contains
> magic numbers, and could not be revealed. These magic numbers are
> received from Realtek via Pine64.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
> drivers/net/phy/realtek.c | 36 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> index d820d00addf6..880022160cd2 100644
> --- a/drivers/net/phy/realtek.c
> +++ b/drivers/net/phy/realtek.c
> @@ -13,6 +13,7 @@
> * option) any later version.
> *
> */
> +#include <linux/of.h>
> #include <linux/phy.h>
> #include <linux/module.h>
>
> @@ -26,6 +27,8 @@
> #define RTL8211_PAGE_SELECT 0x1f
>
> #define RTL8211E_INER_LINK_STATUS 0x400
> +#define RTL8211E_EXT_PAGE_SELECT 0x1e
> +#define RTL8211E_EXT_PAGE 0x7
>
> #define RTL8211F_INER_LINK_STATUS 0x0010
> #define RTL8211F_INSR 0x1d
> @@ -121,6 +124,38 @@ static int rtl8211f_config_init(struct phy_device *phydev)
> return 0;
> }
>
> +static int rtl8211e_config_init(struct phy_device *phydev)
> +{
> + struct device *dev = &phydev->mdio.dev;
> + struct device_node *of_node = dev->of_node;
> + int ret;
> +
> + ret = genphy_config_init(phydev);
> + if (ret < 0)
> + return ret;
> +
> + if (of_node &&
> + of_property_read_bool(of_node, "realtek,disable-rx-delay")) {
> + /* All these magic numbers are retrieved from Pine64, and
> + * they're said to be originated from Realtek.
> + *
> + * The datasheet of RTL8211E didn't cover this ext page.
> + *
> + * Select extension page 0xa4 here.
> + */
> + phy_write(phydev, RTL8211_PAGE_SELECT, RTL8211E_EXT_PAGE)
> + phy_write(phydev, RTL8211E_EXT_PAGE_SELECT, 0xa4);
> +
> + /* Write the magic number */
> + phy_write(phydev, 0x1c, 0xb591);
> +
> + /* Restore to default page 0 */
> + phy_write(phydev, RTL8211_PAGE_SELECT, 0);
> + }
The code itself is probably fine, but the way you are checking whether
the RX delay should be disabled is not. As mentioned in patch 2, using
the correct "phy-mode" property would translate in the proper
phydev->interface value here (presumably PHY_INTERFACE_MODE_RGMII_TXID)
is that you want here that would allow you to check whether the RX delay
should, or should not be disabled.
Thank you
--
Florian
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: add binding for RTL8211E Ethernet PHY
From: icenowy-h8G6r0blFSE @ 2017-04-22 1:12 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, Rob Herring, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <c7aa9d7a-5e97-0e7f-2b1c-584a4de00837-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
在 2017-04-22 08:22，Florian Fainelli 写道：
> On 04/21/2017 04:24 PM, Icenowy Zheng wrote:
>> From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>
>> Some RTL8211E Ethernet PHY have an issue that needs a workaround
>> indicated with device tree.
>>
>> Add the binding for a property that indicates this workaround.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>> ---
>> .../devicetree/bindings/net/realtek,rtl8211e.txt | 22
>> ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>> b/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>> new file mode 100644
>> index 000000000000..c1913301bfe8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>> @@ -0,0 +1,22 @@
>> +Realtek RTL8211E Ethernet PHY
>> +
>> +One batch of RTL8211E is slight broken, that needs some special (and
>> +full of magic numbers) tweaking in order to make GbE to operate
>> properly.
>> +The only well-known board that used the broken batch is Pine64+.
>> +Configure it through an Ethernet OF device node.
>> +
>> +Optional properties:
>> +
>> +- realtek,disable-rx-delay:
>> + If set, RX delay will be completely disabled (according to
>> Realtek). This
>> + will affect the performance on non-broken boards.
>> + default: do not disable RX delay.
>
> Please don't introduce custom properties to do that, instead correct
> specify the "phy-mode" such that it is e.g: "rgmii-txid" which
> indicates
> that there should be no RX internal delay, but a TX internal delay
> added
> by the PHY.
According to Realtek and Pine64 people, set that register is equal to
hardwire RDDLY line to low.
Is it the standard definition of RGMII-TXID?
(P.S. as it's only provided as a workaround, there's no implementation
known for RGMII-RXID and RGMII-ID)
Thanks,
Icenowy
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH v2 0/5] mtd: nand: gpmi: add i.MX 7 support
From: Stefan Agner @ 2017-04-22 1:23 UTC (permalink / raw)
To: dwmw2, computersforpeace, boris.brezillon, marek.vasut, richard,
cyrille.pitchen
Cc: robh+dt, mark.rutland, shawnguo, kernel, han.xu, fabio.estevam,
LW, linux-mtd, devicetree, linux-arm-kernel, linux-kernel,
Stefan Agner
This patchset adds support for i.MX 7 SoC for the GPMI NAND controller.
There have been similar patchsets already:
https://lkml.org/lkml/2016/2/23/912
However, this patchset does not make use of any of the new features.
The current feature set seems to work fine, I successfully run the MTD
tests on a Colibri iMX7.
--
Stefan
Changes since v1:
- Make clks_count const
- Introduce IS_IMX7D for i.MX 7 SoC's and make it part of GPMI_IS_MX6
Stefan Agner (5):
mtd: nand: gpmi: unify clock handling
mtd: nand: gpmi: add i.MX 7 SoC support
mtd: gpmi: document current clock requirements
ARM: dts: imx7: add GPMI NAND
ARM: dts: imx7-colibri: add NAND support
.../devicetree/bindings/mtd/gpmi-nand.txt | 14 +++++-
arch/arm/boot/dts/imx7-colibri.dtsi | 9 ++++
arch/arm/boot/dts/imx7s.dtsi | 31 ++++++++++++
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 56 +++++++++++++---------
drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 9 +++-
5 files changed, 93 insertions(+), 26 deletions(-)
--
2.12.2
^ permalink raw reply
* [PATCH v2 1/5] mtd: nand: gpmi: unify clock handling
From: Stefan Agner @ 2017-04-22 1:23 UTC (permalink / raw)
To: dwmw2, computersforpeace, boris.brezillon, marek.vasut, richard,
cyrille.pitchen
Cc: mark.rutland, fabio.estevam, devicetree, linux-kernel,
Stefan Agner, robh+dt, linux-mtd, kernel, han.xu, shawnguo,
linux-arm-kernel, LW
In-Reply-To: <20170422012338.4635-1-stefan@agner.ch>
Add device specific list of clocks required, and handle all clocks
in a single for loop. This avoids further code duplication when
adding i.MX 7 support.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 41 +++++++++++++++-------------------
drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 2 ++
2 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index d52139635b67..c8bbf5da2ab8 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -82,6 +82,10 @@ static int gpmi_ooblayout_free(struct mtd_info *mtd, int section,
return 0;
}
+static const char * const gpmi_clks_for_mx2x[] = {
+ "gpmi_io",
+};
+
static const struct mtd_ooblayout_ops gpmi_ooblayout_ops = {
.ecc = gpmi_ooblayout_ecc,
.free = gpmi_ooblayout_free,
@@ -91,24 +95,36 @@ static const struct gpmi_devdata gpmi_devdata_imx23 = {
.type = IS_MX23,
.bch_max_ecc_strength = 20,
.max_chain_delay = 16,
+ .clks = gpmi_clks_for_mx2x,
+ .clks_count = ARRAY_SIZE(gpmi_clks_for_mx2x),
};
static const struct gpmi_devdata gpmi_devdata_imx28 = {
.type = IS_MX28,
.bch_max_ecc_strength = 20,
.max_chain_delay = 16,
+ .clks = gpmi_clks_for_mx2x,
+ .clks_count = ARRAY_SIZE(gpmi_clks_for_mx2x),
+};
+
+static const char * const gpmi_clks_for_mx6[] = {
+ "gpmi_io", "gpmi_apb", "gpmi_bch", "gpmi_bch_apb", "per1_bch",
};
static const struct gpmi_devdata gpmi_devdata_imx6q = {
.type = IS_MX6Q,
.bch_max_ecc_strength = 40,
.max_chain_delay = 12,
+ .clks = gpmi_clks_for_mx6,
+ .clks_count = ARRAY_SIZE(gpmi_clks_for_mx6),
};
static const struct gpmi_devdata gpmi_devdata_imx6sx = {
.type = IS_MX6SX,
.bch_max_ecc_strength = 62,
.max_chain_delay = 12,
+ .clks = gpmi_clks_for_mx6,
+ .clks_count = ARRAY_SIZE(gpmi_clks_for_mx6),
};
static irqreturn_t bch_irq(int irq, void *cookie)
@@ -599,35 +615,14 @@ static int acquire_dma_channels(struct gpmi_nand_data *this)
return -EINVAL;
}
-static char *extra_clks_for_mx6q[GPMI_CLK_MAX] = {
- "gpmi_apb", "gpmi_bch", "gpmi_bch_apb", "per1_bch",
-};
-
static int gpmi_get_clks(struct gpmi_nand_data *this)
{
struct resources *r = &this->resources;
- char **extra_clks = NULL;
struct clk *clk;
int err, i;
- /* The main clock is stored in the first. */
- r->clock[0] = devm_clk_get(this->dev, "gpmi_io");
- if (IS_ERR(r->clock[0])) {
- err = PTR_ERR(r->clock[0]);
- goto err_clock;
- }
-
- /* Get extra clocks */
- if (GPMI_IS_MX6(this))
- extra_clks = extra_clks_for_mx6q;
- if (!extra_clks)
- return 0;
-
- for (i = 1; i < GPMI_CLK_MAX; i++) {
- if (extra_clks[i - 1] == NULL)
- break;
-
- clk = devm_clk_get(this->dev, extra_clks[i - 1]);
+ for (i = 0; i < this->devdata->clks_count; i++) {
+ clk = devm_clk_get(this->dev, this->devdata->clks[i]);
if (IS_ERR(clk)) {
err = PTR_ERR(clk);
goto err_clock;
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
index 4e49a1f5fa27..8879c4eff25e 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
@@ -130,6 +130,8 @@ struct gpmi_devdata {
enum gpmi_type type;
int bch_max_ecc_strength;
int max_chain_delay; /* See the async EDO mode */
+ const char * const *clks;
+ const int clks_count;
};
struct gpmi_nand_data {
--
2.12.2
^ permalink raw reply related
* [PATCH v2 2/5] mtd: nand: gpmi: add i.MX 7 SoC support
From: Stefan Agner @ 2017-04-22 1:23 UTC (permalink / raw)
To: dwmw2, computersforpeace, boris.brezillon, marek.vasut, richard,
cyrille.pitchen
Cc: robh+dt, mark.rutland, shawnguo, kernel, han.xu, fabio.estevam,
LW, linux-mtd, devicetree, linux-arm-kernel, linux-kernel,
Stefan Agner
In-Reply-To: <20170422012338.4635-1-stefan@agner.ch>
Add support for i.MX 7 SoC. The i.MX 7 has a slightly different
clock architecture requiring only two clocks to be referenced.
The IP is slightly different compared to i.MX 6, but currently none
of this differences are in use, therefore reuse GPMI_IS_MX6.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 15 +++++++++++++++
drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 7 +++++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index c8bbf5da2ab8..9b777be633a9 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -127,6 +127,18 @@ static const struct gpmi_devdata gpmi_devdata_imx6sx = {
.clks_count = ARRAY_SIZE(gpmi_clks_for_mx6),
};
+static const char * const gpmi_clks_for_mx7d[] = {
+ "gpmi_io", "gpmi_bch_apb",
+};
+
+static const struct gpmi_devdata gpmi_devdata_imx7d = {
+ .type = IS_MX7D,
+ .bch_max_ecc_strength = 62,
+ .max_chain_delay = 12,
+ .clks = gpmi_clks_for_mx7d,
+ .clks_count = ARRAY_SIZE(gpmi_clks_for_mx7d),
+};
+
static irqreturn_t bch_irq(int irq, void *cookie)
{
struct gpmi_nand_data *this = cookie;
@@ -2071,6 +2083,9 @@ static const struct of_device_id gpmi_nand_id_table[] = {
}, {
.compatible = "fsl,imx6sx-gpmi-nand",
.data = &gpmi_devdata_imx6sx,
+ }, {
+ .compatible = "fsl,imx7d-gpmi-nand",
+ .data = &gpmi_devdata_imx7d,
}, {}
};
MODULE_DEVICE_TABLE(of, gpmi_nand_id_table);
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
index 8879c4eff25e..e88a45a62ab6 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
@@ -123,7 +123,8 @@ enum gpmi_type {
IS_MX23,
IS_MX28,
IS_MX6Q,
- IS_MX6SX
+ IS_MX6SX,
+ IS_MX7D,
};
struct gpmi_devdata {
@@ -307,6 +308,8 @@ void gpmi_copy_bits(u8 *dst, size_t dst_bit_off,
#define GPMI_IS_MX28(x) ((x)->devdata->type == IS_MX28)
#define GPMI_IS_MX6Q(x) ((x)->devdata->type == IS_MX6Q)
#define GPMI_IS_MX6SX(x) ((x)->devdata->type == IS_MX6SX)
+#define GPMI_IS_MX7D(x) ((x)->devdata->type == IS_MX7D)
-#define GPMI_IS_MX6(x) (GPMI_IS_MX6Q(x) || GPMI_IS_MX6SX(x))
+#define GPMI_IS_MX6(x) (GPMI_IS_MX6Q(x) || GPMI_IS_MX6SX(x) || \
+ GPMI_IS_MX7D(x))
#endif
--
2.12.2
^ permalink raw reply related
* [PATCH v2 3/5] mtd: gpmi: document current clock requirements
From: Stefan Agner @ 2017-04-22 1:23 UTC (permalink / raw)
To: dwmw2, computersforpeace, boris.brezillon, marek.vasut, richard,
cyrille.pitchen
Cc: robh+dt, mark.rutland, shawnguo, kernel, han.xu, fabio.estevam,
LW, linux-mtd, devicetree, linux-arm-kernel, linux-kernel,
Stefan Agner
In-Reply-To: <20170422012338.4635-1-stefan@agner.ch>
The clock requirements are completely missing, add the clocks
currently required by the driver.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
Documentation/devicetree/bindings/mtd/gpmi-nand.txt | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
index d02acaff3c35..b289ef3c1b7e 100644
--- a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
@@ -4,7 +4,12 @@ The GPMI nand controller provides an interface to control the
NAND flash chips.
Required properties:
- - compatible : should be "fsl,<chip>-gpmi-nand"
+ - compatible : should be "fsl,<chip>-gpmi-nand", chip can be:
+ * imx23
+ * imx28
+ * imx6q
+ * imx6sx
+ * imx7d
- reg : should contain registers location and length for gpmi and bch.
- reg-names: Should contain the reg names "gpmi-nand" and "bch"
- interrupts : BCH interrupt number.
@@ -13,6 +18,13 @@ Required properties:
and GPMI DMA channel ID.
Refer to dma.txt and fsl-mxs-dma.txt for details.
- dma-names: Must be "rx-tx".
+ - clocks : clocks phandle and clock specifier corresponding to each clock
+ specified in clock-names.
+ - clock-names : The "gpmi_io" clock is always required. Which clocks are
+ exactly required depends on chip:
+ * imx23/imx28 : "gpmi_io"
+ * imx6q/sx : "gpmi_io", "gpmi_apb", "gpmi_bch", "gpmi_bch_apb", "per1_bch"
+ * imx7d : "gpmi_io", "gpmi_bch_apb"
Optional properties:
- nand-on-flash-bbt: boolean to enable on flash bbt option if not
--
2.12.2
^ permalink raw reply related
* [PATCH v2 4/5] ARM: dts: imx7: add GPMI NAND
From: Stefan Agner @ 2017-04-22 1:23 UTC (permalink / raw)
To: dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w, richard-/L3Ra7n9ekc,
cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
han.xu-3arQi8VN3Tc, fabio.estevam-KZfg59tc24xl57MIdRCFDg,
LW-bxm8fMRDkQLDiMYJYoSAnRvVK+yQ3ZXh,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stefan Agner
In-Reply-To: <20170422012338.4635-1-stefan-XLVq0VzYD2Y@public.gmane.org>
Add i.MX 7 GPMI NAND module.
Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
---
arch/arm/boot/dts/imx7s.dtsi | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 843eb379e1ea..9645257638d4 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -995,5 +995,36 @@
status = "disabled";
};
};
+
+ dma_apbh: dma-apbh@33000000 {
+ compatible = "fsl,imx7d-dma-apbh", "fsl,imx28-dma-apbh";
+ reg = <0x33000000 0x2000>;
+ interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "gpmi0", "gpmi1", "gpmi2", "gpmi3";
+ #dma-cells = <1>;
+ dma-channels = <4>;
+ clocks = <&clks IMX7D_NAND_USDHC_BUS_ROOT_CLK>,
+ <&clks IMX7D_NAND_ROOT_CLK>;
+ clock-names = "dma_apbh_bch", "dma_apbh_io";
+ };
+
+ gpmi: gpmi-nand@33002000{
+ compatible = "fsl,imx7d-gpmi-nand";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x33002000 0x2000>, <0x33004000 0x4000>;
+ reg-names = "gpmi-nand", "bch";
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "bch";
+ clocks = <&clks IMX7D_NAND_ROOT_CLK>,
+ <&clks IMX7D_NAND_USDHC_BUS_ROOT_CLK>;
+ clock-names = "gpmi_io", "gpmi_bch_apb";
+ dmas = <&dma_apbh 0>;
+ dma-names = "rx-tx";
+ status = "disabled";
+ };
};
};
--
2.12.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 5/5] ARM: dts: imx7-colibri: add NAND support
From: Stefan Agner @ 2017-04-22 1:23 UTC (permalink / raw)
To: dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w, richard-/L3Ra7n9ekc,
cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
han.xu-3arQi8VN3Tc, fabio.estevam-KZfg59tc24xl57MIdRCFDg,
LW-bxm8fMRDkQLDiMYJYoSAnRvVK+yQ3ZXh,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stefan Agner
In-Reply-To: <20170422012338.4635-1-stefan-XLVq0VzYD2Y@public.gmane.org>
The Colibri iMX7 modules come with 512MB on-module SLC NAND flash
populated. Make use of it by enabling the GPMI controller.
Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index 2d87489f9105..ad4ce19d455b 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -106,6 +106,15 @@
fsl,magic-packet;
};
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand>;
+ fsl,use-minimum-ecc;
+ nand-on-flash-bbt;
+ nand-ecc-mode = "hw";
+ status = "okay";
+};
+
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default";
--
2.12.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 V3 2/2] ARM64: dts: hi6220-hikey: Add clock binding for the pmic mfd
From: Stephen Boyd @ 2017-04-22 2:02 UTC (permalink / raw)
To: Daniel Lezcano
Cc: mturquette, lee.jones, xuwei5, linux-kernel, linux-clk,
devicetree, linux-arm-kernel
In-Reply-To: <1492449567-31399-2-git-send-email-daniel.lezcano@linaro.org>
On 04/17, Daniel Lezcano wrote:
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt | 6 ++++++
> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
> 2 files changed, 7 insertions(+)
>
I take it this goes through arm-soc? Not sure why I'm on To:
line.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V2] clk: hi6220: Add the hi655x's pmic clock
From: Stephen Boyd @ 2017-04-22 2:14 UTC (permalink / raw)
To: Daniel Lezcano
Cc: mturquette, lee.jones, xuwei5, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
In-Reply-To: <20170419194737.GB2523@mai>
On 04/19, Daniel Lezcano wrote:
> On Wed, Apr 19, 2017 at 09:00:05AM -0700, Stephen Boyd wrote:
> > On 04/16, Daniel Lezcano wrote:
> > > On Wed, Apr 12, 2017 at 08:02:45AM -0700, Stephen Boyd wrote:
> > > > On 04/08, Daniel Lezcano wrote:
>
> [ ... ]
>
> > > > > + ret = clk_hw_register_clkdev(&hi655x_clk->clk_hw, clk_name, NULL);
> > > >
> > > > Missed this last time. Do you use this clkdev lookup? The name is
> > > > usually supposed to be based on what the device is expecting,
> > > > instead of clk_name, and we would want some device name for the
> > > > third argument here.
> > >
> > > I'm not sure to get your comment. Are you saying the clk_name should be the
> > > third argument?
> > >
> > >
> >
> > Sorry, no. I meant that con_id is typically something like "core"
> > or "ahb" or something like that, and dev_id is something like
> > "a456002.pmic_device" or whatever dev_name(pmic_dev) would return for
> > the consuming device. That way when we call clk_get(dev, "core")
> > it will find the lookup with "core" and "a456002.pmic_device" to
> > match up the clk lookup.
> >
> > If anything, the clk_name should just go into the con_id for now,
> > and then it will need to be a globally unique identifier for the
> > clk. But that is going against how clkdev is supposed to be used.
> > Hence the question if you even need to use it. If not, just don't
> > add it. I can fix up v3 of this patch to put clk_name back at
> > con_id if you like. No need to resend.
>
> Ok, I'm not very used with the CCF, so perhaps clk_name is not needed at all. I
> gave a try with the following combination:
>
> - con_id = NULL, dev_id = clk_name
> - con_id = clk_name, dev_id = NULL
> - con_id = NULL, dev_id = NULL
>
> All worked.
>
> And finally I removed the clk_hw_register_clkdev() call and it worked also.
>
> So I'm not sure about this function.
>
If you've removed it and it still works, then it means you're
using DT and you don't need clkdev at all. That's the of_clk
provider thing that you're using. So I'll go remove this clkdev
lookup because it's not used. If someone needs it they can add it
later.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH RFC 1/7] clk: samsung: Add enable/disable operation for PLL36XX clocks
From: Stephen Boyd @ 2017-04-22 2:51 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: linux-samsung-soc, linux-clk, dri-devel, alsa-devel, devicetree,
inki.dae, sw0312.kim, cw00.choi, javier, krzk, jy0922.shim,
broonie, robh+dt, b.zolnierkie
In-Reply-To: <1492795191-31298-2-git-send-email-s.nawrocki@samsung.com>
On 04/21, Sylwester Nawrocki wrote:
> The existing enable/disable ops for PLL35XX are made more generic
> and used also for PLL36XX. This fixes issues in the kernel with
> PLL36XX PLLs when the PLL has not been already enabled by bootloader.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> drivers/clk/samsung/clk-pll.c | 85 +++++++++++++++++++++++++------------------
> 1 file changed, 49 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
> index 5229089..10c76eb 100644
> --- a/drivers/clk/samsung/clk-pll.c
> +++ b/drivers/clk/samsung/clk-pll.c
> @@ -23,6 +23,10 @@ struct samsung_clk_pll {
> struct clk_hw hw;
> void __iomem *lock_reg;
> void __iomem *con_reg;
> + /* PLL enable control bit offset in @con_reg register */
> + unsigned short enable_offs;
> + /* PLL lock status bit offset in @con_reg register */
> + unsigned short lock_offs;
> enum samsung_pll_type type;
> unsigned int rate_count;
> const struct samsung_pll_rate_table *rate_table;
> @@ -61,6 +65,34 @@ static long samsung_pll_round_rate(struct clk_hw *hw,
> return rate_table[i - 1].rate;
> }
>
> +static int samsung_pll3xxx_enable(struct clk_hw *hw)
> +{
> + struct samsung_clk_pll *pll = to_clk_pll(hw);
> + u32 tmp;
> +
> + tmp = readl_relaxed(pll->con_reg);
> + tmp |= BIT(pll->enable_offs);
> + writel_relaxed(tmp, pll->con_reg);
> +
> + /* wait lock time */
> + do {
> + cpu_relax();
> + tmp = readl_relaxed(pll->con_reg);
> + } while (!(tmp & BIT(pll->lock_offs)));
Not a problem with this patch because we're moving code around,
but this is a potential infinite loop that should have some sort
of timeout so we don't sit here forever trying to see a bit
toggle.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 3/4] net: phy: realtek: add disable RX delay hack for RTL8211E
From: kbuild test robot @ 2017-04-22 7:12 UTC (permalink / raw)
To: Icenowy Zheng
Cc: kbuild-all-JC7UmRfGjtg, Andrew Lunn, Florian Fainelli,
Rob Herring, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170421232436.10924-4-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]
Hi Icenowy,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.11-rc7 next-20170421]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Icenowy-Zheng/net-phy-realtek-change-macro-name-for-page-select-register/20170422-144641
config: i386-randconfig-x070-201716 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/net/phy/realtek.c: In function 'rtl8211e_config_init':
>> drivers/net/phy/realtek.c:147:3: error: expected ';' before 'phy_write'
phy_write(phydev, RTL8211E_EXT_PAGE_SELECT, 0xa4);
^~~~~~~~~
vim +147 drivers/net/phy/realtek.c
141 *
142 * The datasheet of RTL8211E didn't cover this ext page.
143 *
144 * Select extension page 0xa4 here.
145 */
146 phy_write(phydev, RTL8211_PAGE_SELECT, RTL8211E_EXT_PAGE)
> 147 phy_write(phydev, RTL8211E_EXT_PAGE_SELECT, 0xa4);
148
149 /* Write the magic number */
150 phy_write(phydev, 0x1c, 0xb591);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24280 bytes --]
^ permalink raw reply
* [RFC PATH] of/pci/dma: fix DMA configruation for PCI masters
From: Oza Pawandeep via iommu @ 2017-04-22 8:08 UTC (permalink / raw)
To: Joerg Roedel, Robin Murphy
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Oza Pawandeep,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
current device frmework and of framework integration assumes dma-ranges
in a way where memory-mapped devices define their dma-ranges.
dma-ranges: (child-bus-address, parent-bus-address, length).
but iproc based SOCs and other SOCs(suc as rcar) have PCI world dma-ranges.
dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;
of_dma_configure is specifically witten to take care of memory mapped devices.
but no implementation exists for pci to take care of pcie based memory ranges.
in fact pci world doesnt seem to define standard dma-ranges
this patch served following purposes
1) exposes intrface to the pci host driver for thir inbound memory ranges
2) provide an interface to callers such as of_dma_get_ranges.
so then the returned size get best possible (largest) dma_mask.
for e.g.
dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;
we should get dev->coherent_dma_mask=0x7fffffffff.
3) this patch handles multiple inbound windows and dma-ranges.
it is left to the caller, how it wants to use them.
the new function returns the resources in a standard and unform way
4) this way the callers of of_dma_get_ranges does not need to change.
and
5) leaves scope of adding PCI flag handling for inbound memory
by the new function.
Signed-off-by: Oza Pawandeep <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903..ec21191 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -6,6 +6,7 @@
#include <linux/ioport.h>
#include <linux/module.h>
#include <linux/of_address.h>
+#include <linux/of_pci.h>
#include <linux/pci.h>
#include <linux/pci_regs.h>
#include <linux/sizes.h>
@@ -829,10 +830,30 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
int len, naddr, nsize, pna;
int ret = 0;
u64 dmaaddr;
+ struct resource_entry *window;
+ LIST_HEAD(res);
if (!node)
return -EINVAL;
+ if (strcmp(np->name, "pci")) {
+ *size = 0;
+ ret = of_pci_get_dma_ranges(np, &res);
+ if (!ret) {
+ resource_list_for_each_entry(window, &res) {
+ struct resource *res_dma = window->res;
+
+ if (*size < resource_size(res_dma)) {
+ *dma_addr = res_dma->start - window->offset;
+ *paddr = res_dma->start;
+ *size = resource_size(res_dma);
+ }
+ }
+ }
+ pci_free_resource_list(&res);
+ goto out;
+ }
+
while (1) {
naddr = of_n_addr_cells(node);
nsize = of_n_size_cells(node);
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 0ee42c3..2aa9401 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -283,6 +283,83 @@ int of_pci_get_host_bridge_resources(struct device_node *dev,
return err;
}
EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+
+/**
+ * of_pci_get_dma_ranges - Parse PCI host bridge inbound resources from DT
+ * @np: device node of the host bridge having the dma-ranges property
+ * @resources: list where the range of resources will be added after DT parsing
+ *
+ * It is the caller's job to free the @resources list.
+ *
+ * This function will parse the "dma-ranges" property of a
+ * PCI host bridge device node and setup the resource mapping based
+ * on its content.
+ *
+ * It returns zero if the range parsing has been successful or a standard error
+ * value if it failed.
+ */
+
+int of_pci_get_dma_ranges(struct device_node *np, struct list_head *resources)
+{
+ struct device_node *node = of_node_get(np);
+ int rlen;
+ int ret = 0;
+ const int na = 3, ns = 2;
+ struct resource *res;
+ struct of_pci_range_parser parser;
+ struct of_pci_range range;
+
+ if (!node)
+ return -EINVAL;
+
+ parser.node = node;
+ parser.pna = of_n_addr_cells(node);
+ parser.np = parser.pna + na + ns;
+
+ parser.range = of_get_property(node, "dma-ranges", &rlen);
+
+ if (!parser.range) {
+ pr_debug("pcie device has no dma-ranges defined for node(%s)\n",
+ np->full_name);
+ ret = -ENODEV;
+ goto out;
+ }
+
+ parser.end = parser.range + rlen / sizeof(__be32);
+
+ for_each_of_pci_range(&parser, &range) {
+ /*
+ * If we failed translation or got a zero-sized region
+ * then skip this range
+ */
+ if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
+ continue;
+
+ res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+ if (!res) {
+ ret = -ENOMEM;
+ goto parse_failed;
+ }
+
+ ret = of_pci_range_to_resource(&range, np, res);
+ if (ret) {
+ kfree(res);
+ continue;
+ }
+
+ pci_add_resource_offset(resources, res,
+ res->start - range.pci_addr);
+ }
+
+ return ret;
+
+parse_failed:
+ pci_free_resource_list(resources);
+out:
+ of_node_put(node);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_dma_ranges);
#endif /* CONFIG_OF_ADDRESS */
#ifdef CONFIG_PCI_MSI
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 0e0974e..617b90d 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -76,6 +76,7 @@ static inline void of_pci_check_probe_only(void) { }
int of_pci_get_host_bridge_resources(struct device_node *dev,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
+int of_pci_get_dma_ranges(struct device_node *np, struct list_head *resources);
#else
static inline int of_pci_get_host_bridge_resources(struct device_node *dev,
unsigned char busno, unsigned char bus_max,
@@ -83,6 +84,12 @@ static inline int of_pci_get_host_bridge_resources(struct device_node *dev,
{
return -EINVAL;
}
+
+static inline int of_pci_get_dma_ranges(struct device_node *np,
+ struct list_head *resources)
+{
+ return -EINVAL;
+}
#endif
#if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
--
1.9.1
^ permalink raw reply related
* Re: [RFC PATCH] of: Fix DMA configuration for non-DT masters
From: Oza Oza via iommu @ 2017-04-22 8:53 UTC (permalink / raw)
To: Robin Murphy
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Linux IOMMU,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <67d1f46172599be243405f4341665fd0ef9ab969.1490726288.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
On Wed, Mar 29, 2017 at 12:27 AM, Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> wrote:
> For PCI masters not represented in DT, we pass the OF node of their
> associated host bridge to of_dma_configure(), such that they can inherit
> the appropriate DMA configuration from whatever is described there.
> Unfortunately, whilst this has worked for the "dma-coherent" property,
> it turns out to miss the case where the host bridge node has a non-empty
> "dma-ranges", since nobody is expecting the 'device' to be a bus itself.
>
> It transpires, though, that the de-facto interface since the prototype
> change in 1f5c69aa51f9 ("of: Move of_dma_configure() to device.c to help
> re-use") is very clear-cut: either the master_np argument is redundant
> with dev->of_node, or dev->of_node is NULL and master_np is the relevant
> parent bus. Let's ratify that behaviour, then teach the whole
> of_dma_configure() pipeline to cope with both cases properly.
>
> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> ---
>
> This is what I'd consider the better fix - rather than adding yet more
> special cases - which will also make it simple to handle multiple
> "dma-ranges" entries with minimal further disruption. The callers now
> left passing dev->of_node as 'parent' are harmless, but look a bit silly
> and clearly want cleaning up - I'd be partial to renaming the existing
> function and having a single-argument wrapper for the 'normal' case, e.g.:
>
> static inline int of_dma_configure(struct device_node *dev)
> {
> return of_dma_configure_parent(dev, NULL);
> }
>
> Thoughts?
>
> Robin.
>
> drivers/iommu/of_iommu.c | 7 ++++---
> drivers/of/address.c | 37 +++++++++++++++++++++++++------------
> drivers/of/device.c | 12 +++++++-----
> include/linux/of_address.h | 7 ++++---
> include/linux/of_device.h | 4 ++--
> include/linux/of_iommu.h | 4 ++--
> 6 files changed, 44 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 2683e9fc0dcf..35aff07bb5eb 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -138,21 +138,22 @@ static const struct iommu_ops
> }
>
> const struct iommu_ops *of_iommu_configure(struct device *dev,
> - struct device_node *master_np)
> + struct device_node *parent)
> {
> struct of_phandle_args iommu_spec;
> - struct device_node *np;
> + struct device_node *np, *master_np;
> const struct iommu_ops *ops = NULL;
> int idx = 0;
>
> if (dev_is_pci(dev))
> - return of_pci_iommu_configure(to_pci_dev(dev), master_np);
> + return of_pci_iommu_configure(to_pci_dev(dev), parent);
>
> /*
> * We don't currently walk up the tree looking for a parent IOMMU.
> * See the `Notes:' section of
> * Documentation/devicetree/bindings/iommu/iommu.txt
> */
> + master_np = dev->of_node ? dev->of_node : parent;
> while (!of_parse_phandle_with_args(master_np, "iommus",
> "#iommu-cells", idx,
> &iommu_spec)) {
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903fe9d2..833bc17f5e55 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -808,6 +808,7 @@ EXPORT_SYMBOL(of_io_request_and_map);
> /**
> * of_dma_get_range - Get DMA range info
> * @np: device node to get DMA range info
> + * @parent: node of device's parent bus, if @np is NULL
> * @dma_addr: pointer to store initial DMA address of DMA range
> * @paddr: pointer to store initial CPU address of DMA range
> * @size: pointer to store size of DMA range
> @@ -822,36 +823,48 @@ EXPORT_SYMBOL(of_io_request_and_map);
> * It returns -ENODEV if "dma-ranges" property was not found
> * for this device in DT.
> */
> -int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
> +int of_dma_get_range(struct device_node *np, struct device_node *parent,
> + u64 *dma_addr, u64 *paddr, u64 *size)
> {
> - struct device_node *node = of_node_get(np);
> + struct device_node *node;
> const __be32 *ranges = NULL;
> int len, naddr, nsize, pna;
> int ret = 0;
> u64 dmaaddr;
>
> - if (!node)
> - return -EINVAL;
> -
> - while (1) {
> + if (np) {
> + node = of_node_get(np);
> naddr = of_n_addr_cells(node);
> nsize = of_n_size_cells(node);
> node = of_get_next_parent(node);
> - if (!node)
> - break;
> + } else if (parent) {
> + node = of_node_get(parent);
> + np = parent;
> + if (of_property_read_u32(node, "#address-cells", &naddr))
> + naddr = of_n_addr_cells(node);
> + if (of_property_read_u32(node, "#size-cells", &nsize))
> + nsize = of_n_size_cells(node);
> + } else {
> + return -EINVAL;
> + }
>
> + while (node) {
> ranges = of_get_property(node, "dma-ranges", &len);
>
> - /* Ignore empty ranges, they imply no translation required */
> - if (ranges && len > 0)
> - break;
> -
> /*
> * At least empty ranges has to be defined for parent node if
> * DMA is supported
> */
> if (!ranges)
> break;
> +
> + /* Ignore empty ranges, they imply no translation required */
> + if (len > 0)
> + break;
> +
> + naddr = of_n_addr_cells(node);
> + nsize = of_n_size_cells(node);
> + node = of_get_next_parent(node);
> }
>
> if (!ranges) {
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index 9bb8518b28f2..57ec5324ed6c 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -73,7 +73,8 @@ int of_device_add(struct platform_device *ofdev)
> /**
> * of_dma_configure - Setup DMA configuration
> * @dev: Device to apply DMA configuration
> - * @np: Pointer to OF node having DMA configuration
> + * @parent: OF node of device's parent bus, if @dev is not
> + * represented in DT (i.e. @dev->of_node is NULL)
> *
> * Try to get devices's DMA configuration from DT and update it
> * accordingly.
> @@ -82,13 +83,14 @@ int of_device_add(struct platform_device *ofdev)
> * can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
> * to fix up DMA configuration.
> */
> -void of_dma_configure(struct device *dev, struct device_node *np)
> +void of_dma_configure(struct device *dev, struct device_node *parent)
> {
> u64 dma_addr, paddr, size;
> int ret;
> bool coherent;
> unsigned long offset;
> const struct iommu_ops *iommu;
> + struct device_node *np = dev->of_node;
>
> /*
> * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> @@ -104,7 +106,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
> if (!dev->dma_mask)
> dev->dma_mask = &dev->coherent_dma_mask;
>
> - ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
> + ret = of_dma_get_range(np, parent, &dma_addr, &paddr, &size);
> if (ret < 0) {
> dma_addr = offset = 0;
> size = dev->coherent_dma_mask + 1;
> @@ -132,11 +134,11 @@ void of_dma_configure(struct device *dev, struct device_node *np)
> dev->coherent_dma_mask = DMA_BIT_MASK(ilog2(dma_addr + size));
> *dev->dma_mask = dev->coherent_dma_mask;
>
> - coherent = of_dma_is_coherent(np);
> + coherent = of_dma_is_coherent(np ? np : parent);
> dev_dbg(dev, "device is%sdma coherent\n",
> coherent ? " " : " not ");
>
> - iommu = of_iommu_configure(dev, np);
> + iommu = of_iommu_configure(dev, parent);
> dev_dbg(dev, "device is%sbehind an iommu\n",
> iommu ? " " : " not ");
>
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 37864734ca50..f1a507f3ae57 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -52,8 +52,8 @@ extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
> extern struct of_pci_range *of_pci_range_parser_one(
> struct of_pci_range_parser *parser,
> struct of_pci_range *range);
> -extern int of_dma_get_range(struct device_node *np, u64 *dma_addr,
> - u64 *paddr, u64 *size);
> +extern int of_dma_get_range(struct device_node *np, struct device_node *parent,
> + u64 *dma_addr, u64 *paddr, u64 *size);
> extern bool of_dma_is_coherent(struct device_node *np);
> #else /* CONFIG_OF_ADDRESS */
> static inline void __iomem *of_io_request_and_map(struct device_node *device,
> @@ -95,7 +95,8 @@ static inline struct of_pci_range *of_pci_range_parser_one(
> return NULL;
> }
>
> -static inline int of_dma_get_range(struct device_node *np, u64 *dma_addr,
> +static inline int of_dma_get_range(struct device_node *np,
> + struct device_node *parent, u64 *dma_addr,
> u64 *paddr, u64 *size)
> {
> return -ENODEV;
> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
> index c12dace043f3..bcd2b6fbeef3 100644
> --- a/include/linux/of_device.h
> +++ b/include/linux/of_device.h
> @@ -55,7 +55,7 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
> return of_node_get(cpu_dev->of_node);
> }
>
> -void of_dma_configure(struct device *dev, struct device_node *np);
> +void of_dma_configure(struct device *dev, struct device_node *parent);
> #else /* CONFIG_OF */
>
> static inline int of_driver_match_device(struct device *dev,
> @@ -103,7 +103,7 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
> {
> return NULL;
> }
> -static inline void of_dma_configure(struct device *dev, struct device_node *np)
> +static inline void of_dma_configure(struct device *dev, struct device_node *parent)
> {}
> #endif /* CONFIG_OF */
>
> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> index 13394ac83c66..c02b62e8e6ed 100644
> --- a/include/linux/of_iommu.h
> +++ b/include/linux/of_iommu.h
> @@ -12,7 +12,7 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix,
> size_t *size);
>
> extern const struct iommu_ops *of_iommu_configure(struct device *dev,
> - struct device_node *master_np);
> + struct device_node *parent);
>
> #else
>
> @@ -24,7 +24,7 @@ static inline int of_get_dma_window(struct device_node *dn, const char *prefix,
> }
>
> static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
> - struct device_node *master_np)
> + struct device_node *parent)
> {
> return NULL;
> }
> --
> 2.11.0.dirty
>
Hi Robin,
After some more thoughts to this, I have improved upon old patch design.
please check https://lkml.org/lkml/2017/4/22/34
this patch served following purposes
1) exposes intrface to the pci host driver for thir inbound memory ranges
2) provide an interface to callers such as of_dma_get_ranges.
so then the returned size get best possible (largest) dma_mask.
for e.g.
dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;
we should get dev->coherent_dma_mask=0x7fffffffff.
3) this patch handles multiple inbound windows and dma-ranges.
it is left to the caller, how it wants to use them.
the new function returns the resources in a standard and unform way
4) this way the callers of of_dma_get_ranges does not need to change.
and
5) leaves scope of adding PCI flag handling for inbound memory
by the new function.
which I feel much better approach/way than accommodating
of_dma_get_ranges to handle multiple dma-ranges, addressing PCI
masters.
also in your patch I think, you have to make emulated parent node
which is more work I suppose.
again I have tested this on our SOC and it works well.
Regards,
Oza.
^ permalink raw reply
* Re: [PATCH v2 0/5] mtd: nand: gpmi: add i.MX 7 support
From: Marek Vasut @ 2017-04-22 11:43 UTC (permalink / raw)
To: Stefan Agner, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
richard-/L3Ra7n9ekc, cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
han.xu-3arQi8VN3Tc, fabio.estevam-KZfg59tc24xl57MIdRCFDg,
LW-bxm8fMRDkQLDiMYJYoSAnRvVK+yQ3ZXh,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170422012338.4635-1-stefan-XLVq0VzYD2Y@public.gmane.org>
On 04/22/2017 03:23 AM, Stefan Agner wrote:
> This patchset adds support for i.MX 7 SoC for the GPMI NAND controller.
> There have been similar patchsets already:
> https://lkml.org/lkml/2016/2/23/912
>
> However, this patchset does not make use of any of the new features.
> The current feature set seems to work fine, I successfully run the MTD
> tests on a Colibri iMX7.
>
> --
> Stefan
>
> Changes since v1:
> - Make clks_count const
> - Introduce IS_IMX7D for i.MX 7 SoC's and make it part of GPMI_IS_MX6
Super, thanks.
--
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 4/4] [DO NOT MERGE] arm64: allwinner: a64: enable RTL8211E PHY workaround
From: kbuild test robot @ 2017-04-22 12:27 UTC (permalink / raw)
To: Icenowy Zheng
Cc: kbuild-all-JC7UmRfGjtg, Andrew Lunn, Florian Fainelli,
Rob Herring, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170421232436.10924-5-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]
Hi Icenowy,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.11-rc7 next-20170421]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Icenowy-Zheng/net-phy-realtek-change-macro-name-for-page-select-register/20170422-144641
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> Error: arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts:52.1-9 Label or path ext_phy not found
>> FATAL ERROR: Syntax error parsing input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 34529 bytes --]
^ 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