Re: [PATCH] dim: Consider fix-of-fix for -fixes cherry picking.

2022-12-30 Thread Vivi, Rodrigo 
On Fri, 2022-12-30 at 06:55 -0500, Rodrigo Vivi wrote:
> In case a fix was not propagated yet to upstream, the
> original commit sha won't be found hence the fix of this
> fix will be missed during the cherry-pick.
> 
> Since dim cherry-picks reliably adds the -x "(cherry picked
> from" message, let's also grep in the log to see if that
> was the case, before we give up and forget.
> 
> Also, if that's the case, let's then fix the 'Fixes:' tag.
> 
> v2: Actually replaces the 'Fixes:' tag, otherwise dim doesn't
> allow us to push giving the following message:
> "Fixes: SHA1 in not pointing at an ancestor:"
> "dim: ERROR: issues in commits detected, aborting"
> 
> v3: - Also consider fix of fixes in drm-intel-fixes besides
>   the drm-intel-next-fixes.
>     - Use intel_remote branches instead of local.
>     - And run the check unconditionally as suggested by Daniel.
> 
> Signed-off-by: Rodrigo Vivi 
> ---
>  dim | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/dim b/dim
> index b699108..b87b542 100755
> --- a/dim
> +++ b/dim
> @@ -1481,10 +1481,15 @@ function cherry_pick_branch
> if [[ "$(git merge-base $branch $fixes)" =
> "$fixes" ]]; then
> needed=1
> fi
> +
> +   fix_of_fix=$(git log --grep="cherry picked
> from commit $fixes" --after=6months --format=format:%h
> $intel_remote/drm-intel-next-fixes -1)
> +   if [[ -z "$fix_of_fix" ]]; then
> +   fix_of_fix=$(git log --grep="cherry
> picked from commit $fixes" --after=6months --format=format:%h
> $intel_remote/drm-intel-fixes -1)
> +   fi
> done
>  
> # Note: Cc: stable will overrule Fixes:
> -   if [[ -n "$have_fixes" && -z "$needed" ]]; then
> +   if [[ -n "$have_fixes" && -z "$needed" && -z
> "$fix_of_fix" ]]; then
> echo "Fixes a commit not in $branch. OK."
> continue
> fi
> @@ -1495,6 +1500,14 @@ function cherry_pick_branch
> echo "FAILED: $(dim_cite $commit)"
> (dim_cite $commit) >> $fail_log
> git cherry-pick --abort
> +   else
> +   if [[ "$fix_of_fix" ]]; then
> +   short_fixes_hash=$(git log -1 --
> format=format:%h $fixes 2>/dev/null || true)
> +   git log -1 --pretty=%B | \
> +   sed -e :a -e
> '/^\n*$/{$d;N;ba' -e '}' | \
> +   sed
> "s/$short_fixes_hash/$fix_of_fix/g" | \

Daniel, I did not ignored your comment. But I tried to replace the
whole line but sed with single quote doesn't expand the variable nor
dim_cite command and with double quote it fails because the fixes line
has parentheses in it. Then bash doesn't accept nested substitution
and things started to get really ugly there to replace the whole line
that in the end it has absolutely no chance of changing.

Replacing just the hash is safe and the cleanest option imho.

> +   git commit --amend -F-
> +   fi
> fi
> done
>  

Re: [Intel-gfx] [PULL] drm-intel-next

2022-11-01 Thread Vivi, Rodrigo 
On Sat, 2022-10-29 at 02:41 +0300, Ville Syrjälä wrote:
> On Fri, Oct 28, 2022 at 02:22:33PM -0400, Rodrigo Vivi wrote:
> > Hi Dave and Daniel,
> > 
> > Here goes the first chunk of drm-intel-next targeting 6.2
> > 
> > The highlight goes to Ville with many display related clean-up
> > and improvement, some other MTL enabling work and many other
> > fixes and small clean-ups.
> > 
> > drm-intel-next-2022-10-28:
> ...
> > - ELD precompute and readout (Ville)
> 
> A slight clarification seems to be in order. The ELD
> precompute+readout is in fact not in yet. This was just a pile
> of cleanups and minor fixes. The real ELD stuff will come later,
> once we figure out how we actually want to do it.

Sorry for the confusion. I have just used the subject of your series
as summary: 
[Intel-gfx] [PATCH 00/22] drm/i915: ELD precompute and readout

Should I change that to ELD precompute and readout

>

Re: [PATCH] dim: Consider fix-of-fix for -fixes cherry picking.

2022-10-11 Thread Vivi, Rodrigo 
On Wed, 2022-10-05 at 14:12 +0200, Daniel Vetter wrote:
> On Mon, Aug 08, 2022 at 03:00:02PM -0400, Rodrigo Vivi wrote:
> > In case a fix was not propagated yet to upstream, the
> > original commit sha won't be found hence the fix of this
> > fix will be missed during the cherry-pick.
> > 
> > Since dim cherry-picks reliably adds the -x "(cherry picked
> > from" message, let's also grep in the log to see if that
> > was the case, before we give up and forget.
> > 
> > Also, if that's the case, let's then fix the 'Fixes:' tag.
> > 
> > v2: Actually replaces the 'Fixes:' tag, otherwise dim doesn't
> > allow us to push giving the following message:
> > "Fixes: SHA1 in not pointing at an ancestor:"
> > "dim: ERROR: issues in commits detected, aborting"
> > 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  dim | 16 ++--
> >  1 file changed, 14 insertions(+), 2 deletions(-)
> > 
> > diff --git a/dim b/dim
> > index 4b43bf8..33caaf6 100755
> > --- a/dim
> > +++ b/dim
> > @@ -1485,8 +1485,13 @@ function cherry_pick_branch
> >  
> > # Note: Cc: stable will overrule Fixes:
> > if [[ -n "$have_fixes" && -z "$needed" ]]; then
> > -   echo "Fixes a commit not in $branch. OK."
> > -   continue
> > +
> > +   fixes=$(git log -1 --format=format:%h
> > $fixes 2>/dev/null || true)
> > +   fix_of_fix=$(git log --grep="cherry picked
> > from commit $fixes" --after=6months --format=format:%h drm-intel-
> > next-fixes -1)
> > +   if [[ -z "$fix_of_fix" ]]; then
> > +   echo "Fixes a commit not in
> > $branch. OK."
> > +   continue
> > +   fi
> 
> This hunk has my Reviewed-by: Daniel Vetter 
> 
> > fi
> >  
> > echo "Try to cherry-pick."
> > @@ -1495,6 +1500,13 @@ function cherry_pick_branch
> > echo "FAILED: $(dim_cite $commit)"
> > (dim_cite $commit) >> $fail_log
> > git cherry-pick --abort
> > +   else
> > +   if [[ "$fix_of_fix" ]]; then
> > +   git log -1 --pretty=%B | \
> > +   sed -e :a -e
> > '/^\n*$/{$d;N;ba' -e '}' | \
> > +   sed
> > "s/$fixes/$fix_of_fix/g" | \
> 
> Maybe I'm not reading the shell magic here correctly, but I think
> this
> only replaces the sha, not the commit subject we append in ("") after
> them
> usually. So you'll still have some wrong citations in here I think.

you are right. I'm only changing the sha, but I'm considering that this
is the only thing we are changing anyway when cherry-picking to the
fixes branches.

I have never seen any case where we changed the subject while porting.
But you are saying that we should be save then sorry?

> 
> Also I'm wondering whether instead it wouldn't be better to patch up
> dim
> to look at the other history when the commit contains a "cherry
> picked
> from $sha1" line unconditionally? Since we have other cases than dim
> cherry-pick where cherry-picking happens ...

By unconditionally you mean out of the 
if [[ -n "$have_fixes" && -z "$needed" ]]; then
?

I don't believe this is needed because even if it is a cherry-picked
case, if it was found is because it was already propagated properly
and contains the right shas

Thanks,
Rodrigo.

> 
> Cheers, Daniel
> 
> > +   git commit --amend -F-
> > +   fi
> > fi
> > done
> >  
> > -- 
> > 2.37.1
> > 
>

Re: [PATCH] dim: extend check_maintainer to all drm-intel branches

2022-10-04 Thread Vivi, Rodrigo 
On Tue, 2022-10-04 at 11:01 -0700, Ceraolo Spurio, Daniele wrote:
> 
> 
> On 10/4/2022 10:48 AM, Rodrigo Vivi wrote:
> > On Mon, Oct 03, 2022 at 11:50:19AM -0700, Daniele Ceraolo Spurio
> > wrote:
> > > The check_maintainer warns the user if any of the patches being
> > > applied
> > > touches files outside of the ones that are owned by the branch
> > > that the
> > > patches are being applied to.
> > > The only branch currently covered by the checks is drm-intel-
> > > next, but
> > > checking for i915 paths is good practice for all intel branches,
> > > so
> > > extend the check to cover them all.
> > > 
> > > Signed-off-by: Daniele Ceraolo Spurio
> > > 
> > > ---
> > >   dim | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/dim b/dim
> > > index 4b43bf8..1256798 100755
> > > --- a/dim
> > > +++ b/dim
> > > @@ -1701,7 +1701,7 @@ function check_maintainer
> > > branch=$1
> > > commit=$2
> > >   
> > > -    if [ "$branch" = "drm-intel-next" ]; then
> > > +    if [[ "$branch" = "drm-intel-"* ]]; then
> > we probably need to 'or' with drm-intel-gt-next... no one except
> > maintainers
> > should be pushing to any other drm-intel-* branch other than these
> > 2.
> 
> I wanted to be future-proof here, in case we ever add another dev
> branch 
> in the future. This only prints a warning, so even if the warning
> comes 
> out on one of the maintainers-only branches it's not going to hurt.
> But 
> if you still think it is better to limit to just drm-intel-next and 
> drm-intel-gt-next then I can do that.

Well, I really hope that we don't end up creating yet another branch.
2 is already hard enough to keep in sync ;)

But thinking more about this, I believe that it doesn't hurt to have
this in the fixes branches as well. Besides I don't believe that we
should get into this case anyway. So, your approach looks good to me.

> 
> > and if we don't have this check in place already it is probably
> > worth to
> > add an extra check for the fixes branch?!
> 
> I'm not sure I understood this comment correctly. Above you're saying
> to 
> limit to only intel-next and gt-next, while here you're saying we
> should 
> add the fixes branch as well. If fixes is included as well, which
> branch 
> do you want to exclude by explicitly checking for intel-next, gt-next
> and -fixes instead of just drm-intel-* ? Or are you meaning to have a
> different check for the fixes branch?

oh, nevermind. please ignore this part. When I was writing I though
about another msg...

Reviewed-by: Rodrigo Vivi 


> 
> Daniele
> 
> > 
> > > if non_i915_files=$(git diff-tree --no-commit-id
> > > --name-only -r $commit | \
> > > grep -v
> > > "^\(drivers/gpu/drm/i915/\|include/drm/i915\|include/uapi/drm/i91
> > > 5\|Documentation/gpu/i915\)") && [[ -n "$non_i915_files" ]]; then
> > > echo -e "The following files are outside
> > > of i915 maintenance scope:\n"
> > > -- 
> > > 2.37.3
> > > 
>

Re: [PULL] drm-intel-fixes

2022-09-12 Thread Vivi, Rodrigo 
On Sun, 2022-09-11 at 19:22 +0200, Jason A. Donenfeld wrote:
> Hi Rodrigo,
> 
> On Thu, Sep 08, 2022 at 09:59:54AM -0400, Rodrigo Vivi wrote:
> > Hi Dave and Daniel,
> > 
> > A few fixes, but most targeting stable.
> > 
> > [...]
> > 
> > Ville Syrjälä (2):
> >   drm/i915: Implement WaEdpLinkRateDataReload
> 
> Don't you need to revert d5929835080a60f9119d024fa42f315913942f76 in
> order for "drm/i915: Implement WaEdpLinkRateDataReload" to actually
> be
> useful/interesting? Otherwise, what's the point?

Unfortunately there was no clear indication on the revert patch for
the tool to pick, and I hadn't followed that front myself closely.

Should 
483e3d87a37e ("Revert "drm/i915/display: Re-add check for low voltage
sku for max dp source rate"")
have a Fixes tag?

Or should dim consider all reverts as Fixes?

Anyway, I will cherry pick this to our fixes branch for propagation
this week.

Thanks for the heads up,
Rodrigo.

> 
> Regards,
> Jason

Re: [PULL] drm-intel-gt-next

2022-07-21 Thread Vivi, Rodrigo 
On Wed, 2022-07-13 at 17:31 -0400, Rodrigo Vivi wrote:
> Hi Dave and Daniel,
> 
> On behalf of Tvrtko, who is recovering from Covid,
> here goes the latest drm-intel-gt-next pull request
> targeting 5.20.

Hi Folks,

any particular issue with this pull request?

We just realized it is not yet part of the drm-next.


Thanks,
Rodrigo.

> 
> Thanks,
> Rodrigo.
> 
> Driver uAPI changes:
> - All related to the Small BAR support: (and all by Matt Auld)
>  * add probed_cpu_visible_size
>  * expose the avail memory region tracking
>  * apply ALLOC_GPU only by default
>  * add NEEDS_CPU_ACCESS hint
>  * tweak error capture on recoverable contexts
> 
> Driver highlights:
> - Add Small BAR support (Matt)
> - Add MeteorLake support (RK)
> - Add support for LMEM PCIe resizable BAR (Akeem)
> 
> Driver important fixes:
> - ttm related fixes (Matt Auld)
> - Fix a performance regression related to waitboost (Chris)
> - Fix GT resets (Chris)
> 
> Driver others:
> - Adding GuC SLPC selftest (Vinay)
> - Fix ADL-N GuC load (Daniele)
> - Add platform workaround (Gustavo, Matt Roper)
> - DG2 and ATS-M device ID updates (Matt Roper)
> - Add VM_BIND doc rfc with uAPI documentation (Niranjana)
> - Fix user-after-free in vma destruction (Thomas)
> - Async flush of GuC log regions (Alan)
> - Fixes in selftests (Chris, Dan, Andrzej)
> - Convert to drm_dbg (Umesh)
> - Disable OA sseu config param for newer hardware (Umesh)
> - Multi-cast register steering changes (Matt Roper)
> - Add lmem_bar_size modparam (Priyanka)
> 
> Thanks,
> Rodrigo.
> 
> The following changes since commit
> a06968563775181690125091f470a8655742dcbf:
> 
>   drm/i915: Fix a lockdep warning at error capture (2022-06-29
> 14:52:50 +0530)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-
> 2022-07-13
> 
> for you to fetch changes up to
> 17cd10a44a8962860ff4ba351b2a290e752dbbde:
> 
>   drm/i915: Add lmem_bar_size modparam (2022-07-13 17:47:51 +0100)
> 
> 
> Driver uAPI changes:
> - All related to the Small BAR support: (and all by Matt Auld)
>  * add probed_cpu_visible_size
>  * expose the avail memory region tracking
>  * apply ALLOC_GPU only by default
>  * add NEEDS_CPU_ACCESS hint
>  * tweak error capture on recoverable contexts
> 
> Driver highlights:
> - Add Small BAR support (Matt)
> - Add MeteorLake support (RK)
> - Add support for LMEM PCIe resizable BAR (Akeem)
> 
> Driver important fixes:
> - ttm related fixes (Matt Auld)
> - Fix a performance regression related to waitboost (Chris)
> - Fix GT resets (Chris)
> 
> Driver others:
> - Adding GuC SLPC selftest (Vinay)
> - Fix ADL-N GuC load (Daniele)
> - Add platform workaround (Gustavo, Matt Roper)
> - DG2 and ATS-M device ID updates (Matt Roper)
> - Add VM_BIND doc rfc with uAPI documentation (Niranjana)
> - Fix user-after-free in vma destruction (Thomas)
> - Async flush of GuC log regions (Alan)
> - Fixes in selftests (Chris, Dan, Andrzej)
> - Convert to drm_dbg (Umesh)
> - Disable OA sseu config param for newer hardware (Umesh)
> - Multi-cast register steering changes (Matt Roper)
> - Add lmem_bar_size modparam (Priyanka)
> 
> 
> Akeem G Abodunrin (1):
>   drm/i915: Add support for LMEM PCIe resizable bar
> 
> Alan Previn (1):
>   drm/i915/guc: Asynchronous flush of GuC log regions
> 
> Andrzej Hajda (1):
>   drm/i915/selftests: fix subtraction overflow bug
> 
> Chris Wilson (6):
>   drm/i915/selftests: Grab the runtime pm in shrink_thp
>   drm/i915/gt: Serialize GRDOM access between multiple engine
> resets
>   drm/i915/gt: Serialize TLB invalidates with GT resets
>   drm/i915/gem: Look for waitboosting across the whole object
> prior to individual waits
>   drm/i915: Bump GT idling delay to 2 jiffies
>   drm/i915/gt: Only kick the signal worker if there's been an
> update
> 
> Dan Carpenter (1):
>   drm/i915/selftests: fix a couple IS_ERR() vs NULL tests
> 
> Daniele Ceraolo Spurio (1):
>   drm/i915/guc: ADL-N should use the same GuC FW as ADL-S
> 
> Gustavo Sousa (1):
>   drm/i915/pvc: Implement w/a 16016694945
> 
> Matt Roper (4):
>   drm/i915: DG2 and ATS-M device ID updates
>   drm/i915/gt: Add general DSS steering iterator to intel_gt_mcr
>   drm/i915/dg2: Add Wa_15010599737
>   drm/i915: Correct ss -> steering calculation for pre-Xe_HP
> platforms
> 
> Matthew Auld (15):
>   drm/doc: add rfc section for small BAR uapi
>   drm/i915/uapi: add probed_cpu_visible_size
>   drm/i915/uapi: expose the avail tracking
>   drm/i915: remove intel_memory_region avail
>   drm/i915/uapi: apply ALLOC_GPU_ONLY by default
>   drm/i915/uapi: add NEEDS_CPU_ACCESS hint
>   drm/i915/error: skip non-mappable pages
>   drm/i915/uapi: tweak error capture on recoverable contexts
>   drm/i915/selftests: skip the mman tests for stole

Re: anush...@git.freedesktop.org: Permission denied (publickey).

2022-03-01 Thread Vivi, Rodrigo 
Hi Anusha,

first of all, I'm afraid that dim-tools is not the best place
for this kind of queries. Probably something like #freedesktop
channel at oftc.irc would be better. but more below

On Tue, 2022-03-01 at 00:06 +, Srivatsa, Anusha wrote:
> I see the error: anush...@git.freedesktop.org: Permission denied
> (publickey). Even though the public key is added to the account. My
> username on dev laptop is anushasr and for gitlab is anushas, could
> that be the reason I see the error?

Add an entry like this to your ~/.ssh/config file:


Host git.freedesktop.org  
 User anushas 
Host gitlab.freedesktop.org   
 User anushas

Cheers,
Rodrigo.

>  
> Anusha

Re: [PULL] drm-intel-gt-next

2022-02-23 Thread Vivi, Rodrigo 
On Tue, 2022-02-22 at 11:44 -0800, Lucas De Marchi wrote:
> On Mon, Feb 21, 2022 at 11:21:35AM +0200, Jani Nikula wrote:
> > On Mon, 21 Feb 2022, Dave Airlie  wrote:
> > > On Thu, 17 Feb 2022 at 20:26, Joonas Lahtinen
> > >  wrote:
> > > > 
> > > > Hi Dave & Daniel,
> > > > 
> > > > Here is the first drm-intel-gt-next feature PR towards v5.18.
> > > 
> > > Am I missing some previous drm-intel pull?
> > > 
> > > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/i915/gt/intel_
> > > workarounds.c:
> > > In function ‘rcs_engine_wa_init’:
> > > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/i915/gt/intel_
> > > workarounds.c:2051:40:
> > > error: ‘XEHP_DIS_BBL_SYSPIPE’ undeclared (first use in this
> > > function)
> > >  2051 |   wa_masked_en(wal, GEN9_ROW_CHICKEN4,
> > > XEHP_DIS_BBL_SYSPIPE);
> > >   |   
> > > ^~~~
> > > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/i915/gt/intel_
> > > workarounds.c:2051:40:
> > > note: each undeclared identifier is reported only once for each
> > > function it appears in
> > 
> > There's apparently a silent conflict between changes in drm-intel-
> > next
> > and drm-intel-gt-next. There's a fixup patch in drm-rerere:
> > fixups/drm-intel-gt-next.patch.

With ack from Dave on #dri-devel, I've applied this pull request to
drm-intel-next.

Then I used this big fixup on the merge resolution.

Now I'm going to prepare a drm-intel-next pull request towards drm-
next.

Then for the next rounds we check if we are doing cross merges,
or the other way around and get drm-intel-next into drm-intel-gt-next

Thanks,
Rodrigo.


> yeah, with all header refactors landing in drm-intel-next there were
> quite a few conflict lately. Just taking fixups/drm-intel-gt-
> next.patch
> doesn't fix it though as we'd need to follow the merge order drm-tip
> is
> doing, i.e. first get a pull request for drm-intel-next in, and then
> drm-intel-gt-next. Or the octopus merge
> 
> For this merge only I believe the fixup is:
> 
> git show 064030837c5b:fixups/drm-intel-gt-next.patch | patch
> -p1
> 
> with 064030837c5b being the commit in drm-rerere. Cc'ing Matt Roper
> 
> Lucas De Marchi
> 
> > 
> > We opted to sync the branches via drm-next pulls and backmerges,
> > but I'm
> > afraid that means you'd have to use the fixups when merging. I
> > guess we
> > failed to communicate that. The alternative would've been cross-
> > merges
> > within drm-intel.
> > 
> > 
> > BR,
> > Jani.
> > 
> > 
> > > 
> > > Dave.
> > > > 
> > > > For DG2 adds subplatform G12, missing workarounds and fixes GuC
> > > > loading on ARM64. C0/D0 stepping info added for RPL-S.
> > > > 
> > > > For uAPI enables support for simple parallel submission with
> > > > execlists which was previously enabled only for GuC.
> > > > 
> > > > Further fixes for PMU metrics when GuC is enabled, better error
> > > > reporting for GuC loading failures. Fix for PXP unbind splat.
> > > > Updates to GuC version 69.0.3 with improvements to GT reset
> > > > scenarios.
> > > > 
> > > > The rest is mostly refactoring of the memory management code,
> > > > as highlights introduction of async unbinding/migration and
> > > > removal of short-term pinning in execbuf.
> > > > 
> > > > Then a few selftest and coding style fixes.
> > > > 
> > > > Regards, Joonas
> > > > 
> > > > ***
> > > > 
> > > > drm-intel-gt-next-2022-02-17:
> > > > 
> > > > UAPI Changes:
> > > > 
> > > > - Weak parallel submission support for execlists
> > > > 
> > > >   Minimal implementation of the parallel submission support for
> > > >   execlists backend that was previously only implemented for
> > > > GuC.
> > > >   Support one sibling non-virtual engine.
> > > > 
> > > > Core Changes:
> > > > 
> > > > - Two backmerges of drm/drm-next for header file
> > > > renames/changes and
> > > >   i915_regs reorganization
> > > > 
> > > > Driver Changes:
> > > > 
> > > > - Add new DG2 subplatform: DG2-G12 (Matt R)
> > > > - Add new DG2 workarounds (Matt R, Ram, Bruce)
> > > > - Handle pre-programmed WOPCM registers for DG2+ (Daniele)
> > > > - Update guc shim control programming on XeHP SDV+ (Daniele)
> > > > - Add RPL-S C0/D0 stepping information (Anusha)
> > > > - Improve GuC ADS initialization to work on ARM64 on dGFX
> > > > (Lucas)
> > > > 
> > > > - Fix KMD and GuC race on accessing PMU busyness (Umesh)
> > > > - Use PM timestamp instead of RING TIMESTAMP for reference in
> > > > PMU with GuC (Umesh)
> > > > - Report error on invalid reset notification from GuC (John)
> > > > - Avoid WARN splat by holding RPM wakelock during PXP unbind
> > > > (Juston)
> > > > - Fixes to parallel submission implementation (Matt B.)
> > > > - Improve GuC loading status check/error reports (John)
> > > > - Tweak TTM LRU priority hint selection (Matt A.)
> > > > - Align the plane_vma to min_page_size of stolen mem (Ram)
> > > > 
> > > > - Introduce vma resources and implement async unbinding
> > > > (Thomas)
> > > > - Use struct vma_re

Re: [PATCH] dim: add additional prompts for pushing merges

2021-08-11 Thread Vivi, Rodrigo 
On Wed, 2021-08-11 at 13:58 +0300, Jani Nikula wrote:
> It's not exactly trivial to add the smarts to properly check for
> pushing
> backmerges, rebases, topic branches and subtree branches (such as
> gvt). For a start, prompt the user with hints about what's going on.
> 
> Cc: Daniel Vetter 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> Untested.
> ---
>  dim | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/dim b/dim
> index 56463eb0c0a6..9fc2d78b8617 100755
> --- a/dim
> +++ b/dim
> @@ -989,7 +989,7 @@ function checkpatch_commit_push_range
>  # push.
>  function dim_push_branch
>  {
> -   local branch remote committer_email count
> +   local branch remote committer_email commit_count merge_count
>  
> branch=${1:?$usage}
> shift
> @@ -1004,9 +1004,15 @@ function dim_push_branch
>  
> # Apart from maintainers pushing merges or rebases, most
> patches should
> # be pushed in small batches.
> -   count=$(git rev-list --count --first-parent
> "$branch@{u}..$branch")
> -   if [[ $count -gt 10 ]]; then
> -   if ! ask_user "Pushing $count commits. Are you
> sure?"; then
> +   commit_count=$(git rev-list --count --no-merges --first-
> parent "$branch@{u}..$branch")
> +   merge_count=$(git rev-list --count --merges --first-parent
> "$branch@{u}..$branch")
> +   if [[ $merge_count -gt 0 ]]; then
> +   if ! ask_user "Pushing $merge_count merges and
> $commit_count non-merge commits. Merges should only be pushed by
> maintainers. Are you sure?"; then

With our flow of drm-intel-next and drm-intel-gt-next, there are a few
cases where it is much easier a topic branch to get merged to both.

On a recent case I asked Matt Roper to go ahead and merge to both
directly since I was sure that all of them had the same base and all
patches really ready for merge.

Are we going to block cases like this and force pull request on all
kind of topic branches? or with the right maintainer acks we can
get this path and then we'd need to adjust this message?

> +   echoerr "NOTE: Branch not pushed."
> +   return 1
> +   fi
> +   elif [[ $commit_count -gt 10 ]]; then
> +   if ! ask_user "Pushing $commit_count commits. Commits
> should be only be pushed in relatively small batches. Are you sure?";
> then
> echoerr "NOTE: Branch not pushed."
> return 1
> fi

Re: [PULL] drm-intel-fixes v2

2020-12-09 Thread Vivi, Rodrigo 
On Wed, 2020-12-09 at 14:11 +0200, Ville Syrjälä wrote:
> On Thu, Dec 03, 2020 at 05:47:05AM -0800, Rodrigo Vivi wrote:
> > Hi Dave and Daniel,
> > 
> > Please ignore the pull request I had sent yesterday and use only
> > this one.
> > 
> > I had missed one patch: 14d1eaf08845 ("drm/i915/gt: Protect context
> > lifetime with RCU").
> > 
> > Also, please notice that the commit 6db58901c2aa
> > ("drm/i915/display: return earlier from
> > +intel_modeset_init() without display") was not actually a crucial
> > fix, but it
> > +allowed a clean pick of the use-after-free one.
> > 
> > Here goes drm-intel-fixes-2020-12-03:
> > Fixes for GPU hang, null dereference, suspend-resume, power
> > consumption, and use-after-free.
> > 
> > - Program mocs:63 for cache eviction on gen9 (Chris)
> > - Protect context lifetime with RCU (Chris)
> > - Split the breadcrumb spinlock between global and contexts (Chris)
> > - Retain default context state across shrinking (Venkata)
> > - Limit frequency drop to RPe on parking (Chris)
> > - Return earlier from intel_modeset_init() without display (Jani)
> > - Defer initial modeset until after GGTT is initialized (Chris)
> > 
> > Thanks,
> > Rodrigo.
> > 
> > The following changes since commit
> > b65054597872ce3aefbc6a666385eabdf9e288da:
> > 
> >   Linux 5.10-rc6 (2020-11-29 15:50:50 -0800)
> > 
> > are available in the Git repository at:
> > 
> >   git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-
> > 2020-12-03
> > 
> > for you to fetch changes up to
> > ccc9e67ab26feda7e62749bb54c05d7abe07dca9:
> > 
> >   drm/i915/display: Defer initial modeset until after GGTT is
> > initialised (2020-12-02 17:05:58 -0800)
> > 
> > 
> > Fixes for GPU hang, null dereference, suspend-resume, power
> > consumption, and use-after-free.
> > 
> > - Program mocs:63 for cache eviction on gen9 (Chris)
> > - Protect context lifetime with RCU (Chris)
> > - Split the breadcrumb spinlock between global and contexts (Chris)
> > - Retain default context state across shrinking (Venkata)
> > - Limit frequency drop to RPe on parking (Chris)
> > - Return earlier from intel_modeset_init() without display (Jani)
> > - Defer initial modeset until after GGTT is initialized (Chris)
> > 
> > 
> > Chris Wilson (5):
> >   drm/i915/gt: Program mocs:63 for cache eviction on gen9
> 
> That also needs
> commit 444fbf5d7058 ("drm/i915/gt: Declare gen9 has 64 mocs
> entries!")
> which seems to have not made it into this pull.

yeap, I'm sorry I have missed that one.
dim doesn't deal very well with fixes for fixes and I end up missing
that.

It is now on dif and will be part of this week's pull request.

Thanks for the heads up,
Rodrigo.

> 
> >   drm/i915/gt: Protect context lifetime with RCU
> >   drm/i915/gt: Split the breadcrumb spinlock between global and
> > contexts
> >   drm/i915/gt: Limit frequency drop to RPe on parking
> >   drm/i915/display: Defer initial modeset until after GGTT is
> > initialised
> > 
> > Jani Nikula (1):
> >   drm/i915/display: return earlier from intel_modeset_init()
> > without display
> > 
> > Venkata Ramana Nayana (1):
> >   drm/i915/gt: Retain default context state across shrinking
> > 
> >  drivers/gpu/drm/i915/display/intel_display.c  |  24 ++--
> >  drivers/gpu/drm/i915/gt/intel_breadcrumbs.c   | 168
> > ++
> >  drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h |   6 +-
> >  drivers/gpu/drm/i915/gt/intel_context.c   |  15 +-
> >  drivers/gpu/drm/i915/gt/intel_context_types.h |  23 ++-
> >  drivers/gpu/drm/i915/gt/intel_mocs.c  |  14 +-
> >  drivers/gpu/drm/i915/gt/intel_rps.c   |   4 +
> >  drivers/gpu/drm/i915/gt/shmem_utils.c |   7 +-
> >  drivers/gpu/drm/i915/i915_request.h   |   6 +-
> >  9 files changed, 143 insertions(+), 124 deletions(-)
> > ___
> > dim-tools mailing list
> > dim-tools@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dim-tools
> 

___
dim-tools mailing list
dim-tools@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dim-tools

Re: [PULL] drm-intel-fixes

2020-11-12 Thread Vivi, Rodrigo 



> On Nov 12, 2020, at 4:32 PM, Dave Airlie  wrote:
> 
> On Fri, 13 Nov 2020 at 09:08, Rodrigo Vivi  wrote:
>> 
>> Hi Dave and Daniel,
>> 
>> This is the same set as last week + couple new fixes targeting stable.
>> 
> 
> But I merged last weeks set and it's in rc3, maybe you can generate
> the pull request relative to origin/master or drm/drm-fixes because
> I'm not sure which bits to edit out here.

oh, of course... bad rebase on my part. Sorry...
Please ignore this one. I'm going to generate another one soon.

> 
> Dave.
> 
>> Thanks,
>> Rodrigo.
>> 
>> drm-intel-fixes-2020-11-12-1:
>> - GVT fixes including vGPU suspend/resume fixes and workaround for APL guest 
>> GPU hang.
>> - Fix set domain's cache coherency (Chris)
>> - Fixes around breadcrumbs (Chris)
>> - Fix encoder lookup during PSR atomic (Imre)
>> - Hold onto an explicit ref to i915_vma_work.pinned (Chris)
>> - Pull phys pread/pwrite implementations to the backend (Chris)
>> - Correctly set SFC capability for video engines
>> The following changes since commit 3cea11cd5e3b00d91caf0b4730194039b45c5891:
>> 
>>  Linux 5.10-rc2 (2020-11-01 14:43:51 -0800)
>> 
>> are available in the Git repository at:
>> 
>>  git://anongit.freedesktop.org/drm/drm-intel 
>> tags/drm-intel-fixes-2020-11-12-1
>> 
>> for you to fetch changes up to a4264790f4c2f0062d27d8173344c914bc7884e0:
>> 
>>  drm/i915: Correctly set SFC capability for video engines (2020-11-12 
>> 16:41:54 -0500)
>> 
>> 
>> - GVT fixes including vGPU suspend/resume fixes and workaround for APL guest 
>> GPU hang.
>> - Fix set domain's cache coherency (Chris)
>> - Fixes around breadcrumbs (Chris)
>> - Fix encoder lookup during PSR atomic (Imre)
>> - Hold onto an explicit ref to i915_vma_work.pinned (Chris)
>> - Pull phys pread/pwrite implementations to the backend (Chris)
>> - Correctly set SFC capability for video engines
>> 
>> 
>> Chris Wilson (6):
>>  drm/i915/gem: Flush coherency domains on first set-domain-ioctl
>>  drm/i915/gt: Use the local HWSP offset during submission
>>  drm/i915/gt: Expose more parameters for emitting writes into the ring
>>  drm/i915/gt: Flush xcs before tgl breadcrumbs
>>  drm/i915: Hold onto an explicit ref to i915_vma_work.pinned
>>  drm/i915/gem: Pull phys pread/pwrite implementations to the backend
>> 
>> Colin Xu (4):
>>  drm/i915/gvt: Allow zero out HWSP addr on hws_pga_write
>>  drm/i915/gvt: Set SNOOP for PAT3 on BXT/APL to workaround GPU BB hang
>>  drm/i915/gvt: Only pin/unpin intel_context along with workload
>>  drm/i915/gvt: Fix mmio handler break on BXT/APL.
>> 
>> Imre Deak (1):
>>  drm/i915: Fix encoder lookup during PSR atomic check
>> 
>> Matthew Auld (1):
>>  drm/i915/gem: Allow backends to override pread implementation
>> 
>> Venkata Sandeep Dhanalakota (1):
>>  drm/i915: Correctly set SFC capability for video engines
>> 
>> drivers/gpu/drm/i915/display/intel_psr.c |  2 +-
>> drivers/gpu/drm/i915/gem/i915_gem_domain.c   | 28 ++--
>> drivers/gpu/drm/i915/gem/i915_gem_object_types.h |  2 +
>> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 55 
>> 
>> drivers/gpu/drm/i915/gt/intel_engine.h   | 55 
>> +++-
>> drivers/gpu/drm/i915/gt/intel_engine_cs.c|  3 +-
>> drivers/gpu/drm/i915/gt/intel_lrc.c  | 31 +
>> drivers/gpu/drm/i915/gt/intel_timeline.c | 18 
>> drivers/gpu/drm/i915/gt/intel_timeline_types.h   |  2 +
>> drivers/gpu/drm/i915/gvt/handlers.c  | 47 ++--
>> drivers/gpu/drm/i915/gvt/scheduler.c | 15 ---
>> drivers/gpu/drm/i915/i915_gem.c  | 32 +++---
>> drivers/gpu/drm/i915/i915_vma.c  |  6 ++-
>> 13 files changed, 204 insertions(+), 92 deletions(-)

___
dim-tools mailing list
dim-tools@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dim-tools

Re: [PATCH] dim: decode email message content charset to unicode

2020-10-28 Thread Vivi, Rodrigo 


On Oct 28, 2020, at 12:46 AM, Jani Nikula 
mailto:jani.nik...@intel.com>> wrote:

On Tue, 27 Oct 2020, Rodrigo Vivi 
mailto:rodrigo.v...@intel.com>> wrote:
On Mon, Oct 26, 2020 at 12:21:24PM +0200, Jani Nikula wrote:
On Wed, 16 Sep 2020, Rodrigo Vivi 
mailto:rodrigo.v...@intel.com>> wrote:
On Wed, Sep 16, 2020 at 12:57:43PM +0300, Jani Nikula wrote:
Email messages need two levels of decoding: First, content transfer
encoding, such as base64 or quoted-printable. Second, charset decoding.

We've done the first (with part.get_payload(decode=True)), but we've
ignored the charset. Mostly, it has not mattered, since most email is
ascii or utf-8 anyway, and python2 has been relaxed about it. However,
python3 part.get_payload(decode=True) gives us binary instead of
unicode, so we also need to do the charset decoding to get the result we
want.

The problem has likely been observed only now that 'python' no longer
exists or points at python3 instead of python2.

Use part.get_content_charset() for charset decoding, defaulting to
'us-ascii' source charset if nothing is specified.

Cc: Rodrigo Vivi mailto:rodrigo.v...@intel.com>>
Cc: Daniel Vetter mailto:dan...@ffwll.ch>>
Signed-off-by: Jani Nikula mailto:jani.nik...@intel.com>>

Reviewed-by: Rodrigo Vivi 
mailto:rodrigo.v...@intel.com>>
Tested-by: Rodrigo Vivi mailto:rodrigo.v...@intel.com>>

(Although it continue to fail with the encoded email)

Thanks, pushed, though still work to do I guess. :/

yeap... it also fails with recent gvt-fixes pull request :(

Except this is an altogether different issue. The mail parsing works
just fine.

Pulling https://github.com/intel/gvt-linux tags/gvt-fixes-2020-10-27 ...
>From https://github.com/intel/gvt-linux
* tag gvt-fixes-2020-10-27 -> FETCH_HEAD
dim: 401ccfa87856 ("drm/i915/gvt: Only pin/unpin intel_context along with 
workload"): Subject in fixes line doesn't match referenced commit:
dim: e6ba76480299 (drm/i915: Remove i915->kernel_context)
dim: ERROR: issues in commits detected, aborting


$ git log e6ba76480299 -1 --format="%s"
drm/i915: Remove i915->kernel_context

This is a valid complaint.

This is what's in the pull request:

$ git show 401ccfa87856 | grep Fixes
   Fixes: e6ba76480299 (drm/i915: Remove i915->kernel_context)

And this is what it should have:

$ dim fixes e6ba76480299 | grep Fixes
Fixes: e6ba76480299 ("drm/i915: Remove i915->kernel_context")

holy! Because my eyes didn't catch this and I assumed this old bug was the 
cause I had
pulled gvt-fixes into drm-intel-fixes bypassing dim. :/

I'm going to remove, force-push and request the fix there. So we don't 
propagate bad
tag that might break other scripts on the way.

Sorry,
Rodrigo.



BR,
Jani.




BR,
Jani.



Thanks,
Rodrigo.

---
dim | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dim b/dim
index c3a048db8956..3f489976c6bc 100755
--- a/dim
+++ b/dim
@@ -447,7 +447,7 @@ def print_msg(file):
msg = email.message_from_file(file)
for part in msg.walk():
if part.get_content_type() == 'text/plain':
-print(part.get_payload(decode=True))
+
print(part.get_payload(decode=True).decode(part.get_content_charset(failobj='us-ascii')))

print_msg(open('$1', 'r'))
EOF
--
2.20.1


--
Jani Nikula, Intel Open Source Graphics Center

--
Jani Nikula, Intel Open Source Graphics Center

___
dim-tools mailing list
dim-tools@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dim-tools

Should we accept # comment marks on fixes and parse them out?

2020-09-29 Thread Vivi, Rodrigo 
Apparently #x86-32 as comment is breaking dim on the fixes flow.


$ tdim push drm-intel-next-fixes
dim: d6ec212e4a0d ("drm/i915/gem: Avoid implicit vmap for highmem on x86-32"): 
Subject in fixes line doesn't match referenced commit:
dim: fb8621d3bee8 ("drm/i915: Avoid allocating a vmap arena for a single 
page") #x86-32
dim: ERROR: issues in commits detected, aborting

Should we parse the comment out?

if yes:

a simple

 fixes_subject=$(echo "${BASH_REMATCH[2]}" | cut -d# -f1

didn't work out with current comparison flow.. 
any suggestion for a clean parse and comparison?
___
dim-tools mailing list
dim-tools@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dim-tools

Re: [PATCH] dim: decode email message content charset to unicode

2020-09-16 Thread Vivi, Rodrigo 



> On Sep 16, 2020, at 7:00 AM, Jani Nikula  wrote:
> 
> On Wed, 16 Sep 2020, Rodrigo Vivi  wrote:
>> On Wed, Sep 16, 2020 at 12:57:43PM +0300, Jani Nikula wrote:
>>> Email messages need two levels of decoding: First, content transfer
>>> encoding, such as base64 or quoted-printable. Second, charset decoding.
>>> 
>>> We've done the first (with part.get_payload(decode=True)), but we've
>>> ignored the charset. Mostly, it has not mattered, since most email is
>>> ascii or utf-8 anyway, and python2 has been relaxed about it. However,
>>> python3 part.get_payload(decode=True) gives us binary instead of
>>> unicode, so we also need to do the charset decoding to get the result we
>>> want.
>>> 
>>> The problem has likely been observed only now that 'python' no longer
>>> exists or points at python3 instead of python2.
>>> 
>>> Use part.get_content_charset() for charset decoding, defaulting to
>>> 'us-ascii' source charset if nothing is specified.
>>> 
>>> Cc: Rodrigo Vivi 
>>> Cc: Daniel Vetter 
>>> Signed-off-by: Jani Nikula 
>> 
>> Reviewed-by: Rodrigo Vivi 
>> Tested-by: Rodrigo Vivi 
>> 
>> (Although it continue to fail with the encoded email)
> 
> Which one?

I got that gvt-next one and resent using outlook so I got a real encoded case.
That doesn't work with any of our versions.
It would be good to get the case that you told we had working in the past to 
test
as well...

> 
> BR,
> Jani.
> 
> 
>> 
>> Thanks,
>> Rodrigo.
>> 
>>> ---
>>> dim | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/dim b/dim
>>> index c3a048db8956..3f489976c6bc 100755
>>> --- a/dim
>>> +++ b/dim
>>> @@ -447,7 +447,7 @@ def print_msg(file):
>>> msg = email.message_from_file(file)
>>> for part in msg.walk():
>>> if part.get_content_type() == 'text/plain':
>>> -print(part.get_payload(decode=True))
>>> +
>>> print(part.get_payload(decode=True).decode(part.get_content_charset(failobj='us-ascii')))
>>> 
>>> print_msg(open('$1', 'r'))
>>> EOF
>>> -- 
>>> 2.20.1
>>> 
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center
> ___
> dim-tools mailing list
> dim-tools@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dim-tools

___
dim-tools mailing list
dim-tools@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dim-tools

Re: [PATCH] dim: allow to add link to the current HEAD

2019-11-18 Thread Vivi, Rodrigo 


On Nov 18, 2019, at 12:14 PM, Lucas De Marchi 
mailto:lucas.demar...@intel.com>> wrote:

On Mon, Nov 18, 2019 at 04:57:34PM +0200, Jani Nikula wrote:
On Fri, 15 Nov 2019, Lucas De Marchi 
mailto:lucas.demar...@intel.com>> wrote:
Add method add-link-head that applies the link to head without any
additional check. This is useful either to reduce typing or to add a
link while in the middle of an interactive rebase.

I see the patch does what it says on the box. However:

1) Most commands expect you to supply the branch name so you know what
 you're doing. There's tab completion to aid you, but you need to see
 what branch you're operating on. This has been in place since there
 was only one gun and two feet; now there are quite a few more people
 with opportunities to shoot themselves in the foot.

2) I think we should discourage pushing locally rebased
 patches. Recommend only pushing patches that apply cleanly. I'd go as
 far as removing the add-link* subcommands altogether.

Not sure how this is helping or avoiding that. "push" was never
mentioned here and it's not what this is about.

This was useful for me while rebasing a "feature branch"
to prep a new revision.  It's useful for the future developer reading
the patch to have a link to the revision where the patch was discussed,
rather than a link to a last revision where all the reviews were already
collected.


Very good point. But we need to do in a way that we don't loose the
last link. The last one is the proof that it passed CI.


Also any patch being applied to any branch are in other words being
rebased since your branch probably changed from the time you wrote it
and the time it was applied, even if it applies cleanly (your rebase
might have being clean, too).

Lucas De Marchi



BR,
Jani.




Signed-off-by: Lucas De Marchi 
mailto:lucas.demar...@intel.com>>
---
dim | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/dim b/dim
index 1c2da80..3aad25f 100755
--- a/dim
+++ b/dim
@@ -1255,17 +1255,11 @@ function dim_rebase
fi
}

-function dim_add_link
+function dim_add_link_head
{
- local branch file message_id
+ local file message_id

- branch=${1:?$usage}
- shift
file=$(mktemp)
-
- assert_branch $branch
- assert_repo_clean
-
cat > $file

message_id=$(message_get_id $file)
@@ -1279,6 +1273,19 @@ function dim_add_link
fi
}

+function dim_add_link
+{
+ local branch file message_id
+
+ branch=${1:?$usage}
+ shift
+
+ assert_branch $branch
+ assert_repo_clean
+
+ dim_add_link_head
+}
+
function dim_add_link_queued
{
dim_add_link drm-intel-next-queued "$@"

--
Jani Nikula, Intel Open Source Graphics Center
___
dim-tools mailing list
dim-tools@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dim-tools

___
dim-tools mailing list
dim-tools@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dim-tools

Re: [PATCH] doc/drm-tip: Some wording improvements

2019-11-14 Thread Vivi, Rodrigo 
Much better indeed.

Reviewed-by: Rodrigo Vivi 

> On Nov 13, 2019, at 9:48 AM, Daniel Vetter  wrote:
> 
> On Thu, Sep 19, 2019 at 9:35 PM Daniel Vetter  wrote:
>> 
>> Dave asked me how to fix a screwed-up rerere, and I noticed that the
>> wording/spelling is a bit sub-par.
>> 
>> Signed-off-by: Daniel Vetter 
> 
> Can I haz ack on this plz?
> -Daniel
>> ---
>> drm-tip.rst | 13 +++--
>> 1 file changed, 7 insertions(+), 6 deletions(-)
>> 
>> diff --git a/drm-tip.rst b/drm-tip.rst
>> index 80089f078bb4..a1e2dfedd745 100644
>> --- a/drm-tip.rst
>> +++ b/drm-tip.rst
>> @@ -92,7 +92,7 @@ drm-tip. Getting rid of that requires a few steps.
>> 2. Revert that commit and make sure there's no other cache resolutions 
>> around::
>> 
>>   $ cd $DIM_PREFIX/drm-rerere
>> -  $ git pull # to avoid with others
>> +  $ git pull # to avoid conflicts with others
>>   $ git revert $broken_resolution_sha1
>>   $ git clean -dfx
>> 
>> @@ -103,9 +103,9 @@ drm-tip. Getting rid of that requires a few steps.
>> If the Conflict Reappears
>> -
>> 
>> -In some odd cases git rerere fails to recognize the conflict, and doesn't 
>> store
>> -conflict resolution. This needs to be handled with a manual fixup patch, 
>> and the
>> -best way to go about this is:
>> +In some odd cases git rerere fails to recognize the conflict, and doesn't
>> +reapply the stored conflict resolution. This needs to be handled with a 
>> manual
>> +fixup patch, and the best way to go about this is:
>> 
>> 1. Try to resolve the conflict normally, but then running::
>> 
>> @@ -148,12 +148,13 @@ merge commit.
>> 
>> 1. Identify the merge that breaks the build.
>> 
>> -2. Rebuild drm-tip in interactive mode, and stop until the broken merge has 
>> been
>> +2. Rebuild drm-tip in interactive mode, and stop after the broken merge has 
>> been
>>done::
>> 
>>   $ dim -i rebuild-tip
>> 
>> -   Stop the rebuilding of drm-tip by hitting ^C.
>> +   Interrupt the rebuilding of drm-tip by hitting ^C when it asks you to 
>> hit a
>> +   key to proceed.
>> 
>> 3. Resolve the conflict normally, but don't stage it or commit it in any
>>fashion. Check that the resolution looks correct::
>> --
>> 2.23.0
>> 
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dim-tools mailing list
> dim-tools@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dim-tools

___
dim-tools mailing list
dim-tools@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dim-tools

Re: [PATCH 1/3] dim: Move special handling of drm-intel-next's repo to branch_to_repo

2018-08-27 Thread Vivi, Rodrigo 


> On Aug 27, 2018, at 1:39 AM, Nikula, Jani  wrote:
> 
>> On Mon, 27 Aug 2018, Daniel Vetter  wrote:
>>> On Fri, Aug 24, 2018 at 02:43:34PM -0700, Rodrigo Vivi wrote:
>>> I don't understand exactly why we need this special handling only
>>> for drm-intel-next. But let's at least consolidate this into
>>> branch_to_repo instead of spreading it around.
>>> 
>>> Cc: Jani Nikula 
>>> Cc: Daniel Vetter 
>>> Signed-off-by: Rodrigo Vivi 
>> 
>> drm-intel-next is not a dim-managed branch (i.e. it's not listed in
>> nightly.conf). I think that would be good to add in a comment.
>> 
>> With that added: Reviewed-by: Daniel Vetter 
>> 
>> Aside, I recommend you just remove drm-intel-next and all the special
>> casing. With the uncoupling of tagging from sending pull requests there's
>> really no need for this anymore.
>> 
>> The only other thing coupled with drm-intel-next is drm-intel-testing.
>> This was used by Gordon's QA team for the 1-week long manual test cycle.
>> Gordon's gfx QA team is no more (since years!), so there's really no point
>> in this. But there's also not much real harm (except the confusion
>> drm-intel-next/testing cause).
> 
> This is a process question. In general, I think it's a good idea to
> support a split workflow, tag first, tag multiple times, send pull
> request later. Did also Sean talk about this in the past? I forget.

+1 I like this flow of multiple tag and 1 pull request.

> 
> But do we need to *require* that drm-intel-next pull requests are done
> in this manner? Do we require a separate testing tag (which is a drm-tip
> snapshot) at this point? Who needs that? Who uses that?

All good questions. And I think we should kill -testing branch... probably kill 
-queued and unify with -misc approach, but all of this I think it is orthogonal 
to this series here and can be done later or in separate work.

> 
> BR,
> Jani.
> 
> 
> 
>> -Daniel
>> 
>>> ---
>>> dim | 13 +
>>> 1 file changed, 5 insertions(+), 8 deletions(-)
>>> 
>>> diff --git a/dim b/dim
>>> index 5040d6b046b2..fec51f766e55 100755
>>> --- a/dim
>>> +++ b/dim
>>> @@ -290,6 +290,10 @@ function branch_to_repo # branch
>>>fi
>>>done
>>> 
>>> +if [[ "$1" == "drm-intel-next" ]] ; then
>>> +echo "drm-intel"
>>> +fi
>>> +
>>>echo ""
>>> }
>>> 
>>> @@ -1402,10 +1406,6 @@ function dim_checkout
>>>if ! git_branch_exists $branch ; then
>>>repo=$(branch_to_repo $branch)
>>> 
>>> -if [[ $branch == "drm-intel-next" ]] ; then
>>> -repo="drm-intel"
>>> -fi
>>> -
>>>if [[ $repo == "" ]] ; then
>>>echoerr "$branch not found in $dim_integration_config"
>>>exit 1
>>> @@ -1890,6 +1890,7 @@ function dim_pull_request
>>>branch=${1:?$usage}
>>>upstream=${2:?$usage}
>>>remote=$(branch_to_remote $branch)
>>> +repo=$(branch_to_repo $branch)
>>>req_file=$(mktemp)
>>> 
>>>if [ "$branch" != "drm-intel-next" ]; then
>>> @@ -1906,16 +1907,12 @@ function dim_pull_request
>>>drm_intel_next_tags=$(git log "$branch@{upstream}" ^$upstream 
>>> --decorate | grep "(.*tag: drm-intel-next-" | sed -e "s/^.*(.*tag: 
>>> \(drm-intel-next-[^ ,]*\).*)$/\1/")
>>>prep_pull_mail $req_file $drm_intel_next_tags
>>>tag=$(git describe --all --exact "$branch@{upstream}")
>>> -
>>> -repo="drm-intel"
>>>else
>>>tag=$(tag_name "$branch")
>>>gitk --first-parent "$branch" ^$upstream &
>>>tag_branch $tag $branch
>>>$DRY git push $remote $tag
>>>prep_pull_mail $req_file $tag
>>> -
>>> -repo=$(branch_to_repo $branch)
>>>fi
>>> 
>>>url_list=${drm_tip_repos[$repo]}
>>> -- 
>>> 2.17.1
>>> 
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center
___
dim-tools mailing list
dim-tools@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dim-tools

Re: [PATCH 2/3] dim: Introduce dim_request_pull_tags

2018-08-27 Thread Vivi, Rodrigo 


> On Aug 27, 2018, at 1:34 AM, Nikula, Jani  wrote:
> 
>> On Mon, 27 Aug 2018, Daniel Vetter  wrote:
>>> On Fri, Aug 24, 2018 at 02:43:35PM -0700, Rodrigo Vivi wrote:
>>> Besides drm-intel-next, sometimes it is used to re-use an
>>> already existent tag that you just created outside
>>> or in cases where mutt/smtp goof-up you don't want
>>> to generate another identical tag with another date
>>> or with "-1", "-2", etc
>>> 
>>> Suggested-by: Daniel Vetter 
>>> Cc: Daniel Vetter 
>>> Cc: Jani Nikula 
>>> Signed-off-by: Rodrigo Vivi 
>>> ---
>>> dim | 45 +
>>> dim.rst |  6 ++
>>> 2 files changed, 51 insertions(+)
>>> 
>>> diff --git a/dim b/dim
>>> index fec51f766e55..b4d7996a1072 100755
>>> --- a/dim
>>> +++ b/dim
>>> @@ -1882,6 +1882,51 @@ function dim_tag_next
>>>dim_tag_branch "drm-intel-next"
>>> }
>>> 
>>> +function check_tags # tags
>>> +{
>>> +local tag
>>> +
>>> +for tag in "$@";
>>> +do
>>> +if ! git rev-parse "$tag^{tag}" > /dev/null 2>&1; then
>>> +echoerr "Aborting: Tag ${tag} not found"
>>> +exit 1
>>> +else
>>> +echo $tag
>>> +fi
>>> +done
>>> +}
>>> +
>>> +# dim_pull_request_tag branch upstream tag-list
>>> +function dim_pull_request_tags
>>> +{
>>> +local branch upstream repo req_file url_list git_url tags tag
>>> +
>>> +branch=${1:?$usage}
>>> +shift
>>> +upstream=${1:?$usage}
>>> +shift
>>> +tags="$*"
>>> +repo=$(branch_to_repo $branch)
>>> +req_file=$(mktemp)
>>> +
>>> +git_fetch_helper ${upstream%%/*}
>>> +echo "Using $upstream as the upstream"
>>> +
>>> +# Sort with newest first
>>> +tags=$(check_tags $tags | sort -r)
>>> +tag=$(echo $tags | cut -d " " -f 1)
>>> +
>>> +prep_pull_mail $req_file $tags
>>> +
>>> +url_list=${drm_tip_repos[$repo]}
>>> +git_url=$(pick_protocol_url git $url_list)
>>> +
>>> +git request-pull $upstream $git_url $tag >> $req_file
>>> +$DRY $DIM_MUA -s "[PULL] $branch" \
>>> + -i $req_file "${dim_pull_request_recipients[@]}"
>>> +}
>> 
>> s/tags/tag/ everywhere, since it's just a single tag, not plural. That
>> also means you can simplify the code a lot. Or I'm missing why you want to
>> send a pull request for multiple tags at the same time?

Because drm-Intel-next flow

Just making it generic so I can move specific stuff for drm-Intel-next into its 
own function...

>> 
>> Same for the help text below.
>> 
>> Aside: Autocomplete for this would be _very_ nifty. Should be possible to
>> wire up the git tag completion function into our own autocomplete.

Oh yeah, I forgot that, sorry!

>> 
>>> +
>>> # dim_pull_request branch upstream
>>> function dim_pull_request
>>> {
>>> diff --git a/dim.rst b/dim.rst
>>> index 6d7528ce497f..1a9bed464021 100644
>>> --- a/dim.rst
>>> +++ b/dim.rst
>>> @@ -292,6 +292,12 @@ be merged have been added, in order to help 
>>> maintainers with deciding which tree
>>> is in need of a pull request. Commiters that want to check the status of 
>>> their
>>> current branch should use normal **git status** commands.
>>> 
>>> +pull-request-tags *branch* *upstream* *tags*
>>> +
>>> +Fetches the *upstream* remote to make sure it's up-to-date. Based on the 
>>> given
>>> +*tags*, it generates a pull request template with the specified *upstream*,
>>> +and finally is starts \$DIM_MUA with the template with subject and
>>> +recipients already set.
>> 
>> I'd elaborate here a bit more.
>> 
>> "This can be used if the final steps of *pull-request* failed, or together
>> with *tag-branch* to separate the pull request generation from tag
>> creation."
>> 
>> I'd also add a hint to the help text for tag-branch about this new
>> command.
> 
> So what's the purpose here, really?

Allow to re-use tags when you know they are good. Keep old tag regeneration as 
the main path.

> We're carefully generating a new tag
> specifically to avoid re-using existing tags

Why?
Really, what’s the reason of forcing it without allowing to re-use?!


> , and now you want to allow
> it again?

Yes, I do.

> What are these "already existent tag that you just created
> outside"?

I was going to ask Who told I created outside?! And then I noticed this came 
from the poor commit message. I never created any tag from outside. All of them 
were always created with dim.
So I probably need to change commit message to make it clear.

> 
> I've seen these -1 suffix tags from Rodrigo, but I don't recall from
> anyone else.

Apparently I’m the only Goofy maintainer around, and I lost a day to fix the 
tool flow for 100% of the cases I faced here, so, why just mock it at first 
sight without considering it?!

> What goes wrong? Should we focus on fixing that instead?

Another way to solve the -1 case is checking of tag exist and reuse or delete 
and recreate...
But this doesn’t cover 100% of my exclusive goof-ups.

Last week I di

Re: [PATCH] qf: fix shellcheck warning

2018-03-14 Thread Vivi, Rodrigo 


> On Mar 14, 2018, at 2:08 AM, Jani Nikula  wrote:
> 
> In qf line 411:
> git reset --hard $(git rev-parse --abbrev-ref @{u})
> ^-- SC1083: This { is literal. Check expression (missing ;/\n?) or quote it.
> ^-- SC1083: This } is literal. Check expression (missing ;/\n?) or quote it.
> 

Sorry :(

> Cc: Rodrigo Vivi 
> Cc: Lucas De Marchi 
> Fixes: 0db9811183aa ("qf: Make qf_pull -f forcibly clean")
> Signed-off-by: Jani Nikula 

Acked-by: Rodrigo Vivi 

> ---
> qf | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/qf b/qf
> index 6dcf26970726..d1499ada1951 100755
> --- a/qf
> +++ b/qf
> @@ -408,7 +408,7 @@ function qf_pull
>cd patches
> 
>if [[ $FORCE ]]; then
> -git reset --hard $(git rev-parse --abbrev-ref @{u})
> +git reset --hard $(git rev-parse --abbrev-ref "@{u}")
>quiet_pop_all -f
>else
>git pull --ff-only
> -- 
> 2.11.0
> 
> ___
> dim-tools mailing list
> dim-tools@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dim-tools
___
dim-tools mailing list
dim-tools@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dim-tools