From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 00/30] omapdrm: Allocate objects dynamically
Date: Wed, 14 Feb 2018 17:39:14 +0200 [thread overview]
Message-ID: <2797611.AaoVeS1GFj@avalon> (raw)
In-Reply-To: <11227e60-4840-a5c2-7e3c-034f9a88e3ee@ti.com>
Hi Tomi,
On Wednesday, 14 February 2018 15:24:53 EET Tomi Valkeinen wrote:
> Hi,
>
> On 13/02/18 14:00, Laurent Pinchart wrote:
> > Hello,
> >
> > Most of this series has previously been posted as part of "[PATCH 00/48]
> > omapdrm: Merge omapdrm and omapdss". With "[PATCH v2 00/15] omapdrm:
> > Miscellaneous fixes and cleanups" posted and merged a few days ago, it
> > completes the rework of the omapdrm and omapdss drivers to replace most
> > global variables with dynamically-allocated objects. The actual merge of
> > the omapdrm and omapdss drivers has been left out for now as it still
> > suffers from unresolved issues.
> >
> > As with the previous series I have other pending patches based on top of
> > this, as passing driver objects around explicitly helps not relying on
> > more global variables that would hinder the effort to move to the DRM
> > bridge and DRM panel APIs.
> >
> > Patches 02/30, 14/30, 22/30 and 23/30 are new. Patch 21/30 has seen
> > significant changes and I have thus dropped the Reviewed-by tag from
> > Sebastian. All other patches have been rebased and reordered, thus
> > sometimes modified to resolve conflicts, but have otherwise seen only
> > minor changes.
> >
> > The series is based on top of the omapdrm-next branch from
> > git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git.
> >
> > Tomi, as the series has been stripped of its controversial patches, I
> > think it's now ready to be merged (pending review of the patches mentioned
> > above of course). I have tested it on both a Panda board and an AM57xx EVM
> > without any issues (and this time I made sure to try with the drivers
> > compiled as modules).
>
> I have to admit I didn't go through every line of the patches, but
> overall I think this looks good. The only problem is the support for
> DSS6, which I mentioned in the other mail.
>
> We don't have DSS6 support in mainline, but it's a critical thing for TI
> to support. If it helps, we can upstream the current DSS6 driver (which
> is not very big), so that these can be reworked with DSS6 included. Or
> we can delay upstreaming DSS6, but we must get the out-of-mainline DSS6
> driver working on top of these (which, afaics, is not possible at the
> moment).
Following up our discussion in reply to another e-mail in this thread, would
switching to struct device pointers for DSS and DISPC objects in the public
API help ? Is there anything else preventing DSS6 from working on top of this
series ? I would personally prefer getting the cleanups and reworks (including
the switch to DRM bridge and DRM panel) upstream before addressing DSS6 in
mainline, as the problem is already complex enough.
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-02-14 15:38 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-13 12:00 [PATCH v2 00/30] omapdrm: Allocate objects dynamically Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 01/30] drm: omapdrm: Split init and cleanup from probe and remove functions Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 02/30] drm: omapdrm: dss: Expose DSS data in a dss_device structure Laurent Pinchart
2018-02-13 20:05 ` Sebastian Reichel
2018-02-13 12:00 ` [PATCH v2 03/30] drm: omapdrm: dss: Pass DSS private structure to runtime PM functions Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 04/30] drm: omapdrm: dss: Pass PLL pointer to dss_ctrl_pll_enable() Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 05/30] drm: omapdrm: dss: Pass DSS pointer to dss_sdi_*() functions Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 06/30] drm: omapdrm: dss: Pass DSS pointer to dss_ops operations Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 07/30] drm: omapdrm: dss: Pass DSS pointer to dss_get_*_clk_source() Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 08/30] drm: omapdrm: dss: Pass DSS pointer to dss clock functions Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 09/30] drm: omapdrm: dss: Pass DSS pointer to remaining dss functions Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 10/30] drm: omapdrm: dss: Allocate the DSS private data structure dynamically Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 11/30] drm: omapdrm: dss: Support passing private data to debugfs show handlers Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 12/30] drm: omapdrm: dss: Store the registered plls array in struct dss_device Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 13/30] drm: omapdrm: dss: Store the debugfs root directory " Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 14/30] drm: omapdrm: dss: Don't unnecessarily cast to dev to pdev and back Laurent Pinchart
2018-02-13 20:23 ` Sebastian Reichel
2018-02-13 12:00 ` [PATCH v2 15/30] drm: omapdrm: dsi: Pass the dsi_data pointer to internal functions Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 16/30] drm: omapdrm: dsi: Combine two commonly used inline functions Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 17/30] drm: omapdrm: dsi: Use dev pointer directly in dsi_bind() function Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 18/30] drm: omapdrm: dsi: Store the struct device pointer in struct dsi_data Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 19/30] drm: omapdrm: dsi: Don't pass channel to dispc init/uninit functions Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 20/30] drm: omapdrm: dss: Pass omap_dss_device pointer to dss_mgr_*() functions Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 21/30] drm: omapdrm: dss: Pass omap_drm_private pointer to dss_mgr_ops Laurent Pinchart
2018-02-13 20:58 ` Sebastian Reichel
2018-02-13 12:00 ` [PATCH v2 22/30] drm: omapdrm: dss: Store DSS device pointer in the omapdrm private data Laurent Pinchart
2018-02-13 21:25 ` Sebastian Reichel
2018-02-14 8:31 ` Tomi Valkeinen
2018-02-14 15:34 ` Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 23/30] drm: omapdrm: dss: Store dispc ops in dss_device structure Laurent Pinchart
2018-02-13 21:32 ` Sebastian Reichel
2018-02-13 12:00 ` [PATCH v2 24/30] drm: omapdrm: dispc: Pass DISPC pointer to dispc_ops operations Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 25/30] drm: omapdrm: dispc: Pass DISPC pointer to remaining dispc API functions Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 26/30] drm: omapdrm: dispc: Allocate the dispc private data structure dynamically Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 27/30] drm: omapdrm: hdmi4: Allocate the omap_hdmi " Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 28/30] drm: omapdrm: hdmi5: " Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 29/30] drm: omapdrm: sdi: Allocate the sdi private " Laurent Pinchart
2018-02-13 12:00 ` [PATCH v2 30/30] drm: omapdrm: venc: Allocate the venc " Laurent Pinchart
2018-02-14 13:24 ` [PATCH v2 00/30] omapdrm: Allocate objects dynamically Tomi Valkeinen
2018-02-14 15:39 ` Laurent Pinchart [this message]
2018-02-14 15:52 ` Tomi Valkeinen
2018-02-28 8:35 ` Tomi Valkeinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2797611.AaoVeS1GFj@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=tomi.valkeinen@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.