On Fri, Jan 11, 2013 at 03:47:16PM +, Damien Lespiau wrote:
> On Fri, Jan 11, 2013 at 09:41:05AM +0100, Daniel Vetter wrote:
> > What about moving gen4asm into a subdir of i-g-t? With git filter-branch
> > we could even retain the entire history
> > -Daniel
>
> I'm not against doing that,
On Mon, 2013-01-14 at 22:51 +0100, Daniel Vetter wrote:
> On Mon, Jan 14, 2013 at 10:06 PM, Imre Deak wrote:
> > Well, the first flush would first write any valid data in the cache line
> > to memory and only then invalidate it. But this would have the same
> > result as just doing away with the f
On Mon, Jan 14, 2013 at 10:06 PM, Imre Deak wrote:
> Well, the first flush would first write any valid data in the cache line
> to memory and only then invalidate it. But this would have the same
> result as just doing away with the first flush: the original cache line
> updated by the dword.
>
>
On Mon, 2013-01-14 at 21:04 +0100, Daniel Vetter wrote:
> On Mon, Jan 14, 2013 at 8:21 PM, Imre Deak wrote:
> >> + drm_clflush_virt_range(vaddr + page_offset, 4);
> >> + *(uint32_t *)(vaddr + page_offset) = reloc->delta;
> >> + drm_clflus
Hi
2013/1/8 Daniel Vetter :
> This could very well be caused by dirt left behind by the BIOS, so
> tune it down to the debug level.
This message can also be triggered by
"I915_READ(REGISTER_THAT_DOES_NOT_EXIST)". Still, I also suspect that
the very first message we see is due to something left be
On Mon, Jan 14, 2013 at 9:50 PM, Chris Wilson wrote:
> On Mon, 14 Jan 2013 21:04:06 +0100, Daniel Vetter wrote:
>> On Mon, Jan 14, 2013 at 8:21 PM, Imre Deak wrote:
>> >> + drm_clflush_virt_range(vaddr + page_offset, 4);
>> >> + *(uint32_t *)(vaddr + page_
On Mon, 14 Jan 2013 21:04:06 +0100, Daniel Vetter wrote:
> On Mon, Jan 14, 2013 at 8:21 PM, Imre Deak wrote:
> >> + drm_clflush_virt_range(vaddr + page_offset, 4);
> >> + *(uint32_t *)(vaddr + page_offset) = reloc->delta;
> >> + drm_clfl
On Mon, Jan 14, 2013 at 8:21 PM, Imre Deak wrote:
>> + drm_clflush_virt_range(vaddr + page_offset, 4);
>> + *(uint32_t *)(vaddr + page_offset) = reloc->delta;
>> + drm_clflush_virt_range(vaddr + page_offset, 4);
>
> Discussed this already
On Tue, 2013-01-08 at 10:53 +, Chris Wilson wrote:
> If the object lies outside of the mappable GTT aperture, do not force it
> through the CPU domain for relocations, but simply flush the writes as
> we perform them and then queue a chipset flush.
>
> Signed-off-by: Chris Wilson
> ---
> dri
Hi Wang,
I would prefer to use defined HSW_AUD_PIN_ELD_CP_VLD directly at
read/write macros instead of creating an variable aud_cntrl_st2.
But this is minor, the other question I have here, why are you doing
this only for pipe A instead of pipe in use?
On Mon, Jan 7, 2013 at 3:20 AM, Wang Xingcha
On Mon, 2013-01-14 at 17:14 +0100, Daniel Vetter wrote:
> On Mon, Jan 07, 2013 at 09:47:35PM +0200, Imre Deak wrote:
> > Signed-off-by: Imre Deak
>
> I've applied patches 1-3 from this series, since they look like nice
> cleanups. Like discussed on irc, I'm not sold on the later ones since I
> do
On Mon, Jan 07, 2013 at 09:47:35PM +0200, Imre Deak wrote:
> Signed-off-by: Imre Deak
I've applied patches 1-3 from this series, since they look like nice
cleanups. Like discussed on irc, I'm not sold on the later ones since I
don't see a clear upside ...
-Daniel
> ---
> drivers/gpu/drm/i915/i91
On Mon, Jan 14, 2013 at 04:09:39PM +0100, Daniel Vetter wrote:
> On Mon, Jan 14, 2013 at 04:15:07PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > intel_hdmi.has_hdmi_sink is tied into the force audio property, so it
> > doesn't seem like the correct way to detect HDM
On Mon, Jan 14, 2013 at 04:15:07PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> intel_hdmi.has_hdmi_sink is tied into the force audio property, so it
> doesn't seem like the correct way to detect HDMI monitors. Instead add
> a new has_hdmi_monitor member which simply tell
On Sun, Jan 13, 2013 at 10:10:24AM +0800, Yi Sun wrote:
> Signed-off-by: Yi Sun
Applied, thanks for the patch.
-Daniel
>
> diff --git a/tests/testdisplay.c b/tests/testdisplay.c
> index 7aef940..f2711ae 100644
> --- a/tests/testdisplay.c
> +++ b/tests/testdisplay.c
> @@ -598,7 +598,7 @@ int upda
The weekly bug team status for the past week.
== Daniel
Mostly looked at the ILK bug and stiched together a revert of the
shrinker changes. Still no idea about the underlying cause. Details in
the commit [1].
Otherwise the usual bug scrubbing activities with 1-2 failed patch
attempts.
[1]
htt
From: Ville Syrjälä
The AVI infoframe is able to inform the display whether the source is
sending full or limited range RGB data.
As per CEA-861 we must first check whether the display reports the
quantization range as selectable, and if so we can set the approriate
bits in the AVI inforframe.
From: Ville Syrjälä
drm_rgb_quant_range_selectable() will report whether the monitor
claims to support for RGB quantization range selection.
The information can be found in the CEA Video capability block.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 33 +
From: Ville Syrjälä
Add a new "Automatic" mode to the "Broadcast RGB" range property.
When selected the driver automagically selects between full range and
limited range output.
Based on CEA-861 guidelines, limited range output is selected if the
mode is a CEA mode, except 640x480. Otherwise ful
From: Ville Syrjälä
intel_hdmi.has_hdmi_sink is tied into the force audio property, so it
doesn't seem like the correct way to detect HDMI monitors. Instead add
a new has_hdmi_monitor member which simply tells whether a HDMI monitor
was detected.
Not sure if this is the best way, or if we should
From: Ville Syrjälä
The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.
Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limi
This series tries fix and improve the 'Broadcast RGB' property on i915.
Currently the property takes has two values 'Full' and 'Limited 16:235'.
I'm adding a third option 'Automatic' that automagically changes between
full and limited range based on CEA-861 and DP1.2a rules.
I'm also adding suppo
On Mon, 14 Jan 2013 10:49:08 +0100, Nikola Pajkovsky
wrote:
> Daniel Vetter writes:
>
> > On Mon, Jan 14, 2013 at 7:58 AM, Nikola Pajkovsky
> > wrote:
> >> Daniel Vetter writes:
> >>
> >>> On Fri, Jan 11, 2013 at 6:26 PM, Nikola Pajkovsky
> >>> wrote:
> bug still kicking even w/ (drm/
Am 14.01.2013 12:22, schrieb Ville Syrjälä:
> On Fri, Jan 11, 2013 at 09:15:40PM +0100, Daniel Vetter wrote:
>> On Fri, Jan 11, 2013 at 05:57:51PM -0200, Rodrigo Vivi wrote:
>>> From: Shobhit Kumar
>>>
>>> Signed-off-by: Sateesh Kavuri
>>>
>>> v2: Modified and corrected the structures to be more
On Fri, Jan 11, 2013 at 09:15:40PM +0100, Daniel Vetter wrote:
> On Fri, Jan 11, 2013 at 05:57:51PM -0200, Rodrigo Vivi wrote:
> > From: Shobhit Kumar
> >
> > Signed-off-by: Sateesh Kavuri
> >
> > v2: Modified and corrected the structures to be more in line for
> > kernel coding guidelines and
On Mon, Jan 14, 2013 at 7:58 AM, Nikola Pajkovsky wrote:
> Daniel Vetter writes:
>
>> On Fri, Jan 11, 2013 at 6:26 PM, Nikola Pajkovsky
>> wrote:
>>> bug still kicking even w/ (drm/i915: Revert shrinker changes from "Track
>>> unbound pages")
>>
>> Could be a different bug, can you please attac
26 matches
Mail list logo
