The changeset contains a number of cleanups, changed semantics of
init_panel() callback, which allows to simplify getting of panel
properties from panel device tree node, and a handling of optional
"enable-gpios" panel property, the latter is described in
display/panel/panel-dpi.txt device tree binding documentation, but
it has been unsupported by the ARM CLCD driver.
Vladimir Zapolskiy (4):
video: ARM CLCD: sort included headers out alphabetically
video: ARM CLCD: use panel device node for panel initialization
video: ARM CLCD: use panel device node for getting backlight and mode
video: ARM CLCD: add support of an optional GPIO to enable panel
drivers/video/fbdev/amba-clcd-nomadik.c | 9 +---
drivers/video/fbdev/amba-clcd-nomadik.h | 5 +-
drivers/video/fbdev/amba-clcd-versatile.c | 14 ++----
drivers/video/fbdev/amba-clcd-versatile.h | 5 +-
drivers/video/fbdev/amba-clcd.c | 80 +++++++++++++++++++------------
include/linux/amba/clcd.h | 2 +
6 files changed, 59 insertions(+), 56 deletions(-)
--
2.10.2
To simplify the task of looking through the list of included headers sort
them out alphabetically, some of the truly redundant headers are removed
from the list.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/video/fbdev/amba-clcd.c | 23 +++++++++--------------
1 file changed, 9 insertions(+), 14 deletions(-)
There is no necessity to pass an endpoint device node to custom panel
initialization functions, because a child panel device node should be
sufficient, note that the existing init_panel() callback declaration from
linux/amba/clcd.h already prompts to use the panel device node here.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/video/fbdev/amba-clcd-nomadik.c | 9 +--------
drivers/video/fbdev/amba-clcd-nomadik.h | 5 ++---
drivers/video/fbdev/amba-clcd-versatile.c | 14 +++-----------
drivers/video/fbdev/amba-clcd-versatile.h | 5 ++---
drivers/video/fbdev/amba-clcd.c | 8 ++++++--
5 files changed, 14 insertions(+), 27 deletions(-)
@@ -488,11 +486,6 @@ static void versatile_panel_probe(struct device *dev,return;}-panel=of_graph_get_remote_port_parent(endpoint);-if(!panel){-dev_err(dev,"could not locate panel in DT\n");-return;-}if(!of_device_is_compatible(panel,vpanel->compatible))dev_err(dev,"panel in DT is not compatible with the ""auto-detected panel, continuing anyway\n");
@@ -551,7 +543,7 @@ int versatile_clcd_init_panel(struct clcd_fb *fb,fb->board->enable=versatile_clcd_enable;fb->board->disable=versatile_clcd_disable;fb->board->decode=versatile_clcd_decode;-versatile_panel_probe(dev,endpoint);+versatile_panel_probe(dev,panel);dev_info(dev,"set up callbacks for Versatile\n");break;caseREALVIEW_CLCD_EB:
Having obtained panel device node in clcdfb_of_init_display() it allows to
generalize and simplify two more helper functions clcdfb_of_get_backlight()
and clcdfb_of_get_mode().
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/video/fbdev/amba-clcd.c | 20 +++++---------------
1 file changed, 5 insertions(+), 15 deletions(-)
@@ -624,16 +624,11 @@ static int clcdfb_snprintf_mode(char *buf, int size, struct fb_videomode *mode)mode->refresh);}-staticintclcdfb_of_get_backlight(structdevice_node*endpoint,+staticintclcdfb_of_get_backlight(structdevice_node*panel,structclcd_panel*clcd_panel){-structdevice_node*panel;structdevice_node*backlight;-panel=of_graph_get_remote_port_parent(endpoint);-if(!panel)-return-ENODEV;-/* Look up the optional backlight phandle */backlight=of_parse_phandle(panel,"backlight",0);if(backlight){
@@ -646,19 +641,14 @@ static int clcdfb_of_get_backlight(struct device_node *endpoint,return0;}-staticintclcdfb_of_get_mode(structdevice*dev,structdevice_node*endpoint,-structclcd_panel*clcd_panel)+staticintclcdfb_of_get_mode(structdevice*dev,structdevice_node*panel,+structclcd_panel*clcd_panel){interr;-structdevice_node*panel;structfb_videomode*mode;char*name;intlen;-panel=of_graph_get_remote_port_parent(endpoint);-if(!panel)-return-ENODEV;-/* Only directly connected DPI panels supported for now */if(of_device_is_compatible(panel,"panel-dpi"))err=clcdfb_of_get_dpi_panel_mode(panel,clcd_panel);
@@ -791,11 +781,11 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)returnerr;}-err=clcdfb_of_get_backlight(endpoint,fb->panel);+err=clcdfb_of_get_backlight(panel,fb->panel);if(err)returnerr;-err=clcdfb_of_get_mode(&fb->dev->dev,endpoint,fb->panel);+err=clcdfb_of_get_mode(&fb->dev->dev,panel,fb->panel);if(err)returnerr;
The change adds handling of "enable-gpios" property of panel-dpi device
node used with an ARM CLCD controller, note that the property already has
a description in display/panel/panel-dpi.txt documentation and it founds
practical usage while describing some panel devices connected to other
types of display controllers.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/video/fbdev/amba-clcd.c | 29 +++++++++++++++++++++++++++++
include/linux/amba/clcd.h | 2 ++
2 files changed, 31 insertions(+)
On Wed, Dec 21, 2016 at 4:27 AM, Vladimir Zapolskiy [off-list ref] wrote:
The change adds handling of "enable-gpios" property of panel-dpi device
node used with an ARM CLCD controller, note that the property already has
a description in display/panel/panel-dpi.txt documentation and it founds
practical usage while describing some panel devices connected to other
types of display controllers.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
So as you may have seen I already handle a RESET GPIO in the
Nomadik TPG110 panel subddriver in
drivers/video/fbdev/amba-clcd-nomadik.c
So is this all your panel needs?
I guess it is OK for simple panels.
Yours,
Linus Walleij
On Wed, Dec 21, 2016 at 4:27 AM, Vladimir Zapolskiy [off-list ref] wrote:
The changeset contains a number of cleanups, changed semantics of
init_panel() callback, which allows to simplify getting of panel
properties from panel device tree node, and a handling of optional
"enable-gpios" panel property, the latter is described in
display/panel/panel-dpi.txt device tree binding documentation, but
it has been unsupported by the ARM CLCD driver.
Vladimir Zapolskiy (4):
video: ARM CLCD: sort included headers out alphabetically
video: ARM CLCD: use panel device node for panel initialization
video: ARM CLCD: use panel device node for getting backlight and mode
video: ARM CLCD: add support of an optional GPIO to enable panel
As you may have seen Tomi has stepped down as FBDEV maintainer and
this subsystem is now orphaned.
I guess Andrew Morton merges patches for it in this case, he usually does.
But what we should actually do is create a new DRM driver for CLCD
in drivers/gpu/drm/arm/clcd*
It's maybe not a small undertaking :(
But in case you're interested in the job, I will pitch in and test the result
on all ARM reference designs plus Nomadik.
Yours,
Linus Walleij
On Wed, Dec 21, 2016 at 4:27 AM, Vladimir Zapolskiy [off-list ref] wrote:
quoted
The change adds handling of "enable-gpios" property of panel-dpi device
node used with an ARM CLCD controller, note that the property already has
a description in display/panel/panel-dpi.txt documentation and it founds
practical usage while describing some panel devices connected to other
types of display controllers.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
So as you may have seen I already handle a RESET GPIO in the
Nomadik TPG110 panel subddriver in
drivers/video/fbdev/amba-clcd-nomadik.c
So is this all your panel needs?
I need "enable-gpios" property to define a GPIO, which literally enables
(powers up) a panel as a separate attached PCB.
To some extend "enable-gpios" property can be replaced by "power" property
with a phandle to a GPIO voltage regulator.
You may look at drivers/gpu/drm/panel/panel-simple.c, both "enable-gpios"
and "power" properties are defined for simple panels.
On Wed, Dec 21, 2016 at 4:27 AM, Vladimir Zapolskiy [off-list ref] wrote:
quoted
The changeset contains a number of cleanups, changed semantics of
init_panel() callback, which allows to simplify getting of panel
properties from panel device tree node, and a handling of optional
"enable-gpios" panel property, the latter is described in
display/panel/panel-dpi.txt device tree binding documentation, but
it has been unsupported by the ARM CLCD driver.
Vladimir Zapolskiy (4):
video: ARM CLCD: sort included headers out alphabetically
video: ARM CLCD: use panel device node for panel initialization
video: ARM CLCD: use panel device node for getting backlight and mode
video: ARM CLCD: add support of an optional GPIO to enable panel
As you may have seen Tomi has stepped down as FBDEV maintainer and
this subsystem is now orphaned.
I guess Andrew Morton merges patches for it in this case, he usually does.
Hello Andrew,
if you have the patches in your mailbox, could you please review and
apply them for the next?
But what we should actually do is create a new DRM driver for CLCD
in drivers/gpu/drm/arm/clcd*
It's maybe not a small undertaking :(
But in case you're interested in the job, I will pitch in and test the result
on all ARM reference designs plus Nomadik.
I'll take a look at this task, talking about the controller itself
it should be relatively easy to port the driver to DRM and replace
panel initialization code with a panel-simple driver, however platform
specific hooks for Nomadik and Versatile require special attention,
and because I don't have that hardware I'll keep my hands off it. FWIW
the LPC32xx and LPC18xx/LPC43xx platforms for which I did this change
don't need anything out of the shared video/fbdev/amba-clcd.c code.
--
With best wishes,
Vladimir
From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: 2017-01-02 14:22:28
On Fri, Dec 30, 2016 at 09:23:59AM +0100, Linus Walleij wrote:
On Wed, Dec 21, 2016 at 4:27 AM, Vladimir Zapolskiy [off-list ref] wrote:
quoted
The changeset contains a number of cleanups, changed semantics of
init_panel() callback, which allows to simplify getting of panel
properties from panel device tree node, and a handling of optional
"enable-gpios" panel property, the latter is described in
display/panel/panel-dpi.txt device tree binding documentation, but
it has been unsupported by the ARM CLCD driver.
Vladimir Zapolskiy (4):
video: ARM CLCD: sort included headers out alphabetically
video: ARM CLCD: use panel device node for panel initialization
video: ARM CLCD: use panel device node for getting backlight and mode
video: ARM CLCD: add support of an optional GPIO to enable panel
As you may have seen Tomi has stepped down as FBDEV maintainer and
this subsystem is now orphaned.
I guess Andrew Morton merges patches for it in this case, he usually does.
But what we should actually do is create a new DRM driver for CLCD
in drivers/gpu/drm/arm/clcd*
It's maybe not a small undertaking :(
But in case you're interested in the job, I will pitch in and test the result
on all ARM reference designs plus Nomadik.
A DRM driver for it would probably be a good idea, but dealing with all
the weird and wonderful connection arrangements may not be that easy...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
On 01/02/2017 04:22 PM, Russell King - ARM Linux wrote:
On Fri, Dec 30, 2016 at 09:23:59AM +0100, Linus Walleij wrote:
quoted
On Wed, Dec 21, 2016 at 4:27 AM, Vladimir Zapolskiy [off-list ref] wrote:
quoted
The changeset contains a number of cleanups, changed semantics of
init_panel() callback, which allows to simplify getting of panel
properties from panel device tree node, and a handling of optional
"enable-gpios" panel property, the latter is described in
display/panel/panel-dpi.txt device tree binding documentation, but
it has been unsupported by the ARM CLCD driver.
Vladimir Zapolskiy (4):
video: ARM CLCD: sort included headers out alphabetically
video: ARM CLCD: use panel device node for panel initialization
video: ARM CLCD: use panel device node for getting backlight and mode
video: ARM CLCD: add support of an optional GPIO to enable panel
As you may have seen Tomi has stepped down as FBDEV maintainer and
this subsystem is now orphaned.
I guess Andrew Morton merges patches for it in this case, he usually does.
But what we should actually do is create a new DRM driver for CLCD
in drivers/gpu/drm/arm/clcd*
It's maybe not a small undertaking :(
But in case you're interested in the job, I will pitch in and test the result
on all ARM reference designs plus Nomadik.
A DRM driver for it would probably be a good idea, but dealing with all
the weird and wonderful connection arrangements may not be that easy...
Linus, Russell,
I've immediately encountered a problem while porting the driver to DRM,
because LPC18xx/LPC43xx SoCs are powered by Cortex-M3/M4 cores and DRM
framework has build and runtime dependencies on MMU.
That said, in short term I would expect a continuation of support for
the legacy CLCD framebuffer driver, which works fine on MMU-less SoCs.
--
With best wishes,
Vladimir
On 01/02/2017 04:22 PM, Russell King - ARM Linux wrote:
quoted
On Fri, Dec 30, 2016 at 09:23:59AM +0100, Linus Walleij wrote:
quoted
On Wed, Dec 21, 2016 at 4:27 AM, Vladimir Zapolskiy [off-list ref] wrote:
quoted
The changeset contains a number of cleanups, changed semantics of
init_panel() callback, which allows to simplify getting of panel
properties from panel device tree node, and a handling of optional
"enable-gpios" panel property, the latter is described in
display/panel/panel-dpi.txt device tree binding documentation, but
it has been unsupported by the ARM CLCD driver.
Vladimir Zapolskiy (4):
video: ARM CLCD: sort included headers out alphabetically
video: ARM CLCD: use panel device node for panel initialization
video: ARM CLCD: use panel device node for getting backlight and mode
video: ARM CLCD: add support of an optional GPIO to enable panel
As you may have seen Tomi has stepped down as FBDEV maintainer and
this subsystem is now orphaned.
I guess Andrew Morton merges patches for it in this case, he usually does.
But what we should actually do is create a new DRM driver for CLCD
in drivers/gpu/drm/arm/clcd*
It's maybe not a small undertaking :(
But in case you're interested in the job, I will pitch in and test the result
on all ARM reference designs plus Nomadik.
A DRM driver for it would probably be a good idea, but dealing with all
the weird and wonderful connection arrangements may not be that easy...
Linus, Russell,
I've immediately encountered a problem while porting the driver to DRM,
because LPC18xx/LPC43xx SoCs are powered by Cortex-M3/M4 cores and DRM
framework has build and runtime dependencies on MMU.
That said, in short term I would expect a continuation of support for
the legacy CLCD framebuffer driver, which works fine on MMU-less SoCs.
Linus, Russell,
please let me ask you to review/ack the changes, then I'll resend them
to Andrew for inclusion as suggested by Linus.
--
With best wishes,
Vladimir
From: Vladimir Murzin <hidden> Date: 2017-01-10 13:47:01
Hi Vladimir,
On 07/01/17 23:32, Vladimir Zapolskiy wrote:
On 01/02/2017 04:22 PM, Russell King - ARM Linux wrote:
quoted
On Fri, Dec 30, 2016 at 09:23:59AM +0100, Linus Walleij wrote:
quoted
On Wed, Dec 21, 2016 at 4:27 AM, Vladimir Zapolskiy [off-list ref] wrote:
quoted
The changeset contains a number of cleanups, changed semantics of
init_panel() callback, which allows to simplify getting of panel
properties from panel device tree node, and a handling of optional
"enable-gpios" panel property, the latter is described in
display/panel/panel-dpi.txt device tree binding documentation, but
it has been unsupported by the ARM CLCD driver.
Vladimir Zapolskiy (4):
video: ARM CLCD: sort included headers out alphabetically
video: ARM CLCD: use panel device node for panel initialization
video: ARM CLCD: use panel device node for getting backlight and mode
video: ARM CLCD: add support of an optional GPIO to enable panel
As you may have seen Tomi has stepped down as FBDEV maintainer and
this subsystem is now orphaned.
I guess Andrew Morton merges patches for it in this case, he usually does.
But what we should actually do is create a new DRM driver for CLCD
in drivers/gpu/drm/arm/clcd*
It's maybe not a small undertaking :(
But in case you're interested in the job, I will pitch in and test the result
on all ARM reference designs plus Nomadik.
A DRM driver for it would probably be a good idea, but dealing with all
the weird and wonderful connection arrangements may not be that easy...
Linus, Russell,
I've immediately encountered a problem while porting the driver to DRM,
because LPC18xx/LPC43xx SoCs are powered by Cortex-M3/M4 cores and DRM
framework has build and runtime dependencies on MMU.
That said, in short term I would expect a continuation of support for
the legacy CLCD framebuffer driver, which works fine on MMU-less SoCs.
--
With best wishes,
Vladimir
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Problem solved?
Vladimir: I do not require in any way that you create a CLCD driver for DRM,
I just think it would be very very nice...
Yours,
Linus Walleij
Problem solved?
Vladimir: I do not require in any way that you create a CLCD driver for DRM,
I just think it would be very very nice...
I have no other option, this series is unreviewed and thus unlikely it will
be applied, still a panel PCB on my board needs power management support.
--
With best wishes,
Vladimir
Problem solved?
Vladimir: I do not require in any way that you create a CLCD driver for DRM,
I just think it would be very very nice...
I have no other option, this series is unreviewed and thus unlikely it will
be applied, still a panel PCB on my board needs power management support.
Hm I can ACK it I guess, but mergeing it into an unmaintained subsystem
is another issue, just not very optimal. If you get it working on your system
I can look into migrating all the old users to DRM as well.
Yours,
Linus Walleij
Problem solved?
Vladimir: I do not require in any way that you create a CLCD driver for DRM,
I just think it would be very very nice...
I have no other option, this series is unreviewed and thus unlikely it will
be applied, still a panel PCB on my board needs power management support.
Hm I can ACK it I guess, but mergeing it into an unmaintained subsystem
is another issue, just not very optimal.
+ Bartlomiej
Linus, your ack is always more than appreciated.
To all appearance Bartlomiej is a new honoured framebuffer layer maintainer.
Bartlomiej, do you have the changes under discussion in your mailbox or
should I resend them to you directly for review?
If you get it working on your system I can look into migrating all the old
users to DRM as well.
Sure, I started development of a simple CLCD DRM driver as an own attractive
exercise, I'll keep you informed of the progress.
--
With best wishes,
Vladimir
Problem solved?
Vladimir: I do not require in any way that you create a CLCD driver for DRM,
I just think it would be very very nice...
I have no other option, this series is unreviewed and thus unlikely it will
be applied, still a panel PCB on my board needs power management support.
Hm I can ACK it I guess, but mergeing it into an unmaintained subsystem
is another issue, just not very optimal.
+ Bartlomiej
Linus, your ack is always more than appreciated.
+1
To all appearance Bartlomiej is a new honoured framebuffer layer maintainer.
Bartlomiej, do you have the changes under discussion in your mailbox or
should I resend them to you directly for review?
No need for resend, I picked them from the list and they are on TODO.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
quoted
If you get it working on your system I can look into migrating all the old
users to DRM as well.
Sure, I started development of a simple CLCD DRM driver as an own attractive
exercise, I'll keep you informed of the progress.
--
With best wishes,
Vladimir
Problem solved?
Vladimir: I do not require in any way that you create a CLCD driver for DRM,
I just think it would be very very nice...
I have no other option, this series is unreviewed and thus unlikely it will
be applied, still a panel PCB on my board needs power management support.
Hm I can ACK it I guess, but mergeing it into an unmaintained subsystem
is another issue, just not very optimal.
+ Bartlomiej
Linus, your ack is always more than appreciated.
+1
quoted
To all appearance Bartlomiej is a new honoured framebuffer layer maintainer.
Bartlomiej, do you have the changes under discussion in your mailbox or
should I resend them to you directly for review?
No need for resend, I picked them from the list and they are on TODO.
Bartlomiej, Linus,
I've noticed that 4/4 requires special attention due to the anticipated
change of devm_get_gpiod_from_child() interface.
If you have any concerns regarding 4/4, please review and consider to
apply the first three clean-up patches in the series, basically I've
achieved my goal of describing a power supply for a panel in DTS by
introducing a DRM driver (see a note below), however support of
"enable-gpios" property mentioned in the "panel-dpi" device tree binding
documentation still is seen as beneficial for the CLCD fbdev driver.
quoted
quoted
If you get it working on your system I can look into migrating all the old
users to DRM as well.
Sure, I started development of a simple CLCD DRM driver as an own attractive
exercise, I'll keep you informed of the progress.
Some updates, now I've developed a simple CLCD DRM driver which works
nicely on one of my boards powered by LPC3250 (has MMU), but I still
have to find enough time and check that the driver works on MMU-less
LPC4357 with the applied DRM core change referenced by Vladimir earlier.
Most probably I'll complete polishing the driver on this weekend and
send it for review on the next week.
One more comment, I've found a discussion when DT support to the CLCD
fbdev driver was added [1], there are some comments about panel device
node and endpoints incompatibility in comparison to the common layout
for Linux-ish DRM devices, and I do confirm that this incompatibility
exists. I have both versions though, but you guess that DRM flavour
is cleaner, and for CLCD DRM driver I'm going to use it.
The legacy DT layout can be supported in the same driver in parallel,
but unfortunately it makes the driver not so cute, and I decide to
drop it in the initial version. It implies that CLCD fbdev users with
the controller and panel descriptions in DT and who want to switch to
CLCD DRM driver should update DTS. Sorry, I know it is inconvenient...
[1] https://patchwork.kernel.org/patch/3777391/
--
With best wishes,
Vladimir
On Tue, Jan 17, 2017 at 2:57 AM, Vladimir Zapolskiy [off-list ref] wrote:
I've noticed that 4/4 requires special attention due to the anticipated
change of devm_get_gpiod_from_child() interface.
Hm. Yeah I merged that patch to the GPIO tree yesterday.
I can of course put those patches on an immutable branch to
be pulled into the fbdev tree, if Bartlomiej wants to kickstart
the fbdev work with some complex cross-git merging :D
Some updates, now I've developed a simple CLCD DRM driver which works
nicely on one of my boards powered by LPC3250 (has MMU), but I still
have to find enough time and check that the driver works on MMU-less
LPC4357 with the applied DRM core change referenced by Vladimir earlier.
Most probably I'll complete polishing the driver on this weekend and
send it for review on the next week.
Nice! I look forward to it.
One more comment, I've found a discussion when DT support to the CLCD
fbdev driver was added [1], there are some comments about panel device
node and endpoints incompatibility in comparison to the common layout
for Linux-ish DRM devices, and I do confirm that this incompatibility
exists. I have both versions though, but you guess that DRM flavour
is cleaner, and for CLCD DRM driver I'm going to use it.
Probably a good idea.
The legacy DT layout can be supported in the same driver in parallel,
but unfortunately it makes the driver not so cute, and I decide to
drop it in the initial version. It implies that CLCD fbdev users with
the controller and panel descriptions in DT and who want to switch to
CLCD DRM driver should update DTS. Sorry, I know it is inconvenient...
I'm one of those who tend to be lax on these DT ABI issues.
I guess it makes most sense to merge the DRM driver in parallel,
using the DRM bindings, then I can work on adding in support for
my misc systems (all ARM reference designs essentially, plus
Nomadik) using the DRM bindings, and we can stabilize that,
then as a last step simply switch over, augment all device trees
and delete the old fbdev driver.
These systems do NOT have deployed DTB device trees that cannot
be upgraded, they are reference designs not consumer products,
so requireing people to update their device trees is totally
reasonable. In fact I use attached device tree on all of them.
Yours,
Linus Walleij
Problem solved?
Vladimir: I do not require in any way that you create a CLCD driver for DRM,
I just think it would be very very nice...
I have no other option, this series is unreviewed and thus unlikely it will
be applied, still a panel PCB on my board needs power management support.
Hm I can ACK it I guess, but mergeing it into an unmaintained subsystem
is another issue, just not very optimal.
+ Bartlomiej
Linus, your ack is always more than appreciated.
+1
quoted
To all appearance Bartlomiej is a new honoured framebuffer layer maintainer.
Bartlomiej, do you have the changes under discussion in your mailbox or
should I resend them to you directly for review?
No need for resend, I picked them from the list and they are on TODO.
Bartlomiej, Linus,
I've noticed that 4/4 requires special attention due to the anticipated
change of devm_get_gpiod_from_child() interface.
If you have any concerns regarding 4/4, please review and consider to
apply the first three clean-up patches in the series, basically I've
achieved my goal of describing a power supply for a panel in DTS by
introducing a DRM driver (see a note below), however support of
"enable-gpios" property mentioned in the "panel-dpi" device tree binding
documentation still is seen as beneficial for the CLCD fbdev driver.
Thanks, I queued patches #1-3 for 4.11. Please ping me later for
merging patch #4.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics