On Mon, Mar 09, 2020 at 11:43:33PM +0200, Laurent Pinchart wrote:
Hi Ville,
On Mon, Mar 09, 2020 at 11:22:51PM +0200, Ville Syrjälä wrote:
On Mon, Mar 09, 2020 at 10:29:42PM +0200, Laurent Pinchart wrote:
On Mon, Mar 09, 2020 at 08:45:41PM +0100, Sam Ravnborg wrote:
On Mon, Mar 09, 2020 at 09:01:27PM +0200, Laurent Pinchart wrote:
On Mon, Mar 09, 2020 at 08:00:47PM +0100, Sam Ravnborg wrote:
On Mon, Mar 09, 2020 at 08:42:10PM +0200, Laurent Pinchart wrote: > The OrtusTech COM43H4M85ULC is a DPI panel, set the connector type > accordingly. > > Signed-off-by: Laurent Pinchart laurent.pinchart@ideasonboard.com
Reviewed-by: Sam Ravnborg sam@ravnborg.org
I assume you will apply to drm-misc-next - OK?
I still haven't got around to using dim :-)
I can manage - so the entry level is pretty low.
My lame and simple workflow
dim update-branches # save patch from mutt cat mbox | dim apply
Why don't you just pipe the thing into dim straight from mutt? That's what I do. Followed by some amount of dim extract-tag also piped in from mutt.
git rebase etc. dim checkpatch <= if I make changes while applying #build testing dim push
And when I do my own stuff: dim update-branches git checkout -b sam-my-stuff hacking-hacking commit, commit git rebase --exec "dim add-missing-cc" HEAD~5
dim can do much more than that - but the above is the few dim commands I use. This help me to do things remotely correct.
So maybe this is as good as any time to try out dim?
As good as any, and as bad as any I suppose :-)
There are a few things I don't like with dim, and I haven't found time yet to see how to fix (how live with :-) them yet. Among those issues are
dim requires the kernel tree to be under $DIM_PREFIX. This is my main issue, as I have one kernel tree per project, with and develop for different subsystems in each. I would like dim to instead handle any kernel tree regardless of where it is located on the disk, without requiring me to add another DRM-specific tree to my workflow.
The script auto-updates itself, and I find that to be a security issue that I'm not comfortable with.
What do you mean it auto updates? Never seen anything like that.
Unless I'm mistaken,
function dim_uptodate { local using
using="${BASH_SOURCE[0]}"
if [[ ! -e "$using" ]]; then echoerr "could not figure out the version being used ($using)." return 1 fi
if [[ ! -e "$DIM_PREFIX/maintainer-tools/.git" ]]; then echoerr "could not find the upstream repo for $dim." return 1 fi
git --git-dir=$DIM_PREFIX/maintainer-tools/.git fetch -q
if ! git --git-dir=$DIM_PREFIX/maintainer-tools/.git show "@{upstream}:dim" |\ diff "$using" - >& /dev/null; then echoerr "not running upstream version of the script." return 1 fi }
function check_for_updates { local stamp stampfile
stampfile=$HOME/.dim-update-check-timestamp
# daily check for updates based on file timestamp stamp=$(stat --printf=%Y $stampfile 2>/dev/null || echo -n 0) if [[ $((stamp + 24*60*60)) -lt $(date +%s) ]]; then dim_uptodate || true touch $stampfile fi }
And check_for_updates is called for all commands not listed by list_developer_commands.
It checks if your dim is up to date. It doesn't automagically update it for you.
- The dim script makes a special case of intel repositories internally, which I don't find very fair. Maybe that can be considered as a compensation for Intel's efforts in DRM development, but a model where the community maintaining drm-misc has to resolve conflicts with drm-intel before it reaches drm-next bothers me.
It doesn't special case Intel repos. It just merges all the repos listed in the config file to create a new drm-tip. There are Intel repos, AMD repos, and various other repos.
drm-amd has indeed been added and is taken into accout in dim_push_branch, with drm-misc and drm-intel, but there's still lots of Intel-specific code in other places.
All I really see are a few subcommands which I think are only used by i915 maintainers so there hasn't been any real need to abstract away any hardcoded references to intel repos etc. So can't really see "lots of code" like this.
The point is to keep drm-tip always up to date and working (*). And if you manage to create a conflict you can't solve you can always ping someone who can. Also hoefully no one should be seeing all that many conflicts due to rerere (unless you actually created a new conflict that is).
What happens is that drm-misc is competing with drm-intel and drm-amd to get in drm-next, with everything merged in drm-tip. It effectively conveys a message that there's Intel, AMD, and the community, which means that Intel and AMD are considered higher priority than any other single vendor, when we came from a situation where, *in theory*, all vendors were of equal importance. This can be justified by the fact that the amount of patches generated by Intel and AMD are significantly higher than what any other vendor produces, but it's still a significant change in how the contributors to the DRM subsystem are treated.
Anyone working on drm-intel/drm-arm/drm-any-other-repo-we-decide-to-have have to equally deal with the fallout from all the other repos as well. So everyone is treated exactly the same AFAICS.