Changes from v3:
Replaced susbsys_initcall()/module_exit() by module_platform_driver().
Accordingly in the hsotg driver returned -EPROBE_DEFER until phy driver
is registered
Removed unnecessary devm_usb_put_phy() call from the hsotg driver remove.
Changes from v2:
Changed the driver filenames to s
This driver uses usb_phy interface to interact with s3c-hsotg. Supports
phy_init and phy_shutdown functions to enable/disable phy. Tested with
smdk6410 and smdkv310. More SoCs can be brought under later.
Signed-off-by: Praveen Paneri
Acked-by: Heiko Stuebner
---
.../devicetree/bindings/usb/sams
Adding the transceiver to hsotg driver. Keeping the platform data
for continuing the smooth operation for boards which still uses it
Signed-off-by: Praveen Paneri
---
drivers/usb/gadget/s3c-hsotg.c | 37 +++--
1 files changed, 27 insertions(+), 10 deletions(-)
Adding platform device for samsung-usbphy driver. Enabling it for
s3c64xx based machines using s3c-hsotg.
Signed-off-by: Praveen Paneri
---
arch/arm/mach-s3c64xx/include/mach/map.h |2 +
arch/arm/mach-s3c64xx/mach-crag6410.c|4 +++
arch/arm/mach-s3c64xx/mach-smartq.c
This patch removes old phy code from platform side. 'setup-usb-phy.c'
will be used for providing transceiver platform data in next
patch. Not all of the platform data code is removed as there are others
making use of platform_data defined for hsotg. That can be removed once
all the SoCs start using
Adding usbphy node for Exynos4210 along with the platform data.
Signed-off-by: Praveen Paneri
---
arch/arm/boot/dts/exynos4210.dtsi |5 +
arch/arm/mach-exynos/include/mach/map.h |1 +
arch/arm/mach-exynos/mach-exynos4-dt.c |8
arch/arm/mach-exynos/setup-usb-phy.c
From: Ruchika Kharwar
Use the ioremap_nocache variant of the ioremap API in
order to make sure our memory will be marked uncachable.
Signed-off-by: Ruchika Kharwar
Signed-off-by: Felipe Balbi
---
drivers/usb/host/xhci-plat.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --
Hi,
On Fri, Aug 10, 2012 at 12:40:27PM +0530, Praveen Paneri wrote:
> This driver uses usb_phy interface to interact with s3c-hsotg. Supports
> phy_init and phy_shutdown functions to enable/disable phy. Tested with
> smdk6410 and smdkv310. More SoCs can be brought under later.
>
> Signed-off-by:
On Fri, Aug 10, 2012 at 12:40:26PM +0530, Praveen Paneri wrote:
> Changes from v3:
> Replaced susbsys_initcall()/module_exit() by module_platform_driver().
> Accordingly in the hsotg driver returned -EPROBE_DEFER until phy driver
> is registered
> Removed unnecessary devm_usb_put_phy() call from th
On Fri, Aug 10, 2012 at 12:34 PM, Felipe Balbi wrote:
> Hi,
>
> On Fri, Aug 10, 2012 at 12:40:27PM +0530, Praveen Paneri wrote:
>> This driver uses usb_phy interface to interact with s3c-hsotg. Supports
>> phy_init and phy_shutdown functions to enable/disable phy. Tested with
>> smdk6410 and smdkv
Hi,
On Fri, Aug 10, 2012 at 12:40 PM, Praveen Paneri wrote:
> This driver uses usb_phy interface to interact with s3c-hsotg. Supports
> phy_init and phy_shutdown functions to enable/disable phy. Tested with
> smdk6410 and smdkv310. More SoCs can be brought under later.
>
> Signed-off-by: Praveen
In case of ep0 out, if length is not aligned to maxpacket size then we
use dwc->ep_bounce_addr for dma transfer and not request->dma. Since, we
have alreday done memcpy from dwc->ep_bounce to request->buf, so we do
not need to issue cache sync function. Infact, cache sync function will
bring wrong
On Fri, Aug 10, 2012 at 12:36 PM, Felipe Balbi wrote:
> On Fri, Aug 10, 2012 at 12:40:26PM +0530, Praveen Paneri wrote:
>> Changes from v3:
>> Replaced susbsys_initcall()/module_exit() by module_platform_driver().
>> Accordingly in the hsotg driver returned -EPROBE_DEFER until phy driver
>> is reg
On Fri, Aug 10, 2012 at 12:49 PM, ABRAHAM, KISHON VIJAY wrote:
> Hi,
>
> On Fri, Aug 10, 2012 at 12:40 PM, Praveen Paneri wrote:
>> This driver uses usb_phy interface to interact with s3c-hsotg. Supports
>> phy_init and phy_shutdown functions to enable/disable phy. Tested with
>> smdk6410 and smd
Hi,
On Fri, Aug 10, 2012 at 12:54:52PM +0530, Pratyush Anand wrote:
> In case of ep0 out, if length is not aligned to maxpacket size then we
> use dwc->ep_bounce_addr for dma transfer and not request->dma. Since, we
> have alreday done memcpy from dwc->ep_bounce to request->buf, so we do
> not nee
On Fri, Aug 10, 2012 at 12:24 PM, Anton Tikhomirov
wrote:
> Hi Praveen,
>
>> -Original Message-
>> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
>> ow...@vger.kernel.org] On Behalf Of Praveen Paneri
>> Sent: Wednesday, August 08, 2012 4:41 PM
>> To: linux-usb@vger.kernel.org
>>
On Fri, Aug 10, 2012 at 01:04:48PM +0530, Praveen Paneri wrote:
> On Fri, Aug 10, 2012 at 12:36 PM, Felipe Balbi wrote:
> > On Fri, Aug 10, 2012 at 12:40:26PM +0530, Praveen Paneri wrote:
> >> Changes from v3:
> >> Replaced susbsys_initcall()/module_exit() by module_platform_driver().
> >> Accordi
On 8/10/2012 1:07 PM, Felipe Balbi wrote:
Hi,
On Fri, Aug 10, 2012 at 12:54:52PM +0530, Pratyush Anand wrote:
In case of ep0 out, if length is not aligned to maxpacket size then we
use dwc->ep_bounce_addr for dma transfer and not request->dma. Since, we
have alreday done memcpy from dwc->ep_bou
Hi,
On Fri, Aug 10, 2012 at 01:36:42PM +0530, Pratyush Anand wrote:
> On 8/10/2012 1:07 PM, Felipe Balbi wrote:
> >Hi,
> >
> >On Fri, Aug 10, 2012 at 12:54:52PM +0530, Pratyush Anand wrote:
> >>In case of ep0 out, if length is not aligned to maxpacket size then we
> >>use dwc->ep_bounce_addr for d
> > So, the others are usb_state not usb_otg_state. Then, when we
> generalize
> > otg driver, what kinds of **states** do you plan to use to stand for
> otg
> > state machine? Besides, if we name something different with spec, does
> it
> > will confuse the users?
>
> We could have just a singl
In case of ep0 out, if length is not aligned to maxpacket size then we
use dwc->ep_bounce_addr for dma transfer and not request->dma. Since, we
have alreday done memcpy from dwc->ep_bounce to request->buf, so we do
not need to issue cache sync function. Infact, cache sync function will
bring wrong
On Fri, Aug 10, 2012 at 08:12:07AM +, Chen Peter-B29397 wrote:
>
> > > So, the others are usb_state not usb_otg_state. Then, when we
> > generalize
> > > otg driver, what kinds of **states** do you plan to use to stand for
> > otg
> > > state machine? Besides, if we name something different w
>
> > I am a little confused by using phy->state to stand for usb_state that
> I think
> > there is no relationship between usb_state with USB PHY.
>
> well, there's no relationship between usb_state and OTG. The state isn't
> OTG-specific, it's USB specific. This is a difficult detail to find
On Fri, Aug 10, 2012 at 09:02:21AM +, Chen Peter-B29397 wrote:
>
> >
> > > I am a little confused by using phy->state to stand for usb_state that
> > I think
> > > there is no relationship between usb_state with USB PHY.
> >
> > well, there's no relationship between usb_state and OTG. The s
> >
> > In my mind, the system without OTG but using struct usb_phy can still
> > track their states.
> >
> > One thing I am always puzzled of current code is the OTG should be no
> > relationship with USB PHY.
> > The system without OTG but has USB device or host only function should
> > still o
Hello,
The TIOCOUTQ ioctl calls chars_in_buffer(), and
some apps depend on a correct behaviour of that.
mos7840 implements it wrongly: if you write just
one char, TIOCOUTQ will return 32.
The attached patch should fix it.
But it is not tested: customer reported the problem
and fails to test the pa
Add the missing usb controller version info and port0, which is
required during setup usb phy.
Signed-off-by: Shengzhou Liu
---
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
when missing USB PHY clock, kernel booting up will hang during USB
initialization. We should check USBGP[PHY_CLK_VALID] bit to avoid
CPU hanging in this case.
Signed-off-by: Shengzhou Liu
---
drivers/usb/host/ehci-fsl.c | 63 ++
drivers/usb/host/ehci-fsl
On Aug 10, 2012, at 5:48 AM, Shengzhou Liu wrote:
> Add the missing usb controller version info and port0, which is
> required during setup usb phy.
>
> Signed-off-by: Shengzhou Liu
> ---
> arch/powerpc/boot/dts/fsl/p4080si-post.dtsi |7 +++
> 1 files changed, 7 insertions(+), 0 deletion
On Fri, 10 Aug 2012, Venu Byravarasu wrote:
> Existing implementation of tegra_ehci_remove() calls
> usb_put_hcd(hcd) first and then iounmap(hcd->regs).
>
> usb_put_hcd() implementation calls hcd_release()
> which frees up memory allocated for hcd.
>
> As iounmap is trying to unmap hcd->regs, af
With commit 0998d0631001288a5974afc0b2a5f568bcdecb4d, driver_data is
cleared after driver is unbound.
So from now on, it's not suitable to maintain serial port private data
by driver core, because some usb serial drivers,
such as usb_wwan, need retrieve port private data(in disconnect() and
release
On Thu, Aug 9, 2012 at 10:29 PM, Alan Stern wrote:
> In theory a similar quirk could be written to fix your problem. An
> easy way to test this, if you can automatically detect the "hung"
> condition, would be to set ohci->ed_to_check to the "unkillable" ed.
>
I used a very stupid/simplistic log
On Aug 10, 2012, at 5:48 AM, Shengzhou Liu wrote:
> when missing USB PHY clock, kernel booting up will hang during USB
> initialization. We should check USBGP[PHY_CLK_VALID] bit to avoid
> CPU hanging in this case.
>
> Signed-off-by: Shengzhou Liu
> ---
> drivers/usb/host/ehci-fsl.c | 63
On Fri, 10 Aug 2012, Huajun Li wrote:
> With commit 0998d0631001288a5974afc0b2a5f568bcdecb4d, driver_data is
> cleared after driver is unbound.
> So from now on, it's not suitable to maintain serial port private data
> by driver core, because some usb serial drivers,
> such as usb_wwan, need retri
On Fri, 10 Aug 2012, Tomas Sokorai wrote:
> I used a very stupid/simplistic logic I already had for debugging, to
> detect the condition: at the fourth (since its normally just one) pass
> over the SF interrupt clear without being it cleared, I assume it is
> stuck, and if ed_rm_list is the only o
On Thu, 9 Aug 2012, David Ranch wrote:
> Hello Everyone,
>
> I've been researching this specific issue and I'm coming to the
> conclusion my problem is a USB chipset / kernel infrastructure specific
> issue and not a problem with the USB device or it's ALSA driver. If
> anyone has some ideas
On Fri, Aug 10, 2012 at 12:01:46PM -0400, Alan Stern wrote:
> On Fri, 10 Aug 2012, Huajun Li wrote:
>
> > With commit 0998d0631001288a5974afc0b2a5f568bcdecb4d, driver_data is
> > cleared after driver is unbound.
> > So from now on, it's not suitable to maintain serial port private data
> > by driv
Hi,
I'm using an RT3052F device (DIR-620 SOHO wifi router) with current
OpenWrt trunk and its USB port is handled by the dwc_otg driver. The
source is available from their repository:
https://dev.openwrt.org/browser/trunk/target/linux/ramips/files/drivers/usb/dwc_otg
The problem appears when i co
On Sat, Jul 28, 2012 at 10:02:34AM +0900, Masanari Iida wrote:
> Modify printk to pr_info in drivers/usb/class/cdc-acm.c
Why?
This printk should really just be removed entirely, as it's not needed.
Care to do that instead?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubs
On Fri, Aug 10, 2012 at 10:35:20PM +0400, Paul Fertser wrote:
> I've not tried forcing full-speed mode for dwc_otg by hacking the
> sources directly, so no experimental data about it available yet.
By using 1 (full speed) for the default value of the "speed" module
parameter i get a somewhat expec
On Fri, Aug 10, 2012 at 10:35:20PM +0400, Paul Fertser wrote:
> Hi,
>
> I'm using an RT3052F device (DIR-620 SOHO wifi router) with current
> OpenWrt trunk and its USB port is handled by the dwc_otg driver. The
> source is available from their repository:
> https://dev.openwrt.org/browser/trunk/ta
Hi Felipe,
On Fri, Aug 10, 2012 at 10:39:52PM +0300, Felipe Balbi wrote:
> On Fri, Aug 10, 2012 at 10:35:20PM +0400, Paul Fertser wrote:
> > I'm using an RT3052F device (DIR-620 SOHO wifi router) with current
> > OpenWrt trunk and its USB port is handled by the dwc_otg driver. The
> > source is av
On Friday, August 10, 2012, Ming Lei wrote:
> On Fri, Aug 10, 2012 at 3:41 AM, Rafael J. Wysocki wrote:
> >
> > It just isn't guaranteed that the subsystem callback won't do anything
> > after driver->runtime_resume completion. I agree that it isn't likely
> > to happen.
>
> In fact, the subsyst
43 matches
Mail list logo
