[Openchrome-devel] [drm-openchrome]DRM driver for VIA IGPs branch master updated. 9a1424679042d86609e99ddd341d0b73c048546b
James Simmons
jsimmons at kemper.freedesktop.org
Sat Feb 16 06:41:48 PST 2013
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "DRM driver for VIA IGPs".
The branch, master has been updated
via 9a1424679042d86609e99ddd341d0b73c048546b (commit)
via 788e9c7713139cfe117abbfc643a0bc0882c9722 (commit)
via 3314fdf8b44bd4914050614fa2c56b7c587fabc2 (commit)
via f934ec8c34b9dcefb5a4f35b0bda33bca289cbe6 (commit)
via 3e2b756ba330343c960c332695608b9c5881a173 (commit)
via 93711d8becca550154da3b9e422be77083ab51ad (commit)
via a065b46a01b25d7d364e01e75f7ec2bd9ed5d9cb (commit)
via 1b1d5397058f06bc5bd87d43ed93f34b28546ea4 (commit)
via 207fd32970b1def91b11ae28f6bebffc792db714 (commit)
via cd5428a5447cc6ca77ec6547d6f86834b205eac7 (commit)
via 8acf658ad6246be7913647e6e76da6a539bff425 (commit)
via 2180c3c7e76536ce8ff0fd957a11dbfaa1e93403 (commit)
via 7e53f3a423146745a4e4bb93362d488dfad502a8 (commit)
via af5676f1f91585cabe811b8f697e32015e2be826 (commit)
via 76a39dbfb2d1bc45219839e5a95d4ceaf6ca114f (commit)
via 203cb50143029b2bc95736ce10f7defcf59aca44 (commit)
via de1ace5b56d11db26abe69fd19754f91c326763f (commit)
via 43c8a849a1e92fba6ea4493ed950d2a2e31ac87c (commit)
via d21bf469d5301d025cd82997bb1529bcdc7086af (commit)
via 6aed8ec3f76a22217c9ae183d32b1aa990bed069 (commit)
via db3985e5ca8f50fc17606855ba394783d11683a5 (commit)
via d3f03e963ce0a67b7ade179c12ac5c74293d6210 (commit)
from 1cd8d917b3d7c1bb48925019777c5cb23b363529 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 9a1424679042d86609e99ddd341d0b73c048546b
Author: James Simmons <jsimmons at infradead.org>
Date: Sat Feb 16 09:41:00 2013 -0500
Sync to drm-fb-helper changes
commit 788e9c7713139cfe117abbfc643a0bc0882c9722
Merge: d3f03e9 3314fdf
Author: James Simmons <jsimmons at infradead.org>
Date: Sat Feb 16 09:17:37 2013 -0500
Merge branch 'drm-next'
commit 3314fdf8b44bd4914050614fa2c56b7c587fabc2
Merge: f934ec8c a065b46
Author: Dave Airlie <airlied at redhat.com>
Date: Fri Feb 15 10:21:55 2013 +1000
Merge branch 'drm-fb-helper' of git://people.freedesktop.org/~danvet/drm into drm-next
This is the drm fb helper cleanup, mostly motivated by strange things I've
seen in my locking rework and the i915 modeset revamp. Compared to the
original submission I've reinstated the setup flexibility you'd like to
retain, kerneldoc has been reviewed by Laurent Pinchart and Rob Clark
reviewed the code changes.
Quick overview of the changes:
- Cleaned-up library interface for drivers using the fb helper, also
simplified the fb allocation callback since no driver supported
reallocating the fb on-the-fly. And the fbdev/fbcon code keeps pointers
to the old mapping around anyway, so reallocating backing storage will
be much more work.
- No longer call the crtc helper "disable everything" function at init
time, but allow drivers to do so. Motivated by i915's fastboot effort
and allows us to drop a bunch of noop dummy functions just to avoid
calling NULL function pointers from i915.ko.
- Properly clear old state when doing modeset calls, the fb helper left
some old modes in there and unconditionally set an fb (even when
disabling a crtc). The crtc helpers didn't care, but i915 modeset code
can now drop a few special cases.
- Full kerneldoc for the fb helper. Yay!
- My version of the "don't sleep in panic ->unblank calls". The patch is
already in -mm, I guess Andrew can drop it as soon as this pull lands in
drm-next.
* 'drm-fb-helper' of git://people.freedesktop.org/~danvet/drm:
drm/fb-helper: remove unused members of struct drm_fb_helper
drm/fb-helper: don't sleep for screen unblank when an oopps is in progress
drm/fb-helper: improve kerneldoc
drm/<drivers>: simplify ->fb_probe callback
drm/fb-helper: streamline drm_fb_helper_single_fb_probe
drm/fb-helper: directly call set_par from the hotplug handler
drm/fb-helper: fixup set_config semantics
drm/i915: rip out helper->disable noop functions
drm/fb-helper: don't disable everything in initial_config
drm/tegra: don't set up initial fbcon config twice
drm/fb-helper: unexport drm_fb_helper_single_fb_probe
drm/fb-helper: unexport drm_fb_helper_panic
drm/fb-helper: kill drm_fb_helper_restore
drm: review locking for drm_fb_helper_restore_fbdev_mode
commit f934ec8c34b9dcefb5a4f35b0bda33bca289cbe6
Author: Maarten Lankhorst <maarten.lankhorst at canonical.com>
Date: Tue Jan 29 14:27:39 2013 +0100
drm: shut up invalid edid messages
My cheapo monitor has an invalid block 1, resulting in a lot of dmesg spam every few seconds.
I get it the first time that the entire block is all 0xff..
Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com>
Cc: stable at vger.kernel.org [v3.7]
Signed-off-by: Dave Airlie <airlied at redhat.com>
commit 3e2b756ba330343c960c332695608b9c5881a173
Author: Chris Metcalf <cmetcalf at tilera.com>
Date: Fri Feb 1 13:44:33 2013 -0500
drm: fix compile failure by including <linux/swiotlb.h>
On tile architecture (with "make allyesconfig") including
<linux/swiotlb.h> is required to call swiotlb_nr_tbl().
Signed-off-by: Chris Metcalf <cmetcalf at tilera.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst at canonical.com>
Signed-off-by: Dave Airlie <airlied at redhat.com>
commit 93711d8becca550154da3b9e422be77083ab51ad
Author: Bjorn Helgaas <bhelgaas at google.com>
Date: Fri Feb 8 15:27:01 2013 -0700
drm/pci: define drm_pcie_get_speed_cap_mask() only when CONFIG_PCI=y
Move drm_pcie_get_speed_cap_mask() under #ifdef CONFIG_PCI because it
it used only for PCI devices (evergreen, r600, r770), and it uses
PCI interfaces that only exist when CONFIG_PCI=y.
Previously, we tried to compile drm_pcie_get_speed_cap_mask() even when
CONFIG_PCI=n, which fails.
Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Dave Airlie <airlied at redhat.com>
commit a065b46a01b25d7d364e01e75f7ec2bd9ed5d9cb
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date: Tue Feb 12 00:17:09 2013 +0100
drm/fb-helper: remove unused members of struct drm_fb_helper
Spotted by Rob Clark.
Reviewed-by: Rob Clark <robdclark at gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
commit 1b1d5397058f06bc5bd87d43ed93f34b28546ea4
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date: Thu Jan 24 16:42:07 2013 +0100
drm/fb-helper: don't sleep for screen unblank when an oopps is in progress
Otherwise the system will burn even brighter and worse, leave the user
wondering what's going on exactly.
Since we already have a panic handler which will (try) to restore the
entire fbdev console mode, we can just bail out. Inspired by a patch
from Konstantin Khlebnikov. The callchain leading to this, cut&pasted
from Konstantin's original patch:
callstack:
panic()
bust_spinlocks(1)
unblank_screen()
vc->vc_sw->con_blank()
fbcon_blank()
fb_blank()
info->fbops->fb_blank()
drm_fb_helper_blank()
drm_fb_helper_dpms()
drm_modeset_lock_all()
mutex_lock(&dev->mode_config.mutex)
Note that the entire locking in the fb helper around panic/sysrq and
kdbg is ... non-existant. So we have a decent change of blowing up
everything. But since reworking this ties in with funny concepts like
the fbdev notifier chain or the impressive things which happen around
console_lock while oopsing, I'll leave that as an exercise for braver
souls than me.
v2: Drop the -EBUSY return value I've copied, we don't need it since
the we'll take care of things ourselves anyway.
Cc: Konstantin Khlebnikov <khlebnikov at openvz.org>
Cc: Andrew Morton <akpm at linux-foundation.org>
References: https://patchwork.kernel.org/patch/1878181/
Reviewed-by: Rob Clark <robdclark at gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
commit 207fd32970b1def91b11ae28f6bebffc792db714
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date: Sun Jan 20 22:13:14 2013 +0100
drm/fb-helper: improve kerneldoc
Now that the fbdev helper interface for drivers is trimmed down,
update the kerneldoc for all the remaining exported functions.
I've tried to beat the DocBook a bit by reordering the function
references a bit into a more sensible ordering. But that didn't work
out at all. Hence just extend the in-code DOC: section a bit.
Also remove the LOCKING: sections - especially for the setup functions
they're totally bogus. But that's not a documentation problem, but
simply an artifact of the current rather hazardous locking around drm
init and even more so around fbdev setup ...
v2: Some further improvements:
- Also add documentation for drm_fb_helper_single_add_all_connectors,
Dave Airlie didn't want me to kill this one from the fb helper
interface.
- Update docs for drm_fb_helper_fill_var/fix - they should be used
from the driver's ->fb_probe callback to setup the fbdev info
structure.
- Clarify what the ->fb_probe callback should all do - it needs to
setup both the fbdev info and allocate the drm framebuffer used as
backing storage.
- Add basic documentaation for the drm_fb_helper_funcs driver callback
vfunc.
v3: Implement clarifications Laurent Pinchart suggested in his review.
v4: Fix another mispelling Laurent spotted.
Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
commit cd5428a5447cc6ca77ec6547d6f86834b205eac7
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date: Mon Jan 21 23:42:49 2013 +0100
drm/<drivers>: simplify ->fb_probe callback
The fb helper lost its support for reallocating an fb completely, so
no need to return special success values any more.
Reviewed-by: Rob Clark <robdclark at gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
commit 8acf658ad6246be7913647e6e76da6a539bff425
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date: Mon Jan 21 23:38:37 2013 +0100
drm/fb-helper: streamline drm_fb_helper_single_fb_probe
No need to check whether we've allocated a new fb since we're not
always doing that. Also, we always need to register the fbdev and add
it to the panic notifier.
Reviewed-by: Rob Clark <robdclark at gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
commit 2180c3c7e76536ce8ff0fd957a11dbfaa1e93403
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date: Mon Jan 21 23:12:36 2013 +0100
drm/fb-helper: directly call set_par from the hotplug handler
The idea behind calling down into the driver's ->fb_probe function on each
hotplug seems to be able to reallocate the backing storage (if e.g. a screen
with higher resolution gets added). But that requires quite a bit of work in the
fb helper itself, since currently we limit new screens to the currently
allocated fb. An no kms driver supports fbdev fb resizing.
So don't bother and start to simplify the code by calling drm_fb_helper_set_par
directly from the fbdev hotplug function, since that's the only thing left in
drm_fb_helper_single_fb_probe which does not concern itself with fb allocation
and initial setup. Follow-on patches will streamline the initial setup
code.
Reviewed-by: Rob Clark <robdclark at gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
commit 7e53f3a423146745a4e4bb93362d488dfad502a8
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date: Mon Jan 21 10:52:17 2013 +0100
drm/fb-helper: fixup set_config semantics
While doing the modeset rework for drm/i915 I've noticed that the fb
helper is very liberal with the semantics of the ->set_config
interface:
- It doesn't bother clearing stale modes (e.g. when unplugging a
screen).
- It unconditionally sets the fb, even if no mode will be set on a
given crtc.
- The initial setup is a bit fun since we need to pick crtcs to decide
the desired fb size, but also should set the modeset->fb pointer.
Explain what's going on in the fixup code after the fb is allocated.
The crtc helper didn't really care, but the new i915 modeset
infrastructure did, so I've had to add a bunch of special-cases to
catch this.
Fix this all up and enforce the interface by converting the checks in
drm/i915/intel_display.c to BUG_ONs.
v2: Fix commit message spell fail spotted by Rob Clark.
Reviewed-by: Rob Clark <robdclark at gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
commit af5676f1f91585cabe811b8f697e32015e2be826
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date: Sun Jan 20 23:28:14 2013 +0100
drm/i915: rip out helper->disable noop functions
Now that the driver is in control of whether it needs to disable
everything at take-over or not, we can rip this all out.
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
commit 76a39dbfb2d1bc45219839e5a95d4ceaf6ca114f
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date: Sun Jan 20 23:12:54 2013 +0100
drm/fb-helper: don't disable everything in initial_config
This should be done in the drivers for two reasons:
- it gets in the way of fastboot efforts
- it links the fb helpers with the crtc helpers instead of going
through the real interface vfuncs, forcing i915 to fake all the
->disable callbacks used by the crtc helper to avoid ugly Oopsen
v2: Resolve conflicts since drivers still call
drm_fb_helper_single_add_all_connectors.
Reviewed-by: Rob Clark <robdclark at gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
commit 203cb50143029b2bc95736ce10f7defcf59aca44
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date: Sun Jan 20 21:56:20 2013 +0100
drm/tegra: don't set up initial fbcon config twice
drm_fbdev_cma_init does the inital fbcon setup by calling down into
drm_fb_helper_initial_config, so no need at all to restore the just
set up configuration right away ...
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
commit de1ace5b56d11db26abe69fd19754f91c326763f
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date: Sun Jan 20 21:50:49 2013 +0100
drm/fb-helper: unexport drm_fb_helper_single_fb_probe
Not called by anyone, and really, shouldn't be. Drivers are supposed
either drm_fb_helper_initial_config or drm_fb_helper_hotplug_event.
Originally this was done differently, but is now consolidated in the
helper functions and no longer done by drivers directly.
Reviewed-by: Rob Clark <robdclark at gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
commit 43c8a849a1e92fba6ea4493ed950d2a2e31ac87c
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date: Sun Jan 20 18:18:07 2013 +0100
drm/fb-helper: unexport drm_fb_helper_panic
It doesn't even show up in any header files and only used iternally.
Originally it was (ab)used to restore the fbcon on lastclose, but that
died with
commit e8e7a2b8ccfdae0d4cb6bd25824bbedcd42da316
Author: Dave Airlie <airlied at redhat.com>
Date: Thu Apr 21 22:18:32 2011 +0100
drm/i915: restore only the mode of this driver on lastclose (v2)
Reviewed-by: Rob Clark <robdclark at gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
commit d21bf469d5301d025cd82997bb1529bcdc7086af
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date: Sun Jan 20 18:09:52 2013 +0100
drm/fb-helper: kill drm_fb_helper_restore
It's only used internally for the sysrq and panic handlers provided by
the drm fb helper implementation. Hence just inline it, kill the
export and remove the confusing kerneldoc. Driver's are supposed to
call drm_fb_helper_restore_fbdev_mode on lastclose.
Note that locking is totally fubar - the sysrq case doesn't take any
locks at all. The panic handler probably shouldn't take any locks
since it'll only make things worse. Otoh it's probably better to
switch things over to the atomic modeset callbacks (and disable the
panic handler for those drivers which don't implement it).
But that's both better done in separate patches.
Reviewed-by: Rob Clark <robdclark at gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
commit 6aed8ec3f76a22217c9ae183d32b1aa990bed069
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date: Sun Jan 20 17:32:21 2013 +0100
drm: review locking for drm_fb_helper_restore_fbdev_mode
... it's required. Fix up exynos and the cma helper, and add a
corresponding WARN_ON to drm_fb_helper_restore_fbdev_mode.
Note that tegra calls the fbdev cma helper restore function also from
it's driver-load callback. Which is a bit against current practice,
since usually the call is only from ->lastclose, and initial setup is
done by drm_fb_helper_initial_config.
Also add the relevant drm DocBook entry.
v2: Add promised WARN to restore_fbdev_mode.
Reviewed-by: Rob Clark <robdclark at gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
commit db3985e5ca8f50fc17606855ba394783d11683a5
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date: Wed Feb 13 20:37:48 2013 +1000
Revert "drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S"
This reverts commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b.
The quirk cause a regression, and it looks like the original bug was
simply a lack of FIFO bandwidth on the i915G of the reporter. Which
should eventually be fixed as soon as we get around to implemented
DSPARB FIFO reassignment on gen 3.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52281
Cc: stable at vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
Signed-off-by: Dave Airlie <airlied at redhat.com>
commit d3f03e963ce0a67b7ade179c12ac5c74293d6210
Author: James Simmons <jsimmons at infradead.org>
Date: Sun Feb 10 10:54:32 2013 -0500
mdelay can cause errors if the clock source is broke. So we use udelay
-----------------------------------------------------------------------
Summary of changes:
Documentation/DocBook/drm.tmpl | 1 +
drivers/gpu/drm/ast/ast_fb.c | 26 +--
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 26 +---
drivers/gpu/drm/drm_crtc.c | 16 ++-
drivers/gpu/drm/drm_edid.c | 9 +-
drivers/gpu/drm/drm_fb_cma_helper.c | 22 +--
drivers/gpu/drm/drm_fb_helper.c | 251 +++++++++++++++++++++++------
drivers/gpu/drm/drm_pci.c | 54 +++---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 35 +----
drivers/gpu/drm/gma500/framebuffer.c | 14 +-
drivers/gpu/drm/i915/intel_crt.c | 1 -
drivers/gpu/drm/i915/intel_ddi.c | 1 -
drivers/gpu/drm/i915/intel_display.c | 20 +--
drivers/gpu/drm/i915/intel_dp.c | 1 -
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_dvo.c | 1 -
drivers/gpu/drm/i915/intel_fb.c | 21 +--
drivers/gpu/drm/i915/intel_hdmi.c | 1 -
drivers/gpu/drm/i915/intel_lvds.c | 1 -
drivers/gpu/drm/i915/intel_sdvo.c | 1 -
drivers/gpu/drm/i915/intel_tv.c | 1 -
drivers/gpu/drm/mgag200/mgag200_fb.c | 27 +---
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 25 +---
drivers/gpu/drm/radeon/radeon_fb.c | 25 +--
drivers/gpu/drm/radeon/radeon_ttm.c | 1 +
drivers/gpu/drm/tegra/fb.c | 4 -
drivers/gpu/drm/udl/udl_fb.c | 26 +---
drivers/gpu/drm/via/via_clocks.c | 4 +-
drivers/gpu/drm/via/via_fb.c | 1 +
drivers/staging/omapdrm/omap_fbdev.c | 21 +--
include/drm/drm_crtc.h | 1 +
include/drm/drm_fb_helper.h | 18 ++-
33 files changed, 335 insertions(+), 323 deletions(-)
hooks/post-receive
--
DRM driver for VIA IGPs
More information about the Openchrome-devel
mailing list