From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 1/3] usb:ehci-mx6 add board_ehci_usb_mode function
Date: Wed, 5 Nov 2014 10:03:42 +0100 [thread overview]
Message-ID: <201411051003.42245.marex@denx.de> (raw)
In-Reply-To: <5459BD00.1060006@freescale.com>
On Wednesday, November 05, 2014 at 07:00:32 AM, Peng Fan wrote:
> ? 11/5/2014 1:33 AM, Marek Vasut ??:
> > On Tuesday, November 04, 2014 at 02:29:56 PM, Peng Fan wrote:
> >> Hi Marek,
> >>
> >> ? 11/4/2014 7:01 PM, Marek Vasut ??:
> >>> On Tuesday, November 04, 2014 at 11:50:29 AM, Peng Fan wrote:
> >>>> ? 11/4/2014 6:33 PM, Marek Vasut ??:
> >>>>> On Tuesday, November 04, 2014 at 08:50:00 AM, Peng Fan wrote:
> >>>>>> Include a weak function board_ehci_usb_mode to gives board code
> >>>>>> a choice.
> >>>>>
> >>>>> What choice?
> >>>>>
> >>>>>> If the board want the otg port work in host mode but not
> >>>>>> device mode, this should be handled.
> >>>>>
> >>>>> How?
> >>>>>
> >>>>> Also, isn't usb_phy_enable() supposed to do exactly this kind of
> >>>>> selection between device and host mode ?
> >>>>
> >>>> In mx6sxsabresd board, there are two usb port, one used for otg, the
> >>>> other used for host. However they are connected to SOC USB controller
> >>>> otg1 core and otg2 core respectively. Like following:
> >>>>
> >>>> OTG1 CORE <----> board otg port
> >>>> OTG2 CORE <----> board host port
> >>>>
> >>>> However the board do not have ID pin set for board host port. If just
> >>>> use usb_phy_enable, the board 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.
> >>>>
> >>>> Because i did not find way to handle this situation in
> >>>> board/freescale/mx6sxsabresd/mx6sxsabresd.c, add this function to let
> >>>> board level code handle handle 'type', if board level code want to set
> >>>> it's own 'type'.
> >>>
> >>> This part in usb_phy_enable()
> >>>
> >>> 163 return val & USBPHY_CTRL_OTG_ID;
> >>>
> >>> should be replaced by some kind of a board-specific callback then, with
> >>> default implmentation being the above (reading the phy ctrl register).
> >>
> >> How about using the following piece of code?
> >> in ehci-mx6.c
> >>
> >> unsigned int __weak board_usb_phy_mode(int index, unsigned int val)
> >> {
> >>
> >> return val & USBPHY_CTRL_OTG_ID;
> >>
> >> }
> >>
> >> replace "return val & USBPHY_CTRL_OTG_ID;" using "
> >> return board_usb_phy_mode(index, val);"
> >>
> >> In board file,
> >> unsigned int board_usb_phy_mode(int index, unsigned int val)
> >
> > Why not pass in full struct usb_ehci * instead ? Passing some ad-hoc $val
> > into the function doesn't seem like a scalable future-proof solution.
> > [...]
>
> Passing struct usb_ehci * to board code seems exports ehci register
> definition to board layer.
Yeah.
> How about just use
> "int board_usb_phy_mode(int index)" without using 'val' or 'struct
> usb_ehci *ehci'.
The board part might need to read the EHCI registers though. How would the
board part be able to do it if you didn't pass the *ehci in ?
next prev parent reply other threads:[~2014-11-05 9:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-04 7:49 [U-Boot] [PATCH v2 0/3] imx:mx6 add usb support Peng Fan
2014-11-04 7:50 ` [U-Boot] [PATCH v2 1/3] usb:ehci-mx6 add board_ehci_usb_mode function Peng Fan
2014-11-04 10:33 ` Marek Vasut
2014-11-04 10:50 ` Peng Fan
2014-11-04 11:01 ` Marek Vasut
2014-11-04 13:29 ` Peng Fan
2014-11-04 17:33 ` Marek Vasut
2014-11-05 6:00 ` Peng Fan
2014-11-05 9:03 ` Marek Vasut [this message]
2014-11-05 9:18 ` Peng Fan
2014-11-06 20:20 ` Marek Vasut
2014-11-07 1:10 ` Peng Fan
2014-11-07 8:26 ` Marek Vasut
2014-11-04 11:40 ` Jeroen Hofstee
2014-11-04 13:36 ` Peng Fan
2014-11-04 19:39 ` Jeroen Hofstee
2014-11-04 7:50 ` [U-Boot] [PATCH v2 2/3] imx:mx6sxsabresd add usb support Peng Fan
2014-11-04 7:50 ` [U-Boot] [PATCH v2 3/3] imx:mx6slevk " Peng Fan
2014-11-04 10:31 ` [U-Boot] [PATCH v2 0/3] imx:mx6 " Marek Vasut
2014-11-04 12:05 ` Peng Fan
2014-11-04 12:08 ` Marek Vasut
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=201411051003.42245.marex@denx.de \
--to=marex@denx.de \
--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.