* Re: [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Andreas Färber @ 2016-11-28 10:58 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Russell King - ARM Linux, linux-arm-kernel, Michal Hrusecki,
Tomas Hlavacek, Bedřicha Košatu, Jason Cooper,
Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Mark Rutland, devicetree, linux-kernel
In-Reply-To: <e29e1a96-c9d5-d9b1-a42d-8afddc2714a7@kleine-koenig.org>
Hi,
Am 28.11.2016 um 11:54 schrieb Uwe Kleine-König:
> On 11/28/2016 11:52 AM, Andreas Färber wrote:
>> Would it help to split it back up into a series of add-labels,
>> use-labels like I had originally? Then you could start using them in
>> your refactoring as soon as the add-labels patch gets applied. Or are
>> you completely against this style?
>
> I'd even go as far as:
>
> 1: add labels to .dtsi
> 2: use labels on .dts#1
> 3: use labels on .dts#2
> ...
That was what I had in mind. :) I even considered reusing the existing
labels first, then adding more and converting more nodes.
Making the patches smaller will hopefully make them more easily
reviewable at the same time.
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Uwe Kleine-König @ 2016-11-28 10:54 UTC (permalink / raw)
To: Andreas Färber, Russell King - ARM Linux
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Michal Hrusecki, Tomas Hlavacek, Bedřicha Košatu,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Rob Herring, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4ad1108a-43c4-46f8-4683-1c4b89996036-l3A5Bk7waGM@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 738 bytes --]
Hello,
On 11/28/2016 11:52 AM, Andreas Färber wrote:
>> Please don't do this for clearfog - there's changes in the pipeline which
>> completely replace armada-388-clearfog.dts because there's a "base" and
>> "pro" versions of this hardware now, and making such a huge change will
>> effectively mean we have to start over with the DT files.
>
> Would it help to split it back up into a series of add-labels,
> use-labels like I had originally? Then you could start using them in
> your refactoring as soon as the add-labels patch gets applied. Or are
> you completely against this style?
I'd even go as far as:
1: add labels to .dtsi
2: use labels on .dts#1
3: use labels on .dts#2
...
Best regards
Uwe
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Andreas Färber @ 2016-11-28 10:52 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Mark Rutland, Andrew Lunn, Jason Cooper, Uwe Kleine-König,
devicetree, Tomas Hlavacek, linux-kernel, Rob Herring,
linux-arm-kernel, Gregory Clement, Sebastian Hesselbarth,
Bedřicha Košatu, Michal Hrusecki
In-Reply-To: <20161128103738.GT14217@n2100.armlinux.org.uk>
Hi Russell,
Am 28.11.2016 um 11:37 schrieb Russell King - ARM Linux:
> On Sun, Nov 27, 2016 at 07:51:39PM +0100, Andreas Färber wrote:
>> To more consistently reference nodes by label, add labels for sata,
>> usb2, sdhci and usb3 nodes.
>>
>> Convert all other 38x boards for consistency. Add labels for nfc and rtc.
>
> Please don't do this for clearfog - there's changes in the pipeline which
> completely replace armada-388-clearfog.dts because there's a "base" and
> "pro" versions of this hardware now, and making such a huge change will
> effectively mean we have to start over with the DT files.
Would it help to split it back up into a series of add-labels,
use-labels like I had originally? Then you could start using them in
your refactoring as soon as the add-labels patch gets applied. Or are
you completely against this style?
Thanks for pointing this out,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH] ARM: dts: da850: specify the maximum bandwidth for tilcdc
From: Bartosz Golaszewski @ 2016-11-28 10:43 UTC (permalink / raw)
To: Sekhar Nori
Cc: Mark Rutland, linux-devicetree, Kevin Hilman, Michael Turquette,
Jyri Sarha, Russell King, Rob Herring, LKML, Peter Ujfalusi,
Tomi Valkeinen, linux-drm, Frank Rowand, arm-soc,
Laurent Pinchart
In-Reply-To: <86f2b643-c270-1483-4f35-5bdf399a5919@ti.com>
2016-11-28 8:58 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
> On Monday 28 November 2016 01:12 PM, Tomi Valkeinen wrote:
>> On 28/11/16 07:24, Sekhar Nori wrote:
>>> On Friday 25 November 2016 09:07 PM, Bartosz Golaszewski wrote:
>>>> It has been determined that the maximum resolution supported correctly
>>>> by tilcdc rev1 on da850 SoCs is 800x600@60. Due to memory throughput
>>>> constraints we must filter out higher modes.
>>>>
>>>> Specify the max-bandwidth property for the display node for
>>>> da850-based boards.
>>>>
>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>> ---
>>>> arch/arm/boot/dts/da850.dtsi | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>>> index 8e30d9b..9b7c444 100644
>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>> @@ -452,6 +452,7 @@
>>>> compatible = "ti,da850-tilcdc";
>>>> reg = <0x213000 0x1000>;
>>>> interrupts = <52>;
>>>> + max-bandwidth = <28800000>;
>>>
>>> If this is effectively the max pixel clock that the device supports,
>>> then why not use the datasheet specified value of 37.5 MHz (Tc = 26.66 ns).
>>
>> There's a separate property for max-pixelclock. This one is maximum
>> pixels per second (which does sound almost the same), but the doc says
>> it's about the particular memory interface + LCDC combination.
>
> DA850 supports both mDDR and DDR2, at slightly different speeds. So
> memory bandwidth limitation is also board specific. This should probably
> move to board file.
>
> But I would like to know why using max-pixelclock is not good enough.
> Have experiments shown that LCDC on DA850 LCDK underflows even if pixel
> clock is below the datasheet recommendation?
>
Hi Sekhar,
I've just tested 1024x768 at 37000 KHz - indeed seems like the
underflows are gone as soon as we go below 37500 KHz. I'll submit a
new patch using the max-pixelclock property.
Thanks,
Bartosz Golaszewski
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Jean-Francois Moine @ 2016-11-28 10:42 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161128095900.27615-1-icenowy-ymACFijhrKM@public.gmane.org>
On Mon, 28 Nov 2016 17:59:00 +0800
Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org> wrote:
> As there's currently a fork of U-Boot which provides simplefb support
> for H3, a simplefb node can be added to the device tree.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
>
> I'm still not sure which pipeline should I use.
>
> And, it seems that HDMI Slow Clock is not needed?
>
> (seems that it's only for EDID, but simplefb won't use EDID)
So, I don't see how this may work.
How can the u-boot know the resolutions of the HDMI display device?
In other words: I have a new H3 board with the last u-boot and kernel.
I plug my (rather old or brand new) HDMI display device.
After powering on the system, I hope to get something on the screen.
How?
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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
* Re: [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Russell King - ARM Linux @ 2016-11-28 10:37 UTC (permalink / raw)
To: Andreas Färber
Cc: Mark Rutland, Andrew Lunn, Jason Cooper, Uwe Kleine-König,
devicetree, Tomas Hlavacek, linux-kernel, Rob Herring,
linux-arm-kernel, Gregory Clement, Sebastian Hesselbarth,
Bedřicha Košatu, Michal Hrusecki
In-Reply-To: <1480272700-28888-1-git-send-email-afaerber@suse.de>
On Sun, Nov 27, 2016 at 07:51:39PM +0100, Andreas Färber wrote:
> To more consistently reference nodes by label, add labels for sata,
> usb2, sdhci and usb3 nodes.
>
> Convert all other 38x boards for consistency. Add labels for nfc and rtc.
Please don't do this for clearfog - there's changes in the pipeline which
completely replace armada-388-clearfog.dts because there's a "base" and
"pro" versions of this hardware now, and making such a huge change will
effectively mean we have to start over with the DT files.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Sebastian Frias @ 2016-11-28 10:34 UTC (permalink / raw)
To: Florian Fainelli, Martin Blumenstingl, Jerome Brunet
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, khilman-rdvid1DuHRBWk0Htik3J/w,
mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
alexandre.torgue-qxv4g6HH51o, peppe.cavallaro-qxv4g6HH51o,
carlo-KA+7E9HrN00dnm+yROfE0A, Mans Rullgard, Andrew Lunn, mason
In-Reply-To: <1b7f113e-34f9-69f4-a45f-9fd687d87990-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 25/11/16 18:44, Florian Fainelli wrote:
> On 11/25/2016 03:13 AM, Sebastian Frias wrote:
>> On 24/11/16 19:55, Florian Fainelli wrote:
<snip>
>>> Correct, the meaning of PHY_INTERFACE_MODE should be from the
>>> perspective of the PHY device:
>>>
>>> - PHY_INTERFACE_MODE_RGMII_TXID means that the PHY is responsible for
>>> adding a delay when the MAC transmits (TX MAC -> PHY (delay) -> wire)
>>> - PHY_INTERFACE_MODE_RGMII_RXID means that the PHY is responsible for
>>> adding a delay when the MAC receives (RX MAC <- (delay) PHY) <- wire)
>>>
>>
>> Thanks for the explanation.
>> Actually I had thought that the delay was to account for board routing
>> (wires) between the MAC and the PHY.
>> From your explanation it appears that the delay is to account for board
>> routing (wires) between the PHY and the RJ45 socket.
>
> The placement of the (delay) was not meant to be exact, but it was
> wrongly place anyway, so it should be between the MAC and PHY, always.
> This is why you see people either fixing the need for a delay by
> appropriately programming the PHY, or the MAC, or by just inserting a
> fixed delay on the PCB between the PHY and the MAC and programming no
> delays (or using the default values and hoping this works).
Thanks.
Your patch "[PATCH net-next 3/4] Documentation: net: phy: Add blurb about
RGMII" on the documentation makes it clear.
>>>
>>> This also seems reasonable to do, provided that the PHY is also properly
>>> configured not to add delays in both directions, and therefore assumes
>>> that the MAC does it.
>>>
>>> We have a fairly large problem with how RGMII delays are done in PHYLIB
>>> and Ethernet MAC drivers (or just in general), where we can't really
>>> intersect properly what a PHY is supporting (in terms of internal
>>> delays), and what the MAC supports either. One possible approach could
>>> be to update PHY drivers a list of PHY_INTERFACE_MODE_* that they
>>> support (ideally, even with normalized nanosecond delay values),
>>
>> Just to make sure I understood this, the DT would say something like:
>>
>> phy-connection-type = "rgmii-txid";
>> txid-delay-ns = <3>;
>>
>> For a 3ns TX delay, would that be good?
>
> That's one possibility, although, see below, some PHYs support
> sub-nanosecond values, but in general, that seems like a good
> representation. If the "txid-delay-ns" property is omitted, a standard
> 2ns delay is assumed.
Sounds good.
I did not see the "txid-delay-ns" property documented in your patches, if
it is not too late, maybe it could be "txid-delay-ps" using picoseconds as
unit, right?
>>> and
>>> then intersect that with the requested phy_interface_t during
>>> phy_{attach,connect} time, and feed this back to the MAC with a special
>>> error code/callback, so we could gracefully try to choose another
>>> PHY_INTERFACE_MODE_* value that the MAC supports....
>>>
>>> A larger problem is that a number of drivers have been deployed, and
>>> Device Trees, possibly with the meaning of "phy-mode" and
>>> "phy-connection-type" being from the MAC perspective, and not the PHY
>>> perspective *sigh*, good luck auditing those.
>>>
>>> So from there, here is possibly what we could do
>>>
>>> - submit a series of patches that update the PHYLIB documentation (there
>>> are other things missing here) and make it clear from which entity (PHY
>>> or MAC) does the delay apply to, document the "intersection" problem here
>>
>> I think documenting is necessary, thanks in advance!
>>
>> However, I'm wondering if there's a way to make this work in all cases.
>> Indeed, if we consider for example that TX delay is required, we have 4
>> cases:
>>
>> PHY | MAC | Who applies?
>> TXID supported | TXID supported | PHY
>> TXID supported | TXID not supported | PHY
>> TXID not supported | TXID supported | MAC
>> TXID not supported | TXID not supported | cannot be done
>>
>> That is basically what my patch:
>>
>> https://marc.info/?l=linux-netdev&m=147869658031783&w=2
>>
>> attempted to achieve. That would allow more combinations of MAC<->PHY to
>> work, right?
>
> Yes, indeed.
Just one thing, from your patch "[PATCH net-next 3/4] Documentation: net:
phy: Add blurb about RGMII" I have the impression that the 3rd option from
the table above, would be a little bit more complex to implement.
I will comment on the patch.
>> Nevertheless, I think we also need to keep in mind that most of this
>> discussion assumes the case where both, MAC and PHY have equal capabilities.
>> Could it happen that the PHY supports only 2ns delay, and the MAC only
>> 1ns delay?
>
> I doubt this exists at the MAC level what we should have is either a 2ns
> delay, in either RX or TX path, or nothing, because that's the value
> that results in shifting the data lines and the RX/TX lines by 90
> degrees at 125Mhz (1/125^6 = 8 ns, one quarter shift is 90 degrees =
> 2ns). The PHY may have a similar set of pre-programmed, fixed 2ns
> delays, but it is not uncommon to see 0.X ns resolution available:
>
> drivers/net/phy/mscc.c
> drivers/net/phy/dp83867.c w/ arch/arm/boot/dts/dra72-evm-revc.dts
>
> In these cases, if you end-up using a non 2ns delay, you are fixing a
> PCB problem more than an interoperability problem between your MAC and PHY.
I see, thanks.
>> Could it happen that the delay is bigger than what is supported by
>> either the PHY or MAC alone? maybe if combined it could work, for example
>> a 3ns delay required and the PHY supporting 2ns and the MAC 1ns, combined
>> it could work?
>
> I suppose such a thing would work yes, but it would be difficult to
> report correctly to the core PHYLIB how this can work considering the
> vast array of options available to introduce delays in that case:
> MAC-level, PHY-level, pinctrl/pad level and possibly at the PCB itself.
>
> Once we can't rely on the fixed 2ns delay to work, we are going to have
> people do various experiments until they can either measure what the
> right delay value is for the specific PCB, or they just found the value
> that happens to work. I don't think we can do much at that point from a
> core PHYLIB perspective other than tell the network driver that the PHY
> supports delay in either RX, TX or both directions, and have the MAC
> decide what to apply that makes sense here, considering that this is
> already kind of an exceptional situation to be in.
Fair enough.
And thanks again for documenting this.
--
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 net-next v3 2/4] dt-bindings: net: add EEE capability constants
From: Yegor Yefremov @ 2016-11-28 10:28 UTC (permalink / raw)
To: Jerome Brunet
Cc: devicetree, Florian Fainelli, Alexandre TORGUE, Andrew Lunn,
Martin Blumenstingl, netdev, Neil Armstrong, kernel list,
Andre Roth, Kevin Hilman, Carlo Caione, Giuseppe Cavallaro,
linux-amlogic, linux-arm-kernel
In-Reply-To: <1480326409-25419-3-git-send-email-jbrunet@baylibre.com>
On Mon, Nov 28, 2016 at 10:46 AM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Tested using Baltos ir2110 device (cpsw + at8035 PHY).
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
> ---
> include/dt-bindings/net/mdio.h | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 include/dt-bindings/net/mdio.h
>
> diff --git a/include/dt-bindings/net/mdio.h b/include/dt-bindings/net/mdio.h
> new file mode 100644
> index 000000000000..99c6d903d439
> --- /dev/null
> +++ b/include/dt-bindings/net/mdio.h
> @@ -0,0 +1,19 @@
> +/*
> + * This header provides generic constants for ethernet MDIO bindings
> + */
> +
> +#ifndef _DT_BINDINGS_NET_MDIO_H
> +#define _DT_BINDINGS_NET_MDIO_H
> +
> +/*
> + * EEE capability Advertisement
> + */
> +
> +#define MDIO_EEE_100TX 0x0002 /* 100TX EEE cap */
> +#define MDIO_EEE_1000T 0x0004 /* 1000T EEE cap */
> +#define MDIO_EEE_10GT 0x0008 /* 10GT EEE cap */
> +#define MDIO_EEE_1000KX 0x0010 /* 1000KX EEE cap */
> +#define MDIO_EEE_10GKX4 0x0020 /* 10G KX4 EEE cap */
> +#define MDIO_EEE_10GKR 0x0040 /* 10G KR EEE cap */
> +
> +#endif
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH net-next v3 1/4] net: phy: add an option to disable EEE advertisement
From: Yegor Yefremov @ 2016-11-28 10:28 UTC (permalink / raw)
To: Jerome Brunet
Cc: devicetree, Florian Fainelli, Alexandre TORGUE, Andrew Lunn,
Martin Blumenstingl, netdev, Neil Armstrong, kernel list,
Andre Roth, Kevin Hilman, Carlo Caione, Giuseppe Cavallaro,
linux-amlogic, linux-arm-kernel
In-Reply-To: <1480326409-25419-2-git-send-email-jbrunet@baylibre.com>
On Mon, Nov 28, 2016 at 10:46 AM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> This patch adds an option to disable EEE advertisement in the generic PHY
> by providing a mask of prohibited modes corresponding to the value found in
> the MDIO_AN_EEE_ADV register.
>
> On some platforms, PHY Low power idle seems to be causing issues, even
> breaking the link some cases. The patch provides a convenient way for these
> platforms to disable EEE advertisement and work around the issue.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Tested using Baltos ir2110 device (cpsw + at8035 PHY).
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
> ---
> drivers/net/phy/phy.c | 3 ++
> drivers/net/phy/phy_device.c | 80 +++++++++++++++++++++++++++++++++++++++-----
> include/linux/phy.h | 3 ++
> 3 files changed, 77 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 73adbaa9ac86..a3981cc6448a 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -1396,6 +1396,9 @@ int phy_ethtool_set_eee(struct phy_device *phydev, struct ethtool_eee *data)
> {
> int val = ethtool_adv_to_mmd_eee_adv_t(data->advertised);
>
> + /* Mask prohibited EEE modes */
> + val &= ~phydev->eee_broken_modes;
> +
> phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN, val);
>
> return 0;
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index ba86c191a13e..83e52f1b80f2 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1121,6 +1121,43 @@ static int genphy_config_advert(struct phy_device *phydev)
> }
>
> /**
> + * genphy_config_eee_advert - disable unwanted eee mode advertisement
> + * @phydev: target phy_device struct
> + *
> + * Description: Writes MDIO_AN_EEE_ADV after disabling unsupported energy
> + * efficent ethernet modes. Returns 0 if the PHY's advertisement hasn't
> + * changed, and 1 if it has changed.
> + */
> +static int genphy_config_eee_advert(struct phy_device *phydev)
> +{
> + u32 broken = phydev->eee_broken_modes;
> + u32 old_adv, adv;
> +
> + /* Nothing to disable */
> + if (!broken)
> + return 0;
> +
> + /* If the following call fails, we assume that EEE is not
> + * supported by the phy. If we read 0, EEE is not advertised
> + * In both case, we don't need to continue
> + */
> + adv = phy_read_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN);
> + if (adv <= 0)
> + return 0;
> +
> + old_adv = adv;
> + adv &= ~broken;
> +
> + /* Advertising remains unchanged with the broken mask */
> + if (old_adv == adv)
> + return 0;
> +
> + phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN, adv);
> +
> + return 1;
> +}
> +
> +/**
> * genphy_setup_forced - configures/forces speed/duplex from @phydev
> * @phydev: target phy_device struct
> *
> @@ -1178,15 +1215,20 @@ EXPORT_SYMBOL(genphy_restart_aneg);
> */
> int genphy_config_aneg(struct phy_device *phydev)
> {
> - int result;
> + int err, changed;
> +
> + changed = genphy_config_eee_advert(phydev);
>
> if (AUTONEG_ENABLE != phydev->autoneg)
> return genphy_setup_forced(phydev);
>
> - result = genphy_config_advert(phydev);
> - if (result < 0) /* error */
> - return result;
> - if (result == 0) {
> + err = genphy_config_advert(phydev);
> + if (err < 0) /* error */
> + return err;
> +
> + changed |= err;
> +
> + if (changed == 0) {
> /* Advertisement hasn't changed, but maybe aneg was never on to
> * begin with? Or maybe phy was isolated?
> */
> @@ -1196,16 +1238,16 @@ int genphy_config_aneg(struct phy_device *phydev)
> return ctl;
>
> if (!(ctl & BMCR_ANENABLE) || (ctl & BMCR_ISOLATE))
> - result = 1; /* do restart aneg */
> + changed = 1; /* do restart aneg */
> }
>
> /* Only restart aneg if we are advertising something different
> * than we were before.
> */
> - if (result > 0)
> - result = genphy_restart_aneg(phydev);
> + if (changed > 0)
> + return genphy_restart_aneg(phydev);
>
> - return result;
> + return 0;
> }
> EXPORT_SYMBOL(genphy_config_aneg);
>
> @@ -1563,6 +1605,21 @@ static void of_set_phy_supported(struct phy_device *phydev)
> __set_phy_supported(phydev, max_speed);
> }
>
> +static void of_set_phy_eee_broken(struct phy_device *phydev)
> +{
> + struct device_node *node = phydev->mdio.dev.of_node;
> + u32 broken;
> +
> + if (!IS_ENABLED(CONFIG_OF_MDIO))
> + return;
> +
> + if (!node)
> + return;
> +
> + if (!of_property_read_u32(node, "eee-broken-modes", &broken))
> + phydev->eee_broken_modes = broken;
> +}
> +
> /**
> * phy_probe - probe and init a PHY device
> * @dev: device to probe and init
> @@ -1600,6 +1657,11 @@ static int phy_probe(struct device *dev)
> of_set_phy_supported(phydev);
> phydev->advertising = phydev->supported;
>
> + /* Get the EEE modes we want to prohibit. We will ask
> + * the PHY stop advertising these mode later on
> + */
> + of_set_phy_eee_broken(phydev);
> +
> /* Set the state to READY by default */
> phydev->state = PHY_READY;
>
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index edde28ce163a..b53177fd38af 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -417,6 +417,9 @@ struct phy_device {
> u32 advertising;
> u32 lp_advertising;
>
> + /* Energy efficient ethernet modes which should be prohibited */
> + u32 eee_broken_modes;
> +
> int autoneg;
>
> int link_timeout;
> --
> 2.7.4
>
^ permalink raw reply
* Re: [RFC PATCH 3/3] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-28 10:25 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, Xing.Xu, victor.wan, airlied, khilman, linux-kernel,
dri-devel, linux-amlogic, carlo, jerry.cao, linux-arm-kernel
In-Reply-To: <1695441.JP1H7VIm1f@avalon>
On 11/28/2016 11:02 AM, Laurent Pinchart wrote:
> Hi Neil,
>
> On Monday 28 Nov 2016 10:56:30 Neil Armstrong wrote:
>> On 11/28/2016 10:37 AM, Laurent Pinchart wrote:
>>> On Monday 28 Nov 2016 10:23:43 Neil Armstrong wrote:
>>>> On 11/28/2016 09:33 AM, Laurent Pinchart wrote:
>>>>> On Friday 25 Nov 2016 17:03:11 Neil Armstrong wrote:
>>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>>> ---
>>>>>>
>>>>>> .../bindings/display/meson/meson-drm.txt | 134
>>>>>> +++++++++++++++
>>>>>> 1 file changed, 134 insertions(+)
>>>>>> create mode 100644
>>>>>>
>>>>>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>>>>>
>>>>>> diff --git
>>>>>> a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>>>>> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new
>>>>>> file
>>>>>> mode 100644
>>>>>> index 0000000..89c1b5f
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>
>> [...]
>>
>>>>>> +
>>>>>> +VENC CBVS Output
>>>>>> +----------------------
>>>>>> +
>>>>>> +The VENC can output Composite/CVBS output via a decicated VDAC.
>>>>>> +
>>>>>> +Required properties:
>>>>>> + - compatible: value must be one of:
>>>>>> + - compatible: value should be different for each SoC family as :
>>>>> One of those two lines is redundant.
>>>>
>>>> Will fix.
>>>>
>>>>>> + - GXBB (S905) : "amlogic,meson-gxbb-venc-cvbs"
>>>>>> + - GXL (S905X, S905D) : "amlogic,meson-gxl-venc-cvbs"
>>>>>> + - GXM (S912) : "amlogic,meson-gxm-venc-cvbs"
>>>>>> + followed by the common "amlogic,meson-gx-venc-cvbs"
>>>>>> +
>>>>>
>>>>> No registers ? Are the encoders registers part of the VPU register
>>>>> space, intertwined in a way that they can't be specified separately here
>>>>> ?
>>>>
>>>> Exact, all the video registers on the Amlogic SoC are part of a long
>>>> history of fixup/enhance from very old SoCs, it's quite hard to
>>>> distinguish a Venc registers array since they are mixed with the
>>>> multiple encoders registers...
>>>
>>> In that case is there really a reason to model the encoders as separate
>>> nodes in DT ?
>>
>> Here, it more the encoder-connector couple that is represented as a node,
>> and the CVBS output is optional.
>
> You should actually have a DT node for the connector. I would merge the
> encoders into the VPU node (especially given that according to your diagram
> they are part of the VPU), and document the VPU output ports explicitly. If
> the CVBS output is not implemented by some of the SoCs in the family then the
> corresponding DT node should just omit that port.
>
Yes, seems a way better option !
[...]
Thanks for the hints,
Neil
^ permalink raw reply
* Re: Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Chen-Yu Tsai @ 2016-11-28 10:24 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Maxime Ripard, Jernej Skrabec, Jean-Francois Moine,
devicetree, linux-arm-kernel, linux-kernel, linux-sunxi
In-Reply-To: <496171480328390-w+qEnKy0EGlxpj1cXAZ9Bg@public.gmane.org>
On Mon, Nov 28, 2016 at 6:19 PM, Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org> wrote:
>
>
> 28.11.2016, 18:07, "Chen-Yu Tsai" <wens-jdAy2FN1RRM@public.gmane.org>:
>> On Mon, Nov 28, 2016 at 5:59 PM, Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org> wrote:
>>> As there's currently a fork of U-Boot which provides simplefb support
>>
>> Please add it when its finalized...
>>
>>> for H3, a simplefb node can be added to the device tree.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>> ---
>>>
>>> I'm still not sure which pipeline should I use.
>>
>> You are supposed to add _all_ the pipelines that are available and
>> supported by U-boot. U-boot is then supposed to enable and update
>> the one it set up.
>
> I mean the pipeline string ;-)
Looks good to me. There's no separate frontend/backend in DE 2.0.
ChenYu
>
>>
>> ChenYu
>>
>>> And, it seems that HDMI Slow Clock is not needed?
>>>
>>> (seems that it's only for EDID, but simplefb won't use EDID)
>>>
>>> arch/arm/boot/dts/sun8i-h3.dtsi | 16 ++++++++++++++++
>>> 1 file changed, 16 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> index 75a8654..cacc8dd 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> @@ -50,6 +50,22 @@
>>> / {
>>> interrupt-parent = <&gic>;
>>>
>>> + chosen {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges;
>>> +
>>> + simplefb_hdmi: framebuffer@0 {
>>> + compatible = "allwinner,simple-framebuffer",
>>> + "simple-framebuffer";
>>> + allwinner,pipeline = "de0-lcd0-hdmi";
>>> + clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_BUS_DE>,
>>> + <&ccu CLK_BUS_HDMI>, <&ccu CLK_DE>,
>>> + <&ccu CLK_TCON0>, <&ccu CLK_HDMI>;
>>> + status = "disabled";
>>> + };
>>> + };
>>> +
>>> cpus {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> --
>>> 2.10.2
>
> --
> 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
* Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Icenowy Zheng @ 2016-11-28 10:19 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Jernej Skrabec, Jean-Francois Moine, devicetree,
linux-arm-kernel, linux-kernel, linux-sunxi
In-Reply-To: <CAGb2v67akcT6z-xOdCzpLQRZbgNGh3E5akYEs1BvFNP1rH8UeA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
28.11.2016, 18:07, "Chen-Yu Tsai" <wens-jdAy2FN1RRM@public.gmane.org>:
> On Mon, Nov 28, 2016 at 5:59 PM, Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org> wrote:
>> As there's currently a fork of U-Boot which provides simplefb support
>
> Please add it when its finalized...
>
>> for H3, a simplefb node can be added to the device tree.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>> ---
>>
>> I'm still not sure which pipeline should I use.
>
> You are supposed to add _all_ the pipelines that are available and
> supported by U-boot. U-boot is then supposed to enable and update
> the one it set up.
I mean the pipeline string ;-)
>
> ChenYu
>
>> And, it seems that HDMI Slow Clock is not needed?
>>
>> (seems that it's only for EDID, but simplefb won't use EDID)
>>
>> arch/arm/boot/dts/sun8i-h3.dtsi | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index 75a8654..cacc8dd 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -50,6 +50,22 @@
>> / {
>> interrupt-parent = <&gic>;
>>
>> + chosen {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +
>> + simplefb_hdmi: framebuffer@0 {
>> + compatible = "allwinner,simple-framebuffer",
>> + "simple-framebuffer";
>> + allwinner,pipeline = "de0-lcd0-hdmi";
>> + clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_BUS_DE>,
>> + <&ccu CLK_BUS_HDMI>, <&ccu CLK_DE>,
>> + <&ccu CLK_TCON0>, <&ccu CLK_HDMI>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> --
>> 2.10.2
--
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
* fwd, Re: [PATCH v3] cpufreq: brcmstb-cpufreq: CPUfreq driver for older Broadcom STB SoCs
From: Arnd Bergmann @ 2016-11-28 10:16 UTC (permalink / raw)
To: Markus Mayer
Cc: Device Tree, Power Management List, Viresh Kumar,
Rafael J . Wysocki, Linux Kernel Mailing List,
Broadcom Kernel List, Markus Mayer, linux-clk, linux-arm-kernel
In-Reply-To: <20161122213245.17955-1-code@mmayer.net>
[resending my mail, this time with devicetree, linux-clk, and linux-arm-kernel
on cc]
On Tuesday, November 22, 2016 1:32:45 PM CET Markus Mayer wrote:
> From: Markus Mayer <mmayer@broadcom.com>
>
> This CPUfreq driver provides basic frequency scaling for older Broadcom
> STB SoCs that do not use AVS firmware with DVFS support. There is no
> support for voltage scaling.
>
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
This causes multiple build errors in linux-next, please fix asap or
drop the patch again. My feeling is that it's probably too late to
fix it for v4.10, but that's up to Viresh and Rafael of course.
> +#define BRCMSTB_CPUFREQ_PREFIX "brcmstb"
> +#define BRCMSTB_CPUFREQ_NAME BRCMSTB_CPUFREQ_PREFIX "-cpufreq"
> +
> +/* We search for these compatible strings. */
> +#define BRCMSTB_DT_CPU_CLK_CTRL "brcm,brcmstb-cpu-clk-div"
> +#define BRCMSTB_DT_MEMC_DDR "brcm,brcmstb-memc-ddr"
> +#define BRCM_AVS_CPU_DATA "brcm,avs-cpu-data-mem"
> +
> +/* We also need a few clocks in device tree. These are node names. */
> +#define BRCMSTB_CLK_MDIV_CH0 "cpu_mdiv_ch0"
> +#define BRCMSTB_CLK_NDIV_INT "cpu_ndiv_int"
> +#define BRCMSTB_CLK_SW_SCB "sw_scb"
Not critical but the use of those macros obfuscates the DT interfaces
here and made it harder to analyse what was going on.
Also, a couple of them are lacking a DT binding.
> +static int get_frequencies(const struct cpufreq_policy *policy,
> + unsigned int *vco_freq, unsigned int *cpu_freq,
> + unsigned int *scb_freq)
> +{
> + struct clk *cpu_ndiv_int, *sw_scb;
> +
> + cpu_ndiv_int = __clk_lookup(BRCMSTB_CLK_NDIV_INT);
> + if (!cpu_ndiv_int)
> + return -ENODEV;
> +
> + sw_scb = __clk_lookup(BRCMSTB_CLK_SW_SCB);
> + if (!sw_scb)
> + return -ENODEV;
> +
> + /* return frequencies in kHz */
> + *vco_freq = clk_get_rate(cpu_ndiv_int) / 1000;
> + *cpu_freq = clk_get_rate(policy->clk) / 1000;
> + *scb_freq = clk_get_rate(sw_scb) / 1000;
> +
> + return 0;
> +}
You really can't do this:
../drivers/cpufreq/brcmstb-cpufreq.c: In function 'get_frequencies':
../drivers/cpufreq/brcmstb-cpufreq.c:71:17: error: implicit declaration of function '__clk_lookup';did you mean 'key_lookup'? [-Werror=implicit-function-declaration]
cpu_ndiv_int = __clk_lookup(BRCMSTB_CLK_NDIV_INT);
^~~~~~~~~~~~
__clk_lookup is an internal API for the clk providers.
In particular, relying on undocumented internal names of the
clk provider in a device driver is inappropriate.
> +static const struct of_device_id brcmstb_cpufreq_match[] = {
> + { .compatible = BRCMSTB_DT_CPU_CLK_CTRL },
> + { }
> +};
> +MODULE_DEVICE_TABLE(platform, brcmstb_cpufreq_match);
This is a simple typo, also causing the build to fail:
FATAL: drivers/cpufreq/brcmstb-cpufreq: sizeof(struct platform_device_id)=24 is not a modulo of the size of section __mod_platform__<identifier>_device_table=392.
Arnd
^ permalink raw reply
* Re: [PATCH v3] clkdev: add devm_of_clk_get()
From: kbuild test robot @ 2016-11-28 10:16 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: kbuild-all, Russell King - ARM Linux, Stephen Boyd, Rob Herring,
Linux-ALSA, Linux-DT, Michael Turquette, Linux-Kernel, Mark Brown,
linux-clk, Linux-ARM
In-Reply-To: <87vav89chw.wl%kuninori.morimoto.gx@renesas.com>
[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]
Hi Kuninori,
[auto build test ERROR on clk/clk-next]
[also build test ERROR on v4.9-rc7 next-20161128]
[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/Kuninori-Morimoto/clkdev-add-devm_of_clk_get/20161128-173723
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: i386-randconfig-x004-201648 (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/clk/clk-devres.c:57:13: error: redefinition of 'devm_of_clk_get'
struct clk *devm_of_clk_get(struct device *dev,
^~~~~~~~~~~~~~~
In file included from drivers/clk/clk-devres.c:7:0:
include/linux/clk.h:518:27: note: previous definition of 'devm_of_clk_get' was here
static inline struct clk *devm_of_clk_get(struct device *dev,
^~~~~~~~~~~~~~~
vim +/devm_of_clk_get +57 drivers/clk/clk-devres.c
51 ret = devres_release(dev, devm_clk_release, devm_clk_match, clk);
52
53 WARN_ON(ret);
54 }
55 EXPORT_SYMBOL(devm_clk_put);
56
> 57 struct clk *devm_of_clk_get(struct device *dev,
58 struct device_node *np, int index)
59 {
60 struct clk **ptr, *clk;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 26142 bytes --]
^ permalink raw reply
* Re: [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Ziji Hu @ 2016-11-28 10:10 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: <436c6925-cb0d-afe7-e3a2-384eca15ff42@marvell.com>
Hi Ulf,
On 2016/11/24 23:37, Ziji Hu wrote:
> Hi Ulf,
>
> On 2016/11/24 22:33, Ulf Hansson wrote:
<snip>
>>>
>>> As result, our SDHC driver has to implement the functionality to
>>> send commands and check the results, in host layer.
>>> If directly calling mmc_wait_for_cmd() is improper, could you please
>>> give us some suggestions?
>>>
>>> For eMMC, CMD8 is used to test current sampling point set in PHY.
>>
>> Try to use mmc_send_tuning().
>>
>
> Could you please tell me the requirement of "op_code" parameter in
> mmc_send_tuning()?
> According to mmc_send_tuning(),it seems that tuning command(CMD19/CMD21)
> is required. Thus device will not response mmc_send_tuning() if current
> speed mode doesn't support tuning command.
> Please correct me if I am wrong.
>
As you suggest, I replace mmc_wait_for_cmd() with mmc_send_tuning(), to
send commands for testing current sampling point set in our host PHY.
According to my test result, it shows that mmc_send_tuning() can only support
tuning command (CMD21/CMD19).
As a result, we cannot use mmc_send_tuning() when card is in the speed modes
which doesn't support tuning, such as eMMC HS SDR, eMMC HS DRR and
SD SDR 12/SDR25/DDR50. Card will not response to tuning commands in those
speed modes.
Could you please provide suggestions for the speed mode in which tuning is
not available?
Thank you.
Best regards,
Hu Ziji
>>>
>>>>> +
>>>>> + return err;
>>>>> +}
>>>>> +
>>>>> +static int __xenon_sdio_delay_adj_test(struct mmc_card *card)
>>>>> +{
>>>>> + struct mmc_command cmd = {0};
>>>>> + int err;
>>>>> +
>>>>> + cmd.opcode = SD_IO_RW_DIRECT;
>>>>> + cmd.flags = MMC_RSP_R5 | MMC_CMD_AC;
>>>>> +
>>>>> + err = mmc_wait_for_cmd(card->host, &cmd, 0);
>>>>> + if (err)
>>>>> + return err;
>>>>> +
>>>>> + if (cmd.resp[0] & R5_ERROR)
>>>>> + return -EIO;
>>>>> + if (cmd.resp[0] & R5_FUNCTION_NUMBER)
>>>>> + return -EINVAL;
>>>>> + if (cmd.resp[0] & R5_OUT_OF_RANGE)
>>>>> + return -ERANGE;
>>>>> + return 0;
>>>>
>>>> No thanks! MMC/SD/SDIO protocol code belongs in the core.
>>>>
>>> For SDIO, SD_IO_RW_DIRECT command is sent to test current sampling point
>>> in PHY.
>>> Please help provide some suggestion to implement the command transfer.
>>
>> Again, I think mmc_send_tuning() should be possible for you to use.
>>
>> [...]
>>
>>>>> + if (mmc->card)
>>>>> + card = mmc->card;
>>>>> + else
>>>>> + /*
>>>>> + * Only valid during initialization
>>>>> + * before mmc->card is set
>>>>> + */
>>>>> + card = priv->card_candidate;
>>>>> + if (unlikely(!card)) {
>>>>> + dev_warn(mmc_dev(mmc), "card is not present\n");
>>>>> + return -EINVAL;
>>>>> + }
>>>>
>>>> That your host need to hold a copy of the card pointer, tells me that
>>>> something is not really correct.
>>>>
>>>> I might be wrong, if this turns out to be a special case, but I doubt
>>>> it. Although, if it *is* a special such case, we shall most likely try
>>>> to extend the the mmc core layer instead of adding all these hacks in
>>>> your host driver.
>>>>
>>> This card pointer copies the temporary structure mmc_card
>>> used in mmc_init_card(), mmc_sd_init_card() and mmc_sdio_init_card().
>>> Since we call mmc_wait_for_cmd() to send test commands, we need a copy
>>> of that temporary mmc_card here in our host driver.
>>
>> I see, thanks for clarifying.
>>
>>>
>>> During PHY setting in card initialization, mmc_host->card is not updated
>>> yet with that temporary mmc_card. Thus we are not able to directly use
>>> mmc_host->card. Instead, this card pointer is introduced to enable
>>> mmc_wait_for_cmd().
>>>
>>> If we can improve our host driver to send test commands without mmc_card,
>>> this card pointer can be removed.
>>> Could you please share your opinion please?
>>
>> The mmc_send_tuning() API takes the mmc_host as parameter. If you
>> convert to that, perhaps you would be able to remove the need to hold
>> the card pointer.
>>
>> BTW, the reason why mmc_send_tuning() doesn't take the card as a
>> parameter, is exactly those you just described above.
>>
> Got it.
> Thanks a lot for the information.
>
> Thank you for the great help.
>
> 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
>
^ permalink raw reply
* Re: [PATCH v3] clkdev: add devm_of_clk_get()
From: Russell King - ARM Linux @ 2016-11-28 10:10 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Linux-ALSA, Linux-DT, Michael Turquette, Stephen Boyd,
Linux-Kernel, Mark Brown, linux-clk, Linux-ARM
In-Reply-To: <87vav89chw.wl%kuninori.morimoto.gx@renesas.com>
On Mon, Nov 28, 2016 at 09:32:51AM +0000, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> Current Linux has of_clk_get(), but doesn't have devm_of_clk_get().
> This patch adds it.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> v2 -> v3
>
> - implement in clk-devres.c, and reused existing devm_clk_release()
>
> drivers/clk/clk-devres.c | 21 +++++++++++++++++++++
> include/linux/clk.h | 7 +++++++
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
> index 8f57154..2449b25 100644
> --- a/drivers/clk/clk-devres.c
> +++ b/drivers/clk/clk-devres.c
> @@ -53,3 +53,24 @@ void devm_clk_put(struct device *dev, struct clk *clk)
> WARN_ON(ret);
> }
> EXPORT_SYMBOL(devm_clk_put);
> +
> +struct clk *devm_of_clk_get(struct device *dev,
> + struct device_node *np, int index)
> +{
> + struct clk **ptr, *clk;
> +
> + ptr = devres_alloc(devm_clk_release, sizeof(*ptr), GFP_KERNEL);
> + if (!ptr)
> + return ERR_PTR(-ENOMEM);
> +
> + clk = of_clk_get(np, index);
> + if (!IS_ERR(clk)) {
> + *ptr = clk;
> + devres_add(dev, ptr);
> + } else {
> + devres_free(ptr);
> + }
> +
> + return clk;
> +}
> +EXPORT_SYMBOL(devm_of_clk_get);
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 123c027..1b713db 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -506,6 +506,8 @@ static inline void clk_disable_unprepare(struct clk *clk)
>
> #if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
> struct clk *of_clk_get(struct device_node *np, int index);
> +struct clk *devm_of_clk_get(struct device *dev,
> + struct device_node *np, int index);
No need for this to be within the ifdef.
> struct clk *of_clk_get_by_name(struct device_node *np, const char *name);
> struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec);
> #else
> @@ -513,6 +515,11 @@ static inline struct clk *of_clk_get(struct device_node *np, int index)
> {
> return ERR_PTR(-ENOENT);
> }
> +static inline struct clk *devm_of_clk_get(struct device *dev,
> + struct device_node *np, int index)
> +{
> + return ERR_PTR(-ENOENT);
> +}
and so no need for this either. In any case, this will cause !OF ||
!COMMON_CLK builds to fail because this definition will conflict with
that in clk-devres.c
> static inline struct clk *of_clk_get_by_name(struct device_node *np,
> const char *name)
> {
> --
> 1.9.1
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Chen-Yu Tsai @ 2016-11-28 10:06 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec, Jean-Francois Moine,
devicetree, linux-arm-kernel, linux-kernel, linux-sunxi
In-Reply-To: <20161128095900.27615-1-icenowy-ymACFijhrKM@public.gmane.org>
On Mon, Nov 28, 2016 at 5:59 PM, Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org> wrote:
> As there's currently a fork of U-Boot which provides simplefb support
Please add it when its finalized...
> for H3, a simplefb node can be added to the device tree.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
>
> I'm still not sure which pipeline should I use.
You are supposed to add _all_ the pipelines that are available and
supported by U-boot. U-boot is then supposed to enable and update
the one it set up.
ChenYu
>
> And, it seems that HDMI Slow Clock is not needed?
>
> (seems that it's only for EDID, but simplefb won't use EDID)
>
> arch/arm/boot/dts/sun8i-h3.dtsi | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 75a8654..cacc8dd 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -50,6 +50,22 @@
> / {
> interrupt-parent = <&gic>;
>
> + chosen {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + simplefb_hdmi: framebuffer@0 {
> + compatible = "allwinner,simple-framebuffer",
> + "simple-framebuffer";
> + allwinner,pipeline = "de0-lcd0-hdmi";
> + clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_BUS_DE>,
> + <&ccu CLK_BUS_HDMI>, <&ccu CLK_DE>,
> + <&ccu CLK_TCON0>, <&ccu CLK_HDMI>;
> + status = "disabled";
> + };
> + };
> +
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> --
> 2.10.2
>
^ permalink raw reply
* Re: [RFC PATCH 3/3] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Laurent Pinchart @ 2016-11-28 10:02 UTC (permalink / raw)
To: Neil Armstrong
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, airlied-cv59FeDIM0c,
khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, Xing.Xu-LpR1jeaWuhtBDgjK7y7TUQ,
victor.wan-LpR1jeaWuhtBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <534f6d99-a579-27b6-fb54-48584cd1c7aa-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Neil,
On Monday 28 Nov 2016 10:56:30 Neil Armstrong wrote:
> On 11/28/2016 10:37 AM, Laurent Pinchart wrote:
> > On Monday 28 Nov 2016 10:23:43 Neil Armstrong wrote:
> >> On 11/28/2016 09:33 AM, Laurent Pinchart wrote:
> >>> On Friday 25 Nov 2016 17:03:11 Neil Armstrong wrote:
> >>>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> >>>> ---
> >>>>
> >>>> .../bindings/display/meson/meson-drm.txt | 134
> >>>> +++++++++++++++
> >>>> 1 file changed, 134 insertions(+)
> >>>> create mode 100644
> >>>>
> >>>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
> >>>>
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
> >>>> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new
> >>>> file
> >>>> mode 100644
> >>>> index 0000000..89c1b5f
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>
> [...]
>
> >>>> +
> >>>> +VENC CBVS Output
> >>>> +----------------------
> >>>> +
> >>>> +The VENC can output Composite/CVBS output via a decicated VDAC.
> >>>> +
> >>>> +Required properties:
> >>>> + - compatible: value must be one of:
> >>>> + - compatible: value should be different for each SoC family as :
> >>> One of those two lines is redundant.
> >>
> >> Will fix.
> >>
> >>>> + - GXBB (S905) : "amlogic,meson-gxbb-venc-cvbs"
> >>>> + - GXL (S905X, S905D) : "amlogic,meson-gxl-venc-cvbs"
> >>>> + - GXM (S912) : "amlogic,meson-gxm-venc-cvbs"
> >>>> + followed by the common "amlogic,meson-gx-venc-cvbs"
> >>>> +
> >>>
> >>> No registers ? Are the encoders registers part of the VPU register
> >>> space, intertwined in a way that they can't be specified separately here
> >>> ?
> >>
> >> Exact, all the video registers on the Amlogic SoC are part of a long
> >> history of fixup/enhance from very old SoCs, it's quite hard to
> >> distinguish a Venc registers array since they are mixed with the
> >> multiple encoders registers...
> >
> > In that case is there really a reason to model the encoders as separate
> > nodes in DT ?
>
> Here, it more the encoder-connector couple that is represented as a node,
> and the CVBS output is optional.
You should actually have a DT node for the connector. I would merge the
encoders into the VPU node (especially given that according to your diagram
they are part of the VPU), and document the VPU output ports explicitly. If
the CVBS output is not implemented by some of the SoCs in the family then the
corresponding DT node should just omit that port.
> >> The only separate registers are the VDAC and HDMI PHY, I may move them to
> >> these separate nodes since they are part of the HHI register space.
> >>
> >> It is a problem if I move them in the next release ? Next release will
> >> certainly have HDMI support, and will have these refactorings.
> >
> > Given that DT bindings are considered as a stable ABI, I'm afraid it's an
> > issue.
>
> OK, I will add the VDAC/HDMI PHY registers as part if these output nodes.
Thank you.
> >>>> +- ports: A ports node with endpoint definitions as defined in
> >>>> + Documentation/devicetree/bindings/media/video-interfaces.txt. The
> >>>> + first port should be the input endpoints, connected ot the VPU node.
> >>>> +
> >>>> +Example:
> >>>> +
> >>>> +venc_cvbs: venc-cvbs {
> >>>> + compatible = "amlogic,meson-gxbb-venc-cvbs";
> >>>> + status = "okay";
> >>>> +
> >>>> + ports {
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> +
> >>>> + enc_cvbs_in: port@0 {
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> + reg = <0>;
> >>>> +
> >>>> + venc_cvbs_in_vpu: endpoint@0 {
> >>>> + reg = <0>;
> >>>> + remote-endpoint =
<&vpu_out_venc_cvbs>;
> >>>> + };
> >>>> + };
> >>>> + };
> >>>> +};
> >>>> +
> >>>> +vpu: vpu@d0100000 {
> >>>> + compatible = "amlogic,meson-gxbb-vpu";
> >>>> + reg = <0x0 0xd0100000 0x0 0x100000>,
> >>>> + <0x0 0xc883c000 0x0 0x1000>,
> >>>> + <0x0 0xc8838000 0x0 0x1000>;
> >>>> + reg-names = "base", "hhi", "dmc";
> >>>> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
> >>>> +
> >>>> + ports {
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> +
> >>>> + vpu_out: port@1 {
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> + reg = <1>;
> >>>> +
> >>>> + vpu_out_venc_cvbs: endpoint@0 {
> >>>> + reg = <0>;
> >>>> + remote-endpoint =
<&venc_cvbs_in_vpu>;
> >>>> + };
> >>>> + };
> >>>> + };
> >>>> +};
> >>
> >> Thanks for the review !
--
Regards,
Laurent Pinchart
--
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
* [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Icenowy Zheng @ 2016-11-28 9:59 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec, Jean-Francois Moine
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
As there's currently a fork of U-Boot which provides simplefb support
for H3, a simplefb node can be added to the device tree.
Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
---
I'm still not sure which pipeline should I use.
And, it seems that HDMI Slow Clock is not needed?
(seems that it's only for EDID, but simplefb won't use EDID)
arch/arm/boot/dts/sun8i-h3.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 75a8654..cacc8dd 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -50,6 +50,22 @@
/ {
interrupt-parent = <&gic>;
+ chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ simplefb_hdmi: framebuffer@0 {
+ compatible = "allwinner,simple-framebuffer",
+ "simple-framebuffer";
+ allwinner,pipeline = "de0-lcd0-hdmi";
+ clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_BUS_DE>,
+ <&ccu CLK_BUS_HDMI>, <&ccu CLK_DE>,
+ <&ccu CLK_TCON0>, <&ccu CLK_HDMI>;
+ status = "disabled";
+ };
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
--
2.10.2
^ permalink raw reply related
* (unknown),
From: Mr Friedrich Mayrhofer @ 2016-11-28 9:58 UTC (permalink / raw)
Good Day,
This is the second time i am sending you this mail.
I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for
more details.
Regards.
Friedrich Mayrhofer
--
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: [RFC PATCH 3/3] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-28 9:56 UTC (permalink / raw)
To: Laurent Pinchart
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, airlied-cv59FeDIM0c,
khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, Xing.Xu-LpR1jeaWuhtBDgjK7y7TUQ,
victor.wan-LpR1jeaWuhtBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <2350540.yAeGFdYPK2@avalon>
Hi Laurent,
On 11/28/2016 10:37 AM, Laurent Pinchart wrote:
> Hi Neil,
>
> On Monday 28 Nov 2016 10:23:43 Neil Armstrong wrote:
>> On 11/28/2016 09:33 AM, Laurent Pinchart wrote:
>>> On Friday 25 Nov 2016 17:03:11 Neil Armstrong wrote:
>>>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>>> ---
>>>>
>>>> .../bindings/display/meson/meson-drm.txt | 134 +++++++++++++++
>>>> 1 file changed, 134 insertions(+)
>>>> create mode 100644
>>>>
>>>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>>> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new file
>>>> mode 100644
>>>> index 0000000..89c1b5f
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
[...]
>>>> +
>>>> +VENC CBVS Output
>>>> +----------------------
>>>> +
>>>> +The VENC can output Composite/CVBS output via a decicated VDAC.
>>>> +
>>>> +Required properties:
>>>> + - compatible: value must be one of:
>>>> + - compatible: value should be different for each SoC family as :
>>> One of those two lines is redundant.
>>
>> Will fix.
>>
>>>> + - GXBB (S905) : "amlogic,meson-gxbb-venc-cvbs"
>>>> + - GXL (S905X, S905D) : "amlogic,meson-gxl-venc-cvbs"
>>>> + - GXM (S912) : "amlogic,meson-gxm-venc-cvbs"
>>>> + followed by the common "amlogic,meson-gx-venc-cvbs"
>>>> +
>>>
>>> No registers ? Are the encoders registers part of the VPU register space,
>>> intertwined in a way that they can't be specified separately here ?
>>
>> Exact, all the video registers on the Amlogic SoC are part of a long history
>> of fixup/enhance from very old SoCs, it's quite hard to distinguish a Venc
>> registers array since they are mixed with the multiple encoders
>> registers...
>
> In that case is there really a reason to model the encoders as separate nodes
> in DT ?
Here, it more the encoder-connector couple that is represented as a node, and
the CVBS output is optional.
>
>> The only separate registers are the VDAC and HDMI PHY, I may move them to
>> these separate nodes since they are part of the HHI register space.
>>
>> It is a problem if I move them in the next release ? Next release will
>> certainly have HDMI support, and will have these refactorings.
>
> Given that DT bindings are considered as a stable ABI, I'm afraid it's an
> issue.
OK, I will add the VDAC/HDMI PHY registers as part if these output nodes.
>
>>>> +- ports: A ports node with endpoint definitions as defined in
>>>> + Documentation/devicetree/bindings/media/video-interfaces.txt. The
>>>> + first port should be the input endpoints, connected ot the VPU node.
>>>> +
>>>> +Example:
>>>> +
>>>> +venc_cvbs: venc-cvbs {
>>>> + compatible = "amlogic,meson-gxbb-venc-cvbs";
>>>> + status = "okay";
>>>> +
>>>> + ports {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> +
>>>> + enc_cvbs_in: port@0 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + reg = <0>;
>>>> +
>>>> + venc_cvbs_in_vpu: endpoint@0 {
>>>> + reg = <0>;
>>>> + remote-endpoint = <&vpu_out_venc_cvbs>;
>>>> + };
>>>> + };
>>>> + };
>>>> +};
>>>> +
>>>> +vpu: vpu@d0100000 {
>>>> + compatible = "amlogic,meson-gxbb-vpu";
>>>> + reg = <0x0 0xd0100000 0x0 0x100000>,
>>>> + <0x0 0xc883c000 0x0 0x1000>,
>>>> + <0x0 0xc8838000 0x0 0x1000>;
>>>> + reg-names = "base", "hhi", "dmc";
>>>> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
>>>> +
>>>> + ports {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> +
>>>> + vpu_out: port@1 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + reg = <1>;
>>>> +
>>>> + vpu_out_venc_cvbs: endpoint@0 {
>>>> + reg = <0>;
>>>> + remote-endpoint = <&venc_cvbs_in_vpu>;
>>>> + };
>>>> + };
>>>> + };
>>>> +};
>>
>> Thanks for the review !
>
Neil
--
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
* [RFC PATCH 2/2] Documentation: devictree: Add macb mdio bindings
From: Harini Katakam @ 2016-11-28 9:49 UTC (permalink / raw)
To: nicolas.ferre, davem, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, boris.brezillon, alexandre.belloni,
harinikatakamlinux
Cc: netdev, linux-kernel, devicetree, harinik, michals
Add documentations for macb mdio driver.
Signed-off-by: Harini Katakam <harinik@xilinx.com>
---
.../devicetree/bindings/net/macb-mdio.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/macb-mdio.txt
diff --git a/Documentation/devicetree/bindings/net/macb-mdio.txt b/Documentation/devicetree/bindings/net/macb-mdio.txt
new file mode 100644
index 0000000..014cedf
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/macb-mdio.txt
@@ -0,0 +1,31 @@
+* Cadence MACB MDIO controller
+
+Required properties:
+- compatible: Should be "cdns,macb-mdio"
+- reg: Address and length of the register set of MAC to be used
+- clock-names: Tuple listing input clock names.
+ Required elements: 'pclk', 'hclk'
+ Optional elements: 'tx_clk'
+- clocks: Phandles to input clocks.
+
+Examples:
+
+ mdio {
+ compatible = "cdns,macb-mdio";
+ reg = <0x0 0xff0b0000 0x0 0x1000>;
+ clocks = <&clk125>, <&clk125>, <&clk125>;
+ clock-names = "pclk", "hclk", "tx_clk";
+ ethernet_phyC: ethernet-phy@C {
+ reg = <0xC>;
+ };
+ ethernet_phy7: ethernet-phy@7 {
+ reg = <0x7>;
+ };
+ ethernet_phy3: ethernet-phy@3 {
+ reg = <0x3>;
+ };
+ ethernet_phy8: ethernet-phy@8 {
+ reg = <0x8>;
+ };
+ };
+
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 1/2] net: macb: Add MDIO driver for accessing multiple PHY devices
From: Harini Katakam @ 2016-11-28 9:49 UTC (permalink / raw)
To: nicolas.ferre, davem, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, boris.brezillon, alexandre.belloni,
harinikatakamlinux
Cc: netdev, linux-kernel, devicetree, harinik, michals,
Punnaiah Choudary Kalluri
This patch is to add support for the hardware with multiple ethernet
MAC controllers and a single MDIO bus connected to multiple PHY devices.
MDIO lines are connected to any one of the ethernet MAC controllers and
all the PHY devices will be accessed using the PHY maintenance interface
in that MAC controller. This handling along with PHY functionality is
moved to macb_mdio.c
Signed-off-by: Punnaiah Choudary Kalluri <punnaia@xilinx.com>
Signed-off-by: Harini Katakam <harinik@xilinx.com>
---
drivers/net/ethernet/cadence/Makefile | 2 +-
drivers/net/ethernet/cadence/macb.c | 169 +++-----------------
drivers/net/ethernet/cadence/macb.h | 2 +
drivers/net/ethernet/cadence/macb_mdio.c | 266 +++++++++++++++++++++++++++++++
4 files changed, 294 insertions(+), 145 deletions(-)
create mode 100644 drivers/net/ethernet/cadence/macb_mdio.c
diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile
index 91f79b1..75c3d84 100644
--- a/drivers/net/ethernet/cadence/Makefile
+++ b/drivers/net/ethernet/cadence/Makefile
@@ -2,4 +2,4 @@
# Makefile for the Atmel network device drivers.
#
-obj-$(CONFIG_MACB) += macb.o
+obj-$(CONFIG_MACB) += macb.o macb_mdio.o
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 80ccfc4..ae2a797 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -232,45 +232,6 @@ static void macb_get_hwaddr(struct macb *bp)
eth_hw_addr_random(bp->dev);
}
-static int macb_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
-{
- struct macb *bp = bus->priv;
- int value;
-
- macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_SOF)
- | MACB_BF(RW, MACB_MAN_READ)
- | MACB_BF(PHYA, mii_id)
- | MACB_BF(REGA, regnum)
- | MACB_BF(CODE, MACB_MAN_CODE)));
-
- /* wait for end of transfer */
- while (!MACB_BFEXT(IDLE, macb_readl(bp, NSR)))
- cpu_relax();
-
- value = MACB_BFEXT(DATA, macb_readl(bp, MAN));
-
- return value;
-}
-
-static int macb_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
- u16 value)
-{
- struct macb *bp = bus->priv;
-
- macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_SOF)
- | MACB_BF(RW, MACB_MAN_WRITE)
- | MACB_BF(PHYA, mii_id)
- | MACB_BF(REGA, regnum)
- | MACB_BF(CODE, MACB_MAN_CODE)
- | MACB_BF(DATA, value)));
-
- /* wait for end of transfer */
- while (!MACB_BFEXT(IDLE, macb_readl(bp, NSR)))
- cpu_relax();
-
- return 0;
-}
-
/**
* macb_set_tx_clk() - Set a clock to a new frequency
* @clk Pointer to the clock to change
@@ -385,27 +346,19 @@ static void macb_handle_link_change(struct net_device *dev)
static int macb_mii_probe(struct net_device *dev)
{
struct macb *bp = netdev_priv(dev);
- struct macb_platform_data *pdata;
struct phy_device *phydev;
- int phy_irq;
int ret;
- phydev = phy_find_first(bp->mii_bus);
+ if (dev->phydev)
+ return 0;
+
+ phydev = of_phy_find_device(bp->phy_node);
if (!phydev) {
netdev_err(dev, "no PHY found\n");
return -ENXIO;
}
-
- pdata = dev_get_platdata(&bp->pdev->dev);
- if (pdata && gpio_is_valid(pdata->phy_irq_pin)) {
- ret = devm_gpio_request(&bp->pdev->dev, pdata->phy_irq_pin,
- "phy int");
- if (!ret) {
- phy_irq = gpio_to_irq(pdata->phy_irq_pin);
- phydev->irq = (phy_irq < 0) ? PHY_POLL : phy_irq;
- }
- }
-
+ if (bp->phy_irq)
+ phydev->irq = bp->phy_irq;
/* attach the mac to the phy */
ret = phy_connect_direct(dev, phydev, &macb_handle_link_change,
bp->phy_interface);
@@ -429,80 +382,9 @@ static int macb_mii_probe(struct net_device *dev)
bp->speed = 0;
bp->duplex = -1;
- return 0;
-}
-
-static int macb_mii_init(struct macb *bp)
-{
- struct macb_platform_data *pdata;
- struct device_node *np;
- int err = -ENXIO, i;
-
- /* Enable management port */
- macb_writel(bp, NCR, MACB_BIT(MPE));
-
- bp->mii_bus = mdiobus_alloc();
- if (!bp->mii_bus) {
- err = -ENOMEM;
- goto err_out;
- }
-
- bp->mii_bus->name = "MACB_mii_bus";
- bp->mii_bus->read = &macb_mdio_read;
- bp->mii_bus->write = &macb_mdio_write;
- snprintf(bp->mii_bus->id, MII_BUS_ID_SIZE, "%s-%x",
- bp->pdev->name, bp->pdev->id);
- bp->mii_bus->priv = bp;
- bp->mii_bus->parent = &bp->pdev->dev;
- pdata = dev_get_platdata(&bp->pdev->dev);
-
- dev_set_drvdata(&bp->dev->dev, bp->mii_bus);
-
- np = bp->pdev->dev.of_node;
- if (np) {
- /* try dt phy registration */
- err = of_mdiobus_register(bp->mii_bus, np);
-
- /* fallback to standard phy registration if no phy were
- * found during dt phy registration
- */
- if (!err && !phy_find_first(bp->mii_bus)) {
- for (i = 0; i < PHY_MAX_ADDR; i++) {
- struct phy_device *phydev;
-
- phydev = mdiobus_scan(bp->mii_bus, i);
- if (IS_ERR(phydev) &&
- PTR_ERR(phydev) != -ENODEV) {
- err = PTR_ERR(phydev);
- break;
- }
- }
-
- if (err)
- goto err_out_unregister_bus;
- }
- } else {
- if (pdata)
- bp->mii_bus->phy_mask = pdata->phy_mask;
-
- err = mdiobus_register(bp->mii_bus);
- }
-
- if (err)
- goto err_out_free_mdiobus;
-
- err = macb_mii_probe(bp->dev);
- if (err)
- goto err_out_unregister_bus;
+ phy_attached_info(phydev);
return 0;
-
-err_out_unregister_bus:
- mdiobus_unregister(bp->mii_bus);
-err_out_free_mdiobus:
- mdiobus_free(bp->mii_bus);
-err_out:
- return err;
}
static void macb_update_stats(struct macb *bp)
@@ -2060,7 +1942,8 @@ static int macb_open(struct net_device *dev)
netif_carrier_off(dev);
/* if the phy is not yet register, retry later*/
- if (!dev->phydev)
+ err = macb_mii_probe(dev);
+ if (err)
return -EAGAIN;
/* RX buffers initialization */
@@ -3122,16 +3005,16 @@ static int macb_probe(struct platform_device *pdev)
unsigned int queue_mask, num_queues;
struct macb_platform_data *pdata;
bool native_io;
- struct phy_device *phydev;
struct net_device *dev;
struct resource *regs;
void __iomem *mem;
const char *mac;
struct macb *bp;
+ int phy_irq;
int err;
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- mem = devm_ioremap_resource(&pdev->dev, regs);
+ mem = devm_ioremap(&pdev->dev, regs->start, resource_size(regs));
if (IS_ERR(mem))
return PTR_ERR(mem);
@@ -3250,21 +3133,26 @@ static int macb_probe(struct platform_device *pdev)
if (err)
goto err_out_free_netdev;
- err = macb_mii_init(bp);
- if (err)
- goto err_out_free_netdev;
-
- phydev = dev->phydev;
-
- netif_carrier_off(dev);
-
err = register_netdev(dev);
if (err) {
dev_err(&pdev->dev, "Cannot register net device, aborting.\n");
goto err_out_unregister_mdio;
}
- phy_attached_info(phydev);
+ bp->phy_node = of_parse_phandle(bp->pdev->dev.of_node,
+ "phy-handle", 0);
+
+ pdata = dev_get_platdata(&bp->pdev->dev);
+ if (pdata && gpio_is_valid(pdata->phy_irq_pin)) {
+ err = devm_gpio_request(&bp->pdev->dev, pdata->phy_irq_pin,
+ "phy int");
+ if (!err) {
+ phy_irq = gpio_to_irq(pdata->phy_irq_pin);
+ bp->phy_irq = (phy_irq < 0) ? PHY_POLL : phy_irq;
+ }
+ }
+
+ netif_carrier_off(dev);
netdev_info(dev, "Cadence %s rev 0x%08x at 0x%08lx irq %d (%pM)\n",
macb_is_gem(bp) ? "GEM" : "MACB", macb_readl(bp, MID),
@@ -3273,10 +3161,6 @@ static int macb_probe(struct platform_device *pdev)
return 0;
err_out_unregister_mdio:
- phy_disconnect(dev->phydev);
- mdiobus_unregister(bp->mii_bus);
- mdiobus_free(bp->mii_bus);
-
/* Shutdown the PHY if there is a GPIO reset */
if (bp->reset_gpio)
gpiod_set_value(bp->reset_gpio, 0);
@@ -3304,9 +3188,6 @@ static int macb_remove(struct platform_device *pdev)
bp = netdev_priv(dev);
if (dev->phydev)
phy_disconnect(dev->phydev);
- mdiobus_unregister(bp->mii_bus);
- dev->phydev = NULL;
- mdiobus_free(bp->mii_bus);
/* Shutdown the PHY if there is a GPIO reset */
if (bp->reset_gpio)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index d67adad..15e5c0f 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -874,6 +874,8 @@ struct macb {
unsigned int jumbo_max_len;
u32 wol;
+ struct device_node *phy_node;
+ int phy_irq;
};
static inline bool macb_is_gem(struct macb *bp)
diff --git a/drivers/net/ethernet/cadence/macb_mdio.c b/drivers/net/ethernet/cadence/macb_mdio.c
new file mode 100644
index 0000000..1277ca3
--- /dev/null
+++ b/drivers/net/ethernet/cadence/macb_mdio.c
@@ -0,0 +1,266 @@
+/*
+ * Cadence Macb mdio controller driver
+ *
+ * Copyright (C) 2014 - 2016 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/netdevice.h>
+#include <linux/of_address.h>
+#include <linux/of_mdio.h>
+#include <linux/io.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/ptp_clock_kernel.h>
+#include "macb.h"
+
+struct macb_mdio_data {
+ void __iomem *regs;
+
+ struct clk *pclk;
+ struct clk *hclk;
+};
+
+#define macb_mdio_reg_writel(bp, offset, value) \
+ writel_relaxed(value, bp->regs + offset)
+#define macb_mdio_writel(bp, reg, value) \
+ macb_mdio_reg_writel(bp, MACB_##reg, value)
+
+#define macb_mdio_reg_readl(bp, offset) readl_relaxed(bp->regs + offset)
+#define macb_mdio_readl(bp, reg) macb_mdio_reg_readl(bp, MACB_##reg)
+
+#define MACB_MDIO_TIMEOUT 1000
+
+static int macb_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
+{
+ struct macb_mdio_data *bp = bus->priv;
+ unsigned int timeout = MACB_MDIO_TIMEOUT;
+ int value;
+
+ macb_mdio_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_SOF) |
+ MACB_BF(RW, MACB_MAN_READ) |
+ MACB_BF(PHYA, mii_id) |
+ MACB_BF(REGA, regnum) |
+ MACB_BF(CODE, MACB_MAN_CODE)));
+
+ /* wait for end of transfer */
+ while (!MACB_BFEXT(IDLE, macb_mdio_readl(bp, NSR)) && timeout) {
+ cpu_relax();
+ timeout--;
+ }
+
+ if (!timeout)
+ return -ETIMEDOUT;
+
+ value = MACB_BFEXT(DATA, macb_mdio_readl(bp, MAN));
+
+ return value;
+}
+
+static int macb_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
+ u16 value)
+{
+ struct macb_mdio_data *bp = bus->priv;
+ unsigned int timeout = MACB_MDIO_TIMEOUT;
+
+ macb_mdio_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_SOF) |
+ MACB_BF(RW, MACB_MAN_WRITE) |
+ MACB_BF(PHYA, mii_id) |
+ MACB_BF(REGA, regnum) |
+ MACB_BF(CODE, MACB_MAN_CODE) |
+ MACB_BF(DATA, value)));
+
+ /* wait for end of transfer */
+ while (!MACB_BFEXT(IDLE, macb_mdio_readl(bp, NSR)) && timeout) {
+ cpu_relax();
+ timeout--;
+ }
+
+ if (!timeout)
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
+static u32 gem_mdc_clk_div(struct macb_mdio_data *bp)
+{
+ u32 config;
+ unsigned long pclk_hz = clk_get_rate(bp->pclk);
+
+ if (pclk_hz <= 20000000)
+ config = GEM_BF(CLK, GEM_CLK_DIV8);
+ else if (pclk_hz <= 40000000)
+ config = GEM_BF(CLK, GEM_CLK_DIV16);
+ else if (pclk_hz <= 80000000)
+ config = GEM_BF(CLK, GEM_CLK_DIV32);
+ else if (pclk_hz <= 120000000)
+ config = GEM_BF(CLK, GEM_CLK_DIV48);
+ else if (pclk_hz <= 160000000)
+ config = GEM_BF(CLK, GEM_CLK_DIV64);
+ else
+ config = GEM_BF(CLK, GEM_CLK_DIV96);
+
+ return config;
+}
+
+static int macb_mdio_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct mii_bus *bus;
+ struct macb_mdio_data *bp;
+ struct resource *res;
+ int ret;
+ u32 config, i;
+
+ bus = mdiobus_alloc_size(sizeof(*bp));
+ if (!bus)
+ return -ENOMEM;
+
+ bus->name = "macb_mii_bus";
+ bus->read = &macb_mdio_read;
+ bus->write = &macb_mdio_write;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%s-mii", dev_name(&pdev->dev));
+ bus->parent = &pdev->dev;
+ bus->irq = devm_kzalloc(&pdev->dev, sizeof(int) * PHY_MAX_ADDR,
+ GFP_KERNEL);
+ if (!bus->irq) {
+ ret = -ENOMEM;
+ goto err_out_free_mdiobus;
+ }
+
+ bp = bus->priv;
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ bp->regs = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+ if (IS_ERR(bp->regs)) {
+ ret = PTR_ERR(bp->regs);
+ goto err_out_free_mdiobus;
+ }
+
+ bp->pclk = devm_clk_get(&pdev->dev, "pclk");
+ if (IS_ERR(bp->pclk)) {
+ ret = PTR_ERR(bp->pclk);
+ dev_err(&pdev->dev, "failed to get macb_clk (%u)\n", ret);
+ goto err_out_free_mdiobus;
+ }
+
+ bp->hclk = devm_clk_get(&pdev->dev, "hclk");
+ if (IS_ERR(bp->hclk)) {
+ ret = PTR_ERR(bp->hclk);
+ dev_err(&pdev->dev, "failed to get hclk (%u)\n", ret);
+ goto err_out_free_mdiobus;
+ }
+
+ ret = clk_prepare_enable(bp->pclk);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to enable pclk (%u)\n", ret);
+ goto err_out_free_mdiobus;
+ }
+
+ ret = clk_prepare_enable(bp->hclk);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to enable hclk (%u)\n", ret);
+ goto err_disable_pclk;
+ }
+
+ platform_set_drvdata(pdev, bus);
+
+ /* Enable management port */
+ config = macb_mdio_readl(bp, NCR);
+ config |= MACB_BIT(MPE);
+ macb_mdio_writel(bp, NCR, config);
+ config = gem_mdc_clk_div(bp);
+ macb_mdio_writel(bp, NCFGR, config);
+
+ np = pdev->dev.of_node;
+ if (np) {
+ /* try dt phy registration */
+ ret = of_mdiobus_register(bus, np);
+
+ /* Fallback to standard phy registration if no phy were
+ * found during dt phy registration
+ */
+ if (!ret && !phy_find_first(bus)) {
+ for (i = 0; i < PHY_MAX_ADDR; i++) {
+ struct phy_device *phydev;
+
+ phydev = mdiobus_scan(bus, i);
+ if (IS_ERR(phydev) &&
+ PTR_ERR(phydev) != -ENODEV) {
+ ret = PTR_ERR(phydev);
+ break;
+ }
+ }
+
+ if (ret)
+ goto err_out_unregister_bus;
+ }
+ } else {
+ for (i = 0; i < PHY_MAX_ADDR; i++)
+ bus->irq[i] = PHY_POLL;
+
+ ret = of_mdiobus_register(bus, np);
+ }
+
+ if (ret)
+ goto err_out_free_mdio_irq;
+
+ return 0;
+
+err_out_unregister_bus:
+ mdiobus_unregister(bus);
+err_out_free_mdio_irq:
+ kfree(bus->irq);
+err_disable_pclk:
+ clk_disable_unprepare(bp->pclk);
+ clk_disable_unprepare(bp->hclk);
+err_out_free_mdiobus:
+ mdiobus_free(bus);
+ return ret;
+}
+
+static int macb_mdio_remove(struct platform_device *pdev)
+{
+ struct mii_bus *bus = platform_get_drvdata(pdev);
+ struct macb_mdio_data *bp = bus->priv;
+ u32 config;
+
+ /* Disable management port */
+ config = macb_mdio_readl(bp, NCR);
+ config &= ~MACB_BIT(MPE);
+ macb_mdio_writel(bp, NCR, config);
+ mdiobus_unregister(bus);
+ clk_disable_unprepare(bp->hclk);
+ clk_disable_unprepare(bp->pclk);
+ mdiobus_free(bus);
+
+ return 0;
+}
+
+static const struct of_device_id macb_mdio_dt_ids[] = {
+ { .compatible = "cdns,macb-mdio" },
+
+};
+MODULE_DEVICE_TABLE(of, macb_mdio_dt_ids);
+
+static struct platform_driver macb_mdio_driver = {
+ .probe = macb_mdio_probe,
+ .remove = macb_mdio_remove,
+ .driver = {
+ .name = "macb-mdio",
+ .of_match_table = macb_mdio_dt_ids,
+ },
+};
+
+module_platform_driver(macb_mdio_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Cadence MACB MDIO driver");
+MODULE_AUTHOR("Xilinx");
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 0/2] Multi phy management
From: Harini Katakam @ 2016-11-28 9:49 UTC (permalink / raw)
To: nicolas.ferre, davem, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, boris.brezillon, alexandre.belloni,
harinikatakamlinux
Cc: netdev, linux-kernel, devicetree, harinik, michals
This series is to add support for the hardware with multiple ethernet
MAC controllers and a single MDIO bus connected to multiple PHY devices.
MDIO lines are connected to any one of the ethernet MAC controllers and
all the PHY devices will be accessed using the PHY maintenance interface
in that MAC controller.
This handling along with PHY functionality is moved to macb_mdio.c
within the macb driver space.
This is because of the phy maintenance register is within the MAC.
Please advise on how to proceed with handling such a requirement.
Harini Katakam (2):
net: macb: Add MDIO driver for accessing multiple PHY devices
Documentation: devictree: Add macb mdio bindings
.../devicetree/bindings/net/macb-mdio.txt | 31 +++
drivers/net/ethernet/cadence/Makefile | 2 +-
drivers/net/ethernet/cadence/macb.c | 169 ++-----------
drivers/net/ethernet/cadence/macb.h | 2 +
drivers/net/ethernet/cadence/macb_mdio.c | 266 +++++++++++++++++++++
5 files changed, 325 insertions(+), 145 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/macb-mdio.txt
create mode 100644 drivers/net/ethernet/cadence/macb_mdio.c
--
2.7.4
^ permalink raw reply
* [PATCH net-next v3 4/4] ARM64: dts: meson: odroidc2: disable advertisement EEE for GbE.
From: Jerome Brunet @ 2016-11-28 9:46 UTC (permalink / raw)
To: netdev, devicetree, Florian Fainelli
Cc: Jerome Brunet, Carlo Caione, Kevin Hilman, Giuseppe Cavallaro,
Alexandre TORGUE, Martin Blumenstingl, Andre Roth, Andrew Lunn,
Neil Armstrong, linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <1480326409-25419-1-git-send-email-jbrunet@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index e6e3491d48a5..5624714d2b16 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -46,6 +46,7 @@
#include "meson-gxbb.dtsi"
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/net/mdio.h>
/ {
compatible = "hardkernel,odroid-c2", "amlogic,meson-gxbb";
@@ -98,3 +99,18 @@
pinctrl-0 = <&i2c_a_pins>;
pinctrl-names = "default";
};
+
+ðmac {
+ phy-handle = <ð_phy0>;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eth_phy0: ethernet-phy@0 {
+ reg = <0>;
+ eee-broken-modes = <MDIO_EEE_1000T>;
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
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