From: Roger Quadros <rogerq@ti.com>
To: <balbi@ti.com>
Cc: Vivek Gautam <gautamvivek1987@gmail.com>,
Kishon Vijay Abraham I <kishon@ti.com>, <bcousson@baylibre.com>,
<tony@atomide.com>, <rob.herring@calxeda.com>,
<pawel.moll@arm.com>, <mark.rutland@arm.com>,
<linux@arm.linux.org.uk>, <grant.likely@linaro.org>,
<s.nawrocki@samsung.com>, <galak@codeaurora.org>,
<swarren@wwwdotorg.org>, <ian.campbell@citrix.com>,
<rob@landley.net>, <george.cherian@ti.com>,
<gregkh@linuxfoundation.org>, <linux-doc@vger.kernel.org>,
<linux-omap@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-usb@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Date: Tue, 15 Oct 2013 17:03:50 +0300 [thread overview]
Message-ID: <525D4B46.4070302@ti.com> (raw)
In-Reply-To: <20131015135655.GK11380@radagast>
On 10/15/2013 04:56 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Oct 15, 2013 at 04:48:51PM +0300, Roger Quadros wrote:
>> On 10/15/2013 04:19 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Tue, Oct 15, 2013 at 03:10:42PM +0300, Roger Quadros wrote:
>>>>>>>>> @@ -665,6 +669,9 @@ struct dwc3 {
>>>>>>>>> struct usb_phy *usb2_phy;
>>>>>>>>> struct usb_phy *usb3_phy;
>>>>>>>>>
>>>>>>>>> + struct phy *usb2_generic_phy;
>>>>>>>>> + struct phy *usb3_generic_phy;
>>>>>>>>> +
>>>>>>>>> void __iomem *regs;
>>>>>>>>> size_t regs_size;
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> Do you have any suggestions on how to get only individual PHYs? like only
>>>>>>> usb2phy or usb3phy?
>>>>>>
>>>>>> My earlier understanding was that both PHYs are needed only if .speed is "super-speed"
>>>>>> and only usb2phy is needed for "high-speed". But as per Vivek's email it seems
>>>>>> Samsung's exynos5 SoC doesn't need usb2phy for "super-speed".
>>>>>>
>>>>>> So to keeps things flexible, I can propose the following approach
>>>>>> - if speed == 'high-speed' usb2phy must be present. usb3phy will be ignored if supplied.
>>>>>> - if speed == 'super-speed' usb3phy must be present and usb2phy is optional but must be
>>>>>> initialized if supplied.
>>>>>> - if speed is not specified, we default to 'super-speed'.
>>>>>>
>>>>>> Felipe, does this address the issue you were facing with OMAP5?
>>>>>
>>>>> on OMAP5 we cannot skip USB3 PHY initialization. But then it becomes a
>>>>> question of supporting a test feature (in OMAP5 case it would be cool to
>>>>> force controller to lower speeds for testing) or coping with a broken
>>>>> DTS.
>>>>>
>>>>
>>>> I don't think we can protect ourselves from all possible broken
>>>> configurations of DTS.
>>>> I would vote for simplicity and maximum flexibility.
>>>>
>>>> So IMO we should just depend on DTS to provide the phys that are
>>>> needed by the platform.
>>>> In the driver we initialize whatever PHY is provided and don't
>>>> complain if any or even all PHYs are missing.
>>>
>>> considering that DTS is an ABI, I really think eventually we *will* have
>>> broken DTBs burned into ROM and we will have to find ways to work with
>>> those too. Same thing already happens today with ACPI tables.
>>>
>>>> If this is not good enough then could you please suggest an
>>>> alternative? Thanks.
>>>
>>> The alternative would be to mandate nop xceiv for the "missing" PHY, but
>>> that doesn't solve anything, really, as DTS authors might still forget
>>> about the NOP xceiv and you can argue that forcing NOP xceiv would be a
>>> SW configuration.
>>>
>>> So, perhaps we go with the approach that all PHYs are optional, and
>>> here's my original patch which makes USB3 PHY optional:
>>>
>>> commit 979b84f96e4b7559b596b2933ae198aba267f260
>>> Author: Felipe Balbi <balbi@ti.com>
>>> Date: Sun Jun 30 18:39:23 2013 +0300
>>>
>>> usb: dwc3: core: make USB3 PHY optional
>>>
>>> If we want a port to work at any speed lower
>>> than Superspeed, it makes no sense to even
>>> initialize/power up the USB3 transceiver,
>>> provided it won't be used.
>>>
>>> We can use the oportunity to save some power
>>> and leave the superspeed transceiver powered
>>> off.
>>>
>>> There is at least one such case which is
>>> Texas Instruments' AM437x which has one
>>> of its USB3 ports without a matching USB3
>>> PHY (that port is hardwired to work on USB2
>>> only).
>>>
>>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>>>
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>> index 74f9cf0..7a5ab93 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -387,16 +387,34 @@ static int dwc3_probe(struct platform_device *pdev)
>>> if (node) {
>>> dwc->maximum_speed = of_usb_get_maximum_speed(node);
>>>
>>> - dwc->usb2_phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 0);
>>> - dwc->usb3_phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 1);
>>> + switch (dwc->maximum_speed) {
>>> + case USB_SPEED_SUPER:
>>> + dwc->usb2_phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 0);
>>> + dwc->usb3_phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 1);
>>> + break;
>>> + case USB_SPEED_HIGH:
>>> + case USB_SPEED_FULL:
>>> + case USB_SPEED_LOW:
>>> + dwc->usb2_phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 0);
>>> + break;
>>> + }
>>>
>>> dwc->needs_fifo_resize = of_property_read_bool(node, "tx-fifo-resize");
>>> dwc->dr_mode = of_usb_get_dr_mode(node);
>>> } else if (pdata) {
>>> dwc->maximum_speed = pdata->maximum_speed;
>>>
>>> - dwc->usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
>>> - dwc->usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
>>> + switch (dwc->maximum_speed) {
>>> + case USB_SPEED_SUPER:
>>> + dwc->usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
>>> + dwc->usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
>>> + break;
>>> + case USB_SPEED_HIGH:
>>> + case USB_SPEED_FULL:
>>> + case USB_SPEED_LOW:
>>> + dwc->usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
>>> + break;
>>> + }
>>
>> What if we try to get both PHYs irrespective of 'maximum_speed' but based
>> on presence of phandle/pdata. That way there is some control in the adaptation code (dts/pdata)
>> as to which PHYs needs to be initialized for that particular instance.
>>
>> This is because there doesn't seem to be a consensus between different designs.
>> e.g. omap5 needs both phys for 'high-speed' whereas exynos5250 needs just the
>> usb3 phy for 'super-speed'
>
> sure, can you write such a patch ? If it gets to my inbox in a couple
> hours I guess I can still review and take it upstream on v3.13,
> otherwise it's only on v3.14 :-(
As this patch from Kishon is already touching this area, it would be best if
he can send a v2 with this feature.
cheers,
-roger
next prev parent reply other threads:[~2013-10-15 14:04 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-02 15:43 [PATCH 0/7] Make dwc3 use Generic PHY Framework and misc cleanup Kishon Vijay Abraham I
2013-09-02 15:43 ` [PATCH 1/7] usb: dwc3: get "usb_phy" only if the platform indicates the presence of PHY Kishon Vijay Abraham I
2013-09-12 10:36 ` Roger Quadros
2013-09-12 10:47 ` Vivek Gautam
2013-09-12 11:04 ` Roger Quadros
2013-09-12 11:26 ` Vivek Gautam
2013-09-12 13:11 ` Roger Quadros
2013-09-16 8:40 ` Vivek Gautam
2013-09-17 15:45 ` Felipe Balbi
2013-09-02 15:43 ` [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework Kishon Vijay Abraham I
2013-09-12 9:27 ` Vivek Gautam
2013-09-12 10:10 ` Kishon Vijay Abraham I
2013-09-12 10:27 ` Vivek Gautam
2013-10-10 10:28 ` Kishon Vijay Abraham I
2013-09-12 13:19 ` Roger Quadros
2013-09-16 2:52 ` Kishon Vijay Abraham I
2013-09-16 7:25 ` Roger Quadros
2013-10-11 15:09 ` Roger Quadros
2013-10-14 9:26 ` Kishon Vijay Abraham I
2013-10-14 10:21 ` Roger Quadros
2013-10-15 5:31 ` Kishon Vijay Abraham I
2013-10-15 7:57 ` Roger Quadros
2013-10-15 12:00 ` Felipe Balbi
2013-10-15 11:58 ` Felipe Balbi
2013-10-15 11:57 ` Felipe Balbi
2013-10-15 12:10 ` Roger Quadros
2013-10-15 13:19 ` Felipe Balbi
2013-10-15 13:48 ` Roger Quadros
2013-10-15 13:56 ` Felipe Balbi
2013-10-15 14:03 ` Roger Quadros [this message]
2013-10-15 14:12 ` Felipe Balbi
2013-09-02 15:43 ` [PATCH 3/7] drivers: phy: usb3/pipe3: Adapt pipe3 driver to " Kishon Vijay Abraham I
2013-09-12 11:19 ` Roger Quadros
2013-09-16 3:01 ` Kishon Vijay Abraham I
2013-09-16 7:37 ` Roger Quadros
2013-10-11 15:02 ` Roger Quadros
2013-10-14 9:19 ` Kishon Vijay Abraham I
2013-10-14 9:31 ` Roger Quadros
2013-09-02 15:43 ` [PATCH 4/7] Documentation: dt bindings: move ..usb/usb-phy.txt to ..phy/omap-phy.txt Kishon Vijay Abraham I
2013-09-12 13:23 ` Roger Quadros
2013-09-16 3:04 ` Kishon Vijay Abraham I
2013-09-02 15:43 ` [PATCH 5/7] phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/ Kishon Vijay Abraham I
2013-09-02 15:43 ` [PATCH 6/7] arm/dts: added dt properties to adapt to the new phy framwork Kishon Vijay Abraham I
2013-09-12 13:28 ` Roger Quadros
2013-09-02 15:43 ` [PATCH 7/7] drivers: phy: renamed struct omap_control_usb to struct omap_control_phy Kishon Vijay Abraham I
2013-09-12 13:42 ` Roger Quadros
2013-09-16 3:06 ` Kishon Vijay Abraham I
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=525D4B46.4070302@ti.com \
--to=rogerq@ti.com \
--cc=balbi@ti.com \
--cc=bcousson@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=gautamvivek1987@gmail.com \
--cc=george.cherian@ti.com \
--cc=grant.likely@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=ian.campbell@citrix.com \
--cc=kishon@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=rob.herring@calxeda.com \
--cc=rob@landley.net \
--cc=s.nawrocki@samsung.com \
--cc=swarren@wwwdotorg.org \
--cc=tony@atomide.com \
/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).