From: Marek Vasut <marex@denx.de> To: Lucas Stach <l.stach@pengutronix.de>, Adam Ford <aford173@gmail.com> Cc: Liu Ying <victor.liu@oss.nxp.com>, dri-devel <dri-devel@lists.freedesktop.org>, devicetree <devicetree@vger.kernel.org>, Peng Fan <peng.fan@nxp.com>, Alexander Stein <alexander.stein@ew.tq-group.com>, Rob Herring <robh+dt@kernel.org>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Sam Ravnborg <sam@ravnborg.org>, Robby Cai <robby.cai@nxp.com> Subject: Re: [PATCH 1/9] dt-bindings: mxsfb: Add compatible for i.MX8MP Date: Thu, 3 Mar 2022 04:14:46 +0100 [thread overview] Message-ID: <430de480-5a7a-6ed0-eecd-4105f5940aba@denx.de> (raw) In-Reply-To: <85af7c5dfa120903a22e5e704e3bddd87830033c.camel@pengutronix.de> On 3/2/22 10:23, Lucas Stach wrote: [...] >>>> I tend to agree with Marek on this one. We have an instance where the >>>> blk-ctrl and the GPC driver between 8m, mini, nano, plus are close, >>>> but different enough where each SoC has it's own set of tables and >>>> some checks. Lucas created the framework, and others adapted it for >>>> various SoC's. If there really is nearly 50% common code for the >>>> LCDIF, why not either leave the driver as one or split the common code >>>> into its own driver like lcdif-common and then have smaller drivers >>>> that handle their specific variations. >>> >>> I don't know exactly how the standalone driver looks like, but I guess >>> the overlap is not really in any real HW specific parts, but the common >>> DRM boilerplate, so there isn't much point in creating a common lcdif >>> driver. >> >> The mxsfb currently has 1280 LoC as of patch 8/9 of this series. Of >> that, there is some 400 LoC which are specific to old LCDIF and this >> patch adds 380 LoC for the new LCDIF. So that's 800 LoC or ~60% of >> shared boilerplate that would be duplicated . > > That is probably ignoring the fact that the 8MP LCDIF does not support > any overlays, so it could use the drm_simple_display_pipe > infrastructure to reduce the needed boilerplate. It seems the IMXRT1070 LCDIF v2 (heh ...) does support overlays, so no, the mxsfb and hypothetical lcdif drivers would look really very similar. >>> As you brought up the blk-ctrl as an example: I'm all for supporting >>> slightly different hardware in the same driver, as long as the HW >>> interface is close enough. But then I also opted for a separate 8MP >>> blk-ctrl driver for those blk-ctrls that differ significantly from the >>> others, as I think it would make the common driver unmaintainable >>> trying to support all the different variants in one driver. >> >> But then you also need to maintain two sets of boilerplate, they >> diverge, and that is not good. > > I don't think that there is much chance for bugs going unfixed due to > divergence in the boilerplate, especially if you use the simple pipe > framework to handle most of that stuff for you, which gives you a lot > of code sharing with other simple DRM drivers. But I can not use the simple pipe because overlays, see imxrt1070 . [...] We can always split the drivers later if this becomes unmaintainable too, no ?
WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marex@denx.de> To: Lucas Stach <l.stach@pengutronix.de>, Adam Ford <aford173@gmail.com> Cc: devicetree <devicetree@vger.kernel.org>, Peng Fan <peng.fan@nxp.com>, Alexander Stein <alexander.stein@ew.tq-group.com>, dri-devel <dri-devel@lists.freedesktop.org>, Liu Ying <victor.liu@oss.nxp.com>, Rob Herring <robh+dt@kernel.org>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Sam Ravnborg <sam@ravnborg.org>, Robby Cai <robby.cai@nxp.com> Subject: Re: [PATCH 1/9] dt-bindings: mxsfb: Add compatible for i.MX8MP Date: Thu, 3 Mar 2022 04:14:46 +0100 [thread overview] Message-ID: <430de480-5a7a-6ed0-eecd-4105f5940aba@denx.de> (raw) In-Reply-To: <85af7c5dfa120903a22e5e704e3bddd87830033c.camel@pengutronix.de> On 3/2/22 10:23, Lucas Stach wrote: [...] >>>> I tend to agree with Marek on this one. We have an instance where the >>>> blk-ctrl and the GPC driver between 8m, mini, nano, plus are close, >>>> but different enough where each SoC has it's own set of tables and >>>> some checks. Lucas created the framework, and others adapted it for >>>> various SoC's. If there really is nearly 50% common code for the >>>> LCDIF, why not either leave the driver as one or split the common code >>>> into its own driver like lcdif-common and then have smaller drivers >>>> that handle their specific variations. >>> >>> I don't know exactly how the standalone driver looks like, but I guess >>> the overlap is not really in any real HW specific parts, but the common >>> DRM boilerplate, so there isn't much point in creating a common lcdif >>> driver. >> >> The mxsfb currently has 1280 LoC as of patch 8/9 of this series. Of >> that, there is some 400 LoC which are specific to old LCDIF and this >> patch adds 380 LoC for the new LCDIF. So that's 800 LoC or ~60% of >> shared boilerplate that would be duplicated . > > That is probably ignoring the fact that the 8MP LCDIF does not support > any overlays, so it could use the drm_simple_display_pipe > infrastructure to reduce the needed boilerplate. It seems the IMXRT1070 LCDIF v2 (heh ...) does support overlays, so no, the mxsfb and hypothetical lcdif drivers would look really very similar. >>> As you brought up the blk-ctrl as an example: I'm all for supporting >>> slightly different hardware in the same driver, as long as the HW >>> interface is close enough. But then I also opted for a separate 8MP >>> blk-ctrl driver for those blk-ctrls that differ significantly from the >>> others, as I think it would make the common driver unmaintainable >>> trying to support all the different variants in one driver. >> >> But then you also need to maintain two sets of boilerplate, they >> diverge, and that is not good. > > I don't think that there is much chance for bugs going unfixed due to > divergence in the boilerplate, especially if you use the simple pipe > framework to handle most of that stuff for you, which gives you a lot > of code sharing with other simple DRM drivers. But I can not use the simple pipe because overlays, see imxrt1070 . [...] We can always split the drivers later if this becomes unmaintainable too, no ?
next prev parent reply other threads:[~2022-03-03 3:14 UTC|newest] Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-02-28 0:45 [PATCH 1/9] dt-bindings: mxsfb: Add compatible for i.MX8MP Marek Vasut 2022-02-28 0:45 ` Marek Vasut 2022-02-28 0:45 ` [PATCH 2/9] drm: mxsfb: Simplify LCDIF clock handling Marek Vasut 2022-02-28 0:45 ` [PATCH 3/9] drm: mxsfb: Simplify LCDIF IRQ handling Marek Vasut 2022-02-28 0:46 ` [PATCH 4/9] drm: mxsfb: Wrap FIFO reset and comments into mxsfb_reset_block() Marek Vasut 2022-02-28 0:46 ` [PATCH 5/9] drm: mxsfb: Move mxsfb_get_fb_paddr() away from register IO functions Marek Vasut 2022-02-28 0:46 ` [PATCH 6/9] drm: mxsfb: Factor out mxsfb_set_mode() Marek Vasut 2022-02-28 0:46 ` [PATCH 7/9] drm: mxsfb: Reorder mxsfb_crtc_mode_set_nofb() Marek Vasut 2022-02-28 0:46 ` [PATCH 8/9] drm: mxsfb: Factor out mxsfb_update_buffer() Marek Vasut 2022-02-28 0:46 ` [PATCH 9/9] drm: mxsfb: Add support for i.MX8MP LCDIF variant Marek Vasut 2022-02-28 3:48 ` kernel test robot 2022-02-28 3:48 ` kernel test robot 2022-02-28 6:37 ` [PATCH 1/9] dt-bindings: mxsfb: Add compatible for i.MX8MP Liu Ying 2022-02-28 6:37 ` Liu Ying 2022-02-28 6:57 ` Marek Vasut 2022-02-28 6:57 ` Marek Vasut 2022-02-28 8:18 ` Liu Ying 2022-02-28 8:18 ` Liu Ying 2022-02-28 15:34 ` Marek Vasut 2022-02-28 15:34 ` Marek Vasut 2022-03-01 2:44 ` Liu Ying 2022-03-01 2:44 ` Liu Ying 2022-03-01 10:04 ` Lucas Stach 2022-03-01 10:19 ` Marek Vasut 2022-03-01 11:05 ` Lucas Stach 2022-03-01 13:03 ` Adam Ford 2022-03-01 13:03 ` Adam Ford 2022-03-01 13:18 ` Lucas Stach 2022-03-01 13:18 ` Lucas Stach 2022-03-01 13:37 ` [EXT] " Robby Cai 2022-03-01 13:37 ` Robby Cai 2022-03-02 2:49 ` Marek Vasut 2022-03-02 2:49 ` Marek Vasut 2022-03-02 13:14 ` Robby Cai 2022-03-02 13:14 ` Robby Cai 2022-03-03 3:16 ` Marek Vasut 2022-03-03 3:16 ` Marek Vasut 2022-03-02 2:54 ` Marek Vasut 2022-03-02 2:54 ` Marek Vasut 2022-03-02 9:23 ` Lucas Stach 2022-03-02 9:23 ` Lucas Stach 2022-03-02 9:41 ` Liu Ying 2022-03-02 9:41 ` Liu Ying 2022-03-02 11:57 ` Lucas Stach 2022-03-02 11:57 ` Lucas Stach 2022-03-03 2:54 ` Liu Ying 2022-03-03 2:54 ` Liu Ying 2022-03-03 4:14 ` Marek Vasut 2022-03-03 4:14 ` Marek Vasut 2022-03-03 8:19 ` Lucas Stach 2022-03-03 8:19 ` Lucas Stach 2022-03-03 9:14 ` Liu Ying 2022-03-03 9:14 ` Liu Ying 2022-03-03 3:14 ` Marek Vasut [this message] 2022-03-03 3:14 ` Marek Vasut 2022-03-03 8:21 ` Lucas Stach 2022-03-03 8:21 ` Lucas Stach 2022-03-04 4:50 ` Marek Vasut 2022-03-04 4:50 ` Marek Vasut 2022-02-28 6:40 ` Laurent Pinchart 2022-02-28 6:40 ` Laurent Pinchart
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=430de480-5a7a-6ed0-eecd-4105f5940aba@denx.de \ --to=marex@denx.de \ --cc=aford173@gmail.com \ --cc=alexander.stein@ew.tq-group.com \ --cc=devicetree@vger.kernel.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=l.stach@pengutronix.de \ --cc=laurent.pinchart@ideasonboard.com \ --cc=peng.fan@nxp.com \ --cc=robby.cai@nxp.com \ --cc=robh+dt@kernel.org \ --cc=sam@ravnborg.org \ --cc=victor.liu@oss.nxp.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: linkBe 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.