Add a new custom control V4L2_CID_USER_GET_IMX500_DEVICE_ID to allow
userland to query the device id from the IMX500 sensor eeprom.
Note that this device id can only be accessed when a network firmware
has been upoloaded to the device, so cannot be cached on probe.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
dwc2_hc_start_transfer() overwrites hc->xfer_len for split-IN transfers.
Drivers may not allocate buffers that are multiples of the endpoint max
packet size, which may cause buffer overruns in the last transfer.
The hardware needs HCTSIZ to be set to a multiple of HCCHAR.MPS, so trim
chan->max_packet in dwc2_assign_and_init_hc().
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
The HFNUM register increments on every microframe in HS mode, and USB
device drivers expect the returned frame count to relate to the overall
frame. Right-shift the returned value by 3 to drop the microframe bits.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
Masquerading Interrupt split transfers as Control puts the transfer into
the non-periodic handler in the hub. This stops the hub dropping
complete-split data in the microframe after a CSPLIT should have
arrived, improving resilience to host IRQ latency. Devices are none the
wiser - the handshake tokens are the same.
Originally devised by Hans Petter Selasky @ FreeBSD.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
As a result of a hardware bug, small IN packets with length < 4 cause a
4-byte write to memory. Generally, buffers allocated with kmalloc
reserve at least one cacheline of memory, but the UVC driver passes
offsets into a struct as the buffer. This causes trampling of video
control min/max/default/range data.
e.g. on a generic UVC camera, these default values are nonsense:
$ v4l2-ctl -d0 --all
[...]
brightness 0x00980900 (int) : min=0 max=255 step=1 default=-8193 value=128
contrast 0x00980901 (int) : min=0 max=100 step=1 default=57343 value=67
saturation 0x00980902 (int) : min=0 max=100 step=1 default=57343 value=62
hue 0x00980903 (int) : min=-90 max=90 step=2 default=12287 value=0
gamma 0x00980910 (int) : min=1 max=30 step=1 default=57343 value=29
[...]
Update the pre-existing DMA alignment code to catch this case.
Link: https://github.com/raspberrypi/linux/issues/3148
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
The overlay deprecation feature does not give any advance warnings,
just a more user-friendly error message; it's more termination than
deprecation.
Abuse the overlay rename feature to cause a warning message to be
displayed when dwc-otg is loaded:
dtwarn: overlay 'dwc-otg' has been renamed 'dwc-otg-deprecated'
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
It has been decided that we should drop DWC_OTG support on the 64-bit
kernels. Its raison-d'etre on ARCH=arm is the FIQ FSM, which
significantly reduces the overheads of running the hardware in host
mode. Unfortunately, upstream Linux uses the DWC2 driver, which has had
a lot of attention over the years. In particular, there are a number of
situations where DWC_OTG fails where DWC2 works, despite the reduced
throughput.
In the ARMv8 kernel, FIQ support was missing, and is now just different
in an awkward way. It is possible to use DWC_OTG in the v8 kernel, but
only when the FIQ support is disabled, removing its advantage.
It therefore makes sense to transition to using the DWC2 driver in the
64-bit kernels, deprecating DWC_OTG. The first cautious step is to make
the DWC2 driver a built-in, so that either driver can be used for
booting. Unfortunately this increases the size of the kernel by ~200kB,
but the intention is later to demote DWC_OTG to a module or drop it
altogether.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The local spinlock protects the handlers from racing against each other
on separate cores, hard IRQs don't preempt each other, and
disabling/enabling the interrupt is more expensive than letting the fake
FIQ contend the spinlock.
So turn local_fiq_en/disable into no-ops.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
BCM2836 with Cortex-A7 cores has almost the same ARM_LOCAL interrupt
routing logic as BCM2837, so relax the compile guard to CONFIG_SMP not
CONFIG_ARM64.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
Interrupts are dispatched round-robin but doing so trampled FIQ routing.
Taking a FIQ on a core without a handler installed is fatal.
Only modify bits 1:0 which are the IRQ route bits.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
Even though it's documented that specifying slots=0 can be used to disable
the TDM mode, error checking introduced in 6.12.31 version broke this,
therefore, for the time being, a workaround is to provide a xlate_tdm_slot_mask
operation implementation to return 0 instead of -EINVAL as it does in case
slots argument is 0.
Signed-off-by: Giedrius Trainavičius <giedrius@blokas.io>
Add support for the Sony IMX283 image sensor by including the module
for supported Raspberry Pi platforms.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
This supports the OneInchEye with a 24MHz crystal INCK.
Use the option 'cam0' to connect this to the CAM/DISP 0 port on
Raspberry Pi 5.
Use the clock-frequency=<value> option if you have a camera module with
a different inclk frequency:
For example:
dtoverlay=imx283,cam0,clock-frequency=12000000
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
On IMX477 it appears that the on-chip temperature sensor causes
XVS (external sync out) to pulse every ~2ms when not streaming.
So now we do a little dance: Temperature sensor is enabled during
common register setup, giving it time to warm up (almost literally;
otherwise the first frame's reading might be 0C), disabled before
enabling sync out, then enabled again once the camera is streaming.
We already took care to disable XVS output in stop_streaming()
(though previously it wasn't understood why this was needed).
Signed-off-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
To avoid lost frame start in a subsequent session, avoid setting
the number of lanes back to 1 or putting CSI-2 Host into reset.
It's not clear if this is a watertight fix -- what if the camera
itself produced a truncated or garbled packet, or continued to
send until the next start? -- but it does seem to fix the issue.
Signed-off-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
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>
The register needs to be disabled before loading any firmware, otherwise
the upload fails for unknown reasons. Re-enable before starting the
sensor streaming.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Due to possible instabilities, reduce the mmap read lock time to only
cover the call to find_vdma().
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Currently four nearly identical overlays (sc16is750-spi0 / -spi1
and sc16is752-spi0 / -spi1) are provided. Besides the redundant
configuration all of them lack support for other SPI interfaces
than spi0 and spi1.
Thus refactor the common definitions into a generic sc16is75x-spi
overlay which provides support for all known spi / cs combinations.
Also choose the chip type via dtparam rather than different overlay.
Remove the existing overlays, replacing them with rename rules in the
overlay map.
Signed-off-by: Nicolai Buchwitz <n.buchwitz@kunbus.com>
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Now that the current trees are passing the thorough/try-all mode of
overlaycheck (mainly by excluding trying to apply the vl805 overlay
on a CM4S), use it in the build checks.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The 6.9 kernel introduced a large patchset [1] designed to make gpiochip
usage safe in the presence of potential hotplugging events. The changes
included protecting every gpiochip access with a claim of an interlock.
Running on a Pi 5 these changes reduce GPIO performance from userspace
by around 10%. The penalty would be proportionally higher from kernel,
as seen by SPI speed reductions.
Patch the gpiolib implementation to remove the protection of gpiochip
accesses. By providing alternative implementations of the relevant
macros, the changes are localised and therefore easier to verify.
See: https://github.com/raspberrypi/linux/issues/6854
[1] https://lwn.net/Articles/960024/
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Ensure spidev0 is disabled before the cs pin is referenced.
Otherwise the overlay will fail when loaded during runtime with
"spi spi0.0: chipselect 0 already in use"
Signed-off-by: Nicolai Buchwitz <n.buchwitz@kunbus.com>
The Renesas uPD controller is a bit more picky about validating Configure
Endpoint TRBs and requires that bit 0 of the ADD field is 1.
This is mentioned in xhci v1.2 s4.6.6.
Also drop a redundant helper function and reject invalid endpoints.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
Move RP1 DPI's PIO-assisted Composite Sync generation code,
previously released as a separate utility, into the kernel driver.
There are 3 variants for progressive, generic interlaced and TV-
style interlaced CSync, alongside the existing VSync fixup.
Check that all of GPIOs 1-3 are mapped to DPI, so PIO won't try
to snoop on a missing output, or override another device's pins.
Add "force_csync" module parameter, for convenience of testing,
as few tools can set DRM_MODE_FLAG_CSYNC.
Signed-off-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Move RP1 DPI's PIO-assisted Composite Sync generation code,
previously released as a separate utility, into the kernel driver.
There are 3 variants for progressive, generic interlaced and TV-
style interlaced CSync, alongside the existing VSync fixup.
Check that all of GPIOs 1-3 are mapped to DPI, so PIO won't try
to snoop on a missing output, or override another device's pins.
Add "force_csync" module parameter, for convenience of testing,
as few tools can set DRM_MODE_FLAG_CSYNC.
Signed-off-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Call drm_client_setup() to run the kernel's default client setup
for DRM. Set fbdev_probe in struct drm_driver, so that the client
setup can start the common fbdev client.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Call drm_client_setup() to run the kernel's default client setup
for DRM. Set fbdev_probe in struct drm_driver, so that the client
setup can start the common fbdev client.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Call drm_client_setup() to run the kernel's default client setup
for DRM. Set fbdev_probe in struct drm_driver, so that the client
setup can start the common fbdev client.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
It seems that some applications don't work with UART DMA enabled, while
others don't work without it. No DMA seems to be the safer default
choice, but add a dtparam - uart0_dma - to re-enable it.
See: https://github.com/raspberrypi/linux/issues/6365
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
bcm2835_dma_suspend_late is only used if CONFIG_PM_SLEEP is defined,
so make it's presence similarly conditional to avoid a build warning
(and hence error).
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
