All three patches are:
Reviewed-by: Simon Farnsworth
I'd consider making the upper limit of AUX_RETRY_INTERVAL a define as well, but
that's just nit-picking and not worth respinning the patches.
Simon
On Wednesday 26 Aug 2015 22:55:07 ville.syrjala at linux.intel.com wrote:
>
ice does a short HPD when
it sees the DVI-D HPD sense change.
Simon
On Tuesday 10 February 2015 18:38:08 Simon Farnsworth wrote:
> Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
> in their I2C over AUX implementation (fixed in newer revisions). They work
> fin
back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks
S
On Friday 30 January 2015 20:45:28 Ville Syrjälä wrote:
> On Tue, Jan 27, 2015 at 03:43:49PM +0000, Simon Farnsworth wrote:
> > DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs in
> > their I2C over AUX implementation. They work fine with Windows, but fail
On Thursday 29 January 2015 16:36:55 Ville Syrjälä wrote:
> On Thu, Jan 29, 2015 at 02:24:09PM +0000, Simon Farnsworth wrote:
> > On Thursday 29 January 2015 15:30:36 you wrote:
> > > On Tue, Jan 27, 2015 at 03:43:49PM +, Simon Farnsworth wrote:
--snip--
> > &
On Thursday 29 January 2015 15:30:36 you wrote:
> On Tue, Jan 27, 2015 at 03:43:49PM +0000, Simon Farnsworth wrote:
--snip--
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 79968e3..3db116c 100644
> > --- a/drivers/gpu/dr
s trivial. That would taint the kernel if
you play with it, hopefully making it clear that this is not permanent ABI.
I'm now seeing the Bizlink adapters fail after about 45 seconds of
isochronous link up, so it'll be a few days before I do a v4 of this patch,
as I need Datapath'
t it'll be closest to what Windows does, as no sink I've
found actually gives short replies.
Also provide a module parameter for testing smaller transfer sizes, in case
there are sinks out there that cannot work with Windows.
Signed-off-by: Simon Farnsworth
---
v3 changes, after feedback
On Monday 26 January 2015 18:11:01 Ville Syrjälä wrote:
> On Mon, Jan 26, 2015 at 03:47:13PM +0000, Simon Farnsworth wrote:
> > On Monday 26 January 2015 17:33:35 Ville Syrjälä wrote:
> > > On Mon, Jan 26, 2015 at 03:22:48PM +, Simon Farnsworth wrote:
> > > >
On Monday 26 January 2015 17:33:35 Ville Syrjälä wrote:
> On Mon, Jan 26, 2015 at 03:22:48PM +0000, Simon Farnsworth wrote:
> > DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs in
> > their I2C over AUX implementation. They work fine with Windows, but fail
zero
byte transfer ending the I2C transaction.
Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match.
Signed-off-by: Simon Farnsworth
---
v2 changes, after feedback from Thierry
On Friday 23 January 2015 22:21:09 Thierry Reding wrote:
> On Fri, Jan 23, 2015 at 09:46:29PM +0200, Ville Syrjälä wrote:
> > On Fri, Jan 23, 2015 at 06:40:38PM +0000, Simon Farnsworth wrote:
> > > DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs in
> &
zero
byte transfer ending the I2C transaction.
Copy Windows's behaviour, and read 16 bytes at a time. Analysis of the
failure state was provided by Datapath Ltd.
Signed-off-by: Simon Farnsworth
---
Thierry,
You put in the comment about "decreased performance", back in December
Extend the parsing of the xrandr EDID property block to read extension
blocks, not just the basic block.
Signed-off-by: Simon Farnsworth
---
edid-decode.c | 45 -
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/edid-decode.c b/edid
gt;
> 004c
>
> - vendor Id: 0x000c03 (HDMI)
> - video format: 0x001
> - HDMI VIC: 3
>
> after a $ xrandr --output HDMI1 --mode 3840x2160 -r 24
>
>
With the ty
> + err = hdmi_hdmi_infoframe_init(frame);
> + if (err < 0)
> + return err;
> +
> + frame->vic = vic;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_hdmi_vendor_infoframe_from_display_mode);
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http
if (mode_idx < ARRAY_SIZE(edid_4k_modes)) {
> + cea_mode = &edid_4k_modes[mode_idx];
> + clock2 = hdmi_mode_alternate_clock(cea_mode);
> + }
> + }
>
> - cea_mode = &edid_cea
continue;
> + }
> +
> + newmode = drm_mode_duplicate(dev, &edid_4k_modes[vic]);
> + if (!newmode)
> + continue;
> +
> + drm_mode_probed_add(connector, newmode);
> + modes++;
> + }
> +
&g
if (mode_idx < ARRAY_SIZE(edid_4k_modes)) {
> + cea_mode = &edid_4k_modes[mode_idx];
> + clock2 = hdmi_mode_alternate_clock(cea_mode);
> + }
> + }
>
> - cea_mode = &edid_ce
continue;
> + }
> +
> + newmode = drm_mode_duplicate(dev, &edid_4k_modes[vic]);
> + if (!newmode)
> + continue;
> +
> + drm_mode_probed_add(connector, newmode);
> + modes++;
> + }
> +
> +o
gt;
> 004c
>
> - vendor Id: 0x000c03 (HDMI)
> - video format: 0x001
> - HDMI VIC: 3
>
> after a $ xrandr --output HDMI1 --mode 3840x2160 -r 24
>
>
With the ty
> + err = hdmi_hdmi_infoframe_init(frame);
> + if (err < 0)
> + return err;
> +
> + frame->vic = vic;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_hdmi_vendor_infoframe_from_display_mode);
--
Simon Farnsworth
Software Engineer
ONEL
Signed-off-by: Simon Farnsworth
---
This code needs quite a bit of rework, but this removes a pain point on
motherboards with LVDS or eDP provided as an option that we're not using,
and wired so that they appear to be connected.
Without this patch, we can force the unused connector off, bu
Signed-off-by: Simon Farnsworth
---
This code needs quite a bit of rework, but this removes a pain point on
motherboards with LVDS or eDP provided as an option that we're not using,
and wired so that they appear to be connected.
Without this patch, we can force the unused connector off, bu
On Friday 3 February 2012, Dave Airlie wrote:
> On Fri, Feb 3, 2012 at 4:30 PM, Simon Farnsworth
> wrote:
> > As I've got the fix I need (Mesa-dev message "[PATCH] r600g: Use a fake
> > reloc to sleep for fences"), I can't really justify continuing to wor
ded to let you
wait for a kernel fence. I'm thus sending it out as a starting point in case
someone else wants to continue digging into this.
Signed-off-by: Simon Farnsworth
---
Note the FIXME - how does the CS ioctl indicate a fence failure?
I'm also a little concerned that my general
From: Christian K?nig
To support waiting for fence values from usermode.
Signed-off-by: Christian K?nig
---
Again, unchanged from Christian's original work
drivers/gpu/drm/radeon/radeon_fence.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/driv
From: Christian K?nig
They are protected by a read/write lock anyway, so
we actually don't need to use the atomic type.
Signed-off-by: Christian K?nig
---
Unchanged from Christian's original work.
drivers/gpu/drm/radeon/radeon.h |6 +++---
drivers/gpu/drm/radeon/radeon_fence.c | 2
se a fake
reloc to sleep for fences"), I can't really justify continuing to work on
this, so I'm putting out what I've got, complete with known problems, in
case someone else gets interested.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
On Friday 3 February 2012, Dave Airlie wrote:
> On Fri, Feb 3, 2012 at 4:30 PM, Simon Farnsworth
> wrote:
> > As I've got the fix I need (Mesa-dev message "[PATCH] r600g: Use a fake
> > reloc to sleep for fences"), I can't really justify continuing to wor
ded to let you
wait for a kernel fence. I'm thus sending it out as a starting point in case
someone else wants to continue digging into this.
Signed-off-by: Simon Farnsworth
---
Note the FIXME - how does the CS ioctl indicate a fence failure?
I'm also a little concerned that my general
From: Christian König
To support waiting for fence values from usermode.
Signed-off-by: Christian König
---
Again, unchanged from Christian's original work
drivers/gpu/drm/radeon/radeon_fence.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/driv
From: Christian König
They are protected by a read/write lock anyway, so
we actually don't need to use the atomic type.
Signed-off-by: Christian König
---
Unchanged from Christian's original work.
drivers/gpu/drm/radeon/radeon.h |6 +++---
drivers/gpu/drm/radeon/radeon_fence.c | 2
se a fake
reloc to sleep for fences"), I can't really justify continuing to work on
this, so I'm putting out what I've got, complete with known problems, in
case someone else gets interested.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
__
On Wednesday 1 February 2012, Simon Farnsworth wrote:
> This is a userspace only fix for my problem, as suggested by Mark Ol??k. It
My apologies, Marek; my typing appears to have failed me, and renamed you to
Mark. I shall try not to make that mistake again.
--
Simon Farnsworth
Softw
busywaiting if the user provided a timeout.
Signed-off-by: Simon Farnsworth
---
This is a userspace only fix for my problem, as suggested by Mark Ol??k. It
doesn't fix the case with a timeout (which doesn't matter to me), but works
on existing kernels.
Given that my previous suggested fix op
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can wait for an EOP interrupt that
corresponds to a previous EVENT_WRITE_EOP.
Signed-off-by: Simon Farnsworth
---
There's debate on
Instead of busywaiting for the GPU to finish a fence, use the new kernel
interface to wait for fence completion.
If the new kernel interface is unavailable, fall back to busywaiting.
Signed-off-by: Simon Farnsworth
---
This is simply addressing Michel's review comments against the v1
ave changed.
> > > + */
> > > +struct drm_radeon_gem_wait_user_fence {
> > > + uint32_thandle;
> > > + uint32_tring;
> > > + uint64_toffset;
> > > + uint32_tvalue;
> > > + u
On Wednesday 1 February 2012, Simon Farnsworth
wrote:
> This is a userspace only fix for my problem, as suggested by Mark Olšák. It
My apologies, Marek; my typing appears to have failed me, and renamed you to
Mark. I shall try not to make that mistake again.
--
Simon Farnsworth
Softw
busywaiting if the user provided a timeout.
Signed-off-by: Simon Farnsworth
---
This is a userspace only fix for my problem, as suggested by Mark Olšák. It
doesn't fix the case with a timeout (which doesn't matter to me), but works
on existing kernels.
Given that my previous suggested fix op
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can wait for an EOP interrupt that
corresponds to a previous EVENT_WRITE_EOP.
Signed-off-by: Simon Farnsworth
---
There's debate on
Instead of busywaiting for the GPU to finish a fence, use the new kernel
interface to wait for fence completion.
If the new kernel interface is unavailable, fall back to busywaiting.
Signed-off-by: Simon Farnsworth
---
This is simply addressing Michel's review comments against the v1
ave changed.
> > > + */
> > > +struct drm_radeon_gem_wait_user_fence {
> > > + uint32_thandle;
> > > + uint32_tring;
> > > + uint64_toffset;
> > > + uint32_tvalue;
> >
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can wait for an EOP interrupt that
corresponds to a previous EVENT_WRITE_EOP.
Signed-off-by: Simon Farnsworth
---
I've been worki
On Tuesday 31 January 2012, Alan Swanson wrote:
> On Tue, 2012-01-31 at 13:16 +0000, Simon Farnsworth wrote:
> > Hello,
> >
> > When profiling my workload on an AMD E-350 (PALM GPU) to see why it still
> > wasn't performing well with Jerome's WI
; 0)
> + r = timeout;
> +
> + printk( KERN_INFO "wait_user_fence offset %lld value %d timeout
> %lld\n", args->offset, args->value, args->timeout_usec );
> + printk( KERN_INFO "Finished data value %d\n", fence_data[args->offset
> &g
ed in.
Signed-off-by: Simon Farnsworth
---
drivers/gpu/drm/radeon/evergreen.c |8 ++--
drivers/gpu/drm/radeon/radeon.h|3 +
drivers/gpu/drm/radeon/radeon_device.c |1 +
drivers/gpu/drm/radeon/radeon_fence.c |3 +
drivers/gpu/drm/radeon/radeon_gem.c|
interface.
Signed-off-by: Simon Farnsworth
---
src/gallium/drivers/r600/r600_hw_context.c|2 +-
src/gallium/drivers/r600/r600_pipe.c | 12 +++--
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 30 +
src/gallium/winsys/radeon/drm/radeon_winsy
Hello,
When profiling my workload on an AMD E-350 (PALM GPU) to see why it still
wasn't performing well with Jerome's WIP macrotiling patches, I noticed that
r600_fence_finish was taking 10% of my CPU time. I determined experimentally
that changing from sched_yield() to os_time_sleep(10) fixed thi
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can wait for an EOP interrupt that
corresponds to a previous EVENT_WRITE_EOP.
Signed-off-by: Simon Farnsworth
---
I've been worki
On Tuesday 31 January 2012, Alan Swanson wrote:
> On Tue, 2012-01-31 at 13:16 +0000, Simon Farnsworth wrote:
> > Hello,
> >
> > When profiling my workload on an AMD E-350 (PALM GPU) to see why it still
> > wasn't performing well with Jerome's WI
; 0)
> + r = timeout;
> +
> + printk( KERN_INFO "wait_user_fence offset %lld value %d timeout
> %lld\n", args->offset, args->value, args->timeout_usec );
> + printk( KERN_INFO "Finished data value %d\n", fence_data[args->offset
> >>
ed in.
Signed-off-by: Simon Farnsworth
---
drivers/gpu/drm/radeon/evergreen.c |8 ++--
drivers/gpu/drm/radeon/radeon.h|3 +
drivers/gpu/drm/radeon/radeon_device.c |1 +
drivers/gpu/drm/radeon/radeon_fence.c |3 +
drivers/gpu/drm/radeon/radeon_gem.c|
interface.
Signed-off-by: Simon Farnsworth
---
src/gallium/drivers/r600/r600_hw_context.c|2 +-
src/gallium/drivers/r600/r600_pipe.c | 12 +++--
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 30 +
src/gallium/winsys/radeon/drm/radeon_winsy
_fence offset 0 value 0 timeout -1
[ 150.256828] Current data value 0
Stalled again, waiting for EOP interrupt. Could be because the GPU and CPU
have different views of memory at this point.
There will be two patches in reply to this mail - one is the Mesa patch, one
the kernel patch; I would gre
s makes it possible to
guarantee that we meet the hardware constraints. Once macrotiling is
reliable, we can consider a better API to let us exploit the hardware
capabilities.
Signed-off-by: Simon Farnsworth
---
This doesn't fix my problems with enabling macro tiling, but it does help
somewh
s makes it possible to
guarantee that we meet the hardware constraints. Once macrotiling is
reliable, we can consider a better API to let us exploit the hardware
capabilities.
Signed-off-by: Simon Farnsworth
---
This doesn't fix my problems with enabling macro tiling, but it does help
somewh
need matching patches to the DDX to be useful, and expose
bugs in Mesa as well.
Tested-by: Simon Farnsworth
On Monday 28 November 2011, alexdeucher at gmail.com wrote:
> From: Alex Deucher
>
> Avoid infinite loops waiting for surface updates if a GPU
> reset happens while waitin
need matching patches to the DDX to be useful, and expose
bugs in Mesa as well.
Tested-by: Simon Farnsworth
On Monday 28 November 2011, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> Avoid infinite loops waiting for surface updates if a GPU
> reset happens while waitin
kernel.org
This patch, and the preceding patch in this series are:
Tested-by: Simon Farnsworth
The bugs.fdo link details the testing I've done, and the results of those
tests.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
nel.org
This patch, and the preceding patch in this series are:
Tested-by: Simon Farnsworth
The bugs.fdo link details the testing I've done, and the results of those
tests.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
.freedesktop.org/show_bug.cgi?id=41366
>
> Signed-off-by: Alex Deucher
> Cc: stable at kernel.org
Tested-by: Simon Farnsworth
I applied it to airlied's drm-fixes kernel, at commit
6777a4f6898a53974ef7fe7ce09ec41fae0f32db - it fixed my problems with HDMI
being unreliable.
> -
eedesktop.org/show_bug.cgi?id=41366
>
> Signed-off-by: Alex Deucher
> Cc: sta...@kernel.org
Tested-by: Simon Farnsworth
I applied it to airlied's drm-fixes kernel, at commit
6777a4f6898a53974ef7fe7ce09ec41fae0f32db - it fixed my problems with HDMI
being unreliable.
> ---
>
blanking modes, and does not
have an impact on CPU usage in normal blanking modes.
Signed-off-by: Simon Farnsworth
---
Changes from v1:
* Replace the fence with a radeon_bo_wait on the new
frontbuffer. Discussions on #radeon suggest that this should be
good enough to wait for rendering to
On Wednesday 6 July 2011, Jerome Glisse wrote:
> On Wed, Jul 6, 2011 at 12:29 PM, Simon Farnsworth
>
> > In particular, I'm a bit hazy about what the fence in pageflip is
> > doing - I assume it's there to synchronize drawing and scanout, so
> > that I don
blanking modes, and does not
have an impact on CPU usage in normal blanking modes.
Signed-off-by: Simon Farnsworth
---
This is merely a first attempt, and while I've tested it, I expect
there to be bugs I've not thought about in here. I've only previously
worked on the Intel driver, and
blanking modes, and does not
have an impact on CPU usage in normal blanking modes.
Signed-off-by: Simon Farnsworth
---
Changes from v1:
* Replace the fence with a radeon_bo_wait on the new
frontbuffer. Discussions on #radeon suggest that this should be
good enough to wait for rendering to
On Wednesday 6 July 2011, Jerome Glisse wrote:
> On Wed, Jul 6, 2011 at 12:29 PM, Simon Farnsworth
>
> > In particular, I'm a bit hazy about what the fence in pageflip is
> > doing - I assume it's there to synchronize drawing and scanout, so
> > that I don
blanking modes, and does not
have an impact on CPU usage in normal blanking modes.
Signed-off-by: Simon Farnsworth
---
This is merely a first attempt, and while I've tested it, I expect
there to be bugs I've not thought about in here. I've only previously
worked on the Intel driver, and
d to this mailing list, and I'm also
able to make my way onto IRC if semi-interactive debugging would help.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
d to this mailing list, and I'm also
able to make my way onto IRC if semi-interactive debugging would help.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http:/
72 matches
Mail list logo
