From: Rob Herring <robh@kernel.org>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Archit Taneja <architt@codeaurora.org>,
Rob Clark <robdclark@gmail.com>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH 6/6] drm/msm/dsi: Parse DSI lanes via DT
Date: Tue, 23 Feb 2016 14:04:46 -0600 [thread overview]
Message-ID: <20160223200446.GA28828@rob-hp-laptop> (raw)
In-Reply-To: <56CC3E5C.3060101@ti.com>
On Tue, Feb 23, 2016 at 01:11:24PM +0200, Tomi Valkeinen wrote:
>
>
> On 23/02/16 12:43, Archit Taneja wrote:
> >
> >
> > On 02/23/2016 02:48 PM, Tomi Valkeinen wrote:
> >>
> >> On 22/02/16 22:10, Rob Herring wrote:
> >>
> >>>> If we want all DSI host controllers to use a common binding to describe
> >>>> lanes, we'd need to go with the most flexible one, and the driver
> >>>> restricts it to the subsets that we support.
> >>
> >> True, but I wonder if that's necessary. The lane property for the SoC
> >> should be read by the SoC specific driver, right? So the DT property can
> >> be anything. I'm not sure if there's ever a reason for a generic code to
> >> observe the DSI lane setup.
> >
> > Yeah, it is very SoC specific.
Agreed.
> > The only place where it might matter is if a panel/bridge ever needs to
> > know what pins implement what lanes on the platform. A common binding
> > there might help us keep the panel driver generic. Although, this need
> > itself is a bit hypothetical.
>
> My opinion here is that if the panel/bridge needs to know something
> about the DSI lanes/pins, we should have that data in the
> panel's/bridge's endpoint data.
>
> So if both SoC and the DSI peripheral need complex DSI pin/lane setup,
> you might have very similar data on both sides. There's possibly some
> duplication there, but I think it keeps things much simpler.
>
> For example, if the SoC needs OMAP style DSI pin data, and the DSI
> peripheral needs to know the amount of DSI lanes used (but nothing
> else), you might think it's nice if the DSI peripheral would peek at the
> SoC side data, finding out about the DSI lanes.
>
> But I think in that case you should just add a "num-lanes" property to
> the DSI peripheral. The DT data for a device should be private to the
> driver handling the device, except for some special cases like following
> the graph.
num-lanes might not be enough. You could need to have a mask instead.
Not sure if there is really any h/w like that though.
Also, I think it is fine for a parent to look at standard properties in
a child.
Rob
next prev parent reply other threads:[~2016-02-23 20:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-15 13:00 [PATCH 0/6] drm/msm: Misc patches Archit Taneja
2016-02-15 13:00 ` [PATCH 1/6] drm/msm/mdp: Use atomic helper to set crtc property Archit Taneja
2016-02-15 13:42 ` Daniel Vetter
2016-02-15 13:00 ` [PATCH 2/6] drm/msm/mdp: Detach iommu in mdp4_destroy Archit Taneja
2016-02-15 13:00 ` [PATCH 3/6] drm/msm: Free fb helper resources in msm_unload Archit Taneja
2016-02-15 13:00 ` [PATCH 4/6] drm/msm/dsi: Remove incorrect warning on host attach Archit Taneja
2016-02-15 13:00 ` [PATCH 5/6] drm/msm/dsi: Update the "vdd" voltage range Archit Taneja
[not found] ` <1455541259-8967-1-git-send-email-architt-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-02-15 13:00 ` [PATCH 6/6] drm/msm/dsi: Parse DSI lanes via DT Archit Taneja
2016-02-22 2:53 ` Rob Herring
2016-02-22 7:19 ` Archit Taneja
2016-02-22 20:10 ` Rob Herring
2016-02-23 9:18 ` Tomi Valkeinen
2016-02-23 10:43 ` Archit Taneja
2016-02-23 11:11 ` Tomi Valkeinen
2016-02-23 20:04 ` Rob Herring [this message]
2016-02-24 5:02 ` Archit Taneja
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=20160223200446.GA28828@rob-hp-laptop \
--to=robh@kernel.org \
--cc=architt@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=robdclark@gmail.com \
--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.