Rpi 6.17.y based on mainline dt #7009
Conversation
Posted write tracking introduced in the commit below raced with re-use of the requests between completion and submission, potentially causing underflow of the pending write count. Fixes: e6c1e86 ("mmc: restrict posted write counts for SD cards in CQ mode") Signed-off-by: Jonathan Bell <[email protected]>
Samsung EVO Plus, Pro Plus and Evo Ultimate cards of this era appear to have a broken cache-flush implementation when operating in CQ mode. Unfortunately the cards seem to use a separate CID name string for every variant and capacity, so nobble the cache feature for this MANFID, OEMID and year. Turning this off seems to have negligible impact on random-write throughput in non-CQ mode. Signed-off-by: Jonathan Bell <[email protected]>
Cards with manufacture dates in 2019 and 2020 have been seen in the wild that hang indefinitely if issued a cache flush command in CQ mode. Signed-off-by: Jonathan Bell <[email protected]>
Only CMD38 with Arg=0x1 (Discard) is supported when in CQ mode, so turn it off before issuing a non-discard erase op. Signed-off-by: Jonathan Bell <[email protected]>
Recent Integral cards end up with corrupt sectors after a flash erase. This covers sizes for the A2 range, which can't be differentiated from the A1 range which might not have the same issue. Signed-off-by: Jonathan Bell <[email protected]>
Newer versions of the DesignWare I2C block support the detection of stuck signals, and a mechanism to recover from them. Add the required software support to the driver. This change was prompted by the observation that reading a single byte from register 0 of a VEML7700 seems to cause it to issue an ACK too early, and the controller to complain about losing arbitration. There is a suspicion that this may be a more widespread problem, but at least this patch prevents the bus from locking up. See: raspberrypi#6057 Signed-off-by: Phil Elwell <[email protected]>
In the absence of a value in Device Tree, set the SDA hold time to half the SCL low time. Signed-off-by: Phil Elwell <[email protected]>
This code: for_each_sg(sgl, sg, sg_len, i) num_sgs += DIV_ROUND_UP(sg_dma_len(sg), axi_block_len); determines how many hw_desc are allocated. If sg_dma_len(sg)=0 we don't allocate for this sgl. However in the next loop, we will increment loop for this case, and loop gets higher than num_sgs and we trample memory. Signed-off-by: Dom Cobley <[email protected]>
"rotation" is listed as a standard property of panels in panel-common.yaml, therefore it would be logical to process that from within the core code should a panel driver not implement the get_orientation hook. Call of_drm_get_panel_orientation from drm_connector_set_orientation_from_panel to get that information. This removes the need for any boiler-plate in panel drivers for calling drm_connector_set_orientation_from_panel or drm_connector_set_panel_orientation. Signed-off-by: Dave Stevenson <[email protected]>
The autodetection of resolution/timing by the TC358762 can lead to the display being shifted by a pixel or two. Program the TC358762 with the requested mode timing so that it can reproduce it accurately. Signed-off-by: Dave Stevenson <[email protected]>
Reverts 8a4b2fc ("drm/bridge: tc358762: Split register programming from pre-enable to enable") as we want the config commands sent before video starts. Signed-off-by: Dave Stevenson <[email protected]>
Having accepted the upstream change to add the persist_gpio_outputs parameter, make it true by default. See: raspberrypi#6117 Signed-off-by: Phil Elwell <[email protected]>
Even when configured to use only gpiod CS lines, the DW SPI controller still expects a bit to be set in the SER register, otherwise transfers stall. For the csgpiod case, nominate bit 0 for the job. See: raspberrypi#6159 Signed-off-by: Phil Elwell <[email protected]>
The naming of backlight devices is not terribly useful for associating a backlight controller with a display (assuming it is attached to one). Add a sysfs node that will return a display name that can be set by other subsystems. Signed-off-by: Dave Stevenson <[email protected]>
Pass the DRM connector name to any configured backlight device so that userspace can associate the two items. Ideally this should be in drm_panel, but it is bridge/panel that creates the drm_connector and therefore knows the name. Signed-off-by: Dave Stevenson <[email protected]> drm/bridge: panel: Ensure backlight is reachable Ensure that the various options of modules vs builtin results in being able to call into the backlight code. raspberrypi#6198 Fixes: 573f8fd ("drm/bridge: panel: Name an associated backlight device") Signed-off-by: Dave Stevenson <[email protected]>
Add version 4.17.1 of the Hailo PCIe device drivers. Sourced from https://github.com/hailo-ai/hailort-drivers/ Signed-off-by: Naushir Patuck <[email protected]> drivers: media: pcie: hailo: Fix include paths An attempt to fix the include paths - they look reasonable, but the GitHub auto-builds fail. Signed-off-by: Phil Elwell <[email protected]> drivers: media: pci: Update Hailo accelerator device driver to v4.18.0 Sourced from https://github.com/hailo-ai/hailort-drivers/ Signed-off-by: Naushir Patuck <[email protected]> drivers: media: pci: Add wrapper after removal of follow_pfn drivers: media: pci: Fix Hailo compile warnings Signed-off-by: Phil Elwell <[email protected]> drivers: media: pci: Update Hailo accelerator device driver to v4.19 Sourced from https://github.com/hailo-ai/hailort-drivers/ Signed-off-by: Naushir Patuck <[email protected]> drivers: media: pci: Update Hailo accelerator device driver to v4.20 Sourced from https://github.com/hailo-ai/hailort-drivers Signed-off-by: Naushir Patuck <[email protected]> drivers: pci: hailo: Fix kernel warning when calling find_vdma() Calling this function without holding the mmap_read_lock causes the kernel to throw an error message, spamming the dmesg logs when running the Hailo hardware. Fix it by adding the approprite lock/unlock functions around find_vdma(). Signed-off-by: Naushir Patuck <[email protected]> drivers: pci: hailo: Better lock handling when calling find_vdma() Due to possible instabilities, reduce the mmap read lock time to only cover the call to find_vdma(). Signed-off-by: Naushir Patuck <[email protected]>
Add helpers to set and get vchiq driver data. vchiq_set_drvdata() and vchiq_get_drvdata() wraps dev_set_drvdata() and dev_get_drvdata() respectively. Signed-off-by: Umang Jain <[email protected]> Signed-off-by: Kieran Bingham <[email protected]>
Offset the backend dev-nodes starting at /dev/video20 onwards to maintain backward compatibility with the pre-upstreamed kernel driver. Signed-off-by: Naushir Patuck <[email protected]>
Add YAML device tree bindings for the Raspberry Pi RP2040 GPIO Bridge. Signed-off-by: Richard Oliver <[email protected]>
The Raspberry Pi RP2040 GPIO bridge is an I2C-attached device exposing both a Tx-only SPI controller, and a GPIO controller. Due to the relative difference in transfer rates between standard-mode I2C and SPI, the GPIO bridge makes use of 12 MiB of non-volatile storage to cache repeated transfers. This cache is arranged in ~8 KiB blocks and is addressed by the MD5 digest of the data contained therein. Optionally, this driver is able to take advantage of Raspberry Pi RP1 GPIOs to achieve faster than I2C data transfer rates. Signed-off-by: Richard Oliver <[email protected]> spi: rp2040-gpio-bridge: Add debugfs progress indicator Useful for tracking upload progress via userspace. Signed-off-by: Naushir Patuck <[email protected]> spi: rp2040-gpio-bridge: add missing MD5 dependency rp2040-gpio-bridge relies on the md5 crypto driver. This dependency cannot be determined automatically as rp2040-gpio-bridge does not use any of md5's symbols directly. Declare a soft 'pre' dependency on md5 to ensure that it is included and loaded before rp2040-gpio-bridge. Signed-off-by: Richard Oliver <[email protected]> spi: rp2040-gpio-bridge: fix gpiod error handling In some circumstances, devm_gpiod_get_array_optional() can return PTR_ERR rather than NULL to indicate failure. Handle these cases. Signed-off-by: Richard Oliver <[email protected]> spi: rp2040-gpio-bridge: probe: Cfg fast_xfer clk Fast transfer mode requires that the first bit of data is clocked with a rising edge. This can cause extra bits of data to be clocked on hardware where the clock signal uses a pull-up. This change ensures that clk is driven low before fast data transfer mode is entered. Signed-off-by: Richard Oliver <[email protected]>
The snps,block-size DT property declares the maximum block size for each channel of the dw-axi-dmac. However, the driver ignores these when setting max_seg_size and uses MAX_BLOCK_SIZE (4096) instead. To take advantage of the efficiencies of larger blocks, calculate the minimum block size across all channels and use that instead. See: raspberrypi#6256 Signed-off-by: Phil Elwell <[email protected]>
The firmware advertises its features as a string of words separated by spaces. Ensure that feature names are only matched in their entirety. Signed-off-by: Phil Elwell <[email protected]>
The Cypress firmwares use "extsae" to indicate wpa_supplicant-hosted SAE/WPA3. Signed-off-by: Phil Elwell <[email protected]>
support sae executed in wpa_supplicant and offload 4-way handshake offload. Signed-off-by: Chien-Chia Chen <[email protected]> JIRA: SWWLAN-142424
TMOD_TO is the transmit-only mode that doesn't put data into the receive FIFO. Using TMOD_TO when the user doesn't want the received data saves CPU time and memory bandwidth. Signed-off-by: Phil Elwell <[email protected]>
TMOD_RO is the receive-only mode that doesn't require data in the transmit FIFO in order to generate clock cycles. Using TMOD_RO when the device doesn't care about the data sent to it saves CPU time and memory bandwidth. Signed-off-by: Phil Elwell <[email protected]>
Disabling the peripheral resets controller state which has a dangerous side-effect of disabling the DMA handshake interface while it is active. This can cause DMA channels to hang. The error recovery pathway will wait for DMA to stop and reset the chip anyway, so mask further FIFO interrupts and let the transfer finish gracefully. Signed-off-by: Jonathan Bell <[email protected]>
There's no real need to constrain MEM access widths to 32-bit (or narrower), as the DMAC is intelligent enough to size memory accesses appropriately. Wider accesses are more efficient. Similarly, MEM burst lengths don't need to be a function of DEV burst lengths - the DMAC packs/unpacks data into/from its internal channel FIFOs appropriately. Longer accesses are more efficient. However, the DMAC doesn't have complete support for unaligned accesses, and blocks are always defined in integer multiples of SRC_WIDTH, so odd source lengths or buffer alignments will prevent wide accesses being used, as before. There is an implicit requirement to limit requested DEV read burst lengths to less than the hardware's maximum configured MSIZE - otherwise RX data will be left over at the end of a block. There is no config register that reports this value, so the AXI burst length parameter is used to produce a facsimile of it. Warn if such a request arrives that doesn't respect this. Signed-off-by: Jonathan Bell <[email protected]>
Do an end-run around ASoC in lieu of not being able to easily find the associated DMA controller capabilities. Signed-off-by: Jonathan Bell <[email protected]>
Ensure the transmit FIFO has emptied before ending the transfer by dropping the TX threshold to 0 when the last byte has been pushed into the FIFO. Include a similar fix for the non-IRQ paths. See: raspberrypi#6285 Fixes: 6014649 ("spi: dw: Save bandwidth with the TMOD_TO feature") Signed-off-by: Phil Elwell <[email protected]>
Signed-off-by: Phil Elwell <[email protected]>
This at least compiles. Signed-off-by: Phil Elwell <[email protected]>
|
The Pi 5 dts file built from this tree references the following clocks: And clk-rp1.c defines the following clocks: We can ignore the GP clocks for now, but quite a few of the others are important. |
|
I think https://lore.kernel.org/linux-arm-kernel/17e5c6e0c085cfa0bf4b63b639cdc92c6a4c1418.1750714412.git.andrea.porta@suse.com/ (which is in linux-next ie 6.18) should add all of those for us. |
|
All the ethernet patches for RP1 have at least got R-b tags, so it may be worth backporting the official versions of those as well. |
6by9
force-pushed
the
rpi-6.17.y-mainline-dt
branch
from
da331a3 to
02c6dac
Compare
|
Branch updated with the updated clock driver. It appears to include all the clocks you've listed. clk_summary gives me: |
|
In 6.16 and earlier, the Pi 5 dts files have the following structure: The new structure is: It lacks any clear equivalent of the last file, which is important for adding things such as RP1, the DT overrides, gpiomem declarations etc. Some of the features have been folded into |
This reverts commit 2978319.
The driver was calling pinctrl_lookup_state on the result from devm_pinctrl_get without ensuring it wasn't NULL or an error, which could result in a seg fault. Signed-off-by: Dave Stevenson <[email protected]>
CHECK ME! pinctrl-rp1 looks up the RP1 node to try and find the parent and then pokes at the registers thereof. "rp1" has been renamed "rp1_nexus", so accept that. Signed-off-by: Dave Stevenson <[email protected]>
|
Happy to restructure. The existing files were lacking in comments with regard the segregation of devices nodes. A couple of notes: We ought to be trying to direct upstreaming of Pi500 and CM5. As there are common blocks between those and Pi5, those want to move out of bcm2712-rpi-5-b.dts and into what mainline would normally be called bcm2712-rpi.dtsi. The old files had a bundle of duplication in bcm2712-rpi-5-b.dts and bcm2712-rpi-cm5.dtsi that presumably should be factored out (eg PCIe qos settings, RP1 PCIe address layout, ethernet config, enabling rp1 blocks, etc). Sounds like they should be in bcm2712-rpi(-ds).dtsi based on your description of the split. In 6.16, rp1.dtsi included defining a number of external clocks, /rp1_firmware and /rp1_vdd_3v3 - https://github.com/raspberrypi/linux/blob/rpi-6.16.y/arch/arm64/boot/dts/broadcom/rp1.dtsi#L1247-L1343 IMHO it makes more sense to directly include the downstream files from bcm2712-rpi-5-b.dts, rather than the chain of includes that we have on the other boards. bcm2712-rpi-5-b.dts, bcm2712-rpi-5-b-ovl-rp1.dts, and bcm2712.dtsi are already upstream, therefore there seems little point in breaking the include chain to insert something in the middle. |
We could rename bcm2712-rpi.dtsi now - it might save popcornmix a few minutes someday.
Yes, if they are effectively universal.
External in what way? If you mean sitting outside the rp1 node, I don't think there's any technical reason they have to. There's no address mapping involved in the firmware - no addresses are exchanged. Clocks and regulators can be declared anywhere, even if they may need a simple-bus to get them enumerated.
Isn't that already the case? The hierarchies I included above are complete, simple as they are. The upstream additions have made it worse, but we don't need to make it worser. |
Signed-off-by: Dave Stevenson <[email protected]>
Adds bcm2712-ds.dtsi to define all the bits that aren't in the mainline file. Currently there are going to be various Pi5 specific sections in there. Propose splitting into a set of - bcm2712-rpi-5-b-ds.dtsi - bcm2712-rpi-500-ds.dtsi - bcm2712-rpi-cm5-ds.dtsi etc, so that the those files can contain the platform specific modifications required. Signed-off-by: Dave Stevenson <[email protected]>
This reverts commit 5c670f1.
This reverts commit 3f6ad6e.
This reverts commit a62da48.
Declare the positional index for the RP1 MIPI clocks. Signed-off-by: Andrea della Porta <[email protected]> Reviewed-by: Stephen Boyd <[email protected]>
The RP1 clock generator driver currently defines only the fundamental clocks such as the front PLLs for system, audio and video subsystems and the ethernet clock. Add the remaining clocks to the tree so as to be completed, which means that the following RP1 peripherals could now consume their specific clocks and be enabled to work (provided that the relevant driver changes for each specific peripheral, if any, are committed): - ADC - Audio IN/OUT - DMA controller - I2S - MIPI DPI/DSI - PWM - SDIO - UART - Video Encoder Signed-off-by: Andrea della Porta <[email protected]> Reviewed-by: Stephen Boyd <[email protected]>
6by9
force-pushed
the
rpi-6.17.y-mainline-dt
branch
from
02c6dac to
a5aa476
Compare
6by9
force-pushed
the
rpi-6.17.y-mainline-dt
branch
from
a5aa476 to
77a0132
Compare
Done, and will be looking to do the equivalent as bcm2712-rpi.dtsi on mainline next week.
Branch updated doing that.
Moved inside rp1 node. Seems to work.
With the new tree, yes. I was saying that I didn't want to revert to the old massive heirarchy. Branch updated and boots Pi5 OK. Has working ethernet, USB, HDMI, serial console (although I do still have the extra entry in cmdline.txt). One error to resolve: Looks like address mapping issues CM5 needs updating still to use the new files. |
Show me what you consider to be the old massive hierarchy? |
I'm wanting comments on approach more than a full review.
At present there is a fair amount of board specific stuff mixed in to bcm2712-ds.dtsi, which is why CM5 is disabled just to reduce the number of errors thrown out as I was fixing it up.
I'm suggesting we have bcm2712-rpi-5-b-ds.dtsi, bcm2712-rpi-500-ds.dtsi, bcm2712-rpi-cm5-ds.dtsi, etc, to contain the board specific stuff, and those will
#include "bcm2712-ds.dtsi"which will define the devices. Hopefully the only changes to the main upstream files will then be to add the include that downstream one, therefore making Dom's life easier. As more devices get upstream support they will move from -ds.dtsi to the main files.I'm aware that I'm missing HDMI audio dma configuration at present. I'm not seeing any other major omissions from the kernel logs, but haven't tested everything.
@pelwell - you'd reverted the clock driver to the downstream one. I know it's missing RP1_CLK_SDIO_TIMER and RP1_CLK_SDIO_ALT_SRC, but what else do you think it is missing? (I'll try and derive the entries for those two clocks now)