linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ipaton0@gmail.com (Iain Paton)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/6] ARM: dts: microsom-ar8035: MDIO pad must be set open drain
Date: Tue, 26 Aug 2014 13:08:09 +0100	[thread overview]
Message-ID: <53FC78A9.2020907@gmail.com> (raw)
In-Reply-To: <20140824095854.GR30401@n2100.arm.linux.org.uk>

On 24/08/14 10:58, Russell King - ARM Linux wrote:
> On Sun, Aug 24, 2014 at 10:44:54AM +0100, Iain Paton wrote:
>> On 23/08/14 10:11, Russell King wrote:
>>> From: Rabeeh Khoury <rabeeh@solid-run.com>
>>> To: Shawn Guo <shawn.guo@freescale.com>
>>>
>>> MDIO pad must be set open drain.
>>>
>>> Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
>>> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>>> ---
>>>  arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi b/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
>>> index d16066608e21..db9f45b2c573 100644
>>> --- a/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
>>> +++ b/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
>>> @@ -17,7 +17,7 @@
>>>  	enet {
>>>  		pinctrl_microsom_enet_ar8035: microsom-enet-ar8035 {
>>>  			fsl,pins = <
>>> -				MX6QDL_PAD_ENET_MDIO__ENET_MDIO		0x1b0b0
>>> +				MX6QDL_PAD_ENET_MDIO__ENET_MDIO		0x1b8b0
>>>  				MX6QDL_PAD_ENET_MDC__ENET_MDC		0x1b0b0
>>>  				/* AR8035 reset */
>>>  				MX6QDL_PAD_KEY_ROW4__GPIO4_IO15		0x130b0
>>>
>>
>> Can you elaborate some more on the reasons for this?  
>>
>> I'd like to understand if it's something specific to the hardware on that 
>> board, or if other i.MX6 boards using the ar8035 are doing it wrong as well.
>>
>> The datasheet strongly suggests this is the correct thing to do as MDIO 
>> should electrically be open drain. However that suggests many more instances 
>> of this incorrect configuration exist which also need changed, and not just 
>> for ar8035.
>>
>> While I'm reluctant to attribute something like this to the fec/interrupt 
>> problems some people are seeing, I'd also like to be able to rule it out.
> 
> I'm merely passing the patch along; I've forwarded your question to
> Rabeeh via IRC, and may have an answer soon.
> 
> FYI, I've run for a long time (close to a year now) on various iMX6
> SolidRun platforms without the above patch and haven't seen a problem.
> I've now also running with it on Solo and Quad and haven't seen any
> ill effects there, despite the machines running root-NFS, doing
> regular compiles and git activity.

I've not seen any problems either.  Digging through IEEE 802.3 clause 22
only provides references to MDIO being implemented using a tri-state 
driver. Then in Clause 45 (10gig) there's a one liner saying it 'may' be 
implemented using open drain.

The i.MX6 manual specifically states support for Clause 22.

However, as 802.3 requires the pull-up be present, it seems unlikely there 
will be any practical difference between an implementation using open drain 
and tri-state signalling. Indeed, open drain would seem to be the logical
way to implement it electrically.

The AR8035 datasheet specifically marks MDIO and INT as being open drain,
however the KSZ9021 (as used on sabre-lite) datasheet doesn't, instead it 
marks them as Ipu/O (for Input with internal pull-up/Output).

I'd suggest that this is a question of correctness more than a practical 
problem and I have no objection to the patch being applied. 

  parent reply	other threads:[~2014-08-26 12:08 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-23  9:10 [PATCH 0/6] SolidRun Hummingboard/Cubox-i DT updates Russell King - ARM Linux
2014-08-23  9:11 ` [PATCH 1/6] ARM: dts: microsom-ar8035: MDIO pad must be set open drain Russell King
2014-08-24  9:44   ` Iain Paton
2014-08-24  9:58     ` Russell King - ARM Linux
2014-08-25  6:53       ` Eric Bénard
2014-08-26 12:08       ` Iain Paton [this message]
2014-08-26 10:15     ` Shawn Guo
2014-08-26 12:16       ` Iain Paton
2014-08-23  9:11 ` [PATCH 2/6] ARM: dts: hummingboard/cubox-i: add USB OC pinctrl configuration Russell King
2014-08-23  9:11 ` [PATCH 3/6] ARM: dts: hummingboard/cubox-i: change SPDIF output to be more descriptive Russell King
2014-08-23  9:11 ` [PATCH 4/6] ARM: dts: hummingboard: Split HummingBoard DT to support s/dl and d/q Russell King
2014-08-23  9:11 ` [PATCH 5/6] ARM: dts: hummingboard: add mSATA support for iMX6 quad/dual HummingBoard Russell King
2014-08-23  9:11 ` [PATCH 6/6] ARM: dts: hummingboard: gpio-ir on gpio 3,5 Russell King
2014-08-23 13:32   ` Fabio Estevam
2014-08-23 13:36     ` Russell King - ARM Linux
2014-08-23 13:56       ` Fabio Estevam
2014-08-23 14:33         ` Russell King - ARM Linux
2014-08-23 15:02           ` Fabio Estevam
2014-08-27 18:43             ` Russell King - ARM Linux
2014-08-28  8:42               ` Shawn Guo
2014-08-25  6:29 ` [PATCH 0/6] SolidRun Hummingboard/Cubox-i DT updates Shawn Guo
2014-08-25  9:51   ` Russell King - ARM Linux
2014-08-25 11:19     ` Shawn Guo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53FC78A9.2020907@gmail.com \
    --to=ipaton0@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).