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

[Laurent Pinchart]

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 at ideasonboard.com>
> > >
> > > Reviewed-by: Sam Ravnborg <sam at 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
> 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.

- 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.

The second issue is easy to solve by commenting out auto-update (not
sure if Daniel will like that though :-)), and the third one isn't
really a blocker, but the first one currently prevents me from using
dim.

-- 
Regards,

Laurent Pinchart