Re: [PATCH] drm: panel: Set connector type for OrtusTech COM43H4M85ULC panel

["Ville Syrjälä" <ville.syrjala@linux.intel.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