Following the documentation of the Legacy Backlight Brightness (LBB)
Register in the configuration space of some Intel PCI graphics adapters,
setting the LBB register with the value 0x0 causes the backlight to be
turned off, and 0xFF causes the backlight to be set to 100% intensity
(http://download.intel.com/embedded/processors/Whitepaper/324567.pdf).
The Acer Aspire 5734Z, however, turns the backlight off at 0xFF and sets
it to maximum intensity at 0. In consequence, the screen of this systems
becomes dark at an early boot stage which makes it unusable. The same
inversion applies to the BLC_PWM_CTL I915 register. This problem was
introduced in kernel version 2.6.38 when the PCI device of this system
was first supported by the i915 KMS module.
This patch adds a parameter to the i915 module to enable inversion of
the brightness variable (i915.invert_brightness).
Signed-off-by: Carsten Emde <C.Emde@osadl.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I have seen a number of "blt ring initialization failed" messages
where the ctl or start registers are not the correct value. Upon further
inspection, if the code just waited a little bit, it would read the
correct value. Adding the wait_for to these reads should eliminate the
issue.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some newer BIOSes are shipping with all MTRRs already populated. These
BIOSes are all on machines with sufficiently new CPUs that the
referenced errata doesn't apply anyway, so just don't try to claim the
MTRR.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41648
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No functional change here, just clarifying code flow.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is an initial drm/kms driver for the displaylink devices.
Supports fb_defio,
supports KMS dumb interface
supports 24bpp via conversion to 16bpp, hw can do this better.
supports hot unplug using new drm core features.
On an unplug, it disables connector polling, unplugs connectors
from sysfs, unplugs fbdev layer (using Kay's API), drops all the
USB device URBs, and call the drm core to unplug the device.
This driver is based in large parts on udlfb.c so I've licensed
it under GPLv2.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Two parts to this, one is simple unplug from sysfs for the device node.
The second adds an unplugged state, if we have device opens, we
just set the unplugged state and return, if we have no device
opens we drop the drm device.
If after a lastclose we discover we are unplugged we then
drop the drm device.
v2: use an atomic for unplugged and wrap it for users,
add checks on open + mmap + ioctl entry points.
Signed-off-by: Dave Airlie <airlied@redhat.com>
In order to get correct ordering at hot-unplug for userspace,
we need to tear down all the sysfs bits at the correct time.
This adds a helper to allow drivers to remove the sysfs nodes
for all connectors.
Signed-off-by: Dave Airlie <airlied@redhat.com>
a step towards correct hot unplug for USB devices, we need to
remove the userspace facing bits at the unplug time for correct
udev operation.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add a helper function to copy a display mode. Use it in
drm_mode_duplicate() and nouveau mode_fixup hooks.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The blob property data is always allocated immediately after the object
header. No need for the extra indirection when accessing it, just use
a flexible array member.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Check drm_mode_object_get() return value everywhere.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm_crtc_convert_umode() and drm_crtc_convert_to_umode() are never
used outside drm_crtc.c, so make them static. Also make the input
mode structure const for both functions.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Change drm_mode_attachmode_crtc() to take an "all or nothing" approach.
If an error is returned, there are no side effects visible.
Also change the function to always duplicate the mode passed in.
Also change the function to not give up when it finds the first
connector without and encoder.
A simpler approach would be to just remove the function completely as
it's unused currently.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Make sure the requested CRTC viewport fits inside the
framebuffer.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The internal mode representation drm_display_mode uses signed data
types. When converting the user mode to internal representation,
check that the unsigned values don't overflow the signed datatypes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The mode passed to the .set_config() hook was never freed. The drivers
will make a copy of the mode, so simply free it when done.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm_mode_attachmode() always returns 0. Change the return type to void.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The crtc x/y panning coordinates are stored as signed integers
internally. The user provides them as unsigned, so we should check
that the user provided values actually fit in the internal datatypes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When converting from a drm_display_mode to drm_mode_modeinfo, print a
warning if the the timings values don't fit into the __u16 datatype.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When doing a mode set with the special fb id -1, reject the mode set if
no fb is currently bound to the crtc.
Also remove the pointless list traversal to find the current crtc based
on the current crtc :)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We fall apart somewhat on resume because we don't invoke all the resume
methods as we should. Fix the silly error in the logic.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-samsung:
drm exynos: use drm_fb_helper_set_par directly
drm/exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion
drm/exynos: fix runtime_pm fimd device state on probe
drm/exynos: use correct 'exynos-drm' name for platform device
info->fix.visual already is correctly set from drm_fb_helper_fill_fix.
info->fix.line_length is also set from drm_fb_helper_fill_fix,
so drm_fb_helper_set_par directly instead of a custom
exynos_drm_fbdev_set_par.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
The fb_videomode structure stores the front porch and back porch in the
right_margin and left_margin fields respectively. right_margin should
thus be computed with hsync_start - hdisplay, and left_margin with
htotal - hsync_end. The same holds for the vertical direction.
Active Front Sync Back
Region Porch Porch
<-------------------><----------------><-------------><---------------->
//////////////////|
////////////////// |
////////////////// |.................. ..................
_______________
<------ xres -------><- right_margin -><- hsync_len -><- left_margin -->
<---- hdisplay ----->
<------------ hsync_start ------------>
<--------------------- hsync_end -------------------->
<--------------------------------- htotal ----------------------------->
Fix the fb_videomode <-> drm_mode_modeinfo conversion functions
accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
A call to pm_runtime_set_active() forces device to be at the active
state and skips calling its runtime suspend/resume callbacks. This
results in a freeze with a new power domain code based on gen_pd. Fimd
driver does all required runtime power management calls, so this
pm_runtime_set_active call is buggy. This patch removes it and corrects
clock management in probe function (clocks are now enabled by
pm_runtime_get_sync() call).
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Currently Exynos DRM driver uses DRIVER_NAME ('exynos') name for the
core platform device. This is confusing, because it doesn't refer to the
function the platform device is performing. This patch renames the
platform device to the 'exynos-drm', which matches the convention for
naming the platform devices. The name used inside DRM subsystem has not
been changed.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux:
drm/i915: support 32 bit BGR formats in sprite planes
drm/i915: fix color order for BGR formats on SNB
drm/gma500: Fix Cedarview boot failures in 3.3-rc
NVIDIA appear to do these around the same place they do the MODE_CTRL
methods, and for DP at least we need to bash some extra bits in "syncs"
to keep EVO happy.
It's a bit of a guess as to the 6/8bpc, but i have no better idea yet.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The shift from hwsq_data = 0x1400 to 0x080000 actually happened in nv94, not nv92
This fixes some reclocking issues on my newly acquired nv92
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Off-chip encoders (which we don't support yet anyway), and newer chipsets
(such as NVD9...), will need their own code for this.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
More code to do the same thing, but will make it easier to handle various
changes that could possibly happen the the VBIOS tables.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Refactored to allow shadowing of VBIOS images longer than 64KiB, which
allows us to pass the VBIOS checksum test on certain boards.
There's also a workaround for reading the PROM VBIOS on some chipsets.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There's cards out there with completely messed up PCIROM images that have
a perfectly valid signature.. Sigh!
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Theoretically handles CRTC2/CRTC3, should any GF119 out there actually
have them enabled. The room is there for the regs etc, so why not :)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This patch fixes two small issues in timing generation as spotted on
several NVCx cards.
In addition, the header of the file is updated to also contain (some of)
the current developers of this code.
Signed-off-by: Roy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The comparison (lpre == DP_TRAIN_PRE_EMPHASIS_9_5) is always false:
lpre is initialized as (lane & 0x0c) >> 2, which is at most 3, while
DP_TRAIN_PRE_EMPHASIS_9_5 is defined as (3 << 3).
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
