The USB graphics card driver delays the unregistering of the framebuffer
device to a workqueue, which breaks the userspace visible remove uevent
sequence. Recent userspace tools started to support USB graphics card
hotplug out-of-the-box and rely on proper events sent by the kernel.
The framebuffer device is a direct child of the USB interface which is
removed immediately after the USB .disconnect() callback. But the fb device
in /sys stays around until its final cleanup, at a time where all the parent
devices have been removed already.
To work around that, we remove the sysfs fb device directly in the USB
.disconnect() callback and leave only the cleanup of the internal fb
data to the delayed work.
Before:
add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb0 (graphics)
remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
remove /2-1.2:1.0/graphics/fb0 (graphics)
After:
add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb1 (graphics)
remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb1 (graphics)
remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
Cc: stable@vger.kernel.org
Tested-by: Bernie Thompson <bernie@plugable.com>
Acked-by: Bernie Thompson <bernie@plugable.com>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
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>
The drm_display_mode type is a bitmask so it should be unsigned.
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>
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (57 commits)
drm/nouveau: map first page of mmio early and determine chipset earlier
drm/nvd0/disp: disconnect encoders before reprogramming them
drm/nvd0/disp: move syncs/magic setup to or mode_set
drm/nouveau/dp: account for channel coding overhead in link training
drm/nvd0/disp: fix dcb sor link matching in supervisor handler
drm/nvd0/disp: initial implementation of displayport
drm/nouveau/dp: make dp dpms function common, call from sor code instead
drm/nv50/hwsq: some nv92 fixes
drm/nouveau/dp: move all nv50/sor-specific code out of nouveau_dp.c
drm/nouveau/dp: make functions for executing various bios tables
drm/nouveau/pm: fix oops if chipset has no pm support at all
drm/nouveau/bios: rework vbios shadowing
drm/nouveau/bios: attempt acpi rom fetch before pcirom
drm/nvd0/disp: attempt to handle more than 2 crtcs if possible
drm/nvc0/vram: get part count from PUNITS
drm/nv40/pm: fix fanspeed regression
drm/nouveau/pm: several fixes for nvc0 memory timings
drm/nvc0/pm: restrict pll mode to clocks that can actually use it
drm/nouveau/dp: fix bad comparison in dp_link_train_commit()
drm/nouveau/mxm: call mxmi to determine revision before calling mxms
...
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>
There's a HP laptop out there where the MXM version in the VBIOS doesn't
match what the ACPI implementation is expecting. These tables will accept
0x00 to MXMS to return latest version, but *only* if MXMI has been called
first..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This patch fixes an oops cause by pm_trigger accessing the (uninitialised)
crtc list.
Reported-by: Roy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
v2 (Emil Velikov <emil.l.velikov@gmail.com>):
- Fixed a regression on certain nv50 IGP due to not passing the correct
target type to nv50_vm_addr()
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Johannes Obermayr <johannesobermayr@gmx.de>
Goes a long way to correcting NVS295 memory reclocking issues.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
