* Re: [PATCH 00/23] OMAPDSS: misc patches
From: Tomi Valkeinen @ 2015-12-16 15:36 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1449676791-26304-1-git-send-email-tomi.valkeinen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 748 bytes --]
On 13/12/15 22:24, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patches.
>
> On Wednesday 09 December 2015 17:59:28 Tomi Valkeinen wrote:
>> Hi,
>>
>> Here is a pile of smallish patches for omapdss, forward ported from TI's
>> product kernel (which means they have had some testing).
>>
>> Many of these patches prepare the omapdss driver for writeback by cleaning
>> up writeback related code, and adding bits here and there for register
>> level writeback support. The patch to add writeback support itself is
>> missing, as it's still not in a stable state.
>
> For 1/23, 2/13, 20/23, 21/23 and 23/23,
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Thanks for the review!
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 0/9] omapdrm/omapfb/omapdss split
From: Tomi Valkeinen @ 2015-12-16 15:52 UTC (permalink / raw)
To: Dave Airlie; +Cc: linux-fbdev, Emil Velikov, dri-devel, Laurent Pinchart
In-Reply-To: <1449757535-5674-1-git-send-email-tomi.valkeinen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 20937 bytes --]
Hi Dave,
On 10/12/15 16:25, Tomi Valkeinen wrote:
> Hi,
>
> Here's an RFC series to fix the mess we have at the moment with
> omapdrm/omapfb/omapdss.
There hasn't been any NACKs for this series, so I'd like to get this in
for 4.5.
As it's mostly on the fbdev side, I can merge this via fbdev tree. Only
the two last patches are under drivers/gpu/ and it's unlikely they cause
any conflicts, as they mainly just move files from drivers/fbdev/ to
drivers/gpu/ (and they don't cause conflicts at the moment with my other
omapdrm patches, nor with current drm-next).
Can I get your ack on the two last patches?
Tomi
> First, a short background on the current status. We have the following
> entities:
>
> * omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
> display subsystem IPs used on OMAP (and related) SoCs. It offers only a
> kernel internal API, and does not implement anything for fbdev or drm.
>
> * omapdss panels and encoders, located in
> drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
> drivers, which use APIs offered by omapdss driver. These also don't implement
> anything for fbdev or drm.
>
> * omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
> uses omapdss and the panel/encoder drivers to operate the hardware.
>
> * omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
> driver, which uses omapdss and the panel/encoder drivers to operate the
> hardware.
>
> * omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
> which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
>
> So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
> those use the same low level drivers. Without going to the historical details
> why the architecture is like that, I think it's finally time to change that.
>
> The situation with omapfb+omap_vout is that it still works, but no new features
> have been added for a long time, and I want to keep it working as it's still
> being used. At some point in the future I'd like to remove omapfb and
> omap_vout altogether.
>
> Omapdrm, on the other hand, is being actively developed. Sharing the low level
> parts with omapfb makes that development more difficult than it should be. It
> also "hides" half of the development, as everything happening in the low level
> parts resides under fbdev directory, not in the drm directory.
>
> I've been wanting to clean this up for a long time, but I haven't figured out a
> very good way to do it. I still haven't, but here's the best way I have come up
> with.
>
> This series makes a full copy of the low level parts, omapdss and panel/encoder
> drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
> copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
> the current files moved. This way git will associate the omapdrm version with
> the old files.
>
> The omapfb+omap_vout versions won't be touched unless there are some big issues
> there.
>
> The omapdrm versions can be refactored and cleaned up, as the omapfb support
> code is no longer needed. We can perhaps also merge omapdss and omapdrm into
> the same kernel module.
>
> This series only does the copy, and the absolutely necessary parts. No further
> cleanups are done yet.
>
> Tomi
>
> Tomi Valkeinen (9):
> omapfb: allow compilation only if DRM_OMAP is disabled
> omapfb: copy omapdss & displays for omapfb
> omapdss: remove CONFIG_OMAP2_DSS_VENC from omapdss.h
> omapfb/dss: change CONFIG_OMAP* to CONFIG_FB_OMAP*
> omapfb/displays: change CONFIG_DISPLAY_* to CONFIG_FB_OMAP2_*
> omapfb: take omapfb's prive omapdss into use
> omapfb: move vrfb into omapfb
> drm/omap: move omapdss & displays under omapdrm
> drm/omap: make omapdrm select OMAP2_DSS
>
> drivers/gpu/drm/Makefile | 2 +-
> drivers/gpu/drm/omapdrm/Kconfig | 10 +-
> drivers/gpu/drm/omapdrm/Makefile | 3 +
> .../drm/omapdrm/displays}/Kconfig | 3 +-
> .../drm/omapdrm/displays}/Makefile | 0
> .../drm/omapdrm/displays}/connector-analog-tv.c | 0
> .../drm/omapdrm/displays}/connector-dvi.c | 0
> .../drm/omapdrm/displays}/connector-hdmi.c | 0
> .../drm/omapdrm/displays}/encoder-opa362.c | 0
> .../drm/omapdrm/displays}/encoder-tfp410.c | 0
> .../drm/omapdrm/displays}/encoder-tpd12s015.c | 0
> .../drm/omapdrm/displays}/panel-dpi.c | 0
> .../drm/omapdrm/displays}/panel-dsi-cm.c | 0
> .../omapdrm/displays}/panel-lgphilips-lb035q02.c | 0
> .../drm/omapdrm/displays}/panel-nec-nl8048hl11.c | 0
> .../omapdrm/displays}/panel-sharp-ls037v7dw01.c | 0
> .../drm/omapdrm/displays}/panel-sony-acx565akm.c | 0
> .../drm/omapdrm/displays}/panel-tpo-td028ttec1.c | 0
> .../drm/omapdrm/displays}/panel-tpo-td043mtea1.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/Kconfig | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/Makefile | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/apply.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/core.c | 0
> .../omap2 => gpu/drm/omapdrm}/dss/dispc-compat.c | 0
> .../omap2 => gpu/drm/omapdrm}/dss/dispc-compat.h | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/dispc.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/dispc.h | 0
> .../omap2 => gpu/drm/omapdrm}/dss/dispc_coefs.c | 0
> .../omap2 => gpu/drm/omapdrm}/dss/display-sysfs.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/display.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/dpi.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/dsi.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/dss-of.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/dss.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/dss.h | 0
> .../omap2 => gpu/drm/omapdrm}/dss/dss_features.c | 0
> .../omap2 => gpu/drm/omapdrm}/dss/dss_features.h | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi.h | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi4.c | 0
> .../omap2 => gpu/drm/omapdrm}/dss/hdmi4_core.c | 0
> .../omap2 => gpu/drm/omapdrm}/dss/hdmi4_core.h | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi5.c | 0
> .../omap2 => gpu/drm/omapdrm}/dss/hdmi5_core.c | 0
> .../omap2 => gpu/drm/omapdrm}/dss/hdmi5_core.h | 0
> .../omap2 => gpu/drm/omapdrm}/dss/hdmi_common.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi_phy.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi_pll.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi_wp.c | 0
> .../omap2 => gpu/drm/omapdrm}/dss/manager-sysfs.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/manager.c | 0
> .../drm/omapdrm}/dss/omapdss-boot-init.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/output.c | 0
> .../omap2 => gpu/drm/omapdrm}/dss/overlay-sysfs.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/overlay.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/pll.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/rfbi.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/sdi.c | 0
> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/venc.c | 0
> .../omap2 => gpu/drm/omapdrm}/dss/video-pll.c | 0
> drivers/media/platform/omap/Kconfig | 2 +-
> drivers/video/fbdev/omap2/Kconfig | 5 -
> drivers/video/fbdev/omap2/Makefile | 6 +-
> drivers/video/fbdev/omap2/omapfb/Kconfig | 14 +-
> drivers/video/fbdev/omap2/omapfb/Makefile | 3 +
> drivers/video/fbdev/omap2/omapfb/displays/Kconfig | 86 +
> drivers/video/fbdev/omap2/omapfb/displays/Makefile | 14 +
> .../omap2/omapfb/displays/connector-analog-tv.c | 320 ++
> .../fbdev/omap2/omapfb/displays/connector-dvi.c | 398 ++
> .../fbdev/omap2/omapfb/displays/connector-hdmi.c | 348 ++
> .../fbdev/omap2/omapfb/displays/encoder-opa362.c | 278 +
> .../fbdev/omap2/omapfb/displays/encoder-tfp410.c | 320 ++
> .../omap2/omapfb/displays/encoder-tpd12s015.c | 379 ++
> .../video/fbdev/omap2/omapfb/displays/panel-dpi.c | 330 ++
> .../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 1388 +++++
> .../omapfb/displays/panel-lgphilips-lb035q02.c | 404 ++
> .../omap2/omapfb/displays/panel-nec-nl8048hl11.c | 437 ++
> .../omapfb/displays/panel-sharp-ls037v7dw01.c | 415 ++
> .../omap2/omapfb/displays/panel-sony-acx565akm.c | 917 ++++
> .../omap2/omapfb/displays/panel-tpo-td028ttec1.c | 511 ++
> .../omap2/omapfb/displays/panel-tpo-td043mtea1.c | 686 +++
> drivers/video/fbdev/omap2/omapfb/dss/Kconfig | 129 +
> drivers/video/fbdev/omap2/omapfb/dss/Makefile | 18 +
> drivers/video/fbdev/omap2/omapfb/dss/apply.c | 1702 ++++++
> drivers/video/fbdev/omap2/omapfb/dss/core.c | 343 ++
> .../video/fbdev/omap2/omapfb/dss/dispc-compat.c | 667 +++
> .../video/fbdev/omap2/omapfb/dss/dispc-compat.h | 30 +
> drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 4135 +++++++++++++++
> drivers/video/fbdev/omap2/omapfb/dss/dispc.h | 916 ++++
> drivers/video/fbdev/omap2/omapfb/dss/dispc_coefs.c | 325 ++
> .../video/fbdev/omap2/omapfb/dss/display-sysfs.c | 356 ++
> drivers/video/fbdev/omap2/omapfb/dss/display.c | 338 ++
> drivers/video/fbdev/omap2/omapfb/dss/dpi.c | 899 ++++
> drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 5607 ++++++++++++++++++++
> drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 183 +
> drivers/video/fbdev/omap2/omapfb/dss/dss.c | 1323 +++++
> drivers/video/fbdev/omap2/omapfb/dss/dss.h | 472 ++
> .../video/fbdev/omap2/omapfb/dss/dss_features.c | 962 ++++
> .../video/fbdev/omap2/omapfb/dss/dss_features.h | 105 +
> drivers/video/fbdev/omap2/omapfb/dss/hdmi.h | 370 ++
> drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 839 +++
> drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c | 904 ++++
> drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.h | 273 +
> drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c | 876 +++
> drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 916 ++++
> drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.h | 304 ++
> drivers/video/fbdev/omap2/omapfb/dss/hdmi_common.c | 148 +
> drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c | 247 +
> drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c | 255 +
> drivers/video/fbdev/omap2/omapfb/dss/hdmi_wp.c | 282 +
> .../video/fbdev/omap2/omapfb/dss/manager-sysfs.c | 531 ++
> drivers/video/fbdev/omap2/omapfb/dss/manager.c | 263 +
> .../fbdev/omap2/omapfb/dss/omapdss-boot-init.c | 227 +
> drivers/video/fbdev/omap2/omapfb/dss/output.c | 267 +
> .../video/fbdev/omap2/omapfb/dss/overlay-sysfs.c | 456 ++
> drivers/video/fbdev/omap2/omapfb/dss/overlay.c | 202 +
> drivers/video/fbdev/omap2/omapfb/dss/pll.c | 389 ++
> drivers/video/fbdev/omap2/omapfb/dss/rfbi.c | 1078 ++++
> drivers/video/fbdev/omap2/omapfb/dss/sdi.c | 454 ++
> drivers/video/fbdev/omap2/omapfb/dss/venc.c | 997 ++++
> drivers/video/fbdev/omap2/omapfb/dss/video-pll.c | 211 +
> drivers/video/fbdev/omap2/{ => omapfb}/vrfb.c | 0
> include/video/omapdss.h | 2 -
> 122 files changed, 36260 insertions(+), 20 deletions(-)
> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/Kconfig (96%)
> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/Makefile (100%)
> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/connector-analog-tv.c (100%)
> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/connector-dvi.c (100%)
> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/connector-hdmi.c (100%)
> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/encoder-opa362.c (100%)
> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/encoder-tfp410.c (100%)
> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/encoder-tpd12s015.c (100%)
> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/panel-dpi.c (100%)
> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/panel-dsi-cm.c (100%)
> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/panel-lgphilips-lb035q02.c (100%)
> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/panel-nec-nl8048hl11.c (100%)
> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/panel-sharp-ls037v7dw01.c (100%)
> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/panel-sony-acx565akm.c (100%)
> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/panel-tpo-td028ttec1.c (100%)
> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/panel-tpo-td043mtea1.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/Kconfig (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/Makefile (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/apply.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/core.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dispc-compat.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dispc-compat.h (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dispc.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dispc.h (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dispc_coefs.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/display-sysfs.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/display.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dpi.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dsi.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dss-of.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dss.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dss.h (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dss_features.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dss_features.h (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi.h (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi4.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi4_core.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi4_core.h (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi5.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi5_core.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi5_core.h (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi_common.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi_phy.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi_pll.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi_wp.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/manager-sysfs.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/manager.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/omapdss-boot-init.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/output.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/overlay-sysfs.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/overlay.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/pll.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/rfbi.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/sdi.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/venc.c (100%)
> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/video-pll.c (100%)
> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/Kconfig
> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/Makefile
> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/Kconfig
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/Makefile
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/apply.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/core.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.h
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dispc.h
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dispc_coefs.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/display.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dpi.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dss.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dss.h
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dss_features.h
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi.h
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.h
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.h
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi_common.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi_wp.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/manager.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/output.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/overlay.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/pll.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/rfbi.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/sdi.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/venc.c
> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/video-pll.c
> rename drivers/video/fbdev/omap2/{ => omapfb}/vrfb.c (100%)
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] fbdev: omap2: panel-dpi: in .disable first disable backlight then display
From: Tomi Valkeinen @ 2015-12-16 17:16 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1449753107-11410-1-git-send-email-uwe@kleine-koenig.org>
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]
On 10/12/15 15:11, Uwe Kleine-König wrote:
> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>
> This makes .disable operate in reverse order compared to .enable.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index f7be3489f744..06b6e611e4b2 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -102,12 +102,12 @@ static void panel_dpi_disable(struct omap_dss_device *dssdev)
> if (!omapdss_device_is_enabled(dssdev))
> return;
>
> - if (ddata->enable_gpio)
> - gpiod_set_value_cansleep(ddata->enable_gpio, 0);
> -
> if (gpio_is_valid(ddata->backlight_gpio))
> gpio_set_value_cansleep(ddata->backlight_gpio, 0);
>
> + if (ddata->enable_gpio)
> + gpiod_set_value_cansleep(ddata->enable_gpio, 0);
> +
> in->ops.dpi->disable(in);
>
> dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
>
Thanks, queued for 4.5.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/5] fbdev: omap2: panel-dpi: simplify gpio setting
From: Tomi Valkeinen @ 2015-12-16 17:16 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1449753107-11410-2-git-send-email-uwe@kleine-koenig.org>
[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]
On 10/12/15 15:11, Uwe Kleine-König wrote:
> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>
> gpiod_set_value_cansleep is a noop when the passed descriptor is NULL.
> So there is no need to duplicate the check for NULL; just call the
> function unconditionally instead.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index 06b6e611e4b2..e780fd4f8b46 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -83,8 +83,7 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
> if (r)
> return r;
>
> - if (ddata->enable_gpio)
> - gpiod_set_value_cansleep(ddata->enable_gpio, 1);
> + gpiod_set_value_cansleep(ddata->enable_gpio, 1);
>
> if (gpio_is_valid(ddata->backlight_gpio))
> gpio_set_value_cansleep(ddata->backlight_gpio, 1);
> @@ -105,8 +104,7 @@ static void panel_dpi_disable(struct omap_dss_device *dssdev)
> if (gpio_is_valid(ddata->backlight_gpio))
> gpio_set_value_cansleep(ddata->backlight_gpio, 0);
>
> - if (ddata->enable_gpio)
> - gpiod_set_value_cansleep(ddata->enable_gpio, 0);
> + gpiod_set_value_cansleep(ddata->enable_gpio, 0);
>
> in->ops.dpi->disable(in);
>
>
Thanks, queued for 4.5.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] fbdev: omap2: panel-dpi: drop assignment to local variable
From: Tomi Valkeinen @ 2015-12-16 17:29 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1449753107-11410-3-git-send-email-uwe@kleine-koenig.org>
[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]
On 10/12/15 15:11, Uwe Kleine-König wrote:
> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>
> The variable gpio is only used to store the return value of
> devm_gpiod_get_optional just to assign it to a member of the driver
> data.
>
> Get rid of this local variable and assign to driver data directly.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index e780fd4f8b46..1216341a0d19 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -205,13 +205,11 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
> int r;
> struct display_timing timing;
> struct videomode vm;
> - struct gpio_desc *gpio;
>
> - gpio = devm_gpiod_get_optional(&pdev->dev, "enable", GPIOD_OUT_LOW);
> - if (IS_ERR(gpio))
> - return PTR_ERR(gpio);
> -
> - ddata->enable_gpio = gpio;
> + ddata->enable_gpio = devm_gpiod_get_optional(&pdev->dev,
> + "enable", GPIOD_OUT_LOW);
> + if (IS_ERR(ddata->enable_gpio))
> + return PTR_ERR(ddata->enable_gpio);
>
> ddata->backlight_gpio = -ENOENT;
I usually try to avoid writing bad values to fields. Here
ddata->enable_gpio may get an error ptr. It probably doesn't matter as
we bail out right away, but still. If devm_gpiod_get_optional's return
value would be NULL or valid gpio_desc*, then it'd be fine.
And the code is shorter (more readable) when using just "gpio" instead
of "ddata->enable_gpio".
So I'll leave this one out.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 4/5] fbdev: omap2: panel-dpi: allow specification of a reset gpio
From: Tomi Valkeinen @ 2015-12-16 17:35 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1449753107-11410-4-git-send-email-uwe@kleine-koenig.org>
[-- Attachment #1: Type: text/plain, Size: 2963 bytes --]
On 10/12/15 15:11, Uwe Kleine-König wrote:
> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>
> Some displays have a reset input. To assert that the display is
> functional the reset gpio must be deasserted.
>
> Teach the driver to get and drive such a gpio accordingly.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Documentation/devicetree/bindings/video/panel-dpi.txt | 1 +
> drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 7 +++++++
> 2 files changed, 8 insertions(+)
DT changes should be posted to devicetree@vger.kernel.org. And, I think,
the binding document changes are usually as a separate patch.
> diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt b/Documentation/devicetree/bindings/video/panel-dpi.txt
> index a40180b05bab..1a1d8f6f884f 100644
> --- a/Documentation/devicetree/bindings/video/panel-dpi.txt
> +++ b/Documentation/devicetree/bindings/video/panel-dpi.txt
> @@ -7,6 +7,7 @@ Required properties:
> Optional properties:
> - label: a symbolic name for the panel
> - enable-gpios: panel enable gpio
> +- reset-gpios: GPIO to control the RESET pin
>
> Required nodes:
> - "panel-timing" containing video timings
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index 1216341a0d19..7e2f9e0813dc 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -32,6 +32,7 @@ struct panel_drv_data {
> int backlight_gpio;
>
> struct gpio_desc *enable_gpio;
> + struct gpio_desc *reset_gpio;
> };
>
> #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
> @@ -83,6 +84,7 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
> if (r)
> return r;
>
> + gpiod_set_value_cansleep(ddata->reset_gpio, 0);
> gpiod_set_value_cansleep(ddata->enable_gpio, 1);
>
> if (gpio_is_valid(ddata->backlight_gpio))
> @@ -211,6 +213,11 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
> if (IS_ERR(ddata->enable_gpio))
> return PTR_ERR(ddata->enable_gpio);
>
> + ddata->reset_gpio = devm_gpiod_get_optional(&pdev->dev,
> + "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(ddata->reset_gpio))
> + return PTR_ERR(ddata->reset_gpio);
> +
> ddata->backlight_gpio = -ENOENT;
>
> r = of_get_display_timing(node, "panel-timing", &timing);
>
This looks a bit odd to me. This only ever sets the reset gpio to 0, on
panel enable. If we never toggle the reset, it could be set to 0 at
probe time, right?
Reset is a bit tricky. I've seen panels where you have to have only a
short reset pulse (reset high, wait a short time, reset low). If you
leave the reset high, the panel draws extra power.
So I think the best we can do in a generic way is just to ensure the
reset is not asserted.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] fbdev: omap2: panel-dpi: allow specification of a vcc regulator
From: Tomi Valkeinen @ 2015-12-16 17:38 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1449753107-11410-5-git-send-email-uwe@kleine-koenig.org>
[-- Attachment #1: Type: text/plain, Size: 3183 bytes --]
On 10/12/15 15:11, Uwe Kleine-König wrote:
> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>
> To allow supporting displays that need some logic to enable power to the
> display add support for a vcc-supply property to drive a regulator.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Documentation/devicetree/bindings/video/panel-dpi.txt | 1 +
> drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 13 +++++++++++++
> 2 files changed, 14 insertions(+)
Same comments here about the bindings.
> diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt b/Documentation/devicetree/bindings/video/panel-dpi.txt
> index 1a1d8f6f884f..eaa39d1b1279 100644
> --- a/Documentation/devicetree/bindings/video/panel-dpi.txt
> +++ b/Documentation/devicetree/bindings/video/panel-dpi.txt
> @@ -8,6 +8,7 @@ Optional properties:
> - label: a symbolic name for the panel
> - enable-gpios: panel enable gpio
> - reset-gpios: GPIO to control the RESET pin
> +- vcc-supply: phandle of regulator that will be used to enable power to the display
>
> Required nodes:
> - "panel-timing" containing video timings
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index 7e2f9e0813dc..65c6d9e6862b 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -15,6 +15,7 @@
> #include <linux/slab.h>
> #include <linux/of.h>
> #include <linux/of_gpio.h>
> +#include <linux/regulator/consumer.h>
>
> #include <video/omapdss.h>
> #include <video/omap-panel-data.h>
> @@ -33,6 +34,7 @@ struct panel_drv_data {
>
> struct gpio_desc *enable_gpio;
> struct gpio_desc *reset_gpio;
> + struct regulator *vcc_supply;
> };
>
> #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
> @@ -84,6 +86,12 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
> if (r)
> return r;
>
> + r = regulator_enable(ddata->vcc_supply);
> + if (r) {
> + in->ops.dpi->disable(in);
> + return r;
> + }
> +
> gpiod_set_value_cansleep(ddata->reset_gpio, 0);
> gpiod_set_value_cansleep(ddata->enable_gpio, 1);
>
> @@ -107,6 +115,7 @@ static void panel_dpi_disable(struct omap_dss_device *dssdev)
> gpio_set_value_cansleep(ddata->backlight_gpio, 0);
>
> gpiod_set_value_cansleep(ddata->enable_gpio, 0);
> + regulator_disable(ddata->vcc_supply);
>
> in->ops.dpi->disable(in);
>
> @@ -218,6 +227,10 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
> if (IS_ERR(ddata->reset_gpio))
> return PTR_ERR(ddata->reset_gpio);
>
> + ddata->vcc_supply = devm_regulator_get(&pdev->dev, "vcc");
> + if (IS_ERR(ddata->vcc_supply))
> + return PTR_ERR(ddata->vcc_supply);
> +
> ddata->backlight_gpio = -ENOENT;
>
> r = of_get_display_timing(node, "panel-timing", &timing);
Some panels might need to sleep before/after the regulator, but the same
goes for enable gpio. And we don't have a sane way to handle that at the
moment, so I think this is fine.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 0/9] omapdrm/omapfb/omapdss split
From: Rob Clark @ 2015-12-16 22:11 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Linux Fbdev development list, Emil Velikov,
dri-devel@lists.freedesktop.org, Laurent Pinchart
In-Reply-To: <567188D2.4020008@ti.com>
On Wed, Dec 16, 2015 at 10:52 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi Dave,
>
> On 10/12/15 16:25, Tomi Valkeinen wrote:
>> Hi,
>>
>> Here's an RFC series to fix the mess we have at the moment with
>> omapdrm/omapfb/omapdss.
>
> There hasn't been any NACKs for this series, so I'd like to get this in
> for 4.5.
I might suggest a short TODO/README type file explaining the current
state of flux and the plans going forward.. probably just copy/paste
the text from the cover letter.
other than that, if it's worth anything, you've got my a-b ;-)
BR,
-R
> As it's mostly on the fbdev side, I can merge this via fbdev tree. Only
> the two last patches are under drivers/gpu/ and it's unlikely they cause
> any conflicts, as they mainly just move files from drivers/fbdev/ to
> drivers/gpu/ (and they don't cause conflicts at the moment with my other
> omapdrm patches, nor with current drm-next).
>
> Can I get your ack on the two last patches?
>
> Tomi
>
>> First, a short background on the current status. We have the following
>> entities:
>>
>> * omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
>> display subsystem IPs used on OMAP (and related) SoCs. It offers only a
>> kernel internal API, and does not implement anything for fbdev or drm.
>>
>> * omapdss panels and encoders, located in
>> drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
>> drivers, which use APIs offered by omapdss driver. These also don't implement
>> anything for fbdev or drm.
>>
>> * omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
>> uses omapdss and the panel/encoder drivers to operate the hardware.
>>
>> * omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
>> driver, which uses omapdss and the panel/encoder drivers to operate the
>> hardware.
>>
>> * omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
>> which uses omapdss and omapfb to implement a v4l2 API for the video overlays.
>>
>> So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
>> those use the same low level drivers. Without going to the historical details
>> why the architecture is like that, I think it's finally time to change that.
>>
>> The situation with omapfb+omap_vout is that it still works, but no new features
>> have been added for a long time, and I want to keep it working as it's still
>> being used. At some point in the future I'd like to remove omapfb and
>> omap_vout altogether.
>>
>> Omapdrm, on the other hand, is being actively developed. Sharing the low level
>> parts with omapfb makes that development more difficult than it should be. It
>> also "hides" half of the development, as everything happening in the low level
>> parts resides under fbdev directory, not in the drm directory.
>>
>> I've been wanting to clean this up for a long time, but I haven't figured out a
>> very good way to do it. I still haven't, but here's the best way I have come up
>> with.
>>
>> This series makes a full copy of the low level parts, omapdss and panel/encoder
>> drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
>> copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
>> the current files moved. This way git will associate the omapdrm version with
>> the old files.
>>
>> The omapfb+omap_vout versions won't be touched unless there are some big issues
>> there.
>>
>> The omapdrm versions can be refactored and cleaned up, as the omapfb support
>> code is no longer needed. We can perhaps also merge omapdss and omapdrm into
>> the same kernel module.
>>
>> This series only does the copy, and the absolutely necessary parts. No further
>> cleanups are done yet.
>>
>> Tomi
>>
>> Tomi Valkeinen (9):
>> omapfb: allow compilation only if DRM_OMAP is disabled
>> omapfb: copy omapdss & displays for omapfb
>> omapdss: remove CONFIG_OMAP2_DSS_VENC from omapdss.h
>> omapfb/dss: change CONFIG_OMAP* to CONFIG_FB_OMAP*
>> omapfb/displays: change CONFIG_DISPLAY_* to CONFIG_FB_OMAP2_*
>> omapfb: take omapfb's prive omapdss into use
>> omapfb: move vrfb into omapfb
>> drm/omap: move omapdss & displays under omapdrm
>> drm/omap: make omapdrm select OMAP2_DSS
>>
>> drivers/gpu/drm/Makefile | 2 +-
>> drivers/gpu/drm/omapdrm/Kconfig | 10 +-
>> drivers/gpu/drm/omapdrm/Makefile | 3 +
>> .../drm/omapdrm/displays}/Kconfig | 3 +-
>> .../drm/omapdrm/displays}/Makefile | 0
>> .../drm/omapdrm/displays}/connector-analog-tv.c | 0
>> .../drm/omapdrm/displays}/connector-dvi.c | 0
>> .../drm/omapdrm/displays}/connector-hdmi.c | 0
>> .../drm/omapdrm/displays}/encoder-opa362.c | 0
>> .../drm/omapdrm/displays}/encoder-tfp410.c | 0
>> .../drm/omapdrm/displays}/encoder-tpd12s015.c | 0
>> .../drm/omapdrm/displays}/panel-dpi.c | 0
>> .../drm/omapdrm/displays}/panel-dsi-cm.c | 0
>> .../omapdrm/displays}/panel-lgphilips-lb035q02.c | 0
>> .../drm/omapdrm/displays}/panel-nec-nl8048hl11.c | 0
>> .../omapdrm/displays}/panel-sharp-ls037v7dw01.c | 0
>> .../drm/omapdrm/displays}/panel-sony-acx565akm.c | 0
>> .../drm/omapdrm/displays}/panel-tpo-td028ttec1.c | 0
>> .../drm/omapdrm/displays}/panel-tpo-td043mtea1.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/Kconfig | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/Makefile | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/apply.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/core.c | 0
>> .../omap2 => gpu/drm/omapdrm}/dss/dispc-compat.c | 0
>> .../omap2 => gpu/drm/omapdrm}/dss/dispc-compat.h | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/dispc.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/dispc.h | 0
>> .../omap2 => gpu/drm/omapdrm}/dss/dispc_coefs.c | 0
>> .../omap2 => gpu/drm/omapdrm}/dss/display-sysfs.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/display.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/dpi.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/dsi.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/dss-of.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/dss.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/dss.h | 0
>> .../omap2 => gpu/drm/omapdrm}/dss/dss_features.c | 0
>> .../omap2 => gpu/drm/omapdrm}/dss/dss_features.h | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi.h | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi4.c | 0
>> .../omap2 => gpu/drm/omapdrm}/dss/hdmi4_core.c | 0
>> .../omap2 => gpu/drm/omapdrm}/dss/hdmi4_core.h | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi5.c | 0
>> .../omap2 => gpu/drm/omapdrm}/dss/hdmi5_core.c | 0
>> .../omap2 => gpu/drm/omapdrm}/dss/hdmi5_core.h | 0
>> .../omap2 => gpu/drm/omapdrm}/dss/hdmi_common.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi_phy.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi_pll.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi_wp.c | 0
>> .../omap2 => gpu/drm/omapdrm}/dss/manager-sysfs.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/manager.c | 0
>> .../drm/omapdrm}/dss/omapdss-boot-init.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/output.c | 0
>> .../omap2 => gpu/drm/omapdrm}/dss/overlay-sysfs.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/overlay.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/pll.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/rfbi.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/sdi.c | 0
>> .../fbdev/omap2 => gpu/drm/omapdrm}/dss/venc.c | 0
>> .../omap2 => gpu/drm/omapdrm}/dss/video-pll.c | 0
>> drivers/media/platform/omap/Kconfig | 2 +-
>> drivers/video/fbdev/omap2/Kconfig | 5 -
>> drivers/video/fbdev/omap2/Makefile | 6 +-
>> drivers/video/fbdev/omap2/omapfb/Kconfig | 14 +-
>> drivers/video/fbdev/omap2/omapfb/Makefile | 3 +
>> drivers/video/fbdev/omap2/omapfb/displays/Kconfig | 86 +
>> drivers/video/fbdev/omap2/omapfb/displays/Makefile | 14 +
>> .../omap2/omapfb/displays/connector-analog-tv.c | 320 ++
>> .../fbdev/omap2/omapfb/displays/connector-dvi.c | 398 ++
>> .../fbdev/omap2/omapfb/displays/connector-hdmi.c | 348 ++
>> .../fbdev/omap2/omapfb/displays/encoder-opa362.c | 278 +
>> .../fbdev/omap2/omapfb/displays/encoder-tfp410.c | 320 ++
>> .../omap2/omapfb/displays/encoder-tpd12s015.c | 379 ++
>> .../video/fbdev/omap2/omapfb/displays/panel-dpi.c | 330 ++
>> .../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 1388 +++++
>> .../omapfb/displays/panel-lgphilips-lb035q02.c | 404 ++
>> .../omap2/omapfb/displays/panel-nec-nl8048hl11.c | 437 ++
>> .../omapfb/displays/panel-sharp-ls037v7dw01.c | 415 ++
>> .../omap2/omapfb/displays/panel-sony-acx565akm.c | 917 ++++
>> .../omap2/omapfb/displays/panel-tpo-td028ttec1.c | 511 ++
>> .../omap2/omapfb/displays/panel-tpo-td043mtea1.c | 686 +++
>> drivers/video/fbdev/omap2/omapfb/dss/Kconfig | 129 +
>> drivers/video/fbdev/omap2/omapfb/dss/Makefile | 18 +
>> drivers/video/fbdev/omap2/omapfb/dss/apply.c | 1702 ++++++
>> drivers/video/fbdev/omap2/omapfb/dss/core.c | 343 ++
>> .../video/fbdev/omap2/omapfb/dss/dispc-compat.c | 667 +++
>> .../video/fbdev/omap2/omapfb/dss/dispc-compat.h | 30 +
>> drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 4135 +++++++++++++++
>> drivers/video/fbdev/omap2/omapfb/dss/dispc.h | 916 ++++
>> drivers/video/fbdev/omap2/omapfb/dss/dispc_coefs.c | 325 ++
>> .../video/fbdev/omap2/omapfb/dss/display-sysfs.c | 356 ++
>> drivers/video/fbdev/omap2/omapfb/dss/display.c | 338 ++
>> drivers/video/fbdev/omap2/omapfb/dss/dpi.c | 899 ++++
>> drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 5607 ++++++++++++++++++++
>> drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 183 +
>> drivers/video/fbdev/omap2/omapfb/dss/dss.c | 1323 +++++
>> drivers/video/fbdev/omap2/omapfb/dss/dss.h | 472 ++
>> .../video/fbdev/omap2/omapfb/dss/dss_features.c | 962 ++++
>> .../video/fbdev/omap2/omapfb/dss/dss_features.h | 105 +
>> drivers/video/fbdev/omap2/omapfb/dss/hdmi.h | 370 ++
>> drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 839 +++
>> drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c | 904 ++++
>> drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.h | 273 +
>> drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c | 876 +++
>> drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 916 ++++
>> drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.h | 304 ++
>> drivers/video/fbdev/omap2/omapfb/dss/hdmi_common.c | 148 +
>> drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c | 247 +
>> drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c | 255 +
>> drivers/video/fbdev/omap2/omapfb/dss/hdmi_wp.c | 282 +
>> .../video/fbdev/omap2/omapfb/dss/manager-sysfs.c | 531 ++
>> drivers/video/fbdev/omap2/omapfb/dss/manager.c | 263 +
>> .../fbdev/omap2/omapfb/dss/omapdss-boot-init.c | 227 +
>> drivers/video/fbdev/omap2/omapfb/dss/output.c | 267 +
>> .../video/fbdev/omap2/omapfb/dss/overlay-sysfs.c | 456 ++
>> drivers/video/fbdev/omap2/omapfb/dss/overlay.c | 202 +
>> drivers/video/fbdev/omap2/omapfb/dss/pll.c | 389 ++
>> drivers/video/fbdev/omap2/omapfb/dss/rfbi.c | 1078 ++++
>> drivers/video/fbdev/omap2/omapfb/dss/sdi.c | 454 ++
>> drivers/video/fbdev/omap2/omapfb/dss/venc.c | 997 ++++
>> drivers/video/fbdev/omap2/omapfb/dss/video-pll.c | 211 +
>> drivers/video/fbdev/omap2/{ => omapfb}/vrfb.c | 0
>> include/video/omapdss.h | 2 -
>> 122 files changed, 36260 insertions(+), 20 deletions(-)
>> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/Kconfig (96%)
>> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/Makefile (100%)
>> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/connector-analog-tv.c (100%)
>> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/connector-dvi.c (100%)
>> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/connector-hdmi.c (100%)
>> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/encoder-opa362.c (100%)
>> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/encoder-tfp410.c (100%)
>> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/encoder-tpd12s015.c (100%)
>> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/panel-dpi.c (100%)
>> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/panel-dsi-cm.c (100%)
>> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/panel-lgphilips-lb035q02.c (100%)
>> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/panel-nec-nl8048hl11.c (100%)
>> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/panel-sharp-ls037v7dw01.c (100%)
>> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/panel-sony-acx565akm.c (100%)
>> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/panel-tpo-td028ttec1.c (100%)
>> rename drivers/{video/fbdev/omap2/displays-new => gpu/drm/omapdrm/displays}/panel-tpo-td043mtea1.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/Kconfig (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/Makefile (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/apply.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/core.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dispc-compat.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dispc-compat.h (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dispc.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dispc.h (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dispc_coefs.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/display-sysfs.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/display.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dpi.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dsi.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dss-of.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dss.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dss.h (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dss_features.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/dss_features.h (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi.h (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi4.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi4_core.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi4_core.h (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi5.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi5_core.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi5_core.h (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi_common.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi_phy.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi_pll.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/hdmi_wp.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/manager-sysfs.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/manager.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/omapdss-boot-init.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/output.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/overlay-sysfs.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/overlay.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/pll.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/rfbi.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/sdi.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/venc.c (100%)
>> rename drivers/{video/fbdev/omap2 => gpu/drm/omapdrm}/dss/video-pll.c (100%)
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/Kconfig
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/Makefile
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/Kconfig
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/Makefile
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/apply.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/core.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.h
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dispc.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dispc.h
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dispc_coefs.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/display.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dpi.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dsi.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dss.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dss.h
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dss_features.h
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi.h
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.h
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.h
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi_common.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi_wp.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/manager.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/output.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/overlay.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/pll.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/rfbi.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/sdi.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/venc.c
>> create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/video-pll.c
>> rename drivers/video/fbdev/omap2/{ => omapfb}/vrfb.c (100%)
>>
>
^ permalink raw reply
* Re: [PATCH RFC 0/9] omapdrm/omapfb/omapdss split
From: Dave Airlie @ 2015-12-17 0:22 UTC (permalink / raw)
To: Rob Clark
Cc: Linux Fbdev development list, Tomi Valkeinen, Emil Velikov,
Laurent Pinchart, dri-devel@lists.freedesktop.org
In-Reply-To: <CAF6AEGs0WNmt+LBQXP0EcTU+x3yQDYJ-oRcQ_hMMmG9hnnH6hQ@mail.gmail.com>
On 17 December 2015 at 08:11, Rob Clark <robdclark@gmail.com> wrote:
> On Wed, Dec 16, 2015 at 10:52 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> Hi Dave,
>>
>> On 10/12/15 16:25, Tomi Valkeinen wrote:
>>> Hi,
>>>
>>> Here's an RFC series to fix the mess we have at the moment with
>>> omapdrm/omapfb/omapdss.
>>
>> There hasn't been any NACKs for this series, so I'd like to get this in
>> for 4.5.
>
> I might suggest a short TODO/README type file explaining the current
> state of flux and the plans going forward.. probably just copy/paste
> the text from the cover letter.
>
> other than that, if it's worth anything, you've got my a-b ;-)\
Ack from me on whatever you need to make this happen in the other tree!.
Dave.
^ permalink raw reply
* Re: [PATCH] backlight: gpio-backlight: use default-on on GPIO request
From: Stefan Agner @ 2015-12-17 5:08 UTC (permalink / raw)
To: jingoohan1, lee.jones; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <1445643883-30726-1-git-send-email-stefan@agner.ch>
Hi,
Any comment on this? I still think it is a valuable change...
--
Stefan
On 2015-10-23 16:44, Stefan Agner wrote:
> There are situations where the backlight should be on at boot time
> (e.g. if the boot loader already turned the display on). The DT
> bindings specify the "default-on" property for that purpose.
> Currently, the initial state of the GPIO at request time is always
> set to logical off (high or low depending on whether it is an
> active high or low GPIO). Since the GPIO is requested as an output,
> the GPIO will be driven low for a short period of time, which leads
> to a flickering display in the above use-case.
>
> Initialize the GPIO depending on the default-on property to be
> logical on or off.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
> drivers/video/backlight/gpio_backlight.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/backlight/gpio_backlight.c
> b/drivers/video/backlight/gpio_backlight.c
> index 5fbbc2e..1813441 100644
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -89,6 +89,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
> struct backlight_device *bl;
> struct gpio_backlight *gbl;
> struct device_node *np = pdev->dev.of_node;
> + unsigned long flags = GPIOF_DIR_OUT;
> int ret;
>
> if (!pdata && !np) {
> @@ -114,9 +115,12 @@ static int gpio_backlight_probe(struct
> platform_device *pdev)
> gbl->def_value = pdata->def_value;
> }
>
> - ret = devm_gpio_request_one(gbl->dev, gbl->gpio, GPIOF_DIR_OUT |
> - (gbl->active ? GPIOF_INIT_LOW
> - : GPIOF_INIT_HIGH),
> + if (gbl->active)
> + flags |= gbl->def_value ? GPIOF_INIT_HIGH : GPIOF_INIT_LOW;
> + else
> + flags |= gbl->def_value ? GPIOF_INIT_LOW : GPIOF_INIT_HIGH;
> +
> + ret = devm_gpio_request_one(gbl->dev, gbl->gpio, flags,
> pdata ? pdata->name : "backlight");
> if (ret < 0) {
> dev_err(&pdev->dev, "unable to request GPIO\n");
^ permalink raw reply
* Re: [PATCH v6 1/2] video: fbdev: pxafb: loosen the platform data bond
From: Robert Jarzmik @ 2015-12-18 20:41 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-kernel
In-Reply-To: <56701430.9050100@ti.com>
Tomi Valkeinen <tomi.valkeinen@ti.com> writes:
> On 12/12/15 23:27, Robert Jarzmik wrote:
>> In order to prepare the transition to a mixed platform data and
>> device-tree initialization, remove all the platform data references all
>> over the driver.
>>
>> Copy the platform data into the internal structure of the pxafb, and
>> only use this afterward.
>>
>> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
>> ---
>> drivers/video/fbdev/pxafb.c | 54 ++++++++++++++++++++++++++++-----------------
>> drivers/video/fbdev/pxafb.h | 2 ++
>> 2 files changed, 36 insertions(+), 20 deletions(-)
>
> Thanks, I've queued this and the second patch for 4.5.
Excellent, thank you.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH] video: fbdev: pxafb: fix out of memory error path
From: Robert Jarzmik @ 2015-12-19 12:14 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: linux-fbdev, linux-kernel, Julia Lawall, Robert Jarzmik
As seen by Julia, the initial allocation memory is not checked anymore
after commit "video: fbdev: pxafb: initial devicetree conversion".
Introduce back the removed test.
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
drivers/video/fbdev/pxafb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index 8588dd683105..54666424a720 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -2252,6 +2252,8 @@ static int pxafb_probe(struct platform_device *dev)
ret = -ENOMEM;
pdata = dev_get_platdata(&dev->dev);
inf = devm_kmalloc(&dev->dev, sizeof(*inf), GFP_KERNEL);
+ if (!inf)
+ goto failed;
if (pdata) {
*inf = *pdata;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 5/5] fbdev: omap2: panel-dpi: allow specification of a vcc regulator
From: Adam Ford @ 2015-12-19 20:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1449753107-11410-5-git-send-email-uwe@kleine-koenig.org>
Tomi,
Do you have any thought on how to approach adding sleep/delay
functions? I have a display that requires a small delay before and
after the enable gpio toggle. I assume that some may require a delay
after the regulator starts for it to be be ready. For now I have a
temp hack that just inserts a blanket 300mS wait, but I'd rather have
something mainstreamed in the device tree, but I don't want to walk
over someone else's work either.
I'd love to help if you have an idea of how you vision it.
adam
On Wed, Dec 16, 2015 at 11:38 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>
> On 10/12/15 15:11, Uwe Kleine-König wrote:
>> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>>
>> To allow supporting displays that need some logic to enable power to the
>> display add support for a vcc-supply property to drive a regulator.
>>
>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>> ---
>> Documentation/devicetree/bindings/video/panel-dpi.txt | 1 +
>> drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 13 +++++++++++++
>> 2 files changed, 14 insertions(+)
>
> Same comments here about the bindings.
>
>> diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt b/Documentation/devicetree/bindings/video/panel-dpi.txt
>> index 1a1d8f6f884f..eaa39d1b1279 100644
>> --- a/Documentation/devicetree/bindings/video/panel-dpi.txt
>> +++ b/Documentation/devicetree/bindings/video/panel-dpi.txt
>> @@ -8,6 +8,7 @@ Optional properties:
>> - label: a symbolic name for the panel
>> - enable-gpios: panel enable gpio
>> - reset-gpios: GPIO to control the RESET pin
>> +- vcc-supply: phandle of regulator that will be used to enable power to the display
>>
>> Required nodes:
>> - "panel-timing" containing video timings
>> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
>> index 7e2f9e0813dc..65c6d9e6862b 100644
>> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
>> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
>> @@ -15,6 +15,7 @@
>> #include <linux/slab.h>
>> #include <linux/of.h>
>> #include <linux/of_gpio.h>
>> +#include <linux/regulator/consumer.h>
>>
>> #include <video/omapdss.h>
>> #include <video/omap-panel-data.h>
>> @@ -33,6 +34,7 @@ struct panel_drv_data {
>>
>> struct gpio_desc *enable_gpio;
>> struct gpio_desc *reset_gpio;
>> + struct regulator *vcc_supply;
>> };
>>
>> #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
>> @@ -84,6 +86,12 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
>> if (r)
>> return r;
>>
>> + r = regulator_enable(ddata->vcc_supply);
>> + if (r) {
>> + in->ops.dpi->disable(in);
>> + return r;
>> + }
>> +
>> gpiod_set_value_cansleep(ddata->reset_gpio, 0);
>> gpiod_set_value_cansleep(ddata->enable_gpio, 1);
>>
>> @@ -107,6 +115,7 @@ static void panel_dpi_disable(struct omap_dss_device *dssdev)
>> gpio_set_value_cansleep(ddata->backlight_gpio, 0);
>>
>> gpiod_set_value_cansleep(ddata->enable_gpio, 0);
>> + regulator_disable(ddata->vcc_supply);
>>
>> in->ops.dpi->disable(in);
>>
>> @@ -218,6 +227,10 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
>> if (IS_ERR(ddata->reset_gpio))
>> return PTR_ERR(ddata->reset_gpio);
>>
>> + ddata->vcc_supply = devm_regulator_get(&pdev->dev, "vcc");
>> + if (IS_ERR(ddata->vcc_supply))
>> + return PTR_ERR(ddata->vcc_supply);
>> +
>> ddata->backlight_gpio = -ENOENT;
>>
>> r = of_get_display_timing(node, "panel-timing", &timing);
>
> Some panels might need to sleep before/after the regulator, but the same
> goes for enable gpio. And we don't have a sane way to handle that at the
> moment, so I think this is fine.
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH 3/5] fbdev: omap2: panel-dpi: drop assignment to local variable
From: Uwe Kleine-König @ 2015-12-20 10:31 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1449753107-11410-3-git-send-email-uwe@kleine-koenig.org>
Hello,
On Wed, Dec 16, 2015 at 07:29:17PM +0200, Tomi Valkeinen wrote:
> On 10/12/15 15:11, Uwe Kleine-König wrote:
> > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> >
> > The variable gpio is only used to store the return value of
> > devm_gpiod_get_optional just to assign it to a member of the driver
> > data.
> >
> > Get rid of this local variable and assign to driver data directly.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> > drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 10 ++++------
> > 1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> > index e780fd4f8b46..1216341a0d19 100644
> > --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> > +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> > @@ -205,13 +205,11 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
> > int r;
> > struct display_timing timing;
> > struct videomode vm;
> > - struct gpio_desc *gpio;
> >
> > - gpio = devm_gpiod_get_optional(&pdev->dev, "enable", GPIOD_OUT_LOW);
> > - if (IS_ERR(gpio))
> > - return PTR_ERR(gpio);
> > -
> > - ddata->enable_gpio = gpio;
> > + ddata->enable_gpio = devm_gpiod_get_optional(&pdev->dev,
> > + "enable", GPIOD_OUT_LOW);
> > + if (IS_ERR(ddata->enable_gpio))
> > + return PTR_ERR(ddata->enable_gpio);
> >
> > ddata->backlight_gpio = -ENOENT;
>
> I usually try to avoid writing bad values to fields. Here
> ddata->enable_gpio may get an error ptr. It probably doesn't matter as
> we bail out right away, but still. If devm_gpiod_get_optional's return
> value would be NULL or valid gpio_desc*, then it'd be fine.
this is probably a matter of taste but still I don't see why people
don't like writing to structs immediately.
With the local variable you might have
gpio = -ESOMETHING
and
ddata->enable_gpio = NULL;
In the case that the error is handled correctly it doesn't matter if the
value was written to the struct or not (if you accept a little
performance penalty for writing the value actually to memory maybe). So
the motivation is the consideration that the error might not be handled
correctly after a later patch, right? But when ddata->enable_gpio is a
negative error code this probably results in a crash already during
development of the faulty patch, while when the struct's member isn't
assigned it probably doesn't.
This convinces me that writing to the struct is actually a good thing.
Additionally even though the line length of
gpio = devm_gpiod_get_optional(&pdev->dev, "enable", GPIOD_OUT_LOW);
if (IS_ERR(gpio))
return PTR_ERR(gpio);
ddata->enable_gpio = gpio;
is shorter (which is good), with my approach of doing:
ddata->enable_gpio = devm_gpiod_get_optional(&pdev->dev,
"enable", GPIOD_OUT_LOW);
if (IS_ERR(ddata->enable_gpio))
return PTR_ERR(ddata->enable_gpio);
apart from saving an assignment also "enable_gpio" and "enable" are
nearer to each other which IMHO makes it easier to see that the
assignment is correct which outweighs the longer lines. This argument
even gets more important when reset_gpio is added in patch 4 when the
situation looks as follows:
gpio = devm_gpiod_get_optional(... "enable" ...);
if (IS_ERR(gpio))
...
ddata->enable_gpio = gpio;
gpio = devm_gpiod_get_optional(... "reset" ...);
if (IS_ERR(gpio))
...
ddata->reset_gpio = gpio;
vs.
ddata->enable_gpio = devm_gpiod_get_optional(... "enable" ...);
if (IS_ERR(ddata->enable_gpio))
...
ddata->reset_gpio = devm_gpiod_get_optional(... "reset" ...);
if (IS_ERR(ddata->reset_gpio))
...
I like my approach better, but if you don't agree, I don't care enough
to argue (more).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 4/5] fbdev: omap2: panel-dpi: allow specification of a reset gpio
From: Uwe Kleine-König @ 2015-12-20 10:33 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Uwe Kleine-König, Jean-Christophe Plagniol-Villard,
linux-omap-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5671A0E2.7000909-l0cyMroinI0@public.gmane.org>
[Cc += devicetree@vger.kernel.org]
Hello Tomi,
On Wed, Dec 16, 2015 at 07:35:30PM +0200, Tomi Valkeinen wrote:
>
> On 10/12/15 15:11, Uwe Kleine-König wrote:
> > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> >
> > Some displays have a reset input. To assert that the display is
> > functional the reset gpio must be deasserted.
> >
> > Teach the driver to get and drive such a gpio accordingly.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> > Documentation/devicetree/bindings/video/panel-dpi.txt | 1 +
> > drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 7 +++++++
> > 2 files changed, 8 insertions(+)
>
> DT changes should be posted to devicetree@vger.kernel.org. And, I think,
> the binding document changes are usually as a separate patch.
Right for devicetree@vger.kernel.org, but separate patches for bindings
is news to me. Anyhow, I can split this off if you prefer.
> > diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt b/Documentation/devicetree/bindings/video/panel-dpi.txt
> > index a40180b05bab..1a1d8f6f884f 100644
> > --- a/Documentation/devicetree/bindings/video/panel-dpi.txt
> > +++ b/Documentation/devicetree/bindings/video/panel-dpi.txt
> > @@ -7,6 +7,7 @@ Required properties:
> > Optional properties:
> > - label: a symbolic name for the panel
> > - enable-gpios: panel enable gpio
> > +- reset-gpios: GPIO to control the RESET pin
> >
> > Required nodes:
> > - "panel-timing" containing video timings
> > diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> > index 1216341a0d19..7e2f9e0813dc 100644
> > --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> > +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> > @@ -32,6 +32,7 @@ struct panel_drv_data {
> > int backlight_gpio;
> >
> > struct gpio_desc *enable_gpio;
> > + struct gpio_desc *reset_gpio;
> > };
> >
> > #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
> > @@ -83,6 +84,7 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
> > if (r)
> > return r;
> >
> > + gpiod_set_value_cansleep(ddata->reset_gpio, 0);
> > gpiod_set_value_cansleep(ddata->enable_gpio, 1);
> >
> > if (gpio_is_valid(ddata->backlight_gpio))
> > @@ -211,6 +213,11 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
> > if (IS_ERR(ddata->enable_gpio))
> > return PTR_ERR(ddata->enable_gpio);
> >
> > + ddata->reset_gpio = devm_gpiod_get_optional(&pdev->dev,
> > + "reset", GPIOD_OUT_HIGH);
> > + if (IS_ERR(ddata->reset_gpio))
> > + return PTR_ERR(ddata->reset_gpio);
> > +
> > ddata->backlight_gpio = -ENOENT;
> >
> > r = of_get_display_timing(node, "panel-timing", &timing);
> >
>
> This looks a bit odd to me. This only ever sets the reset gpio to 0, on
> panel enable. If we never toggle the reset, it could be set to 0 at
> probe time, right?
>
> Reset is a bit tricky. I've seen panels where you have to have only a
> short reset pulse (reset high, wait a short time, reset low). If you
> leave the reset high, the panel draws extra power.
>
> So I think the best we can do in a generic way is just to ensure the
> reset is not asserted.
Good idea, will implement this in v2.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 0/3] fbdev: omap2: panel-dpi: support reset-gpios and vcc regulator
From: Uwe Kleine-König @ 2015-12-20 11:13 UTC (permalink / raw)
To: linux-fbdev
Hello,
these patches are what is remaining from my previous series sent
starting with
Message-Id: 1449753107-11410-1-git-send-email-uwe@kleine-koenig.org .
I split out the changes to
Documentation/devicetree/bindings/video/panel-dpi.txt in a (single)
separate patch. Also I changed the behaviour of the reset gpio to never
assert it because there are too many different needs.
Have fun
Uwe
Uwe Kleine-König (3):
devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi
fbdev: omap2: panel-dpi: make (limited) use of a reset gpio
fbdev: omap2: panel-dpi: implement support for a vcc regulator
.../bindings/display/panel/panel-dpi.txt | 2 ++
drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 23 ++++++++++++++++++++++
2 files changed, 25 insertions(+)
--
2.6.2
^ permalink raw reply
* [PATCH v2 1/3] devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi
From: Uwe Kleine-König @ 2015-12-20 11:13 UTC (permalink / raw)
To: Tomi Valkeinen, Jean-Christophe Plagniol-Villard
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1450610002-10531-1-git-send-email-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Some displays have a reset input and/or need a regulator to function
properly. Allow to specify them for panel-dpi devices.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
index 216c894d4f99..b52ac52757df 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
+++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
@@ -7,6 +7,8 @@ Required properties:
Optional properties:
- label: a symbolic name for the panel
- enable-gpios: panel enable gpio
+- reset-gpios: GPIO to control the RESET pin
+- vcc-supply: phandle of regulator that will be used to enable power to the display
Required nodes:
- "panel-timing" containing video timings
--
2.6.2
^ permalink raw reply related
* [PATCH v2 2/3] fbdev: omap2: panel-dpi: make (limited) use of a reset gpio
From: Uwe Kleine-König @ 2015-12-20 11:13 UTC (permalink / raw)
To: linux-fbdev
Some displays have a reset input. To assert that the display is
functional the reset gpio must be deasserted.
Teach the driver to get and drive such a gpio accordingly.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
--
Changes since (implicit) v1, sent with
Message-Id: 1449753107-11410-4-git-send-email-uwe@kleine-koenig.org :
- never assert reset because there are too many different panels with
too many different needs for their reset.
- split out dt binding changes
- reword commit log
---
drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
index e780fd4f8b46..201a1c1a6f42 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
@@ -213,6 +213,16 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
ddata->enable_gpio = gpio;
+ /*
+ * Many different panels are supported by this driver and there are
+ * probably very different needs for their reset pins in regards to
+ * timing and order relative to the enable gpio. So for now it's just
+ * ensured that the reset line isn't active.
+ */
+ gpio = devm_gpiod_get_optional(&pdev->dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(gpio))
+ return PTR_ERR(gpio);
+
ddata->backlight_gpio = -ENOENT;
r = of_get_display_timing(node, "panel-timing", &timing);
--
2.6.2
^ permalink raw reply related
* [PATCH v2 3/3] fbdev: omap2: panel-dpi: implement support for a vcc regulator
From: Uwe Kleine-König @ 2015-12-20 11:13 UTC (permalink / raw)
To: linux-fbdev
To allow supporting displays that need some logic to enable power to the
display try to get a vcc-supply property from the device tree and drive
the resulting regulator accordingly.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Changes since (implicit) v1, sent with
Message-Id: 1449753107-11410-5-git-send-email-uwe@kleine-koenig.org:
- split out dt binding changes
- reword commit log
---
drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
index 201a1c1a6f42..8c3f31ebff00 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
@@ -15,6 +15,7 @@
#include <linux/slab.h>
#include <linux/of.h>
#include <linux/of_gpio.h>
+#include <linux/regulator/consumer.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
@@ -32,6 +33,7 @@ struct panel_drv_data {
int backlight_gpio;
struct gpio_desc *enable_gpio;
+ struct regulator *vcc_supply;
};
#define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
@@ -83,6 +85,12 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
if (r)
return r;
+ r = regulator_enable(ddata->vcc_supply);
+ if (r) {
+ in->ops.dpi->disable(in);
+ return r;
+ }
+
gpiod_set_value_cansleep(ddata->enable_gpio, 1);
if (gpio_is_valid(ddata->backlight_gpio))
@@ -105,6 +113,7 @@ static void panel_dpi_disable(struct omap_dss_device *dssdev)
gpio_set_value_cansleep(ddata->backlight_gpio, 0);
gpiod_set_value_cansleep(ddata->enable_gpio, 0);
+ regulator_disable(ddata->vcc_supply);
in->ops.dpi->disable(in);
@@ -223,6 +232,10 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
if (IS_ERR(gpio))
return PTR_ERR(gpio);
+ ddata->vcc_supply = devm_regulator_get(&pdev->dev, "vcc");
+ if (IS_ERR(ddata->vcc_supply))
+ return PTR_ERR(ddata->vcc_supply);
+
ddata->backlight_gpio = -ENOENT;
r = of_get_display_timing(node, "panel-timing", &timing);
--
2.6.2
^ permalink raw reply related
* [PATCH] OMAPDSS: fix omapfb build error due missing feat functions declaration
From: Javier Martinez Canillas @ 2015-12-21 18:26 UTC (permalink / raw)
To: linux-kernel, Tomi Valkeinen
Cc: Tony Lindgren, Javier Martinez Canillas, linux-fbdev, Dave Airlie,
Jean-Christophe Plagniol-Villard, Rob Clark, linux-omap
The omapfb is failing to build in -next due missing declarations for
dss_feat_get_supported_displays() and dss_feat_get_supported_outputs():
CC [M] drivers/video/fbdev/omap2//omapfb/dss/dss.o
drivers/video/fbdev/omap2//omapfb/dss/dss.c: In function 'dss_save_context':
drivers/video/fbdev/omap2//omapfb/dss/dss.c:144:2: error: implicit declaration of function 'dss_feat_get_supported_displays' [-Werror=implicit-function-declaration]
Add the declaration for these functions in the dss_features.h header
file to fix this compile error.
Also, remove the functions export since are not used outside the driver.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Hello Tomi,
This seems to be caused by a wrong order in which some commits from
the omapdss tree [0] were merged, or rather a wrong base used for
the dss-drm-merge (4.4.0-rc4) and the for-next (4.4.0-rc5) branches.
The problem is that commit 2ea164a9af9c ("drm/omap: move omapdss &
displays under omapdrm") moves the dss_features.h header from the
drivers/video/fbdev/omap2/dss/ dir to drivers/gpu/drm/omapdrm}/dss.
And then commit 8b987a111b1a ("omapfb: copy omapdss & displays for
omapfb" copies the hader from the omapdrm dir to the omapfb one.
Now, since commit 66c78ddd7a2e ("OMAPDSS: make a two dss feat funcs
internal to omapdss") is the one that moves the function declaration
from the public include/video/omapdss.h header to the internal one,
this means that git will be smart enough to identify that the header
that was drivers/video/fbdev/omap2/dss/dss_features.h now is the one
in the omapdrm directory but that means that the omapfb files won't
get the changes since the move & copy happened before.
This happens AFAIU because dss-drm-merge having an older base so the
patches in for-next are rebased on top of dss-drm-merge when merging.
The issue can easily be avoided by first merging the patch that does
the feat funcs declaration move and then merging the ones that do the
per driver omapdss refactoring.
But I'm posting this patch anyways in case you can't redo your branches
and need a fix to apply on top of your current for-next.
[0]: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
Best regards,
Javier
drivers/video/fbdev/omap2/omapfb/dss/dss_features.c | 2 --
drivers/video/fbdev/omap2/omapfb/dss/dss_features.h | 3 +++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c b/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
index b0b6dfd657bf..a2e26b8d6ded 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
@@ -844,13 +844,11 @@ enum omap_display_type dss_feat_get_supported_displays(enum omap_channel channel
{
return omap_current_dss_features->supported_displays[channel];
}
-EXPORT_SYMBOL(dss_feat_get_supported_displays);
enum omap_dss_output_id dss_feat_get_supported_outputs(enum omap_channel channel)
{
return omap_current_dss_features->supported_outputs[channel];
}
-EXPORT_SYMBOL(dss_feat_get_supported_outputs);
enum omap_color_mode dss_feat_get_supported_color_modes(enum omap_plane plane)
{
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss_features.h b/drivers/video/fbdev/omap2/omapfb/dss/dss_features.h
index 100f7a2d0638..4474ebff8607 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss_features.h
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss_features.h
@@ -102,4 +102,7 @@ bool dss_feat_rotation_type_supported(enum omap_dss_rotation_type rot_type);
bool dss_has_feature(enum dss_feat_id id);
void dss_feat_get_reg_field(enum dss_feat_reg_field id, u8 *start, u8 *end);
void dss_features_init(enum omapdss_version version);
+
+enum omap_display_type dss_feat_get_supported_displays(enum omap_channel channel);
+enum omap_dss_output_id dss_feat_get_supported_outputs(enum omap_channel channel);
#endif
--
2.4.3
^ permalink raw reply related
* Re: [PATCH] OMAPDSS: fix omapfb build error due missing feat functions declaration
From: Tomi Valkeinen @ 2015-12-22 7:50 UTC (permalink / raw)
To: Javier Martinez Canillas, linux-kernel
Cc: Tony Lindgren, linux-fbdev, Dave Airlie,
Jean-Christophe Plagniol-Villard, Rob Clark, linux-omap
In-Reply-To: <1450722384-4606-1-git-send-email-javier@osg.samsung.com>
[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]
Hi Javier,
On 21/12/15 20:26, Javier Martinez Canillas wrote:
> The omapfb is failing to build in -next due missing declarations for
> dss_feat_get_supported_displays() and dss_feat_get_supported_outputs():
>
> CC [M] drivers/video/fbdev/omap2//omapfb/dss/dss.o
> drivers/video/fbdev/omap2//omapfb/dss/dss.c: In function 'dss_save_context':
> drivers/video/fbdev/omap2//omapfb/dss/dss.c:144:2: error: implicit declaration of function 'dss_feat_get_supported_displays' [-Werror=implicit-function-declaration]
>
> Add the declaration for these functions in the dss_features.h header
> file to fix this compile error.
>
> Also, remove the functions export since are not used outside the driver.
Thanks!
Yep, I messed that up. I thought I had tested it, but apparently I only
tested the final for-next only for omapdrm, which does compile and work.
omapdss.h is the the only file still shared between omapdrm and omapfb
after the copy-omapdss-series (I'll work on omapdss.h later), and of
course there was a change to omapdss.h which broke the build.
So I rebased the copy-omapdss-series on top of the rest of the omapdss
patches, and updated the "omapfb: copy omapdss & displays for omapfb" to
make a fresh copy of omapdss for omapfb. I think it's better to update
the series, rather than applying fixes for already confusing series.
I've pushed new version to my for-next branch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] fbdev: omap2: panel-dpi: drop assignment to local variable
From: Tomi Valkeinen @ 2015-12-22 8:56 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1449753107-11410-3-git-send-email-uwe@kleine-koenig.org>
[-- Attachment #1: Type: text/plain, Size: 5905 bytes --]
On 20/12/15 12:31, Uwe Kleine-König wrote:
> Hello,
>
> On Wed, Dec 16, 2015 at 07:29:17PM +0200, Tomi Valkeinen wrote:
>> On 10/12/15 15:11, Uwe Kleine-König wrote:
>>> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>>>
>>> The variable gpio is only used to store the return value of
>>> devm_gpiod_get_optional just to assign it to a member of the driver
>>> data.
>>>
>>> Get rid of this local variable and assign to driver data directly.
>>>
>>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>>> ---
>>> drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 10 ++++------
>>> 1 file changed, 4 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
>>> index e780fd4f8b46..1216341a0d19 100644
>>> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
>>> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
>>> @@ -205,13 +205,11 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
>>> int r;
>>> struct display_timing timing;
>>> struct videomode vm;
>>> - struct gpio_desc *gpio;
>>>
>>> - gpio = devm_gpiod_get_optional(&pdev->dev, "enable", GPIOD_OUT_LOW);
>>> - if (IS_ERR(gpio))
>>> - return PTR_ERR(gpio);
>>> -
>>> - ddata->enable_gpio = gpio;
>>> + ddata->enable_gpio = devm_gpiod_get_optional(&pdev->dev,
>>> + "enable", GPIOD_OUT_LOW);
>>> + if (IS_ERR(ddata->enable_gpio))
>>> + return PTR_ERR(ddata->enable_gpio);
>>>
>>> ddata->backlight_gpio = -ENOENT;
>>
>> I usually try to avoid writing bad values to fields. Here
>> ddata->enable_gpio may get an error ptr. It probably doesn't matter as
>> we bail out right away, but still. If devm_gpiod_get_optional's return
>> value would be NULL or valid gpio_desc*, then it'd be fine.
>
> this is probably a matter of taste but still I don't see why people
> don't like writing to structs immediately.
I don't have a problem with writing to struct immediately. My point was
that I don't like writing invalid values to "long term storage".
What's "invalid" is of course up to the case, but here I think it's
quite clear that 'ddata->enable_gpio' should either be a valid gpiod or
NULL.
Generally, I also like to work on a resource/object in local variables
until it's "ready", and only then push it to the public storage. In my
experience that style results in less possibilities for bugs and confusion.
> With the local variable you might have
>
> gpio = -ESOMETHING
>
> and
>
> ddata->enable_gpio = NULL;
>
> In the case that the error is handled correctly it doesn't matter if the
> value was written to the struct or not (if you accept a little
> performance penalty for writing the value actually to memory maybe). So
> the motivation is the consideration that the error might not be handled
> correctly after a later patch, right? But when ddata->enable_gpio is a
> negative error code this probably results in a crash already during
> development of the faulty patch, while when the struct's member isn't
> assigned it probably doesn't.
Yes, my motivation is that later patches may change the behavior, and
keeping a valid value in 'data->enable_gpio' may make future patches
simpler and prevent problems.
I think it's quite common to do cleanups later, using the values in the
long term storage. Here it might mean setting enable-gpio to 0, or if
devm_* was not used, freeing the gpio, and that would result in using an
error ptr as a pointer to gpiod.
And it's quite common to later change error handling slightly so that
instead of failing, the driver continues if it doesn't actually require
the resource that it failed to get.
Of course, patches for both can and should be written correctly so that
both local and direct write to struct work correctly.
> This convinces me that writing to the struct is actually a good thing.
>
> Additionally even though the line length of
>
> gpio = devm_gpiod_get_optional(&pdev->dev, "enable", GPIOD_OUT_LOW);
> if (IS_ERR(gpio))
> return PTR_ERR(gpio);
>
> ddata->enable_gpio = gpio;
>
> is shorter (which is good), with my approach of doing:
>
> ddata->enable_gpio = devm_gpiod_get_optional(&pdev->dev,
> "enable", GPIOD_OUT_LOW);
> if (IS_ERR(ddata->enable_gpio))
> return PTR_ERR(ddata->enable_gpio);
No big diff here, but I can easily imagine this turning in some future
patch into:
ddata->enable_gpio = devm_gpiod_get_optional(&pdev->dev,
"enable", GPIOD_OUT_LOW);
if (IS_ERR(ddata->enable_gpio)) {
r = PTR_ERR(data->enable_gpio);
ddata->enable_gpio = NULL;
return r;
}
> apart from saving an assignment also "enable_gpio" and "enable" are
> nearer to each other which IMHO makes it easier to see that the
> assignment is correct which outweighs the longer lines. This argument
> even gets more important when reset_gpio is added in patch 4 when the
> situation looks as follows:
>
> gpio = devm_gpiod_get_optional(... "enable" ...);
> if (IS_ERR(gpio))
> ...
> ddata->enable_gpio = gpio;
>
> gpio = devm_gpiod_get_optional(... "reset" ...);
> if (IS_ERR(gpio))
> ...
> ddata->reset_gpio = gpio;
It is, of course, possible to use more exactly named locals instead of a
single 'gpio'.
> vs.
>
> ddata->enable_gpio = devm_gpiod_get_optional(... "enable" ...);
> if (IS_ERR(ddata->enable_gpio))
> ...
>
> ddata->reset_gpio = devm_gpiod_get_optional(... "reset" ...);
> if (IS_ERR(ddata->reset_gpio))
> ...
>
> I like my approach better, but if you don't agree, I don't care enough
> to argue (more).
I don't agree, but I don't care too much either =). Both ways are valid,
and they can always be changed later if the driver changes enough to
require that change.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: fix omapfb build error due missing feat functions declaration
From: Javier Martinez Canillas @ 2015-12-22 12:02 UTC (permalink / raw)
To: Tomi Valkeinen, linux-kernel
Cc: Tony Lindgren, linux-fbdev, Dave Airlie,
Jean-Christophe Plagniol-Villard, Rob Clark, linux-omap
In-Reply-To: <567900BD.6070907@ti.com>
Hello Tomi,
On 12/22/2015 04:50 AM, Tomi Valkeinen wrote:
> Hi Javier,
>
> On 21/12/15 20:26, Javier Martinez Canillas wrote:
>> The omapfb is failing to build in -next due missing declarations for
>> dss_feat_get_supported_displays() and dss_feat_get_supported_outputs():
>>
>> CC [M] drivers/video/fbdev/omap2//omapfb/dss/dss.o
>> drivers/video/fbdev/omap2//omapfb/dss/dss.c: In function 'dss_save_context':
>> drivers/video/fbdev/omap2//omapfb/dss/dss.c:144:2: error: implicit declaration of function 'dss_feat_get_supported_displays' [-Werror=implicit-function-declaration]
>>
>> Add the declaration for these functions in the dss_features.h header
>> file to fix this compile error.
>>
>> Also, remove the functions export since are not used outside the driver.
>
> Thanks!
>
You are welcome.
> Yep, I messed that up. I thought I had tested it, but apparently I only
> tested the final for-next only for omapdrm, which does compile and work.
>
Yes, that's what I thought.
> omapdss.h is the the only file still shared between omapdrm and omapfb
> after the copy-omapdss-series (I'll work on omapdss.h later), and of
> course there was a change to omapdss.h which broke the build.
>
> So I rebased the copy-omapdss-series on top of the rest of the omapdss
> patches, and updated the "omapfb: copy omapdss & displays for omapfb" to
> make a fresh copy of omapdss for omapfb. I think it's better to update
> the series, rather than applying fixes for already confusing series.
>
I completely agree, maintaining bisectability is important. As I mentioned
in my last email, I just posted in case you couldn't rework your branches
for whatever reason.
> I've pushed new version to my for-next branch.
>
Great, thanks!
> Tomi
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH] ocfb: fix tgdel and tvdel timing parameters
From: Andrea Merello @ 2015-12-22 12:26 UTC (permalink / raw)
To: linux-fbdev
According to the ocfb documentation:
Fix tgdel HW param should be left margin, not right.
Fix tvdel HW param should upper margin, not lower.
This seems to fix lock issues on certain monitors (tested on a
slightly customized IP, but the FPGA guy said that it should
be the same wrt this changes).
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
diff --git a/drivers/video/fbdev/ocfb.c b/drivers/video/fbdev/ocfb.c
index c9293ae..a970edc2 100644
--- a/drivers/video/fbdev/ocfb.c
+++ b/drivers/video/fbdev/ocfb.c
@@ -123,11 +123,11 @@ static int ocfb_setupfb(struct ocfb_dev *fbdev)
/* Horizontal timings */
ocfb_writereg(fbdev, OCFB_HTIM, (var->hsync_len - 1) << 24 |
- (var->right_margin - 1) << 16 | (var->xres - 1));
+ (var->left_margin - 1) << 16 | (var->xres - 1));
/* Vertical timings */
ocfb_writereg(fbdev, OCFB_VTIM, (var->vsync_len - 1) << 24 |
- (var->lower_margin - 1) << 16 | (var->yres - 1));
+ (var->upper_margin - 1) << 16 | (var->yres - 1));
/* Total length of frame */
hlen = var->left_margin + var->right_margin + var->hsync_len +
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] backlight: adp8860: fix another uninitialized variable use
From: Jingoo Han @ 2015-12-22 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <565D6937.90503@analog.com>
On Tuesday, December 01, 2015 6:33 PM, Michael Hennerich wrote:
> On 11/30/2015 12:24 PM, Arnd Bergmann wrote:
> > A recent patch I did fixed two potential uses of uninitialized
> > variables in the adp8870 and adp8860 drivers. Unfortunately,
> > I missed another one:
> >
> > drivers/video/backlight/adp8860_bl.c: In function 'adp8860_bl_ambient_light_level_show':
> > drivers/video/backlight/adp8860_bl.c:570:11: warning: 'reg_val' may be used uninitialized in this
> function
> >
> > This does the same change as before in one additional function,
> > and also changes the check for the return value in a way that
> > avoids another false positive warning with a similar message.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Best regards,
Jingoo Han
>
> > Fixes: 6be3a5a9cd91 ("backlight: adp88x0: Fix uninitialized variable use")
> > ---
> > Sorry for missing this third hunk the first time around.
> >
> > diff --git a/drivers/video/backlight/adp8860_bl.c b/drivers/video/backlight/adp8860_bl.c
> > index f0d4c0324580..510e559c060e 100644
> > --- a/drivers/video/backlight/adp8860_bl.c
> > +++ b/drivers/video/backlight/adp8860_bl.c
> > @@ -566,11 +566,13 @@ static ssize_t adp8860_bl_ambient_light_level_show(struct device *dev,
> >
> > mutex_lock(&data->lock);
> > error = adp8860_read(data->client, ADP8860_PH1LEVL, ®_val);
> > - ret_val = reg_val;
> > - error |= adp8860_read(data->client, ADP8860_PH1LEVH, ®_val);
> > + if (!error) {
> > + ret_val = reg_val;
> > + error = adp8860_read(data->client, ADP8860_PH1LEVH, ®_val);
> > + }
> > mutex_unlock(&data->lock);
> >
> > - if (error < 0)
> > + if (error)
> > return error;
> >
> > /* Return 13-bit conversion value for the first light sensor */
> >
>
>
> --
> Greetings,
> Michael
>
> --
> Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
> Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
> Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
> Margaret Seif
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox