From: Peng Fan <B51431@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3 1/3] usb:ehci-mx6 add board_usb_phy_mode function
Date: Fri, 7 Nov 2014 19:03:30 +0800 [thread overview]
Message-ID: <545CA702.6090301@freescale.com> (raw)
In-Reply-To: <201411070925.14856.marex@denx.de>
? 11/7/2014 4:25 PM, Marek Vasut ??:
> On Friday, November 07, 2014 at 02:08:12 AM, Peng Fan wrote:
>> Include a weak function board_usb_phy_mode.
>>
>> usb_phy_enable decide whether the controller in device mode or in host mode
>> by '*phy_ctrl & USBPHY_CTRL_OTG_ID'.
>>
>> There are two usb port on mx6sxsabresd and also mx6slevk.
>> 1. OTG port
>> 2. HOST port
>> There are connected to SOC USB controller OTG1 core and OTG2 core as
>> following: OTG1 core <----> board OTG port
>> OTG2 core <----> board HOST port
>
> This patch has nothing to do with any board, so this part should not
> be in the commit message.
>
>> However to these two board, no ID pin for the board host port. If only use
>> '*phy_ctrl & USBPHY_CTRL_OTG_ID' to decide the work mode, the host port
>> will not work, because "type = usb_phy_enable(index, ehci) ?
>> USB_INIT_DEVICE : USB_INIT_HOST;" will always set 'type' with
>> USB_INIT_DEVICE.
>>
>> So introduce this weak function to let board level code can decide to work
>> in host or device mode, if board level code want to implement this
>> function.
>>
>> Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
>> Signed-off-by: Ye Li <B37916@freescale.com>
>> ---
>>
>> Changes v3:
>> Take Marek's suggestions, replace 'return val & USBPHY_CTRL_OTG_ID' with
>> this new function like 'return board_usb_phy_mode(index);'
>> Here board_usb_phy_mode only has one parameter 'index' as board_ehci_power
>> and board_echi_hcd_init do.
>> "http://lists.denx.de/pipermail/u-boot/2014-November/194183.html" has
>> detailed discussion.
>>
>> Changes v2:
>> Introduce a new weak function to let board have a choice to decide which
>> mode to work at.
>>
>> drivers/usb/host/ehci-mx6.c | 16 +++++++++++++++-
>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
>> index 9ec5a0a..e2a247e 100644
>> --- a/drivers/usb/host/ehci-mx6.c
>> +++ b/drivers/usb/host/ehci-mx6.c
>> @@ -113,6 +113,20 @@ static void usb_power_config(int index)
>> pll_480_ctrl_set);
>> }
>>
>> +int __weak board_usb_phy_mode(int port)
>> +{
>> + void __iomem *phy_reg;
>> + void __iomem *phy_ctrl;
>> + u32 val;
>> +
>> + phy_reg = (void __iomem *)phy_bases[port];
>> + phy_ctrl = (void __iomem *)(phy_reg + USBPHY_CTRL);
>> +
>> + val = __raw_readl(phy_ctrl);
>> +
>> + return val & USBPHY_CTRL_OTG_ID;
>> +}
>> +
>> /* Return 0 : host node, <>0 : device mode */
>> static int usb_phy_enable(int index, struct usb_ehci *ehci)
>> {
>> @@ -160,7 +174,7 @@ static int usb_phy_enable(int index, struct usb_ehci
>> *ehci) val |= (USBPHY_CTRL_ENUTMILEVEL2 | USBPHY_CTRL_ENUTMILEVEL3);
>> __raw_writel(val, phy_ctrl);
>>
>> - return val & USBPHY_CTRL_OTG_ID;
>> + return board_usb_phy_mode(index);
>
> This should be called from ehci_hcd_init() right after usb_phy_enable().
> Afterall, the mode detection has nothing to do with the PHY enabling.
>
This back to what I did in patch v2. right after usb_phy_enable(), just
paste that piece of code here:
The weak function:
+int __weak board_ehci_usb_mode(int index, enum usb_init_type *type)
+{
+ return 0;
+}
+
type = usb_phy_enable(index, ehci) ? USB_INIT_DEVICE :
USB_INIT_HOST;
+ board_usb_phy_mode(index, &type);
+
What need to do is to let board can modify the `type` like following:
+int board_usb_phy_mode(int port, enum usb_init_type *type)
+{
+ if (port == 1)
+ /* port1 works in HOST Mode */
+ *type = USB_INIT_HOST;
+
+ return 0;
+}
+
This is the way that I did in patch v2. If this is fine, I'll resent
this patch set.
> btw. an idea for a separate patch(set) -- the PHY registers should be
> converted to struct-based access.
>
Yeah, struct based access PHY register should be done. After this board
level usb support patch is finished.
>> }
>>
>> /* Base address for this IP block is 0x02184800 */
Regards,
Peng.
next prev parent reply other threads:[~2014-11-07 11:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-07 1:08 [U-Boot] [PATCH v3 0/3] Add board level usb supporrt for mxsxsabresd and mx6slevk Peng Fan
2014-11-07 1:08 ` [U-Boot] [PATCH v3 1/3] usb:ehci-mx6 add board_usb_phy_mode function Peng Fan
2014-11-07 8:25 ` Marek Vasut
2014-11-07 11:03 ` Peng Fan [this message]
2014-11-07 11:09 ` Marek Vasut
2014-11-07 11:45 ` Peng Fan
2014-11-07 12:17 ` Marek Vasut
2014-11-08 4:07 ` Peng Fan
2014-11-08 4:35 ` Peng Fan
2014-11-08 11:33 ` Marek Vasut
2014-11-10 1:01 ` Peng Fan
2014-11-10 17:55 ` Marek Vasut
2014-11-07 1:08 ` [U-Boot] [PATCH v3 2/3] imx:mx6sxsabresd add board level support for usb Peng Fan
2014-11-07 1:08 ` [U-Boot] [PATCH v3 3/3] imx:mx6slevk " Peng Fan
2014-11-07 8:26 ` Marek Vasut
2014-11-07 11:08 ` Peng Fan
2014-11-07 11:10 ` Marek Vasut
2014-11-07 11:48 ` Peng Fan
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=545CA702.6090301@freescale.com \
--to=b51431@freescale.com \
--cc=u-boot@lists.denx.de \
/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