Upstream imx708 driver#7507
Draft
6by9 wants to merge 647 commits into
Draft
Conversation
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>
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 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>
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: raspberrypi#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: raspberrypi#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>
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: raspberrypi/utils#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: raspberrypi#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: raspberrypi#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: raspberrypi#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: raspberrypi#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> misc: rp1-pio: Get burst size from DMA capabilities Although the PIO throughput benefits from larger burst sizes, only the first two DMA channels support a burst size of 8 - the others are capped at 4. To avoid misconfiguring the PIO hardware, retrieve the actual max_burst value from the DMA channel's capabilities. Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: Defer for out-of-order probing In the event that a client of the rp1-pio driver is probed before it, return -EPROBE_DEFER from pio_open to allow it to be retried. Otherwise, return an error code on error, not a NULL pointer, as that is what clients are expecting. See: raspberrypi#7211 Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: Add narrowing casts Avoid some compiler warnings by adding explicit narrowing casts. See: raspberrypi#7309 Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: Include maxburst in PIO_DMACTRL The PIO DMA interface exposes empty/not empty signals as well as the threshold signals required for bursts. If the FIFO is not ready for a burst, a single beat burst can still be performed. It is therefore safe to set the PIO FIFO thresholds to the burst size used by the DMA controller. See: https://forums.raspberrypi.com/viewtopic.php?t=398882 Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: Ensure transfers are configured Fail transfers if they haven't first been configured. 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] raspberrypi#6971 Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de> pwm: rp1: Silently correct illegal values Remove the need for the user to know the limitations of this PWM implementation by adjusting configuration requests to be the closest acceptable value. Add a get_state method so that the actual values can be queried. Signed-off-by: Phil Elwell <phil@raspberrypi.com> pwm: rp1: Correct period off-by-1 error Correct the set_period method to pass (period - 1), as required by the PIO state machine. Signed-off-by: Phil Elwell <phil@raspberrypi.com> pwm: pio-rp1: don't flag driver as using atomic ops The functions are implemented over a RPC pipe, so may sleep. Signed-off-by: Jonathan Bell <jonathan@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> misc: ws2812-pio-rp1: Add pass-through mode Pass-through mode disables all gamma and brightness processing, sending the raw pixel data directly to the LEDs. It is enabled by setting the brightness to zero, either in Device Tree or using the runtime method of writing a single byte (in this case 0) to the device. See: raspberrypi#7108 Signed-off-by: Phil Elwell <phil@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>
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>
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>
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>
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>
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>
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 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>
vc4_dsi_bridge_disable wasn't resetting things during shutdown, so add that in. 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 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 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>
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 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>
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: 96922af ("drm/vc4: Allow setting the TV norm via module parameter") 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>
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 raspberrypi#4371 and this provides an optional way of getting back the old behaviour 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>
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 body of this function was missing so we don't reset the phy when disabling it. Signed-off-by: Dom Cobley <popcornmix@gmail.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 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>
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
fll_min (Frame Length Lines) is set to the same value as fll_def for all modes, which makes it redundant. The actual value is also erroneous as the sensor works in all the defined modes with FLL set at the mode height + 20 lines, so set the vblank control minimum to 20 rather than varying it. This also improves the maximum frame rate achievable. Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Provide all the cropping information via get_selection. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Avoid powering the sensor up and down unnecessarily by using pm_runtime's autosuspend_delay feature. Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Use the new comon CCI register access helpers to replace the private register access helpers in the imx355 driver. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The colorspace fields were left set to 0 when they should be set appropriately for a raw image sensor. Add those values. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The difference between frame length and max exposure time in lines is 10. That had been used as a bare value in calculations. Move it to a define, and use that define. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
This avoids the set_ctrl handler being called under any circumstances, as it will return an error for the unhandled ctrl. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
In preparation for additional options in the PLL setup, compute the link frequency rather than using a hardcoded value. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The sensor supports 2 or 4 lane readout, but the driver only allowed for 4 lanes. Add 2 lane support. The clock tree only supports single PLL mode to feed both IOP (MIPI) and IVT (Pixel array). 2 lane mode supports a MIPI link frequency of up to 445MHz (890Mbit/s) cf 360MHz (720Mbit/s) for 4lane. Update clock setup and pixel rates to match. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The subdev state is now preferred rather than handling crop and format within the driver state, so switch the driver to using it. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
All the information for the mode is now stored within the subdev state, so configure the sensor based on that. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
V4L2_CID_HBLANK / LLP was a read-only control that set min/ max/default all to the same value. The datasheet does state "H-sync timing is fixed in order to avoid the sensor internal interference (FPN) in IMX355 by line_length". No interference has currently been observed, and the default is always to leave it at the minimum (and approved) value. Allowing it to be controllable therefore has no effect unless a frame period longer than can be achieved just through VBLANK is requested. Exposure times up to 14.9s/frame can be achieved when combined with the max FLL / VBLANK value. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Add a new overlay for EDATEC IPC/EXP series industrial PC carrier boards. This overlay configures PCA9535 GPIO expanders on both i2c_csi_dsi and i2c_arm buses, with support for multiple board profiles (IPC2100, IPC2300, IPC3100, IPC3300, PLC2010, etc.) and optional expansion modules (exp8x8y, exp4x4y). Signed-off-by: zjzhao <zjzhao@edatec.cn>
The way upstream deals with compatibles is to add emc2305 and then deal with the variations in the driver as it's detectable so add emc2305 to the compat so we work with the upstream driver. Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Posted write tracking introduced in the commit below referenced the request in the submission path after it had been issued, racing with re-use of the request and potentially causing underflow of the pending write count. The count is signed but was compared against the unsigned posted write limit, so such an underflow would wrap to a large value and wrongly throttle further writes (hang entire system). Fixes: e6c1e86 ("mmc: restrict posted write counts for SD cards in CQ mode") Co-developed-by: Jonathan Bell <jonathan@raspberrypi.com> Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> Signed-off-by: Yufeng Gao <yufeng.gao@canonical.com>
…rn_ratelimited" This reverts commit b2f7eec. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
…_tx_poll" This reverts commit 60fc80b. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
This reverts commit 79dc190. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
This reverts commit ff6914e. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
vc4_hdmi_handle_hotplug() calls drm_atomic_helper_connector_hdmi_hotplug() twice: once from the downstream commit 7a761a6 ("vc4: Add jack detection to HDMI audio driver") and once from the upstream code it was rebased onto, which gained the same call in commit 34f051a ("drm/vc4: hdmi: Call HDMI hotplug helper on disconnect"). The helper reads the EDID over DDC, so every detect currently performs two full EDID reads and signals the audio jack state twice. Drop the duplicate and keep the call where upstream has it, after the locking comment. Fixes: 7a761a6 ("vc4: Add jack detection to HDMI audio driver") Signed-off-by: Dom Cobley <popcornmix@gmail.com>
create_pagelist() maps the bulk scatterlist with instance->state->dev
(the vchiq platform device) while free_pagelist() and
cleanup_pagelistinfo() unmap it with g_dma_dev - on BCM2711 the
brcm,bcm2711-dma device resolved for use_36bit_addrs, whose dma-ranges
differ from the vchiq node's. The coherent pagelist buffer is likewise
allocated on instance->state->dev but freed on g_dma_dev.
Mapping and unmapping with different devices breaks every userspace
bulk transfer on Pi 4 arm64:
- the 36-bit addrs[] entries handed to the VPU are computed from
sg_dma_address() under the wrong device's dma-ranges, so the VPU
reads/writes the wrong bus addresses (bulk WRITE payloads arrive
as garbage; under sustained load the VPU stops responding to
mailbox requests entirely);
- the first bulk READ oopses in free_pagelist(): the DMA_FROM_DEVICE
dma_unmap_sg() cache invalidate mis-translates the dma address back
to phys under the other device's dma-ranges (0xf41e8e80 = phys
0x341e8e80 still carrying the vchiq device's 0xc0000000 alias):
Unable to handle kernel paging request at virtual address
ffffff80f41e8e80
CPU: 0 PID: 80 Comm: vchiq-slot/0
Call trace:
dcache_inval_poc+0x28/0x58 (P)
dma_direct_unmap_sg+0x224/0x260
dma_unmap_sg_attrs+0x60/0x148
free_pagelist.isra.0+0x54/0x1f8
slot_handler_func+0x4b8/0xdf0
rpi-6.12.y paired these consistently: dma_map_sg/dma_unmap_sg both on
g_dma_dev, dma_alloc_coherent/dma_free_coherent both on
instance->state->dev. Restore that pairing.
Verified on a Pi 4B Rev 1.5: on an unpatched 6.18 kernel a
vc.ril.video_splitter payload loopback from a 64-bit userland oopses
as above and vc.ril.video_decode consumes garbage; with this change
the loopback round-trips byte-identical and decode runs at full rate.
Nothing in-tree exercises userspace vchiq bulk on arm64 (the kernel
MMAL clients use vc-sm-cma zero-copy imports), which is why this went
unnoticed.
Fixes: 35ef141 ("staging: vchiq_arm: Set up dma ranges on child devices")
Link: raspberrypi#7493
Signed-off-by: Rachmat Aditiya <raditiya@me.com>
The RP1 mailbox + firmware interface is currently synchronous, with only one outstanding message at a time and the same buffer used for the reply. It is therefore of no use to know when the transmit has completed, only that the reply is ready. This is TXDONE_BY_ACK mode, which is automatically selected if neither txdone_irq nor txdone_poll are provided. This change increases performance and reduces hrtimer usage significantly, but it requires the mailbox client to call mbox_client_txdone after each transmission. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Now that TX polling has been disabled and the mailbox is running in TXDONE_BY_ACK mode, call mbox_client_txdone after each transmission to tell the mailbox framework that the transmission has completed. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Sony IMX708 is an 11.9 Megapixel CMOS sensor, that can output pixels over MIPI CSI-2 bus. Add bindings for it. Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Sony IMX708 is an 11.9 Megapixel CMOS sensor with a 16:9 aspect ratio. It is a quad-bayer sensor with support for remosaicing the output to a normal 2x2 bayer pattern. This basic driver adds supports for capturing the full active-area of 4608x2592, up to 14.35fps. The following features are supported by the driver: - MIPI RAW10 output - Fixed quad-bayer correction - Multiple link frequencies (different IOP_PLL_MPY) - VBLANK control for flexible frame-rate - Analogue gain and exposure control - Extremely long exposure time with LONG_EXP_SHIFT - Test pattern support The following features are currently not supported and may be added later. Some of them depend on the new common raw sensor model: - Embedded data stream - Freely configurable crop (analog and digital) - 2x2 binning - Quad-bayer multi-exposure HDR support - HBLANK control - 4-lane support - Configurable clock-tree - Flexible quad-bayer correction Co-developed-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com> Signed-off-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com> Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Picking up upstream series https://lore.kernel.org/linux-media/20260715-imx708-v1-0-1f36f54e14d4@ideasonboard.com/ for testing.
(Reverts most of the downstream stuff first, but missed with Kconfig and Makefile).