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

[Ville Syrjälä]

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

-- 
Ville Syrjälä
Intel