Prevent possible uninitialized return value from intel_sbi_read call.
Signed-off-by: Eugeni Dodonov
---
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
b/drivers/gpu/drm/i915/intel_display.c
index c
On Sat, 9 Jun 2012 00:22:12 +0200, Daniel Vetter 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 a connect
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
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 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
>
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
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |8
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
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |8
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
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
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 pci_enable
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 Fri, Jun 08, 2012 at 06:03:57PM +0200, Jakob Bornecrantz wrote:
> On Fri, Jun 8, 2012 at 4:52 PM, Daniel Vetter 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
> > boilerplate in drm_pci.c.
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 pc
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
On Fri, Jun 08, 2012 at 12:16:41PM +0300, Jani Nikula wrote:
>
> Hi Daniel -
>
> On Thu, 07 Jun 2012, Daniel Vetter 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 cal
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 agp).
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 exampl
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
a
On Fri, Jun 08, 2012 at 01:09:10PM +0300, Jani Nikula wrote:
> On Thu, 07 Jun 2012, Daniel Vetter wrote:
> > #define INTEL_GTT_GEN intel_private.driver->gen
> > @@ -1522,14 +1523,32 @@ static int find_gmch(u16 device)
> > return 1;
> > }
> >
> > -int intel_gmch_probe(struct pci_dev *p
On Thu, 07 Jun 2012, Daniel Vetter 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 gpu pdev both being p
Hi Daniel -
On Thu, 07 Jun 2012, Daniel Vetter 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 correctly.
>
> Th
21 matches
Mail list logo
