Dave Stevenson [Fri, 25 Feb 2022 18:16:13 +0000 (18:16 +0000)]
media/i2c: Add driver for Omnivision OV2311
Omnivision OV2311 is a CSI2 1600x1300 global shutter image sensor.
Add a driver for it.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Jonathan Bell [Tue, 1 Mar 2022 15:17:04 +0000 (15:17 +0000)]
usb: xhci: expand the scope of XHCI_VLI_SS_BULK_OUT_BUG
Further testing has revealed that any TRB with buffer length that is not
a multiple of wMaxPacket and not the last TRB in a TD can cause data
corruption.
Work around this by linearising any vulnerable Bulk OUT scatter-gather
URBs prior to URB submission. Normal XHCI TRB formation will split
buffers on 64K boundaries and align TRBs prior to a Link TRB to
wMaxPacket, so keep the residue TRB generation added with the first
iteration of the quirk which will guarantee the last TRB is the only TRB
with an odd buffer size.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
Jonathan Bell [Tue, 1 Mar 2022 15:12:15 +0000 (15:12 +0000)]
usb: xhci: rework XHCI_VLI_SS_BULK_OUT_BUG quirk
Fix incorrectly applying the quirk for bulk IN endpoints and remove the
commentary which is not completely accurate based on observed behaviour.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
Phil Elwell [Fri, 25 Feb 2022 15:08:56 +0000 (15:08 +0000)]
configs: Add CONFIG_TINYDRM_HX8357D=m
See: https://forums.raspberrypi.com/viewtopic.php?t=330088
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Phil Elwell [Fri, 25 Feb 2022 09:53:56 +0000 (09:53 +0000)]
overlays: Add "drm" parameter to pitft35-resistive
The "drm" parameter forces the use of the hx8357d DRM driver, when by
default the fb_hx8357d framebuffer driver will be used in preference.
See: https://forums.raspberrypi.com/viewtopic.php?t=330088
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
nmbath [Thu, 24 Feb 2022 13:10:01 +0000 (13:10 +0000)]
overlays: Overlays for WaveShare 2-Chan CAN FD HAT
This patch adds the overlays for the Waveshare 2-Channel Isolated
CAN FD Expansion HAT for Raspberry Pi, Multi Protections. This HAT
is based on the mcp2518fd chip and can be run in two modes
Mode A: can0 on spi0.0 and can1 on spi1.0 (cs = pin 26)
Mode B: can1 on spi0.0 and can1 in spi0.1
Interupts: can0 pin 25 / can1 pin 16
https://www.waveshare.com/2-ch-can-fd-hat.htm
Overlays generated by:
Mode A: ovmerge -c spi1-1cs-overlay.dts,cs0_pin=26,cs0_spidev=false \
mcp251xfd-overlay.dts,spi0-0,interrupt=25 \
mcp251xfd-overlay.dts,spi1-0,interrupt=16
Mode B: ovmerge -c mcp251xfd-overlay.dts,spi0-0,interrupt=25 \
mcp251xfd-overlay.dts,spi0-1,interrupt=16
Joerg Schambacher [Wed, 23 Feb 2022 11:08:42 +0000 (12:08 +0100)]
overlays:fixes probing of Hifiberry DAC2 HD
Removed clocks-declarations in I2C sections of the DT-overlay
which kept the devices from probing.
Signed-off-by: Joerg Schambacher <joerg@hifiberry.com>
Phil Elwell [Sun, 20 Feb 2022 16:27:11 +0000 (16:27 +0000)]
ARM: dts: Add GPIO line names for downstream RPis
Largely copied from the upstream dts files, with a few additions and
tweaks.
See: https://github.com/raspberrypi/linux/issues/2760
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Maxime Ripard [Thu, 16 Dec 2021 13:54:54 +0000 (14:54 +0100)]
drm/vc4: hvs: Defer dlist slots deallocation
During normal operations, the cursor position update is done through an
asynchronous plane update, which on the vc4 driver basically just
modifies the right dlist word to move the plane to the new coordinates.
However, when we have the overscan margins setup, we fall back to a
regular commit when we are next to the edges. And since that commit
happens to be on a cursor plane, it's considered a legacy cursor update
by KMS.
The main difference it makes is that it won't wait for its completion
(ie, next vblank) before returning. This means if we have multiple
commits happening in rapid succession, we can have several of them
happening before the next vblank.
In parallel, our dlist allocation is tied to a CRTC state, and each time
we do a commit we end up with a new CRTC state, with the previous one
being freed. This means that we free our previous dlist entry (but don't
clear it though) every time a new one is being committed.
Now, if we were to have two commits happening before the next vblank, we
could end up freeing reusing the same dlist entries before the next
vblank.
Indeed, we would start from an initial state taking, for example, the
dlist entries 10 to 20, then start a commit taking the entries 20 to 30
and setting the dlist pointer to 20, and freeing the dlist entries 10 to
20. However, since we haven't reach vblank yet, the HVS is still using
the entries 10 to 20.
If we were to make a new commit now, chances are the allocator are going
to give the 10 to 20 entries back, and we would change their content to
match the new state. If vblank hasn't happened yet, we just corrupted
the active dlist entries.
A first attempt to solve this was made by creating an intermediate dlist
buffer to store the current (ie, as of the last commit) dlist content,
that we would update each time the HVS is done with a frame. However, if
the interrupt handler missed the vblank window, we would end up copying
our intermediate dlist to the hardware one during the composition,
essentially creating the same issue.
Since making sure that our interrupt handler runs within a fixed,
constrained, time window would require to make Linux a real-time kernel,
this seems a bit out of scope.
Instead, we can work around our original issue by keeping the dlist
slots allocation longer. That way, we won't reuse a dlist slot while
it's still in flight. In order to achieve this, instead of freeing the
dlist slot when its associated CRTC state is destroyed, we'll queue it
in a list.
A naive implementation would free the buffers in that queue when we get
our end of frame interrupt. However, there's still a race since, just
like in the shadow dlist case, we don't control when the handler for
that interrupt is going to run. Thus, we can end up with a commit adding
an old dlist allocation to our queue during the window between our
actual interrupt and when our handler will run. And since that buffer is
still being used for the composition of the current frame, we can't free
it right away, exposing us to the original bug.
Fortunately for us, the hardware provides a frame counter that is
increased each time the first line of a frame is being generated.
Associating the frame counter the image is supposed to go away to the
allocation, and then only deallocate buffers that have a counter below
or equal to the one we see when the deallocation code should prevent the
above race from occuring.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Mon, 14 Feb 2022 16:21:05 +0000 (17:21 +0100)]
drm/vc4: hvs: Use pointer to HVS in HVS_READ and HVS_WRITE macros
Those macros are really about the HVS itself, and thus its associated
structure vc4_hvs, rather than the entire (virtual) vc4 device.
Let's change those macros to use the hvs pointer directly, and change
the calling sites accordingly.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Thu, 17 Feb 2022 09:55:26 +0000 (10:55 +0100)]
drm/vc4: hvs: Fix frame count register readout
In order to get the field currently being output, the driver has been
using the display FIFO frame count in the HVS, reading a 6-bit field at
the offset 12 in the DISPSTATx register.
While that field is indeed at that location for the FIFO 1 and 2, the
one for the FIFO0 is actually in the DISPSTAT1 register, at the offset
18.
Fixes:
e538092cb15c ("drm/vc4: Enable precise vblank timestamping for interlaced modes.")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Dave Stevenson [Thu, 17 Feb 2022 18:12:36 +0000 (18:12 +0000)]
dtoverlays: Switch ov7251 to using Media Controller by default
We should have all the functionality required by now, so switch
to using Media Controller so that it can be used with libcamera.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Thu, 17 Feb 2022 18:31:56 +0000 (18:31 +0000)]
media: i2c: ov7251: Switch from V4L2_CID_GAIN to V4L2_CID_ANALOGUE_GAIN
The control is specifically for analogue gain, therefore switch
to using the control for that.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Thu, 17 Feb 2022 18:08:39 +0000 (18:08 +0000)]
media: i2c: ov7251: Add V4L2_CID_VBLANK
This is a raw sensor so should be implementing V4L2_CID_VBLANK
instead of the frame_interval ops, as per docs at
https://www.kernel.org/doc/html/latest/driver-api/media/camera-sensor.html#frame-interval-configuration
This driver already implemented the frame_interval ops, so
removing them would be a regression.
Implement V4L2_CID_VBLANK, with the frame_interval ops setting
that control.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Thu, 17 Feb 2022 17:00:27 +0000 (17:00 +0000)]
media: i2c: ov7251: Separate modes from frame intervals
The modes and frame intervals are independent, therefore
separate them into 2 structures.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Thu, 17 Feb 2022 16:44:33 +0000 (16:44 +0000)]
media: i2c: ov7251: Limit exposure based on VTS
The maximum exposure is dictated by VTS, so compute it rather
than having the value in the mode table.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Thu, 17 Feb 2022 16:24:51 +0000 (16:24 +0000)]
media: i2c: ov7251: Set VTS instead of having full tables for FPS.
The driver did have a full copy of the registers for each of
the 30, 60, and 90 fps modes. The main difference between them were
registers 0x380e/f which set the total height of the frame (VTS).
Remove the excess register settings, and Set that register value
explicitly for each mode.
This has dropped a change for the 30fps mode to registers 0x3016,
0x3017, 0x3018, 0x301a, 0x301b, and 0x301c. The data available
doesn't describe these registers, but the sensor seems fully
functional without the alternate settings.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Thu, 17 Feb 2022 16:23:23 +0000 (16:23 +0000)]
media: i2c: ov7251: Add get_selection for NATIVE_SIZE, CROP_BOUNDS, CROP_DEFAULT
As required by libcamera, add get_selection handling for
V4L2_SEL_TGT_NATIVE_SIZE, V4L2_SEL_TGT_CROP_DEFAULT, and
V4L2_SEL_TGT_CROP_BOUNDS.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Thu, 17 Feb 2022 15:57:01 +0000 (15:57 +0000)]
media: i2c: ov7251: Fix link_freq validation loop
If only one link frequency was configured, then ov7251_check_hwcfg
failed as the conditions weren't checked in the appropriate places.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Sat, 12 Feb 2022 12:33:13 +0000 (12:33 +0000)]
media: i2c: ov7251: Do not reset gain on mode change
There is no reaon why changing mode should reset the analogue
gain of the sensor, and it's not the behaviour that userspace
will be expecting.
Remove the reset.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Sat, 12 Feb 2022 12:05:02 +0000 (12:05 +0000)]
media: i2c: ov7251: Add V4L2_CID_HBLANK control
HBLANK is a fixed value in this driver, so add as a fixed
read-only control.
The value is updated during set_format as the V4L2 control is
dependent on width, even though only one width is actually
defined.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Sat, 12 Feb 2022 11:57:19 +0000 (11:57 +0000)]
media: i2c: ov7251: Initialise current_mode during probe
Initialise ov7251->current_mode during probe to avoid the issue
of a NULL dereference should get_frame_interval be called before
set_frame_interval or set_format.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Sat, 12 Feb 2022 09:53:47 +0000 (09:53 +0000)]
media: i2c: ov7251: V4L2_CID_LINK_FREQUENCY is fixed
The link frequency does not change with the mode, so remove
the special handling for it.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Sat, 12 Feb 2022 09:47:38 +0000 (09:47 +0000)]
media: i2c: ov7251: V4L2_CID_PIXEL_RATE is fixed
The pixel rate doesn't actually change based on the mode, and
can not be set by userspace.
Fix the control. The control is already read only as set by the core.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Thu, 17 Feb 2022 14:48:30 +0000 (14:48 +0000)]
media: i2c: ov7251: Reinstate setting ov7251_global_init_setting
"media: i2c: Remove .s_power() from ov7251" removed the call that
sent ov7251_global_init_setting to the sensor. Send it when starting
streaming.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Daniel Scally [Tue, 15 Feb 2022 23:07:36 +0000 (23:07 +0000)]
media: i2c: Remove .s_power() from ov7251
The .s_power() callback is deprecated, and now that we have pm_runtime
functionality in the driver there's no further use for it. Delete the
function.
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Daniel Scally [Tue, 15 Feb 2022 23:07:35 +0000 (23:07 +0000)]
media: i2c: Add pm_runtime support to ov7251
Add pm_runtime support to the ov7251 driver.
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Daniel Scally [Tue, 15 Feb 2022 23:07:34 +0000 (23:07 +0000)]
media: i2c: Add ov7251_detect_chip()
.probe() is quite busy for this driver; make it cleaner by moving the
chip verification to a dedicated function.
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Daniel Scally [Tue, 15 Feb 2022 23:07:33 +0000 (23:07 +0000)]
media: i2c: Add support for 19.2MHz clock to ov7251
The OV7251 sensor is used as the IR camera sensor on the Microsoft
Surface line of tablets; this provides a 19.2MHz external clock. Add
the ability to support that rate to the driver by defining a new set
of PLL configs. Extend the clock handling in .probe() to check for
either supported frequency.
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Daniel Scally [Tue, 15 Feb 2022 23:07:32 +0000 (23:07 +0000)]
media: i2c: Add ov7251_pll_configure()
Rather than having the pll settings hidden inside mode blobs, define
them in structs and use a dedicated function to set them. This makes
it simpler to extend the driver to support other external clock
frequencies.
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Daniel Scally [Tue, 15 Feb 2022 23:07:31 +0000 (23:07 +0000)]
media: i2c: Provide ov7251_check_hwcfg()
Move the endpoint checking from .probe() to a dedicated function,
and additionally check that the firmware provided link frequencies
are a match for those supported by the driver. Finally, return
-EPROBE_DEFER if the endpoint is not available, as it could be built
by the ipu3-cio2 driver if that probes later.
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Daniel Scally [Tue, 15 Feb 2022 23:07:30 +0000 (23:07 +0000)]
media: i2c: Add acpi support to ov7251
Add support for enumeration through ACPI to the ov7251 driver
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Dave Stevenson [Thu, 17 Feb 2022 15:16:56 +0000 (15:16 +0000)]
dtoverlays: Correct link frequency for ov7251
It was incorrect, so the driver rejected it.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Jonathan Bell [Wed, 16 Feb 2022 14:31:02 +0000 (14:31 +0000)]
usb: xhci: add a quirk for Superspeed bulk OUT transfers on VL805
The VL805 has a bug in its internal FIFO space accounting that results
in bulk OUT babble if a TRB in a large multi-element TD has a data
buffer size that is larger than and not a multiple of wMaxPacketSize for
the endpoint. If the downstream USB3.0 link is congested, or latency is
increased through an intermediate hub, then the VL805 enters a suspected
FIFO overflow condition and transmits repeated, garbled data to the
endpoint.
TDs with TRBs of exact multiples of wMaxPacketSize and smaller than
wMaxPacketSize appear to be handled correctly, so split buffers at a
1024-byte length boundary and put the remainder in a separate smaller
TRB.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
Dave Stevenson [Fri, 11 Feb 2022 14:15:26 +0000 (14:15 +0000)]
drm/vc4: Remove entry to ULPS from vc4_dsi post_disable
Post_disable was sending the D-PHY sequence to put any device
into ULPS suspend mode, and then cutting power to the DSI block.
The power-on reset state of the DSI block is for DSI to be in
an operational state, not ULPS, so it then never sent the sequence
for exiting ULPS. Any attached device that didn't have an external
reset therefore remained in ULPS / standby, and didn't function.
Use of ULPS isn't well specified in DRM, therefore remove entering
it to avoid the above situation.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Wed, 15 Dec 2021 17:57:45 +0000 (17:57 +0000)]
drm/vc4: Convert vc4_dsi to using a bridge instead of encoder.
Remove the encoder functions, and create a bridge attached to
this dumb encoder which implements the same functionality.
As a bridge has state which an encoder doesn't, we need to
add the state management functions as well.
As there is no bridge atomic_mode_set, move the initialisation
code that was in mode_set into _pre_enable.
The code to actually enable and disable sending video are split
from the general control into _enable and _disable.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Wed, 15 Dec 2021 17:47:14 +0000 (17:47 +0000)]
drm/vc4: Convert vc4_dsi to use atomic enable/disable/mode_set.
The atomic calls are preferred as the non-atomic ones
are deprecated. In preparation for conversion to a bridge,
switch to the atomic calls.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Wed, 15 Dec 2021 17:44:49 +0000 (17:44 +0000)]
drm/vc4: Remove splitting the bridge chain from the driver.
Splitting the bridge chain fails for atomic bridges as the
framework can't add the relevant state in
drm_atomic_add_encoder_bridges.
The chain was split because we needed to power up before
calling pre_enable, but that is now done in mode_set, and will
move into the framework.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Mon, 7 Feb 2022 17:14:51 +0000 (17:14 +0000)]
drm/vc4: Move DSI initialisation to encoder_mode_set.
Breaking the bridge chain does not work for atomic bridges/panels
and generally causes issues.
We need to initialise the DSI host before the bridge pre_enables
are called, so move that to encoder_mode_set in the same way that
dw-mipi-dsi does.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Thu, 30 Sep 2021 16:51:16 +0000 (17:51 +0100)]
drm/vc4: Rename bridge to out_bridge
In preparation for converting the encoder to being a bridge,
rename the variable holding the next bridge in the chain to
out_bridge, so that our bridge can be called bridge.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Thu, 20 Jan 2022 17:29:36 +0000 (17:29 +0000)]
drm/bridge: tc358762: Ignore EPROBE_DEFER when logging errors
mipi_dsi_attach can fail due to resources not being available
yet, therefore do not log error messages should they occur.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Fri, 17 Dec 2021 13:36:52 +0000 (13:36 +0000)]
drm/dsi: Document the meaning and spec references for MIPI_DSI_MODE_*
The MIPI_DSI_MODE_* flags have fairly terse descriptions and no reference
to the DSI specification as to their exact meaning. Usage has therefore
been rather fluid.
Extend the descriptions and provide references to the part of the
MIPI DSI specification regarding what they mean.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Mon, 14 Feb 2022 15:59:32 +0000 (15:59 +0000)]
dtoverlays: Add additional mappings to vc4-kms-dpi-generic
Adds mappings for bgr666, bgr666-padhi, and bgr888.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Mon, 14 Feb 2022 15:34:51 +0000 (15:34 +0000)]
drm/vc4: For DPI, MEDIA_BUS_FMT_RGB565_1X16 is mode 1, not 3.
The mapping is incorrect for RGB565_1X16 as it should be
DPI_FORMAT_18BIT_666_RGB_1 instead of DPI_FORMAT_18BIT_666_RGB_3.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
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>