- 07 Oct, 2023 40 commits
-
-
Wolfram Sang authored
No need to check the argument of i2c_unregister_device() because the function itself does it. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl>
-
Wolfram Sang authored
No need to check the argument of i2c_unregister_device() because the function itself does it. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Jernej Skrabec authored
According to H6 user manual, resets should always be de-asserted before clocks are enabled. This is also consistent with vendor driver. Fixes: d5aecd28 ("media: cedrus: Implement runtime PM") Signed-off-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
-
Ross Zwisler authored
The canonical location for the tracefs filesystem is at /sys/kernel/tracing. But, from Documentation/trace/ftrace.rst: Before 4.1, all ftrace tracing control files were within the debugfs file system, which is typically located at /sys/kernel/debug/tracing. For backward compatibility, when mounting the debugfs file system, the tracefs file system will be automatically mounted at: /sys/kernel/debug/tracing Update the visl decoder driver documentation to use this tracefs path. Signed-off-by:
Ross Zwisler <zwisler@google.com> Reviewed-by:
Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by:
Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by:
-
Jiasheng Jiang authored
Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Moreover, use kfree() in the later error handling in order to avoid memory leak. Fixes: c2f78f0c ("media: vidtv: psi: add a Network Information Table (NIT)") Signed-off-by:
Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by:
-
Jiasheng Jiang authored
Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Fixes: 7a7899f6 ("media: vidtv: psi: Implement an Event Information Table (EIT)") Fixes: c2f78f0c ("media: vidtv: psi: add a Network Information Table (NIT)") Fixes: f90cf607 ("media: vidtv: add a bridge driver") Signed-off-by:
-
Dan Carpenter authored
The of_parse_phandle() function returns NULL on error. It never returns error pointers. Update the check accordingly. Fixes: 70721089985c ("media: nuvoton: Add driver for NPCM video capture and encoding engine") Signed-off-by:Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by:
-
Chengfeng Ye authored
As &dev->condlock is acquired under irq context along the following call chain from s5p_mfc_irq(), other acquisition of the same lock inside process context or softirq context should disable irq avoid double lock. enc_post_frame_start() seems to be one such function that execute under process context or softirq context. <deadlock #1> enc_post_frame_start() --> clear_work_bit() --> spin_loc(&dev->condlock) <interrupt> --> s5p_mfc_irq() --> s5p_mfc_handle_frame() --> clear_work_bit() --> spin_lock(&dev->condlock) This flaw was found by an experimental static analysis tool I am developing for irq-related deadlock. To prevent the potential deadlock, the patch change clear_work_bit() inside enc_post_frame_start() to clear_work_bit_irqsave(). Signed-off-by:
Chengfeng Ye <dg573847474@gmail.com> Acked-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Irui Wang authored
Remove PM functions at start/stop streaming, add PM helper functions to get PM before encoding frame start and put PM after encoding frame done. Meanwhile, remove unnecessary clock operations. Signed-off-by:
Irui Wang <irui.wang@mediatek.com> Signed-off-by:
-
Biju Das authored
Sort header files alphabetically. Suggested-by:
Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by:
Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by:
-
Biju Das authored
Drop of_match_ptr() from tvp514x_driver and get rid of ugly CONFIG_OF if check. This slightly increases the size of tvp514x_driver on non-OF system and shouldn't be an issue. Add mod_devicetable.h include. It also allows, in case if needed, to enumerate this device via ACPI with PRP0001 magic. Signed-off-by:
-
Biju Das authored
The driver has an OF match table, still, it uses an ID lookup table for retrieving match data. Currently, the driver is working on the assumption that an I2C device registered via OF will always match a legacy I2C device ID. The correct approach is to have an OF device ID table using i2c_get_match_data() if the devices are registered via OF/ID. Unify the OF/ID table by using tvp514x_reg as match data for both these tables and replace the ID lookup table for the match data by i2c_get_match_data() and simplifly probe(). While at it, remove the trailing comma in the terminator entry for the OF table making code robust against (theoretical) misrebases or other similar things where the new entry goes _after_ the termination without the compiler noticing. Signed-off-by:
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct v4l2_subscribed_event. Additionally, since the element count member must be set before accessing the annotated flexible array member, move its initialization earlier. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: lijian <lijian@yulong.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct mcu_msg_push_buffers_internal. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Michael Tretter <m.tretter@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Signed-off-by:
-
Katya Orlova authored
s3c_camif_register_video_node() works with video_device structure stored as a field of camif_vp, so it should not be kfreed. But there is video_device_release() on error path that do it. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: babde1c2 ("[media] V4L: Add driver for S3C24XX/S3C64XX SoC series camera interface") Signed-off-by:
Katya Orlova <e.orlova@ispras.ru> Signed-off-by:
-
Ilpo Järvinen authored
Use FIELD_GET() to extract PCIe Negotiated and Maximum Link Width fields instead of custom masking and shifting. Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Biju Das authored
Drop of_match_ptr() from adv7180_driver and get rid of ugly CONFIG_OF if check. This slightly increases the size of adv7180_driver on non-OF system and shouldn't be an issue. Add mod_devicetable.h include. It also allows, in case if needed, to enumerate this device via ACPI with PRP0001 magic. Signed-off-by:
-
Biju Das authored
The driver has an OF match table, still, it uses an ID lookup table for retrieving match data. Currently, the driver is working on the assumption that an I2C device registered via OF will always match a legacy I2C device ID. The correct approach is to have an OF device ID table using i2c_get_match_data() if the devices are registered via OF/ID. Unify the OF/ID table by using struct adv7180_chip_info as match data for both these tables and replace the ID lookup table for the match data by i2c_get_match_data(). While at it, remove the trailing comma in the terminator entry for the OF table making code robust against (theoretical) misrebases or other similar things where the new entry goes _after_ the termination without the compiler noticing. Signed-off-by:
-
Fei Shao authored
The driver uses the upper-bound approach to decide the target JPEG encode quality, but there's a logic bug that if the desired quality is higher than what the driver can support, the driver falls back to using the worst quality. Fix the bug by assuming using the best quality in the beginning, and with trivial refactor to avoid long lines. Fixes: 45f13a57 ("media: platform: Add jpeg enc feature") Signed-off-by:
Fei Shao <fshao@chromium.org> Reviewed-by:
Chen-Yu Tsai <wenst@chromium.org> Signed-off-by:
-
Julia Lawall authored
for_each_child_of_node performs an of_node_get on each iteration, so a break out of the loop requires an of_node_put. This was done using the Coccinelle semantic patch iterators/for_each_child.cocci Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by:
-
Hans Verkuil authored
Explain how the DV Timings API and the V4L2_EVENT_SOURCE_CHANGE event work together to handle video source changes. Signed-off-by: -
Ming Qian authored
decoder firmware may notify host some debug message, it can help analyze the state of the firmware in case of error Fixes: 9f599f35 ("media: amphion: add vpu core driver") Signed-off-by:
Ming Qian <ming.qian@nxp.com> Reviewed-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by:
-
Bryan O'Donoghue authored
Digging into the documentation we find that the DT_ID bitfield is used to map the six bit DT to a two bit ID code. This value is concatenated to the VC bitfield to create a CID value. DT_ID is the two least significant bits of CID and VC the most significant bits. Originally we set dt_id = vc * 4 in and then subsequently set dt_id = vc. commit 3c4ed72a ("media: camss: sm8250: Virtual channels for CSID") silently fixed the multiplication by four which would give a better value for the generated CID without mentioning what was being done or why. Next up I haplessly changed the value back to "dt_id = vc * 4" since there didn't appear to be any logic behind it. Hans asked what the change was for and I honestly couldn't remember the provenance of it, so I dug in. Link: https://lore.kernel.org/linux-arm-msm/edd4bf9b-0e1b-883c-1a4d-50f4102c3924@xs4all.nl/ Add a comment so the next hapless programmer doesn't make this same mistake. Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by:
-
Bryan O'Donoghue authored
A previous patch I had removed the returns from vfe_disable() since we didn't trap any meaningful errors. Konrad pointed out vfe_reset() could return an error, which is true. Trap the vfe_reset() error code and throw it up the callstack. Suggested-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
-
Bryan O'Donoghue authored
We can move vfe_disable() into a common routine in the core VFE file provided we make wm_stop() a VFE specific callback. The callback is required to capture the case where VFE 17x currently isn't VC enabled where as VFE 480 is. Suggested-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Bryan O'Donoghue authored
Some VFEs have four RDIs apiece. Right now the ISR code has a hard-coded value which tops-out at RDI2 meaning only three RDIs can be utilised in practice. Extend out the various routines in camss-vfe-17x.c to support the higher RDI count. Signed-off-by:
-
Bryan O'Donoghue authored
Several of our upstream and soon-to-be upstream SoC CAMSS dtsi declare csiphyX as opposed to the older clock name csiX_phy. Right now the CAMSS code will fail to set the csiphyX clock even if we have declared it in our list of clocks. For sdm845 and sm8250 we appear to "get away" with this error, however on sc8280xp we don't. The right approach here is to set the clock when it is declared. If a SoC doesn't require or a SoC driver implementer doesn't think we need, then the clock ought to simply be omitted from the clock list. Include csiphyX in the set of permissible strings which will subsequently lead to the csiphyX clock being set during csiphy_set_clock_rates() phase. sdm845 and sm8250 will work with the code as-is so I've omitted this from a suggested Fixes list. Signed-off-by:
-
Bryan O'Donoghue authored
The csiphyX_timer and csiX_phy values need not be hard-coded. We can functionally decompose the string matching inside of a loop. Static string values are brittle, difficult to extend and not required anyway since the camss->res->csiphy_num value informs us of the number of CSIPHYs and hence the set of potential clocks for a given CSIPHY. In simple terms if we have five CSIPHYs we can have no more and no less than five csiphy_timer clocks. Similarly csi_phy core clocks have a 1:1 relationship with the PHY they clock. Signed-off-by:
-
Bryan O'Donoghue authored
The number of Video Front End - VFE or Image Front End - IFE supported with new SoCs can vary both for the full and lite cases. For example sdm845 has one vfe_lite and two vfe interfaces with the vfe clock called simply "vfe_lite" with no integer postfix. sc8280xp has four vfe and four vfe lite blocks. At the moment we declare vfe_lite0 and vfe_lite1 for sm8250 but never set those clocks because we don't match the strings. We need to support the following clock name formats - vfeN - vfe_liteN - vfe_lite with N being any reasonably sized integer. There are two sites in this code which need to do the same thing, constructing and matching strings with the pattern above, so encapsulate the logic in one function. Signed-off-by:
-
Bryan O'Donoghue authored
We have a very convoluted if/else legacy here which needs to be rationalised to make it more sustainable. Adding in another Soc or two will make some of these if statements into increasingly large multi-clause behemoths. Introduce switches in the obvious places to despaghetiify. Signed-off-by:
-
Bryan O'Donoghue authored
From sdm845 onwards we need to ensure the VFE is powered on prior to switching on the CSID. Currently the code tests for sdm845, sm8250 and then does get/set. This is not extensible and it turns out is not necessary either since vfe_get and vfe_set reference count. Remove the over-conservative SoC version check. Signed-off-by:
-
Bryan O'Donoghue authored
Each Video Front End - VFE - has a variable number of Raw Data Interfaces - RDIs associated with it. The CAMSS code started from a naive implementation where a fixed define was used as a control in a for(){} loop iterating through RDIs. That model scales badly. An attempt was made with VFE_LINE_NUM_GEN2 and VFE_LINE_NUM_GEN1 to differentiate between SoCs but, the problem with that is "gen1" and "gen2" have no meaning in the silicon. There is no fixed constraint in the silicon between VFE and RDI, it is entirely up to the SoC designers how many VFEs are populated and how many RDIs to associate with each VFE. As an example sdm845 has VFE version 175 and sm8250 VFE version 480. sdm845 has 2 VFEs with 4 RDIs and 1 VFE Lite with 4 RDIs. sm8250 has 2 VFEs with 3 RDIs and 2 VFE Lite with 4 RDIs. Clearly then we need a more granular model to capture the necessary data. The defines have gone away to be replaced with per-SoC data but, we haven't populated the parameter data with the real values. Let's call those values out now msm8916: 1 x VFE 3 x RDI per VFE (not 4) msm8996: 2 x VFE 3 x RDI per VFE (not 4) sdm660: 2 x VFE 3 x RDI per VFE (not 4) sdm845: 2 x VFE 4 x RDI per VFE (not 3) 1 x VFE Lite 4 x RDI per VFE Lite (not 3) sm8250: 2 x VFE 3 x RDI per VFE (not 4) 2 x VFE Lite 4 x RDI per VFE Lite This more complex and correct mapping was not possible prior to passing values via driver data. Now that we have that change in place we can correctly map VFEs to RDIs for each VFE. Signed-off-by: -
Bryan O'Donoghue authored
It is possible to pass all of the CAMSS subdevice internal operations pointers from the controlling resources structure with an additional pointer added to the resources structure. This allows for the removal of most of the probe-time control structures. Signed-off-by:
-
Bryan O'Donoghue authored
line_num indicates the number of RDI - raw data interface channels which are associated with a given IFE/VFE - image/video front end. On several SoCs the RDI number is not static for each VFE - for example on sm8250 VFE Lite has four RDIs where regular VFE has three. Assigning line_num statically in the subdev_init() phase initialises each VFE to the lower number, meaning in practical terms that we are lobbing off one RDI on some VFEs. Interrupt handling uses static for (i = RDI0; i < RDI2; i++) {} in some of our VFE blocks but this can't work for situations where we have a mixture of VFE @ 3 RDI and VFE-lite @ 4 RDI blocks. First step to remediate is to pass line_num from a compat string controlled data-structure and do so on a per-VFE basis. Later patches will assign the correct number of RDI blocks per VFE. Signed-off-by: -
Bryan O'Donoghue authored
The following variables are being assigned statically based on compatible strings in the probe path. * enum camss_version version; * unsigned int csiphy_num; * unsigned int csid_num; * unsigned int vfe_num; * unsigned int vfe_lite_num; * unsigned int vfe_total_num; Migrate those variables to resource parameters passed in on platform probe arguments. The one caveat is for VFE it has been necessary to intoduce a new variable vfe_total_num to capture the aggregate value of vfe_num + vfe_lite_num. All the rest of the changes are rote camss->variable to camss->res->variable with the parameter tables now populating the listed variables. Signed-off-by:
-
Bryan O'Donoghue authored
Pass the bandwidth table as a platform parameter not if/else derived pointer to the static table. Signed-off-by:
-
Bryan O'Donoghue authored
There is a lot of unnecessary if/elsing in this code that arguably should never have made it upstream when adding a second let alone subsequent SoC. I'm guilty of not fixing the mess myself when adding in the sm8250. Before adding in any new SoCs or resources lets take the time to cleanup the resource passing. First step is to pass the generic struct camss_resources as a parameter per the compatible list. Subsequent patches will address the other somewhat disparate strutures which we are also doing if/else on and assigning statically. Squashed down a commit to drop useless NULL assignment for ispif resources. Signed-off-by:
-
Bryan O'Donoghue authored
Rename non-specific struct resources {} to struct camss_subdev_resources {} Each logical block in CAMSS has a number of regulators, clocks and resets associated with it. We represent these blocks as v4l subdevices. The name "struct camss_subdev_resources" is a more descriptive and accurate name. Suggested-by: -
Bryan O'Donoghue authored
There is no good reason to differentiate the two resource structures here. As part of a general tidyup of the declaration and passing of resources within in the CAMSS driver it will be advantageous to have one unified resource structure. The two structures are very similar anyway thus leading more credence still to the argument there should be only one. Signed-off-by:
-
Martin Tůma authored
The "admin-guide" documentation for the Digiteq Automotive MGB4 driver. Signed-off-by:
Martin Tůma <martin.tuma@digiteqautomotive.com> Signed-off-by:
-
