| Age | Commit message (Collapse) | Author |
|---|
|
In
commit cdd1cf799bd24ac0a4184549601ae302267301c5
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Dec 4 21:03:25 2014 +0000
drm: Make drm_read() more robust against multithreaded races
I fixed the races by serialising the use of the event by extending the
dev->event_lock. However, as Thomas pointed out, the copy_to_user() may
fault (even the __copy_to_user_inatomic() variant used here) and calling
into the driver backend with the spinlock held is bad news. Therefore we
have to drop the spinlock before the copy, but that exposes us to the
old race whereby a second reader could see an out-of-order event (as the
first reader may claim the first request but fail to copy it back to
userspace and so on returning it to the event list it will be behind the
current event being copied by the second reader).
Reported-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448462343-2072-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Commit "30c964a drm/i915: Detect virtual south bridge" detects and
handles the southbridge emulated by vmware esx. Add the ich9 south
bridge emulated by 'qemu -M q35'.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
"Could not force DPM to low", etc. is usually harmless and
just confuses users.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
Currently a DDI port may register the DP hotplug handler even though
it's used with HDMI, and the DP HPD handler overrides the encoder
type forcibly to DP. This caused the inconsistency on a machine
connected with a HDMI monitor; upon a hotplug event, the DDI port is
suddenly switched to be handled as a DP although the same monitor is
kept connected, and this leads to the erroneous blank output.
This patch papers over the bug by excluding the previous HDMI encoder
type from this override. This should be fixed more fundamentally,
e.g. by moving the encoder type reset from the HPD or by having
individual encoder objects for HDMI and DP. But since the bug has
been present for a long time (3.17), it's better to have a
quick-n-dirty fix for now, and keep working on a cleaner fix.
Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=955190
Fixes: 0e32b39ceed6 ('drm/i915: add DP 1.2 MST support (v0.7)')
Cc: <stable@vger.kernel.org> # v3.17+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1447931396-19147-1-git-send-email-tiwai@suse.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The commit [cfb23ed622d0: drm/i915: Allow fuzzy matching in
pipe_config_compare, v2] relaxed the way to compare the pipe
configurations, but one new comparison sneaked in there: it added the
strict has_drrs value check. This causes a regression on many
machines, typically HP laptops with a docking port, where the kernel
spews warnings and eventually fails to set the mode properly like:
[drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in has_drrs (expected 1, found 0)
------------[ cut here ]------------
WARNING: CPU: 0 PID: 79 at drivers/gpu/drm/i915/intel_display.c:12700 intel_modeset_check_state+0x5aa/0x870 [i915]()
pipe state doesn't match!
....
This patch just removes the check again for fixing the regression.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104041
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92456
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=956397
Fixes: cfb23ed622d0 ('drm/i915: Allow fuzzy matching in pipe_config_compare, v2')
Cc: <stable@vger.kernel.org> # v4.3+
Reported-and-tested-by: Max Lin <mlin@suse.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448461607-16868-1-git-send-email-tiwai@suse.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
ipu_crtc_handle_pageflip() was calling drm_send_vblank_event() with
a pipe argument of -1. Commit cc1ef118fc09 ("drm/irq: Make pipe
unsigned and name consistent") now makes this error obvious, as we
now may get a warning from:
if (WARN_ON(pipe >= dev->num_crtcs))
in drm_vblank_count_and_time(). Prior to this change, we would end
up making out-of-bounds array accesses via:
struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
and
*vblanktime = vblanktimestamp(dev, pipe, cur_vblank);
So, this has been broken for a very long time, and is not a result
of the above commit. Since we don't care about the staging versions,
I've tagged this with the earliest mainline commit where we do care,
even though this commit did not introduce the bug.
Fixes: 6556f7f82b9c ("drm: imx: Move imx-drm driver out of staging")
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
Kbuild now supports <modname>-m variables.
This reverts commit 8fa884dc355ffd0caa964a284a530bf747df5c77.
Signed-off-by: Michal Marek <mmarek@suse.cz>
|
|
We have serious dangling else bugs waiting to happen in our for_each_
style macros with ifs. Consider, for example,
#define for_each_power_domain(domain, mask) \
for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \
if ((1 << (domain)) & (mask))
If this is used in context:
if (condition)
for_each_power_domain(domain, mask);
else
foo();
foo() will be called for each domain *not* in mask, if condition holds,
and not at all if condition doesn't hold.
Fix this by reversing the conditions in the macros, and adding an else
branch for the "for each" block, so that other if/else blocks can't
interfere. Provide a "for_each_if" helper macro to make it easier to get
this right.
v2: move for_each_if to drmP.h in a separate patch.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448392916-2281-2-git-send-email-jani.nikula@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
being set
Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Martin Peres <martin.peres@free.fr>
|
|
Regression from "abi16: implement limited interoperability with
usif/nvif".
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Somehow missed these two when removing dodgy void casts during the
rework.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
is zero
fdo#92761
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
correct GPC
Each GPCCS unit was reading the mask from GPC0, which causes problems on
boards where some GPCs are missing PPCs.
Part of the fix for fdo#92761.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
There's a few places where we need to access a GPC register from ucode,
but outside of the falcon's io address space. To do this we need to
calculate the offset based on which GPC we're executing on.
This used to be done manually, but we've since found a "base" offset
that can be added by the hardware. To use this, an extra bit needs to
be set in the register address, which is what this macro achieves.
There should be no functional change from this commit.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Fixes detection of a failed attempt at fetching the entire ROM image
in one-shot (a violation of the spec, that works a lot of the time).
Tested on a HP Zbook 15 G2.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
No locking is required for the traversal of this list, as it only
happens during suspend/resume where nothing else can be executing.
Fixes some of the issues noticed during parallel piglit runs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
fdo#70354 - comment #88.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
this is needed for my gpu
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
commit b04c5bd6fda54703e56f29569e4bca489d6c5a5c
Author: Borun Fu <borun.fu@intel.com>
Date: Sat Jul 12 10:02:27 2014 +0530
drm/i915: Power gating display wells during i915_pm_suspend
moved for_each_power_domain from intel_display.c to i915_drv.h but we
still have the definition around in intel_display.c, due to a merge
conflict resolution gone wrong in
commit 4dac3edfe68e5e1b3c2216b84ba160572420fa40
Merge: 487777673e35 e05444be705b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jul 29 20:49:36 2014 +0200
Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next
Just remove the extra definition left behind.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448383645-7615-1-git-send-email-jani.nikula@intel.com
|
|
On some cards it takes a relatively long time for the change
to take place. Make a timeout non-fatal.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76130
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
A single blank line is enough to separate Kconfig entries.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
For consistency with other drivers, use dashes instead of underscores in
filenames.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
On some machines the CRT connector may be fused off. The weird thing
about this setup is that the ADPA register works otherwise normally,
except the enable bit is hardwired to 0. No one knows of any fuse
register that would tell us if this is the case, so the only thing we
can do (apart from a blacklist) is to try and set the enable bit and see
if it sticks. If not, we don't register the connector at all. Obviously
if the bit is already set when loading the driver we can just assume it
works.
I've smoke tested this approach on several machines (GMCH and PCH),
some with actual CRT connectors, some with shadow connectors, and
obviously the machine (IVB) with the fused off connector. So far
I've not seen any ill effects from this probe.
The main benefit is that we can actually run igt on machines with
fused off connectors, without totally upsetting the state checker.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448051741-22771-1-git-send-email-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
To get a better idea if underruns occurred during crtc disabling,
let's check for them explicitly. This helps in cases where the
error interrupt isn't active, or there is no underrun interrupt
support at all.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448050160-14124-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
We sometimes get a spurious CPU pipe underrun somewhere between
enabling port A and enabling vdd for the panel. Observed on both
ILK and IVB with port A eDP. Suppress FIFO underrun reporting
around the port and vdd enable to avoid the dmesg errors.
Not sure if port D eDP would suffer from the same issue, but assume
that it doesn't until proven differently.
Testcase: igt/kms_setmode
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448050160-14124-2-git-send-email-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We still get spurious pipe underruns on ILK/SNB/IVB under two
circumstances when dealing with PCH ports:
* When the pipe has been disabled, but FDI RX/TX is still enabled
* During FDI link training
Both cases seem to happen at least when we do VGA+HDMI cloning
from the same pipe. I don't think I've seen them when not cloning,
but can't be 100% sure.
Disable underrun reporting around those places to eliminate the
dmesg errors.
Testcase: igt/kms_setmode/basic-clone-single-crtc
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448050160-14124-1-git-send-email-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
It is not a bad idea to disable the PSR feature on Sink
when we are disabling on the Source.
v2: Move dpcd write inside mutex protected area as suggested by Sonika.
Cc: Sonika Jindal <sonika.jindal@intel.com>
Suggested-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Whenever DMC firmware put the HW into DC State a bunch
of registers including this perf counter is reset to 0.
Even with PSR active and working we could still read
"Performance_Counter: 0" what will misslead people to believe
PSR is broken. For instance on SKL we can only see PC10
residency with screen on if PSR is working properly.
However Performance_Counter was showing 0.
Even if it restored properly on DC6 exit we don't want to
give users the wrong impression that PSR is not working
while we know for sure it is.
So, it is better to remove this counter information while
we don't have a better way to track PSR residency.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
When we introduced PSR we let LPSP masked allowing us to get PSR
independently from the audio runtime PM. However in one of the
attempts to get PSR enabled by default one user reported one specific
case where he would miss screen updates if scrolling the firefox in a
Gnome environment when i915 runtime pm was enabled. So for
this specific case that (I could never create an i-g-t test case)
we decided to remove the LPSP mask and let HW tracking taking care of
this case. The mask got removed later by my
commit 09108b90f04 ("drm/i915: PSR: Remove Low Power HW tracking mask.")
So we started depending on audio driver again, what is bad.
With previous commit
"drm/i915: PSR: Let's rely more on frontbuffer tracking."
we transfered the PSR exit responsability totally to SW frontbuffer
tracking. So now can safelly shut off a bit the HW tracking, or
at least this case that makes us to depend on other drivers.
v2: Update commit message since this patch by itself doesn't solve
the bugzilla entries.
v3: Another attempt to improve commit message.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau damien.lespiau@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The ultimate goal here is to remove the dependency we
currently have on audio driver power to get PSR working.
Since with audio driver runtime PM disabled the Hardware tracking
believes graphics is fully active and prevent PSR Entry, or
in other words continuously exit PSR.
So, the idea is to transfer the PSR exit responsability
from the HW tracking to the SW tracking (frontbuffer tracking),
who is really mature right now.
However with LPSP masked out there might be cases where we could
miss exit from HW tracking since it can be relying on this,
like a specific case reported at our mailing list who
user reported he would miss screen updates if scrolling firefox
in a Gnome environment when i915 runtimepm was enabled.
So before masking out LPSP again to make us independent from
the audio driver we need to make sure that all our cases
are coverred from the frontbuffer tracking perspective,
where the flush means invalidate and flush.
Without this patch for HSW, BDW and SKL we just do the
invalidate part when the flush wasn't originated by a page flip
because we were trusting the HW tracking for the flip case.
So let's rely more on frontbuffer tracking and do the
invalidation regardless the origin as expected for all platforms.
v2: Improve commit message as suggested by Paulo.
v3: Another attempt to let commit message more clear.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau damien.lespiau@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Commit (89251b17) intended to remove this line and let only one
DP_PSR_EN_CFG set, but it was wrong and this call is now duplicated
at the code.
Also "& ~DP_PSR_MAIN_LINK_ACTIVE" doesn't do anything at all. It
was like that since I introduced this call but probably the idea
was to be informative and make clear statement that we were not using
the link standby. So it is better to remove this one here and let
the code a bit cleaner.
v2: Improve commit message as requested by Paulo.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau damien.lespiau@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date: Mon Oct 5 13:26:36 2015 +0100
drm/i915: Clean up associated VMAs on context destruction
Added a warning based on an incorrect assumption that all VMAs
in a VM will be on the inactive list at the point last reference
to a context and VM is dropped.
This is not true because i915_gem_object_retire__read will not
put VMA on the inactive list until all activities on the object
in question (in all VMs) have been retired.
As a consequence, whether or not a context/VM will be destroyed
with its VMAs still on the active list, can depend on completely
unrelated activities using the same object from a different
context or engine.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92638
Testcase: igt/gem_request_retire/retire-vma-not-inactive
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448025816-25584-1-git-send-email-tvrtko.ursulin@linux.intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
To avoid even more code duplication punt this all to the probe worker,
which needs some slight adjustment to also generate a uevent when the
status has changed to due connector->force.
v2: Instead of running the output_poll_work (which is kinda the wrong
thing and a layering violation since it's an internal of the probe
helpers), or calling ->detect (which is again a layering violation
since it's used only by probe helpers) just call the official
->fill_modes function, like a GET_CONNECTOR ioctl call.
v3: Restore the accidentally removed forced-probe for echo "detect" >
force.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447951610-12622-22-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Use the correct function name for drm_atomic_clean_old_fb docs.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
We chase pointers/lists without taking the locks protecting them,
which isn't that good.
Fix it.
v2: Actually unlock properly, spotted by Julia.
v3: Put the label _before_ the mutex_unlock (Emil)
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Link: http://patchwork.freedesktop.org/patch/msgid/1443783662-23066-1-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
To aid in debugging failures, print the src,dst,clip rectangles
when drm_plane_helper_check_update() fails.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Allow the caller to specify a "prefix" string to drm_rect_debug_print()
to make it easier to see which drm_rect is being printed.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Drivers shouldn't clobber the passed in addfb ioctl parameters.
i915 was doing just that. To prevent it from happening again,
pass the struct around as const, starting all the way from
internal_framebuffer_create().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The simple_strtoul function is marked as obsolete.
This patch replace it by kstrtouint.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
I noticed that intel_fbdev->our_mode is unused. Introduced by
79e539453b34 ("DRM: i915: add mode setting support").
Then I noticed that intel_fbdev->fbdev_list is unused as well.
Introduced by 386516744ba4 ("drm/fb: fix fbdev object model +
cleanup properly.") in i915, nouveau and radeon.
Subsequently cargo culted to amdgpu, ast, cirrus, qxl, udl,
virtio and mgag200.
Already removed from the latter with cc59487a05b1 ("drm/mgag200:
'fbdev_list' in 'struct mga_fbdev' is not used").
Remove it from the others.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The drm_property_unreference_blob() function tests whether its argument
is NULL and then returns immediately.
Thus the tests around the calls are not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Link: http://patchwork.freedesktop.org/patch/msgid/563C8B3E.405@users.sourceforge.net
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
DRM_TEGRA_FBDEV config is currently used to enable/disable legacy fbdev
emulation for the tegra kms driver.
Remove this local config option and use the top level DRM_FBDEV_EMULATION
config option instead.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1445933459-5249-4-git-send-email-architt@codeaurora.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
DRM_IMX_FB_HELPER config is currently used to enable/disable fbdev
emulation for the imx kms driver.
Remove this local config option and use the top level DRM_FBDEV_EMULATION
config option where applicable. Using this config lets us also prevent
wrapping around drm_fb_helper_* calls with #ifdefs in certain places.
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1445933459-5249-2-git-send-email-architt@codeaurora.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
A bunch of things have been removed meanwhile and docs not fully
brought up to speed. And a few gaps closed where I noticed missing
kerneldoc while reading through the overview sections.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445533889-7661-3-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The drm_fbdev_cma_restore_mode() function tests whether its argument
is NULL and then returns immediately.
Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
The crtc child device driver shouldn't modify the of_node of its platform
device in the probe function. Instead, since the previous patch, the IPU
core driver sets the of_node when the platform device is created.
Drop the now unused custom imx_drm_get_port_by_id function.
Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
The crtc child device driver shouldn't have to modify the of_node of its
platform device in the probe function. Instead, let the IPU core driver
set the of_node when the platform device is created.
Also reorder the client_reg array so the elements are in port id order
(CSIs first, then DIs).
Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
This is not used, so remove it.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
panel
Similarly to commit 5e501ed7253b3 ("drm/imx: imx-ldb: allow to determine
bus format from the connected panel"), if a panel is connected to the ldb
output port via the of_graph bindings, the data mapping is determined from
the display_info.bus_format field provided by the panel instead of from the
optional interface_pix_fmt device tree property.
Reported-by: Ulrich Ölmann <u.oelmann@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Gary Bisson <gary.bisson@boundarydevices.com>
|
