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

[Laurent Pinchart]

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.

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

> 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. I think
that what bothered me the most was to figure this out by reading the
source code of dim, instead of seeing the message officially stated
somewhere. I'm not claiming that anybody's intent was to sneak this in
in any malicious way, but it probably felt similar unconciously, hence
my initial troubled reaction.

All this being said, my main concern is the first point I mentioned
above, that's the real technical blocker.

> * why would anyone run anything else but drm-tip anyway? ;)

-- 
Regards,

Laurent Pinchart