Re: Fwd: Surface Go VCM type (was: Need to pass acpi_enforce_resources=lax on the Surface Go (version1))

From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Dave Stevenson <dave.stevenson@raspberrypi.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Daniel Scally <djrscally@gmail.com>, Kate Hsuan <hpa@redhat.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	libcamera devel <libcamera-devel@lists.libcamera.org>,
	Sakari Ailus <sakari.ailus@iki.fi>
Subject: Re: Fwd: Surface Go VCM type (was: Need to pass acpi_enforce_resources=lax on the Surface Go (version1))
Date: Mon, 15 Nov 2021 17:03:31 +0200	[thread overview]
Message-ID: <YZJ2wzYTQnZBe9ev@smile.fi.intel.com> (raw)
In-Reply-To: <YZJhxJ+z4Zvg8ewP@pendragon.ideasonboard.com>

On Mon, Nov 15, 2021 at 03:33:56PM +0200, Laurent Pinchart wrote:
> On Fri, Nov 12, 2021 at 01:37:27PM +0200, Andy Shevchenko wrote:
> > On Fri, Nov 12, 2021 at 12:46:56PM +0200, Laurent Pinchart wrote:
> > > On Fri, Nov 12, 2021 at 10:32:31AM +0000, Dave Stevenson wrote:
> > > > On Thu, 11 Nov 2021 at 22:04, Laurent Pinchart wrote:
> > 
> > > > Sorry, just my two-penneth as someone who has to support general
> > > > users, rather than just develop platforms or address specific use
> > > > cases.
> > > 
> > > As mentioned above, I certainly don't oppose improving power management
> > > for VCMs, as well as the VCM control API in general, as long as we can
> > > cover all use cases. I'm not familiar enough with the use cases to tell
> > > whether making the kernel side more "clever" would be just fine or could
> > > cause issues.
> > 
> > Personally I found the
> > 
> >   kernel <--> library in userspace <--> another library or app
> > 
> > schema is more flexible in many ways:
> >  - we unburden kernel from the heavy code that has nothing to
> >    do directly with HW
> >  - we allow nevertheless to use kernel ABIs if needed
> >  - we decrease burden of the ABI evolution by doing it in only
> >    two places
> 
> I think that's generally true (provided the low-level userspace library
> is well designed). In this specific case, we're moving towards that
> model, and even if it ends up being better, I agree with Dave that the
> transition can be painful.
> 
> > After all this kind of schema might lead us at some point to the
> > shifting of 'we don't break user space' paradigm to the 'we hardly
> > try not to break user space and do not break library ABIs / APIs
> > in user space'.
> 
> Is that an officially allowed policy for kernel subsystems ?

Keyword is "might". And no, it's not allowed right now, but that's I recognize
as a trend.

-- 
With Best Regards,
Andy Shevchenko