Re: [PATCH v3 00/35] omapdrm: Deconstruct DSS features
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 00/35] omapdrm: Deconstruct DSS features
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 signature.asc Description: OpenPGP digital signature ___ 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
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
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 signature.asc Description: OpenPGP digital signature ___ 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
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: oma
