linux.git/drivers/staging/media/atomisp, branch v5.19

media: atomisp: don't pass a pointer to a local variable

2022-05-13T09:02:20+00:00

As warned by gcc 12.1:

	drivers/staging/media/atomisp/pci/runtime/rmgr/src/rmgr_vbuf.c: In function 'ia_css_rmgr_acq_vbuf':
	drivers/staging/media/atomisp/pci/runtime/rmgr/src/rmgr_vbuf.c:275:33: error: storing the address of local variable 'h' in '*handle' [-Werror=dangling-pointer=]
	  275 |                         *handle = &h;
	      |                         ~~~~~~~~^~~~
	drivers/staging/media/atomisp/pci/runtime/rmgr/src/rmgr_vbuf.c:257:40: note: 'h' declared here
	  257 |         struct ia_css_rmgr_vbuf_handle h;
	      |                                        ^
	drivers/staging/media/atomisp/pci/runtime/rmgr/src/rmgr_vbuf.c:257:40: note: 'handle' declared here
	cc1: all warnings being treated as errors

The logic uses a temporary struct to update the handler, but,
instead of copying the value to the pointer sent by the caller, it
replaces it with the content with a local variable. That's wrong, and
may lead the caller to use a weird value.

Signed-off-by: Mauro Carvalho Chehab

media: atomisp: fix bad usage at error handling logic

2022-03-18T04:58:35+00:00

As warned by sparse:
	atomisp: drivers/staging/media/atomisp/pci/atomisp_acc.c:508 atomisp_acc_load_extensions() warn: iterator used outside loop: 'acc_fw'

The acc_fw interactor is used outside the loop, at the error handling
logic. On most cases, this is actually safe there, but, if
atomisp_css_set_acc_parameters() has an error, an attempt to use it
will pick an invalid value for acc_fw.

Reported-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: Kconfig: cleanup VIDEO_DEV dependencies

2022-03-18T04:58:35+00:00

media Kconfig has two entries associated to V4L API:
VIDEO_DEV and VIDEO_V4L2.

On Kernel 2.6.x, there were two V4L APIs, each one with its own flag.
VIDEO_DEV were meant to:
	1) enable Video4Linux and make its Kconfig options to appear;
	2) it makes the Kernel build the V4L core.

while VIDEO_V4L2 where used to distinguish between drivers that
implement the newer API and drivers that implemented the former one.

With time, such meaning changed, specially after the removal of
all V4L version 1 drivers.

At the current implementation, VIDEO_DEV only does (1): it enables
the media options related to V4L, that now has:

	menu "Video4Linux options"
		visible if VIDEO_DEV

	source "drivers/media/v4l2-core/Kconfig"
	endmenu

but it doesn't affect anymore the V4L core drivers.

The rationale is that the V4L2 core has a "soft" dependency
at the I2C bus, and now requires to select a number of other
Kconfig options:

	config VIDEO_V4L2
		tristate
		depends on (I2C || I2C=n) && VIDEO_DEV
		select RATIONAL
		select VIDEOBUF2_V4L2 if VIDEOBUF2_CORE
		default (I2C || I2C=n) && VIDEO_DEV

In the past, merging them would be tricky, but it seems that it is now
possible to merge those symbols, in order to simplify V4L dependencies.

Let's keep VIDEO_DEV, as this one is used on some make *defconfig
configurations.

Suggested-by: Laurent Pinchart 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Jacopo Mondi 
Reviewed-by: Neil Armstrong  # for meson-vdec & meson-ge2d
Acked-by: Andrzej Pietrasiewicz 
Acked-by: Łukasz Stelmach 
Signed-off-by: Mauro Carvalho Chehab

media: atomisp: fix dummy_ptr check to avoid duplicate active_bo

2022-02-08T06:31:33+00:00

The dummy_ptr check in hmm_init() [1] results in the following
"hmm_init Failed to create sysfs" error exactly once every
two times on atomisp reload by rmmod/insmod (although atomisp module
loads and works fine regardless of this error):

	[  140.230662] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:03.0/active_bo'
	[  140.230668] CPU: 1 PID: 2502 Comm: insmod Tainted: G         C OE     5.15.0-rc4-1-surface-mainline #1 b8acf6eb64994414b2e20bad312a7a2c45f748f9
	[  140.230675] Hardware name: OEMB OEMB/OEMB, BIOS 1.51116.238 03/09/2015
	[  140.230678] Call Trace:
	[  140.230687]  dump_stack_lvl+0x46/0x5a
	[  140.230702]  sysfs_warn_dup.cold+0x17/0x24
	[  140.230710]  sysfs_add_file_mode_ns+0x160/0x170
	[  140.230717]  internal_create_group+0x126/0x390
	[  140.230723]  hmm_init+0x5c/0x70 [atomisp 7a6a680bf400629363d2a6f58fd10e7299678b99]
	[  140.230811]  atomisp_pci_probe.cold+0x1136/0x148e [atomisp 7a6a680bf400629363d2a6f58fd10e7299678b99]
	[  140.230875]  local_pci_probe+0x45/0x80
	[  140.230882]  ? pci_match_device+0xd7/0x130
	[  140.230887]  pci_device_probe+0xfa/0x1b0
	[  140.230892]  really_probe+0x1f5/0x3f0
	[  140.230899]  __driver_probe_device+0xfe/0x180
	[  140.230903]  driver_probe_device+0x1e/0x90
	[  140.230908]  __driver_attach+0xc0/0x1c0
	[  140.230912]  ? __device_attach_driver+0xe0/0xe0
	[  140.230915]  ? __device_attach_driver+0xe0/0xe0
	[  140.230919]  bus_for_each_dev+0x89/0xd0
	[  140.230924]  bus_add_driver+0x12b/0x1e0
	[  140.230929]  driver_register+0x8f/0xe0
	[  140.230933]  ? 0xffffffffc153f000
	[  140.230937]  do_one_initcall+0x57/0x220
	[  140.230945]  do_init_module+0x5c/0x260
	[  140.230952]  load_module+0x24bd/0x26a0
	[  140.230962]  ? __do_sys_finit_module+0xae/0x110
	[  140.230966]  __do_sys_finit_module+0xae/0x110
	[  140.230972]  do_syscall_64+0x5c/0x80
	[  140.230979]  ? syscall_exit_to_user_mode+0x23/0x40
	[  140.230983]  ? do_syscall_64+0x69/0x80
	[  140.230988]  ? exc_page_fault+0x72/0x170
	[  140.230991]  entry_SYSCALL_64_after_hwframe+0x44/0xae
	[  140.230997] RIP: 0033:0x7f7fd5d8718d
	[  140.231003] Code: b4 0c 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d b3 6c 0c 00 f7 d8 64 89 01 48
	[  140.231006] RSP: 002b:00007ffefc25f0e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
	[  140.231012] RAX: ffffffffffffffda RBX: 000055ac3edcd7f0 RCX: 00007f7fd5d8718d
	[  140.231015] RDX: 0000000000000000 RSI: 000055ac3d723270 RDI: 0000000000000003
	[  140.231017] RBP: 0000000000000000 R08: 0000000000000000 R09: 00007f7fd5e52380
	[  140.231019] R10: 0000000000000003 R11: 0000000000000246 R12: 000055ac3d723270
	[  140.231021] R13: 0000000000000000 R14: 000055ac3edd06e0 R15: 0000000000000000
	[  140.231038] atomisp-isp2 0000:00:03.0: hmm_init Failed to create sysfs

The problem is that dummy_ptr == 0 is a valid value. So, change the logic
which checks if dummy_ptr was allocated.

At this point, atomisp now gives WARN_ON() in hmm_free() [2] on atomisp
reload by rmmod/insmod. Again, the check is wrong there.

So, change both checks for mmgr_EXCEPTION, which is the error value when
HMM allocation fails, and initialize dummy_ptr with such value.

[1] added on commit
    d9ab83953fa7 ("media: atomisp: don't cause a warn if probe failed")
[2] added on commit
    b83cc378dfc4 ("atomisp: clean up the hmm init/cleanup indirections")

Link: https://lore.kernel.org/linux-media/20211017162337.44860-3-kitakar@gmail.com

Signed-off-by: Tsuchiya Yuto 
Co-developed-by: Mauro Carvalho Chehab 
Signed-off-by: Mauro Carvalho Chehab

media: staging: media: atomisp: Use BIT macro instead of left shifting

2022-02-08T06:22:25+00:00

There is a BIT(nr) macro available in Linux Kernel,
which does the same thing.
Example: BIT(7) = (1UL << 7)

Link: https://lore.kernel.org/linux-media/20220206185232.21726-1-mosescb.dev@gmail.com

Signed-off-by: Moses Christopher Bollavarapu 
Signed-off-by: Mauro Carvalho Chehab

media: atomisp: make array idx_map static const

2022-02-08T06:21:32+00:00

Don't populate the read-only array idx_map on the stack but
instead it static const. Also makes the object code a little smaller.

Link: https://lore.kernel.org/linux-media/20220109195129.46118-1-colin.i.king@gmail.com

Signed-off-by: Colin Ian King 
Signed-off-by: Mauro Carvalho Chehab

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

2022-02-08T05:28:38+00:00

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 
Signed-off-by: Mauro Carvalho Chehab

media: atomisp_gmin_platform: Base CsiPort default on detected CLK

2022-02-08T05:28:38+00:00

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 
Signed-off-by: Mauro Carvalho Chehab

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

2022-02-08T05:28:38+00:00

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 
Signed-off-by: Mauro Carvalho Chehab

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

2022-02-08T05:28:38+00:00

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 
Signed-off-by: Mauro Carvalho Chehab