In Haswell while disabling a pipe, we need to disable the DDI control as
well along with the PIPECONF. Otherwise we will hit assertions during crtc
disable
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |7 +++
1 files changed, 7
Hi Daniel -
On Thu, 07 Jun 2012, Daniel Vetter daniel.vet...@ffwll.ch wrote:
I've done an audit of everything which is being set up between the
place where drm_pci_agp_init is called currently and where the
driver's -load function is called. Nothing seems to depend upon
dev-agp being set up
On Thu, 07 Jun 2012, Daniel Vetter daniel.vet...@ffwll.ch wrote:
To be able to directly set up the intel-gtt code from drm/i915 and
avoid setting up the fake-agp driver we need to prepare a few things:
- pass both the bridge and gpu pci_dev to the probe function and add
code to handle the
On Fri, Jun 08, 2012 at 11:44:23AM +0530, Shobhit Kumar wrote:
In Haswell while disabling a pipe, we need to disable the DDI control as
well along with the PIPECONF. Otherwise we will hit assertions during crtc
disable
Hm, can you add such an example assert with backtrace please? All these
On 06/08/2012 09:49 AM, Daniel Vetter wrote:
On Fri, Jun 08, 2012 at 11:44:23AM +0530, Shobhit Kumar wrote:
In Haswell while disabling a pipe, we need to disable the DDI control as
well along with the PIPECONF. Otherwise we will hit assertions during crtc
disable
Hm, can you add such an
To be able to directly set up the intel-gtt code from drm/i915 and
avoid setting up the fake-agp driver we need to prepare a few things:
- pass both the bridge and gpu pci_dev to the probe function and add
code to handle the gpu pdev both being present (for drm/i915) and
not present (fake
On Fri, Jun 08, 2012 at 12:16:41PM +0300, Jani Nikula wrote:
Hi Daniel -
On Thu, 07 Jun 2012, Daniel Vetter daniel.vet...@ffwll.ch wrote:
I've done an audit of everything which is being set up between the
place where drm_pci_agp_init is called currently and where the
driver's -load
Within drm_fill_in_dev we call drm_lastclose to clean up the dirt in
case of failures. But the callers of drm_fill_in_dev simply don't do
anything. Now from a cursory look drm_lastclose doesn't look like the
best cleanup function in itself, but whom am I to judge the drm error
paths. Imo before we
Otherwise we'll nicely leak this reference counter. Now thanks to the
awesome layering in the drm core, the enable call is done by the pci
boilerplate in drm_pci.c. But the disable can't be done without adding
yet another neat indirection layer just for that.
So take the simple way and sprinkle
On Fri, Jun 08, 2012 at 06:03:57PM +0200, Jakob Bornecrantz wrote:
On Fri, Jun 8, 2012 at 4:52 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Otherwise we'll nicely leak this reference counter. Now thanks to the
awesome layering in the drm core, the enable call is done by the pci
Hi folks,
trying to get an old Fujitsu Siemens Laptop to work, I hacked up the
NS2501 support provided by Gilles
earlier. This patch provides simple DPMS support and includes some
experimental support for the undocumented
ns2501 scaler. I just copied the values the video bios left behind - and
There's the neat little problem that some systems die if vga decoding
isn't decoded anywhere, because linux disabled that pci device.
Atm we solve that problem by simple not calling pci_disable_device at
driver unregister time for drm pci devices. Which isn't to great
because it leaks a
On Thu, Jun 07, 2012 at 09:12:41AM -0700, Ben Widawsky wrote:
int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
This should bump the libdrm version. We're waiting for context support
so we can do both features in one bump.
v2: don't return remaining timeout amount
use get
On Fri, Jun 08, 2012 at 06:15:06PM +0200, Thomas Richter wrote:
Hi folks,
trying to get an old Fujitsu Siemens Laptop to work, I hacked up the
NS2501 support provided by Gilles
earlier. This patch provides simple DPMS support and includes some
experimental support for the undocumented
Somehow this went unnoticed in the past reviews, but the condition would
never timeout properly.
This was initially introduced in the v2 of original SBI enabling patch.
Highly embarrassing.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
Somehow this went unnoticed in the past reviews, but the condition would
never timeout properly.
This was initially introduced in the v2 of original SBI enabling patch.
Highly embarrassing.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
On Fri, Jun 08, 2012 at 04:43:19PM -0300, Eugeni Dodonov wrote:
Somehow this went unnoticed in the past reviews, but the condition would
never timeout properly.
This was initially introduced in the v2 of original SBI enabling patch.
Highly embarrassing.
Reported-by: Dan Carpenter
Hi folks,
trying to get an old Fujitsu Siemens Laptop to work, I hacked up the
NS2501 support provided by Gilles
earlier. This patch provides simple DPMS support and includes some
experimental support for the undocumented
ns2501 scaler. I just copied the values the video bios left behind - and
On Thu, May 31, 2012 at 01:08:53PM +0100, Chris Wilson wrote:
Whilst most monitors do wire up the HPD presence pin, it seems quite a
few KVM do not. Therefore if we simply rely on the HPD pin being
asserted to indicate a connected monitor we fail miserable, so fall back
to performing a DCC
On Sat, 9 Jun 2012 00:22:12 +0200, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, May 31, 2012 at 01:08:53PM +0100, Chris Wilson wrote:
Whilst most monitors do wire up the HPD presence pin, it seems quite a
few KVM do not. Therefore if we simply rely on the HPD pin being
asserted to indicate
Prevent possible uninitialized return value from intel_sbi_read call.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
21 matches
Mail list logo
