Message-ID: <20151005162904.GF18784@saruman.tx.rr.com>
Date:	Mon, 5 Oct 2015 11:29:04 -0500
From:	Felipe Balbi <balbi@...com>
To:	Mark Brown <broonie@...nel.org>
CC:	Felipe Balbi <balbi@...com>, Baolin Wang <baolin.wang@...aro.org>,
	Greg KH <gregkh@...uxfoundation.org>, <sre@...nel.org>,
	<dbaryshkov@...il.com>, <dwmw2@...radead.org>,
	<peter.chen@...escale.com>, <stern@...land.harvard.edu>,
	<r.baldyga@...sung.com>, <sojka@...ica.cz>,
	<yoshihiro.shimoda.uh@...esas.com>, <linux-usb@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <sameo@...ux.intel.com>,
	<lee.jones@...aro.org>, <ckeepax@...nsource.wolfsonmicro.com>,
	<patches@...nsource.wolfsonmicro.com>, <linux-pm@...r.kernel.org>,
	<device-mainlining@...ts.linuxfoundation.org>
Subject: Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

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

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists