All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Robby Cai <robby.cai@nxp.com>,
	Lucas Stach <l.stach@pengutronix.de>,
	Adam Ford <aford173@gmail.com>
Cc: "Ying Liu (OSS)" <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>
Subject: Re: [EXT] Re: [PATCH 1/9] dt-bindings: mxsfb: Add compatible for i.MX8MP
Date: Wed, 2 Mar 2022 03:49:41 +0100	[thread overview]
Message-ID: <3485f77c-667c-05fa-ff96-93e732247b49@denx.de> (raw)
In-Reply-To: <VI1PR04MB699190CC6CB1D5C37C4BB64CF2029@VI1PR04MB6991.eurprd04.prod.outlook.com>

On 3/1/22 14:37, Robby Cai wrote:

Hi,

[...]

>>> 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.
>>
>> 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.
>>
>> Regards,
>> Lucas
> 
> LCDIF on i.MX8MP is a different IP which is borrowed from non-iMX series, although it's also called 'LCDIF'.
> We prefer not mix these two series of IPs in one driver for ease of maintenance and extension.

Where does the MX8MP LCDIF come from then, SGTL maybe ?

WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marex@denx.de>
To: Robby Cai <robby.cai@nxp.com>,
	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>,
	"Ying Liu \(OSS\)" <victor.liu@oss.nxp.com>,
	Rob Herring <robh+dt@kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [EXT] Re: [PATCH 1/9] dt-bindings: mxsfb: Add compatible for i.MX8MP
Date: Wed, 2 Mar 2022 03:49:41 +0100	[thread overview]
Message-ID: <3485f77c-667c-05fa-ff96-93e732247b49@denx.de> (raw)
In-Reply-To: <VI1PR04MB699190CC6CB1D5C37C4BB64CF2029@VI1PR04MB6991.eurprd04.prod.outlook.com>

On 3/1/22 14:37, Robby Cai wrote:

Hi,

[...]

>>> 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.
>>
>> 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.
>>
>> Regards,
>> Lucas
> 
> LCDIF on i.MX8MP is a different IP which is borrowed from non-iMX series, although it's also called 'LCDIF'.
> We prefer not mix these two series of IPs in one driver for ease of maintenance and extension.

Where does the MX8MP LCDIF come from then, SGTL maybe ?

  reply	other threads:[~2022-03-02  2:49 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 [this message]
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
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=3485f77c-667c-05fa-ff96-93e732247b49@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: 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.