RE: Bugged initial state with Chipidea driver

> Subject: Bugged initial state with Chipidea driver > > Hi, > > In the Chipidea driver the extcon state is read early in the initialization > and > notifications for extcon events are only enabled at the end of the > initialization. If the > extcon state ch

[PATCH v2 5/5] arm: dts: ls1021a: enable chipidea driver and USB 2.0 PHY driver

This patch adds entries in dts to enable chipidea platform driver and USB 2.0 PHY driver. Signed-off-by: Rajesh Bhagat --- Changes in v2: - Reworked for latest changes arch/arm/boot/dts/ls1021a.dtsi | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-)

Re: [GIT PULL] USB chipidea driver fixes for 4.3-rc6

On Wed, Oct 21, 2015 at 04:25:58PM +0800, Peter Chen wrote: > The following changes since commit fd7cd061adcf5f7503515ba52b6a724642a839c8: > > xhci: Add spurious wakeup quirk for LynxPoint-LP controllers (2015-10-17 > 00:04:18 -0700) > > are available in the git repository at: > >

Re: [GIT PULL] USB chipidea driver fixes for 4.3-rc6

On Thu, Oct 22, 2015 at 06:24:13PM -0700, Greg KH wrote: > On Wed, Oct 21, 2015 at 04:25:58PM +0800, Peter Chen wrote: > > The following changes since commit fd7cd061adcf5f7503515ba52b6a724642a839c8: > > > > xhci: Add spurious wakeup quirk for LynxPoint-LP controllers (2015-10-17 > > 00:04:18

[GIT PULL] USB chipidea driver fixes for 4.3-rc6

The following changes since commit fd7cd061adcf5f7503515ba52b6a724642a839c8: xhci: Add spurious wakeup quirk for LynxPoint-LP controllers (2015-10-17 00:04:18 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/

RE: assitance required: ulpi+chipidea driver for z27xx

with chipidea driver, I have no ulpi hardware on hands. Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: assitance required: ulpi+chipidea driver for z27xx

Hi So, you have returned ulpi_init successfully? Yes. I do. The ULPI init returns me a vendor and product ID. not check your code, it maybe a reset pin connect to ulpi phy. Alexander and Chris has run ulpi hardware successfully with chipidea driver, I have no ulpi hardware on hands. Ok. It's

i.MX6 UDC driver fsl-usb2-udc versus chipidea driver

I am developing a usb perihperal with the goal of high data throughput on a freescla i.Mx6 (phyFlex). My current UDC driver is fsl-usb2-udc on kernel 3.0.35. I was recommended the chipidea driver introduced in kernel 3.5 since it would perform better. Currently I have speed issues when I use

Re: i.MX6 UDC driver fsl-usb2-udc versus chipidea driver

On Fri, Apr 04, 2014 at 09:58:10AM +0200, Marco Zamponi wrote: I am developing a usb perihperal with the goal of high data throughput on a freescla i.Mx6 (phyFlex). My current UDC driver is fsl-usb2-udc on kernel 3.0.35. I was recommended the chipidea driver introduced in kernel 3.5 since

Re: Two remain problems at chipidea driver

On Mon, Jun 17, 2013 at 9:59 AM, Peter Chen hzpeterc...@gmail.com wrote: On Thu, Mar 21, 2013 at 11:06 AM, Peter Chen peter.c...@freescale.com wrote: On Wed, Mar 20, 2013 at 01:04:33PM +0200, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: On Fri, Mar 15, 2013 at

Re: Two remain problems at chipidea driver

Peter Chen hzpeterc...@gmail.com writes: On Thu, Mar 21, 2013 at 11:06 AM, Peter Chen peter.c...@freescale.com wrote: On Wed, Mar 20, 2013 at 01:04:33PM +0200, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin

Re: Two remain problems at chipidea driver

On Thu, Mar 21, 2013 at 11:06 AM, Peter Chen peter.c...@freescale.com wrote: On Wed, Mar 20, 2013 at 01:04:33PM +0200, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote: Eg, for tablet or phone, the

About usbmisc_imx.c at chipidea driver

Hi Michael Marc, Recently, I have worked at i.mx USB loadable module support for chipidea driver, it needs to write non-core register during the ci13xxx_imx remove process, but currently, the usbmisc_imx is a driver, and it uses symbol from ci13xxx_imx, so it will be unload first. How about I

Re: About usbmisc_imx.c at chipidea driver

Peter Chen peter.c...@freescale.com writes: Hi Michael Marc, Recently, I have worked at i.mx USB loadable module support for chipidea driver, it needs to write non-core register during the ci13xxx_imx remove process, but currently, the usbmisc_imx is a driver, and it uses symbol from

Re: About usbmisc_imx.c at chipidea driver

On Wed, May 15, 2013 at 01:34:31PM +0300, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: Hi Michael Marc, Recently, I have worked at i.mx USB loadable module support for chipidea driver, it needs to write non-core register during the ci13xxx_imx remove

Re: About usbmisc_imx.c at chipidea driver

Sascha Hauer s.ha...@pengutronix.de writes: On Wed, May 15, 2013 at 01:34:31PM +0300, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: Hi Michael Marc, Recently, I have worked at i.mx USB loadable module support for chipidea driver, it needs to write non-core

Re: About usbmisc_imx.c at chipidea driver

loadable module support for chipidea driver, it needs to write non-core register during the ci13xxx_imx remove process, but currently, the usbmisc_imx is a driver, and it uses symbol from ci13xxx_imx, so it will be unload first. One driver really shouldn't be using symbols from

Re: About usbmisc_imx.c at chipidea driver

On Wed, May 15, 2013 at 01:34:31PM +0300, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: Hi Michael Marc, Recently, I have worked at i.mx USB loadable module support for chipidea driver, it needs to write non-core register during the ci13xxx_imx remove

Re: [PATCH v3 0/1] Chipidea driver support for the AR933x platform

Svetoslav Neykov svetos...@neykov.name writes: Add support for the usb controller in AR933x platform. The controller supports both host or device mode (defined at startup) but not OTG. The patches are tested on WR703n router running OpenWRT in device mode. You forgot to mention the

RE: [PATCH v3 0/1] Chipidea driver support for the AR933x platform

From: Alexander Shishkin [mailto:alexander.shish...@linux.intel.com] Svetoslav Neykov svetos...@neykov.name writes: Add support for the usb controller in AR933x platform. The controller supports both host or device mode (defined at startup) but not OTG. The patches are tested on WR703n

[PATCH v3 0/1] Chipidea driver support for the AR933x platform

. Changes to follow the style of the existing code. Svetoslav Neykov (1): usb: chipidea: AR933x platform support for the chipidea driver arch/mips/ath79/dev-usb.c | 42 arch/mips/include/asm/mach-ath79/ar71xx_regs.h |3 ++ 2 files changed, 45

[PATCH v3 1/1] usb: chipidea: AR933x platform support for the chipidea driver

Support host and device usb modes for the chipidea controller in AR933x. The controller doesn't support OTG functionality so the platform code forces one of the modes based on the state of GPIO13 pin at startup. Signed-off-by: Svetoslav Neykov svetos...@neykov.name --- arch/mips/ath79/dev-usb.c

Re: [PATCH v2 2/2] usb: chipidea: AR933x platform support for the chipidea driver

a dynamically allocated structure for ci13xxx_platform_data * move controller mode check to platform usb registration * pick a different name for the ar933x chipidea driver * use a correct MODE_ALIAS name * use the dr_mode changes in [PATCH 0/3] otg-for-v3.10-v2

RE: [PATCH v2 2/2] usb: chipidea: AR933x platform support for the chipidea driver

Alexander Shishkin wrote: No need to initialize it like this, it should save a few bytes in .data. Ok. Why can't you just use ci13xxx_platform_data? It looks like you don't need a glue driver is drivers/usb/chipidea at all, you can register ci_hdrc right from the ath79/dev-usb.c You are right. I

Re: Two remain problems at chipidea driver

Marc Kleine-Budde m...@pengutronix.de writes: On 03/20/2013 02:37 PM, Alexander Shishkin wrote: Marc Kleine-Budde m...@pengutronix.de writes: On 03/20/2013 12:23 PM, Alexander Shishkin wrote: Marc Kleine-Budde m...@pengutronix.de writes: On 03/20/2013 12:04 PM, Alexander Shishkin wrote:

Re: Two remain problems at chipidea driver

Peter Chen peter.c...@freescale.com writes: On Wed, Mar 20, 2013 at 01:04:33PM +0200, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote: Eg, for tablet or phone, the dr_mode may be gadget, but the

Re: Two remain problems at chipidea driver

On Tue, Mar 26, 2013 at 12:35:44PM +0200, Alexander Shishkin wrote: I'm thinking now that what Felipe suggests is probably the best at least for the time being. That is, if we don't want host, for example, in the product build, we just compile it out. And then we expect the dr_mode to be otg

Re: Two remain problems at chipidea driver

Peter Chen peter.c...@freescale.com writes: On Thu, Mar 14, 2013 at 09:53:55AM +0100, Marc Kleine-Budde wrote: On 03/14/2013 09:34 AM, Peter Chen wrote: Hi Alex and all, Currently, we have two problems to block chipidea driver coming development. As there are so many chipidea

Re: Two remain problems at chipidea driver

chipidea driver coming development. As there are so many chipidea versions, we impossible to collect all to make a decision, it is better to cover most of the cases, and using device tree (or platform data) to cover exceptions if they exist. 1. USB Mode Problem How can we

Re: Two remain problems at chipidea driver

Peter Chen peter.c...@freescale.com writes: On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote: Eg, for tablet or phone, the dr_mode may be gadget, but the otg_capable = 1. No, because dr_mode indicates controller's capability, and not the current mode of operation. Why

Re: Two remain problems at chipidea driver

On 03/20/2013 12:04 PM, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote: Eg, for tablet or phone, the dr_mode may be gadget, but the otg_capable = 1. No, because dr_mode indicates controller's

Re: Two remain problems at chipidea driver

Marc Kleine-Budde m...@pengutronix.de writes: On 03/20/2013 12:04 PM, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote: Eg, for tablet or phone, the dr_mode may be gadget, but the otg_capable = 1.

Re: Two remain problems at chipidea driver

On 03/20/2013 12:23 PM, Alexander Shishkin wrote: Marc Kleine-Budde m...@pengutronix.de writes: On 03/20/2013 12:04 PM, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote: Eg, for tablet or phone, the

Re: Two remain problems at chipidea driver

Marc Kleine-Budde m...@pengutronix.de writes: On 03/20/2013 12:23 PM, Alexander Shishkin wrote: Marc Kleine-Budde m...@pengutronix.de writes: On 03/20/2013 12:04 PM, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander

Re: Two remain problems at chipidea driver

Hi, On Wed, Mar 20, 2013 at 03:37:01PM +0200, Alexander Shishkin wrote: dr_cap is what the device can actually do (host, peripheral, etc). Tells us which roles to initialize and wether we can access OTGSC on this device. dr_mode is what function of the device we'll be using on this

Re: Two remain problems at chipidea driver

Felipe Balbi ba...@ti.com writes: Hi, On Wed, Mar 20, 2013 at 03:37:01PM +0200, Alexander Shishkin wrote: dr_cap is what the device can actually do (host, peripheral, etc). Tells us which roles to initialize and wether we can access OTGSC on this device. dr_mode is what function of the

Re: Two remain problems at chipidea driver

Hi, On Wed, Mar 20, 2013 at 04:26:02PM +0200, Alexander Shishkin wrote: dr_cap is what the device can actually do (host, peripheral, etc). Tells us which roles to initialize and wether we can access OTGSC on this device. dr_mode is what function of the device we'll be using on this

Re: Two remain problems at chipidea driver

On 03/20/2013 02:37 PM, Alexander Shishkin wrote: Marc Kleine-Budde m...@pengutronix.de writes: On 03/20/2013 12:23 PM, Alexander Shishkin wrote: Marc Kleine-Budde m...@pengutronix.de writes: On 03/20/2013 12:04 PM, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: On

Re: Two remain problems at chipidea driver

On 03/20/2013 03:44 PM, Felipe Balbi wrote: Hi, On Wed, Mar 20, 2013 at 04:26:02PM +0200, Alexander Shishkin wrote: dr_cap is what the device can actually do (host, peripheral, etc). Tells us which roles to initialize and wether we can access OTGSC on this device. dr_mode is what function

Re: Two remain problems at chipidea driver

On Wed, Mar 20, 2013 at 04:58:05PM +0100, Marc Kleine-Budde wrote: On 03/20/2013 03:44 PM, Felipe Balbi wrote: Hi, On Wed, Mar 20, 2013 at 04:26:02PM +0200, Alexander Shishkin wrote: dr_cap is what the device can actually do (host, peripheral, etc). Tells us which roles to

Re: Two remain problems at chipidea driver

;-) Sure, even the mainline chipidea driver already allows us to build it host or device only :D Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-

Re: Two remain problems at chipidea driver

as well. But what if you want a kernel with host-only ? You don't want to waste precious memory initializing data you will never use ;-) Sure, even the mainline chipidea driver already allows us to build it host or device only :D yeah, note what Alex had said his plans were when I replied

Re: Two remain problems at chipidea driver

On Wed, Mar 20, 2013 at 01:04:33PM +0200, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote: Eg, for tablet or phone, the dr_mode may be gadget, but the otg_capable = 1. No, because dr_mode

Re: Two remain problems at chipidea driver

On Fri, Mar 15, 2013 at 11:04:47PM +0200, Svetoslav Neykov wrote: Hi Peter, There is a core on mips which doesn't support otg. From my point of view, support for dual_role should be a separate patch, ideally by Svetoslav (Cc'ed) who has this hardware, after we've cleaned up all dr-mode

Re: Two remain problems at chipidea driver

On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote: Eg, for tablet or phone, the dr_mode may be gadget, but the otg_capable = 1. No, because dr_mode indicates controller's capability, and not the current mode of operation. Why would anyone want to put *that* in a DT?

Re: Two remain problems at chipidea driver

On Fri, Mar 15, 2013 at 01:42:36PM +0100, Matthieu CASTET wrote: Peter Chen a écrit : On Fri, Mar 15, 2013 at 12:38:07PM +0200, Alexander Shishkin wrote: Do you see any problems with this? How to know vbus status if dr_mode == gadget, we need to indicate connection and disconnection?

Re: Two remain problems at chipidea driver

On Thu, Mar 14, 2013 at 12:31:38PM +0200, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: Hi Alex and all, Currently, we have two problems to block chipidea driver coming development. As there are so many chipidea versions, we impossible to collect all

Re: Two remain problems at chipidea driver

Peter Chen peter.c...@freescale.com writes: On Thu, Mar 14, 2013 at 12:31:38PM +0200, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: Hi Alex and all, Currently, we have two problems to block chipidea driver coming development. As there are so many chipidea

Re: Two remain problems at chipidea driver

that. That is PHY, dr_mode was core's platform data or DT node entries. struct ci13xxx_imx_data will not allocated by chipidea driver, it will be allocated by driver core, every platform needs to change. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb

Re: Two remain problems at chipidea driver

Peter Chen a écrit : On Fri, Mar 15, 2013 at 12:38:07PM +0200, Alexander Shishkin wrote: Do you see any problems with this? How to know vbus status if dr_mode == gadget, we need to indicate connection and disconnection? We don't. Do we need to indicate vbus session valid for gadget only

Re: Two remain problems at chipidea driver

Peter Chen peter.c...@freescale.com writes: On Fri, Mar 15, 2013 at 12:38:07PM +0200, Alexander Shishkin wrote: I'd say, in the core driver: 1) get dr_mode from platform data 2) only if that's DR_MODE_UNKNOWN (iirc), read DCCPARAMS, since it's not guaranteed to work across all

RE: Two remain problems at chipidea driver

Hi Peter, There is a core on mips which doesn't support otg. From my point of view, support for dual_role should be a separate patch, ideally by Svetoslav (Cc'ed) who has this hardware, after we've cleaned up all dr-mode related stuff. What means support OTG? The spec said it or there is a

Two remain problems at chipidea driver

Hi Alex and all, Currently, we have two problems to block chipidea driver coming development. As there are so many chipidea versions, we impossible to collect all to make a decision, it is better to cover most of the cases, and using device tree (or platform data) to cover exceptions

Re: Two remain problems at chipidea driver

On 03/14/2013 09:34 AM, Peter Chen wrote: Hi Alex and all, Currently, we have two problems to block chipidea driver coming development. As there are so many chipidea versions, we impossible to collect all to make a decision, it is better to cover most of the cases, and using device tree

Re: Two remain problems at chipidea driver

On Thu, Mar 14, 2013 at 09:53:55AM +0100, Marc Kleine-Budde wrote: On 03/14/2013 09:34 AM, Peter Chen wrote: Hi Alex and all, Currently, we have two problems to block chipidea driver coming development. As there are so many chipidea versions, we impossible to collect all to make

Re: Two remain problems at chipidea driver

Peter Chen peter.c...@freescale.com writes: Hi Alex and all, Currently, we have two problems to block chipidea driver coming development. As there are so many chipidea versions, we impossible to collect all to make a decision, it is better to cover most of the cases, and using device tree

Re: Two remain problems at chipidea driver

On 03/14/2013 11:31 AM, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: Hi Alex and all, Currently, we have two problems to block chipidea driver coming development. As there are so many chipidea versions, we impossible to collect all to make a decision

Re: About USBADRA bit at DEVICEADDR for chipidea driver

Peter Chen peter.c...@freescale.com writes: On Fri, Mar 08, 2013 at 04:06:30PM +0200, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: On Fri, Mar 08, 2013 at 12:39:04PM +0200, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: Hi David

RE: About USBADRA bit at DEVICEADDR for chipidea driver

For USB 3.0 host CV test, the host sends GET_DESCRIPTOR very quick (500us) once it accept the status of SET_ADDRESS The USB 2.0 spec says the recovery period after the status phase of SetAddress is 2ms. That should be enough to process the transfer completion interrupt, shouldn't it?

Re: About USBADRA bit at DEVICEADDR for chipidea driver

On Mon, 11 Mar 2013, Alexander Shishkin wrote: For USB 3.0 host CV test, the host sends GET_DESCRIPTOR very quick (500us) once it accept the status of SET_ADDRESS The USB 2.0 spec says the recovery period after the status phase of SetAddress is 2ms. That should be enough to process the

Re: About USBADRA bit at DEVICEADDR for chipidea driver

On Mon, Mar 11, 2013 at 10:58:05AM -0400, Alan Stern wrote: On Mon, 11 Mar 2013, Alexander Shishkin wrote: For USB 3.0 host CV test, the host sends GET_DESCRIPTOR very quick (500us) once it accept the status of SET_ADDRESS The USB 2.0 spec says the recovery period after the

Re: About USBADRA bit at DEVICEADDR for chipidea driver

On Fri, Mar 08, 2013 at 04:06:30PM +0200, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: On Fri, Mar 08, 2013 at 12:39:04PM +0200, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: Hi David Hi, I notice at your code for

About USBADRA bit at DEVICEADDR for chipidea driver

Hi David I notice at your code for hw_usb_set_address, there is a comment for it /** * This function explicitly sets the address, without the USBADRA (advance) * feature, which is not supported by older versions of the controller. */ If we use USB3.0 host for CV test, we must use this bit, or

Re: About USBADRA bit at DEVICEADDR for chipidea driver

Peter Chen peter.c...@freescale.com writes: Hi David Hi, I notice at your code for hw_usb_set_address, there is a comment for it /** * This function explicitly sets the address, without the USBADRA (advance) * feature, which is not supported by older versions of the controller. */

Re: About USBADRA bit at DEVICEADDR for chipidea driver

On Fri, Mar 08, 2013 at 12:39:04PM +0200, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: Hi David Hi, I notice at your code for hw_usb_set_address, there is a comment for it /** * This function explicitly sets the address, without the USBADRA (advance)

Re: About USBADRA bit at DEVICEADDR for chipidea driver

Alexander Shishkin a écrit : Peter Chen peter.c...@freescale.com writes: Hi David Hi, I notice at your code for hw_usb_set_address, there is a comment for it /** * This function explicitly sets the address, without the USBADRA (advance) * feature, which is not supported by older

Re: About USBADRA bit at DEVICEADDR for chipidea driver

Peter Chen peter.c...@freescale.com writes: On Fri, Mar 08, 2013 at 12:39:04PM +0200, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: Hi David Hi, I notice at your code for hw_usb_set_address, there is a comment for it /** * This function explicitly sets

[PATCH v2 0/2] Chipidea driver support for the AR933x platform

chipidea driver * use a correct MODE_ALIAS name * use the dr_mode changes in [PATCH 0/3] otg-for-v3.10-v2: separate phy code and add DT helper Svetoslav Neykov (2): usb: chipidea: big-endian support usb: chipidea: AR933x platform support for the chipidea driver

[PATCH 0/5] chipidea-for-v3.10-v2: USB chipidea: make use of DT helpers in chipidea driver improve driver

Hello, this series depends on the series [PATCH 0/3] otg-for-v3.10-v2: separate phy code and add DT helper (a.k.a. tags/otg-for-v3.10-v2) posted earlier and is intended for v3.10. The chipidea driver is converted to make use of the DT helper functions. No changes since v1, just rebased to otg

[PATCH 0/5] chipidea-for-v3.10-v1: USB chipidea: make use of DT helpers in chipidea driver improve driver

Hello, this series depends on the series [PATCH 0/3] otg-for-v3.10-v1: separate phy code and add DT helper (a.k.a. tags/otg-for-v3.10-v1) posted earlier and is intended for v3.10. The chipidea driver is converted to make use of the DT helper functions. regards, Marc The following changes since

Re: [PATCH 0/5] chipidea-for-v3.10-v1: USB chipidea: make use of DT helpers in chipidea driver improve driver

On Wed, Feb 27, 2013 at 03:20:25PM +0100, Marc Kleine-Budde wrote: Hello, this series depends on the series [PATCH 0/3] otg-for-v3.10-v1: separate phy code and add DT helper (a.k.a. tags/otg-for-v3.10-v1) posted earlier and is intended for v3.10. The chipidea driver is converted to make use

RE: [PATCH 0/5] Chipidea driver support for the AR933x platform

] Chipidea driver support for the AR933x platform Svetoslav Neykov svetos...@neykov.name writes: Add support for the usb controller in AR933x platform. The processor is big-endian so all multi-byte values of the usb descriptors must be converted explicitly. Another difference

RE: [PATCH 0/5] Chipidea driver support for the AR933x platform

Svetoslav Neykov svetos...@neykov.name writes: Hi Alex, I am working on the incorporating all received comments - thanks to all for taking their time to comment. Apologies for not replying to the received mails, didn't want to spam with OK replies to each separately. Great, thanks! Looks

RE: [PATCH 0/5] Chipidea driver support for the AR933x platform

Great, thanks! Looks like this patchset will need some synchronization with Sacha's dr_mode/phy_mode patchset, but I presume you're aware of that. Yes, I will base the next patch on the existing changes, thanks for bringing that up. Regards, Svetoslav. -- To unsubscribe from this list: send the

Re: [PATCH 0/5] Chipidea driver support for the AR933x platform

On 02/26/2013 03:47 PM, Alexander Shishkin wrote: Svetoslav Neykov svetos...@neykov.name writes: Hi Alex, I am working on the incorporating all received comments - thanks to all for taking their time to comment. Apologies for not replying to the received mails, didn't want to spam with OK

Re: [PATCH 4/5] usb: chipidea: AR933x platform support for the chipidea driver

Hi Svetoslav, Support host and device usb modes for the chipidea controller in AR933x. The controller doesn't support OTG functionality so the platform code forces one of the modes based on the state of GPIO13 pin at startup. Signed-off-by: Svetoslav Neykov svetos...@neykov.name --- ...

[PATCH 0/5] Chipidea driver support for the AR933x platform

running OpenWRT trunk. Svetoslav Neykov (5): usb: chipidea: big-endian support usb: chipidea: flags to force usb mode (host/device) usb: chipidea: Don't access OTG related registers usb: chipidea: AR933x platform support for the chipidea driver usb: chipidea: Fix incorrect check of function

[PATCH 4/5] usb: chipidea: AR933x platform support for the chipidea driver

Support host and device usb modes for the chipidea controller in AR933x. The controller doesn't support OTG functionality so the platform code forces one of the modes based on the state of GPIO13 pin at startup. Signed-off-by: Svetoslav Neykov svetos...@neykov.name --- arch/mips/ath79/dev-usb.c

[PATCH v2] Add USB of helpers and use them in the chipidea driver

changes since v1: - move phy specific of helper to drivers/usb/phy/of.c - use strcmp instead of strcasecmp for matching property values - change usb_phy_dr_mode to usb_dr_mode - change USBPHY_INTERFACE_MODE_NA to USBPHY_INTERFACE_MODE_UNKNOWN - add copyright header to new files - chipidea: drop

[PATCH] Add USB of helpers and use them in the chipidea driver

This is the 2nd version of the USB of helper patch, this time with adding support for the chipidea driver for the new properties. Kishon, I decided against adding an extra Kconfig option for the OF helpers since I found out the USB stuff already has enough options ;) The helpers are now in usb

Re: Need review for chipidea driver

On 24 January 2013 05:15, Chen Peter-B29397 b29...@freescale.com wrote: Sorry, forget to cc the list Hi Greg, Alex has no response for chipidea driver review for long time (more than 1 month), below are some links about patchset. Does anyone else can help do it? Sorry for that. Looking

RE: Need review for chipidea driver

Sorry, forget to cc the list Hi Greg, Alex has no response for chipidea driver review for long time (more than 1 month), below are some links about patchset. Does anyone else can help do it? http://marc.info/?t=13540330436r=1w=2 http://marc.info/?l=linux-usbm=135873754825186w=2

About OTG operation for chipidea driver

Hi Alex, At current chipidea driver, we have not implemented struct usb_otg, so when udc calls otg_set_peripheral, it will fail. (udc_start at drivers/usb/chipidea/udc.c). In fact, if both host and device use chipidea driver, we do not need to call otg_set_peripheral at all at current chipidea

Re: chipidea driver

Greg KH gre...@linuxfoundation.org writes: On Fri, Aug 24, 2012 at 10:09:11AM +0800, Richard Zhao wrote: On Thu, Aug 23, 2012 at 06:57:03PM +0200, Marc Kleine-Budde wrote: Hello, Michael and I have a bunch of updates and improvement for the chipidea driver. They apply to Richard's tree

Re: chipidea driver

for the chipidea driver. They apply to Richard's tree: https://github.com/riczhao/kernel-imx/commits/topics/usb-driver What's the status of these patches? It would be fine if someone queues them for upstream. My patches is pending on Alex to review. The otg patch series was sent on Jul 12. I don't

Re: chipidea driver

: Hello, Michael and I have a bunch of updates and improvement for the chipidea driver. They apply to Richard's tree: https://github.com/riczhao/kernel-imx/commits/topics/usb-driver What's the status of these patches? It would be fine if someone queues them for upstream. My

Re: chipidea driver

On 09/06/2012 04:02 PM, Greg KH wrote: Indeed there's a pile of patches, I'm going through them right now, Marc already has my acks. We should probably agree if I should collect them all before sending to you or if guys can send them to you directly (as soon as we agree on acks). The fixes

Re: chipidea driver

On Thu, Sep 06, 2012 at 04:09:58PM +0200, Marc Kleine-Budde wrote: On 09/06/2012 04:02 PM, Greg KH wrote: Indeed there's a pile of patches, I'm going through them right now, Marc already has my acks. We should probably agree if I should collect them all before sending to you or if guys can

Re: chipidea driver

On Fri, Aug 24, 2012 at 10:09:11AM +0800, Richard Zhao wrote: On Thu, Aug 23, 2012 at 06:57:03PM +0200, Marc Kleine-Budde wrote: Hello, Michael and I have a bunch of updates and improvement for the chipidea driver. They apply to Richard's tree: https://github.com/riczhao/kernel-imx

Re: chipidea driver

On Fri, Aug 24, 2012 at 10:34:37AM +0300, Alexander Shishkin wrote: Richard Zhao richard.z...@freescale.com writes: On Thu, Aug 23, 2012 at 06:57:03PM +0200, Marc Kleine-Budde wrote: Hello, Hi, Michael and I have a bunch of updates and improvement for the chipidea driver

Re: chipidea driver

Richard Zhao richard.z...@freescale.com writes: On Thu, Aug 23, 2012 at 06:57:03PM +0200, Marc Kleine-Budde wrote: Hello, Hi, Michael and I have a bunch of updates and improvement for the chipidea driver. They apply to Richard's tree: https://github.com/riczhao/kernel-imx/commits/topics

chipidea driver

Hello, Michael and I have a bunch of updates and improvement for the chipidea driver. They apply to Richard's tree: https://github.com/riczhao/kernel-imx/commits/topics/usb-driver What's the status of these patches? It would be fine if someone queues them for upstream. regards, Marc

Re: chipidea driver

On Thu, Aug 23, 2012 at 06:57:03PM +0200, Marc Kleine-Budde wrote: Hello, Michael and I have a bunch of updates and improvement for the chipidea driver. They apply to Richard's tree: https://github.com/riczhao/kernel-imx/commits/topics/usb-driver What's the status of these patches