Now that twl4030-usb is adapted to the new generic PHY framework,
*set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on and
power_off 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
Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break
Used the generic PHY framework API to create the PHY. For powering on
and powering off the PHY, power_on and power_off ops are used. Once the
MUSB OMAP glue is adapted to the new framework, the suspend and resume
ops of usb phy library will be removed.
However using the old usb phy library cannot
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.
The PHY binding information can be found at
In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy device name) should be added in the platform
data of the controller.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
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. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.
PHY drivers should create the PHY by
Separate the ST OHCI SPEAr host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Acked-by: Alan
Separate the TI OHCI OMAP1/2 host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Felipe
Separate the TI OHCI Atmel host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd
Separate the Samsung OHCI S3C host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd
Separate the TI OHCI OMAP3 host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Anand
These patches are for separating the SOC On-Chip ohci host controller
from ohci-hcd host code into its own driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.
V2:
In patch 5/6 and 6/6:
-Set non-standard fields in hc_driver manually,
Separate the Samsung OHCI EXYNOS host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_ep93xx_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Suspend scenario in case of ohci-at91 glue was not properly
handled as it was not suspending generic part of ohci controller.
Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend()
will ensure proper handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Suspend scenario in case of OHCI was not properly
handled in ochi_suspend()routine. This does proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Acked-by: Alan Stern st...@rowland.harvard.edu
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Suspend scenario in case of ohci bus glue was not properly handled as
it was not suspending generic part of ohci controller. Calling
explicitly the ohci_suspend()routine will ensure proper handling
of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without executing
Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspend() will ensure
proper handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Suspend scenario in case of ohci-omap glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_omap_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Suspend scenario in case of ohci-exynos glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in exynos_ohci_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Suspend scenario in case of ohci-pxa27x glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_pxa27x_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in spear_ohci_hcd_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Suspend scenario in case of ohci-sm501 glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_sm501_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Suspend scenario in case of ohci-platform glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_platform_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
it does not compile since 09fc7d (usb: musb: fix incorrect usage of
resource pointer). What makes me wonder most is if source of the
Tested-by tag :)
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
Greg, this is against your usb-next tree.
From: Andrzej Pietrasiewicz andrze...@samsung.com
Converting to configfs requires making the f_mass_storage.c a module.
But first we need to get rid of #include storage_common.c.
This patch makes storage_common.c a separately compiled file, which is
built as a utility module named u_ms.ko. After
From: Andrzej Pietrasiewicz andrze...@samsung.com
Add a method to unregister the gadget using its config_item.
Add a method to query the registered status using config_item.
There can be functions (e.g. mass storage), which in some circumstances
need the gadget stopped. Add a method of stopping
From: Andrzej Pietrasiewicz andrze...@samsung.com
Converting mass storage to the new function interface requires converting
the USB mass storage's function code and its users.
This patch converts the f_mass_storage.c to the new function interface.
The file is now compiled into a separate
From: Andrzej Pietrasiewicz andrze...@samsung.com
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Hello All,
Andrzej Pietrasiewicz, who has been working on configfs support for usb
gadgets for a last few months, went for holidays this week. He asked me
to post his initial patches adding configs support to mass storage usb
function.
The patches are based on latest usb-next kernel free from
From: Andrzej Pietrasiewicz andrze...@samsung.com
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
From: Andrzej Pietrasiewicz andrze...@samsung.com
This is needed to prepare for configfs integration.
So far the luns have been allocated during gadget's initialization, based
on the nluns module parameter's value; the exact number is known when the
gadget is initialized and that number of luns
From: Andrzej Pietrasiewicz andrze...@samsung.com
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
From: Andrzej Pietrasiewicz andrze...@samsung.com
This will be required by configfs integration.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/storage_common.c | 41 +++
From: Andrzej Pietrasiewicz andrze...@samsung.com
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
From: Andrzej Pietrasiewicz andrze...@samsung.com
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
From: Andrzej Pietrasiewicz andrze...@samsung.com
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
From: Andrzej Pietrasiewicz andrze...@samsung.com
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
From: Andrzej Pietrasiewicz andrze...@samsung.com
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
From: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/f_mass_storage.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff
From: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../ABI/testing/configfs-usb-gadget-mass-storage | 31 ++
drivers/usb/gadget/Kconfig | 11 +
From: Andrzej Pietrasiewicz andrze...@samsung.com
When configfs is in place, the things related to intialization
of struct fsg_common will be split over a number of places.
This patch adds several functions which together cover the former
intialization routine fsg_common_init. As a consequence,
From: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/Kconfig|1 +
drivers/usb/gadget/mass_storage.c | 107 +++--
2
From: Andrzej Pietrasiewicz andrze...@samsung.com
Show/store methods for sysfs attributes contain code which can be used
also by configfs. Make them abstract the source the lun and rw_semaphore
are taken from.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin
From: Andrzej Pietrasiewicz andrze...@samsung.com
In order to prepare for the new function interface the f_mass_storage.c
needs to be compiled as a module, and so a header file will be required.
This patch factors out some code to a new f_mass_storage.h.
Signed-off-by: Andrzej Pietrasiewicz
Hello Greg,
Am 24.06.2013 20:56, schrieb Greg KH:
But wiring that up to a real 9pin serial port would be a pain (doable,
but a pain). Is there any devices out there with a DB-9 output
connector?
You mean if you want to test full handshake with all signals - that's true.
Which is what the
Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
drivers/usb/gadget/at91_udc.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git
Am 24.06.2013 21:00, schrieb Greg KH:
Personally, I have resolved to abandon the PL2303 chip, and move to
FTDI instead. But for the sake of other Linux users who might buy that
adapter by mistake, I am willing to donate the hardware to an able
kernel hacker :-)
Yes, I recommend the ftdi devices
On 06/25/2013 01:42 AM, Greg Kroah-Hartman wrote:
On Wed, Jun 19, 2013 at 08:50:08AM +0200, Jiri Slaby wrote:
On 06/18/2013 06:04 PM, Greg Kroah-Hartman wrote:
So currently I have what is attached... Comments?
Looks good to me, want me to queue it up through my char/misc driver
tree for
Fabio Estevam fabio.este...@freescale.com writes:
commit ea1418b5f1a (usb: chipidea: i.MX: use devm_usb_get_phy_by_phandle to
get
phy) causes the USB host to miss the disconnect/connect events.
In order to reproduce this problem:
- Insert a USB thumb into the USB host port (connection is
Hi,
Here is one more fix for the usb-next.
Fabio Estevam (1):
usb: chipidea: ci_hdrc_imx: access phy via private data
drivers/usb/chipidea/ci_hdrc_imx.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
--
1.7.10.4
--
To unsubscribe from this list: send the line
From: Fabio Estevam fabio.este...@freescale.com
commit ea1418b5f1a (usb: chipidea: i.MX: use devm_usb_get_phy_by_phandle to get
phy) causes the USB host to miss the disconnect/connect events.
In order to reproduce this problem:
- Insert a USB thumb into the USB host port (connection is
Hi Greg,
coincidentally, I also tested non-standard baudrates on a PL2303 these
days and was about to start a similar thread when I found this one...
On Fri, 14 Jun 2013 at 18:58, Greg KH wrote:
On Fri, Jun 14, 2013 at 11:20:01AM +0200, Mastro Gippo wrote:
PS: this device (at least mine)
On Tue, Jun 25, 2013, Greg KH gre...@linuxfoundation.org said:
On Fri, Jun 21, 2013 at 03:01:04PM +0530, navin patidar wrote:
pr_warn() is preferred over pr_warning().
And dev_warn() is preferred over both of them, can you convert the code
to use that instead?
struct device is not
Hi,
I am seeing that with an acquisition board:
[27044.406737] usb 4-4.4: usb_probe_device
[27044.406739] usb 4-4.4: configuration #1 chosen from 1 choice
[27044.406803] usb 4-4.4: Successful Endpoint Configure command
[27044.418946] usb 4-4.4: Successful evaluate context command
[27044.421725]
On Mon, Jun 24, 2013 at 11:17 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 24 Jun 2013, Ming Lei wrote:
This patch implements the mechanism of giveback of URB in
tasklet context, so that hardware interrupt handling time for
usb host controller can be saved much, and HCD interrupt
On Tue, Jun 25, 2013 at 2:53 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 24 Jun 2013, Ming Lei wrote:
Given interrupt URB will be resubmitted from tasklet context which
is scheduled by ehci hardware interrupt handler, and commonly only
one interrupt URB is scheduled on qh, so the
On Tue, Jun 25, 2013 at 12:26 AM, Alan Stern st...@rowland.harvard.edu wrote:
Other than usbtest, the only driver using SG that I know of is
usb-storage, and it does make that assumption. It works because the
Another example is usbfs driver, which sets the SG size as 16KB and also
makes the
Hello.
On 25-06-2013 11:41, Sebastian Andrzej Siewior wrote:
it does not compile since 09fc7d (usb: musb: fix incorrect usage of
resource pointer). What makes me wonder most is if source of the
Tested-by tag :)
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sebastian Andrzej Siewior
USB spec stats that short packet can only appear at the end
of transfer. Because lost of HC(EHCI/UHCI/OHCI/...) can't
build a full packet from discontinuous buffers, we introduce
the limit in usb_submit_urb() to avoid such kind of bad sg
coming from driver.
The limit might be a bit strict:
Hi ... I'm using an ARM Samsung S3C24XX processor with a 3.1.10 kernel.
I'm interested in creating medical equipment using Linux and came onto
an issue today. I've created an application that connects to two FTDI
devices and reads continuous data from a medical sensor. I have a
custom based
On 06/24/2013 10:36 PM, Felipe Balbi wrote:
On Thu, Jun 20, 2013 at 01:25:31PM -0400, Alan Stern wrote:
On Thu, 20 Jun 2013, Felipe Balbi wrote:
In fact, the PHY setting and handling is related to platform or SOC,
and for different SOC they can
have same EHCI HCD but they PHY handling can be
On Tue, Jun 25, 2013 at 04:37:11PM +0300, Roger Quadros wrote:
On 06/24/2013 10:36 PM, Felipe Balbi wrote:
On Thu, Jun 20, 2013 at 01:25:31PM -0400, Alan Stern wrote:
On Thu, 20 Jun 2013, Felipe Balbi wrote:
In fact, the PHY setting and handling is related to platform or SOC,
and for
On 06/24/2013 10:34 PM, Alan Stern wrote:
On Mon, 24 Jun 2013, Roger Quadros wrote:
OK I've tried to handle all this in an alternate way. Now the controller
suspend/resume
and runtime suspend/resume is independent of bus suspend.
The controller now runtime suspends when all devices on the
On Mon, Jun 24, 2013 at 10:51 AM, Marek Vasut ma...@denx.de wrote:
Fabio, can you possibly test on MX23EVK please?
I never used USB gadget with chipidea driver.
Could you please explain what are the changes I need to do in the dts
file (I want to try on mx28evk first) and defconfig in order to
Hi Sarah,
I am seeing a few webcams that work only on EHCI. The XHCI is in principle
functional. Other webcams do work. Do you have any idea what to do in such
a case? The cameras are high-speed devices. The camera is detected, but yields
no pictures.
I do have traces but they are rather large.
On Tue, 25 Jun 2013, raespi wrote:
Hi ... I'm using an ARM Samsung S3C24XX processor with a 3.1.10 kernel.
I'm interested in creating medical equipment using Linux and came onto
an issue today. I've created an application that connects to two FTDI
devices and reads continuous data from a
On Tue, 25 Jun 2013, Oliver Neukum wrote:
Hi Sarah,
I am seeing a few webcams that work only on EHCI. The XHCI is in principle
functional. Other webcams do work. Do you have any idea what to do in such
a case? The cameras are high-speed devices. The camera is detected, but
yields no
On Tuesday 25 June 2013 10:29:06 Alan Stern wrote:
On Tue, 25 Jun 2013, Oliver Neukum wrote:
Hi Sarah,
I am seeing a few webcams that work only on EHCI. The XHCI is in principle
functional. Other webcams do work. Do you have any idea what to do in such
a case? The cameras are
On 06/25/2013 10:26 AM, Alan Stern wrote:
On Tue, 25 Jun 2013, raespi wrote:
On my board I can't hook up my application again to the new address
since it's the only parameter identifiable by it. Both FTDI Devices
have the same product and vendor numbers:
Bus 001 Device 003: ID 0403:6001
Bus
On Mon, 24 Jun 2013, Daniel Santos wrote:
I submit an out URB (to rx my response)
No, an OUT URB transfers data _out_ from the computer to the device.
The response goes from the device _in_ to the computer.
I sure do appreciate this because I was initially confused about this
and am
On Tue, 25 Jun 2013, Ming Lei wrote:
+
+ spin_lock(bh-lock);
+ list_add_tail(urb-urb_list, bh-head);
+ if (bh-running)
+ sched = 0;
+ else
+ sched = 1;
+ spin_unlock(bh-lock);
How about calling this variable running instead of sched?
On Tue, Jun 25, 2013 at 04:27:18PM +0530, navin patidar wrote:
On Tue, Jun 25, 2013, Greg KH gre...@linuxfoundation.org said:
On Fri, Jun 21, 2013 at 03:01:04PM +0530, navin patidar wrote:
pr_warn() is preferred over pr_warning().
And dev_warn() is preferred over both of them, can you
On Tue, 25 Jun 2013, Ming Lei wrote:
On Tue, Jun 25, 2013 at 2:53 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 24 Jun 2013, Ming Lei wrote:
Given interrupt URB will be resubmitted from tasklet context which
is scheduled by ehci hardware interrupt handler, and commonly only
On Tue, 25 Jun 2013, Ming Lei wrote:
USB spec stats that short packet can only appear at the end
of transfer. Because lost of HC(EHCI/UHCI/OHCI/...) can't
build a full packet from discontinuous buffers, we introduce
the limit in usb_submit_urb() to avoid such kind of bad sg
coming from
On Tue, 25 Jun 2013, Oliver Neukum wrote:
On Tuesday 25 June 2013 10:29:06 Alan Stern wrote:
On Tue, 25 Jun 2013, Oliver Neukum wrote:
Hi Sarah,
I am seeing a few webcams that work only on EHCI. The XHCI is in principle
functional. Other webcams do work. Do you have any idea
Hi all,
With the release of the 3.10-rc7 kernel, I think it's time to close the
USB tree for new features / cleanups for 3.11. So I'm closing my
tree, and will only be applying obvious bugfixes or regressions to it
until 3.11-rc1 comes out.
You can keep sending me patches for the tree that
Hi,
On Tue, Jun 25, 2013 at 11:28:39AM +0530, Kishon Vijay Abraham I wrote:
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
new file mode 100644
index 000..7abf573
--- /dev/null
+++ b/include/linux/phy/phy.h
on this header, how about adding phy_set_drvdata() and
On Tue, Jun 25, 2013 at 11:28:43AM +0530, Kishon Vijay Abraham I wrote:
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.
The PHY binding
On Tue, Jun 25, 2013 at 11:28:40AM +0530, Kishon Vijay Abraham I wrote:
Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.
However using the old USB PHY library cannot be completely removed
On Tue, Jun 25, 2013 at 11:28:41AM +0530, Kishon Vijay Abraham I wrote:
Used the generic PHY framework API to create the PHY. For powering on
and powering off the PHY, power_on and power_off ops are used. Once the
MUSB OMAP glue is adapted to the new framework, the suspend and resume
ops of
On Tue, Jun 25, 2013 at 11:28:42AM +0530, Kishon Vijay Abraham I wrote:
In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy device name) should be added in the platform
data of the controller.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
On Tue, Jun 25, 2013 at 11:28:45AM +0530, Kishon Vijay Abraham I wrote:
Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
On Tue, Jun 25, 2013 at 11:28:44AM +0530, Kishon Vijay Abraham I wrote:
Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on and
power_off to align with the new PHY framework.
musb-xceiv can't be removed as of now because
On Tue, Jun 25, 2013 at 11:28:46AM +0530, Kishon Vijay Abraham I wrote:
Now that twl4030-usb is adapted to the new generic PHY framework,
*set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Reviewed-by: Felipe Balbi
On Tue, Jun 25, 2013 at 11:21:43AM -0400, Alan Stern wrote:
On Tue, 25 Jun 2013, Greg KH wrote:
Hi all,
With the release of the 3.10-rc7 kernel, I think it's time to close the
USB tree for new features / cleanups for 3.11. So I'm closing my
tree, and will only be applying obvious
On Tue, 25 Jun 2013, raespi wrote:
On 06/25/2013 10:26 AM, Alan Stern wrote:
On Tue, 25 Jun 2013, raespi wrote:
On my board I can't hook up my application again to the new address
since it's the only parameter identifiable by it. Both FTDI Devices
have the same product and vendor
On Tue, 25 Jun 2013, Greg KH wrote:
Hi all,
With the release of the 3.10-rc7 kernel, I think it's time to close the
USB tree for new features / cleanups for 3.11. So I'm closing my
tree, and will only be applying obvious bugfixes or regressions to it
until 3.11-rc1 comes out.
You can
This patch adds OF match table to the driver to allow instantiating it
using device tree.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/usb/samsung-hsotg.txt | 40 ++
This patch adds device tree nodes for USB OTG PHYs of Exynos4210 and
Exynos4x12 SoCs.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4210.dtsi | 15 +++
arch/arm/boot/dts/exynos4x12.dtsi | 15
This series enables platforms booting with Device Tree to use the Samsung
HSOTG IP. Since USB PHY support has been already added, it's just a matter
of adding an OF match table to the driver and respective device tree nodes
to dts files.
[On Samsung Trats board based on Exynos 4210]
Tested-by:
This patch adds device tree nodes necessary to enable USB gadget
functionality on Exynos4210-based Trats board.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4210-trats.dts | 10 ++
1 file changed, 10
On Tue, Jun 25, 2013 at 11:23 AM, Fabio Estevam feste...@gmail.com wrote:
On Mon, Jun 24, 2013 at 10:51 AM, Marek Vasut ma...@denx.de wrote:
Fabio, can you possibly test on MX23EVK please?
I never used USB gadget with chipidea driver.
Could you please explain what are the changes I need to
This patch adds device tree node for USB HSOTG controller present on
Exynos4 SoCs.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git
On Tue, Jun 25, 2013 at 09:25:50AM -0400, raespi wrote:
Hi ... I'm using an ARM Samsung S3C24XX processor with a 3.1.10
kernel.
Note, this is a very old and unsupported kernel version, you really
should consider upgrading, or getting support for these types of issues
from the vendor that is
convert all debug messages from printk to dev_dbg() add kernel config to
enable/disable these messages during compilation.
Signed-off-by: Rupesh Gujare rupesh.guj...@atmel.com
---
drivers/staging/ozwpan/Kbuild|2 +-
drivers/staging/ozwpan/Kconfig |9 +
On Tue, 2013-06-25 at 17:30 +0100, Rupesh Gujare wrote:
convert all debug messages from printk to dev_dbg() add kernel config to
enable/disable these messages during compilation.
[]
-#define oz_trace(...) printk(TRACE_PREFIX __VA_ARGS__)
+#define oz_trace(fmt, ...) dev_dbg(g_oz_wpan_dev, fmt,
1 - 100 of 142 matches
Mail list logo
