linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] Does PHY UTMI data width belong to DWC2 or PHY binding?
Date: Tue, 22 Oct 2013 16:38:52 -0500	[thread overview]
Message-ID: <5266F06C.2080701@gmail.com> (raw)
In-Reply-To: <20131022112520.GE29341@beef>

On 10/22/2013 06:25 AM, Matt Porter wrote:
> On Tue, Oct 22, 2013 at 12:48:29PM +0200, Matthijs Kooijman wrote:
>> Hi Kishon,
>>
>> On Mon, Oct 21, 2013 at 02:57:26PM +0530, Kishon Vijay Abraham I wrote:
>>> I think it makes sense to keep the data width property in the dwc2 node itself.
>>> I mean it describes how the dwc2 IP is configured in that particular SoC (given
>>> that it can be either <8> or <16>).
>> If I'm reading the RT3052 datasheet correctly (GHWCFG4 register), the IP
>> can be configured for 8, 16 or 8 _and_ 16. In the latter case, the "8
>> and 16 supported" would make sense as a property of dwc2 (though this
>> value should be autodetectable through GHWCFG4), while the actual 8 or
>> 16 supported by the PHY would make sense as property of a phy.
> 
> There would be no value in adding a property for an already detectable
> value to dwc2's binding. To be honest, it's pretty much useless
> information due to the existence of the "8 and 16" option.
> 
>> Note sure if this is really useful in practice as well, or if just
>> setting the actual width to use on dwc2 makes more sense...
> 
> The GHWCFG4 information itself is not useful in practice, as described
> in the original thread: https://lkml.org/lkml/2013/10/10/477
> 
> It's certainly useful in practice to have this width property in either
> the dwc2 or the phy binding. One can make a case for either. As I
> mentioned in the original post, if we put it in the phy binding we'll be
> updating the generic phy binding. We'll then need an api added into the
> generic phy framework to fetch the width of a phy.
> 
> Both cases are doable and trivial, we just need the canonical decision
> from a DT maintainer as to where the property belongs. Given that they
> are in ARM ksummit, I'm not expecting to hear anything right this
> moment. :)

The host can support both, so it is not a property of the host and is a
property of the phy. It is no different than what mode a SPI slave
requires or whether an i2c slave supports 8 or 10-bit addressing. Those
examples are all 1 to many rather than 1 to 1 where it doesn't really
matter, but the same logic applies.

Rob

  reply	other threads:[~2013-10-22 21:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-18 14:12 [RFC] Does PHY UTMI data width belong to DWC2 or PHY binding? Matt Porter
2013-10-21  9:27 ` Kishon Vijay Abraham I
2013-10-22 10:48   ` Matthijs Kooijman
2013-10-22 11:25     ` Matt Porter
2013-10-22 21:38       ` Rob Herring [this message]
2013-10-23 14:42         ` Matt Porter
2013-10-23 18:11           ` Felipe Balbi
2013-10-23 20:07             ` Matt Porter
2013-10-23 21:29           ` Paul Zimmerman
2013-10-25 13:31             ` Matt Porter
2013-10-24  5:21           ` Kishon Vijay Abraham I
2013-10-25 13:33             ` Matt Porter

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=5266F06C.2080701@gmail.com \
    --to=robherring2@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).