On Wed, 16 Feb 2011 20:59:35 +0100
Alex Riesen wrote:
> On Wed, Feb 16, 2011 at 20:54, Jesse Barnes wrote:
> > On Wed, 16 Feb 2011 20:46:45 +0100
> > Alex Riesen wrote:
> >> > The backlight level on this Dell XPS M1330 reduces every time I reopen
> >> >
> > Tested-by: Alex Riesen
>
> Guys, should I apply this, or will I get it through somebody's pull?
I'm worried that removing combo mode will break some working setups,
but if it's seen a lot of testing and is ok, then I'm fine with it, as
it definitely simplifies thing
On Thu, 3 Mar 2011 17:34:53 -0600 (CST)
Ilija Hadzic wrote:
> The fix/improvement I propose is to extend the request.type field
> in drmVBlank structure with additional 5 bits that I call high_crtc
> (there are lots of unused bits in that field). 5 bits covers for 32
> CRTCs, which seems to be th
On Fri, 11 Mar 2011 02:35:45 +0100 (CET)
"Indan Zupancic" wrote:
> drm/i915: Fix DPMS and suspend interaction for intel_panel.c
>
> When suspending intel_panel_disable_backlight() is never called,
> but intel_panel_enable_backlight() is called at resume. With the
> effect that if the brightness
= connector->funcs->detect(connector, true);
> + mutex_unlock(&connector->dev->mode_config.mutex);
> +
How about adding a mutex assertion check in the detect hook as well? I
think we need a more generous sprinkling of those around the CRTC
helper code in general...
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
ted code in each function is begging to get pulled out into
a separate function...
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
param check, but I'd still prefer a new ioctl to abusing
the old one.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, 18 Mar 2011 18:13:11 -0500 (CDT)
Ilija Hadzic wrote:
>
>
> On Fri, 18 Mar 2011, Jesse Barnes wrote:
>
> >
> > I like the new param check, but I'd still prefer a new ioctl to abusing
> > the old one.
> >
>
> It's not "
not like we can't do
> "advanced" things like compositing using the CPU. Transparency may stretch
> it a bit on lower end CPUs, but you don't always need that.
There's nothing in DRM that precludes doing simple fbdev-like drivers
as well, though
On Mon, 21 Mar 2011 19:19:43 +
timofonic timofonic wrote:
> So if KMS is so cool and provides many advantages over fbdev and
> such... Why isn't more widely used intead of still relying on fbdev?
> Why still using fbdev emulation (that is partial and somewhat broken,
> it seems) instead using
On Mon, 21 Mar 2011 20:50:20 +0100
Geert Uytterhoeven wrote:
> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes wrote:
> > On Mon, 21 Mar 2011 19:19:43 +
> > timofonic timofonic wrote:
> >> So if KMS is so cool and provides many advantages over fbdev and
> >> s
ich makes reallocation of the framebuffer
somewhat difficult.
IIRC plymouth or whatever Fedora is using these days uses the KMS APIs
though...
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@l
additional features it would provide (output
> > management, memory management, execution management)
>
> 3) its got documentation
Jeez, some people want it all.
You looking for docs for the ioctls and such?
--
Jesse Barnes, Intel Open Source Technology Center
to VT switching suggest that the problems
> related to disabling part A may actually have been related to handover
> to the console driver before KMS.
Yes, definitely possible. We didn't have all the assertion checks we
have now, so we may have just been masking othe
ery much custom to DRM.
If that's the only issue you have, we could easily rename that
structure or add conversion funcs to a smaller structure if that's what
you need.
Dave's point is that we can't ditch the existing code without
introducing a lot of risk; it would be better to start a library-ized
EDID codebase from the most complete one we have already, i.e. the DRM
EDID code.
Do you really think the differences between your code and the existing
DRM code are irreconcilable?
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
; Why can't the gpu be reset/restarted when this happens? When a nic card
> gets hung it is reinitialized
> and restarted why not the gpu?
Yeah, we try to restart in this case, but often just end up back in the
same situation when the app runs again. We could be meane
s regarding this
issue though, but it does seem a likely candidate.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
ink we've been doing well with this on the Intel
side at least; we add feature flags every time we change something, and
make sure userspace is forward and backward compatible). This is more
work for us, but I think it benefits the user in the end. And it could
be worse, at least we're
ditionals to our FDI
training code to support newer chips, I've split it into separate
functions entirely, leaving the old one alone. If, after awhile we've
decided that they really are mostly the same and we have things working
well, we can consider merging them again, but only a
On Fri, 9 Apr 2010 15:10:50 -0700
Jesse Barnes wrote:
> This set of 3 patches makes it a little more likely we'll get panic
> output onto the screen even when X is running, assuming a KMS enabled
> stack anyway.
>
> It gets me from a blank or very sparsely populated black sc
On Fri, 9 Apr 2010 15:10:50 -0700
Jesse Barnes wrote:
> This set of 3 patches makes it a little more likely we'll get panic
> output onto the screen even when X is running, assuming a KMS enabled
> stack anyway.
>
> It gets me from a blank or very sparsely populated black sc
On Thu, 20 May 2010 04:27:07 +0300
Maxim Levitsky wrote:
> On Thu, 2010-05-20 at 04:13 +0300, Maxim Levitsky wrote:
> > On Wed, 2010-05-19 at 17:34 -0700, Jesse Barnes wrote:
> > > On Fri, 9 Apr 2010 15:10:50 -0700
> > > Jesse Barnes wrote:
> > >
>
On Sat, 22 May 2010 00:57:30 +0300
Maxim Levitsky wrote:
> On Fri, 2010-05-21 at 00:14 +0300, Maxim Levitsky wrote:
> > On Thu, 2010-05-20 at 09:28 -0700, Jesse Barnes wrote:
> > > On Thu, 20 May 2010 04:27:07 +0300
> > > Maxim Levitsky wrote:
> > >
>
i, 2010-05-21 at 15:02 -0700, Jesse Barnes wrote:
>> > On Sat, 22 May 2010 00:57:30 +0300
>> > Maxim Levitsky wrote:
>> >
>> > > On Fri, 2010-05-21 at 00:14 +0300, Maxim Levitsky wrote:
>> > > > On Thu, 2010-05-20 at 09:28 -0700, Jesse Barn
On Sun, 6 Jun 2010 17:36:24 +0100 (BST)
James Simmons wrote:
>
> > On Fri, 9 Apr 2010 15:10:50 -0700
> > Jesse Barnes wrote:
> >
> > > This set of 3 patches makes it a little more likely we'll get panic
> > > output onto the screen even when X is
ic daily tests? To unload you need to unbind the fbcon interface
first, my script is like this:
echo 0 > /sys/class/vtconsole/vtcon1/bind
rmmod i915
rmmod drm_kms_helper
rmmod drm
modprobe i915
echo 1 > /sys/class/vtconsole/vtcon1/bind
If unload and re-load doesn't work please fi
Emit a trace point for vblank events. This can be helpful for mapping
drawing activity against the vblank frequency and period.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/Makefile |5 +++-
drivers/gpu/drm/drm_irq.c |3 ++
drivers/gpu/drm/drm_trace.h
Allows us to track each process that requests and completes events.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_irq.c |8 ++
drivers/gpu/drm/drm_trace.h | 57 --
include/drm/drmP.h |2 +
3 files changed, 53 insertions
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_trace.h| 36 ++
drivers/gpu/drm/i915/intel_display.c |5
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915
ow it won't light up" bug).
Signed-off-by: Jesse Barnes
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b3779d2..32f67cb 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -315,8 +315,9 @@ static void drm_fb_helper_on(s
f. Much of the
drm source has doxygen rather than kdoc style comments though, I need
to clean those up before I can actually include the source generated
info in the drm.tmpl.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
> kept opaque to the kernel as well and left open to interpretation by
> userland. What I am most unclear about is under which circumstances is
> this backchannel communication preferable to passing the extra information
> over the IPC that needs to be performed anyway in order
iguration into something they couldn't change. :)
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Make drm_edid_read take a new argument, edid_read, to allow drivers to
provide their own EDID fetch routine. Export the bit banging DDC over
i2c version of the EDID fetching routine and make the drivers use it.
This sets the stage for GMBUS support in the Intel driver.
Signed-off-by: Jesse
Use the GMBUS interface rather than direct bit banging to grab the EDID
over DDC. The hope is that this method will be more reliable than bit
banging for fetching EDIDs from buggy monitors or through switches.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h| 52
On Wed, 21 Jul 2010 08:54:30 +1000
Dave Airlie wrote:
> On Tue, 2010-07-20 at 15:44 -0700, Jesse Barnes wrote:
> > Make drm_edid_read take a new argument, edid_read, to allow drivers to
> > provide their own EDID fetch routine. Export the bit banging DDC over
> > i2
On Wed, 21 Jul 2010 09:27:54 +1000
Dave Airlie wrote:
> On Tue, 2010-07-20 at 16:05 -0700, Jesse Barnes wrote:
> > On Wed, 21 Jul 2010 08:54:30 +1000
> > Dave Airlie wrote:
> >
> > > On Tue, 2010-07-20 at 15:44 -0700, Jesse Barnes wrote:
> > > &
On Tue, 20 Jul 2010 16:34:39 -0700
Jesse Barnes wrote:
> On Wed, 21 Jul 2010 09:27:54 +1000
> Dave Airlie wrote:
>
> > On Tue, 2010-07-20 at 16:05 -0700, Jesse Barnes wrote:
> > > On Wed, 21 Jul 2010 08:54:30 +1000
> > > Dave Airlie wrote:
> > >
though, whitespace isn't top of my
> priorities most days.
I think you should just reject it, unless it comes as part of a series
with actual work in it. At least that's been my policy lately...
--
Jesse Barnes, Intel Open Source Technology Center
___
.
Wait for vblank off will spin until the display line reg stops
incrementing, so it's important that we flush any previous writes to
shut off the pipe before waiting. So adding a POSTING_READ() above it
might help? But that still doesn't explai
oblems all because of this
line? Maybe because we wait for a longer period here now? Can you
check and see if we're timing out in the wait_for_vblank function?
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
d *startwrite, *startread;
> int offset;
> - int bytesperline = dev->vbi_width;
> + int bytesperline;
>
> if (dev == NULL) {
> em28xx_isocdbg("dev is null\n");
> return;
> }
> + bytesperline = dev->v
#endif /* __alpha__ */
>
> +#ifdef CONFIG_PCI
> return pci_domain_nr(dev->pdev->bus);
> +#else
> + return 0;
> +#endif
> }
>
> #if __OS_HAS_AGP
I think we fixed this, but I guess Linus hasn't pulled my tree yet...
--
Jesse Barnes, Intel Open Sourc
code is causing problems.
>
> If driver is utilising invalidate events detection can't happen in server
> side.
We could print a warning in this case at the very least. Maybe if we
try to swap again with the same dri2 invalidate stamp we could print an
error. Kristi
Seems like the first one shouldn't change behavior since we ought to
time out on waiting on vblank in that case, and the timeout is the same
as the msleep we used to use.
The second one looks like a good change, but really the pipe off change
is separate from the plane disable bug fix.
"Keith Packard" wrote:
>On Sun, 3 Oct 2010 08:10:48 -0700, Jesse Barnes
>wrote:
>
>> Do these fixes help with the DP issues you've been seeing, Keith?
>> Seems like the first one shouldn't change behavior since we ought to
>> time out on waiting
out, you're stuck fumbling
>> around in the dark trying to run 'xrandr' again.
>
>don't you do this already? both radeon/nouveau handle DP replug fine,
>I thought Intel would have been where I stole the code from.
There is some code to handle the interrupts, but I
call to pass an argument
> to indicate if this is an entry or an exit from an atomic kernel mode
> set change. Individual drm drivers can properly save and restore
> state accordingly.
>
> Signed-off-by: Jason Wessel
> CC: Jesse Barnes
> CC: David Airlie
> CC: dri-devel@lis
On Tue, 12 Oct 2010 10:46:52 -0500
Jason Wessel wrote:
> On 10/12/2010 10:38 AM, Jesse Barnes wrote:
> > On Tue, 12 Oct 2010 07:49:59 -0500
> > Jason Wessel wrote:
> >
> >
> >> Some devices such as the pre nv02 chips have enter and exit
> >> c
_fitter_pipe(struct drm_device *dev)
> +int intel_panel_fitter_pipe(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> u32 pfit_control;
>
Hm, the LVDS code should take care of panel fitting in
the !HAS_PCH_SPLIT case. Does this p
On Mon, 18 Oct 2010 21:13:59 +0200
Arnd Bergmann wrote:
> On Monday 18 October 2010 20:56:48 Jesse Barnes wrote:
> > Hm, the LVDS code should take care of panel fitting in
> > the !HAS_PCH_SPLIT case. Does this patch achieve the same thing as
> > yours? Maybe we were leavi
On Mon, 18 Oct 2010 21:57:05 +0200
Arnd Bergmann wrote:
> On Monday 18 October 2010 21:28:01 Jesse Barnes wrote:
> >
> > On Mon, 18 Oct 2010 21:13:59 +0200
> > Arnd Bergmann wrote:
> >
> > > On Monday 18 October 2010 20:56:48 Jesse Barnes wrote:
> >
short circuit it before that.
So we should probably do it in setup_outputs or init_display once we've
figured out there's no LVDS. It's cool that the panel fitter still has
an effect even on non-LVDS platforms though, maybe we really should
treat it as a part of the CRTC
ic one's lack register addresses
> for PCH regs ...
> Reviewed-by: Daniel Vetter
Yep, I like it too:
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
the hardware when
> the driver starts and use that if present. But, that might mean that
> you'd get different modes depending on whether the machine booted with
> the lid closed or open, which seems like a bad plan.
More than that, I think eDP *requires* an EDID, and it sounds like even
pp_status,
> + I915_READ(PCH_PP_CONTROL));
> + }
> +}
I'd call it "intel_dp_assert_dp_power" or something more descriptive
(or just assert_panel_power to match the other asserts in
intel_display.c), but other than that this is a nice sanity check.
--
Jesse Barnes, Intel Open Source Technology Center
> /* Returns true if the panel was already on when called */
> -static bool ironlake_edp_panel_on (struct intel_dp *intel_dp)
> +static void ironlake_edp_panel_on (struct intel_dp *intel_dp)
> {
Remove the comment too?
--
Jesse Barnes, Intel Open Source Technology Center
On Thu, 29 Sep 2011 18:09:42 -0700
Keith Packard wrote:
> Talking to the eDP DDC channel requires that the panel be powered
> up. Wrap both the EDID and modes fetch code with calls to turn the vdd
> power on and back off.
>
These VDD AUX changes look good, ack on all of them.
--
ems pretty much the
> same as people are getting under Mac OS.
As long as you enable RC6. :)
--
Jesse Barnes, Intel Open Source Technology Center
front seems nicer; did you get confirmation that the
"wavy VGA" bug was fixed with this series? Overall seems like a good
improvement over our old PCH refclk code...
--
Jesse Barnes, Intel Open Source Technology Center
ver is ruining things, but I believe patch 7
> includes whitespace errors.
Yay excellent.
Now... is keeping the various refclks enabled costing us any power?
IOW, should we be trying to disable them when everything has been
DPMS'd off too?
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, 03 Oct 2011 16:18:48 -0700
Keith Packard wrote:
> On Mon, 3 Oct 2011 14:14:23 -0700, Jesse Barnes
> wrote:
>
> > Now... is keeping the various refclks enabled costing us any power?
> > IOW, should we be trying to disable them when everything has been
> >
On Thu, 15 Sep 2011 01:31:00 +0200
Mario Kleiner wrote:
> On Sep 15, 2011, at 12:54 AM, Francisco Jerez wrote:
>
> > Mario Kleiner writes:
> >
> >> On Sep 14, 2011, at 6:02 PM, Keith Packard wrote:
> >>
> >>> On Wed, 14 Sep 2011 10:05:29 -0500, J
I've given up waiting for someone to implement support for these ioctls
on another platform before they're merged, but I have received a lot of
feedback on the interfaces, and it sounds like they're ok. I've also
fixed all the remaining issues I'm aware of on SNB platforms and things
are working w
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 236 +++-
drivers/gpu/drm/drm_
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
This avoids the need to unpin on the error path.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_overlay2.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay2.c
b/drivers/gpu/drm/i915/intel_overlay2.c
index 2e38b15
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4f599ce..cd7e04d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i9
Make sure the object exists (it may not if the plane was previously disabled)
and make sure we zero it out in the disable path to avoid trouble later.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_overlay2.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff
Split things out a little and add the IVB reg definitions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h | 59
drivers/gpu/drm/i915/intel_overlay2.c | 168 ++--
2 files changed, 216 insertions(+), 11 deletions(-)
diff --git a
To avoid the object being destroyed before our disable hook is called,
take a private reference on it. This will guarantee that we can still
access the object at disable time.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_overlay2.c | 27 ++-
1 files
If the source and destination size are different, try to scale the sprite on the
corresponding CRTC.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h |5 +
drivers/gpu/drm/i915/intel_overlay2.c | 14 --
2 files changed, 17 insertions(+), 2 deletions
If we try to scan a sprite outside of the parent CRTC area, the display
engine will underflow and potentially blank the framebuffer. So clamp
the position + size to the viewable area.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_overlay2.c | 12 +++-
1 files changed, 11
On Tue, 25 Oct 2011 19:47:13 +0900
Joonyoung Shim wrote:
> 10/25/2011 06:46 PM, Jesse Barnes ? ?:
> > I've given up waiting for someone to implement support for these
> > ioctls on another platform before they're merged, but I have
> > received a lot of feedback o
On Tue, 25 Oct 2011 19:53:02 +0900
Joonyoung Shim wrote:
> > +/**
> > + * drm_plane - central DRM plane control structure
> > + * @dev: DRM device this plane belongs to
> > + * @kdev: kernel device
> > + * @attr: kdev attributes
> > + * @head: for list management
> > + * @base: base mode object
>
On Tue, 25 Oct 2011 11:46:55 +0200
Jesse Barnes wrote:
> I've given up waiting for someone to implement support for these
> ioctls on another platform before they're merged, but I have received
> a lot of feedback on the interfaces, and it sounds like they're ok.
&
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
v2: collapse patches and fix plane disable vs unpin ordering bug
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
v2: collapse patches
v3: no really, fix disable ordering
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile
On Tue, 25 Oct 2011 13:58:55 +0200
Daniel Vetter wrote:
> On Tue, Oct 25, 2011 at 11:46:56AM +0200, Jesse Barnes wrote:
> > Planes are a bit like half-CRTCs. They have a location and fb, but
> > don't drive outputs directly. Add support for handling them to t
On Tue, 25 Oct 2011 14:26:07 +0100
Alan Cox wrote:
> > As discussed with Jesse on irc, drm fb handling is fragile. Current
> > rules:
> > - fbs are not reference counted, hence when destroying we need to
> > disable all crtcs (and now also planes) that use them.
> > drm_framebuffer_cleanup does t
Here's a diff I can roll in if it looks ok. It adds the ability to
specify multiple handles for a single fb to better accommodate planar
configs. I think Rob has convinced me that this is a good idea...
comments appreciated.
Thanks,
Jesse
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/dr
On Wed, 26 Oct 2011 14:40:07 +0900
Joonyoung Shim wrote:
> 10/25/2011 06:46 PM, Jesse Barnes ? ?:
>
> [snip]
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 8020798..d7f03aa 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/
es, tablets, notebooks, etc will need
and want an architecture that looks a lot like the DRM layer, with
authentication for rendering clients, an command submission ioctl for
acceleration, and memory management, so I expect most of the driver
growth to be in DRM in the near future.
On Mon, 19 Sep 2011 15:22:00 -0700
Keith Packard wrote:
> The eDP panel may not be able to respond to aux channel communications
> unless it has power supplied. During mode setting, power may be
> cut-off during panel power sequencing. Make sure that any aux channel
> communications will work by
On Mon, 19 Sep 2011 15:22:03 -0700
Keith Packard wrote:
> There's no good reason to turn off the eDP force VDD bit synchronously
> while probing devices; that just sticks a huge delay into all mode
> setting paths. Instead, queue a delayed work proc to disable the VDD
> force bit and then remembe
On Tue, 20 Sep 2011 21:45:54 -0700
Keith Packard wrote:
> On Wed, 21 Sep 2011 09:20:01 +0530, Jesse Barnes
> wrote:
>
> > This one mixes up lots of cleanups plus the EDID read with the power
> > changes.
>
> I think the cleanups are;
>
> 1) edp checks insi
On Tue, 20 Sep 2011 21:51:33 -0700
Keith Packard wrote:
> Yes, making it cleaner would help a ton. There are some basic problems
> with the DRM API that make this hard though -- intel_dp_prepare may
> not ever be followed by a call to intel_dp_commit. That's why I had
> the VDD AUX stuff get turne
er interrupt, with chained secondary interrupt statuses.
> If IIR is 0, the interrupt wasn't raised by the GPU.
I've actually seen cases where one of the PIPE*STAT regs is stuck, and
even if IIR is 0 we still get interrupts... Jiri can you verify the
PIPE*STAT regs have bits set, maybe one
known issue with the DRM code, I thought Dave had a
fix queued a long time ago though... Dave?
--
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 byt
10 @@ static void intel_sdvo_mode_set(struct drm_encoder
> *encoder,
> !intel_sdvo_set_tv_format(intel_sdvo))
> return;
>
> + /* We have tried to get input timing in mode_fixup, and filled into
> + * adjusted_mode.
> + */
> + in
On Tue, 10 Apr 2012 10:47:49 +0200
Jiri Slaby wrote:
> On 04/09/2012 07:11 PM, Jesse Barnes wrote:
> > On Fri, 30 Mar 2012 11:45:43 +0100 Chris Wilson
> > wrote:
> >
> >> On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby
> >> wrote:
> >>> I don
;input_dtd because it's not
> needed).
>
> Hopefully this clears things up a bit.
Yep, thanks. Hopefully you'll get your SDVO spec access soon...
--
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed.
On Tue, 10 Apr 2012 20:11:29 +0200
Jiri Slaby wrote:
> On 04/10/2012 06:26 PM, Jesse Barnes wrote:
> > So port hotplug is always reporting that port C has a hotplug
> > interrupt though... If you write 0x3 back to it does the interrupt
> > stop?
>
> I'm not s
etting stuck (though it's possible this could be related to
pipelined fencing, if the fences are programmed to point at some funky
memory space).
--
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signatu
On Wed, 11 Apr 2012 08:29:22 +0200
Michel D?nzer wrote:
> On Die, 2012-04-10 at 11:34 -0700, Jesse Barnes wrote:
> > On Tue, 10 Apr 2012 20:11:29 +0200
> > Jiri Slaby wrote:
> >
> > > On 04/10/2012 06:26 PM, Jesse Barnes wrote:
> > > > So port hot
re planes associated with a given pipe, along with
ancillary data that may be needed (sprite position, z order, gamma,
etc).
This could easily spiral out of control though, given how poorly the
existing KMS API expresses the variety of display controllers out
there; hopefully we can keep things incremental.
--
Jesse Barnes, Intel Open Source Technology Center
tc didn't emit an
event, so I didn't add it to setplane (it would be of limited
usefulness anyway since we really want to flip primary + sprite at the
same time).
--
Jesse Barnes, Intel Open Source Technology Center
401 - 500 of 905 matches
Mail list logo
