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.
> > > 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, 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?
> > Yup, which is a really cool feature and keeps us all employed too! :)
> > This is one reason for attaching things to the USB stack, right now it
> > does a limited negotiation but in future like you say there's more and
> > more features coming.
> keep in mind that the same stack used to change a charging current, will also be
> used to tell the other end to mux those lines differently.
Sure.
> > 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?
Attachment:
signature.asc
Description: Digital signature
