Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
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
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
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(&intel_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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
The gen2+ code has been unreachable since: commit ebb7c78d358b2ea45c7d997423e6feb42e5ce4ef Author: Daniel Vetter Date: Wed Jan 27 14:38:00 2016 +0100 agp/intel-gtt: Only register fake agp driver for gen1 Signed-off-by: Adam Jackson --- 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, &gmch_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 (stolen_size > 0) { -
[Intel-gfx] [PATCH 2/2] drm/i915: Only build INTEL_GTT on 32-bit x86
The i810 was attached to Pentium III motherboards, no 64-bit CPU is ever going to have one. Signed-off-by: Adam Jackson --- 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.
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
On Fri, 2018-01-19 at 10:17 +0200, Jani Nikula wrote: > On Thu, 18 Jan 2018, Adam Jackson wrote: > > On Thu, 2018-01-18 at 17:06 +0200, Jani Nikula wrote: > > > No more sing-a-ling. > > > > > > Reported-by: Adam Jackson > > > > 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
On Thu, 2018-01-18 at 17:06 +0200, Jani Nikula wrote: > No more sing-a-ling. > > Reported-by: Adam Jackson 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
Signed-off-by: Adam Jackson --- 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
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 - 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
On Tue, 2017-04-18 at 19:07 +0900, Michel Dänzer wrote: > From: Michel Dänzer > > 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 Reviewed-by: Adam Jackson - 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
We only ever use xserver's AGP support from the i810 driver. Signed-off-by: Adam Jackson --- 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
On Thu, 2015-10-08 at 11:43 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > 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 - 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
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
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 --- 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
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 --- 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
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 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 - 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)
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 --- 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
On Fri, 2013-02-15 at 13:36 -0200, Paulo Zanoni wrote: > From: Paulo Zanoni > > 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 - 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
On 11/29/12 8:29 AM, Paulo Zanoni wrote: From: Paulo Zanoni 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 - 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
On 10/27/12 9:52 AM, Daniel Vetter wrote: This essentially reverts commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae Author: Adam Jackson 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 Reviewed-by: Adam Jackson - 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
On 10/27/12 9:52 AM, Daniel Vetter wrote: Userspace seems to like this, see commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae Author: Adam Jackson 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 Signed-off-by: Eric Anholt 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 - ajax ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/14] drm/i915: fix Haswell DP M/N registers
On 10/15/12 2:51 PM, Paulo Zanoni wrote: diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f48986b9..ba40aa7 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5356,7 +5356,8 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc, intel_set_pipe_timings(intel_crtc, mode, adjusted_mode); - ironlake_set_m_n(crtc, mode, adjusted_mode); + if (!(is_dp && !is_cpu_edp)) + ironlake_set_m_n(crtc, mode, adjusted_mode); The double-negation here hurts my brain. I think this would be clearer and equivalent phrased positively: if (!is_dp || is_pch_edp) ironlake_set_m_n(crtc, mode, adjusted_mode); - 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
On Wed, 2012-09-26 at 18:43 +0300, Jani Nikula wrote: > The dithering introduced in > > commit 3b5c78a35cf7511c15e09a9b0ffab290a42d9bcf > Author: Adam Jackson > 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 > 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 - 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 2/2] drm/dp: Make sink count DP 1.2 aware
Signed-off-by: Adam Jackson --- drivers/gpu/drm/i915/intel_dp.c |9 - include/drm/drm_dp_helper.h |3 ++- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 813b771..00f99e5 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2106,13 +2106,12 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp) /* 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; + uint8_t reg; if (!intel_dp_aux_native_read_retry(intel_dp, DP_SINK_COUNT, - &sink_count, 1)) + ®, 1)) return connector_status_unknown; - sink_count &= DP_SINK_COUNT_MASK; - return sink_count ? connector_status_connected - : connector_status_disconnected; + return DP_GET_SINK_COUNT(reg) ? connector_status_connected + : connector_status_disconnected; } /* If no HPD, poke DDC gently */ diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 38ffcb4..fe06148 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -221,7 +221,8 @@ # define DP_PSR_FRAME_CAPTURE (1 << 3) #define DP_SINK_COUNT 0x200 -# define DP_SINK_COUNT_MASK(31 << 0) +/* prior to 1.2 bit 7 was reserved mbz */ +# define DP_GET_SINK_COUNT(x) x) & 0x80) >> 1) | ((x) & 0x3f)) # define DP_SINK_CP_READY (1 << 6) #define DP_DEVICE_SERVICE_IRQ_VECTOR 0x201 -- 1.7.7.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/dp: Document DP spec versions for various DPCD registers
Note with a comment anything newer than DP 1.1a. Obviously this needs some work still... Signed-off-by: Adam Jackson --- include/drm/drm_dp_helper.h | 52 ++ 1 files changed, 32 insertions(+), 20 deletions(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index f9888c3..38ffcb4 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -26,7 +26,19 @@ #include #include -/* From the VESA DisplayPort spec */ +/* + * Unless otherwise noted, all values are from the DP 1.1a spec. Note that + * DP and DPCD versions are independent. Differences from 1.0 are not noted, + * 1.0 devices basically don't exist in the wild. + * + * Abbreviations, in chronological order: + * + * eDP: Embedded DisplayPort version 1 + * DPI: DisplayPort Interoperability Guideline v1.1a + * 1.2: DisplayPort 1.2 + * + * 1.2 formally includes both eDP and DPI definitions. + */ #define AUX_NATIVE_WRITE 0x8 #define AUX_NATIVE_READ0x9 @@ -53,7 +65,7 @@ #define DP_MAX_LANE_COUNT 0x002 # define DP_MAX_LANE_COUNT_MASK0x1f -# define DP_TPS3_SUPPORTED (1 << 6) +# define DP_TPS3_SUPPORTED (1 << 6) /* 1.2 */ # define DP_ENHANCED_FRAME_CAP (1 << 7) #define DP_MAX_DOWNSPREAD 0x003 @@ -69,16 +81,16 @@ /* 10b = TMDS or HDMI */ /* 11b = Other */ # define DP_FORMAT_CONVERSION (1 << 3) -# define DP_DETAILED_CAP_INFO_AVAILABLE(1 << 4) +# define DP_DETAILED_CAP_INFO_AVAILABLE(1 << 4) /* DPI */ #define DP_MAIN_LINK_CHANNEL_CODING 0x006 #define DP_DOWN_STREAM_PORT_COUNT 0x007 # define DP_PORT_COUNT_MASK0x0f -# define DP_MSA_TIMING_PAR_IGNORED (1 << 6) +# define DP_MSA_TIMING_PAR_IGNORED (1 << 6) /* eDP */ # define DP_OUI_SUPPORT(1 << 7) -#define DP_I2C_SPEED_CAP 0x00c +#define DP_I2C_SPEED_CAP 0x00c/* DPI */ # define DP_I2C_SPEED_1K 0x01 # define DP_I2C_SPEED_5K 0x02 # define DP_I2C_SPEED_10K 0x04 @@ -86,16 +98,16 @@ # define DP_I2C_SPEED_400K 0x10 # define DP_I2C_SPEED_1M 0x20 -#define DP_EDP_CONFIGURATION_CAP0x00d -#define DP_TRAINING_AUX_RD_INTERVAL 0x00e +#define DP_EDP_CONFIGURATION_CAP0x00d /* XXX 1.2? */ +#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ /* Multiple stream transport */ -#define DP_MSTM_CAP0x021 +#define DP_MSTM_CAP0x021 /* 1.2 */ # define DP_MST_CAP(1 << 0) -#define DP_PSR_SUPPORT 0x070 +#define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ # define DP_PSR_IS_SUPPORTED1 -#define DP_PSR_CAPS 0x071 +#define DP_PSR_CAPS 0x071 /* XXX 1.2? */ # define DP_PSR_NO_TRAIN_ON_EXIT1 # define DP_PSR_SETUP_TIME_330 (0 << 1) # define DP_PSR_SETUP_TIME_275 (1 << 1) @@ -136,7 +148,7 @@ #defineDP_LINK_BW_SET 0x100 # define DP_LINK_BW_1_62 0x06 # define DP_LINK_BW_2_70x0a -# define DP_LINK_BW_5_40x14 +# define DP_LINK_BW_5_40x14/* 1.2 */ #define DP_LANE_COUNT_SET 0x101 # define DP_LANE_COUNT_MASK0x0f @@ -146,7 +158,7 @@ # define DP_TRAINING_PATTERN_DISABLE 0 # define DP_TRAINING_PATTERN_1 1 # define DP_TRAINING_PATTERN_2 2 -# define DP_TRAINING_PATTERN_3 3 +# define DP_TRAINING_PATTERN_3 3 /* 1.2 */ # define DP_TRAINING_PATTERN_MASK 0x3 # define DP_LINK_QUAL_PATTERN_DISABLE (0 << 2) @@ -187,22 +199,22 @@ #define DP_DOWNSPREAD_CTRL 0x107 # define DP_SPREAD_AMP_0_5 (1 << 4) -# define DP_MSA_TIMING_PAR_IGNORE_EN (1 << 7) +# define DP_MSA_TIMING_PAR_IGNORE_EN (1 << 7) /* eDP */ #define DP_MAIN_LINK_CHANNEL_CODING_SET0x108 # define DP_SET_ANSI_8B10B (1 << 0) -#define DP_I2C_SPEED_CONTROL_STATUS0x109 +#define DP_I2C_SPEED_CONTROL_STATUS0x109 /* DPI */ /* bitmask as for DP_I2C_SPEED_CAP */ -#define DP_EDP_CONFIGURATION_SET0x10a +#define DP_EDP_CONFIGURATION_SET0x10a /* XXX 1.2? */ -#define DP_MSTM_CTRL 0x111 +#define DP_MSTM_CTRL 0x111 /* 1.2 */ # define DP_MST_EN (1 << 0) # define DP_UP_REQ_EN (1 << 1) # defin
Re: [Intel-gfx] [PATCH 2/4] drm/dp: Update DPCD defines
On 9/20/12 10:10 AM, Paulo Zanoni wrote: 2012/9/18 Adam Jackson : 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] [PATCH 4/4] drm/i915/dp: Be smarter about connection sense for branch devices
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
[Intel-gfx] [PATCH 4/4] drm/i915/dp: Be smarter about connection sense for branch devices
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 Signed-off-by: Adam Jackson --- 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
[Intel-gfx] [PATCH 3/4] drm/i915/dp: Fetch downstream port info if needed during DPCD fetch
v2: Fix parenthesis mismatch, spotted by Jani Nikula Tested-by: Takashi Iwai Signed-off-by: Adam Jackson --- 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 2/4] drm/dp: Update DPCD defines
Sources: DP, eDP, and DP interop specs, and a VESA slideshow about DP 1.2 for the MST bits. Tested-by: Takashi Iwai Signed-off-by: Adam Jackson --- 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 1/4] drm: Export drm_probe_ddc()
Tested-by: Takashi Iwai Signed-off-by: Adam Jackson --- 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
Re: [Intel-gfx] Valid DP connection without EDID?
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 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
Re: [Intel-gfx] Valid DP connection without EDID?
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
[Intel-gfx] [PATCH 4/4] drm/i915/dp: Be smarter about connection sense for branch devices
Signed-off-by: Adam Jackson --- 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
[Intel-gfx] [PATCH 3/4] drm/i915/dp: Fetch downstream port info if needed during DPCD fetch
Signed-off-by: Adam Jackson --- 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 2/4] drm/dp: Update DPCD defines
Sources: DP, eDP, and DP interop specs, and a VESA slideshow about DP 1.2 for the MST bits. Signed-off-by: Adam Jackson --- 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 1/4] drm: Export drm_probe_ddc()
Signed-off-by: Adam Jackson --- 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 0/4] Fix handling of DP bridge devices
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
Re: [Intel-gfx] Valid DP connection without EDID?
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 wrote: > > > At Mon, 17 Sep 2012 18:21:47 +1000, > > > Dave Airlie wrote: > > >> On Mon, Sep 17, 2012 at 6:16 PM, Takashi Iwai 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
Re: [Intel-gfx] Valid DP connection without EDID?
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] Fighting tearing
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] [PATCH] drm/i915: rip out edp special case from dp_link_down
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 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] GMA3150
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] GMA3150
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
Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.20.6
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] [PATCH] drm/i915/hdmi: only enable audio if there's a hdmi sink
On 8/30/12 3:44 AM, Daniel Vetter wrote: Some monitors totally don't like to receive infoframes, and naturally don't claim to support hdmi. But for some odd reason they've added a CEA block to their edid, which automatically gives you basic audio. Still, we may not send out hdmi infoframes to them, hence check whether the sink is indeed hdmi capable. Also kill a stale comment while at it. Does an incomplete version of what it says on the box, you need to hit the HDMI code in intel_sdvo.c too. At which point, should do the obvious bool drm_monitor_has_hdmi_audio() in drm_edid.c. - 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
Signed-off-by: Adam Jackson --- 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
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
On 7/18/12 6:34 PM, Chris Wilson wrote: On Wed, 18 Jul 2012 15:47:44 -0400, Adam Jackson 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
On Wed, 2012-07-18 at 15:36 +0100, Chris Wilson wrote: > On Wed, 18 Jul 2012 10:29:26 -0400, Adam Jackson 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] [BUG] intel_drv.so fails to load
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] [RFC] GPU reset notification interface
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
On Wed, 2012-07-18 at 15:07 +0100, Chris Wilson wrote: > On Wed, 18 Jul 2012 10:02:08 -0400, Adam Jackson wrote: > > On Tue, 2012-07-17 at 22:16 +0100, Chris Wilson wrote: > > > On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen > > > 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] [BUG] intel_drv.so fails to load
On Tue, 2012-07-17 at 22:16 +0100, Chris Wilson wrote: > On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen > 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
On 7/17/12 4:54 PM, Knut Petersen wrote: Am 17.07.2012 22:41, schrieb Chris Wilson: On Tue, 17 Jul 2012 21:16:59 +0100, Chris Wilson wrote: On Tue, 17 Jul 2012 22:08:34 +0200, Knut Petersen wrote: Current Xorg tree builds without problems but fails to load intel_drv.so. Xorg log and build script attached. Ok, looks like the xaa removal from i810 was snafu. Let me split out the common ring functions from the xaa acceleration routines... A second attempt is now online. If I got my grepping correct, only the xaa specific routines are in i810_xaa.c and not built with --disable-xaa. 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 That's... surprising. That should only be fatal if you have LD_BIND_NOW semantics turned on, which is not the default. What OS are you running? Any special security or compiler options? - ajax ___ 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
On Mon, 2012-07-16 at 09:23 +0100, Chris Wilson wrote: > On Mon, 16 Jul 2012 16:18:19 +0800, Chris 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
On Fri, 2012-06-22 at 10:05 +0100, Chris Wilson wrote: > On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard wrote: > > Jesse Barnes 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
Re: [Intel-gfx] [PATCH 1/2] drm/i915: add sanity checks for hsync and htotal
On Wed, 2012-06-20 at 23:15 +0300, Jani Nikula wrote: > Restrict hsync start, end, hdisplay and htotal to be according to hw > spec. Through drm_mode_set_crtcinfo(), these will also limit hblank start, > end. I'm pretty sure any physical hardware would balk at modes like this. Virtual framebuffers probably wouldn't care, I guess. Still, seems wrong to have this in i915 when it should be common. Is this a problem we've seen in the wild, or is this just paranoia? - 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
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 --- 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 |\
Re: [Intel-gfx] [PATCH 02/14] drm: handle HDP and polled connectors separately
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
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 (1<<11) #define DRM_MODE_FLAG_DBLCLK (1<<12) #define DRM_MODE_FLAG_CLKDIV2 (1<<13) +/* 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
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] g33 + dual head = problems
On 5/3/12 1:11 PM, Andriy Gapon wrote: Can the problem be related to some 2048x2048 limitation in G33? Yes, the problem is exactly that limitation. - ajax ___ 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
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: > Signed-off-by: Takashi Iwai 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
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] drm/i915: Do not set "Enable Panel Fitter" on SNB pageflips
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 - 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
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] Suggestions on fixing fill_modes ioctl() delays under i915
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 4/6] drm/i915: Try harder on multifunction SDVO DDC
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 3&2. 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] [PATCH 00/12] Add more DMT and common modes
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
[Intel-gfx] [PATCH 12/12] drm/edid: Generate modes from extra_modes for range descriptors
Signed-off-by: Adam Jackson --- drivers/gpu/drm/drm_edid.c | 73 1 files changed, 73 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7131f38..9e3794d 100644 --- a/drivers/gpu/drm/drm_edid.c +++ 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
[Intel-gfx] [PATCH 11/12] drm/edid: Add extra_modes
Some common sizes that don't show up in DMT. Signed-off-by: Adam Jackson --- drivers/gpu/drm/drm_edid_modes.h | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h index eab60ea..26a1d33 100644 --- 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 10/12] drm/edid: Give the est3 mode struct a real name
We want the same type for extra modes inferred from ranges. Signed-off-by: Adam Jackson --- drivers/gpu/drm/drm_edid_modes.h |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h index ab3a051..eab60ea 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 09/12] drm/edid: Update range descriptor struct for EDID 1.4
Signed-off-by: Adam Jackson --- include/drm/drm_edid.h | 26 -- 1 files changed, 20 insertions(+), 6 deletions(-) diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index bcb9a66..8cefbbe 100644 --- a/include/drm/drm_edid.h +++ b/include/drm/drm_edid.h @@ -90,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 08/12] drm/edid: Do drm_dmt_modes_for_range() for all range descriptor types
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 --- 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 07/12] drm/edid: Fix some comment typos in the DMT mode list
Signed-off-by: Adam Jackson --- drivers/gpu/drm/drm_edid_modes.h | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h index 4be9c1a..ab3a051 100644 --- a/drivers/gpu/drm/drm_edid_modes.h +++ b/drivers/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 06/12] drm/edid: Add the reduced blanking DMT modes to the DMT list
Copied from the list in xserver. Signed-off-by: Adam Jackson --- drivers/gpu/drm/drm_edid_modes.h | 94 +- 1 files changed, 93 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h index a91ffb1..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
[Intel-gfx] [PATCH 05/12] drm/edid: s/drm_gtf_modes_for_range/drm_dmt_modes_for_range/
Slightly more honest naming. Signed-off-by: Adam Jackson --- drivers/gpu/drm/drm_edid.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 70dcf7a..355e6a0 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/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 04/12] drm/edid: Remove a misleading comment
mode_in_range() handles what this was warning about. Signed-off-by: Adam Jackson --- drivers/gpu/drm/drm_edid.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 4f52103..70dcf7a 100644 --- a/drivers/gpu/drm/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 03/12] drm/edid: Allow drm_mode_find_dmt to hunt for reduced-blanking modes
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 --- 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_
[Intel-gfx] [PATCH 02/12] drm/edid: Rewrite drm_mode_find_dmt search loop
No functional change, but will make an upcoming change clearer. Signed-off-by: Adam Jackson --- drivers/gpu/drm/drm_edid.c | 19 ++- 1 files changed, 10 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 79a3637..0a23ee5 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 01/12] drm/edid: Document drm_mode_find_dmt
Signed-off-by: Adam Jackson --- drivers/gpu/drm/drm_edid.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 5a18b0d..79a3637 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -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 00/12] Add more DMT and common modes
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
Re: [Intel-gfx] [PATCH 5/7] drm/edid: Armor drm_dmt_modes_for_range for reduced blanking modes
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