[PATCH] ACPI: scan: Honor _DEP for Intel CVS devices

[PATCH] ACPI: scan: Honor _DEP for Intel CVS devices

[Miguel Vadillo]

CVS (Computer Vision Sensing) is an ACPI-enumerated device that sits
inline in the CSI-2 path between the camera sensor and Intel IPU.
On platforms where CVS is present, the camera sensor's ACPI node
declares a _DEP dependency on the CVS device.

The CVS driver must be fully initialized before camera sensor drivers
probe, because CVS controls the CSI-2 link ownership handshake (via
GPIO REQ/RESP), the MIPI/CSI-2 lane configuration, and the camera
power domain. Without CVS ready, the sensor driver can bind but the
CSI-2 stream will not function correctly.

The CVS driver calls acpi_dev_clear_dependencies() at the end of its
probe() to unblock waiting consumers once it is ready.

Move the CVS HIDs from acpi_ignore_dep_ids[] to acpi_honor_dep_ids[]
so that camera sensor enumeration is deferred until the CVS driver has
finished probing, matching the behavior already in place for IVSC.

Signed-off-by: Miguel Vadillo <miguel.vadillo@intel.com>
---
Note: this patch has a functional dependency on the CVS driver and its
IPU bridge support, which are queued in media-next for v7.2. Without
those drivers, no code will call acpi_dev_clear_dependencies() for the
CVS HIDs and camera sensors will remain deferred indefinitely.

The CVS driver series (v5) can be found at:
  https://lore.kernel.org/linux-media/20260527170531.383871-1-miguel.vadillo@intel.com/

 drivers/acpi/scan.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 530547cda8b2..1463eb3a4f6e 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -848,8 +848,6 @@ static bool acpi_info_matches_ids(struct acpi_device_info *info,
 static const char * const acpi_ignore_dep_ids[] = {
 	"PNP0D80", /* Windows-compatible System Power Management Controller */
 	"INT33BD", /* Intel Baytrail Mailbox Device */
-	"INTC10DE", /* Intel CVS LNL */
-	"INTC10E0", /* Intel CVS ARL */
 	"LATT2021", /* Lattice FW Update Client Driver */
 	NULL
 };
@@ -861,6 +859,9 @@ static const char * const acpi_honor_dep_ids[] = {
 	"INTC1095", /* IVSC (ADL) driver must be loaded to allow i2c access to camera sensors */
 	"INTC100A", /* IVSC (RPL) driver must be loaded to allow i2c access to camera sensors */
 	"INTC10CF", /* IVSC (MTL) driver must be loaded to allow i2c access to camera sensors */
+	"INTC10DE", /* CVS (LNL) driver must be loaded to allow camera streaming */
+	"INTC10E0", /* CVS (ARL) driver must be loaded to allow camera streaming */
+	"INTC10E1", /* CVS (PTL) driver must be loaded to allow camera streaming */
 	"RSCV0001", /* RISC-V PLIC */
 	"RSCV0002", /* RISC-V APLIC */
 	"RSCV0005", /* RISC-V SBI MPXY MBOX */
-- 
2.43.0

Re: [PATCH] ACPI: scan: Honor _DEP for Intel CVS devices

[Sakari Ailus]

Hi Miguel, Rafael,

Thanks for the patch.

On Mon, Jun 01, 2026 at 12:40:40PM -0700, Miguel Vadillo wrote:
> CVS (Computer Vision Sensing) is an ACPI-enumerated device that sits
> inline in the CSI-2 path between the camera sensor and Intel IPU.
> On platforms where CVS is present, the camera sensor's ACPI node
> declares a _DEP dependency on the CVS device.
> 
> The CVS driver must be fully initialized before camera sensor drivers
> probe, because CVS controls the CSI-2 link ownership handshake (via
> GPIO REQ/RESP), the MIPI/CSI-2 lane configuration, and the camera
> power domain. Without CVS ready, the sensor driver can bind but the
> CSI-2 stream will not function correctly.
> 
> The CVS driver calls acpi_dev_clear_dependencies() at the end of its
> probe() to unblock waiting consumers once it is ready.
> 
> Move the CVS HIDs from acpi_ignore_dep_ids[] to acpi_honor_dep_ids[]
> so that camera sensor enumeration is deferred until the CVS driver has
> finished probing, matching the behavior already in place for IVSC.
> 
> Signed-off-by: Miguel Vadillo <miguel.vadillo@intel.com>

Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>

Rafael: do you think this could still make it to 7.2? Otherwise cameras
might not work on a some laptops where they did use to.

The default configuration is appropriate in some laptops so camera used to
work without the CVS driver but now that we have the CVS driver merged and
the CVS device is part of the software node / ACPI graph, probing the
camera sensor driver will in fact not take place at all (and obviously the
camera won't work in this case).

-- 
Kind regards,

Sakari Ailus

Re: [PATCH] ACPI: scan: Honor _DEP for Intel CVS devices

[Rafael J. Wysocki]

On Wed, Jun 3, 2026 at 9:43 AM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> Hi Miguel, Rafael,
>
> Thanks for the patch.
>
> On Mon, Jun 01, 2026 at 12:40:40PM -0700, Miguel Vadillo wrote:
> > CVS (Computer Vision Sensing) is an ACPI-enumerated device that sits
> > inline in the CSI-2 path between the camera sensor and Intel IPU.
> > On platforms where CVS is present, the camera sensor's ACPI node
> > declares a _DEP dependency on the CVS device.
> >
> > The CVS driver must be fully initialized before camera sensor drivers
> > probe, because CVS controls the CSI-2 link ownership handshake (via
> > GPIO REQ/RESP), the MIPI/CSI-2 lane configuration, and the camera
> > power domain. Without CVS ready, the sensor driver can bind but the
> > CSI-2 stream will not function correctly.
> >
> > The CVS driver calls acpi_dev_clear_dependencies() at the end of its
> > probe() to unblock waiting consumers once it is ready.
> >
> > Move the CVS HIDs from acpi_ignore_dep_ids[] to acpi_honor_dep_ids[]
> > so that camera sensor enumeration is deferred until the CVS driver has
> > finished probing, matching the behavior already in place for IVSC.
> >
> > Signed-off-by: Miguel Vadillo <miguel.vadillo@intel.com>
>
> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
>
> Rafael: do you think this could still make it to 7.2? Otherwise cameras
> might not work on a some laptops where they did use to.
>
> The default configuration is appropriate in some laptops so camera used to
> work without the CVS driver but now that we have the CVS driver merged and
> the CVS device is part of the software node / ACPI graph, probing the
> camera sensor driver will in fact not take place at all (and obviously the
> camera won't work in this case).

Applied as 7.2 material, thanks!

Re: [PATCH] ACPI: scan: Honor _DEP for Intel CVS devices

[Thorsten Leemhuis]

On 6/1/26 21:40, Miguel Vadillo wrote:
> CVS (Computer Vision Sensing) is an ACPI-enumerated device that sits
> inline in the CSI-2 path between the camera sensor and Intel IPU.
> On platforms where CVS is present, the camera sensor's ACPI node
> declares a _DEP dependency on the CVS device.
> 
> The CVS driver must be fully initialized before camera sensor drivers
> probe, because CVS controls the CSI-2 link ownership handshake (via
> GPIO REQ/RESP), the MIPI/CSI-2 lane configuration, and the camera
> power domain. Without CVS ready, the sensor driver can bind but the
> CSI-2 stream will not function correctly.
> 
> The CVS driver calls acpi_dev_clear_dependencies() at the end of its
> probe() to unblock waiting consumers once it is ready.
> 
> Move the CVS HIDs from acpi_ignore_dep_ids[] to acpi_honor_dep_ids[]
> so that camera sensor enumeration is deferred until the CVS driver has
> finished probing, matching the behavior already in place for IVSC.

TWIMC, there is a bug report where one or two people claim that this
change caused a regression; the report is quite verbose (guess LLM
assisted) and hard to grasp for me as outsider; requests for
clarifications from my side were not really fruitful. Not sure what to
make of this, but I thought I'd let you know; for details see:

https://bugzilla.kernel.org/show_bug.cgi?id=221988

Ciao, Thorsten
> Signed-off-by: Miguel Vadillo <miguel.vadillo@intel.com>
> ---
> Note: this patch has a functional dependency on the CVS driver and its
> IPU bridge support, which are queued in media-next for v7.2. Without
> those drivers, no code will call acpi_dev_clear_dependencies() for the
> CVS HIDs and camera sensors will remain deferred indefinitely.
> 
> The CVS driver series (v5) can be found at:
>   https://lore.kernel.org/linux-media/20260527170531.383871-1-miguel.vadillo@intel.com/
> 
>  drivers/acpi/scan.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 530547cda8b2..1463eb3a4f6e 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -848,8 +848,6 @@ static bool acpi_info_matches_ids(struct acpi_device_info *info,
>  static const char * const acpi_ignore_dep_ids[] = {
>  	"PNP0D80", /* Windows-compatible System Power Management Controller */
>  	"INT33BD", /* Intel Baytrail Mailbox Device */
> -	"INTC10DE", /* Intel CVS LNL */
> -	"INTC10E0", /* Intel CVS ARL */
>  	"LATT2021", /* Lattice FW Update Client Driver */
>  	NULL
>  };
> @@ -861,6 +859,9 @@ static const char * const acpi_honor_dep_ids[] = {
>  	"INTC1095", /* IVSC (ADL) driver must be loaded to allow i2c access to camera sensors */
>  	"INTC100A", /* IVSC (RPL) driver must be loaded to allow i2c access to camera sensors */
>  	"INTC10CF", /* IVSC (MTL) driver must be loaded to allow i2c access to camera sensors */
> +	"INTC10DE", /* CVS (LNL) driver must be loaded to allow camera streaming */
> +	"INTC10E0", /* CVS (ARL) driver must be loaded to allow camera streaming */
> +	"INTC10E1", /* CVS (PTL) driver must be loaded to allow camera streaming */
>  	"RSCV0001", /* RISC-V PLIC */
>  	"RSCV0002", /* RISC-V APLIC */
>  	"RSCV0005", /* RISC-V SBI MPXY MBOX */

Re: [PATCH] ACPI: scan: Honor _DEP for Intel CVS devices

[Thorsten Leemhuis]

On 9/12/26 18:50, Thorsten Leemhuis wrote:
> On 6/1/26 21:40, Miguel Vadillo wrote:
>> CVS (Computer Vision Sensing) is an ACPI-enumerated device that sits
>> inline in the CSI-2 path between the camera sensor and Intel IPU.
>> On platforms where CVS is present, the camera sensor's ACPI node
>> declares a _DEP dependency on the CVS device.
>>
>> The CVS driver must be fully initialized before camera sensor drivers
>> probe, because CVS controls the CSI-2 link ownership handshake (via
>> GPIO REQ/RESP), the MIPI/CSI-2 lane configuration, and the camera
>> power domain. Without CVS ready, the sensor driver can bind but the
>> CSI-2 stream will not function correctly.
>>
>> The CVS driver calls acpi_dev_clear_dependencies() at the end of its
>> probe() to unblock waiting consumers once it is ready.
>>
>> Move the CVS HIDs from acpi_ignore_dep_ids[] to acpi_honor_dep_ids[]
>> so that camera sensor enumeration is deferred until the CVS driver has
>> finished probing, matching the behavior already in place for IVSC.
> 
> TWIMC, there is a bug report where one or two people claim that this
> change caused a regression; the report is quite verbose (guess LLM
> assisted) and hard to grasp for me as outsider; requests for
> clarifications from my side were not really fruitful. Not sure what to
> make of this, but I thought I'd let you know; for details see:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=221988

For completeness, a report that is more straight forward to read (at
least for me) was now posted here:
https://lore.kernel.org/all/20260912185836.309071-1-manuel.knitza@googlemail.com/

Cia, Thorsten

>> Signed-off-by: Miguel Vadillo <miguel.vadillo@intel.com>
>> ---
>> Note: this patch has a functional dependency on the CVS driver and its
>> IPU bridge support, which are queued in media-next for v7.2. Without
>> those drivers, no code will call acpi_dev_clear_dependencies() for the
>> CVS HIDs and camera sensors will remain deferred indefinitely.
>>
>> The CVS driver series (v5) can be found at:
>>   https://lore.kernel.org/linux-media/20260527170531.383871-1-miguel.vadillo@intel.com/
>>
>>  drivers/acpi/scan.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> index 530547cda8b2..1463eb3a4f6e 100644
>> --- a/drivers/acpi/scan.c
>> +++ b/drivers/acpi/scan.c
>> @@ -848,8 +848,6 @@ static bool acpi_info_matches_ids(struct acpi_device_info *info,
>>  static const char * const acpi_ignore_dep_ids[] = {
>>  	"PNP0D80", /* Windows-compatible System Power Management Controller */
>>  	"INT33BD", /* Intel Baytrail Mailbox Device */
>> -	"INTC10DE", /* Intel CVS LNL */
>> -	"INTC10E0", /* Intel CVS ARL */
>>  	"LATT2021", /* Lattice FW Update Client Driver */
>>  	NULL
>>  };
>> @@ -861,6 +859,9 @@ static const char * const acpi_honor_dep_ids[] = {
>>  	"INTC1095", /* IVSC (ADL) driver must be loaded to allow i2c access to camera sensors */
>>  	"INTC100A", /* IVSC (RPL) driver must be loaded to allow i2c access to camera sensors */
>>  	"INTC10CF", /* IVSC (MTL) driver must be loaded to allow i2c access to camera sensors */
>> +	"INTC10DE", /* CVS (LNL) driver must be loaded to allow camera streaming */
>> +	"INTC10E0", /* CVS (ARL) driver must be loaded to allow camera streaming */
>> +	"INTC10E1", /* CVS (PTL) driver must be loaded to allow camera streaming */
>>  	"RSCV0001", /* RISC-V PLIC */
>>  	"RSCV0002", /* RISC-V APLIC */
>>  	"RSCV0005", /* RISC-V SBI MPXY MBOX */
> 
> 

Re: [PATCH] ACPI: scan: Honor _DEP for Intel CVS devices

[Rafael J. Wysocki (Intel)]

On Sun, Sep 13, 2026 at 10:30 AM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> On 9/12/26 18:50, Thorsten Leemhuis wrote:
> > On 6/1/26 21:40, Miguel Vadillo wrote:
> >> CVS (Computer Vision Sensing) is an ACPI-enumerated device that sits
> >> inline in the CSI-2 path between the camera sensor and Intel IPU.
> >> On platforms where CVS is present, the camera sensor's ACPI node
> >> declares a _DEP dependency on the CVS device.
> >>
> >> The CVS driver must be fully initialized before camera sensor drivers
> >> probe, because CVS controls the CSI-2 link ownership handshake (via
> >> GPIO REQ/RESP), the MIPI/CSI-2 lane configuration, and the camera
> >> power domain. Without CVS ready, the sensor driver can bind but the
> >> CSI-2 stream will not function correctly.
> >>
> >> The CVS driver calls acpi_dev_clear_dependencies() at the end of its
> >> probe() to unblock waiting consumers once it is ready.
> >>
> >> Move the CVS HIDs from acpi_ignore_dep_ids[] to acpi_honor_dep_ids[]
> >> so that camera sensor enumeration is deferred until the CVS driver has
> >> finished probing, matching the behavior already in place for IVSC.
> >
> > TWIMC, there is a bug report where one or two people claim that this
> > change caused a regression; the report is quite verbose (guess LLM
> > assisted) and hard to grasp for me as outsider; requests for
> > clarifications from my side were not really fruitful. Not sure what to
> > make of this, but I thought I'd let you know; for details see:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=221988
>
> For completeness, a report that is more straight forward to read (at
> least for me) was now posted here:
> https://lore.kernel.org/all/20260912185836.309071-1-manuel.knitza@googlemail.com/

This doesn't seem to be about the same commit though as it mentions
ipu-bridge.c which is not touched by the patch in question here.

Thanks!

Re: [PATCH] ACPI: scan: Honor _DEP for Intel CVS devices

[Sakari Ailus]

Hi Thorsten,

On Sun, Sep 13, 2026 at 10:27:15AM +0200, Thorsten Leemhuis wrote:
> On 9/12/26 18:50, Thorsten Leemhuis wrote:
> > On 6/1/26 21:40, Miguel Vadillo wrote:
> >> CVS (Computer Vision Sensing) is an ACPI-enumerated device that sits
> >> inline in the CSI-2 path between the camera sensor and Intel IPU.
> >> On platforms where CVS is present, the camera sensor's ACPI node
> >> declares a _DEP dependency on the CVS device.
> >>
> >> The CVS driver must be fully initialized before camera sensor drivers
> >> probe, because CVS controls the CSI-2 link ownership handshake (via
> >> GPIO REQ/RESP), the MIPI/CSI-2 lane configuration, and the camera
> >> power domain. Without CVS ready, the sensor driver can bind but the
> >> CSI-2 stream will not function correctly.
> >>
> >> The CVS driver calls acpi_dev_clear_dependencies() at the end of its
> >> probe() to unblock waiting consumers once it is ready.
> >>
> >> Move the CVS HIDs from acpi_ignore_dep_ids[] to acpi_honor_dep_ids[]
> >> so that camera sensor enumeration is deferred until the CVS driver has
> >> finished probing, matching the behavior already in place for IVSC.
> > 
> > TWIMC, there is a bug report where one or two people claim that this
> > change caused a regression; the report is quite verbose (guess LLM
> > assisted) and hard to grasp for me as outsider; requests for
> > clarifications from my side were not really fruitful. Not sure what to
> > make of this, but I thought I'd let you know; for details see:
> > 
> > https://bugzilla.kernel.org/show_bug.cgi?id=221988
> 
> For completeness, a report that is more straight forward to read (at
> least for me) was now posted here:
> https://lore.kernel.org/all/20260912185836.309071-1-manuel.knitza@googlemail.com/

Thanks for the link, I've replied to the bug report.

-- 
Kind regards,

Sakari Ailus