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.free
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
http://lists.freedesktop.org/mailman
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 dan.carpen...@oracle.com
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
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
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
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 HTML attachment was
md64-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: Paulo
'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
> [-Wunused-but-set-variable]
>
?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
).
--
Eugeni Dodonov
http://eugeni.dodonov.net/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
not segfault in this case (by
checking for the return value of drmModeGetProperty).
another-bikeshedding
I think this could be done in a separate patch..
/another-bikeshedding
But besides those comments, this is:
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
--
Eugeni Dodonov
http
-by: Eugeni Dodonov eugeni.dodo...@intel.com
--
Eugeni Dodonov
http://eugeni.dodonov.net/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Mar 29, 2012 at 18:28, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
--
Eugeni Dodonov
http://eugeni.dodonov.net
, we will be able to deal with object properties
without knowing the real type of the object.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
--
Eugeni Dodonov
http://eugeni.dodonov.net/
___
dri
);
+ break;
+ }
bikeshedding
Perhaps we could add a debug message here for catch the unhandled types..
/bikeshedding
But apart from that,
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
--
Eugeni Dodonov
http://eugeni.dodonov.net/
___
dri
On Thu, Mar 29, 2012 at 18:27, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
--
Eugeni Dodonov
http://eugeni.dodonov.net
e 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>
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
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 Vetter
>
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 Mon, Feb 27, 2012 at 13:09, Jesse Barnes jbar...@virtuousgeek.orgwrote:
On Thu, 23 Feb 2012 21:19:20 +0100
Torsten Kaiser just.for.l...@googlemail.com wrote:
On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie airl...@linux.ie wrote:
Eugeni Dodonov (4):
drm/i915: gen7: implement
On Tue, Feb 14, 2012 at 19:37, Daniel Vetter daniel.vet...@ffwll.ch 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 daniel.vet...@ffwll.ch
Reviewed-by: Eugeni Dodonov eugeni.dodo
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 Vetter daniel.vet...@ffwll.ch
Reviewed-by: Eugeni Dodonov
On 02/23/2012 06:15 PM, Linus Torvalds wrote:
On Thu, Feb 23, 2012 at 11:52 AM, Chris Wilsonch...@chris-wilson.co.uk 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
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
; + }
>
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 code
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?
/bikeshedding
Other than that, it looks correct to me, and certainly makes code more
clean.
Reviewed-by: Eugeni Dodonov
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://lists.f
this by adding a mutex lock when calling
gmbus_xfer().
Signed-off-by: Yufeng Shen mile...@chromium.org
Looks correct to me. Thanks!
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
--
Eugeni Dodonov
http://eugeni.dodonov.net/
___
dri-devel mailing list
dri
t;
> 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 jbar...@virtuousgeek.org
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
--
Eugeni Dodonov
http://eugeni.dodonov.net/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman
Looks like a CC to dri-devel got forgotten originally, so forwarding it
properly.
-- Forwarded message --
From: Eugeni Dodonov <eugeni.dodo...@intel.com>
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 resp
Looks like a CC to dri-devel got forgotten originally, so forwarding it
properly.
-- Forwarded message --
From: Eugeni Dodonov eugeni.dodo...@intel.com
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
;
> >> /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 you th
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 you think we
may still have any need for it, or we can let it go?
--
Eugeni Dodonov
http://eugeni.dodonov.net/
___
dri-devel mailing
ng 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
:).
[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
Daniel 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 status in
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 status in the patch.
--
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
...@ffwll.ch
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
arch/x86/kernel/pci-dma.c |1 +
drivers/iommu/intel-iommu.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index 80dc793..4c9191e 100644
--- a/arch
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
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/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org
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
>>
On Sat, Nov 19, 2011 at 16:32, Keith Packard kei...@keithp.com wrote:
On Sat, 19 Nov 2011 07:25:09 -0200, Eugeni Dodonov eug...@dodonov.net 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
ndif
> + ? ? ? 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>
behavior.
Signed-off-by: Keith Packard kei...@keithp.com
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
--
Eugeni Dodonov
http://eugeni.dodonov.net/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman
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
___
dri
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
---
drivers/gpu/drm
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!
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
...@fireburn.co.uk
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
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
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.freedeskto
kei...@keithp.com
Cc: Ben Widawsky b...@bwidawsk.net
Reviewed-By: Eugeni Dodonov eugeni.dodo...@intel.com
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
: 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: Chris Wilson
Tested-By: Sean
: 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/gpu/drm/drm_edid.c |5
: 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 eugeni.dodo...@intel.com
Tested-By: Sean Finney sean...@seanius.net
Tested-By: Soren Hansen so...@linux2go.dk
Tested
: 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 eugeni.dodo...@intel.com
Reviewed-By: Chris
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 eugeni.dodo...@intel.com
---
drivers/gpu/drm/drm_edid.c |5 +
drivers/gpu/drm/drm_stub.c |5 +
include/drm
d,
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");
and update the patch to use this option?
--
Eugeni Dodonov
<http://eug
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://eu
.
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.dodo...@intel.com
--
Eugeni Dodonov
http://eugeni.dodonov.net/
___
dri-devel
not provide
edid on first attempt);
and update the patch to use this option?
--
Eugeni Dodonov
http://eugeni.dodonov.net/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
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 so it
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
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
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/gpu/drm
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/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 eugeni.dodo...@intel.com
---
drivers/gpu/drm/drm_edid.c |5 +
1
intel_ddc_probe, whose functionality is now done by
intel_drm_get_valid_edid.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_crt.c | 46 ++--
drivers/gpu/drm/i915/intel_dp.c|4 +-
drivers/gpu/drm/i915/intel_drv.h
On Mon, Oct 17, 2011 at 18:41, Keith Packard kei...@keithp.com wrote:
On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov
eugeni.dodo...@intel.com wrote:
+ if (ret == -ENXIO) {
+ DRM_DEBUG_KMS(drm: skipping non-existent adapter
%s\n
On Mon, Oct 17, 2011 at 20:41, Keith Packard kei...@keithp.com wrote:
On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov eug...@dodonov.net
wrote:
From what I've checked, the other return error value in this context
could
be -EREMOTEIO, which could be caused by transmission error so
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
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-devel mailing list
dri-devel
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
-by: 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
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.
drivers/gpu/drm/drm_edid.c
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.
drivers/gpu/drm/drm_edid.c
-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
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
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
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
-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 option 1, and then 3, in this order.
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 option 1, and then 3, in this order.
--
Eugeni Dodonov
http://eugeni.dodonov.net/
___
dri-devel mailing list
dri-devel
95 matches
Mail list logo
