Hi,
On Sat, Mar 16, 2013 at 1:49 AM, Felipe Balbi wrote:
> On Fri, Mar 15, 2013 at 11:00:45AM -0400, Alan Stern wrote:
>> On Fri, 15 Mar 2013, Felipe Balbi wrote:
>>
>> > On Fri, Mar 15, 2013 at 04:26:10PM +0800, victor yeo wrote:
>> > > Hi,
>> > >
>> > > > On Fri, Mar 15, 2013 at 01:59:30PM +080
The Kconfig symbol USB_GADGET_NET2272_DMA was renamed to USB_NET2272_DMA
in commit 193ab2a6070039e7ee2b9b9bebea754a7c52fd1b ("usb: gadget: allow
multiple gadgets to be built"). That commit did not convert the only
occurrence of the corresponding Kconfig macro. Convert that macro now.
Signed-off-by
Peter Chen 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 versions
Use the generic PHY framework API to get the PHY. The usb_phy_set_suspend
and usb_phy_set_resume is replaced with phy_suspend and phy_resume to
align with the new PHY framework.
musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state
In order for controllers to get PHY in case of non dt boot, the phy
binding information should be added in the platform specific
initialization code using phy_bind. The previously added usb_bind_phy
can't be removed yet because the musb controller continues to use the
old PHY library which has OTG
Used the generic PHY framework API to create the PHY. twl4030_usb_suspend
and twl4030_usb_resume is added to phy_ops in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new
framework comp
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
shoul
Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/usb/omap-usb.tx
Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle. To obtain a reference to the PHY
without using phandle, the platform specfic intialization code (say from
Used the generic PHY framework API to create the PHY. omap_usb2_suspend
is split into omap_usb_suspend and omap_usb_resume in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framewor
On Wed, Mar 20, 2013 at 09:17:06AM +0800, Peter Chen wrote:
> On Tue, Mar 19, 2013 at 01:02:59PM +0100, Michael Grzeschik wrote:
> > On Tue, Mar 19, 2013 at 09:34:54AM +0800, Peter Chen wrote:
> > > On Mon, Mar 18, 2013 at 03:28:26PM +0100, Michael Grzeschik wrote:
> > > > On Fri, Mar 08, 2013 at 0
On Wed, Mar 20, 2013 at 11:11:09AM +0200, Alexander Shishkin wrote:
> Peter Chen 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
Use proper macro while extracting TRB transfer length from
Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23)
for the same, and use it instead of TRB_LEN (bits 0:16) in
case of event TRBs.
Signed-off-by: Vivek gautam
---
drivers/usb/host/xhci-ring.c | 45 +++-
Hi Sarah,
On Wed, Mar 20, 2013 at 10:17 AM, Vivek Gautam
wrote:
> Hi,
>
>
> On Wed, Mar 20, 2013 at 12:51 AM, Sarah Sharp
> wrote:
>> On Thu, Mar 07, 2013 at 03:38:46PM +0530, Vivek Gautam wrote:
>>> Hi Sarah,
>>>
>>>
>>> While going through the code for Handling Transfer Events
>>> (drivers/us
Peter Chen 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 would
On 03/20/2013 12:04 PM, Alexander Shishkin wrote:
> Peter Chen 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 capabilit
Hi,
On Monday 18 March 2013 05:59 PM, Venu Byravarasu wrote:
The existing Tegra USB bindings have a few issues:
1) Many properties are documented as being part of the EHCI controller
node, yet they apply more to the PHY device. They should be moved.
2) Some registers in PHY1 are shared with PH
Marc Kleine-Budde writes:
> On 03/20/2013 12:04 PM, Alexander Shishkin wrote:
>> Peter Chen 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
Hi,
On Monday 18 March 2013 05:59 PM, Venu Byravarasu wrote:
This patch updates all Tegra board files so that they contain all the
properties required by the updated USB DT binding. Note that this patch
only adds the new properties and does not yet remove the old properties,
in order to maintain
On 03/20/2013 12:23 PM, Alexander Shishkin wrote:
> Marc Kleine-Budde writes:
>
>> On 03/20/2013 12:04 PM, Alexander Shishkin wrote:
>>> Peter Chen writes:
>>>
On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote:
>
>> Eg, for tablet or phone, the dr_mode may be "gadge
> -Original Message-
> From: Venu Byravarasu
> Sent: Wednesday, March 20, 2013 11:30 AM
> To: 'Stephen Warren'
> Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> linux-te...@vger.kernel.org; devicetree-disc
On Wed, Mar 20, 2013 at 03:41:08PM +0800, victor yeo wrote:
> Hi,
>
> On Sat, Mar 16, 2013 at 1:49 AM, Felipe Balbi wrote:
> > On Fri, Mar 15, 2013 at 11:00:45AM -0400, Alan Stern wrote:
> >> On Fri, 15 Mar 2013, Felipe Balbi wrote:
> >>
> >> > On Fri, Mar 15, 2013 at 04:26:10PM +0800, victor yeo
> -Original Message-
> From: kishon [mailto:kis...@ti.com]
> Sent: Wednesday, March 20, 2013 4:49 PM
> To: Venu Byravarasu
> Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> swar...@wwwdotorg.org; linux-te.
> -Original Message-
> From: kishon [mailto:kis...@ti.com]
> Sent: Wednesday, March 20, 2013 4:53 PM
> To: Venu Byravarasu
> Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> swar...@wwwdotorg.org; linux-te.
Hi,
On Tue, Mar 19, 2013 at 10:29:05AM -0600, Stephen Warren wrote:
> I see the following Kconfig warnings in next-20130319:
>
> > warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects USB_ULPI which
> > has unmet direct dependencies (USB_SUPPORT && USB_PHY && ARM)
> > warning: (ARCH_TEGRA_2
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Wednesday, March 20, 2013 1:24 AM
> To: Venu Byravarasu
> Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> linux-te...@vger
On Wed, Mar 20, 2013 at 09:26:03AM +0100, Mark Brown wrote:
> On Wed, Mar 20, 2013 at 08:12:43AM +0200, Felipe Balbi wrote:
> > Due to recent changes to regulator API, all
> > users which don't check regulator_{en,dis}able()'s
> > return value will generate compile warnings.
>
> Should only be ena
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Wednesday, March 20, 2013 1:29 AM
> To: Venu Byravarasu
> Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> linux-te...@vger
On Wed, Mar 20, 2013 at 05:47:46PM +0530, Venu Byravarasu wrote:
> > -Original Message-
> > From: kishon [mailto:kis...@ti.com]
> > Sent: Wednesday, March 20, 2013 4:53 PM
> > To: Venu Byravarasu
> > Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> > ba...@ti.com; linux-usb@vger
> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Wednesday, March 20, 2013 5:55 PM
> To: Venu Byravarasu
> Cc: kishon; gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> swar...@wwwdotorg.o
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Wednesday, March 20, 2013 1:51 AM
> To: Venu Byravarasu
> Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> linux-te...@vger
On Wed, Mar 20, 2013 at 01:27:28PM +0100, Mark Brown wrote:
> On Wed, Mar 20, 2013 at 02:21:15PM +0200, Felipe Balbi wrote:
>
> > Do I get an Acked-by to carry on ?
>
> Sure if you like, I didn't think you needed one.
fair enough, not necessary. I'll carry this one.
cheers
--
balbi
signatur
From: Du Xing duxing2...@gmail.com
In skel_read,the reader blocked in wait_for_completion before submit bulk in
urb.
Using processed_urb is for retaining the completion in the case that
previous interruptible wait in skel_read was interrupted and complete before
next skel_read.
Replacing complet
On Tue, Mar 19, 2013 at 02:22:56PM +0100, Michal Nazarewicz wrote:
> On Tue, Mar 19 2013, oskar.and...@sonymobile.com wrote:
> > The udc_irq service runs the isr_tr_complete_handler which in turn
> > "nukes" the endpoints, including a call to rndis_response_complete,
> > if appropriate. If the rndi
On Sun, Mar 17, 2013 at 08:23:20PM +0200, Grazvydas Ignotas wrote:
> I have a pandora board which has similar musb setup to beagleboard
> (OMAP3530 + TWL4030) and musb never worked well on it for me in mainline.
> Well it usually works if you plug the cable once, but as soon as you start
> repluggi
From: Truls Bengtsson
The udc_irq service runs the isr_tr_complete_handler which in turn
"nukes" the endpoints, including a call to rndis_response_complete,
if appropriate. If the rndis_msg_parser fails here, an error will
be printed using a dev_err call (through the ERROR() macro).
However, if
On Sun, Mar 17, 2013 at 08:23:25PM +0200, Grazvydas Ignotas wrote:
> At least on pandora, STS_VBUS gets set even when VBUS is driven by twl
> itself. Reporting VBUS in this case confuses OMAP musb glue and charger
> driver, so check if OTG VBUS charge pump is on before reporting VBUS
> event to avo
On Wed, Mar 20, 2013 at 02:54:25PM +0200, Felipe Balbi wrote:
> On Sun, Mar 17, 2013 at 08:23:20PM +0200, Grazvydas Ignotas wrote:
> > I have a pandora board which has similar musb setup to beagleboard
> > (OMAP3530 + TWL4030) and musb never worked well on it for me in mainline.
> > Well it usually
On Mon, Mar 18, 2013 at 03:55:29AM -0400, Chao Xie wrote:
> The origianl understanding of clock is wrong. The OTG controller
> only have one clock input.
> Passing clock name by pdata is wrong. The clock is defined by device
> iteself.
>
> Signed-off-by: Chao Xie
please rebase against my 'next'
On Wed, Mar 13, 2013 at 02:17:05PM +0530, Kishon Vijay Abraham I wrote:
> This series has some misc cleanup and fixes. The fix solves the cold
> plug issue in omap3 which some have reported. Developed these patches on
> Linux 3.9-rc2 after applying
> http://www.spinics.net/lists/linux-usb/msg81563
Hi,
On Tue, Mar 19, 2013 at 11:48 PM, Alan Stern wrote:
> On Tue, 19 Mar 2013, Yuan-Hsin Chen wrote:
>
>> > What about the port_status registers? They're not between command and
>> > async_next. If they aren't consistent with EHCI, it makes things a lot
>> > more complicated.
>>
>> fusbh200 has
Marc Kleine-Budde writes:
> On 03/20/2013 12:23 PM, Alexander Shishkin wrote:
>> Marc Kleine-Budde writes:
>>
>>> On 03/20/2013 12:04 PM, Alexander Shishkin wrote:
Peter Chen writes:
> On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote:
>>
>>> Eg, for tabl
From: Fabio Estevam
Building a kernel for imx_v4_v5_defconfig with CONFIG_USB_ULPI disabled, results
in the following error:
arch/arm/mach-imx/built-in.o: In function 'pca100_init':
platform-mx2-emma.c:(.init.text+0x6788): undefined reference to
'otg_ulpi_create'
platform-mx2-emma.c:(.init.text
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
On Mon, Mar 18, 2013 at 02:41:11PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 18-03-2013 12:19, Felipe Balbi wrote:
>
> >with the latest udc_start/udc_stop conversion,
> >too much code was deleted which ended up creating
> >a regression in net2272 and net2280 drivers.
>
> >To fix the regressi
Hello.
On 20-03-2013 17:55, Felipe Balbi wrote:
with the latest udc_start/udc_stop conversion,
too much code was deleted which ended up creating
a regression in net2272 and net2280 drivers.
To fix the regression we revert one hunk of the
original commits.
Signed-off-by: Felipe Balbi
---
Hi,
What is recomended driver to use for a USB device that provides just 2
bulk end-points, in and out, to create a TTY to talk to it? Exact data
formats that are used are application-specific, so only generic IO
TTY-alike device (with no control) is required from the kernel.
Searching through th
On 03/20/13 15:35, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Building a kernel for imx_v4_v5_defconfig with CONFIG_USB_ULPI disabled,
> results
> in the following error:
>
> arch/arm/mach-imx/built-in.o: In function 'pca100_init':
> platform-mx2-emma.c:(.init.text+0x6788): undefined refere
Hi,
what shows lsusb (e.g. what is TTY PID)? What is chip inside? Usually
the chips are either FTDI or something similar, and then ftdi driver
should work (coupled with right parameters for "unsuported" IDs - you
can then propose patch once you will see the device working).
Hope this helps
On Wed, 20 Mar 2013, victor yeo wrote:
> Thanks, i add processing the pending data from FIFO after queue was
> called. The UDC driver can process the SCSI INQUIRY command and SCSI
> READ FORMAT CAPACITIES command now.
>
> In the processing of SCSI READ FORMAT CAPACITIES command, there is
> attent
Felipe Balbi 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
On Wed, 20 Mar 2013, Yuan-Hsin Chen wrote:
> Hi,
>
> On Tue, Mar 19, 2013 at 11:48 PM, Alan Stern
> wrote:
> > On Tue, 19 Mar 2013, Yuan-Hsin Chen wrote:
> >
> >> > What about the port_status registers? They're not between command and
> >> > async_next. If they aren't consistent with EHCI, it
On Tue, 19 Mar 2013, Stephen Warren wrote:
> On 03/19/2013 04:48 PM, Stephen Warren wrote:
> > On 03/19/2013 02:07 PM, Alan Stern wrote:
> ...
> >> A dmesg log with CONFIG_USB_DEBUG enabled would be helpful. We ought
> >> to be able to tell where khubd is getting stuck.
> >
> > Hmmm. Enabling CO
Hi Igor,
On Wed, Mar 20, 2013 at 11:14 AM, Igor Grinberg wrote:
> On 03/20/13 15:35, Fabio Estevam wrote:
>> From: Fabio Estevam
>>
>> Building a kernel for imx_v4_v5_defconfig with CONFIG_USB_ULPI disabled,
>> results
>> in the following error:
>>
>> arch/arm/mach-imx/built-in.o: In function '
OK. Do you know the protocol?
User space - use /proc entries. See Apogee CCD driver for an example,
or ask me, I might be able to reveal parts of MI CCD driver which does
that.
Kernel space - see some existing (FTDI,..) drivers and write your own.
Petr
On Wed, 20 Mar 2013 18:41:41 +0400, Se
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
On Wed, Mar 20, 2013 at 06:04:55PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 20-03-2013 17:55, Felipe Balbi wrote:
>
> >>>with the latest udc_start/udc_stop conversion,
> >>>too much code was deleted which ended up creating
> >>>a regression in net2272 and net2280 drivers.
>
> >>>To fix the
>> What is recomended driver to use for a USB device that provides just
>> 2 bulk end-points, in and out, to create a TTY to talk to it? Exact
>> data formats that are used are application-specific, so only generic IO
>> TTY-alike device (with no control) is required from the kernel.
>> Searching
On Wed, Mar 20, 2013 at 06:04:55PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 20-03-2013 17:55, Felipe Balbi wrote:
>
> >>>with the latest udc_start/udc_stop conversion,
> >>>too much code was deleted which ended up creating
> >>>a regression in net2272 and net2280 drivers.
>
> >>>To fix the
Hi,
On Wed, Mar 20, 2013 at 11:40:10AM -0300, Fabio Estevam wrote:
> >> +#if IS_ENABLED(CONFIG_USB_ULPI)
> >> struct usb_phy *otg_ulpi_create(struct usb_phy_io_ops *ops,
> >> unsigned int flags);
> >> +#else
> >> +static inline struct usb_phy *otg_ulpi_create
On Tue, 19 Mar 2013, Julius Werner wrote:
> > Yes, okay, that's true. If a new USB device is plugged in while the
> > lid is shut, and then the lid is opened very briefly, it's possible
> > that the system could suspend again before the new device's "persist"
> > attribute is updated. Does that
On 03/20/13 16:40, Fabio Estevam wrote:
> Hi Igor,
>
> On Wed, Mar 20, 2013 at 11:14 AM, Igor Grinberg
> wrote:
>> On 03/20/13 15:35, Fabio Estevam wrote:
>>> From: Fabio Estevam
>>>
>>> Building a kernel for imx_v4_v5_defconfig with CONFIG_USB_ULPI disabled,
>>> results
>>> in the following e
p...@kubanek.net writes:
> OK. Do you know the protocol?
Yes, it's just 2 plain raw streams of bytes, in and out, for USB driver
itself. Everything else is application-dependent, as I've alredy wrote.
> User space - use /proc entries. See Apogee CCD driver for an example,
> or ask me, I might be
On Wed, 20 Mar 2013, Sergei Organov wrote:
>
> >> What is recomended driver to use for a USB device that provides just
> >> 2 bulk end-points, in and out, to create a TTY to talk to it? Exact
> >> data formats that are used are application-specific, so only generic IO
> >> TTY-alike device (with
>> What is recomended driver to use for a USB device that provides just
>> 2 bulk end-points, in and out, to create a TTY to talk to it? Exact
>> data formats that are used are application-specific, so only generic IO
>> TTY-alike device (with no control) is required from the kernel.
>> Searching t
p...@kubanek.net writes:
> OK. Do you know the protocol?
>
> User space - use /proc entries. See Apogee CCD driver for an example,
> or ask me, I might be able to reveal parts of MI CCD driver which does
> that.
I actually meant something readily available, something that can create
a simple brid
On Wed, Mar 20, 2013 at 11:04:14AM -0400, Alan Stern wrote:
> On Wed, 20 Mar 2013, Sergei Organov wrote:
>
> >
> > >> What is recomended driver to use for a USB device that provides just
> > >> 2 bulk end-points, in and out, to create a TTY to talk to it? Exact
> > >> data formats that are used a
Alan Stern
writes:
> On Wed, 20 Mar 2013, Sergei Organov wrote:
>
>>
>> >> What is recomended driver to use for a USB device that provides just
>> >> 2 bulk end-points, in and out, to create a TTY to talk to it? Exact
>> >> data formats that are used are application-specific, so only generic IO
Felipe,
On Wednesday 20 March 2013 06:42 PM, Felipe Balbi wrote:
On Wed, Mar 13, 2013 at 02:17:05PM +0530, Kishon Vijay Abraham I wrote:
This series has some misc cleanup and fixes. The fix solves the cold
plug issue in omap3 which some have reported. Developed these patches on
Linux 3.9-rc2 af
On Wed, Mar 20, 2013 at 4:13 PM, Johan Hovold wrote:
> The reason why one shouldn't use the generic driver for a "real"
> usb-serial device is that you cannot control baudrates, etc, and of
> course that the device-driver matching isn't automatic.
>
> For a simple device without any control comman
Please make sure to keep all parties CCed in your replies.
On Wed, Mar 20, 2013 at 07:18:16PM +0400, Sergei Organov wrote:
> Alan Stern
> writes:
>
> > On Wed, 20 Mar 2013, Sergei Organov wrote:
> >
> >>
> >> >> What is recomended driver to use for a USB device that provides just
> >> >> 2 bulk
This reverts commit 27b351c5546008c640b3e65152f60ca74b3706f1.
Calling tty_flip_buffer_push on an unopened tty is legal, so the
driver doesn't need track if port has been opened. Reverting this
allows the entire is_open logic to be removed.
Signed-off-by: Bill Pemberton
---
drivers/usb/serial/q
Use usbhs_init_phys() to register the PHY's RESET regulators
and the NOP PHY devices.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-3630sdp.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm
Use usbhs_init_phys() to register the PHY's RESET regulator
and the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-zoom.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom.c b/arch/arm/mach-omap2/bo
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 71
1 files
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3.dtsi | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4.dtsi | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b
This helper allows board support code to add the PHY's
VCC and RESET regulators which are GPIO controlled as well
as the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/usb-host.c | 160 +++-
arch/arm/mach-omap2/usb.h |9 ++
2 fi
Use usbhs_init_phys() to register the PHY's RESET regulator
and NOP PHY device. VAUX2 supplies the PHY's VCC.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3pandora.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap
Use usbhs_init_phys() to register the PHY's RESET regulator
and the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3stalker.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch
Use usbhs_init_phys() to register the PHY's RESET regulator
and the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-overo.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2
Use usbhs_init_phys() to register the PHY's RESET regulator
and the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3touchbook.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/
Use usbhs_init_phys() to register the PHY's RESET regulators
and the NOP PHY devices.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-igep0020.c | 32 ++--
1 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020
Use usbhs_init_phys() to register the PHY's RESET regulator
and the NOP PHY device. VAUX2 supplies the PHY's VCC.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3evm.c | 25 +
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach
Remove deprecated USBHS platform data.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-devkit8000.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 53056c3..42fbf1e 1
Use usbhs_init_phys() to register the PHY's RESET regulators
and the NOP PHY devices.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-cm-t3517.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/ar
Use usbhs_init_phys() to register the PHY's RESET regulators
and the NOP PHY devices.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-cm-t35.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/ma
Add clk_rate parameter to platform data. If supplied, the
NOP phy driver will program the clock to that rate during probe.
Also add 2 flags, needs_vcc and needs_reset.
If the flag is set and the regulator couldn't be found
then the driver will bail out with -EPROBE_DEFER.
Signed-off-by: Roger Qua
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators and the NOP PHY device.
Get rid of managing the PHY clock as it will be done by the PHY driver.
For that to work we create a clock alias that links the PHY clock name
to the PHY device name.
Signed-off-by: Roger Quadros
---
ar
Hi Tony,
These patches provide the SoC side code required to support
the changes in the OMAP USB Host drivers done in [1], [2] & [3].
Device tree support is added for Beagleboard only. I've removed
Panda device tree support till we have resolved the AUXCLK issue.
NOTE: The first patch needs to b
Use usbhs_init_phys() to register the PHY's RESET regulators
and the NOP PHY devices.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-3430sdp.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators and the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3beagle.c | 32 +-
1 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-
Use usbhs_init_phys() to register the PHY's RESET regulators
and the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-am3517evm.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators and the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-am3517crane.c | 24 ++--
1 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517
On 03/20/2013 02:37 PM, Alexander Shishkin wrote:
> Marc Kleine-Budde writes:
>
>> On 03/20/2013 12:23 PM, Alexander Shishkin wrote:
>>> Marc Kleine-Budde writes:
>>>
On 03/20/2013 12:04 PM, Alexander Shishkin wrote:
> Peter Chen writes:
>
>> On Fri, Mar 15, 2013 at 05:17:08PM
On Wed, Mar 20, 2013 at 05:44:40PM +0200, Roger Quadros wrote:
> Add clk_rate parameter to platform data. If supplied, the
> NOP phy driver will program the clock to that rate during probe.
>
> Also add 2 flags, needs_vcc and needs_reset.
> If the flag is set and the regulator couldn't be found
>
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.
>>
On Wed, Mar 20, 2013 at 08:52:36PM +0530, kishon wrote:
> Felipe,
>
> On Wednesday 20 March 2013 06:42 PM, Felipe Balbi wrote:
> >On Wed, Mar 13, 2013 at 02:17:05PM +0530, Kishon Vijay Abraham I wrote:
> >>This series has some misc cleanup and fixes. The fix solves the cold
> >>plug issue in omap3
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
> >>
* Felipe Balbi [130320 09:00]:
> On Wed, Mar 20, 2013 at 05:44:40PM +0200, Roger Quadros wrote:
> > Add clk_rate parameter to platform data. If supplied, the
> > NOP phy driver will program the clock to that rate during probe.
> >
> > Also add 2 flags, needs_vcc and needs_reset.
> > If the flag i
1 - 100 of 191 matches
Mail list logo
