[Intel-gfx] [PATCH 0/9] drm/i915: Plane assert/readout cleanups etc.

Alex Villacis Lasso alexvillacislasso at hotmail.com
Sat Oct 14 06:45:25 UTC 2017


El 13/10/17 a las 11:28, Alex Villacís Lasso escribió:
> El 11/10/17 a las 11:38, Ville Syrjälä escribió:
>> On Wed, Oct 11, 2017 at 04:21:58PM +0000, Alex Villacis Lasso wrote:
>>> El 11/10/17 a las 11:04, Ville Syrjala escribió:
>>>> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
>>>>
>>>> This series aims to clean up some of the plane state readout and
>>>> sanitation, and clean up the enum plane mess a bit by renaming it
>>>> to enum old_plane_id.
>>>>
>>>> The one actual bugfix here is the plane<->crtc sanitation
>>>> change. Previously we tried to shut down the entire pipe when
>>>> the plane mapping wasn't what we want, now we just shut down the
>>>> plane, which is easier.
>>>>
>>>> Most of the other stuff is just polish, but I also decided to
>>>> throw the gen2/3 and chv primary plane windowing support on on top
>>>> just because it's been bugging me for years, and I was already
>>>> in the neighbourhood.
>>>>
>>>> Series available here:
>>>> git://github.com/vsyrjala/linux.git plane_sanitation_2
>>>>
>>>> Cc: Thierry Reding <thierry.reding at gmail.com>
>>>> Cc: Alex Villacís Lasso <alexvillacislasso at hotmail.com>
>>>>
>>>> Ville Syrjälä (9):
>>>>     drm/i915: Add .get_hw_state() method for planes
>>>>     drm/i915: Redo plane sanitation during readout
>>>>     drm/i915: s/enum plane/enum old_plane_id/
>>>>     drm/i915: Use enum old_plane_id for the .get_fifo_size() hooks
>>>>     drm/i915: Cleanup enum pipe/enum plane_id/enum old_plane_id in 
>>>> initial
>>>>       fb readout
>>>>     drm/i915: Nuke ironlake_get_initial_plane_config()
>>>>     drm/i915: Switch fbc over to for_each_new_intel_plane_in_state()
>>>>     drm/i915: Nuke crtc->plane
>>>>     drm/i915: Add windowing for primary planes on gen2/3 and chv
>>>>
>>>>    drivers/gpu/drm/i915/i915_drv.h      |  16 +-
>>>>    drivers/gpu/drm/i915/intel_display.c | 500 
>>>> +++++++++++++++--------------------
>>>>    drivers/gpu/drm/i915/intel_drv.h     |   8 +-
>>>>    drivers/gpu/drm/i915/intel_fbc.c     |  27 +-
>>>>    drivers/gpu/drm/i915/intel_pm.c      |  36 +--
>>>>    drivers/gpu/drm/i915/intel_sprite.c  |  43 +++
>>>>    6 files changed, 299 insertions(+), 331 deletions(-)
>>>>
>>> Sorry if this sounds like a newbie question, but what kernel version 
>>> should these two patches be applied against? Can they be applied on 
>>> top of 4.13.5?
>> Not sure they apply cleanly to something so old. In general we develop
>> everything on top of 'git://anongit.freedesktop.org/drm-tip drm-tip' so
>> that's where they would at least apply. But in that case it's actually
>> easier to just grab my plane_sanitation_2 branch directly since it's
>> sitting on top of the latest drm-tip.
>>
>> Hmm. Looks like only trivial conflicts when cherry-picking the first
>> two patches onto 4.13.5. I pushed the result to here:
>> git://github.com/vsyrjala/linux.git plane_sanitation_2_v4.13
>> but note that I only compile tested it so it's still possible it won't
>> actually work.
>>
>
> The plane_sanitation_2 branch fails to module_install on my Acer 
> Aspire One. It complains at the DEPMOD stage that there is a circular 
> dependency between drm and drm_kms_helper. I compiled using the 
> configuration file from 4.13.5 and running "make oldconfig" prior to 
> building. Therefore I am unable to check whether the patchset fixes 
> the situation in my machine. What is needed to track and possibly fix 
> this situation?
>
>
More specifically:

   INSTALL sound/usb/misc/snd-ua101.ko
   INSTALL sound/usb/snd-usb-audio.ko
   INSTALL sound/usb/snd-usbmidi-lib.ko
   INSTALL sound/usb/usx2y/snd-usb-us122l.ko
   INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
   INSTALL sound/x86/snd-hdmi-lpe-audio.ko
   INSTALL virt/lib/irqbypass.ko
   DEPMOD  4.14.0-rc4
depmod: ERROR: Cycle detected: drm_kms_helper -> drm -> drm_kms_helper
depmod: ERROR: Found 2 modules in dependency cycles!
make: *** [Makefile:1244: _modinst_post] Error 1



More information about the Intel-gfx mailing list