| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Basically just extracting some code duplicated in gma500, omapdrm, udl,
and upcoming msm driver.
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Variant of drm_gem_create_mmap_offset() which doesn't make the
assumption that virtual size and physical size (obj->size) are the same.
This is needed in omapdrm to deal with tiled buffers. And lets us get
rid of a duplicated and slightly modified version of
drm_gem_create_mmap_offset() in omapdrm.
Signed-off-by: Rob Clark <[email protected]>
Reviewed-by: David Herrmann <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
And simplify how we hold a ref+pin to what is being scanned out by using
fb refcnt'ing. The previous logic pre-dated fb refcnt, and as a result
was less straightforward than it could have been. By holding a ref to
the fb, we don't have to care about how many plane's there are and
holding a ref to each color plane's bo.
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Rob Clark <[email protected]>
Tested-by: Darren Etheridge <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
A small helper to queue up work to do, from workqueue context, after a
flip. Typically useful to defer unreffing buffers that may be read by
the display controller until vblank.
v1: original
v2: wire up docbook + couple docbook fixes
Signed-off-by: Rob Clark <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
This function is unused.
Signed-off-by: Stéphane Marchesin <[email protected]>
Reviewed-by: David Herrmann <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Again only used by a tests in libdrm and by dristat. Nowadays we have
much better tracing tools to get detailed insights into what a drm
driver is doing. And for a simple "does it work" kind of question that
these stats could answer we have plenty of dmesg debug log spew.
So I don't see any use for this stat gathering complexity at all.
To be able to gradually drop things start with ripping out the
interfaces to it, here the ioctl.
To prevent dristat from eating its own stack garbage we can't use the
drm_noop ioctl though, since we need to clear the return data with a
memset.
Cc: Eric Anholt <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
We not only have debugfs files to do pretty much the equivalent of
lsof, we also have an ioctl. Not that compared to lsof this dumps a
wee bit more information, but we can still get at that from debugfs
easily.
I've dug around in mesa, libdrm and ddx histories and the only users
seem to be drm/tests/dristat.c and drm/tests/getclients.c. The later
is a testcase for the ioctl itself since up to
commit b018fcdaa5e8b4eabb8cffda687d00004a3c4785
Author: Eric Anholt <[email protected]>
Date: Thu Nov 22 18:46:54 2007 +1000
drm: Make DRM_IOCTL_GET_CLIENT return EINVAL when it can't find client #idx
there was actually no way at all for userspace to enumerate all
clients since the kernel just wouldn't tell it when to stop. Which
completely broke it's only user, dristat -c.
So obviously that ioctl wasn't much use for debugging. Hence I don't
see any point in keeping support for a tool which was pretty obviously
never really used, and while we have good replacements in the form of
equivalent debugfs files.
Still, to keep dristat -c from looping forever again stop it early by
returning an unconditional -EINVAL. Also add a comment in the code
about why.
v2: Slightly less hollowed-out implementation. libva uses GET_CLIENTS
to figure out whether the fd it has is already authenticated or not.
So we need to keep that part of things working. Simplest way is to
just return one entry to keep va_drm_is_authenticated in
libva/va/drm/va_drm_auth.c working.
This is exercised by igt/drm_get_client_auth which contains a
copypasta of the libva auth check code.
Cc: Gwenole Beauchesne <[email protected]>
Cc: David Herrmann <[email protected]>
Reviewed-by: David Herrmann <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
They're only used by the agpgart support code in drm_agpgart.c,
not by any drivers.
I think long-term we should create a drm_internal.h include file with
all the various functions only used by the drm core and not exported
to drivers, and remove them from drmP.h. Oh, and someone should kill
that upper-case P sometimes ;-) But that's all stuff for future patch
bombs.
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
The gma500 driver somehow set the DRIVER_IRQ_VBL flag, but since
there's no code at all to check for this we can kill it. The other two
are completely unused.
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
No driver ever sets that flag, so good riddance!
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
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 <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Rob Clark <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: David Herrmann <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
It's kzalloced ...
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
And hide the checks a bit better. This was already disallowed for
modesetting drivers, so no functinal change here.
Reviewed-by: Eric Anholt <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Rob Clark <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Again, it does nothing.
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
KMS drivers really shouldn't need to do anything on firstopen, so kill
empty callbacks.
Signed-off-by: Daniel Vetter <[email protected]>
Acked-by: Rob Clark <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Thomas Hellstrom <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Merge the rcar stable branch that is being shared with the arm-soc tree.
Signed-off-by: Dave Airlie <[email protected]>
* 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
|
|
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 <[email protected]>
Tested-by: Sebastian Hesselbarth <[email protected]>
Tested-by: Russell King <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Sebastian Hesselbarth <[email protected]>
Tested-by: Russell King <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
This fixes the wrong sync generation and sync calculation of TDA998x
for HS/VS-based sync detection.
Signed-off-by: Sebastian Hesselbarth <[email protected]>
Tested-by: Darren Etheridge <[email protected]>
Tested-by: Russell King <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Sebastian Hesselbarth <[email protected]>
Tested-by: Darren Etheridge <[email protected]>
Tested-by: Russell King <[email protected]>
Tested-by: Russell King <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Tested-by: Darren Etheridge <[email protected]>
Tested-by: Sebastian Hesselbarth <[email protected]>
Tested-by: Russell King <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Tested-by: Darren Etheridge <[email protected]>
Tested-by: Sebastian Hesselbarth <[email protected]>
Tested-by: Russell King <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Tested-by: Darren Etheridge <[email protected]>
Tested-by: Sebastian Hesselbarth <[email protected]>
Tested-by: Russell King <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
TDA19988 devices need their RAM enabled in order to read EDID
information. Add support for this.
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
Tested-by: Darren Etheridge <[email protected]>
Tested-by: Sebastian Hesselbarth <[email protected]>
Tested-by: Russell King <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 <[email protected]>
Reported-by: Thiago Macieira <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64725
Signed-off-by: Chris Wilson <[email protected]>
Tested-by: Thiago Macieira <[email protected]>
Cc: [email protected]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
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 <[email protected]>
Cc: [email protected]
Signed-off-by: Alex Deucher <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Cc: [email protected]
|
|
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 <[email protected]>
|
|
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 <[email protected]>
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 <[email protected]>
Cc: Damien Lespiau <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Chris Wilson <[email protected]>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60021
Cc: [email protected]
Tested-by: Dustin King <[email protected]>
Reviewed-by: Jani Nikula <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
When the message buffer is currently moving block until it is idle again.
Signed-off-by: Christian König <[email protected]>
Cc: [email protected]
Signed-off-by: Alex Deucher <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
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 <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
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 <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
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 <[email protected]>
|
|
The R8A7790 includes two internal LVDS encoders. Support them in the DU
driver.
Signed-off-by: Laurent Pinchart <[email protected]>
|