From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Genes Lists <lists@sapience.com>,
linux-kernel@vger.kernel.org, mchehab@kernel.org,
hverkuil-cisco@xs4all.nl, wentong.wu@intel.com,
linux-media@vger.kernel.org, linux-acpi@vger.kernel.org,
"regressions@lists.linux.dev" <regressions@lists.linux.dev>
Subject: Re: [PATCH 1/1] ACPI: scan: Ignore Dell XPS 9320 camera graph port nodes
Date: Wed, 12 Jun 2024 17:39:56 +0300 [thread overview]
Message-ID: <20240612143956.GN28989@pendragon.ideasonboard.com> (raw)
In-Reply-To: <18cb82bb-51c6-4a52-80a4-6b1e3d95f99c@redhat.com>
On Wed, Jun 12, 2024 at 04:30:30PM +0200, Hans de Goede wrote:
> On 6/12/24 3:06 PM, Rafael J. Wysocki wrote:
> > On Wed, Jun 12, 2024 at 2:47 PM Sakari Ailus wrote:
> >> On Wed, Jun 12, 2024 at 02:32:26PM +0200, Rafael J. Wysocki wrote:
> >>>>>>> I just hit the same problem on another Dell laptop. It seems that
> >>>>>>> all Dell laptops with IPU6 camera from the Tiger Lake, Alder Lake
> >>>>>>> and Raptor Lake generations suffer from this problem.
> >>>>>>>
> >>>>>>> So instead of playing whack a mole with DMI matches we should
> >>>>>>> simply disable ACPI MIPI DISCO support on all Dell laptops
> >>>>>>> with those CPUs. I'm preparing a fix for this to replace
> >>>>>>> the DMI matching now.
> >>>>>>
> >>>>>> DisCo for Imaging support shouldn't be dropped on these systems, and this
> >>>>>> isn't what your patch does either. Instead the ACPI graph port nodes (as
> >>>>>> per Linux specific definitions) are simply dropped, i.e. this isn't related
> >>>>>> to DisCo for Imaging at all.
> >>>>>
> >>>>> So it looks like the changelog of that patch could be improved, right?
> >>>>
> >>>> Well, yes. The reason the function is in the file is that nearly all camera
> >>>> related parsing is located there, not that it would be related to DisCo for
> >>>> Imaging as such.
> >>>
> >>> So IIUC the camera graph port nodes are created by default with the
> >>> help of the firmware-supplied information, but if that is defective a
> >>> quirk can be added to skip the creation of those ports in which case
> >>> they will be created elsewhere.
> >>>
> >>> Is this correct?
> >>
> >> Yes.
> >
> > So it would be good to add a comment to this effect to
> > acpi_nondev_subnode_extract() where acpi_graph_ignore_port() is
> > called.
> >
> > And there is a somewhat tangential question that occurred to me: If
> > the nodes are created elsewhere when acpi_graph_ignore_port() is true,
> > why is it necessary to consult the platform firmware for the
> > information on them at all? Wouldn't it be better to simply always
> > create them elsewhere?
>
> That is a good question. The ACPI MIPI DISCO specification is an
> attempt standardize how MIPI cameras and their sensors are described
> in ACPI.
>
> But this is not actually being used by any Windows drivers atm. The windows
> drivers rely on their own custom ACPI data which gets translated into
> standard Linux device-properties by: drivers/media/pci/intel/ipu-bridge.c
>
> and so far AFAIK there are 0 laptops where there actually is 100% functional
> ACPI MIPI information. I believe that some work is in place to get correct
> usable ACPI MIPI information in place in the ACPI tables of some Meteor Lake
> laptops. But I believe that there too it does not work yet with the BIOS
> version with which current Windows models are shipping. It is being fixed
> for systems which have Linux support from the vendor but I suspect that
I think it's shipped in Chrome Books. Sakari can confirm.
> on other models if ACPI MIPI DISCO information is there it will not
> necessarily be reliable because AFAICT Windows does not actually use it.
>
> And TBH this has me worried about camera support for Meteor Lake devices
> going forward. We really need to have 1 reliable source of truth here and
> using information which is ignored by Windows does not seem like the best
> source to use.
As long as the Windows drivers don't use the ACPI data that Linux uses,
you can be 100% sure it will be wrong. That will never be fixed if Intel
doesn't address the issue on their side, and effort we would put in
standardizing that data for machines shipped by Windows OEMs is a waste
of time in my opinion. Our only option, given Intel's failure, is to
keep reverse-engineering camera support per machine for the time being
(sometimes with the help of OEMs).
> Sakari I know you have been pushing for MIPI camera descriptions under
> ACPI to move to a standardized format and I can see how that is a good
> thing, but atm it seems to mainly cause things to break and before
> the ACPI MIPI DISCO support landed in 6.8 we did not have these issues,
> since the information used by the ipu-bridge code does seem to be correct.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2024-06-12 14:40 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-27 16:34 6.10-rc1 : crash in mei_csi_probe Genes Lists
2024-05-27 19:57 ` Sakari Ailus
2024-05-27 20:58 ` Genes Lists
2024-05-28 8:44 ` [PATCH 1/1] ACPI: scan: Ignore Dell XPS 9320 camera graph port nodes Sakari Ailus
2024-05-28 17:09 ` Hans de Goede
2024-06-06 18:12 ` Hans de Goede
2024-06-07 7:55 ` Rafael J. Wysocki
2024-06-07 9:24 ` Sakari Ailus
2024-06-12 10:08 ` Hans de Goede
2024-06-12 10:25 ` Rafael J. Wysocki
2024-06-12 12:10 ` Sakari Ailus
2024-06-12 12:21 ` Rafael J. Wysocki
2024-06-12 12:26 ` Sakari Ailus
2024-06-12 12:32 ` Rafael J. Wysocki
2024-06-12 12:47 ` Sakari Ailus
2024-06-12 13:06 ` Rafael J. Wysocki
2024-06-12 14:30 ` Hans de Goede
2024-06-12 14:39 ` Laurent Pinchart [this message]
2024-06-12 18:24 ` Sakari Ailus
2024-06-12 19:07 ` Rafael J. Wysocki
2024-06-12 20:08 ` Laurent Pinchart
2024-06-12 15:26 ` Rafael J. Wysocki
2024-06-12 18:33 ` Sakari Ailus
2024-06-12 18:41 ` Rafael J. Wysocki
2024-06-12 19:06 ` Sakari Ailus
2024-06-12 19:12 ` Rafael J. Wysocki
2024-06-12 19:17 ` Sakari Ailus
2024-06-12 19:32 ` Rafael J. Wysocki
2024-06-12 20:00 ` Sakari Ailus
2024-06-12 20:17 ` Sakari Ailus
2024-06-13 9:50 ` Rafael J. Wysocki
2024-06-12 18:21 ` Sakari Ailus
2024-06-12 18:29 ` Rafael J. Wysocki
2024-06-12 18:40 ` Sakari Ailus
2024-06-12 18:50 ` Rafael J. Wysocki
2024-06-12 19:11 ` Sakari Ailus
2024-06-12 19:26 ` Rafael J. Wysocki
2024-06-12 20:00 ` Laurent Pinchart
2024-06-12 20:31 ` Rafael J. Wysocki
2024-06-12 20:41 ` Laurent Pinchart
2024-06-13 12:37 ` Rafael J. Wysocki
2024-06-12 20:01 ` Laurent Pinchart
2024-05-30 0:35 ` Wu, Wentong
2024-06-06 15:39 ` 6.10-rc1 : crash in mei_csi_probe Genes Lists
2024-06-06 15:50 ` Sakari Ailus
2024-06-06 16:17 ` Genes Lists
2024-06-06 17:07 ` Linux regression tracking (Thorsten Leemhuis)
2024-06-07 7:57 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240612143956.GN28989@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=hdegoede@redhat.com \
--cc=hverkuil-cisco@xs4all.nl \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=lists@sapience.com \
--cc=mchehab@kernel.org \
--cc=rafael@kernel.org \
--cc=regressions@lists.linux.dev \
--cc=sakari.ailus@linux.intel.com \
--cc=wentong.wu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).