Re: [PATCH v8 19/22] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
Hi Roger, On Tue, 5 Feb 2013, Roger Quadros wrote: On 01/21/2013 05:03 PM, Paul Walmsley wrote: Hi On Mon, 21 Jan 2013, Roger Quadros wrote: On 01/18/2013 10:27 PM, Paul Walmsley wrote: On Fri, 18 Jan 2013, Roger Quadros wrote: We don't need multiple aliases for the OMAP USB host clocks and neither the dummy clocks so remove them. CC: Paul Walmsley p...@pwsan.com CC: Rajendra Nayak rna...@ti.com CC: Benoit Cousson b-cous...@ti.com CC: Mike Turquette mturque...@linaro.com Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Per Tony's earlier request, you can drop this patch and patch 20 from your series now. I've got them queued for 3.10 or late 3.9 merge window. Should have mentioned it earlier, but just this patch without the rest of the cleanup patches will break USB Host on OMAP3, as the old driver bails out if optional clock nodes are missing. Including patch 20 doesn't seem to cause a problem with OMAP4 though. I've got these two patches queued for merging after your other patches go upstream -- e.g., probably 3.10. Do you foresee any problems with that? FYI, the usbhost patches are already in linux-next. Queued this patch for v3.11; looks like I missed it for v3.10. - Paul -- 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: Proposed modification to PL2303 driver
Hello, I'm working with a PL2303 device and I had an issue with the driver. Basically, I can't set the baudrate to 250kbps, but everything is better explained here: http://stackoverflow.com/questions/1778/prolific-pl2303-serial-port-to-25bps I think that removing lines from 332 to 348 of the driver the device will work even with non-standard (but common in embedded devices) baudrates. Baudrates standards were set a long time ago to use the same clock to generate human-compatible timing, for example with 32.768kHz crystals. Nowadays, crystals come mostly in round numbers, and the Prolific device makes no exception, having a 12MHz clock. In all my embedded project I'm running these non-standard baudrates for that same reason. I don't see any negative effects that may derive from this modification, but please let me know if there are any. Best regards -- 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: [PATCH 1/3] usb: chipidea: add CSR SiRFSoC ci13xxx usb driver
Hi Arnd,
2013/6/9 Arnd Bergmann a...@arndb.de:
On Sunday 09 June 2013 11:25:36 Barry Song wrote:
From: Rong Wang rong.w...@csr.com
CSR SiRF SoCs licensed chipidea ci13xxx USB IP, this patch
makes the chipidea drivers support CSR SiRF SoCS.
It also changes the Kconfig, only compile MSM and IMX if related
drivers are enabled. Otherwise, we always need to enable all
clients of chipidea drivers.
Can't you use the same driver as for imx and make it more generic?
I don't actually see anything in here that is really specific to SiRF
and most of the code is the same as for imx.
it seems you means a common driver like drivers/mmc/host/sdhci-pltfm.c
for mmc host.
it is a good idea.
If there are bits that are truly SiRF specific, at least that can
be a much smaller part I think.
+#define RSC_USB_UART_SHARE 0x0
+#define USB1_MODE_SELBIT(2)
+#define pdev_to_phy(pdev)((struct usb_phy *)platform_get_drvdata(pdev))
+
+static int sirfsoc_vbus_gpio;
What do you need static data for? This seems like a bad idea because it
makes it impossible to support multiple such devices.
this should be attached to the data struct. sorry for my carelessness.
rong did a very good job at first glance, then i took easy and missed
to read one line by one line before i sent and missed some issues.
+struct ci13xxx_sirf_data {
+ struct platform_device *ci_pdev;
+ struct clk *clk;
+};
+
+static inline int ci13xxx_sirf_drive_vbus(int value)
+{
+ return gpio_direction_output(sirfsoc_vbus_gpio, value ? 0 : 1);
+}
+
+static void ci13xxx_sirf_notify_event(struct ci13xxx *ci, unsigned event)
+{
+ switch (event) {
+ case CI13XXX_CONTROLLER_RESET_EVENT:
+ ci13xxx_sirf_drive_vbus(1);
+ break;
+ case CI13XXX_CONTROLLER_STOPPED_EVENT:
+ ci13xxx_sirf_drive_vbus(0);
+ break;
+ default:
+ dev_info(ci-dev, Unknown Event\n);
+ break;
+ }
+}
+
+static struct ci13xxx_platform_data ci13xxx_sirf_platdata = {
+ .name = ci13xxx_sirf,
+ .flags = CI13XXX_DISABLE_STREAMING,
+ .capoffset = DEF_CAPOFFSET,
+ .notify_event = ci13xxx_sirf_notify_event,
+};
+
+static struct of_device_id rsc_ids[] = {
+ { .compatible = sirf,prima2-rsc, },
+ { /* sentinel */ }
+};
This is the reset controller, right? You already use the reset API
below, why do you need to open-code the gpio
it's not reset controller. this is a Resource Sharing Control Module
involved with pinmux, we have sirf pinctrl driver, so we should move
to that.
here the problem is the driver is still hardcoding the pinmux between
uart and usb.
+static int ci13xxx_sirf_probe(struct platform_device *pdev)
+{
+ struct platform_device *plat_ci, *phy_pdev;
+ struct device_node *rsc_np, *phy_np;
+ struct ci13xxx_sirf_data *data;
+ struct usb_phy *phy;
+ void __iomem *rsc_vbase;
+ int ret;
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev, Failed to allocate ci13xxx_sirf_data!\n);
+ return -ENOMEM;
+ }
+
+ /* 1. set usb controller clock */
+ data-clk = devm_clk_get(pdev-dev, NULL);
+ if (IS_ERR(data-clk)) {
+ dev_err(pdev-dev,
+ Failed to get clock, err=%ld\n, PTR_ERR(data-clk));
+ return PTR_ERR(data-clk);
+ }
+ ret = clk_prepare_enable(data-clk);
+ if (ret) {
+ dev_err(pdev-dev,
+ Failed to prepare or enable clock, err=%d\n, ret);
+ return ret;
+ }
+
+ /* 2. software reset */
+ ret = device_reset(pdev-dev);
+ if (ret)
+ dev_info(pdev-dev,
+ Failed to reset device, err=%d\n, ret);
+
+ /* 3. vbus configuration */
+ sirfsoc_vbus_gpio = of_get_named_gpio(pdev-dev.of_node,
+ vbus-gpios, 0);
+ if (sirfsoc_vbus_gpio 0) {
+ dev_err(pdev-dev, Can't get vbus gpio from DT\n);
+ ret = -ENODEV;
+ goto err;
+ }
+ ret = gpio_request(sirfsoc_vbus_gpio, ci13xxx_sirf);
+ if (ret) {
+ dev_err(pdev-dev, Failed to get gpio control\n);
+ goto err;
+ }
+
This seems totally generic so far, better put it into a common file.
not so generic, it seems. i think we might need some comments here to
explain why.
+ /* 4. rsc control */
+ rsc_np = of_find_matching_node(NULL, rsc_ids);
+ if (!rsc_np) {
+ dev_err(pdev-dev, Failed to get rsc device node\n);
+ ret = -ENODEV;
+ goto err;
+ }
+ rsc_vbase = of_iomap(rsc_np, 0);
+ if (!rsc_vbase) {
+ dev_err(pdev-dev, Failed to iomap rsc memory\n);
+ ret = -ENOMEM;
+
Re: Proposed modification to PL2303 driver
On Sun, 9 Jun 2013 10:38:01 +0200 Mastro Gippo gip...@gmail.com wrote: Hello, I'm working with a PL2303 device and I had an issue with the driver. Basically, I can't set the baudrate to 250kbps, but everything is better explained here: http://stackoverflow.com/questions/1778/prolific-pl2303-serial-port-to-25bps I think that removing lines from 332 to 348 of the driver the device will work even with non-standard (but common in embedded devices) baudrates. Baudrates standards were set a long time ago to use the same clock to generate human-compatible timing, for example with 32.768kHz crystals. Nowadays, crystals come mostly in round numbers, and the Prolific device makes no exception, having a 12MHz clock. In all my embedded project I'm running these non-standard baudrates for that same reason. It's also worth pointing out that lighting control via DMX512 runs at 250kbps (RS485, unidirectional), so being able to select that rate on USB-serial adaptors would make a fair amount of weird and wonderful (expensive!) converter hardware unnecessary. I can't comment on whether the driver change makes this possible, though! Richard -- 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
[RFC PATCH 2/4] USB: EHCI: don't release ehci-lock if URB giveback in tasklet context
If HCD_BH is set for HC driver's flags, URB giveback will be done in tasklet context instead of interrupt context, so the ehci-lock needn't to be released any more before calling usb_hcd_giveback_urb(). Cc: Alan Stern st...@rowland.harvard.edu Signed-off-by: Ming Lei ming@canonical.com --- drivers/usb/host/ehci-q.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c index d34b399..0387a81 100644 --- a/drivers/usb/host/ehci-q.c +++ b/drivers/usb/host/ehci-q.c @@ -283,9 +283,11 @@ __acquires(ehci-lock) /* complete() can reenter this HCD */ usb_hcd_unlink_urb_from_ep(ehci_to_hcd(ehci), urb); - spin_unlock (ehci-lock); + if (!hcd_giveback_urb_in_bh(ehci_to_hcd(ehci))) + spin_unlock(ehci-lock); usb_hcd_giveback_urb(ehci_to_hcd(ehci), urb, status); - spin_lock (ehci-lock); + if (!hcd_giveback_urb_in_bh(ehci_to_hcd(ehci))) + spin_lock(ehci-lock); } static int qh_schedule (struct ehci_hcd *ehci, struct ehci_qh *qh); -- 1.7.9.5 -- 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
[RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
Hi, The patchset supports to run giveback of URB in tasklet context, so that DMA unmapping/mapping on transfer buffer and compelte() callback can be run with interrupt enabled, then time of HCD interrupt handler can be saved much. Also this approach may simplify HCD since HCD lock needn't be released any more before calling usb_hcd_giveback_urb(). The patchset enables the mechanism on EHCI HCD. Patch 3/4 improves interrupt qh unlink on EHCI HCD when the mechanism is introduced. In the commit log of patch 4/4, detailed test result on three machines (ARM A9/A15 dual core, X86) are provided about transfer performance and ehci irq handling time. From the result, no transfer performance loss is found and ehci irq handling time can drop much with the patchset. drivers/usb/core/hcd.c| 170 +++-- drivers/usb/host/ehci-fsl.c |2 +- drivers/usb/host/ehci-grlib.c |2 +- drivers/usb/host/ehci-hcd.c | 18 ++-- drivers/usb/host/ehci-hub.c |1 + drivers/usb/host/ehci-mv.c|2 +- drivers/usb/host/ehci-octeon.c|2 +- drivers/usb/host/ehci-pmcmsp.c|2 +- drivers/usb/host/ehci-ppc-of.c|2 +- drivers/usb/host/ehci-ps3.c |2 +- drivers/usb/host/ehci-q.c |6 +- drivers/usb/host/ehci-sched.c | 60 - drivers/usb/host/ehci-sead3.c |2 +- drivers/usb/host/ehci-sh.c|2 +- drivers/usb/host/ehci-tegra.c |2 +- drivers/usb/host/ehci-tilegx.c|2 +- drivers/usb/host/ehci-timer.c | 43 ++ drivers/usb/host/ehci-w90x900.c |2 +- drivers/usb/host/ehci-xilinx-of.c |2 +- drivers/usb/host/ehci.h |3 + include/linux/usb/hcd.h | 16 21 files changed, 295 insertions(+), 48 deletions(-) Thanks, -- Ming Lei -- 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
[RFC PATCH 4/4] USB: EHCI: support running URB giveback in tasklet context
Both 4 transfers can work well on EHCI HCD after switching to run
URB giveback in tasklet context, so mark all HCD drivers to support
it.
From below test results on 3 machines(2 ARM and one x86), time
consumed by EHCI interrupt handler droped much without performance
loss.
1 test description
1.1 mass storage performance test:
- run below command 10 times and compute the average performance
dd if=/dev/sdN iflag=direct of=/dev/null bs=200M count=1
- two usb mass storage device:
A: sandisk extreme USB 3.0 16G(used in test case 1 case 2)
B: kingston DataTraveler G2 4GB(only used in test case 2)
1.2 uvc function test:
- run one simple capture program in the below link
http://kernel.ubuntu.com/~ming/up/capture.c
- capture format 640*480 and results in High Bandwidth mode on the
uvc device: Z-Star 0x0ac8/0x3450
- on T410(x86) laptop, also use guvcview to watch video capture/playback
1.3 about test2 and test4
- both two devices involved are tested concurrently by above test items
1.4 how to compute irq time(the time consumed by ehci_irq)
- use trace points of irq:irq_handler_entry and irq:irq_handler_exit
1.5 kernel
3.10.0-rc3-next-20130528
1.6 test machines
Pandaboard A1: ARM CortexA9 dural core
Arndale board: ARM CortexA15 dural core
T410: i5 CPU 2.67GHz quad core
2 test result
2.1 test case1: single mass storage device performance test
upstream| patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
Pandaboard A1: 25.690(avg:144,max:818) | 25.620(avg:14, max:77)
Arndale board: 29.700(avg:29, max:123) | 29.700(avg:9, max:48)
T410: 34.420(avg:20, max:199*)| 34.440(avg:12, max:157)
-
2.2 test case2: two mass storage devices' performance test
upstream| patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
Pandaboard A1: 15.830/15.530(avg:158,max:1139) | 16.490/16.180(avg:15, max:135)
Arndale board: 17.370/16.260(avg:30 max:222) | 17.450/16.240(avg:10, max:92)
T410: 21.300/19.900(avg:18 max:243) | 21.230/19.920(avg:12, max:152)
-
2.3 test case3: one uvc streaming test
- uvc device works well(on x86, luvcview can be used too and has
same result with uvc capture)
upstream| patched
irq time(us)| irq time(us)
Pandaboard A1: (avg:455, max:941) | (avg:33, max:45)
Arndale board: (avg:316, max:616) | (avg:19, max:27)
T410: (avg:39, max:164) | (avg:10, max:142)
-
2.4 test case4: one uvc streaming plus one mass storage device test
upstream| patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
Pandaboard A1: 20.340(avg:258,max:1575)| 20.230(avg:24, max:100)
Arndale board: 23.570(avg:120,max:683) | 23.560(avg:14, max:61)
T410: 28.260(avg:27, max:178) | 28.230(avg:13, max:155)
-
* On T410, sometimes read ehci status register in ehci_irq takes more
than 100us, and the problem has been reported on the link:
http://marc.info/?t=13706586731r=1w=2
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/usb/host/ehci-fsl.c |2 +-
drivers/usb/host/ehci-grlib.c |2 +-
drivers/usb/host/ehci-hcd.c |2 +-
drivers/usb/host/ehci-mv.c|2 +-
drivers/usb/host/ehci-octeon.c|2 +-
drivers/usb/host/ehci-pmcmsp.c|2 +-
drivers/usb/host/ehci-ppc-of.c|2 +-
drivers/usb/host/ehci-ps3.c |2 +-
drivers/usb/host/ehci-sead3.c |2 +-
drivers/usb/host/ehci-sh.c|2 +-
drivers/usb/host/ehci-tegra.c |2 +-
drivers/usb/host/ehci-tilegx.c|2 +-
drivers/usb/host/ehci-w90x900.c |2 +-
drivers/usb/host/ehci-xilinx-of.c |2 +-
14 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index bd831ec..330274a 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -669,7 +669,7 @@ static const struct hc_driver ehci_fsl_hc_driver = {
* generic hardware linkage
[RFC PATCH 1/4] USB: HCD: support giveback of URB in tasklet context
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 handling
can be simplified.
Motivations:
1), on some arch(such as ARM), DMA mapping/unmapping is a bit
time-consuming, for example: when accessing usb mass storage
via EHCI on pandaboard, the common length of transfer buffer is 120KB,
the time consumed on DMA unmapping may reach hundreds of microseconds;
even on A15 based box, the time is still about scores of microseconds
2), on some arch, reading DMA coherent memoery is very time-consuming,
the most common example is usb video class driver[1]
3), driver's complete() callback may do much things which is driver
specific, so the time is consumed unnecessarily in hardware irq context.
4), running driver's complete() callback in hardware irq context causes
that host controller driver has to release its lock in interrupt handler,
so reacquiring the lock after return may busy wait a while and increase
interrupt handling time. More seriously, releasing the HCD lock makes
HCD becoming quite complicated to deal with introduced races.
So the patch proposes to run giveback of URB in tasklet context, then
time consumed in HCD irq handling doesn't depend on drivers' complete and
DMA mapping/unmapping any more, also we can simplify HCD since the HCD
lock isn't needed to be released during irq handling.
The patch should be reasonable and doable:
1), for drivers, they don't care if the complete() is called in hard irq
context or softirq context
2), the biggest change is the situation in which usb_submit_urb() is called
in complete() callback, so the introduced tasklet schedule delay might be a
con, but it shouldn't be a big deal:
- control/bulk asynchronous transfer isn't sensitive to schedule
delay
- the patch schedules giveback of periodic URBs using
tasklet_hi_schedule, so the introduced delay should be very
small
- use percpu tasklset for each HCD to schedule giveback of URB,
which are running as much as parallel
- for ISOC transfer, generally, drivers submit several URBs
concurrently to avoid interrupt delay, so it is OK with the
little schedule delay.
- for interrupt transfer, generally, drivers only submit one URB
at the same time, but interrupt transfer is often used in event
report, polling, ... situations, and a little delay should be OK.
Considered that HCDs may optimize on submitting URB in complete(), the
patch may cause the optimization not working, so introduces one flag to mark
if the HCD supports to run giveback URB in tasklet context. When all HCDs
are ready, the flag can be removed.
[1], http://marc.info/?t=136438111600010r=1w=2
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/usb/core/hcd.c | 170 ---
include/linux/usb/hcd.h | 16 +
2 files changed, 162 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 3d27d87..dc319e5 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -676,9 +676,11 @@ error:
* Avoiding calls to local_irq_disable/enable makes the code
* RT-friendly.
*/
- spin_unlock(hcd_root_hub_lock);
+ if (!hcd_giveback_urb_in_bh(hcd))
+ spin_unlock(hcd_root_hub_lock);
usb_hcd_giveback_urb(hcd, urb, status);
- spin_lock(hcd_root_hub_lock);
+ if (!hcd_giveback_urb_in_bh(hcd))
+ spin_lock(hcd_root_hub_lock);
spin_unlock_irq(hcd_root_hub_lock);
return 0;
@@ -719,9 +721,11 @@ void usb_hcd_poll_rh_status(struct usb_hcd *hcd)
memcpy(urb-transfer_buffer, buffer, length);
usb_hcd_unlink_urb_from_ep(hcd, urb);
- spin_unlock(hcd_root_hub_lock);
+ if (!hcd_giveback_urb_in_bh(hcd))
+ spin_unlock(hcd_root_hub_lock);
usb_hcd_giveback_urb(hcd, urb, 0);
- spin_lock(hcd_root_hub_lock);
+ if (!hcd_giveback_urb_in_bh(hcd))
+ spin_lock(hcd_root_hub_lock);
} else {
length = 0;
set_bit(HCD_FLAG_POLL_PENDING, hcd-flags);
@@ -812,9 +816,11 @@ static int usb_rh_urb_dequeue(struct usb_hcd *hcd, struct
urb *urb, int status)
hcd-status_urb = NULL;
usb_hcd_unlink_urb_from_ep(hcd, urb);
- spin_unlock(hcd_root_hub_lock);
+ if (!hcd_giveback_urb_in_bh(hcd))
+ spin_unlock(hcd_root_hub_lock);
usb_hcd_giveback_urb(hcd, urb, status);
-
[RFC PATCH 3/4] USB: EHCI: improve interrupt qh unlink
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 qh may be unlinked
immediately once qh_completions() returns from ehci_irq(), then
the intr URB to be resubmitted in complete() can only be scheduled
and linked to hardware until the qh unlink is completed.
This patch applied the QH_STATE_UNLINK_WAIT(not used by interrupt qh)
state to improve this above situation, and the qh will wait for 5
milliseconds before being unlinked from hardware, if one URB is submitted
during the period, the qh is move out of unlink wait state and the
interrupt transfer can be scheduled immediately, not like before: the
transfer is only linked to hardware until previous unlink is completed.
Only enable the improvement in case that HCD supports to run
giveback of URB in tasklet context.
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/usb/host/ehci-hcd.c | 16 ---
drivers/usb/host/ehci-hub.c |1 +
drivers/usb/host/ehci-sched.c | 60 ++---
drivers/usb/host/ehci-timer.c | 43 +
drivers/usb/host/ehci.h |3 +++
5 files changed, 115 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 246e124..0ab82de 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -304,7 +304,9 @@ static void end_unlink_async(struct ehci_hcd *ehci);
static void unlink_empty_async(struct ehci_hcd *ehci);
static void unlink_empty_async_suspended(struct ehci_hcd *ehci);
static void ehci_work(struct ehci_hcd *ehci);
-static void start_unlink_intr(struct ehci_hcd *ehci, struct ehci_qh *qh);
+static void start_unlink_intr(struct ehci_hcd *ehci, struct ehci_qh *qh,
+ bool wait);
+static void start_do_unlink_intr(struct ehci_hcd *ehci, struct ehci_qh *qh);
static void end_unlink_intr(struct ehci_hcd *ehci, struct ehci_qh *qh);
#include ehci-timer.c
@@ -484,6 +486,7 @@ static int ehci_init(struct usb_hcd *hcd)
ehci-periodic_size = DEFAULT_I_TDPS;
INIT_LIST_HEAD(ehci-async_unlink);
INIT_LIST_HEAD(ehci-async_idle);
+ INIT_LIST_HEAD(ehci-intr_unlink_wait);
INIT_LIST_HEAD(ehci-intr_unlink);
INIT_LIST_HEAD(ehci-intr_qh_list);
INIT_LIST_HEAD(ehci-cached_itd_list);
@@ -908,15 +911,20 @@ static int ehci_urb_dequeue(struct usb_hcd *hcd, struct
urb *urb, int status)
switch (qh-qh_state) {
case QH_STATE_LINKED:
if (usb_pipetype(urb-pipe) == PIPE_INTERRUPT)
- start_unlink_intr(ehci, qh);
+ start_unlink_intr(ehci, qh, false);
else
start_unlink_async(ehci, qh);
break;
case QH_STATE_COMPLETING:
qh-dequeue_during_giveback = 1;
break;
- case QH_STATE_UNLINK:
case QH_STATE_UNLINK_WAIT:
+ if (usb_pipetype(urb-pipe) == PIPE_INTERRUPT) {
+ cancel_unlink_wait_intr(ehci, qh);
+ start_unlink_intr(ehci, qh, false);
+ }
+ break;
+ case QH_STATE_UNLINK:
/* already started */
break;
case QH_STATE_IDLE:
@@ -1042,7 +1050,7 @@ ehci_endpoint_reset(struct usb_hcd *hcd, struct
usb_host_endpoint *ep)
if (eptype == USB_ENDPOINT_XFER_BULK)
start_unlink_async(ehci, qh);
else
- start_unlink_intr(ehci, qh);
+ start_unlink_intr(ehci, qh, false);
}
}
spin_unlock_irqrestore(ehci-lock, flags);
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index b2f6450..4104c66 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -345,6 +345,7 @@ static int ehci_bus_suspend (struct usb_hcd *hcd)
end_unlink_async(ehci);
unlink_empty_async_suspended(ehci);
+ ehci_handle_start_intr_unlinks(ehci);
ehci_handle_intr_unlinks(ehci);
end_free_itds(ehci);
diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
index acff5b8..d132c6f 100644
--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -601,10 +601,10 @@ static void qh_unlink_periodic(struct ehci_hcd *ehci,
struct ehci_qh *qh)
list_del(qh-intr_node);
}
-static void start_unlink_intr(struct ehci_hcd *ehci, struct ehci_qh *qh)
+static void start_do_unlink_intr(struct ehci_hcd *ehci, struct ehci_qh *qh)
{
- /* If the QH isn't linked then
Re: [RFC PATCH 1/4] USB: HCD: support giveback of URB in tasklet context
On Sun, 9 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 handling can be simplified. Why do you want to minimize the hardware interrupt handling time? The total interrupt handling time will actually be increased by your change; the only advantage is that much of the work will not be in hardirq context. Also, I suspect that this will make HCD interrupt handling _more_ complicated, not less. Motivations: 1), on some arch(such as ARM), DMA mapping/unmapping is a bit time-consuming, for example: when accessing usb mass storage via EHCI on pandaboard, the common length of transfer buffer is 120KB, the time consumed on DMA unmapping may reach hundreds of microseconds; even on A15 based box, the time is still about scores of microseconds DMA mapping/unmapping will remain just as time-consuming as before. This patch won't change that. 2), on some arch, reading DMA coherent memoery is very time-consuming, the most common example is usb video class driver[1] Reading DMA-coherent memory will remain just as time-consuming as before. 3), driver's complete() callback may do much things which is driver specific, so the time is consumed unnecessarily in hardware irq context. With this patch, the time is consumed in softirq context. What is the advantage? 4), running driver's complete() callback in hardware irq context causes that host controller driver has to release its lock in interrupt handler, so reacquiring the lock after return may busy wait a while and increase interrupt handling time. More seriously, releasing the HCD lock makes HCD becoming quite complicated to deal with introduced races. There is no choice; the lock _has_ to be released before giving back completed URBs. Therefore the races are unavoidable, as is the busy-wait. So the patch proposes to run giveback of URB in tasklet context, then time consumed in HCD irq handling doesn't depend on drivers' complete and DMA mapping/unmapping any more, also we can simplify HCD since the HCD lock isn't needed to be released during irq handling. I'm not convinced. In particular, I'm not convinced that this is better than using a threaded interrupt handler. The patch should be reasonable and doable: 1), for drivers, they don't care if the complete() is called in hard irq context or softirq context True. 2), the biggest change is the situation in which usb_submit_urb() is called in complete() callback, so the introduced tasklet schedule delay might be a con, but it shouldn't be a big deal: - control/bulk asynchronous transfer isn't sensitive to schedule delay Mass-storage device access (which uses bulk async transfers) certainly _is_ sensitive to scheduling delays. - the patch schedules giveback of periodic URBs using tasklet_hi_schedule, so the introduced delay should be very small - use percpu tasklset for each HCD to schedule giveback of URB, which are running as much as parallel That might be an advantage; it depends on the work load. But if the tasklet ends up running on a different CPU from the task that submitted the URB originally, it would be less of an advantage. - for ISOC transfer, generally, drivers submit several URBs concurrently to avoid interrupt delay, so it is OK with the little schedule delay. This varies. Some drivers use very low overheads for isochronous transfers. A delay of even one millisecond might be too long for them. - for interrupt transfer, generally, drivers only submit one URB at the same time, but interrupt transfer is often used in event report, polling, ... situations, and a little delay should be OK. Agreed. Alan Stern -- 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: [RFC PATCH 2/4] USB: EHCI: don't release ehci-lock if URB giveback in tasklet context
On Sun, 9 Jun 2013, Ming Lei wrote: If HCD_BH is set for HC driver's flags, URB giveback will be done in tasklet context instead of interrupt context, so the ehci-lock needn't to be released any more before calling usb_hcd_giveback_urb(). Ah, this is the reason why you don't need to release the private lock. I'm not sure that this will save much time overall. With the existing code, the main reason for lock contention would be if (for example) CPU 2 submitted or cancelled an URB while the giveback was occurring on CPU 1. Then CPU 1 would be forced to wait while CPU 2 finished its submission or cancellation. With this patch, it's the other way around. CPU 2 would be forced to wait while CPU 1 does all the rest of the work in its interrupt handler. The total time spent holding the lock will be the same; it will just be distributed differently among the CPUs. Hence it is not at all clear that this change will save any time. Alan Stern -- 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: Proposed modification to PL2303 driver
On Sun, Jun 09, 2013 at 10:38:01AM +0200, Mastro Gippo wrote: Hello, I'm working with a PL2303 device and I had an issue with the driver. Basically, I can't set the baudrate to 250kbps, but everything is better explained here: http://stackoverflow.com/questions/1778/prolific-pl2303-serial-port-to-25bps I think that removing lines from 332 to 348 of the driver the device will work even with non-standard (but common in embedded devices) baudrates. What exact kernel version are you using? Have you tried removing those lines and see what happens in the driver? How exactly are you trying to set odd baud rates in the device? Can you provide a code example to test with? And what happens when you do it? Baudrates standards were set a long time ago to use the same clock to generate human-compatible timing, for example with 32.768kHz crystals. Nowadays, crystals come mostly in round numbers, and the Prolific device makes no exception, having a 12MHz clock. In all my embedded project I'm running these non-standard baudrates for that same reason. How do you know the speed of the crystal for this device? We don't have a data sheet for it, and have no idea how this chip works. I don't see any negative effects that may derive from this modification, but please let me know if there are any. Given that the driver has been working properly with this table for over 10 years, and we don't have data sheets on how exactly this driver works, and we don't know if this chip will even support different baud rates than what is in it, it's a big risk to just rip it out now. thanks, greg k-h -- 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
Fwd: request some hep for usb comminucation
Hi I am mahdi. i want to communicate with a radio over USB. creator of this radio only support windows driver for communicate, but i want to have connection in Linux. i have a SDK for windows and protocol specification of this device and do some sniffing USB port on connection in windows. may you help me how to have connection with this device in Linux? or how can i write a driver for this device in Linux? thank a lot M. Razavi -- 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: Fwd: request some hep for usb comminucation
On Mon, Jun 10, 2013 at 01:01:15AM +0430, Mahdi Razavi wrote: Hi I am mahdi. i want to communicate with a radio over USB. creator of this radio only support windows driver for communicate, but i want to have connection in Linux. What device is this exactly? What is the output of 'lsusb -v' with it plugged in? i have a SDK for windows and protocol specification of this device and do some sniffing USB port on connection in windows. may you help me how to have connection with this device in Linux? or how can i write a driver for this device in Linux? What type of interface to userspace do you need for this device? Can it be a dumb serial-like interface that you send it AT modem commands? Or do you need to do other stuff with it? What about just using libusb to talk directly to it from your program from userspace, no kernel driver is needed for that. thanks, greg k-h -- 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
[PATCH 0/3] USB: OMAP: Tahvo USB support for 770
Hi, These patches add support for Tahvo USB transceiver and allow using both host and peripheral modes on Nokia 770. Tested (peripheral mode, host mode, vbus detection) with 3.10-rc4. Aaro Koskinen (3): ARM: OMAP1: nokia770: enable Tahvo USB: OMAP: add omap-otg USB: OMAP: Tahvo USB transceiver driver arch/arm/mach-omap1/board-nokia770.c | 10 + drivers/usb/phy/Kconfig | 24 ++ drivers/usb/phy/Makefile |2 + drivers/usb/phy/phy-omap-otg.c | 126 ++ drivers/usb/phy/phy-tahvo.c | 429 ++ include/linux/usb/omap-otg.h | 19 ++ 6 files changed, 610 insertions(+) create mode 100644 drivers/usb/phy/phy-omap-otg.c create mode 100644 drivers/usb/phy/phy-tahvo.c create mode 100644 include/linux/usb/omap-otg.h -- 1.7.10.4 -- 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
[PATCH 2/3] USB: OMAP: add omap-otg
Transceivers need to manage OTG controller state on OMAP1 to enable
switching between peripheral and host modes. Provide a driver for that.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/usb/phy/Kconfig| 10
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/phy-omap-otg.c | 126
include/linux/usb/omap-otg.h | 19 ++
4 files changed, 156 insertions(+)
create mode 100644 drivers/usb/phy/phy-omap-otg.c
create mode 100644 include/linux/usb/omap-otg.h
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 7ef3eb8..2d2cd5f 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -135,6 +135,16 @@ config USB_GPIO_VBUS
optionally control of a D+ pullup GPIO as well as a VBUS
current limit regulator.
+config OMAP_OTG
+ tristate OMAP USB OTG controller driver
+ depends on ARCH_OMAP_OTG
+ help
+ Enable this to support some transceivers on OMAP1 platforms. OTG
+ controller is needed to switch between host and peripheral modes.
+
+ This driver can also be built as a module. If so, the module
+ will be called omap-otg.
+
config USB_ISP1301
tristate NXP ISP1301 USB transceiver support
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index a9169cb..c7f391b 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_ISP1301_OMAP)+= phy-isp1301-omap.o
obj-$(CONFIG_MV_U3D_PHY) += phy-mv-u3d-usb.o
obj-$(CONFIG_NOP_USB_XCEIV)+= phy-nop.o
obj-$(CONFIG_OMAP_CONTROL_USB) += phy-omap-control.o
+obj-$(CONFIG_OMAP_OTG) += phy-omap-otg.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
obj-$(CONFIG_OMAP_USB3)+= phy-omap-usb3.o
obj-$(CONFIG_SAMSUNG_USBPHY) += phy-samsung-usb.o
diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
new file mode 100644
index 000..cb00ffe
--- /dev/null
+++ b/drivers/usb/phy/phy-omap-otg.c
@@ -0,0 +1,126 @@
+/*
+ * OMAP OTG controller driver
+ *
+ * Based on code from tahvo-usb.c and isp1301_omap.c drivers.
+ *
+ * Copyright (C) 2005-2006 Nokia Corporation
+ * Copyright (C) 2004 Texas Instruments
+ * Copyright (C) 2004 David Brownell
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/io.h
+#include linux/err.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/usb/omap-otg.h
+#include linux/platform_device.h
+
+struct otg_device {
+ void __iomem*base;
+ struct mutexserialize;
+};
+static struct otg_device *otg_dev;
+
+#define OMAP_OTG_CTRL (otg_dev-base + 0x0c)
+#define OMAP_OTG_ASESSVLD (1 20)
+#define OMAP_OTG_BSESSEND (1 19)
+#define OMAP_OTG_BSESSVLD (1 18)
+#define OMAP_OTG_VBUSVLD (1 17)
+#define OMAP_OTG_ID(1 16)
+#define OMAP_OTG_XCEIV_OUTPUTS \
+ (OMAP_OTG_ASESSVLD | OMAP_OTG_BSESSEND | OMAP_OTG_BSESSVLD | \
+OMAP_OTG_VBUSVLD | OMAP_OTG_ID)
+
+static void omap_otg_ctrl(u32 outputs)
+{
+ u32 l;
+
+ l = readl(OMAP_OTG_CTRL);
+ l = ~OMAP_OTG_XCEIV_OUTPUTS;
+ l |= outputs;
+ writel(l, OMAP_OTG_CTRL);
+}
+
+void omap_otg_set_mode(enum omap_otg_mode mode)
+{
+ if (!otg_dev) {
+ WARN(1, %s: controller not present\n, __func__);
+ return;
+ }
+ mutex_lock(otg_dev-serialize);
+ switch (mode) {
+ case OMAP_OTG_MODE_DEVICE:
+ /*
+* Set B-session valid.
+*/
+ omap_otg_ctrl(OMAP_OTG_ID | OMAP_OTG_BSESSVLD);
+ break;
+ case OMAP_OTG_MODE_HOST:
+ /*
+* Set A-session valid.
+*/
+ omap_otg_ctrl(OMAP_OTG_ASESSVLD);
+ break;
+ case OMAP_OTG_MODE_DISCONNECT:
+ /*
+* Set B-session end to indicate no VBUS.
+*/
+ omap_otg_ctrl(OMAP_OTG_ID | OMAP_OTG_BSESSEND);
+ break;
+ default:
+ WARN(1, %s: unknown mode: %d\n, __func__, mode);
+ }
+ mutex_unlock(otg_dev-serialize);
+}
+EXPORT_SYMBOL_GPL(omap_otg_set_mode);
+
+static int omap_otg_probe(struct platform_device *dev)
+{
+ struct otg_device *odev;
+ u32 rev;
+
+ if (otg_dev)
+
[PATCH 1/3] ARM: OMAP1: nokia770: enable Tahvo
Add platform data for Tahvo.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/arm/mach-omap1/board-nokia770.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index 62a15e2..91449c5 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -234,16 +234,26 @@ static struct i2c_board_info nokia770_i2c_board_info_2[]
__initdata = {
{
I2C_BOARD_INFO(retu-mfd, 0x01),
},
+ {
+ I2C_BOARD_INFO(tahvo-mfd, 0x02),
+ },
};
static void __init nokia770_cbus_init(void)
{
const int retu_irq_gpio = 62;
+ const int tahvo_irq_gpio = 40;
if (gpio_request_one(retu_irq_gpio, GPIOF_IN, Retu IRQ))
return;
+ if (gpio_request_one(tahvo_irq_gpio, GPIOF_IN, Tahvo IRQ)) {
+ gpio_free(retu_irq_gpio);
+ return;
+ }
irq_set_irq_type(gpio_to_irq(retu_irq_gpio), IRQ_TYPE_EDGE_RISING);
+ irq_set_irq_type(gpio_to_irq(tahvo_irq_gpio), IRQ_TYPE_EDGE_RISING);
nokia770_i2c_board_info_2[0].irq = gpio_to_irq(retu_irq_gpio);
+ nokia770_i2c_board_info_2[1].irq = gpio_to_irq(tahvo_irq_gpio);
i2c_register_board_info(2, nokia770_i2c_board_info_2,
ARRAY_SIZE(nokia770_i2c_board_info_2));
platform_device_register(nokia770_cbus_device);
--
1.7.10.4
--
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
[PATCH 3/3] USB: OMAP: Tahvo USB transceiver driver
Add Tahvo USB transceiver driver.
Based on old code from linux-omap tree. The original driver was written
by Juha Yrjölä, Tony Lindgren, and Timo Teräs.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/usb/phy/Kconfig | 14 ++
drivers/usb/phy/Makefile|1 +
drivers/usb/phy/phy-tahvo.c | 429 +++
3 files changed, 444 insertions(+)
create mode 100644 drivers/usb/phy/phy-tahvo.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 2d2cd5f..f796745 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -145,6 +145,20 @@ config OMAP_OTG
This driver can also be built as a module. If so, the module
will be called omap-otg.
+config TAHVO_USB
+ tristate Tahvo USB transceiver driver
+ depends on MFD_RETU OMAP_OTG
+ help
+ Enable this to support USB transceiver on Tahvo. This is used
+ at least on Nokia 770.
+
+config TAHVO_USB_HOST_BY_DEFAULT
+ depends on TAHVO_USB
+ boolean Device in USB host mode by default
+ help
+ Say Y here, if you want the device to enter USB host mode
+ by default on bootup.
+
config USB_ISP1301
tristate NXP ISP1301 USB transceiver support
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index c7f391b..f3984d1 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -13,6 +13,7 @@ phy-fsl-usb2-objs := phy-fsl-usb.o
phy-fsm-usb.o
obj-$(CONFIG_FSL_USB2_OTG) += phy-fsl-usb2.o
obj-$(CONFIG_ISP1301_OMAP) += phy-isp1301-omap.o
obj-$(CONFIG_MV_U3D_PHY) += phy-mv-u3d-usb.o
+obj-$(CONFIG_TAHVO_USB)+= phy-tahvo.o
obj-$(CONFIG_NOP_USB_XCEIV)+= phy-nop.o
obj-$(CONFIG_OMAP_CONTROL_USB) += phy-omap-control.o
obj-$(CONFIG_OMAP_OTG) += phy-omap-otg.o
diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/phy/phy-tahvo.c
new file mode 100644
index 000..51bc40e
--- /dev/null
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -0,0 +1,429 @@
+/*
+ * Tahvo USB transceiver driver
+ *
+ * Copyright (C) 2005-2006 Nokia Corporation
+ *
+ * Parts copied from isp1301_omap.c.
+ * Copyright (C) 2004 Texas Instruments
+ * Copyright (C) 2004 David Brownell
+ *
+ * Original driver written by Juha Yrjölä, Tony Lindgren and Timo Teräs.
+ * Modified for Retu/Tahvo MFD by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/io.h
+#include linux/clk.h
+#include linux/usb.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/usb/otg.h
+#include linux/mfd/retu.h
+#include linux/usb/gadget.h
+#include linux/usb/omap-otg.h
+#include linux/platform_device.h
+
+#define DRIVER_NAME tahvo-usb
+
+#define TAHVO_REG_IDSR 0x02
+#define TAHVO_REG_USBR 0x06
+
+#define USBR_SLAVE_CONTROL (1 8)
+#define USBR_VPPVIO_SW (1 7)
+#define USBR_SPEED (1 6)
+#define USBR_REGOUT(1 5)
+#define USBR_MASTER_SW2(1 4)
+#define USBR_MASTER_SW1(1 3)
+#define USBR_SLAVE_SW (1 2)
+#define USBR_NSUSPEND (1 1)
+#define USBR_SEMODE(1 0)
+
+#define TAHVO_MODE_HOST0
+#define TAHVO_MODE_PERIPHERAL 1
+
+struct tahvo_usb {
+ struct platform_device *pt_dev;
+ struct usb_phy phy;
+ int vbus_state;
+ struct mutexserialize;
+ struct clk *ick;
+ int irq;
+ int tahvo_mode;
+};
+
+static ssize_t vbus_state_show(struct device *device,
+ struct device_attribute *attr, char *buf)
+{
+ struct tahvo_usb *tu = dev_get_drvdata(device);
+ return sprintf(buf, %d\n, tu-vbus_state);
+}
+static DEVICE_ATTR(vbus_state, 0444, vbus_state_show, NULL);
+
+static void check_vbus_state(struct tahvo_usb *tu)
+{
+ struct retu_dev *rdev = dev_get_drvdata(tu-pt_dev-dev.parent);
+ int reg, prev_state;
+
+ reg = retu_read(rdev, TAHVO_REG_IDSR);
+ if (reg TAHVO_STAT_VBUS) {
+ switch (tu-phy.state) {
+ case OTG_STATE_B_IDLE:
+ /* Enable the gadget driver */
+ if (tu-phy.otg-gadget)
+ usb_gadget_vbus_connect(tu-phy.otg-gadget);
+ omap_otg_set_mode(OMAP_OTG_MODE_DEVICE);
+ tu-phy.state = OTG_STATE_B_PERIPHERAL;
+
Re: [PATCH v9 0/3] Add USB support to R8A7778/BOCK-W
On Sun, Jun 09, 2013 at 12:24:04AM +0400, Sergei Shtylyov wrote: On 06/09/2013 12:12 AM, Sergei Shtylyov wrote: Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130607' tag, and the R8A7779/Marzen USB patchset I've posted. It was created to add support of R8A7778/BOCK-W USB to the platform code and the USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/phy/ subtrees. [1/3] phy-rcar-usb: add R8A7778 support [2/3] ARM: shmobile: r8a7778: add USB support [3/3] ARM: shmobile: BOCK-W: add USB support The patch #4 (ARM: shmobile: BOCK-W: enable USB in defconfig) that has been already merged, is not reposted. The patchset is completely ready for merging now. Argh, scratch that -- I forgot to refresh the patches before sending... Scratched. -- 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
Fwd: Fwd: request some hep for usb comminucation
Hi This is a Digital Radio which can report some data through USB to its application. The output of lsudb : Bus 002 Device 004: ID 238b:0a31 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 254 bDeviceProtocol 254 bMaxPacketSize0 8 idVendor 0x238b idProduct 0x0a31 bcdDevice0.00 iManufacturer 1 iProduct2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower4mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 255 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 255 -- output od dmesg: [26785.637159] usb 2-2.1: new full-speed USB device number 11 using uhci_hcd [26785.748010] usb 2-2.1: config 1 has an invalid interface number: 2 but max is 0 [26785.748018] usb 2-2.1: config 1 has no interface number 0 [26785.759058] usb 2-2.1: New USB device found, idVendor=238b, idProduct=0a31 [26785.759064] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [26785.759069] usb 2-2.1: Product: Digital Radio [26785.759073] usb 2-2.1: Manufacturer: RIGOL Communications this device has a SDK for developing in windows but there isnt any in Linux. i know protocol specification of message, and try sniffing on windows verify protocol. but when send a same data in Linux(with pyusb) to device dosent response. i guess there is a initial handshake in driver layer between device and OS. 2013/6/10 Greg KH gre...@linuxfoundation.org: On Mon, Jun 10, 2013 at 01:01:15AM +0430, Mahdi Razavi wrote: Hi I am mahdi. i want to communicate with a radio over USB. creator of this radio only support windows driver for communicate, but i want to have connection in Linux. What device is this exactly? What is the output of 'lsusb -v' with it plugged in? i have a SDK for windows and protocol specification of this device and do some sniffing USB port on connection in windows. may you help me how to have connection with this device in Linux? or how can i write a driver for this device in Linux? What type of interface to userspace do you need for this device? Can it be a dumb serial-like interface that you send it AT modem commands? Or do you need to do other stuff with it? What about just using libusb to talk directly to it from your program from userspace, no kernel driver is needed for that. thanks, greg k-h -- Best Regards M.Razavi -- 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
