Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services

[Adam Jackson]

On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote:
> On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer  wrote:
> > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > > pre-merge CI.
> > 
> > Thanks for the suggestion! I implemented something like this for Mesa:
> > 
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
> 
> I wouldn't mind manually triggering pipelines, but unless there is
> some trick I'm not realizing, it is super cumbersome.  Ie. you have to
> click first the container jobs.. then wait.. then the build jobs..
> then wait some more.. and then finally the actual runners.  That would
> be a real step back in terms of usefulness of CI.. one might call it a
> regression :-(

I think that's mostly a complaint about the conditionals we've written
so far, tbh. As I commented on the bug, when I clicked the container
job (which the rules happen to have evaluated to being "manual"), every
job (recursively) downstream of it got enqueued, which isn't what
you're describing. So I think if you can describe the UX you'd like we
can write rules to make that reality.

But I don't really know which jobs are most expensive in terms of
bandwidth, or storage, or CPUs, and even if I knew those I don't know
how to map those to currency. So I'm not sure if the UI we'd like would
minimize the cost the way we'd like.

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v2,1/3] drm/dp: Introduce EDID-based quirks

[Adam Jackson]

On Tue, 2020-02-11 at 13:33 -0500, Lyude Paul wrote:
> The whole point of using OUIs is so that we can recognize certain
> devices and potentially apply quirks for them. Normally this should work
> quite well, but there appears to be quite a number of laptop panels out
> there that will fill the OUI but not the device ID. As such, for devices
> like this I can't imagine it's a very good idea to try relying on OUIs
> for applying quirks. As well, some laptop vendors have confirmed to us
> that their panels have this exact issue.
> 
> So, let's introduce the ability to apply DP quirks based on EDID
> identification. We reuse the same quirk bits for OUI-based quirks, so
> that callers can simply check all possible quirks using
> drm_dp_has_quirk().

With the bug URL fixed in 2/3, series is:

Reviewed-by: Adam Jackson 

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v2, 2/3] drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panel

[Adam Jackson]

On Tue, 2020-02-11 at 13:33 -0500, Lyude Paul wrote:

> - if (!intel_dp_aux_display_control_capable(intel_connector))
> + /*
> +  * There are a lot of machines that don't advertise the backlight
> +  * control interface to use properly in their VBIOS, :\
> +  */
> + if (dev_priv->vbt.backlight.type !=
> + INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
> + !drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
> +   DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
> + DRM_DEV_INFO(dev->dev,
> +  "Panel advertises DPCD backlight support, but "
> +  "VBT disagrees. If your backlight controls "
> +  "don't work try booting with "
> +  "i915.enable_dpcd_backlight=1. If your machine "
> +  "needs this, please file a _new_ bug report on "
> +  "bugs.freedesktop.org against DRI -> "
> +  "DRM/Intel\n");

Bugzilla's been put out of our misery, probably this should point to
gitlab instead.

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: customize DPCD brightness control for specific panel

[Adam Jackson]

On Mon, 2019-10-07 at 12:08 +0300, Jani Nikula wrote:

> The problem with the EDID quirks is that exposing the quirks sticks out
> like a sore thumb. Thus far all of it has been contained in drm_edid.c
> and they affect how the EDID gets parsed, for all drivers. Obviously
> this could be changed, but is it the right thing to do?
> 
> What I suggested was, check the OUI only, and if it matches, do
> more. Perhaps there's something in the 0x300 range of DPCD offsets that
> you can read? Or perhaps you need to write the source OUI first, and
> then do that.

My issue isn't really with identifying the panel from EDID rather than
DPCD, whichever identifier is most specific is probably the best thing
to use. It's more that this quirk is identified in common code but only
applied in one driver. If this panel were ever to be attached to some
other source, they might well want to apply the same kind of fix. My
(admittedly naïve) reading of the OUI handshake process is that when
the source device writes an OUI to DP_SOURCE_OUI it is telling the sink
"I'm about to issue commands that conform to _this_ vendor's own
conventions". If that convention communicates information that is
entirely contained within AUXCH transactions (and doesn't, for example,
require looking at some other strapping pin or external device) then in
principle it doesn't matter if the source device "matches" that OUI; it
would be legal for an AMD GPU to write the same sequence and expect the
same reaction, should that panel be attached to an AMD GPU.

So, it would be nice to know exactly what that protocol is meant to do,
if it applies only to this specific panel or anything else with the
same TCON, how one would identify such TCONs in the wild other than
EDID, if it relies on an external PWM or something, etc. And it might
make sense for now to make this a (shudder) driver-specific EDID quirk
rather than match by DPCD, at least until we know if the panel is ever
seen attached to other source devices and if the OUI convention is
self-contained.

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: customize DPCD brightness control for specific panel

[Adam Jackson]

On Sat, 2019-10-05 at 05:58 +0800, Lee Shawn C wrote:
> This panel (manufacturer is SDC, product ID is 0x4141)
> used manufacturer defined DPCD register to control brightness
> that not defined in eDP spec so far. This change follow panel
> vendor's instruction to support brightness adjustment.

I'm sure this works, but this smells a little funny to me.

> + /* Samsung eDP panel */
> + { "SDC", 0x4141, EDID_QUIRK_NON_STD_BRIGHTNESS_CONTROL },

It feels a bit like a layering violation to identify eDP behavior
changes based on EDID. But I'm not sure there's any obvious way to
identify this device by its DPCD. The Sink OUI (from the linked
bugzilla) seems to be 0011F8, which doesn't match up to anything in my
oui.txt...

> @@ -1953,6 +1956,7 @@ static u32 edid_get_quirks(const struct edid *edid)
>  
>   return 0;
>  }
> +EXPORT_SYMBOL(edid_get_quirks);

If we're going to export this it should probably get a drm_ prefix.

> +#define DPCD_EDP_GETSET_CTRL_PARAMS  0x344
> +#define DPCD_EDP_CONTENT_LUMINANCE   0x346
> +#define DPCD_EDP_PANEL_LUMINANCE_OVERRIDE0x34a
> +#define DPCD_EDP_BRIGHTNESS_NITS 0x354
> +#define DPCD_EDP_BRIGHTNESS_OPTIMIZATION 0x358
> +
> +#define EDP_CUSTOMIZE_MAX_BRIGHTNESS_LEVEL   (512)

This also seems a bit weird, the 0x300-0x3FF registers belong to the
_source_ DP device. But then later...

> + /* write source OUI */
> + write_val[0] = 0x00;
> + write_val[1] = 0xaa;
> + write_val[2] = 0x01;

Oh hey, you're writing (an) Intel OUI to the Source OUI, so now it
makes sense that you're writing to registers whose behavior the source
defines. But this does raise the question: is this just a convention
between Intel and this particular panel? Would we expect this to work
with other similar panels? Is there any way to know to expect this
convention from DPCD instead?

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/edid: Remove defunct EDID_QUIRK_FIRST_DETAILED_PREFERRED

[Adam Jackson]

On Fri, 2019-03-22 at 19:42 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything.
> Its counterpart in f86EdidModes.c is properly hooked up but somehow
> that functionality was lost when it was copied into the kernel.
> 
> The concensus seems to be that this quirk is a bit misguided
> anyway so let's nuke the leftovers.

Reviewed-by: Adam Jackson 

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Pick the first mode from EDID as the fixed mode when there is no preferred mode

[Adam Jackson]

On Thu, 2019-03-21 at 15:24 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Some monitors apparently forget to mark any mode as preferred in the
> EDID. In this particular case we have a very generic looking ID
> "PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk
> doesn't seem particularly wise. Also the quirk we have
> (EDID_QUIRK_FIRST_DETAILED_PREFERRED) is actually defunct so we'd
> have to fix it first.
> 
> When there is no preferred mode we currently fall back to the VBT.
> That approach fails us here as the VBT mode is 1024x768 whereas
> the panel resolution is 800x600. So instead of falling back to the
> VBT when there is no preferred mode let's just pick the first
> probed mode. Only if the EDID provided no modes we fall back to
> the VBT.
> 
> For this machine the VBIOS would appear to select the 800x600
> 60Hz EST mode rather than the first detailed mode (which is
> the new fallback will pick). The two modes differ only by
> having opposite sync polarities, which does not seem to matter
> to the panel in question.

Took me a moment to realize this was only about panels on i915, and not
any monitor/connector with no preferred modes. Looks sane to me though.

Reviewed-by: Adam Jackson 

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/fourcc: Fix conflicting Y41x definitions

[Adam Jackson]

On Tue, 2019-03-19 at 13:17 +0100, Maarten Lankhorst wrote:
> There has unfortunately been a conflict with the following 3 commits:
> 
> commit e9961ab95af81b8d29054361cd5f0c575102cf87
> Author: Ayan Kumar Halder 
> Date:   Fri Nov 9 17:21:12 2018 +
> drm: Added a new format DRM_FORMAT_XVYU2101010
> 
> commit 7ba0fee247ee7a36b3bfbed68f6988d980aa3aa3
> Author: Brian Starkey 
> Date:   Fri Oct 5 10:27:00 2018 +0100
> 
> drm/fourcc: Add AFBC yuv fourccs for Mali
> 
> and
> 
> commit 50bf5d7d595fd0705ef3785f80e679b6da501e5b
> Author: Swati Sharma 
> Date:   Mon Mar 4 17:26:33 2019 +0530
> 
> drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
> 
> Unfortunately gcc didn't warn about the redefinitions, because the
>

... sentence got cut off here.

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] topic/hdr-formats

[Adam Jackson]

On Mon, 2019-03-11 at 12:19 +0100, Maarten Lankhorst wrote:
> Hey,
> 
> Op 07-03-2019 om 18:12 schreef Adam Jackson:
> > On Thu, 2019-03-07 at 10:48 +0100, Maarten Lankhorst wrote:
> > > Hi Sean and Joonas,
> > > 
> > > Here's a pull request for HDR format enabling in i915. Can this be pulled 
> > > to drm-misc-next and dinq?
> > Could you also add Kevin Strasser's patch for FP16 formats? For that
> > matter I'd like to see FP32 added too, but I don't think there's been a
> > patch sent for that yet.
> 
> Added kevin to CC.
> 
> Is the mesa side considered completely reviewed then?

Is that strictly necessary for just adding a fourcc? I get wanting to
see a real userspace consumer first, but this is just allocating some
magic numbers not promising that a certain ioctl behaves a certain way.

That said, I did say r-b for the Mesa series as a whole. Daniel Stone
had some comments on 13/13 that made it sound like it (that specific
patch) was unnecessary/undesirable, but everything before that looked
great to me, and even if we only merged the first 12 we'd still have
FP16 wired through for the gbm EGL platform, meaning HDR scanout could
actually be a thing.

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] topic/hdr-formats

[Adam Jackson]

On Thu, 2019-03-07 at 10:48 +0100, Maarten Lankhorst wrote:
> Hi Sean and Joonas,
> 
> Here's a pull request for HDR format enabling in i915. Can this be pulled to 
> drm-misc-next and dinq?

Could you also add Kevin Strasser's patch for FP16 formats? For that
matter I'd like to see FP32 added too, but I don't think there's been a
patch sent for that yet.

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/edid: If no preferred mode is found assume the first mode is preferred

[Adam Jackson]

On Wed, 2019-02-27 at 23:03 +0200, Ville Syrjälä wrote:

> So instead of putting this logic into the EDID parser I guess we
> could just put it into the i915 fixed mode code. But then I suppose
> we should also fix EDID_QUIRK_FIRST_DETAILED_PREFERRED (assuming it
> exists for a good reason).

I don't think it has any good reason to exist, tbh. The commit adding
it to xserver was for the Philips 107P5, which - being a CRT - would be
entirely expected to not have the preferred bit set. We should probably
have handled that instead by letting the "target a DPI near 96" logic
handle things.

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/edid: If no preferred mode is found assume the first mode is preferred

[Adam Jackson]

On Wed, 2019-02-27 at 19:14 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Some monitors apparently forget to mark any mode as preferred in the
> EDID. In this particular case we have a very generic looking ID
> "PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk
> doesn't seem particularly wise. Also the quirk we have
> (EDID_QUIRK_FIRST_DETAILED_PREFERRED) is actually defunct so we'd
> have to fix it first.
>
> As a generic fallback let's just mark the first probed mode (which
> should be the first detailed mode, assuming there are any) as
> preferred.

What problem is this trying to fix? Userspace (and drm for that matter)
is typically going to pick the first mode in the list anyway if there's
none marked as preferred. Not having any preferred modes was pretty
common on CRTs IIRC.

The other major case I've seen of a monitor with no preferred mode are
the early dual-link DVI displays without internal scalers (Apple
Cinema, Dell 3007WFP, etc). You end up with 1280x800 first in the list
since 2560x1600 doesn't fit in a single DVI link. It might be nice if
such monitors decided their preferred mode based on the link
capabilities; if you know it's a dual-link capable port, you'd probably
prefer 2560x1600.

Does it make more sense to run the "infer a preferred mode" logic after
we've done mode validation for the output?

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 0/3] Support 64 bpp half float formats

[Adam Jackson]

On Fri, 2019-02-08 at 13:49 -0800, Kevin Strasser wrote:
> This series defines new formats and adds implementation to the i915 driver.
> Since posting v1 I have removed the pixel normalize property, as it's not 
> needed
> for basic functionality. Also, I have been working on adding support to
> userspace, but we can't land any patches until drm_fourcc.h has been updated
> here.

Series is:

Reviewed-by: Adam Jackson 

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab

[Adam Jackson]

On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote:

> - Sticking to fdo bugzilla and disabling gitlab issues for at least
>   drm-intel for the time being. Doing that migration in the same go is a
>   bit much I think. Reassignment across bugzilla and gitlab will be an
>   issue.

Can you elaborate a bit on the issues here? The actual move-the-bugs
process has been pretty painless for the parts of xorg we've done so
far.

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 1/3] drm: Add colorspace property

[Adam Jackson]

On Tue, 2018-07-24 at 21:15 +0530, Uma Shankar wrote:

> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -209,6 +209,17 @@
>  #define DRM_MODE_CONTENT_PROTECTION_DESIRED 1
>  #define DRM_MODE_CONTENT_PROTECTION_ENABLED 2
>  
> +enum extended_colorimetry {
> + EXTENDED_COLORIMETRY_XV_YCC_601 = 0,
> + EXTENDED_COLORIMETRY_XV_YCC_709,
> + EXTENDED_COLORIMETRY_S_YCC_601,
> + EXTENDED_COLORIMETRY_ADOBE_YCC_601,
> + EXTENDED_COLORIMETRY_ADOBE_RGB,
> + EXTENDED_COLORIMETRY_BT2020_RGB,
> + EXTENDED_COLORIMETRY_BT2020_YCC,
> + EXTENDED_COLORIMETRY_BT2020_CYCC,
> +};

This doesn't give any way to distinguish "not set" from BT.601, which
I'm not sure I like.

Is this enum simply built to match the values you're injecting into the
InfoFrame? Would we need a different enum for DisplayPort?

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Heads up: Xorg repository moves

[Adam Jackson]

Hey, if you haven't been following xorg-devel@, we're planning to move
our repository hosting to freedesktop's gitlab instance. This is
basically transparent from the client side, your git urls won't change,
but you get continuous integration hooks for free if you want them.
Longer term, we'd like to move from a bugzilla/mailing list model to
tracking issues and merge requests in gitlab as well, but we're leaving
that optional and per-component.

I'd hoped to also take this opportunity to merge several of the X-
related projects under the Xorg namespace and (gitlab) group, in
particular openchrome nouveau and xcb. Individual subproject ACLs are
much easier to manage in gitlab, so this is also something of a
formality. But I understand if people would prefer to keep their own
top-level project identity, and if this is your project, please do
speak up.

There are also some questions about which repos are worth
migrating/archiving or moving to other namespaces. For details please
see the freedesktop gitlab ticket:

https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/40

We would like to complete the majority of the move by Monday, July 9,
but can defer any given component as long as needed. Please raise any
issues or suggestions on the ticket.

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [ANNOUNCE] xorg-server 1.20.0

[Adam Jackson]

On Tue, 2018-05-15 at 12:51 +0200, Thomas Klausner wrote:

> > Those specific fixes could probably be cherry-picked to the version
> > you're trying to build, but it may be worthwhile to update to git
> > master anyway.
> 
> I'm packaging for NetBSD, and we prefer to package tarballs, not git
> master. Perhaps someone can make a new release? 2.99.917 doesn't even
> compile against server version 1.19...

It's starting to be difficult to buy Intel hardware at retail that
2.99.917 can drive at all, it's been over three years since it was
released. The project looks fairly quiescent these days. I don't know
if Intel has some formal release process they want to use, but I figure
intel-gfx@ would be the place to ask (cc'd).

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] agp/intel-gtt: Drop the code for gen > 1

[Adam Jackson]

On Fri, 2018-04-20 at 20:20 +, Patchwork wrote:

>  Possible regressions 
> 
> igt@drv_module_reload@basic-no-display:
>   fi-elk-e7500:   PASS -> DMESG-FAIL +2
> 
> igt@drv_module_reload@basic-reload:
>   fi-gdg-551: PASS -> DMESG-FAIL +2
>   fi-blb-e6850:   PASS -> DMESG-FAIL +2
>   fi-ilk-650: PASS -> DMESG-FAIL +2
> 
> igt@drv_module_reload@basic-reload-inject:
>   fi-bwr-2160:PASS -> DMESG-FAIL +2

Fun, apparently that code isn't purely gen1. Feel free to ignore this
series.

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] agp/intel-gtt: Drop the code for gen > 1

[Adam Jackson]

The gen2+ code has been unreachable since:

commit ebb7c78d358b2ea45c7d997423e6feb42e5ce4ef
Author: Daniel Vetter <daniel.vet...@ffwll.ch>
Date:   Wed Jan 27 14:38:00 2016 +0100

agp/intel-gtt: Only register fake agp driver for gen1

Signed-off-by: Adam Jackson <a...@redhat.com>
---
 drivers/char/agp/intel-gtt.c | 631 +--
 1 file changed, 18 insertions(+), 613 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index c6271ce250b3..82459b886868 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -40,12 +40,6 @@
 #endif
 
 struct intel_gtt_driver {
-   unsigned int gen : 8;
-   unsigned int is_g33 : 1;
-   unsigned int is_pineview : 1;
-   unsigned int is_ironlake : 1;
-   unsigned int has_pgtbl_enable : 1;
-   unsigned int dma_mask_size : 8;
/* Chipset specific GTT setup */
int (*setup)(void);
/* This should undo anything done in ->setup() save the unmapping
@@ -88,12 +82,6 @@ static struct _intel_private {
unsigned int gtt_mappable_entries;
 } intel_private;
 
-#define INTEL_GTT_GEN  intel_private.driver->gen
-#define IS_G33 intel_private.driver->is_g33
-#define IS_PINEVIEWintel_private.driver->is_pineview
-#define IS_IRONLAKEintel_private.driver->is_ironlake
-#define HAS_PGTBL_EN   intel_private.driver->has_pgtbl_enable
-
 #if IS_ENABLED(CONFIG_AGP_INTEL)
 static int intel_gtt_map_memory(struct page **pages,
unsigned int num_entries,
@@ -335,212 +323,27 @@ static void i810_write_entry(dma_addr_t addr, unsigned 
int entry,
 
 static resource_size_t intel_gtt_stolen_size(void)
 {
-   u16 gmch_ctrl;
-   u8 rdct;
-   int local = 0;
-   static const int ddt[4] = { 0, 16, 32, 64 };
-   resource_size_t stolen_size = 0;
-
-   if (INTEL_GTT_GEN == 1)
-   return 0; /* no stolen mem on i81x */
-
-   pci_read_config_word(intel_private.bridge_dev,
-I830_GMCH_CTRL, _ctrl);
-
-   if (intel_private.bridge_dev->device == PCI_DEVICE_ID_INTEL_82830_HB ||
-   intel_private.bridge_dev->device == PCI_DEVICE_ID_INTEL_82845G_HB) {
-   switch (gmch_ctrl & I830_GMCH_GMS_MASK) {
-   case I830_GMCH_GMS_STOLEN_512:
-   stolen_size = KB(512);
-   break;
-   case I830_GMCH_GMS_STOLEN_1024:
-   stolen_size = MB(1);
-   break;
-   case I830_GMCH_GMS_STOLEN_8192:
-   stolen_size = MB(8);
-   break;
-   case I830_GMCH_GMS_LOCAL:
-   rdct = 
readb(intel_private.registers+I830_RDRAM_CHANNEL_TYPE);
-   stolen_size = (I830_RDRAM_ND(rdct) + 1) *
-   MB(ddt[I830_RDRAM_DDT(rdct)]);
-   local = 1;
-   break;
-   default:
-   stolen_size = 0;
-   break;
-   }
-   } else {
-   switch (gmch_ctrl & I855_GMCH_GMS_MASK) {
-   case I855_GMCH_GMS_STOLEN_1M:
-   stolen_size = MB(1);
-   break;
-   case I855_GMCH_GMS_STOLEN_4M:
-   stolen_size = MB(4);
-   break;
-   case I855_GMCH_GMS_STOLEN_8M:
-   stolen_size = MB(8);
-   break;
-   case I855_GMCH_GMS_STOLEN_16M:
-   stolen_size = MB(16);
-   break;
-   case I855_GMCH_GMS_STOLEN_32M:
-   stolen_size = MB(32);
-   break;
-   case I915_GMCH_GMS_STOLEN_48M:
-   stolen_size = MB(48);
-   break;
-   case I915_GMCH_GMS_STOLEN_64M:
-   stolen_size = MB(64);
-   break;
-   case G33_GMCH_GMS_STOLEN_128M:
-   stolen_size = MB(128);
-   break;
-   case G33_GMCH_GMS_STOLEN_256M:
-   stolen_size = MB(256);
-   break;
-   case INTEL_GMCH_GMS_STOLEN_96M:
-   stolen_size = MB(96);
-   break;
-   case INTEL_GMCH_GMS_STOLEN_160M:
-   stolen_size = MB(160);
-   break;
-   case INTEL_GMCH_GMS_STOLEN_224M:
-   stolen_size = MB(224);
-   break;
-   case INTEL_GMCH_GMS_STOLEN_352M:
-   stolen_size = MB(352);
-   break;
-   default:
-   stolen_size = 0;
-   break;
-   }
-   }
-
-   if 

[Intel-gfx] [PATCH 2/2] drm/i915: Only build INTEL_GTT on 32-bit x86

[Adam Jackson]

The i810 was attached to Pentium III motherboards, no 64-bit CPU is ever
going to have one.

Signed-off-by: Adam Jackson <a...@redhat.com>
---
 drivers/gpu/drm/i915/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index dfd95889f4b7..0f2a98c9d5af 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -2,7 +2,7 @@ config DRM_I915
tristate "Intel 8xx/9xx/G3x/G4x/HD Graphics"
depends on DRM
depends on X86 && PCI
-   select INTEL_GTT
+   select INTEL_GTT if X86_32
select INTERVAL_TREE
# we need shmfs for the swappable backing store, and in particular
# the shmem_readpage() which depends upon tmpfs
-- 
2.17.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] dri2: Sync i965_pci_ids.h from Mesa.

[Adam Jackson]

On Wed, 2018-03-07 at 07:46 -0800, Rodrigo Vivi wrote:
> Copied from Mesa with no modifications.
> 
> Gives us Geminilake and Kaby Lake platform names updates and
> sync on Coffee Lake PCI IDs.
> 
> Cc: Timo Aaltonen 
> Signed-off-by: Rodrigo Vivi 

Merged, thanks:

remote: I: patch #208689 updated using rev 
90e0cdd42dfda2accfadffa5c550712696902e14.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   43576b901..90e0cdd42  master -> master

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: vbt defs typo fixes

[Adam Jackson]

On Fri, 2018-01-19 at 10:17 +0200, Jani Nikula wrote:
> On Thu, 18 Jan 2018, Adam Jackson <a...@redhat.com> wrote:
> > On Thu, 2018-01-18 at 17:06 +0200, Jani Nikula wrote:
> > > No more sing-a-ling.
> > > 
> > > Reported-by: Adam Jackson <a...@redhat.com>
> > 
> > Why'd you omit the typos I reported in tools/intel_vbt_decode.c ?
> 
> This one's for the kernel. I'll apply your original patch to igt. (Sorry
> for the delay.)

Sorry about that, just saw the file name not the repo. Thanks!

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: vbt defs typo fixes

[Adam Jackson]

On Thu, 2018-01-18 at 17:06 +0200, Jani Nikula wrote:
> No more sing-a-ling.
> 
> Reported-by: Adam Jackson <a...@redhat.com>

Why'd you omit the typos I reported in tools/intel_vbt_decode.c ?

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] intel_vbt_decode: Typo fixes

[Adam Jackson]

Signed-off-by: Adam Jackson <a...@redhat.com>
---
 tools/intel_vbt_decode.c | 4 ++--
 tools/intel_vbt_defs.h   | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/intel_vbt_decode.c b/tools/intel_vbt_decode.c
index 9d90c69d..ce7da2c0 100644
--- a/tools/intel_vbt_decode.c
+++ b/tools/intel_vbt_decode.c
@@ -309,8 +309,8 @@ static const struct {
{ DEVICE_TYPE_COMPOSITE_OUTPUT, "Composite output" },
{ DEVICE_TYPE_DUAL_CHANNEL, "Dual channel" },
{ 1 << 7, "Content protection" },
-   { DEVICE_TYPE_HIGH_SPEED_LINK, "High speel link" },
-   { DEVICE_TYPE_LVDS_SINGALING, "LVDS signaling" },
+   { DEVICE_TYPE_HIGH_SPEED_LINK, "High speed link" },
+   { DEVICE_TYPE_LVDS_SIGNALING, "LVDS signaling" },
{ DEVICE_TYPE_TMDS_DVI_SIGNALING, "TMDS/DVI signaling" },
{ DEVICE_TYPE_VIDEO_SIGNALING, "Video signaling" },
{ DEVICE_TYPE_DISPLAYPORT_OUTPUT, "DisplayPort output" },
diff --git a/tools/intel_vbt_defs.h b/tools/intel_vbt_defs.h
index 404569c9..e388f9ad 100644
--- a/tools/intel_vbt_defs.h
+++ b/tools/intel_vbt_defs.h
@@ -227,7 +227,7 @@ struct bdb_general_features {
 #define DEVICE_TYPE_COMPOSITE_OUTPUT   (1 << 9)
 #define DEVICE_TYPE_DUAL_CHANNEL   (1 << 8)
 #define DEVICE_TYPE_HIGH_SPEED_LINK(1 << 6)
-#define DEVICE_TYPE_LVDS_SINGALING (1 << 5)
+#define DEVICE_TYPE_LVDS_SIGNALING (1 << 5)
 #define DEVICE_TYPE_TMDS_DVI_SIGNALING (1 << 4)
 #define DEVICE_TYPE_VIDEO_SIGNALING(1 << 3)
 #define DEVICE_TYPE_DISPLAYPORT_OUTPUT (1 << 2)
@@ -243,7 +243,7 @@ struct bdb_general_features {
 DEVICE_TYPE_MIPI_OUTPUT |  \
 DEVICE_TYPE_COMPOSITE_OUTPUT | \
 DEVICE_TYPE_DUAL_CHANNEL | \
-DEVICE_TYPE_LVDS_SINGALING |   \
+DEVICE_TYPE_LVDS_SIGNALING |   \
 DEVICE_TYPE_TMDS_DVI_SIGNALING |   \
 DEVICE_TYPE_VIDEO_SIGNALING |  \
 DEVICE_TYPE_DISPLAYPORT_OUTPUT |   \
@@ -253,7 +253,7 @@ struct bdb_general_features {
(DEVICE_TYPE_INTERNAL_CONNECTOR |   \
 DEVICE_TYPE_MIPI_OUTPUT |  \
 DEVICE_TYPE_COMPOSITE_OUTPUT | \
-DEVICE_TYPE_LVDS_SINGALING |   \
+DEVICE_TYPE_LVDS_SIGNALING |   \
 DEVICE_TYPE_TMDS_DVI_SIGNALING |   \
 DEVICE_TYPE_VIDEO_SIGNALING |  \
 DEVICE_TYPE_DISPLAYPORT_OUTPUT |   \
-- 
2.14.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/10] drm/uapi: Deprecate nonsense kms mode types

[Adam Jackson]

On Tue, 2017-11-14 at 20:32 +0200, Ville Syrjala wrote:

> @@ -253,8 +251,11 @@ struct drm_display_mode {
>*  - DRM_MODE_TYPE_USERDEF: Mode defined via kernel command line
>*
>* Plus a big list of flags which shouldn't be used at all, but are
> -  * still around since these flags are also used in the userspace ABI:
> +  * still around since these flags are also used in the userspace ABI.
> +  * We no longer accept modes with these types though:
>*
> +  *  - DRM_MODE_TYPE_BUILTIN: Meant for hard-coded modes, effectively
> +  *unused.

This should suggest _TYPE_DRIVER, I think. The intent with the xfree86
mode type was that "built-in" modes were known quantities of the
hardware, either because the hardware only had one mode or due to
strapping pins or the like. These should be considered "supplied by the
driver" as with EDID-derived modes.

With or without that, patches 2 3 4 and 8 are:

Reviewed-by: Adam Jackson <a...@redhat.com>

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH xserver] Make PixmapDirtyUpdateRec::src a DrawablePtr

[Adam Jackson]

On Tue, 2017-04-18 at 19:07 +0900, Michel Dänzer wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
> 
> This allows making the master screen's pixmap_dirty_list entries
> explicitly reflect that we're now tracking the root window instead of
> the screen pixmap, in order to allow Present page flipping on master
> outputs while there are active slave outputs.
> 
> Define HAS_DIRTYTRACKING_DRAWABLE_SRC for drivers to check, but leave
> HAS_DIRTYTRACKING_ROTATION defined as well to make things slightly
> easier for drivers.
> 
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>

Reviewed-by: Adam Jackson <a...@redhat.com>

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH driver/intel] uxa: Don't bother with xf86GARTCloseScreen

[Adam Jackson]

We only ever use xserver's AGP support from the i810 driver.

Signed-off-by: Adam Jackson <a...@redhat.com>
---
 src/uxa/intel_driver.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/uxa/intel_driver.c b/src/uxa/intel_driver.c
index 73d7f4f..62abdd2 100644
--- a/src/uxa/intel_driver.c
+++ b/src/uxa/intel_driver.c
@@ -1172,8 +1172,6 @@ static Bool I830CloseScreen(CLOSE_SCREEN_ARGS_DECL)
 
intel_sync_close(screen);
 
-   xf86GARTCloseScreen(scrn->scrnIndex);
-
scrn->vtSema = FALSE;
return TRUE;
 }
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings

[Adam Jackson]

On Thu, 2015-10-08 at 11:43 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
> 
> EDID detailed timings have a resolution of 10kHz for the pixel clock, so
> they can't represent certain CEA/HDMI modes accurately. If we see a mode
> coming in via detailed timings which otherwise matches one of the
> CEA/HDMI modes except the clock is just a bit off, let's assume that the
> intention was for that mode to be one of the CEA/HDMI modes and go ahead
> and fix up the clock to match the CEA/HDMI spec exactly (well, as close
> as we can get with the 1 kHz resolution we use).
> 
> This should help code that's looking for an exact clock match (eg. i915
> audio N/CTS setup).

Looks like a sane set of changes.  Series is:

Reviewed-by: Adam Jackson <a...@redhat.com>

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/37] mi: Drop plane argument from miHandleExposures

[Adam Jackson]

On Sat, 2014-10-11 at 14:35 +0100, Mike Lothian wrote:
 Hi
 
 This stops xf86-video-intel working or compiling for me
 
 The below patch is a work around but I'm not quite sure what to check
 for to make it work with both old and new xservers

Intel will need to be fixed, yeah.  Preferably by not forking fb, which
is, you know, insane.

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] configure: Don't link the driver against libX11

[Adam Jackson]

78dc0c04745ad4485b994f67833f4a155749f01d added REQUIRED_MODULES to the
driver link line for... some reason.  That pulled in the libs from the
XF86DRI check, which near as I can tell has always been wrong, all of
the other extension checks just look for the protocol module and
xextproto doesn't define dri1 protocol in any case.

Signed-off-by: Adam Jackson a...@redhat.com
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 353f942..30bed3e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -330,7 +330,7 @@ fi
 # Store the list of server defined optional extensions in REQUIRED_MODULES
 XORG_DRIVER_CHECK_EXT(RANDR, randrproto)
 XORG_DRIVER_CHECK_EXT(RENDER, renderproto)
-XORG_DRIVER_CHECK_EXT(XF86DRI, xextproto x11)
+XORG_DRIVER_CHECK_EXT(XF86DRI, xf86driproto)
 XORG_DRIVER_CHECK_EXT(DPMSExtension, xextproto)
 
 # Obtain compiler/linker options for the driver dependencies
-- 
1.9.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Downgrade pipe state mismatches to DRM_DEBUG_KMS

[Adam Jackson]

This is, by far, the most common kernel retrace in i915 I'm seeing:

https://retrace.fedoraproject.org/faf/problems/1346879/

There's not enough information in the backtrace to know if something
actually went wrong or if this is just an assertion failure, so it's
pretty useless.  Downgrade this to DRM_DEBUG_KMS so we can still see it
if we want it.

Signed-off-by: Adam Jackson a...@redhat.com
---
 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 d78d33f..ce5d1b3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8803,7 +8803,7 @@ check_crtc_state(struct drm_device *dev)
 
if (active 
!intel_pipe_config_compare(dev, crtc-config, 
pipe_config)) {
-   WARN(1, pipe state doesn't match!\n);
+   DRM_DEBUG_KMS(pipe state doesn't match!\n);
intel_dump_pipe_config(crtc, pipe_config,
   [hw state]);
intel_dump_pipe_config(crtc, crtc-config,
-- 
1.8.4.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dp: downstream port capabilities are not present in DPCD 1.0

[Adam Jackson]

On Fri, 2013-09-27 at 14:48 +0300, Jani Nikula wrote:
 We haven't read the downstream port caps for DPCD 1.0, so don't use
 them.
 
 v2: use defines for DPCD 1.0 downstream port types
 
 Signed-off-by: Jani Nikula jani.nik...@intel.com

I don't know if I've ever seen a DPCD 1.0 device, but the changes make
sense.  For the series:

Reviewed-by: Adam Jackson a...@redhat.com

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Be sure to turn hsync/vsync back on at crt enable (v2)

[Adam Jackson]

f40ebd6b properly disabled the hsync/vsync logic at disable time, but
neglected to re-enable them at enable time.

v2: In the enable hook, restore the connector's expected DPMS level
instead of forcing ON.  Do this by stashing a back pointer to the
connector in the crt (suggested by danvet) since otherwise it's awkward
to look up.

Signed-off-by: Adam Jackson a...@redhat.com
---
 drivers/gpu/drm/i915/intel_crt.c | 40 +---
 1 file changed, 17 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 32a3693..498dafd 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -45,6 +45,9 @@
 
 struct intel_crt {
struct intel_encoder base;
+   /* DPMS state is stored in the connector, which we need in the
+* encoder's enable/disable callbacks */
+   struct intel_connector *connector;
bool force_hotplug_required;
u32 adpa_reg;
 };
@@ -81,29 +84,6 @@ static bool intel_crt_get_hw_state(struct intel_encoder 
*encoder,
return true;
 }
 
-static void intel_disable_crt(struct intel_encoder *encoder)
-{
-   struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
-   struct intel_crt *crt = intel_encoder_to_crt(encoder);
-   u32 temp;
-
-   temp = I915_READ(crt-adpa_reg);
-   temp |= ADPA_HSYNC_CNTL_DISABLE | ADPA_VSYNC_CNTL_DISABLE;
-   temp = ~ADPA_DAC_ENABLE;
-   I915_WRITE(crt-adpa_reg, temp);
-}
-
-static void intel_enable_crt(struct intel_encoder *encoder)
-{
-   struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
-   struct intel_crt *crt = intel_encoder_to_crt(encoder);
-   u32 temp;
-
-   temp = I915_READ(crt-adpa_reg);
-   temp |= ADPA_DAC_ENABLE;
-   I915_WRITE(crt-adpa_reg, temp);
-}
-
 /* Note: The caller is required to filter out dpms modes not supported by the
  * platform. */
 static void intel_crt_set_dpms(struct intel_encoder *encoder, int mode)
@@ -135,6 +115,19 @@ static void intel_crt_set_dpms(struct intel_encoder 
*encoder, int mode)
I915_WRITE(crt-adpa_reg, temp);
 }
 
+static void intel_disable_crt(struct intel_encoder *encoder)
+{
+   intel_crt_set_dpms(encoder, DRM_MODE_DPMS_OFF);
+}
+
+static void intel_enable_crt(struct intel_encoder *encoder)
+{
+   struct intel_crt *crt = intel_encoder_to_crt(encoder);
+
+   intel_crt_set_dpms(encoder, crt-connector-dpms);
+}
+
+
 static void intel_crt_dpms(struct drm_connector *connector, int mode)
 {
struct drm_device *dev = connector-dev;
@@ -746,6 +739,7 @@ void intel_crt_init(struct drm_device *dev)
}
 
connector = intel_connector-base;
+   crt-connector = connector;
drm_connector_init(dev, intel_connector-base,
   intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
 
-- 
1.8.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: don't add inferred modes for monitors that don't support them

[Adam Jackson]

On Fri, 2013-02-15 at 13:36 -0200, Paulo Zanoni wrote:
 From: Paulo Zanoni paulo.r.zan...@intel.com
 
 If bit 0 of the features byte (0x18) is set to 0, then, according to
 the EDID spec, the display is non-continuous frequency (multi-mode)
 and is only specified to accept the video timing formats that are
 listed in Base EDID and certain Extension Blocks.
 
 For more information, please see the EDID spec, check the notes of the
 table that explains the Feature Support byte (18h) and also the
 notes on the tables of the section that explains Display Range Limits
  Additional Timing Description Definition (tag #FDh).

Seems sane.

Reviewed-by: Adam Jackson a...@redhat.com

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: fix FDI lane calculation

[Adam Jackson]

On 11/29/12 8:29 AM, Paulo Zanoni wrote:

From: Paulo Zanoni paulo.r.zan...@intel.com

The previous code was making the bps value 5% higher than what the
spec says, which was enough to make certain VGA modes require 3 lanes
instead of 2, which makes us reject these modes on Haswell since it
only has 2 FDI lanes. For previous gens this was not much of a
problem, since they had 4 lanes, and requiring more lanes than the
needed is ok, as long as you have all the lanes.

Notice that this might improve the case where we use pipes B and C on
Ivy Bridge since both pipes only have 4 lanes to share (see
ironlake_check_fdi_lanes).


Fine with me.  I'm not entirely sure the SS check I had there was 
necessary; I do remember the docs saying to account for it, but I'm not 
sure the check we had there was correct.


Reviewed-by: Adam Jackson a...@redhat.com

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm: add helper to sort panels to the head of the connector list

[Adam Jackson]

On 10/27/12 9:52 AM, Daniel Vetter wrote:

Userspace seems to like this, see

commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
Author: Adam Jackson a...@redhat.com
Date:   Fri Jul 16 14:46:29 2010 -0400

 drm/i915: Initialize LVDS and eDP outputs before anything else

 This makes them sort to the front in X, which makes them likely to be
 the primary outputs if you haven't specified a preference in your DE,
 which is likely to be what you want.

 Signed-off-by: Adam Jackson a...@redhat.com
 Signed-off-by: Eric Anholt e...@anholt.net

Sorting the connector list after the fact is much easier than trying
to be clever with the init sequence.


Entirely reasonable.

Reviewed-by: Adam Jackson a...@redhat.com

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: move panel connectors to the front

[Adam Jackson]

On 10/27/12 9:52 AM, Daniel Vetter wrote:

This essentially reverts

commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
Author: Adam Jackson a...@redhat.com
Date:   Fri Jul 16 14:46:29 2010 -0400

 drm/i915: Initialize LVDS and eDP outputs before anything else

simply because it doesn't scale: It misses SDVO and DVO panels,
and now with DDI encoders on haswell this is becoming unmanageable.

Instead we simply sort the connector list after everything is
set up.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch


Reviewed-by: Adam Jackson a...@redhat.com

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag

[Adam Jackson]

On Wed, 2012-09-26 at 18:43 +0300, Jani Nikula wrote:
 The dithering introduced in
 
 commit 3b5c78a35cf7511c15e09a9b0ffab290a42d9bcf
 Author: Adam Jackson a...@redhat.com
 Date:   Tue Dec 13 15:41:00 2011 -0800
 
 drm/i915/dp: Dither down to 6bpc if it makes the mode fit
 
 stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the
 adjusted mode, while i9xx_crtc_mode_set() and ironlake_crtc_mode_set() use
 the original mode, without the flag, so it would never have any
 effect. However, the BPC was clamped by VBT settings, making things work by
 coincidence, until that part was removed in
 
 commit 4344b813f105a19f793f1fd93ad775b784648b95
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Fri Aug 10 11:10:20 2012 +0200
 
 Use adjusted_mode instead of mode when checking for
 INTEL_MODE_DP_FORCE_6BPC to make the flag have effect.
 
 v2: Don't forget to fix this in i9xx_crtc_mode_set() also, pointed out by
 Daniel both before and after sending the first patch.

Reviewed-by: Adam Jackson a...@redhat.com

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/dp: Update DPCD defines

[Adam Jackson]

On 9/20/12 10:10 AM, Paulo Zanoni wrote:

2012/9/18 Adam Jackson a...@redhat.com:

Sources: DP, eDP, and DP interop specs, and a VESA slideshow about DP
1.2 for the MST bits.


All I needed to review every bit was DP spec version 1.2.


Lucky you!  I don't have a copy.


+#define DP_SINK_COUNT  0x200
+# define DP_SINK_COUNT_MASK(31  0)


My DP spec version 1.2 says bits 7 and 5:0, but the DP 1.1 spec says
it's just 5:0 and Bits 7 = RESERVED. So should we treat bit 7 as the
most-significant-bit? Notice that this will affect patch 4 of this
series.


Oh, wild.  I guess they did that so they could have twice as many 
downstream devices?



Idea for a follow-up patch: maybe we should try to add some comments
explaining which bits appeared only in some specific DPCD x.y
revision?


That's a good idea.

I'll send follow-ups for that, and to make a DP_GET_SINK_COUNT() that 
does the right math.


- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Valid DP connection without EDID?

[Adam Jackson]

On Tue, 2012-09-18 at 13:01 +0200, Takashi Iwai wrote:

  I started a patch series for this a bit ago, I'll send it on
  momentarily.
 
 Thanks!  I evaluated it now (with a typo fix suggested by Jani).
 Unfortunately, it doesn't improve the situation.
 
 The fetch of downstream ports succeeds, and it gets 0x09.  So, this
 indicates again it's a VGA downstream port.  But that's all, so far.
 The 0x09 is reported no matter whether the VGA cable is plugged or
 not, so this can't be used as the detection of the downstream port
 plug state.

Sorry, there's a bug in the patch.  link_configuration[0] is not
DP_SINK_COUNT, I have no idea why I thought it was.  Try this on top of
the series:

===
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9809c53..b6b9a18 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2098,15 +2098,22 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
 
if (!intel_dp_get_dpcd(intel_dp))
return connector_status_disconnected;
-   
+
/* if there's no downstream port, we're done */
if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT]  DP_DWN_STRM_PORT_PRESENT))
return connector_status_connected;
 
/* If we're HPD-aware, SINK_COUNT changes dynamically */
hpd = !!(intel_dp-downstream_ports[0]  DP_DS_PORT_HPD);
-   if (hpd  (intel_dp-link_configuration[0]  DP_SINK_COUNT_MASK))
-   return connector_status_connected;
+   if (hpd) {
+   uint8_t sink_count;
+   if (!intel_dp_aux_native_read_retry(intel_dp, DP_SINK_COUNT,
+   sink_count, 1))
+   return connector_status_unknown;
+   sink_count = DP_SINK_COUNT_MASK;
+   return sink_count ? connector_status_connected
+ : connector_status_disconnected;
+   }
 
/* If no HPD, poke DDC gently */
if (drm_probe_ddc(intel_dp-adapter))
===

If that doesn't work then the HPD-capable bit is useless - or if we're
lucky just needs quirking by branch OUI - and we should just fall
through to the drm_probe_ddc() path.  What is the branch OUI, anyway?

There's a third possibility, which is that HPD does work but that we're
not doing enough to enable it.  The DP 1.1a spec has a non-normative
appendix describing one way a device could go about doing that as an
optional feature, but the method described does not match how we're
currently handling sink-specific IRQs.  I have no idea what the 1.2 spec
says on this point though.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Valid DP connection without EDID?

[Adam Jackson]

On Tue, 2012-09-18 at 16:32 +0200, Takashi Iwai wrote:

 Woohoo, the patch works!

\o/

 Could you brush up and resend the patches for merging to 3.7 kernel?
 Or, would you like to fix the multiple branch devices first?

I'm not too worried about branch devices with multiple downstreams just
yet.  I don't know of any you can buy anyway.  Even if you could there's
some open questions about how we'd present them to the user, and the
whole concept will need rethinking once we get multiple-stream support.

The only case I can think of where this might not work sanely is an
active DP-HDMI adaptor with sinks for both audio and video?  But again,
I don't think those exist.  If they do you'd expect both the A and V
sinks to plug simultaneously, so sink count should always be either zero
or non-zero, so it should work anyway.

 When you resubmit patches, feel free to add:
   Tested-by: Takashi Iwai ti...@suse.de

Will do, thanks for testing!

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/4] drm: Export drm_probe_ddc()

[Adam Jackson]

Tested-by: Takashi Iwai ti...@suse.de
Signed-off-by: Adam Jackson a...@redhat.com
---
 drivers/gpu/drm/drm_edid.c |3 ++-
 include/drm/drm_crtc.h |1 +
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b7ee230..a1895ba 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -376,13 +376,14 @@ out:
  * \param adapter : i2c device adaptor
  * \return 1 on success
  */
-static bool
+bool
 drm_probe_ddc(struct i2c_adapter *adapter)
 {
unsigned char out;
 
return (drm_do_probe_ddc_edid(adapter, out, 0, 1) == 0);
 }
+EXPORT_SYMBOL(drm_probe_ddc);
 
 /**
  * drm_get_edid - get EDID data, if available
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bfacf0d..f5d434b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -862,6 +862,7 @@ extern char *drm_get_tv_subconnector_name(int val);
 extern char *drm_get_tv_select_name(int val);
 extern void drm_fb_release(struct drm_file *file_priv);
 extern int drm_mode_group_init_legacy_group(struct drm_device *dev, struct 
drm_mode_group *group);
+extern bool drm_probe_ddc(struct i2c_adapter *adapter);
 extern struct edid *drm_get_edid(struct drm_connector *connector,
 struct i2c_adapter *adapter);
 extern int drm_add_edid_modes(struct drm_connector *connector, struct edid 
*edid);
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/4] drm/dp: Update DPCD defines

[Adam Jackson]

Sources: DP, eDP, and DP interop specs, and a VESA slideshow about DP
1.2 for the MST bits.

Tested-by: Takashi Iwai ti...@suse.de
Signed-off-by: Adam Jackson a...@redhat.com
---
 include/drm/drm_dp_helper.h |   60 ---
 1 files changed, 56 insertions(+), 4 deletions(-)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1744b18c..f9888c3 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -69,16 +69,30 @@
 /* 10b = TMDS or HDMI */
 /* 11b = Other */
 # define DP_FORMAT_CONVERSION   (1  3)
+# define DP_DETAILED_CAP_INFO_AVAILABLE(1  4)
 
 #define DP_MAIN_LINK_CHANNEL_CODING 0x006
 
 #define DP_DOWN_STREAM_PORT_COUNT  0x007
-#define  DP_PORT_COUNT_MASK0x0f
-#define  DP_OUI_SUPPORT(1  7)
+# define DP_PORT_COUNT_MASK0x0f
+# define DP_MSA_TIMING_PAR_IGNORED (1  6)
+# define DP_OUI_SUPPORT(1  7)
+
+#define DP_I2C_SPEED_CAP   0x00c
+# define DP_I2C_SPEED_1K   0x01
+# define DP_I2C_SPEED_5K   0x02
+# define DP_I2C_SPEED_10K  0x04
+# define DP_I2C_SPEED_100K 0x08
+# define DP_I2C_SPEED_400K 0x10
+# define DP_I2C_SPEED_1M   0x20
 
 #define DP_EDP_CONFIGURATION_CAP0x00d
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e
 
+/* Multiple stream transport */
+#define DP_MSTM_CAP0x021
+# define DP_MST_CAP(1  0)
+
 #define DP_PSR_SUPPORT  0x070
 # define DP_PSR_IS_SUPPORTED1
 #define DP_PSR_CAPS 0x071
@@ -93,6 +107,31 @@
 # define DP_PSR_SETUP_TIME_MASK (7  1)
 # define DP_PSR_SETUP_TIME_SHIFT1
 
+/*
+ * 0x80-0x8f describe downstream port capabilities, but there are two layouts
+ * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set.  If it was not,
+ * each port's descriptor is one byte wide.  If it was set, each port's is
+ * four bytes wide, starting with the one byte from the base info.  As of
+ * DP interop v1.1a only VGA defines additional detail.
+ */
+
+/* offset 0 */
+#define DP_DOWNSTREAM_PORT_0   0x80
+# define DP_DS_PORT_TYPE_MASK  (7  0)
+# define DP_DS_PORT_TYPE_DP0
+# define DP_DS_PORT_TYPE_VGA   1
+# define DP_DS_PORT_TYPE_DVI   2
+# define DP_DS_PORT_TYPE_HDMI  3
+# define DP_DS_PORT_TYPE_NON_EDID  4
+# define DP_DS_PORT_HPD(1  3)
+/* offset 1 for VGA is maximum megapixels per second / 8 */
+/* offset 2 */
+# define DP_DS_VGA_MAX_BPC_MASK(3  0)
+# define DP_DS_VGA_8BPC0
+# define DP_DS_VGA_10BPC   1
+# define DP_DS_VGA_12BPC   2
+# define DP_DS_VGA_16BPC   3
+
 /* link configuration */
 #defineDP_LINK_BW_SET  0x100
 # define DP_LINK_BW_1_62   0x06
@@ -148,24 +187,37 @@
 
 #define DP_DOWNSPREAD_CTRL 0x107
 # define DP_SPREAD_AMP_0_5 (1  4)
+# define DP_MSA_TIMING_PAR_IGNORE_EN   (1  7)
 
 #define DP_MAIN_LINK_CHANNEL_CODING_SET0x108
 # define DP_SET_ANSI_8B10B (1  0)
 
+#define DP_I2C_SPEED_CONTROL_STATUS0x109
+/* bitmask as for DP_I2C_SPEED_CAP */
+
+#define DP_EDP_CONFIGURATION_SET0x10a
+
+#define DP_MSTM_CTRL   0x111
+# define DP_MST_EN (1  0)
+# define DP_UP_REQ_EN  (1  1)
+# define DP_UPSTREAM_IS_SRC(1  2)
+
 #define DP_PSR_EN_CFG  0x170
 # define DP_PSR_ENABLE (1  0)
 # define DP_PSR_MAIN_LINK_ACTIVE   (1  1)
 # define DP_PSR_CRC_VERIFICATION   (1  2)
 # define DP_PSR_FRAME_CAPTURE  (1  3)
 
+#define DP_SINK_COUNT  0x200
+# define DP_SINK_COUNT_MASK(31  0)
+# define DP_SINK_CP_READY  (1  6)
+
 #define DP_DEVICE_SERVICE_IRQ_VECTOR   0x201
 # define DP_REMOTE_CONTROL_COMMAND_PENDING  (1  0)
 # define DP_AUTOMATED_TEST_REQUEST (1  1)
 # define DP_CP_IRQ (1  2)
 # define DP_SINK_SPECIFIC_IRQ  (1  6)
 
-#define DP_EDP_CONFIGURATION_SET0x10a
-
 #define DP_LANE0_1_STATUS  0x202
 #define DP_LANE2_3_STATUS  0x203
 # define DP_LANE_CR_DONE   (1  0)
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/4] drm/i915/dp: Fetch downstream port info if needed during DPCD fetch

[Adam Jackson]

v2: Fix parenthesis mismatch, spotted by Jani Nikula

Tested-by: Takashi Iwai ti...@suse.de
Signed-off-by: Adam Jackson a...@redhat.com
---
 drivers/gpu/drm/i915/intel_dp.c |   25 -
 1 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ace757a..098119e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -39,6 +39,7 @@
 #include drm_dp_helper.h
 
 #define DP_RECEIVER_CAP_SIZE   0xf
+#define DP_MAX_DOWNSTREAM_PORTS 0xf
 #define DP_LINK_STATUS_SIZE6
 #define DP_LINK_CHECK_TIMEOUT  (10 * 1000)
 
@@ -56,6 +57,7 @@ struct intel_dp {
uint8_t link_bw;
uint8_t lane_count;
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
+   uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
struct i2c_adapter adapter;
struct i2c_algo_dp_aux_data algo;
bool is_pch_edp;
@@ -1968,12 +1970,25 @@ static bool
 intel_dp_get_dpcd(struct intel_dp *intel_dp)
 {
if (intel_dp_aux_native_read_retry(intel_dp, 0x000, intel_dp-dpcd,
-  sizeof(intel_dp-dpcd)) 
-   (intel_dp-dpcd[DP_DPCD_REV] != 0)) {
-   return true;
-   }
+  sizeof(intel_dp-dpcd)) == 0)
+   return false; /* aux transfer failed */
 
-   return false;
+   if (intel_dp-dpcd[DP_DPCD_REV] == 0)
+   return false; /* DPCD not present */
+
+   if (!(intel_dp-dpcd[DP_DOWNSTREAMPORT_PRESENT] 
+ DP_DWN_STRM_PORT_PRESENT))
+   return true; /* native DP sink */
+
+   if (intel_dp-dpcd[DP_DPCD_REV] == 0x10)
+   return true; /* no per-port downstream info */
+
+   if (intel_dp_aux_native_read_retry(intel_dp, DP_DOWNSTREAM_PORT_0,
+  intel_dp-downstream_ports,
+  DP_MAX_DOWNSTREAM_PORTS) == 0)
+   return false; /* downstream port status fetch failed */
+
+   return true;
 }
 
 static void
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/4] drm/i915/dp: Be smarter about connection sense for branch devices

[Adam Jackson]

If there's no downstream device, DPCD success is good enough.  If
there's a hotplug-capable downstream device, count the number of
connected sinks in DP_SINK_STATUS and return success if it's non-zero.
Otherwise, probe DDC and report appropriately.

v2: Check DP_SINK_STATUS instead of something unrelated to sink status.

Tested-by: Takashi Iwai ti...@suse.de
Signed-off-by: Adam Jackson a...@redhat.com
---
 drivers/gpu/drm/i915/intel_dp.c |   35 ++-
 1 files changed, 34 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 098119e..813b771 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2088,11 +2088,44 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
}
 }
 
+/* XXX this is probably wrong for multiple downstream ports */
 static enum drm_connector_status
 intel_dp_detect_dpcd(struct intel_dp *intel_dp)
 {
-   if (intel_dp_get_dpcd(intel_dp))
+   uint8_t *dpcd = intel_dp-dpcd;
+   bool hpd;
+   uint8_t type;
+
+   if (!intel_dp_get_dpcd(intel_dp))
+   return connector_status_disconnected;
+
+   /* if there's no downstream port, we're done */
+   if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT]  DP_DWN_STRM_PORT_PRESENT))
+   return connector_status_connected;
+
+   /* If we're HPD-aware, SINK_COUNT changes dynamically */
+   hpd = !!(intel_dp-downstream_ports[0]  DP_DS_PORT_HPD);
+   if (hpd) {
+   uint8_t sink_count;
+   if (!intel_dp_aux_native_read_retry(intel_dp, DP_SINK_COUNT,
+   sink_count, 1))
+   return connector_status_unknown;
+   sink_count = DP_SINK_COUNT_MASK;
+   return sink_count ? connector_status_connected
+ : connector_status_disconnected;
+   }
+
+   /* If no HPD, poke DDC gently */
+   if (drm_probe_ddc(intel_dp-adapter))
return connector_status_connected;
+
+   /* Well we tried, say unknown for unreliable port types */
+   type = intel_dp-downstream_ports[0]  DP_DS_PORT_TYPE_MASK;
+   if (type == DP_DS_PORT_TYPE_VGA || type == DP_DS_PORT_TYPE_NON_EDID)
+   return connector_status_unknown;
+
+   /* Anything else is out of spec, warn and ignore */
+   DRM_DEBUG_KMS(Broken DP branch device, ignoring\n);
return connector_status_disconnected;
 }
 
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915/dp: Be smarter about connection sense for branch devices

[Adam Jackson]

On Tue, 2012-09-18 at 10:58 -0400, Adam Jackson wrote:
 If there's no downstream device, DPCD success is good enough.  If
 there's a hotplug-capable downstream device, count the number of
 connected sinks in DP_SINK_STATUS and return success if it's non-zero.
 Otherwise, probe DDC and report appropriately.
 
 v2: Check DP_SINK_STATUS instead of something unrelated to sink status.

Ugh, s/STATUS/COUNT/g in the summary, sorry.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Valid DP connection without EDID?

[Adam Jackson]

On Mon, 2012-09-17 at 11:32 +0200, Takashi Iwai wrote:
 At Mon, 17 Sep 2012 19:11:34 +1000,
 Dave Airlie wrote:
  On Mon, Sep 17, 2012 at 6:28 PM, Takashi Iwai ti...@suse.de wrote:
   At Mon, 17 Sep 2012 18:21:47 +1000,
   Dave Airlie wrote:
   On Mon, Sep 17, 2012 at 6:16 PM, Takashi Iwai ti...@suse.de wrote:
At Fri, 14 Sep 2012 11:25:03 -0400,
Adam Jackson wrote:
   
Can you be more specific here?  What DPCD does it return?
   
It shows DPCD: 110a820100030181

So dpcd[0x5] is 0x03, and drm_dp_helper.h says:

#define DP_DOWNSTREAMPORT_PRESENT   0x005
# define DP_DWN_STRM_PORT_PRESENT   (1  0)
# define DP_DWN_STRM_PORT_TYPE_MASK 0x06
/* 00b = DisplayPort */
/* 01b = Analog */
/* 10b = TMDS or HDMI */
/* 11b = Other */
# define DP_FORMAT_CONVERSION   (1  3)

So there we go, it's a branch device with VGA downstream of it.  We need
to figure out the connectivity of the downstream port.

   Checking DPCD bits might work, but I have no exact spec of DPCD, so no
   idea whether the above is really wrong or not.
  
  Is there a VGA port on the docking station, it might have a DP-VGA in
  it, or dual-link DVI port.
 
 Ah, right, that's the missing piece!
 
 It's a DP-VGA conversion indeed.  Plugging to a VGA connector appears
 as DP2.  Oh well, I didn't think of this possibility at all.
 
 But then this makes me wonder how to solve the problem at best.
 It's obviously a bogus connection status returned from the driver.
 DP2 advertises itself as if connected.

I wouldn't quite say it's bogus, more that we're describing the
connection status of the nearest DP device as if it were the
connection status of the whole wire.

I started a patch series for this a bit ago, I'll send it on
momentarily.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/4] Fix handling of DP bridge devices

[Adam Jackson]

Connection sense for DP bridge devices (like DP-VGA) currently only looks
at DPCD presence.  This is wrong.  However we would still like to avoid
DDC reads if possible, since they're much slower than AUXCH.

This series enhances i915 DP detection to know about branch devices, and
attempts to discover downstream port status and reflect that back to KMS.
It does not handle the case of multiple downstream ports very well, but
then neither does the existing code; if anyone has an example of such a
device I'll be happy to investigate.

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/4] drm: Export drm_probe_ddc()

[Adam Jackson]

Signed-off-by: Adam Jackson a...@redhat.com
---
 drivers/gpu/drm/drm_edid.c |3 ++-
 include/drm/drm_crtc.h |1 +
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b7ee230..a1895ba 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -376,13 +376,14 @@ out:
  * \param adapter : i2c device adaptor
  * \return 1 on success
  */
-static bool
+bool
 drm_probe_ddc(struct i2c_adapter *adapter)
 {
unsigned char out;
 
return (drm_do_probe_ddc_edid(adapter, out, 0, 1) == 0);
 }
+EXPORT_SYMBOL(drm_probe_ddc);
 
 /**
  * drm_get_edid - get EDID data, if available
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bfacf0d..f5d434b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -862,6 +862,7 @@ extern char *drm_get_tv_subconnector_name(int val);
 extern char *drm_get_tv_select_name(int val);
 extern void drm_fb_release(struct drm_file *file_priv);
 extern int drm_mode_group_init_legacy_group(struct drm_device *dev, struct 
drm_mode_group *group);
+extern bool drm_probe_ddc(struct i2c_adapter *adapter);
 extern struct edid *drm_get_edid(struct drm_connector *connector,
 struct i2c_adapter *adapter);
 extern int drm_add_edid_modes(struct drm_connector *connector, struct edid 
*edid);
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/4] drm/dp: Update DPCD defines

[Adam Jackson]

Sources: DP, eDP, and DP interop specs, and a VESA slideshow about DP
1.2 for the MST bits.

Signed-off-by: Adam Jackson a...@redhat.com
---
 include/drm/drm_dp_helper.h |   60 ---
 1 files changed, 56 insertions(+), 4 deletions(-)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1744b18c..f9888c3 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -69,16 +69,30 @@
 /* 10b = TMDS or HDMI */
 /* 11b = Other */
 # define DP_FORMAT_CONVERSION   (1  3)
+# define DP_DETAILED_CAP_INFO_AVAILABLE(1  4)
 
 #define DP_MAIN_LINK_CHANNEL_CODING 0x006
 
 #define DP_DOWN_STREAM_PORT_COUNT  0x007
-#define  DP_PORT_COUNT_MASK0x0f
-#define  DP_OUI_SUPPORT(1  7)
+# define DP_PORT_COUNT_MASK0x0f
+# define DP_MSA_TIMING_PAR_IGNORED (1  6)
+# define DP_OUI_SUPPORT(1  7)
+
+#define DP_I2C_SPEED_CAP   0x00c
+# define DP_I2C_SPEED_1K   0x01
+# define DP_I2C_SPEED_5K   0x02
+# define DP_I2C_SPEED_10K  0x04
+# define DP_I2C_SPEED_100K 0x08
+# define DP_I2C_SPEED_400K 0x10
+# define DP_I2C_SPEED_1M   0x20
 
 #define DP_EDP_CONFIGURATION_CAP0x00d
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e
 
+/* Multiple stream transport */
+#define DP_MSTM_CAP0x021
+# define DP_MST_CAP(1  0)
+
 #define DP_PSR_SUPPORT  0x070
 # define DP_PSR_IS_SUPPORTED1
 #define DP_PSR_CAPS 0x071
@@ -93,6 +107,31 @@
 # define DP_PSR_SETUP_TIME_MASK (7  1)
 # define DP_PSR_SETUP_TIME_SHIFT1
 
+/*
+ * 0x80-0x8f describe downstream port capabilities, but there are two layouts
+ * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set.  If it was not,
+ * each port's descriptor is one byte wide.  If it was set, each port's is
+ * four bytes wide, starting with the one byte from the base info.  As of
+ * DP interop v1.1a only VGA defines additional detail.
+ */
+
+/* offset 0 */
+#define DP_DOWNSTREAM_PORT_0   0x80
+# define DP_DS_PORT_TYPE_MASK  (7  0)
+# define DP_DS_PORT_TYPE_DP0
+# define DP_DS_PORT_TYPE_VGA   1
+# define DP_DS_PORT_TYPE_DVI   2
+# define DP_DS_PORT_TYPE_HDMI  3
+# define DP_DS_PORT_TYPE_NON_EDID  4
+# define DP_DS_PORT_HPD(1  3)
+/* offset 1 for VGA is maximum megapixels per second / 8 */
+/* offset 2 */
+# define DP_DS_VGA_MAX_BPC_MASK(3  0)
+# define DP_DS_VGA_8BPC0
+# define DP_DS_VGA_10BPC   1
+# define DP_DS_VGA_12BPC   2
+# define DP_DS_VGA_16BPC   3
+
 /* link configuration */
 #defineDP_LINK_BW_SET  0x100
 # define DP_LINK_BW_1_62   0x06
@@ -148,24 +187,37 @@
 
 #define DP_DOWNSPREAD_CTRL 0x107
 # define DP_SPREAD_AMP_0_5 (1  4)
+# define DP_MSA_TIMING_PAR_IGNORE_EN   (1  7)
 
 #define DP_MAIN_LINK_CHANNEL_CODING_SET0x108
 # define DP_SET_ANSI_8B10B (1  0)
 
+#define DP_I2C_SPEED_CONTROL_STATUS0x109
+/* bitmask as for DP_I2C_SPEED_CAP */
+
+#define DP_EDP_CONFIGURATION_SET0x10a
+
+#define DP_MSTM_CTRL   0x111
+# define DP_MST_EN (1  0)
+# define DP_UP_REQ_EN  (1  1)
+# define DP_UPSTREAM_IS_SRC(1  2)
+
 #define DP_PSR_EN_CFG  0x170
 # define DP_PSR_ENABLE (1  0)
 # define DP_PSR_MAIN_LINK_ACTIVE   (1  1)
 # define DP_PSR_CRC_VERIFICATION   (1  2)
 # define DP_PSR_FRAME_CAPTURE  (1  3)
 
+#define DP_SINK_COUNT  0x200
+# define DP_SINK_COUNT_MASK(31  0)
+# define DP_SINK_CP_READY  (1  6)
+
 #define DP_DEVICE_SERVICE_IRQ_VECTOR   0x201
 # define DP_REMOTE_CONTROL_COMMAND_PENDING  (1  0)
 # define DP_AUTOMATED_TEST_REQUEST (1  1)
 # define DP_CP_IRQ (1  2)
 # define DP_SINK_SPECIFIC_IRQ  (1  6)
 
-#define DP_EDP_CONFIGURATION_SET0x10a
-
 #define DP_LANE0_1_STATUS  0x202
 #define DP_LANE2_3_STATUS  0x203
 # define DP_LANE_CR_DONE   (1  0)
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/4] drm/i915/dp: Fetch downstream port info if needed during DPCD fetch

[Adam Jackson]

Signed-off-by: Adam Jackson a...@redhat.com
---
 drivers/gpu/drm/i915/intel_dp.c |   25 -
 1 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ace757a..92939bd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -39,6 +39,7 @@
 #include drm_dp_helper.h
 
 #define DP_RECEIVER_CAP_SIZE   0xf
+#define DP_MAX_DOWNSTREAM_PORTS 0xf
 #define DP_LINK_STATUS_SIZE6
 #define DP_LINK_CHECK_TIMEOUT  (10 * 1000)
 
@@ -56,6 +57,7 @@ struct intel_dp {
uint8_t link_bw;
uint8_t lane_count;
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
+   uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
struct i2c_adapter adapter;
struct i2c_algo_dp_aux_data algo;
bool is_pch_edp;
@@ -1968,12 +1970,25 @@ static bool
 intel_dp_get_dpcd(struct intel_dp *intel_dp)
 {
if (intel_dp_aux_native_read_retry(intel_dp, 0x000, intel_dp-dpcd,
-  sizeof(intel_dp-dpcd)) 
-   (intel_dp-dpcd[DP_DPCD_REV] != 0)) {
-   return true;
-   }
+  sizeof(intel_dp-dpcd) == 0))
+   return false; /* aux transfer failed */
 
-   return false;
+   if (intel_dp-dpcd[DP_DPCD_REV] == 0)
+   return false; /* DPCD not present */
+
+   if (!(intel_dp-dpcd[DP_DOWNSTREAMPORT_PRESENT] 
+ DP_DWN_STRM_PORT_PRESENT))
+   return true; /* native DP sink */
+
+   if (intel_dp-dpcd[DP_DPCD_REV] == 0x10)
+   return true; /* no per-port downstream info */
+
+   if (intel_dp_aux_native_read_retry(intel_dp, DP_DOWNSTREAM_PORT_0,
+  intel_dp-downstream_ports,
+  DP_MAX_DOWNSTREAM_PORTS) == 0)
+   return false; /* downstream port status fetch failed */
+
+   return true;
 }
 
 static void
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/4] drm/i915/dp: Be smarter about connection sense for branch devices

[Adam Jackson]

Signed-off-by: Adam Jackson a...@redhat.com
---
 drivers/gpu/drm/i915/intel_dp.c |   28 +++-
 1 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 92939bd..9809c53 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2088,11 +2088,37 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
}
 }
 
+/* XXX this is probably wrong for multiple downstream ports */
 static enum drm_connector_status
 intel_dp_detect_dpcd(struct intel_dp *intel_dp)
 {
-   if (intel_dp_get_dpcd(intel_dp))
+   uint8_t *dpcd = intel_dp-dpcd;
+   bool hpd;
+   uint8_t type;
+
+   if (!intel_dp_get_dpcd(intel_dp))
+   return connector_status_disconnected;
+   
+   /* if there's no downstream port, we're done */
+   if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT]  DP_DWN_STRM_PORT_PRESENT))
return connector_status_connected;
+
+   /* If we're HPD-aware, SINK_COUNT changes dynamically */
+   hpd = !!(intel_dp-downstream_ports[0]  DP_DS_PORT_HPD);
+   if (hpd  (intel_dp-link_configuration[0]  DP_SINK_COUNT_MASK))
+   return connector_status_connected;
+
+   /* If no HPD, poke DDC gently */
+   if (drm_probe_ddc(intel_dp-adapter))
+   return connector_status_connected;
+
+   /* Well we tried, say unknown for unreliable port types */
+   type = intel_dp-downstream_ports[0]  DP_DS_PORT_TYPE_MASK;
+   if (type == DP_DS_PORT_TYPE_VGA || type == DP_DS_PORT_TYPE_NON_EDID)
+   return connector_status_unknown;
+
+   /* Anything else is out of spec, warn and ignore */
+   DRM_DEBUG_KMS(Broken DP branch device, ignoring\n);
return connector_status_disconnected;
 }
 
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Valid DP connection without EDID?

[Adam Jackson]

On 9/14/12 10:19 AM, Takashi Iwai wrote:

Hi,

we've got a machine showing a ghost DP2 output on a docking station.
The docking station has only one DP port and it's connected to DP1.
As a result, we get an DP2 active output containing the bogus VESA
standard modes 1024x768, 800x600, 640x480 although it's not connected
at all.

Looking a bit deeply on it, it seems that the connector gives actually
the valid DPCD.  So intel_dp_detect() returns
connector_status_connected.  But since there is no real connection,
EDID isn't obtained.  Thus of course no valid modes set.


Can you be more specific here?  What DPCD does it return?  Does it claim 
to be a branch device?  We don't currently get that case right, try for 
instance plugging in a DP-VGA pigtail.



A quick patch below adds (moves) a check of EDID and returns the
disconnected state when no valid EDID is returned.  An open question
is whether this is really safe.  Is there any case where no valid EDID
is returned but the connection is still valid?


DisplayPort requires EDID.  There may be a platform method for obtaining 
it for eDP, but for normal DP it has to exist over AUXCH.


DVI and HDMI require it too, in fact.  The only one that doesn't is VGA.

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: rip out edp special case from dp_link_down

[Adam Jackson]

On 9/9/12 1:58 PM, Daniel Vetter wrote:


The really interesting question is how this special cases survived
this long in the code. The first step is declaring the pch port D as
eDP if it's used for an internal panel:

commit b329530ca7cdf6bf014f2124efd983e01265d623
Author: Adam Jackson a...@redhat.com
Date:   Fri Jul 16 14:46:28 2010 -0400

 drm/i915/dp: Correctly report eDP in the core connector type

This commit unfortunately failed to notice that not all edp ports are
created equal. Then follow a flurry of refactorings, culminating in a
patch from Keith Packard which resulted in the current logic (by
making it correct for all platforms that have edp):


The motivation for this patch was simply making eDP connectors be 
reported as eDP, since that has the same probably special properties 
as LVDS (correlation with lid state, probably the primary if no better 
guidance given, etc).


- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Fighting tearing

[Adam Jackson]

On 9/9/12 11:48 AM, Roberth Sjonøy wrote:


WIth UXA, rendering of the windows in my XFCE4-desktop goes just
fines, good performance, windows (exspecially GTK+) doesn't hang after
if I drag them over the screen, but there is lot of small tearing.
And I want this to go away, I do not use any kind of composition, and
I am using XFCEs window manager.


So use a compositor.  X's rendering model, in the absence of a 
compositor, has no concept of vsync.  It's simply not possible to not tear.


- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] GMA3150

[Adam Jackson]

On Wed, 2012-09-05 at 08:43 +0200, Luca Ellero wrote:

 Hi Adam,
 thank you for your quick reply.
 Anyway, if you don't mind I would like to ask you two more questions then:
 
 1) does this mean that I can't use Open Source Graphics Drivers for GMA3150?

Incorrect. The GMA3150 is supported by open drivers.

 2) if this is not true and Intel has not publicly released any 
 programming documentation for GMA3150, who and how are this drivers 
 written? By reading source code can we understand how GMA3150 works?

The gen3 support was originally written by Tungsten Graphics under
contract with Intel (with NDA documentation), and is currently
maintained by Intel directly.  It's quite readable, as drivers go.  In
many cases reading the code is more enlightening than reading
documentation anyway.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.20.6

[Adam Jackson]

On 9/2/12 5:40 AM, Chris Wilson wrote:


  * Incoherent concurrent access with the CPU and GPU
https://bugs.freedesktop.org/show_bug.cgi
https://bugs.freedesktop.org/show_bug.cgi


Which bugs were these meant to be?

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] GMA3150

[Adam Jackson]

On 9/4/12 9:41 AM, Luca Ellero wrote:


I've read this page:

http://intellinuxgraphics.org/documentation.html

and found a lot of interesting docs on various chipsets. But I'm
interested on GMA3150 (found for example on Atom processor D450
LunaPier) and I cannot find datasheets about it.
Can someone please tell me where can I find such docs or maybe if I can
refer to other chipsets  that are similar (maybe GM965).


The 3150 is a gen3 part, like the 915 and 945.  Intel has not publicly 
released any programming documentation for GPU generations older than 
gen4 (ie, 965).


- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] Check that the drm fd is i915 before calling i915 ioctls on it

[Adam Jackson]

Signed-off-by: Adam Jackson a...@redhat.com
---
 src/intel_module.c |   14 ++
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/src/intel_module.c b/src/intel_module.c
index edea48d..be9688a 100644
--- a/src/intel_module.c
+++ b/src/intel_module.c
@@ -392,11 +392,17 @@ static Bool has_kernel_mode_setting(struct pci_device 
*dev)
ret = FALSE;
fd = drmOpen(NULL, id);
if (fd != -1) {
-   struct drm_i915_getparam gp;
+   drmVersionPtr v;
 
-   gp.param = I915_PARAM_HAS_GEM;
-   gp.value = ret;
-   (void)drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, gp);
+   v = drmGetVersion(fd);
+   if (v  !strcmp(v-name, i915)) {
+   struct drm_i915_getparam gp;
+
+   gp.param = I915_PARAM_HAS_GEM;
+   gp.value = ret;
+   (void)drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, gp);
+   }
+   drmFreeVersion(v);
close(fd);
}
 
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [BUG] intel_drv.so fails to load

[Adam Jackson]

On 7/20/12 8:03 AM, Knut Petersen wrote:

Am 18.07.2012 16:29, schrieb Adam Jackson:

So this really honestly is a toolchain problem, not a driver problem.


Neither icecream nor gcc are broken.

The solution is pretty simple:


Never ever include -v or --verbose in CFLAGS


Why?

Because otherwise there will be some output to
stdout during the -fPIC test compile executed from
configure, and that output causes the build system
to erroneously assume that -fPIC does not work.

Hence xorg parts that normally would be build with
-fPIC will be built without that flag.


autoconf bug!  Nice find.


I think the test for -fPIC support is fundamentally
broken and should be fixed. Or would it be better
to check for -v and --verbose in CFLAGS?


It sounds like the test is broken, yeah.  Although I wonder how many 
other standard autoconf tests have this property.


- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [BUG] intel_drv.so fails to load

[Adam Jackson]

On 7/18/12 6:34 PM, Chris Wilson wrote:

On Wed, 18 Jul 2012 15:47:44 -0400, Adam Jackson a...@redhat.com wrote:

It's not clear to me if, subsequent to your change, DRI would work with
NoAccel.


It does. The mapping of the ring and control registers was already
managed outside of the XAA specific routines, so enabling the blit
function without the XAA infrastructure is fine.

Tested insofar as running glxgears on a remote i815 with XAA exorcised.
Not totally convinced I've verified all the necessary paths, but it
loads and seems to run.


Hah, nice, sounds like all one could expect from an i815.

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [BUG] intel_drv.so fails to load

[Adam Jackson]

On Tue, 2012-07-17 at 22:16 +0100, Chris Wilson wrote:
 On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen knut_peter...@t-online.de 
 wrote:
  Some XAA code still waits for a sudden death:
  
  [ 35756.654] (EE) Failed to load 
  /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: 
  /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined 
  symbol: XAAGetPatternROP
 
 Ok, pushed yet another patch to reimplement those tables within i810. I
 couldn't spot any more obvious XAA functions called from i810_accel, so
 hopefully this will be the last iteration!

Sigh.  Wish you hadn't, the linker behaviour he's seeing is _broken_.
Just because we don't know why doesn't make it not a bug.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [BUG] intel_drv.so fails to load

[Adam Jackson]

On Wed, 2012-07-18 at 15:07 +0100, Chris Wilson wrote:
 On Wed, 18 Jul 2012 10:02:08 -0400, Adam Jackson a...@redhat.com wrote:
  On Tue, 2012-07-17 at 22:16 +0100, Chris Wilson wrote:
   On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen 
   knut_peter...@t-online.de wrote:
Some XAA code still waits for a sudden death:

[ 35756.654] (EE) Failed to load 
/home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: 
/home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: 
undefined symbol: XAAGetPatternROP
   
   Ok, pushed yet another patch to reimplement those tables within i810. I
   couldn't spot any more obvious XAA functions called from i810_accel, so
   hopefully this will be the last iteration!
  
  Sigh.  Wish you hadn't, the linker behaviour he's seeing is _broken_.
  Just because we don't know why doesn't make it not a bug.
 
 Except it also meant that i810 was indeed broken since it was unusing
 undefined symbols.

No, not the case.

Normal ELF behaviour is that external data references are resolved at
object load time, but that function references are resolved when they
are first called; this is an optimization for app startup time.  The
former case is not what's going on here, because we're not taking the
address of XAAGetPatternROP (a data reference), we're calling it (a
function reference):

hate:~/driver/xf86-video-intel% git grep XAAGetPatternROP
src/legacy/i810/i810_accel.c:   (XAAGetPatternROP(rop)  16) |
src/legacy/i810/i810_xaa.c:   pI810-BR[13] |= XAAGetPatternROP(rop)  16;

So those should resolve lazily, which means if you never call them they
never _need_ to resolve.  And this is how X drivers normally work,
notice that libfb isn't loaded _before_ you load your driver but yet the
driver loads.

And we know the failure case here is not failing to lazily resolve,
because if we were hitting _that_ we wouldn't see the error message he's
seeing, ld.so would just bitch on stderr and _exit().  The error message
he's seeing is dlopen() failing.

So this really honestly is a toolchain problem, not a driver problem.

Knut, can you send me a copy of your driver binary?  I'm really curious
to see where that data reference is coming from, assuming BIND_NOW is
not what we're seeing.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] GPU reset notification interface

[Adam Jackson]

On Wed, 2012-07-18 at 09:23 -0700, Ian Romanick wrote:
 On 07/18/2012 02:20 AM, Daniel Vetter wrote:
  A few things:
  - I agree with Chris that reset_in_progress should go, if userspace can
 sneak in and witness a reset event, we have a bug in the kernel. Since
 very recently, we actually have a few bugs less in that area ;-)
 
 I'm operating under the assumption that, from user space's perspective, 
 resets are not instantaneous.  If resets are instantaneous, that may 
 change things.

Do they need to be instantaneous, or do they merely need to be
atomic-and-reasonably-quick?  Could just block new ioctl submission
until the reset completes.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [BUG] intel_drv.so fails to load

[Adam Jackson]

On Wed, 2012-07-18 at 20:04 +0200, Knut Petersen wrote:

 Ok, I built caef63e0268e59e439b030a9a338e81d5cf8e311 using
 
 export MYROOT=/home/knut/git/X11-t
 export PREFIX=$MYROOT/usr
 export EPREFIX=$PREFIX
 export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PREFIX/share/pkgconfig
 export PATH=$PREFIX/bin:$PATH
 export ACLOCAL=aclocal -I $PREFIX/share/aclocal
 export LD_LIBRARY_PATH=$PREFIX/lib
 export PYTHONPATH=$PREFIX/lib/python2.7/site-packages
 export MAKEFLAGS=-j 15
 export GMAKEFLAGS=-j 15
 export CC=/opt/icecream/bin/gcc
 export CXX=/opt/icecream/bin/g++
 export CFLAGS=-g2 -O3 --verbose -D MULTITOUCH
 export CXXFLAGS=-g2 -O3 
 export LD_PRELOAD=$PREFIX/lib/libmtdev.so
 util/modular/build.sh -g $PREFIX -o driver/xf86-video-intel --confflags 
 --disable-xaa  --localstatedir=$MYROOT/var
 
 and got the following log entries:
 
 [107706.682] (II) LoadModule: intel
 [107706.682] (II) Loading 
 /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so
 [107706.700] (EE) Failed to load 
 /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: 
 /home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined 
 symbol: XAAGetPatternROP
 [107706.700] (II) UnloadModule: intel
 [107706.700] (II) Unloading intel
 [107706.700] (EE) Failed to load module intel (loader failed, 7)
 [107706.700] (EE) No drivers available.
 [107706.709]
 Fatal server error:
 [107706.709] no screens found
 
 Bad behaviour restored.

So, one difference between the driver you built and the driver in
factory:

http://download.opensuse.org/pub/opensuse/factory/repo/oss/suse/i586/xf86-video-intel-2.20.0-1.1.i586.rpm

Is that yours has this, and theirs doesn't:

hate:~% eu-readelf -a intel_drv.so | grep TEXTREL
  TEXTREL   
  FLAGS TEXTREL

This suggests that you managed to build the X driver without -fPIC, and
eu-findtextrel(1) agrees.  This would cause the problem if text
relocations are also not lazy, and I believe that to be the case. [1]
To verify this assumption you could just jam -fPIC into CFLAGS and see
if the result works, but that's just papering over the bug, not
necessarily a fix.

I have no idea _how_ you managed to build it that way though.  I would
start by inspecting config.log and libtool from the build tree, or by
pointing $CC at real local gcc instead of icecream.

[1] - This, I think, is more artifact of implementation rather than
something done of necessity, but since textrels in DSOs are an i686ism
as far as Linux is concerned - and generally frowned upon even there -
it would be a lot of typing for little benefit.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [BUG] intel_drv.so fails to load

[Adam Jackson]

On Wed, 2012-07-18 at 15:36 +0100, Chris Wilson wrote:
 On Wed, 18 Jul 2012 10:29:26 -0400, Adam Jackson a...@redhat.com wrote:
  So those should resolve lazily, which means if you never call them they
  never _need_ to resolve.  And this is how X drivers normally work,
  notice that libfb isn't loaded _before_ you load your driver but yet the
  driver loads.
 
 They were being used by i810_dri.c, so i810 was busted. It just happened
 to be that the first user to spot this was not using i810.

Ennh.  PreInit does:

---
   if (xf86ReturnOptValBool(pI810-Options, OPTION_NOACCEL, FALSE))
  pI810-noAccel = TRUE;

   if (!pI810-noAccel) {
  if (!xf86LoadSubModule(scrn, xaa)) {
 I810FreeRec(scrn);
 return FALSE;
  }
   }

#ifdef HAVE_DRI1
   pI810-directRenderingDisabled =
 !xf86ReturnOptValBool(pI810-Options, OPTION_DRI, TRUE);

   if (!pI810-directRenderingDisabled) {
 if (pI810-noAccel) {
   xf86DrvMsg(scrn-scrnIndex, X_WARNING, DRI is disabled because it 
  needs 2D acceleration.\n);
   pI810-directRenderingDisabled=TRUE;
 } else if (scrn-depth!=16) {
   xf86DrvMsg(scrn-scrnIndex, X_WARNING, DRI is disabled because it 
  runs only at 16-bit depth.\n);
   pI810-directRenderingDisabled=TRUE;
 }
   }
#endif
---

So we default to asking for XAA, and if it doesn't load (because you
built without it) then neither will the driver; conversely, if XAA
loads, DRI's use of XAA symbols would be safe.  You'd have to have asked
for Option NoAccel to hit that bug.

It's not clear to me if, subsequent to your change, DRI would work with
NoAccel.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Can't start X headless

[Adam Jackson]

On Mon, 2012-07-16 at 09:23 +0100, Chris Wilson wrote:
 On Mon, 16 Jul 2012 16:18:19 +0800, Chris tlv...@gmail.com wrote:
  Hi All,
  
  I am trying desperately to find a working X config that would allow me
  to leverage the intel driver without a monitor being plugged in
  (Headless). We need to do some opengl rendering which are later saved
  on the disk as images and the jobs are executed on servers which by
  nature are headless.
  
  For reference, the server has an intel HD 2000 IGPU and I am using
  Ubuntu 12.04 LTS with the latest intel driver (2.19.0).
  I have tried everything I could think of without success.
  Always end up with:
  
  [3661641.967] (EE) No devices detected.
  [3661641.967] Fatal server error: no screens found
 
 This implies that it wasn't able to detect the Intel GPU at all. Can you
 please attach your dmesg and lspci? You may need to tweak your BIOS in
 case it is hiding the iGPU.

Well, no, the intel driver didn't bind because the OP booted into a
configuration that can't possibly work:

 [3661641.851] Kernel command line: 
 BOOT_IMAGE=/boot/bzImage-3.2.13--grs-ipv6-64 root=/dev/md1 ro text 
 nomodeset

'nomodeset' - no kms - no intel driver.

Once you've fixed that, if things still don't work, refer to the static
multihead configuration guide here:

http://intellinuxgraphics.org/dualhead.html

and just pick an output to enable; or, force it one on the kernel
command line by saying video=VGA-1:e to force it to be considered
enabled.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: prefer wide slow to fast narrow in DP configs

[Adam Jackson]

On Fri, 2012-06-22 at 10:05 +0100, Chris Wilson wrote:
 On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard kei...@keithp.com wrote:
  Jesse Barnes jbar...@virtuousgeek.org writes:
  
   High frequency link configurations have the potential to cause trouble
   with long and/or cheap cables, so prefer slow and wide configurations
   instead.  This patch has the potential to cause trouble for eDP
   configurations that lie about available lanes, so if we run into that we
   can make it conditional on eDP.

Have we considered looking at the link quality bits of DPCD for this?
Section 2.5.3.5 of the DP 1.1 spec looks apropos.  It looks painfully
slow to get all the way to the actual spec error rate, but it might not
be a bad first test to run for a second before doing actual link
training.  Do you have a crappy cable that produces this problem?

There's also a comment about the sink clearing the symbol lock and lane
alignment bits on too many errors (3.5.1.3.2); we're not periodically
re-checking those bits, maybe we should.

It's a shame they didn't bother to spec anything actually good, like
sink must report the number of ECC corrections it's done.  But I
suppose that applies to DP as a whole really.

  I *have* run into this on eDP machines already, which is why the code
  loops this way today...
 
 It was structured to minimise lane count because certain chipsets did
 not wire up all the lanes, right? Is that still relevant as we are using
 the advertised max_lane_count from the DPCD now?

Pretty sure it's structured to use minimum lane count because that's the
correct thing to do for power.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: pch_irq_handler - {ibx, cpt}_irq_handler

[Adam Jackson]

Cougar/Panther Point redefine the bits in SDEIIR pretty completely.
This function is just debugging, but if we're debugging we probably want
to be told accurate things instead of lies.

I'm told Lynx Point changes this yet more, but I have no idea how...

Signed-off-by: Adam Jackson a...@redhat.com
---
 drivers/gpu/drm/i915/i915_irq.c |   38 +++---
 drivers/gpu/drm/i915/i915_reg.h |   35 ---
 2 files changed, 67 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1417660..b1fe0ed 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -510,7 +510,7 @@ out:
return ret;
 }
 
-static void pch_irq_handler(struct drm_device *dev, u32 pch_iir)
+static void ibx_irq_handler(struct drm_device *dev, u32 pch_iir)
 {
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
int pipe;
@@ -550,6 +550,35 @@ static void pch_irq_handler(struct drm_device *dev, u32 
pch_iir)
DRM_DEBUG_DRIVER(PCH transcoder A underrun interrupt\n);
 }
 
+static void cpt_irq_handler(struct drm_device *dev, u32 pch_iir)
+{
+   drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
+   int pipe;
+
+   if (pch_iir  SDE_AUDIO_POWER_MASK_CPT)
+   DRM_DEBUG_DRIVER(PCH audio power change on port %d\n,
+(pch_iir  SDE_AUDIO_POWER_MASK_CPT) 
+SDE_AUDIO_POWER_SHIFT_CPT);
+
+   if (pch_iir  SDE_AUX_MASK_CPT)
+   DRM_DEBUG_DRIVER(AUX channel interrupt\n);
+
+   if (pch_iir  SDE_GMBUS_CPT)
+   DRM_DEBUG_DRIVER(PCH GMBUS interrupt\n);
+
+   if (pch_iir  SDE_AUDIO_CP_REQ_CPT)
+   DRM_DEBUG_DRIVER(Audio CP request interrupt\n);
+
+   if (pch_iir  SDE_AUDIO_CP_CHG_CPT)
+   DRM_DEBUG_DRIVER(Audio CP change interrupt\n);
+
+   if (pch_iir  SDE_FDI_MASK_CPT)
+   for_each_pipe(pipe)
+   DRM_DEBUG_DRIVER(  pipe %c FDI IIR: 0x%08x\n,
+pipe_name(pipe),
+I915_READ(FDI_RX_IIR(pipe)));
+}
+
 static irqreturn_t ivybridge_irq_handler(DRM_IRQ_ARGS)
 {
struct drm_device *dev = (struct drm_device *) arg;
@@ -591,7 +620,7 @@ static irqreturn_t ivybridge_irq_handler(DRM_IRQ_ARGS)
 
if (pch_iir  SDE_HOTPLUG_MASK_CPT)
queue_work(dev_priv-wq, 
dev_priv-hotplug_work);
-   pch_irq_handler(dev, pch_iir);
+   cpt_irq_handler(dev, pch_iir);
 
/* clear PCH hotplug event before clear CPU irq */
I915_WRITE(SDEIIR, pch_iir);
@@ -684,7 +713,10 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS)
if (de_iir  DE_PCH_EVENT) {
if (pch_iir  hotplug_mask)
queue_work(dev_priv-wq, dev_priv-hotplug_work);
-   pch_irq_handler(dev, pch_iir);
+   if (HAS_PCH_CPT(dev))
+   cpt_irq_handler(dev, pch_iir);
+   else
+   ibx_irq_handler(dev, pch_iir);
}
 
if (de_iir  DE_PCU_EVENT) {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2d49b95..b27bcf6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3313,7 +3313,7 @@
 
 /* PCH */
 
-/* south display engine interrupt */
+/* south display engine interrupt: IBX */
 #define SDE_AUDIO_POWER_D  (1  27)
 #define SDE_AUDIO_POWER_C  (1  26)
 #define SDE_AUDIO_POWER_B  (1  25)
@@ -3349,15 +3349,44 @@
 #define SDE_TRANSA_CRC_ERR (1  1)
 #define SDE_TRANSA_FIFO_UNDER  (1  0)
 #define SDE_TRANS_MASK (0x3f)
-/* CPT */
-#define SDE_CRT_HOTPLUG_CPT(1  19)
+
+/* south display engine interrupt: CPT/PPT */
+#define SDE_AUDIO_POWER_D_CPT  (1  31)
+#define SDE_AUDIO_POWER_C_CPT  (1  30)
+#define SDE_AUDIO_POWER_B_CPT  (1  29)
+#define SDE_AUDIO_POWER_SHIFT_CPT   29
+#define SDE_AUDIO_POWER_MASK_CPT(7  29)
+#define SDE_AUXD_CPT   (1  27)
+#define SDE_AUXC_CPT   (1  26)
+#define SDE_AUXB_CPT   (1  25)
+#define SDE_AUX_MASK_CPT   (7  25)
 #define SDE_PORTD_HOTPLUG_CPT  (1  23)
 #define SDE_PORTC_HOTPLUG_CPT  (1  22)
 #define SDE_PORTB_HOTPLUG_CPT  (1  21)
+#define SDE_CRT_HOTPLUG_CPT(1  19)
 #define SDE_HOTPLUG_MASK_CPT   (SDE_CRT_HOTPLUG_CPT |  \
 SDE_PORTD_HOTPLUG_CPT |\
 SDE_PORTC_HOTPLUG_CPT |\
 SDE_PORTB_HOTPLUG_CPT)
+#define SDE_GMBUS_CPT  (1  17)
+#define SDE_AUDIO_CP_REQ_C_CPT (1  10)
+#define SDE_AUDIO_CP_CHG_C_CPT (1  9)
+#define SDE_FDI_RXC_CPT(1  8)
+#define SDE_AUDIO_CP_REQ_B_CPT (1  6)
+#define SDE_AUDIO_CP_CHG_B_CPT

Re: [Intel-gfx] [PATCH 02/14] drm: handle HDP and polled connectors separately

[Adam Jackson]

On 5/24/12 3:26 PM, Daniel Vetter wrote:

Instead of reusing the polling code for hdp handling, split them up.
This has a few consequences:
- Don't touch HDP capable connectors in the poll loop.
- Only touch HDP capable connectors in drm_helper_hpd_irq_event.
- Run the HDP handling directly instead of going through a work item -
   all callers already call drm_helper_hpd_irq_event from process
   context without holding the mode_config mutex.


HPD.


-   /* if this is HPD or polled don't check it -
-  TV out for instance */
-   if (!connector-polled)
+   /* Ignore HDP capable connectors and connectors where we don't
+* want any hotplug detection at all for polling. */
+   if (!connector-polled || connector-polled == 
DRM_CONNECTOR_POLL_HPD)


Here too.  Also in the subject.

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/edid: adjust double-clocked cea modes

[Adam Jackson]

On 5/14/12 3:43 PM, Paulo Zanoni wrote:


Also, I think flag DRM_MODE_FLAG_DBLCLK does not sound correct for
them, so we would need to create flags:
- DRM_MODE_FLAG_PR_1_to_10
- DRM_MODE_FLAG_PR_1_or_2
- DRM_MODE_FLAG_PR_1_or_2_or_4

Or any other more creative names. And then we should cross our fingers
in the hope that they don't start creating modes with other possible
variations of PR :)
Anyway, how will the user be able to choose the wanted PR? What about
the aspect ratio? Yet Another Connector Property?


Well, one thing at a time.

Right now we don't have the concept of a mode property.  Therefore, 
modes exposed to userspace should all be unique.  Exposing the pixel 
repeat to userspace as a connector property is wrong because it doesn't 
apply to all modes for a connector.


So my initial inclination would be to do something like this in the 
flags field:


--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -58,6 +58,9 @@
 #define DRM_MODE_FLAG_PIXMUX   (111)
 #define DRM_MODE_FLAG_DBLCLK   (112)
 #define DRM_MODE_FLAG_CLKDIV2  (113)
+/* begin non-xorg definitions */
+#define DRM_PIXREP_MASK(15  14)
+#define DRM_MODE_FLAG_PIXREP(x) (((x)  14)  DRM_PIXMULT_MASK)

 /* DPMS flags */
 /* bit compatible with the xorg definitions. */

The timings for the variably-repeated modes won't change (right?) so 
this is the only way to get the desired pixel repeat passed into the 
modesettinng path.  And then the one to ten and one two or four 
modes simply need to be added to the list multiple times, once for each 
possible pixel replication, and with varying names depending on the 
effective framebuffer size.


Problems with this approach are that it means rewriting the CEA mode 
list or the VIC table walk or both, and that it means creating a class 
of modes that userspace can set but not create (which means, if your X 
driver is parsing EDID itself instead of just using the damn kernel mode 
list, that many of the modes will be inaccessible to X).  Neither is 
insoluble, just nngh.


The dual-aspect-ratio modes are, well, ugly.  Ideally we'd have scaler 
hardware on all digital output routes so we could just make that a 
connector property, and then hide the choice of mechanism inside the drm 
(either in the monitor if the infoframe says so / if it's controllable 
with DDC/CI or something, or in the GPU if not).  I don't know if all 
the digital outputs in the world live up to that lofty goal.  Failing 
that we could encode the widescreen-ness in the mode name?  All quite 
horrible.  TVs really are the worst thing.


I think at some point we're going to need to reconsider using xserver's 
data type for the mode so literally.


- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/edid: adjust double-clocked cea modes

[Adam Jackson]

On Sun, 2012-05-13 at 00:07 +0200, Daniel Vetter wrote:

 The problem left is that the CEA spec specifies these modes with
 timings as they get transmitted, but because the double-clocking is
 just to make the HDMI phy happy, the TV actually drops every 2nd
 pixel. So e.g. a 1440x576 mode in our CEA mode list is actually a
 720x576 mode.

Well, okay, but...

   /* 9 - 1440x240@60Hz */
 - { DRM_MODE(1440x240, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
 + { DRM_MODE(720x240, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
  1602, 1716, 0, 240, 244, 247, 262, 0,
  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
   DRM_MODE_FLAG_DBLCLK) },

... right after this are the 2800x480 modes.  Are they really 720, 1440,
or 2880 wide?  Both before and after this change they're 2880 wide, but
the logic of this change makes me believe they should not be.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Suppress hotplug work during PM suspend/resume

[Adam Jackson]

On Thu, 2012-04-19 at 18:10 +0200, Takashi Iwai wrote:

 This patch adds a flag to disable the hotplug during PM operation for
 avoiding such a race.
 
 Cc: sta...@kernel.org
 Signed-off-by: Takashi Iwai ti...@suse.de

This seems simpler (untested):

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1a7559b..1cd77a4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -530,11 +530,12 @@ static int i915_drm_thaw(struct drm_device *dev)
ironlake_init_pch_refclk(dev);
 
drm_mode_config_reset(dev);
-   drm_irq_install(dev);
 
/* Resume the modeset for every activated CRTC */
drm_helper_resume_force_mode(dev);
 
+   drm_irq_install(dev);
+
if (IS_IRONLAKE_M(dev))
ironlake_enable_rc6(dev);

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: make PCH poison interrupt debug only

[Adam Jackson]

On Wed, 2012-04-18 at 10:20 -0700, Jesse Barnes wrote:
 This indicates an internal messaging issue between the CPU and PCH, but
 there's nothing the driver can do about it.  We seem to be able to
 trigger it at hotplug time sometimes, possibly due to the interrupt
 corrupting an in-flight message between CPU and PCH.  At any rate, the
 error is harmless, so there's no need to bother the user about it.

I'm unconvinced.  The bugs I've seen tend to have these messages in
combination with actual output setup problems.  If that's going to be
reliably true I'd just as soon always see the message without needing
drm.debug=7.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/12] drm/edid: Update range descriptor struct for EDID 1.4

[Adam Jackson]

On Tue, 2012-04-17 at 17:25 +0200, Takashi Iwai wrote:
 At Fri, 13 Apr 2012 16:33:37 -0400, Adam Jackson wrote:
  +   u8 flags;
  +   union {
  +   struct {
  +   u8 reserved;
  +   u8 hfreq_start_khz; /* need to multiply by 2 */
  +   u8 c; /* need to divide by 2 */
  +   __le16 m;
  +   u8 k;
  +   u8 j; /* need to divide by 2 */
  +   } gtf2;
  +   struct {
  +   u8 version;
  +   u8 data1; /* high 6 bits: extra clock resolution */
  +   u8 data2; /* plus low 2 of above: max hactive */
  +   u8 supported_aspects;
  +   u8 flags; /* preferred aspect and blanking support */
  +   u8 supported_scalings;
  +   u8 preferred_refresh;
  +   } cvt;
 
 These new structs must be marked with __attribute__((packed)) although
 the struct detailed_data_monitor_range itself is already marked.  At
 least, with gcc 4.6 and x86-64 here, they get unaligned.

Eek.  Good catch, thanks.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Do not set Enable Panel Fitter on SNB pageflips

[Adam Jackson]

On Tue, 2012-04-17 at 20:37 +0100, Chris Wilson wrote:
 Not only do the pageflip work without it at non-native modes (i.e. with
 the panel fitter enabled), it also causes normal (non-pageflipped)
 modesets to fail.

Testcase: enable a GLX compositor like gnome-shell, resize X to
something other than LVDS native size, vt switch to text console, frown
at black screen of doom.

Fixes the above testcase on a Lenovo X220.

Tested-by: Adam Jackson a...@redhat.com

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Try harder on multifunction SDVO DDC

[Adam Jackson]

On Mon, 2012-04-16 at 01:10 +0200, Daniel Vetter wrote:

 But while looking through the git history I've noticed that this code got
 added before we've figured out the vbios sdvo ddc pin mappings game, so
 I'm inclined to just rip this out. Especially since we start at the ddc
 that does _not_ read our edid and don't unconditionally test all 3 ddc
 buses, potentially leaving out bus 32. Does anyone know why we've needed
 this or maybe even have the hw?

Yeah, I've never liked this path.  Use the pin mappings.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Suggestions on fixing fill_modes ioctl() delays under i915

[Adam Jackson]

On Mon, 2012-04-16 at 18:54 +0300, Dan Aloni wrote:

 Okay, with 3.4-rc3 I can confirm that it works much better. For the
 xrandr test case, I've timed each ioctl to about 60 milli-secs with 9
 calls spanning over half a second. Any further suggestions? Isn't it
 possible to tell that nothing is connected and then not try to probe
 those ports at all?

There could be such detection, but there is not.  We have hotplug
interrupts, but we don't trust them to actually tell us whether
something is connected.  (We don't trust them because we think they're
unreliable, and then they remain unreliable because we don't fix the
implementation to be trustworthy.)  We just turn the interrupts into
uevents and then rely on userspace to compensate for the kernel not
doing a good enough job.

Since we don't do that, the only way to tell that nothing is connected
is to probe.  We could make probing a bit faster by caching previous
EDID and memcmp'ing the first 16 bytes (which include the
vendor/model/serial tuple, which should be unique enough) instead of
retrying the whole EDID fetch unconditionally.

But, as Chris said: You probably want to fix SDL to use
GetScreenResourcesCurrent since GetScreenResources is really only meant
for the session's configuration manager; and if you're running xrandr by
hand, use xrandr --current.

- ajax


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

[Adam Jackson]

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 bug.  That's why I said it should be renamed 
drm_dmt_modes_for_range and run unconditionally if we find a range 
descriptor.



The thing you're trying
to sneak in here is a 1600x900 timing that doesn't correspond to
anything in DMT (at least, not in the copy of DMT that I have handy).
It's fine to want to add more modes - although I'm still unclear exactly
which machine you're trying to compensate for here - but not if it comes
by sacrificing the DMT list, which is there for a reason.


There are customers complaining about lots of missing modes that are
supported by windows and/or other drivers and we are missing. If this
modes are ok on edid spec I se no problem in add them... ok.. I don't
like hardcoded as well... I think we could find another way to invent
this modes and use the cvt function to calculate timings... or
something like that.


Why are they complaining, and why do you think you're obligated to care?

If it's not the native panel size and it's not a commonly found size in 
the wild, why are we obligated to provide them for every user?  Remember 
that userspace has the ability to hand in modes from above.



+ /* 1024x576@60Hz */
+ { DRM_MODE(1024x576, DRM_MODE_TYPE_DRIVER, 46500, 1024, 1064,
+1160, 1296, 0, 576, 579, 584, 599, 0,
+DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 2560x1600@60Hz */
+ { DRM_MODE(2560x1600, DRM_MODE_TYPE_DRIVER, 348500, 2560, 2760,
+3032, 3504, 0, 1600, 1603, 1609, 1658, 0,
+DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },


These ones came as request from HP.
I'll check how they made that list.


1024x576 almost makes some sense, it's the fat-pixel version of 
2048x1152.  Except that you typically do fat-pixel modes like 1280x800 
on a 2560x1600 screen because you're compensating for the host not being 
able to do dual-link DVI (cough Intel), but 2048x1152 fits in a single link.


That 2560 mode appears to have been copied from the DMT list, but 
seriously nobody does that size without doing reduced blanking.  So if 
we took my series to add the RB modes to the DMT list, and fixed that 
bug I mentioned above...


- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

[Adam Jackson]

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 one.  For asymmetric cloning, a misfeature 
exceeded in stupidity only by panning.  Because you have a panel with a 
bizarre size and then an external that's sane, and you try to clone, and 
even though the bizarre size would fit it's not available on both mode 
lists.


And at _that_ point, this isn't an EDID parser issue at all, it's driver 
policy.


- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/7] drm/edid: Armor drm_dmt_modes_for_range for reduced blanking modes

[Adam Jackson]

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_rb(drm_dmt_modes[i])
+   !drm_monitor_supports_rb(edid))
+   continue;
+
newmode = drm_mode_duplicate(dev,drm_dmt_modes[i]);
if (newmode) {
drm_mode_probed_add(connector, newmode);


This chunk is actually unnecessary, upon second reading. 
mode_in_range() already checks this.


New series in a moment that addresses the extra mode list from HP.

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 00/12] Add more DMT and common modes

[Adam Jackson]

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 extra modes

This still doesn't address the driver policy decision of I know I have
a scaler, add modes as if there were a range descriptor even if there's
not one.  But it should at least make clear what such a helper function
should do.

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 01/12] drm/edid: Document drm_mode_find_dmt

[Adam Jackson]

Signed-off-by: Adam Jackson a...@redhat.com
---
 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
@@ -486,6 +486,16 @@ static void edid_fixup_preferred(struct drm_connector 
*connector,
preferred_mode-type |= DRM_MODE_TYPE_PREFERRED;
 }
 
+/*
+ * drm_mode_find_dmt - Create a copy of a mode if present in DMT
+ * @dev: Device to duplicate against
+ * @hsize: Mode width
+ * @vsize: Mode height
+ * @fresh: Mode refresh rate
+ *
+ * Walk the DMT mode list looking for a match for the given parameters.
+ * Return a newly allocated copy of the mode, or NULL if not found.
+ */
 struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
   int hsize, int vsize, int fresh)
 {
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 02/12] drm/edid: Rewrite drm_mode_find_dmt search loop

[Adam Jackson]

No functional change, but will make an upcoming change clearer.

Signed-off-by: Adam Jackson a...@redhat.com
---
 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 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -499,20 +499,21 @@ static void edid_fixup_preferred(struct drm_connector 
*connector,
 struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
   int hsize, int vsize, int fresh)
 {
-   struct drm_display_mode *mode = NULL;
int i;
 
for (i = 0; i  drm_num_dmt_modes; i++) {
const struct drm_display_mode *ptr = drm_dmt_modes[i];
-   if (hsize == ptr-hdisplay 
-   vsize == ptr-vdisplay 
-   fresh == drm_mode_vrefresh(ptr)) {
-   /* get the expected default mode */
-   mode = drm_mode_duplicate(dev, ptr);
-   break;
-   }
+   if (hsize != ptr-hdisplay)
+   continue;
+   if (vsize != ptr-vdisplay)
+   continue;
+   if (fresh != drm_mode_vrefresh(ptr))
+   continue;
+
+   return drm_mode_duplicate(dev, ptr);
}
-   return mode;
+
+   return NULL;
 }
 EXPORT_SYMBOL(drm_mode_find_dmt);
 
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 03/12] drm/edid: Allow drm_mode_find_dmt to hunt for reduced-blanking modes

[Adam Jackson]

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 list regrows the r-b modes, but practically speaking EST3
codes don't exist in the wild.

Signed-off-by: Adam Jackson a...@redhat.com
---
 drivers/gpu/drm/drm_edid.c  |   37 -
 drivers/gpu/drm/drm_fb_helper.c |2 +-
 include/drm/drm_crtc.h  |3 ++-
 3 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0a23ee5..4f52103 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -486,18 +486,29 @@ static void edid_fixup_preferred(struct drm_connector 
*connector,
preferred_mode-type |= DRM_MODE_TYPE_PREFERRED;
 }
 
+static bool
+mode_is_rb(const struct drm_display_mode *mode)
+{
+   return (mode-htotal - mode-hdisplay == 160) 
+  (mode-hsync_end - mode-hdisplay == 80) 
+  (mode-hsync_end - mode-hsync_start == 32) 
+  (mode-vsync_start - mode-vdisplay == 3);
+}
+
 /*
  * drm_mode_find_dmt - Create a copy of a mode if present in DMT
  * @dev: Device to duplicate against
  * @hsize: Mode width
  * @vsize: Mode height
  * @fresh: Mode refresh rate
+ * @rb: Mode reduced-blanking-ness
  *
  * Walk the DMT mode list looking for a match for the given parameters.
  * Return a newly allocated copy of the mode, or NULL if not found.
  */
 struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
-  int hsize, int vsize, int fresh)
+  int hsize, int vsize, int fresh,
+  bool rb)
 {
int i;
 
@@ -509,6 +520,8 @@ struct drm_display_mode *drm_mode_find_dmt(struct 
drm_device *dev,
continue;
if (fresh != drm_mode_vrefresh(ptr))
continue;
+   if (rb != mode_is_rb(ptr))
+   continue;
 
return drm_mode_duplicate(dev, ptr);
}
@@ -742,10 +755,17 @@ drm_mode_std(struct drm_connector *connector, struct edid 
*edid,
}
 
/* check whether it can be found in default mode table */
-   mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate);
+   if (drm_monitor_supports_rb(edid)) {
+   mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate,
+true);
+   if (mode)
+   return mode;
+   }
+   mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate, false);
if (mode)
return mode;
 
+   /* okay, generate it */
switch (timing_level) {
case LEVEL_DMT:
break;
@@ -920,15 +940,6 @@ static struct drm_display_mode *drm_mode_detailed(struct 
drm_device *dev,
 }
 
 static bool
-mode_is_rb(const struct drm_display_mode *mode)
-{
-   return (mode-htotal - mode-hdisplay == 160) 
-  (mode-hsync_end - mode-hdisplay == 80) 
-  (mode-hsync_end - mode-hsync_start == 32) 
-  (mode-vsync_start - mode-vdisplay == 3);
-}
-
-static bool
 mode_in_hsync_range(const struct drm_display_mode *mode,
struct edid *edid, u8 *t)
 {
@@ -1073,8 +1084,8 @@ drm_est3_modes(struct drm_connector *connector, struct 
detailed_timing *timing)
mode = drm_mode_find_dmt(connector-dev,
 est3_modes[m].w,
 est3_modes[m].h,
-est3_modes[m].r
-/*, est3_modes[m].rb 
*/);
+est3_modes[m].r,
+est3_modes[m].rb);
if (mode) {
drm_mode_probed_add(connector, mode);
modes++;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a0d6e89..6e19dd1 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1083,7 +1083,7 @@ static bool drm_target_cloned(struct drm_fb_helper 
*fb_helper,
 
/* try and find a 1024x768 mode on each connector */
can_clone = true;
-   dmt_mode = drm_mode_find_dmt(fb_helper-dev, 1024, 768, 60);
+   dmt_mode = drm_mode_find_dmt(fb_helper-dev, 1024, 768, 60, false);
 
for (i = 0; i  fb_helper-connector_count; i++) {
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e250eda..2be73d7 100644
--- a/include/drm/drm_crtc.h
+++ b/include

[Intel-gfx] [PATCH 04/12] drm/edid: Remove a misleading comment

[Adam Jackson]

mode_in_range() handles what this was warning about.

Signed-off-by: Adam Jackson a...@redhat.com
---
 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/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1016,10 +1016,6 @@ mode_in_range(const struct drm_display_mode *mode, 
struct edid *edid,
return true;
 }
 
-/*
- * XXX If drm_dmt_modes ever regrows the CVT-R modes (and it will) this will
- * need to account for them.
- */
 static int
 drm_gtf_modes_for_range(struct drm_connector *connector, struct edid *edid,
struct detailed_timing *timing)
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 05/12] drm/edid: s/drm_gtf_modes_for_range/drm_dmt_modes_for_range/

[Adam Jackson]

Slightly more honest naming.

Signed-off-by: Adam Jackson a...@redhat.com
---
 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/gpu/drm/drm_edid.c
@@ -1017,7 +1017,7 @@ mode_in_range(const struct drm_display_mode *mode, struct 
edid *edid,
 }
 
 static int
-drm_gtf_modes_for_range(struct drm_connector *connector, struct edid *edid,
+drm_dmt_modes_for_range(struct drm_connector *connector, struct edid *edid,
struct detailed_timing *timing)
 {
int i, modes = 0;
@@ -1045,7 +1045,7 @@ do_inferred_modes(struct detailed_timing *timing, void *c)
int gtf = (closure-edid-features  DRM_EDID_FEATURE_DEFAULT_GTF);
 
if (gtf  data-type == EDID_DETAIL_MONITOR_RANGE)
-   closure-modes += drm_gtf_modes_for_range(closure-connector,
+   closure-modes += drm_dmt_modes_for_range(closure-connector,
  closure-edid,
  timing);
 }
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 06/12] drm/edid: Add the reduced blanking DMT modes to the DMT list

[Adam Jackson]

Copied from the list in xserver.

Signed-off-by: Adam Jackson a...@redhat.com
---
 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..4be9c1a 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -30,7 +30,6 @@
 /*
  * Autogenerated from the DMT spec.
  * This table is copied from xfree86/modes/xf86EdidModes.c.
- * But the mode with Reduced blank feature is deleted.
  */
 static const struct drm_display_mode drm_dmt_modes[] = {
/* 640x350@85Hz */
@@ -81,6 +80,10 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE(800x600, DRM_MODE_TYPE_DRIVER, 56250, 800, 832,
   896, 1048, 0, 600, 601, 604, 631, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 800x600@120Hz RB */
+   { DRM_MODE(800x600, DRM_MODE_TYPE_DRIVER, 73250, 800, 848,
+  880, 960, 0, 600, 603, 607, 636, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 848x480@60Hz */
{ DRM_MODE(848x480, DRM_MODE_TYPE_DRIVER, 33750, 848, 864,
   976, 1088, 0, 480, 486, 494, 517, 0,
@@ -106,10 +109,18 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE(1024x768, DRM_MODE_TYPE_DRIVER, 94500, 1024, 1072,
   1168, 1376, 0, 768, 769, 772, 808, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 1024x768@120Hz RB */
+   { DRM_MODE(1024x768, DRM_MODE_TYPE_DRIVER, 115500, 1024, 1072,
+  1104, 1184, 0, 768, 771, 775, 813, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1152x864@75Hz */
{ DRM_MODE(1152x864, DRM_MODE_TYPE_DRIVER, 108000, 1152, 1216,
   1344, 1600, 0, 864, 865, 868, 900, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 1280x768@60Hz RB */
+   { DRM_MODE(1280x768, DRM_MODE_TYPE_DRIVER, 68250, 1280, 1328,
+  1360, 1440, 0, 768, 771, 778, 790, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1280x768@60Hz */
{ DRM_MODE(1280x768, DRM_MODE_TYPE_DRIVER, 79500, 1280, 1344,
   1472, 1664, 0, 768, 771, 778, 798, 0,
@@ -122,6 +133,14 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE(1280x768, DRM_MODE_TYPE_DRIVER, 117500, 1280, 1360,
   1496, 1712, 0, 768, 771, 778, 809, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 1280x768@120Hz RB */
+   { DRM_MODE(1280x768, DRM_MODE_TYPE_DRIVER, 140250, 1280, 1328,
+  1360, 1440, 0, 768, 771, 778, 813, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 1280x800@60Hz RB */
+   { DRM_MODE(1280x800, DRM_MODE_TYPE_DRIVER, 71000, 1280, 1328,
+  1360, 1440, 0, 800, 803, 809, 823, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1280x800@60Hz */
{ DRM_MODE(1280x800, DRM_MODE_TYPE_DRIVER, 83500, 1280, 1352,
   1480, 1680, 0, 800, 803, 809, 831, 0,
@@ -134,6 +153,10 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE(1280x800, DRM_MODE_TYPE_DRIVER, 122500, 1280, 1360,
   1496, 1712, 0, 800, 803, 809, 843, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 1280x800@120Hz RB */
+   { DRM_MODE(1280x800, DRM_MODE_TYPE_DRIVER, 146250, 1280, 1328,
+  1360, 1440, 0, 800, 803, 809, 847, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1280x960@60Hz */
{ DRM_MODE(1280x960, DRM_MODE_TYPE_DRIVER, 108000, 1280, 1376,
   1488, 1800, 0, 960, 961, 964, 1000, 0,
@@ -142,6 +165,10 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE(1280x960, DRM_MODE_TYPE_DRIVER, 148500, 1280, 1344,
   1504, 1728, 0, 960, 961, 964, 1011, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 1280x960@120Hz RB */
+   { DRM_MODE(1280x960, DRM_MODE_TYPE_DRIVER, 175500, 1280, 1328,
+  1360, 1440, 0, 960, 963, 967, 1017, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1280x1024@60Hz */
{ DRM_MODE(1280x1024, DRM_MODE_TYPE_DRIVER, 108000, 1280, 1328,
   1440, 1688, 0, 1024, 1025, 1028, 1066, 0,
@@ -154,10 +181,22 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE(1280x1024, DRM_MODE_TYPE_DRIVER, 157500, 1280, 1344,
   1504, 1728, 0, 1024, 1025, 1028, 1072, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 1280x1024@120Hz RB */
+   { DRM_MODE(1280x1024, DRM_MODE_TYPE_DRIVER, 187250, 1280, 1328

[Intel-gfx] [PATCH 07/12] drm/edid: Fix some comment typos in the DMT mode list

[Adam Jackson]

Signed-off-by: Adam Jackson a...@redhat.com
---
 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/gpu/drm/drm_edid_modes.h
@@ -197,15 +197,15 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE(1400x1050, DRM_MODE_TYPE_DRIVER, 101000, 1400, 1448,
   1480, 1560, 0, 1050, 1053, 1057, 1080, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
-   /* 1440x1050@60Hz */
+   /* 1400x1050@60Hz */
{ DRM_MODE(1400x1050, DRM_MODE_TYPE_DRIVER, 121750, 1400, 1488,
   1632, 1864, 0, 1050, 1053, 1057, 1089, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
-   /* 1440x1050@75Hz */
+   /* 1400x1050@75Hz */
{ DRM_MODE(1400x1050, DRM_MODE_TYPE_DRIVER, 156000, 1400, 1504,
   1648, 1896, 0, 1050, 1053, 1057, 1099, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
-   /* 1440x1050@85Hz */
+   /* 1400x1050@85Hz */
{ DRM_MODE(1400x1050, DRM_MODE_TYPE_DRIVER, 179500, 1400, 1504,
   1656, 1912, 0, 1050, 1053, 1057, 1105, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
@@ -281,7 +281,7 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE(1792x1344, DRM_MODE_TYPE_DRIVER, 204750, 1792, 1920,
   2120, 2448, 0, 1344, 1345, 1348, 1394, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
-   /* 1729x1344@75Hz */
+   /* 1792x1344@75Hz */
{ DRM_MODE(1792x1344, DRM_MODE_TYPE_DRIVER, 261000, 1792, 1888,
   2104, 2456, 0, 1344, 1345, 1348, 1417, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
@@ -289,7 +289,7 @@ static const struct drm_display_mode drm_dmt_modes[] = {
{ DRM_MODE(1792x1344, DRM_MODE_TYPE_DRIVER, 333250, 1792, 1840,
   1872, 1952, 0, 1344, 1347, 1351, 1423, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
-   /* 1853x1392@60Hz */
+   /* 1856x1392@60Hz */
{ DRM_MODE(1856x1392, DRM_MODE_TYPE_DRIVER, 218250, 1856, 1952,
   2176, 2528, 0, 1392, 1393, 1396, 1439, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 08/12] drm/edid: Do drm_dmt_modes_for_range() for all range descriptor types

[Adam Jackson]

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-by: Adam Jackson a...@redhat.com
---
 drivers/gpu/drm/drm_edid.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 355e6a0..7131f38 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1042,12 +1042,13 @@ do_inferred_modes(struct detailed_timing *timing, void 
*c)
 {
struct detailed_mode_closure *closure = c;
struct detailed_non_pixel *data = timing-data.other_data;
-   int gtf = (closure-edid-features  DRM_EDID_FEATURE_DEFAULT_GTF);
 
-   if (gtf  data-type == EDID_DETAIL_MONITOR_RANGE)
-   closure-modes += drm_dmt_modes_for_range(closure-connector,
- closure-edid,
- timing);
+   if (data-type != EDID_DETAIL_MONITOR_RANGE)
+   return;
+
+   closure-modes += drm_dmt_modes_for_range(closure-connector,
+ closure-edid,
+ timing);
 }
 
 static int
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 09/12] drm/edid: Update range descriptor struct for EDID 1.4

[Adam Jackson]

Signed-off-by: Adam Jackson a...@redhat.com
---
 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,12 +90,26 @@ struct detailed_data_monitor_range {
u8 min_hfreq_khz;
u8 max_hfreq_khz;
u8 pixel_clock_mhz; /* need to multiply by 10 */
-   __le16 sec_gtf_toggle; /* A000=use above, 20=use below */
-   u8 hfreq_start_khz; /* need to multiply by 2 */
-   u8 c; /* need to divide by 2 */
-   __le16 m;
-   u8 k;
-   u8 j; /* need to divide by 2 */
+   u8 flags;
+   union {
+   struct {
+   u8 reserved;
+   u8 hfreq_start_khz; /* need to multiply by 2 */
+   u8 c; /* need to divide by 2 */
+   __le16 m;
+   u8 k;
+   u8 j; /* need to divide by 2 */
+   } gtf2;
+   struct {
+   u8 version;
+   u8 data1; /* high 6 bits: extra clock resolution */
+   u8 data2; /* plus low 2 of above: max hactive */
+   u8 supported_aspects;
+   u8 flags; /* preferred aspect and blanking support */
+   u8 supported_scalings;
+   u8 preferred_refresh;
+   } cvt;
+   } formula;
 } __attribute__((packed));
 
 struct detailed_data_wpindex {
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 10/12] drm/edid: Give the est3 mode struct a real name

[Adam Jackson]

We want the same type for extra modes inferred from ranges.

Signed-off-by: Adam Jackson a...@redhat.com
---
 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 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -412,12 +412,14 @@ static const struct drm_display_mode edid_est_modes[] = {
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) }, /* 
1152x864@75Hz */
 };
 
-static const struct {
+struct minimode {
short w;
short h;
short r;
short rb;
-} est3_modes[] = {
+};
+
+static const struct minimode est3_modes[] = {
/* byte 6 */
{ 640, 350, 85, 0 },
{ 640, 400, 85, 0 },
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 11/12] drm/edid: Add extra_modes

[Adam Jackson]

Some common sizes that don't show up in DMT.

Signed-off-by: Adam Jackson a...@redhat.com
---
 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
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -473,6 +473,17 @@ static const struct minimode est3_modes[] = {
 };
 static const int num_est3_modes = sizeof(est3_modes) / sizeof(est3_modes[0]);
 
+static const struct minimode extra_modes[] = {
+   { 1024, 576,  60, 0 },
+   { 1366, 768,  60, 0 },
+   { 1600, 900,  60, 0 },
+   { 1680, 945,  60, 0 },
+   { 1920, 1080, 60, 0 },
+   { 2048, 1152, 60, 0 },
+   { 2048, 1536, 60, 0 },
+};
+static const int num_extra_modes = sizeof(extra_modes) / 
sizeof(extra_modes[0]);
+
 /*
  * Probably taken from CEA-861 spec.
  * This table is converted from xorg's hw/xfree86/modes/xf86EdidModes.c.
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 12/12] drm/edid: Generate modes from extra_modes for range descriptors

[Adam Jackson]

Signed-off-by: Adam Jackson a...@redhat.com
---
 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
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1037,11 +1037,61 @@ drm_dmt_modes_for_range(struct drm_connector 
*connector, struct edid *edid,
return modes;
 }
 
+static int
+drm_gtf_modes_for_range(struct drm_connector *connector, struct edid *edid,
+   struct detailed_timing *timing)
+{
+   int i, modes = 0;
+   struct drm_display_mode *newmode;
+   struct drm_device *dev = connector-dev;
+
+   for (i = 0; i  num_extra_modes; i++) {
+   const struct minimode *m = extra_modes[i];
+   newmode = drm_gtf_mode(dev, m-w, m-h, m-r, 0, 0);
+
+   if (!mode_in_range(newmode, edid, timing)) {
+   drm_mode_destroy(dev, newmode);
+   continue;
+   }
+
+   drm_mode_probed_add(connector, newmode);
+   modes++;
+   }
+
+   return modes;
+}
+
+static int
+drm_cvt_modes_for_range(struct drm_connector *connector, struct edid *edid,
+   struct detailed_timing *timing)
+{
+   int i, modes = 0;
+   struct drm_display_mode *newmode;
+   struct drm_device *dev = connector-dev;
+   bool rb = drm_monitor_supports_rb(edid);
+
+   for (i = 0; i  num_extra_modes; i++) {
+   const struct minimode *m = extra_modes[i];
+   newmode = drm_cvt_mode(dev, m-w, m-h, m-r, rb, 0, 0);
+
+   if (!mode_in_range(newmode, edid, timing)) {
+   drm_mode_destroy(dev, newmode);
+   continue;
+   }
+
+   drm_mode_probed_add(connector, newmode);
+   modes++;
+   }
+
+   return modes;
+}
+
 static void
 do_inferred_modes(struct detailed_timing *timing, void *c)
 {
struct detailed_mode_closure *closure = c;
struct detailed_non_pixel *data = timing-data.other_data;
+   struct detailed_data_monitor_range *range = data-data.range;
 
if (data-type != EDID_DETAIL_MONITOR_RANGE)
return;
@@ -1049,6 +1099,29 @@ do_inferred_modes(struct detailed_timing *timing, void 
*c)
closure-modes += drm_dmt_modes_for_range(closure-connector,
  closure-edid,
  timing);
+   
+   if (!version_greater(closure-edid, 1, 1))
+   return; /* GTF not defined yet */
+
+   switch (range-flags) {
+   case 0x02: /* secondary gtf, XXX could do more */
+   case 0x00: /* default gtf */
+   closure-modes += drm_gtf_modes_for_range(closure-connector,
+ closure-edid,
+ timing);
+   break;
+   case 0x04: /* cvt, only in 1.4+ */
+   if (!version_greater(closure-edid, 1, 3))
+   break;
+
+   closure-modes += drm_cvt_modes_for_range(closure-connector,
+ closure-edid,
+ timing);
+   break;
+   case 0x01: /* just the ranges, no formula */
+   default:
+   break;
+   }
 }
 
 static int
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 00/12] Add more DMT and common modes

[Adam Jackson]

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 specify a formula, generate timings from the extra modes

This still doesn't address the driver policy decision of I know I have
a scaler, add modes as if there were a range descriptor even if there's
not one.  But it should at least make clear what such a helper function
should do.


One minor buglet in this series that's not obvious from inspection (and 
that I didn't realize until just now) is that putting 1366x768 in the 
minimode list won't do what you want, since the mode you get back will 
be 1368x768.  Probably we should move the manual-underscan hack into the 
timing generators themselves.


- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

[Adam Jackson]

On Wed, 2012-04-11 at 21:59 -0300, Rodrigo Vivi wrote:
 There are many bugs open on fd.o regarding missing modes that are supported 
 on Windows and other closed source drivers.
 From EDID spec we can (might?) infer modes using GTF and CVT when monitor 
 allows it trough range limited flag... obviously limiting by the range.
 From our code:
  * EDID spec says modes should be preferred in this order:
  * - preferred detailed mode
  * - other detailed modes from base block
  * - detailed modes from extension blocks
  * - CVT 3-byte code modes
  * - standard timing codes
  * - established timing codes
  * - modes inferred from GTF or CVT range information
  *
  * We get this pretty much right.
 
 Not actually so right... We were inferring just using GTF... not CVT or even 
 GTF2.
 This patch not just add some common cvt modes but also allows some modes been 
 inferred when using gtf2 as well.

The intent here is great, but I don't like the way this is phrased, or
the implementation.

CVT monitors _must_ accept GTF as well, EDID says so.  So functionally
there's nothing wrong with the existing code.  The thing you're trying
to sneak in here is a 1600x900 timing that doesn't correspond to
anything in DMT (at least, not in the copy of DMT that I have handy).
It's fine to want to add more modes - although I'm still unclear exactly
which machine you're trying to compensate for here - but not if it comes
by sacrificing the DMT list, which is there for a reason.

So...

 +static int
 +drm_cvt_modes_for_range(struct drm_connector *connector, struct edid *edid,
 + struct detailed_timing *timing)
 +{
 + int i, modes = 0;
 + struct drm_display_mode *newmode;
 + struct drm_device *dev = connector-dev;
 +
 + for (i = 0; i  drm_num_cvt_inferred_modes; i++) {
 + if (mode_in_range(drm_cvt_inferred_modes + i, edid, timing)) {
 + newmode = drm_mode_duplicate(dev, 
 drm_cvt_inferred_modes[i]);
 + if (newmode) {
 + drm_mode_probed_add(connector, newmode);
 + modes++;
 + }
 + }
 + }
 +
 + return modes;
 +}

The mode list you're iterating over here should just be a w/h/r/rb tuple
like est3_modes.  This list should _not_ duplicate any size or rate
already present in the DMT list.  There should be a function like this
for each of CVT and GTF (and I guess dual-curve GTF too, although
honestly I have no monitors left that support it with which to test),
all iterating over the same list, and they should generate the timing
from drm_{cvt,gtf}_mode().  The CVT version should generate RB modes if
the monitor is RB-capable.

  static void
  do_inferred_modes(struct detailed_timing *timing, void *c)
  {
   struct detailed_mode_closure *closure = c;
   struct detailed_non_pixel *data = timing-data.other_data;
 - int gtf = (closure-edid-features  DRM_EDID_FEATURE_DEFAULT_GTF);
 + int timing_level = standard_timing_level(closure-edid);
  
 - if (gtf  data-type == EDID_DETAIL_MONITOR_RANGE)
 + if (data-type == EDID_DETAIL_MONITOR_RANGE)
 + switch (timing_level) {
 + case LEVEL_DMT:
 + break;
 + case LEVEL_GTF:
 + case LEVEL_GTF2:
   closure-modes += drm_gtf_modes_for_range(closure-connector,
 closure-edid,
 timing);
 + break;
 + case LEVEL_CVT:
 + closure-modes += drm_cvt_modes_for_range(closure-connector,
 +   closure-edid,
 +   timing);
 + break;
 + }
  }

drm_gtf_modes_for_range should be renamed drm_dmt_modes_for_range, and
run unconditionally for the range descriptor.  drm_*_modes_for_range
will then handle generating the timings by formula.

 + /* 900x600@60Hz */
 + { DRM_MODE(900x600, DRM_MODE_TYPE_DRIVER, 45250, 960, 992,
 +1088, 1216, 0, 600, 603, 609, 624, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
 + /* 1024x576@60Hz */
 + { DRM_MODE(1024x576, DRM_MODE_TYPE_DRIVER, 46500, 1024, 1064,
 +1160, 1296, 0, 576, 579, 584, 599, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },

Citation needed.  Can you point to real hardware with these panel sizes,
or are you just copying from Windows?

 + /* 2560x1600@60Hz */
 + { DRM_MODE(2560x1600, DRM_MODE_TYPE_DRIVER, 348500, 2560, 2760,
 +3032, 3504, 0, 1600, 1603, 1609, 1658, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },

lol no.  Nobody does a size this large without also doing reduced
blanking.

I have a patch somewhere to fix the DMT list to re-include the reduced
blanking modes (as should have been done in the first place).  I'll send

[Intel-gfx] [PATCH 0/7] drm/edid: Add the reduced-blanking modes to the DMT list

[Adam Jackson]

These should have been there since day one.

This series cleans up the few places that touch the DMT list to handle rb
modes correctly, and then imports the modes from xserver's list, along with
a few cosmetic changes.

- ajax

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/7] drm/edid: Document drm_mode_find_dmt

[Adam Jackson]

Signed-off-by: Adam Jackson a...@redhat.com
---
 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
@@ -486,6 +486,16 @@ static void edid_fixup_preferred(struct drm_connector 
*connector,
preferred_mode-type |= DRM_MODE_TYPE_PREFERRED;
 }
 
+/*
+ * drm_mode_find_dmt - Create a copy of a mode if present in DMT
+ * @dev: Device to duplicate against
+ * @hsize: Mode width
+ * @vsize: Mode height
+ * @fresh: Mode refresh rate
+ *
+ * Walk the DMT mode list looking for a match for the given parameters.
+ * Return a newly allocated copy of the mode, or NULL if not found.
+ */
 struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
   int hsize, int vsize, int fresh)
 {
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/7] drm/edid: Rewrite drm_mode_find_dmt search loop

[Adam Jackson]

No functional change, but will make an upcoming change clearer.

Signed-off-by: Adam Jackson a...@redhat.com
---
 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 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -499,20 +499,21 @@ static void edid_fixup_preferred(struct drm_connector 
*connector,
 struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
   int hsize, int vsize, int fresh)
 {
-   struct drm_display_mode *mode = NULL;
int i;
 
for (i = 0; i  drm_num_dmt_modes; i++) {
const struct drm_display_mode *ptr = drm_dmt_modes[i];
-   if (hsize == ptr-hdisplay 
-   vsize == ptr-vdisplay 
-   fresh == drm_mode_vrefresh(ptr)) {
-   /* get the expected default mode */
-   mode = drm_mode_duplicate(dev, ptr);
-   break;
-   }
+   if (hsize != ptr-hdisplay)
+   continue;
+   if (vsize != ptr-vdisplay)
+   continue;
+   if (fresh != drm_mode_vrefresh(ptr))
+   continue;
+
+   return drm_mode_duplicate(dev, ptr);
}
-   return mode;
+
+   return NULL;
 }
 EXPORT_SYMBOL(drm_mode_find_dmt);
 
-- 
1.7.7.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/7] drm/edid: Allow drm_mode_find_dmt to hunt for reduced-blanking modes

[Adam Jackson]

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 list regrows the r-b modes, but practically speaking EST3
codes don't exist in the wild.

Signed-off-by: Adam Jackson a...@redhat.com
---
 drivers/gpu/drm/drm_edid.c  |   37 -
 drivers/gpu/drm/drm_fb_helper.c |2 +-
 include/drm/drm_crtc.h  |3 ++-
 3 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0a23ee5..4f52103 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -486,18 +486,29 @@ static void edid_fixup_preferred(struct drm_connector 
*connector,
preferred_mode-type |= DRM_MODE_TYPE_PREFERRED;
 }
 
+static bool
+mode_is_rb(const struct drm_display_mode *mode)
+{
+   return (mode-htotal - mode-hdisplay == 160) 
+  (mode-hsync_end - mode-hdisplay == 80) 
+  (mode-hsync_end - mode-hsync_start == 32) 
+  (mode-vsync_start - mode-vdisplay == 3);
+}
+
 /*
  * drm_mode_find_dmt - Create a copy of a mode if present in DMT
  * @dev: Device to duplicate against
  * @hsize: Mode width
  * @vsize: Mode height
  * @fresh: Mode refresh rate
+ * @rb: Mode reduced-blanking-ness
  *
  * Walk the DMT mode list looking for a match for the given parameters.
  * Return a newly allocated copy of the mode, or NULL if not found.
  */
 struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
-  int hsize, int vsize, int fresh)
+  int hsize, int vsize, int fresh,
+  bool rb)
 {
int i;
 
@@ -509,6 +520,8 @@ struct drm_display_mode *drm_mode_find_dmt(struct 
drm_device *dev,
continue;
if (fresh != drm_mode_vrefresh(ptr))
continue;
+   if (rb != mode_is_rb(ptr))
+   continue;
 
return drm_mode_duplicate(dev, ptr);
}
@@ -742,10 +755,17 @@ drm_mode_std(struct drm_connector *connector, struct edid 
*edid,
}
 
/* check whether it can be found in default mode table */
-   mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate);
+   if (drm_monitor_supports_rb(edid)) {
+   mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate,
+true);
+   if (mode)
+   return mode;
+   }
+   mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate, false);
if (mode)
return mode;
 
+   /* okay, generate it */
switch (timing_level) {
case LEVEL_DMT:
break;
@@ -920,15 +940,6 @@ static struct drm_display_mode *drm_mode_detailed(struct 
drm_device *dev,
 }
 
 static bool
-mode_is_rb(const struct drm_display_mode *mode)
-{
-   return (mode-htotal - mode-hdisplay == 160) 
-  (mode-hsync_end - mode-hdisplay == 80) 
-  (mode-hsync_end - mode-hsync_start == 32) 
-  (mode-vsync_start - mode-vdisplay == 3);
-}
-
-static bool
 mode_in_hsync_range(const struct drm_display_mode *mode,
struct edid *edid, u8 *t)
 {
@@ -1073,8 +1084,8 @@ drm_est3_modes(struct drm_connector *connector, struct 
detailed_timing *timing)
mode = drm_mode_find_dmt(connector-dev,
 est3_modes[m].w,
 est3_modes[m].h,
-est3_modes[m].r
-/*, est3_modes[m].rb 
*/);
+est3_modes[m].r,
+est3_modes[m].rb);
if (mode) {
drm_mode_probed_add(connector, mode);
modes++;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a0d6e89..6e19dd1 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1083,7 +1083,7 @@ static bool drm_target_cloned(struct drm_fb_helper 
*fb_helper,
 
/* try and find a 1024x768 mode on each connector */
can_clone = true;
-   dmt_mode = drm_mode_find_dmt(fb_helper-dev, 1024, 768, 60);
+   dmt_mode = drm_mode_find_dmt(fb_helper-dev, 1024, 768, 60, false);
 
for (i = 0; i  fb_helper-connector_count; i++) {
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e250eda..2be73d7 100644
--- a/include/drm/drm_crtc.h
+++ b/include