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 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.