Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

[Felipe Balbi]

On Sun, Oct 04, 2015 at 11:55:06PM +0100, Mark Brown wrote:
> On Fri, Oct 02, 2015 at 02:11:25PM -0500, Felipe Balbi wrote:
> > On Fri, Oct 02, 2015 at 07:49:09PM +0100, Mark Brown wrote:
> > > On Fri, Oct 02, 2015 at 12:23:11PM -0500, Felipe Balbi wrote:
> 
> > > > > Things more difficult, if nothing else it means we need to get whatever
> > > > > userspace component deployed in all relevant userspace stacks with
> > > > > appropriate configuration in order to do things.
> 
> > > > but that will be a thing for the kernel too. We will have to deploy this new
> > > > kernel component in all relevant stacks with appropriate configuration in order
> > > > to do things :-) No changes there.
> 
> > > Sure, but it's one project which is developed entirely in the open -
> > > that's a lot more manageable.
> 
> > We can have a fully open source userland daemon too. Much like systemd, bluez,
> > neard, and many, many others. Why wouldn't that be a thing ?
> 
> 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.

> > Similar applies to power delivery charging profile themselves. Not all
> > profiles are mandatory. Some are optional and that will be completely
> > device/board specific. How an OEM implements that in the PCB is also
> > completely board-specific :-) Some might have a dumb IC hardcoding some
> > messages, some might have something largely more flexible.
> 
> Right, and what I was trying to say was that it seems like the kernel ought to
> be worrying about the board specific bits and userspace worrying about what to
> do with those bits.

we're not saying anything different in this front. I, too, want kernel to deal
with certain details and expose notifications. Where we disagree is how granular
should these notifications be and where they should be sent to.

 > > The things we've got with audio are a combination of tuning to taste and
> > > (even more importantly) very different ideas about what you want to do
> > > with an audio subsystem that influence how you set things up in a given
> > > use case.
> 
> > 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.

> > > > Actually, I was thinking about it in a more granular fashion. Kernel
> > > > exposes a charger/power_supply, a few regulators, a UDC view and this
> > > > single userspace daemon figures out how to tie those together.
> 
> > > That sounds worrying - it means that new hardware support needs
> > > supporting in every userspace (it seems inevitable that there will be at
> > > least some reimplementations because that's fun) which gets old really
> > > fast, and every userspace needs to understand every topology.
> 
> > very true, but it's also true for a kernel solution.
> 
> > It seems like you want it in the kernel because of it being convenient :-)
> 
> 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 ?)

> > > > The view here isn't really a USB port, it's just a source of power. But how much
> > > > power we can draw from it depends on, possibly, a ton of different chips and
> > > > different notifications.
> 
> > > Right, yes - it's the power input/output associated with the USB port.
> > > The USB port is just the physical thing users can see so it's a good way
> > > to label it.  That could mean that we ought to move the aggregation bit
> > > into the power supply code of course, but then a lot of the decisions
> > > are going to be specific to USB.
> 
> > in a sense, yes. But they can happen at a layer which knows nothing (or very
> > little) about USB. Here's an example:
> 
> > Not everybody follows USB Battery Charging class. Some chargers don't short
> > D+/D- to signify they are a wall charger. Some will use different resistance
> > values on the ID pin to tell you how much current you can draw from them.
> 
> > From a PMIC (or something else) point of view, all it needs is a tiny current
> > source and a an ADC, then it reports the ADC value to the upper layer. This
> > really doesn't even need to know that it's using an ID pin, or whatever.
> 
> This doesn't seem much different to things like the various GPIO to
> subsystem X drivers we've got - we already have some for IIO type
> things IIRC.

that's really not what I was trying to point out :-)

> > > How different are the end goals of these designs really going to be
> > > though - that's more of the question for me?  Part of what the kernel is
> > > doing is hiding implementation details from userspace.  I'd expect
> > > userspace to be interested in things like the maximum current allowed in
> > > or out in a given mode rather than the details of how that is accomplished.
> 
> > 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.

> problem space, and how much of it we need to worry about right now in
> this scope.
> 
> > With Type-C there's no port type anymore. What we used to refer as Host/Hub
> > Charger, Standard Port, Charging Port, Wall Charger, etc, now becomes a single
> > type (let's call it type-c for short) which can provide profiles. These profiles
> > are negotiated using that new stack I pointed out above, not by checking
> > resistance on data lines or ID pin.
> 
> 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.

> > Add to that the fact that the same power delivery pipe (the CC pins) can be used
> > to tell the other end of remux the pins to e.g. PCIe, and s**t just hit the fan
> > :-)
> 
> > In short, whatever we do, needs to consider coping with incoming requests from
> > userspace at a minimum because userspace will need control over the port
> > alternate modes. I mean, don't get me wrong, these is all uber-cool to me, but
> > it'll be a pain to make a flexible/generic solution :-)
> 
> That seems to make sense to me - anything the kernel is able to do
> autonomously for USB C should probably be pretty dumb.  Older USB
> standards are already pretty dumb themselves (although inconsistently
> standardised).

right.

> > > > The real difficulty here is coming up with an interface which we're agreeing to
> > > > supporting for the next 30 years. Whatever that is, as soon as it gets exposed
> > > > to userland, we will have to support it.
> 
> > > To me that sounds like an argument for hiding things :)
> 
> > the problem with hiding, though, is that once something new comes about, it
> > might not fit our current abstraction and it might be big PITA to support "old"
> > and new systems.
> 
> 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.

> > > > And this another reason I think a more granular approach is better, as it allows
> > > > us to easily add more pieces as they come along.
> 
> > > OTOH it's more work for the system as a whole.
> 
> > it's more work outside the kernel, yes. The total amount of work (kernel +
> > userspace) will be the same, regardless if you hide it in the kernel or in userspace.
> 
> Like I say I'm worried about deployment issues for the split solutions
> making things harder than they should be.

and I'm worried about us having too much inside the kernel and that making
things harder than they should be :-)

-- 
balbi

Attachment: signature.asc
Description: PGP signature