- 19 Aug, 2013 9 commits
-
-
Daniel Vetter authored
So I've stumbled over drm_fasync and wondered what it does. Digging that up is quite a story. First I've had to read up on what this does and ended up being rather bewildered why peopled loved signals so much back in the days that they've created SIGIO just for that ... Then I wondered how this ever works, and what that strange "No-op." comment right above it should mean. After all calling the core fasync helper is pretty obviously not a noop. After reading through the kernels FASYNC implementation I've noticed that signals are only sent out to the processes attached with FASYNC by calling kill_fasync. No merged drm driver has ever done that. After more digging I've found out that the only driver that ever used this is the so called GAMMA driver. I've frankly never heard of such a gpu brand ever before. Now FASYNC seems to not have been the only bad thing with that driver, since Dave Airlie removed it from the drm driver with prejudice: commit 1430163b4bbf7b00367ea1066c1c5fe85dbeefed Author: Dave Airlie <airlied@linux.ie> Date: Sun Aug 29 12:04:35 2004 +0000 Drop GAMMA DRM from a great height ... Long story short, the drm fasync support seems to be doing absolutely nothing. And the only user of it was never merged into the upstream kernel. And we don't need any fops->fasync callback since the fcntl implementation in the kernel already implements the noop case correctly. So stop this particular cargo-cult and rip it all out. v2: Kill drm_fasync assignments in rcar (newly added) and imx drivers (somehow I've missed that one in staging). Also drop the reference in the drm DocBook. ARM compile-fail reported by Rob Clark. v3: Move the removal of dev->buf_asnyc assignment in drm_setup to this patch here. v4: Actually git add ... tsk. Cc: Dave Airlie <airlied@linux.ie> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Rob Clark <robdclark@gmail.com> Acked-by:Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Daniel Vetter authored
It's kzalloced ... Signed-off-by:
-
Daniel Vetter authored
So after a lot of digging around in git histories it looks like this has only ever be used by dri1 render clients. Hence we can fully disable the entire thing for modesetting drivers and so greatly reduce the attack surface for potential exploits (or at least tools like trinity ...). Also add the drm_legacy prefix for functions which are called from common code. To further reduce the impact on common code also extract all the ctx release handling into a function (instead of only releasing individual handles) and make ctxbitmap_cleanup return void - it can never fail. Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Daniel Vetter authored
Now only legacy ums drivers have the DRIVER_HAVE_DMA driver feature flag set, so strictly speaking the modesetting check is redundant. But adding it has the upside that it makes it very clear that the dma support is legacy stuff. Reviewed-by:
-
Daniel Vetter authored
And hide the checks a bit better. This was already disallowed for modesetting drivers, so no functinal change here. Reviewed-by:
-
Daniel Vetter authored
Only the radeon/r128/ati ums drivers use this. Furthermore the cleanup was already only done for UMS drivers. Also a quick check of the ATI ddx git history shows that only the UMS code ever used this facility. So we can safely disallow these pair of ioctls for modesetting drivers. Reviewed-by:
-
Daniel Vetter authored
I've decided that some clear markers for what's legacy dri1/non-gem code is useful. I've opted to use the drm_legacy prefix and then hide all the checks in that function for better readability in the common code. Reviewed-by:
-
Daniel Vetter authored
Totally unused, so just rip it out. Anyway, we want drivers to be fully backwards compatible, allowing them to change behaviour is just a recipe for them to break badly. Reviewed-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Daniel Vetter authored
Again, it does nothing. Signed-off-by:
-
- 18 Aug, 2013 17 commits
-
-
Daniel Vetter authored
KMS drivers really shouldn't need to do anything on firstopen, so kill empty callbacks. Signed-off-by:
-
Maarten Lankhorst authored
Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@canonical.com> Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
-
David Herrmann authored
This field is never read. No need to set it in radeon. Besides, DRM gem core clears it during setup, anyway. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
David Herrmann authored
These two helpers are unused. Remove them. They rely on gem_obj->driver_private, which is set to NULL during setup. As this field isn't used by the driver, anymore, we can remove this assignment as well. Signed-off-by:
-
David Herrmann authored
gem_bo->driver_private is never read by cirrus nor DRM core. No need to set it. Besides, drm core clears it during setup, anyway. Signed-off-by:
-
David Herrmann authored
gem_bo->driver_private is never read by mgag200 nor DRM core. No need to set it. Besides, drm core clears it during setup, anyway. Signed-off-by:
-
David Herrmann authored
gem_bo->driver_private is never read by ast nor DRM core. No need to set it. Besides, drm core clears it during setup, anyway. Signed-off-by:
-
Dave Airlie authored
Merge the rcar stable branch that is being shared with the arm-soc tree. Signed-off-by: -
Darren Etheridge authored
Add a fixup function that will flip the hsync priority and add a hskew value that is used to shift the tda998x to the right by a variable number of pixels depending on the mode. This works around an issue with the sync timings that tilcdc is outputing. Signed-off-by:
Darren Etheridge <detheridge@ti.com> Tested-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by:
Russell King <rmk_kernel@arm.linux.org.uk> Signed-off-by:
-
Sebastian Hesselbarth authored
Some LCD controller cannot provide valid VESA style sync, i.e. coincident HS/VS edges. First, this patch adds hskew passed from the adjusted_mode to reference pixel calculation to allow those controllers to add an offset relative to the expected reference pixel. Signed-off-by:
-
Sebastian Hesselbarth authored
This fixes the wrong sync generation and sync calculation of TDA998x for HS/VS-based sync detection. Signed-off-by:
-
Russell King authored
This patch adds tda998x specific parameters to allow it to be configured for different boards using it. Also, this implements rudimentary audio support for S/PDIF attached controllers. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Russell King authored
The video-input-port (VIP) is highly configurable. This prepares current driver to allow to configure VIP configuration, as some boards connect lcd controller and TDA998x "pin-swapped" and depend on VIP to swap the pins by register configuration. Signed-off-by:
-
Russell King authored
The npix/nline registers are supposed to be programmed with the total number of pixels/lines, not the displayed pixels/lines, and not minus one either. Signed-off-by:
-
Russell King authored
When switching between various drivers for this device, it's possible that some critical registers are left containing values which affect the device operation. One such case encountered is the VIP output mux register. This defaults to 0x24 on powerup, but other drivers may set this to 0x12. This results in incorrect colours. Fix this by ensuring that the register is always set to the power on default setting. Signed-off-by:
-
Russell King authored
TDA19988 devices need their RAM enabled in order to read EDID information. Add support for this. Signed-off-by:
-
Geert Uytterhoeven authored
If NO_DMA=y: drivers/built-in.o: In function `__drm_pci_free': drivers/gpu/drm/drm_pci.c:112: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `drm_pci_alloc': drivers/gpu/drm/drm_pci.c:72: undefined reference to `dma_alloc_coherent' drivers/built-in.o: In function `drm_gem_unmap_dma_buf': drivers/gpu/drm/drm_prime.c:87: undefined reference to `dma_unmap_sg' drivers/built-in.o: In function `drm_gem_map_dma_buf': drivers/gpu/drm/drm_prime.c:78: undefined reference to `dma_map_sg' Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
- 09 Aug, 2013 14 commits
-
-
git://linuxtv.org/pinchartl/fbdevDave Airlie authored
Create topic branch for rcar for shmobile tree to pull as well, arm-soc should probably merge after drm merges if possible. Signed-off-by:
-
Laurent Pinchart authored
Use the FB CMA helpers to implement FBDEV emulation support. The VGA connector status must be reported as connector_status_connected instead of connector_status_unknown to be usable by the emulation layer. Signed-off-by:Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
The R8A7790 includes two internal LVDS encoders. Support them in the DU driver. Signed-off-by: -
Laurent Pinchart authored
The R8A7790 DU variant has a single RGB output called DPAD0 that can be fed with the output of DU0, DU1 or DU2. Making the routing configurable. Signed-off-by: -
Laurent Pinchart authored
Split the output routing specification between SoC-internal data, specified in the rcar_du_device_info structure, and board data, passed through platform data. The DU has 5 possible outputs (DPAD0/1, LVDS0/1, TCON). SoC-internal output routing data specify which output are valid, which CRTCs can be connected to the valid outputs, and the type of in-SoC encoder for the output. Platform data then specifies external encoders and the output they are connected to. Signed-off-by: -
Laurent Pinchart authored
The R8A7790 DU has a new extended function control register. Support it. Signed-off-by: -
Laurent Pinchart authored
The R8A7790 DU has 3 CRTCs, split in two groups. Support them. Signed-off-by: -
Laurent Pinchart authored
The R8A7790 DU seems to require a 128 bytes pitch alignment, even though the documentation only mentions a 16 pixels alignement as for the R8A7779 DU. Make this configurable through a device flag. Signed-off-by: -
Laurent Pinchart authored
The DU revision in the R8A7790 SoC uses one IRQ and clock per CRTC. Add a corresponding entry in the module platform ID table. Signed-off-by: -
Laurent Pinchart authored
Output routing is configured in group registers, move the corresponding code from rcar_du_crtc.c to rcar_du_group.c. Signed-off-by: -
Laurent Pinchart authored
Channels are accessed through a global channel memory offset, there's no need to define register addresses for the second channel. Signed-off-by: -
Laurent Pinchart authored
The rcar_du_device structure contains a field that stores the number of CRTCs, use it instead of the CRTCs array size. This prepares the driver to support a variable number of CRTCs. Signed-off-by: -
Laurent Pinchart authored
The R8A7779 DU is split in per-CRTC resources (scan-out engine, blending unit, timings generator, ...) and device-global resources (start/stop control, planes, ...) shared between the two CRTCs. The R8A7790 introduced a third CRTC with its own set of global resources This would be modeled as two separate DU device instances if it wasn't for a handful or resources that are shared between the three CRTCs (mostly related to input and output routing). For this reason the R8A7790 DU must be modeled as a single device with three CRTCs, two sets of "semi-global" resources, and a few device-global resources. Introduce a new rcar_du_group driver-specific object, without any real counterpart in the DU documentation, that models those semi-global resources. Signed-off-by: -
Laurent Pinchart authored
The functions initialize or register all planes, rename them accordingly. Signed-off-by:
-
