Phil Elwell [Fri, 29 Sep 2017 09:32:19 +0000 (10:32 +0100)]
amba_pl011: Add cts-event-workaround DT property
The BCM2835 PL011 implementation seems to have a bug that can lead to a
transmission lockup if CTS changes frequently. A workaround was added to
the driver with a vendor-specific flag to enable it, but this flag is
currently not set for ARM implementations.
Add a "cts-event-workaround" property to Pi DTBs and use the presence
of that property to force the flag to be enabled in the driver.
See: https://github.com/raspberrypi/linux/issues/1280
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Phil Elwell [Fri, 29 Sep 2017 09:32:19 +0000 (10:32 +0100)]
amba_pl011: Insert mb() for correct FIFO handling
The pl011 register accessor functions use the _relaxed versions of the
standard readl() and writel() functions, meaning that there are no
automatic memory barriers. When polling a FIFO status register to check
for fullness, it is necessary to ensure that any outstanding writes have
completed; otherwise the flags are effectively stale, making it possible
that the next write is to a full FIFO.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Phil Elwell [Tue, 17 Oct 2017 14:04:29 +0000 (15:04 +0100)]
lan78xx: Enable LEDs and auto-negotiation
For applications of the LAN78xx that don't have valid programmed
EEPROMs or OTPs, enabling both LEDs and auto-negotiation by default
seems reasonable.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Phil Elwell [Tue, 23 Jan 2018 16:52:45 +0000 (16:52 +0000)]
irqchip: irq-bcm2836: Remove regmap and syscon use
The syscon node defines a register range that duplicates that used by
the local_intc node on bcm2836/7. Since irq-bcm2835 and irq-bcm2836 are
built in and always present together (both drivers are enabled by
CONFIG_ARCH_BCM2835), it is possible to replace the syscon usage with a
global variable that simplifies the code. Doing so does lose the
locking provided by regmap, but as only one side is using the regmap
interface (irq-bcm2835 uses readl and write) there is no loss of
atomicity.
See: https://github.com/raspberrypi/firmware/issues/926
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Noralf Trønnes [Tue, 1 Nov 2016 14:15:41 +0000 (15:15 +0100)]
i2c: bcm2835: Add debug support
This adds a debug module parameter to aid in debugging transfer issues
by printing info to the kernel log. When enabled, status values are
collected in the interrupt routine and msg info in
bcm2835_i2c_start_transfer(). This is done in a way that tries to avoid
affecting timing. Having printk in the isr can mask issues.
debug values (additive):
1: Print info on error
2: Print info on all transfers
3: Print messages before transfer is started
The value can be changed at runtime:
/sys/module/i2c_bcm2835/parameters/debug
Example output, debug=3:
[ 747.114448] bcm2835_i2c_xfer: msg(1/2) write addr=0x54, len=2 flags= [i2c1]
[ 747.114463] bcm2835_i2c_xfer: msg(2/2) read addr=0x54, len=32 flags= [i2c1]
[ 747.117809] start_transfer: msg(1/2) write addr=0x54, len=2 flags= [i2c1]
[ 747.117825] isr: remain=2, status=0x30000055 : TA TXW TXD TXE [i2c1]
[ 747.117839] start_transfer: msg(2/2) read addr=0x54, len=32 flags= [i2c1]
[ 747.117849] isr: remain=32, status=0xd0000039 : TA RXR TXD RXD [i2c1]
[ 747.117861] isr: remain=20, status=0xd0000039 : TA RXR TXD RXD [i2c1]
[ 747.117870] isr: remain=8, status=0x32 : DONE TXD RXD [i2c1]
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Claggy3 [Sat, 11 Feb 2017 14:00:30 +0000 (14:00 +0000)]
Update vfpmodule.c
Christopher Alexander Tobias Schulze - May 2, 2015, 11:57 a.m.
This patch fixes a problem with VFP state save and restore related
to exception handling (panic with message "BUG: unsupported FP
instruction in kernel mode") present on VFP11 floating point units
(as used with ARM1176JZF-S CPUs, e.g. on first generation Raspberry
Pi boards). This patch was developed and discussed on
https://github.com/raspberrypi/linux/issues/859
A precondition to see the crashes is that floating point exception
traps are enabled. In this case, the VFP11 might determine that a FPU
operation needs to trap at a point in time when it is not possible to
signal this to the ARM11 core any more. The VFP11 will then set the
FPEXC.EX bit and store the trapped opcode in FPINST. (In some cases,
a second opcode might have been accepted by the VFP11 before the
exception was detected and could be reported to the ARM11 - in this
case, the VFP11 also sets FPEXC.FP2V and stores the second opcode in
FPINST2.)
If FPEXC.EX is set, the VFP11 will "bounce" the next FPU opcode issued
by the ARM11 CPU, which will be seen by the ARM11 as an undefined opcode
trap. The VFP support code examines the FPEXC.EX and FPEXC.FP2V bits
to decide what actions to take, i.e., whether to emulate the opcodes
found in FPINST and FPINST2, and whether to retry the bounced instruction.
If a user space application has left the VFP11 in this "pending trap"
state, the next FPU opcode issued to the VFP11 might actually be the
VSTMIA operation vfp_save_state() uses to store the FPU registers
to memory (in our test cases, when building the signal stack frame).
In this case, the kernel crashes as described above.
This patch fixes the problem by making sure that vfp_save_state() is
always entered with FPEXC.EX cleared. (The current value of FPEXC has
already been saved, so this does not corrupt the context. Clearing
FPEXC.EX has no effects on FPINST or FPINST2. Also note that many
callers already modify FPEXC by setting FPEXC.EN before invoking
vfp_save_state().)
This patch also addresses a second problem related to FPEXC.EX: After
returning from signal handling, the kernel reloads the VFP context
from the user mode stack. However, the current code explicitly clears
both FPEXC.EX and FPEXC.FP2V during reload. As VFP11 requires these
bits to be preserved, this patch disables clearing them for VFP
implementations belonging to architecture 1. There should be no
negative side effects: the user can set both bits by executing FPU
opcodes anyway, and while user code may now place arbitrary values
into FPINST and FPINST2 (e.g., non-VFP ARM opcodes) the VFP support
code knows which instructions can be emulated, and rejects other
opcodes with "unhandled bounce" messages, so there should be no
security impact from allowing reloading FPEXC.EX and FPEXC.FP2V.
Signed-off-by: Christopher Alexander Tobias Schulze <cat.schulze@alice-dsl.net>
Phil Elwell [Thu, 9 Feb 2017 14:36:44 +0000 (14:36 +0000)]
sound: Demote deferral errors to INFO level
At present there is no mechanism to specify driver load order,
which can lead to deferrals and repeated retries until successful.
Since this situation is expected, reduce the dmesg level to
INFO and mention that the operation will be retried.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix [Tue, 6 Dec 2016 17:05:39 +0000 (17:05 +0000)]
bcm2835-rng: Avoid initialising if already enabled
Avoids the 0x40000 cycles of warmup again if firmware has already used it
popcornmix [Wed, 9 Nov 2016 13:02:52 +0000 (13:02 +0000)]
bcm: Make RASPBERRYPI_POWER depend on PM
popcornmix [Tue, 5 Apr 2016 18:40:12 +0000 (19:40 +0100)]
reboot: Use power off rather than busy spinning when halt is requested
reboot: Use power off rather than busy spinning when halt is requested
Busy spinning after halt is dumb
We've previously applied this patch to arch/arm
but it is currenltly missing in arch/arm64
Pi4 after "sudo halt" uses 520mA
Pi4 after "sudo shutdown now" uses 310mA
Make them both use the lower powered option
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Noralf Trønnes [Fri, 7 Oct 2016 14:50:59 +0000 (16:50 +0200)]
watchdog: bcm2835: Support setting reboot partition
The Raspberry Pi firmware looks at the RSTS register to know which
partition to boot from. The reboot syscall command
LINUX_REBOOT_CMD_RESTART2 supports passing in a string argument.
Add support for passing in a partition number 0..63 to boot from.
Partition 63 is a special partiton indicating halt.
If the partition doesn't exist, the firmware falls back to partition 0.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Phil Elwell [Wed, 15 Jun 2016 15:48:41 +0000 (16:48 +0100)]
rtc: Add SPI alias for pcf2123 driver
Without this alias, Device Tree won't cause the driver
to be loaded.
See: https://github.com/raspberrypi/linux/pull/1510
Noralf Trønnes [Sat, 3 Oct 2015 20:22:55 +0000 (22:22 +0200)]
dmaengine: bcm2835: Load driver early and support legacy API
Load driver early since at least bcm2708_fb doesn't support deferred
probing and even if it did, we don't want the video driver deferred.
Support the legacy DMA API which is needed by bcm2708_fb.
Don't mask out channel 2.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
bcm2835-dma: Add support for per-channel flags
Add the ability to interpret the high bits of the dreq specifier as
flags to be included in the DMA_CS register. The motivation for this
change is the ability to set the DISDEBUG flag for SD card transfers
to avoid corruption when using the VPU debugger.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
bcm2835-dma: Add proper 40-bit DMA support
BCM2711 has 4 DMA channels with a 40-bit address range, allowing them
to access the full 4GB of memory on a Pi 4.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
bcm2835-dma: Derive slave DMA addresses correctly
Slave addresses for DMA are meant to be supplied as physical addresses
(contrary to what struct snd_dmaengine_dai_dma_data does). It is up to
the DMA controller driver to perform the translation based on its own
view of the world, as described in Device Tree.
Now that the Pi Device Trees have the correct peripheral mappings,
replace the hacky address munging with phys_to_dma().
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
bcm2835-dma: Add NO_WAIT_RESP flag
Use bit 27 of the dreq value (the second cell of the DT DMA descriptor)
to request that the WAIT_RESP bit is not set.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
bcm2835-dma: Advertise the full DMA range
Unless the DMA mask is set wider than 32 bits, DMA mapping will use a
bounce buffer.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
bcm2835-dma: only reserve channel 0 if legacy dma driver is enabled
If CONFIG_DMA_BCM2708 isn't enabled there's no need to mask out
one of the already scarce DMA channels.
Signed-off-by: Matthias Reichl <hias@horus.com>
bcm2835-dma: Avoid losing CS flags after interrupt
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
bcm2835-dma: Add bcm2835-dma: Add DMA_WIDE_SOURCE and DMA_WIDE_DEST flags
Use (reserved) bits 24 and 25 of the dreq value
(the second cell of the DT DMA descriptor) to request
that wide source reads or wide dest writes are required
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
dmaengine: bcm2835: Fix position reporting for 40 bits channels
For 40 bits channels, the position is reported by reading the upper byte
in the SRCI/DESTI registers. However the driver adds that upper byte
with an 8-bits left shift, while it should be 32.
Fixes:
9a52a9918306 ("bcm2835-dma: Add proper 40-bit DMA support")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
dmaengine: bcm2835: Use to_bcm2711_cbaddr where relevant
bcm2711_dma40_memcpy has some code strictly equivalent to the
to_bcm2711_cbaddr() function. Let's use it instead.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
dmaengine: bcm2835: Fix descriptors usage for 40-bits channels
The bcm2835_dma_create_cb_chain() function is in charge of building up
the descriptors chain for a given transfer.
It was initially supporting only the BCM2835-style DMA controller, and
was later expanded to support controllers with 40-bits channels that use
a different descriptor layout.
However, some part of the function only use the old style descriptor,
even when building a chain of new-style descriptors, resulting in weird
bugs.
Fixes:
9a52a9918306 ("bcm2835-dma: Add proper 40-bit DMA support")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
bcm2835-dma: Fix WAIT_RESP on memcpy
It goes in info not extra
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
bcm2835-dma: Fix dma_abort for 40-bit channels
It wasn't aborting the transfer and caused stop/start
of hdmi audio dma to be unreliable.
New sequence approved by Broadcom.
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
bcm2835-dma: Fix dma_abort for non-40bit channels
The sequence we were doing was not safe.
Clearing CS meant BCM2835_DMA_WAIT_FOR_WRITES was cleared
and so polling BCM2835_DMA_WAITING_FOR_WRITES has no benefit
Broadcom have provided a recommended sequence to abort
a dma lite channel, so switch to that.
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
bcm2835-dma: Support dma flags for multi-beat burst
Add a control bit to enable a multi-beat burst on a DMA.
This improves DMA performance and is required for HDMI audio.
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
bcm2835-dma: Need to keep PROT bits set in CS on 40bit controller
Resetting them to zero puts DMA channel into secure mode
which makes further accesses impossible
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Dom Cobley [Mon, 24 Jan 2022 13:41:16 +0000 (13:41 +0000)]
spi: spidev: Completely disable the spidev warning
An alternative strategy would be to use "rpi,spidev" instead, but that
would require many Raspberry Pi Device Tree changes.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Noralf Trønnes [Fri, 23 Oct 2015 14:26:55 +0000 (16:26 +0200)]
irqchip: irq-bcm2835: Add 2836 FIQ support
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Noralf Trønnes [Fri, 12 Jun 2015 17:01:05 +0000 (19:01 +0200)]
irqchip: bcm2835: Add FIQ support
Add a duplicate irq range with an offset on the hwirq's so the
driver can detect that enable_fiq() is used.
Tested with downstream dwc_otg USB controller driver.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Phil Elwell [Thu, 9 Feb 2017 14:33:30 +0000 (14:33 +0000)]
irq-bcm2836: Avoid "Invalid trigger warning"
Initialise the level for each IRQ to avoid a warning from the
arm arch timer code.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Phil Elwell [Fri, 13 Mar 2015 12:43:36 +0000 (12:43 +0000)]
Protect __release_resource against resources without parents
Without this patch, removing a device tree overlay can crash here.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Phil Elwell [Mon, 27 Nov 2017 17:14:54 +0000 (17:14 +0000)]
cgroup: Disable cgroup "memory" by default
Some Raspberry Pis have limited RAM and most users won't use the
cgroup memory support so it is disabled by default. Enable with:
cgroup_enable=memory
See: https://github.com/raspberrypi/linux/issues/1950
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix [Tue, 26 Mar 2013 17:26:38 +0000 (17:26 +0000)]
Allow mac address to be set in smsc95xx
Signed-off-by: popcornmix <popcornmix@gmail.com>
SQUASH: smsc95xx: Use dev_mod_addr to set MAC addr
Since
adeef3e32146 ("net: constify netdev->dev_addr") it has been
illegal to write to the dev_addr MAC address field. Later commits
have added explicit checks that it hasn't been modified by nefarious
means. The dev_addr_mod helper function is the accepted way to change
the dev_addr field, so use it.
Squash with
96c1def63ee1 ("Allow mac address to be set in smsc95xx").
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Sam Nazarko [Fri, 1 Apr 2016 16:27:21 +0000 (17:27 +0100)]
smsc95xx: Experimental: Enable turbo_mode and packetsize=2560 by default
See: http://forum.kodi.tv/showthread.php?tid=285288
Steve Glendinning [Thu, 19 Feb 2015 18:47:12 +0000 (18:47 +0000)]
smsx95xx: fix crimes against truesize
smsc95xx is adjusting truesize when it shouldn't, and following a recent patch from Eric this is now triggering warnings.
This patch stops smsc95xx from changing truesize.
Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
Dom Cobley [Mon, 31 Jul 2023 12:47:10 +0000 (13:47 +0100)]
Revert "Revert "xhci: add quirk for host controllers that don't update endpoint DCS""
This reverts commit
5bef4b3cb95a5b883dfec8b3ffc0d671323d55bb.
We don't agree with upstream revert so undo it.
Phil Elwell [Mon, 7 Mar 2022 16:18:55 +0000 (16:18 +0000)]
Revert "net: bcmgenet: Request APD, DLL disable and IDDQ-SR"
This reverts commit
c3a4c69360ab43560f212eed326c9d8bde35b14c, which
broke rebooting when network booting.
See: https://github.com/raspberrypi/rpi-eeprom/issues/417
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Phil Elwell [Mon, 1 Mar 2021 09:14:35 +0000 (09:14 +0000)]
Revert "Bluetooth: Always request for user confirmation for Just Works"
This reverts commit
92516cd97fd4d8ad5b1421a0d51771044f453a5f.
Thi commit "Bluetooth: Always request for user confirmation for Just
Works" prevents BLE devices pairing in (at least) the Raspberry Pi OS
GUI. After reverting it, pairing works again.
If another solution to the problem is found then this reversion will
be removed.
See: https://github.com/raspberrypi/linux/issues/4139
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Phil Elwell [Mon, 1 Mar 2021 09:12:44 +0000 (09:12 +0000)]
Revert "Bluetooth: Always request for user confirmation for Just Works (LE SC)"
This reverts commit
ffee202a78c2980688bc5d2f7d56480e69a5e0c9.
The commit "Bluetooth: Always request for user confirmation for Just
Works" prevents BLE devices pairing in (at least) the Raspberry Pi OS
GUI. After reverting it, pairing works again. Although this companion
commit ("... (LE SC)") has not been demonstrated to be problematic,
it follows the same logic and therefore could affect some use cases.
If another solution to the problem is found then this reversion will
be removed.
See: https://github.com/raspberrypi/linux/issues/4139
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Phil Elwell [Mon, 20 Apr 2020 12:41:10 +0000 (13:41 +0100)]
Revert "spi: spidev: Fix CS polarity if GPIO descriptors are used"
This reverts commit
83b2a8fe43bda0c11981ad6afa5dd0104d78be28.
popcornmix [Fri, 25 Aug 2017 18:18:13 +0000 (19:18 +0100)]
cache: export clean and invalidate
hack: cache: Fix linker error
Dan Pasanen [Thu, 21 Sep 2017 14:55:42 +0000 (09:55 -0500)]
arm: partially revert
702b94bff3c50542a6e4ab9a4f4cef093262fe65
* Re-expose some dmi APIs for use in VCSM
Dom Cobley [Tue, 19 Oct 2021 13:14:55 +0000 (14:14 +0100)]
clk-bcm2835: Remove VEC clock support
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Phil Elwell [Thu, 8 Jul 2021 08:37:10 +0000 (09:37 +0100)]
clk: bcm2835: Pass DT node to rpi_firmware_get
The fw_node pointer has already been retrieved, and using it allows
us to remove a downstream patch to the firmware driver.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix [Tue, 3 Sep 2019 19:28:00 +0000 (20:28 +0100)]
clk-bcm2835: Disable v3d clock
This is controlled by firmware, see clk-raspberrypi.c
Signed-off-by: popcornmix <popcornmix@gmail.com>
popcornmix [Tue, 6 Aug 2019 14:23:14 +0000 (15:23 +0100)]
clk-bcm2835: Avoid null pointer exception
clk_desc_array[BCM2835_PLLB] doesn't exist so we dereference null when iterating
Signed-off-by: popcornmix <popcornmix@gmail.com>
Eric Anholt [Thu, 2 May 2019 22:24:04 +0000 (15:24 -0700)]
clk: bcm2835: Allow reparenting leaf clocks while they're running.
This falls under the same "we can reprogram glitch-free as long as we
pause generation" rule as updating the div/frac fields. This can be
used for runtime reclocking of V3D to manage power leakage.
Signed-off-by: Eric Anholt <eric@anholt.net>
Eric Anholt [Thu, 2 May 2019 22:11:05 +0000 (15:11 -0700)]
clk: bcm2835: Add support for setting leaf clock rates while running.
As long as you wait for !BUSY, you can do glitch-free updates of clock
rate while the clock is running.
Signed-off-by: Eric Anholt <eric@anholt.net>
Phil Elwell [Wed, 23 Jan 2019 16:11:50 +0000 (16:11 +0000)]
clk-bcm2835: Don't wait for pllh lock
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Dave Stevenson [Thu, 24 Jan 2019 15:09:28 +0000 (15:09 +0000)]
clk: clk-bcm2835: Use %zd when printing size_t
The debug text for how many clocks have been registered
uses "%d" with a size_t. Correct it to "%zd".
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
Phil Elwell [Mon, 6 Mar 2017 09:06:18 +0000 (09:06 +0000)]
clk-bcm2835: Read max core clock from firmware
The VPU is responsible for managing the core clock, usually under
direction from the bcm2835-cpufreq driver but not via the clk-bcm2835
driver. Since the core frequency can change without warning, it is
safer to report the maximum clock rate to users of the core clock -
I2C, SPI and the mini UART - to err on the safe side when calculating
clock divisors.
If the DT node for the clock driver includes a reference to the
firmware node, use the firmware API to query the maximum core clock
instead of reading the divider registers.
Prior to this patch, a "100KHz" I2C bus was sometimes clocked at about
160KHz. In particular, switching to the 4.9 kernel was likely to break
SenseHAT usage on a Pi3.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Phil Elwell [Mon, 13 Feb 2017 17:20:08 +0000 (17:20 +0000)]
clk-bcm2835: Add claim-clocks property
The claim-clocks property can be used to prevent PLLs and dividers
from being marked as critical. It contains a vector of clock IDs,
as defined by dt-bindings/clock/bcm2835.h.
Use this mechanism to claim PLLD_DSI0, PLLD_DSI1, PLLH_AUX and
PLLH_PIX for the vc4_kms_v3d driver.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Phil Elwell [Mon, 13 Feb 2017 17:20:08 +0000 (17:20 +0000)]
clk-bcm2835: Mark used PLLs and dividers CRITICAL
The VPU configures and relies on several PLLs and dividers. Mark all
enabled dividers and their PLLs as CRITICAL to prevent the kernel from
switching them off.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Martin Sperl [Fri, 2 Sep 2016 15:45:27 +0000 (16:45 +0100)]
Register the clocks early during the boot process, so that special/critical clocks can get enabled early on in the boot process avoiding the risk of disabling a clock, pll_divider or pll when a claiming driver fails to install propperly - maybe it needs to defer.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Dom Cobley [Tue, 12 Apr 2022 19:07:20 +0000 (20:07 +0100)]
clk-raspberrypi: Add ISP to exported clocks
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix [Mon, 13 Apr 2015 16:16:29 +0000 (17:16 +0100)]
config: Add default configs
notro [Wed, 9 Jul 2014 12:46:08 +0000 (14:46 +0200)]
BCM2708: Add core Device Tree support
Add the bare minimum needed to boot BCM2708 from a Device Tree.
Signed-off-by: Noralf Tronnes <notro@tronnes.org>
BCM2708: DT: change 'axi' nodename to 'soc'
Change DT node named 'axi' to 'soc' so it matches ARCH_BCM2835.
The VC4 bootloader fills in certain properties in the 'axi' subtree,
but since this is part of an upstreaming effort, the name is changed.
Signed-off-by: Noralf Tronnes notro@tronnes.org
BCM2708_DT: Correct length of the peripheral space
Use dts-dirs feature for overlays.
The kernel makefiles have a dts-dirs target that is for vendor subdirectories.
Using this fixes the install_dtbs target, which previously did not install the overlays.
BCM270X_DT: configure I2S DMA channels
Signed-off-by: Matthias Reichl <hias@horus.com>
BCM270X_DT: switch to bcm2835-i2s
I2S soundcard drivers with proper devicetree support (i.e. not linking
to the cpu_dai/platform via name but to cpu/platform via of_node)
will work out of the box without any modifications.
When the kernel is compiled without devicetree support the platform
code will instantiate the bcm2708-i2s driver and I2S soundcard drivers
will link to it via name, as before.
Signed-off-by: Matthias Reichl <hias@horus.com>
SDIO-overlay: add poll_once-boolean parameter
Add paramter to toggle sdio-device-polling
done every second or once at boot-time.
Signed-off-by: Patrick Boettcher <patrick.boettcher@posteo.de>
BCM270X_DT: Make mmc overlay compatible with current firmware
The original DT overlay logic followed a merge-then-patch procedure,
i.e. parameters are applied to the loaded overlay before the overlay
is merged into the base DTB. This sequence has been changed to
patch-then-merge, in order to support parameterised node names, and
to protect against bad overlays. As a result, overrides (parameters)
must only target labels in the overlay, but the overlay can obviously target nodes in the base DTB.
mmc-overlay.dts (that switches back to the original mmc sdcard
driver) is the only overlay violating that rule, and this patch
fixes it.
bcm270x_dt: Use the sdhost MMC controller by default
The "mmc" overlay reverts to using the other controller.
squash: Add cprman to dt
BCM270X_DT: Use clk_core for I2C interfaces
BCM270X_DT: Use bcm283x.dtsi, bcm2835.dtsi and bcm2836.dtsi
The mainline Device Tree files are quite close to downstream now.
Let's use bcm283x.dtsi, bcm2835.dtsi and bcm2836.dtsi as base files
for our dts files.
Mainline dts files are based on these files:
bcm2835-rpi.dtsi
bcm2835.dtsi bcm2836.dtsi
bcm283x.dtsi
Current downstream are based on these:
bcm2708.dtsi bcm2709.dtsi bcm2710.dtsi
bcm2708_common.dtsi
This patch introduces this dependency:
bcm2708.dtsi bcm2709.dtsi
bcm2708-rpi.dtsi
bcm270x.dtsi
bcm2835.dtsi bcm2836.dtsi
bcm283x.dtsi
And:
bcm2710.dtsi
bcm2708-rpi.dtsi
bcm270x.dtsi
bcm283x.dtsi
bcm270x.dtsi contains the downstream bcm283x.dtsi diff.
bcm2708-rpi.dtsi is the downstream version of bcm2835-rpi.dtsi.
Other changes:
- The led node has moved from /soc/leds to /leds. This is not a problem
since the label is used to reference it.
- The clk_osc reg property changes from 6 to 3.
- The gpu nodes has their interrupt property set in the base file.
- the clocks label does not point to the /clocks node anymore, but
points to the cprman node. This is not a problem since the overlays
that use the clock node refer to it directly: target-path = "/clocks";
- some nodes now have 2 labels since mainline and downstream differs in
this respect: cprman/clocks, spi0/spi, gpu/vc4.
- some nodes doesn't have an explicit status = "okay" since they're not
disabled in the base file: watchdog and random.
- gpiomem doesn't need an explicit status = "okay".
- bcm2708-rpi-cm.dts got the hpd-gpios property from bcm2708_common.dtsi,
it's now set directly in that file.
- bcm2709-rpi-2-b.dts has the timer node moved from /soc/timer to /timer.
- Removed clock-frequency property on the bcm{2709,2710}.dtsi timer nodes.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
BCM270X_DT: Use raspberrypi-power to turn on USB power
Use the raspberrypi-power driver to turn on USB power.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
BCM270X_DT: Add a .dtbo target, use for overlays
Change the filenames and extensions to keep the pre-DDT style of
overlay (<name>-overlay.dtb) distinct from new ones that use a
different style of local fixups (<name>.dtbo), and to match other
platforms.
The RPi firmware uses the DDTK trailer atom to choose which type of
overlay to use for each kernel.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
BCM270X_DT: Don't generate "linux,phandle" props
The EPAPR standard says to use "phandle" properties to store phandles,
rather than the deprecated "linux,phandle" version. By default, dtc
generates both, but adding "-H epapr" causes it to only generate
"phandle"s, saving some space and clutter.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
BCM270X_DT: Add overlay for enc28j60 on SPI2
Works on SPI2 for compute module
BCM270X_DT: Add midi-uart0 overlay
MIDI requires 31.25kbaud, a baudrate unsupported by Linux. The
midi-uart0 overlay configures uart0 (ttyAMA0) to use a fake clock
so that requesting 38.4kbaud actually gets 31.25kbaud.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
BCM270X_DT: Add i2c-sensor overlay
The i2c-sensor overlay is a container for various pressure and
temperature sensors, currently bmp085 and bmp280. The standalone
bmp085_i2c-sensor overlay is now deprecated.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
BCM270X_DT: overlays/*-overlay.dtb -> overlays/*.dtbo (#1752)
We now create overlays as .dtbo files.
build: support for .dtbo files for dtb overlays
Kernel 4.4.6+ on RaspberryPi support .dtbo files for overlays, instead of .dtb.
Patch the kernel, which has faulty rules to generate .dtbo the way yocto does
Signed-off-by: Herve Jourdain <herve.jourdain@neuf.fr>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
BCM270X: Drop position requirement for CMA in VC4 overlay.
No longer necessary since
2aefcd576195a739a7a256099571c9c4a401005f,
and will probably let peeople that want to choose a larger CMA
allocation (particularly on pi0/1).
Signed-off-by: Eric Anholt <eric@anholt.net>
BCM270X_DT: RPi Device Tree tidy
Use the upstream sdhost node, add thermal-zones, and factor out some
common elements.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
kbuild: Silence unhelpful DTC warnings
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
BCM270X_DT: DT build rules no longer arch-specific
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Maxime Ripard [Mon, 6 Jun 2022 09:02:16 +0000 (11:02 +0200)]
arm64: setup: Fix build warning
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Dave Stevenson [Mon, 24 Apr 2023 17:32:45 +0000 (18:32 +0100)]
drm/vc4: Limit max_bpc to 8 on Pi0-3
Pi 0-3 have no deep colour support and only 24bpp output,
so max_bpc should remain as 8.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Matthias Reichl [Sat, 11 Mar 2023 21:41:17 +0000 (22:41 +0100)]
drm/vc4: drop unnecessary and harmful HDMI RGB format check
RGB is a mandatory format for all DVI and HDMI monitors so there's
no need to check for presence of the DRM_COLOR_FORMAT_RGB444 bit in
color_formats.
More importantly this checks breaks working around EDID issues with
eg video=HDMI-A-1:1024x768D or drm.edid_firmware=edid/1024x768.bin
as the RGB444 bit is only set when a valid EDID with digital bit set in
the input byte is present - which isn't the case when no EDID can be
read from the display device at all or with the in-built kernel EDIDs,
which mimic analog (VGA) displays without the digital bit set.
So drop the check, if we output video on the HDMI connector we can
assume that the display can accept 8bit RGB.
Signed-off-by: Matthias Reichl <hias@horus.com>
Dave Stevenson [Thu, 11 Aug 2022 12:59:34 +0000 (13:59 +0100)]
drm/vc4: Set AXI panic modes for the HVS
The HVS can change AXI request mode based on how full the COB
FIFOs are.
Until now the vc4 driver has been relying on the firmware to
have set these to sensible values.
With HVS channel 2 now being used for live video, change the
panic mode for all channels to be explicitly set by the driver,
and the same for all channels.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Matthias Reichl [Sat, 14 Jan 2023 15:24:39 +0000 (16:24 +0100)]
drm/vc4: Calculate bpc based on max_requested_bpc
This aligns vc4 with Intel, AMD and Synopsis drivers and fixes max bpc
connector property not working as expected on monitors with YCbCr 4:2:2
support but not deep color support.
max_bpc in connector state is clamped at max_bpc from display info and
the latter only takes deep color modes into account so it will always
be 8, even if the display can do 4:2:2 12-bit output.
Signed-off-by: Matthias Reichl <hias@horus.com>
Dom Cobley [Tue, 31 Jan 2023 15:14:32 +0000 (15:14 +0000)]
drm/vc4_plane: Add support for YUV444 formats
Support displaying DRM_FORMAT_YUV444 and DRM_FORMAT_YVU444 formats.
Tested with kmstest and kodi. e.g.
kmstest -r 1920x1080@60 -f 400x300-YU24
Note: without the shift of width, only half the chroma is fetched,
resulting in correct left half of image and corrupt colours on right half.
The increase in width shouldn't affect fetching of Y data,
as the hardware will clamp at dest width.
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Maxime Ripard [Wed, 25 Jan 2023 12:05:26 +0000 (13:05 +0100)]
drm/vc4: hvs: Destroy dlist allocations immediately when running a test
When running a kunit test, the driver runs with a mock device. As such,
any attempt to read or write to a hardware register will fail the
current test immediately.
The dlist allocation management recently introduced will read the
current frame count from the HVS to defer its destruction until a
subsequent frame has been output. This obviously involves a register
read that fails the Kunit tests.
Change the destruction deferral function to destroy the allocation
immediately if we run under kunit. This is essentially harmless since
the main reason for that deferall is to prevent any access to the
hardware dlist while a frame described by that list is rendered. On our
mock driver, we have neither a hardware dlist nor a rendering, so it
doesn't matter.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Wed, 25 Jan 2023 11:54:36 +0000 (12:54 +0100)]
drm/vc4: hvs: Move the dlist allocation destruction to a function
We'll need to destroy a dlist allocation in multiple code paths, so
let's move it to a separate function.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Wed, 25 Jan 2023 11:38:37 +0000 (12:38 +0100)]
drm/vc4: hvs: Initialize the dlist allocation list entry
The vc4_hvs_dlist_allocation structure has a list that we don't
initialize when we allocate a new instance.
This makes any call reading the list structure (such as list_empty) fail
with a NULL pointer dereference.
Let's make sure our list is always initialized.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Thu, 16 Dec 2021 13:54:54 +0000 (14:54 +0100)]
drm/vc4: hvs: Defer dlist slots deallocation
During normal operations, the cursor position update is done through an
asynchronous plane update, which on the vc4 driver basically just
modifies the right dlist word to move the plane to the new coordinates.
However, when we have the overscan margins setup, we fall back to a
regular commit when we are next to the edges. And since that commit
happens to be on a cursor plane, it's considered a legacy cursor update
by KMS.
The main difference it makes is that it won't wait for its completion
(ie, next vblank) before returning. This means if we have multiple
commits happening in rapid succession, we can have several of them
happening before the next vblank.
In parallel, our dlist allocation is tied to a CRTC state, and each time
we do a commit we end up with a new CRTC state, with the previous one
being freed. This means that we free our previous dlist entry (but don't
clear it though) every time a new one is being committed.
Now, if we were to have two commits happening before the next vblank, we
could end up freeing reusing the same dlist entries before the next
vblank.
Indeed, we would start from an initial state taking, for example, the
dlist entries 10 to 20, then start a commit taking the entries 20 to 30
and setting the dlist pointer to 20, and freeing the dlist entries 10 to
20. However, since we haven't reach vblank yet, the HVS is still using
the entries 10 to 20.
If we were to make a new commit now, chances are the allocator are going
to give the 10 to 20 entries back, and we would change their content to
match the new state. If vblank hasn't happened yet, we just corrupted
the active dlist entries.
A first attempt to solve this was made by creating an intermediate dlist
buffer to store the current (ie, as of the last commit) dlist content,
that we would update each time the HVS is done with a frame. However, if
the interrupt handler missed the vblank window, we would end up copying
our intermediate dlist to the hardware one during the composition,
essentially creating the same issue.
Since making sure that our interrupt handler runs within a fixed,
constrained, time window would require to make Linux a real-time kernel,
this seems a bit out of scope.
Instead, we can work around our original issue by keeping the dlist
slots allocation longer. That way, we won't reuse a dlist slot while
it's still in flight. In order to achieve this, instead of freeing the
dlist slot when its associated CRTC state is destroyed, we'll queue it
in a list.
A naive implementation would free the buffers in that queue when we get
our end of frame interrupt. However, there's still a race since, just
like in the shadow dlist case, we don't control when the handler for
that interrupt is going to run. Thus, we can end up with a commit adding
an old dlist allocation to our queue during the window between our
actual interrupt and when our handler will run. And since that buffer is
still being used for the composition of the current frame, we can't free
it right away, exposing us to the original bug.
Fortunately for us, the hardware provides a frame counter that is
increased each time the first line of a frame is being generated.
Associating the frame counter the image is supposed to go away to the
allocation, and then only deallocate buffers that have a counter below
or equal to the one we see when the deallocation code should prevent the
above race from occuring.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Dom Cobley [Tue, 6 Dec 2022 15:05:56 +0000 (15:05 +0000)]
vc4_hdmi: Avoid log spam for audio start failure
We regularly get dmesg error reports of:
[ 18.184066] hdmi-audio-codec hdmi-audio-codec.3.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[ 18.184098] MAI: soc_pcm_open() failed (-19)
Currently I get 30 of these when booting to desktop.
We always say, ignore they are harmless, but removing them would be good.
A bit of investigation shows, for me, the errors are all generated by second, unused hdmi interface.
It shows as an alsa device, and pulseaudio attempts to open it (numerous times), generating a kernel
error message each time.
systemctl --user restart pulseaudio.service generates 6 additional error messages.
The error messages all come through:
https://github.com/raspberrypi/linux/blob/
a009a9c0d79dfec114ee5102ec3d3325a172c952/sound/soc/soc-pcm.c#L39
which suggests returning ENOTSUPP, rather that ENODEV will be quiet. And indeed it is.
Note: earlier kernels do not have the quiet ENOTSUPP, so additional cherry-picks will be needed to backport
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Dom Cobley [Wed, 1 Jun 2022 14:43:51 +0000 (15:43 +0100)]
drm/vc4_hdmi: Allow hotplug detect to be forced
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>
Maxime Ripard [Mon, 11 Jul 2022 08:38:25 +0000 (10:38 +0200)]
drm/vc4: hvs: Skip DebugFS Registration for FKMS
FKMS doesn't have an HVS and it's expected. Return from the debugfs init
function immediately if we're running with fkms.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Dave Stevenson [Fri, 1 Apr 2022 16:10:37 +0000 (17:10 +0100)]
drm/atomic: If margins are updated, update all planes.
Margins may be implemented by scaling the planes, but as there
is no way of intercepting the set_property for a standard property,
and all planes are checked in drm_atomic_check_only before the
connectors, there's now way to add the planes into the state
from the driver.
If the margin properties change, add all corresponding planes to
the state.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Daniel Vetter [Fri, 23 Oct 2020 12:39:23 +0000 (14:39 +0200)]
drm/atomic-helpers: remove legacy_cursor_update hacks
The stuff never really worked, and leads to lots of fun because it
out-of-order frees atomic states. Which upsets KASAN, among other
things.
For async updates we now have a more solid solution with the
->atomic_async_check and ->atomic_async_commit hooks. Support for that
for msm and vc4 landed. nouveau and i915 have their own commit
routines, doing something similar.
For everyone else it's probably better to remove the use-after-free
bug, and encourage folks to use the async support instead. The
affected drivers which register a legacy cursor plane and don't either
use the new async stuff or their own commit routine are: amdgpu,
atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx.
Inspired by an amdgpu bug report.
v2: Drop RFC, I think with amdgpu converted over to use
atomic_async_check/commit done in
commit
674e78acae0dfb4beb56132e41cbae5b60f7d662
Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Date: Wed Dec 5 14:59:07 2018 -0500
drm/amd/display: Add fast path for cursor plane updates
we don't have any driver anymore where we have userspace expecting
solid legacy cursor support _and_ they are using the atomic helpers in
their fully glory. So we can retire this.
v3: Paper over msm and i915 regression. The complete_all is the only
thing missing afaict.
v4: Rebased on recent kernel, added extra link for vc4 bug.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=199425
Link: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/
Cc: mikita.lipski@amd.com
Cc: Michel Dänzer <michel@daenzer.net>
Cc: harry.wentland@amd.com
Cc: Rob Clark <robdclark@gmail.com>
Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com>
Tested-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Dave Stevenson [Fri, 1 Apr 2022 10:31:38 +0000 (11:31 +0100)]
drm/vc4: Force trigger of dlist update on margins change
When the margins are changed, the dlist needs to be regenerated
with the changed updated dest regions for each of the planes.
Setting the zpos_changed flag is sufficient to trigger that
without doing a full modeset, therefore set it should the
margins be changed.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dom Cobley [Thu, 27 Jan 2022 15:32:04 +0000 (15:32 +0000)]
vc4/drm:plane: Make use of chroma siting parameter
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Dom Cobley [Wed, 26 Jan 2022 15:58:13 +0000 (15:58 +0000)]
drm: Add chroma siting properties
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Dom Cobley [Fri, 9 Apr 2021 14:00:40 +0000 (15:00 +0100)]
vc4/drm: Handle fractional coordinates using the phase field
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Dom Cobley [Mon, 14 Mar 2022 17:56:10 +0000 (17:56 +0000)]
vc4/drm: vc4_plane: Keep fractional source coords inside state
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Dave Stevenson [Thu, 20 Jan 2022 17:29:36 +0000 (17:29 +0000)]
drm/bridge: tc358762: Ignore EPROBE_DEFER when logging errors
mipi_dsi_attach can fail due to resources not being available
yet, therefore do not log error messages should they occur.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Fri, 17 Dec 2021 13:36:52 +0000 (13:36 +0000)]
drm/dsi: Document the meaning and spec references for MIPI_DSI_MODE_*
The MIPI_DSI_MODE_* flags have fairly terse descriptions and no reference
to the DSI specification as to their exact meaning. Usage has therefore
been rather fluid.
Extend the descriptions and provide references to the part of the
MIPI DSI specification regarding what they mean.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Thu, 13 Jan 2022 11:30:42 +0000 (11:30 +0000)]
drm/vc4: Disable Gamma control on HVS5 due to issues writing the table
Still under investigation, but the conditions under which the HVS
will accept values written to the gamma PWL are not straightforward.
Disable gamma on HVS5 again until it can be resolved to avoid
gamma being enabled with an incorrect table.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Wed, 10 Nov 2021 16:36:12 +0000 (16:36 +0000)]
drm/vc4: Validate the size of the gamma_lut
Add a check to vc4_hvs_gamma_check to ensure a new non-empty
gamma LUT is of the correct length before accepting it.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Mon, 8 Nov 2021 18:25:49 +0000 (18:25 +0000)]
drm/vc4: Only add gamma properties once.
Two calls were made to drm_crtc_enable_color_mgmt to add gamma
and CTM, however they were both set to add the gamma properties,
so they ended up added twice.
Fixes:
766cc6b1f7fc "drm/vc4: Add CTM support"
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Mon, 8 Nov 2021 17:32:45 +0000 (17:32 +0000)]
drm/vc4: Enable gamma block only when required.
With HVS5 the gamma block is now only reprogrammed with
a disable/enable. Loading the table from vc4_hvs_init_channel
(called from vc4_hvs_atomic_enable) appears to be at an
invalid point in time and so isn't applied.
Switch to enabling and disabling the gamma table instead. This
isn't safe if the pipeline is running, but it isn't now.
For HVS4 it is safe to enable and disable dynamically, so
adopt that approach there too.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Tue, 2 Nov 2021 16:01:36 +0000 (16:01 +0000)]
drm: Check whether the gamma lut has changed before updating
drm_crtc_legacy_gamma_set updates the gamma_lut blob unconditionally,
which leads to unnecessary reprogramming of hardware.
Check whether the blob contents has actually changed before
signalling that it has been updated.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Mateusz Kwiatkowski [Wed, 14 Jul 2021 23:08:11 +0000 (01:08 +0200)]
drm/vc4: Make VEC progressive modes readily accessible
Add predefined modelines for the 240p (NTSC) and 288p (PAL) progressive
modes, and report them through vc4_vec_connector_get_modes().
Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Mateusz Kwiatkowski [Wed, 14 Jul 2021 23:08:08 +0000 (01:08 +0200)]
drm/vc4: Relax VEC modeline requirements and add progressive mode support
Make vc4_vec_encoder_atomic_check() accept arbitrary modelines, as long
as they result in somewhat sane output from the VEC. The bounds have
been determined empirically. Additionally, add support for the
progressive 262-line and 312-line modes.
Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Maxime Ripard [Mon, 14 Jun 2021 13:28:30 +0000 (15:28 +0200)]
drm/vc4: hvs: Force modeset on gamma lut change
The HVS Gamma block can only be updated when idle, so we need to disable
the HVS channel when the gamma property is set in an atomic commit.
Since the pixelvalve cannot have its assigned channel halted without
stalling unless it's disabled as well, in our case that means forcing a
full disable / enable cycle on the pipeline.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Dave Stevenson [Wed, 28 Apr 2021 10:32:10 +0000 (12:32 +0200)]
drm/vc4: Add debugfs node that dumps the vc5 gamma PWL entries
This helps with debugging the conversion from a 256 point gamma LUT to
16 point PWL entries as used by the BCM2711.
Co-developed-by: Juerg Haefliger <juergh@canonical.com>
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Dave Stevenson [Tue, 27 Apr 2021 12:24:21 +0000 (14:24 +0200)]
drm/vc4: Add support for gamma on BCM2711
BCM2711 changes from a 256 entry lookup table to a 16 point
piecewise linear function as the pipeline bitdepth has increased
to make a LUT unwieldy.
Implement a simple conversion from a 256 entry LUT that userspace
is likely to expect to 16 evenly spread points in the PWL. This
could be improved with curve fitting at a later date.
Co-developed-by: Juerg Haefliger <juergh@canonical.com>
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Dave Stevenson [Mon, 7 Sep 2020 16:32:27 +0000 (17:32 +0100)]
drm/vc4: Add firmware-kms mode
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/4971
https://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>
Mateusz Kwiatkowski [Wed, 14 Jul 2021 23:08:01 +0000 (01:08 +0200)]
drm/vc4: Allow setting the TV norm via module parameter
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>
Dave Stevenson [Thu, 7 Jan 2021 16:30:55 +0000 (16:30 +0000)]
drm/atomic: Don't fixup modes that haven't been reset
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Tue, 19 May 2020 15:20:30 +0000 (16:20 +0100)]
drm/vc4: Add FKMS as an acceptable node for dma ranges.
Under FKMS, the firmware (via FKMS) also requires the VideoCore cache
aliases for image planes, as defined by the dma-ranges under /soc.
Add rpi-firmware-kms to the list of acceptable nodes to look for
to copy dma config from.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dom Cobley [Thu, 7 Apr 2022 17:23:07 +0000 (18:23 +0100)]
raspberrypi-firmware: Update mailbox commands
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Andreas Blaesius [Wed, 5 Jan 2022 19:38:39 +0000 (20:38 +0100)]
Use GitHubs issue form for bug reports
Use GitHubs issue form for bug reports.
- modern look
- user don't need to mess with given markdown parts while filling the issue template
Setup config.yml for general questions and problems with the Raspbian distribution packages.
Update issue templates (#2736)
Dave Stevenson [Wed, 8 Mar 2023 15:28:19 +0000 (15:28 +0000)]
workflows: We all love checkpatch, so add it to the CI workflows
This is currently running on defaults, so the --strict desired
for media drivers and similar won't be observed. That may be
possible to add later.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
.github: Add Github Workflow for KUnit
Now that we have some KUnit coverage, let's add a github actions file to
run them on each push or pull request.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
.github/workflows: Add dtoverlaycheck workflow
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
.github/workflows: Create workflow to CI kernel builds
Builds the bcmrpi, bcm2709, bcm2711, and bcm2835 32 bit kernels,
and defconfig and bcm2711 64bit kernels, saving the artifacts for
7 days.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
.github: Skip broken Generic DRM/KMS Unit Tests
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
.github/workflows: Set warnings-as-errors for builds
To avoid code with build warnings being introduced into the tree, force
CONFIG_WERROR=y in the build workflow.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
.github/workflows: Correct kernel builds artifacts
Modify the kernel build workflow to create artifacts with the correct
names and structure, both as an example of what we expect and in case
anyone wants to use the output.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
.github/workflows: Switch to a matrix build
Remove the per-build duplication by putting build parameters in a
matrix.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
.github/workflows: Retain artifacts for 90 days
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Greg Kroah-Hartman [Fri, 16 Feb 2024 18:10:57 +0000 (19:10 +0100)]
Linux 6.6.17
Link: https://lore.kernel.org/r/20240213171852.948844634@linuxfoundation.org
Tested-by: SeongJae Park <sj@kernel.org>
Tested-by: Miguel Ojeda <ojeda@kernel.org>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Tested-by: Allen Pais <apais@linux.microsoft.com>
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
Link: https://lore.kernel.org/r/20240214142247.920076071@linuxfoundation.org
Tested-by: Allen Pais <apais@linux.microsoft.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Tested-by: Ron Economos <re@w6rz.net>
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: kernelci.org bot <bot@kernelci.org>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
Tested-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pablo Neira Ayuso [Wed, 7 Feb 2024 17:49:51 +0000 (18:49 +0100)]
netfilter: nft_set_rbtree: skip end interval element from gc
commit
60c0c230c6f046da536d3df8b39a20b9a9fd6af0 upstream.
rbtree lazy gc on insert might collect an end interval element that has
been just added in this transactions, skip end interval elements that
are not yet active.
Fixes:
f718863aca46 ("netfilter: nft_set_rbtree: fix overlap expiration walk")
Cc: stable@vger.kernel.org
Reported-by: lonial con <kongln9170@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Furong Xu [Sat, 3 Feb 2024 05:31:33 +0000 (13:31 +0800)]
net: stmmac: xgmac: fix a typo of register name in DPP safety handling
commit
1ce2654d87e2fb91fea83b288bd9b2641045e42a upstream.
DDPP is copied from Synopsys Data book:
DDPP: Disable Data path Parity Protection.
When it is 0x0, Data path Parity Protection is enabled.
When it is 0x1, Data path Parity Protection is disabled.
The macro name should be XGMAC_DPP_DISABLE.
Fixes:
46eba193d04f ("net: stmmac: xgmac: fix handling of DPP safety error for DMA channels")
Signed-off-by: Furong Xu <0x1207@gmail.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Link: https://lore.kernel.org/r/20240203053133.1129236-1-0x1207@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Wed, 24 Jan 2024 15:53:07 +0000 (16:53 +0100)]
ALSA: usb-audio: Sort quirk table entries
commit
668abe6dc7b61941fa5c724c06797efb0b87f070 upstream.
The quirk table entries should be put in the USB ID order, but some
entries have been put in random places. Re-sort them.
Fixes:
bf990c102319 ("ALSA: usb-audio: add quirk to fix Hamedal C20 disconnect issue")
Fixes:
fd28941cff1c ("ALSA: usb-audio: Add new quirk FIXED_RATE for JBL Quantum810 Wireless")
Fixes:
dfd5fe19db7d ("ALSA: usb-audio: Add FIXED_RATE quirk for JBL Quantum610 Wireless")
Fixes:
4a63e68a2951 ("ALSA: usb-audio: Fix microphone sound on Nexigo webcam.")
Fixes:
7822baa844a8 ("ALSA: usb-audio: add quirk for RODE NT-USB+")
Fixes:
4fb7c24f69c4 ("ALSA: usb-audio: Add quirk for Fiero SC-01")
Fixes:
2307a0e1ca0b ("ALSA: usb-audio: Add quirk for Fiero SC-01 (fw v1.0.0)")
Link: https://lore.kernel.org/r/20240124155307.16996-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Simon Horman [Thu, 8 Feb 2024 09:48:27 +0000 (09:48 +0000)]
net: stmmac: xgmac: use #define for string constants
commit
1692b9775e745f84b69dc8ad0075b0855a43db4e upstream.
The cited commit introduces and uses the string constants dpp_tx_err and
dpp_rx_err. These are assigned to constant fields of the array
dwxgmac3_error_desc.
It has been reported that on GCC 6 and 7.5.0 this results in warnings
such as:
.../dwxgmac2_core.c:836:20: error: initialiser element is not constant
{ true, "TDPES0", dpp_tx_err },
I have been able to reproduce this using: GCC 7.5.0, 8.4.0, 9.4.0 and 10.5.0.
But not GCC 13.2.0.
So it seems this effects older compilers but not newer ones.
As Jon points out in his report, the minimum compiler supported by
the kernel is GCC 5.1, so it does seem that this ought to be fixed.
It is not clear to me what combination of 'const', if any, would address
this problem. So this patch takes of using #defines for the string
constants
Compile tested only.
Fixes:
46eba193d04f ("net: stmmac: xgmac: fix handling of DPP safety error for DMA channels")
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Closes: https://lore.kernel.org/netdev/
c25eb595-8d91-40ea-9f52-
efa15ebafdbc@nvidia.com/
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/
202402081135.lAxxBXHk-lkp@intel.com/
Signed-off-by: Simon Horman <horms@kernel.org>
Link: https://lore.kernel.org/r/20240208-xgmac-const-v1-1-e69a1eeabfc8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jens Axboe [Mon, 29 Jan 2024 19:00:58 +0000 (12:00 -0700)]
io_uring/net: limit inline multishot retries
Commit
76b367a2d83163cf19173d5cb0b562acbabc8eac upstream.
If we have multiple clients and some/all are flooding the receives to
such an extent that we can retry a LOT handling multishot receives, then
we can be starving some clients and hence serving traffic in an
imbalanced fashion.
Limit multishot retry attempts to some arbitrary value, whose only
purpose serves to ensure that we don't keep serving a single connection
for way too long. We default to 32 retries, which should be more than
enough to provide fairness, yet not so small that we'll spend too much
time requeuing rather than handling traffic.
Cc: stable@vger.kernel.org
Depends-on:
704ea888d646 ("io_uring/poll: add requeue return code from poll multishot handling")
Depends-on:
1e5d765a82f ("io_uring/net: un-indent mshot retry path in io_recv_finish()")
Depends-on:
e84b01a880f6 ("io_uring/poll: move poll execution helpers higher up")
Fixes:
b3fdea6ecb55 ("io_uring: multishot recv")
Fixes:
9bb66906f23e ("io_uring: support multishot in recvmsg")
Link: https://github.com/axboe/liburing/issues/1043
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jens Axboe [Mon, 29 Jan 2024 18:57:11 +0000 (11:57 -0700)]
io_uring/poll: add requeue return code from poll multishot handling
Commit
704ea888d646cb9d715662944cf389c823252ee0 upstream.
Since our poll handling is edge triggered, multishot handlers retry
internally until they know that no more data is available. In
preparation for limiting these retries, add an internal return code,
IOU_REQUEUE, which can be used to inform the poll backend about the
handler wanting to retry, but that this should happen through a normal
task_work requeue rather than keep hammering on the issue side for this
one request.
No functional changes in this patch, nobody is using this return code
just yet.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jens Axboe [Mon, 29 Jan 2024 18:54:18 +0000 (11:54 -0700)]
io_uring/net: un-indent mshot retry path in io_recv_finish()
Commit
91e5d765a82fb2c9d0b7ad930d8953208081ddf1 upstream.
In preparation for putting some retry logic in there, have the done
path just skip straight to the end rather than have too much nesting
in here.
No functional changes in this patch.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jens Axboe [Mon, 29 Jan 2024 18:52:54 +0000 (11:52 -0700)]
io_uring/poll: move poll execution helpers higher up
Commit
e84b01a880f635e3084a361afba41f95ff500d12 upstream.
In preparation for calling __io_poll_execute() higher up, move the
functions to avoid forward declarations.
No functional changes in this patch.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jens Axboe [Thu, 1 Feb 2024 13:42:36 +0000 (06:42 -0700)]
io_uring/net: fix sr->len for IORING_OP_RECV with MSG_WAITALL and buffers
commit
72bd80252feeb3bef8724230ee15d9f7ab541c6e upstream.
If we use IORING_OP_RECV with provided buffers and pass in '0' as the
length of the request, the length is retrieved from the selected buffer.
If MSG_WAITALL is also set and we get a short receive, then we may hit
the retry path which decrements sr->len and increments the buffer for
a retry. However, the length is still zero at this point, which means
that sr->len now becomes huge and import_ubuf() will cap it to
MAX_RW_COUNT and subsequently return -EFAULT for the range as a whole.
Fix this by always assigning sr->len once the buffer has been selected.
Cc: stable@vger.kernel.org
Fixes:
7ba89d2af17a ("io_uring: ensure recv and recvmsg handle MSG_WAITALL correctly")
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aurelien Jarno [Sat, 13 Jan 2024 18:33:31 +0000 (19:33 +0100)]
media: solo6x10: replace max(a, min(b, c)) by clamp(b, a, c)
commit
31e97d7c9ae3de072d7b424b2cf706a03ec10720 upstream.
This patch replaces max(a, min(b, c)) by clamp(b, a, c) in the solo6x10
driver. This improves the readability and more importantly, for the
solo6x10-p2m.c file, this reduces on my system (x86-64, gcc 13):
- the preprocessed size from 121 MiB to 4.5 MiB;
- the build CPU time from 46.8 s to 1.6 s;
- the build memory from 2786 MiB to 98MiB.
In fine, this allows this relatively simple C file to be built on a
32-bit system.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Closes: https://lore.kernel.org/lkml/
18c6df0d-45ed-450c-9eda-
95160a2bbb8e@gmail.com/
Cc: <stable@vger.kernel.org> # v6.7+
Suggested-by: David Laight <David.Laight@ACULAB.COM>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: David Laight <David.Laight@ACULAB.COM>
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: <regressions@leemhuis.info>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Tue, 13 Feb 2024 14:44:48 +0000 (15:44 +0100)]
Revert "ASoC: amd: Add new dmi entries for acp5x platform"
This reverts commit
c87011986fad043ce31a5e749f113540a179a73f which is
commit
c3ab23a10771bbe06300e5374efa809789c65455 upstream.
Link: https://lore.kernel.org/r/CAD_nV8BG0t7US=+C28kQOR==712MPfZ9m-fuKksgoZCgrEByCw@mail.gmail.com
Reported-by: Ted Chang <tedchang2010@gmail.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Fri, 26 Jan 2024 16:07:23 +0000 (17:07 +0100)]
Input: atkbd - skip ATKBD_CMD_SETLEDS when skipping ATKBD_CMD_GETID
commit
683cd8259a9b883a51973511f860976db2550a6e upstream.
After commit
936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in
translated mode") the keyboard on Dell XPS 13 9350 / 9360 / 9370 models
has stopped working after a suspend/resume.
The problem appears to be that atkbd_probe() fails when called
from atkbd_reconnect() on resume, which on systems where
ATKBD_CMD_GETID is skipped can only happen by ATKBD_CMD_SETLEDS
failing. ATKBD_CMD_SETLEDS failing because ATKBD_CMD_GETID was
skipped is weird, but apparently that is what is happening.
Fix this by also skipping ATKBD_CMD_SETLEDS when skipping
ATKBD_CMD_GETID.
Fixes:
936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in translated mode")
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Closes: https://lore.kernel.org/linux-input/
0aa4a61f-c939-46fe-a572-
08022e8931c7@molgen.mpg.de/
Closes: https://bbs.archlinux.org/viewtopic.php?pid=2146300
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218424
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2260517
Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240126160724.13278-2-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Werner Sembach [Tue, 5 Dec 2023 16:36:01 +0000 (17:36 +0100)]
Input: i8042 - fix strange behavior of touchpad on Clevo NS70PU
commit
a60e6c3918d20848906ffcdfcf72ca6a8cfbcf2e upstream.
When closing the laptop lid with an external screen connected, the mouse
pointer has a constant movement to the lower right corner. Opening the
lid again stops this movement, but after that the touchpad does no longer
register clicks.
The touchpad is connected both via i2c-hid and PS/2, the predecessor of
this device (NS70MU) has the same layout in this regard and also strange
behaviour caused by the psmouse and the i2c-hid driver fighting over
touchpad control. This fix is reusing the same workaround by just
disabling the PS/2 aux port, that is only used by the touchpad, to give the
i2c-hid driver the lone control over the touchpad.
v2: Rebased on current master
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20231205163602.16106-1-wse@tuxedocomputers.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Frederic Weisbecker [Mon, 29 Jan 2024 23:56:36 +0000 (15:56 -0800)]
hrtimer: Report offline hrtimer enqueue
commit
dad6a09f3148257ac1773cd90934d721d68ab595 upstream.
The hrtimers migration on CPU-down hotplug process has been moved
earlier, before the CPU actually goes to die. This leaves a small window
of opportunity to queue an hrtimer in a blind spot, leaving it ignored.
For example a practical case has been reported with RCU waking up a
SCHED_FIFO task right before the CPUHP_AP_IDLE_DEAD stage, queuing that
way a sched/rt timer to the local offline CPU.
Make sure such situations never go unnoticed and warn when that happens.
Fixes:
5c0930ccaad5 ("hrtimers: Push pending hrtimers away from outgoing CPU earlier")
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240129235646.3171983-4-boqun.feng@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Heikki Krogerus [Mon, 15 Jan 2024 09:28:20 +0000 (11:28 +0200)]
usb: dwc3: pci: add support for the Intel Arrow Lake-H
commit
de4b5b28c87ccae4da268a53c5df135437f5cfde upstream.
This patch adds the necessary PCI ID for Intel Arrow Lake-H
devices.
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240115092820.1454492-1-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michal Pecio [Thu, 25 Jan 2024 15:27:37 +0000 (17:27 +0200)]
xhci: handle isoc Babble and Buffer Overrun events properly
commit
7c4650ded49e5b88929ecbbb631efb8b0838e811 upstream.
xHCI 4.9 explicitly forbids assuming that the xHC has released its
ownership of a multi-TRB TD when it reports an error on one of the
early TRBs. Yet the driver makes such assumption and releases the TD,
allowing the remaining TRBs to be freed or overwritten by new TDs.
The xHC should also report completion of the final TRB due to its IOC
flag being set by us, regardless of prior errors. This event cannot
be recognized if the TD has already been freed earlier, resulting in
"Transfer event TRB DMA ptr not part of current TD" error message.
Fix this by reusing the logic for processing isoc Transaction Errors.
This also handles hosts which fail to report the final completion.
Fix transfer length reporting on Babble errors. They may be caused by
device malfunction, no guarantee that the buffer has been filled.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20240125152737.2983959-5-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>