s3c-hsotg patches

PATCH In review Ben Dooks 6 participants 18 messages Jul 7, 2010 – Jul 15, 2010 4 messages not in the archive

Subsystems (4)

Arm (32-bit) USB Arm sub-architectures Arm Samsung Exynos

lore

Share & tools

lore

Ben Dooks

author

2010-07-07 11:57 UTC #0 lore raw

Re-send of previous set, with corrected patches.

A message that is not in the archive (sent off-list or not yet received): 1278460943-16224-1-git-send-email-ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org

Ben Dooks

2010-07-07 00:02 UTC #2 lore raw

PATCH 4/11 USB: s3c-hsotg: Re-initialise all FIFOs on USB bus reset

The USB documentation suggest that the FIFOs should be reset when a bus reset event happens. Use the s3c_hsotg_init_fifo() to ensure that the FIFO layout is correct and that the FIFOs are flushed before acknowledging the reset.

Signed-off-by Ben Dooks <[email protected]>

---
 drivers/usb/gadget/s3c-hsotg.c |   13 ++++---------
 1 files changed, 4 insertions(+), 9 deletions(-)

drivers/usb/gadget/s3c-hsotg.c +3 -5

index 354fd45..9d32c9f 100644
@@ -2082,17 +2082,12 @@ irq_retry:
 		kill_all_requests(hsotg, &hsotg->eps[0], -ECONNRESET, true);
 
 		/* it seems after a reset we can end up with a situation
-		 * where the TXFIFO still has data in it... try flushing
-		 * it to remove anything that may still be in it.
+		 * where the TXFIFO still has data in it... the docs
+		 * suggest resetting all the fifos, so use the init_fifo
+		 * code to relayout and flush the fifos.
 		 */
 
-		if (1) {
-			writel(S3C_GRSTCTL_TxFNum(0) | S3C_GRSTCTL_TxFFlsh,
-			       hsotg->regs + S3C_GRSTCTL);

Ben Dooks

2010-07-07 00:02 UTC #3 lore raw

PATCH 6/11 USB: s3c-hsotg: Only load packet per fifo write

In reply to a message not in the archive

Limit the IN FIFO write to a single packet per attempt at writing, as per the specifications and ensure that we don't return fifo-full so that we can continue writing packets if we have the space.

Signed-off-by Ben Dooks <[email protected]>

---
 drivers/usb/gadget/s3c-hsotg.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

drivers/usb/gadget/s3c-hsotg.c +11 -0

index 4196e37..df6a39d 100644
@@ -538,6 +538,17 @@ static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg,
 	if (can_write > 512)
 		can_write = 512;
 
+	/* limit the write to one max-packet size worth of data, but allow
+	 * the transfer to return that it did not run out of fifo space
+	 * doing it. */
+	if (to_write > hs_ep->ep.maxpacket) {
+		to_write = hs_ep->ep.maxpacket;
+
+		s3c_hsotg_en_gsint(hsotg,
+				   periodic ? S3C_GINTSTS_PTxFEmp :
+				   S3C_GINTSTS_NPTxFEmp);
+	}
+
 	/* see if we can write data */
 
 	if (to_write > can_write) {

Signature · 6 lines

1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Sergei Shtylyov

2010-07-09 10:49 UTC #4 lore raw

Re: [PATCH 06/11] USB: s3c-hsotg: Only load packet per fifo write

Hello.

Quoted 5 lines · Ben Dooks

Limit the IN FIFO write to a single packet per attempt at writing, as per the specifications and ensure that we don't return fifo-full so that we can continue writing packets if we have the space.
Signed-off-by Ben Dooks <[email protected]>

[...]

drivers/usb/gadget/s3c-hsotg.c static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg, · line 543

Quoted 11 lines

drivers/usb/gadget/s3c-hsotg.c +3 -0

index 4196e37..df6a39d 100644
@@ -538,6 +538,17 @@ static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg,
 	if (can_write > 512)
 		can_write = 512;
 
+	/* limit the write to one max-packet size worth of data, but allow
+	 * the transfer to return that it did not run out of fifo space
+	 * doing it. */

According to CodingStyle, the preferred style for the multi-line commnets
is this:

/*
* bla
* bla
*/

WBR, Sergei

Ben Dooks

2010-07-07 00:02 UTC #5 lore raw

PATCH 8/11 USB: s3c-hsotg: Fix max EP0 IN request length

In reply to a message not in the archive

The maximum length for any EP0 IN request on EP0 is 127 bytes, not 128 as the driver currently has it.

Signed-off-by Ben Dooks <[email protected]>

---
 drivers/usb/gadget/s3c-hsotg.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

drivers/usb/gadget/s3c-hsotg.c +1 -2

index 10aeee1..1020006 100644
@@ -612,8 +612,7 @@ static unsigned get_ep_limit(struct s3c_hsotg_ep *hs_ep)
 		maxpkt = S3C_DxEPTSIZ_PktCnt_LIMIT + 1;
 	} else {
 		if (hs_ep->dir_in) {
-			/* maxsize = S3C_DIEPTSIZ0_XferSize_LIMIT + 1; */
-			maxsize = 64+64+1;
+			maxsize = 64+64;
 			maxpkt = S3C_DIEPTSIZ0_PktCnt_LIMIT + 1;
 		} else {
 			maxsize = 0x3f;

Signature · 6 lines

1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ben Dooks

author

2010-07-07 11:57 UTC #6 lore raw

PATCH 1/11 USB: s3c-hsotg: Increase TX fifo limit

In reply to Ben Dooks

Up the FIFO size for the TX to 1024 entries, as this now seems to work with all the cores. This fixes a problem when using large packets on a core with MPS set to 512 can hang due to insufficient space for the writes.

The hang arises due to getting the non-periodic FIFO empty IRQ but not being able to satisfy any requests since there is never enough space to write 512 bytes into the buffer. This means we end up with a stream of interrupt requests.

It is easier to up the TX FIFO to fill the space we left for it than to try and fix the positions in the code where we should have limited the max-packet size to < TXFIFOSIZE, since the TXFIFOSIZE depends on how the TX FIFOs have been setup.

Signed-off-by Ben Dooks <[email protected]>

---
 drivers/usb/gadget/s3c-hsotg.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

drivers/usb/gadget/s3c-hsotg.c +2 -2

index 26193ec..81f62da 100644
@@ -310,11 +310,11 @@ static void s3c_hsotg_init_fifo(struct s3c_hsotg *hsotg)
 		hsotg->regs + S3C_GNPTXFSIZ);
 	*/
 
-	/* set FIFO sizes to 2048/0x1C0 */
+	/* set FIFO sizes to 2048/1024 */
 
 	writel(2048, hsotg->regs + S3C_GRXFSIZ);
 	writel(S3C_GNPTXFSIZ_NPTxFStAddr(2048) |
-	       S3C_GNPTXFSIZ_NPTxFDep(0x1C0),
+	       S3C_GNPTXFSIZ_NPTxFDep(1024),
 	       hsotg->regs + S3C_GNPTXFSIZ);
 
 	/* arange all the rest of the TX FIFOs, as some versions of this

Signature · 1 line

1.7.0.4

Ben Dooks

author

2010-07-07 11:57 UTC #7 lore raw

PATCH 2/11 USB: s3c-hsotg: The NPTX/PTX FIFO sizes are in words, not bytes

In reply to Ben Dooks

Fix a problem where we have been underestimating the space available in the IN PTX/NPTX FIFOs by assuming that they where simply word aligned instead of in number-of-words. This means all length calculations need to be multiplied-by-4.

Note, we do not change the information about fifo size or start addresses available to userspace as we assume the user can multiply by four easily and is already knows these values are in words.

Signed-off-by Ben Dooks <[email protected]>

---
 drivers/usb/gadget/s3c-hsotg.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

drivers/usb/gadget/s3c-hsotg.c +2 -1

index 81f62da..4a25145 100644
@@ -505,6 +505,7 @@ static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg,
 		}
 
 		can_write = S3C_GNPTXSTS_NPTxFSpcAvail_GET(gnptxsts);
+		can_write *= 4;	/* fifo size is in 32bit quantities. */
 	}
 
 	dev_dbg(hsotg->dev, "%s: GNPTXSTS=%08x, can=%d, to=%d, mps %d\n",

@@ -2732,7 +2733,7 @@ static void __devinit s3c_hsotg_initep(struct s3c_hsotg *hsotg,
 	 */
 
 	ptxfifo = readl(hsotg->regs + S3C_DPTXFSIZn(epnum));
-	hs_ep->fifo_size = S3C_DPTXFSIZn_DPTxFSize_GET(ptxfifo);
+	hs_ep->fifo_size = S3C_DPTXFSIZn_DPTxFSize_GET(ptxfifo) * 4;
 
 	/* if we're using dma, we need to set the next-endpoint pointer
 	 * to be something valid.

Signature · 1 line

1.7.0.4

Ben Dooks

author

2010-07-07 11:57 UTC #8 lore raw

PATCH 3/11 USB: s3c-hsotg: Avoid overwriting contents of perodic in 'fifo'

In reply to Ben Dooks

In shared fifo mode (used on older SoCs) the periodic in fifo beahves much more like a packet buffer, discarding old data when writing new data. Avoid this by ensuring that we do not load new transactions in when there is data sitting already in the FIFO.

Note, this may not be an observed bug, we are fixing the case that this may happen.

Signed-off-by Ben Dooks <[email protected]>

---
 drivers/usb/gadget/s3c-hsotg.c |   12 +++++++++++-
 1 files changed, 11 insertions(+), 1 deletions(-)

drivers/usb/gadget/s3c-hsotg.c +11 -1

index 4a25145..354fd45 100644
@@ -91,7 +91,9 @@ struct s3c_hsotg_req;
  * For periodic IN endpoints, we have fifo_size and fifo_load to try
  * and keep track of the amount of data in the periodic FIFO for each
  * of these as we don't have a status register that tells us how much
- * is in each of them.
+ * is in each of them. (note, this may actually be useless information
+ * as in shared-fifo mode periodic in acts like a single-frame packet
+ * buffer than a fifo)
  */
 struct s3c_hsotg_ep {
 	struct usb_ep		ep;

@@ -474,6 +476,14 @@ static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg,
 
 		size_left = S3C_DxEPTSIZ_XferSize_GET(epsize);
 
+		/* if shared fifo, we cannot write anything until the
+		 * previous data has been completely sent.
+		 */
+		if (hs_ep->fifo_load != 0) {
+			s3c_hsotg_en_gsint(hsotg, S3C_GINTSTS_PTxFEmp);
+			return -ENOSPC;
+		}
+
 		dev_dbg(hsotg->dev, "%s: left=%d, load=%d, fifo=%d, size %d\n",
 			__func__, size_left,
 			hs_ep->size_loaded, hs_ep->fifo_load, hs_ep->fifo_size);

Signature · 1 line

1.7.0.4

Ben Dooks

author

2010-07-07 11:57 UTC #9 lore raw

PATCH 5/11 USB: s3c-hsotg: Add initial detection and setup for dedicated FIFO mode

In reply to Ben Dooks

Add support for the dedicated FIFO mode on newer SoCs such as the S5PV210 partly to improve support and to fix the bug where any non-EP0 IN endpoint requires its own FIFO allocation.

To fix this, we ensure that any non-zero IN endpoint is given a TXFIFO using the same allocation method as the periodic case (all our current hardware has enough FIFOs and FIFO memory for a 1:1 mapping) and ensure that the necessary transmission done interrupt is enabled.

The default settings from reset for the core point all EPs at FIFO0, used for the control endpoint. However, the controller documentation states that all IN endpoints _must_ have a unique FIFO to avoid any contention during transmission.

Note, this leaves us with a large IN FIFO for EP0 (which re-uses the old NPTXFIFO) for an endpoint which cannot shift more than a pair of packets at a time... this is a waste, but it looks like we cannot re-allocate space to the individual IN FIFOs as they are already maxed out (to be confirmed).

Signed-off-by Ben Dooks <[email protected]>

---
 .../arm/plat-samsung/include/plat/regs-usb-hsotg.h |    2 +
 drivers/usb/gadget/s3c-hsotg.c                     |   40 +++++++++++++++++++-
 2 files changed, 40 insertions(+), 2 deletions(-)

arch/arm/plat-samsung/include/plat/regs-usb-hsotg.h +2 -0

index 8d18d9d..dc90f5e 100644
@@ -226,6 +226,7 @@
 
 #define S3C_DIEPMSK				S3C_HSOTG_REG(0x810)
 
+#define S3C_DIEPMSK_TxFIFOEmpty			(1 << 7)
 #define S3C_DIEPMSK_INEPNakEffMsk		(1 << 6)
 #define S3C_DIEPMSK_INTknEPMisMsk		(1 << 5)
 #define S3C_DIEPMSK_INTknTXFEmpMsk		(1 << 4)

@@ -371,6 +372,7 @@
 
 #define S3C_DIEPDMA(_a)				S3C_HSOTG_REG(0x914 + ((_a) * 0x20))
 #define S3C_DOEPDMA(_a)				S3C_HSOTG_REG(0xB14 + ((_a) * 0x20))
+#define S3C_DTXFSTS(_a)				S3C_HSOTG_REG(0x918 + ((_a) * 0x20))
 
 #define S3C_EPFIFO(_a)				S3C_HSOTG_REG(0x1000 + ((_a) * 0x1000))

drivers/usb/gadget/s3c-hsotg.c +38 -2

index 9d32c9f..4196e37 100644
@@ -12,6 +12,8 @@
  * published by the Free Software Foundation.
 */
 
+#define DEBUG
+
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/spinlock.h>

@@ -130,6 +132,7 @@ struct s3c_hsotg_ep {
  * @regs: The memory area mapped for accessing registers.
  * @regs_res: The resource that was allocated when claiming register space.
  * @irq: The IRQ number we are using
+ * @dedicated_fifos: Set if the hardware has dedicated IN-EP fifos.
  * @debug_root: root directrory for debugfs.
  * @debug_file: main status file for debugfs.
  * @debug_fifo: FIFO status file for debugfs.

@@ -148,6 +151,8 @@ struct s3c_hsotg {
 	struct resource		*regs_res;
 	int			irq;
 
+	unsigned int		dedicated_fifos:1;
+
 	struct dentry		*debug_root;
 	struct dentry		*debug_file;
 	struct dentry		*debug_fifo;

@@ -466,7 +471,7 @@ static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg,
 	if (to_write == 0)
 		return 0;
 
-	if (periodic) {
+	if (periodic && !hsotg->dedicated_fifos) {
 		u32 epsize = readl(hsotg->regs + S3C_DIEPTSIZ(hs_ep->index));
 		int size_left;
 		int size_done;

@@ -504,6 +509,11 @@ static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg,
 			s3c_hsotg_en_gsint(hsotg, S3C_GINTSTS_PTxFEmp);
 			return -ENOSPC;
 		}
+	} else if (hsotg->dedicated_fifos && hs_ep->index != 0) {
+		can_write = readl(hsotg->regs + S3C_DTXFSTS(hs_ep->index));
+
+		can_write &= 0xffff;
+		can_write *= 4;
 	} else {
 		if (S3C_GNPTXSTS_NPTxQSpcAvail_GET(gnptxsts) == 0) {
 			dev_dbg(hsotg->dev,

@@ -1829,6 +1839,15 @@ static void s3c_hsotg_epint(struct s3c_hsotg *hsotg, unsigned int idx,
 				 __func__, idx);
 			clear |= S3C_DIEPMSK_INTknEPMisMsk;
 		}
+
+		/* FIFO has space or is empty (see GAHBCFG) */
+		if (hsotg->dedicated_fifos &&
+		    ints & S3C_DIEPMSK_TxFIFOEmpty) {
+			dev_dbg(hsotg->dev, "%s: ep%d: TxFIFOEmpty\n",
+				__func__, idx);
+			s3c_hsotg_trytx(hsotg, hs_ep);
+			clear |= S3C_DIEPMSK_TxFIFOEmpty;
+		}
 	}
 
 	writel(clear, hsotg->regs + epint_reg);

@@ -2280,6 +2299,12 @@ static int s3c_hsotg_ep_enable(struct usb_ep *ep,
 		break;
 	}
 
+	/* if the hardware has dedicated fifos, we must give each IN EP
+	 * a unique tx-fifo even if it is non-periodic.
+	 */
+	if (dir_in && hsotg->dedicated_fifos)
+		epctrl |= S3C_DxEPCTL_TxFNum(index);
+
 	/* for non control endpoints, set PID to D0 */
 	if (index)
 		epctrl |= S3C_DxEPCTL_SetD0PID;

@@ -2569,7 +2594,8 @@ int usb_gadget_register_driver(struct usb_gadget_driver *driver)
 
 	writel(S3C_DIEPMSK_TimeOUTMsk | S3C_DIEPMSK_AHBErrMsk |
 	       S3C_DIEPMSK_INTknEPMisMsk |
-	       S3C_DIEPMSK_EPDisbldMsk | S3C_DIEPMSK_XferComplMsk,
+	       S3C_DIEPMSK_EPDisbldMsk | S3C_DIEPMSK_XferComplMsk |
+	       ((hsotg->dedicated_fifos) ? S3C_DIEPMSK_TxFIFOEmpty : 0),
 	       hsotg->regs + S3C_DIEPMSK);
 
 	/* don't need XferCompl, we get that from RXFIFO in slave mode. In

@@ -2778,6 +2804,8 @@ static void s3c_hsotg_otgreset(struct s3c_hsotg *hsotg)
 
 static void s3c_hsotg_init(struct s3c_hsotg *hsotg)
 {
+	u32 cfg4;
+
 	/* unmask subset of endpoint interrupts */
 
 	writel(S3C_DIEPMSK_TimeOUTMsk | S3C_DIEPMSK_AHBErrMsk |

@@ -2813,6 +2841,14 @@ static void s3c_hsotg_init(struct s3c_hsotg *hsotg)
 
 	writel(using_dma(hsotg) ? S3C_GAHBCFG_DMAEn : 0x0,
 	       hsotg->regs + S3C_GAHBCFG);
+
+	/* check hardware configuration */
+
+	cfg4 = readl(hsotg->regs + 0x50);
+	hsotg->dedicated_fifos = (cfg4 >> 25) & 1;
+
+	dev_info(hsotg->dev, "%s fifos\n",
+		 hsotg->dedicated_fifos ? "dedicated" : "shared");
 }
 
 static void s3c_hsotg_dump(struct s3c_hsotg *hsotg)

Signature · 1 line

1.7.0.4

Ben Dooks

author

2010-07-07 11:57 UTC #10 lore raw

PATCH 7/11 USB: s3c-hsotg: Check for new request before enqueing new setup

In reply to Ben Dooks

Before trying a new setup transaction after getting an EP0 in complete interrupt, check that the driver did not try and send more EP0 IN data before enqueing a new setup transaction.

This fixes a bug where we cannot send all of the IN data in one go so split the transfer, but then fail to send all the data as we start waiting for a new OUT transaction

Signed-off-by Ben Dooks <[email protected]>

---
 drivers/usb/gadget/s3c-hsotg.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

drivers/usb/gadget/s3c-hsotg.c +1 -1

index df6a39d..10aeee1 100644
@@ -1790,7 +1790,7 @@ static void s3c_hsotg_epint(struct s3c_hsotg *hsotg, unsigned int idx,
 		if (dir_in) {
 			s3c_hsotg_complete_in(hsotg, hs_ep);
 
-			if (idx == 0)
+			if (idx == 0 && !hs_ep->req)
 				s3c_hsotg_enqueue_setup(hsotg);
 		} else if (using_dma(hsotg)) {
 			/* We're using DMA, we need to fire an OutDone here

Signature · 1 line

1.7.0.4

Ben Dooks

author

2010-07-07 11:57 UTC #11 lore raw

PATCH 9/11 USB: s3c-hsotg: Fix the OUT EP0 limit

In reply to Ben Dooks

The EP0 out limit is the same as the IN limit, so make them the same.

Signed-off-by Ben Dooks <[email protected]>

---
 drivers/usb/gadget/s3c-hsotg.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

drivers/usb/gadget/s3c-hsotg.c +1 -2

index 1020006..552ec89 100644
@@ -611,11 +611,10 @@ static unsigned get_ep_limit(struct s3c_hsotg_ep *hs_ep)
 		maxsize = S3C_DxEPTSIZ_XferSize_LIMIT + 1;
 		maxpkt = S3C_DxEPTSIZ_PktCnt_LIMIT + 1;
 	} else {
+		maxsize = 64+64;
 		if (hs_ep->dir_in) {
-			maxsize = 64+64;
 			maxpkt = S3C_DIEPTSIZ0_PktCnt_LIMIT + 1;
 		} else {
-			maxsize = 0x3f;
 			maxpkt = 2;
 		}
 	}

Signature · 1 line

1.7.0.4

Ben Dooks

author

2010-07-07 11:57 UTC #12 lore raw

PATCH 10/11 USB: s3c-hsotg: Fix OUT packet request retry

In reply to Ben Dooks

If there is more data in the request than we could fit into a single hardware request, then check when the OutDone event is received if we have more data, and if so, schedule the new data instead of trying to complete the request (and in the case of EP0, sending a 0 packet in the middle of a transfer).

Also, move the debug message about the current transfer state before the warning about a bad transfer.

Signed-off-by Ben Dooks <[email protected]>

---
 drivers/usb/gadget/s3c-hsotg.c |   18 +++++++++++-------
 1 files changed, 11 insertions(+), 7 deletions(-)

drivers/usb/gadget/s3c-hsotg.c +11 -7

index 552ec89..825b6ca 100644
@@ -1383,6 +1383,9 @@ static void s3c_hsotg_rx_data(struct s3c_hsotg *hsotg, int ep_idx, int size)
 	read_ptr = hs_req->req.actual;
 	max_req = hs_req->req.length - read_ptr;
 
+	dev_dbg(hsotg->dev, "%s: read %d/%d, done %d/%d\n",
+		__func__, to_read, max_req, read_ptr, hs_req->req.length);
+
 	if (to_read > max_req) {
 		/* more data appeared than we where willing
 		 * to deal with in this request.

@@ -1392,9 +1395,6 @@ static void s3c_hsotg_rx_data(struct s3c_hsotg *hsotg, int ep_idx, int size)
 		WARN_ON_ONCE(1);
 	}
 
-	dev_dbg(hsotg->dev, "%s: read %d/%d, done %d/%d\n",
-		__func__, to_read, max_req, read_ptr, hs_req->req.length);
-
 	hs_ep->total_data += to_read;
 	hs_req->req.actual += to_read;
 	to_read = DIV_ROUND_UP(to_read, 4);

@@ -1463,9 +1463,11 @@ static void s3c_hsotg_send_zlp(struct s3c_hsotg *hsotg,
 static void s3c_hsotg_handle_outdone(struct s3c_hsotg *hsotg,
 				     int epnum, bool was_setup)
 {
+	u32 epsize = readl(hsotg->regs + S3C_DOEPTSIZ(epnum));
 	struct s3c_hsotg_ep *hs_ep = &hsotg->eps[epnum];
 	struct s3c_hsotg_req *hs_req = hs_ep->req;
 	struct usb_request *req = &hs_req->req;
+	unsigned size_left = S3C_DxEPTSIZ_XferSize_GET(epsize);
 	int result = 0;
 
 	if (!hs_req) {

@@ -1474,9 +1476,7 @@ static void s3c_hsotg_handle_outdone(struct s3c_hsotg *hsotg,
 	}
 
 	if (using_dma(hsotg)) {
-		u32 epsize = readl(hsotg->regs + S3C_DOEPTSIZ(epnum));
 		unsigned size_done;
-		unsigned size_left;
 
 		/* Calculate the size of the transfer by checking how much
 		 * is left in the endpoint size register and then working it

@@ -1486,14 +1486,18 @@ static void s3c_hsotg_handle_outdone(struct s3c_hsotg *hsotg,
 		 * so may overshoot/undershoot the transfer.
 		 */
 
-		size_left = S3C_DxEPTSIZ_XferSize_GET(epsize);
-
 		size_done = hs_ep->size_loaded - size_left;
 		size_done += hs_ep->last_load;
 
 		req->actual = size_done;
 	}
 
+	/* if there is more request to do, schedule new transfer */
+	if (req->actual < req->length && size_left == 0) {
+		s3c_hsotg_start_req(hsotg, hs_ep, hs_req, true);
+		return;
+	}
+
 	if (req->actual < req->length && req->short_not_ok) {
 		dev_dbg(hsotg->dev, "%s: got %d/%d (short not ok) => error\n",
 			__func__, req->actual, req->length);

Signature · 1 line

1.7.0.4

Ben Dooks

author

2010-07-07 11:57 UTC #13 lore raw

PATCH 11/11 USB: s3c-hsotg: Add support for external USB clock

In reply to Ben Dooks

From: Maurus Cuelenaere <[email protected]>

The PLL that drives the USB clock supports 3 input clocks: 12, 24 and 48Mhz. This patch adds support to the USB driver for setting the correct register bit according to the given clock.

This depends on the following patch:
[PATCH] ARM: S3C64XX: Add USB external clock definition

Signed-off-by Maurus Cuelenaere <[email protected]>

Signed-off-by Ben Dooks <[email protected]>

---
 drivers/usb/gadget/s3c-hsotg.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

drivers/usb/gadget/s3c-hsotg.c +19 -0

index 825b6ca..a4e0b0f 100644
@@ -25,6 +25,7 @@
 #include <linux/delay.h>
 #include <linux/io.h>
 #include <linux/slab.h>
+#include <linux/clk.h>
 
 #include <linux/usb/ch9.h>
 #include <linux/usb/gadget.h>

@@ -2798,6 +2799,7 @@ static void __devinit s3c_hsotg_initep(struct s3c_hsotg *hsotg,
  */
 static void s3c_hsotg_otgreset(struct s3c_hsotg *hsotg)
 {
+	struct clk *xusbxti;
 	u32 osc;
 
 	writel(0, S3C_PHYPWR);

@@ -2805,6 +2807,23 @@ static void s3c_hsotg_otgreset(struct s3c_hsotg *hsotg)
 
 	osc = hsotg->plat->is_osc ? S3C_PHYCLK_EXT_OSC : 0;
 
+	xusbxti = clk_get(hsotg->dev, "xusbxti");
+	if (xusbxti && !IS_ERR(xusbxti)) {
+		switch (clk_get_rate(xusbxti)) {
+		case 12*MHZ:
+			osc |= S3C_PHYCLK_CLKSEL_12M;
+			break;
+		case 24*MHZ:
+			osc |= S3C_PHYCLK_CLKSEL_24M;
+			break;
+		default:
+		case 48*MHZ:
+			/* default reference clock */
+			break;
+		}
+		clk_put(xusbxti);
+	}
+
 	writel(osc | 0x10, S3C_PHYCLK);
 
 	/* issue a full set of resets to the otg and core */

Signature · 1 line

1.7.0.4

Greg KH

2010-07-07 15:18 UTC #14 lore raw

In reply to Ben Dooks

Quoted 1 line · Ben Dooks

Re-send of previous set, with corrected patches.

Hm, what tree are these going through? Do you need me to take them through the linux-usb tree? Or are they going through a platform-specific one somewhere?

confused,

greg k-h

Marek Szyprowski

2010-07-14 09:41 UTC #15 lore raw

Hello,

Quoted 8 lines · Greg KH

Quoted 1 line · Ben Dooks
Re-send of previous set, with corrected patches.
Hm, what tree are these going through? Do you need me to take them through the linux-usb tree? Or are they going through a platform-specific one somewhere?
confused,

Looks that Ben is busy and has no time to answer...

I'm interested in merging these patches too. These patches were intended to be merged to 2.6.35-rc5. They are available on
git://git.fluff.org/bjdooks/linux for-2635-rc5/hsotg branch.

IMHO these patches should go though the linux-usb tree - they don't touch any platform specific code, and register definitions (arch/arm/plat-samsung/include/plat/regs-usb-hsotg.h) in fact belongs to the driver rather than the platform. s3c-hsotg driver belongs to the linux-usb tree.

Here is original message for that patch series - see
http://kerneltrap.org/mailarchive/linux-usb/2010/6/11/6261985

-->8---
Some further fixes for the s3c-hsotg block, as well as a repost of the missed USB phy clock setting patch which either got missed or passed over from last time.

As a note, this series has a patch adding support for dedicated FIFO mode, this is in my view a fix, as when the hsotg block is compiled with dedicated fifos then each USB IN non-periodic pipe needs to be alloacted a unique TX FIFO. We have no actual data on how well the block performs when all IN TX NP FIFOs are all set to the same one, but it really should be fixed.

I am not sure if I have been subscribed to linux-usb, please CC: me just in case.

--
Ben
--->8---

Best regards
--
Marek Szyprowski
Samsung Poland R&D Center

A message that is not in the archive (sent off-list or not yet received): 00c401cb2338$84a3f730$8debe590$%[email protected]

Greg KH

2010-07-14 15:10 UTC #17 lore raw

Quoted 7 lines · Marek Szyprowski

Hello,
Quoted 3 lines · Greg KH
Quoted 1 line · Ben Dooks
Re-send of previous set, with corrected patches.

Quoted 7 lines

Quoted 5 lines
Hm, what tree are these going through? Do you need me to take them through the linux-usb tree? Or are they going through a platform-specific one somewhere?
confused,
Looks that Ben is busy and has no time to answer...

Then we all should be too busy to apply them :)

Seriously, if a simple question like this is ignored, what happens if a real problem is reported?

Quoted 9 lines

I'm interested in merging these patches too. These patches were intended to be merged to 2.6.35-rc5. They are available on
git://git.fluff.org/bjdooks/linux for-2635-rc5/hsotg branch.
IMHO these patches should go though the linux-usb tree - they don't touch any platform specific code, and register definitions (arch/arm/plat-samsung/include/plat/regs-usb-hsotg.h) in fact belongs to the driver rather than the platform. s3c-hsotg driver belongs to the linux-usb tree.

Ok, I can take them all, care to resend them through email?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

Ben Dooks

2010-07-15 09:02 UTC #19 lore raw

Quoted 12 lines · Greg KH

Quoted 11 lines · Marek Szyprowski
Hello,
Quoted 7 lines · Greg KH
Quoted 1 line · Ben Dooks
Re-send of previous set, with corrected patches.
Hm, what tree are these going through? Do you need me to take them through the linux-usb tree? Or are they going through a platform-specific one somewhere?

Quoted 5 lines

Quoted 3 lines
Quoted 1 line
confused,
Looks that Ben is busy and has no time to answer...
Then we all should be too busy to apply them :)

I've been really ill for the last couple of weeks, so still sifting through a pile of stuff that needs to be sorted.

They where sent to you as I much prefer the driver specific stuff to go to the relevant maintainer and if possible have them merged via the maintainer tree.

Quoted 7 lines

Seriously, if a simple question like this is ignored, what happens if a real problem is reported?
Quoted 4 lines
I'm interested in merging these patches too. These patches were intended to be merged to 2.6.35-rc5. They are available on
git://git.fluff.org/bjdooks/linux for-2635-rc5/hsotg branch.

Quoted 7 lines

Quoted 5 lines
IMHO these patches should go though the linux-usb tree - they don't touch any platform specific code, and register definitions (arch/arm/plat-samsung/include/plat/regs-usb-hsotg.h) in fact belongs to the driver rather than the platform. s3c-hsotg driver belongs to the linux-usb tree.
Ok, I can take them all, care to resend them through email?

Do you still want them re-sending. I'd have to check that the branch on git://git.fluff.org/bjdooks/linux for-2635-rc5/hsotg is up to date before having it pulled.

Signature · 9 lines

Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 20100715090222.GD16584-SMNkleLxa3Z6Wcw2j4pizdi2O/[email protected]

Greg KH

2010-07-15 10:05 UTC #21 lore raw

Quoted 13 lines · Ben Dooks

Quoted 12 lines · Greg KH
Quoted 11 lines · Marek Szyprowski
Hello,
Quoted 7 lines · Greg KH
Quoted 1 line · Ben Dooks
Re-send of previous set, with corrected patches.
Hm, what tree are these going through? Do you need me to take them through the linux-usb tree? Or are they going through a platform-specific one somewhere?

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
Quoted 1 line
confused,
Looks that Ben is busy and has no time to answer...
Then we all should be too busy to apply them :)
I've been really ill for the last couple of weeks, so still sifting through a pile of stuff that needs to be sorted.

Completly understandable, the comment "no time to answer" I took to be a choice on your part, not external circumstances, my appologies. Hope you are better now.

Quoted 3 lines

They where sent to you as I much prefer the driver specific stuff to go to the relevant maintainer and if possible have them merged via the maintainer tree.

Great.

Quoted 13 lines

Quoted 13 lines
Seriously, if a simple question like this is ignored, what happens if a real problem is reported?
Quoted 9 lines
I'm interested in merging these patches too. These patches were intended to be merged to 2.6.35-rc5. They are available on
git://git.fluff.org/bjdooks/linux for-2635-rc5/hsotg branch.
IMHO these patches should go though the linux-usb tree - they don't touch any platform specific code, and register definitions (arch/arm/plat-samsung/include/plat/regs-usb-hsotg.h) in fact belongs to the driver rather than the platform. s3c-hsotg driver belongs to the linux-usb tree.

Quoted 5 lines

Quoted 1 line
Ok, I can take them all, care to resend them through email?
Do you still want them re-sending. I'd have to check that the branch on git://git.fluff.org/bjdooks/linux for-2635-rc5/hsotg is up to date before having it pulled.

I can't "pull" trees, sorry, I need email patches.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html