aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2021-11-10cec: copy sequence field for the replybr-v5.16afor-v5.16aHans Verkuil1-0/+1
When the reply for a non-blocking transmit arrives, the sequence field for that reply was never filled in, so userspace would have no way of associating the reply to the original transmit. Copy the sequence field to ensure that this is now possible. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: 0dbacebede1e ([media] cec: move the CEC framework out of staging and to media) Cc: <stable@vger.kernel.org>
2021-11-10media: videobuf2-dma-sg: Fix buf->vb NULL pointer dereferenceHans de Goede1-0/+2
Commit a4b83deb3e76 ("media: videobuf2: rework vb2_mem_ops API") added a new vb member to struct vb2_dma_sg_buf, but it only added code setting this to the vb2_dma_sg_alloc() function and not to the vb2_dma_sg_get_userptr() and vb2_dma_sg_attach_dmabuf() which also create vb2_dma_sg_buf objects. This is causing a crash due to a NULL pointer deref when using libcamera on devices with an Intel IPU3 (qcam app). Fix these crashes by assigning buf->vb in the other 2 functions too, note libcamera tests the vb2_dma_sg_get_userptr() path, the change to the vb2_dma_sg_attach_dmabuf() path is untested. Fixes: a4b83deb3e76 ("media: videobuf2: rework vb2_mem_ops API") Cc: Sergey Senozhatsky <senozhatsky@chromium.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-11-10media: v4l2-core: fix VIDIOC_DQEVENT handling on non-x86Arnd Bergmann1-24/+17
My previous bugfix addressed an API inconsistency found by syzbot, and it correctly fixed the issue on x86-64 machines, which now behave correctly for both native and compat tasks. Unfortunately, John found that the patch broke compat mode on all other architectures, as they can no longer rely on the VIDIOC_DQEVENT_TIME32 code from the native handler as a fallback in the compat code. The best way I can see for addressing this is to generalize the VIDIOC_DQEVENT32_TIME32 code from x86 and use that for all architectures, leaving only the VIDIOC_DQEVENT32 variant as x86 specific. The original code was trying to be clever and use the same conversion helper for native 32-bit code and compat mode, but that turned out to be too obscure so even I missed that bit I had introduced myself when I made the fix. Fixes: c344f07aa1b4 ("media: v4l2-core: ignore native time32 ioctls on 64-bit") Reported-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-11-06media: atomisp: register first the preview devnodeMauro Carvalho Chehab1-7/+9
The atomisp currenyl registers 5 pairs of devices each one for one different run_mode, plus one for "ACC". The only one that behaves like a normal V4L2 device is the preview one. The others are doing weird things, and perhaps are using some proprietary extensions to the API. Change the device order to start with the preview one, e. g: /dev/video0: ATOMISP ISP PREVIEW output /dev/video1: ATOMISP ISP CAPTURE output /dev/video2: ATOMISP ISP VIEWFINDER output /dev/video3: ATOMISP ISP VIDEO output /dev/video4: ATOMISP ACC This way, a normal V4L2 application will get the right device, as the first one will be the one they should use. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: set per-device's default modeMauro Carvalho Chehab5-7/+23
The atomisp driver originally used the s_parm command to initialize the run_mode type to the driver. So, before start setting up the streaming, s_parm should be called. So, even having 5 "normal" video devices, one meant to be used for each type, the run_mode was actually selected when s_parm is called. Without setting the run mode, applications that don't call VIDIOC_SET_PARM with a custom atomisp parameters won't work, as the pipeline won't be set: atomisp-isp2 0000:00:03.0: can't create streams atomisp-isp2 0000:00:03.0: __get_frame_info 1600x1200 (padded to 0) returned -22 However, commit 8a7c5594c020 ("media: v4l2-ioctl: clear fields in s_parm") broke support for it, with a good reason, as drivers shoudn't be extending the API for their own purposes. So, as an step to allow generic apps to use this driver, put the device's run_mode in preview after open. After this patch, using v4l2grab starts to work on preview mode (/dev/video2): $ v4l2grab -f YUYV -x 1600 -y 1200 -d /dev/video2 -n 1 -u $ feh out000.pnm So, let's just setup the default run_mode that each video devnode should assume, setting it at open() time. Reported-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: get rid of ISP2401_NEW_INPUT_SYSTEMMauro Carvalho Chehab5-26/+17
All ISP2401 devices use the new input system. So, get rid of the remaining definitions, replacing them by runtime checks for BYT/CHT when applicable. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: return errors from ia_css_dma_configure_from_info()Mauro Carvalho Chehab11-27/+78
Now that the pipeline config functions can return errors, change ia_css_dma_configure_from_info() and callers in order for them to return errors at pipelines instead of using assert(). Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: add return codes for pipeline config functionsMauro Carvalho Chehab23-129/+87
Those functions can internally break, but, as they don't return errors, internally there are some assert() calls, which is bad, as it hangs the driver. So, add return codes there, in preparation for removing such assert() calls. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: sh_css_sp: better handle pipeline config errorsMauro Carvalho Chehab1-20/+46
If something gets wrong while setup a pipeline, return an error code. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: propagate errors at ia_css_*_configure()Mauro Carvalho Chehab20-126/+82
Propagate the lower lever ia_css config errors to the next level. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: cleanup ia_css_isp_configs() codeMauro Carvalho Chehab2-406/+284
The auto-generated code inside ia_css_isp_configs() is more complex than it should be. Also, it doesn't return any errors. However, the functions called by it can mis-configure the pipelines, but, as there's no way to return errors, it internally calls the assert() macro. So, add a return parameter to each routine there, in order to prepare the code to be more robust. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: unify ia_css_isp_params.cMauro Carvalho Chehab3-3429/+3
The contents of ia_css_isp_params.c is almost identical for 2400 and 2401. The only difference is that, on 2400, there are some duplicated assignments. So, drop it, unifying this file. While here, simplify the Makefile's logic by dropping an unused define. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: drop duplicated ia_css_isp_states.cMauro Carvalho Chehab3-227/+2
Both 2400 and 2401 have this file, but they're identical. So, drop one of them. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: drop duplicated ia_css_isp_configs.cMauro Carvalho Chehab3-388/+1
Both 2400 and 2401 have this file, but they're identical. So, drop one of them. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: allocate a v4l2_fh at open timeMauro Carvalho Chehab1-1/+9
This avoids an OOPS when VIDIOC_*_PRIORITY calls are used. [ 90.820011] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 90.820021] #PF: supervisor read access in kernel mode [ 90.820026] #PF: error_code(0x0000) - not-present page [ 90.820030] PGD 1221bc067 P4D 1221bc067 PUD 1221bd067 PMD 0 [ 90.820042] Oops: 0000 [#1] SMP [ 90.820048] CPU: 0 PID: 2007 Comm: qv4l2 Tainted: G C 5.15.0-rc4+ #77 [ 90.820055] Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.306 04/23/2019 [ 90.820059] RIP: 0010:v4l2_prio_change+0xf/0x40 [videodev] [ 90.820096] Code: 48 8b 47 20 8b 40 44 25 ff ff 0f 00 48 8b 04 c5 20 58 44 c0 c3 66 0f 1f 44 00 00 0f 1f 44 00 00 8d 42 ff 83 f8 02 77 21 31 c0 <39> 16 74 20 8d 02 f0 ff 04 87 8b 06 89 c1 83 e9 01 83 f9 02 77 04 [ 90.820103] RSP: 0018:ffffb348c142fd70 EFLAGS: 00010246 [ 90.820109] RAX: 0000000000000000 RBX: ffff95575fbe2760 RCX: ffffb348c142fe48 [ 90.820114] RDX: 0000000000000002 RSI: 0000000000000020 RDI: ffff955740996088 [ 90.820118] RBP: 0000000040045644 R08: ffffffffc070da80 R09: 0000000000004000 [ 90.820122] R10: 0000000000000000 R11: 0000000000000000 R12: ffff955766725300 [ 90.820126] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000044 [ 90.820131] FS: 00007f848526b900(0000) GS:ffff9557bbe00000(0000) knlGS:0000000000000000 [ 90.820137] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 90.820141] CR2: 0000000000000020 CR3: 00000001221bf000 CR4: 00000000001006f0 [ 90.820146] Call Trace: [ 90.820155] __video_do_ioctl+0x37d/0x3b0 [videodev] [ 90.820189] video_usercopy+0x188/0x7a0 [videodev] [ 90.820218] ? v4l_print_control+0x20/0x20 [videodev] [ 90.820247] ? swake_up_one+0x39/0x70 [ 90.820258] ? rcu_core+0xff/0x2e0 [ 90.820267] ? sched_clock_cpu+0x9/0xa0 [ 90.820275] ? irqtime_account_irq+0x38/0xb0 [ 90.820282] v4l2_ioctl+0x46/0x50 [videodev] Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp-mt9m114: use v4l2_find_nearest_size()Mauro Carvalho Chehab1-115/+15
Instead of reinventing the wheel, use v4l2_find_nearest_size() in order to get the closest resolution. This should address a bug where the wrong resolution was selected. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp-gc2235: use v4l2_find_nearest_size()Mauro Carvalho Chehab2-96/+20
Instead of reinventing the wheel, use v4l2_find_nearest_size() in order to get the closest resolution. This should address a bug where the wrong resolution was selected. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp-gc0310: use v4l2_find_nearest_size()Mauro Carvalho Chehab2-100/+22
Instead of reinventing the wheel, use v4l2_find_nearest_size() in order to get the closest resolution. This should address a bug where the wrong resolution was selected. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp-ov2722: use v4l2_find_nearest_size()Mauro Carvalho Chehab2-99/+22
Instead of reinventing the wheel, use v4l2_find_nearest_size() in order to get the closest resolution. This should address a bug where the wrong resolution was selected. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp-ov2680: use v4l2_find_nearest_size()Mauro Carvalho Chehab2-105/+25
Instead of reinventing the wheel, use v4l2_find_nearest_size() in order to get the closest resolution. This should address a bug where the wrong resolution was selected. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: fix g_fmt logicMauro Carvalho Chehab1-57/+7
The g_fmt logic is currently broken, as it is not returning the same imagesize as previoulsy calculated by s_fmt. Fix it by just re-using whatever it was defined at s_fmt, if this was called before. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: fix try_fmt logicMauro Carvalho Chehab2-8/+71
The internal try_fmt logic is not meant to provide everything that the V4L2 API should provide. Also, it doesn't decrement the pads that are used only internally by the driver, but aren't part of the device's output. Fix it. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: move atomisp_g_fmt_cap()Mauro Carvalho Chehab1-28/+28
move atomisp_g_fmt_cap() for it to be after try_fmt, as we'll re-use try_fmt there. No functional changes. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: fix enum_fmt logicMauro Carvalho Chehab1-4/+5
Currently, the enum lists the sensor's native format as a supported format. However, trying to setup a pipeline using it doesn't work. So, exclude such formats from the enum. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: fix VIDIOC_S_FMT logicMauro Carvalho Chehab1-2/+44
There are several issues on S_FMT implementation: - it doesn't properly handle pad_h/pad_w; - it reports a wrong visible size to userspace; - it allows setting the format to a raw mode, which currently causes the pipeline to break. Address such issues, for it to start working with generic apps. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: move a debug printf to a better placeMauro Carvalho Chehab1-2/+4
The sensor width/height report is alread being printed after its calculus. The only reason for an extra debug printk is when dis is used. So, change its message to reflect and move it to be inside the if checks. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: align sizes returned by g_fmtMauro Carvalho Chehab1-2/+2
Repeat the same round logic used inside s_fmt here, for the sake of sanity. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: TODO: make it updated to the current issuesMauro Carvalho Chehab1-65/+126
Now that this driver starting to show signals of real progress, let's update its TODO list. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: add a default case at __get_frame_info()Mauro Carvalho Chehab1-0/+2
The switch() logic there misses a break and a default case. That makes it more prone to problems as the code change. Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: staging: max96712: Add basic support for MAX96712 GMSL2 deserializerNiklas Söderlund6-0/+464
Add basic support for Maxim MAX96712 quad GMSL2 deserializers. The driver is capable of powering on the device and configuring the MIPI CSI-2 bus in a DPHY 4-lane configuration as well as operating the internal VTG (Video Timing Generator) and VPG (Video Pattern Generator). Using these features the driver is able to act as a 1080p @ 30 fps V4L2 video source. Producing either a checkerboard or gradient pattern on the CSI-2 bus, selectable thru a V4L2 control. While the driver is useful as-is and have been used to prove the correct operation of the MAX96712 itself and "downstream" devices using the MAX96712 as a video source there are a lot of features missing. Most notably the ability to operate the GMSL bus. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: comment-out JPEG formatMauro Carvalho Chehab2-4/+5
This is already disabled on some parts of the code, and trying to use it with current firmware causes an error: [ 53.799946] atomisp-isp2 0000:00:03.0: can't create streams [ 53.799962] atomisp-isp2 0000:00:03.0: __get_frame_info 1600x900 (padded to 0) returned -22 So, completely disable reporting it. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: report the visible resolutionMauro Carvalho Chehab1-0/+14
The atomisp sensors and logic adds an extra pad lines/columns, called "dvs envelope". It also uses an extra 12 lines/columns at the sensor for BYT. As those are not visible to userspace, the V4L2 API should decrement such values when reporting the current resolution. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: don't print errors for ignored MBUS formatsMauro Carvalho Chehab1-2/+0
The bayer formats aren't currently available for userspace to select: those are marked as IA_CSS_FRAME_FORMAT_RAW and trying to get them result on binary firmware load errors: [74625.258097] atomisp-isp2 0000:00:03.0: Using binary isp_preview_var_isp2 (id 22), type 0, mode 1, continuous true [74625.258146] atomisp-isp2 0000:00:03.0: Seeking for binary failed at: [74625.258161] CPU: 3 PID: 2792 Comm: v4l2grab Tainted: G C 5.15.0-rc4+ #77 [74625.258190] Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.306 04/23/2019 [74625.258208] Call Trace: [74625.258231] dump_stack_lvl+0x46/0x5a [74625.258272] ia_css_binary_find+0xa7d/0xcf0 [atomisp] [74625.258570] load_preview_binaries+0x323/0x3c0 [atomisp] ... [74625.265892] atomisp-isp2 0000:00:03.0: can't create streams [74625.265937] atomisp-isp2 0000:00:03.0: __get_frame_info 1604x1200 (padded to 0) returned -22 [74625.265962] atomisp-isp2 0000:00:03.0: Can't set format on ISP. Error -22 As those formats are ignored by purpose, it doesn't make any sense to print a message like: atomisp_enum_fmt_cap(): format for code 3007 not found. for those. Yet, some day it would be interesting to also report the bayer formats, letting userspace to decode them on a different way. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: report colorspace informationMauro Carvalho Chehab2-0/+23
While different sensors could have different colorspaces, the colorspace V4L2 support didn't exist by the time atomisp driver was written. So, the sensors won't have any data about that. So, let's report what Asus T101HA uses (ov2680 sensor). It may require further changes, if other sensors used on this driver have different colorspaces. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-06media: atomisp: properly implement g_fmtMauro Carvalho Chehab3-16/+45
The current logic only initializes pipe->pix after setting up a pipeline - e. g. after start streaming. While it makes sense to get the format of the pipeline, when it is set, this breaks support for generic applications, as they rely on getting the current sensor format (which is usually the highest resolution format). So, implement a call to the sensor's get_fmt, when this is called before setting up a pipeline. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-02media: atomisp: better describe get_frame_info issuesMauro Carvalho Chehab2-33/+40
When atomisp is used by a normal client, it fails to get frame info. However, the information is confusing and misleading, as there are several wrappers for such function, and the error could be on different places. So, improve the error log in order to allow narrowing down where the error is actually occuring. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-02media: atomisp: fix enum formats logicMauro Carvalho Chehab1-6/+17
Changeset 374d62e7aa50 ("media: v4l2-subdev: Verify v4l2_subdev_call() pad config argument") added an extra verification for a pads parameter for enum mbus format code. Such change broke atomisp, because now the V4L2 core refuses to enum MBUS formats if the state is empty. So, add .which field in order to select the active formats, in order to make it work again. While here, improve error messages. Fixes: 374d62e7aa50 ("media: v4l2-subdev: Verify v4l2_subdev_call() pad config argument") Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-02media: atomisp: add NULL check for asd obtained from atomisp_video_pipeTsuchiya Yuto3-0/+169
This is almost a BUG report with RFC patch that just avoids kernel oopses. Thus, prefixed with [BUG][RFC]. Here is the kernel log after running `v4l2-compliance -d /dev/video4` with this patch applied: kern :err : [25507.580392] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible) kern :warn : [25507.592343] isys dma store at addr(0xcd408) val(0) kern :err : [25507.592995] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.593685] atomisp-isp2 0000:00:03.0: atomisp_g_input(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.593719] atomisp-isp2 0000:00:03.0: atomisp_g_parm(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.593727] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC [omitting 42 same messages] kern :err : [25507.593976] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.594191] atomisp-isp2 0000:00:03.0: atomisp_g_input(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.594449] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC [omitting 43 same messages] kern :err : [25507.594756] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.594779] atomisp-isp2 0000:00:03.0: atomisp_g_ctrl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.594787] atomisp-isp2 0000:00:03.0: atomisp_s_ctrl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.594803] atomisp-isp2 0000:00:03.0: atomisp_camera_g_ext_ctrls(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.594880] atomisp-isp2 0000:00:03.0: atomisp_enum_fmt_cap(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.594915] atomisp-isp2 0000:00:03.0: atomisp_g_parm(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.595058] atomisp-isp2 0000:00:03.0: atomisp_try_fmt(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.595089] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.595124] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.595221] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.595241] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.601571] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible) kern :warn : [25507.607496] isys dma store at addr(0xcd408) val(0) kern :err : [25507.608604] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.611988] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible) kern :warn : [25507.617420] isys dma store at addr(0xcd408) val(0) kern :err : [25507.618429] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.618811] atomisp-isp2 0000:00:03.0: atomisp_g_parm(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.622193] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible) kern :warn : [25507.627355] isys dma store at addr(0xcd408) val(0) kern :err : [25507.628391] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.631143] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible) kern :warn : [25507.635813] isys dma store at addr(0xcd408) val(0) kern :err : [25507.636489] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.636504] atomisp-isp2 0000:00:03.0: atomisp_s_input(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.636516] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.639111] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible) kern :warn : [25507.646152] isys dma store at addr(0xcd408) val(0) kern :err : [25507.646831] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.646847] atomisp-isp2 0000:00:03.0: atomisp_s_input(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.650079] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible) kern :warn : [25507.657476] isys dma store at addr(0xcd408) val(0) kern :err : [25507.658741] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.658759] atomisp-isp2 0000:00:03.0: atomisp_s_input(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.658771] atomisp-isp2 0000:00:03.0: atomisp_set_fmt(): asd is NULL, device is ATOMISP ISP ACC kern :err : [25507.660959] atomisp-isp2 0000:00:03.0: can't change power state from D3cold to D0 (config space inaccessible) kern :warn : [25507.666665] isys dma store at addr(0xcd408) val(0) kern :err : [25507.667397] atomisp-isp2 0000:00:03.0: atomisp_queryctl(): asd is NULL, device is ATOMISP ISP ACC [mchehab: fix coding style] Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-02media: atomisp: Fix up the open v load raceAlan3-0/+29
Date: Mon, 06 Nov 2017 23:36:36 +0000 This isn't the ideal final solution but it stops the main problem for now where an open (often from udev) races the device initialization and we try and load the firmware twice at the same time. This needless to say doesn't usually end well. [kitakar: ported to upstream Kernel] [mchehab: make comments to use our coding style] Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-02media: atomisp: add Microsoft Surface 3 ACPI varsTsuchiya Yuto1-0/+19
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>
2021-11-02media: atomisp: pci: release_version is now ↵Tsuchiya Yuto5-19/+1
irci_stable_candrpv_0415_20150521_0458 Now that we made atomisp work with firmware version irci_stable_candrpv_0415_20150521_0458 also for ISP2401, the release_version for ISP2401 is not irci_ecr-master_20150911_0724 anymore. So, use the same release_version for both ISP2400 and ISP2401 (i.e., irci_stable_candrpv_0415_20150521_0458). Referred to the following diff to make this patch: - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/staging/media/atomisp/pci/sh_css_firmware.c?id=3c0538fbad9f1d07d588f631e380256d941e3d3a ("media: atomisp: get rid of most checks for ISP2401 version") changes for file sh_css_firmware.c Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-02media: atomisp: make fw ver irci_stable_candrpv_0415_20150521_0458 workTsuchiya Yuto2-26/+0
This patch removes the unnamed struct `shading` from `struct sh_css_sp_pipeline` as well as its usage [1]. [1] added on updating css version to irci_master_20150701_0213 https://raw.githubusercontent.com/intel/ProductionKernelQuilts/cht-m1stable-2016_ww31/uefi/cht-m1stable/patches/cam-0439-atomisp2-css2401-and-2401_legacy-irci_master_2015070.patch ("atomisp2: css2401 and 2401_legacy-irci_master_20150701_0213") This patch, together with the 4 patches applied before it revert incompatible changes in the current css version for ISP2401 (irci_ecr-master_20150911_0724) back to irci_stable_candrpv_0415_20150521_0458. Some `struct`s are `sizeof()`ed in sh_css_firmware.c file. So, I guess issues will happen if these sizes are changed. Therefore, keep them the same as css version irci_stable_candrpv_0415_20150521_0458 to make atomisp work for firmware made for such css version since we don't have firmware made for the current css version. Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-02media: atomisp: remove polling_mode and subscr_indexTsuchiya Yuto3-35/+2
This patch removes polling_mode and subscr_index from `struct virtual_input_system_stream_s` as well as its usage [1]. Note that for subscr_index, only the definition were removed because it was not used anywhere. [1] added on updating css version to irci_master_20150701_0213 https://raw.githubusercontent.com/intel/ProductionKernelQuilts/cht-m1stable-2016_ww31/uefi/cht-m1stable/patches/cam-0439-atomisp2-css2401-and-2401_legacy-irci_master_2015070.patch ("atomisp2: css2401 and 2401_legacy-irci_master_20150701_0213") Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-02media: atomisp: remove struct ia_css_isp_parameter xnr3Tsuchiya Yuto2-26/+0
This patch removes `struct ia_css_isp_parameter xnr3` from `struct ia_css_memory_offsets` as well as its usage [1]. [1] added on updating css version to irci_master_20150701_0213 https://raw.githubusercontent.com/intel/ProductionKernelQuilts/cht-m1stable-2016_ww31/uefi/cht-m1stable/patches/cam-0439-atomisp2-css2401-and-2401_legacy-irci_master_2015070.patch ("atomisp2: css2401 and 2401_legacy-irci_master_20150701_0213") Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-02media: atomisp: remove struct ia_css_isp_parameterTsuchiya Yuto5-127/+0
This patch removes `struct ia_css_isp_parameter sc` from `struct ia_css_config_memory_offsets` as well as its usage [1]. [1] added on updating css version to irci_master_20150701_0213 https://raw.githubusercontent.com/intel/ProductionKernelQuilts/cht-m1stable-2016_ww31/uefi/cht-m1stable/patches/cam-0439-atomisp2-css2401-and-2401_legacy-irci_master_2015070.patch ("atomisp2: css2401 and 2401_legacy-irci_master_20150701_0213") Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-02media: atomisp: drop luma_only, input_yuv and input_raw from ISP2401Tsuchiya Yuto5-28/+0
This patch removes luma_only, input_yuv and input_raw from `struct ia_css_binary_info` as well as its usage [1]. Note that for input_yuv and input_raw, only the definitions were removed because these were not used anywhere. [1] added on updating css version to irci_master_20150701_0213 https://raw.githubusercontent.com/intel/ProductionKernelQuilts/cht-m1stable-2016_ww31/uefi/cht-m1stable/patches/cam-0439-atomisp2-css2401-and-2401_legacy-irci_master_2015070.patch ("atomisp2: css2401 and 2401_legacy-irci_master_20150701_0213") Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-02media: atomisp: fix ifdefs in sh_css.cTsuchiya Yuto1-16/+11
## `if (pipe->stream->config.mode == IA_CSS_INPUT_MODE_TPG) {` case The intel-aero atomisp has `#if defined(IS_ISP_2400_SYSTEM)` [1]. It is to be defined in the following two places [2]: - css/hive_isp_css_common/system_global.h - css/css_2401_csi2p_system/system_global.h and the former file is to be included on ISP2400 devices, too. So, it is to be defined for both ISP2400 and ISP2401 devices. Because the upstreamed atomisp driver now supports only ISP2400 and ISP2401, just remove the ISP version test again. This matches the other upstream commits like 3c0538fbad9f ("media: atomisp: get rid of most checks for ISP2401 version"). While here, moved the comment for define GP_ISEL_TPG_MODE to the appropriate place. [1] https://github.com/intel-aero/linux-kernel/blob/a1b673258feb915268377275130c5c5df0eafc82/drivers/media/pci/atomisp/css/sh_css.c#L552-L558 [2] https://github.com/intel-aero/linux-kernel/search?q=IS_ISP_2400_SYSTEM ## `isys_stream_descr->polling_mode` case This does not exist on the intel-aero atomisp. This is because it is based on css version irci_stable_candrpv_0415_20150521_0458. On the other hand, the upstreamed atomisp is based on the following css version depending on the ISP version using ifdefs: - ISP2400: irci_stable_candrpv_0415_20150521_0458 - ISP2401: irci_master_20150911_0724 The `isys_stream_descr->polling_mode` usage was added on updating css version to irci_master_20150701_0213 [3]. So, it is not a ISP version specific thing, but css version specific thing. Because the upstreamed atomisp driver uses irci_master_20150911_0724 for ISP2401, re-add the ISP version check for now. I say "for now" because ISP2401 should eventually use the same css version with ISP2400 (i.e., irci_stable_candrpv_0415_20150521_0458) [3] https://raw.githubusercontent.com/intel/ProductionKernelQuilts/cht-m1stable-2016_ww31/uefi/cht-m1stable/patches/cam-0439-atomisp2-css2401-and-2401_legacy-irci_master_2015070.patch ("atomisp2: css2401 and 2401_legacy-irci_master_20150701_0213") Link to Intel's Android kernel patch. ## `coord = &me->config.internal_frame_origin_bqs_on_sctbl;` case it was added on commit 4f744a573db3 ("media: atomisp: make sh_css_sp_init_pipeline() ISP version independent") for ISP2401. Because the upstreamed atomisp for the ISP2401 part is based on irci_master_20150911_0724, hence the difference. Because the upstreamed atomisp driver uses irci_master_20150911_0724 for ISP2401, revert the test back to `if (IS_ISP2401)`. Fixes: 27333dadef57 ("media: atomisp: adjust some code at sh_css that could be broken") Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-02media: atomisp: use IA_CSS_ERROR() for error messages in sh_css_mipi.cTsuchiya Yuto1-19/+13
Some debug messages for error cases (messages contain "error: ") use IA_CSS_DEBUG_TRACE_PRIVATE debug level. This causes these error messages not to appear unless users raise debug output level to 7 or higher (using module parameter, dbg_level=7). So, use IA_CSS_DEBUG_ERROR debug level (dbg_level=1) instead considering that these are error messages. There is already a macro IA_CSS_ERROR() for this use case. Let's use it. It automatically appends "error: " at the beginning and a newline to a message. Therefore, we can remove them from these messages. While here, remove the unnecessary newline from one IA_CSS_ERROR() occurrence in the same file. Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-02media: atomisp: fix inverted error check for ia_css_mipi_is_source_port_valid()Tsuchiya Yuto1-9/+15
The function ia_css_mipi_is_source_port_valid() returns true if the port is valid. So, we can't use the existing err variable as is. To fix this issue while reusing that variable, invert the return value when assigning it to the variable. Fixes: 3c0538fbad9f ("media: atomisp: get rid of most checks for ISP2401 version") Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-02media: atomisp: do not use err var when checking port validity for ISP2400Tsuchiya Yuto1-3/+6
Currently, the `port >= N_CSI_PORTS || err` checks for ISP2400 are always evaluated as true because the err variable is set to `-EINVAL` on declaration but the variable is never used until the evaluation. Looking at the diff of commit 3c0538fbad9f ("media: atomisp: get rid of most checks for ISP2401 version"), the `port >= N_CSI_PORTS` check is for ISP2400 and the err variable check is for ISP2401. Fix this issue by adding ISP version test there accordingly. Fixes: 3c0538fbad9f ("media: atomisp: get rid of most checks for ISP2401 version") Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Privacy Policy