[PATCH 6/6] USB: IOCTL to toggle the quirk (not required).
These patches implement a modification of the USBTMC
protocol to allow operation with Rigol equipment. Ioctl change allowing test
and toggling of the status of the rigol_quirk bit.
Signed-off-by: Alexandre Peixoto Ferreira alexandre...@gmail.com
---
drivers/usb/class/usbtmc.c | 25 +
include/uapi/linux/usb/tmc.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
index 609dbc2..20c0b88 100644
--- a/drivers/usb/class/usbtmc.c
+++ b/drivers/usb/class/usbtmc.c
@@ -154,6 +154,28 @@ static int usbtmc_release(struct inode *inode, struct file
*file)
return 0;
}
+static int usbtmc_ioctl_rigol_quirk(struct usbtmc_device_data *data,unsigned
long arg)
+{
+ struct device *dev;
+
+ dev = data-intf-dev;
+
+ switch(arg) {
+ case 0 : /* RESET RIGOL QUIRK MODE IF SET */
+ data-rigol_quirk = 0;
+ return 0;
+ case 1 : /* RESET RIGOL QUIRK MODE IF SET */
+ data-rigol_quirk = 1;
+ return 0;
+ case 2 : /* Check it it is set */
+ if (data-rigol_quirk)
+ return 0;
+ else
+ return -EINVAL;
+ }
+ return 0;
+}
+
static int usbtmc_ioctl_abort_bulk_in(struct usbtmc_device_data *data)
{
u8 *buffer;
@@ -1067,6 +1089,9 @@ static long usbtmc_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
case USBTMC_IOCTL_ABORT_BULK_IN:
retval = usbtmc_ioctl_abort_bulk_in(data);
break;
+ case USBTMC_IOCTL_RIGOL_QUIRK:
+ retval = usbtmc_ioctl_rigol_quirk(data,arg);
+ break;
}
skip_io_on_zombie:
diff --git a/include/uapi/linux/usb/tmc.h b/include/uapi/linux/usb/tmc.h
index c045ae1..1787460 100644
--- a/include/uapi/linux/usb/tmc.h
+++ b/include/uapi/linux/usb/tmc.h
@@ -39,5 +39,6 @@
#define USBTMC_IOCTL_ABORT_BULK_IN _IO(USBTMC_IOC_NR, 4)
#define USBTMC_IOCTL_CLEAR_OUT_HALT_IO(USBTMC_IOC_NR, 6)
#define USBTMC_IOCTL_CLEAR_IN_HALT _IO(USBTMC_IOC_NR, 7)
+#define USBTMC_IOCTL_RIGOL_QUIRK _IO(USBTMC_IOC_NR, 8)
#endif
--
1.8.2.1
--
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: [GIT PATCH] USB patches for 3.10-rc1
Hi, On Mon, Apr 29, 2013 at 02:31:59PM -0700, Linus Torvalds wrote: On Mon, Apr 29, 2013 at 2:14 PM, Alan Stern st...@rowland.harvard.edu wrote: What other things seemed odd about Greg's pull request? The only other thing I noticed was the new CONFIG_USB_PHY quesiton, which is not something that I think is sensible to ask from a user, and the help text doesn't really help anything either. I think the question may make sense, but the wording does not. *EVERYBODY* wants a USB PHY. You can't have USB without a physical layer unless it's a purely virtual device. There's one in a EHCI controller too. It's like a network chip - without a PHY there's no point. Why ask about whether you want to support a phy or not? The question makes no sense. right, the thing is that the standard host-only drivers (EHCI, OHCI, UHCI and XHCI) still don't know about the PHY layer. They give no SW visibility on the PHY at all so I felt that adding unused code to the x86 binaries would worse than just asking the user if they want the PHY layer enabled or not. In any case, *HCI drivers need to learn about the PHY layer, at least on their embedded forms (OMAP, Tegra, Marvel, SuperH, etc) since those will need SW control of the PHY for e.g. PM, remote wakeup, and few other cases. So I don't think the question should be do you want a USB PHY. The question should be Do you want a driver for some of the specialized external USB controllers or something like that. Because as it is now, anybody who actually reads the question is likely to answer y, I think, even if he just wants one of the *normal* USB chips that don't split out the PHY. makes sense. Hmm? Or does PHY have some magic other meaning in USB circles? In no, it means the same thing. -- balbi signature.asc Description: Digital signature
[PATCH] USB: reset resume quirk needed by a hub
From: Oliver Neukum oli...@neukum.org
Werner Fink has reported problems with this hub.
Signed-off-by: Oliver Neukum oli...@neukum.org
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 3113c1d..e14346a 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -88,6 +88,9 @@ static const struct usb_device_id usb_quirk_list[] = {
/* Edirol SD-20 */
{ USB_DEVICE(0x0582, 0x0027), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* Alcor Micro Corp. Hub */
+ { USB_DEVICE(0x058f, 0x9254), .driver_info = USB_QUIRK_RESET_RESUME },
+
/* appletouch */
{ USB_DEVICE(0x05ac, 0x021a), .driver_info = USB_QUIRK_RESET_RESUME },
--
1.8.1.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
Re: Testing phonet
Hello Andrzej, I removed people from CC On Monday, April 29, 2013 6:30 PM Daniele Forsi wrote: I can provide the OP with frames captured from a real phone when talking with gnokii You mean some kind of dump? What can it be useful for? Comparing the messages sequence to that of conversation with a real hardware? Simulating conversation with a real hardware without the hardware? both: you can compare the recorded conversation if you have the hardware or replay it without the hardware How can I get it from you? tell what you want to test and what kind of dump you can use and I'll see if I am able do it -- Daniele Forsi -- 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 v6 4/9] rcar-phy: remove EHCI internal buffer setup
On Tue, Apr 23, 2013 at 07:23:24PM +0400, Sergei Shtylyov wrote: Now that the EHCI internal buffer setup is done by the platform code, we can remove such code from this driver as it never really belonged here. We also no longer need the 2nd memory region now (2nd EHCI controller is simply missing in e.g. R8A7778 SoC). The patch has been tested on the Marzen and BOCK-W boards. Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com Acked-by: Simon Horman horms+rene...@verge.net.au looks alright. I'm not sure who should be taking this series, though. I won't queue patches for v3.11 until v3.10-rc1 is tagged and since it depends on the rest of the series, to me it makes little difference if I take them through my tree or somebody else does. In any case, here my: Acked-by: Felipe Balbi ba...@ti.com if anyone wants to take this patch. -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 6/9] rcar-phy: correct base address
On Tue, Apr 23, 2013 at 07:30:21PM +0400, Sergei Shtylyov wrote: The memory region that is used by the driver overlaps EHCI and OHCI register regions for absolutely no reason now -- fix it by adding offset of 0x800 to the base address, changing the register #define's accordingly. This has extra positive effect that we now can use devm_ioremap_resource()... Note that the driver and the SoC code have to be in one patch to keep the code bisectable... The patch has been tested on the Marzen board. Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com Acked-by: Simon Horman horms+rene...@verge.net.au Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 7/9] rcar-phy: add platform data
Hi, On Tue, Apr 23, 2013 at 07:33:00PM +0400, Sergei Shtylyov wrote: Currently the driver hard-codes USBPCTRL0 register to 0. It is wrong since this register contains board-specific USB ports configuration and so its value should be somehow passed via the platform data. Add linux/usb/rcar-phy.h file with the 'struct rcar_phy_platform_data' containing various bit fields describing USB pin configuration. Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com Acked-by: Simon Horman horms+rene...@verge.net.au --- Changes since version 3: - moved USBPCTRL0 register bit #define's to patch #9; - replaced USBPCTRL0 register value in the platform data structure by a set of bit fields describing the configuration of the board, rewrote changelog; Changes since version 2: - added #include linux/types.h; - added ACKs from Simon Horman and Kuninori Morimoto. include/linux/usb/rcar-phy.h | 26 ++ the new location for platform_data is include/linux/platform_data/ In fact, musb.h should move there eventually. -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 9/9] rcar-phy: handle platform data
On Tue, Apr 23, 2013 at 07:42:07PM +0400, Sergei Shtylyov wrote:
Set the USBPCTRL0 register from the passed platform data in
rcar_usb_phy_init();
don't reset it to 0 in rcar_usb_phy_shutdown() anymore as that does not make
sense. Also, don't allow the driver's probe to succeed when the platform data
are not supplied with a device.
The patch has been tested on the Marzen and BOCK-W boards.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
Acked-by: Felipe Balbi ba...@ti.com
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -11,10 +12,11 @@
#include linux/delay.h
#include linux/io.h
-#include linux/usb/otg.h
#include linux/platform_device.h
#include linux/spinlock.h
#include linux/module.h
+#include linux/usb/otg.h
trailing change here. Please just mention it on the commit log. It
doesn't a patch of its own :-p
@@ -89,8 +112,21 @@ static int rcar_usb_phy_init(struct usb_
/* (4) USB-PHY reset clear */
iowrite32(PHY_ENB | PLL_ENB | PHY_RST, (reg0 + USBPCTRL1));
- /* set platform specific port settings */
- iowrite32(0x, (reg0 + USBPCTRL0));
+ /* Board specific port settings */
+ val = 0;
+ if (pdata-port1_func)
+ val |= PORT1;
+ if (pdata-penc1)
+ val |= PENC;
+ for (i = 0; i 3; i++) {
+ /* OVCn bits follow each other in the right order */
+ if (pdata-ovc_pin[i].select_3_3v)
+ val |= OVC0 i;
+ /* OVCn_ACT bits are spaced by irregular intervals */
+ if (pdata-ovc_pin[i].active_high)
+ val |= ovcn_act[i];
+ }
+ iowrite32(val, (reg0 + USBPCTRL0));
not all architectures provide iowrite32(). Please make sure your driver
builds on x86 and ARM by using SHOW_ALL_DRIVERS (on Kconfig).
BTW, conversion away from iowrite32() could (should) be part of a
separate patch. No need to prevent this one from being applied.
--
balbi
signature.asc
Description: Digital signature
RE: Testing phonet
On Monday, April 29, 2013 3:48 PM Rémi Denis-Courmont wrote: Le lundi 29 avril 2013 15:06:17, Sebastian Andrzej Siewior a écrit : In Documentation/networking/phonet.txt are few snippets how to open SOCK_DGRAM and PN_PROTO_PIPE. With this and read()/write() should work. Using datagram socket is possible to test IN and OUT. But you would first need to configure the network interface - on both the host and the gadget. For that you could use the old Phonet utilities: http://gitorious.org/meego-cellular/phonet-utils/trees/master Thanks! This was very helpful. The tools compile and seem to work both on the host and on the device. But I am now stuck with sending the right data over the link. On a USB analyzer I can see one OUT transaction if I sendto() from host to device, or one IN transaction if I sendto() from device to host. The data packet in the transaction does contain some data I can recognize, so I assume that the USB connectivity itself works. But I don't know what to send in order for recvfrom() to receive something. Andrzej -- 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: Testing phonet
On Tuesday, April 30, 2013 11:30 AM Daniele Forsi wrote: Hello Andrzej, I removed people from CC On Monday, April 29, 2013 6:30 PM Daniele Forsi wrote: I can provide the OP with frames captured from a real phone when talking with gnokii You mean some kind of dump? What can it be useful for? Comparing the messages sequence to that of conversation with a real hardware? Simulating conversation with a real hardware without the hardware? both: you can compare the recorded conversation if you have the hardware or replay it without the hardware How can I get it from you? tell what you want to test and what kind of dump you can use and I'll see if I am able do it As I already wrote I am now stuck with sending correct data, so that when I sendto() from host I can recvfrom() on device (or vice versa). What I would like to test is to transmit any data, preferably both ways, in order to see if the link works. Just that. The simpler the tool, the better. I would like best to have a small tool to run on both ends of the link to verify the link is working. When it comes to the dumps I would prefer a dump of the simplest conversation possible between a host and a device, both ways. Andrzej -- 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: hso driver bug
On 02/20/13 05:58, Greg KH wrote: On Tue, Feb 19, 2013 at 01:21:46PM +0100, Magda Matouskova wrote: Hi, i have a problem with driver for my usb modems. Time after time server stuck( log from this event is below), in this case server has to be rebooted. I think that this could be caused by any condition that cannot be occured. Can you take a look for it or give me some tips to solve this problem? Name of modemes is GlobeTrotter GI1505 and the whole description is in attached in mail. The version of my kernel is 3.6.11 on debian linux. Can you try 3.7.9? A number of tty issues have been fixed since 3.6.11 that might be the cause here. thanks, greg k-h Hi, i`ve tried kernel version 3.8.2 as you advised. But there is the similar problem as i`ve described in last mail. Can you take a look for it? Here is dmesg: [428954.195708] BUG: unable to handle kernel NULL pointer dereference at 0090 [428954.196001] IP: [8139b465] mutex_lock+0x5/0x1f [428954.196001] PGD 7bf27067 PUD 37715067 PMD 0 [428954.196001] Oops: 0002 [#1] SMP [428954.196001] Modules linked in: tcp_diag inet_diag lpc_ich hso mfd_core shpchp cdc_phonet evdev phonet rfkill microcode processor pci_hotplug rng_core ehci_pci cdc_acm button thermal_sys i3000_edac i2c_i801 i2c_core edac_core sg sr_mod cdrom ext3 jbd mbcache dm_mod raid1 md_mod ata_generic pata_acpi usb_storage ahci libahci ata_piix uhci_hcd ehci_hcd libata usbcore usb_common e1000e [428954.196001] CPU 0 [428954.196001] Pid: 1020, comm: gnokii Not tainted 3.8.2.sms.sh #1 Supermicro PDSMi/PDSMi+ [428954.196001] RIP: 0010:[8139b465] [8139b465] mutex_lock+0x5/0x1f [428954.196001] RSP: 0018:88007afefdd0 EFLAGS: 00010206 [428954.196001] RAX: a0212951 RBX: 0090 RCX: 88007cb7d800 [428954.196001] RDX: 0048 RSI: 880058cfab80 RDI: 0090 [428954.196001] RBP: R08: R09: [428954.196001] R10: 7fff7298b4a0 R11: 0246 R12: 880058cfab80 [428954.196001] R13: 0009 R14: 88007d0334a0 R15: 880058cfab90 [428954.196001] FS: 7f5e98478700() GS:88007fc0() knlGS: [428954.196001] CS: 0010 DS: ES: CR0: 8005003b [428954.196001] CR2: 0090 CR3: 7aaa4000 CR4: 07f0 [428954.196001] DR0: DR1: DR2: [428954.196001] DR3: DR6: 0ff0 DR7: 0400 [428954.196001] Process gnokii (pid: 1020, threadinfo 88007afee000, task 88007c82f040) [428954.196001] Stack: [428954.196001] 88007bef3800 a021297f 0008 [428954.196001] 880056650800 8125448f 880005f8 [428954.196001] 0028 88007fc12800 0028 0014 [428954.196001] Call Trace: [428954.196001] [a021297f] ? hso_serial_close+0x2e/0xe2 [hso] [428954.196001] [8125448f] ? tty_release+0xe9/0x584 [428954.196001] [81029908] ? __do_page_fault+0x19e/0x400 [428954.196001] [8110c620] ? __fput+0x96/0x1fb [428954.196001] [810513e8] ? task_work_run+0x88/0x9f [428954.196001] [8139e19a] ? int_signal+0x12/0x17 [428954.196001] Code: 24 28 48 89 44 24 30 44 89 e9 4c 89 e2 48 89 e6 4c 89 c7 e8 f5 fe ff ff 48 83 c4 48 5b 5d 41 5c 41 5d c3 00 00 00 55 53 48 89 fb f0 ff 0f 79 05 e8 79 00 00 00 65 48 8b 04 25 00 b9 00 00 48 89 [428954.196001] RIP [8139b465] mutex_lock+0x5/0x1f [428954.196001] RSP 88007afefdd0 [428954.196001] CR2: 0090 [428954.957843] ---[ end trace 9850a53e683ee19b ]-- thanks, Magdalena Matouskova Linux Administrator -- 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:
From: Egan, Desri, L Sent: Tuesday, April 30, 2013 7:35 AM To: Egan, Desri, L Subject: My wife Violet and I Allen Large won $11.3 million in a lottery 6-49 in July, 2010 and we have decided to donate the sum of $2,000,000.00 USD to you. Contact us via our personal email for more details( alvio...@rogers.commailto:alvio...@rogers.com ) Electronic mail from Children's Mercy Hospitals and Clinics. This communication is intended only for the use of the addressee. It may contain information that is privileged or confidential under applicable law. If you are not the intended recipient or the agent of the recipient, you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited. If you have received this communication in error, please immediately forward the message to Children's Mercy Hospital's Information Security Officer via return electronic mail at informationsecurityoffi...@cmh.edu and expunge this communication without making any copies. Thank you for your cooperation. -- 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: ERROR transfer event TRB DMA ptr not part of current TD
On Mon, Apr 29, 2013 at 01:02:19PM +0200, Oliver Neukum wrote: On Thursday 10 January 2013 10:42:07 Sarah Sharp wrote: The new debugging shows that the host is giving *two* short status completions for a TD. This only happens when the isoc TD is split into two TRBs because the buffer crosses a 64KB boundary. The completion event shows that none of the buffer in either TRB was sent. So this suggests a deeper hardware issue, and we may need to use bounce buffers to work around it. I'll need to file a bug with our hardware team and cook up a work-around. So don't send any patches just yet. Hi Sarah, has this issue been addressed? I looked into it, and it's not a hardware bug. It's caused by a change in how xHCI 1.0 hosts handle short packets, that I didn't catch before now. It's relatively harmless, but does need to get fixed. I've added it to my JIRA bug tracker, but it's a low priority bug at this point. Perhaps we just need to add the spurious success quirk for all xHCI 1.0 hosts? Sarah Sharp -- 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/7] staging: dwc2: replace some magic numbers by constants
On Tue, Apr 30, 2013 at 05:20:14PM +0200, Matthijs Kooijman wrote: Hi Greg Paul, Whups, I didn't notice that Matthijs hadn't CC:ed you on these. Can you pick them up anyway? If not I can resend them. And I'll make sure you're on CC on all future patches. What's the best way to handle this for future patches? Should I CC Greg when submitting a patch, or is it better to let Paul add the CC when he acks the patch (to prevent noise for greg on patches that need further discussion)? I'd prefer to just get the patches from Paul, as he is the maintainer of the code, so I want to see his ack on them before I can take them. 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
RE:
From: Egan, Desri, L Sent: Tuesday, April 30, 2013 7:35 AM To: Egan, Desri, L Subject: My wife Violet and I Allen Large won $11.3 million in a lottery 6-49 in July, 2010 and we have decided to donate the sum of $2,000,000.00 USD to you. Contact us via our personal email for more details( alvio...@rogers.commailto:alvio...@rogers.com ) Electronic mail from Children's Mercy Hospitals and Clinics. This communication is intended only for the use of the addressee. It may contain information that is privileged or confidential under applicable law. If you are not the intended recipient or the agent of the recipient, you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited. If you have received this communication in error, please immediately forward the message to Children's Mercy Hospital's Information Security Officer via return electronic mail at informationsecurityoffi...@cmh.edu and expunge this communication without making any copies. Thank you for your cooperation. -- 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 v6 9/9] rcar-phy: handle platform data
Hello.
On 04/30/2013 02:42 PM, Felipe Balbi wrote:
Set the USBPCTRL0 register from the passed platform data in rcar_usb_phy_init();
don't reset it to 0 in rcar_usb_phy_shutdown() anymore as that does not make
sense. Also, don't allow the driver's probe to succeed when the platform data
are not supplied with a device.
The patch has been tested on the Marzen and BOCK-W boards.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
Acked-by: Felipe Balbi ba...@ti.com
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -11,10 +12,11 @@
#include linux/delay.h
#include linux/io.h
-#include linux/usb/otg.h
#include linux/platform_device.h
#include linux/spinlock.h
#include linux/module.h
+#include linux/usb/otg.h
trailing change here.
What do you mean by trailing? I just naturally grouped together
headers from the same directory.
Please just mention it on the commit log. It doesn't a patch of its own :-p
I'll drop it now probably as you told me to switch to
include/linux/platfrom_data/...
@@ -89,8 +112,21 @@ static int rcar_usb_phy_init(struct usb_
/* (4) USB-PHY reset clear */
iowrite32(PHY_ENB | PLL_ENB | PHY_RST, (reg0 + USBPCTRL1));
- /* set platform specific port settings */
- iowrite32(0x, (reg0 + USBPCTRL0));
+ /* Board specific port settings */
+ val = 0;
+ if (pdata-port1_func)
+ val |= PORT1;
+ if (pdata-penc1)
+ val |= PENC;
+ for (i = 0; i 3; i++) {
+ /* OVCn bits follow each other in the right order */
+ if (pdata-ovc_pin[i].select_3_3v)
+ val |= OVC0 i;
+ /* OVCn_ACT bits are spaced by irregular intervals */
+ if (pdata-ovc_pin[i].active_high)
+ val |= ovcn_act[i];
+ }
+ iowrite32(val, (reg0 + USBPCTRL0));
not all architectures provide iowrite32(). Please make sure your driver
builds on x86 and ARM by using SHOW_ALL_DRIVERS (on Kconfig).
Sure, it builds on ARM because it was designed for ARM SH Mobile
subarch.
I'll check x86 just in case.
BTW, conversion away from iowrite32() could (should) be part of a
separate patch. No need to prevent this one from being applied.
Of course. You mean conversion to plain writel(), right?
WBR, Sergei
--
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] xhci: Compute last_ctx from complete set of endpoints.
The context entries field of the slot context must be set to one more
than the highest endpoint index currently active. The previous logic
only included the set of endpoints currently being added, meaning that
if an endpoint where dropped then the field would be reset to 1,
deactivating all configured endpoints.
The xHCI spec is decidedly unclear on whether this field includes all
configured endpoints or only those being modified by a configure
endpoint command. My interpretation is the former and is the behavior
observed in the Apple's xHCI driver.
Signed-off-by: Reilly Grant gra...@vmware.com
---
drivers/usb/host/xhci.c | 52 +
1 file changed, 18 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 53b8f89..5c40d3e 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1557,12 +1557,10 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
struct xhci_hcd *xhci;
struct xhci_container_ctx *in_ctx, *out_ctx;
struct xhci_input_control_ctx *ctrl_ctx;
- struct xhci_slot_ctx *slot_ctx;
- unsigned int last_ctx;
unsigned int ep_index;
struct xhci_ep_ctx *ep_ctx;
u32 drop_flag;
- u32 new_add_flags, new_drop_flags, new_slot_info;
+ u32 new_add_flags, new_drop_flags;
int ret;
ret = xhci_check_args(hcd, udev, ep, 1, true, __func__);
@@ -1603,24 +1601,13 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
ctrl_ctx-add_flags = cpu_to_le32(~drop_flag);
new_add_flags = le32_to_cpu(ctrl_ctx-add_flags);
- last_ctx = xhci_last_valid_endpoint(le32_to_cpu(ctrl_ctx-add_flags));
- slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
- /* Update the last valid endpoint context, if we deleted the last one */
- if ((le32_to_cpu(slot_ctx-dev_info) LAST_CTX_MASK)
- LAST_CTX(last_ctx)) {
- slot_ctx-dev_info = cpu_to_le32(~LAST_CTX_MASK);
- slot_ctx-dev_info |= cpu_to_le32(LAST_CTX(last_ctx));
- }
- new_slot_info = le32_to_cpu(slot_ctx-dev_info);
-
xhci_endpoint_zero(xhci, xhci-devs[udev-slot_id], ep);
- xhci_dbg(xhci, drop ep 0x%x, slot id %d, new drop flags = %#x, new add
flags = %#x, new slot info = %#x\n,
+ xhci_dbg(xhci, drop ep 0x%x, slot id %d, new drop flags = %#x, new add
flags = %#x\n,
(unsigned int) ep-desc.bEndpointAddress,
udev-slot_id,
(unsigned int) new_drop_flags,
- (unsigned int) new_add_flags,
- (unsigned int) new_slot_info);
+ (unsigned int) new_add_flags);
return 0;
}
@@ -1643,11 +1630,9 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
struct xhci_hcd *xhci;
struct xhci_container_ctx *in_ctx, *out_ctx;
unsigned int ep_index;
- struct xhci_slot_ctx *slot_ctx;
struct xhci_input_control_ctx *ctrl_ctx;
u32 added_ctxs;
- unsigned int last_ctx;
- u32 new_add_flags, new_drop_flags, new_slot_info;
+ u32 new_add_flags, new_drop_flags;
struct xhci_virt_device *virt_dev;
int ret = 0;
@@ -1662,7 +1647,6 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
return -ENODEV;
added_ctxs = xhci_get_endpoint_flag(ep-desc);
- last_ctx = xhci_last_valid_endpoint(added_ctxs);
if (added_ctxs == SLOT_FLAG || added_ctxs == EP0_FLAG) {
/* FIXME when we have to issue an evaluate endpoint command to
* deal with ep0 max packet size changing once we get the
@@ -1723,24 +1707,14 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
*/
new_drop_flags = le32_to_cpu(ctrl_ctx-drop_flags);
- slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
- /* Update the last valid endpoint context, if we just added one past */
- if ((le32_to_cpu(slot_ctx-dev_info) LAST_CTX_MASK)
- LAST_CTX(last_ctx)) {
- slot_ctx-dev_info = cpu_to_le32(~LAST_CTX_MASK);
- slot_ctx-dev_info |= cpu_to_le32(LAST_CTX(last_ctx));
- }
- new_slot_info = le32_to_cpu(slot_ctx-dev_info);
-
/* Store the usb_device pointer for later use */
ep-hcpriv = udev;
- xhci_dbg(xhci, add ep 0x%x, slot id %d, new drop flags = %#x, new add
flags = %#x, new slot info = %#x\n,
+ xhci_dbg(xhci, add ep 0x%x, slot id %d, new drop flags = %#x, new add
flags = %#x\n,
(unsigned int) ep-desc.bEndpointAddress,
udev-slot_id,
(unsigned int) new_drop_flags,
- (unsigned int) new_add_flags,
- (unsigned int) new_slot_info);
+ (unsigned int) new_add_flags);
Re: [PATCH 1/1] usb: gadget/uvc: Add support to allocate UVC payload and header as SG elements
Hi Laurent,
Thanks for your review comments.
On 4/29/2013 8:08 PM, Laurent Pinchart wrote:
Hi Bhupesh,
Thank you for the patch.
On Wednesday 17 April 2013 09:44:25 Bhupesh Sharma wrote:
This patch adds the support in UVC webcam gadget to allocate UVC header and
payload as Scatter-Gather elements which can be used on a SG-capable UDC
controller.
A module parameter has been introduced for the same. One can set the
module parameter 'sg_mode' to 1 to turn on this feature (by default this
feature is turned-off).
This ensures that we don't require a memcpy from CPU side to append UVC
header in front of the UVC payload atleast for SG capable UDC contollers.
Signed-off-by: Bhupesh Sharma bhupesh.sha...@st.com
---
Note that to ease review and integration of this patch, I have rebased it
on the following patch already circulated for review last week:
[PATCH 1/1] usb: gadget/uvc: Add support for Bulk endpoint to be used as
Video Streaming ep
http://www.mail-archive.com/linux-usb@vger.kernel.org/msg19546.html
The above patch was rebased on Laurent's UVC gadget git tree available here
(head uvc-gadget):
git://linuxtv.org/pinchartl/uvcvideo.git
This will allow the patches to be pulled into Felipe's repo in one go
after review and any subsequent rework (if required).
drivers/usb/gadget/f_uvc.c |8 +++
drivers/usb/gadget/uvc.h |2 +
drivers/usb/gadget/uvc_video.c | 113 -
3 files changed, 109 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index e5953eb..ccf0253 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -50,6 +50,11 @@ module_param(bulk_streaming_ep, bool, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(bulk_streaming_ep, 0 (Use ISOC video streaming ep) /
1 (Use BULK video streaming ep));
+static bool sg_mode;
+module_param(sg_mode, bool, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(sg_mode, 0 (Don't use SG feature) /
+ 1 (Use scatterlist for SG-capable controllers));
+
Can't this be queried automatically from the UDC at runtime ?
Yes, it can be. But I believe its better to still provide a module
parameter to the UVC webcam module user as some UDCs may have flaky SG
implementations in H/W and then the user will not be able to use the
UVC gadget without using the SG feature of SG-capable UDCs.
I believe in worst-case its better to fall-back on memcpy from CPU if
the SG features in the UDC are not yet properly supported.
/*
* Function descriptors
*/
@@ -888,6 +893,9 @@ uvc_function_bind(struct usb_configuration *c, struct
usb_function *f) uvc-control_req-complete = uvc_function_ep0_complete;
uvc-control_req-context = uvc;
+ /* Use SG mode ? */
+ uvc-video.sg_mode = sg_mode;
+
/* Avoid letting this gadget enumerate until the userspace server is
* active.
*/
diff --git a/drivers/usb/gadget/uvc.h b/drivers/usb/gadget/uvc.h
index 8756853..3a54510 100644
--- a/drivers/usb/gadget/uvc.h
+++ b/drivers/usb/gadget/uvc.h
@@ -122,6 +122,7 @@ struct uvc_video
struct usb_request *req[UVC_NUM_REQUESTS];
__u8 *req_buffer[UVC_NUM_REQUESTS];
struct list_head req_free;
+ unsigned char *header_buf;
Don't you need one header per request ?
It would probably be easier to create a uvc_request structure to group the
request, the request header and the request buffer:
struct uvc_request{
struct usb_request *req;
__u8 *header;
__u8 *buffer;
};
and have a table of those in the uvc_video structure.
Ok. Will do this in V2.
spinlock_t req_lock;
void (*encode) (struct usb_request *req, struct uvc_video *video,
@@ -135,6 +136,7 @@ struct uvc_video
unsigned int fid;
bool bulk_streaming_ep;
+ bool sg_mode;
};
enum uvc_state
diff --git a/drivers/usb/gadget/uvc_video.c b/drivers/usb/gadget/uvc_video.c
index 87ac526..5f92f93 100644
--- a/drivers/usb/gadget/uvc_video.c
+++ b/drivers/usb/gadget/uvc_video.c
@@ -39,6 +39,25 @@ uvc_video_encode_header(struct uvc_video *video, struct
uvc_buffer *buf, }
static int
+uvc_video_encode_header_sg(struct uvc_video *video, struct uvc_buffer *buf,
+ int len)
+{
+ unsigned char *data = video-header_buf;
+
+ *data++ = 2;
+ *data = UVC_STREAM_EOH | video-fid;
+
+ if (!video-bulk_streaming_ep) {
+ if (buf-bytesused - video-queue.buf_used = len - 2)
+ *data |= UVC_STREAM_EOF;
+ } else {
+ *data |= UVC_STREAM_EOF;
+ }
+
+ return 2;
+}
Instead of duplicating the code could you just pass the header pointer to
uvc_video_encode_header() ? It might be even better to pass a uvc_request
structure pointer instead of a data pointer and
Re: [PATCH 1/1] usb: gadget/uvc: Add support for Bulk endpoint to be used as Video Streaming ep
Hi Laurent,
Thanks for your review comments.
On 4/29/2013 4:23 PM, Laurent Pinchart wrote:
Hi Bhupesh,
Thank you for the patch. Please see below for comments.
On Thursday 11 April 2013 15:04:04 Bhupesh Sharma wrote:
This patch adds the support for Bulk endpoint to be used as video streaming
endpoint, on basis of a module parameter.
By default, the gadget still supports Isochronous endpoint for video
streaming, but if the module parameter 'bulk_streaming_ep' is set to 1, we
can support Bulk endpoint as well, which is useful for UDC's which don't
support Isochronous endpoints.
The important difference between the two implementations is that,
alt-settings in a video streaming interface are supported only for
Isochronous endpoints as there are different alt-settings for
zero-bandwidth and full-bandwidth use-cases, but the same is not true for
Bulk endpoints, as they support only a single alt-setting.
Signed-off-by: Bhupesh Sharma bhupesh.sha...@st.com
---
Note that to ease review and integration of this patch, I have rebased it
on Laurent's UVC gadget git tree available here (head uvc-gadget):
git://linuxtv.org/pinchartl/uvcvideo.git
This will allow the patch to be pulled into Felipe's repo in one go
after review and any subsequent rework (if required).
Thank you.
drivers/usb/gadget/f_uvc.c | 321 +
drivers/usb/gadget/uvc.h |2 +
drivers/usb/gadget/uvc_v4l2.c | 17 ++-
drivers/usb/gadget/uvc_video.c | 13 ++-
4 files changed, 286 insertions(+), 67 deletions(-)
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index 38dcedd..e5953eb 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -45,6 +45,11 @@ static unsigned int streaming_maxburst;
module_param(streaming_maxburst, uint, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(streaming_maxburst, 0 - 15 (ss only));
+static bool bulk_streaming_ep;
+module_param(bulk_streaming_ep, bool, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(bulk_streaming_ep, 0 (Use ISOC video streaming ep) /
+ 1 (Use BULK video streaming ep));
+
Do you think an endpoint type property with values equal to isoc or bulk
would be more explicit ?
Yes. Explicit values seem better. So I will add this in V2.
Any value other than ISOC and BULK will be an flagged as an invalid
module argument.
/*
* Function descriptors
*/
@@ -135,6 +140,19 @@ static struct usb_interface_descriptor
uvc_streaming_intf_alt0 __initdata = { .iInterface = 0,
};
+static struct usb_interface_descriptor uvc_bulk_streaming_intf_alt0
+__initdata = {
+ .bLength= USB_DT_INTERFACE_SIZE,
+ .bDescriptorType= USB_DT_INTERFACE,
+ .bInterfaceNumber = UVC_INTF_VIDEO_STREAMING,
+ .bAlternateSetting = 0,
+ .bNumEndpoints = 1,
+ .bInterfaceClass= USB_CLASS_VIDEO,
+ .bInterfaceSubClass = UVC_SC_VIDEOSTREAMING,
+ .bInterfaceProtocol = 0x00,
+ .iInterface = 0,
+};
+
For consistency, could you please rename uvc_streaming_intf_alt* to
uvc_isoc_streaming_intf_alt* (in a separate preparation patch) ?
Ok.
static struct usb_interface_descriptor uvc_streaming_intf_alt1 __initdata =
{ .bLength = USB_DT_INTERFACE_SIZE,
.bDescriptorType= USB_DT_INTERFACE,
@@ -160,6 +178,18 @@ static struct usb_endpoint_descriptor
uvc_fs_streaming_ep __initdata = { .bInterval = 0,
};
+static struct usb_endpoint_descriptor uvc_fs_bulk_streaming_ep __initdata =
{ + .bLength= USB_DT_ENDPOINT_SIZE,
+ .bDescriptorType= USB_DT_ENDPOINT,
+ .bEndpointAddress = USB_DIR_IN,
+ .bmAttributes = USB_ENDPOINT_XFER_BULK,
+ /* The wMaxPacketSize and bInterval values will be initialized from
+* module parameters.
+*/
+ .wMaxPacketSize = 0,
+ .bInterval = 0,
You can remove these two lines (I've sent a patch to do so for the rest of the
structures).
Ok.
+};
+
static struct usb_endpoint_descriptor uvc_hs_streaming_ep __initdata = {
.bLength= USB_DT_ENDPOINT_SIZE,
.bDescriptorType= USB_DT_ENDPOINT,
@@ -173,6 +203,18 @@ static struct usb_endpoint_descriptor
uvc_hs_streaming_ep __initdata = { .bInterval = 0,
};
+static struct usb_endpoint_descriptor uvc_hs_bulk_streaming_ep __initdata =
{ + .bLength= USB_DT_ENDPOINT_SIZE,
+ .bDescriptorType= USB_DT_ENDPOINT,
+ .bEndpointAddress = USB_DIR_IN,
+ .bmAttributes = USB_ENDPOINT_XFER_BULK,
+ /* The wMaxPacketSize and bInterval values will be initialized from
+* module parameters.
+*/
+ .wMaxPacketSize = 0,
+ .bInterval = 0,
You can remove
Re: [PATCH 1/1] usb: gadget/uvc: Add support to allocate UVC payload and header as SG elements
Hi Bhupesh, On Wednesday 01 May 2013 01:08:23 Bhupesh SHARMA wrote: On 4/29/2013 8:08 PM, Laurent Pinchart wrote: On Wednesday 17 April 2013 09:44:25 Bhupesh Sharma wrote: This patch adds the support in UVC webcam gadget to allocate UVC header and payload as Scatter-Gather elements which can be used on a SG-capable UDC controller. A module parameter has been introduced for the same. One can set the module parameter 'sg_mode' to 1 to turn on this feature (by default this feature is turned-off). This ensures that we don't require a memcpy from CPU side to append UVC header in front of the UVC payload atleast for SG capable UDC contollers. Signed-off-by: Bhupesh Sharma bhupesh.sha...@st.com --- Note that to ease review and integration of this patch, I have rebased it on the following patch already circulated for review last week: [PATCH 1/1] usb: gadget/uvc: Add support for Bulk endpoint to be used as Video Streaming ep http://www.mail-archive.com/linux-usb@vger.kernel.org/msg19546.html The above patch was rebased on Laurent's UVC gadget git tree available here (head uvc-gadget): git://linuxtv.org/pinchartl/uvcvideo.git This will allow the patches to be pulled into Felipe's repo in one go after review and any subsequent rework (if required). drivers/usb/gadget/f_uvc.c |8 +++ drivers/usb/gadget/uvc.h |2 + drivers/usb/gadget/uvc_video.c | 113 - 3 files changed, 109 insertions(+), 14 deletions(-) diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c index e5953eb..ccf0253 100644 --- a/drivers/usb/gadget/f_uvc.c +++ b/drivers/usb/gadget/f_uvc.c @@ -50,6 +50,11 @@ module_param(bulk_streaming_ep, bool, S_IRUGO|S_IWUSR); MODULE_PARM_DESC(bulk_streaming_ep, 0 (Use ISOC video streaming ep) / 1 (Use BULK video streaming ep)); +static bool sg_mode; +module_param(sg_mode, bool, S_IRUGO|S_IWUSR); +MODULE_PARM_DESC(sg_mode, 0 (Don't use SG feature) / + 1 (Use scatterlist for SG-capable controllers)); + Can't this be queried automatically from the UDC at runtime ? Yes, it can be. But I believe its better to still provide a module parameter to the UVC webcam module user as some UDCs may have flaky SG implementations in H/W and then the user will not be able to use the UVC gadget without using the SG feature of SG-capable UDCs. I believe in worst-case its better to fall-back on memcpy from CPU if the SG features in the UDC are not yet properly supported. In that case could we default to use SG with UDCs that support it, and have a module parameter to disable SG ? -- Regards, Laurent Pinchart -- 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 v7 0/9] Reorganize R8A7779/Marzen USB code
Hello. Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130426' tag. It was created to fix the shortcomings in the R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have to touch both subtrees). The patches were conceived with the complete bisectability goal in mind. [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code [2/9] ehci-platform: add pre_setup() method to platform data [3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer [4/9] rcar-phy: remove EHCI internal buffer setup [5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource [6/9] rcar-phy: correct base address [7/9] rcar-phy: add platform data [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device [9/9] rcar-phy: handle platform data WBR, Sergei -- 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 v7 1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
registered in the Marzen board file. Move the data and code to their proper
place in setup-r8a7779.c; while at it, we have to rename r8a7779_late_devices[]
to r8a7779_standard_devices[] -- this seems legitimate since they are registered
from r8a7779_add_standard_devices() anyway.
Note that I'm deliberately changing the USB PHY platform device's 'id' field
from (previously just omitted) 0 to -1 as the device is a single of its kind.
Note also that the board and SoC code have to be in one patch to keep the code
bisectable...
The patch has been tested on the Marzen board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 5:
- fixed typos in the changelog.
Changes since version 4:
- resolved reject in the 'board-marzen.c' file, refreshed the patch.
Changes since version 3:
- refreshed the 'board-marzen.c' file.
Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- added a note about bisectability to the changelog.
arch/arm/mach-shmobile/board-marzen.c | 178 -
arch/arm/mach-shmobile/include/mach/r8a7779.h |1
arch/arm/mach-shmobile/setup-r8a7779.c| 185 +-
3 files changed, 184 insertions(+), 180 deletions(-)
Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -37,10 +37,6 @@
#include linux/mmc/host.h
#include linux/mmc/sh_mobile_sdhi.h
#include linux/mfd/tmio.h
-#include linux/usb/otg.h
-#include linux/usb/ehci_pdriver.h
-#include linux/usb/ohci_pdriver.h
-#include linux/pm_runtime.h
#include mach/hardware.h
#include mach/r8a7779.h
#include mach/common.h
@@ -150,26 +146,6 @@ static struct platform_device hspi_devic
.num_resources = ARRAY_SIZE(hspi_resources),
};
-/* USB PHY */
-static struct resource usb_phy_resources[] = {
- [0] = {
- .start = 0xffe7,
- .end= 0xffe70900 - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = 0xfff7,
- .end= 0xfff70900 - 1,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device usb_phy_device = {
- .name = rcar_usb_phy,
- .resource = usb_phy_resources,
- .num_resources = ARRAY_SIZE(usb_phy_resources),
-};
-
/* LEDS */
static struct gpio_led marzen_leds[] = {
{
@@ -205,161 +181,9 @@ static struct platform_device *marzen_de
sdhi0_device,
thermal_device,
hspi_device,
- usb_phy_device,
leds_device,
};
-/* USB */
-static struct usb_phy *phy;
-static int usb_power_on(struct platform_device *pdev)
-{
- if (!phy)
- return -EIO;
-
- pm_runtime_enable(pdev-dev);
- pm_runtime_get_sync(pdev-dev);
-
- usb_phy_init(phy);
-
- return 0;
-}
-
-static void usb_power_off(struct platform_device *pdev)
-{
- if (!phy)
- return;
-
- usb_phy_shutdown(phy);
-
- pm_runtime_put_sync(pdev-dev);
- pm_runtime_disable(pdev-dev);
-}
-
-static struct usb_ehci_pdata ehcix_pdata = {
- .power_on = usb_power_on,
- .power_off = usb_power_off,
- .power_suspend = usb_power_off,
-};
-
-static struct resource ehci0_resources[] = {
- [0] = {
- .start = 0xffe7,
- .end= 0xffe70400 - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = gic_iid(0x4c),
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct platform_device ehci0_device = {
- .name = ehci-platform,
- .id = 0,
- .dev= {
- .dma_mask = ehci0_device.dev.coherent_dma_mask,
- .coherent_dma_mask = 0x,
- .platform_data = ehcix_pdata,
- },
- .num_resources = ARRAY_SIZE(ehci0_resources),
- .resource = ehci0_resources,
-};
-
-static struct resource ehci1_resources[] = {
- [0] = {
- .start = 0xfff7,
- .end= 0xfff70400 - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = gic_iid(0x4d),
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct platform_device ehci1_device = {
- .name = ehci-platform,
- .id = 1,
- .dev= {
- .dma_mask = ehci1_device.dev.coherent_dma_mask,
-
[PATCH v7 2/9] ehci-platform: add pre_setup() method to platform data
Sometimes there is a need to initialize some non-standard registers mapped to
the EHCI region before accessing the standard EHCI registers. Add pre_setup()
method with 'struct usb_hcd *' parameter to be called just before ehci_setup()
to the 'ehci-platform' driver's platform data for this purpose...
While at it, add the missing incomplete declaration of 'struct platform_device'
to linux/usb/ehci_pdriver.h...
The patch has been tested on the Marzen and BOCK-W boards.
Suggested-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
Acked-by: Alan Stern st...@rowland.harvard.edu
---
Changes since version 3:
- added ACK from Alan Stern.
Changes since version 2:
- replaced #include with incomplete declarations of 'struct platform_device' and
'struct usb_hcd';
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- changed init() method to pre_setup() with different parameters and call site.
drivers/usb/host/ehci-platform.c |6 ++
include/linux/usb/ehci_pdriver.h |4
2 files changed, 10 insertions(+)
Index: renesas/drivers/usb/host/ehci-platform.c
===
--- renesas.orig/drivers/usb/host/ehci-platform.c
+++ renesas/drivers/usb/host/ehci-platform.c
@@ -46,6 +46,12 @@ static int ehci_platform_reset(struct us
ehci-big_endian_desc = pdata-big_endian_desc;
ehci-big_endian_mmio = pdata-big_endian_mmio;
+ if (pdata-pre_setup) {
+ retval = pdata-pre_setup(hcd);
+ if (retval 0)
+ return retval;
+ }
+
ehci-caps = hcd-regs + pdata-caps_offset;
retval = ehci_setup(hcd);
if (retval)
Index: renesas/include/linux/usb/ehci_pdriver.h
===
--- renesas.orig/include/linux/usb/ehci_pdriver.h
+++ renesas/include/linux/usb/ehci_pdriver.h
@@ -19,6 +19,9 @@
#ifndef __USB_CORE_EHCI_PDRIVER_H
#define __USB_CORE_EHCI_PDRIVER_H
+struct platform_device;
+struct usb_hcd;
+
/**
* struct usb_ehci_pdata - platform_data for generic ehci driver
*
@@ -50,6 +53,7 @@ struct usb_ehci_pdata {
/* Turn on only VBUS suspend power and hotplug detection,
* turn off everything else */
void (*power_suspend)(struct platform_device *pdev);
+ int (*pre_setup)(struct usb_hcd *hcd);
};
#endif /* __USB_CORE_EHCI_PDRIVER_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 v7 3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer
Setup the EHCI internal buffer (before EHCI driver has a chance to touch the
registers) using the pre_setup() method in 'struct usb_ehci_pdata'.
The patch has been tested on the Marzen board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 4:
- refreshed the patch.
Changes since version 3:
- lowercased the SoC name in the subject.
Changes since version 2:
- added #include linux/usb/hcd.h;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- changed from init() platform device method to pre_setup() as per the previous
patch.
arch/arm/mach-shmobile/setup-r8a7779.c | 16
1 file changed, 16 insertions(+)
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -33,6 +33,7 @@
#include linux/sh_timer.h
#include linux/dma-mapping.h
#include linux/usb/otg.h
+#include linux/usb/hcd.h
#include linux/usb/ehci_pdriver.h
#include linux/usb/ohci_pdriver.h
#include linux/pm_runtime.h
@@ -435,10 +436,25 @@ static void usb_power_off(struct platfor
pm_runtime_disable(pdev-dev);
}
+static int ehci_init_internal_buffer(struct usb_hcd *hcd)
+{
+ /*
+* Below are recommended values from the datasheet;
+* see [USB :: Setting of EHCI Internal Buffer].
+*/
+ /* EHCI IP internal buffer setting */
+ iowrite32(0x00ff0040, hcd-regs + 0x0094);
+ /* EHCI IP internal buffer enable */
+ iowrite32(0x0001, hcd-regs + 0x009C);
+
+ return 0;
+}
+
static struct usb_ehci_pdata ehcix_pdata = {
.power_on = usb_power_on,
.power_off = usb_power_off,
.power_suspend = usb_power_off,
+ .pre_setup = ehci_init_internal_buffer,
};
static struct resource ehci0_resources[] = {
--
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 v7 4/9] rcar-phy: remove EHCI internal buffer setup
Now that the EHCI internal buffer setup is done by the platform code, we can
remove such code from this driver as it never really belonged here. We also
no longer need the 2nd memory region now (2nd EHCI controller is simply missing
in e.g. R8A7778 SoC).
The patch has been tested on the Marzen and BOCK-W boards.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
Acked-by: Felipe Balbi ba...@ti.com
---
Changes since version 6:
- added an ACK from Felipe Balbi.
Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- split R8A7779 SoC file change to a separate patch.
drivers/usb/phy/rcar-phy.c | 28
1 file changed, 4 insertions(+), 24 deletions(-)
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -23,8 +23,6 @@
#define USBEH0 0x080C
#define USBOH0 0x081C
#define USBCTL00x0858
-#define EIIBC1 0x0094
-#define EIIBC2 0x009C
/* USBPCTRL1 */
#define PHY_RST(1 2)
@@ -40,7 +38,6 @@ struct rcar_usb_phy_priv {
spinlock_t lock;
void __iomem *reg0;
- void __iomem *reg1;
int counter;
};
@@ -59,7 +56,6 @@ static int rcar_usb_phy_init(struct usb_
struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
struct device *dev = phy-dev;
void __iomem *reg0 = priv-reg0;
- void __iomem *reg1 = priv-reg1;
int i;
u32 val;
unsigned long flags;
@@ -97,19 +93,6 @@ static int rcar_usb_phy_init(struct usb_
iowrite32(0x, (reg0 + USBPCTRL0));
/*
-* EHCI IP internal buffer setting
-* EHCI IP internal buffer enable
-*
-* These are recommended value of a datasheet
-* see [USB :: EHCI internal buffer setting]
-*/
- iowrite32(0x00ff0040, (reg0 + EIIBC1));
- iowrite32(0x00ff0040, (reg1 + EIIBC1));
-
- iowrite32(0x0001, (reg0 + EIIBC2));
- iowrite32(0x0001, (reg1 + EIIBC2));
-
- /*
* Bus alignment settings
*/
@@ -145,14 +128,13 @@ static void rcar_usb_phy_shutdown(struct
static int rcar_usb_phy_probe(struct platform_device *pdev)
{
struct rcar_usb_phy_priv *priv;
- struct resource *res0, *res1;
+ struct resource *res0;
struct device *dev = pdev-dev;
- void __iomem *reg0, *reg1;
+ void __iomem *reg0;
int ret;
res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (!res0 || !res1) {
+ if (!res0) {
dev_err(dev, Not enough platform resources\n);
return -EINVAL;
}
@@ -164,8 +146,7 @@ static int rcar_usb_phy_probe(struct pla
* this driver can't use devm_request_and_ioremap(dev, res) here
*/
reg0 = devm_ioremap_nocache(dev, res0-start, resource_size(res0));
- reg1 = devm_ioremap_nocache(dev, res1-start, resource_size(res1));
- if (!reg0 || !reg1) {
+ if (!reg0) {
dev_err(dev, ioremap error\n);
return -ENOMEM;
}
@@ -177,7 +158,6 @@ static int rcar_usb_phy_probe(struct pla
}
priv-reg0 = reg0;
- priv-reg1 = reg1;
priv-counter = 0;
priv-phy.dev = dev;
priv-phy.label = dev_name(dev);
--
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 v7 5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource
Now that 'drivers/usb/phy/rcar-phy.c' doesn't require the second memory resource
anymore, we can remove it from the R8A7779's USB PHY platform device.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 4:
- refreshed the patch.
Changes since version 3:
- lowercased the SoC name in the subject.
Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- new patch in this version, split from the previous one.
arch/arm/mach-shmobile/setup-r8a7779.c |5 -
1 file changed, 5 deletions(-)
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -395,11 +395,6 @@ static struct resource usb_phy_resources
.end= 0xffe70900 - 1,
.flags = IORESOURCE_MEM,
},
- [1] = {
- .start = 0xfff7,
- .end= 0xfff70900 - 1,
- .flags = IORESOURCE_MEM,
- },
};
static struct platform_device usb_phy_device = {
--
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 v7 7/9] rcar-phy: add platform data
Currently the driver hard-codes USBPCTRL0 register to 0. It is wrong since this
register contains board-specific USB ports configuration and so its value should
be somehow passed via the platform data. Add the global header file containing
'struct rcar_phy_platform_data' consisting of the various bit fields describing
USB ports' pin configuration.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 6:
- renamed the header file into linux/platform_data/usb-rcar-phy.h, renamed the
guarding #define accordingly;
- rephrased the changelog.
Changes since version 3:
- moved USBPCTRL0 register bit #define's to patch #9;
- replaced USBPCTRL0 register value in the platform data structure by a set of
bit fields describing the configuration of the board, rewrote changelog;
Changes since version 2:
- added #include linux/types.h;
- added ACKs from Simon Horman and Kuninori Morimoto.
include/linux/platform_data/usb-rcar-phy.h | 26 ++
1 file changed, 26 insertions(+)
Index: renesas/include/linux/platform_data/usb-rcar-phy.h
===
--- /dev/null
+++ renesas/include/linux/platform_data/usb-rcar-phy.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __USB_RCAR_PHY_H
+#define __USB_RCAR_PHY_H
+
+#include linux/types.h
+
+struct rcar_phy_platform_data {
+ bool port1_func:1; /* true: port 1 used by function, false: host */
+ unsigned penc1:1; /* Output of the PENC1 pin in function mode */
+ struct {/* Overcurrent pin control for ports 0..2 */
+ bool select_3_3v:1; /* true: USB_OVCn pin, false: OVCn pin */
+ /* Set to false on port 1 in function mode */
+ bool active_high:1; /* true: active high, false: active low */
+ /* Set to true on port 1 in function mode */
+ } ovc_pin[3];
+};
+
+#endif /* __USB_RCAR_PHY_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 v7 8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
Since we're now going to setup the USBPCTRL0 register using the USB PHY device's
platform data, we now need a way to pass those platform data from the board file
to the device which is situated in setup-r8a7779.c -- and what I'm suggesting is
r8a7779_add_usb_phy_device() that will register USB PHY platform device with the
passed platform data using platform_device_register_resndata() call; creating
this function involves deletion of 'usb_phy_device' from r8a7779_devices_dt[],
so that it will no longer be registered for the generic R8A7779 machine (where
we can't provide the platform data anyway), hence EHCI/OHCI drivers will fail
to load as well.
For the Marzen board, this new function will be called from marzen_init() to
register the USB PHY device early enough.
Note that the board and the SoC code have to be in one patch to keep the code
bisectable...
The patch has been tested on the Marzen board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 6:
- renamed the R-Car PHY driver header file in #include.
Changes since version 5:
- annotated USB PHY resources and platform data as '__initdata' since they're
kmemdup()'ed while registering the platform device anyway;
- fixed typo in the changelog.
Changes since version 4:
- refreshed the patch.
Changes since version 3:
- removed the initializer for 'usb_phy_platform_data';
- refreshed the 'board-marzen.c' file.
Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- added a note about bisectability to the changelog.
arch/arm/mach-shmobile/board-marzen.c |3 +++
arch/arm/mach-shmobile/include/mach/r8a7779.h |2 ++
arch/arm/mach-shmobile/setup-r8a7779.c| 18 +-
3 files changed, 14 insertions(+), 9 deletions(-)
Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -57,6 +57,8 @@ static struct regulator_consumer_supply
REGULATOR_SUPPLY(vdd33a, smsc911x),
};
+static struct rcar_phy_platform_data usb_phy_platform_data __initdata;
+
/* SMSC LAN89218 */
static struct resource smsc911x_resources[] = {
[0] = {
@@ -232,6 +234,7 @@ static void __init marzen_init(void)
r8a7779_init_irq_extpin(1); /* IRQ1 as individual interrupt */
r8a7779_add_standard_devices();
+ r8a7779_add_usb_phy_device(usb_phy_platform_data);
platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
}
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -4,6 +4,7 @@
#include linux/sh_clk.h
#include linux/pm_domain.h
#include linux/sh_eth.h
+#include linux/platform_data/usb-rcar-phy.h
struct platform_device;
@@ -33,6 +34,7 @@ extern void r8a7779_add_early_devices(vo
extern void r8a7779_add_standard_devices(void);
extern void r8a7779_add_standard_devices_dt(void);
extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
extern void r8a7779_init_late(void);
extern void r8a7779_clock_init(void);
extern void r8a7779_pinmux_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -389,7 +389,7 @@ static struct platform_device sata_devic
};
/* USB PHY */
-static struct resource usb_phy_resources[] = {
+static struct resource usb_phy_resources[] __initdata = {
[0] = {
.start = 0xffe70800,
.end= 0xffe70900 - 1,
@@ -397,13 +397,6 @@ static struct resource usb_phy_resources
},
};
-static struct platform_device usb_phy_device = {
- .name = rcar_usb_phy,
- .id = -1,
- .resource = usb_phy_resources,
- .num_resources = ARRAY_SIZE(usb_phy_resources),
-};
-
/* USB */
static struct usb_phy *phy;
@@ -575,7 +568,6 @@ static struct platform_device *r8a7779_d
scif5_device,
tmu00_device,
tmu01_device,
- usb_phy_device,
};
static struct platform_device *r8a7779_standard_devices[] __initdata = {
@@ -610,6 +602,14 @@ void __init r8a7779_add_ether_device(str
pdata, sizeof(*pdata));
}
+void __init r8a7779_add_usb_phy_device(struct
[PATCH v7 9/9] rcar-phy: handle platform data
Set the USBPCTRL0 register from the passed platform data in rcar_usb_phy_init();
don't reset it to 0 in rcar_usb_phy_shutdown() anymore as that does not make
sense. Also, don't allow the driver's probe to succeed when the platform data
are not supplied with a device.
The patch has been tested on the Marzen and BOCK-W boards.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
Acked-by: Felipe Balbi ba...@ti.com
---
Changes since version 6:
- renamed the R-Car PHY driver header file in #include;
- added an ACK from Felipe Balbi.
Changes since version 3:
- moved USBPCTRL0 register bit #define's from patch #7, removing the prefixes;
- implemented parsing of the platform data to set USBPCTRL0 register.
Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
drivers/usb/phy/rcar-phy.c | 51 +++--
1 file changed, 45 insertions(+), 6 deletions(-)
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -1,8 +1,9 @@
/*
* Renesas R-Car USB phy driver
*
- * Copyright (C) 2012 Renesas Solutions Corp.
+ * Copyright (C) 2012-2013 Renesas Solutions Corp.
* Kuninori Morimoto kuninori.morimoto...@renesas.com
+ * Copyright (C) 2013 Cogent Embedded, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -15,6 +16,7 @@
#include linux/platform_device.h
#include linux/spinlock.h
#include linux/module.h
+#include linux/platform_data/usb-rcar-phy.h
/* REGS block */
#define USBPCTRL0 0x00
@@ -24,6 +26,25 @@
#define USBOH0 0x1C
#define USBCTL00x58
+/* USBPCTRL0 */
+#define OVC2 (1 10) /* Switches the OVC input pin for port 2: */
+ /* 1: USB_OVC2, 0: OVC2 */
+#define OVC1_VBUS1 (1 9) /* Switches the OVC input pin for port 1: */
+ /* 1: USB_OVC1, 0: OVC1/VBUS1 */
+ /* Function mode: set to 0 */
+#define OVC0 (1 8) /* Switches the OVC input pin for port 0: */
+ /* 1: USB_OVC0 pin, 0: OVC0 */
+#define OVC2_ACT (1 6) /* Host mode: OVC2 polarity: */
+ /* 1: active-high, 0: active-low*/
+#define PENC (1 4) /* Function mode: output level of PENC1 pin: */
+ /* 1: high, 0: low */
+#define OVC0_ACT (1 3) /* Host mode: OVC0 polarity: */
+ /* 1: active-high, 0: active-low*/
+#define OVC1_ACT (1 1) /* Host mode: OVC1 polarity: */
+ /* 1: active-high, 0: active-low*/
+ /* Function mode: be sure to set to 1 */
+#define PORT1 (1 0) /* Selects port 1 mode:*/
+ /* 1: function, 0: host */
/* USBPCTRL1 */
#define PHY_RST(1 2)
#define PLL_ENB(1 1)
@@ -55,7 +76,9 @@ static int rcar_usb_phy_init(struct usb_
{
struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
struct device *dev = phy-dev;
+ struct rcar_phy_platform_data *pdata = dev-platform_data;
void __iomem *reg0 = priv-reg0;
+ const u8 ovcn_act[] = { OVC0_ACT, OVC1_ACT, OVC2_ACT };
int i;
u32 val;
unsigned long flags;
@@ -89,8 +112,21 @@ static int rcar_usb_phy_init(struct usb_
/* (4) USB-PHY reset clear */
iowrite32(PHY_ENB | PLL_ENB | PHY_RST, (reg0 + USBPCTRL1));
- /* set platform specific port settings */
- iowrite32(0x, (reg0 + USBPCTRL0));
+ /* Board specific port settings */
+ val = 0;
+ if (pdata-port1_func)
+ val |= PORT1;
+ if (pdata-penc1)
+ val |= PENC;
+ for (i = 0; i 3; i++) {
+ /* OVCn bits follow each other in the right order */
+ if (pdata-ovc_pin[i].select_3_3v)
+ val |= OVC0 i;
+ /* OVCn_ACT bits are spaced by irregular intervals */
+ if (pdata-ovc_pin[i].active_high)
+ val |= ovcn_act[i];
+ }
+ iowrite32(val, (reg0 + USBPCTRL0));
/*
* Bus alignment settings
@@ -117,10 +153,8 @@ static void rcar_usb_phy_shutdown(struct
xhci_hcd 0000:11:00.0: HW died, polling stopped.
Hi, I just tried 3.9 kernel with pcie_aspm=off and in another attempt with pcie_aspm=native. I realized the message HW died happens only in the former case. I believe this is a bug. If I unplug an express card with a NEC-based USB3 host it should be properly terminated, and xhci_hcd should unbind *even* when HW died happened. It is not the case now so I have to do: echo 1 /sys/bus/pci/devices/:11:00.0/remove to get rid of the stale 11:00 device from my system (sysfs entries): /proc/iomem f1104000-f1104fff : r8169 f680-f6bf : :00:02.0 f6c0-f7cf : PCI Bus :11 -f6c0-f6c01fff : :11:00.0 - f6c0-f6c01fff : xhci_hcd f7d0-f7df : PCI Bus :0b f7d0-f7d0 : :0b:00.0 f7d0-f7d0 : xhci_hcd /proc/interrupts: - 45: 1 0 PCI-MSI-edge xhci_hcd - 46: 0 0 PCI-MSI-edge xhci_hcd - 47: 0 0 PCI-MSI-edge xhci_hcd Let's say that when pcie_aspm=off the first hot eject of the express card with the USB3.0 controller does not result in HW died but in HC error bitmask = 0x4, whatever that means. That is because of pciehp being broken under pcie_aspm=off (unlike under pcie_aspm=native) but is not the story for linux-usb. [ 62.960729] xhci_hcd :0b:00.0: Poll event ring: 4294943584 [ 62.960732] xhci_hcd :11:00.0: Poll event ring: 4294943584 [ 62.960757] xhci_hcd :11:00.0: op reg status = 0x0 [ 62.960763] xhci_hcd :11:00.0: ir_set 0 pending = 0x2 [ 62.960764] xhci_hcd :11:00.0: HC error bitmask = 0x4 [ 62.960765] xhci_hcd :11:00.0: Event ring: [ 62.960768] xhci_hcd :11:00.0: @d6020400 d602 01003028 c001 [ 62.960769] xhci_hcd :0b:00.0: op reg status = 0x0 [ 62.960771] xhci_hcd :11:00.0: @d6020410 [ 62.960772] xhci_hcd :11:00.0: @d6020420 [ 62.960773] xhci_hcd :0b:00.0: ir_set 0 pending = 0x2 [ 62.960775] xhci_hcd :11:00.0: @d6020430 [ 62.960776] xhci_hcd :0b:00.0: HC error bitmask = 0x0 [ 62.960777] xhci_hcd :11:00.0: @d6020440 The kernel is still looking for the device, silly, the device is ejected from the express card slot already: +[ 62.961160] xhci_hcd :11:00.0: // xHC command ring deq ptr low bits + flags = @0008 +[ 62.961161] xhci_hcd :11:00.0: // xHC command ring deq ptr high bits = @ A subsequent hot re-insert of the card is unnoticed by pciehp (due to a bug cause by pcie_aspm=off) and therefore, xhci_hcd is puzzled and spits out: +[ 123.191537] xhci_hcd :0b:00.0: Poll event ring: 4294949600 +[ 123.191547] xhci_hcd :11:00.0: Poll event ring: 4294949600 +[ 123.191557] xhci_hcd :11:00.0: op reg status = 0x +[ 123.191563] xhci_hcd :0b:00.0: op reg status = 0x0 +[ 123.191570] xhci_hcd :0b:00.0: ir_set 0 pending = 0x2 +[ 123.191574] xhci_hcd :11:00.0: HW died, polling stopped. +[ 123.191580] xhci_hcd :0b:00.0: HC error bitmask = 0x0 At this step xhci_hcd should unbind the dead device so that it's sysfs entries could be removed (bot iomem and interrupts). If that doe not happen or is not done manually a subsequent hot insert has no chance to succeed and will silently proceed but device is left unconfigured and sysfs entries show just crappy cached values. This can be demonstrated when a desperate users inserts a different express card (a mixture of both is shown in lspci entries but only the old data in sysfs entries). Lets cleanup the mess and ensure xhci_hcd releases resources allocated by the dead device. I speculate the HC error bitmask = 0x4 should result in a HW died case as well. Thank you, Martin P.S.: Collected dmesg/lspci/iomem/interrupts data are at: http://195.113.57.32/~mmokrejs/tmp/20130430.tar.bz2 in 3.9/off subdirectory (the pcie_aspm=off case). The working pcie_aspm=native behavior is documented under 3.9/native subdirectory. -- 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 v6 2/3] ARM: shmobile: r8a7778: add USB support
Add USB clock and EHCI, OHCI, and USB PHY platform devices for R8A7778 SoC; add
a function to register PHY device with board-specific platform data and register
EHCI and OHCI platfrom devices from the init_late() board method.
Also, don't forget to enable CONFIG_ARCH_HAS_[EO]HCI options for R8A7778 SoC in
Kconfig...
The patch has been tested on the BOCK-W board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
Changes since version 5:
- renamed the R-Car PHY driver header file in #include.
Changes since version 4:
- annotated USB resources and '[eo]hci_info' as '__initdata' since they're
kmemdup()'ed while registering the platform devices anyway;
- refreshed the patch.
Changes since version 3:
- resolved reject in the 'clock-r8a7778.c' file, refreshed the patch.
Changes since version 2:
- refreshed the patch.
Changes since the original posting:
- resolved rejects in the 'clock-r8a7778.c' file;
- lowercased the SoC name in the subject.
arch/arm/mach-shmobile/Kconfig|2
arch/arm/mach-shmobile/clock-r8a7778.c|4
arch/arm/mach-shmobile/include/mach/r8a7778.h |3
arch/arm/mach-shmobile/setup-r8a7778.c| 108 ++
4 files changed, 117 insertions(+)
Index: renesas/arch/arm/mach-shmobile/Kconfig
===
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -41,6 +41,8 @@ config ARCH_R8A7778
select CPU_V7
select SH_CLK_CPG
select ARM_GIC
+ select USB_ARCH_HAS_EHCI
+ select USB_ARCH_HAS_OHCI
config ARCH_R8A7779
bool R-Car H1 (R8A77790)
Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -105,6 +105,7 @@ static struct clk *main_clks[] = {
enum {
MSTP323, MSTP322, MSTP321,
MSTP114,
+ MSTP100,
MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
MSTP016, MSTP015,
MSTP_NR };
@@ -114,6 +115,7 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP322] = SH_CLK_MSTP32(p_clk, MSTPCR3, 22, 0), /* SDHI1 */
[MSTP321] = SH_CLK_MSTP32(p_clk, MSTPCR3, 21, 0), /* SDHI2 */
[MSTP114] = SH_CLK_MSTP32(p_clk, MSTPCR1, 14, 0), /* Ether */
+ [MSTP100] = SH_CLK_MSTP32(p_clk, MSTPCR1, 0, 0), /* USB0/1 */
[MSTP026] = SH_CLK_MSTP32(p_clk, MSTPCR0, 26, 0), /* SCIF0 */
[MSTP025] = SH_CLK_MSTP32(p_clk, MSTPCR0, 25, 0), /* SCIF1 */
[MSTP024] = SH_CLK_MSTP32(p_clk, MSTPCR0, 24, 0), /* SCIF2 */
@@ -130,6 +132,8 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID(sh_mobile_sdhi.1, mstp_clks[MSTP322]), /* SDHI1 */
CLKDEV_DEV_ID(sh_mobile_sdhi.2, mstp_clks[MSTP321]), /* SDHI2 */
CLKDEV_DEV_ID(sh-eth, mstp_clks[MSTP114]), /* Ether */
+ CLKDEV_DEV_ID(ehci-platform, mstp_clks[MSTP100]), /* USB EHCI
port0/1 */
+ CLKDEV_DEV_ID(ohci-platform, mstp_clks[MSTP100]), /* USB OHCI
port0/1 */
CLKDEV_DEV_ID(sh-sci.0, mstp_clks[MSTP026]), /* SCIF0 */
CLKDEV_DEV_ID(sh-sci.1, mstp_clks[MSTP025]), /* SCIF1 */
CLKDEV_DEV_ID(sh-sci.2, mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -20,10 +20,13 @@
#include linux/mmc/sh_mobile_sdhi.h
#include linux/sh_eth.h
+#include linux/platform_data/usb-rcar-phy.h
extern void r8a7778_add_standard_devices(void);
extern void r8a7778_add_standard_devices_dt(void);
extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7778_init_late(void);
extern void r8a7778_init_delay(void);
extern void r8a7778_init_irq(void);
extern void r8a7778_init_irq_dt(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -30,6 +30,12 @@
#include linux/irqchip.h
#include linux/serial_sci.h
#include linux/sh_timer.h
+#include linux/pm_runtime.h
+#include linux/usb/phy.h
+#include linux/usb/hcd.h
+#include linux/usb/ehci_pdriver.h
+#include linux/usb/ohci_pdriver.h
+#include linux/dma-mapping.h
#include mach/irqs.h
#include mach/r8a7778.h
#include mach/common.h
@@ -89,6 +95,99 @@ static struct sh_timer_config sh_tmu1_pl
sh_tmu##idx##_platform_data, \
sizeof(sh_tmu##idx##_platform_data))
+/* USB PHY */
+static struct resource usb_phy_resources[] __initdata = {
+ DEFINE_RES_MEM(0xffe70800,
[PATCH v6 3/3] ARM: shmobile: BOCK-W: add USB support
Register the USB PHY device from bockw_init(), passing the platform data to it.
Set machine's init_late() method to r8a7778_init_late() in order for [EO]HCI to
get registered too...
The patch has been tested on the BOCK-W board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
Changes since version 4:
- annotated 'usb_phy_platform_data' as '__initdata' since it's kmemdup()'ed
while registering the platform device anyway;
- refreshed the patch.
Changes since version 3:
- removed initializer for 'usb_phy_platform_data' letting it be set to all 0s;
- refreshed the patch.
Changes since version 2:
- refreshed the patch.
Changes since the original posting:
- removed initializer for no longer existing field in 'usb_phy_platform_data',
modified the comment to the 'ferrite_bead' field initializer.
arch/arm/mach-shmobile/board-bockw.c |4
1 file changed, 4 insertions(+)
Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -63,6 +63,8 @@ static struct sh_mobile_sdhi_info sdhi0_
.tmio_flags = TMIO_MMC_HAS_IDLE_WAIT,
};
+static struct rcar_phy_platform_data usb_phy_platform_data __initdata;
+
static const struct pinctrl_map bockw_pinctrl_map[] = {
/* SCIF0 */
PIN_MAP_MUX_GROUP_DEFAULT(sh-sci.0, pfc-r8a7778,
@@ -91,6 +93,7 @@ static void __init bockw_init(void)
r8a7778_clock_init();
r8a7778_init_irq_extpin(1);
r8a7778_add_standard_devices();
+ r8a7778_add_usb_phy_device(usb_phy_platform_data);
pinctrl_register_mappings(bockw_pinctrl_map,
ARRAY_SIZE(bockw_pinctrl_map));
@@ -146,4 +149,5 @@ DT_MACHINE_START(BOCKW_DT, bockw)
.init_machine = bockw_init,
.init_time = shmobile_timer_init,
.dt_compat = bockw_boards_compat_dt,
+ .init_late = r8a7778_init_late,
MACHINE_END
--
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 v2] HID: add support for Sony RF receiver with USB product id 0x0374
Hi Jiri, On Tue, 2013-01-15 at 17:02 +0100, Jiri Kosina wrote: On Tue, 15 Jan 2013, Fernando Luis Vázquez Cao wrote: Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have a RF receiver, multi-interface USB device 054c:0374, that is used to connect a wireless keyboard and a wireless mouse. The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not seem to be generating any pointer events. The problem is that the mouse pointer is wrongly declared as a constant non-data variable in the report descriptor (see lsusb and usbhid-dump output below), with the consequence that it is ignored by the HID code. Add this device to the have-special-driver list and fix up the report descriptor in the Sony-specific driver which happens to already have a fixup for a similar firmware bug. Applied, thanks. It looks like after the merge of the the sony and steelseries branches the hid core hunk was left out, which means that this fix-up is never applied. I will be replying to this email with a fix. Thanks, Fernando -- 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] HID: fix botched tree merge that disabled fix-up for certain Sony RF receivers
It looks like the manual merge 0d69a3c731e120b05b7da9fb976830475a3fbc01 (Merge
branches 'for-3.9/sony' and 'for-3.9/steelseries' into for-linus) accidentally
removed Sony RF receiver with USB product id 0x0374 from the have special
driver list, effectively nullifying a464918419f94a0043d2f549d6defb4c3f69f68a
(HID: add support for Sony RF receiver with USB product id 0x0374). Add the
device back to the list.
Cc: sta...@vger.kernel.org
Signed-off-by: Fernando Luis Vazquez Cao ferna...@oss.ntt.co.jp
---
diff -urNp linux-3.9/drivers/hid/hid-core.c linux-3.9-fix/drivers/hid/hid-core.c
--- linux-3.9/drivers/hid/hid-core.c2013-04-29 09:36:01.0 +0900
+++ linux-3.9-fix/drivers/hid/hid-core.c2013-04-30 21:53:57.596269692
+0900
@@ -1702,6 +1702,7 @@ static const struct hid_device_id hid_ha
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY,
USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY,
USB_DEVICE_ID_SONY_PS3_CONTROLLER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE)
},
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGP_MOUSE)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_STEELSERIES,
USB_DEVICE_ID_STEELSERIES_SRWS1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SUNPLUS, USB_DEVICE_ID_SUNPLUS_WDESKTOP)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_THINGM, USB_DEVICE_ID_BLINK1) },
--
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: xhci_hcd 0000:11:00.0: HW died, polling stopped.
The HW died, polling stopped message is harmless. It happens when the xHCI host goes into a PCI low power state (D3). When the PCI host goes into D3cold, the registers will read as all Fs, and the polling loop will mistakenly believe the hardware has been removed. However, this bug only effects the debug code. It does not effect any other part of the xHCI driver. Please disregard the HW died, polling stopped messages in dmesg. Sarah Sharp On Wed, May 01, 2013 at 01:07:48AM +0200, Martin Mokrejs wrote: Hi, I just tried 3.9 kernel with pcie_aspm=off and in another attempt with pcie_aspm=native. I realized the message HW died happens only in the former case. I believe this is a bug. If I unplug an express card with a NEC-based USB3 host it should be properly terminated, and xhci_hcd should unbind *even* when HW died happened. It is not the case now so I have to do: echo 1 /sys/bus/pci/devices/:11:00.0/remove to get rid of the stale 11:00 device from my system (sysfs entries): /proc/iomem f1104000-f1104fff : r8169 f680-f6bf : :00:02.0 f6c0-f7cf : PCI Bus :11 -f6c0-f6c01fff : :11:00.0 - f6c0-f6c01fff : xhci_hcd f7d0-f7df : PCI Bus :0b f7d0-f7d0 : :0b:00.0 f7d0-f7d0 : xhci_hcd /proc/interrupts: - 45: 1 0 PCI-MSI-edge xhci_hcd - 46: 0 0 PCI-MSI-edge xhci_hcd - 47: 0 0 PCI-MSI-edge xhci_hcd Let's say that when pcie_aspm=off the first hot eject of the express card with the USB3.0 controller does not result in HW died but in HC error bitmask = 0x4, whatever that means. That is because of pciehp being broken under pcie_aspm=off (unlike under pcie_aspm=native) but is not the story for linux-usb. [ 62.960729] xhci_hcd :0b:00.0: Poll event ring: 4294943584 [ 62.960732] xhci_hcd :11:00.0: Poll event ring: 4294943584 [ 62.960757] xhci_hcd :11:00.0: op reg status = 0x0 [ 62.960763] xhci_hcd :11:00.0: ir_set 0 pending = 0x2 [ 62.960764] xhci_hcd :11:00.0: HC error bitmask = 0x4 [ 62.960765] xhci_hcd :11:00.0: Event ring: [ 62.960768] xhci_hcd :11:00.0: @d6020400 d602 01003028 c001 [ 62.960769] xhci_hcd :0b:00.0: op reg status = 0x0 [ 62.960771] xhci_hcd :11:00.0: @d6020410 [ 62.960772] xhci_hcd :11:00.0: @d6020420 [ 62.960773] xhci_hcd :0b:00.0: ir_set 0 pending = 0x2 [ 62.960775] xhci_hcd :11:00.0: @d6020430 [ 62.960776] xhci_hcd :0b:00.0: HC error bitmask = 0x0 [ 62.960777] xhci_hcd :11:00.0: @d6020440 The kernel is still looking for the device, silly, the device is ejected from the express card slot already: +[ 62.961160] xhci_hcd :11:00.0: // xHC command ring deq ptr low bits + flags = @0008 +[ 62.961161] xhci_hcd :11:00.0: // xHC command ring deq ptr high bits = @ A subsequent hot re-insert of the card is unnoticed by pciehp (due to a bug cause by pcie_aspm=off) and therefore, xhci_hcd is puzzled and spits out: +[ 123.191537] xhci_hcd :0b:00.0: Poll event ring: 4294949600 +[ 123.191547] xhci_hcd :11:00.0: Poll event ring: 4294949600 +[ 123.191557] xhci_hcd :11:00.0: op reg status = 0x +[ 123.191563] xhci_hcd :0b:00.0: op reg status = 0x0 +[ 123.191570] xhci_hcd :0b:00.0: ir_set 0 pending = 0x2 +[ 123.191574] xhci_hcd :11:00.0: HW died, polling stopped. +[ 123.191580] xhci_hcd :0b:00.0: HC error bitmask = 0x0 At this step xhci_hcd should unbind the dead device so that it's sysfs entries could be removed (bot iomem and interrupts). If that doe not happen or is not done manually a subsequent hot insert has no chance to succeed and will silently proceed but device is left unconfigured and sysfs entries show just crappy cached values. This can be demonstrated when a desperate users inserts a different express card (a mixture of both is shown in lspci entries but only the old data in sysfs entries). Lets cleanup the mess and ensure xhci_hcd releases resources allocated by the dead device. I speculate the HC error bitmask = 0x4 should result in a HW died case as well. Thank you, Martin P.S.: Collected dmesg/lspci/iomem/interrupts data are at: http://195.113.57.32/~mmokrejs/tmp/20130430.tar.bz2 in 3.9/off subdirectory (the pcie_aspm=off case). The working pcie_aspm=native behavior is documented under 3.9/native subdirectory. -- 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: xhci_hcd 0000:11:00.0: HW died, polling stopped.
: 4294949600 +[ 123.191547] xhci_hcd :11:00.0: Poll event ring: 4294949600 +[ 123.191557] xhci_hcd :11:00.0: op reg status = 0x +[ 123.191563] xhci_hcd :0b:00.0: op reg status = 0x0 +[ 123.191570] xhci_hcd :0b:00.0: ir_set 0 pending = 0x2 +[ 123.191574] xhci_hcd :11:00.0: HW died, polling stopped. +[ 123.191580] xhci_hcd :0b:00.0: HC error bitmask = 0x0 At this step xhci_hcd should unbind the dead device so that it's sysfs entries could be removed (bot iomem and interrupts). If that doe not happen or is not done manually a subsequent hot insert has no chance to succeed and will silently proceed but device is left unconfigured and sysfs entries show just crappy cached values. This can be demonstrated when a desperate users inserts a different express card (a mixture of both is shown in lspci entries but only the old data in sysfs entries). Lets cleanup the mess and ensure xhci_hcd releases resources allocated by the dead device. I speculate the HC error bitmask = 0x4 should result in a HW died case as well. Thank you, Martin P.S.: Collected dmesg/lspci/iomem/interrupts data are at: http://195.113.57.32/~mmokrejs/tmp/20130430.tar.bz2 in 3.9/off subdirectory (the pcie_aspm=off case). The working pcie_aspm=native behavior is documented under 3.9/native subdirectory. -- 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
