Re: USB 3.0 driver code flow for OTG gadget/host decision process
On Thu, Mar 27, 2014 at 12:32:07PM -0600, David Kochendorfer wrote: > Greg, > > I apologize if you've already received a copy of this - I inadvertently > shutdown evolution in the middle of sending and it doesn't look like the > first one was sent, so ... > > Is there a document/tutorial on the USB 3.0 driver code flow in general, > especially regarding the OTG decisions process? > > I am interested in both: (1) my Samsung (android linux) defaults to a > host at 2.0 when a 3.0 OTG gadget is plugged in, posting a pop-up to > select 3.0; I'd like to have it default to 3.0 in that case. That sounds like a hardware configuration issue, can't you just select this order properly in your code? > I'm also interested in your thoughts on what it would take to make the > large file data transfer (isochronous?) rate approach the 3.0 spec > maximum, even if it means compromising other transfers. Where are you seeing slowdowns compared to "possible maximum speeds"? There are known areas that we can improve on, but a lot of them still rely on the hardwar getting things right, and I don't know if that's the case that hardware is even doing everything right just yet. And we can't "compromise other transfers", especially with isoc transfers, that's not how USB works. good luck, 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
[RFC] mtd: nand: Preparatory patch for adding on-die ECC controller support. This patch adds NAND_ECC_HW_ON_DIE and all other changes to generic code.
Pekon,
Before I go any further with this, could you confirm that what is
below is what you had in mind as far as the generic portion of the
patch is concerned. If so, I'll go ahead and create the second,
Micron-specific part next.
Thanks,
--david
PS: This patch adds a one-liner to of_mtd.c that I forgot about previously.
Signed-off-by: David Mosberger
---
drivers/mtd/nand/nand_base.c | 36 +---
drivers/of/of_mtd.c |1 +
include/linux/mtd/nand.h |7 +++
3 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 5826da3..b94e2e9 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3783,22 +3783,46 @@ EXPORT_SYMBOL(nand_scan_ident);
int nand_scan_tail(struct mtd_info *mtd)
{
int i;
+ u8 features[ONFI_SUBFEATURE_PARAM_LEN];
struct nand_chip *chip = mtd->priv;
struct nand_ecc_ctrl *ecc = &chip->ecc;
struct nand_buffers *nbuf;
+ if (chip->onfi_get_features(mtd, chip, ONFI_FEATURE_ADDR_OP_MODE,
+ features) >= 0) {
+ if (features[0] & ONFI_FEATURE_OP_MODE_ENABLE_ON_DIE_ECC) {
+ /*
+* If the chip has on-die ECC enabled, we kind
+* of have to do the same...
+*/
+ chip->ecc.mode = NAND_ECC_HW_ON_DIE;
+ pr_info("Using on-die ECC\n");
+ }
+ }
+
/* New bad blocks should be marked in OOB, flash-based BBT, or both */
BUG_ON((chip->bbt_options & NAND_BBT_NO_OOB_BBM) &&
!(chip->bbt_options & NAND_BBT_USE_FLASH));
if (!(chip->options & NAND_OWN_BUFFERS)) {
+ size_t on_die_bufsz = 0;
+
+ if (chip->ecc.mode == NAND_ECC_HW_ON_DIE)
+ on_die_bufsz = 2*(mtd->writesize + mtd->oobsize);
+
nbuf = kzalloc(sizeof(*nbuf) + mtd->writesize
- + mtd->oobsize * 3, GFP_KERNEL);
+ + mtd->oobsize * 3 + on_die_bufsz, GFP_KERNEL);
if (!nbuf)
return -ENOMEM;
nbuf->ecccalc = (uint8_t *)(nbuf + 1);
nbuf->ecccode = nbuf->ecccalc + mtd->oobsize;
nbuf->databuf = nbuf->ecccode + mtd->oobsize;
+ if (chip->ecc.mode == NAND_ECC_HW_ON_DIE) {
+ nbuf->chkbuf = (nbuf->databuf + mtd->writesize
+ + mtd->oobsize);
+ nbuf->rawbuf = (nbuf->chkbuf + mtd->writesize
+ + mtd->oobsize);
+ }
chip->buffers = nbuf;
} else {
@@ -3956,6 +3980,7 @@ int nand_scan_tail(struct mtd_info *mtd)
ecc->strength = ecc->bytes * 8 / fls(8 * ecc->size);
break;
+ case NAND_ECC_HW_ON_DIE:
case NAND_ECC_NONE:
pr_warn("NAND_ECC_NONE selected by board driver. "
"This is not recommended!\n");
@@ -4023,8 +4048,13 @@ int nand_scan_tail(struct mtd_info *mtd)
/* Invalidate the pagebuffer reference */
chip->pagebuf = -1;
- /* Large page NAND with SOFT_ECC should support subpage reads */
- if ((ecc->mode == NAND_ECC_SOFT) && (chip->page_shift > 9))
+ /*
+* Large page NAND with SOFT_ECC or on-die ECC should support
+* subpage reads.
+*/
+ if (((ecc->mode == NAND_ECC_SOFT)
+|| (chip->ecc.mode == NAND_ECC_HW_ON_DIE))
+ && (chip->page_shift > 9))
chip->options |= NAND_SUBPAGE_READ;
/* Fill in remaining MTD driver data */
diff --git a/drivers/of/of_mtd.c b/drivers/of/of_mtd.c
index b7361ed..c844c84 100644
--- a/drivers/of/of_mtd.c
+++ b/drivers/of/of_mtd.c
@@ -23,6 +23,7 @@ static const char *nand_ecc_modes[] = {
[NAND_ECC_HW_SYNDROME] = "hw_syndrome",
[NAND_ECC_HW_OOB_FIRST] = "hw_oob_first",
[NAND_ECC_SOFT_BCH] = "soft_bch",
+ [NAND_ECC_HW_ON_DIE]= "hw_on_die",
};
/**
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 450d61e..a1cc980 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -115,6 +115,7 @@ typedef enum {
NAND_ECC_HW_SYNDROME,
NAND_ECC_HW_OOB_FIRST,
NAND_ECC_SOFT_BCH,
+ NAND_ECC_HW_ON_DIE,
} nand_ecc_modes_t;
/*
@@ -214,6 +215,10 @@ struct nand_chip;
/* Vendor-specific feature address (Micron) */
#define ONFI_FEATURE_ADDR_READ_RETRY 0x89
+/* Vendor-specific array operation mode (Micron) */
+#define ONFI_FEATURE_ADDR_OP_MODE 0x90
+#define ONFI_FEATURE_OP_MODE_ENABLE_ON_DIE_ECC 0x08
+
/* ONFI subfeature parameters length */
#define ONFI_SUBFEATURE_PARAM_LEN 4
@@ -516,6 +521,8 @@ struct nand_buffers {
Re: problem with resume after s2ram
On Thu, Mar 27 2014, Alan Stern wrote: > Oops -- I just realized that the instructions I sent you before were > incomplete. Please try running the same test again, but this time > issue the following commands to suspend the device: > > echo on >/sys/bus/usb/devices/4-2/power/control > echo 0 >/sys/bus/usb/devices/4-2/bConfigurationValue > echo auto >/sys/bus/pci/devices/:00:12.1/power/control > echo auto >/sys/bus/usb/devices/4-2/power/control > > Then a few seconds later, the following command to resume the device: > > echo on >/sys/bus/usb/devices/4-2/power/control > > Without the write to the PCI device, the USB controller did not go into > suspend and so it wasn't a valid test. Hi Alan, These are my commands: echo 8 >/proc/sys/kernel/printk echo on >/sys/bus/usb/devices/4-2/power/control sleep 1 echo 0 >/sys/bus/usb/devices/4-2/bConfigurationValue sleep 1 echo auto >/sys/bus/pci/devices/:00:12.1/power/control sleep 1 echo auto >/sys/bus/usb/devices/4-2/power/control sleep 10 echo on >/sys/bus/usb/devices/4-2/power/control Please find attached the kernel messages and the content of the registers file once per second. > As for the changing hcca frame value, that was just a wild guess on my > part. Still, if you find it's _not_ changing after this new test, that > would explain the problem you experienced. It's still changing. -- Peter 2014-03-27T21:49:34.060126+01:00 micropit kernel: [ 192.519501] usb 4-2: unregistering interface 4-2:1.0 2014-03-27T21:49:34.060161+01:00 micropit kernel: [ 192.519608] ohci-pci :00:12.1: shutdown urb 8801210a1240 ep1in-intr 2014-03-27T21:49:34.100112+01:00 micropit kernel: [ 192.558362] usb 4-2: usb_disable_device nuking non-ep0 URBs 2014-03-27T21:49:36.564126+01:00 micropit kernel: [ 195.023277] usb 4-2: usb auto-suspend, wakeup 0 2014-03-27T21:49:36.564162+01:00 micropit kernel: [ 195.023298] hub 4-0:1.0: hub_suspend 2014-03-27T21:49:36.564165+01:00 micropit kernel: [ 195.023324] usb usb4: bus auto-suspend, wakeup 1 2014-03-27T21:49:36.564168+01:00 micropit kernel: [ 195.023334] ohci-pci :00:12.1: suspend root hub 2014-03-27T21:49:36.564171+01:00 micropit kernel: [ 195.023686] ohci-pci :00:12.1: hcd_pci_runtime_suspend: 0 2014-03-27T21:49:46.108132+01:00 micropit kernel: [ 204.575426] ohci-pci :00:12.1: powerup ports 2014-03-27T21:49:46.132137+01:00 micropit kernel: [ 204.596549] ohci-pci :00:12.1: hcd_pci_runtime_resume: 0 2014-03-27T21:49:46.132172+01:00 micropit kernel: [ 204.596569] usb usb4: usb auto-resume 2014-03-27T21:49:46.132175+01:00 micropit kernel: [ 204.596581] ohci-pci :00:12.1: resume root hub 2014-03-27T21:49:46.132178+01:00 micropit kernel: [ 204.596594] usb usb4: usb wakeup-resume 2014-03-27T21:49:46.204123+01:00 micropit kernel: [ 204.671043] hub 4-0:1.0: hub_resume 2014-03-27T21:49:46.204159+01:00 micropit kernel: [ 204.671198] hub 4-0:1.0: port 2: status 0303 change 2014-03-27T21:49:46.204163+01:00 micropit kernel: [ 204.671299] hub 4-0:1.0: state 7 ports 3 chg evt 2014-03-27T21:49:46.204166+01:00 micropit kernel: [ 204.671379] usb 4-2: finish resume 2014-03-27T21:49:46.204178+01:00 micropit kernel: [ 204.672598] ohci-pci :00:12.1: urb 8801214e8a40 path 2 ep0in 5ec2 cc 5 --> status -62 2014-03-27T21:49:46.208145+01:00 micropit kernel: [ 204.672681] usb 4-2: retry with reset-resume 2014-03-27T21:49:46.236076+01:00 micropit kernel: [ 204.702512] ohci-pci :00:12.1: port[1] reset timeout, stat 0313 2014-03-27T21:49:46.240071+01:00 micropit kernel: [ 204.705874] hub 4-0:1.0: state 7 ports 3 chg evt 0004 2014-03-27T21:49:46.252140+01:00 micropit kernel: [ 204.716594] hub 4-0:1.0: state 7 ports 3 chg evt 0004 2014-03-27T21:49:46.440125+01:00 micropit kernel: [ 204.904711] ohci-pci :00:12.1: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS 2014-03-27T21:49:46.496125+01:00 micropit kernel: [ 204.960790] usb 4-2: reset low-speed USB device number 2 using ohci-pci 2014-03-27T21:49:46.520096+01:00 micropit kernel: [ 204.986657] ohci-pci :00:12.1: port[1] reset timeout, stat 0313 2014-03-27T21:49:46.524124+01:00 micropit kernel: [ 204.991077] hub 4-0:1.0: state 7 ports 3 chg evt 0004 2014-03-27T21:49:46.724127+01:00 micropit kernel: [ 205.188863] ohci-pci :00:12.1: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS 2014-03-27T21:49:46.748115+01:00 micropit kernel: [ 205.212901] hub 4-0:1.0: state 7 ports 3 chg evt 0004 Thu Mar 27 21:49:32 CET 2014 bus pci, device :00:12.1 OHCI PCI host controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x28f RWC HCFS=operational IE PLE CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH ed_controlhead ce648000 hcca frame 0xd93f fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x80001c09 FRT FR=0x1c09 periodicstart
USB 3.0 driver code flow for OTG gadget/host decision process
Greg, I apologize if you've already received a copy of this - I inadvertently shutdown evolution in the middle of sending and it doesn't look like the first one was sent, so ... Is there a document/tutorial on the USB 3.0 driver code flow in general, especially regarding the OTG decisions process? I am interested in both: (1) my Samsung (android linux) defaults to a host at 2.0 when a 3.0 OTG gadget is plugged in, posting a pop-up to select 3.0; I'd like to have it default to 3.0 in that case. I'm also interested in your thoughts on what it would take to make the large file data transfer (isochronous?) rate approach the 3.0 spec maximum, even if it means compromising other transfers. I'm somewhat familiar with the 3.0 spec, but not the driver. Any pointers gratefully accepted. David Kochendorfer (kotchkotch - linux.com) (struggling with 3.0 OTG) -- 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
USB 3.0 code flow for OTG gadget/host decision process
Greg, Is there a document/tutorial on the USB 3.0 driver code flow in general, especially regarding the OTG decisions process? I am interested in both: (1) my Samsung (android linux) defaults to a host at 2.0 when a 3.0 OTG gadget is plugged in, posting a pop-up to select 3.0; I'd like to have it default to 3.0 in that case. I'm also interested in your thoughts on what it would take to make the large file data transfer (isochronous?) rate approach the 3.0 spec maximum, even if it means compromising other transfers. I'm somewhat familiar with the 3.0 spec, but not the driver. Any pointers gratefully accepted. David Kochendorfer (kotchkotch - linux.com) (struggling with 3.0 OTG) -- 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] usb: dwc3: gadget: Iterate only over valid endpoints
On Thu, 2014-03-27 at 12:15 -0500, Felipe Balbi wrote: > > I mean, -rc8 is out, if you fix your patches up right now, how much > testing can you do in the next couple days ? Patches need to soak in > linux-next for a while. Even if Greg would accept a pull request, I'm > not sure I'd feel comfortable sending him something which quite likely > wasn't very well tested. Understood. Changes are tested last several weeks :-). Anyway, I will send them soon. Thanks, Ivan > > cheers > -- 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] usb: dwc3: gadget: Iterate only over valid endpoints
On Thu, Mar 27, 2014 at 06:16:15PM +0200, Ivan T. Ivanov wrote: > On Thu, 2014-03-27 at 09:58 -0500, Felipe Balbi wrote: > > On Thu, Mar 27, 2014 at 04:03:08PM +0200, Ivan T. Ivanov wrote: > > > > > > Hi, > > > > > > On Wed, 2014-03-26 at 12:15 -0500, Felipe Balbi wrote: > > > > > > ps: can you guys, please, just send your dwc3 glue layer ? :-) > > > > > > > > > > Ivan Ivanov (cc'ed) had sent a number of patches for our "dwc3-msm" > > > > > layer to the list for review, but I think they were still held up in > > > > > the > > > > > feedback process. Ivan, what is the status of this? > > > > > > > > they had some comments which never got addressed, both dwc3-msm and > > > > phy-msm. > > > > > > Yes, sorry. I think I've corrected them, now I'm testing the result. > > > Will send new version soon. > > > > cool, I'd like to merge that ASAP because we already lost 2 merge > > windows due to late review comments :-s > > I was thinking that I have missed this window? -rc8 is out, it's really late to add anything right now. I don't think Greg would even accept a pull request :-s I mean, -rc8 is out, if you fix your patches up right now, how much testing can you do in the next couple days ? Patches need to soak in linux-next for a while. Even if Greg would accept a pull request, I'm not sure I'd feel comfortable sending him something which quite likely wasn't very well tested. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb: dwc3: gadget: Iterate only over valid endpoints
On Thu, 2014-03-27 at 09:58 -0500, Felipe Balbi wrote: > On Thu, Mar 27, 2014 at 04:03:08PM +0200, Ivan T. Ivanov wrote: > > > > Hi, > > > > On Wed, 2014-03-26 at 12:15 -0500, Felipe Balbi wrote: > > > > > ps: can you guys, please, just send your dwc3 glue layer ? :-) > > > > > > > > Ivan Ivanov (cc'ed) had sent a number of patches for our "dwc3-msm" > > > > layer to the list for review, but I think they were still held up in the > > > > feedback process. Ivan, what is the status of this? > > > > > > they had some comments which never got addressed, both dwc3-msm and > > > phy-msm. > > > > Yes, sorry. I think I've corrected them, now I'm testing the result. > > Will send new version soon. > > cool, I'd like to merge that ASAP because we already lost 2 merge > windows due to late review comments :-s I was thinking that I have missed this window? Ivan > > cheers > -- 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 v2 1/7] usb: gadget: gr_udc: Make struct platform_device variable name clearer and use platform_set/get_drvdata
Rename struct platform_device pointers from ofdev to pdev for clarity.
Suggested by Mark Rutland.
Signed-off-by: Andreas Larsson
---
Differences since v1: use platform_set/get_drvdata
drivers/usb/gadget/gr_udc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/gadget/gr_udc.c b/drivers/usb/gadget/gr_udc.c
index f984ee7..ae5bebe 100644
--- a/drivers/usb/gadget/gr_udc.c
+++ b/drivers/usb/gadget/gr_udc.c
@@ -2065,9 +2065,9 @@ static int gr_udc_init(struct gr_udc *dev)
return 0;
}
-static int gr_remove(struct platform_device *ofdev)
+static int gr_remove(struct platform_device *pdev)
{
- struct gr_udc *dev = dev_get_drvdata(&ofdev->dev);
+ struct gr_udc *dev = platform_get_drvdata(pdev);
if (dev->added)
usb_del_gadget_udc(&dev->gadget); /* Shuts everything down */
@@ -2077,7 +2077,7 @@ static int gr_remove(struct platform_device *ofdev)
gr_dfs_delete(dev);
if (dev->desc_pool)
dma_pool_destroy(dev->desc_pool);
- dev_set_drvdata(&ofdev->dev, NULL);
+ platform_set_drvdata(pdev, NULL);
gr_free_request(&dev->epi[0].ep, &dev->ep0reqi->req);
gr_free_request(&dev->epo[0].ep, &dev->ep0reqo->req);
@@ -2090,7 +2090,7 @@ static int gr_request_irq(struct gr_udc *dev, int irq)
IRQF_SHARED, driver_name, dev);
}
-static int gr_probe(struct platform_device *ofdev)
+static int gr_probe(struct platform_device *pdev)
{
struct gr_udc *dev;
struct resource *res;
@@ -2098,12 +2098,12 @@ static int gr_probe(struct platform_device *ofdev)
int retval;
u32 status;
- dev = devm_kzalloc(&ofdev->dev, sizeof(*dev), GFP_KERNEL);
+ dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
if (!dev)
return -ENOMEM;
- dev->dev = &ofdev->dev;
+ dev->dev = &pdev->dev;
- res = platform_get_resource(ofdev, IORESOURCE_MEM, 0);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_ioremap_resource(dev->dev, res);
if (IS_ERR(regs))
return PTR_ERR(regs);
@@ -2132,7 +2132,7 @@ static int gr_probe(struct platform_device *ofdev)
spin_lock_init(&dev->lock);
dev->regs = regs;
- dev_set_drvdata(&ofdev->dev, dev);
+ platform_set_drvdata(pdev, dev);
/* Determine number of endpoints and data interface mode */
status = gr_read32(&dev->regs->status);
@@ -2204,7 +2204,7 @@ out:
spin_unlock(&dev->lock);
if (retval)
- gr_remove(ofdev);
+ gr_remove(pdev);
return retval;
}
--
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 v2 5/7] usb: gadget: gr_udc: Add ep.maxpacket_limit to debugfs information
Add information on ep.maxpacket_limit for each endpoint in the debugfs information. Signed-off-by: Andreas Larsson --- Differences since v1: none drivers/usb/gadget/gr_udc.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/gr_udc.c b/drivers/usb/gadget/gr_udc.c index 0f3a953..253e608 100644 --- a/drivers/usb/gadget/gr_udc.c +++ b/drivers/usb/gadget/gr_udc.c @@ -143,6 +143,7 @@ static void gr_seq_ep_show(struct seq_file *seq, struct gr_ep *ep) seq_printf(seq, " wedged = %d\n", ep->wedged); seq_printf(seq, " callback = %d\n", ep->callback); seq_printf(seq, " maxpacket = %d\n", ep->ep.maxpacket); + seq_printf(seq, " maxpacket_limit = %d\n", ep->ep.maxpacket_limit); seq_printf(seq, " bytes_per_buffer = %d\n", ep->bytes_per_buffer); if (mode == 1 || mode == 3) seq_printf(seq, " nt = %d\n", -- 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 v2 3/7] usb: gadget: gr_udc: Use platform_get_irq instead of irq_of_parse_and_map
Use platform_get_irq as no mapping needs to be done. No functional difference
for SPARC which is the typical environment for the driver though. Suggested by
Mark Rutland.
Signed-off-by: Andreas Larsson
---
Differences since v1: none
drivers/usb/gadget/gr_udc.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/gr_udc.c b/drivers/usb/gadget/gr_udc.c
index ae5bebe..7a99254 100644
--- a/drivers/usb/gadget/gr_udc.c
+++ b/drivers/usb/gadget/gr_udc.c
@@ -2108,20 +2108,22 @@ static int gr_probe(struct platform_device *pdev)
if (IS_ERR(regs))
return PTR_ERR(regs);
- dev->irq = irq_of_parse_and_map(dev->dev->of_node, 0);
- if (!dev->irq) {
+ dev->irq = platform_get_irq(pdev, 0);
+ if (dev->irq <= 0) {
dev_err(dev->dev, "No irq found\n");
return -ENODEV;
}
/* Some core configurations has separate irqs for IN and OUT events */
- dev->irqi = irq_of_parse_and_map(dev->dev->of_node, 1);
- if (dev->irqi) {
- dev->irqo = irq_of_parse_and_map(dev->dev->of_node, 2);
- if (!dev->irqo) {
+ dev->irqi = platform_get_irq(pdev, 1);
+ if (dev->irqi > 0) {
+ dev->irqo = platform_get_irq(pdev, 2);
+ if (dev->irqo <= 0) {
dev_err(dev->dev, "Found irqi but not irqo\n");
return -ENODEV;
}
+ } else {
+ dev->irqi = 0;
}
dev->gadget.name = driver_name;
--
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 v2 4/7] usb: gadget: gr_udc: Use of_property_read_u32_index to access arrays
Use an appropriate accessor function for property arrays to make the code nicer
and make the code correct if it would ever run on little endian architectures.
Suggested by Mark Rutland.
Signed-off-by: Andreas Larsson
---
Differences since v1: none
drivers/usb/gadget/gr_udc.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/gr_udc.c b/drivers/usb/gadget/gr_udc.c
index 7a99254..0f3a953 100644
--- a/drivers/usb/gadget/gr_udc.c
+++ b/drivers/usb/gadget/gr_udc.c
@@ -2020,9 +2020,7 @@ static int gr_udc_init(struct gr_udc *dev)
u32 dmactrl_val;
int i;
int ret = 0;
- u32 *bufsizes;
u32 bufsize;
- int len;
gr_set_address(dev, 0);
@@ -2033,19 +2031,17 @@ static int gr_udc_init(struct gr_udc *dev)
INIT_LIST_HEAD(&dev->ep_list);
gr_set_ep0state(dev, GR_EP0_DISCONNECT);
- bufsizes = (u32 *)of_get_property(np, "epobufsizes", &len);
- len /= sizeof(u32);
for (i = 0; i < dev->nepo; i++) {
- bufsize = (bufsizes && i < len) ? bufsizes[i] : 1024;
+ if (of_property_read_u32_index(np, "epobufsizes", i, &bufsize))
+ bufsize = 1024;
ret = gr_ep_init(dev, i, 0, bufsize);
if (ret)
return ret;
}
- bufsizes = (u32 *)of_get_property(np, "epibufsizes", &len);
- len /= sizeof(u32);
for (i = 0; i < dev->nepi; i++) {
- bufsize = (bufsizes && i < len) ? bufsizes[i] : 1024;
+ if (of_property_read_u32_index(np, "epibufsizes", i, &bufsize))
+ bufsize = 1024;
ret = gr_ep_init(dev, i, 1, bufsize);
if (ret)
return ret;
--
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 v2 2/7] usb: gadget: gr_udc: Expand devicetree documentation
Provide more information on the two different interrupt cases and more information of endpoint buffer sizes. Suggested by Mark Rutland. Signed-off-by: Andreas Larsson --- Differences since v1: none Documentation/devicetree/bindings/usb/gr-udc.txt | 22 ++ 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/gr-udc.txt b/Documentation/devicetree/bindings/usb/gr-udc.txt index 0c5118f..e944522 100644 --- a/Documentation/devicetree/bindings/usb/gr-udc.txt +++ b/Documentation/devicetree/bindings/usb/gr-udc.txt @@ -12,17 +12,23 @@ Required properties: - reg : Address and length of the register set for the device -- interrupts : Interrupt numbers for this device +- interrupts : Interrupt numbers for this device. Either one interrupt number + for all interrupts, or one for status related interrupts, one for IN + endpoint related interrupts and one for OUT endpoint related interrupts. Optional properties: -- epobufsizes : An array of buffer sizes for OUT endpoints. If the property is - not present, or for endpoints outside of the array, 1024 is assumed by - the driver. - -- epibufsizes : An array of buffer sizes for IN endpoints. If the property is - not present, or for endpoints outside of the array, 1024 is assumed by - the driver. +- epobufsizes : Array of buffer sizes for OUT endpoints when they differ + from the default size of 1024. The array is indexed by the OUT endpoint + number. If the property is present it typically contains one entry for + each OUT endpoint of the core. Fewer entries overrides the default sizes + only for as many endpoints as the array contains. + +- epibufsizes : Array of buffer sizes for IN endpoints when they differ + from the default size of 1024. The array is indexed by the IN endpoint + number. If the property is present it typically contains one entry for + each IN endpoint of the core. Fewer entries overrides the default sizes + only for as many endpoints as the array contains. For further information look in the documentation for the GLIB IP core library: http://www.gaisler.com/products/grlib/grip.pdf -- 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 7/7] usb: gadget: gr_udc: Use GFP_ATOMIC when allocating under help spinlock
As gr_ep_init must be called with dev->lock held, GFP_KERNEL must not be used.
Reported-by: Dan Carpenter
Signed-off-by: Andreas Larsson
---
New patch but needs patch 1/7 to apply
drivers/usb/gadget/gr_udc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/gr_udc.c b/drivers/usb/gadget/gr_udc.c
index 72458be..4966971 100644
--- a/drivers/usb/gadget/gr_udc.c
+++ b/drivers/usb/gadget/gr_udc.c
@@ -1990,8 +1990,8 @@ static int gr_ep_init(struct gr_udc *dev, int num, int
is_in, u32 maxplimit)
INIT_LIST_HEAD(&ep->queue);
if (num == 0) {
- _req = gr_alloc_request(&ep->ep, GFP_KERNEL);
- buf = devm_kzalloc(dev->dev, PAGE_SIZE, GFP_DMA | GFP_KERNEL);
+ _req = gr_alloc_request(&ep->ep, GFP_ATOMIC);
+ buf = devm_kzalloc(dev->dev, PAGE_SIZE, GFP_DMA | GFP_ATOMIC);
if (!_req || !buf) {
/* possible _req freed by gr_probe via gr_remove */
return -ENOMEM;
--
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 v2 6/7] usb: gadget: gr_udc: Return error code when trying to set ep.maxpacket > ep.maxpacket_limit
Make gr_ep_enable fail properly when a call requests a larger ep.maxpacket than
ep.maxpacket_limit.
Signed-off-by: Andreas Larsson
---
Differences since v1: none
drivers/usb/gadget/gr_udc.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/gadget/gr_udc.c b/drivers/usb/gadget/gr_udc.c
index 253e608..72458be 100644
--- a/drivers/usb/gadget/gr_udc.c
+++ b/drivers/usb/gadget/gr_udc.c
@@ -1542,6 +1542,10 @@ static int gr_ep_enable(struct usb_ep *_ep,
} else if (max == 0) {
dev_err(dev->dev, "Max payload cannot be set to 0\n");
return -EINVAL;
+ } else if (max > ep->ep.maxpacket_limit) {
+ dev_err(dev->dev, "Requested max payload %d > limit %d\n",
+ max, ep->ep.maxpacket_limit);
+ return -EINVAL;
}
spin_lock(&ep->dev->lock);
--
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 v2 0/7] usb: gadget: gr_udc: OF and ep.maxpacket_limit improvements and fix of GFP_KERNEL in atomic context
This patchset: - Adds some OF related improvements suggested by Mark Rutland. - Adds ep.maxpacket_limit to the debugfs file and adds a check if gr_ep_enable is called with a maxpacket value greater than ep.maxpacket_limit. - Fixes a bug where GFP_KERNEL was used in atomic context Andreas Larsson (7): usb: gadget: gr_udc: Make struct platform_device variable name clearer and use platform_set/get_drvdata usb: gadget: gr_udc: Expand devicetree documentation usb: gadget: gr_udc: Use platform_get_irq instead of irq_of_parse_and_map usb: gadget: gr_udc: Use of_property_read_u32_index to access arrays usb: gadget: gr_udc: Add ep.maxpacket_limit to debugfs information usb: gadget: gr_udc: Return error code when trying to set ep.maxpacket > ep.maxpacket_limit usb: gadget: gr_udc: Use GFP_ATOMIC when allocating under help spinlock Documentation/devicetree/bindings/usb/gr-udc.txt | 22 + drivers/usb/gadget/gr_udc.c | 53 -- 2 files changed, 42 insertions(+), 33 deletions(-) -- 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
Re: Fwd: Failure to recognize device for 45 minutes and Device Disconnects
On Wed, 26 Mar 2014, Mike Mitchell wrote: > On Mon, Mar 24, 2014 at 7:30 AM, Alan Stern wrote: > > > What happens if you run "lsusb -v" shortly after booting? Does that > cause the mouse to be recognized? Oops -- I meant "microphone", not "mouse". Trying to work on too many bug reports at once... > No Please post the output from the "lsusb -v". > > while the trace is running, do the following: > >echo 0 >/sys/bus/usb/devices/2-1/bConfigurationValue > >and a few seconds later, > >echo 1 >/sys/bus/usb/devices/2-1/bConfigurationValue > > This did not cause the device to be detected. Please post the trace data for these commands. > >Have you tried using this mouse with a different computer? > > No, but we have similar problems disconnecting and filing to recognize > with several of the same brand of devices. The manufacturer (CAD > Audio) says all revisions of this model are the same, using a C-Media > IC. The reason I do not think it is cable relate that I record 6 > hours a day and never have a glitch. The devices only seem to fall > offline when they are not being used. That suggests a setting in the device's firmware. It may deliberately disconnect itself after a period of inactivity. Of course, that doesn't answer the question of why it doesn't connect initially. > Here's a trap of the delayed recognition. It actually took about 5 > hours this time. This trace doesn't show a delayed recognition. At the start of the trace, the audio device is already in active use. Alan Stern PS: In the future, when you put data files like this into the body of an email message, try to make certain that your email client does not split up long lines. It makes reading the files harder. -- 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] usb: dwc3: gadget: Iterate only over valid endpoints
On Thu, Mar 27, 2014 at 04:03:08PM +0200, Ivan T. Ivanov wrote: > > Hi, > > On Wed, 2014-03-26 at 12:15 -0500, Felipe Balbi wrote: > > > > ps: can you guys, please, just send your dwc3 glue layer ? :-) > > > > > > Ivan Ivanov (cc'ed) had sent a number of patches for our "dwc3-msm" > > > layer to the list for review, but I think they were still held up in the > > > feedback process. Ivan, what is the status of this? > > > > they had some comments which never got addressed, both dwc3-msm and > > phy-msm. > > Yes, sorry. I think I've corrected them, now I'm testing the result. > Will send new version soon. cool, I'd like to merge that ASAP because we already lost 2 merge windows due to late review comments :-s cheers -- balbi signature.asc Description: Digital signature
Re: problem with resume after s2ram
On Wed, 26 Mar 2014, Peter Münster wrote: > On Wed, Mar 26 2014, Alan Stern wrote: > > > Please try running the test again. When it finishes, go to the > > /sys/kernel/debug/usb/ohci/:00:12.1/ directory and post a copy of > > the "registers" file. > > > > Check the contents of that file several times; in the line that says > > "hcca frame", the value should change over time. Does it? > > Yes, it does. > > Please find attached the kernel messages and the output of this command: > >while sleep 1; do date; cat registers; echo; done >/tmp/registers.log Oops -- I just realized that the instructions I sent you before were incomplete. Please try running the same test again, but this time issue the following commands to suspend the device: echo on >/sys/bus/usb/devices/4-2/power/control echo 0 >/sys/bus/usb/devices/4-2/bConfigurationValue echo auto >/sys/bus/pci/devices/:00:12.1/power/control echo auto >/sys/bus/usb/devices/4-2/power/control Then a few seconds later, the following command to resume the device: echo on >/sys/bus/usb/devices/4-2/power/control Without the write to the PCI device, the USB controller did not go into suspend and so it wasn't a valid test. As for the changing hcca frame value, that was just a wild guess on my part. Still, if you find it's _not_ changing after this new test, that would explain the problem you experienced. 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: usb/serial/io_ti.c broken on BE systems
Hi Johan, I just tested your patch on a x86 system and everything works fine. If I find some time I'll try to find why the module crashes on arm with debug=1. Best regards, -- Ludovic Drolez. http://www.aopensource.com - The Android Open Source Portal http://www.drolez.com - Personal site - Linux and Free Software -- 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: usb: gadget: Add UDC driver for Aeroflex Gaisler GRUSBDC
Hi!
Other responsibilities has been holding back the Linux commitments.
Thank you for reminding me! I'll get to it!
Best regards,
Andreas Larsson
Software Engineer
Aeroflex Gaisler AB
Aeroflex Microelectronic Solutions – HiRel
Kungsgatan 12
SE-411 19 Gothenburg, Sweden
Phone: +46 31 7758669
andr...@gaisler.com
www.Aeroflex.com/Gaisler
On 2014-03-27 14:52, Dan Carpenter wrote:
This bug is still there in linux-next. What's the story, Andreas?
regards,
dan carpenter
On Thu, Jan 23, 2014 at 07:19:57PM +0300, Dan Carpenter wrote:
Hello Andreas Larsson,
The patch 27e9dcc924e9: "usb: gadget: Add UDC driver for Aeroflex
Gaisler GRUSBDC" from Dec 23, 2013, leads to the following static
checker warning:
drivers/usb/gadget/gr_udc.c:1994 gr_ep_init()
error: scheduling with locks held: 'spin_lock:lock'
drivers/usb/gadget/gr_udc.c
1991 INIT_LIST_HEAD(&ep->queue);
1992
1993 if (num == 0) {
1994 _req = gr_alloc_request(&ep->ep, GFP_KERNEL);
^^
GFP_ATOMIC?
1995 buf = devm_kzalloc(dev->dev, PAGE_SIZE, GFP_DMA |
GFP_KERNEL);
This allocation can sleep as well. We're not allowed to sleep if we're
holding a spinlock.
1996 if (!_req || !buf) {
1997 /* possible _req freed by gr_probe via
gr_remove */
1998 return -ENOMEM;
1999 }
2000
2001 req = container_of(_req, struct gr_request, req);
2002 req->req.buf = buf;
2003 req->req.length = MAX_CTRL_PL_SIZE;
The call tree is:
gr_probe() <- takes the spinlock
-> gr_udc_init()
-> gr_ep_init() <-- sleeps
regards,
dan carpenter
--
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] usb: dwc3: gadget: Iterate only over valid endpoints
Hi, On Wed, 2014-03-26 at 12:15 -0500, Felipe Balbi wrote: > > > ps: can you guys, please, just send your dwc3 glue layer ? :-) > > > > Ivan Ivanov (cc'ed) had sent a number of patches for our "dwc3-msm" > > layer to the list for review, but I think they were still held up in the > > feedback process. Ivan, what is the status of this? > > they had some comments which never got addressed, both dwc3-msm and > phy-msm. Yes, sorry. I think I've corrected them, now I'm testing the result. Will send new version soon. Regards, Ivan -- 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: usb: gadget: Add UDC driver for Aeroflex Gaisler GRUSBDC
This bug is still there in linux-next. What's the story, Andreas?
regards,
dan carpenter
On Thu, Jan 23, 2014 at 07:19:57PM +0300, Dan Carpenter wrote:
> Hello Andreas Larsson,
>
> The patch 27e9dcc924e9: "usb: gadget: Add UDC driver for Aeroflex
> Gaisler GRUSBDC" from Dec 23, 2013, leads to the following static
> checker warning:
>
> drivers/usb/gadget/gr_udc.c:1994 gr_ep_init()
> error: scheduling with locks held: 'spin_lock:lock'
>
> drivers/usb/gadget/gr_udc.c
> 1991 INIT_LIST_HEAD(&ep->queue);
> 1992
> 1993 if (num == 0) {
> 1994 _req = gr_alloc_request(&ep->ep, GFP_KERNEL);
> ^^
> GFP_ATOMIC?
>
> 1995 buf = devm_kzalloc(dev->dev, PAGE_SIZE, GFP_DMA |
> GFP_KERNEL);
>
>
> This allocation can sleep as well. We're not allowed to sleep if we're
> holding a spinlock.
>
> 1996 if (!_req || !buf) {
> 1997 /* possible _req freed by gr_probe via
> gr_remove */
> 1998 return -ENOMEM;
> 1999 }
> 2000
> 2001 req = container_of(_req, struct gr_request, req);
> 2002 req->req.buf = buf;
> 2003 req->req.length = MAX_CTRL_PL_SIZE;
>
> The call tree is:
> gr_probe() <- takes the spinlock
> -> gr_udc_init()
> -> gr_ep_init() <-- sleeps
>
> regards,
> dan carpenter
--
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
XHCI ERROR: Transfer error on endpoint
Hi, I am trying to send data to a USB device connected to a USB3.0 port over a USB bulk end point using libusb APIs . It is failing failed with error ERROR_IO. The same device and the test program works fine on a USB2.0 port. After enabling the XHCI debug options, I found that I am getting the following errors: "Endpoint xxx not halted, refusing to reset Transfer error on endpoint" I have tested in following kernel : 3.13.7 3.11.0-18 Both gave the same results. The test has been performed on USB 3.0 host controller. Can you please let me know the root cause and possible solutions? Attached is the debug log. Regards, Keerthy This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. -- 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 RESEND] gadgetfs: Initialize CHIP to NULL before UDC probe
Otherwise the value from the last probe would be retained that possibly is freed since (the UDC is removed) and therefore no longer relevant. Reproducible with the dummy UDC: modprobe dummy_hcd mount -t gadgetfs gadgetfs /dev/gadget umount /dev/gadget rmmod dummy_hcd mount -t gadgetfs gadgetfs /dev/gadget BUG: unable to handle kernel paging request at a066fd9d Call Trace: [] ? d_alloc_name+0x22/0x50 [] ? selinux_d_instantiate+0x1c/0x20 [] gadgetfs_create_file+0x27/0xa0 [gadgetfs] [] ? setup_req.isra.4+0x80/0x80 [gadgetfs] [] gadgetfs_fill_super+0x13c/0x180 [gadgetfs] [] mount_single+0x92/0xc0 [] gadgetfs_mount+0x18/0x20 [gadgetfs] [] mount_fs+0x39/0x1b0 [] ? __alloc_percpu+0x10/0x20 [] vfs_kern_mount+0x63/0xf0 [] do_mount+0x23e/0xac0 [] ? strndup_user+0x4b/0xf0 [] SyS_mount+0x83/0xc0 [] system_call_fastpath+0x16/0x1b Signed-off-by: Lubomir Rintel --- drivers/usb/gadget/inode.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/inode.c b/drivers/usb/gadget/inode.c index b94c049..ee15628 100644 --- a/drivers/usb/gadget/inode.c +++ b/drivers/usb/gadget/inode.c @@ -2046,6 +2046,7 @@ gadgetfs_fill_super (struct super_block *sb, void *opts, int silent) return -ESRCH; /* fake probe to determine $CHIP */ + CHIP = NULL; usb_gadget_probe_driver(&probe_driver); if (!CHIP) return -ENODEV; -- 1.8.5.3 -- 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
