Naushir Patuck [Tue, 8 Feb 2022 13:49:11 +0000 (13:49 +0000)]
media: i2c: imx219: Scale the pixel clock rate for the 640x480 mode
The 640x480 mode uses a special binning mode for high framerate operation where
the pixel rate is effectively doubled. Account for this when setting up the
pixel clock rate, and applying the vblank and exposure controls.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Grigori Goronzy [Wed, 9 Feb 2022 21:23:11 +0000 (22:23 +0100)]
dtoverlays: add rgb565-padhi output to vc4-kms-dpi-generic
This mode is used by some DPI based display adapters, such as the
'VGA565' and 'VGA Zero' low-cost VGA adapters for the Raspberry Pi.
Signed-off-by: Grigori Goronzy <greg@kinoho.net>
Grigori Goronzy [Wed, 9 Feb 2022 21:20:17 +0000 (22:20 +0100)]
dtoverlays: fix overrides in vc4-kms-dpi-generic
Apparently broken by commit
3c033975. Introduce new names to allow for
proper addressing of overrides.
Signed-off-by: Grigori Goronzy <greg@kinoho.net>
Phil Elwell [Mon, 7 Feb 2022 16:06:11 +0000 (16:06 +0000)]
overlays: rpi-poe(-plus): Fix parameters
The support of PoE HATs is complicated because there are two methods to
control them - via the firmware, and directly over I2C - the choice
between the two methods depending on which side "owns" the i2c0 bus.
The firmware determines the ownership of i2c0 by analysing the Device
Tree after applying any dtoverlays and dtparams. For this reason the
PoE HAT overlays have recently been applied by the firmware _after_
config.txt has been processed, but this has prevented any user-supplied
threshold settings from being applied - either because the parameters
are unknown or because (after an explicit dtoverlay=rpi-poe) the
firmware's reload of the overlay has overwritten the user's settings.
Solve the problem by restructuring the rpi-poe overlays to support
a mode switch _after_ the overlay has been merged, thereby allowing
the overlays to be loaded _before_ config.txt is processed.
There is a companion firmware patch that changes the point at which
the overlays are loaded, and the parameter used to switch modes, but
the updated overlays are still compatible with older firmware, albeit
without working parameters.
See: https://github.com/raspberrypi/firmware/issues/1689
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Dave Stevenson [Fri, 4 Feb 2022 16:12:35 +0000 (16:12 +0000)]
media: bcm2835-unicam: Handle a repeated frame start with no end
In the case of 2 frame starts being received with no frame end
between, the queued buffer held in next_frm was lost as the
pointer was overwritten with the dummy buffer.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Phil Elwell [Sat, 5 Feb 2022 18:41:07 +0000 (18:41 +0000)]
drm: panel: Fix compilation warnings
See: https://github.com/raspberrypi/linux/pull/4812
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Phil Elwell [Thu, 3 Feb 2022 15:51:41 +0000 (15:51 +0000)]
net: phy: lan87xx: Decrease phy polling rate
Polling at 100Hz for 1.5s consumes quite a bit of kworker time with no
obvious benefit. Reduce that polling rate to ~6Hz.
To further save CPU and power, defer the next poll if no energy is
detected.
See: https://github.com/raspberrypi/linux/issues/4780
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Phil Elwell [Wed, 2 Feb 2022 17:47:54 +0000 (17:47 +0000)]
ARM: dts: Permanently disable hdmi1 and ddc1 on CM4S
CM4S has no HDMI1 output, so it is advisable to disable the controller
and its I2C interface in software. This is ordinarily done by setting
their status properties to "disabled", but the vc4-kms-v3d(-pi4)
overlay enables both HDMIs and DDCs as part of the transfer of control
from the VPU.
Knobble the CM4S dts in such a way that the overlay applies
successfully but the hdmi1 and ddc1 nodes remain disabled by changing
the compatible string to something unrecognised.
See: https://github.com/raspberrypi/linux/issues/4857
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Dave Stevenson [Thu, 3 Feb 2022 11:17:16 +0000 (11:17 +0000)]
dtoverlay: Reduce size of PCIE IB window in pcie-32-dma overlay
The PCIE inbound window is rounded up to a power of 2, so the default
of 3GB rounds up to 4GB starting at 0. This prohibits the MSI vector
sitting at 0x0_fffffffc, and causes warnings from some subsystems
(eg ahci) of a 64bit address on a 32bit configuration.
Reduce the window down to 2GB to avoid this issue.
https://github.com/raspberrypi/linux/issues/4848
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Thu, 6 Jan 2022 13:04:34 +0000 (13:04 +0000)]
dtoverlays: Add overlays for Pimoroni Hyperpixel displays
Adds an overlays for the Pimoroni HyperPixel4, HyperPixel 4
Square, and HyperPixel 2 Round DPI displays.
We have a conflict over the use of GPIO 27 for touch screen
interrupt and SPI CLK for configuring the display on the
two HyperPixel4 displays.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Phil Elwell [Wed, 12 Jan 2022 08:23:28 +0000 (08:23 +0000)]
spi: gpio: Add sck-idle-input property
The sck-idle-input property indicates that the spi-gpio driver should
return the SCK line to an input when the chip select signals are
inactive.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Phil Elwell [Fri, 4 Feb 2022 11:33:28 +0000 (11:33 +0000)]
bindings: Add sck-idle-input to spi-gpio
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Dave Stevenson [Thu, 6 Jan 2022 13:15:46 +0000 (13:15 +0000)]
defconfig: Enable Pimoroni HyperPixel drivers in Pi defconfigs
Drivers for Pimoroni HyperPixel4, HyperPixel 4 Square, and
HyperPixel 2 Round displays.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Tue, 1 Feb 2022 15:27:01 +0000 (15:27 +0000)]
drm/panel/panel-sitronix-st7701: Support SPI config and RGB data
The ST7701 supports numerous different interface mechanisms for
MIPI DSI, RGB, or SPI. The driver was only implementing DSI input,
so add RGB parallel input with SPI configuration.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Wed, 26 Jan 2022 16:02:31 +0000 (16:02 +0000)]
drm/panel: Add panel driver for TDO Y17B based panels
The Top DisplayOptoelectronics (TDO) T17B driver chip is used
in the TL040HDS20CT panel (found in the Pimoroni HyperPixel4
Square display) and potentially other displays.
The driver chip supports SPI for configuration and DPI
video data.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Wed, 5 Jan 2022 19:14:48 +0000 (19:14 +0000)]
drm/panel: Add panel driver for Ilitek ILI9806E panel
The Ilitek ILI9806E driver is used in the Pimoroni HyperPixel4
and potentially other displays. Whilst it can support multiple
interfaces, this driver only accounts for SPI configuration and
DPI video data.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Chris Morgan [Wed, 2 Feb 2022 16:43:32 +0000 (10:43 -0600)]
overlays: Add Geekworm mzp280 to vc4-kms-dpi-panel
Add support for the Geekworm mzp280 DPI panel to the generic
vc4-kms-dpi-panel overlay.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Chris Morgan [Wed, 2 Feb 2022 16:42:00 +0000 (10:42 -0600)]
overlays: Add rotate property to vc4-kms-dpi-panel
Allow a user to specify the panel rotation in devicetree as 0, 90,
180, or 270 by setting a parameter.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Dave Stevenson [Tue, 1 Feb 2022 12:24:51 +0000 (12:24 +0000)]
drm/panel: simple: Remove custom handling of orientation
Panel orientation is now handled by the drm_panel and
panel_bridge frameworks, so remove the custom handling.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Tue, 1 Feb 2022 12:20:20 +0000 (12:20 +0000)]
drm/panel: Add and initialise an orientation field to drm_panel
Current usage of drm_connector_set_panel_orientation is from a panel's
get_modes call. However if the panel orientation property doesn't
exist on the connector at this point, then drm_mode_object triggers
WARNs as the connector is already registered.
Add an orientation variable to struct drm_panel and initialise it from
drm_panel_init.
panel_bridge_attach can then create the property before the connector
is registered.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Phil Elwell [Wed, 2 Feb 2022 09:11:20 +0000 (09:11 +0000)]
overlays: README: Deprecate vc4-kms-kippah-7inch
The vc4-kms-kippah-7inch overlay has been replaced by the container
overlay vc4-kms-dpi-panel, using the "kippah-7inch" parameter. The
original overlay has been retained for now to avoid breaking
existing installations, but that doesn't make it any less deprecated,
so update the README accordingly.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Chris Morgan [Fri, 28 Jan 2022 23:42:12 +0000 (17:42 -0600)]
drm/panel: simple: add Geekworm MZP280 Panel
Add support for the Geekworm MZP280 Panel
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Chris Morgan [Fri, 28 Jan 2022 23:41:18 +0000 (17:41 -0600)]
dt-bindings: display: simple: add Geekworm MZP280 Panel
The Geekworm MZP280 panel is a 480x640 (portrait) panel with a
capacitive touch interface and a 40 pin header meant to interface
directly with the Raspberry Pi. The screen is 2.8 inches diagonally,
and there appear to be at least 4 distinct versions all with the same
panel timings.
Timings were derived from drivers posted on the github located here:
https://github.com/tianyoujian/MZDPI/tree/master/vga
Additional details about this panel family can be found here:
https://wiki.geekworm.com/2.8_inch_Touch_Screen_for_Pi_zero
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Chris Morgan [Fri, 28 Jan 2022 23:40:50 +0000 (17:40 -0600)]
dt-bindings: vendor-prefixes: Add Geekworm
Add vendor prefix for Geekworm (https://geekworm.com).
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Chris Morgan [Fri, 28 Jan 2022 23:39:54 +0000 (17:39 -0600)]
drm/vc4: dpi: Support DPI interface in mode3 for RGB565
Add support for the VC4 DPI driver to utilize DPI mode 3. This is
defined here as xxxRRRRRxxGGGGGGxxxBBBBB:
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#parallel-display-interface-dpi
This mode is required to use the Geekworm MZP280 DPI display.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Chris Morgan [Fri, 28 Jan 2022 23:38:40 +0000 (17:38 -0600)]
media: uapi: add MEDIA_BUS_FMT_RGB565_1X24_CPADHI
Add the MEDIA_BUS_FMT_RGB565_1X24_CPADHI format used by the Geekworm
MZP280 panel for the Raspberry Pi.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Chris Morgan [Fri, 28 Jan 2022 23:37:43 +0000 (17:37 -0600)]
media: uapi: Document format MEDIA_BUS_FMT_RGB565_1X24_CPADHI
Add support for MEDIA_BUS_FMT_RGB565_1X24_CPADHI. This format is used
by the Geekworm MZP280 panel which interfaces with the Raspberry Pi.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Dave Stevenson [Mon, 31 Jan 2022 17:25:19 +0000 (17:25 +0000)]
dtoverlays: Rework vc4-kms-dpi overlays to remove duplication
Removes all the common panel, dpi, and backlight configuration
from the individual vc4-kms-dpi-* files into vc4-kms-dpi.dtsi.
Creates a new vc4-kms-dpi-panel-overlay.dts for preconfigured
panels, with overrides to enable the different panel configurations.
Deprecates vc4-kms-dpi-at056tn53v1 as superceded by vc4-kms-dpi-panel.
vc4-kms-kippah-7inch not deprecated for now as it is likely to be
in wider use than at056tn53v1.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Phil Elwell [Mon, 31 Jan 2022 21:01:25 +0000 (21:01 +0000)]
overlays: Add spi0-0cs overlay
An overlay to enable SPI0 without claiming any chip select GPIOs.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Dave Stevenson [Mon, 31 Jan 2022 16:28:43 +0000 (16:28 +0000)]
drm/vc4: Add DRM
210101010 RGB formats for hvs5.
HVS5 supports the
210101010 RGB[A|X] formats, but they were
missing from the DRM to HVS mapping list, so weren't available.
Add them in.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
tiagofreire-pt [Sat, 29 Jan 2022 10:01:36 +0000 (10:01 +0000)]
Patching lan78xx for SOF_TIMESTAMPING_TX_SOFTWARE support
Alex Crawford [Fri, 28 Jan 2022 21:36:51 +0000 (13:36 -0800)]
i2c: bcm2835: Make clock-stretch timeout configurable
The default clock-stretch timeout is 35 mS, which works well for
SMBus, but there are some I2C devices which can stretch the clock even
longer. Rather than trying to prescribe a safe default for everyone,
allow the timeout to be configured.
Signed-off-by: Alex Crawford <raspberrypi/linux@code.acrawford.com>
Nathan Chancellor [Tue, 1 Feb 2022 00:50:43 +0000 (17:50 -0700)]
media: i2c: ov9281: Initialize id_msb to zero in ov9281_check_sensor_id()
Clang warns:
drivers/media/i2c/ov9281.c:1132:6: warning: variable 'id_msb' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if (!ret)
^~~~
drivers/media/i2c/ov9281.c:1135:9: note: uninitialized use occurs here
id |= (id_msb << 8);
^~~~~~
drivers/media/i2c/ov9281.c:1132:2: note: remove the 'if' if its condition is always true
if (!ret)
^~~~~~~~~
drivers/media/i2c/ov9281.c:1127:20: note: initialize the variable 'id_msb' to silence this warning
u32 id = 0, id_msb;
^
= 0
1 warning generated.
If the first ov9281_read_reg() call fails, id_msb will be used
uninitialized. However, this warning does not actually matter in
practice because the value of id is not used when either call to
ov9281_read_reg() fails, as the boolean OR will short circuit due to the
ret condition being checked first. Regardless, it is not good to use
variables uninitialized so silence the warning by initializing id_msb to
0, as was done with id.
Fixes:
20855581e0eb ("media: i2c: ov9281: Read chip ID via 2 reads")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Nathan Chancellor [Tue, 1 Feb 2022 00:23:38 +0000 (17:23 -0700)]
media: bcm2835-unicam: Set ret on error path in unicam_async_complete()
Clang warns:
drivers/media/platform/bcm2835/bcm2835-unicam.c:3109:6: warning: variable 'ret' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
if (!source_pads) {
^~~~~~~~~~~~
drivers/media/platform/bcm2835/bcm2835-unicam.c:3152:9: note: uninitialized use occurs here
return ret;
^~~
drivers/media/platform/bcm2835/bcm2835-unicam.c:3109:2: note: remove the 'if' if its condition is always false
if (!source_pads) {
^~~~~~~~~~~~~~~~~~~
drivers/media/platform/bcm2835/bcm2835-unicam.c:3091:9: note: initialize the variable 'ret' to silence this warning
int ret;
^
= 0
1 warning generated.
When the if condition is true, ret will be used uninitialized, which
could result in undesirable behavior. Set ret to -ENODEV on the error
path, which is a standard error code for the ->complete() callback.
Fixes:
d056e86eb35f ("media/bcm2835-unicam: Parse pad numbers correctly")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Nathan Chancellor [Tue, 1 Feb 2022 00:20:55 +0000 (17:20 -0700)]
ASoC: bcm: allo-piano-dac-plus: Remove unnecessary const specifiers
Clang warns:
sound/soc/bcm/allo-piano-dac-plus.c:66:14: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(allo_piano_mode_enum,
^
./include/sound/soc.h:355:2: note: expanded from macro 'SOC_ENUM_SINGLE_DECL'
SOC_ENUM_DOUBLE_DECL(name, xreg, xshift, xshift, xtexts)
^
./include/sound/soc.h:352:2: note: expanded from macro 'SOC_ENUM_DOUBLE_DECL'
const struct soc_enum name = SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, \
^
sound/soc/bcm/allo-piano-dac-plus.c:75:14: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(allo_piano_dual_mode_enum,
^
./include/sound/soc.h:355:2: note: expanded from macro 'SOC_ENUM_SINGLE_DECL'
SOC_ENUM_DOUBLE_DECL(name, xreg, xshift, xshift, xtexts)
^
./include/sound/soc.h:352:2: note: expanded from macro 'SOC_ENUM_DOUBLE_DECL'
const struct soc_enum name = SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, \
^
sound/soc/bcm/allo-piano-dac-plus.c:96:14: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(allo_piano_enum,
^
./include/sound/soc.h:355:2: note: expanded from macro 'SOC_ENUM_SINGLE_DECL'
SOC_ENUM_DOUBLE_DECL(name, xreg, xshift, xshift, xtexts)
^
./include/sound/soc.h:352:2: note: expanded from macro 'SOC_ENUM_DOUBLE_DECL'
const struct soc_enum name = SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, \
^
3 warnings generated.
SOC_VALUE_ENUM_DOUBLE_DECL already has a const specifier. Remove the duplicate
const specifiers to clean up the warnings.
Fixes:
42444979e710 ("Add support for all the downstream rpi sound card drivers")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Nathan Chancellor [Tue, 1 Feb 2022 00:15:35 +0000 (17:15 -0700)]
ASoC: ma120x0p: Remove unnecessary const specifier
Clang warns:
sound/soc/codecs/ma120x0p.c:891:14: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
static const SOC_VALUE_ENUM_SINGLE_DECL(pwr_mode_ctrl,
^
./include/sound/soc.h:362:2: note: expanded from macro 'SOC_VALUE_ENUM_SINGLE_DECL'
SOC_VALUE_ENUM_DOUBLE_DECL(name, xreg, xshift, xshift, xmask, xtexts, xvalues)
^
./include/sound/soc.h:359:2: note: expanded from macro 'SOC_VALUE_ENUM_DOUBLE_DECL'
const struct soc_enum name = SOC_VALUE_ENUM_DOUBLE(xreg, xshift_l, xshift_r, xmask, \
^
1 warning generated.
SOC_VALUE_ENUM_DOUBLE_DECL already has a const specifier. Remove the duplicate
const to clean up the warning.
Fixes:
42444979e710 ("Add support for all the downstream rpi sound card drivers")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Nathan Chancellor [Tue, 1 Feb 2022 00:12:10 +0000 (17:12 -0700)]
misc: bcm2835_smi: Use proper enum types for dma_{,un}map_single()
Clang warns:
drivers/misc/bcm2835_smi.c:692:4: warning: implicit conversion from enumeration type 'enum dma_transfer_direction' to different enumeration type 'enum dma_data_direction' [-Wenum-conversion]
DMA_MEM_TO_DEV);
^~~~~~~~~~~~~~~
./include/linux/dma-mapping.h:406:66: note: expanded from macro 'dma_map_single'
#define dma_map_single(d, a, s, r) dma_map_single_attrs(d, a, s, r, 0)
~~~~~~~~~~~~~~~~~~~~ ^
drivers/misc/bcm2835_smi.c:705:35: warning: implicit conversion from enumeration type 'enum dma_transfer_direction' to different enumeration type 'enum dma_data_direction' [-Wenum-conversion]
(inst->dev, phy_addr, n_bytes, DMA_MEM_TO_DEV);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
./include/linux/dma-mapping.h:407:70: note: expanded from macro 'dma_unmap_single'
#define dma_unmap_single(d, a, s, r) dma_unmap_single_attrs(d, a, s, r, 0)
~~~~~~~~~~~~~~~~~~~~~~ ^
drivers/misc/bcm2835_smi.c:751:12: warning: implicit conversion from enumeration type 'enum dma_transfer_direction' to different enumeration type 'enum dma_data_direction' [-Wenum-conversion]
DMA_DEV_TO_MEM);
^~~~~~~~~~~~~~~
./include/linux/dma-mapping.h:406:66: note: expanded from macro 'dma_map_single'
#define dma_map_single(d, a, s, r) dma_map_single_attrs(d, a, s, r, 0)
~~~~~~~~~~~~~~~~~~~~ ^
drivers/misc/bcm2835_smi.c:761:50: warning: implicit conversion from enumeration type 'enum dma_transfer_direction' to different enumeration type 'enum dma_data_direction' [-Wenum-conversion]
dma_unmap_single(inst->dev, phy_addr, n_bytes, DMA_DEV_TO_MEM);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
./include/linux/dma-mapping.h:407:70: note: expanded from macro 'dma_unmap_single'
#define dma_unmap_single(d, a, s, r) dma_unmap_single_attrs(d, a, s, r, 0)
~~~~~~~~~~~~~~~~~~~~~~ ^
4 warnings generated.
Use the proper enumerated type to clear up the warning. There is not
actually a bug here because the enumerated types have the same integer
value:
DMA_MEM_TO_DEV = DMA_TO_DEVICE = 1
DMA_DEV_TO_MEM = DMA_FROM_DEVICE = 2
Fixes:
93254d0f7bc8 ("Add SMI driver")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
coldspark29 [Wed, 18 Aug 2021 11:41:04 +0000 (13:41 +0200)]
overlays: Add MAX30102 HR to i2c-sensor overlay
Add support for the MAX30102 heart rate and blood oxygen sensor to the
i2c-sensor overlay.
See: https://github.com/raspberrypi/linux/pull/4535
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
coldspark29 [Wed, 18 Aug 2021 12:42:22 +0000 (14:42 +0200)]
configs: Add CONFIG_MAX30102=m
See: https://github.com/raspberrypi/linux/pull/4535
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Dave Stevenson [Wed, 8 Apr 2020 15:12:02 +0000 (16:12 +0100)]
drm/vc4_hdmi: Add Broadcast RGB property to allow override of RGB range
Copy Intel's "Broadcast RGB" property semantics to add manual override
of the HDMI pixel range for monitors that don't abide by the content
of the AVI Infoframe.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
David Plowman [Tue, 25 Jan 2022 15:48:53 +0000 (15:48 +0000)]
media: i2c: imx219: Correct the minimum vblanking value
The datasheet for this sensor documents the minimum vblanking as being
32 lines. It does fix some problems with occasional black lines at the
bottom of images (tested on Raspberry Pi).
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Andreas Watterott [Sat, 22 Jan 2022 11:32:09 +0000 (12:32 +0100)]
update rpi-display-overlay.dts pins for 5.10+
backlight has been turned off
Phil Elwell [Fri, 21 Jan 2022 12:24:57 +0000 (12:24 +0000)]
ARM: dts: BCM2711 AON_INTR2 generates IRQ edges
THe AON_INTR2 controller manages the HDMI interrupts, combining them
into a single interrupt passed to the GIC. bcm2711.dtsi declares the
interrupt as being IRQ_TYPE_LEVEL_HIGH, but it should be
IRQ_TYPE_EDGE_RISING. Most of the time the distinction shouldn't
matter, but there is a small possibility of losing interrupts unless
it is corrected.
See: http://lists.infradead.org/pipermail/linux-arm-kernel/2022-January/710292.html
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Dave Stevenson [Fri, 21 Jan 2022 15:12:25 +0000 (15:12 +0000)]
dtoverlays: Correct [h|v]sync_invert config in vc4-kms-dpi-generic
Both the base node and override set these parameters to 0,
so it made no difference. The base node should have been 1.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Fri, 21 Jan 2022 14:22:01 +0000 (14:22 +0000)]
dtoverlays: Add pwm backlight option to vc4-kms-dpi-generic
Adds the option of a PWM controlled backlight on a generic
DPI display.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Fri, 21 Jan 2022 14:11:57 +0000 (14:11 +0000)]
defconfig: Add BACKLIGHT_PWM to bcm2709 and bcmrpi defconfigs
BACKLIGHT_PWM can be used with DPI displays, so add it to the
defconfig.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Fri, 22 Oct 2021 15:48:50 +0000 (16:48 +0100)]
drm/vc4: dsi: Correct max divider to 255 (not 7)
The integer divider from parent PLL to DSI clock is capable
of going up to /255, not just /7 that the driver was trying.
This allows for slower link frequencies on the DSI bus where
the resolution permits.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Phil Elwell [Fri, 21 Jan 2022 08:49:13 +0000 (08:49 +0000)]
arm: Remove spurious .fnend directive
...a.k.a. Fix annoying build error
Some toolchains rightly object to the fact that once the acros are
expanded this results in multiple ".fnend"s without ".fnstart"s.
See: https://github.com/raspberrypi/linux/issues/4836
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Naushir Patuck [Tue, 18 Jan 2022 13:13:14 +0000 (13:13 +0000)]
drivers: bcm2835_unicam: Disable trigger mode operation
On a Pi3 B/B+ platform the imx219 sensor frequently generates a single corrupt
frame when the sensor first starts. This can either be a missing line, or
invalid samples within the line. This only occurrs using the Unicam kernel
driver.
Disabling trigger mode elimiates this corruption. Since trigger mode is a
legacy feature copied from the firmware driver and not expected to be needed,
remove it. Tested on the Raspberry Pi cameras and shows no ill effects.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Dave Stevenson [Wed, 19 Jan 2022 17:29:13 +0000 (17:29 +0000)]
dtoverlays: Add option for PoE HAT to use Linux I2C instead of FW.
Adds parameter "i2c" to use the PoE HAT I2C MFD driver to instantiate
the PoE HAT drivers, instead of being off the firmware.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Wed, 19 Jan 2022 17:33:14 +0000 (17:33 +0000)]
defconfigs: Add MFD_RASPBERRYPI_POE_HAT to Pi defconfigs.
Required for PoE HAT when driven from Linux over I2C.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Thu, 20 Jan 2022 15:50:27 +0000 (15:50 +0000)]
power: rpi-poe: Add option of being created by MFD or FW
The firmware can only use I2C0 if the kernel isn't, therefore
with libcamera and DRM using it the PoE HAT fan control needs
to move to the kernel.
Add the option for the driver to be created by the PoE HAT core
MFD driver, and use the I2C regmap that provides to control fan
functions.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Thu, 20 Jan 2022 15:48:03 +0000 (15:48 +0000)]
power: rpi-poe: Drop CURRENT_AVG as it is not hardware averaged
As documented the _AVG parameters are meant to be hardware
averaged, but the implementation for the PoE+ HAT was done in
software in the firmware.
Drop the property.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Wed, 19 Jan 2022 17:26:22 +0000 (17:26 +0000)]
pwm: raspberrypi-poe: Add option of being created by MFD or FW
The firmware can only use I2C0 if the kernel isn't, therefore
with libcamera and DRM using it the PoE HAT fan control needs
to move to the kernel.
Add the option for the driver to be created by the PoE HAT core
MFD driver, and use the I2C regmap that provides to control fan
functions.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Wed, 19 Jan 2022 17:22:57 +0000 (17:22 +0000)]
mfd: simple-mfd-i2c: Add configuration for RPi POE HAT
The Raspbery Pi PoE+ HAT exposes a fan controller and power
supply status reporting via a single I2C address.
Create an MFD device that allows loading of the relevant
sub-drivers, with a shared I2C regmap.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Phil Elwell [Wed, 12 Jan 2022 14:39:46 +0000 (14:39 +0000)]
ARM: dts: Remove VL805 USB node from CM4 dts
Neither the CM4 module nor the CM4IO board have a VL805 USB3
controller. The existing "usb@0,0" node is a hangover from the
Pi 4 dts; delete it. An up-to-date firmware will automatically load
the vl805 overlay on CM4s with VL805=1 in the EEPROM config, ensuring
that the firmware is notified of any PCIe reset.
See: https://forums.raspberrypi.com/viewtopic.php?t=326088
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Dom Cobley [Thu, 13 Jan 2022 15:47:23 +0000 (15:47 +0000)]
drm/vc4: hdmi: Fix clock value used for validating hdmi modes
We are using mode->crt_clock here which is filled by drm_mode_set_crtcinfo()
which is called right after .mode_valid.
Use mode->clock which is valid here.
Fixes:
624d93a4f0 ("drm/vc4: hdmi: Move clock calculation into its own function")
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Dave Stevenson [Thu, 13 Jan 2022 11:30:42 +0000 (11:30 +0000)]
drm/vc4: Disable Gamma control on HVS5 due to issues writing the table
Still under investigation, but the conditions under which the HVS
will accept values written to the gamma PWL are not straightforward.
Disable gamma on HVS5 again until it can be resolved to avoid
gamma being enabled with an incorrect table.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Phil Elwell [Wed, 12 Jan 2022 17:27:03 +0000 (17:27 +0000)]
arm: Fix annoying .eh_frame section warnings
Replace the cfi directives with the UNWIND equivalents. This prevents
the .eh_frame section from being created, eliminating the warnings.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Phil Elwell [Wed, 12 Jan 2022 12:48:53 +0000 (12:48 +0000)]
overlays: Add vl805 overlay
With the automatic VL805 support being removed from the standard
CM4 dtb (since most CM4 carriers don't have a VL805), retain support
on those that do by creating a "vl805" overlay that restores the
deleted "usb@0,0" node.
The "vl805" overlay will be loaded automatically (after an upcoming
firmware update) on CM4 boards where the EEPROM config includes the
setting VL805=1.
See: https://forums.raspberrypi.com/viewtopic.php?t=326088
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Phil Elwell [Tue, 11 Jan 2022 10:48:30 +0000 (10:48 +0000)]
arm: Fix custom rpi __memset32 and __memset64
See: https://github.com/raspberrypi/linux/issues/4798
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Dave Stevenson [Sat, 8 Jan 2022 13:24:10 +0000 (13:24 +0000)]
drm/vc4: Add alpha_blend_mode property to each plane.
Move from only supporting the default of pre-multiplied
alpha to supporting user specified blend mode using the
standardised property.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
marcone [Mon, 10 Jan 2022 19:37:39 +0000 (11:37 -0800)]
configs: add CONFIG_LEDS_TRIGGER_PATTERN=m
Enable the pattern led trigger.
Signed-off-by: Marco Nelissen <marco.nelissen@gmail.com>
Dave Stevenson [Fri, 7 Jan 2022 11:12:08 +0000 (11:12 +0000)]
dtoverlays: Add backlight-gpio parameter to vc4-kms-dpi-generic
To allow for the cases where a simple panel does have a GPIO
controlled backlight. Defaults to having no backlight defined.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Jeff LaBundy [Tue, 29 Jan 2019 05:11:47 +0000 (23:11 -0600)]
overlays: Add overlay for Azoteq IQS550
This patch adds a device tree overlay for the Azoteq IQS550
trackpad/touchscreen controller.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Jeff LaBundy [Wed, 30 Jan 2019 01:35:45 +0000 (19:35 -0600)]
configs: Enable Azoteq IQS550/572/525
This patch enables the Azoteq IQS550/572/525 trackpad/touchscreen
controller as a module.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Padmanabha Srinivasaiah [Thu, 30 Dec 2021 20:45:10 +0000 (21:45 +0100)]
bcm2835-v4l2-isp: Add missing lock initialization
ISP device allocation is dynamic hence the locks too.
struct mutex queue_lock is not initialized which result in bug.
Fixing same by initializing it.
[ 29.847138] INFO: trying to register non-static key.
[ 29.847156] The code is fine but needs lockdep annotation, or maybe
[ 29.847159] you didn't initialize this object before use?
[ 29.847161] turning off the locking correctness validator.
[ 29.847167] CPU: 1 PID: 343 Comm: v4l_id Tainted: G C 5.15.11-rt24-v8+ #8
[ 29.847187] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
[ 29.847194] Call trace:
[ 29.847197] dump_backtrace+0x0/0x1b8
[ 29.847227] show_stack+0x20/0x30
[ 29.847240] dump_stack_lvl+0x8c/0xb8
[ 29.847254] dump_stack+0x18/0x34
[ 29.847263] register_lock_class+0x494/0x4a0
[ 29.847278] __lock_acquire+0x80/0x1680
[ 29.847289] lock_acquire+0x214/0x3a0
[ 29.847300] mutex_lock_nested+0x70/0xc8
[ 29.847312] _vb2_fop_release+0x3c/0xa8 [videobuf2_v4l2]
[ 29.847346] vb2_fop_release+0x34/0x60 [videobuf2_v4l2]
[ 29.847367] v4l2_release+0xc8/0x108 [videodev]
[ 29.847453] __fput+0x8c/0x258
[ 29.847476] ____fput+0x18/0x28
[ 29.847487] task_work_run+0x98/0x180
[ 29.847502] do_notify_resume+0x228/0x3f8
[ 29.847515] el0_svc+0xec/0xf0
[ 29.847523] el0t_64_sync_handler+0x90/0xb8
[ 29.847531] el0t_64_sync+0x180/0x184
Signed-off-by: Padmanabha Srinivasaiah <treasure4paddy@gmail.com>
Andreas Blaesius [Wed, 5 Jan 2022 19:38:39 +0000 (20:38 +0100)]
Use GitHubs issue form for bug reports
Use GitHubs issue form for bug reports.
- modern look
- user don't need to mess with given markdown parts while filling the issue template
Setup config.yml for general questions and problems with the Raspbian distribution packages.
Dave Stevenson [Tue, 4 Jan 2022 14:46:01 +0000 (14:46 +0000)]
media: i2c: ov9281: Increase diff between VTS and max exposure
The driver did allow the exposure to go up to VTS - 4 lines,
but this would produce a visible line on 1280x800, and a stall of
the sensor at 640x480.
Whilst it appears to work with a difference of 5, the datasheet states
there should be at least 25 lines difference between VTS and exposure,
so use that value.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Andriy Gelman [Sun, 2 Jan 2022 17:22:52 +0000 (12:22 -0500)]
staging/bcm2835-codec: Fix typo
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Matthias Reichl [Thu, 30 Dec 2021 14:12:19 +0000 (15:12 +0100)]
drm/vc4: hdmi: Fix no video output on DVI monitors
The drm edid parser doesn't signal RGB support on DVI monitors
with old edid versions, leading to 8-bit RGB mode being rejected
and no video on DVI monitors.
As 8-bit RGB is mandatory on HDMI and DVI monitors anyways we can
simply drop the RGB format check, aligning vc4 with other drivers.
Signed-off-by: Matthias Reichl <hias@horus.com>
Matthias Reichl [Thu, 30 Dec 2021 13:28:37 +0000 (14:28 +0100)]
drm/vc4: hdmi: Fix HDMI monitor detection in polled mode
When vc4_hdmi_connector_detect() was called in
connector_status_connected state it incorrectly cleared the
hdmi_monitor flag, leading to no audio on RPi3.
Fix this by clearing hdmi_monitor only when the hpd check
indicated no connection or if reading the edid failed.
Signed-off-by: Matthias Reichl <hias@horus.com>
Dave Stevenson [Tue, 4 Jan 2022 13:56:42 +0000 (13:56 +0000)]
uapi/v4l2-controls: Reset V4L2_CID_USER_BCM2835_ISP_BASE to same as 5.10
https://github.com/raspberrypi/linux/issues/4440
Upstream has added additional device specific controls, so the
V4L2_CID_USER_BASE + 0x10e0 value that had been defined for use with
the ISP has been taken by something else (and +0x10f0 has been used as
well)
Duplicate the use on V4L2_CID_USER_BASE + 0x10e0 so that userspace
(libcamera) doesn't need to change. Once the driver is upstream, then
we'll update libcamera to adopt the new value as it then won't change.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Jakub Vaněk [Tue, 28 Dec 2021 14:43:10 +0000 (15:43 +0100)]
dtoverlays: Enable cam1_clock when using tc358743 or irs1125
This fixes a regression introduced in
131f1322039284932ccb601a5cffdd9ca5d36d96
(see also https://github.com/raspberrypi/linux/issues/4791).
The tc358743 driver refused to bind to the device. The irs1125
driver is likely behaving similarly.
The new unified cam1_clk node that represents the fixed on-board
oscillator is marked as disabled by default. These overlays didn't
expect this and so the clock nodes were stuck in disabled state.
This commit just adds the required status = "okay" line. Other sensor
drivers do this too.
Penk Chen [Sun, 19 Dec 2021 18:46:26 +0000 (03:46 +0900)]
Add panel overlay for CutiePi
Signed-off-by: Penk Chen <penk@cutiepi.io>
Penk Chen [Sun, 19 Dec 2021 18:45:46 +0000 (03:45 +0900)]
Enable ili9881 panel and pwm backlight driver by default
Signed-off-by: Penk Chen <penk@cutiepi.io>
Penk Chen [Sun, 19 Dec 2021 18:44:56 +0000 (03:44 +0900)]
Extending ili9881c driver support for nwe080 panel
Signed-off-by: Penk Chen <penk@cutiepi.io>
David Plowman [Mon, 16 Aug 2021 11:39:09 +0000 (13:39 +0200)]
media: v4l2-ctrls: Document V4L2_CID_NOTIFY_GAINS control
commit
311a839a1ad255ebcb7291fb4e0d2ec2f32312a7 upstream.
Add documentation for the V4L2_CID_NOTIFY_GAINS control.
This control is required by sensors that need to know what colour
gains will be applied to pixels by downstream processing (such as by
an ISP), though the sensor does not apply these gains itself.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
David Plowman [Mon, 16 Aug 2021 11:39:08 +0000 (13:39 +0200)]
media: v4l2-ctrls: Add V4L2_CID_NOTIFY_GAINS control
commit
a9c80593ff80ddb7c6496624e5384e1ea3460a72 upstream.
We add a new control V4L2_CID_NOTIFY_GAINS which allows the sensor to
be notified what gains will be applied to the different colour
channels by subsequent processing (such as by an ISP), even though the
sensor will not apply any of these gains itself.
For Bayer sensors this will be an array control taking 4 values which
are the 4 gains arranged in the fixed order B, Gb, Gr and R,
irrespective of the exact Bayer order of the sensor itself. The use of
an array makes it straightforward to extend this control to non-Bayer
sensors (for example, sensors with an RGBW pattern) in future.
The units are in all cases linear with the default value indicating a
gain of exactly 1.0. For example, if the default value were reported as
128 then the value 192 would represent a gain of exactly 1.5.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Maxime Ripard [Fri, 4 Dec 2020 16:12:06 +0000 (17:12 +0100)]
drm/vc4: hdmi: Support HDMI YUV output
In addition to the RGB444 output, the BCM2711 HDMI controller supports
the YUV444 and YUV422 output formats.
Let's add support for them in the driver, but still use RGB as the
preferred format.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Fri, 10 Dec 2021 14:29:56 +0000 (15:29 +0100)]
drm/vc4: hdmi: Always try to have the highest bpc
Currently we take the max_bpc property as the bpc value and do not try
anything else.
However, what the other drivers seem to be doing is that they would try
with the highest bpc allowed by the max_bpc property and the hardware
capabilities, test if it results in an acceptable configuration, and if
not decrease the bpc and try again.
Let's use the same logic.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Fri, 10 Dec 2021 14:00:04 +0000 (15:00 +0100)]
drm/vc4: hdmi: Take bpp into account for the scrambler
The current code only base its decision for whether the scrambler must be
enabled or not on the pixel clock of the mode, but doesn't take the bits
per color into account.
Let's leverage the new function to compute the clock rate in the
scrambler setup code.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Mon, 13 Dec 2021 14:33:11 +0000 (15:33 +0100)]
drm/vc4: hdmi: Take the sink maximum TMDS clock into account
In the function that validates that the clock isn't too high, we've only
taken our controller limitations into account so far.
However, the sink can have a limit on the maximum TMDS clock it can deal
with too which is exposed through the EDID and the drm_display_info.
Make sure we check it.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Thu, 2 Dec 2021 16:04:18 +0000 (17:04 +0100)]
drm/vc4: hdmi: Move clock calculation into its own function
The code to compute our clock rate for a given setup will be called in
multiple places in the next patches, so let's create a separate function
for it.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Thu, 2 Dec 2021 15:58:17 +0000 (16:58 +0100)]
drm/vc4: hdmi: Move clock validation to its own function
Our code is doing the same clock rate validation in multiple instances.
Let's create a helper to share the rate validation.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Mon, 18 Jan 2021 08:51:12 +0000 (09:51 +0100)]
drm/vc4: hdmi: Change CSC callback prototype
In order to support the YUV output, we'll need the atomic state to know
what is the state of the associated property in the CSC setup callback.
Let's change the prototype of that callback to allow us to access it.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Wed, 13 Jan 2021 10:30:21 +0000 (11:30 +0100)]
drm/vc4: hdmi: Define colorspace matrices
The current CSC setup code for the BCM2711 uses a sequence of register
writes to configure the CSC depending on whether we output using a full
or limited range.
However, with the upcoming introduction of the YUV output, we're going
to add new matrices to perform the conversions, so we should switch to
something a bit more flexible that takes the matrix as an argument and
programs the CSC accordingly.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Wed, 13 Jan 2021 10:20:08 +0000 (11:20 +0100)]
drm/vc4: hdmi: Replace CSC_CTL hardcoded value by defines
On BCM2711, the HDMI_CSC_CTL register value has been hardcoded to an
opaque value. Let's replace it with properly defined values.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Wed, 13 Jan 2021 10:07:48 +0000 (11:07 +0100)]
drm/vc4: hdmi: Move XBAR setup to csc_setup
On the BCM2711, the HDMI_VEC_INTERFACE_XBAR register configuration
depends on whether we're using an RGB or YUV output. Let's move that
configuration to the CSC setup.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Tue, 12 Jan 2021 14:57:50 +0000 (15:57 +0100)]
drm/vc4: hdmi: Use full range helper in csc functions
The CSC callbacks takes a boolean as an argument to tell whether we're
using the full range or limited range RGB.
However, with the upcoming YUV support, the logic will be a bit more
complex. In order to address this, let's make the callbacks take the
entire mode, and call our new helper to tell whether the full or limited
range RGB should be used.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Tue, 12 Jan 2021 14:55:07 +0000 (15:55 +0100)]
drm/vc4: hdmi: Add full range RGB helper
We're going to need to tell whether we want to run with a full or
limited range RGB output in multiple places in the code, so let's create
a helper that will return whether we need with full range or not.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Wed, 14 Apr 2021 14:21:08 +0000 (16:21 +0200)]
drm/edid: Rename drm_hdmi_avi_infoframe_colorspace to _colorimetry
The drm_hdmi_avi_infoframe_colorspace() function actually sets the
colorimetry and extended_colorimetry fields in the hdmi_avi_infoframe
structure with DRM_MODE_COLORIMETRY_* values.
To make things worse, the hdmi_avi_infoframe structure also has a
colorspace field used to signal whether an RGB or YUV output is being
used.
Let's remove the inconsistency and allow for the colorspace usage by
renaming the function.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Mon, 13 Dec 2021 12:47:51 +0000 (13:47 +0100)]
drm/edid: Don't clear YUV422 if using deep color
The current code, when parsing the EDID Deep Color depths, that the
YUV422 cannot be used, referring to the HDMI 1.3 Specification.
This specification, in its section 6.2.4, indeed states:
For each supported Deep Color mode, RGB 4:4:4 shall be supported and
optionally YCBCR 4:4:4 may be supported.
YCBCR 4:2:2 is not permitted for any Deep Color mode.
This indeed can be interpreted like the code does, but the HDMI 1.4
specification further clarifies that statement in its section 6.2.4:
For each supported Deep Color mode, RGB 4:4:4 shall be supported and
optionally YCBCR 4:4:4 may be supported.
YCBCR 4:2:2 is also 36-bit mode but does not require the further use
of the Deep Color modes described in section 6.5.2 and 6.5.3.
This means that, even though YUV422 can be used with 12 bit per color,
it shouldn't be treated as a deep color mode.
This deviates from the interpretation of the code and comment, so let's
fix those.
Fixes:
d0c94692e0a3 ("drm/edid: Parse and handle HDMI deep color modes.")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Dom Cobley [Fri, 10 Dec 2021 18:03:18 +0000 (18:03 +0000)]
drm/vc4: Skip writes to disabled packet RAM
This path actually occurs when audio is started during a hdmi mode set.
As the data will be written by vc4_hdmi_set_infoframes when packet RAM
is enabled again, don't treat as an error
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Maxime Ripard [Mon, 6 Dec 2021 15:32:10 +0000 (16:32 +0100)]
drm/vc4: hvs: Ignore atomic_flush if we're disabled
atomic_flush will be called for each CRTC even if they aren't enabled.
The whole code we have there will thus run without a properly affected
channel, which can then result in all sorts of weird behaviour.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Mon, 6 Dec 2021 15:31:33 +0000 (16:31 +0100)]
drm/vc4: hvs: Move the dlist setup to its own function
The vc4_hvs_update_dlist function mostly deals with setting up the
vblank events and setting up the dlist entry pointer to our current
active one.
We'll want to do the former separately from the vblank handling in later
patches, so let's move it to a function of its own.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Mon, 6 Dec 2021 15:17:56 +0000 (16:17 +0100)]
drm/vc4: hvs: Remove dlist setup duplication
Setting the DISPLISTx register needs to occur in every case, and we
don't need to protect the register using the event_lock, so we can just
move it after the if branches and simplify a bit the function.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Mon, 29 Nov 2021 11:18:39 +0000 (12:18 +0100)]
drm/vc4: hvs: Store channel in variable
The assigned_channel field of our vc4_crtc_state structure is accessed
multiple times in vc4_hvs_atomic_flush, so let's move it to a variable
that can be used in all those places.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Thu, 18 Nov 2021 13:04:00 +0000 (14:04 +0100)]
drm/vc4: kms: Take old state core clock rate into account
During a commit, the core clock, which feeds the HVS, needs to run at
a minimum of 500MHz.
While doing that commit, we can also change the mode to one that
requires a higher core clock, so we take the core clock rate associated
to that new state into account for that boost.
However, the old state also needs to be taken into account if it
requires a core clock higher that the new one and our 500MHz limit,
since it's still live in hardware at the beginning of our commit.
Fixes:
16e101051f32 ("drm/vc4: Increase the core clock based on HVS load")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Phil Elwell [Thu, 16 Dec 2021 16:25:00 +0000 (16:25 +0000)]
staging/bcm2835-isp: Fix cleanup after init fail
bcm2835_isp_remove is called on an initialisation failure, but at that
point the drvdata hasn't been set. This causes a crash when e.g. using
the cutdown firmware (gpu_mem=16).
Move platform_set_drvdata before the instance probing loop to avoid the
problem.
See: https://github.com/raspberrypi/linux/issues/4774
Signed-off-by: Phil Elwell <phil@raspberrypi.com>