t it also allows CPU to go into higher turbo
modes as it has more watts to spend while GPU is idle, perhaps this is what
causes the issue here?
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists
t it also allows CPU to go into higher turbo
modes as it has more watts to spend while GPU is idle, perhaps this is what
causes the issue here?
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
h
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
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
ould also fix
https://bugs.freedesktop.org/show_bug.cgi?id=35648 and
https://bugs.freedesktop.org/show_bug.cgi?id=40241 as well.
--
Eugeni Dodonov
ould also fix
https://bugs.freedesktop.org/show_bug.cgi?id=35648 and
https://bugs.freedesktop.org/show_bug.cgi?id=40241 as well.
--
Eugeni Dodonov
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Mar 29, 2012 at 18:27, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Signed-off-by: Paulo Zanoni
>
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrub
+ break;
> + }
>
Perhaps we could add a debug message here for catch the unhandled types..
But apart from that,
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attac
o deal with object properties
> without knowing the real type of the object.
>
> Signed-off-by: Paulo Zanoni
>
>
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL:
<
return false;
>
Those two checks could probably be combined into one (< values || > values)
for further simplification.
But other than this,
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part
On Thu, Mar 29, 2012 at 18:28, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Signed-off-by: Paulo Zanoni
>
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrub
On Thu, Mar 29, 2012 at 18:28, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> New library calls:
> - drmModeObjectGetProperties
> - drmModeFreeObjectProperties
> - drmModeObjectSetProperties
>
> Signed-off-by: Paulo Zanoni
>
Reviewed-by: Eugeni Dodonov
not segfault in this case (by
> checking for the return value of drmModeGetProperty).
>
I think this could be done in a separate patch..
But besides those comments, this is:
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An
eck-amd64-linux.so)
> by 0x4E30DD8: drmMalloc (xf86drm.c:147)
> by 0x4E35024: drmAllocCpy (xf86drmMode.c:73)
> by 0x4E35D69: drmModeGetConnector (xf86drmMode.c:507)
> by 0x402F22: dump_connectors (modetest.c:181)
> by 0x40261B: main (modetest.c:801)
>
> Signed-off-by:
x27;fd' variable is global, we don't need to pass it as an argument:
> - modetest.c:698:40: warning: unused parameter ?fd? [-Wunused-parameter]
>
> We don't use the 'modeset' variable:
> - modetest.c:725:8: warning: variable ?modeset? set but not used
> [-
On Thu, Mar 29, 2012 at 18:27, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Signed-off-by: Paulo Zanoni
>
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
___
dri-devel mailing list
dri-devel@lists.fr
+ break;
> + }
>
Perhaps we could add a debug message here for catch the unhandled types..
But apart from that,
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
___
dri-devel mailing list
dri
o deal with object properties
> without knowing the real type of the object.
>
> Signed-off-by: Paulo Zanoni
>
>
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
___
dri-devel mailing li
return false;
>
Those two checks could probably be combined into one (< values || > values)
for further simplification.
But other than this,
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
___
On Thu, Mar 29, 2012 at 18:28, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Signed-off-by: Paulo Zanoni
>
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
___
dri-devel mailing list
dri-devel@lists.fr
On Thu, Mar 29, 2012 at 18:28, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> New library calls:
> - drmModeObjectGetProperties
> - drmModeFreeObjectProperties
> - drmModeObjectSetProperties
>
> Signed-off-by: Paulo Zanoni
>
Reviewed-by: Eugeni Dodonov
not segfault in this case (by
> checking for the return value of drmModeGetProperty).
>
I think this could be done in a separate patch..
But besides those comments, this is:
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
__
eck-amd64-linux.so)
> by 0x4E30DD8: drmMalloc (xf86drm.c:147)
> by 0x4E35024: drmAllocCpy (xf86drmMode.c:73)
> by 0x4E35D69: drmModeGetConnector (xf86drmMode.c:507)
> by 0x402F22: dump_connectors (modetest.c:181)
> by 0x40261B: main (modetest.c:801)
>
> Signed-off-by:
x27;fd' variable is global, we don't need to pass it as an argument:
> - modetest.c:698:40: warning: unused parameter ‘fd’ [-Wunused-parameter]
>
> We don't use the 'modeset' variable:
> - modetest.c:725:8: warning: variable ‘modeset’ set but not used
> [-
please report it into our bugzilla, attaching the files and
information mentioned at
http://intellinuxgraphics.org/how_to_report_bug.html please?
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
please report it into our bugzilla, attaching the files and
information mentioned at
http://intellinuxgraphics.org/how_to_report_bug.html please?
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120306/a2e51e15/attachment.htm>
rted by the bit-banging together with
> what gmbus can do, so that this doesn't randomly change any more.
>
> v2: Chris Wilson noticed that I've mixed up && and & ...
>
> v3: Clarify an if block as suggested by Eugeni Dodonov.
>
> Signed-Off-by: Daniel
On Tue, Feb 14, 2012 at 19:37, Daniel Vetter wrote:
> This way we can free up the bus->adaptor.algo_data pointer and make it
> available for use with the bitbanging fallback algo.
>
> Signed-Off-by: Daniel Vetter
>
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http
On Mon, Feb 27, 2012 at 13:09, Jesse Barnes wrote:
> On Thu, 23 Feb 2012 21:19:20 +0100
> Torsten Kaiser wrote:
>
> > On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie wrote:
> > > Eugeni Dodonov (4):
> > > drm/i915: gen7: implement rczunit workaround
> >
rted by the bit-banging together with
> what gmbus can do, so that this doesn't randomly change any more.
>
> v2: Chris Wilson noticed that I've mixed up && and & ...
>
> v3: Clarify an if block as suggested by Eugeni Dodonov.
>
> Signed-Off-by: Daniel
On Tue, Feb 14, 2012 at 19:37, Daniel Vetter wrote:
> This way we can free up the bus->adaptor.algo_data pointer and make it
> available for use with the bitbanging fallback algo.
>
> Signed-Off-by: Daniel Vetter
>
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http
On Mon, Feb 27, 2012 at 13:09, Jesse Barnes wrote:
> On Thu, 23 Feb 2012 21:19:20 +0100
> Torsten Kaiser wrote:
>
> > On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie wrote:
> > > Eugeni Dodonov (4):
> > > drm/i915: gen7: implement rczunit workaround
> >
On 02/23/2012 06:15 PM, Linus Torvalds wrote:
On Thu, Feb 23, 2012 at 11:52 AM, Chris Wilson wrote:
i2c retries if sees an EGAIN, drm_do_probe_ddc_edid retries until it
gets a result and *then* drm_do_get_edid retries until it gets a result
it is happy with. All in all, that is a lot of proces
As noticed by Torsten Kaiser, the operator precedence can play tricks with
us here.
CC: Dave Airlie
CC: Jesse Barnes
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915
On 02/23/2012 06:15 PM, Linus Torvalds wrote:
> On Thu, Feb 23, 2012 at 11:52 AM, Chris Wilson
> wrote:
>>
>> i2c retries if sees an EGAIN, drm_do_probe_ddc_edid retries until it
>> gets a result and *then* drm_do_get_edid retries until it gets a result
>> it is happy with. All in all, that is a
As noticed by Torsten Kaiser, the operator precedence can play tricks with
us here.
CC: Dave Airlie
CC: Jesse Barnes
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915
}
>
Wouldn't it be cleaner and more consistent with the rest of the code to use:
if (!bus->has_gpio)
ret = -EIO;
else {
bus->force_bit = true;
ret = intel_i2c_quirk_xfer(bus, msgs, num);
}
instead?
Other than that, it looks correct to me, and certainly makes
}
>
Wouldn't it be cleaner and more consistent with the rest of the code to use:
if (!bus->has_gpio)
ret = -EIO;
else {
bus->force_bit = true;
ret = intel_i2c_quirk_xfer(bus, msgs, num);
}
instead?
Other than that, it looks correct to me, and certainly makes
ding a mutex lock when calling
> gmbus_xfer().
>
> Signed-off-by: Yufeng Shen
>
Looks correct to me. Thanks!
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://li
ding a mutex lock when calling
> gmbus_xfer().
>
> Signed-off-by: Yufeng Shen
>
Looks correct to me. Thanks!
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
___
dri-devel mailing list
d
> Signed-off-by: Jesse Barnes
>
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120209/2f44d3fc/attachment.htm>
> Signed-off-by: Jesse Barnes
>
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Looks like a CC to dri-devel got forgotten originally, so forwarding it
properly.
-- Forwarded message --
From: Eugeni Dodonov
Date: Thu, Jan 5, 2012 at 09:34
Subject: [Intel-gfx] [PATCH 1/2] drm: give up on edid retries when i2c bus
is not responding
To: intel-gfx at
Looks like a CC to dri-devel got forgotten originally, so forwarding it
properly.
-- Forwarded message --
From: Eugeni Dodonov
Date: Thu, Jan 5, 2012 at 09:34
Subject: [Intel-gfx] [PATCH 1/2] drm: give up on edid retries when i2c bus
is not responding
To: intel
;
> >> /me would like to kill this cruft
>
> All sounds good to me, kill it with fire. I've never known this code
> to be used in anything.
>
I think we can kill it, it does not seems to be used by anything.
Just to be sure - Eric, you was the last one to touch it, do y
;
> >> /me would like to kill this cruft
>
> All sounds good to me, kill it with fire. I've never known this code
> to be used in anything.
>
I think we can kill it, it does not seems to be used by anything.
Just to be sure - Eric, you was the last one to touch it
you running stable kernels
who want to test the latest breakages^w features :).
[1] http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/7961
--
Eugeni Dodonov
you running stable kernels
who want to test the latest breakages^w features :).
[1] http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/7961
--
Eugeni Dodonov
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
l suggests, that would
> be great. In any case, I'll post a revert of the semaphore enable patch
> as it looks like that's still not working right...
>
Could we revert it for SNB, and leave it enabled for IVB?
It would be just the chunk which checks for intel_iommu
l suggests, that would
> be great. In any case, I'll post a revert of the semaphore enable patch
> as it looks like that's still not working right...
>
Could we revert it for SNB, and leave it enabled for IVB?
It would be just the chunk which checks for intel_iommu
Those are needed by the rc6 and semaphores support in i915 driver.
In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
is enabled. So we use those variables to check the io remapping and iommu
status.
CC: Keith Packard
CC: Daniel Vetter
Signed-off-by: Eugeni Dodonov
Those are needed by the rc6 and semaphores support in i915 driver.
In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
is enabled. So we use those variables to check the io remapping and iommu
status.
CC: Keith Packard
CC: Daniel Vetter
Signed-off-by: Eugeni Dodonov
On Tue, Nov 22, 2011 at 18:15, Matthew Garrett wrote:
> On Fri, Nov 18, 2011 at 10:41:29PM -0800, Keith Packard wrote:
>
> > + /*
> > + * Only enable RC6 if all dma remapping is disabled, or if
> > + * there's no iommu present in the machine.
> > + */
> > + if (INTEL_INFO(d
ndom gpu hangs and
crashes when both are enabled :(.
When the root cause will be discovered, we should allow both of course. But
so far, all the attempts on this weren't successful.
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
__
On Sat, Nov 19, 2011 at 16:32, Keith Packard wrote:
> On Sat, 19 Nov 2011 07:25:09 -0200, Eugeni Dodonov
> wrote:
>
>> Just one question I caught on 2nd read. Shouldn't we have #else within
>> this #ifdef block, to return 1? Otherwise, if CONFIG_INTEL_IOMMU is
&g
On Sat, Nov 19, 2011 at 16:32, Keith Packard wrote:
> On Sat, 19 Nov 2011 07:25:09 -0200, Eugeni Dodonov wrote:
>
>> Just one question I caught on 2nd read. Shouldn't we have #else within
>> this #ifdef block, to return 1? Otherwise, if CONFIG_INTEL_IOMMU is
>> not
; +#endif
> + ? ? ? return 0;
> +}
Just one question I caught on 2nd read. Shouldn't we have #else within
this #ifdef block, to return 1? Otherwise, if CONFIG_INTEL_IOMMU is
not defined, we'll always disable rc6.
Or we just always intend to disable rc6 in case CONFIG_INTEL_IOMMU is not there?
--
Eugeni Dodonov
ied behavior.
>
> Signed-off-by: Keith Packard
>
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2019/b674cf3e/attachment.html>
; +#endif
> + return 0;
> +}
Just one question I caught on 2nd read. Shouldn't we have #else within
this #ifdef block, to return 1? Otherwise, if CONFIG_INTEL_IOMMU is
not defined, we'll always disable rc6.
Or we just always int
ied behavior.
>
> Signed-off-by: Keith Packard
>
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
27; command:
Machine 4: from 3.210s to 1.060s
Reviewed-by: Chris Wilson
Reviewed-by: Keith Packard
Tested-by: Sean Finney
Tested-by: Soren Hansen
Tested-by: Hernando Torque
Tested-by: Mike Lothian
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059
Signed-off-by: Eugeni Dodonov
So as we all agree on this patch now, I updated it with all the Tested-by and
Reviewed-by.
Dave, I think it is good for pulling into -next now.
Thanks!
27; command:
Machine 4: from 3.210s to 1.060s
Reviewed-by: Chris Wilson
Reviewed-by: Keith Packard
Tested-by: Sean Finney
Tested-by: Soren Hansen
Tested-by: Hernando Torque
Tested-by: Mike Lothian
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059
Signed-off-by: Eugeni Dodonov
So as we all agree on this patch now, I updated it with all the Tested-by and
Reviewed-by.
Dave, I think it is good for pulling into -next now.
Thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listi
th Packard
> Cc: Ben Widawsky
>
Reviewed-By: Eugeni Dodonov
We have no need for the workaround when we don't have IOMMU.
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freed
th Packard
> Cc: Ben Widawsky
>
Reviewed-By: Eugeni Dodonov
We have no need for the workaround when we don't have IOMMU.
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://
3.210s to 1.060s
v2: added a module parameter to control this behavior. The idea came from
discussion with Jean Delvare.
v3: added external tested-by's and timing results.
v4: changed module parameter to bool, added default value description
Signed-off-by: Eugeni Dodonov
Reviewed-By: Chri
3.210s to 1.060s
v2: added a module parameter to control this behavior. The idea came from
discussion with Jean Delvare.
v3: added external tested-by's and timing results.
Signed-off-by: Eugeni Dodonov
Tested-By: Sean Finney
Tested-By: Soren Hansen
Tested-By: Hernando Torque
---
drivers/
3.210s to 1.060s
v2: added a module parameter to control this behavior. The idea came from
discussion with Jean Delvare.
v3: added external tested-by's and timing results.
v4: changed module parameter to bool, added default value description
Signed-off-by: Eugeni Dodonov
Reviewed-By: Chri
3.210s to 1.060s
v2: added a module parameter to control this behavior. The idea came from
discussion with Jean Delvare.
v3: added external tested-by's and timing results.
Signed-off-by: Eugeni Dodonov
Tested-By: Sean Finney
Tested-By: Soren Hansen
Tested-By: Hernando Torque
---
drivers/
larger margin
in case of phantom outputs.
v2: added a module parameter to control this behavior. The idea came from
discussion with Jean Delvare.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/drm_edid.c |5 +
drivers/gpu/drm/drm_stub.c |5 +
include/drm/drmP.h |2
larger margin
in case of phantom outputs.
v2: added a module parameter to control this behavior. The idea came from
discussion with Jean Delvare.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/drm_edid.c |5 +
drivers/gpu/drm/drm_stub.c |5 +
include/drm/drmP.h |2
h.
In any case - looking at a faster way to leave the drm_do_probe_ddc_edid,
while also allowing a way for having a more detailed probing - would it be
an acceptable solution to add a:
MODULE_PARM(skip_unresponsive_edid, "Ignore outputs which do not provide
edid on first attempt");
for bit-
> > banged I2C. That's exactly what my patch is doing.
>
> Seems fine to me then. I don't know why we set it so low to begin
> with, but I'm certainly not an i2c expert.
>
Seems fine for me as well.
Acked-by: Eugeni Dodonov
--
Eugeni D
h.
In any case - looking at a faster way to leave the drm_do_probe_ddc_edid,
while also allowing a way for having a more detailed probing - would it be
an acceptable solution to add a:
MODULE_PARM(skip_unresponsive_edid, "Ignore outputs which do not provide
edid on first attempt");
for bit-
> > banged I2C. That's exactly what my patch is doing.
>
> Seems fine to me then. I don't know why we set it so low to begin
> with, but I'm certainly not an i2c expert.
>
Seems fine for me as well.
Acked-by: Eugeni Dodonov
--
Eugeni Dodonov
<http:
g spurious NAKs by a chance?
> One thing which may make sense would be to make the retry count a
> module parameter, instead of a hard-coded value, so that users can
> lower the value if they care more about boot time than reliability. But
> again, ideally problematic buses would not have been created in the
> first place.
Or perhaps it would be possible to have any error code coming from
i2c_transfer to signal a permanent error, which should not be retried..
what do you think?
--
Eugeni Dodonov
g spurious NAKs by a chance?
> One thing which may make sense would be to make the retry count a
> module parameter, instead of a hard-coded value, so that users can
> lower the value if they care more about boot time than reliability. But
> again, i
On Mon, Oct 17, 2011 at 20:41, Keith Packard wrote:
> On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov
> wrote:
>
> > From what I've checked, the other return error value in this context
> could
> > be -EREMOTEIO, which could be caused by transmission error
On Mon, Oct 17, 2011 at 18:41, Keith Packard wrote:
> On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov <
> eugeni.dodonov at intel.com> wrote:
>
> > + if (ret == -ENXIO) {
> > + DRM_DEBUG_KMS("drm: skip
On Mon, Oct 17, 2011 at 20:41, Keith Packard wrote:
> On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov
> wrote:
>
> > From what I've checked, the other return error value in this context
> could
> > be -EREMOTEIO, which could be caused by transmission error
On Mon, Oct 17, 2011 at 18:41, Keith Packard wrote:
> On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov <
> eugeni.dodo...@intel.com> wrote:
>
> > + if (ret == -ENXIO) {
> > + DRM_DEBUG_KMS("drm: skip
intel_ddc_probe, whose functionality is now done by
intel_drm_get_valid_edid.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_crt.c | 46 ++--
drivers/gpu/drm/i915/intel_dp.c|4 +-
drivers/gpu/drm/i915/intel_drv.h |3 +-
drivers/gpu/drm
.
This change should fix
https://bugs.freedesktop.org/show_bug.cgi?id=41059 and improve overall
edid detection timing by 10-30% in most cases, and by a much larger margin
in case of phantom outputs.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/drm_edid.c |5 +
1 files changed, 5
s the
existent functionality with no additional benefits.
Could we have any feedback or reviewed-by or from non-intel drm maintainers?
Thanks!
Eugeni Dodonov (2):
Give up on edid retries when i2c tells us that bus is not there
Check if the bus is valid prior to discovering edid.
drivers/gp
intel_ddc_probe, whose functionality is now done by
intel_drm_get_valid_edid.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_crt.c | 46 ++--
drivers/gpu/drm/i915/intel_dp.c|4 +-
drivers/gpu/drm/i915/intel_drv.h |3 +-
drivers/gpu/drm
.
This change should fix
https://bugs.freedesktop.org/show_bug.cgi?id=41059 and improve overall
edid detection timing by 10-30% in most cases, and by a much larger margin
in case of phantom outputs.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/drm_edid.c |5 +
1 files changed, 5
s the
existent functionality with no additional benefits.
Could we have any feedback or reviewed-by or from non-intel drm maintainers?
Thanks!
Eugeni Dodonov (2):
Give up on edid retries when i2c tells us that bus is not there
Check if the bus is valid prior to discovering edid.
drivers/gp
e cards which use drm. But
until I find some non-intel cards to test it (or someone with such cards
volunteers to do such testing), I am a bit sceptical about having it merged.
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment
e cards which use drm. But
until I find some non-intel cards to test it (or someone with such cards
volunteers to do such testing), I am a bit sceptical about having it merged.
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
___
dri-d
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_dp.c|4 ++--
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_hdmi.c |4 ++--
drivers/gpu/drm/i915/intel_i2c.c | 33 +
drivers/gpu/drm/i915/intel_lvds.c |2
: Eugeni Dodonov
---
drivers/gpu/drm/drm_edid.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7425e5c..5ed34f2 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -265,6 +265,11
5 patch: 280ms
(manually ignoring phantom outputs)
ubuntu 3.0.0-12.19: 175ms
3.0.0-12.19 + drm patch: 140ms
3.0.0-12.19 + i915 patch: 140ms
Eugeni Dodonov (2):
Give up on edid retries when i2c tells us that bus is not there
Check if the bus is valid prior to discovering edid.
d
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_dp.c|4 ++--
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_hdmi.c |4 ++--
drivers/gpu/drm/i915/intel_i2c.c | 33 +
drivers/gpu/drm/i915/intel_lvds.c |2
: Eugeni Dodonov
---
drivers/gpu/drm/drm_edid.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7425e5c..5ed34f2 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -265,6 +265,11
5 patch: 280ms
(manually ignoring phantom outputs)
ubuntu 3.0.0-12.19: 175ms
3.0.0-12.19 + drm patch: 140ms
3.0.0-12.19 + i915 patch: 140ms
Eugeni Dodonov (2):
Give up on edid retries when i2c tells us that bus is not there
Check if the bus is valid prior to discovering edid.
d
t; pretty darn good time; drm-intel-fixes and drm-intel-next are in-sync as
> I haven't started pulling 3.2 code into -next.
>
I think that if we don?t get to push this patch now, we are unlikely to do
it in nearby future. And such kind of cleanup is a nice thing to have.
So I?d vote f
t; pretty darn good time; drm-intel-fixes and drm-intel-next are in-sync as
> I haven't started pulling 3.2 code into -next.
>
I think that if we don´t get to push this patch now, we are unlikely to do
it in nearby future. And such kind of cleanup is a nice thing to have.
So I´d vote for
98 matches
Mail list logo
