- 07 Jul, 2014 7 commits
-
-
Fabian Frederick authored
Fix checkpatch warning: WARNING: kfree(NULL) is safe this check is probably not required Cc: David Airlie <airlied@linux.ie> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
David Herrmann <dh.herrmann@gmail.com>
-
Fabian Frederick authored
use mm.h definition Signed-off-by:
-
Lucas Stach authored
Nouveau can now be used on ARM, so add an ioprot handler for this architecture. Signed-off-by:
Lucas Stach <dev@lynxeye.de> Signed-off-by:
Alexandre Courbot <acourbot@nvidia.com> Signed-off-by:
-
David Herrmann authored
We introduced render-nodes about 1/2 year ago and no problems showed up. Remove the drm_rnodes argument and enable them by default now. Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alexandre Courbot authored
ttm_tt_cache_flush's implementation was removed in 2009 by commit c9c97b8c, but its declaration has been hiding in ttm_bo_driver.h since then. It has been surviving in the dark for too long now ; give it the mercy blow. Reviewed-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
-
David Herrmann authored
drm_gem_get_pages() currently allows passing a 'gfp' parameter that is passed to shmem combined with mapping_gfp_mask(). Given that the default mapping_gfp_mask() is GFP_HIGHUSER, it is _very_ unlikely that anyone will ever make use of that parameter. In fact, all drivers currently pass redundant flags or 0. This patch removes the 'gfp' parameter. The only reason to keep it is to remove flags like __GFP_WAIT. But in its current form, it can only be used to add flags. So to remove __GFP_WAIT, you'd have to drop it from the mapping_gfp_mask, which again is stupid as this mask is used by shmem-core for other allocations, too. If any driver ever requires that parameter, we can introduce a new helper that takes the raw 'gfp' parameter. The caller'd be responsible to combine it with mapping_gfp_mask() in a suitable way. The current drm_gem_get_pages() helper would then simply use mapping_gfp_mask() and call the new helper. This is what shmem_read_mapping_pages{_gfp,} does right now. Moreover, the gfp-zone flag-usage is not obvious: If you pass a modified zone, shmem core will WARN() or even BUG(). In other words, the following must be true for 'gfp' passed to shmem_read_mapping_pages_gfp(): gfp_zone(mapping_gfp_mask(mapping)) == gfp_zone(gfp) Add a comment to drm_gem_read_pages() explaining that constraint. Signed-off-by: -
David Herrmann authored
OMAP requires bo-pages to be in the DMA32 zone. Explicitly request this by setting __GFP_DMA32 as mapping-gfp-mask during shmem initialization. This drops HIGHMEM from the gfp-mask and uses DMA32 instead. shmem-core takes care to relocate pages during swap-in in case they have been loaded into the wrong zone. It is _not_ possible to pass __GFP_DMA32 to shmem_read_mapping_page_gfp() as the page might have already been swapped-in at that time. The zone-mask must be set during initialization and be kept constant for now. Remove the now superfluous TODO in omap_gem.c. Reviewed-by:
Rob Clark <robdclark@gmail.com> Tested-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
- 17 Jun, 2014 1 commit
-
-
David Herrmann authored
Instead of shuffling gfp-masks all the time, use the shmem_read_mapping_page() helper. Note that __GFP_IO and __GFP_WAIT are set in mapping_gfp_mask() for i915, so the behavior is still the same. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
- 11 Jun, 2014 32 commits
-
-
Dave Airlie authored
Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next display rework fixes lots of displayport issues. * 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (43 commits) drm/nouveau/disp/dp: fix tmds passthrough on dp connector drm/nouveau/dp: probe dpcd to determine connectedness drm/nv50-: trigger update after all connectors disabled drm/nv50-: prepare for attaching a SOR to multiple heads drm/gf119-/disp: fix debug output on update failure drm/nouveau/disp/dp: make use of postcursor when its available drm/g94-/disp/dp: take max pullup value across all lanes drm/nouveau/bios/dp: parse lane postcursor data drm/nouveau/dp: fix support for dpms drm/nouveau: register a drm_dp_aux channel for each dp connector drm/g94-/disp: add method to power-off dp lanes drm/nouveau/disp/dp: maintain link in response to hpd signal drm/g94-/disp: bash and wait for something after changing lane power regs drm/nouveau/disp/dp: split link config/power into two steps drm/nv50/disp: train PIOR-attached DP from second supervisor drm/nouveau/disp/dp: make use of existing output data for link training drm/gf119/disp: start removing direct vbios parsing from supervisor drm/nv50/disp: start removing direct vbios parsing from supervisor drm/nouveau/disp/dp: maintain receiver caps in response to hpd signal drm/nouveau/disp/dp: create subclass for dp outputs ...
-
Ben Skeggs authored
Signed-off-by:Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
We were sending the necessary state changes to unset the mode, but never actually hit the big GO button unless another modeset happens afterwards. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
And at the same time, obey the spec better wrt out-of-range requests. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
SOR_PWR has no effect to power-off DP links, unlike other SOR protocols. Instead, on the source side, we cut power to the lanes after having put the sink into D3. Link training takes care of everything required to bring it back again. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
This previously worked for the most part due to userspace doing a modeset in response to HPD interrupts. This will allow us to properly handle cases where sync is lost for other reasons, or if userspace isn't caring. Signed-off-by: -
Ben Skeggs authored
Some kind of update? Needed to make the power-down take effect at least. Signed-off-by: -
Ben Skeggs authored
We want to be able to power down the lanes for DPMS off. Signed-off-by: -
Ben Skeggs authored
Same place as for SOR, between detach and attach phases. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
This will, at some point, be used to replace various bits and pieces of code doing direct bios parsing. For now, it'll just be used for some DP improvements. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
There's also provisions to allow a pad to be locked with a specific routing, for an indefinite period of time. This will be used in future patches. The G94+ pad driver will now also power-down pads when not required. Signed-off-by: -
Ben Skeggs authored
This was a half-finished hack before, just enough to handle the shared aux/i2c pad thing on G94 and up. We got lucky with locking etc up until now, as this was (generally) all protected by the DRM mode_config lock. It's about to become a lot more likely to hit the races. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by:
-
