All of lore.kernel.org
 help / color / mirror / Atom feed
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: MUSB multiplatform work?
Date: Thu, 30 May 2013 13:18:54 -0700	[thread overview]
Message-ID: <20130530201854.GB6467@atomide.com> (raw)
In-Reply-To: <20130528163548.GC28253@arwen.pp.htv.fi>

* Felipe Balbi <balbi@ti.com> [130528 09:42]:
> Hi,
> 
> On Mon, May 27, 2013 at 05:02:09PM +0200, Arnd Bergmann wrote:
> > Hi Felipe,
> > 
> > We've gone through remaining work items for getting the ARM kernel
> > to full multiplatform support again, and MUSB came up. I'm sure you
> > have your own thoughts on this, but I'd like to know if there is
> > already a plan in place.
> > 
> > From what I can see, the driver in PIO mode should almost work
> > on multiple platforms, but there are a couple of compile-time
> > dependencies in it that need to be turned into run-time conditionals.
> > In particular the TUSB version seem sufficiently different that
> > it needs some extra work to be a true run-time option.
> 
> yeah, TUSB layer is quite messy, all the others should be doable though.

TUSB we can make depend on ARMv7, the only implementation we have
is for omap2420, which is ARMv6. This should solve the issue for
ARMv7 multiplatform builds for now.
 
> > The DMA support as far as I can tell has never been intended to
> > be usable in a multiplatform setup, but that also seems doable.
> 
> we're looking into dmaengine for that but will take a lot of work to
> have something usable.

TUSB would work with dmaengine, but AFAIK we're still missing the
dmaengine configuration options to support increasing device end
FIFO address.
 
> > Looking just at the #ifdef statements in the driver, I found
> > that the following things need to be addressed:
> > 
> > * abstract musb_write_fifo and musb_read_fifo into callbacks
> > * move fifo_mode setting into glue driver for runtime selection
> 
> for the fifo mode, I'd rather detect the size of the internal fifo and
> configure it dynamically based on that plus number of endpoints
> configured in the IP.
> 
> > * turn TUSB compile-time switches into run-time conditionals
> > * turn musb_ep_select into run-time switch
> > * make is_dma_capable/is_cppi_enabled/tusb_dma_omap run-time conditionals
> 
> those can be remove, actually. Back at Nokia we did a huge cleanup on
> the DMA programming part, it can be very simple with no ifdefs at all,
> just needs someone to put the work and test on all platforms.
> 
> > * abtract dma_controller_create/destroy interface
> > 
> > Aside from this, a recent discussion with Maxime has brought up
> > that the Allwinner A1x platform (mach-sunxi) contains an MUSB variant
> > that is currently used with an independently implemented device driver,
> > see https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-3.0/drivers/usb/sun5i_usb
> > I wonder if you have any insight on how that can be integrated into
> > musb, or whether it is likely to be a compatible version to start with.
> 
> just write a glue layer, should be as easy as that :-)

Yes the MUSB code should be able to support it considering the number
of implementations we already have there.

Regards,

Tony

  reply	other threads:[~2013-05-30 20:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-27 15:02 MUSB multiplatform work? Arnd Bergmann
2013-05-28 16:35 ` Felipe Balbi
2013-05-30 20:18   ` Tony Lindgren [this message]
2013-05-30 20:21     ` Linus Walleij
2013-05-30 20:31       ` Tony Lindgren
2013-05-30 21:19         ` Linus Walleij
2013-06-12 10:05           ` Vinod Koul
2013-06-12 11:57             ` Jassi Brar
2013-06-17 13:43               ` Vinod Koul
2013-06-17 15:57                 ` Jassi Brar
2013-06-01 11:41         ` Jassi Brar
2013-05-30 20:54     ` Tony Lindgren
2013-05-31  4:00       ` Felipe Balbi
2013-05-31 17:52         ` Tony Lindgren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130530201854.GB6467@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.