imx:mx6 add usb support

PATCH Superseded Peng Fan 4 participants 21 messages Nov 4, 2014 – Nov 7, 2014

Subsystems (3)

Arm (32-bit) USB USB ehci driver

lore

Share & tools

lore

Peng Fan

author

2014-11-04 07:49 UTC #0 lore raw

v2 cover imx:mx6 add usb support

Changes v2:
- move pinmux setting into board_init
- add otg polarity setting in board_ehci_hcd_init
- Introduce a new weak function to give board a choice to decide the work mode of the otg port, since a otg port can also work in host mode without touch ID pin.

Peng Fan (3):
usb:ehci-mx6 add board_ehci_usb_mode function
imx:mx6sxsabresd add usb support
imx:mx6slevk add usb support

 arch/arm/include/asm/arch-mx6/mx6sl_pins.h  |  5 +++
 board/freescale/mx6slevk/mx6slevk.c         | 51 +++++++++++++++++++++++++++++
 board/freescale/mx6sxsabresd/mx6sxsabresd.c | 51 +++++++++++++++++++++++++++++
 drivers/usb/host/ehci-mx6.c                 |  7 ++++
 include/configs/mx6slevk.h                  | 14 ++++++++
 include/configs/mx6sxsabresd.h              | 14 ++++++++
 6 files changed, 142 insertions(+)

Signature · 1 line

1.8.4.5

Peng Fan

author

2014-11-04 07:50 UTC #1 lore raw

PATCH v2 1/3 usb:ehci-mx6 add board_ehci_usb_mode function

Include a weak function board_ehci_usb_mode to gives board code a choice. If the board want the otg port work in host mode but not device mode, this should be handled.

Signed-off-by Peng Fan <[email protected]>

Signed-off-by Ye Li <[email protected]>

---

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 | 7 +++++++
 1 file changed, 7 insertions(+)

drivers/usb/host/ehci-mx6.c +7 -0

index 9ec5a0a..3662a80 100644
@@ -193,6 +193,11 @@ static void usb_oc_config(int index)
 	__raw_writel(val, ctrl);
 }
 
+int __weak board_ehci_usb_mode(int index, enum usb_init_type *type)
+{
+	return 0;
+}
+
 int __weak board_ehci_hcd_init(int port)
 {
 	return 0;

@@ -223,6 +228,8 @@ int ehci_hcd_init(int index, enum usb_init_type init,
 	usb_internal_phy_clock_gate(index, 1);
 	type = usb_phy_enable(index, ehci) ? USB_INIT_DEVICE : USB_INIT_HOST;
 
+	board_ehci_usb_mode(index, &type);
+
 	*hccr = (struct ehci_hccr *)((uint32_t)&ehci->caplength);
 	*hcor = (struct ehci_hcor *)((uint32_t)*hccr +
 			HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));

Signature · 1 line

1.8.4.5

Marek Vasut

2014-11-04 10:33 UTC #2 lore raw

PATCH v2 1/3 usb:ehci-mx6 add board_ehci_usb_mode function

Quoted 2 lines · Peng Fan

Include a weak function board_ehci_usb_mode to gives board code a choice.

What choice?

Quoted 2 lines

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 ?

Quoted 28 lines

Signed-off-by Peng Fan <[email protected]>
Signed-off-by Ye Li <[email protected]>
---
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 | 7 +++++++
 1 file changed, 7 insertions(+)
drivers/usb/host/ehci-mx6.c +5 -0
index 9ec5a0a..3662a80 100644
@@ -193,6 +193,11 @@ static void usb_oc_config(int index)
 	__raw_writel(val, ctrl);
 }
 
+int __weak board_ehci_usb_mode(int index, enum usb_init_type *type)
+{
+	return 0;
+}
+
 int __weak board_ehci_hcd_init(int port)
 {
 	return 0;

drivers/usb/host/ehci-mx6.c int ehci_hcd_init(int index, enum usb_init_type init, · line 235

Quoted 8 lines

drivers/usb/host/ehci-mx6.c +2 -0

@@ -223,6 +228,8 @@ int ehci_hcd_init(int index, enum usb_init_type init,
 	usb_internal_phy_clock_gate(index, 1);
 	type = usb_phy_enable(index, ehci) ? USB_INIT_DEVICE : USB_INIT_HOST;
 
+	board_ehci_usb_mode(index, &type);
+
 	*hccr = (struct ehci_hccr *)((uint32_t)&ehci->caplength);
 	*hcor = (struct ehci_hcor *)((uint32_t)*hccr +
 			HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));

Best regards,
Marek Vasut

Peng Fan

2014-11-04 10:50 UTC #3 lore raw

PATCH v2 1/3 usb:ehci-mx6 add board_ehci_usb_mode function

? 11/4/2014 6:33 PM, Marek Vasut ??:

Quoted 6 lines · Peng Fan

Quoted 2 lines
Include a weak function board_ehci_usb_mode to gives board code a choice.
What choice?

Quoted 7 lines

Quoted 2 lines
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'.

Quoted 32 lines

Signed-off-by Peng Fan <[email protected]>

Signed-off-by Ye Li <[email protected]>

---

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 | 7 +++++++
  1 file changed, 7 insertions(+)

drivers/usb/host/ehci-mx6.c +5 -0

index 9ec5a0a..3662a80 100644
@@ -193,6 +193,11 @@ static void usb_oc_config(int index)
  	__raw_writel(val, ctrl);
  }
 
+int __weak board_ehci_usb_mode(int index, enum usb_init_type *type)
+{
+	return 0;
+}
+
  int __weak board_ehci_hcd_init(int port)
  {
  	return 0;

@@ -223,6 +228,8 @@ int ehci_hcd_init(int index, enum usb_init_type init,
  	usb_internal_phy_clock_gate(index, 1);
  	type = usb_phy_enable(index, ehci) ? USB_INIT_DEVICE : USB_INIT_HOST;

Quoted 9 lines

drivers/usb/host/ehci-mx6.c int ehci_hcd_init(int index, enum usb_init_type init, · line 235
Quoted 5 lines
drivers/usb/host/ehci-mx6.c +2 -0
+	board_ehci_usb_mode(index, &type);
+
  	*hccr = (struct ehci_hccr *)((uint32_t)&ehci->caplength);
  	*hcor = (struct ehci_hcor *)((uint32_t)*hccr +
  			HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));
Best regards,
Marek Vasut

Regards,
Peng.

Marek Vasut

2014-11-04 11:01 UTC #4 lore raw

PATCH v2 1/3 usb:ehci-mx6 add board_ehci_usb_mode function

Quoted 27 lines · Peng Fan

? 11/4/2014 6:33 PM, Marek Vasut ??:
Quoted 6 lines · Peng Fan
Quoted 2 lines
Include a weak function board_ehci_usb_mode to gives board code a choice.
What choice?
Quoted 7 lines
Quoted 2 lines
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.

Quoted 4 lines

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

Best regards,
Marek Vasut

Peng Fan

2014-11-04 13:29 UTC #5 lore raw

PATCH v2 1/3 usb:ehci-mx6 add board_ehci_usb_mode function

Hi Marek,

? 11/4/2014 7:01 PM, Marek Vasut ??:

Quoted 33 lines · Peng Fan

Quoted 27 lines
? 11/4/2014 6:33 PM, Marek Vasut ??:
Quoted 6 lines · Peng Fan
Quoted 2 lines
Include a weak function board_ehci_usb_mode to gives board code a choice.
What choice?
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
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'.

Quoted 7 lines

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)

{
	if (index == 1)
		return 0; /* HOST */
	else
		return 1; /* DEVICE */
}

Quoted 3 lines

Best regards,
Marek Vasut

Regards,
Peng.

Marek Vasut

2014-11-04 17:33 UTC #6 lore raw

PATCH v2 1/3 usb:ehci-mx6 add board_ehci_usb_mode function

Quoted 51 lines · Peng Fan

Hi Marek,
? 11/4/2014 7:01 PM, Marek Vasut ??:
Quoted 33 lines · Peng Fan
Quoted 27 lines
? 11/4/2014 6:33 PM, Marek Vasut ??:
Quoted 6 lines · Peng Fan
Quoted 2 lines
Include a weak function board_ehci_usb_mode to gives board code a choice.
What choice?
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
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'.
Quoted 6 lines
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;
}

Quoted 5 lines

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. [...]
Best regards,
Marek Vasut

Peng Fan

2014-11-05 06:00 UTC #7 lore raw

PATCH v2 1/3 usb:ehci-mx6 add board_ehci_usb_mode function

? 11/5/2014 1:33 AM, Marek Vasut ??:

Quoted 55 lines · Peng Fan

Quoted 54 lines
Hi Marek,
? 11/4/2014 7:01 PM, Marek Vasut ??:
Quoted 33 lines · Peng Fan
Quoted 27 lines
? 11/4/2014 6:33 PM, Marek Vasut ??:
Quoted 6 lines · Peng Fan
Quoted 2 lines
Include a weak function board_ehci_usb_mode to gives board code a choice.
What choice?
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
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'.
Quoted 6 lines
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);"

Quoted 6 lines

Quoted 2 lines
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. How about just use
"int board_usb_phy_mode(int index)" without using 'val' or 'struct usb_ehci *ehci'.

Quoted 3 lines

Best regards,
Marek Vasut

Regards,
Peng.

Marek Vasut

2014-11-05 09:03 UTC #8 lore raw

PATCH v2 1/3 usb:ehci-mx6 add board_ehci_usb_mode function

Quoted 61 lines · Peng Fan

? 11/5/2014 1:33 AM, Marek Vasut ??:
Quoted 60 lines · Peng Fan
Quoted 58 lines
Hi Marek,
? 11/4/2014 7:01 PM, Marek Vasut ??:
Quoted 33 lines · Peng Fan
Quoted 27 lines
? 11/4/2014 6:33 PM, Marek Vasut ??:
Quoted 6 lines · Peng Fan
Quoted 2 lines
Include a weak function board_ehci_usb_mode to gives board code a choice.
What choice?
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
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'.
Quoted 6 lines
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)

Quoted 6 lines

Quoted 3 lines
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.

Quoted 3 lines

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 ?

Peng Fan

2014-11-05 09:18 UTC #9 lore raw

PATCH v2 1/3 usb:ehci-mx6 add board_ehci_usb_mode function

? 11/5/2014 5:03 PM, Marek Vasut ??:

Quoted 69 lines · Peng Fan

Quoted 61 lines
? 11/5/2014 1:33 AM, Marek Vasut ??:
Quoted 60 lines · Peng Fan
Quoted 58 lines
Hi Marek,
? 11/4/2014 7:01 PM, Marek Vasut ??:
Quoted 33 lines · Peng Fan
Quoted 27 lines
? 11/4/2014 6:33 PM, Marek Vasut ??:
Quoted 6 lines · Peng Fan
Quoted 2 lines
Include a weak function board_ehci_usb_mode to gives board code a choice.
What choice?
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
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'.
Quoted 6 lines
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)
Quoted 6 lines
Quoted 3 lines
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.

Quoted 8 lines

Yeah.
Quoted 3 lines
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 ?

To imx6, the ID bit is in PHY ctrl reg 'USBPHYx_CTRLn', also the phy regs definition are not included in "struct usb_ehci". I just think expose the ehci register to board layer is not fine and board_usb_phy_mode does not need this. I define this just as "board_ehci_hcd_init" and "board_ehci_power". Their prototype are int __weak board_ehci_hcd_init(int port);
int __weak board_ehci_power(int port, int on);

My implementation is the following:

replace "return val & USBPHY_CTRL_OTG_ID;" using "return board_usb_phy_mode(index);" in usb_phy_enable

In drivers/usb/host/ehci-mx6.c:
116 int __weak board_usb_phy_mode(int index)
117 {

118         void __iomem *phy_reg;
119         void __iomem *phy_ctrl;
120         u32 val;

121
122 phy_reg = (void __iomem *)phy_bases[index];
123 phy_ctrl = (void __iomem *)(phy_reg + USBPHY_CTRL);
124
125 val = __raw_readl(phy_ctrl);
126
127 return val & USBPHY_CTRL_OTG_ID;
128 }

In board/freescale/mx6sxsabresd/mx6sxsabresd.c:
295 int board_usb_phy_mode(int port)
296 {

297         void __iomem *phy_reg;
298         void __iomem *phy_ctrl;
299         u32 val;
300
301         switch (port) {
302         case 0:
303                 phy_reg = (void __iomem *)USB_PHY0_BASE_ADDR;
304                 phy_ctrl = (void __iomem *)(phy_reg + USBPHY_CTRL);
305                 val = __raw_readl(phy_ctrl);
306                 return val & USBPHY_CTRL_OTG_ID;

307 case 1:
308 /* Work in HOST mode. */
309 return 0;
310 }
311
312 /* suppress warning msg */
313 return 0;
314 }

Is this piece of code fine?

Quoted 1 line

Regards,
Peng.

Marek Vasut

2014-11-06 20:20 UTC #10 lore raw

PATCH v2 1/3 usb:ehci-mx6 add board_ehci_usb_mode function

Quoted 130 lines · Peng Fan

? 11/5/2014 5:03 PM, Marek Vasut ??:
Quoted 70 lines · Peng Fan
Quoted 62 lines
? 11/5/2014 1:33 AM, Marek Vasut ??:
Quoted 61 lines · Peng Fan
Quoted 59 lines
Hi Marek,
? 11/4/2014 7:01 PM, Marek Vasut ??:
Quoted 33 lines · Peng Fan
Quoted 27 lines
? 11/4/2014 6:33 PM, Marek Vasut ??:
Quoted 6 lines · Peng Fan
Quoted 2 lines
Include a weak function board_ehci_usb_mode to gives board code a choice.
What choice?
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
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'.
Quoted 7 lines
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)
Quoted 6 lines
Quoted 3 lines
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.
Quoted 8 lines
Yeah.
Quoted 3 lines
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 ?
To imx6, the ID bit is in PHY ctrl reg 'USBPHYx_CTRLn', also the phy regs definition are not included in "struct usb_ehci". I just think expose the ehci register to board layer is not fine and board_usb_phy_mode does not need this. I define this just as "board_ehci_hcd_init" and "board_ehci_power". Their prototype are int __weak board_ehci_hcd_init(int port);
int __weak board_ehci_power(int port, int on);
My implementation is the following:
replace "return val & USBPHY_CTRL_OTG_ID;" using "return board_usb_phy_mode(index);" in usb_phy_enable
In drivers/usb/host/ehci-mx6.c:
116 int __weak board_usb_phy_mode(int index)
117 {
118         void __iomem *phy_reg;
119         void __iomem *phy_ctrl;
120         u32 val;
121
122 phy_reg = (void __iomem *)phy_bases[index];
123 phy_ctrl = (void __iomem *)(phy_reg + USBPHY_CTRL);
124
125 val = __raw_readl(phy_ctrl);
126
127 return val & USBPHY_CTRL_OTG_ID;
128 }
In board/freescale/mx6sxsabresd/mx6sxsabresd.c:
295 int board_usb_phy_mode(int port)
296 {
297         void __iomem *phy_reg;
298         void __iomem *phy_ctrl;
299         u32 val;
300
301         switch (port) {
302         case 0:
303                 phy_reg = (void __iomem *)USB_PHY0_BASE_ADDR;
304                 phy_ctrl = (void __iomem *)(phy_reg + USBPHY_CTRL);
305                 val = __raw_readl(phy_ctrl);
306                 return val & USBPHY_CTRL_OTG_ID;
307 case 1:
308 /* Work in HOST mode. */
309 return 0;
310 }
311
312 /* suppress warning msg */
313 return 0;
314 }

Quoted 1 line

Is this piece of code fine?

These ad-hoc hooks are starting to become absolute horror, but I guess this one (if properly documented) might just work. Let's see what will come out of this approach.

Peng Fan

2014-11-07 01:10 UTC #11 lore raw

PATCH v2 1/3 usb:ehci-mx6 add board_ehci_usb_mode function

? 11/7/2014 4:20 AM, Marek Vasut ??:

Quoted 131 lines · Peng Fan

Quoted 130 lines
? 11/5/2014 5:03 PM, Marek Vasut ??:
Quoted 70 lines · Peng Fan
Quoted 62 lines
? 11/5/2014 1:33 AM, Marek Vasut ??:
Quoted 61 lines · Peng Fan
Quoted 59 lines
Hi Marek,
? 11/4/2014 7:01 PM, Marek Vasut ??:
Quoted 33 lines · Peng Fan
Quoted 27 lines
? 11/4/2014 6:33 PM, Marek Vasut ??:
Quoted 6 lines · Peng Fan
Quoted 2 lines
Include a weak function board_ehci_usb_mode to gives board code a choice.
What choice?
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
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'.
Quoted 7 lines
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)
Quoted 6 lines
Quoted 3 lines
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.
Quoted 8 lines
Yeah.
Quoted 3 lines
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 ?
To imx6, the ID bit is in PHY ctrl reg 'USBPHYx_CTRLn', also the phy regs definition are not included in "struct usb_ehci". I just think expose the ehci register to board layer is not fine and board_usb_phy_mode does not need this. I define this just as "board_ehci_hcd_init" and "board_ehci_power". Their prototype are int __weak board_ehci_hcd_init(int port);
int __weak board_ehci_power(int port, int on);
My implementation is the following:
replace "return val & USBPHY_CTRL_OTG_ID;" using "return board_usb_phy_mode(index);" in usb_phy_enable
In drivers/usb/host/ehci-mx6.c:
116 int __weak board_usb_phy_mode(int index)
117 {
118         void __iomem *phy_reg;
119         void __iomem *phy_ctrl;
120         u32 val;
121
122 phy_reg = (void __iomem *)phy_bases[index];
123 phy_ctrl = (void __iomem *)(phy_reg + USBPHY_CTRL);
124
125 val = __raw_readl(phy_ctrl);
126
127 return val & USBPHY_CTRL_OTG_ID;
128 }
In board/freescale/mx6sxsabresd/mx6sxsabresd.c:
295 int board_usb_phy_mode(int port)
296 {
297         void __iomem *phy_reg;
298         void __iomem *phy_ctrl;
299         u32 val;
300
301         switch (port) {
302         case 0:
303                 phy_reg = (void __iomem *)USB_PHY0_BASE_ADDR;
304                 phy_ctrl = (void __iomem *)(phy_reg + USBPHY_CTRL);
305                 val = __raw_readl(phy_ctrl);
306                 return val & USBPHY_CTRL_OTG_ID;
307 case 1:
308 /* Work in HOST mode. */
309 return 0;
310 }
311
312 /* suppress warning msg */
313 return 0;
314 }

Quoted 6 lines

Quoted 1 line
Is this piece of code fine?
These ad-hoc hooks are starting to become absolute horror, but I guess this one (if properly documented) might just work. Let's see what will come out of this approach.

Sent out v3 patch set just now. Please review.

Thanks,
Peng.

Marek Vasut

2014-11-07 08:26 UTC #12 lore raw

PATCH v2 1/3 usb:ehci-mx6 add board_ehci_usb_mode function

On Friday, November 07, 2014 at 02:10:28 AM, Peng Fan wrote:
[...]

Quoted 22 lines

Quoted 22 lines
Quoted 22 lines
In board/freescale/mx6sxsabresd/mx6sxsabresd.c:
295 int board_usb_phy_mode(int port)
296 {
297         void __iomem *phy_reg;
298         void __iomem *phy_ctrl;
299         u32 val;
300
301         switch (port) {
302         case 0:
303                 phy_reg = (void __iomem *)USB_PHY0_BASE_ADDR;
304                 phy_ctrl = (void __iomem *)(phy_reg + USBPHY_CTRL);
305                 val = __raw_readl(phy_ctrl);
306                 return val & USBPHY_CTRL_OTG_ID;
307 case 1:
308 /* Work in HOST mode. */
309 return 0;
310 }
311
312 /* suppress warning msg */
313 return 0;
314 }

Quoted 7 lines

Quoted 5 lines
Quoted 1 line
Is this piece of code fine?
These ad-hoc hooks are starting to become absolute horror, but I guess this one (if properly documented) might just work. Let's see what will come out of this approach.
Sent out v3 patch set just now. Please review.

Done, there're only minor comments.

Thanks!

Best regards,
Marek Vasut

Jeroen Hofstee

2014-11-04 11:40 UTC #13 lore raw

PATCH v2 1/3 usb:ehci-mx6 add board_ehci_usb_mode function

In reply to Peng Fan

Hello Peng,

Quoted 32 lines · Peng Fan

Include a weak function board_ehci_usb_mode to gives board code a choice. If the board want the otg port work in host mode but not device mode, this should be handled.
Signed-off-by Peng Fan <[email protected]>
Signed-off-by Ye Li <[email protected]>
---
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 | 7 +++++++
  1 file changed, 7 insertions(+)
drivers/usb/host/ehci-mx6.c +5 -0
index 9ec5a0a..3662a80 100644
@@ -193,6 +193,11 @@ static void usb_oc_config(int index)
  	__raw_writel(val, ctrl);
  }
 
+int __weak board_ehci_usb_mode(int index, enum usb_init_type *type)
+{
+	return 0;
+}
+
  int __weak board_ehci_hcd_init(int port)
  {
  	return 0;

drivers/usb/host/ehci-mx6.c int ehci_hcd_init(int index, enum usb_init_type init, · line 235

Quoted 8 lines

drivers/usb/host/ehci-mx6.c +2 -0

@@ -223,6 +228,8 @@ int ehci_hcd_init(int index, enum usb_init_type init,
  	usb_internal_phy_clock_gate(index, 1);
  	type = usb_phy_enable(index, ehci) ? USB_INIT_DEVICE : USB_INIT_HOST;
 
+	board_ehci_usb_mode(index, &type);
+
  	*hccr = (struct ehci_hccr *)((uint32_t)&ehci->caplength);
  	*hcor = (struct ehci_hcor *)((uint32_t)*hccr +
  			HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));

Can you add a prototype type as well and make sure it is included?

Thanks,
Jeroen

Peng Fan

2014-11-04 13:36 UTC #14 lore raw

PATCH v2 1/3 usb:ehci-mx6 add board_ehci_usb_mode function

Hi Jeroen,

? 11/4/2014 7:40 PM, Jeroen Hofstee ??:

Quoted 38 lines

Hello Peng,
Quoted 35 lines · Peng Fan
Include a weak function board_ehci_usb_mode to gives board code a choice. If the board want the otg port work in host mode but not device mode, this should be handled.
Signed-off-by Peng Fan <[email protected]>
Signed-off-by Ye Li <[email protected]>
---
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 | 7 +++++++
   1 file changed, 7 insertions(+)
drivers/usb/host/ehci-mx6.c +5 -0
index 9ec5a0a..3662a80 100644
@@ -193,6 +193,11 @@ static void usb_oc_config(int index)
   	__raw_writel(val, ctrl);
   }
 
+int __weak board_ehci_usb_mode(int index, enum usb_init_type *type)
+{
+	return 0;
+}
+
   int __weak board_ehci_hcd_init(int port)
   {
   	return 0;
@@ -223,6 +228,8 @@ int ehci_hcd_init(int index, enum usb_init_type init,
   	usb_internal_phy_clock_gate(index, 1);
   	type = usb_phy_enable(index, ehci) ? USB_INIT_DEVICE : USB_INIT_HOST;
 

Quoted 7 lines

drivers/usb/host/ehci-mx6.c int ehci_hcd_init(int index, enum usb_init_type init, · line 235
Quoted 5 lines
drivers/usb/host/ehci-mx6.c +2 -0
+	board_ehci_usb_mode(index, &type);
+
   	*hccr = (struct ehci_hccr *)((uint32_t)&ehci->caplength);
   	*hcor = (struct ehci_hcor *)((uint32_t)*hccr +
   			HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));
Can you add a prototype type as well and make sure it is included?

I did not find a good place for the prototype type. I think ehci.h is not fine to include this prototype. Any suggestions?

Quoted 4 lines

Thanks,
Jeroen

Regards,
Peng.

Jeroen Hofstee

2014-11-04 19:39 UTC #15 lore raw

PATCH v2 1/3 usb:ehci-mx6 add board_ehci_usb_mode function

Hello Peng,

Quoted 52 lines · Peng Fan

Hi Jeroen,
? 11/4/2014 7:40 PM, Jeroen Hofstee ??:
Quoted 41 lines
Hello Peng,
Quoted 38 lines · Peng Fan
Include a weak function board_ehci_usb_mode to gives board code a choice. If the board want the otg port work in host mode but not device mode, this should be handled.
Signed-off-by Peng Fan <[email protected]>
Signed-off-by Ye Li <[email protected]>
---
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 | 7 +++++++
   1 file changed, 7 insertions(+)
drivers/usb/host/ehci-mx6.c +5 -0
index 9ec5a0a..3662a80 100644
@@ -193,6 +193,11 @@ static void usb_oc_config(int index)
       __raw_writel(val, ctrl);
   }
 
+int __weak board_ehci_usb_mode(int index, enum usb_init_type *type)
+{
+    return 0;
+}
+
   int __weak board_ehci_hcd_init(int port)
   {
       return 0;
@@ -223,6 +228,8 @@ int ehci_hcd_init(int index, enum usb_init_type 
 init,
       usb_internal_phy_clock_gate(index, 1);
       type = usb_phy_enable(index, ehci) ? USB_INIT_DEVICE : 
 USB_INIT_HOST;
 
Quoted 7 lines
Quoted 5 lines
drivers/usb/host/ehci-mx6.c +2 -0
+    board_ehci_usb_mode(index, &type);
+
       *hccr = (struct ehci_hccr *)((uint32_t)&ehci->caplength);
       *hcor = (struct ehci_hcor *)((uint32_t)*hccr +
HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));
Can you add a prototype type as well and make sure it is included?

Quoted 2 lines

I did not find a good place for the prototype type. I think ehci.h is not fine to include this prototype. Any suggestions?

Ah, good point. I have reserved USB as well for the "not trivial" to fix warnings. Ideally there should be a header in drivers somewhere defining what different usb drivers can/should support when dealing with common usb code and one in include/... for the board interface.

Since this is currently lacking, I am also fine checking it in without a valid
prototype and fix it later.

Regards,
Jeroen

Peng Fan

author

2014-11-04 07:50 UTC #16 lore raw

PATCH v2 2/3 imx:mx6sxsabresd add usb support

In reply to Peng Fan

Add usb support for mx6sxsabresd board.

There are two usb port on mx6sxsabresd board:
1. OTG
2. OTG
The second port is actually an otg port with a USB A type interface on the board.

Signed-off-by Peng Fan <[email protected]>

Signed-off-by Ye Li <[email protected]>

---

Changes v2:
Add otg polarity setting
Move pinmux setting into board_init

 board/freescale/mx6sxsabresd/mx6sxsabresd.c | 51 +++++++++++++++++++++++++++++
 include/configs/mx6sxsabresd.h              | 14 ++++++++
 2 files changed, 65 insertions(+)

board/freescale/mx6sxsabresd/mx6sxsabresd.c +51 -0

index 256ea29..81619bd 100644
@@ -25,6 +25,7 @@
 #include <netdev.h>
 #include <power/pmic.h>
 #include <power/pfuze100_pmic.h>
+#include <usb.h>
 
 DECLARE_GLOBAL_DATA_PTR;

@@ -271,6 +272,52 @@ int board_mmc_init(bd_t *bis)
 	return fsl_esdhc_initialize(bis, &usdhc_cfg[0]);
 }
 
+#ifdef CONFIG_USB_EHCI_MX6
+#define USB_OTHERREGS_OFFSET	0x800
+#define UCTRL_PWR_POL		(1 << 9)
+
+static iomux_v3_cfg_t const usb_otg_pads[] = {
+	/* OGT1 */
+	MX6_PAD_GPIO1_IO09__USB_OTG1_PWR | MUX_PAD_CTRL(NO_PAD_CTRL),
+	MX6_PAD_GPIO1_IO10__ANATOP_OTG1_ID | MUX_PAD_CTRL(NO_PAD_CTRL),
+	/* OTG2 */
+	MX6_PAD_GPIO1_IO12__USB_OTG2_PWR | MUX_PAD_CTRL(NO_PAD_CTRL)
+};
+
+static void setup_usb(void)
+{
+	imx_iomux_v3_setup_multiple_pads(usb_otg_pads,
+					 ARRAY_SIZE(usb_otg_pads));
+}
+
+int board_ehci_usb_mode(int port, enum usb_init_type *type)
+{
+	if (port != 1)
+		return -EINVAL;
+
+	/* port1 works in HOST Mode */
+	*type = USB_INIT_HOST;
+
+	return 0;
+}
+
+int board_ehci_hcd_init(int port)
+{
+	u32 *usbnc_usb_ctrl;
+
+	if (port != 1)
+		return -EINVAL;
+
+	usbnc_usb_ctrl = (u32 *)(USB_BASE_ADDR + USB_OTHERREGS_OFFSET +
+				 port * 4);
+
+	/* Set Power polarity */
+	setbits_le32(usbnc_usb_ctrl, UCTRL_PWR_POL);
+
+	return 0;
+}
+#endif
+
 int board_init(void)
 {
 	/* Address of boot parameters */

@@ -280,6 +327,10 @@ int board_init(void)
 	setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, &i2c_pad_info1);
 #endif
 
+#ifdef CONFIG_USB_EHCI_MX6
+	setup_usb();
+#endif
+
 	return 0;
 }

include/configs/mx6sxsabresd.h +14 -0

index e02ea18..8edf187 100644
@@ -198,6 +198,20 @@
 #define CONFIG_PHYLIB
 #define CONFIG_PHY_ATHEROS
 
+
+#define CONFIG_CMD_USB
+#ifdef CONFIG_CMD_USB
+#define CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_MX6
+#define CONFIG_USB_STORAGE
+#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_ASIX
+#define CONFIG_MXC_USB_PORTSC  (PORT_PTS_UTMI | PORT_PTS_PTW)
+#define CONFIG_MXC_USB_FLAGS   0
+#define CONFIG_USB_MAX_CONTROLLER_COUNT 2
+#endif
+
 #define CONFIG_CMD_PCI
 #ifdef CONFIG_CMD_PCI
 #define CONFIG_PCI

Signature · 1 line

1.8.4.5

Peng Fan

author

2014-11-04 07:50 UTC #17 lore raw

PATCH v2 3/3 imx:mx6slevk add usb support

In reply to Peng Fan

Add usb support for mx6slevk board.

Signed-off-by Peng Fan <[email protected]>

Signed-off-by Ye Li <[email protected]>

---

Changes v2:
Add otg polarity setting
move pinmux into board_init

 arch/arm/include/asm/arch-mx6/mx6sl_pins.h |  5 +++
 board/freescale/mx6slevk/mx6slevk.c        | 51 ++++++++++++++++++++++++++++++
 include/configs/mx6slevk.h                 | 14 ++++++++
 3 files changed, 70 insertions(+)

arch/arm/include/asm/arch-mx6/mx6sl_pins.h +5 -0

index 045ccc4..17b4798 100644
@@ -34,5 +34,10 @@ enum {
 	MX6_PAD_FEC_REF_CLK__FEC_REF_OUT			= IOMUX_PAD(0x424, 0x134, 0x10, 0x000, 0, 0),
 	MX6_PAD_FEC_RX_ER__GPIO_4_19				= IOMUX_PAD(0x0428, 0x0138, 5, 0x0000, 0, 0),
 	MX6_PAD_FEC_TX_CLK__GPIO_4_21				= IOMUX_PAD(0x0434, 0x0144, 5, 0x0000, 0, 0),
+
+	MX6_PAD_EPDC_PWRCOM__ANATOP_USBOTG1_ID			= IOMUX_PAD(0x03D0, 0x00E0, 4, 0x05DC, 0, 0),
+
+	MX6_PAD_KEY_COL4__USB_USBOTG1_PWR			= IOMUX_PAD(0x0484, 0x017C, 6, 0x0000, 0, 0),
+	MX6_PAD_KEY_COL5__USB_USBOTG2_PWR			= IOMUX_PAD(0x0488, 0x0180, 6, 0x0000, 0, 0),
 };
 #endif	/* __ASM_ARCH_MX6_MX6SL_PINS_H__ */

board/freescale/mx6slevk/mx6slevk.c +51 -0

69 lines not on this page · raw message

include/configs/mx6slevk.h +14 -0

index fddedf1..021dc0e 100644
@@ -210,4 +210,18 @@
 #define CONFIG_SF_DEFAULT_MODE		SPI_MODE_0
 #endif
 
+/* USB Configs */
+#define CONFIG_CMD_USB
+#ifdef CONFIG_CMD_USB
+#define CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_MX6
+#define CONFIG_USB_STORAGE
+#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_ASIX
+#define CONFIG_MXC_USB_PORTSC		(PORT_PTS_UTMI | PORT_PTS_PTW)
+#define CONFIG_MXC_USB_FLAGS		0
+#define CONFIG_USB_MAX_CONTROLLER_COUNT	2
+#endif
+
 #endif				/* __CONFIG_H */

Signature · 1 line

1.8.4.5

Marek Vasut

2014-11-04 10:31 UTC #18 lore raw

v2 cover imx:mx6 add usb support

In reply to Peng Fan

On Tuesday, November 04, 2014 at 08:49:59 AM, Peng Fan wrote:

So uh, what exactly does this patchset do ? It's not clear at all from the subject and any description is completely missing.

To my knowledge, i.MX6 already does have USB support in U-Boot, so the subject is misleading as well.

Quoted 12 lines

Changes v2:
- move pinmux setting into board_init
- add otg polarity setting in board_ehci_hcd_init
- Introduce a new weak function to give board a choice to decide the work
mode of the otg port, since a otg port can also work in host mode without touch ID pin.
Peng Fan (3):
usb:ehci-mx6 add board_ehci_usb_mode function
imx:mx6sxsabresd add usb support
imx:mx6slevk add usb support

Quoted 8 lines

 arch/arm/include/asm/arch-mx6/mx6sl_pins.h  |  5 +++
 board/freescale/mx6slevk/mx6slevk.c         | 51
+++++++++++++++++++++++++++++ board/freescale/mx6sxsabresd/mx6sxsabresd.c
| 51 +++++++++++++++++++++++++++++ drivers/usb/host/ehci-mx6.c            
    |  7 ++++
 include/configs/mx6slevk.h                  | 14 ++++++++
 include/configs/mx6sxsabresd.h              | 14 ++++++++
 6 files changed, 142 insertions(+)

Best regards,
Marek Vasut

Peng Fan

2014-11-04 12:05 UTC #19 lore raw

v2 cover imx:mx6 add usb support

? 11/4/2014 6:31 PM, Marek Vasut ??:

Quoted 7 lines · Peng Fan

So uh, what exactly does this patchset do ? It's not clear at all from the subject and any description is completely missing.
To my knowledge, i.MX6 already does have USB support in U-Boot, so the subject is misleading as well.

mx6sxsasbresd board and mx6slevk board does not have board level support for usb. This patchset is mainly to add pinmux and implement board_ehci_hcd_init and board_echi_power and add USB CONFIG in header file to make usb work fine.

I'll send another patch for review, if "usb:ehci-mx6 add board_ehci_usb_mode function" is fine.

Quoted 22 lines

Quoted 13 lines
Changes v2:
- move pinmux setting into board_init
- add otg polarity setting in board_ehci_hcd_init
- Introduce a new weak function to give board a choice to decide the work
mode of the otg port, since a otg port can also work in host mode without touch ID pin.
Peng Fan (3):
usb:ehci-mx6 add board_ehci_usb_mode function
imx:mx6sxsabresd add usb support
imx:mx6slevk add usb support
Quoted 8 lines
  arch/arm/include/asm/arch-mx6/mx6sl_pins.h  |  5 +++
  board/freescale/mx6slevk/mx6slevk.c         | 51
+++++++++++++++++++++++++++++ board/freescale/mx6sxsabresd/mx6sxsabresd.c
| 51 +++++++++++++++++++++++++++++ drivers/usb/host/ehci-mx6.c
     |  7 ++++
  include/configs/mx6slevk.h                  | 14 ++++++++
  include/configs/mx6sxsabresd.h              | 14 ++++++++
  6 files changed, 142 insertions(+)

Quoted 3 lines

Best regards,
Marek Vasut

Regards,
Peng.

Marek Vasut

2014-11-04 12:08 UTC #20 lore raw

v2 cover imx:mx6 add usb support

Quoted 9 lines · Peng Fan

? 11/4/2014 6:31 PM, Marek Vasut ??:
Quoted 7 lines · Peng Fan
So uh, what exactly does this patchset do ? It's not clear at all from the subject and any description is completely missing.
To my knowledge, i.MX6 already does have USB support in U-Boot, so the subject is misleading as well.

Quoted 7 lines

mx6sxsasbresd board and mx6slevk board does not have board level support for usb. This patchset is mainly to add pinmux and implement board_ehci_hcd_init and board_echi_power and add USB CONFIG in header file to make usb work fine.
I'll send another patch for review, if "usb:ehci-mx6 add board_ehci_usb_mode function" is fine.

Please see my comment to that patch before you re-submit.

Thanks!

Best regards,
Marek Vasut