- Dec 07, 2020
-
-
Sakari Ailus authored
CCS allows odd PLL dividers other than 1, granted that the corresponding capability bit is set. Support this both in the PLL calculator and the CCS driver. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
Add support for decoupled OP domain clock calculation. This means that the number of VT and OP domain clocks are no longer dependent on the number of CSI-2 lanes in the lane speed mode. The support also replaces the existing quirk flag to calculate OP domain clocks per lane. Also support decoupled OP domain calculation in the CCS driver. Signed-off-by:
-
Sakari Ailus authored
Convey the relevant PLL flags to the PLL calculator. Also the lane speed model affects how the link rate is calculated on the CSI-2 bus, as the rate is total of all lanes. Signed-off-by:
-
Sakari Ailus authored
CCS PLL includes a capability to calculate the VT clocks on per-lane basis. Add support for this feature. Move calculation of the pixel rate on the CSI-2 bus early in the function as everything needed to calculate it is already available. Signed-off-by:
-
Sakari Ailus authored
Use uint32_t instead of unsigned int for a variable that contains explicitly 32-bit numbers. Signed-off-by:
-
Sakari Ailus authored
The additional multiplier (for higher VT timing) of the PLL multiplier was checked against the upper limit but the result was rounded up, possibly producing too high additional multiplier. Round down instead to keep within hardware limits. Signed-off-by:
-
Sakari Ailus authored
The comment is about minimum PLL multiplier but the related check really deals with the maximum PLL multiplier. Signed-off-by:
-
Sakari Ailus authored
The external clock frequency times the PLL multiplier may exceed the value range of 32-bit unsigned integers. Instead perform the same calculation y using two divisions. The result has some potential to be different, but that's ok: this number is used to limit the range of pre-PLL divisors to find optimal values. So the effect of the rare case of a different result here would mean an invalid pre-PLL divisor is tried. That will be found out a little later in any case. Also guard against dividing by zero if the external clock frequency is higher than the maximum OP PLL output clock --- a rather improbable case. Signed-off-by:
-
Sakari Ailus authored
The lower bound of the pre-PLL divider was calculated based on OP SYS clock frequency which is also affected by the OP SYS clock divider. This is wrong. The right clock frequency is that of the PLL output clock. Signed-off-by:
-
Sakari Ailus authored
The OP system clock frequency defines the CSI-2 bus clock frequency, not the PLL output clock frequency. Both values were overwritten in the end, but the wrong limit value was used for the OP system clock frequency, possibly leading to too high frequencies being used. Also remove now duplicated calculation of OP system clock frequency later in the PLL calculator. Signed-off-by:
-
Sakari Ailus authored
Use the BIT macro for setting individual bits. Signed-off-by:
-
Sakari Ailus authored
The CCS pll is used by the CCS driver at the moment, but documenting the interface makes sense. It's non-trivial and the calculator could be used elsewhere. Signed-off-by:
-
Sakari Ailus authored
This way the struct will use less memory, with better packing and no waste due to unsigned long. Signed-off-by:
-
Sakari Ailus authored
Differentiate between CSI-2 D-PHY and C-PHY. This does not yet include support for C-PHY. Signed-off-by:
-
Sakari Ailus authored
The parallel bus PLL calculation has no users. Remove it. Signed-off-by:
-
Sakari Ailus authored
The VT divisor search can be ended if we've already found the value that corresponds exactly the total divisor, as there are no better (lower) values available. Signed-off-by:
-
Sakari Ailus authored
Use the correct video timing divisor to calculate the SYS divisor. Instead of the current value, the minimum was used. This could have resulted in a too low SYS divisor. Signed-off-by:
-
Sakari Ailus authored
The CCS spec supports a lot of variation in the PLL. Split the PLL in front and back parts to better prepare for supporting it. Also use CCS compliant naming for IP and OP PLL frequencies (i.e. include "clk" in the name). Signed-off-by:
-
Sakari Ailus authored
pll->pll_op_clk_freq is a 32-bit number. It does not need div_u64 to divide it. Signed-off-by:
-
Rob Herring authored
Fix a few new indentation warnings found with yamllint (now integrated into the checks). Cc: Ricardo Ribalda <ribalda@kernel.org> Signed-off-by:
Rob Herring <robh@kernel.org> Acked-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> # For adv7604 Acked-by:
-
Hans Verkuil authored
The 'disconnect' error injection functionality suffered from bit rot. New device nodes were added without updating vivid_user_gen_s_ctrl(), so that function had to be updated for the new device nodes. Also, vivid didn't check if specific device nodes were actually ever created, so the vivid_is_last_user() would fail on that (it would return true instead of false in that case). Finally, selecting Disconnect, then unbind the vivid driver would fail since the remove() would think that the device nodes were already unregistered. Keep track of whether disconnect was pressed and re-register the device nodes in remove() before doing the real unregister. [hverkuil: unsigned uses -> unsigned int uses] Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Jacopo Mondi authored
The VNCSI_IFMD register controls the data expansion mode and the channel routing between the CSI-2 receivers and VIN instances. According to the chip manual revision 2.20 not all fields are available for all the SoCs: - V3M, V3H and E3 do not support the DES1 field has they do not feature a CSI20 receiver. - D3 only supports parallel input, and the whole register shall always be written as 0. Inspect the per-SoC channel routing table where the available CSI-2 instances are reported and configure VNCSI_IFMD accordingly. This patch supports this BSP change commit: https://github.com/renesas-rcar/linux-bsp/commit/f54697394457 ("media: rcar-vin: Fix VnCSI_IFMD register access for r8a77990") [hverkuil: replace BSP commit ID with BSP URL] Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Suggested-by:
-
Neil Armstrong authored
Add new entry to MAINTAINERS. [hverkuil: added changelog] Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Neil Armstrong authored
The GE2D is a 2D accelerator with various features like configurable blitter with alpha blending, frame rotation, scaling, format conversion and colorspace conversion. The driver implements a Memory2Memory VB2 V4L2 streaming device permitting: - 0, 90, 180, 270deg rotation - horizontal/vertical flipping - source cropping - destination compositing - 32bit/24bit/16bit format conversion This adds the support for the GE2D version found in the AXG SoCs Family. The missing features are: - Source scaling - Colorspace conversion - Advanced alpha blending & blitting options Is passes v4l2-compliance: SHA: ea16a7ef13a902793a5c2626b0cefc4d956147f3, 64 bits, 64-bit time_t [hverkuil: add missing linux/bitfield.h include] Signed-off-by:
-
Neil Armstrong authored
The GE2D is a 2D accelerator with various features like configurable blitter with alpha blending, frame rotation, scaling, format conversion and colorspace conversion. This adds the bindings for the GE2D version found in the AXG SoCs Family. Signed-off-by:
-
Jernej Skrabec authored
Commit 31d9b9ef8564 ("media: cedrus: Register all codecs as capability") makes separate capability flags for each codec. However, VP8 codec was merged at the same time as mentioned patch, so there is no capability flag for it. This patch adds capability flag for VP8 and enables it for all variants except for V3s. Signed-off-by:Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
-
Alan Stern authored
The gspca driver leaks memory when a probe fails. gspca_dev_probe2() calls v4l2_device_register(), which takes a reference to the underlying device node (in this case, a USB interface). But the failure pathway neglects to call v4l2_device_unregister(), the routine responsible for dropping this reference. Consequently the memory for the USB interface and its device never gets released. This patch adds the missing function call. Reported-and-tested-by:
<syzbot+44e64397bd81d5e84cba@syzkaller.appspotmail.com> Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> Signed-off-by:
-
Laurent Pinchart authored
Planar pixel formats are documented in separate files. This duplicates information, as those formats share comon traits. Consolidate them in a single file and summarize their descriptions in a single table. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Laurent Pinchart authored
Semi-planar pixel formats are documented in separate files. This duplicates information, as those formats share comon traits. Consolidate them in a single file and summarize their descriptions in a single table. Signed-off-by:
-
Laurent Pinchart authored
Luma-only pixel formats are documented in separate files. This duplicates information, as those formats share comon traits. Consolidate them in a single file and describe them in a single table. Signed-off-by:
-
Laurent Pinchart authored
Document the naming scheme for the existing packed YUV 4:4:4 formats, as previously done for the RGB formats. Signed-off-by:
-
Laurent Pinchart authored
The 4:4:4 packed YUV formats are documented with a bit-level representation, which creates a wide table. Switch to a byte-oriented representation to make it more compact. This prepares for the addition of formats with more than 8 bits per component, that would make the table way too wide. Signed-off-by:
-
Laurent Pinchart authored
The padding bits are left blank, which look weird in the XYUV format, and, worse, may lead to the VUYX format to be understand as consuming 3 bytes per pixel. Add 'X' for padding bits as we do for RGB formats. Signed-off-by:
-
Laurent Pinchart authored
The pixfmt-packed-yuv.rst file documents packed YUV 4:4:4 formats, but is titled generically as "Packed YUV formats". 4:2:2 and 4:1:1 packed YUV formats are documented in separate files, which can be confusing. Group all packed YUV formats in pixfmt-packed-yuv.rst, which allows documenting the 4:2:2 formats in a more concise way. Signed-off-by:
-
Laurent Pinchart authored
Document YUV subsampling, including chroma spatial siting, and replace the siting examples in individual formats by references to the common documentation. Signed-off-by:
-
Laurent Pinchart authored
Using '-' to represent padding bits and bytes make text and tables more difficult to read. Use 'x' and 'X' instead. Signed-off-by:
-
Laurent Pinchart authored
All formats using 8 bits per component can be described with a byte granularity instead of a bit granularity without loss of precision. This makes the corresponding table more compact and easier to read. Signed-off-by:
-
Laurent Pinchart authored
The naming scheme for the RGB pixel formats has been developed organically, and isn't consistent between formats using less than 8 bits per pixels (mostly stored in 1 or 2 bytes per pixel, except for RGB666 that uses 4 bytes per pixel) and formats with 8 bits per pixel (stored in 3 or 4 bytes). For the latter category, the names use a components order convention that is the opposite of the first category, and the opposite of DRM pixel formats. This has led to lots of confusion in the past, and would really benefit from being explained more precisely. Do so, which also prepares for the addition of additional RGB pixels formats. Signed-off-by:
-
Laurent Pinchart authored
Improve readability of the documentation by adding a section title for the deprecated formats. Signed-off-by:
-
Laurent Pinchart authored
The packed RGB formats documentation includes a layout table without any context. This doesn't bring much useful information, and is confusing at best. Remove it. Signed-off-by:
-
