[PATCH v2 0/2] Chipidea driver support for the AR933x platform

[PATCH v2 0/2] Chipidea driver support for the AR933x platform

[Svetoslav Neykov]

Add support for the usb controller in AR933x platform.
The processor is big-endian so all multi-byte values of the usb 
descriptors must be converted explicitly. Another difference is that
the controller supports both host and device modes but not OTG.
The patches are tested on WR703n router running OpenWRT trunk in device mode.

This version of the patch relies on the changes in "[PATCH 0/3] 
otg-for-v3.10-v2: separate phy code and add DT helper" and is generated from 
the tree at http://git.pengutronix.de/?p=mgr/linux.git;a=shortlog;h=refs/heads/chipidea-for-v3.10

The patch "[PATCH 3/5] usb: chipidea: Don't access OTG related registers" from
the last patchset is not attached because there have been significant
changes in the chipidea-for-v3.10 repository which make it obsolete. A patch
based on the latest changes will be provided in a separate patchset.

Changes since last version:
        * conditionally include ci13xxx_ar933x.c for compilation
        * removed __devinit/__devexit/__devexit_p()
        * use a dynamically allocated structure for ci13xxx_platform_data
        * move controller mode check to platform usb registration
        * pick a different name for the ar933x chipidea driver
        * use a correct MODE_ALIAS name
        * use the dr_mode changes in "[PATCH 0/3] otg-for-v3.10-v2:
          separate phy code and add DT helper"


Svetoslav Neykov (2):
  usb: chipidea: big-endian support
  usb: chipidea: AR933x platform support for the chipidea driver

 arch/mips/ath79/dev-usb.c                          |   50 +++++++++++++
 arch/mips/include/asm/mach-ath79/ar71xx_regs.h     |    3 +
 .../asm/mach-ath79/ar933x_chipidea_platform.h      |   18 +++++
 drivers/usb/chipidea/Makefile                      |    5 ++
 drivers/usb/chipidea/ci13xxx_ar933x.c              |   75 ++++++++++++++++++++
 drivers/usb/chipidea/core.c                        |    2 +-
 drivers/usb/chipidea/udc.c                         |   59 +++++++--------
 7 files changed, 183 insertions(+), 29 deletions(-)
 create mode 100644 arch/mips/include/asm/mach-ath79/ar933x_chipidea_platform.h
 create mode 100644 drivers/usb/chipidea/ci13xxx_ar933x.c

-- 
1.7.9.5

[PATCH v2 1/2] usb: chipidea: big-endian support

[Svetoslav Neykov]

Convert between big-endian and little-endian format when accessing the usb controller structures which are little-endian by specification.
Fix cases where the little-endian memory layout is taken for granted.
The patch doesn't have any effect on the already supported little-endian architectures.

(no changes since last version)

Signed-off-by: Svetoslav Neykov <svetoslav@neykov.name>
---
 drivers/usb/chipidea/core.c |    2 +-
 drivers/usb/chipidea/udc.c  |   59 +++++++++++++++++++++++--------------------
 2 files changed, 32 insertions(+), 29 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 45fa227..0e012ca 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -184,7 +184,7 @@ static int hw_device_init(struct ci13xxx *ci, void __iomem *base)
 
 	ci->hw_bank.cap = ci->hw_bank.abs;
 	ci->hw_bank.cap += ci->platdata->capoffset;
-	ci->hw_bank.op = ci->hw_bank.cap + ioread8(ci->hw_bank.cap);
+	ci->hw_bank.op = ci->hw_bank.cap + (ioread32(ci->hw_bank.cap) & 0xFF);
 
 	hw_alloc_regmap(ci, false);
 	reg = hw_read(ci, CAP_HCCPARAMS, HCCPARAMS_LEN) >>
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index e355914..4f5152b 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -413,10 +413,10 @@ static int _hardware_enqueue(struct ci13xxx_ep *mEp, struct ci13xxx_req *mReq)
 			return -ENOMEM;
 
 		memset(mReq->zptr, 0, sizeof(*mReq->zptr));
-		mReq->zptr->next    = TD_TERMINATE;
-		mReq->zptr->token   = TD_STATUS_ACTIVE;
+		mReq->zptr->next    = cpu_to_le32(TD_TERMINATE);
+		mReq->zptr->token   = cpu_to_le32(TD_STATUS_ACTIVE);
 		if (!mReq->req.no_interrupt)
-			mReq->zptr->token   |= TD_IOC;
+			mReq->zptr->token   |= cpu_to_le32(TD_IOC);
 	}
 	ret = usb_gadget_map_request(&ci->gadget, &mReq->req, mEp->dir);
 	if (ret)
@@ -427,32 +427,35 @@ static int _hardware_enqueue(struct ci13xxx_ep *mEp, struct ci13xxx_req *mReq)
 	 * TODO - handle requests which spawns into several TDs
 	 */
 	memset(mReq->ptr, 0, sizeof(*mReq->ptr));
-	mReq->ptr->token    = length << ffs_nr(TD_TOTAL_BYTES);
-	mReq->ptr->token   &= TD_TOTAL_BYTES;
-	mReq->ptr->token   |= TD_STATUS_ACTIVE;
+	mReq->ptr->token    = cpu_to_le32(length << ffs_nr(TD_TOTAL_BYTES));
+	mReq->ptr->token   &= cpu_to_le32(TD_TOTAL_BYTES);
+	mReq->ptr->token   |= cpu_to_le32(TD_STATUS_ACTIVE);
 	if (mReq->zptr) {
-		mReq->ptr->next    = mReq->zdma;
+		mReq->ptr->next    = cpu_to_le32(mReq->zdma);
 	} else {
-		mReq->ptr->next    = TD_TERMINATE;
+		mReq->ptr->next    = cpu_to_le32(TD_TERMINATE);
 		if (!mReq->req.no_interrupt)
-			mReq->ptr->token  |= TD_IOC;
+			mReq->ptr->token  |= cpu_to_le32(TD_IOC);
+	}
+	mReq->ptr->page[0]  = cpu_to_le32(mReq->req.dma);
+	for (i = 1; i < 5; i++) {
+		u32 page = mReq->req.dma + i * CI13XXX_PAGE_SIZE;
+		page &= ~TD_RESERVED_MASK;
+		mReq->ptr->page[i] = cpu_to_le32(page);
 	}
-	mReq->ptr->page[0]  = mReq->req.dma;
-	for (i = 1; i < 5; i++)
-		mReq->ptr->page[i] =
-			(mReq->req.dma + i * CI13XXX_PAGE_SIZE) & ~TD_RESERVED_MASK;
 
 	if (!list_empty(&mEp->qh.queue)) {
 		struct ci13xxx_req *mReqPrev;
 		int n = hw_ep_bit(mEp->num, mEp->dir);
 		int tmp_stat;
+		u32 next = mReq->dma & TD_ADDR_MASK;
 
 		mReqPrev = list_entry(mEp->qh.queue.prev,
 				struct ci13xxx_req, queue);
 		if (mReqPrev->zptr)
-			mReqPrev->zptr->next = mReq->dma & TD_ADDR_MASK;
+			mReqPrev->zptr->next = cpu_to_le32(next);
 		else
-			mReqPrev->ptr->next = mReq->dma & TD_ADDR_MASK;
+			mReqPrev->ptr->next = cpu_to_le32(next);
 		wmb();
 		if (hw_read(ci, OP_ENDPTPRIME, BIT(n)))
 			goto done;
@@ -466,9 +469,9 @@ static int _hardware_enqueue(struct ci13xxx_ep *mEp, struct ci13xxx_req *mReq)
 	}
 
 	/*  QH configuration */
-	mEp->qh.ptr->td.next   = mReq->dma;    /* TERMINATE = 0 */
-	mEp->qh.ptr->td.token &= ~TD_STATUS;   /* clear status */
-	mEp->qh.ptr->cap |=  QH_ZLT;
+	mEp->qh.ptr->td.next   = cpu_to_le32(mReq->dma);    /* TERMINATE = 0 */
+	mEp->qh.ptr->td.token &= cpu_to_le32(~TD_STATUS);   /* clear status */
+	mEp->qh.ptr->cap |=  cpu_to_le32(QH_ZLT);
 
 	wmb();   /* synchronize before ep prime */
 
@@ -490,11 +493,11 @@ static int _hardware_dequeue(struct ci13xxx_ep *mEp, struct ci13xxx_req *mReq)
 	if (mReq->req.status != -EALREADY)
 		return -EINVAL;
 
-	if ((TD_STATUS_ACTIVE & mReq->ptr->token) != 0)
+	if ((cpu_to_le32(TD_STATUS_ACTIVE) & mReq->ptr->token) != 0)
 		return -EBUSY;
 
 	if (mReq->zptr) {
-		if ((TD_STATUS_ACTIVE & mReq->zptr->token) != 0)
+		if ((cpu_to_le32(TD_STATUS_ACTIVE) & mReq->zptr->token) != 0)
 			return -EBUSY;
 		dma_pool_free(mEp->td_pool, mReq->zptr, mReq->zdma);
 		mReq->zptr = NULL;
@@ -504,7 +507,7 @@ static int _hardware_dequeue(struct ci13xxx_ep *mEp, struct ci13xxx_req *mReq)
 
 	usb_gadget_unmap_request(&mEp->ci->gadget, &mReq->req, mEp->dir);
 
-	mReq->req.status = mReq->ptr->token & TD_STATUS;
+	mReq->req.status = le32_to_cpu(mReq->ptr->token) & TD_STATUS;
 	if ((TD_STATUS_HALTED & mReq->req.status) != 0)
 		mReq->req.status = -1;
 	else if ((TD_STATUS_DT_ERR & mReq->req.status) != 0)
@@ -512,7 +515,7 @@ static int _hardware_dequeue(struct ci13xxx_ep *mEp, struct ci13xxx_req *mReq)
 	else if ((TD_STATUS_TR_ERR & mReq->req.status) != 0)
 		mReq->req.status = -1;
 
-	mReq->req.actual   = mReq->ptr->token & TD_TOTAL_BYTES;
+	mReq->req.actual   = le32_to_cpu(mReq->ptr->token) & TD_TOTAL_BYTES;
 	mReq->req.actual >>= ffs_nr(TD_TOTAL_BYTES);
 	mReq->req.actual   = mReq->req.length - mReq->req.actual;
 	mReq->req.actual   = mReq->req.status ? 0 : mReq->req.actual;
@@ -784,7 +787,7 @@ __acquires(mEp->lock)
 		if (retval < 0)
 			break;
 		list_del_init(&mReq->queue);
-		dbg_done(_usb_addr(mEp), mReq->ptr->token, retval);
+		dbg_done(_usb_addr(mEp), le32_to_cpu(mReq->ptr->token), retval);
 		if (mReq->req.complete != NULL) {
 			spin_unlock(mEp->lock);
 			if ((mEp->type == USB_ENDPOINT_XFER_CONTROL) &&
@@ -1028,15 +1031,15 @@ static int ep_enable(struct usb_ep *ep,
 	mEp->qh.ptr->cap = 0;
 
 	if (mEp->type == USB_ENDPOINT_XFER_CONTROL)
-		mEp->qh.ptr->cap |=  QH_IOS;
+		mEp->qh.ptr->cap |=  cpu_to_le32(QH_IOS);
 	else if (mEp->type == USB_ENDPOINT_XFER_ISOC)
-		mEp->qh.ptr->cap &= ~QH_MULT;
+		mEp->qh.ptr->cap &= cpu_to_le32(~QH_MULT);
 	else
-		mEp->qh.ptr->cap &= ~QH_ZLT;
+		mEp->qh.ptr->cap &= cpu_to_le32(~QH_ZLT);
 
 	mEp->qh.ptr->cap |=
-		(mEp->ep.maxpacket << ffs_nr(QH_MAX_PKT)) & QH_MAX_PKT;
-	mEp->qh.ptr->td.next |= TD_TERMINATE;   /* needed? */
+		cpu_to_le32((mEp->ep.maxpacket << ffs_nr(QH_MAX_PKT)) & QH_MAX_PKT);
+	mEp->qh.ptr->td.next |= cpu_to_le32(TD_TERMINATE);   /* needed? */
 
 	/*
 	 * Enable endpoints in the HW other than ep0 as ep0
-- 
1.7.9.5

Re: [PATCH v2 1/2] usb: chipidea: big-endian support

[Alexander Shishkin]

Svetoslav Neykov <svetoslav@neykov.name> writes:

> Convert between big-endian and little-endian format when accessing the usb controller structures which are little-endian by specification.
> Fix cases where the little-endian memory layout is taken for granted.
> The patch doesn't have any effect on the already supported
> little-endian architectures.

Applied to my branch of things that are aiming at v3.10. Next time
please make sure that it applies cleanly.

> (no changes since last version)

No need to mention this here, you can use cover letter and/or below the
diffstat, so that it's not part of the commit message.

Thanks,
--
Alex

Re: [PATCH v2 1/2] usb: chipidea: big-endian support

[Alexander Shishkin]

Svetoslav Neykov <svetoslav@neykov.name> writes:

> Convert between big-endian and little-endian format when accessing the usb controller structures which are little-endian by specification.
> Fix cases where the little-endian memory layout is taken for granted.
> The patch doesn't have any effect on the already supported
> little-endian architectures.

Applied to my branch of things that are aiming at v3.10. Next time
please make sure that it applies cleanly.

> (no changes since last version)

No need to mention this here, you can use cover letter and/or below the
diffstat, so that it's not part of the commit message.

Thanks,
--
Alex

Re: [PATCH v2 1/2] usb: chipidea: big-endian support

[Michael Grzeschik]

On Thu, Mar 28, 2013 at 11:28:32AM +0200, Alexander Shishkin wrote:
> Svetoslav Neykov <svetoslav@neykov.name> writes:
> 
> > Convert between big-endian and little-endian format when accessing the usb controller structures which are little-endian by specification.
> > Fix cases where the little-endian memory layout is taken for granted.
> > The patch doesn't have any effect on the already supported
> > little-endian architectures.
> 
> Applied to my branch of things that are aiming at v3.10. Next time
> please make sure that it applies cleanly.

I am currently rebasing my fix/cleanup/feature patches against your
ci-for-greg and realised that this patch missed to fix debug.c with
cpu_le_32 action. Is someone volunteering to cook a patch?

Thanks,
Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v2 1/2] usb: chipidea: big-endian support

[Alexander Shishkin]

Michael Grzeschik <mgr@pengutronix.de> writes:

> On Thu, Mar 28, 2013 at 11:28:32AM +0200, Alexander Shishkin wrote:
>> Svetoslav Neykov <svetoslav@neykov.name> writes:
>> 
>> > Convert between big-endian and little-endian format when accessing the usb controller structures which are little-endian by specification.
>> > Fix cases where the little-endian memory layout is taken for granted.
>> > The patch doesn't have any effect on the already supported
>> > little-endian architectures.
>> 
>> Applied to my branch of things that are aiming at v3.10. Next time
>> please make sure that it applies cleanly.
>
> I am currently rebasing my fix/cleanup/feature patches against your
> ci-for-greg and realised that this patch missed to fix debug.c with
> cpu_le_32 action. Is someone volunteering to cook a patch?

Nice catch. If nobody beats me to it, I'll probably just amend that
patch in my branch in a couple of hours.

Regards,
--
Alex

RE: [PATCH v2 1/2] usb: chipidea: big-endian support

[Svetoslav Neykov]

Hi Michael,

On Thu, March 28, 2013 4:13 PM Michael Grzeschik wrote: 
>On Thu, Mar 28, 2013 at 11:28:32AM +0200, Alexander Shishkin wrote:
>> Svetoslav Neykov <svetoslav@neykov.name> writes:
>> 
>> > Convert between big-endian and little-endian format when accessing the
usb controller structures which are little-endian by specification.
>> > Fix cases where the little-endian memory layout is taken for granted.
>> > The patch doesn't have any effect on the already supported
>> > little-endian architectures.
>> 
>> Applied to my branch of things that are aiming at v3.10. Next time
>> please make sure that it applies cleanly.
>
>I am currently rebasing my fix/cleanup/feature patches against your
>ci-for-greg and realised that this patch missed to fix debug.c with
>cpu_le_32 action. Is someone volunteering to cook a patch?

I will gladly make the changes, but after having a look at it I didn't spot
any candidates. The DMA buffers are printed either as addresses in memory or
as raw data which doesn't make sense to be cpu_le_32'ed. If Alexander hasn't
already made the changes could you point me to the lines in question.

Thanks,
Svetoslav.

RE: [PATCH v2 1/2] usb: chipidea: big-endian support

[Svetoslav Neykov]

Hi Michael,

On Thu, March 28, 2013 4:13 PM Michael Grzeschik wrote: 
>On Thu, Mar 28, 2013 at 11:28:32AM +0200, Alexander Shishkin wrote:
>> Svetoslav Neykov <svetoslav@neykov.name> writes:
>> 
>> > Convert between big-endian and little-endian format when accessing the
usb controller structures which are little-endian by specification.
>> > Fix cases where the little-endian memory layout is taken for granted.
>> > The patch doesn't have any effect on the already supported
>> > little-endian architectures.
>> 
>> Applied to my branch of things that are aiming at v3.10. Next time
>> please make sure that it applies cleanly.
>
>I am currently rebasing my fix/cleanup/feature patches against your
>ci-for-greg and realised that this patch missed to fix debug.c with
>cpu_le_32 action. Is someone volunteering to cook a patch?

I will gladly make the changes, but after having a look at it I didn't spot
any candidates. The DMA buffers are printed either as addresses in memory or
as raw data which doesn't make sense to be cpu_le_32'ed. If Alexander hasn't
already made the changes could you point me to the lines in question.

Thanks,
Svetoslav.

RE: [PATCH v2 1/2] usb: chipidea: big-endian support

[Alexander Shishkin]

Svetoslav Neykov <svetoslav@neykov.name> writes:

> Hi Michael,
>
> On Thu, March 28, 2013 4:13 PM Michael Grzeschik wrote: 
>>On Thu, Mar 28, 2013 at 11:28:32AM +0200, Alexander Shishkin wrote:
>>> Svetoslav Neykov <svetoslav@neykov.name> writes:
>>> 
>>> > Convert between big-endian and little-endian format when accessing the
> usb controller structures which are little-endian by specification.
>>> > Fix cases where the little-endian memory layout is taken for granted.
>>> > The patch doesn't have any effect on the already supported
>>> > little-endian architectures.
>>> 
>>> Applied to my branch of things that are aiming at v3.10. Next time
>>> please make sure that it applies cleanly.
>>
>>I am currently rebasing my fix/cleanup/feature patches against your
>>ci-for-greg and realised that this patch missed to fix debug.c with
>>cpu_le_32 action. Is someone volunteering to cook a patch?
>
> I will gladly make the changes, but after having a look at it I didn't spot
> any candidates. The DMA buffers are printed either as addresses in memory or
> as raw data which doesn't make sense to be cpu_le_32'ed. If Alexander hasn't
> already made the changes could you point me to the lines in question.

You're right, it's either physical addresses or raw data, no need for
conversions there.

Regards,
--
Alex

Re: [PATCH v2 1/2] usb: chipidea: big-endian support

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

On 03/28/2013 10:28 AM, Alexander Shishkin wrote:
> Svetoslav Neykov <svetoslav@neykov.name> writes:
> 
>> Convert between big-endian and little-endian format when accessing
>> the usb controller structures which are little-endian by
>> specification. Fix cases where the little-endian memory layout is
>> taken for granted. The patch doesn't have any effect on the already
>> supported little-endian architectures.

Has anyone tested how the cpu_to_le32 and vice versa effects the
load/store operations? Does the compiler generate full 32 bit accesses
on mips (and big endian arm) or is a byte-shift-or pattern used?

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

RE: [PATCH v2 1/2] usb: chipidea: big-endian support

[Svetoslav Neykov]

Hi Marc,

Marc Kleine-Budde [mailto:mkl@pengutronix.de] (On Thursday, March 28, 2013
4:16 PM)
>On 03/28/2013 10:28 AM, Alexander Shishkin wrote:
>> Svetoslav Neykov <svetoslav@neykov.name> writes:
>> 
>>> Convert between big-endian and little-endian format when accessing
>>> the usb controller structures which are little-endian by
>>> specification. Fix cases where the little-endian memory layout is
>>> taken for granted. The patch doesn't have any effect on the already
>>> supported little-endian architectures.
>
>Has anyone tested how the cpu_to_le32 and vice versa effects the
>load/store operations? Does the compiler generate full 32 bit accesses
>on mips (and big endian arm) or is a byte-shift-or pattern used?

Better late than never... I have checked your question, the value is loaded
in a register and then swapped, so the read is performed only once.

Regards,
Svetoslav.

RE: [PATCH v2 1/2] usb: chipidea: big-endian support

[Svetoslav Neykov]

Hi Marc,

Marc Kleine-Budde [mailto:mkl@pengutronix.de] (On Thursday, March 28, 2013
4:16 PM)
>On 03/28/2013 10:28 AM, Alexander Shishkin wrote:
>> Svetoslav Neykov <svetoslav@neykov.name> writes:
>> 
>>> Convert between big-endian and little-endian format when accessing
>>> the usb controller structures which are little-endian by
>>> specification. Fix cases where the little-endian memory layout is
>>> taken for granted. The patch doesn't have any effect on the already
>>> supported little-endian architectures.
>
>Has anyone tested how the cpu_to_le32 and vice versa effects the
>load/store operations? Does the compiler generate full 32 bit accesses
>on mips (and big endian arm) or is a byte-shift-or pattern used?

Better late than never... I have checked your question, the value is loaded
in a register and then swapped, so the read is performed only once.

Regards,
Svetoslav.

Re: [PATCH v2 1/2] usb: chipidea: big-endian support

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1280 bytes --]

On 05/09/2013 11:22 PM, Svetoslav Neykov wrote:
> Hi Marc,
> 
> Marc Kleine-Budde [mailto:mkl@pengutronix.de] (On Thursday, March 28, 2013
> 4:16 PM)
>> On 03/28/2013 10:28 AM, Alexander Shishkin wrote:
>>> Svetoslav Neykov <svetoslav@neykov.name> writes:
>>>
>>>> Convert between big-endian and little-endian format when accessing
>>>> the usb controller structures which are little-endian by
>>>> specification. Fix cases where the little-endian memory layout is
>>>> taken for granted. The patch doesn't have any effect on the already
>>>> supported little-endian architectures.
>>
>> Has anyone tested how the cpu_to_le32 and vice versa effects the
>> load/store operations? Does the compiler generate full 32 bit accesses
>> on mips (and big endian arm) or is a byte-shift-or pattern used?
> 
> Better late than never... I have checked your question, the value is loaded
> in a register and then swapped, so the read is performed only once.

Thanks for checking this.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

RE: [PATCH v2 1/2] usb: chipidea: big-endian support

[Svetoslav Neykov]

Alexander Shishkin wrote:
> Svetoslav Neykov <svetoslav@neykov.name> writes:
>
>> Convert between big-endian and little-endian format when accessing the
usb controller structures which are little-endian by specification.
>> Fix cases where the little-endian memory layout is taken for granted.
>> The patch doesn't have any effect on the already supported
>> little-endian architectures.
>
>Applied to my branch of things that are aiming at v3.10. Next time
>please make sure that it applies cleanly.

I am a bit confused about the workflow and which repository to base my work
on. Should I use github/virtuoso/linux-ci for my future patches? Or
linux-next?

Regards,
Svetoslav.

RE: [PATCH v2 1/2] usb: chipidea: big-endian support

[Svetoslav Neykov]

Alexander Shishkin wrote:
> Svetoslav Neykov <svetoslav@neykov.name> writes:
>
>> Convert between big-endian and little-endian format when accessing the
usb controller structures which are little-endian by specification.
>> Fix cases where the little-endian memory layout is taken for granted.
>> The patch doesn't have any effect on the already supported
>> little-endian architectures.
>
>Applied to my branch of things that are aiming at v3.10. Next time
>please make sure that it applies cleanly.

I am a bit confused about the workflow and which repository to base my work
on. Should I use github/virtuoso/linux-ci for my future patches? Or
linux-next?

Regards,
Svetoslav.

RE: [PATCH v2 1/2] usb: chipidea: big-endian support

[Alexander Shishkin]

Svetoslav Neykov <svetoslav@neykov.name> writes:

> Alexander Shishkin wrote:
>> Svetoslav Neykov <svetoslav@neykov.name> writes:
>>
>>> Convert between big-endian and little-endian format when accessing the
> usb controller structures which are little-endian by specification.
>>> Fix cases where the little-endian memory layout is taken for granted.
>>> The patch doesn't have any effect on the already supported
>>> little-endian architectures.
>>
>>Applied to my branch of things that are aiming at v3.10. Next time
>>please make sure that it applies cleanly.
>
> I am a bit confused about the workflow and which repository to base my work
> on. Should I use github/virtuoso/linux-ci for my future patches? Or
> linux-next?

It really depends on what your patches change. For chipidea driver
changes, yes it's that branch. For mips-related bits, it's most probably
something else. For gadget, otg or phy patches, it's Felipe's tree. If
you get it wrong, normally it shouldn't be too much work to rebase your
patches onto a different tree, especially for the author of the
patches. In some cases I might do it for you, but you should be aware of
possible penalties [1]. :)

For the coming merge window I'm fixing and rebasing everything for
everybody anyway, so this time it's no big deal.

[1] http://lwn.net/Articles/536546/

Regards,
--
Alex

[PATCH v2 2/2] usb: chipidea: AR933x platform support for the chipidea driver

[Svetoslav Neykov]

Support host and device usb modes for the chipidea controller in AR933x.

Changes since last version of the patch:
	* conditionally include ci13xxx_ar933x.c for compilation
	* removed __devinit/__devexit/__devexit_p()
	* use a dynamically allocated structure for ci13xxx_platform_data
	* move controller mode check to platform usb registration
	* pick a different name for the ar933x chipidea driver
	* use a correct MODE_ALIAS name
	* use the dr_mode changes in "[PATCH 0/3] otg-for-v3.10-v2:
	  separate phy code and add DT helper"

Signed-off-by: Svetoslav Neykov <svetoslav@neykov.name>
---
 arch/mips/ath79/dev-usb.c                          |   50 +++++++++++++
 arch/mips/include/asm/mach-ath79/ar71xx_regs.h     |    3 +
 .../asm/mach-ath79/ar933x_chipidea_platform.h      |   18 +++++
 drivers/usb/chipidea/Makefile                      |    5 ++
 drivers/usb/chipidea/ci13xxx_ar933x.c              |   75 ++++++++++++++++++++
 5 files changed, 151 insertions(+)
 create mode 100644 arch/mips/include/asm/mach-ath79/ar933x_chipidea_platform.h
 create mode 100644 drivers/usb/chipidea/ci13xxx_ar933x.c

diff --git a/arch/mips/ath79/dev-usb.c b/arch/mips/ath79/dev-usb.c
index bd2bc10..0c285d9 100644
--- a/arch/mips/ath79/dev-usb.c
+++ b/arch/mips/ath79/dev-usb.c
@@ -19,9 +19,11 @@
 #include <linux/platform_device.h>
 #include <linux/usb/ehci_pdriver.h>
 #include <linux/usb/ohci_pdriver.h>
+#include <linux/usb/otg.h>
 
 #include <asm/mach-ath79/ath79.h>
 #include <asm/mach-ath79/ar71xx_regs.h>
+#include <asm/mach-ath79/ar933x_chipidea_platform.h>
 #include "common.h"
 #include "dev-usb.h"
 
@@ -68,6 +70,22 @@ static struct platform_device ath79_ehci_device = {
 	},
 };
 
+static struct resource ar933x_chipidea_resources[2];
+
+static struct ar933x_chipidea_platform_data ar933x_chipidea_data = {
+};
+
+static struct platform_device ar933x_chipidea_device = {
+	.name		= "ar933x-chipidea",
+	.id		= -1,
+	.resource	= ar933x_chipidea_resources,
+	.num_resources	= ARRAY_SIZE(ar933x_chipidea_resources),
+	.dev = {
+		.dma_mask		= &ath79_ehci_dmamask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
 static void __init ath79_usb_init_resource(struct resource res[2],
 					   unsigned long base,
 					   unsigned long size,
@@ -174,8 +192,32 @@ static void __init ar913x_usb_setup(void)
 	platform_device_register(&ath79_ehci_device);
 }
 
+static void __init ar933x_usb_setup_ctrl_config(void)
+{
+	void __iomem *usb_ctrl_base, *usb_config_reg;
+	u32 usb_config;
+
+	usb_ctrl_base = ioremap(AR71XX_USB_CTRL_BASE, AR71XX_USB_CTRL_SIZE);
+	usb_config_reg = usb_ctrl_base + AR71XX_USB_CTRL_REG_CONFIG;
+	usb_config = __raw_readl(usb_config_reg);
+	usb_config &= ~AR933X_USB_CONFIG_HOST_ONLY;
+	__raw_writel(usb_config, usb_config_reg);
+	iounmap(usb_ctrl_base);
+}
+
 static void __init ar933x_usb_setup(void)
 {
+	u32 bootstrap;
+	enum usb_dr_mode dr_mode;
+
+	bootstrap = ath79_reset_rr(AR933X_RESET_REG_BOOTSTRAP);
+	if (bootstrap & AR933X_BOOTSTRAP_USB_MODE_HOST) {
+		dr_mode = USB_DR_MODE_HOST;
+	} else {
+		dr_mode = USB_DR_MODE_PERIPHERAL;
+		ar933x_usb_setup_ctrl_config();
+	}
+
 	ath79_device_reset_set(AR933X_RESET_USBSUS_OVERRIDE);
 	mdelay(10);
 
@@ -187,8 +229,16 @@ static void __init ar933x_usb_setup(void)
 
 	ath79_usb_init_resource(ath79_ehci_resources, AR933X_EHCI_BASE,
 				AR933X_EHCI_SIZE, ATH79_CPU_IRQ_USB);
+
 	ath79_ehci_device.dev.platform_data = &ath79_ehci_pdata_v2;
 	platform_device_register(&ath79_ehci_device);
+
+	ath79_usb_init_resource(ar933x_chipidea_resources, AR933X_EHCI_BASE,
+				AR933X_EHCI_SIZE, ATH79_CPU_IRQ_USB);
+
+	ar933x_chipidea_data.dr_mode = dr_mode;
+	ar933x_chipidea_device.dev.platform_data = &ar933x_chipidea_data;
+	platform_device_register(&ar933x_chipidea_device);
 }
 
 static void __init ar934x_usb_setup(void)
diff --git a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
index a5e0f17..13eb2d9 100644
--- a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
+++ b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
@@ -297,6 +297,7 @@
 #define AR934X_RESET_USB_PHY		BIT(4)
 #define AR934X_RESET_USBSUS_OVERRIDE	BIT(3)
 
+#define AR933X_BOOTSTRAP_USB_MODE_HOST	BIT(3)
 #define AR933X_BOOTSTRAP_REF_CLK_40	BIT(0)
 
 #define AR934X_BOOTSTRAP_SW_OPTION8	BIT(23)
@@ -315,6 +316,8 @@
 #define AR934X_BOOTSTRAP_SDRAM_DISABLED	BIT(1)
 #define AR934X_BOOTSTRAP_DDR1		BIT(0)
 
+#define AR933X_USB_CONFIG_HOST_ONLY	BIT(8)
+
 #define AR934X_PCIE_WMAC_INT_WMAC_MISC		BIT(0)
 #define AR934X_PCIE_WMAC_INT_WMAC_TX		BIT(1)
 #define AR934X_PCIE_WMAC_INT_WMAC_RXLP		BIT(2)
diff --git a/arch/mips/include/asm/mach-ath79/ar933x_chipidea_platform.h b/arch/mips/include/asm/mach-ath79/ar933x_chipidea_platform.h
new file mode 100644
index 0000000..2b0ee30
--- /dev/null
+++ b/arch/mips/include/asm/mach-ath79/ar933x_chipidea_platform.h
@@ -0,0 +1,18 @@
+/*
+ *  Platform data definition for Atheros AR933X Chipidea USB controller
+ *
+ *  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 _AR933X_CHIPIDEA_PLATFORM_H
+#define _AR933X_CHIPIDEA_PLATFORM_H
+
+#include <linux/usb/otg.h>
+
+struct ar933x_chipidea_platform_data {
+	enum usb_dr_mode dr_mode;
+};
+
+#endif /* _AR933X_UART_PLATFORM_H */
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 146ecd7..aae70a4 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -19,3 +19,8 @@ endif
 ifneq ($(CONFIG_OF_DEVICE),)
 	obj-$(CONFIG_USB_CHIPIDEA)	+= ci13xxx_imx.o usbmisc_imx.o
 endif
+
+ifneq ($(CONFIG_SOC_AR933X),)
+	obj-$(CONFIG_USB_CHIPIDEA)	+= ci13xxx_ar933x.o
+endif
+
diff --git a/drivers/usb/chipidea/ci13xxx_ar933x.c b/drivers/usb/chipidea/ci13xxx_ar933x.c
new file mode 100644
index 0000000..4ba977a
--- /dev/null
+++ b/drivers/usb/chipidea/ci13xxx_ar933x.c
@@ -0,0 +1,75 @@
+/* Copyright (c) 2010, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/usb/ulpi.h>
+#include <linux/usb/gadget.h>
+#include <linux/usb/chipidea.h>
+#include <asm/mach-ath79/ath79.h>
+#include <asm/mach-ath79/ar71xx_regs.h>
+#include <asm/mach-ath79/ar933x_chipidea_platform.h>
+
+#include "ci.h"
+
+static int ci13xxx_ar933x_probe(struct platform_device *pdev)
+{
+	u32 bootstrap;
+	struct ar933x_chipidea_platform_data *ar933x_chipidea_data;
+	struct ci13xxx_platform_data *pdata;
+	struct platform_device *plat_ci;
+
+	dev_dbg(&pdev->dev, "ci13xxx_ar933x_probe\n");
+
+	ar933x_chipidea_data = pdev->dev.platform_data;
+
+	pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata) {
+		dev_err(&pdev->dev, "Failed to allocate ci13xxx-ar933x pdata!\n");
+		return -ENOMEM;
+	}
+
+	pdata->name = "ci13xxx_ar933x";
+	pdata->capoffset = DEF_CAPOFFSET;
+	pdata->dr_mode = ar933x_chipidea_data->dr_mode;
+	plat_ci = ci13xxx_add_device(&pdev->dev,
+				pdev->resource, pdev->num_resources,
+				pdata);
+	if (IS_ERR(plat_ci)) {
+		dev_err(&pdev->dev, "ci13xxx_add_device failed!\n");
+		return PTR_ERR(plat_ci);
+	}
+
+	platform_set_drvdata(pdev, plat_ci);
+
+	pm_runtime_no_callbacks(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+
+	return 0;
+}
+
+static int ci13xxx_ar933x_remove(struct platform_device *pdev)
+{
+	struct platform_device *plat_ci = platform_get_drvdata(pdev);
+
+	pm_runtime_disable(&pdev->dev);
+	ci13xxx_remove_device(plat_ci);
+
+	return 0;
+}
+
+static struct platform_driver ci13xxx_ar933x_driver = {
+	.probe = ci13xxx_ar933x_probe,
+	.remove = ci13xxx_ar933x_remove,
+	.driver = { .name = "ar933x-chipidea", },
+};
+
+module_platform_driver(ci13xxx_ar933x_driver);
+
+MODULE_ALIAS("platform:ci13xxx_ar933x_driver");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5

Re: [PATCH v2 2/2] usb: chipidea: AR933x platform support for the chipidea driver

[Alexander Shishkin]

Svetoslav Neykov <svetoslav@neykov.name> writes:

> Support host and device usb modes for the chipidea controller in AR933x.
>
> Changes since last version of the patch:
> 	* conditionally include ci13xxx_ar933x.c for compilation
> 	* removed __devinit/__devexit/__devexit_p()
> 	* use a dynamically allocated structure for ci13xxx_platform_data
> 	* move controller mode check to platform usb registration
> 	* pick a different name for the ar933x chipidea driver
> 	* use a correct MODE_ALIAS name
> 	* use the dr_mode changes in "[PATCH 0/3] otg-for-v3.10-v2:
> 	  separate phy code and add DT helper"
>
> Signed-off-by: Svetoslav Neykov <svetoslav@neykov.name>

This can go in either through chipidea or mips tree, but in either case
it has to have an Acked-by from the maintainer of the other tree.

> ---
>  arch/mips/ath79/dev-usb.c                          |   50 +++++++++++++
>  arch/mips/include/asm/mach-ath79/ar71xx_regs.h     |    3 +
>  .../asm/mach-ath79/ar933x_chipidea_platform.h      |   18 +++++
>  drivers/usb/chipidea/Makefile                      |    5 ++
>  drivers/usb/chipidea/ci13xxx_ar933x.c              |   75 ++++++++++++++++++++
>  5 files changed, 151 insertions(+)
>  create mode 100644 arch/mips/include/asm/mach-ath79/ar933x_chipidea_platform.h
>  create mode 100644 drivers/usb/chipidea/ci13xxx_ar933x.c
>
> diff --git a/arch/mips/ath79/dev-usb.c b/arch/mips/ath79/dev-usb.c
> index bd2bc10..0c285d9 100644
> --- a/arch/mips/ath79/dev-usb.c
> +++ b/arch/mips/ath79/dev-usb.c
> @@ -19,9 +19,11 @@
>  #include <linux/platform_device.h>
>  #include <linux/usb/ehci_pdriver.h>
>  #include <linux/usb/ohci_pdriver.h>
> +#include <linux/usb/otg.h>
>  
>  #include <asm/mach-ath79/ath79.h>
>  #include <asm/mach-ath79/ar71xx_regs.h>
> +#include <asm/mach-ath79/ar933x_chipidea_platform.h>
>  #include "common.h"
>  #include "dev-usb.h"
>  
> @@ -68,6 +70,22 @@ static struct platform_device ath79_ehci_device = {
>  	},
>  };
>  
> +static struct resource ar933x_chipidea_resources[2];
> +
> +static struct ar933x_chipidea_platform_data ar933x_chipidea_data = {
> +};

No need to initialize it like this, it should save a few bytes in
.data.

> +
> +static struct platform_device ar933x_chipidea_device = {
> +	.name		= "ar933x-chipidea",
> +	.id		= -1,
> +	.resource	= ar933x_chipidea_resources,
> +	.num_resources	= ARRAY_SIZE(ar933x_chipidea_resources),
> +	.dev = {
> +		.dma_mask		= &ath79_ehci_dmamask,
> +		.coherent_dma_mask	= DMA_BIT_MASK(32),
> +	},
> +};
> +
>  static void __init ath79_usb_init_resource(struct resource res[2],
>  					   unsigned long base,
>  					   unsigned long size,
> @@ -174,8 +192,32 @@ static void __init ar913x_usb_setup(void)
>  	platform_device_register(&ath79_ehci_device);
>  }
>  
> +static void __init ar933x_usb_setup_ctrl_config(void)
> +{
> +	void __iomem *usb_ctrl_base, *usb_config_reg;
> +	u32 usb_config;
> +
> +	usb_ctrl_base = ioremap(AR71XX_USB_CTRL_BASE, AR71XX_USB_CTRL_SIZE);
> +	usb_config_reg = usb_ctrl_base + AR71XX_USB_CTRL_REG_CONFIG;
> +	usb_config = __raw_readl(usb_config_reg);
> +	usb_config &= ~AR933X_USB_CONFIG_HOST_ONLY;
> +	__raw_writel(usb_config, usb_config_reg);
> +	iounmap(usb_ctrl_base);
> +}
> +
>  static void __init ar933x_usb_setup(void)
>  {
> +	u32 bootstrap;
> +	enum usb_dr_mode dr_mode;
> +
> +	bootstrap = ath79_reset_rr(AR933X_RESET_REG_BOOTSTRAP);
> +	if (bootstrap & AR933X_BOOTSTRAP_USB_MODE_HOST) {
> +		dr_mode = USB_DR_MODE_HOST;
> +	} else {
> +		dr_mode = USB_DR_MODE_PERIPHERAL;
> +		ar933x_usb_setup_ctrl_config();
> +	}
> +
>  	ath79_device_reset_set(AR933X_RESET_USBSUS_OVERRIDE);
>  	mdelay(10);
>  
> @@ -187,8 +229,16 @@ static void __init ar933x_usb_setup(void)
>  
>  	ath79_usb_init_resource(ath79_ehci_resources, AR933X_EHCI_BASE,
>  				AR933X_EHCI_SIZE, ATH79_CPU_IRQ_USB);
> +
>  	ath79_ehci_device.dev.platform_data = &ath79_ehci_pdata_v2;
>  	platform_device_register(&ath79_ehci_device);
> +
> +	ath79_usb_init_resource(ar933x_chipidea_resources, AR933X_EHCI_BASE,
> +				AR933X_EHCI_SIZE, ATH79_CPU_IRQ_USB);
> +
> +	ar933x_chipidea_data.dr_mode = dr_mode;
> +	ar933x_chipidea_device.dev.platform_data = &ar933x_chipidea_data;
> +	platform_device_register(&ar933x_chipidea_device);
>  }
>  
>  static void __init ar934x_usb_setup(void)
> diff --git a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
> index a5e0f17..13eb2d9 100644
> --- a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
> +++ b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
> @@ -297,6 +297,7 @@
>  #define AR934X_RESET_USB_PHY		BIT(4)
>  #define AR934X_RESET_USBSUS_OVERRIDE	BIT(3)
>  
> +#define AR933X_BOOTSTRAP_USB_MODE_HOST	BIT(3)
>  #define AR933X_BOOTSTRAP_REF_CLK_40	BIT(0)
>  
>  #define AR934X_BOOTSTRAP_SW_OPTION8	BIT(23)
> @@ -315,6 +316,8 @@
>  #define AR934X_BOOTSTRAP_SDRAM_DISABLED	BIT(1)
>  #define AR934X_BOOTSTRAP_DDR1		BIT(0)
>  
> +#define AR933X_USB_CONFIG_HOST_ONLY	BIT(8)
> +
>  #define AR934X_PCIE_WMAC_INT_WMAC_MISC		BIT(0)
>  #define AR934X_PCIE_WMAC_INT_WMAC_TX		BIT(1)
>  #define AR934X_PCIE_WMAC_INT_WMAC_RXLP		BIT(2)
> diff --git a/arch/mips/include/asm/mach-ath79/ar933x_chipidea_platform.h b/arch/mips/include/asm/mach-ath79/ar933x_chipidea_platform.h
> new file mode 100644
> index 0000000..2b0ee30
> --- /dev/null
> +++ b/arch/mips/include/asm/mach-ath79/ar933x_chipidea_platform.h
> @@ -0,0 +1,18 @@
> +/*
> + *  Platform data definition for Atheros AR933X Chipidea USB controller
> + *
> + *  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 _AR933X_CHIPIDEA_PLATFORM_H
> +#define _AR933X_CHIPIDEA_PLATFORM_H
> +
> +#include <linux/usb/otg.h>
> +
> +struct ar933x_chipidea_platform_data {
> +	enum usb_dr_mode dr_mode;
> +};

Why can't you just use ci13xxx_platform_data?
It looks like you don't need a glue driver is drivers/usb/chipidea at
all, you can register ci_hdrc right from the ath79/dev-usb.c

Regards,
--
Alex

Re: [PATCH v2 2/2] usb: chipidea: AR933x platform support for the chipidea driver

[Alexander Shishkin]

Svetoslav Neykov <svetoslav@neykov.name> writes:

> Support host and device usb modes for the chipidea controller in AR933x.
>
> Changes since last version of the patch:
> 	* conditionally include ci13xxx_ar933x.c for compilation
> 	* removed __devinit/__devexit/__devexit_p()
> 	* use a dynamically allocated structure for ci13xxx_platform_data
> 	* move controller mode check to platform usb registration
> 	* pick a different name for the ar933x chipidea driver
> 	* use a correct MODE_ALIAS name
> 	* use the dr_mode changes in "[PATCH 0/3] otg-for-v3.10-v2:
> 	  separate phy code and add DT helper"
>
> Signed-off-by: Svetoslav Neykov <svetoslav@neykov.name>

This can go in either through chipidea or mips tree, but in either case
it has to have an Acked-by from the maintainer of the other tree.

> ---
>  arch/mips/ath79/dev-usb.c                          |   50 +++++++++++++
>  arch/mips/include/asm/mach-ath79/ar71xx_regs.h     |    3 +
>  .../asm/mach-ath79/ar933x_chipidea_platform.h      |   18 +++++
>  drivers/usb/chipidea/Makefile                      |    5 ++
>  drivers/usb/chipidea/ci13xxx_ar933x.c              |   75 ++++++++++++++++++++
>  5 files changed, 151 insertions(+)
>  create mode 100644 arch/mips/include/asm/mach-ath79/ar933x_chipidea_platform.h
>  create mode 100644 drivers/usb/chipidea/ci13xxx_ar933x.c
>
> diff --git a/arch/mips/ath79/dev-usb.c b/arch/mips/ath79/dev-usb.c
> index bd2bc10..0c285d9 100644
> --- a/arch/mips/ath79/dev-usb.c
> +++ b/arch/mips/ath79/dev-usb.c
> @@ -19,9 +19,11 @@
>  #include <linux/platform_device.h>
>  #include <linux/usb/ehci_pdriver.h>
>  #include <linux/usb/ohci_pdriver.h>
> +#include <linux/usb/otg.h>
>  
>  #include <asm/mach-ath79/ath79.h>
>  #include <asm/mach-ath79/ar71xx_regs.h>
> +#include <asm/mach-ath79/ar933x_chipidea_platform.h>
>  #include "common.h"
>  #include "dev-usb.h"
>  
> @@ -68,6 +70,22 @@ static struct platform_device ath79_ehci_device = {
>  	},
>  };
>  
> +static struct resource ar933x_chipidea_resources[2];
> +
> +static struct ar933x_chipidea_platform_data ar933x_chipidea_data = {
> +};

No need to initialize it like this, it should save a few bytes in
.data.

> +
> +static struct platform_device ar933x_chipidea_device = {
> +	.name		= "ar933x-chipidea",
> +	.id		= -1,
> +	.resource	= ar933x_chipidea_resources,
> +	.num_resources	= ARRAY_SIZE(ar933x_chipidea_resources),
> +	.dev = {
> +		.dma_mask		= &ath79_ehci_dmamask,
> +		.coherent_dma_mask	= DMA_BIT_MASK(32),
> +	},
> +};
> +
>  static void __init ath79_usb_init_resource(struct resource res[2],
>  					   unsigned long base,
>  					   unsigned long size,
> @@ -174,8 +192,32 @@ static void __init ar913x_usb_setup(void)
>  	platform_device_register(&ath79_ehci_device);
>  }
>  
> +static void __init ar933x_usb_setup_ctrl_config(void)
> +{
> +	void __iomem *usb_ctrl_base, *usb_config_reg;
> +	u32 usb_config;
> +
> +	usb_ctrl_base = ioremap(AR71XX_USB_CTRL_BASE, AR71XX_USB_CTRL_SIZE);
> +	usb_config_reg = usb_ctrl_base + AR71XX_USB_CTRL_REG_CONFIG;
> +	usb_config = __raw_readl(usb_config_reg);
> +	usb_config &= ~AR933X_USB_CONFIG_HOST_ONLY;
> +	__raw_writel(usb_config, usb_config_reg);
> +	iounmap(usb_ctrl_base);
> +}
> +
>  static void __init ar933x_usb_setup(void)
>  {
> +	u32 bootstrap;
> +	enum usb_dr_mode dr_mode;
> +
> +	bootstrap = ath79_reset_rr(AR933X_RESET_REG_BOOTSTRAP);
> +	if (bootstrap & AR933X_BOOTSTRAP_USB_MODE_HOST) {
> +		dr_mode = USB_DR_MODE_HOST;
> +	} else {
> +		dr_mode = USB_DR_MODE_PERIPHERAL;
> +		ar933x_usb_setup_ctrl_config();
> +	}
> +
>  	ath79_device_reset_set(AR933X_RESET_USBSUS_OVERRIDE);
>  	mdelay(10);
>  
> @@ -187,8 +229,16 @@ static void __init ar933x_usb_setup(void)
>  
>  	ath79_usb_init_resource(ath79_ehci_resources, AR933X_EHCI_BASE,
>  				AR933X_EHCI_SIZE, ATH79_CPU_IRQ_USB);
> +
>  	ath79_ehci_device.dev.platform_data = &ath79_ehci_pdata_v2;
>  	platform_device_register(&ath79_ehci_device);
> +
> +	ath79_usb_init_resource(ar933x_chipidea_resources, AR933X_EHCI_BASE,
> +				AR933X_EHCI_SIZE, ATH79_CPU_IRQ_USB);
> +
> +	ar933x_chipidea_data.dr_mode = dr_mode;
> +	ar933x_chipidea_device.dev.platform_data = &ar933x_chipidea_data;
> +	platform_device_register(&ar933x_chipidea_device);
>  }
>  
>  static void __init ar934x_usb_setup(void)
> diff --git a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
> index a5e0f17..13eb2d9 100644
> --- a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
> +++ b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
> @@ -297,6 +297,7 @@
>  #define AR934X_RESET_USB_PHY		BIT(4)
>  #define AR934X_RESET_USBSUS_OVERRIDE	BIT(3)
>  
> +#define AR933X_BOOTSTRAP_USB_MODE_HOST	BIT(3)
>  #define AR933X_BOOTSTRAP_REF_CLK_40	BIT(0)
>  
>  #define AR934X_BOOTSTRAP_SW_OPTION8	BIT(23)
> @@ -315,6 +316,8 @@
>  #define AR934X_BOOTSTRAP_SDRAM_DISABLED	BIT(1)
>  #define AR934X_BOOTSTRAP_DDR1		BIT(0)
>  
> +#define AR933X_USB_CONFIG_HOST_ONLY	BIT(8)
> +
>  #define AR934X_PCIE_WMAC_INT_WMAC_MISC		BIT(0)
>  #define AR934X_PCIE_WMAC_INT_WMAC_TX		BIT(1)
>  #define AR934X_PCIE_WMAC_INT_WMAC_RXLP		BIT(2)
> diff --git a/arch/mips/include/asm/mach-ath79/ar933x_chipidea_platform.h b/arch/mips/include/asm/mach-ath79/ar933x_chipidea_platform.h
> new file mode 100644
> index 0000000..2b0ee30
> --- /dev/null
> +++ b/arch/mips/include/asm/mach-ath79/ar933x_chipidea_platform.h
> @@ -0,0 +1,18 @@
> +/*
> + *  Platform data definition for Atheros AR933X Chipidea USB controller
> + *
> + *  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 _AR933X_CHIPIDEA_PLATFORM_H
> +#define _AR933X_CHIPIDEA_PLATFORM_H
> +
> +#include <linux/usb/otg.h>
> +
> +struct ar933x_chipidea_platform_data {
> +	enum usb_dr_mode dr_mode;
> +};

Why can't you just use ci13xxx_platform_data?
It looks like you don't need a glue driver is drivers/usb/chipidea at
all, you can register ci_hdrc right from the ath79/dev-usb.c

Regards,
--
Alex

RE: [PATCH v2 2/2] usb: chipidea: AR933x platform support for the chipidea driver

[Svetoslav Neykov]

Alexander Shishkin wrote:
>No need to initialize it like this, it should save a few bytes in
>.data.
Ok.

>Why can't you just use ci13xxx_platform_data?
>It looks like you don't need a glue driver is drivers/usb/chipidea at
>all, you can register ci_hdrc right from the ath79/dev-usb.c

You are right. I will register ci_hdrc in ath79/dev-usb.c.

Regards.
Svetoslav.

RE: [PATCH v2 2/2] usb: chipidea: AR933x platform support for the chipidea driver

[Svetoslav Neykov]

Alexander Shishkin wrote:
>No need to initialize it like this, it should save a few bytes in
>.data.
Ok.

>Why can't you just use ci13xxx_platform_data?
>It looks like you don't need a glue driver is drivers/usb/chipidea at
>all, you can register ci_hdrc right from the ath79/dev-usb.c

You are right. I will register ci_hdrc in ath79/dev-usb.c.

Regards.
Svetoslav.