The BCM2712 has a simpler pipeline than the BCM2711, and thus the muxing
requirements are different. Create some tests to make sure we get proper
muxing decisions.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The BCM2712 has a simpler pipeline that can only output to a writeback
connector and two HDMI controllers.
Let's allow our kunit tests to create a mock of that pipeline.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Some tests will need to retrieve the output that was just allocated by
vc4_mock_atomic_add_output().
Instead of making them look them up in the DRM device, we can simply
make vc4_mock_atomic_add_output() return an error pointer that holds the
allocated output instead of the error code.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The DRM device pointer and the DRM encoder pointer are redundant, since
the latter is attached to the former and we can just follow the
drm_encoder->dev pointer.
Let's remove the drm_device pointer argument.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Testing whether the VideoCore generation we want to mock is vc5 or vc4
worked so far, but will be difficult to extend to support BCM2712 (VC6).
Convert to a switch.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
This is a squash of all firmware-kms related patches from previous
branches, up to and including
"drm/vc4: Set the possible crtcs mask correctly for planes with FKMS"
plus a couple of minor fixups for the 5.9 branch.
Please refer to earlier branches for full history.
This patch includes work by Eric Anholt, James Hughes, Phil Elwell,
Dave Stevenson, Dom Cobley, and Jonathon Bell.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
drm/vc4: Fixup firmware-kms after "drm/atomic: Pass the full state to CRTC atomic enable/disable"
Prototype for those calls changed, so amend fkms (which isn't
upstream) to match.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
drm/vc4: Fixup fkms for API change
Atomic flush and check changed API, so fix up the downstream-only
FKMS driver.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
drm/vc4: Make normalize_zpos conditional on using fkms
Eric's view was that there was no point in having zpos
support on vc4 as all the planes had the same functionality.
Can be later squashed into (and fixes):
drm/vc4: Add firmware-kms mode
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
drm/vc4: FKMS: Change of Broadcast RGB mode needs a mode change
The Broadcast RGB (aka HDMI limited/full range) property is only
notified to the firmware on mode change, so this needs to be
signalled when set.
https://github.com/raspberrypi/firmware/issues/1580
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
vc4/drv: Only notify firmware of display done with kms
fkms driver still wants firmware display to be active
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
ydrm/vc4: fkms: Fix margin calculations for the right/bottom edges
The calculations clipped the right/bottom edge of the clipped
range based on the left/top margins.
https://github.com/raspberrypi/linux/issues/4447
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
drm/vc4: fkms: Use new devm_rpi_firmware_get api
drm/kms: Add allow_fb_modifiers
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
drm/vc4: Add async update support for cursor planes
Now that cursors are implemented as regular planes, all cursor
movements result in atomic updates. As the firmware-kms driver
doesn't support asynchronous updates, these are synchronous, which
limits the update rate to the screen refresh rate. Xorg seems unaware
of this (or at least of the effect of this), because if the mouse is
configured with a higher update rate than the screen then continuous
mouse movement results in an increasing backlog of mouse events -
cue extreme lag.
Add minimal support for asynchronous updates - limited to cursor
planes - to eliminate the lag.
See: https://github.com/raspberrypi/linux/pull/4971https://github.com/raspberrypi/linux/issues/4988
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
drivers/gpu/drm/vc4: Add missing 32-bit RGB formats
The missing 32-bit per pixel ABGR and various "RGB with an X value"
formats are added. Change sent by Dave Stevenson.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
drm: vc4: Fixup duplicated macro definition in vc4_firmware_kms
Both vc4_drv.h and vc4_firmware_kms.c had definitions for
to_vc4_crtc.
Rename the fkms one to make it unique, and drop the magic
define vc4_crtc vc4_kms_crtc
define to_vc4_crtc to_vc4_kms_crtc
that renamed half the variable and function names in a slightly
unexpected way.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
drm/vc4: Fix FKMS for when the YUV chroma planes are different buffers
The code was assuming that it was a single buffer with offsets,
when kmstest uses separate buffers and 0 offsets for each plane.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
drm/vc4: fkms: Rename plane related functions
The name collide with the Full KMS functions that are going to be made
public.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
drm/vc4_fkms: Fix up interrupt handler for both 2835/2711 and 2712
2712 has switched from using the SMI peripheral to another interrupt
source for the vsync interrupt, so handle both sources cleanly.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
drm/vc4: fkms: No SMI abuse needed on BCM2712
Since we don't use the (absent) SMI block to create interrupts on
BCM2712, there's no need to map any registers.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Currently, booting with no hdmi connected has:
pi@pi4:~ $ vcgencmd measure_clock hdmi pixel
frequency(9)=120010256
frequency(29)=74988280
After connecting hdmi we get:
pi@pi4:~ $ vcgencmd measure_clock hdmi pixel
frequency(9)=300005856
frequency(29)=149989744
and that persists after disconnecting hdmi
I can measure this on a power supply as 10mA@5.2V (52mW).
We should always remove clk_set_min_rate requests
when we no longer need them.
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
The txp block can implement transpose as it writes out the image
data, so expose that through the new connector rotation property.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
drm: vc4: txp: Do not allow 24bpp formats when transposing
The hardware doesn't support transposing to 24bpp (RGB888/BGR888)
formats. There's no way to advertise this through DRM, so block
it from atomic_check instead.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
As the writeback connector doesn't have the same realtime
constraints of a live display, drop the panic priority for it.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The transposer/writeback connector should be running with a
lower priority, so shouldn't be factored into the load
calculations.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Instead of having 48 generic overlay planes, assign 32 to the
writeback connector so that there is no ambiguity in wlroots
when trying to find a plane for composition using the writeback
connector vs display.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The HVS can accept an arbitrary number of planes, provided
that the overall pixel read load is within limits, and
the display list can fit into the dlist memory.
Now that DRM will support 64 planes per device, increase
the number of overlay planes from 16 to 48 so that the
dlist complexity can be increased (eg 4x4 video wall on
each of 3 displays).
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The register to enable/disable background fill was being set
from atomic flush, however that will be applied immediately and
can be a while before the vblank. If it was required for the
current frame but not for the next one, that can result in
corruption for part of the current frame.
Store the state in vc4_hvs, and update it on vblank.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The documentation says that the TPZ filter can not upscale,
and requesting a scaling factor > 1:1 will output the original
image in the top left, and repeat the right/bottom most pixels
thereafter.
That fits perfectly with upscaling a 1x1 image which is done
a fair amount by some compositors to give solid colour, and it
saves a large amount of LBM (TPZ is based on src size, whilst
PPF is based on dest size).
Select TPZ filter for images with source rectangle <=1.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Seeing as the HVS can be configured with regard the scaling filter,
and DRM now supports selecting scaling filters at a per CRTC or
per plane level, we can implement it.
Default remains as the Mitchell/Netravali filter, but nearest
neighbour is now also implemented.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
There are no MEDIA_BUS_FMT_* defines for GRB or BRG, and adding
them is a pain.
Add a DT override to allow setting the order.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The current reset code doesn't actually stop the hdmi output.
That makes it difficult for displays to handle a mode set.
Powering down the PLL does actually remove the hdmi signal
and makes mode sets more reliable
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
There appears to be a requirement for some devices
(I'm testing with a 8K VRROOM 40Gbps HDMI switch)
for a measable delay between removing the hdmi phy output from
the old mode, to enabling the hdmi phy output for the new mode.
Without the delay, a mode switch has a small change of getting a permanent
'no signal', which requires a subsequent mode switch or a unplug/replug
to redetect.
Switching between 4kp24/25/30 modes fails about 5% of time in my testing.
Add a delay to make it impossible to switch faster than this.
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
The intention of the vc4.force_hotplug setting is to
ignore hotplug completely.
It can be used when a display toggles hotplug when
switching AV inputs, going into standby or changing a
KVM switch, and some side effect of that is unwanted.
It turns out while vc4.force_hotplug currently makes
hotplug always read as asserted, that isn't enough to
stop drm doing lots of stuff, including re-reading
the edid.
An example of what drm does with a hotplug deasert/assert
and vc4.force_hotplug=1 currently is:
https://paste.debian.net/hidden/dc07434b/
That is unwanted. Lets ignore the hotplug interrupt
completely so drm is blissfully unaware of the hotplug change.
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
See: https://forum.libreelec.tv/thread/24783-tv-avr-turns-back-on-right-after-turning-them-off
While the kernel provides a :D flag for assuming device is connected,
it doesn't stop this function from being called and generating a cec_phys_addr_invalidate
message when hotplug is deasserted.
That message provokes a flurry of CEC messages which for many users results in the TV
switching back on again and it's very hard to get it to stay switched off.
It seems to only occur with an AVR and TV connected but has been observed across a
number of manufacturers.
The issue started with https://github.com/raspberrypi/linux/pull/4371
and this provides an optional way of getting back the old behaviour
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
If you disable HDR metadata, then the hardware should stop
sending the infoframe, and that is implemented by the
clear_infoframe hook which wasn't implemented. Add it.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
With the command line parser now providing the information about
the tv mode, use that as the preferred choice for initialising the
default of the tv_mode property.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Similar to the ch7006 and nouveau drivers, introduce a "tv_mode" module
parameter that allow setting the TV norm by specifying vc4.tv_norm= on
the kernel command line.
If that is not specified, try inferring one of the most popular norms
(PAL or NTSC) from the video mode specified on the command line. On
Raspberry Pis, this causes the most common cases of the sdtv_mode
setting in config.txt to be respected.
Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
drm/vc4: Do not reset tv mode as this is already handled by framework
In vc4_vec_connector_reset, the tv mode is already reset to the
property default by drm_atomic_helper_connector_tv_reset, so there
is no need for a local fixup to potentially some other default.
Fixes: 96922af144 ("drm/vc4: Allow setting the TV norm via module parameter")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The DSI block appears to be able to come up stuck in a condition where
it leaves the lanes in HS mode or just jabbering. This stops LP
transfers from completing as there is no LP time available. This is
signalled via the LP1 contention error.
Enabling video briefly clears that condition, so if we detect the
error condition, enable video mode and then retry.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Some DSI peripheral drivers wish to send commands in the
post_disable or panel unprepare callback. These are called
after the DSI host's disable call, but before the host's
post_disable if pre_enable_prev_first is set.
Don't reset the block until post_disable to allow these
commands to be sent.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The TC358762 bridge and panel decodes the mode differently on
DSI0 to DSI1 for no obvious reason, and results in a shift off
the screen.
Whilst it would be possible to change the compatible used for
the panel, that then messes up Pi5.
As it appears to be restricted to vc4 DSI0, fix up the mode
in vc4_dsi.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The pixel to byte FIFO appears to not always reset correctly,
which can lead to colour errors and/or horizontal shifts.
Reset on every vblank to work around the issue.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The block must be enabled for the FIFO resets to be actioned,
so ensure this is the case.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The initialisation sequence differs slightly from the documentation
in that the clocks are meant to be running before resets and
similar.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
DSI0 is misbehaving and needs to action things on vblank to
work around it.
Add a new hook to call across during vblank.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The dmabuf import already checks that the backing buffer is contiguous
and rejects it if it isn't. vc4 also requires that the buffer is
in the bottom 1GB of RAM, and this is all correctly defined via
dma-ranges.
However the kernel silently uses swiotlb to bounce dma buffers
around if they are in the wrong region. This relies on dma sync
functions to be called in order to copy the data to/from the
bounce buffer.
DRM is based on all memory allocations being coherent with the
GPU so that any updates to a framebuffer will be acted on without
the need for any additional update. This is fairly fundamentally
incompatible with needing to call dma_sync_ to handle the bounce
buffer copies, and therefore we have to detect and reject mappings
that use bounce buffers.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
We have a read-modify-write race when updating SCALER_DISPCTRL for
underrun and end-of-frame interrupts.
Ideally it would be fixed via a spinlock or similar, but that will
require a reasonable amount of study to ensure we don't get deadlocks.
The underrun reporting is only for debug, so disable it for now.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Users are reporting running out of DLIST memory. Add a
debugfs file to dump out all the allocations.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
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 occurring.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
DSI0 and DSI1 have different widths for the command FIFO (24bit
vs 32bit), but the driver was assuming the 32bit width of DSI1
in all cases.
DSI0 also wants the data packed as 24bit big endian, so the
formatting code needs updating.
Handle the difference via the variant structure.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Using increased bit depth for no reason increases power
consumption, and differs from the behaviour prior to the
conversion to use the HDMI helper functions.
Initialise the state max_bpc and requested_max_bpc to the
minimum value supported. This only affects Raspberry Pi,
as the other users of the helpers (rockchip/inno_hdmi and
sunx4i) only support a bit depth of 8.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
ws2812-pio-rp1 is a PIO-based driver for WS2812 LEDS. It creates a
character device in /dev, the default name of which is /dev/leds<n>,
where <n> is the instance number. The number of LEDS should be set
in the DT overlay, as should whether it is RGB or RGBW, and the default
brightness.
Write data to the /dev/* entry in a 4 bytes-per-pixel format in RGBW
order:
RR GG BB WW RR GG BB WW ...
The white values are ignored unless the rgbw flag is set for the device.
To change the brightness, write a single byte to offset 0, 255 being
full brightness and 0 being off.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Use the PIO hardware on RP1 to implement a PWM interface.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
pwm: rp1: use pwmchip_get_drvdata() instead of container_of()
The PWM framework may not embed struct pwm_chip within the driver’s
private data. Using container_of() can result in accessing invalid
memory or NULL pointers, especially after recent kernel changes.
Switch to pwmchip_get_drvdata() to reliably access the driver data.
This resolves kernel warnings and probe failures seen after updating
from kernel 6.12.28 to 6.12.34 [1]
While at it remove the now obsolete `struct pwm_chip chip` member from
`struct pwm_pio_rp1`.
[1] https://github.com/raspberrypi/linux/issues/6971
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Provide remote access to the PIO hardware in RP1. There is a single
instance, with 4 state machines.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
misc: rp1-pio: Support larger data transfers
Add a separate IOCTL for larger transfer with a 32-bit data_bytes
field.
See: https://github.com/raspberrypi/utils/issues/107
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
misc: rp1-pio: More logical probe sequence
Sort the probe function initialisation into a more logical order.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
misc: rp1-pio: Minor cosmetic tweaks
No functional change.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
misc: rp1-pio: Add in-kernel DMA support
Add kernel-facing implementations of pio_sm_config_xfer and
pio_xm_xfer_data.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
misc: rp1-pio: Handle probe errors
Ensure that rp1_pio_open fails if the device failed to probe.
Link: https://github.com/raspberrypi/linux/issues/6593
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
misc: rp1-pio: SM_CONFIG_XFER32 = larger DMA bufs
Add an ioctl type - SM_CONFIG_XFER32 - that takes uints for the buf_size
and buf_count values.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
misc/rp1-pio: Fix copy/paste error in pio_rp1.h
As per the subject, there was a copy/paste error that caused
pio_sm_unclaim from a driver to result in a call to
pio_sm_claim. Fix it.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
misc: rp1-pio: Fix parameter checks wihout client
Passing bad parameters to an API call without a pio pointer will cause
a NULL pointer exception when the persistent error is set. Guard
against that.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
misc: rp1-pio: Convert floats to 24.8 fixed point
Floating point arithmetic is not supported in the kernel, so use fixed
point instead.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
misc: rp1-pio: Error out on incompatible firmware
If the RP1 firmware has reported an error then return that from the PIO
probe function, otherwise defer the probing.
Link: https://github.com/raspberrypi/linux/issues/6642
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
misc: rp1-pio: Demote fw probe error to warning
Support for the RP1 firmware mailbox API is rolling out to Pi 5 EEPROM
images. For most users, the fact that the PIO is not available is no
cause for alarm. Change the message to a warning, so that it does not
appear with "quiet" in cmdline.txt.
Link: https://github.com/raspberrypi/linux/issues/6642
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
misc: rp1-pio: Don't just reuse the same DMA buf
A missing pointer increment meant that not only was the same buffer
being reused again and again, there was also no protection against
using it simultaneously for multiple transfers. Fix that basic bug, and
also move a similar increment to before the transfer is started, which
feels less racy.
See: https://github.com/raspberrypi/linux/issues/6919
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
misc: rp1-pio: Fix a config_xfer error path
If the DMA channel allocation fails, the relevant dma_configs entry
should be marked as no longer claimed, otherwise rp1_pio_sm_dma_free
will be called with an error number as a DMA channel pointer.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
misc: rp1-pio: Request a DMA burst size of 8
Improve DMA performance by increasing the burst size to 8.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The RP1 firmware runs a simple communications channel over some shared
memory and a mailbox. This driver provides access to that channel.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
firmware: rp1: Simplify rp1_firmware_get
Simplify the implementation of rp1_firmware_get, requiring its clients
to have a valid 'firmware' property. Also make it return NULL on error.
Link: https://github.com/raspberrypi/linux/issues/6593
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
firmware: rp1: Linger on firmware failure
To avoid pointless retries, let the probe function succeed if the
firmware interface is configured correctly but the firmware is
incompatible. The value of the private drvdata field holds the outcome.
Link: https://github.com/raspberrypi/linux/issues/6642
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
firmware: rp1: Rename to rp1-fw to avoid module name collision
There is already the driver in drivers/mfd/rp1.ko, so having
drivers/firmware/rp1.ko can cause issues when using modinfo
and similar, and we can get errors with "Module rp1 is already
loaded" when trying to load it.
Rename the module so that the name is unique.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
mailbox: rp1: Don't claim channels in of_xlate
The of_xlate method saves the calculated event mask in the con_priv
field. It also rejects subsequent attempt to use that channel because
the mask is non-zero, which causes a repeated instantiation of a client
driver to fail.
The of_xlate method is not meant to be a point of resource acquisition.
Leave the con_priv initialisation, but drop the test that it was
previously zero.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The Raspberry Pi RP1 includes 2 M3 cores running firmware. This driver
adds a mailbox communication channel to them via a doorbell and some
shared memory.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Attempting to start a non-idle channel causes an error message to be
logged, and is inefficient. Test for emptiness of the desc_issued list
before doing so.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xHC may commence Host Initiated Data Moves for streaming endpoints -
see USB3.2 spec s8.12.1.4.2.4. However, this behaviour is typically
counterproductive as the submission of UAS URBs in {Status, Data,
Command} order and 1 outstanding IO per stream ID means the device never
enters Move Data after a HIMD for Status or Data stages with the same
stream ID. For OUT transfers this is especially inefficient as the host
will start transmitting multiple bulk packets as a burst, all of which
get NAKed by the device - wasting bandwidth.
Also, some buggy UAS adapters don't properly handle the EP flow control
state this creates - e.g. RTL9210.
Set Host Initiated Data Move Disable to always defer stream selection to
the device. xHC implementations may treat this field as "don't care,
forced to 1" anyway - xHCI 1.2 s4.12.1.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
SPI transfers are of defined length, unlike some UART traffic, so it is
safe to let the DMA controller choose a suitable memory width.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
For devices where transfer lengths are not known upfront, there is a
danger when the destination is wider than the source that partial words
can be lost at the end of a transfer. Ideally the controller would be
able to flush the residue, but it can't - it's not even possible to tell
that there is any.
Instead, allow the client driver to avoid the problem by setting a
smaller width.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
