ACK/Cmnt: [PULL v7][SRU][Jammy] Support Intel IPU6 MIPI camera on Alder Lake platforms

[You-Sheng Yang]

On Thu, May 26, 2022 at 12:25 AM Andrea Righi
<andrea.righi at canonical.com> wrote:
>
> On Wed, May 25, 2022 at 11:05:10PM +0800, You-Sheng Yang wrote:
> > On Wed, May 25, 2022 at 9:30 PM Andrea Righi <andrea.righi at canonical.com> wrote:
> > > On Wed, May 25, 2022 at 06:38:44PM +0800, You-Sheng Yang wrote:
> ...
> > > 1) In the first set of commits:
> > >
> > >  1f69ec679b19 UBUNTU: SAUCE: IPU driver release WW14
> > >  7d3cff6e365e UBUNTU: SAUCE: IPU driver release WW04
> > >  a5733bc898ab UBUNTU: SAUCE: IPU driver release WW52
> > >  db472c127487 UBUNTU: SAUCE: IPU driver release WW48 with MCU
> > >  8d6d4af24f5b UBUNTU: SAUCE: IPU driver release WW48
> > >  07e7d9202f9b UBUNTU: SAUCE: intel ipu drivers first release
> > >
> > > it would be nice to know what kind of backport activity was required, I see
> > > that you pretty much imported the initial code from
> > > github.com/intel/ipu6-drivers, what kind of adjustment you had to do to
> > > apply this code to the jammy kernel? Just a few context adjustments or
> > > you had to fix some ABI changes?
> >
> > The upstream repo is a partial kernel tree that contains only
> > ipu6/ivsc drivers. It, along with ivsc-driver, finally gained the
> > ability to build inlinely as a DKMS source tree. So, these backports
> > were for accommodating Makefile/Kconfig contents to our kernel source
> > tree.
>
> Makefile/Kconfig changes sounds good, maybe next time it'd be nice to
> report a short comment around the backport line to explain the backport
> activity (in this case Makefile/Kconfig adjustments).

Sure. Anything that would help explain the purpose and result is a
good practice.

> > > 2) I think I've asked this before, but who's going to maintain this? Do
> > > we need to actively keep track of github.com/intel/ipu6-drivers and
> > > apply stable fixes in the future?
> >
> > Two parts. From oem-5.17 and on, we're to use the DKMS format instead.
> > Bugs for tracking this are so far:
> >
> >   * https://launchpad.net/bugs/1972106: import ivsc-driver to Ubuntu archive
> >   * https://launchpad.net/bugs/1972109: import ipu6-drivers
> >
> > So there will not be ipu6/ivsc drivers in the kernel tree starting
> > from 5.17, but it's also true there might still be fixes specialized
> > for IPU6 to be backported into generic/oem kernel trees, such as
> > https://bugs.launchpad.net/bugs/1958004.
> >
> > With https://bugs.launchpad.net/bugs/1969434 made its way into Jammy,
> > we may reconsider doing the same thing as oem-5.17 -- use dkms instead
> > and remove in kernel IPU6 drivers.
> >
> > And, yes, even if we switched to DKMS method, we'll still have to
> > monitor the changes from upstream repo as long as we would like to
> > continue supporting IPU6 cameras in oem projects, except it's now
> > easier because the upstream repos have been converted to DKMS source
> > trees already. No backporting to generic/oem kernel trees will then be
> > required.
>
> OK.
>
> >
> > >  Is there any plan to merge this upstream?
> >
> > Intel's plan was to upstream their IPU7 (not IPU6) driver on 2024, and
> > Dell and Canonical have raised the request to upstream IPU6 driver as
> > well explicitly.
>
> OK.
>
> >
> > > 3) Which commits have been added to address the regressions of
> > > Ubuntu-5.15.0-28.29? Just curious to see what was the problem and maybe
> > > check for similar patterns in the code.
> >
> > The problem was that the last 10 commits from this pull request break
> > IPU6 on TGL platforms, but we need 5.15 kernel for ADL platforms only,
> > for now. On the first time these drivers were proposed for 5.15, I
> > skipped the last 10 commits so that proposed changeset were identical
> > to those in oem-5.14 (with a few fixes for 5.15 of course), but it
> > turned out to hang one of the TGL MIPI camera platform while loading
> > ljca driver from ivsc-driver repo. So it's a choice between hanging
> > one of the TGL platforms or failing to enable the camera of all TGL
> > platforms. We now pick the latter, and Intel is working on identifying
> > the root cause before we will migrate oem-5.14 to hwe-5.15 a couple of
> > months later.
>
> OK, I understand now. Thanks for all the extra details!
>
> -Andrea



-- 
Regards,
You-Sheng Yang