All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH RFC 0/2] usb: host: Add a wrapper layer for mutiple host support
Date: Wed, 25 Jun 2014 20:30:14 -0600	[thread overview]
Message-ID: <CAPnjgZ2LoSah9=DRZam+CkS5ASBnMohEWTv+84YeytU94nNxZg@mail.gmail.com> (raw)
In-Reply-To: <201406251033.51050.marex@denx.de>

Hi Marek,

On 25 June 2014 02:33, Marek Vasut <marex@denx.de> wrote:
> On Wednesday, June 25, 2014 at 08:27:39 AM, Simon Glass wrote:
> [...]
>> > > > model. Instead, I'd love to see a mean to instantiate each *HCI
>> > > > controller and have a USB core which would track those instances. The
>> > > > USB core would then be able to call whatever generic ops on those
>> > > > instances as needed. Does that make sense please ?
>> > >
>> > > True, i understand your point here. I think the second approach i was
>> > > talking of, goes in this direction.
>> > > I think i could not put it well in words there.
>> > >
>> > > I will prepare an RFC patch for that, and post it as soon as its
>> > > ready, so that you can have
>> > > a look.
>> >
>> > Ah, this would be so very appreciated! Thank you!
>>
>> Should we consider just going straight for driver model?
>
> I was thinking about that, but I'm worried it might break USB support on some
> platforms. Also, the size of U-Boot will grow on many platforms, right?
>
> What do you think ?

If you add CONFIG_DM_USB as an option, you can then pull in either
usb-uclass.c or the old usb code. Since USB is often tied to a board
then you can move just that board (or group of boards) to dm.

I am keeping a working tree in u-boot-dm.git which does this for
serial, SPI, SPI flash and GPIO. It seems to work fairly well as a
technique for keeping both things in the tree in the interim..

As to the size increase, yes it will increase the size, but not that
much, and after all, aren't we trying to move the code to dm?

Regards,
Simon

  reply	other threads:[~2014-06-26  2:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-24 14:10 [U-Boot] [PATCH RFC 0/2] usb: host: Add a wrapper layer for mutiple host support Vivek Gautam
2014-06-24 14:10 ` [U-Boot] [PATCH 1/2] usb: Rename usb_submit_int_msg() API to usb_int_msg() Vivek Gautam
2014-06-24 14:10 ` [U-Boot] [PATCH 2/2] RFC: usb: host: Introduce host translational layer Vivek Gautam
2014-06-24 14:26 ` [U-Boot] [PATCH RFC 0/2] usb: host: Add a wrapper layer for mutiple host support Marek Vasut
2014-06-25  5:11   ` Vivek Gautam
2014-06-25  6:08     ` Marek Vasut
2014-06-25  6:27       ` Simon Glass
2014-06-25  8:33         ` Marek Vasut
2014-06-26  2:30           ` Simon Glass [this message]
2014-06-26  4:34             ` Vivek Gautam
2014-06-26  4:46               ` Vivek Gautam
2014-06-26  9:21                 ` Marek Vasut
2014-07-07 22:46                   ` Simon Glass

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='CAPnjgZ2LoSah9=DRZam+CkS5ASBnMohEWTv+84YeytU94nNxZg@mail.gmail.com' \
    --to=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /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.