From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Doug Anderson <dianders@chromium.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>,
Neil Armstrong <narmstrong@baylibre.com>,
Rob Clark <robdclark@chromium.org>,
Sean Paul <seanpaul@chromium.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>,
Jernej Skrabec <jernej.skrabec@siol.net>,
Jonas Karlman <jonas@kwiboo.se>,
dri-devel <dri-devel@lists.freedesktop.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm/bridge: ti-sn65dsi86: Implement lane reordering + polarity
Date: Wed, 6 May 2020 18:56:47 +0300 [thread overview]
Message-ID: <20200506155647.GD15206@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CAD=FV=U8_Krob9oftJjzrYs1zrbLr9WZ-HSStv5_rbq9MpTChw@mail.gmail.com>
Hi Doug,
On Tue, May 05, 2020 at 05:18:48PM -0700, Doug Anderson wrote:
> On Tue, May 5, 2020 at 2:24 PM Doug Anderson wrote:
> > On Tue, May 5, 2020 at 2:14 PM Laurent Pinchart wrote:
> > >
> > > > I'll add this documentation into the comments of the yaml, but I'm not
> > > > going to try to implement enforcement at the yaml level.
> > >
> > > Why not ? :-)
> >
> > Because trying to describe anything in the yaml bindings that doesn't
> > fit in the exact pattern of things that the yaml bindings are designed
> > to check is like constructing the empire state building with only
> > toothpicks.
> >
> > If you want to suggest some syntax that would actually make this
> > doable without blowing out the yaml bindings then I'm happy to add it.
> > Me being naive would assume that we'd need to do an exhaustive list of
> > the OK combinations. That would be fine for the 1-land and 2-lane
> > cases, but for 4 lanes that means adding 256 entries to the bindings.
> >
> > I think the correct way to do this would require adding code in the
> > <https://github.com/devicetree-org/dt-schema> project but that's
> > really only done for generic subsystem-level concepts and not for a
> > single driver.
>
> OK. Looked at your review of the .yaml and the "uniqueItems" is
> probably the bit I didn't think of. With that I can limit this but
> it's still a little awkward. I still haven't figured out how to force
> data-lanes and lane-polarities to have the same number of items, too.
> I'll add this as an add-on patch to my v2 and folks can decide if they
> like it or hate it.
Thanks for looking into it. Looks good to me. Regarding the same number
of items I would assume it should be possible, I would be surprised if
the schemas allowed a different number of items for clocks and
clock-names for instance, but maybe that's not implemented yet. In any
case, no big deal.
> # See ../../media/video-interface.txt for details.
> data-lanes:
> oneOf:
> - minItems: 1
> maxItems: 1
> uniqueItems: true
> items:
> enum:
> - 0
> - 1
> description:
> If you have 1 logical lane it can go to either physical
> port 0 or port 1. Port 0 is suggested.
>
> - minItems: 2
> maxItems: 2
> uniqueItems: true
> items:
> enum:
> - 0
> - 1
> description:
> If you have 2 logical lanes they can be reordered on
> physical ports 0 and 1.
>
> - minItems: 4
> maxItems: 4
> uniqueItems: true
> items:
> enum:
> - 0
> - 1
> - 2
> - 3
> description:
> If you have 4 logical lanes they can be reordered on
> in any way.
--
Regards,
Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Doug Anderson <dianders@chromium.org>
Cc: Rob Clark <robdclark@chromium.org>,
Jernej Skrabec <jernej.skrabec@siol.net>,
Neil Armstrong <narmstrong@baylibre.com>,
David Airlie <airlied@linux.ie>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Jonas Karlman <jonas@kwiboo.se>,
LKML <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Andrzej Hajda <a.hajda@samsung.com>,
Sean Paul <seanpaul@chromium.org>
Subject: Re: [PATCH] drm/bridge: ti-sn65dsi86: Implement lane reordering + polarity
Date: Wed, 6 May 2020 18:56:47 +0300 [thread overview]
Message-ID: <20200506155647.GD15206@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CAD=FV=U8_Krob9oftJjzrYs1zrbLr9WZ-HSStv5_rbq9MpTChw@mail.gmail.com>
Hi Doug,
On Tue, May 05, 2020 at 05:18:48PM -0700, Doug Anderson wrote:
> On Tue, May 5, 2020 at 2:24 PM Doug Anderson wrote:
> > On Tue, May 5, 2020 at 2:14 PM Laurent Pinchart wrote:
> > >
> > > > I'll add this documentation into the comments of the yaml, but I'm not
> > > > going to try to implement enforcement at the yaml level.
> > >
> > > Why not ? :-)
> >
> > Because trying to describe anything in the yaml bindings that doesn't
> > fit in the exact pattern of things that the yaml bindings are designed
> > to check is like constructing the empire state building with only
> > toothpicks.
> >
> > If you want to suggest some syntax that would actually make this
> > doable without blowing out the yaml bindings then I'm happy to add it.
> > Me being naive would assume that we'd need to do an exhaustive list of
> > the OK combinations. That would be fine for the 1-land and 2-lane
> > cases, but for 4 lanes that means adding 256 entries to the bindings.
> >
> > I think the correct way to do this would require adding code in the
> > <https://github.com/devicetree-org/dt-schema> project but that's
> > really only done for generic subsystem-level concepts and not for a
> > single driver.
>
> OK. Looked at your review of the .yaml and the "uniqueItems" is
> probably the bit I didn't think of. With that I can limit this but
> it's still a little awkward. I still haven't figured out how to force
> data-lanes and lane-polarities to have the same number of items, too.
> I'll add this as an add-on patch to my v2 and folks can decide if they
> like it or hate it.
Thanks for looking into it. Looks good to me. Regarding the same number
of items I would assume it should be possible, I would be surprised if
the schemas allowed a different number of items for clocks and
clock-names for instance, but maybe that's not implemented yet. In any
case, no big deal.
> # See ../../media/video-interface.txt for details.
> data-lanes:
> oneOf:
> - minItems: 1
> maxItems: 1
> uniqueItems: true
> items:
> enum:
> - 0
> - 1
> description:
> If you have 1 logical lane it can go to either physical
> port 0 or port 1. Port 0 is suggested.
>
> - minItems: 2
> maxItems: 2
> uniqueItems: true
> items:
> enum:
> - 0
> - 1
> description:
> If you have 2 logical lanes they can be reordered on
> physical ports 0 and 1.
>
> - minItems: 4
> maxItems: 4
> uniqueItems: true
> items:
> enum:
> - 0
> - 1
> - 2
> - 3
> description:
> If you have 4 logical lanes they can be reordered on
> in any way.
--
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:[~2020-05-06 15:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-05 4:36 [PATCH] drm/bridge: ti-sn65dsi86: Implement lane reordering + polarity Douglas Anderson
2020-05-05 4:36 ` Douglas Anderson
2020-05-05 5:44 ` Stephen Boyd
2020-05-05 5:44 ` Stephen Boyd
2020-05-05 18:45 ` Doug Anderson
2020-05-05 18:45 ` Doug Anderson
2020-05-05 19:52 ` Stephen Boyd
2020-05-05 19:52 ` Stephen Boyd
2020-05-05 8:24 ` Laurent Pinchart
2020-05-05 8:24 ` Laurent Pinchart
2020-05-05 17:59 ` Doug Anderson
2020-05-05 17:59 ` Doug Anderson
2020-05-05 21:06 ` Laurent Pinchart
2020-05-05 21:06 ` Laurent Pinchart
2020-05-05 21:12 ` Doug Anderson
2020-05-05 21:12 ` Doug Anderson
2020-05-05 21:14 ` Laurent Pinchart
2020-05-05 21:14 ` Laurent Pinchart
2020-05-05 21:24 ` Doug Anderson
2020-05-05 21:24 ` Doug Anderson
2020-05-06 0:18 ` Doug Anderson
2020-05-06 0:18 ` Doug Anderson
2020-05-06 15:56 ` Laurent Pinchart [this message]
2020-05-06 15:56 ` Laurent Pinchart
2020-05-05 21:20 ` Sam Ravnborg
2020-05-05 21:20 ` Sam Ravnborg
2020-05-05 21:25 ` Doug Anderson
2020-05-05 21:25 ` Doug Anderson
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=20200506155647.GD15206@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dianders@chromium.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jernej.skrabec@siol.net \
--cc=jonas@kwiboo.se \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=narmstrong@baylibre.com \
--cc=robdclark@chromium.org \
--cc=seanpaul@chromium.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.