| Message ID | 20200309184210.10042-1-laurent.pinchart@ideasonboard.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm: panel: Set connector type for OrtusTech COM43H4M85ULC panel | expand |
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
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 = {
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
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.
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? ;)
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? ;)
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.
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
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
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 = {
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(+)