From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/4] usb: chipidea: ci13xxx-imx: add "dr_mode" property to device tree bindings
Date: Mon, 02 Jul 2012 14:04:12 -0600 [thread overview]
Message-ID: <4FF1FEBC.3040107@wwwdotorg.org> (raw)
In-Reply-To: <20120630011906.GA2489@richard-laptop>
On 06/29/2012 07:19 PM, Richard Zhao wrote:
> On Fri, Jun 29, 2012 at 09:51:49AM -0600, Stephen Warren wrote:
>> On 06/29/2012 02:45 AM, Richard Zhao wrote:
>>> On Fri, Jun 29, 2012 at 09:47:03AM +0200, Marc Kleine-Budde wrote:
>>>>
>>>> Cc'ed Devicetree Discussions
>>>>
>>>> On 06/29/2012 03:43 AM, Richard Zhao wrote:
>>>>> On Thu, Jun 28, 2012 at 03:53:48PM +0200, Marc Kleine-Budde wrote:
>>>>>> This patch allows the device tree to limit the chipidea to host or
>>>>>> peripheral mode only.
>>>>>>
>>>>>> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
>>>>>> ---
>>>>>> .../devicetree/bindings/usb/ci13xxx-imx.txt | 3 ++
>>>>>> drivers/usb/chipidea/ci13xxx_imx.c | 3 ++
>>>>>> drivers/usb/chipidea/core.c | 41 +++++++++++++++++---
>>>>>> include/linux/usb/chipidea.h | 9 +++++
>>>>>> 4 files changed, 50 insertions(+), 6 deletions(-)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
>>>>>> index 5a0ad66..67f97f56 100644
>>>>>> --- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
>>>>>> +++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
>>>>>> @@ -4,6 +4,8 @@ Required properties:
>>>>>> - compatible: Should be "fsl,imx27-usb"
>>>>>> - reg: Should contain registers location and length
>>>>>> - interrupts: Should contain controller interrupt
>>>>>> +- dr_mode: indicates the working mode for compatible controllers. Can
>>>>>> + be "host", "peripheral", or "otg". Defaults to "otg" if not defined.
>>>>
>>>>> By default, it should be decided by capability registers. Only bad hw
>>>>> design needs such settings. So, why not name it as force-xxx? If it's
>>>>> not specific to imx, it doesn't needs to has prefix "fsl,".
>>>>
>>>> It's not a bad hardware design if you don't route or enable all ports a
>>>> soc offers. In modern socs you cannot enable all ports anyway.
>>>
>>> I'm not sure about your case, but generally, it's not about ports.
>>> It's about ID pin. If ID pin is not connect correctly, we may need to
>>> force it to host or device working mode. The 'force" here means it
>>> won't follow the capability registers and ID pin.
>>>>
>>>> The property isn't prefixed with "fsl,", it's just "dr_mode".
>>>>
>>>> Why not "force-xxx"? I had a look at Documentation/devicetree/bindings/usb:
>>>>
>>>> tegra-usb.txt:
>>>>> - dr_mode : dual role mode. Indicates the working mode for
>>>>> nvidia,tegra20-ehci compatible controllers. Can be "host", "peripheral",
>>>>> or "otg". Default to "host" if not defined for backward compatibility.
>>>>> host means this is a host controller
>>>>> peripheral means it is device controller
>>>>> otg means it can operate as either ("on the go")
>>>>
>>>> fsl-usb.txt:
>>>>> - dr_mode : indicates the working mode for "fsl-usb2-dr" compatible
>>>>> controllers. Can be "host", "peripheral", or "otg". Default to
>>>>> "host" if not defined for backward compatibility.
>>>>>
>>>>
>>>> So why invent something new, if there seems to be a pattern?
>>>
>>> I'm not sure they mean the same things, because the default value is
>>> different. Event if they're same, why not make them all with sensible
>>> name?
>>
>> I'm not quite sure what the question is I'm being asked here.
>>
>> I certainly think that new bindings should follow existing precedent
>> where possible for representing the same data. dr_mode is that precedent
>> for a USB host's operating mode. Tegra chose to use that because of
>> precedent in fsl-usb.txt IIRC.
>
> For imx, in most cases, we don't use dr_mode. The role is decided by
> CAP_DCCPARAMS and ID pin. For tegra and fsl-usb, it looks like the role
> is totally decided by dt property. So I suggested use force-xxx to let
> everyone know it does not follow the default action. I don't quite
> insist on the naming, because dr_mode is similar (not same).
Hmm. I think it'd be reasonable to use dr_mode like the other bindings,
and have the default case be decided by the ID pin when dr_mode isn't
specified. Having different defaults for different bindings seems pretty
reasonable to me.
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Richard Zhao <linuxzsc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Richard Zhao
<richard.zhao-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org,
swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
alexander.shishkin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
Devicetree Discussions
<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v2 3/4] usb: chipidea: ci13xxx-imx: add "dr_mode" property to device tree bindings
Date: Mon, 02 Jul 2012 14:04:12 -0600 [thread overview]
Message-ID: <4FF1FEBC.3040107@wwwdotorg.org> (raw)
In-Reply-To: <20120630011906.GA2489@richard-laptop>
On 06/29/2012 07:19 PM, Richard Zhao wrote:
> On Fri, Jun 29, 2012 at 09:51:49AM -0600, Stephen Warren wrote:
>> On 06/29/2012 02:45 AM, Richard Zhao wrote:
>>> On Fri, Jun 29, 2012 at 09:47:03AM +0200, Marc Kleine-Budde wrote:
>>>>
>>>> Cc'ed Devicetree Discussions
>>>>
>>>> On 06/29/2012 03:43 AM, Richard Zhao wrote:
>>>>> On Thu, Jun 28, 2012 at 03:53:48PM +0200, Marc Kleine-Budde wrote:
>>>>>> This patch allows the device tree to limit the chipidea to host or
>>>>>> peripheral mode only.
>>>>>>
>>>>>> Signed-off-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>>>>> ---
>>>>>> .../devicetree/bindings/usb/ci13xxx-imx.txt | 3 ++
>>>>>> drivers/usb/chipidea/ci13xxx_imx.c | 3 ++
>>>>>> drivers/usb/chipidea/core.c | 41 +++++++++++++++++---
>>>>>> include/linux/usb/chipidea.h | 9 +++++
>>>>>> 4 files changed, 50 insertions(+), 6 deletions(-)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
>>>>>> index 5a0ad66..67f97f56 100644
>>>>>> --- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
>>>>>> +++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
>>>>>> @@ -4,6 +4,8 @@ Required properties:
>>>>>> - compatible: Should be "fsl,imx27-usb"
>>>>>> - reg: Should contain registers location and length
>>>>>> - interrupts: Should contain controller interrupt
>>>>>> +- dr_mode: indicates the working mode for compatible controllers. Can
>>>>>> + be "host", "peripheral", or "otg". Defaults to "otg" if not defined.
>>>>
>>>>> By default, it should be decided by capability registers. Only bad hw
>>>>> design needs such settings. So, why not name it as force-xxx? If it's
>>>>> not specific to imx, it doesn't needs to has prefix "fsl,".
>>>>
>>>> It's not a bad hardware design if you don't route or enable all ports a
>>>> soc offers. In modern socs you cannot enable all ports anyway.
>>>
>>> I'm not sure about your case, but generally, it's not about ports.
>>> It's about ID pin. If ID pin is not connect correctly, we may need to
>>> force it to host or device working mode. The 'force" here means it
>>> won't follow the capability registers and ID pin.
>>>>
>>>> The property isn't prefixed with "fsl,", it's just "dr_mode".
>>>>
>>>> Why not "force-xxx"? I had a look at Documentation/devicetree/bindings/usb:
>>>>
>>>> tegra-usb.txt:
>>>>> - dr_mode : dual role mode. Indicates the working mode for
>>>>> nvidia,tegra20-ehci compatible controllers. Can be "host", "peripheral",
>>>>> or "otg". Default to "host" if not defined for backward compatibility.
>>>>> host means this is a host controller
>>>>> peripheral means it is device controller
>>>>> otg means it can operate as either ("on the go")
>>>>
>>>> fsl-usb.txt:
>>>>> - dr_mode : indicates the working mode for "fsl-usb2-dr" compatible
>>>>> controllers. Can be "host", "peripheral", or "otg". Default to
>>>>> "host" if not defined for backward compatibility.
>>>>>
>>>>
>>>> So why invent something new, if there seems to be a pattern?
>>>
>>> I'm not sure they mean the same things, because the default value is
>>> different. Event if they're same, why not make them all with sensible
>>> name?
>>
>> I'm not quite sure what the question is I'm being asked here.
>>
>> I certainly think that new bindings should follow existing precedent
>> where possible for representing the same data. dr_mode is that precedent
>> for a USB host's operating mode. Tegra chose to use that because of
>> precedent in fsl-usb.txt IIRC.
>
> For imx, in most cases, we don't use dr_mode. The role is decided by
> CAP_DCCPARAMS and ID pin. For tegra and fsl-usb, it looks like the role
> is totally decided by dt property. So I suggested use force-xxx to let
> everyone know it does not follow the default action. I don't quite
> insist on the naming, because dr_mode is similar (not same).
Hmm. I think it'd be reasonable to use dr_mode like the other bindings,
and have the default case be decided by the ID pin when dr_mode isn't
specified. Having different defaults for different bindings seems pretty
reasonable to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-07-02 20:04 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-28 13:53 [PATCH v2 0/4] usb: chipidea: fix error handling and add dr_role property Marc Kleine-Budde
2012-06-28 13:53 ` [PATCH v2 1/4] usb: chipidea: pci: make platformdata static Marc Kleine-Budde
2012-06-28 14:06 ` Richard Zhao
2012-07-08 15:10 ` Richard Zhao
2012-07-08 17:48 ` Russell King - ARM Linux
2012-07-09 1:20 ` Richard Zhao
2012-06-28 13:53 ` [PATCH v2 2/4] usb: chipidea: udc: fix error path in udc_start() Marc Kleine-Budde
2012-06-28 13:53 ` [PATCH v2 3/4] usb: chipidea: ci13xxx-imx: add "dr_mode" property to device tree bindings Marc Kleine-Budde
2012-06-29 1:43 ` Richard Zhao
2012-06-29 7:47 ` Marc Kleine-Budde
2012-06-29 7:47 ` Marc Kleine-Budde
2012-06-29 8:45 ` Richard Zhao
2012-06-29 8:45 ` Richard Zhao
2012-06-29 9:29 ` Marc Kleine-Budde
2012-06-29 9:29 ` Marc Kleine-Budde
2012-06-30 1:40 ` Richard Zhao
2012-06-30 1:40 ` Richard Zhao
2012-06-29 15:51 ` Stephen Warren
2012-06-29 15:51 ` Stephen Warren
2012-06-30 1:19 ` Richard Zhao
2012-06-30 1:19 ` Richard Zhao
2012-07-02 20:04 ` Stephen Warren [this message]
2012-07-02 20:04 ` Stephen Warren
2012-07-03 2:22 ` Peter Chen
2012-07-03 2:22 ` Peter Chen
2012-07-03 3:00 ` Richard Zhao
2012-07-03 3:00 ` Richard Zhao
2012-07-03 7:02 ` Lothar Waßmann
2012-07-03 7:02 ` Lothar Waßmann
2012-07-03 7:10 ` Richard Zhao
2012-07-03 7:10 ` Richard Zhao
2012-06-30 1:33 ` Richard Zhao
2012-06-30 1:33 ` Richard Zhao
2012-06-30 21:57 ` Sergei Shtylyov
2012-06-28 13:53 ` [PATCH v2 4/4] ARM: dts: imx23,28: limit usb to host role Marc Kleine-Budde
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=4FF1FEBC.3040107@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.