summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2013-08-19drm/vmwgfx: remove redundant clearing of driver->dma_quiescentDaniel Vetter1-1/+0
It's kzalloced ... Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm: mark context support as a legacy subsystemDaniel Vetter3-36/+68
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 <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm: disallow legacy dma ioctls for modesetting driversDaniel Vetter1-0/+15
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: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm: mark dma setup/teardown as legacy systemsDaniel Vetter3-14/+19
And hide the checks a bit better. This was already disallowed for modesetting drivers, so no functinal change here. Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm: disallow legacy sg ioctls for modesetting driversDaniel Vetter1-0/+6
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: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm: hide legacy sg cleanup better from common codeDaniel Vetter2-6/+10
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: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm: kill dev->driver->set_versionDaniel Vetter1-3/+0
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: Eric Anholt <eric@anholt.net> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm/radeon: kill firstopen callback for kms driverDaniel Vetter2-15/+0
Again, it does nothing. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm/omap: kill firstopen callbackDaniel Vetter1-7/+0
KMS drivers really shouldn't need to do anything on firstopen, so kill empty callbacks. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm/ttm: kill unused functionsMaarten Lankhorst1-154/+0
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm/radeon: remove stale gem->driver_private accessDavid Herrmann2-2/+0
This field is never read. No need to set it in radeon. Besides, DRM gem core clears it during setup, anyway. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm/qxl: remove unused object_pin/unpin() helpersDavid Herrmann3-30/+0
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 <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm/cirrus: remove unused driver_private accessDavid Herrmann1-1/+0
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 <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm/mgag200: remove unused driver_private accessDavid Herrmann1-1/+0
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 <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm/ast: remove unused driver_private accessDavid Herrmann1-1/+0
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: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19Merge remote-tracking branch 'pfdo/drm-rcar-for-v3.12' into drm-nextDave Airlie45-1243/+2410
Merge the rcar stable branch that is being shared with the arm-soc tree. Signed-off-by: Dave Airlie <airlied@redhat.com> * pfdo/drm-rcar-for-v3.12: (220 commits) drm/rcar-du: Add FBDEV emulation support drm/rcar-du: Add internal LVDS encoder support drm/rcar-du: Configure RGB output routing to DPAD0 drm/rcar-du: Rework output routing support drm/rcar-du: Add support for DEFR8 register drm/rcar-du: Add support for multiple groups drm/rcar-du: Fix buffer pitch alignment for R8A7790 DU drm/rcar-du: Add support for the R8A7790 DU drm/rcar-du: Move output routing configuration to group drm/rcar-du: Remove register definitions for the second channel drm/rcar-du: Use dynamic number of CRTCs instead of CRTCs array size drm/rcar-du: Introduce CRTCs groups drm/rcar-du: Rename rcar_du_plane_(init|register) to rcar_du_planes_* drm/rcar-du: Create rcar_du_planes structure drm/rcar-du: Rename platform data fields to match what they describe drm/rcar-du: Merge LVDS and VGA encoder code drm/rcar-du: Split VGA encoder and connector drm/rcar-du: Split LVDS encoder and connector drm/rcar-du: Clarify comment regarding plane Y source coordinate drm/rcar-du: Support per-CRTC clock and IRQ ... Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/i915/intel_pm.c drivers/gpu/drm/qxl/qxl_release.c
2013-08-19drm/tilcdc fixup mode to workaround sync for tda998xDarren Etheridge2-2/+32
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: Dave Airlie <airlied@redhat.com>
2013-08-19drm/i2c: tda998x: prepare for broken sync workaroundSebastian Hesselbarth1-0/+8
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: Darren Etheridge <detheridge@ti.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by: Russell King <rmk_kernel@arm.linux.org.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm/i2c: tda998x: fix sync generation and calculationSebastian Hesselbarth1-66/+115
This fixes the wrong sync generation and sync calculation of TDA998x for HS/VS-based sync detection. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Russell King <rmk_kernel@arm.linux.org.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm/i2c: tda998x: add video and audio input configurationRussell King1-8/+260
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: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Russell King <rmk_kernel@arm.linux.org.uk> Tested-by: Russell King <rmk_kernel@arm.linux.org.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-19drm/i2c: tda998x: prepare for video input configurationRussell King1-6/+10
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 <rmk+kernel@arm.linux.org.uk> Tested-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: Dave Airlie <airlied@redhat.com>
2013-08-19drm/i2c: tda998x: fix npix/nline programmingRussell King1-2/+2
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 <rmk+kernel@arm.linux.org.uk> Tested-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: Dave Airlie <airlied@redhat.com>
2013-08-19drm/i2c: tda998x: ensure VIP output mux is properly setRussell King1-0/+4
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 <rmk+kernel@arm.linux.org.uk> Tested-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: Dave Airlie <airlied@redhat.com>
2013-08-19drm/i2c: tda998x: fix EDID reading on TDA19988 devicesRussell King1-1/+13
TDA19988 devices need their RAM enabled in order to read EDID information. Add support for this. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Rob Clark <robdclark@gmail.com> Tested-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: Dave Airlie <airlied@redhat.com>
2013-08-19drm: DRM should depend on HAS_DMAGeert Uytterhoeven1-1/+1
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: Dave Airlie <airlied@redhat.com>
2013-08-18drm/i915: Invalidate TLBs for the rings after a resetChris Wilson2-0/+14
After any "soft gfx reset" we must manually invalidate the TLBs associated with each ring. Empirically, it seems that a suspend/resume or D3-D0 cycle count as a "soft reset". The symptom is that the hardware would fail to note the new address for its status page, and so it would continue to write the shadow registers and breadcrumbs into the old physical address (now used by something completely different, scary). Whereas the driver would read the new status page and never see any progress, it would appear that the GPU hung immediately upon resume. Based on a patch by naresh kumar kachhi <naresh.kumar.kacchi@intel.com> Reported-by: Thiago Macieira <thiago@kde.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64725 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Thiago Macieira <thiago@kde.org> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-15drm/radeon: fix WREG32_OR macro setting bits in a registerRafał Miłecki1-1/+1
This bug (introduced in 3.10) in WREG32_OR made commit d3418eacad403033e95e49dc14afa37c2112c134 "drm/radeon/evergreen: setup HDMI before enabling it" cause a regression. Sometimes audio over HDMI wasn't working, sometimes display was corrupted. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60687 https://bugzilla.kernel.org/show_bug.cgi?id=60709 https://bugs.freedesktop.org/show_bug.cgi?id=67767 Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-15drm/gma500/cdv: Add and hook up chip op for disabling srPatrik Jakobsson6-7/+7
Add a callback hook to the chip ops struct to allow chips to have their specific self-refresh function. Currently only used by cdv. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
2013-08-15drm/radeon/r7xx: fix copy paste typo in golden register setupAlex Deucher1-6/+6
Uses the wrong array size for some asics which can lead to garbage getting written to registers. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60674 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2013-08-14drm/gma500/cdv: Add and hook up chip op for watermarksPatrik Jakobsson6-4/+5
Add a callback hook to the chip ops struct to allow chips to have their specific fifo watermark update function. Currently only cdv actually tries to set wms based on crtc configuration but if/when the other chips needs it we can attach a callback for them as well. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
2013-08-14drm/i915: Don't deref pipe->cpu_transcoder in the hangcheck codeChris Wilson1-29/+57
If we get an error event really early in the driver setup sequence, which gen3 is especially prone to with various display GTT faults we Oops. So try to avoid this. Additionally with Haswell the transcoders are a separate bank of registers from the pipes (4 transcoders, 3 pipes). In event of an error, we want to be sure we have a complete and accurate picture of the machine state, so record all the transcoders in addition to all the active pipes. This regression has been introduced in commit 702e7a56af3780d8b3a717f698209bef44187bb0 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Tue Oct 23 18:29:59 2012 -0200 drm/i915: convert PIPECONF to use transcoder instead of pipe Based on the patch "drm/i915: Dump all transcoder registers on error" from Chris Wilson: v2: Rebase so that we don't try to be clever and try to figure out the cpu transcoder from hw state. That exercise should be done when we analyze the error state offline. The actual bugfix is to not call intel_pipe_to_cpu_transcoder in the error state capture code in case the pipes aren't fully set up yet. v3: Simplifiy the err->num_transcoders computation a bit. While at it make the error capture stuff save on systems without a display block. v4: Fix fail, spotted by Jani. v5: Completely new commit message, cc: stable. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60021 Cc: stable@vger.kernel.org Tested-by: Dustin King <daking@rescomp.stanford.edu> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-12drm/radeon: fix UVD message buffer validationChristian König1-0/+8
When the message buffer is currently moving block until it is idle again. Signed-off-by: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-08-10drm/i915: Allow the GPU to cache stolen memoryChris Wilson1-3/+2
As a corollary to reviewing the interaction between LLC and our cache domains, the GPU PTE bits are independent of the CPU PAT bits. As such we can set the cache level on stolen memory based on how we wish the GPU to cache accesses to it. So we are free to set the same default cache levels as for normal bo, i.e. enable LLC cacheing by default where appropriate. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-10drm/i915: Update rules for writing through the LLC with the cpuChris Wilson4-29/+35
As mentioned in the previous commit, reads and writes from both the CPU and GPU go through the LLC. This gives us coherency between the CPU and GPU irrespective of the attribute settings either device sets. We can use to avoid having to clflush even uncached memory. Except for the scanout. The scanout resides within another functional block that does not use the LLC but reads directly from main memory. So in order to maintain coherency with the scanout, writes to uncached memory must be flushed. In order to optimize writes elsewhere, we start tracking whether an framebuffer is attached to an object. v2: Use pin_display tracking rather than fb_count (to ensure we flush cursors as well etc) and only force the clflush along explicit writes to the scanout paths (i.e. pin_to_display_plane and pwrite into scanout). v3: Force the flush after hitting the slowpath in pwrite, as after dropping the lock the object's cache domain may be invalidated. (Ville) Based on a patch by Ville Syrjälä. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-10drm/i915: Track when an object is pinned for use by the display engineChris Wilson4-6/+42
The display engine has unique coherency rules such that it requires special handling to ensure that all writes to cursors, scanouts and sprites are clflushed. This patch introduces the infrastructure to simply track when an object is being accessed by the display engine. v2: Explain the is_pin_display() magic as the sources for obj->pin_count and their individual rules is not obvious. (Ville) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-10drm/i915: Update rules for reading cache lines through the LLCChris Wilson1-8/+14
The LLC is a fun device. The cache is a distinct functional block within the SA that arbitrates access from both the CPU and GPU cores. As such all writes to memory land first in the LLC before further action is taken. For example, an uncached write from either the CPU or GPU will then proceed to memory and evict the cacheline from the LLC. This means that a read from the LLC always returns the correct information even if the PTE bit in the GPU differs from the PAT bit in the CPU. For the older snooping architecture on non-LLC, the fundamental principle still holds except that some coordination is required between the CPU and GPU to explicitly perform the snooping (which is handled by our request tracking). The upshot of this is that we know that we can issue a read from either LLC devices or snoopable memory and trust the contents of the cache - i.e. we can forgo a clflush before a read in these circumstances. Writing to memory from the CPU is a little more tricky as we have to consider that the scanout does not read from the CPU cache at all, but from main memory. So we have to currently treat all requests to write to uncached memory as having to be flushed to main memory for coherency with all consumers. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-10drm/rcar-du: Add FBDEV emulation supportLaurent Pinchart4-9/+45
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>
2013-08-10drm/rcar-du: Add internal LVDS encoder supportLaurent Pinchart12-3/+374
The R8A7790 includes two internal LVDS encoders. Support them in the DU driver. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-10drm/rcar-du: Configure RGB output routing to DPAD0Laurent Pinchart4-4/+50
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 <laurent.pinchart+renesas@ideasonboard.com>
2013-08-10drm/rcar-du: Rework output routing supportLaurent Pinchart8-20/+92
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 <laurent.pinchart+renesas@ideasonboard.com>
2013-08-10drm/rcar-du: Add support for DEFR8 registerLaurent Pinchart3-1/+5
The R8A7790 DU has a new extended function control register. Support it. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-10drm/rcar-du: Add support for multiple groupsLaurent Pinchart8-30/+63
The R8A7790 DU has 3 CRTCs, split in two groups. Support them. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-10drm/rcar-du: Fix buffer pitch alignment for R8A7790 DULaurent Pinchart3-4/+16
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 <laurent.pinchart+renesas@ideasonboard.com>
2013-08-10drm/rcar-du: Add support for the R8A7790 DULaurent Pinchart2-3/+68
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 <laurent.pinchart+renesas@ideasonboard.com>
2013-08-10drm/rcar-du: Move output routing configuration to groupLaurent Pinchart3-21/+21
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 <laurent.pinchart+renesas@ideasonboard.com>
2013-08-10drm/rcar-du: Remove register definitions for the second channelLaurent Pinchart1-9/+0
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 <laurent.pinchart+renesas@ideasonboard.com>
2013-08-10drm/rcar-du: Use dynamic number of CRTCs instead of CRTCs array sizeLaurent Pinchart2-2/+2
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 <laurent.pinchart+renesas@ideasonboard.com>
2013-08-10drm/rcar-du: Introduce CRTCs groupsLaurent Pinchart10-203/+299
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 <laurent.pinchart+renesas@ideasonboard.com>
2013-08-10drm/rcar-du: Rename rcar_du_plane_(init|register) to rcar_du_planes_*Laurent Pinchart3-6/+7
The functions initialize or register all planes, rename them accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2013-08-10drm/rcar-du: Create rcar_du_planes structureLaurent Pinchart2-12/+16
Move the plane-related fields of struct rcar_du_device to their own structure. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-11-11 17:29:44 +0300