Hi,
On Mon, Oct 05, 2015 at 05:18:33PM +0100, Mark Brown wrote:
> On Mon, Oct 05, 2015 at 10:15:11AM -0500, Felipe Balbi wrote:
> > On Sun, Oct 04, 2015 at 11:55:06PM +0100, Mark Brown wrote:
>
> > > The trouble is getting traction on adoption. Vendors have a habit of doing
> > > things like finding problems and rather than reporting them deciding that the
> > > open source solution isn't great and going and writing their own thing
> > > (especially when they're in stealth mode) rather than talking to anyone.
> > > Sometimes we manage to avoid that but it can be challenging, and often we only
> > > even hear about the new thing after it's shipping and there's a lot of inertia
> > > behind changing it. The kernel ABIs tend to be a lot sticker than userspace
> > > things here.
>
> > but this is not a solid enough argument to push anything into the kernel.
>
> To my mind it is a concern when considering design - it's not the only
> consideration certainly but it should influence if or how we split
> things.
sure
> > > > the same thing will happen with Type-C and power delivery. There won't be tuning
> > > > to taste, of course :-) But there will be "very different ideas what what you
> > > > want to do with" your charging methodology.
>
> > > Are those very different things about the use cases ("don't bother with
> > > high speed data, get all the power you can" or whatever) or are they
> > > about the details of the board?
>
> > I'm pretty sure there will be interesting designs in the market. I'm pretty sure
> > there will be type-C systems which won't support USB 3.1 for example, even
> > though they'll support USB Power Delivery in its entirety.
>
> That's sounding like generic USB stuff to me.
>
> > > Yes, definitely - my experience both in terms of watching how people
> > > like handset vendors often work internally and in terms of getting
> > > things adopted is that it's a lot easier if you can have one component
> > > you need to update to handle new hardware rather than multiple ones that
> > > need to be upgraded for things that are purely board differences.
>
> > IMO, just because you have it in the kernel, it doesn't mean it'll be
> > adopted. Look at pm_runtime, for example; it's a very nice API and, yet, not
> > used by Android (or has that changed ?)
>
> That's always been a bit of a myth - most Android systems use runtime PM
> extensively when they're running, the discussion is really about the
> edge case where you're idling the system. The Android suspend behaviour
> is about the system idle case and is as much about providing a simple
> way to go into an idle state, especially bearing in mind that they have
> apps installed from the app store there, as anything else. It's the
> making sure things are idle part of things that's different.
okay
> > > > okay, this is a fair point :-) I just don't see, as of now at least, how we can
> > > > get to that in a way that's somewhat future-proof. It seems like we will
> > > > add more and more notifications until we can't maintain this anymore.
>
> > > So we need to look at the new/upcoming USB specs and understand the
>
> > not upcoming, it's already out there.
>
> I assume there's ongoing work on further revisions to the spec though?
that'd be a correct assumption
> > > Does the problem not get easier if we break it down to just the charger
> > > elements and realise that the USB C modes are going to have a lot more
> > > policy in them?
>
> > the thing with USB C is that it's not only for negotiating a charging power
> > (with power delivery you're not necessarily tied to 5V, btw), that very stack
> > will also be used to change to other alternate modes, and those can be anything:
> > Thunderbolt, PCIe, DisplayPort, etc.
>
> Surely these features have sufficient orthogonality to allow us to split
> things up and deal with some of the problems while providing spaces for
> future work?
yeah, might. As long as we keep that voice in our heads that things are likely
to change.
--
balbi
Attachment:
signature.asc
Description: PGP signature
