On Mon, Nov 07, 2011 at 10:02:52AM -0800, 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 the core
> KMS code.
>
> Signed-off-by: Jesse Barnes
One question belowk, but still:
Reviewed-by:
This prevents an in-kernel division by zero which happens when we are
asking for i915_chipset_val too quickly, or within a race condition
between the power monitoring thread and userspace accesses via debugfs.
The issue can be reproduced easily via the following command:
while ``; do cat /sys/kern
On Tue, 8 Nov 2011 15:20:37 +0100
Daniel Vetter wrote:
> On Mon, Nov 07, 2011 at 10:02:52AM -0800, 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 the core
> > KMS code.
> >
> > Signed
Add new ioctls for getting and setting the current destination color
key. This allows for simple overlay display control by matching a color
key value in the primary plane before blending the overlay on top.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c |2 +
drivers/g
To save power when the sprite is full screen, we can disable the primary
plane on the same pipe. Track the sprite status and enable/disable the
primary opportunistically.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_drv.h|3 ++
drivers/gpu/drm/i915/intel_sprite.c | 67 +++
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
sprite support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_reg.h | 123 ++
There is an error in i915_read_blc_pwm_ctl, where the register values
are not being copied correctly. BLC_PWM_CTL and BLC_PWM_CTL2 are
getting mixed up. This patch fixes that so that saveBLC_PWM_CTL2 and
not saveBLC_PWM_CTL is copied to the BLC_PWM_CTL2 register.
Signed-off-by: Simon Que
---
d
Use 0x1000 as the default backlight PWM max value and period. This is
passed in as a module parameter to i915_drv and is used to program the
PWM registers. It can be set to other values based on the needs of each
system.
Signed-off-by: Simon Que
---
Matthew, this patch has been reworked to bett
On Mon, Nov 07, 2011 at 10:02:54AM -0800, Jesse Barnes wrote:
> 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
> sprite support functions.
>
> Signed-off-by: Jesse Barnes
I've not checked the wate
I feel like I'm missing something here. Where's the firmware getting its
initial value from?
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Nov 8, 2011 at 1:42 PM, Matthew Garrett wrote:
> I feel like I'm missing something here. Where's the firmware getting its
> initial value from?
My understanding is that normally, the firmware's VBIOS can program the
value of the PWM register. But if the firmware doesn't have the VBIOS
On Mon, Nov 07, 2011 at 10:02:55AM -0800, Jesse Barnes wrote:
> Add new ioctls for getting and setting the current destination color
> key. This allows for simple overlay display control by matching a color
> key value in the primary plane before blending the overlay on top.
>
> Signed-off-by: Je
On Mon, Nov 07, 2011 at 10:02:56AM -0800, Jesse Barnes wrote:
> To save power when the sprite is full screen, we can disable the primary
> plane on the same pipe. Track the sprite status and enable/disable the
> primary opportunistically.
>
> Signed-off-by: Jesse Barnes
I'll again look at this w
On Tue, Nov 08, 2011 at 02:05:14PM -0800, Simon Que wrote:
> On Tue, Nov 8, 2011 at 1:42 PM, Matthew Garrett wrote:
>
> > I feel like I'm missing something here. Where's the firmware getting its
> > initial value from?
>
>
> My understanding is that normally, the firmware's VBIOS can program th
On Tue, Nov 08, 2011 at 10:57:03PM +0100, Daniel Vetter wrote:
> > + /*
> > +* Clamp the width & height into the visible area. Note we don't
> > +* try to scale the source if part of the visible region is offscreen.
> > +* The caller must handle that by adjusting source offset and si
On Tue, Nov 8, 2011 at 2:10 PM, Matthew Garrett wrote:
> On Tue, Nov 08, 2011 at 02:05:14PM -0800, Simon Que wrote:
> > On Tue, Nov 8, 2011 at 1:42 PM, Matthew Garrett
> wrote:
> >
> > > I feel like I'm missing something here. Where's the firmware getting
> its
> > > initial value from?
> >
> >
On Tue, Nov 08, 2011 at 02:27:04PM -0800, Simon Que wrote:
> This is for an x86-based Chromebook. Its firmware doesn't have the VBIOS
> support. Previously, we had our own backlight driver that also did a
> similar initialization. Now, we are trying to move away from that and use
> the upstream
On Tue, 8 Nov 2011 22:57:03 +0100
Daniel Vetter wrote:
> I've not checked the watermarks, that kind of magic eludes me ;-) A few
> other comments below.
I need to get docs on that; in particular WM handling with downscaling
is an unknown.
> > +#define DVS_SCALE_ENABLE (1<<31)
> > +#define DV
On Tue, 8 Nov 2011 23:06:57 +0100
Daniel Vetter wrote:
> On Mon, Nov 07, 2011 at 10:02:55AM -0800, Jesse Barnes wrote:
> > Add new ioctls for getting and setting the current destination color
> > key. This allows for simple overlay display control by matching a color
> > key value in the primary
On Tue, Nov 8, 2011 at 2:28 PM, Matthew Garrett wrote:
> On Tue, Nov 08, 2011 at 02:27:04PM -0800, Simon Que wrote:
>
> > This is for an x86-based Chromebook. Its firmware doesn't have the VBIOS
> > support. Previously, we had our own backlight driver that also did a
> > similar initialization.
On Tue, Nov 08, 2011 at 02:41:56PM -0800, Simon Que wrote:
> There is a backup kernel partition that can be used for boot.
>
> Failing that, the system can boot from a recovery image over USB.
So absolutely no video code in the firmware at all? Ok. What I'd really
rather see here is some generi
On Tue, Nov 08, 2011 at 02:31:00PM -0800, Jesse Barnes wrote:
> On Tue, 8 Nov 2011 22:57:03 +0100 Daniel Vetter wrote:
> > > @@ -270,8 +270,14 @@ void intel_fb_restore_mode(struct drm_device *dev)
> > > {
> > > int ret;
> > > drm_i915_private_t *dev_priv = dev->dev_private;
> > > + struct drm
On Tue, Nov 8, 2011 at 2:47 PM, Matthew Garrett wrote:
> On Tue, Nov 08, 2011 at 02:41:56PM -0800, Simon Que wrote:
>
>> There is a backup kernel partition that can be used for boot.
>>
>> Failing that, the system can boot from a recovery image over USB.
>
> So absolutely no video code in the firm
On Tue, Nov 08, 2011 at 05:36:11PM -0500, Alex Deucher wrote:
> On Tue, Nov 8, 2011 at 5:06 PM, Daniel Vetter wrote:
> > On Mon, Nov 07, 2011 at 10:02:55AM -0800, Jesse Barnes wrote:
> >> Add new ioctls for getting and setting the current destination color
> >> key. This allows for simple overlay
On Tue, Nov 08, 2011 at 03:02:00PM -0800, Olof Johansson wrote:
> How about a DMI table check that overrides whatever is setup (or not
> setup) from the video bios? We know exactly what platforms need this
> so that table would be easy to specify.
dmi's horribly unscalable. It's much better to ha
Rather than relying on the hardware to do this correctly, we can
trivially do it ourselves.
This fixes a very reliable crash on d-i-n with all bits enabled during a
cairo-trace replay. The symptoms of the crash is that we continue to
write commands into the render ring buffer past the active head
Enabling FBC is causing the BLT ring to run between 10-100x slower than
normal and frequently lockup. The interim solution is disable FBC once
more until we know why.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Thanks, seems mesa+gmplayer were the culprits this time:
https://bugs.freedesktop.org/show_bug.cgi?id=42726
- Clemens
2011/11/5 Chris Wilson :
> On Sat, 5 Nov 2011 00:51:59 +0100, Clemens Eisserer
> wrote:
>> Hi,
>>
>> While I was trying out intel-git as well as mesa-i915git on my i945GM
>> ba
Hi,
On Tue, Nov 8, 2011 at 3:11 PM, Matthew Garrett wrote:
> On Tue, Nov 08, 2011 at 03:02:00PM -0800, Olof Johansson wrote:
>
>> How about a DMI table check that overrides whatever is setup (or not
>> setup) from the video bios? We know exactly what platforms need this
>> so that table would be
On Tue, Nov 8, 2011 at 5:49 PM, Olof Johansson wrote:
> Hi,
>
> On Tue, Nov 8, 2011 at 3:11 PM, Matthew Garrett wrote:
>> On Tue, Nov 08, 2011 at 03:02:00PM -0800, Olof Johansson wrote:
>>
>>> How about a DMI table check that overrides whatever is setup (or not
>>> setup) from the video bios? We
SandyBridge should be using the same register addresses as IvyBridge.
btw, rename the register names accordingly.
Signed-off-by: Wu Fengguang
---
drivers/gpu/drm/i915/i915_reg.h |6 +++---
drivers/gpu/drm/i915/intel_display.c | 10 +-
2 files changed, 8 insertions(+), 8 delet
Hi Christopher,
I don't find anything wrong with the ELD parsing code, however I do
find a bug that prevented ELD from being passed to the audio driver on
SandyBridge.
I just posted the fix. For your convenience, it's attached in this
email too.
Thanks,
Fengguang
On Fri, Oct 28, 2011 at 03:57:2
Hi Takashi,
I enumerated all the DELL DisplayPort monitors in our lab and find
only two of them being able to produce audible DisplayPort audio...
- DELL 2408WFP
- DELL 2709W
- DELL 3008WFP
no CEA extension found
- DELL U2410
ELD reports OK but cannot hear DP sound
monit
Here are the EDID for the DELL monitors, grabbed by command
cp /sys/class/drm/card0-DP-3/edid .
Thanks,
Fengguang
On Wed, Nov 09, 2011 at 03:20:53PM +0800, Wu Fengguang wrote:
> Hi Takashi,
>
> I enumerated all the DELL DisplayPort monitors in our lab and find
> only two of them being a
At Wed, 9 Nov 2011 15:20:53 +0800,
Wu Fengguang wrote:
>
> Hi Takashi,
>
> I enumerated all the DELL DisplayPort monitors in our lab and find
> only two of them being able to produce audible DisplayPort audio...
Thanks for testing!
> - DELL 2408WFP
> - DELL 2709W
> - DELL 3008WFP
> no C
35 matches
Mail list logo
