- Sep 13, 2019
-
-
Aman Gupta authored
The ISP and ENCODE roles have the same underlying hardware. Neither requires vertical alignment. Signed-off-by:
Aman Gupta <aman@tmm1.net>
-
Aman Gupta authored
fixes #3171 Signed-off-by:
Aman Gupta <aman@tmm1.net>
-
popcornmix authored
-
popcornmix authored
This code path hasn't been used previously. Fixed up after testing with kodi on 32-bit userland and 64-bit kernel Signed-off-by:
popcornmix <popcornmix@gmail.com>
-
Phil Elwell authored
The xtal parameter is targetting the wrong node - fix it. See: https://github.com/raspberrypi/linux/issues/3156 Signed-off-by:
Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
Enable the V3D driver, which depends on BCM2835_POWER. Originally submitted by GitHub user 'phire' in a slightly different form. See: https://github.com/raspberrypi/linux/pull/3063 Signed-off-by:
Phil Elwell <phil@raspberrypi.org>
-
P33M authored
The hardware will do a 4-byte write to memory on any IN packet received that is between 1 and 3 bytes long. This tramples memory in the uvcvideo driver, as it uses a sequence of 1- and 2-byte control transfers to query the min/max/range/step of each individual camera control and gives us buffers that are offsets into a struct. Catch small control transfers in the data phase and use the align_buf to bounce the correct number of bytes into the URB's buffer. In general, short packets on non-control endpoints should be OK as URBs should have enough buffer space for a wMaxPacket size transfer. See: https://github.com/raspberrypi/linux/issues/3148 Signed-off-by:
Jonathan Bell <jonathan@raspberrypi.org>
-
Jonathan Bell authored
Users have reported log spam created by "Event Ring Full" xHC event TRBs. These are caused by interrupt latency in conjunction with a very busy set of devices on the bus. The errors are benign, but throughput will suffer as the xHC will pause processing of transfers until the event ring is drained by the kernel. Expand the number of event TRB slots available by increasing the number of event ring segments in the ERST. Controllers have a hardware-defined limit as to the number of ERST entries they can process, so make the actual number in use min(ERST_MAX_SEGS, hw_max). Signed-off-by:
Jonathan Bell <jonathan@raspberrypi.org>
-
Phil Elwell authored
The I2C interface nodes need aliases to give them fixed bus numbers, and setting the pulls on the GPIOs (particularly 9-13) increases the chances of the bus working with weak or absent external pulls. See: https://www.raspberrypi.org/forums/posting.php?mode=reply&f=107&t=248439 Signed-off-by:
Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
See: https://github.com/raspberrypi/linux/issues/3141 Signed-off-by:
Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
Update bcm2709_defconfig to match the output from savedefconfig. Signed-off-by:
Phil Elwell <phil@raspberrypi.org>
-
Boris Brezillon authored
X/Y positioning of T-format buffers is quite tricky and the current implementation was failing to position a plane using this format correctly when the CRTC X, Y or both X and Y offsets were negative. It was also failing when the SRC X/Y offsets were != 0. Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20180803092231.26446-5-boris.brezillon@bootlin.com
-
Boris Brezillon authored
The offset adjustment depends on the framebuffer modified, so let's just move this operation in the DRM_FORMAT_MOD_LINEAR case inside vc4_plane_mode_set(). This we'll be able to fix offset calculation for DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED and DRM_FORMAT_MOD_BROADCOM_SANDXXX. Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20180803092231.26446-4-boris.brezillon@bootlin.com
-
Boris Brezillon authored
drm_atomic_helper_check_plane_state() takes care of checking the scaling capabilities and calculating the clipped X/Y offsets for us. Rely on this function instead of open-coding the logic. Incidentally, it seems to fix a problem we had with negative X/Y positioning of YUV planes. Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20180803092231.26446-3-boris.brezillon@bootlin.com
-
Eric Anholt authored
This is needed to support X/Y negative placement of planes using T-format buffers. Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180803092231.26446-2-boris.brezillon@bootlin.com
-
Eric Anholt authored
Y_OFFSET field starts at bit 8 not 7. Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180803092231.26446-1-boris.brezillon@bootlin.com
-
Phil Elwell authored
Some combinations of Pi 4Bs and Ethernet switches don't reliably get a DCHP-assigned IP address, leaving the unit with a self=assigned 169.254 address. In the failure case, the Pi is left able to receive packets but not send them, suggesting that the MAC<->PHY link is getting into a bad state. It has been found empirically that skipping a reset step by the genet driver prevents the failures. No downsides have been discovered yet, and unlike the forced renegotiation it doesn't increase the time to get an IP address, so the workaround is enabled by default; add genet.skip_umac_reset=n to the command line to disable it. See: https://github.com/raspberrypi/linux/issues/3108 Signed-off-by:
Phil Elwell <phil@raspberrypi.org>
-
Dave Stevenson authored
vc4_crtc_consume_event wasn't checking crtc->state->event was set before dereferencing it, leading to an OOPS. Fixes "a5b534bb drm/vc4: Resolve the vblank warnings on mode switching" Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Dave Stevenson authored
The handling of format changed events incorrectly set bytesperline to the cropped width, which ignored padding and formats with more than 8bpp. Fix these. Reported by: zillevdr <zillevdr@gmx.de> Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Dave Stevenson authored
Adds some more useful logging during format changed events and s_fmt. Reported by: zillevdr <zillevdr@gmx.de> Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Dave Stevenson authored
"89d13761 drm/vc4: Add support for margins to fkms" removed the requirement for having the mode structure from vc4_plane_to_mb, but didn't remove it as a local to the function, causing a compiler warning. Remove the unused variable. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Dave Stevenson authored
The details over when and how a driver is to service the vblank events are sketchy, and the fkms driver was triggering a kernel warning every time the crtc was enabled or disabled. Copy the event handling as used by the vc4-kms driver slightly more closely, and we avoid the warnings. https://github.com/raspberrypi/linux/issues/3020 Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Phil Elwell authored
The overlays for enabling the new BCM2711 I2C interfaces were lacking the means to configure the baud/clock rate. Also explictly set the default pins, rather than relying on the values in the base DTB. Signed-off-by:
Phil Elwell <phil@raspberrypi.org>
-
James Hughes authored
For generic ALSA, all you need is the bcm2835.h change, but have also added structures for IEC958 HDMI. Not sure how to test those.
-
Chen-Yu Tsai authored
Instead of filling in the struct v4l2_capability device_caps field, fill in the struct video_device device_caps field. That way the V4L2 core knows what the capabilities of the video device are. This is similar to a cleanup series by Hans Verkuil [1]. [1] https://www.spinics.net/lists/linux-media/msg153313.html Signed-off-by:
Chen-Yu Tsai <wens@csie.org>
-
Chen-Yu Tsai authored
The stateful decoder specification shows an optional step for retrieving the miminum number of capture buffers required for the decoder to proceed. While not a required parameter, having it makes some applications happy. bcm2835-codec is a little different from other decoder implementations in that there is an intermediate format conversion between the hardware and V4L2 buffers. The number of capture buffers required is therefore independent of the stream and DPB etc. There are plans to remove the conversion, but it requires a fair amount of rework within the firmware. Until that is done, simply return a value of 1. Signed-off-by:
Chen-Yu Tsai <wens@csie.org>
-
Chen-Yu Tsai authored
There are two APIs for mem2mem devices, the older single-planar API and the newer multi-planar one. Without making things overly complex, the driver can only support one or the other. However the userspace libv4l2 library has a plugin that allows multi-planar API devices to service single-planar consumers. Chromium supports the multi-planar API exclusively, though this is currently limited to ChromiumOS. It would be possible to add support for generic Linux. Switching to the multi-planar API would allow usage of both APIs from userspace. Signed-off-by:
Chen-Yu Tsai <wens@csie.org>
-
Dave Stevenson authored
To allow for console rotation under DRM (where the firmware can't lie about geometry), add FRAMEBUFFER_CONSOLE_ROTATION so that the kernel can do it. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Dave Stevenson authored
Taken from the dri-devel mailing list (11/7/2019) to fixup the cmdline parsing, but requires changes as things have moved between 4.19 and 5.2. From: Dmitry Osipenko <digetx@gmail.com> The rotation mode from cmdline shouldn't be taken into account if it wasn't specified in the cmdline. This fixes ignored default display orientation when display mode is given using cmdline without the rotation being specified. Fixes: 1bf4e092 ("drm/modes: Allow to specify rotation and reflection on the commandline") Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Dave Stevenson authored
Now that the TV margins are properly parsed and filled into drm_cmdline_mode, we just need to initialise the first state at reset to get those values and start using them. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Maxime Ripard authored
Now that the TV margins are properly parsed and filled into drm_cmdline_mode, we just need to initialise the first state at reset to get those values and start using them. Acked-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/44e24172e300be6a41578517021ef6a6e90ed682.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
Commit 731514b4 upstream. Reworked as functions have been moved from drm_atomic_helper.[c|h] to drm_atomic_state_helper.[c|h]. During the connector reset, if that connector has a TV property, it needs to be reset to the value provided on the command line. Provide a helper to do that. Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/84a7b657f09303a2850e1cc79e68f623547f3fdd.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
Commit 3d46a300 upstream. Properly configuring the overscan properties might be needed for the initial setup of the framebuffer for display that still have overscan. Let's allow for more properties on the kernel command line to setup each margin. Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/e481f1628e3768ca49226ec2115cfa4dfcbd5e4c.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
Commit 22045e8e upstream. The TV margins has been defined as a structure inside the drm_connector_state structure so far. However, we will need it in other structures as well, so let's move that structure definition so that it can be reused. Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/38b773b03f15ec7a135cdf8f7db669e5ada20cf2.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
Commit 1bf4e092 upstream. Minor conflict resolution as upstream has moved functions from drm_fb_helper.c to a new drm_client_modeset.c Rotations and reflections setup are needed in some scenarios to initialise properly the initial framebuffer. Some drivers already had a bunch of quirks to deal with this, such as either a private kernel command line parameter (omapdss) or on the device tree (various panels). In order to accomodate this, let's create a video mode parameter to deal with the rotation and reflexion. Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/777da16e42db757c1f5b414b5ca34507097fed5c.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
commit 3aeeb13d upstream. Minor conflict resolution as upstream has moved functions from drm_fb_helper.c to a new drm_client_modeset.c The drm subsystem also uses the video= kernel parameter, and in the documentation refers to the fbdev documentation for that parameter. However, that documentation also says that instead of giving the mode using its resolution we can also give a name. However, DRM doesn't handle that case at the moment. Even though in most case it shouldn't make any difference, it might be useful for analog modes, where different standards might have the same resolution, but still have a few different parameters that are not encoded in the modes (NTSC vs NTSC-J vs PAL-M for example). Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/18443e0c3bdbbd16cea4ec63bc7f2079b820b43b.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
commit e08ab74b upstream. Rewrite the command line parser in order to get away from the state machine parsing the video mode lines. Hopefully, this will allow to extend it more easily to support named modes and / or properties set directly on the command line. Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/e32cd4009153b184103554009135c7bf7c9975d7.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
commit 772cd52c upstream. The struct drm_cmdline_mode holds the result of the command line parsers. However, it wasn't documented so far, so let's do that. Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/963c893c16c6a25fc469b53c726f493d99bdc578.1560783090.git-series.maxime.ripard@bootlin.com
-
Dave Stevenson authored
Some HDMI monitors do not abide by the full or limited (16-235) range RGB flags in the AVI infoframe. This can result in images looking washed out (if given limited and interpreting as full), or detail disappearing at the extremes (given full and interpreting as limited). Copy the Intel i915 driver's approach of adding an override property ("Broadcast RGB") to force one mode or the other. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Jonathan Bell authored
These wireless mouse/keyboard combo remote control devices specify multiple "wheel" events in their report descriptors. The wheel events are incorrectly defined and apparently map to accelerometer data, leading to spurious mouse scroll events being generated at an extreme rate when the device is moved. As a workaround, use HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE to mask feeding the extra wheel events to the input subsystem. See: https://github.com/raspberrypi/firmware/issues/1189 Signed-off-by:
Jonathan Bell <jonathan@raspberrypi.org>
-