On Fri, 13 Apr 2012 18:39:24 -0700
Ben Widawsky wrote:
> On Sat, 14 Apr 2012 00:24:03 +0100
> Chris Wilson wrote:
>
> > On Fri, 13 Apr 2012 16:05:14 -0700, Ben Widawsky
> > wrote:
> > > Dumb binary interfaces which allow root-only updates of our cache
> > > remapping registers. See intel-gpu-
On Sat, 14 Apr 2012 00:24:03 +0100
Chris Wilson wrote:
> On Fri, 13 Apr 2012 16:05:14 -0700, Ben Widawsky
> wrote:
> > Dumb binary interfaces which allow root-only updates of our cache
> > remapping registers. See intel-gpu-tools for how this can/should be
> > used.
>
> Initial comments: don't
On Fri, Apr 13, 2012 at 18:11, Chris Wilson wrote:
> On Fri, 13 Apr 2012 17:08:57 -0300, Eugeni Dodonov <
> eugeni.dodo...@intel.com> wrote:
> > - if (IS_HASWELL(dev))
> > + if (IS_HASWELL(dev)) {
> > intel_init_power_wells(dev);
> > + intel_hsw_prepare_ddi_buffer
On Fri, Apr 13, 2012 at 18:03, Chris Wilson wrote:
> On Fri, 13 Apr 2012 17:08:53 -0300, Eugeni Dodonov <
> eugeni.dodo...@intel.com> wrote:
> > void intel_modeset_init(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > @@ -9652,6 +9680,9 @@ void in
On Fri, Apr 13, 2012 at 18:17, Chris Wilson wrote:
> We're starting to get to ridiculous levels of indention. Break the PCH
> detection of SDVO/HDMI outputs into its own routine, and perhaps further
> down in architectures?
>
Yes, both intel_display and intel_hdmi get too overcomplex with those
p
On Fri, Apr 13, 2012 at 17:55, Chris Wilson wrote:
> The PLL split needs to be reconsidered in light of Jesse's decoupling
> PLLs from the pipes.
>
> I think we want to start annotating those so that we can keep track of
> CPU vs PCH DP/FDI links and plls.
>
Yes, I'll wait for the PLL patches to
On Fri, Apr 13, 2012 at 17:26, Chris Wilson wrote:
> On Fri, 13 Apr 2012 17:08:42 -0300, Eugeni Dodonov <
> eugeni.dodo...@intel.com> wrote:
> > With Lynx Point, we need to use SBI to communicate with the display clock
> > control. This commit adds helper functions to access the registers via
> >
On Fri, Apr 13, 2012 at 17:18, Chris Wilson wrote:
> On Fri, 13 Apr 2012 17:08:41 -0300, Eugeni Dodonov <
> eugeni.dodo...@intel.com> wrote:
> > Prevent a NULL pointer exception when we are trying to retrieve EDID data
> > from non-existent adapter.
>
> This just means that a HDMI with a garbage d
On Fri, 13 Apr 2012 16:05:14 -0700, Ben Widawsky wrote:
> Dumb binary interfaces which allow root-only updates of our cache
> remapping registers. See intel-gpu-tools for how this can/should be
> used.
Initial comments: don't bother posting a read just before a read, and do
return errors from th
Dumb binary interfaces which allow root-only updates of our cache
remapping registers. See intel-gpu-tools for how this can/should be
used.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_reg.h | 10
drivers/gpu/drm/i915/i915_sysfs.c | 103 +++
On IVB hardware we are given an interrupt whenever a parity error occurs
in the L3 cache. This is a very rare occurrence (in fact to test this I
need to use specially instrumented silicon).
When a row in the L3 cache detects a parity error, we alert userspace
via a uevent. With this information us
I'm still working on the test cases for this feature. I just wanted to
put these patches out there to make sure people were okay with the
concept.
I think it's pretty straightforward... uevent on error, and binary sysfs
interface to remap the bad rows.
If nobody has any issue with the "design" I'
On Fri, 13 Apr 2012 17:09:01 -0300, Eugeni Dodonov
wrote:
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index bdc22f5..1524966 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8743,26 +8743,45
On Fri, 13 Apr 2012 17:08:57 -0300, Eugeni Dodonov
wrote:
> - if (IS_HASWELL(dev))
> + if (IS_HASWELL(dev)) {
> intel_init_power_wells(dev);
> + intel_hsw_prepare_ddi_buffers(dev);
Give this a much more generic, more grandiose name and move the
generation specifi
On Fri, 13 Apr 2012 17:08:57 -0300, Eugeni Dodonov
wrote:
> + /* Those registers seem to be double-buffered, so write them twice */
> + for (j=0; j < 2; j++) {
> + for (i=0, reg=DDI_BUF_TRANS(port); i <
> ARRAY_SIZE(hsw_ddi_translations_fdi); i++) {
> + I9
On Fri, 13 Apr 2012 17:08:53 -0300, Eugeni Dodonov
wrote:
> void intel_modeset_init(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -9652,6 +9680,9 @@ void intel_modeset_init(struct drm_device *dev)
>
> intel_init_quirks(dev);
>
> + i
On 4/13/12 4:33 PM, Adam Jackson wrote:
Incorporates some feedback from Rodrigo and Takashi. Major themes of the
series:
- Fix the DMT list to include reduced-blanking modes
- Add modes from DMT for any range descriptor type
- Add an extra modes list for things not in DMT
- For ranges that spec
The PLL split needs to be reconsidered in light of Jesse's decoupling
PLLs from the pipes.
I think we want to start annotating those so that we can keep track of
CPU vs PCH DP/FDI links and plls.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Digital port detection on Haswell is indicated by the presence of a bit in
DDI_BUF_CTL for port A, and by a different register for ports B, C and D.
So we check for those bits during the initialization time and let the hdmi
function know about those.
Note that this bit does not indicates whether t
This needs proper enablement to avoid machine hangs, so let's just avoid
it for now.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/dr
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_hdmi.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 700bd0b..0978fb7 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/inte
v2: prevent possible conflicts with VLV.
v1 Reviewed-by: Rodrigo Vivi
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_irq.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index febddc2..1
This patch enables i915 driver to handle Haswell devices. It should go in
last, when things are working stable enough.
Signed-off-by: Eugeni Dodonov
---
drivers/char/agp/intel-agp.c|4
drivers/gpu/drm/i915/i915_drv.c |7 +++
2 files changed, 11 insertions(+)
diff --git a/dr
This patch attempts at following the modeset sequence closely, retrying
with different voltages if the DP_TP_STATUS reports a failed training.
For training, we add a table of recommended settings for FDI, HDMI and DP
connections. For FDI and DP modes, we also add the HDMI buffer
translation as the
The line time can be programmed according to the number of horizontal
pixels vs effective pixel rate ratio.
v2: improve comment as per Chris Wilson suggestion
v3: incorporate latest changes in specs.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1
This table is used for programming WR PLL clocks, used by HDMI and DVI outputs.
I split it into a separate patch to simplify the HDMI enabling patch which was
getting huge.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_hdmi.c | 388 +
1 file ch
Those are driven by DDIs on Haswell architecture, so we need to keep track
of which DDI is being used on each output.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_hdmi.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
Buffer translations for DDI links must be initialized prior to enablement.
For FDI and DP, first 9 pairs of values are used to select the connection
parameters. HDMI uses the last pair of values and ignores the first 9
pairs. So we program HDMI values in both cases, which allows HDMI to work
over b
Reviewed-by: Rodrigo Vivi
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5ee652d..33ff60e 100644
--- a/drivers/gpu/drm
On Haswell, we need to properly train the DDI buffers prior to enabling
HDMI, and enable the required clocks with correct dividers for the desired
frequency.
Also, we cannot simple reuse HDMI routines from previous generations of
GPU, as most of HDMI-specific stuff is being done via the DDI port
p
Reviewed-by: Rodrigo Vivi
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3d78686..5ee652d 100644
--- a/drivers/gpu/drm
This should be already configured when FDI auto-negotiation is done.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dcfe143..ac34457 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/driv
The iCLKIP clock is used to drive the VGA pixel clock on the PCH. In order
to do so, it must be programmed to properly do the clock ticks according
to the divisor, phase direction, phase increments and a special auxiliary
divisor for 20MHz clock.
Those values can be programmed individually, by doi
Haswell has a different way of accessing pipes and PCH-specific registers,
so avoid using legacy registers on it.
This patch will probably be reworked into a series of smaller patches once
the required plumbing lands and we won't hit those assertions anymore.
Signed-off-by: Eugeni Dodonov
---
d
On Haswell, the only PCH-connected output is the one driven by DDI E in
FDI mode, used for VGA connection. All the others are handled by the CPU.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i
This attempts to enable all the available power wells during the
initialization.
Those power wells can be enabled in parallel or on-demand, and disabled
when no longer needed, but this is out of scope of this initial
enablement. Proper tracking of who uses which power well will require
a considera
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0768f48..e4ebd39 100644
--- a/drivers/gpu/drm/i915/intel_display.c
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 73
1 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7131f38..9e3794d 100644
--- a/drivers/gpu/drm/drm_edid.c
++
Some common sizes that don't show up in DMT.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index eab60ea..26a1d33 100644
---
We want the same type for extra modes inferred from ranges.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index ab3a051..eab60ea 10
Signed-off-by: Adam Jackson
---
include/drm/drm_edid.h | 26 --
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index bcb9a66..8cefbbe 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -90,
EDID 1.4 retcons the meaning of the "GTF feature" bit to mean "is
continuous frequency", and moves the set of supported timing formulas
into the range descriptor itself. In any event, the range descriptor
can act as a filter on the DMT list without regard to a specific timing
formula.
Signed-off-
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index 4be9c1a..ab3a051 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers
Copied from the list in xserver.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 94 +-
1 files changed, 93 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1..4be9
Slightly more honest naming.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 70dcf7a..355e6a0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers
mode_in_range() handles what this was warning about.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4f52103..70dcf7a 100644
--- a/drivers/gpu/drm/
It won't find any, yet. Fix up callers to match: standard mode codes
will look prefer r-b modes for a given size if present, EST3 mode codes
will look for exactly the r-b-ness mentioned in the mode code. This
might mean fewer modes matched for EST3 mode codes between now and when
the DMT mode lis
No functional change, but will make an upcoming change clearer.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 79a3637..0a23ee5 10
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a18b0d..79a3637 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@
Incorporates some feedback from Rodrigo and Takashi. Major themes of the
series:
- Fix the DMT list to include reduced-blanking modes
- Add modes from DMT for any range descriptor type
- Add an extra modes list for things not in DMT
- For ranges that specify a formula, generate timings from the e
On Fri, 13 Apr 2012 17:08:43 -0300, Eugeni Dodonov
wrote:
> Signed-off-by: Eugeni Dodonov
> ---
> drivers/gpu/drm/i915/intel_display.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> in
On Fri, 13 Apr 2012 17:08:42 -0300, Eugeni Dodonov
wrote:
> With Lynx Point, we need to use SBI to communicate with the display clock
> control. This commit adds helper functions to access the registers via
> SBI.
>
> v2: de-inline the function and address changes in bits names
>
> v3: protect
On Fri, 13 Apr 2012 17:08:41 -0300, Eugeni Dodonov
wrote:
> Prevent a NULL pointer exception when we are trying to retrieve EDID data
> from non-existent adapter.
This just means that a HDMI with a garbage ddc_bus is never detected.
Since we control ddc_bus entirely, it means that the initialisa
They work differently, but the count is the same.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_dma.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 333b746..a
Reviewed-by: Rodrigo Vivi
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 60b1540..3d78686 100644
--- a/drivers/gpu/drm
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 36f6b8e..60b1540 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b
With Lynx Point, we need to use SBI to communicate with the display clock
control. This commit adds helper functions to access the registers via
SBI.
v2: de-inline the function and address changes in bits names
v3: protect operations with dpio_lock, increase timeout to 100 for
paranoia sake.
v1
Prevent a NULL pointer exception when we are trying to retrieve EDID data
from non-existent adapter.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_hdmi.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/int
Haswell has different DIP registers which we need to use for infoframes,
so add proper infrastructure to address that.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_hdmi.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i91
Haswell has different DIP control registers and offsets.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_reg.h | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 05d98f2..8cc53fb 100644
--- a
Those are used to program the WRPLL dividers correctly for each gives
frequency.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_reg.h |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 98579f5..05d98f2 1
v2: change bits names to align better with other bits style
Reviewed-by: Rodrigo Vivi
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_reg.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 972321f..9857
Hi forks,
Just in time for everyone's weekend, here comes the 3rd round of patches on
Haswell.
As major highlights, it also adds support for HDMI/DVI outputs and multi-head
modes (I tried with VGA and HDMI).
Other than that, it is the same patches with comments from the past round
addressed (SBI
On 4/12/12 5:35 PM, Adam Jackson wrote:
@@ -1030,6 +1026,10 @@ drm_dmt_modes_for_range(struct drm_connector *connector,
struct edid *edid,
for (i = 0; i< drm_num_dmt_modes; i++) {
if (mode_in_range(drm_dmt_modes + i, edid, timing)) {
+ if (mode_is
So, the modes that I added in that list was half got from windows on
my monitor and half requested by HP.
So let forget about other modes and focus on the one required by HP.
HP has requested the same list for everybody 3 years ago and it was
added by Windows and AMD at that time but our open driv
From: Jesse Barnes
PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
treat them as part of the pipe.
So split the code out and manage PCH PLLs separately, allocating them
when needed or trying to re-use existing PCH PLL setups when the timings
match.
v2: add num_pch_pll fiel
On 4/13/12 11:25 AM, David Airlie wrote:
I'm still intrigued about what hardware exists with a panel with a native mode
it doesn't describe.
How are we to know what the panel preferred mode is in this case?
Or is this for larger panels wanting to use smaller modes?
AFAICT, yes, this last on
At Fri, 13 Apr 2012 12:31:25 -0400,
Adam Jackson wrote:
>
> On 4/13/12 11:41 AM, Takashi Iwai wrote:
> > At Fri, 13 Apr 2012 11:30:01 -0400, Alex Deucher wrote:
> >> One thing to be careful of is that some monitors (especially LCD
> >> panels) don't like modes that are not in their EDIDs. As such
On 4/13/12 11:41 AM, Takashi Iwai wrote:
At Fri, 13 Apr 2012 11:30:01 -0400, Alex Deucher wrote:
One thing to be careful of is that some monitors (especially LCD
panels) don't like modes that are not in their EDIDs. As such when
you try and set them you often get a wonky display or more often a
At Fri, 13 Apr 2012 11:30:01 -0400,
Alex Deucher wrote:
>
> On Fri, Apr 13, 2012 at 11:13 AM, Takashi Iwai wrote:
> > At Fri, 13 Apr 2012 15:35:04 +0100,
> > Dave Airlie wrote:
> >>
> >> > I don't think we need to support all wild modes, too. But the _very_
> >> > common modes like 1366x768 and
At Fri, 13 Apr 2012 10:55:16 -0400,
Adam Jackson wrote:
>
> On 4/13/12 10:29 AM, Takashi Iwai wrote:
> > At Fri, 13 Apr 2012 10:14:46 -0400,
> > Adam Jackson wrote:
> >> Yeah, that's a bug. That's why I said it should be renamed
> >> drm_dmt_modes_for_range and run unconditionally if we find a ra
<#part sign=pgpmime>
On Thu, 12 Apr 2012 19:34:12 + (UTC), Eric Appleman
wrote:
> It's a known issue, but I've yet to find a comprehensive explanation for
> what's
> going on.
Appears to be caused by the Hi-Z code. No known solution at this
point, aside from disabling Hi-Z. Here's a script
At Fri, 13 Apr 2012 15:35:04 +0100,
Dave Airlie wrote:
>
> > I don't think we need to support all wild modes, too. But the _very_
> > common modes like 1366x768 and 1600x900 should be really supported as
> > default.
>
> You guys still haven't answered the basic question, what HW is this broken?
On 4/13/12 10:29 AM, Takashi Iwai wrote:
At Fri, 13 Apr 2012 10:14:46 -0400,
Adam Jackson wrote:
Yeah, that's a bug. That's why I said it should be renamed
drm_dmt_modes_for_range and run unconditionally if we find a range
descriptor.
Yeah, I saw your patches. Should the further work base on
On Fri, 13 Apr 2012 16:26:31 +0200, Daniel Vetter wrote:
> On Fri, Apr 13, 2012 at 03:21:42PM +0100, Chris Wilson wrote:
> > And share with i915_gem_tiling.c. Or is that overkill?
>
> The function we might want here already exists as
> i915_gem_object_needs_bit17_swizzle but I've figured that's o
> I don't think we need to support all wild modes, too. But the _very_
> common modes like 1366x768 and 1600x900 should be really supported as
> default.
You guys still haven't answered the basic question, what HW is this broken?
Can you provide some EDIDs?
Dave.
___
At Fri, 13 Apr 2012 10:14:46 -0400,
Adam Jackson wrote:
>
> On 4/12/12 7:09 PM, Rodrigo Vivi wrote:
>
> >> CVT monitors _must_ accept GTF as well, EDID says so. So functionally
> >> there's nothing wrong with the existing code.
> >
> > Actually the current code just check for gtf flag... so if a
On Fri, Apr 13, 2012 at 03:21:42PM +0100, Chris Wilson wrote:
> On Fri, 13 Apr 2012 15:51:51 +0200, Daniel Vetter
> wrote:
> > ... we will botch up the bit17 swizzling. Furthermore tiled pwrite is
> > a (now) unused slowpath, so no one really cares.
> >
> > This fixes the last swizzling issues I
On Fri, 13 Apr 2012 15:51:51 +0200, Daniel Vetter
wrote:
> ... we will botch up the bit17 swizzling. Furthermore tiled pwrite is
> a (now) unused slowpath, so no one really cares.
>
> This fixes the last swizzling issues I have with i-g-t on my bit17
> swizzling i915G. No regression, it's been b
On 4/12/12 7:09 PM, Rodrigo Vivi wrote:
CVT monitors _must_ accept GTF as well, EDID says so. So functionally
there's nothing wrong with the existing code.
Actually the current code just check for gtf flag... so if a monitor
is gtf2 or cvt this dmt modes are not being added.
Yeah, that's a
... we will botch up the bit17 swizzling. Furthermore tiled pwrite is
a (now) unused slowpath, so no one really cares.
This fixes the last swizzling issues I have with i-g-t on my bit17
swizzling i915G. No regression, it's been broken since the dawn of
gem, but it's nice for regression tracking wh
On Fri, Apr 13, 2012 at 10:27:01AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This is a command-line tool that allows us to display and modify the
> InfoFrames we send.
>
> v2: use argv instead of stdin
>
> Signed-off-by: Paulo Zanoni
Merged, thanks for the patch.
-Daniel
> ---
>
> H
From: Paulo Zanoni
This is a command-line tool that allows us to display and modify the
InfoFrames we send.
v2: use argv instead of stdin
Signed-off-by: Paulo Zanoni
---
Hi
I sent this tool a long time ago, received reviews (asking to read
input from argv instead of stdin), but then kinda ga
On Wed, Apr 11, 2012 at 04:42:13PM -0700, Eric Anholt wrote:
> On Wed, 11 Apr 2012 22:12:45 +0200, Daniel Vetter
> wrote:
> > Hi all,
> >
> > This patch series is inspired by Ben's ring->get|put_irq cleanup for gen6+
> > and
> > my perpetual hatred for intel_ringbuffer.c.
> >
> > It's a lot of
On Fri, 13 Apr 2012 11:13:53 +0200, Daniel Vetter wrote:
> On Thu, Apr 12, 2012 at 06:03:30PM -0700, Ben Widawsky wrote:
> > On Wed, 11 Apr 2012 22:12:59 +0200
> > Daniel Vetter wrote:
> >
> > > Now that these are properly refactored this additional indirection
> > > doesn't really buy us anythi
On Thu, Apr 12, 2012 at 06:03:30PM -0700, Ben Widawsky wrote:
> On Wed, 11 Apr 2012 22:12:59 +0200
> Daniel Vetter wrote:
>
> > Now that these are properly refactored this additional indirection
> > doesn't really buy us anything but confusion. Hence inline them.
> >
> > This duplicates the iron
On Thu, Apr 12, 2012 at 06:05:14PM -0700, Ben Widawsky wrote:
> On Wed, 11 Apr 2012 22:12:58 +0200
> Daniel Vetter wrote:
>
> > We already disallow initialition of gem in this case in the
> > corresponding ioctl, so don't bother setting up the gem support ring
> > functions in the legacy dri rend
On Thu, Apr 12, 2012 at 05:54:45PM -0700, Ben Widawsky wrote:
> On Wed, 11 Apr 2012 22:12:57 +0200
> Daniel Vetter wrote:
>
> > They're indentical, so just kill one. Also give the other a prefix to
> > distinguish it from the gen6+ functions - this add_request function is
> > not really generic c
89 matches
Mail list logo
