From: Dave Airlie
This takes the tiling info from the connector and
exposes it to userspace, as a blob object in a
connector property.
The contents of the blob is ABI.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 36
drivers/gpu/drm
From: Dave Airlie
These are just taken from the DisplayID v1.3 spec, and the
DDC spec.
Signed-off-by: Dave Airlie
---
include/drm/drm_displayid.h | 76 +
include/drm/drm_edid.h | 2 ++
2 files changed, 78 insertions(+)
create mode 100644 inclu
From: Dave Airlie
A tile group is an identifier shared by a single monitor,
DisplayID topology has 8 bytes we can use for this, just
use those for now until something else comes up in the
future. We assign these to an idr and use the idr to
tell userspace what connectors are in the same tile grou
From: Dave Airlie
This creates a tile group from DisplayID block, and
stores the pieces of parsed info from the DisplayID block
into the connector.
---
drivers/gpu/drm/drm_crtc.c | 5 ++
drivers/gpu/drm/drm_edid.c | 139 -
include/drm/drm_crtc.h
From: Dave Airlie
This adds fbdev/con support for tiled monitors, so that we
only set a mode on the correct half of the monitor, or
span the two halves if needed.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_fb_helper.c| 122 +++--
drivers/gpu/drm/i915
So I believe attempts to hide the DP MST tiled monitors in the kernel,
are a path to failure, so I've resurrected my previous code to just
create a tile property on the connectors for userspace to key off.
The contents of the tile blob are ABI, and I expect it to be
parsed by a fair few userspace
From: Dave Airlie
Logical ports are never going to have EDID changes,
they are used for the internal ports on MST monitors.
We cache the EDIDs from these to save time at MST probe.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_mst_topology.c | 20 ++--
drivers/gpu/drm/
On Mon, Oct 6, 2014 at 5:17 PM, Chris Wilson wrote:
> On Mon, Oct 06, 2014 at 03:15:04PM +0100, john.c.harri...@intel.com wrote:
>> From: John Harrison
>>
>> Work in progress for replacing seqno usage with requst structures.
>
> You fail to end up with my earlier code. Nak.
Well I've tried to sp
On 16/10/14 15:33, Cheng, Yao wrote:
> Hi Emil,
> Sorry, what do you mean by "correctly aligned"? does it mean the paddings in
> this data structure?
>
Afaict for compatibility reasons the struct size have to be "aligned"
(multiple of 8 bytes), or if you prefer - the struct is missing the
require
On Thu, Oct 16, 2014 at 01:48:20PM +0300, Jani Nikula wrote:
> On Thu, 16 Oct 2014, Daniel Vetter wrote:
> > Too many new drm driver writers seem to look at i915 for inspiration.
> > But we have two ways to do mmap, so discourage readers from the old,
> > ugly version. In a new driver we'd just ex
On Sun, Oct 19, 2014 at 04:28:57PM +0200, Daniel Vetter wrote:
> On Thu, Oct 09, 2014 at 03:18:03PM +0300, Ander Conselvan de Oliveira wrote:
> > On 10/09/2014 12:11 PM, Daniel Vetter wrote:
> > >On Wed, Oct 08, 2014 at 06:32:21PM +0300, Ander Conselvan de Oliveira
> > >wrote:
> > >>From: Ander Co
On Thu, Oct 09, 2014 at 03:18:03PM +0300, Ander Conselvan de Oliveira wrote:
> On 10/09/2014 12:11 PM, Daniel Vetter wrote:
> >On Wed, Oct 08, 2014 at 06:32:21PM +0300, Ander Conselvan de Oliveira wrote:
> >>From: Ander Conselvan de Oliveira
> >>
> >>This shouldn't change the behavior of those fun
On Thu, Oct 09, 2014 at 08:13:18AM -0700, Jesse Barnes wrote:
> Gets the detect code (which may take awhile) out of the resume path,
> speeding things up a bit.
>
> v2: use a delayed work queue instead (Daniel)
> v3: cancel delayed work at unload and suspend time (Jesse)
> v4: make delayed work co
On Fri, Oct 10, 2014 at 01:03:17PM +0100, John Harrison wrote:
> I have just posted an updated subset of the patch series. Note that one
> patch has been inserted in the middle and the first one has been dropped.
> The correct sequence is now:
>
>01drm/i915: Remove redundant parameter to
>
On Fri, Oct 10, 2014 at 12:41:33PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> For: VIZ-4377
> Signed-off-by: john.c.harri...@intel.com
Now I'm confused ... patch 3 made it sound like having the request and the
seqno allocated at different points is a really fragile idea? O
On Fri, Oct 10, 2014 at 12:41:12PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> For: VIZ-4377
> Signed-off-by: john.c.harri...@intel.com
I think this should be squashed (well, split first) into the relevant
earlier patches. Generally I much prefer kzalloc, and we use that al
On Tue, Oct 07, 2014 at 05:47:29PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> For: VIZ-4377
> Signed-off-by: john.c.harri...@intel.com
Why? If it's just for performance I think we should do this as part of the
switch to struct fence, which already has this.
> ---
> driver
On Mon, Oct 06, 2014 at 03:15:25PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> For: VIZ-4377
> Signed-off-by: john.c.harri...@intel.com
I think this should be split up into the different parts:
- s/obj->ring/obj->last_read_req->ring/ for all the cases that just want
the
On Mon, Oct 06, 2014 at 03:15:24PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> For: VIZ-4377
> Signed-off-by: john.c.harri...@intel.com
We have places that shovel stuff onto the ring without an explicit
add_request. Or at least we've had, so this needs a full audit, and tha
On Mon, Oct 06, 2014 at 03:15:23PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> For: VIZ-4377
> Signed-off-by: john.c.harri...@intel.com
This smells funky on a quick look. I'd expect some reference counting in
here, or at least an explanatation for why it's not needed.
But
On Fri, Oct 10, 2014 at 12:39:49PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> For: VIZ-4377
> Signed-off-by: john.c.harri...@intel.com
> ---
> drivers/gpu/drm/i915/i915_debugfs.c |3 +--
> drivers/gpu/drm/i915/i915_drv.h | 18 ++
> drivers/gpu/d
On Mon, Oct 06, 2014 at 03:15:18PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
Again on the topic of thin commit message: Some additional words about why
we can noodle around in request structures from hardirq context (those
fields are invariant after add_request) would be good.
On Mon, Oct 06, 2014 at 03:15:17PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
Again on the topic of thin commit messages: Beyond the boilerplate blabla
explaining why we do all the s/seqno/request/ stuff for the benefit of the
future reader this definitely needs a mention of th
On Fri, Oct 10, 2014 at 12:38:22PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> For: VIZ-4377
> Signed-off-by: john.c.harri...@intel.com
This looks like a v2 of the previous patch 08, but the commit message
fails to mention what exactly changed and why.
-Daniel
> ---
> dr
On Sun, Oct 19, 2014 at 2:25 PM, Daniel Vetter wrote:
> On Mon, Oct 06, 2014 at 03:15:06PM +0100, john.c.harri...@intel.com wrote:
>> From: John Harrison
>
> Empty commit messages are a bit too thin. E.g. in this case this was an
> oversight from
>
> commit c8725f3dc0911d4354315a65150aecd8b7d0d74
On Mon, Oct 06, 2014 at 03:15:14PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
I know there's often not a lot to talk about for if you have a refactoring
step that needs to be applied n times. But even then a small commit
message to reiterate what is going on and why and a small
On Sun, Oct 19, 2014 at 2:48 PM, Daniel Vetter wrote:
>> @@ -2605,9 +2603,8 @@ static void i915_gem_reset_ring_cleanup(struct
>> drm_i915_private *dev_priv,
>> }
>>
>> /* These may not have been flush before the reset, do so now */
>> - kfree(ring->preallocated_lazy_request);
>> -
On Mon, Oct 06, 2014 at 03:15:12PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> For: VIZ-4377
> Signed-off-by: john.c.harri...@intel.com
given the scary commit message for patch 3 I'm confused that we can just
do this. Or maybe we should move patch 3 right before this one he
On Mon, Oct 06, 2014 at 03:15:09PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
I think a few words about how these helpers help the transitions (and
example maybe) would be great. Since without peeking ahead (which I
didn't) and looking at the JIRA (which I've forgotten all a
On Mon, Oct 06, 2014 at 03:15:07PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The new seqno alloction code pre-allocates a 'lazy' request structure and then
> tries to allocate the 'lazy' seqno. The seqno allocation can potential wrap
> around zero and when doing so, tries
On Mon, Oct 06, 2014 at 03:15:06PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
Empty commit messages are a bit too thin. E.g. in this case this was an
oversight from
commit c8725f3dc0911d4354315a65150aecd8b7d0d74a
Author: Chris Wilson
Date: Mon Mar 17 12:21:55 2014 +
On Thu, Oct 09, 2014 at 07:11:47AM -0700, Rodrigo Vivi wrote:
> Let's clean this a bit
>
> v2: Rebase after other Mika's patch that removed some BDW production
> workarounds.
> v3: Removed stepping info.
>
> Reviewed-by: Mika Kuoppala
> Signed-off-by: Rodrigo Vivi
Queued for -next, thanks for
On Fri, Oct 10, 2014 at 06:08:21PM +0300, Jani Nikula wrote:
> On Sun, 24 Aug 2014, Chris Wilson wrote:
> > Just a couple more macros that assume that they were being passed a
> > struct drm_device when they want a struct drm_i915_private. Use our
> > magic macro to ease transitioning over to usin
On Sat, Oct 18, 2014 at 12:04:32PM +0200, Jesse Barnes wrote:
> On Thu, 16 Oct 2014 13:47:38 +0200
> Daniel Vetter wrote:
>
> > We need ww mutexes and need to rewrite i915 a bit fo fix this all.
> > I.e. known issue. As long as your userspace isn't nasty nothing bad
> > will ever happen though.
>
On Thu, Oct 16, 2014 at 03:47:08PM +0200, David Herrmann wrote:
> Hi
>
> On Thu, Oct 16, 2014 at 3:39 PM, Cheng, Yao wrote:
> > Accepted :) I will update the patch to implement the mmap interface and
> > remove the legacy MMAP_IOCTL.
> > BTW I didn't see a field to get mmap_offset in struct drm_
On Thu, Oct 16, 2014 at 03:05:07PM +, Cheng, Yao wrote:
> > Ok, bunch of comments. First a high-level one: I think this qualifies as a
> > new
> > subsystem of i915, and so it would be good to extract this into a new file
> > (i915_ved.c maybe), including adding kerneldoc for the setup functio
36 matches
Mail list logo
