vc4/drm: Handle fractional coordinates using the phase field

Signed-off-by: Dom Cobley <popcornmix@gmail.com>

vc4/drm: vc4_plane: Keep fractional source coords inside state

Signed-off-by: Dom Cobley <popcornmix@gmail.com>

Revert "usb: xhci: expand the scope of XHCI_VLI_SS_BULK_OUT_BUG"

This reverts commit 40686d87f87a46b3abf48a8dcaee5e0a031deafb.

See: https://github.com/raspberrypi/linux/issues/4930

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

drm/vc4: hdmi: Add CSC for BT601/709/2020 limited and full range output

The HVS always composes in the RGB domain, but there is a colourspace
conversion block on the output to allow for sending YCbCr over the
HDMI interface.
The colourspace on that link is configurable via the "Colorspace"
property on the connector, and that updates the infoframes. There
is also selection of limited or full range based on the mode selected
or an override.

Add code to update the CSC as well so that the metadata matches the
image data.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

dtoverlays: Connect the backlight to the pitft35 display

DRM will automatically handle the backlight with the display if
told about the linking, so link the two together.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

overlays: iqs550: Enable interrupt pull-down

The device's active-high interrupt normally serves as a push-pull
output, but becomes high-impedance during bootloader mode. Enable
a pull-down to hold the pin in the inactive state.

Signed-off-by: Jeff LaBundy <jeff@labundy.com>

overlays: Fix cam*_reg_gpio parameter on CM1

See: https://github.com/raspberrypi/linux/pull/4945

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

CM3 cam1_reg and cam1_reg_gpio fix

property name is gpio and not gpios

drm/vc4: Support zpos on all planes

Adds the zpos property to all planes, and creates the dlist
by placing the fragments in the correct order based on zpos.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

drm/object: Add default color encoding and range value at reset

Upstream commit 9a48ab11714c955456fefdd4ab532d324fbef563

The drm_plane_create_color_properties() function asks for an initial
value for the color encoding and range, and will set the associated
plane state variable with that value if a state is present.

However, that function is usually called at a time where there's no
state yet. Since the drm_plane_state reset helper doesn't take care of
reading that value when it's called, it means that in most cases the
initial value will be 0 (so DRM_COLOR_YCBCR_BT601 and
DRM_COLOR_YCBCR_LIMITED_RANGE, respectively), or the drivers will have
to work around it.

Let's add some code in __drm_atomic_helper_plane_state_reset() to get
the initial encoding and range value if the property has been attached
in order to fix this.

Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-19-maxime@cerno.tech

drm/object: Add default zpos value at reset

Upstream commit 1a7998dab5dd3d11bada7e3921781922082e7fe6

The drm_plane_create_zpos_property() function asks for an initial value,
and will set the associated plane state variable with that value if a
state is present.

However, that function is usually called at a time where there's no
state yet. Since the drm_plane_state reset helper doesn't take care of
reading that value when it's called, it means that in most cases the
initial value will be 0, or the drivers will have to work around it.

Let's add some code in __drm_atomic_helper_plane_state_reset() to get
the initial zpos value if the property has been attached in order to fix
this.

Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-8-maxime@cerno.tech

drm/object: Add drm_object_property_get_default_value() function

Upstream commit adf47b75297ebc71c53b6dc2d3c55f42b8fb79fd.

Some functions to create properties (drm_plane_create_zpos_property or
drm_plane_create_color_properties for example) will ask for a range of
acceptable value and an initial one.

This initial value is then stored in the values array for that property.

Let's provide an helper to access this property.

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-7-maxime@cerno.tech

media: i2c: Rename ad5398 to ad5398_vcm

There's already a regulator module called ad5398 that exposes
this device through the regulator API. That is meaningless in
the terms that it uses and how it maps to V4L2, so a new driver
was added. However the module name collision wasn't noted, so
rename it now.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

dtoverlay: Add VCM option to ov5647 overlay

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

dtoverlays: Add VCM option to imx219

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

defconfigs: Add AD5398 VCM to all Pi defconfigs

Supports AD5398 controlled lens, as found on some 3rd party
OV5647 and IMX219 image sensors.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: i2c: ov5647: Use v4l2_async_register_subdev_sensor for lens binding

v4l2_async_register_subdev doesn't bind in lens or flash drivers,
but v4l2_async_register_subdev_sensor does.
Switch to using v4l2_async_register_subdev_sensor.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: i2c: Add driver for AD5398 VCM lens driver

Adds a driver for the Analog Devices AD5398 10 bit
I2C DAC which is commonly used for driving VCM lens
mechanisms.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

dt-bindings: media: i2c: Add binding for ad5398 VCM

Add a binding for Analog Devices AD5398 10bit current
sinking DAC when used as a lens VCM driver.

FIXME: Convert to YAML

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: v4l2-async: Create links during v4l2_async_match_notify()

Upon an async fwnode match, there's some typical behaviour that the
notifier and matching subdev will want to do. For example, a notifier
representing a sensor matching to an async subdev representing its
VCM will want to create an ancillary link to expose that relationship
to userspace.

To avoid lots of code in individual drivers, try to build these links
within v4l2 core.

Signed-off-by: Daniel Scally <djrscally@gmail.com>

media: entity: Add support for ancillary links

Add functions to create ancillary links, so that they don't need to
be manually created by users.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Scally <djrscally@gmail.com>

media: entity: Add link_type_name() helper

Now we have three types of media link, printing the right name during
debug output is slightly more complicated. Add a helper function to
make it easier.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Scally <djrscally@gmail.com>

media: media.h: Add new media link type

To describe in the kernel the connection between devices and their
supporting peripherals (for example, a camera sensor and the vcm
driving the focusing lens for it), add a new type of media link
to introduce the concept of these ancillary links.

Add some elements to the uAPI documentation to explain the new link
type, their purpose and some aspects of their current implementation.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Scally <djrscally@gmail.com>

media: entity: Skip non-data links in graph iteration

When iterating over the media graph, don't follow links that are not
data links.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Scally <djrscally@gmail.com>

bcm2835-codec: /dev/video31 as interface to image_encode JPEG encoder

Signed-off-by: Maxim Devaev <mdevaev@gmail.com>

drm/tc358762: Set the pre_enable_upstream_first flag to configure DSI host

TC358762 wants the DSI host to be prepared before it is powered up, so
set the flag to request that the upstream bridges have their
pre_enable called first.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

drm: Include drm_connector.h from drm_panel.h

drm_panel.h wants to reference enum drm_panel_orientation which is defined
in drm_connector.h (despite the name).
Include drm_connector.h in drm_panel.h to avoid the rare situation where
drm_panel.h is used with drm_connector.h

https://github.com/raspberrypi/linux/issues/4919

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

drm/panel: Add prepare_upstream_first flag to drm_panel

Mapping to the drm_bridge flag pre_enable_upstream_first,
add a new flag prepare_upstream_first to drm_panel to allow
the panel driver to request that the upstream bridge should
be pre_enabled before the panel prepare.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

drm/bridge: Introduce pre_enable_upstream_first to alter bridge init order

DSI sink devices typically want the DSI host powered up and configured
before they are powered up. pre_enable is the place this would normally
happen, but they are called in reverse order from panel/connector towards
the encoder, which is the "wrong" order.

Add a new flag pre_enable_upstream_first that any bridge can set
to swap the order of pre_enable (and post_disable) for that and the
immediately upstream bridge.
Should the immediately upstream bridge also set the
pre_enable_upstream_first flag, the bridge upstream of that will be called
before either of those which requested pre_enable_upstream_first.

eg:
- Panel
- Bridge 1
- Bridge 2 pre_enable_upstream_first
- Bridge 3
- Bridge 4 pre_enable_upstream_first
- Bridge 5 pre_enable_upstream_first
- Bridge 6
- Encoder
Would result in pre_enable's being called as Panel, Bridge 1, Bridge 3,
Bridge 2, Bridge 6, Bridge 5, Bridge 4, Encoder.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

ARM: dts: bcm2711-rpi-ds: Disable the BCM2835 STC

Although BCM2711 still includes the old BCM2835 system timer, the newer
per-core local timers are preferred because they are more efficient to
access and can generate core-specific interrupts. Make the usage clear
by disabling the driver for the old STC.

See: https://github.com/raspberrypi/firmware/issues/1702

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

drm/vc4: txp: Force alpha to be 0xff if it's disabled

If we use a format that has padding instead of the alpha component (such
as XRGB8888), it appears that the Transposer will fill the padding to 0,
disregarding what was stored in the input buffer padding.

This leads to issues with IGT, since it will set the padding to 0xff,
but will then compare the CRC of the two frames which will thus fail.

Fixes: 008095e065a8 ("drm/vc4: Add support for the transposer block")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: txp: Don't set TXP_VSTART_AT_EOF

The TXP_VSTART_AT_EOF will generate a second VSTART signal to the HVS.
However, the HVS waits for VSTART to enable the FIFO and will thus start
filling the FIFO before the start of the frame.

This leads to corruption at the beginning of the first frame, and
content from the previous frame at the beginning of the next frames.

Since one VSTART is enough, let's get rid of it.

Fixes: 008095e065a8 ("drm/vc4: Add support for the transposer block")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: kms: Improve logging

When debugging, finding out what muxing decisions were made and what the
actual core clock rate is is always useful, so let's add some more
messages.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: kms: Warn if we have an incompatible muxing setup

The documentation explicitly states we must prevent the output
2 and 3 from feeding from the same HVS channel.

Let's add a warning to make some noise if we ever find ourselves in such
a case.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: kms: Store channel in local variable

We use the channel from our vc4_crtc_state structure in multiple places,
let's store it in a local variable to make it cleaner.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: hvs: Reset muxes at probe time

By default, the HVS driver will force the HVS output 3 to be muxed to
the HVS channel 2. However, the Transposer can only be assigned to the
HVS channel 2, so whenever we try to use the writeback connector, we'll
mux its associated output (Output 2) to the channel 2.

This leads to both the output 2 and 3 feeding from the same channel,
which is explicitly discouraged in the documentation.

In order to avoid this, let's reset all the output muxes to their reset
value.

Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

staging: vc04_services: codec: Add support for V4L2_PIX_FMT_RGBA32 format

We already support V4L2_PIX_FMT_BGR32 which is the same thing with red
and blue swapped, so it makes sense to include this variant as well.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>

drm/vc4: Fix out of order frames during asynchronous page flips

When doing an asynchronous page flip (PAGE_FLIP ioctl with the
DRM_MODE_PAGE_FLIP_ASYNC flag set), the current code waits for the
possible GPU buffer being rendered through a call to
vc4_queue_seqno_cb().

On the BCM2835-37, the GPU driver is part of the vc4 driver and that
function is defined in vc4_gem.c to wait for the buffer to be rendered,
and once it's done, call a callback.

However, on the BCM2711 used on the RaspberryPi4, the GPU driver is
separate (v3d) and that function won't do anything. This was working
because we were going into a path, due to uninitialized variables, that
was always scheduling the callback.

However, we were never actually waiting for the buffer to be rendered
which was resulting in frames being displayed out of order.

The generic API to signal those kind of completion in the kernel are the
DMA fences, and fortunately the v3d drivers supports them and signal
when its job is done. That API also provides an equivalent function that
allows to have a callback being executed when the fence is signalled as
done.

Let's change our driver a bit to rely on the previous function for the
older SoCs, and on DMA fences for the BCM2711.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drivers: staging: bcm2835-isp: Do not cleanup mmal vcsm buffer on stop_streaming

On stop_streaming() the vcsm buffer handle gets released by the buffer cleanup
code.  This will subsequently cause and error if userland re-queues the same
buffer on the next start_streaming() call.

Remove this cleanup code and rely on the vb2_ops->buf_cleanup() call to do the
cleanups instead.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

staging: vc04_services: isp: Permit all sRGB colour spaces on ISP outputs

ISP outputs actually support all colour spaces that are fundamentally
sRGB underneath, regardless of whether an RGB or YUV output format is
actually requested.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>

staging/vc-sm-cma: Avoid log spamming on Pi0/1 over cache alias.

Pi 0/1 use the 0x80000000 cache alias as the ARM also sees the world
through the VPU L2 cache.
vc-sm-cma was trying to ensure it was in an uncached alias (0xc), and
complaining on every allocation if it weren't. Reduce this logging.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

defconfigs: Add OV2311 image sensor to Pi defconfigs

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

dtoverlays: Add overlay for Omnivision OV2311 image sensor

Adds an overlay for the OV2311 1600x1300 monochrome global
shutter image sensor.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

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>

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>

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>

configs: Add CONFIG_TINYDRM_HX8357D=m

See: https://forums.raspberrypi.com/viewtopic.php?t=330088

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

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>

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

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

media: i2c: Add pm_runtime support to ov7251

Add pm_runtime support to the ov7251 driver.

Signed-off-by: Daniel Scally <djrscally@gmail.com>

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>

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>

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>

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>

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>

dtoverlays: Correct link frequency for ov7251

It was incorrect, so the driver rejected it.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

drm: panel: Fix compilation warnings

See: https://github.com/raspberrypi/linux/pull/4812

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

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>

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>

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>

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>

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>

bindings: Add sck-idle-input to spi-gpio

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

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>