On Fri, Apr 13, 2012 at 05:08:36PM -0300, Eugeni Dodonov wrote: > Hi forks, > > Just in time for everyone's weekend, here comes the 3rd round of patches on > Haswell. > > As major highlights, it also adds support for HDMI/DVI outputs and multi-head > modes (I tried with VGA and HDMI). > > Other than that, it is the same patches with comments from the past round > addressed (SBI locking support, proper WM calculation, better PCH items > detection, and so on). > > Daniel, I think that the bits definitions, power wells, clocks programming, and > modesetting for both FDI and HDMI modes should be good to go unless someone > spots additional issues with them - so please, all of you who have something to > say about them, say it now and bikeshed as you please :). I've picked up a few more patches I couldn't find anything to bikeshed about, the others grew some comments. I haven't looked too hard at the actual modeset stuff given that you're already really busy reworking things and moving stuff to intel_ddi.c For the modeset stuff 2 general comments so you know from where the bikeshed will hit you in the next review round: - if possible, I'd like to hide most of the 'disable pch stuff on hsw' stuff behind crtc_driving_pch checks. - I think we need to be careful about IS_HASWELL vs PCH_LPT checks, otherwise hsw+ppt will not work so great. For the dip/infoframe stuff, maybe you can volunteer Paulo to help you out, he's looking into this atm anyway. Cheers, Daniel > > Note that the DP and eDP modesetting support is not there yet - it will still > require a considerable amount of patches. > > Also, there is one patch which fixes null pointer exceptions in gmbus code I > was having with some of the drm-intel-next-queued iterations, but I don't think > it is necessary at the moment now that gmbus stuff was disabled again (patch > 5). I am not even sure if we'll hit those code paths with invalid values in > real life, so I simple added some checks for cases when we don't have a valid > adapter as it was looking too error-prone otherwise. Perhaps we could add a > WARN into them as well. > > Eugeni Dodonov (29): > drm/i915: add definition of LPT FDI port width registers > drm/i915: add WRPLL divider programming bits > drm/i915: add Haswell DIP controls registers > drm/i915: support infoframes on Haswell > drm/i915: prevent NULL pointer exception when using gmbus > drm/i915: add support for SBI ops > drm/i915: calculate same watermarks on Haswell as on Ivy Bridge > drm/i915: share forcewaking code between IVB and HSW > drm/i915: haswell has 3 pipes as well > drm/i915: reuse Ivybridge interrupts code for Haswell > drm/i915: share pipe count handling with Ivybridge > drm/i915: share IVB cursor routine with Haswell > drm/i915: show unknown sdvox registers on hdmi init > drm/i915: do not use fdi_normal_train on haswell > drm/i915: do not enable PCH PLL on pre-haswell > drm/i915: detect PCH encoders on Haswell > drm/i915: enable power wells on haswell init > drm/i915: disable rc6 on haswell for now > drm/i915: program WM_LINETIME on Haswell > drm/i915: do not use old code paths on Haswell > drm/i915: initialize DDI buffer translations > drm/i915: perform Haswell DDI link training in FDI mode > drm/i915: disable pipe DDI function when disabling pipe > drm/i915: program iCLKIP on Lynx Point > drm/i915: detect digital outputs on Haswell > drm/i915: add support for DDI-controlled digital outputs > drm/i915: add WR PLL programming table > drm/i915: prepare HDMI link for Haswell > drm/i915: hook Haswell devices in place > > drivers/char/agp/intel-agp.c | 4 + > drivers/gpu/drm/i915/i915_dma.c | 2 +- > drivers/gpu/drm/i915/i915_drv.c | 7 + > drivers/gpu/drm/i915/i915_irq.c | 6 +- > drivers/gpu/drm/i915/i915_reg.h | 23 + > drivers/gpu/drm/i915/intel_display.c | 763 ++++++++++++++++++++++++++++++++-- > drivers/gpu/drm/i915/intel_drv.h | 1 + > drivers/gpu/drm/i915/intel_hdmi.c | 602 ++++++++++++++++++++++++++- > 8 files changed, 1357 insertions(+), 51 deletions(-) > > -- > 1.7.10 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48