[PATCH v3 00/35] omapdrm: Deconstruct DSS features

[PATCH v3 00/35] omapdrm: Deconstruct DSS features

[Laurent Pinchart]

Hello,

This patch series is a third version of the code previously posted as
"[PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code".

The omapdss/omapdrm initialization code is quite a mess. The physical devices
are instantiated from DT, but two virtual devices named omapdrm and omapdss
are instanciated from platform code to pass various pieces of platform data to
the drivers.

The omapdrm and omapdss platform devices are currently used to pass data and
function pointers from board code to the drivers for the purpose of

- identifying the OMAP SoC revision
- controlling the DSI pads
- configuring bus throughput

It turns out that all these can be handled in the omapdrm and omapdss drivers
without the need for platform data.

- The SoC revision is used to identify the version of various DSS IP cores,
which can instead be done through compatible string matching (with the help of
soc_device_match() in two cases where ES version is needed).

- The DSI pads control can be performed by the driver directly without calling
board code, accessing the related registers through syscon.

- Bus throughput control is implemented in mach-omap2 as a no-op, so we can
just drop the code.

This patch series starts with a new patch that fixes soc_device_match() usage
on OMAP2+. It turned out that OMAP2+ registers SoC device attributes at late
init time, making soc_device_match() impossible to use for drivers at probe
time, which is unfortunately the location where the feature is most needed.

The next five patches (02/35 to 06/35) are small and simple unneeded or unused
code removal. The next two patches (07/35 and 08/35) are cleanups that make
sense by themselves and will be needed by later refactoring.

The series then starts removing usage of the DSS platform data. It first
removes callbacks to platform code in patches 09/35 and 10/35, and then
tackles the larger task of replacing DSS version usage with model data
stored in OF or SoC device match entries (patches 11/35 to 14/35).

The next large user of the DSS version is the omap_dss_features infrastructure
not to be confused with the similarly named dss_features. The former is a
dirty mix of data related to all IP cores in the while display device, while
the latter contains data related to the DSS itself. The next patches
deconstruct omap_dss_features by removing one unneeded features field (15/35),
and slowly moving features to where they belong (patches 16/35 to 34/35).
Patch 35/35 finally removes the omap_dss_features altogether as they're then
empty.

Note that patches 17/35 and 18/35 are not strictly related to
omap_dss_features deconstruction, but they pave the road to removing the
omapdss platform driver (for the virtual omapdss platform device, also known
as core code, not to be confused with the omapdss_dss driver for the DSS
hardware device) which is the ultimate goal of this effort and should be ready
for upstreaming.

Compared to v2, the DSS version usage in the HDMI4 and HDMI5 drivers is still
present, as the related patches were more controversial and require more work.
I will tackle that next as a separate patch series that will finally remove
omapdss platform driver

This version should be simpler to merge given that it doesn't touch the FBDEV
and ALSA subsystems, but still carries an annoying dependency on OMAP2+
platform code. The easiest solution would be to merge the single OMAP2+ patch
(01/35) through the DRM tree as that's where the bulk of changes lies.

The patches are currently based on top of v4.13-rc2 (-rc1 doesn't boot on the
AM57xx board I use for testing) and have been tested on OMAP3 (BeagleBoard-xM,
DM3730), OMAP4 (pandaboard, OMAP4460) and OMAP5 (AM572x EVM, AM572x). Many
regressions were found, and fixed :-)

Laurent Pinchart (35):
  ARM: OMAP2+: Register SoC device attributes from machine .init()
  drm: omapdrm: acx565akm: Remove unneeded check for OF node
  drm: omapdrm: connector-analog-tv: Remove unneeded check for OF node
  drm: omapdrm: panel-dpi: Remove unneeded check for OF node
  drm: omapdrm: dpi: Remove unneeded regulator check
  drm: omapdrm: venc: Don't export omap_dss_pal_vm and omap_dss_ntsc_vm
  drm: omapdrm: hdmi: Store PHY features in PHY data structure
  drm: omapdrm: dss: Split operations out of dss_features structure
  drm: omapdrm: dsi: Handle pin muxing internally
  drm: omapdrm: Don't forward set_min_bus_tput() to no-op platform code
  drm: omapdrm: dispc: Select features based on compatible string
  drm: omapdrm: dpi: Replace OMAP SoC model checks with DSS model
  drm: omapdrm: dsi: Store DSI model and PLL hardware data in OF data
  drm: omapdrm: dss: Select features based on compatible string
  drm: omapdrm: dss: Use supported outputs instead of display types
  drm: omapdrm: dss: Initialize DSS internal features at probe time
  drm: omapdrm: Move all debugfs code from core to dss
  drm: omapdrm: Move shutdown() handler from core to dss
  drm: omapdrm: Move size unit features to dispc_features structure
  drm: omapdrm: Move color modes feature to dispc_features structure
  drm: omapdrm: Move overlay caps features to dispc_features structure
  drm: omapdrm: Move num_ovls and num_mgrs to dispc_features structure
  drm: omapdrm: Move DISPC_CLK_SWITCH reg feature to struct dss_features
  drm: omapdrm: Move reg_fields to dispc_features structure
  drm: omapdrm: Move FEAT_VENC_REQUIRES_TV_DAC_CLK to venc driver
  drm: omapdrm: Move FEAT_DSI_* features to dsi driver
  drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver
  drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code
  drm: omapdrm: Move FEAT_LCD_CLK_SRC feature to dss_features structure
  drm: omapdrm: Move FEAT_* features to dispc driver
  drm: omapdrm: Move FEAT_PARAM_DSI* features to dsi driver
  drm: omapdrm: Move PCD, LINEWIDTH and DOWNSCALE features to dispc
    driver
  drm: omapdrm: Move DSS_FCK feature to dss driver
  drm: omapdrm: Move supported outputs feature to dss driver
  drm: omapdrm: Remove dss_features.h

 arch/arm/mach-omap2/board-generic.c                |   1 +
 arch/arm/mach-omap2/io.c                           |   1 -
 .../gpu/drm/omapdrm/displays/connector-analog-tv.c |   3 +
 drivers/gpu/drm/omapdrm/displays/panel-dpi.c       |   3 +
 .../drm/omapdrm/displays/panel-sony-acx565akm.c    |   3 +
 drivers/gpu/drm/omapdrm/dss/Makefile               |   2 +-
 drivers/gpu/drm/omapdrm/dss/core.c                 | 133 ---
 drivers/gpu/drm/omapdrm/dss/dispc.c                | 824 ++++++++++++++-----
 drivers/gpu/drm/omapdrm/dss/dpi.c                  |  88 +-
 drivers/gpu/drm/omapdrm/dss/dsi.c                  | 307 ++++---
 drivers/gpu/drm/omapdrm/dss/dss.c                  | 406 ++++++---
 drivers/gpu/drm/omapdrm/dss/dss.h                  |  46 +-
 drivers/gpu/drm/omapdrm/dss/dss_features.c         | 905 ---------------------
 drivers/gpu/drm/omapdrm/dss/dss_features.h         | 109 ---
 drivers/gpu/drm/omapdrm/dss/hdmi.h                 |   9 +
 drivers/gpu/drm/omapdrm/dss/hdmi4.c                |   1 -
 drivers/gpu/drm/omapdrm/dss/hdmi4_core.c           |  38 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c                |   1 -
 drivers/gpu/drm/omapdrm/dss/hdmi_phy.c             |  23 +-
 drivers/gpu/drm/omapdrm/dss/omapdss.h              |   7 -
 drivers/gpu/drm/omapdrm/dss/venc.c                 |  21 +-
 drivers/gpu/drm/omapdrm/dss/video-pll.c            |   1 -
 22 files changed, 1296 insertions(+), 1636 deletions(-)
 delete mode 100644 drivers/gpu/drm/omapdrm/dss/dss_features.c
 delete mode 100644 drivers/gpu/drm/omapdrm/dss/dss_features.h

-- 
Regards,

Laurent Pinchart

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

[PATCH v3 01/35] ARM: OMAP2+: Register SoC device attributes from machine .init()

[Laurent Pinchart]

SoC device attributes are registered with a call to
soc_device_register() from the machine .init_late() operation, which is
called from the late initcall, after all drivers built-in drivers have
been probed. This results in the impossibility for drivers to use SoC
device matching in their probe function.

The omap_soc_device_init() function is safe to call from the machine
.init() operation, as all data it depends on is initialized from the
.init_early() operation. Move SoC device attribute registration to
machine .init() like on all other ARM platforms.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 arch/arm/mach-omap2/board-generic.c | 1 +
 arch/arm/mach-omap2/io.c            | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index dc9e34e670a2..5303402ed5c2 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -33,6 +33,7 @@ static void __init omap_generic_init(void)
 	pdata_quirks_init(omap_dt_match_table);
 
 	omapdss_init_of();
+	omap_soc_device_init();
 }
 
 #ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 1d739d1a0a65..952e36b4c4d3 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -428,7 +428,6 @@ static void __init omap_hwmod_init_postsetup(void)
 static void __init __maybe_unused omap_common_late_init(void)
 {
 	omap2_common_pm_late_init();
-	omap_soc_device_init();
 }
 
 #ifdef CONFIG_SOC_OMAP2420
-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v3 00/35] omapdrm: Deconstruct DSS features

[Laurent Pinchart]

On Saturday 05 Aug 2017 01:43:44 Laurent Pinchart wrote:
> Hello,
> 
> This patch series is a third version of the code previously posted as
> "[PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform
> code".
> 
> The omapdss/omapdrm initialization code is quite a mess. The physical
> devices are instantiated from DT, but two virtual devices named omapdrm and
> omapdss are instanciated from platform code to pass various pieces of
> platform data to the drivers.
> 
> The omapdrm and omapdss platform devices are currently used to pass data and
> function pointers from board code to the drivers for the purpose of
> 
> - identifying the OMAP SoC revision
> - controlling the DSI pads
> - configuring bus throughput
> 
> It turns out that all these can be handled in the omapdrm and omapdss
> drivers without the need for platform data.
> 
> - The SoC revision is used to identify the version of various DSS IP cores,
> which can instead be done through compatible string matching (with the help
> of soc_device_match() in two cases where ES version is needed).
> 
> - The DSI pads control can be performed by the driver directly without
> calling board code, accessing the related registers through syscon.
> 
> - Bus throughput control is implemented in mach-omap2 as a no-op, so we can
> just drop the code.
> 
> This patch series starts with a new patch that fixes soc_device_match()
> usage on OMAP2+. It turned out that OMAP2+ registers SoC device attributes
> at late init time, making soc_device_match() impossible to use for drivers
> at probe time, which is unfortunately the location where the feature is
> most needed.
> 
> The next five patches (02/35 to 06/35) are small and simple unneeded or
> unused code removal. The next two patches (07/35 and 08/35) are cleanups
> that make sense by themselves and will be needed by later refactoring.
> 
> The series then starts removing usage of the DSS platform data. It first
> removes callbacks to platform code in patches 09/35 and 10/35, and then
> tackles the larger task of replacing DSS version usage with model data
> stored in OF or SoC device match entries (patches 11/35 to 14/35).
> 
> The next large user of the DSS version is the omap_dss_features
> infrastructure not to be confused with the similarly named dss_features.
> The former is a dirty mix of data related to all IP cores in the while
> display device, while the latter contains data related to the DSS itself.
> The next patches deconstruct omap_dss_features by removing one unneeded
> features field (15/35), and slowly moving features to where they belong
> (patches 16/35 to 34/35). Patch 35/35 finally removes the omap_dss_features
> altogether as they're then empty.
> 
> Note that patches 17/35 and 18/35 are not strictly related to
> omap_dss_features deconstruction, but they pave the road to removing the
> omapdss platform driver (for the virtual omapdss platform device, also known
> as core code, not to be confused with the omapdss_dss driver for the DSS
> hardware device) which is the ultimate goal of this effort and should be
> ready for upstreaming.
> 
> Compared to v2, the DSS version usage in the HDMI4 and HDMI5 drivers is
> still present, as the related patches were more controversial and require
> more work. I will tackle that next as a separate patch series that will
> finally remove omapdss platform driver
> 
> This version should be simpler to merge given that it doesn't touch the
> FBDEV and ALSA subsystems, but still carries an annoying dependency on
> OMAP2+ platform code. The easiest solution would be to merge the single
> OMAP2+ patch (01/35) through the DRM tree as that's where the bulk of
> changes lies.
> 
> The patches are currently based on top of v4.13-rc2 (-rc1 doesn't boot on
> the AM57xx board I use for testing) and have been tested on OMAP3
> (BeagleBoard-xM, DM3730), OMAP4 (pandaboard, OMAP4460) and OMAP5 (AM572x
> EVM, AM572x). Many regressions were found, and fixed :-)

This should of course have read DRA7, not OMAP5.

> Laurent Pinchart (35):
>   ARM: OMAP2+: Register SoC device attributes from machine .init()
>   drm: omapdrm: acx565akm: Remove unneeded check for OF node
>   drm: omapdrm: connector-analog-tv: Remove unneeded check for OF node
>   drm: omapdrm: panel-dpi: Remove unneeded check for OF node
>   drm: omapdrm: dpi: Remove unneeded regulator check
>   drm: omapdrm: venc: Don't export omap_dss_pal_vm and omap_dss_ntsc_vm
>   drm: omapdrm: hdmi: Store PHY features in PHY data structure
>   drm: omapdrm: dss: Split operations out of dss_features structure
>   drm: omapdrm: dsi: Handle pin muxing internally
>   drm: omapdrm: Don't forward set_min_bus_tput() to no-op platform code
>   drm: omapdrm: dispc: Select features based on compatible string
>   drm: omapdrm: dpi: Replace OMAP SoC model checks with DSS model
>   drm: omapdrm: dsi: Store DSI model and PLL hardware data in OF data
>   drm: omapdrm: dss: Select features based on compatible string
>   drm: omapdrm: dss: Use supported outputs instead of display types
>   drm: omapdrm: dss: Initialize DSS internal features at probe time
>   drm: omapdrm: Move all debugfs code from core to dss
>   drm: omapdrm: Move shutdown() handler from core to dss
>   drm: omapdrm: Move size unit features to dispc_features structure
>   drm: omapdrm: Move color modes feature to dispc_features structure
>   drm: omapdrm: Move overlay caps features to dispc_features structure
>   drm: omapdrm: Move num_ovls and num_mgrs to dispc_features structure
>   drm: omapdrm: Move DISPC_CLK_SWITCH reg feature to struct dss_features
>   drm: omapdrm: Move reg_fields to dispc_features structure
>   drm: omapdrm: Move FEAT_VENC_REQUIRES_TV_DAC_CLK to venc driver
>   drm: omapdrm: Move FEAT_DSI_* features to dsi driver
>   drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver
>   drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code
>   drm: omapdrm: Move FEAT_LCD_CLK_SRC feature to dss_features structure
>   drm: omapdrm: Move FEAT_* features to dispc driver
>   drm: omapdrm: Move FEAT_PARAM_DSI* features to dsi driver
>   drm: omapdrm: Move PCD, LINEWIDTH and DOWNSCALE features to dispc
>     driver
>   drm: omapdrm: Move DSS_FCK feature to dss driver
>   drm: omapdrm: Move supported outputs feature to dss driver
>   drm: omapdrm: Remove dss_features.h
> 
>  arch/arm/mach-omap2/board-generic.c                |   1 +
>  arch/arm/mach-omap2/io.c                           |   1 -
>  .../gpu/drm/omapdrm/displays/connector-analog-tv.c |   3 +
>  drivers/gpu/drm/omapdrm/displays/panel-dpi.c       |   3 +
>  .../drm/omapdrm/displays/panel-sony-acx565akm.c    |   3 +
>  drivers/gpu/drm/omapdrm/dss/Makefile               |   2 +-
>  drivers/gpu/drm/omapdrm/dss/core.c                 | 133 ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c                | 824 ++++++++++++-----
>  drivers/gpu/drm/omapdrm/dss/dpi.c                  |  88 +-
>  drivers/gpu/drm/omapdrm/dss/dsi.c                  | 307 ++++---
>  drivers/gpu/drm/omapdrm/dss/dss.c                  | 406 ++++++---
>  drivers/gpu/drm/omapdrm/dss/dss.h                  |  46 +-
>  drivers/gpu/drm/omapdrm/dss/dss_features.c         | 905 ------------------
>  drivers/gpu/drm/omapdrm/dss/dss_features.h         | 109 ---
>  drivers/gpu/drm/omapdrm/dss/hdmi.h                 |   9 +
>  drivers/gpu/drm/omapdrm/dss/hdmi4.c                |   1 -
>  drivers/gpu/drm/omapdrm/dss/hdmi4_core.c           |  38 +-
>  drivers/gpu/drm/omapdrm/dss/hdmi5.c                |   1 -
>  drivers/gpu/drm/omapdrm/dss/hdmi_phy.c             |  23 +-
>  drivers/gpu/drm/omapdrm/dss/omapdss.h              |   7 -
>  drivers/gpu/drm/omapdrm/dss/venc.c                 |  21 +-
>  drivers/gpu/drm/omapdrm/dss/video-pll.c            |   1 -
>  22 files changed, 1296 insertions(+), 1636 deletions(-)
>  delete mode 100644 drivers/gpu/drm/omapdrm/dss/dss_features.c
>  delete mode 100644 drivers/gpu/drm/omapdrm/dss/dss_features.h

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v3 00/35] omapdrm: Deconstruct DSS features

[Tomi Valkeinen]

[-- Attachment #1.1.1: Type: text/plain, Size: 2137 bytes --]

Hi Laurent,

On 05/08/17 01:43, Laurent Pinchart wrote:
> Hello,
> 
> This patch series is a third version of the code previously posted as
> "[PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code".
> 
> The omapdss/omapdrm initialization code is quite a mess. The physical devices
> are instantiated from DT, but two virtual devices named omapdrm and omapdss
> are instanciated from platform code to pass various pieces of platform data to
> the drivers.
> 
> The omapdrm and omapdss platform devices are currently used to pass data and
> function pointers from board code to the drivers for the purpose of
> 
> - identifying the OMAP SoC revision
> - controlling the DSI pads
> - configuring bus throughput
> 
> It turns out that all these can be handled in the omapdrm and omapdss drivers
> without the need for platform data.
> 
> - The SoC revision is used to identify the version of various DSS IP cores,
> which can instead be done through compatible string matching (with the help of
> soc_device_match() in two cases where ES version is needed).
> 
> - The DSI pads control can be performed by the driver directly without calling
> board code, accessing the related registers through syscon.
> 
> - Bus throughput control is implemented in mach-omap2 as a no-op, so we can
> just drop the code.
> 
> This patch series starts with a new patch that fixes soc_device_match() usage
> on OMAP2+. It turned out that OMAP2+ registers SoC device attributes at late
> init time, making soc_device_match() impossible to use for drivers at probe
> time, which is unfortunately the location where the feature is most needed.
> 
> The next five patches (02/35 to 06/35) are small and simple unneeded or unused
> code removal. The next two patches (07/35 and 08/35) are cleanups that make
> sense by themselves and will be needed by later refactoring.

I've picked patches 2-8 (inclusive). I think those can be applied
already, even if the rest of the series would need more work.

Patch 9 doesn't compile, it's referring to DSI_MODEL_OMAP4 which is not
defined.

 Tomi


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

Re: [PATCH v3 00/35] omapdrm: Deconstruct DSS features

[Laurent Pinchart]

Hi Tomi,

On Tuesday 08 Aug 2017 15:56:10 Tomi Valkeinen wrote:
> On 05/08/17 01:43, Laurent Pinchart wrote:
> > Hello,
> > 
> > This patch series is a third version of the code previously posted as
> > "[PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform
> > code".
> > 
> > The omapdss/omapdrm initialization code is quite a mess. The physical
> > devices are instantiated from DT, but two virtual devices named omapdrm
> > and omapdss are instanciated from platform code to pass various pieces of
> > platform data to the drivers.
> > 
> > The omapdrm and omapdss platform devices are currently used to pass data
> > and function pointers from board code to the drivers for the purpose of
> > 
> > - identifying the OMAP SoC revision
> > - controlling the DSI pads
> > - configuring bus throughput
> > 
> > It turns out that all these can be handled in the omapdrm and omapdss
> > drivers without the need for platform data.
> > 
> > - The SoC revision is used to identify the version of various DSS IP
> > cores,
> > which can instead be done through compatible string matching (with the
> > help of soc_device_match() in two cases where ES version is needed).
> > 
> > - The DSI pads control can be performed by the driver directly without
> > calling board code, accessing the related registers through syscon.
> > 
> > - Bus throughput control is implemented in mach-omap2 as a no-op, so we
> > can
> > just drop the code.
> > 
> > This patch series starts with a new patch that fixes soc_device_match()
> > usage on OMAP2+. It turned out that OMAP2+ registers SoC device
> > attributes at late init time, making soc_device_match() impossible to use
> > for drivers at probe time, which is unfortunately the location where the
> > feature is most needed.
> > 
> > The next five patches (02/35 to 06/35) are small and simple unneeded or
> > unused code removal. The next two patches (07/35 and 08/35) are cleanups
> > that make sense by themselves and will be needed by later refactoring.
> 
> I've picked patches 2-8 (inclusive). I think those can be applied
> already, even if the rest of the series would need more work.

I agree, let's try to apply as many as possible.

> Patch 9 doesn't compile, it's referring to DSI_MODEL_OMAP4 which is not
> defined.

I might have forgotten to compile-test all patches individually after 
reordering them, I'm sorry for that. I'm fixing that now. If you can push your 
-next branch with patches 2-8 I can rebase on top of that, otherwise I'll keep 
the v4.13-rc2 base.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v3 00/35] omapdrm: Deconstruct DSS features

[Tomi Valkeinen]

[-- Attachment #1.1.1: Type: text/plain, Size: 634 bytes --]

On 08/08/17 16:02, Laurent Pinchart wrote:

>> Patch 9 doesn't compile, it's referring to DSI_MODEL_OMAP4 which is not
>> defined.
> 
> I might have forgotten to compile-test all patches individually after 
> reordering them, I'm sorry for that. I'm fixing that now. If you can push your 
> -next branch with patches 2-8 I can rebase on top of that, otherwise I'll keep 
> the v4.13-rc2 base.

Please keep them based on v4.13-rc for now. There are still some patches
in my current branch of which I'm not 100% sure if I should push them
(the OMAP_BO flags patches, ping on them ;), so I might end up rebasing.

 Tomi


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

Re: [PATCH v3 00/35] omapdrm: Deconstruct DSS features

[Laurent Pinchart]

Hi Tomi,

On Tuesday 08 Aug 2017 16:04:57 Tomi Valkeinen wrote:
> On 08/08/17 16:02, Laurent Pinchart wrote:
> >> Patch 9 doesn't compile, it's referring to DSI_MODEL_OMAP4 which is not
> >> defined.
> > 
> > I might have forgotten to compile-test all patches individually after
> > reordering them, I'm sorry for that. I'm fixing that now. If you can push
> > your -next branch with patches 2-8 I can rebase on top of that, otherwise
> > I'll keep the v4.13-rc2 base.
> 
> Please keep them based on v4.13-rc for now.

The easiest fix is likely to move "drm: omapdrm: dsi: Store DSI model and PLL 
hardware data in OF data" before "drm: omapdrm: dsi: Handle pin muxing 
internally". Could you review that patch ? If you're fine with it let's just 
move it.

> There are still some patches in my current branch of which I'm not 100% sure
> if I should push them (the OMAP_BO flags patches, ping on them ;), so I
> might end up rebasing.

I'll try to review those today.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v3 01/35] ARM: OMAP2+: Register SoC device attributes from machine .init()

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 228 bytes --]

This message contains a digitally signed email which can be read by opening the attachment.
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki



[-- Attachment #2: Type: message/rfc822, Size: 5279 bytes --]

[-- Attachment #2.1.1.1: Type: text/plain, Size: 1838 bytes --]

Hi Tony,

On 05/08/17 01:43, Laurent Pinchart wrote:
> SoC device attributes are registered with a call to
> soc_device_register() from the machine .init_late() operation, which is
> called from the late initcall, after all drivers built-in drivers have
> been probed. This results in the impossibility for drivers to use SoC
> device matching in their probe function.
> 
> The omap_soc_device_init() function is safe to call from the machine
> .init() operation, as all data it depends on is initialized from the
> .init_early() operation. Move SoC device attribute registration to
> machine .init() like on all other ARM platforms.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
>  arch/arm/mach-omap2/board-generic.c | 1 +
>  arch/arm/mach-omap2/io.c            | 1 -
>  2 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index dc9e34e670a2..5303402ed5c2 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -33,6 +33,7 @@ static void __init omap_generic_init(void)
>  	pdata_quirks_init(omap_dt_match_table);
>  
>  	omapdss_init_of();
> +	omap_soc_device_init();
>  }
>  
>  #ifdef CONFIG_SOC_OMAP2420
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index 1d739d1a0a65..952e36b4c4d3 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -428,7 +428,6 @@ static void __init omap_hwmod_init_postsetup(void)
>  static void __init __maybe_unused omap_common_late_init(void)
>  {
>  	omap2_common_pm_late_init();
> -	omap_soc_device_init();
>  }
>  
>  #ifdef CONFIG_SOC_OMAP2420
> 

Tony, how does this look? Can I push it via the drm tree, along with the
series?

 Tomi


[-- Attachment #2.1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

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

Re: [PATCH v3 01/35] ARM: OMAP2+: Register SoC device attributes from machine .init()

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [170809 05:57]:
> > diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> > index dc9e34e670a2..5303402ed5c2 100644
> > --- a/arch/arm/mach-omap2/board-generic.c
> > +++ b/arch/arm/mach-omap2/board-generic.c
> > @@ -33,6 +33,7 @@ static void __init omap_generic_init(void)
> >  	pdata_quirks_init(omap_dt_match_table);
> >  
> >  	omapdss_init_of();
> > +	omap_soc_device_init();
> >  }
> >  
> >  #ifdef CONFIG_SOC_OMAP2420
> > diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> > index 1d739d1a0a65..952e36b4c4d3 100644
> > --- a/arch/arm/mach-omap2/io.c
> > +++ b/arch/arm/mach-omap2/io.c
> > @@ -428,7 +428,6 @@ static void __init omap_hwmod_init_postsetup(void)
> >  static void __init __maybe_unused omap_common_late_init(void)
> >  {
> >  	omap2_common_pm_late_init();
> > -	omap_soc_device_init();
> >  }
> >  
> >  #ifdef CONFIG_SOC_OMAP2420
> > 
> 
> Tony, how does this look? Can I push it via the drm tree, along with the
> series?

Yes seems safe to me, please feel free to merge it with your
series:

Acked-by: Tony Lindgren <tony@atomide.com>




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