- 08 Jul, 2022 40 commits
-
-
Laurent Pinchart authored
Rename all the functions and macros imported from imx-media-capture.c with a consistent imx7_csi_video_ prefix. No functional change intended. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Rui Miguel Silva <rmfrfs@gmail.com> Tested-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Laurent Pinchart authored
Merge the capture_priv fields in the imx7_csi structure as there's no more need to have two separate structures. Update all the users accordingly. Signed-off-by:
-
Laurent Pinchart authored
The struct imx7_csi fields are in a random order, reorganize them logically to prepare for adding new fields. Signed-off-by:
-
Laurent Pinchart authored
Drop the unused control handler from the driver. Signed-off-by:
-
Laurent Pinchart authored
Drop all the code related to the unused (by this driver) legacy video device support. Signed-off-by:
-
Laurent Pinchart authored
To prepare for code refactoring, copy the video device helper code used by this driver verbatim from imx-media-capture. Rename some functions to avoid name clashes, and leave the legacy ioctls out as they're not used by the imx7-media-csi driver. No functional change included. Signed-off-by:
-
Paul Elder authored
imx_media_of_add_csi() from imx-media-of.c validates that the fwnode for the CSI bridge is enabled, and adds the fwnode to the async notifier of the imxmd. The former is redundant, as if the CSI bridge driver probes, clearly it is enabled in the DT. The latter is not needed as the imxmd notifier isn't used anymore. The call is thus not needed and can be dropped. This removes the dependency of imx7-media-csi.c on imx-media-of.c. Signed-off-by:
Paul Elder <paul.elder@ideasonboard.com> Acked-by:
-
Laurent Pinchart authored
There's no need to wait until the subdev is registered to initialize the active pad formats. Do so at probe time. Signed-off-by:
-
Laurent Pinchart authored
The frame_interval field of the imx7_csi structure is set but never used. Drop it. Signed-off-by:
-
Laurent Pinchart authored
The imx_media_dev framework maintains a per-pad list of connected video devices, created once all subdevs have been bound. This is used for two purposes, updating V4L2 control inheritance when links change, and relaying subdev events to video nodes. None of these are used by the imx7-media-csi driver as it implements the MC-centric approach. Drop them. Signed-off-by:
-
Paul Elder authored
There is a chunk of miscellaneous initializations related to the CSI subdev and media pads directly in the probe function. Move them into the imx7_csi_media_init() function to clean up the probe function. Signed-off-by:
-
Laurent Pinchart authored
The V4L2 async notifier embedded in the imx_media_dev structure is triggered when the CSI bridge subdev is registered. We don't need an async notifier for this, as we can call the .complete() handler directly from the CSI bridge subdev .registered() handler. Signed-off-by:
-
Laurent Pinchart authored
The imx_media_create_csi2_links() creates a media controller link between the CSI-2 receiver and the next entity in the pipeline, which can be either a video mux (handled by the video-mux driver) or the CSI bridge itself. This isn't needed, as the link is already created either by the video-mux driver or by the imx7-media-csi driver itself (in imx7_csi_notify_bound()). Drop imx_media_create_csi2_links(), which allows dropping the CSI bridge subdev grp_id. Signed-off-by:
-
Laurent Pinchart authored
To prepare for code refactoring, copy the V4L2 async notifier helper code used by this driver verbatim from imx-media-dev-common.c. Rename some functions to avoid name clashes. No functional change included. Signed-off-by:
-
Laurent Pinchart authored
Prepare for the decoupling of the imx7-media-csi driver from the IPUv3-based drivers by moving the imx_media_dev handling from probe() function to separate functions. Signed-off-by:
-
Laurent Pinchart authored
Group all the direct initialization of imx7_csi fields at the beginning of the imx7_csi_probe() function instead of spreading them around. Signed-off-by:
-
Laurent Pinchart authored
The device_driver structure's of_match_table field exists unconditionally, so there's no need for of_match_ptr(). This fixes a compiler warning when test-compiling on non-OF platforms: drivers/media/platform/renesas/rcar_drif.c:1470:34: warning: unused variable 'rcar_drif_of_table' [-Wunused-const-variable] static const struct of_device_id rcar_drif_of_table[] = { ^ Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Jiang Jian authored
There is an unexpected word 'with' in the comments that need to be dropped. Signed-off-by:
Jiang Jian <jiangjian@cdjrlc.com> Signed-off-by:
-
Marek Vasut authored
The .open subdev op is not always called soon enough to initialize the default crop settings. Move all this initialization into .init_cfg op instead. Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Marek Vasut authored
Add compatible for MT9P006 sensor, which is older variant of MT9P031 and compatible with this driver. Signed-off-by:
-
Marek Vasut authored
Add compatible for MT9P006 sensor, which is older variant of MT9P031 and compatible with this driver. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Li zeming authored
Remove the repeated ',' from string Link: https://lore.kernel.org/linux-media/20220704022807.3215-1-zeming@nfschina.comSigned-off-by:
Li zeming <zeming@nfschina.com> Signed-off-by:
-
Colin Ian King authored
There is a for-loop that initializes variable i but does not use it; the assignment is redundant and can be removed. The proceeding assignment to pointer fw can also be moved into the for-loop to clean up the code. Link: https://lore.kernel.org/linux-media/20220628152451.184416-1-colin.i.king@gmail.comSigned-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Karthik Alapati authored
fix a coccinelle warning by replacing opencoded max() implementation with max() WARNING opportunity for max() Link: https://lore.kernel.org/linux-media/YrNFpF2qvTxpZP8e@karthik-strix-linux.karthek.comSigned-off-by:
Karthik Alapati <mail@karthek.com> Signed-off-by:
-
Jiang Jian authored
Remove the repeated word 'and' from comments file: drivers/staging/media/atomisp/pci/hive_isp_css_include/host/debug_public.h line: 28 * The buffer has a remote and and a local store changed to: * The buffer has a remote and a local store Link: https://lore.kernel.org/linux-media/20220622143442.16942-1-jiangjian@cdjrlc.comSigned-off-by:
-
Ard Biesheuvel authored
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:
-
Hans de Goede authored
ia_css_rmgr_acq_vbuf() uses a local on stack "struct ia_css_rmgr_vbuf_handle v" variable. When this path using this is hit, either the rmgr_pop_handle() call will make *handle point to another vbuf-handle, or because v.count == 0, ia_css_rmgr_refcount_retain_vbuf() will alloc a new vbuf-handle and make *handle point to it. So on leaving the function *handle will never point to the on stack vbuf-handle, but gcc does not know this and emits the following: 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:276:33: warning: storing the address of local variable ‘h’ in ‘*handle’ [-Wdangling-pointer=] 276 | *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 Rework the code using a new_handle helper to suppress this false-postive compiler warning. Link: https://lore.kernel.org/linux-media/20220612160556.108264-4-hdegoede@redhat.comSigned-off-by:Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
When ia_css_rmgr_acq_vbuf() enters the code path where it uses the local "struct ia_css_rmgr_vbuf_handle v" on the stack it relies on v.count==0 so that ia_css_rmgr_refcount_retain_vbuf allocates a new handle. Explicitly set v.count to 0 rather then it being whatever was on the stack. Link: https://lore.kernel.org/linux-media/20220612160556.108264-3-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
The gcc is warning about returning a pointer to a local variable is a false positive. The type of handle is "struct ia_css_rmgr_vbuf_handle **" and "h.vptr" is left to NULL, so the "if ((*handle)->vptr == 0x0)" check always succeeds when the "*handle = &h;" statement which gcc warns about executes. Leading to this statement being executed: rmgr_pop_handle(pool, handle); If that succeeds, then *handle has been set to point to one of the pre-allocated array of handles, so it no longer points to h. If that fails the following statement will be executed: /* Note that handle will change to an internally maintained one */ ia_css_rmgr_refcount_retain_vbuf(handle); Which allocated a new handle from the array of pre-allocated handles and then makes *handle point to this. So the address of h is actually never returned. The fix for the false-postive compiler warning actually breaks the code, the new: **handle = h; is part of a "if (pool->copy_on_write) { ... }" which means that the handle where *handle points to should be treated read-only, IOW **handle must never be set, instead *handle must be set to point to a new handle (with a copy of the contents of the old handle). The old code correctly did this and the new fixed code gets this wrong. Note there is another patch in this series, which fixes the warning in another way. Link: https://lore.kernel.org/linux-media/20220612160556.108264-2-hdegoede@redhat.com Fixes: fa145137 ("media: atomisp: don't pass a pointer to a local variable") Signed-off-by: -
Haowen Bai authored
The info->data is dereferencing before null checking, so move it after checking. Link: https://lore.kernel.org/linux-media/1653897481-25681-1-git-send-email-baihaowen@meizu.comSigned-off-by:
Haowen Bai <baihaowen@meizu.com> Reviewed-by:
Tommaso Merciai <tommaso.merciai@amarulasolutions.com> Signed-off-by:
-
Xiaomeng Tong authored
The three bugs are here: __func__, s3a_buf->s3a_data->exp_id); __func__, md_buf->metadata->exp_id); __func__, dis_buf->dis_data->exp_id); The list iterator 's3a_buf/md_buf/dis_buf' will point to a bogus position containing HEAD if the list is empty or no element is found. This case must be checked before any use of the iterator, otherwise it will lead to a invalid memory access. To fix this bug, add an check. Use a new variable '*_iter' as the list iterator, while use the old variable '*_buf' as a dedicated pointer to point to the found element. Link: https://lore.kernel.org/linux-media/20220414041415.3342-1-xiam0nd.tong@gmail.com Cc: stable@vger.kernel.org Fixes: ad85094b ("Revert "media: staging: atomisp: Remove driver"") Signed-off-by:
Xiaomeng Tong <xiam0nd.tong@gmail.com> Signed-off-by:
-
Fabio M. De Francesco authored
The use of kmap() is being deprecated in favor of kmap_local_page() where it is feasible. The same is true for kmap_atomic(). In file pci/hmm/hmm.c, function hmm_store() test if we are in atomic context and, if so, it calls kmap_atomic(), if not, it calls kmap(). First of all, in_atomic() shouldn't be used in drivers. This macro cannot always detect atomic context; in particular, it cannot know about held spinlocks in non-preemptible kernels. Notwithstanding what it is said above, this code doesn't need to care whether or not it is executing in atomic context. It can simply use kmap_local_page() / kunmap_local() that can instead do the mapping / unmapping regardless of the context. With kmap_local_page(), the mapping is per thread, CPU local and not globally visible. Therefore, hmm_store()() is a function where the use of kmap_local_page() in place of both kmap() and kmap_atomic() is correctly suited. Convert the calls of kmap() / kunmap() and kmap_atomic() / kunmap_atomic() to kmap_local_page() / kunmap_local() and drop the unnecessary tests which test if the code is in atomic context. Link: https://lore.kernel.org/linux-media/20220413225531.9425-1-fmdefrancesco@gmail.comSigned-off-by:
Fabio M. De Francesco <fmdefrancesco@gmail.com> Reviewed-by:
Ira Weiny <ira.weiny@intel.com> Tested-by:
-
Fabio M. De Francesco authored
The use of kmap() is being deprecated in favor of kmap_local_page() where it is feasible. In file pci/hmm/hmm.c, function hmm_set() calls kmap() / kunmap() where kmap_local_page() can instead do the mapping. With kmap_local_page(), the mapping is per thread, CPU local and not globally visible. Therefore, hmm_set()() is a function where the use of kmap_local_page() in place of kmap() is correctly suited. Convert the calls of kmap() / kunmap() to kmap_local_page() / kunmap_local(). Link: https://lore.kernel.org/linux-media/20220413212210.18494-1-fmdefrancesco@gmail.comSigned-off-by:
-
Fabio M. De Francesco authored
The use of kmap() is being deprecated in favor of kmap_local_page() where it is feasible. With kmap_local_page(), the mapping is per thread, CPU local and not globally visible. load_and_flush_by_kmap() is a function where the use of kmap_local_page() in place of kmap() is correctly suited. Convert load_and_flush_by_kmap() from kmap() to kmap_local_page(). Link: https://lore.kernel.org/linux-media/20220408223129.3844-1-fmdefrancesco@gmail.comSigned-off-by:
-
Tom Rix authored
Clang static analysis reports this representative issue atomisp-ov2722.c:920:3: warning: 3rd function call argument is an uninitialized value dev_err(&client->dev, "sensor_id_high = 0x%x\n", high); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ high and low are only set when ov2722_read_reg() is successful. Reporting the high value when there is an error is not meaningful. The later read for low is not checked. high and low are or-ed together and checked against a non zero value. Remove the unneeded error reporting for high. Initialize high and low to 0 and use the id check to determine if the reads were successful The later read for revision is not checked. If it fails the old high value will be used and the revision will be misreported. Since the revision is only reported and not checked or stored it is not necessary to return if the read with successful. This makes the ret variable unnecessary so remove it. Link: https://lore.kernel.org/linux-media/20220326191853.2914552-1-trix@redhat.comSigned-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
Hans de Goede authored
Add a files documenting what I've learned about the driver while working on various cleanups. Link: https://lore.kernel.org/linux-media/20220615205037.16549-41-hdegoede@redhat.comReviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Hans de Goede authored
The force argument to the __destroy_pipe[s]() and __destroy_stream[s]() functions is always true. Remove the argument and remove the code necessary to handle the false case. Link: https://lore.kernel.org/linux-media/20220615205037.16549-40-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Use atomisp_destroy_pipes_stream_force() in 4 more places, instead of open coding it. Link: https://lore.kernel.org/linux-media/20220615205037.16549-39-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Use atomisp_css_update_stream() in 2 more places, instead of open coding it. Link: https://lore.kernel.org/linux-media/20220615205037.16549-38-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Use atomisp_create_pipes_stream() in 2 more places, instead of open coding it. Link: https://lore.kernel.org/linux-media/20220615205037.16549-37-hdegoede@redhat.comReviewed-by:
-
