From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Thierry Reding <thierry.reding@gmail.com>,
Sam Ravnborg <sam@ravnborg.org>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm: panel: Set connector type for OrtusTech COM43H4M85ULC panel
Date: Mon, 9 Mar 2020 23:22:51 +0200 [thread overview]
Message-ID: <20200309212251.GZ13686@intel.com> (raw)
In-Reply-To: <20200309202942.GD4916@pendragon.ideasonboard.com>
On Mon, Mar 09, 2020 at 10:29:42PM +0200, Laurent Pinchart wrote:
> Hi Sam,
>
> 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.
> - 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. 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).
* why would anyone run anything else but drm-tip anyway? ;)
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-03-09 21:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-09 18:42 [PATCH] drm: panel: Set connector type for OrtusTech COM43H4M85ULC panel Laurent Pinchart
2020-03-09 19:00 ` Sam Ravnborg
2020-03-09 19:01 ` Laurent Pinchart
2020-03-09 19:45 ` Sam Ravnborg
2020-03-09 20:29 ` Laurent Pinchart
2020-03-09 21:22 ` Ville Syrjälä [this message]
2020-03-09 21:43 ` Laurent Pinchart
2020-03-10 11:51 ` Ville Syrjälä
2020-03-10 17:31 ` Sam Ravnborg
2020-03-10 17:37 ` Sam Ravnborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200309212251.GZ13686@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=sam@ravnborg.org \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).