On Mon, Sep 23, 2013 at 05:33:17PM -0300, Rodrigo Vivi wrote: > This is another drm-intel-collector push for review: > http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector > > Here goes the list in order for better reviewers assignment: > > Patch 01/13 - 816e102 drm/i915: check that the i965g/gm 4G limit is really obeyed - Reviewer: Damien > Patch 02/13 - 036f5da drm/i915: Move the conditional seqno query into the tracepoint - Reviewer: Ville > Patch 03/13 - f381b05 drm/i915: Add some missing steps to i915_driver_load error path - Reviewer: Ben Lazy reviers, tsk ;-) > Patch 04/13 - f648dba drm/i915: Asynchronously perform the set-base for a simple modeset - Reviewer: Dunno what to do exactly with this, given that the android guys seem to need more vblank waits in the plane ioctls. I'd drop for now, we need a more coherent story here ... Or just wait for nuclear flips. > Patch 05/13 - ec31a06 drm/i915: Align tiled scanouts from stolen memory to 256k in the GTT - Reviewer: I think scanouts in stolen have died for now, too many issues. So I guess we can drop this, since there are other issues. > Patch 06/13 - 3b2a43a drm/i915: Pair seqno completion tracepoint with its dispatch - Reviewer: There's some bikeshed pending from Thomas Gleixner in the same are to move the i915_ring_get_seqno out of the tracepoint. I think if we frob this we might as well do it right. > Patch 07/13 - 4d98ddd drm/i915: Initialise min/max frequencies before updating RPS registers - Reviewer: Ville had some bikesheds pending, and there's the issue of the delayed rps work. I'd drop and wait for a new version. > Patch 08/13 - 35983bd drm/i915: Delay the relase of the forcewake by a jiffie - Reviewer: Already reviewed by Ville and needs a bit work it seems, you can drop and wait for a new version. > Patch 09/13 - 14141ee drm/i915: Add a tracepoint for using a semaphore - Reviewer: Ville. > Patch 10/13 - 06d2851 drm/i915: Boost RPS frequency for CPU stalls - Reviewer: > Patch 11/13 - e64dce9 drm/i915: Tweak RPS thresholds to more aggressively downclock - Reviewer: It sounds like Chris has updated versions of these somewhere. Imo you can drop these here. Also Jesse should take a look. > Patch 12/13 - 7b6c68c drm/i915: Allow GT3 Slice Shutdown on Boot. - Reviewer: > Patch 13/13 - 2f3c359 drm/i915: Allow Dynamically GT3 Slice Shutdown. - Reviewer: Imo this shouldn't be an official interface in sysf until we have a solid interface. So I vote to drop patch 12 and rework patch 13 to use debugfs. For the real deal (i.e. a flag in execbuf that userspace has the right commands to support dynamic switching) we ofc need testcases in igt ;-) > > Overall Process has changed a bit in order to avoid discussion split/duplications and for poking reviewers: > > 1. Daniel pushs drm-intel-testing (every 2 weeks) > 2. I rebase drm-intel-collector onto drm-intel-testing > 3. Add Reviewer: tag with voluntered reviewers. If you don't believe you should be assigned on a particular patch please don't get mad just tell you wont review or volunteer someone else. > 4. I resubmit remaining patches for review without picking any new (drm-intel-collector - review request) 4b) Push out the same patches to drm-intel-collector on git.fd.o - the current branch is 2 weeks old ;-) Also can you upload the scrip you're using somewhere, like I update the maintainer scrip with every push to my rerere-cache branch? And if you don't have this fully scripted yet, that needs to be fixed asap ;-) Cheers, Daniel > 5. One week later I collect all simple (1-2) patches that wasn't yet reviewed and not queued by Daniel from one testing update until another. > 6. Request automated QA's PRTS automated i-g-t tests comparing drm-intel-testing x drm-intel-collector > 7. If tests are ok I send the update notification or the patches as a series to intel-gfx mailing list for better tracking and to be reviewed. (drm-intel-collector - updated) > 8. Let me know volunteers for review new patches and also let me know if I've picked any patch that I shouldn't. > > There are some reasons that some patches can be left behind: > 1. It was send so long time ago. I started with patches from Jul 26th. > 2. Your patch didn't applied cleanly and I couldn't easily solve the conflicts. > 3. Kernel didn't compiled with your patch. > 4. I simply missed it. If you believe this is the case please warn me. > > Please help me to get these patches reviewed and queued by Daniel. > > Also, please let me know if you have further ideas how to improve this process. > > Thanks in advance, > Rodrigo. > > Chris Wilson (10): > drm/i915: Move the conditional seqno query into the tracepoint > drm/i915: Add some missing steps to i915_driver_load error path > drm/i915: Asynchronously perform the set-base for a simple modeset > drm/i915: Align tiled scanouts from stolen memory to 256k in the GTT > drm/i915: Pair seqno completion tracepoint with its dispatch > drm/i915: Initialise min/max frequencies before updating RPS registers > drm/i915: Delay the relase of the forcewake by a jiffie > drm/i915: Add a tracepoint for using a semaphore > drm/i915: Boost RPS frequency for CPU stalls > drm/i915: Tweak RPS thresholds to more aggressively downclock > > Daniel Vetter (1): > drm/i915: check that the i965g/gm 4G limit is really obeyed > > Rodrigo Vivi (2): > drm/i915: Allow GT3 Slice Shutdown on Boot. > drm/i915: Allow Dynamically GT3 Slice Shutdown. > > drivers/gpu/drm/i915/i915_debugfs.c | 2 +- > drivers/gpu/drm/i915/i915_dma.c | 41 ++--- > drivers/gpu/drm/i915/i915_drv.c | 5 + > drivers/gpu/drm/i915/i915_drv.h | 28 +++- > drivers/gpu/drm/i915/i915_gem.c | 146 +++++++++++------ > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +- > drivers/gpu/drm/i915/i915_irq.c | 59 ++++--- > drivers/gpu/drm/i915/i915_reg.h | 13 +- > drivers/gpu/drm/i915/i915_sysfs.c | 64 +++++++- > drivers/gpu/drm/i915/i915_trace.h | 52 ++++-- > drivers/gpu/drm/i915/intel_display.c | 16 +- > drivers/gpu/drm/i915/intel_drv.h | 7 +- > drivers/gpu/drm/i915/intel_pm.c | 250 +++++++++++++++++++++-------- > drivers/gpu/drm/i915/intel_uncore.c | 30 +++- > 14 files changed, 525 insertions(+), 190 deletions(-) > > -- > 1.8.1.4 > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
