media: atomisp: Fix buffer overrun in gmin_get_var_int()

Not all functions used in gmin_get_var_int() update len to the actual
length of the returned string. So len may still have its initial value

media: atomisp: Fix buffer overrun in gmin_get_var_int()

Not all functions used in gmin_get_var_int() update len to the actual
length of the returned string. So len may still have its initial value
of the length of val[] when "val[len] = 0;" is run to ensure 0 termination.

If this happens we end up writing one beyond the bounds of val[], fix this.

Note this is a quick fix for this since the entirety of
atomisp_gmin_platform.c will be removed once all atomisp sensor
drivers have been moved over to runtime-pm + v4l2-async device
registration.

Closes: https://lore.kernel.org/linux-media/26f37e19-c240-4d77-831d-ef3f1a4dd51d@kili.mountain/

Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp: gmin_platform: fix out_len in gmin_get_config_dsm_var()

Ideally, strlen(cur->string.pointer) and strlen(out) would be the same.
But this code is using strscpy() to avoid a potential

media: atomisp: gmin_platform: fix out_len in gmin_get_config_dsm_var()

Ideally, strlen(cur->string.pointer) and strlen(out) would be the same.
But this code is using strscpy() to avoid a potential buffer overflow.
So in the same way we should take the strlen() of the smaller string to
avoid a buffer overflow in the caller, gmin_get_var_int().

Link: https://lore.kernel.org/r/26124bcd-8132-4483-9d67-225c87d424e8@kili.mountain

Fixes: 387041cda44e ("media: atomisp: improve sensor detection code to use _DSM table")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp: Drop v4l2_get_acpi_sensor_info() function

Drop v4l2_get_acpi_sensor_info() the 2 sensor drivers which were
using this have both been converted to v4l2-async probing, relying
on the a

media: atomisp: Drop v4l2_get_acpi_sensor_info() function

Drop v4l2_get_acpi_sensor_info() the 2 sensor drivers which were
using this have both been converted to v4l2-async probing, relying
on the atomisp_csi2_bridge.c code to add the GPIO mappings instead.

Link: https://lore.kernel.org/r/20230525190100.130010-5-hdegoede@redhat.com

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp: initialize settings to 0

Fix a compiler warning:

drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c:1525:13: warning: 'settings' may be used uninitialized [-Wmaybe-uninitiali

media: atomisp: initialize settings to 0

Fix a compiler warning:

drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c:1525:13: warning: 'settings' may be used uninitialized [-Wmaybe-uninitialized]

The 'settings' variable is actually always initialized, but the
compiler isn't quite able to figure that out. Just initialize it
to 0 to avoid this warning.

Link: https://lore.kernel.org/r/20230524121150.435736-2-hverkuil-cisco@xs4all.nl

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp: Store number of sensor lanes per port in struct atomisp_device

Store number of sensor lanes per port in struct atomisp_device.

This is a preparation patch for adding v4l2-async sens

media: atomisp: Store number of sensor lanes per port in struct atomisp_device

Store number of sensor lanes per port in struct atomisp_device.

This is a preparation patch for adding v4l2-async sensor probing support.
With async probing the inputs will get registered later, but we can
already fill the sensor_lanes array when parsing the fwnodes.

Link: https://lore.kernel.org/r/20230518153733.195306-6-hdegoede@redhat.com

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp: gmin_platform: Add Lenovo Ideapad Miix 310 gmin_vars

The _DSM used to get sensor variables like CsiPort returns the wrong
csi-port for the front OV2680 sensor on the Lenovo Ideapad M

media: atomisp: gmin_platform: Add Lenovo Ideapad Miix 310 gmin_vars

The _DSM used to get sensor variables like CsiPort returns the wrong
csi-port for the front OV2680 sensor on the Lenovo Ideapad Miix 310
add a gmin_vars DMI quirk / override setting the right CsiPort.

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp: gmin_platform: Make DMI quirks take precedence over the _DSM table

On some devices the _DSM sensor-info table contains wrong info,
move the DMI quirk handling up to above the _DSM ta

media: atomisp: gmin_platform: Make DMI quirks take precedence over the _DSM table

On some devices the _DSM sensor-info table contains wrong info,
move the DMI quirk handling up to above the _DSM table check
to allow DMI quirks to override wrong info in the _DSM table.

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp: Add v4l2_get_acpi_sensor_info() helper

ACPI nodes describing sensors on atomisp devices implement a
"79234640-9e10-4fea-a5c1-b5aa8b19756f" Device Specific Method (DSM)
to get info ab

media: atomisp: Add v4l2_get_acpi_sensor_info() helper

ACPI nodes describing sensors on atomisp devices implement a
"79234640-9e10-4fea-a5c1-b5aa8b19756f" Device Specific Method (DSM)
to get info about the GPIOs.

Using this method is necessary to figure out which ACPI GPIO resource
is "reset" and which one is "powerdown" and this is also necessary to
figure out the correct polarity of the pins.

One example where this is necessary is the GC0310 sensor. The current
GC0310 code hardcodes reset as being active-low and power-down as being
active-high. This works on a number of devices such as the mpman
converter 9. But it is wrong for the Chuwi Vi8 CWI501 where the powerdown
pin is active-low.

Rather then adding DMI quirks for this, add a helper for this,
which can be shared between sensor-drivers. This new helper optionally
also returns a string identifying the exact sensor-module used, which
might be useful if any module specific behvior is necessary in the sensor
driver.

This uses the DSM directly on the sensor device's ACPI node. This is
different from later Intel hardware (IPU3 / IPU6) which has a separate
INT3472 node (with its own driver) with this info.

Since there is no separate ACPI node to which we can bind to register GPIO
lookups, this unfortunately means that all sensor drivers which may be used
on BYT or CHT hw need to call this new helper.

Note for now this function is being added to atomisp_gmin_platform.c,
but once things are ready to move atomisp over to using generic sensor
drivers this will need to become a generic v4l2 sensor helper. but this
will require upstream discussion first.

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp: Put sensor ACPI devices in D3 before disable ACPI power-resources

The device core will call ACPI to turn the device (i2c_client) for a sensor
on / put it in D0 before calling its pro

media: atomisp: Put sensor ACPI devices in D3 before disable ACPI power-resources

The device core will call ACPI to turn the device (i2c_client) for a sensor
on / put it in D0 before calling its probe() method.

This takes a reference on all of the ACPI power-resources belonging to
the device. Since the atomisp_gmin_platform code disables ACPI
power-resource management and does its own pm, this reference never gets
released.

This is a problem for ACPI power-resources which are shared with other
devices since those now never get turned off again (nor back on again).

Explicitly put the device in D3 before disabling the ACPI power-resource
management.

Note that atomisp_register_i2c_module() runs near the end of the sensor
driver's probe() function, after the driver is done with probing the hw.
So the power-resouces (the same resources as directly controlled by
the atomisp platform code) getting turned off (a second time, as they are
already off) is not a problem.

Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp: Add atomisp_register_sensor_no_gmin() helper

The DSDT of all Windows BYT / CHT devices which I have seen has proper
ACPI powermagement for the clk and regulators used by the sensors.

media: atomisp: Add atomisp_register_sensor_no_gmin() helper

The DSDT of all Windows BYT / CHT devices which I have seen has proper
ACPI powermagement for the clk and regulators used by the sensors.

So there is no need for the whole custom atomisp_gmin custom code to
disable the ACPI pm and directly poke at the PMIC for this.

Add new atomisp_register_sensor_no_gmin() + atomisp_unregister_subdev()
helpers which allow registering a sensor with the atomisp code without
using any of the atomisp_gmin power-management code.

Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp: Remove atomisp_gmin_find_subdev()

atomisp_gmin_find_subdev() can be used to lookup a subdev
given its i2c-adapter + i2c-client-address.

But the only caller of it reads this from the

media: atomisp: Remove atomisp_gmin_find_subdev()

atomisp_gmin_find_subdev() can be used to lookup a subdev
given its i2c-adapter + i2c-client-address.

But the only caller of it reads this from the intel_v4l2_subdev_table
struct and that same struct already contains a pointer to the v4l2_subdev.

So this function is not necessary, drop it and modify its only caller
to directly take the subdev from the intel_v4l2_subdev_table struct.

Also drop struct intel_v4l2_subdev_i2c_board_info since that now no
longer is used.

Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp: Fix regulator registers on BYT devices with CRC PMIC

The Crystal Cove PMIC used on some BYT/CHT devices has different revisions
when paired with Bay Trail (BYT) vs Cherry Trail (CHT)

media: atomisp: Fix regulator registers on BYT devices with CRC PMIC

The Crystal Cove PMIC used on some BYT/CHT devices has different revisions
when paired with Bay Trail (BYT) vs Cherry Trail (CHT) SoCs.

The current hardcoded values are only valid for CHT devices, change
the code so that it uses the correct register values on both BYT and CHT.

Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp_gmin_platform: Unexport and split camera_sensor_csi()

The camera_sensor_csi() is not used outside the module, hence make it
static. While at it, split it to _alloc() and _free() to cl

media: atomisp_gmin_platform: Unexport and split camera_sensor_csi()

The camera_sensor_csi() is not used outside the module, hence make it
static. While at it, split it to _alloc() and _free() to clearly show
the idea behind the last parameter @flag that is passed to
gmin_csi_cfg().

Link: https://lore.kernel.org/r/20220730162027.1011-1-andriy.shevchenko@linux.intel.com

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp: Remove const/fixed camera_caps

The code checks a camera_caps struct in various places, but this always
points to the same const camera_caps struct.

Remove the checks, keeping the co

media: atomisp: Remove const/fixed camera_caps

The code checks a camera_caps struct in various places, but this always
points to the same const camera_caps struct.

Remove the checks, keeping the code paths which would be taken with
the fixed camera caps struct still in place and remove the camera_caps
struct itself.

Note this completely removes atomisp_pause_buffer_event() because that
only ever does something if camera_caps.sensors[0].is_slave is true and
that never is true.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp_gmin_platform: Switch to use acpi_evaluate_dsm_typed()

The acpi_evaluate_dsm_typed() provides a way to check the type of the
object evaluated by _DSM call. Use it instead of open code

media: atomisp_gmin_platform: Switch to use acpi_evaluate_dsm_typed()

The acpi_evaluate_dsm_typed() provides a way to check the type of the
object evaluated by _DSM call. Use it instead of open coded variant.

Link: https://lore.kernel.org/r/20220730155905.90091-1-andriy.shevchenko@linux.intel.com

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp_gmin_platform: stop abusing efivar API

As the code comment already suggests, using the efivar API in this way
is not how it is intended, and so let's switch to the right one, which
is

media: atomisp_gmin_platform: stop abusing efivar API

As the code comment already suggests, using the efivar API in this way
is not how it is intended, and so let's switch to the right one, which
is simply to call efi.get_variable() directly after checking whether or
not the GetVariable() runtime service is supported.

Link: https://lore.kernel.org/linux-media/20220620100819.1682995-1-ardb@kernel.org
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp_gmin_platform: stop abusing efivar API

As the code comment already suggests, using the efivar API in this way
is not how it is intended, and so let's switch to the right one, which
is

media: atomisp_gmin_platform: stop abusing efivar API

As the code comment already suggests, using the efivar API in this way
is not how it is intended, and so let's switch to the right one, which
is simply to call efi.get_variable() directly after checking whether or
not the GetVariable() runtime service is supported.

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

show more ...

media: atomisp_gmin_platform: Add DMI quirk to not turn AXP ELDO2 regulator off on some boards

The TrekStor SurfTab duo W1 10.1 has a hw bug where turning eldo2 back on
after having turned it off ca

media: atomisp_gmin_platform: Add DMI quirk to not turn AXP ELDO2 regulator off on some boards

The TrekStor SurfTab duo W1 10.1 has a hw bug where turning eldo2 back on
after having turned it off causes the CPLM3218 ambient-light-sensor on
the front camera sensor's I2C bus to crash, hanging the bus.

Add a DMI quirk table for systems on which to leave eldo2 on.

Note an alternative fix is to turn off the CPLM3218 ambient-light-sensor
as long as the camera sensor is being used, this is what Windows seems
to do as a workaround (based on analyzing the DSDT). But that is not
easy to do cleanly under Linux.

Link: https://lore.kernel.org/linux-media/20220116215204.307649-10-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp_gmin_platform: Base CsiPort default on detected CLK

On devices with 2 cameras and no _DSM / EFI-vars providing CsiPort
clock info, defaulting to CsiPort 0 obviously is wrong for 1 of

media: atomisp_gmin_platform: Base CsiPort default on detected CLK

On devices with 2 cameras and no _DSM / EFI-vars providing CsiPort
clock info, defaulting to CsiPort 0 obviously is wrong for 1 of the
2 cameras.

The Intel Cherry Trail (ISP2401) reference design combines:
pmc_plt_clk_2 with CsiPort 0
pmc_plt_clk_4 with CsiPort 1

The Intel Bay Trail (ISP2400) reference design combines:
pmc_plt_clk_1 with CsiPort 0
pmc_plt_clk_0 with CsiPort 1

Use this knowledge to set the default CsiPort value based on
the detected CLK for the sensor.

Link: https://lore.kernel.org/linux-media/20220116215204.307649-9-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp_gmin_platform: Do not turn ELDO2 off from axp_v1p8_on()

Fix axp_v1p8_on() turning ELDO2 off at the end again by removing the bogus
code which turns it off again after just having turn

media: atomisp_gmin_platform: Do not turn ELDO2 off from axp_v1p8_on()

Fix axp_v1p8_on() turning ELDO2 off at the end again by removing the bogus
code which turns it off again after just having turned it on.

Link: https://lore.kernel.org/linux-media/20220116215204.307649-8-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp_gmin_platform: Set ELDO1 to 1.6V on devices with an AXP288 PMIC

Testing on multiple tablet models has shown that Android always uses
1.6V for ELDO1, adjust our code to match.

This al

media: atomisp_gmin_platform: Set ELDO1 to 1.6V on devices with an AXP288 PMIC

Testing on multiple tablet models has shown that Android always uses
1.6V for ELDO1, adjust our code to match.

This also matches with how ELDO1 is used in the DSDTs on these devices,
where for Cherry Trail (ISP2401) based devices ELDO1 is used for an
ACPI power-resource which is named "P16P".

Note on Bay Trail (ISP2400) based devices the power-resource is called
"P15P", which suggests that 1.5V might be a better value there.

Link: https://lore.kernel.org/linux-media/20220116215204.307649-7-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp_gmin_platform: Add enable-count to gmin_[v1p8|v2p8]_ctrl()

On devices with 2 sensors the 2 sensors may get probed simultaneously
and the v1p8 and v2p8 regulators are ususally shared b

media: atomisp_gmin_platform: Add enable-count to gmin_[v1p8|v2p8]_ctrl()

On devices with 2 sensors the 2 sensors may get probed simultaneously
and the v1p8 and v2p8 regulators are ususally shared between the
2 sensors.

This means that the probe() function of sensor 1 may end up calling
gmin_v1p8_ctrl(..., false) turning the regulator off while sensor 2's
probe() function still needs it to be on, causing the probe() of
sensor 2 to sometimes fail.

Fix this by adding an enable-count for both regulators and only
disabling them again when that goes to 0.

Note all this really should be converted to use the standard kernel
regulator framework, I have doing this on my long term TODO list,
this fix is only meant as a temporary workaround for the issue.

Link: https://lore.kernel.org/linux-media/20220116215204.307649-6-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp_gmin_platform: Fix axp_regulator_set() writing to the wrong register

The second write done in axp_regulator_set() must go to the ctrl_reg which
turns the various regulators on/off. Th

media: atomisp_gmin_platform: Fix axp_regulator_set() writing to the wrong register

The second write done in axp_regulator_set() must go to the ctrl_reg which
turns the various regulators on/off. This replaces the second write
writing the sel_reg, which sets the voltage for the regulator, for a
second time with a wrong value.

Link: https://lore.kernel.org/linux-media/20220116215204.307649-5-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: atomisp: fix uninitialized bug in gmin_get_pmic_id_and_addr()

The "power" pointer is not initialized on the else path and that would
lead to an Oops.

Link: https://lore.kernel.org/linux-medi

media: atomisp: fix uninitialized bug in gmin_get_pmic_id_and_addr()

The "power" pointer is not initialized on the else path and that would
lead to an Oops.

Link: https://lore.kernel.org/linux-media/20211012082150.GA31086@kili
Fixes: c30f4cb2d4c7 ("media: atomisp: Refactor PMIC detection to a separate function")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...

media: atomisp: add Microsoft Surface 3 ACPI vars

Microsoft Surface 3 does not describe CsiPort/CsiLanes in DSDT [1] or
EFI, or at least not desctibed in the forms the current atomisp driver
expects

media: atomisp: add Microsoft Surface 3 ACPI vars

Microsoft Surface 3 does not describe CsiPort/CsiLanes in DSDT [1] or
EFI, or at least not desctibed in the forms the current atomisp driver
expects. This results in the default values (port: 0 lanes: 1) to be
used, which does not work.

So, define them ourselves in the driver.

The user-facing camera is AR0330 (2-lane) and the world-facing camera
is OV8835 (4-lane).

According to the portconfigs definition in atomisp_csi_lane_config()
[atomisp_v4l2.c]:

} portconfigs[] = {
/* Tangier/Merrifield available lane configurations */
{ 0x00, { 4, 1, 0 } }, /* 00000 */
{ 0x01, { 3, 1, 0 } }, /* 00001 */
{ 0x02, { 2, 1, 0 } }, /* 00010 */
{ 0x03, { 1, 1, 0 } }, /* 00011 */
{ 0x04, { 2, 1, 2 } }, /* 00100 */
{ 0x08, { 3, 1, 1 } }, /* 01000 */
{ 0x09, { 2, 1, 1 } }, /* 01001 */
{ 0x0a, { 1, 1, 1 } }, /* 01010 */

/* Anniedale/Moorefield only configurations */
{ 0x10, { 4, 2, 0 } }, /* 10000 */
{ 0x11, { 3, 2, 0 } }, /* 10001 */
{ 0x12, { 2, 2, 0 } }, /* 10010 */
{ 0x13, { 1, 2, 0 } }, /* 10011 */
{ 0x14, { 2, 2, 2 } }, /* 10100 */
{ 0x18, { 3, 2, 1 } }, /* 11000 */
{ 0x19, { 2, 2, 1 } }, /* 11001 */
{ 0x1a, { 1, 2, 1 } }, /* 11010 */
};

4-lane camera is always connected to the PRIMARY (port1) port [2]. In
this case, 2-lane camera can be connected to the only SECONDARY (port0)
port.

So, add these data accordingly as the gmin_cfg_var ACPI variables for
Surface 3.

[1] https://github.com/linux-surface/acpidumps/blob/7da48a392b4085c2021952290def1fc28505a643/surface_3/dsdt.dsl#L5879-L6278

[2] Yes, the PRIMARY port is port1 according to atomisp_camera_port
[atomisp.h]:

enum atomisp_camera_port {
ATOMISP_CAMERA_PORT_SECONDARY,
ATOMISP_CAMERA_PORT_PRIMARY,
ATOMISP_CAMERA_PORT_TERTIARY,
ATOMISP_CAMERA_NR_PORTS
};

Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...