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

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

[Laurent Pinchart]

The OrtusTech COM43H4M85ULC is a DPI panel, set the connector type
accordingly.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index e14c14ac62b5..145ee05dcacd 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2439,6 +2439,7 @@ static const struct panel_desc ortustech_com43h4m85ulc = {
 	},
 	.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 	.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+	.connector_type = DRM_MODE_CONNECTOR_DPI,
 };
 
 static const struct drm_display_mode osddisplays_osd070t1718_19ts_mode  = {
-- 
Regards,

Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Sam Ravnborg]

Hi Laurent.

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?

	Sam


> ---
>  drivers/gpu/drm/panel/panel-simple.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index e14c14ac62b5..145ee05dcacd 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2439,6 +2439,7 @@ static const struct panel_desc ortustech_com43h4m85ulc = {
>  	},
>  	.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
>  	.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
> +	.connector_type = DRM_MODE_CONNECTOR_DPI,
>  };
>  
>  static const struct drm_display_mode osddisplays_osd070t1718_19ts_mode  = {
> -- 
> Regards,
> 
> Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Laurent Pinchart]

Hi Sam,

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 :-)

> > ---
> >  drivers/gpu/drm/panel/panel-simple.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > index e14c14ac62b5..145ee05dcacd 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -2439,6 +2439,7 @@ static const struct panel_desc ortustech_com43h4m85ulc = {
> >  	},
> >  	.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> >  	.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
> > +	.connector_type = DRM_MODE_CONNECTOR_DPI,
> >  };
> >  
> >  static const struct drm_display_mode osddisplays_osd070t1718_19ts_mode  = {

-- 
Regards,

Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Sam Ravnborg]

On Mon, Mar 09, 2020 at 09:01:27PM +0200, Laurent Pinchart wrote:
> Hi Sam,
> 
> 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
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?

	Sam

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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@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
> 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Ville Syrjälä]

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

Re: [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@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.

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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@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.
> 
> 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Sam Ravnborg]

Hi Ville.

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

Because you did not tell me this was possible :-)
So I just tried '|' dim apply - it worked like wonders.
Thanks!

	Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Sam Ravnborg]

Hi Laurent.

On Mon, Mar 09, 2020 at 09:01:27PM +0200, Laurent Pinchart wrote:
> Hi Sam,
> 
> 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 :-)
OK.

Applied and pushed to drm-misc-next.

	Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel