All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Frank Rowand <frowand.list@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	dri-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org, Rob Herring <robh@kernel.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v6 0/4] R-Car DU: Convert LVDS code to bridge driver
Date: Thu, 22 Feb 2018 22:27:10 +0200	[thread overview]
Message-ID: <2099183.6c7g0IDd6G@avalon> (raw)
In-Reply-To: <1ffb9d8c-fde3-af3b-c9a7-caac5ec253eb@gmail.com>

Hi Frank,

On Thursday, 22 February 2018 22:23:20 EET Frank Rowand wrote:
> On 02/22/18 05:13, Laurent Pinchart wrote:
> > Hello,
> > 
> > This patch series addresses a design mistake that dates back from the
> > initial DU support. Support for the LVDS encoders, which are IP cores
> > separate from the DU, was bundled in the DU driver. Worse, both the DU
> > and LVDS were described through a single DT node.
> > 
> > To fix the, patches 1/4 and 2/4 define new DT bindings for the LVDS
> > encoders, and deprecate their description inside the DU bindings. To
> > retain backward compatibility with existing DT, patch 3/4 then patch the
> > device tree at runtime to convert the legacy bindings to the new ones.
> > 
> > With the DT side addressed, patch 4/4 converts the LVDS support code to a
> > separate bridge driver.
> > 
> > I decided to go for live DT patching in patch 3/4 because implementing
> > support for both the legacy and new bindings in the driver would have been
> > very intrusive, and prevented further cleanups. This version relies more
> > heavily on overlays to avoid touching the internals of the OF core
> > compared to v2, even if manual fixes to the device tree are still needed.
> > 
> > As all the patches but the last one have been acked, I plan to send a pull
> > request by the end of the week if no new issue is discovered.
> > 
> > Compared to v5, I've dropped the OF changeset halpers series as Frank
> > raised concerns about hidding it in the middle of a driver patch series.
> > I've thus copied the implementation of of_changeset_add_property_copy()
> > in the driver to avoid blocking this series. The function arguments are
> > identical, so when the OF changeset helpers will land it will be very
> > easy to drop the private copy and use the
> > of_changeset_add_property_copy() helper.
> 
> Thank you Laurent.
> 
> My issues with that are procedural, and I'll reply later about this in the
> v4 patch thread, where I raised the issue.  (For the peanut gallery, I
> replied in thread v4 _after_ Laurent sent v5, so Laurent did not ignore
> me in v5.)

I would have waited for your ack anyway :-)

> My technical comments are more relevent than my process comments, in terms
> of helping Laurent get his driver submitted, so I will delay the process
> comments.

Thank you. 

> My technical comments will be in reply to patch 3/4.

-- 
Regards,

Laurent Pinchart

WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Frank Rowand <frowand.list@gmail.com>
Cc: linux-renesas-soc@vger.kernel.org,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v6 0/4] R-Car DU: Convert LVDS code to bridge driver
Date: Thu, 22 Feb 2018 22:27:10 +0200	[thread overview]
Message-ID: <2099183.6c7g0IDd6G@avalon> (raw)
In-Reply-To: <1ffb9d8c-fde3-af3b-c9a7-caac5ec253eb@gmail.com>

Hi Frank,

On Thursday, 22 February 2018 22:23:20 EET Frank Rowand wrote:
> On 02/22/18 05:13, Laurent Pinchart wrote:
> > Hello,
> > 
> > This patch series addresses a design mistake that dates back from the
> > initial DU support. Support for the LVDS encoders, which are IP cores
> > separate from the DU, was bundled in the DU driver. Worse, both the DU
> > and LVDS were described through a single DT node.
> > 
> > To fix the, patches 1/4 and 2/4 define new DT bindings for the LVDS
> > encoders, and deprecate their description inside the DU bindings. To
> > retain backward compatibility with existing DT, patch 3/4 then patch the
> > device tree at runtime to convert the legacy bindings to the new ones.
> > 
> > With the DT side addressed, patch 4/4 converts the LVDS support code to a
> > separate bridge driver.
> > 
> > I decided to go for live DT patching in patch 3/4 because implementing
> > support for both the legacy and new bindings in the driver would have been
> > very intrusive, and prevented further cleanups. This version relies more
> > heavily on overlays to avoid touching the internals of the OF core
> > compared to v2, even if manual fixes to the device tree are still needed.
> > 
> > As all the patches but the last one have been acked, I plan to send a pull
> > request by the end of the week if no new issue is discovered.
> > 
> > Compared to v5, I've dropped the OF changeset halpers series as Frank
> > raised concerns about hidding it in the middle of a driver patch series.
> > I've thus copied the implementation of of_changeset_add_property_copy()
> > in the driver to avoid blocking this series. The function arguments are
> > identical, so when the OF changeset helpers will land it will be very
> > easy to drop the private copy and use the
> > of_changeset_add_property_copy() helper.
> 
> Thank you Laurent.
> 
> My issues with that are procedural, and I'll reply later about this in the
> v4 patch thread, where I raised the issue.  (For the peanut gallery, I
> replied in thread v4 _after_ Laurent sent v5, so Laurent did not ignore
> me in v5.)

I would have waited for your ack anyway :-)

> My technical comments are more relevent than my process comments, in terms
> of helping Laurent get his driver submitted, so I will delay the process
> comments.

Thank you. 

> My technical comments will be in reply to patch 3/4.

-- 
Regards,

Laurent Pinchart

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

  reply	other threads:[~2018-02-22 20:26 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-22 13:13 [PATCH v6 0/4] R-Car DU: Convert LVDS code to bridge driver Laurent Pinchart
2018-02-22 13:13 ` Laurent Pinchart
2018-02-22 13:13 ` [PATCH v6 1/4] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings Laurent Pinchart
2018-02-22 13:13   ` Laurent Pinchart
2018-02-22 13:37   ` Niklas Söderlund
2018-02-22 13:37     ` Niklas Söderlund
2018-02-22 13:13 ` [PATCH v6 2/4] dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings Laurent Pinchart
2018-02-22 13:13   ` Laurent Pinchart
2018-02-22 13:40   ` Niklas Söderlund
2018-02-22 13:40     ` Niklas Söderlund
2018-02-22 13:13 ` [PATCH v6 3/4] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes Laurent Pinchart
2018-02-22 13:13   ` Laurent Pinchart
2018-02-22 22:10   ` Frank Rowand
2018-02-22 22:10     ` Frank Rowand
2018-02-22 22:22     ` Laurent Pinchart
2018-02-22 22:22       ` Laurent Pinchart
2018-02-23  2:38     ` Frank Rowand
2018-02-23  2:38       ` Frank Rowand
2018-02-23  9:00       ` Laurent Pinchart
2018-02-23  9:00         ` Laurent Pinchart
2018-02-23 19:43         ` Frank Rowand
2018-02-23 19:43           ` Frank Rowand
2018-02-23 19:56           ` Laurent Pinchart
2018-02-23 19:56             ` Laurent Pinchart
2018-02-24 22:09             ` Frank Rowand
2018-02-24 22:09               ` Frank Rowand
2018-02-24 22:42     ` Frank Rowand
2018-02-24 22:42       ` Frank Rowand
2018-02-25 11:33       ` Laurent Pinchart
2018-02-25 11:33         ` Laurent Pinchart
2018-02-22 13:13 ` [PATCH v6 4/4] drm: rcar-du: Convert LVDS encoder code to bridge driver Laurent Pinchart
2018-02-22 13:13   ` Laurent Pinchart
2018-02-22 14:49   ` Niklas Söderlund
2018-02-22 14:49     ` Niklas Söderlund
2018-02-22 20:23 ` [PATCH v6 0/4] R-Car DU: Convert LVDS " Frank Rowand
2018-02-22 20:23   ` Frank Rowand
2018-02-22 20:27   ` Laurent Pinchart [this message]
2018-02-22 20:27     ` 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=2099183.6c7g0IDd6G@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=frowand.list@gmail.com \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=robh@kernel.org \
    /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.