Dear All,
In intel 3D driver, It seems there are two vertex buffers： one is "struct
intel_buffer_object" (VBO), which catches all vertex
building and drawing commands, such as glVertex3f; Another is "struct prim" in
"struct intel_context", into which functions like intel_draw_triangle
accumula
On Mon, 15 Oct 2012 20:59:22 +0200
Daniel Vetter wrote:
> On Wed, Oct 03, 2012 at 07:34:23PM -0700, Ben Widawsky wrote:
> > That fix was the disable render deptch cache pipeline flush
> >
> > Signed-off-by: Ben Widawsky
>
> I've stumbled over the same one, but my docs here suggest i965g/gm45
>
On Tue, Oct 16, 2012 at 6:16 AM, Rodrigo Vivi wrote:
> On the worst scenario, users with new hardwares and old kernel from enabling
> times can get black screens.
> So, now on, this i915_perliminary_hw_support variable shall be used by all
> upcoming platforms that are still under enabling.
>
>
Hi
2012/10/15 Daniel Vetter :
> On Mon, Oct 15, 2012 at 10:29 PM, Adam Jackson wrote:
>> On 10/15/12 2:51 PM, Paulo Zanoni wrote:
>>
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>> b/drivers/gpu/drm/i915/intel_display.c
>>> index f48986b9..ba40aa7 100644
>>> --- a/drivers/gpu/drm/i915/i
On Mon, Oct 15, 2012 at 10:29 PM, Adam Jackson wrote:
> On 10/15/12 2:51 PM, Paulo Zanoni wrote:
>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index f48986b9..ba40aa7 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm
On 10/15/12 2:51 PM, Paulo Zanoni wrote:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f48986b9..ba40aa7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5356,7 +5356,8 @@ static int haswell_crtc_mo
On the worst scenario, users with new hardwares and old kernel from enabling
times can get black screens.
So, now on, this i915_perliminary_hw_support variable shall be used by all
upcoming platforms that are still under enabling.
Although it is uncomfortable for developers use this extra variab
On Sat, Sep 29, 2012 at 01:07:35PM -0700, Ben Widawsky wrote:
> On Fri, 28 Sep 2012 10:13:26 +1000
> Dave Airlie wrote:
>
> > On Fri, Sep 28, 2012 at 4:05 AM, Jesse Barnes
> > wrote:
> > > On Wed, 26 Sep 2012 10:34:01 -0700
> > > Ben Widawsky wrote:
> > >
> > >> BIOS should be setting the mini
I'll repost it, looks like last message got lost.
Am 14.10.2012 14:49, schrieb Oleksij Rempel:
Am 14.10.2012 10:55, schrieb Daniel Vetter:
On Sun, Oct 14, 2012 at 9:18 AM, Oleksij Rempel
wrote:
With latest kernel (vanilla/master, or intel.drm-next) i do not have
image
on build in screen (eDP)
On Thu, Sep 27, 2012 at 11:06:21AM -0700, Jesse Barnes wrote:
> On Wed, 26 Sep 2012 10:34:02 -0700
> Ben Widawsky wrote:
>
> > CC: Jesse Barnes
> > Signed-off-by: Ben Widawsky
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
On Wed, Oct 03, 2012 at 07:34:23PM -0700, Ben Widawsky wrote:
> That fix was the disable render deptch cache pipeline flush
>
> Signed-off-by: Ben Widawsky
I've stumbled over the same one, but my docs here suggest i965g/gm45 need
it, too:
http://cgit.freedesktop.org/~danvet/drm/commit/?h=ilk-wa
From: Paulo Zanoni
This is the final remaining piece of Haswell DP enablement. After this
patch, just calling intel_dp_init on any port will make DP work. We
still do not do this because we're currently initializing HDMI on all
the ports, so if we replace intel_hdmi_init with intel_dp_init, we
wi
From: Paulo Zanoni
Previous patch "drm/i915: add basic Haswell DP link train bits"
implemented the basic structure to set the voltage levels and training
patterns. This patch adds the higher-level bits that are part of the
mode set sequence and hot plug.
Signed-off-by: Paulo Zanoni
---
drivers
From: Paulo Zanoni
We should only write the DDI_BUF_CTL at this point for HDMI/DVI. For
DP we need to do this earlier, and the values written to the register
are also different.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 21 -
1 file changed, 12 inse
From: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 817ebb2..9324636 100644
--- a/drivers/gpu/drm/i915/intel_ddi.
From: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index c6ddba9..817ebb2 100644
--- a/drivers/gpu/drm/i915/intel
From: Paulo Zanoni
The old rule that the AUX registers are just an offset (+4 and +10)
from output_reg is not true anymore, since output_reg in on the CPU
and some AUX regs are on the PCH.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h | 8
drivers/gpu/drm/i915/intel
From: Paulo Zanoni
We have to write the correct values inside intel_dp_set_m_n and then
prevent these values from being overwritten later.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
drivers/gpu/drm/i915/intel_dp.c | 7 ++-
2 files changed, 8 insertio
From: Paulo Zanoni
Much simpler and looks more like the M/N code inside intel_display.c.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_dp.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
From: Paulo Zanoni
Previously, the DP register was used for everything. On Haswell, it
was split into DDI_BUF_CTL (which is the new intel_dp->DP register)
and DP_TP_CTL.
The logic behind this patch is based on a patch written by Shobhit
Kumar, but the way the code was written is very different.
From: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 61 +---
drivers/gpu/drm/i915/intel_dp.c | 28 ++
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed, 62 insertions(+), 28 deletions(-)
diff --git a/
From: Paulo Zanoni
Just a missing register. There is no problem to run this code when the
output is HDMI.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/
From: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index e58df71..5071370 100644
--- a/drivers/gpu/d
From: Paulo Zanoni
In theory, all the DDI pipe settings should be set here, including
timing and M/N registers. For now, let's just set the DP MSA
attributes.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h | 10 ++
drivers/gpu/drm/i915/intel_ddi.c | 34 +++
From: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 34 ++
drivers/gpu/drm/i915/intel_dp.c | 5 -
drivers/gpu/drm/i915/intel_drv.h | 5 +
3 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/
From: Paulo Zanoni
Hi
>From the first 47 patches sent a few days ago the first 10 were already
committed, so now I'm sending patches 11-24 which add the basic DP enablement.
After these patches you will notice that DP will still not work, but if you
replace intel_hdmi_init with intel_dp_init (in
On Mon, Oct 15, 2012 at 07:16:26PM +0200, Daniel Vetter wrote:
> On Mon, Oct 15, 2012 at 5:11 PM, Greg KH wrote:
> > On Mon, Oct 15, 2012 at 10:11:22AM +0200, Daniel Vetter wrote:
> >> Hi Greg&stable-team,
> >>
> >> The below patch papers over a graphics corruption issue in 3.5/3.6. The
> >> regre
On 10/14/2012 04:40 PM, Bruno Prémont wrote:
On Sun, 14 October 2012 Mark Hounschell wrote:
I gave it a try. I don't think it liked my kernel cmdline. dmesg attached.
There is a lot more in there now that nomodeset is gone and the debug is
turned on.
# ls -al /lib/firmware/edid/lg42lb9df.edid
On 10/14/2012 01:22 PM, Bruno Prémont wrote:
Hi Mark,
On Sun, 14 October 2012 Mark Hounschell wrote:
I've taken the EDID data from that service manual. I've looked at the
EDID-Howto for how to specify the connector but all I see is:
"An EDID data set will only be used for a particular connect
On 10/14/2012 07:03 AM, Bruno Prémont wrote:
On Sun, 14 October 2012 Mark Hounschell wrote:
On 10/14/2012 04:41 AM, Bruno Prémont wrote:
Your best solution is probably to write an EDID blob (or reuse one you find
somewhere) that provides at least one mode matching your TV's native mode
(probab
On 10/14/2012 11:55 AM, Bruno Prémont wrote:
On Sun, 14 October 2012 Daniel Vetter wrote:
On Sun, Oct 14, 2012 at 5:41 PM, Mark Hounschell wrote:
There is something amiss. Here is my i915_pci_probe routine. I Added a
couple more printks. NONE of these show up in dmesg. Not even the "Entered"
On Mon, Oct 15, 2012 at 5:11 PM, Greg KH wrote:
> On Mon, Oct 15, 2012 at 10:11:22AM +0200, Daniel Vetter wrote:
>> Hi Greg&stable-team,
>>
>> The below patch papers over a graphics corruption issue in 3.5/3.6. The
>> regression happened due to pwrite tunings in 3.5, which made cpu relocations
>>
On Mon, 15 Oct 2012 10:42:03 +0100
Chris Wilson wrote:
> On Mon, 15 Oct 2012 09:37:00 +0100, Chris Wilson
> wrote:
> > On Sun, 14 Oct 2012 19:10:38 -0700, Jesse Barnes
> > wrote:
> > > The BIOS shouldn't be touching this memory across suspend/resume, so
> > > just leave it alone. This saves
On Mon, 15 Oct 2012 09:41:33 +0200
Daniel Vetter wrote:
> On Sun, Oct 14, 2012 at 07:10:38PM -0700, Jesse Barnes wrote:
> > The BIOS shouldn't be touching this memory across suspend/resume, so
> > just leave it alone. This saves us ~50ms on resume on my T420.
>
> Is that 50ms still accurate wit
On Mon, Oct 15, 2012 at 10:11:22AM +0200, Daniel Vetter wrote:
> Hi Greg&stable-team,
>
> The below patch papers over a graphics corruption issue in 3.5/3.6. The
> regression happened due to pwrite tunings in 3.5, which made cpu relocations
> much more likely.
>
> The issue seems to have disappea
On Mon, 15 Oct 2012 09:37:00 +0100, Chris Wilson
wrote:
> On Sun, 14 Oct 2012 19:10:38 -0700, Jesse Barnes
> wrote:
> > The BIOS shouldn't be touching this memory across suspend/resume, so
> > just leave it alone. This saves us ~50ms on resume on my T420.
> >
> > Signed-off-by: Jesse Barnes
On Sun, 14 Oct 2012 19:10:36 -0700, Jesse Barnes
wrote:
> The console lock can be contended, so rather than prevent other drivers
> after us from being held up, queue the console suspend into the global
> work queue that can happen anytime. I've measured this to take around
> 200ms on my T420.
On Sun, 14 Oct 2012 19:10:38 -0700, Jesse Barnes
wrote:
> The BIOS shouldn't be touching this memory across suspend/resume, so
> just leave it alone. This saves us ~50ms on resume on my T420.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_drv.c |7 ++-
> 1 file chan
Hi Greg&stable-team,
The below patch papers over a graphics corruption issue in 3.5/3.6. The
regression happened due to pwrite tunings in 3.5, which made cpu relocations
much more likely.
The issue seems to have disappeared in 3.7-rc1, but it takes a few days to test
a patch, so we haven't figure
On Sun, Oct 14, 2012 at 07:10:37PM -0700, Jesse Barnes wrote:
> Communicating via the mailbox registers with the PCU can take quite
> awhile. And updating the ring frequency or enabling turbo is not
> something that needs to happen synchronously, so take it out of our init
> and resume paths to sp
On Sun, Oct 14, 2012 at 07:10:38PM -0700, Jesse Barnes wrote:
> The BIOS shouldn't be touching this memory across suspend/resume, so
> just leave it alone. This saves us ~50ms on resume on my T420.
Is that 50ms still accurate with wc gtt ptes?
-Daniel
>
> Signed-off-by: Jesse Barnes
> ---
> d
On Mon, Oct 15, 2012 at 2:49 PM, Jesse Barnes wrote:
> On Mon, 15 Oct 2012 12:32:05 +1000
> Dave Airlie wrote:
>
>> > The console lock can be contended, so rather than prevent other drivers
>> > after us from being held up, queue the console suspend into the global
>> > work queue that can happen
42 matches
Mail list logo
