From: eric@anholt.net (Eric Anholt)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/4] drm/pl111: Support multiple endpoints on the CLCD
Date: Mon, 29 Jan 2018 15:55:41 -0800 [thread overview]
Message-ID: <87wp00w77m.fsf@anholt.net> (raw)
In-Reply-To: <20180126132033.19744-4-linus.walleij@linaro.org>
Linus Walleij <linus.walleij@linaro.org> writes:
> The Versatile PL110 implementations use multiple endpoints:
> from the PL111 port, the lines are routed through a PLD,
> and from there forked so the same lines go to a VGA DAC and
> an external TFT panel connector. This is discrete wireing
> so there is no way to turn of one output, i.e. this is
> really two endpoints, not two ports.
>
> We model this with multiple endpoints, so we need to loop
> over the available endpoints, check for panel or bridge on
> each and accumulate the result before continuing.
>
> The code already will give the panel preference over the
> bridge, if present, so the output will be sent to the panel
> if both a panel and a bridge is present on two endpoints
> of the same port.
>
> If they all return -EPROBE_DEFER we return -EPROBE_DEFER
> as well.
>
> If just one endpoint is present on the port, the behaviour
> is the same as before.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Huh, from the binding I would have thought that we were describing
things to the point of the pins coming out of the PLD, not past whatever
splitting comes after that.
I'm also confused how this would work. You're talking about the DT
looking like:
clcd at 10020000 {
compatible = "arm,pl111", "arm,primecell";
reg = <0x10020000 0x1000>;
interrupt-names = "combined";
interrupts = <0 44 4>;
clocks = <&oscclk1>, <&oscclk2>;
clock-names = "clcdclk", "apb_pclk";
max-memory-bandwidth = <94371840>; /* Bps, 1024x768 at 60 16bpp */
port {
dac_pads: endpoint1 {
remote-endpoint = <&vgadac>;
arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
};
tft_pads: endpoint2 {
remote-endpoint = <&tftpanel>;
arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
};
};
};
Are you anticipating that a DT would actually connect up to two
endpoints on the CLCD? How should we resolve the pads property, in that
case? Is there much point in supporting this, if we don't actually
support panels or bridges on both of the endpoints at once (since we
pick only one to do panel/bridge setup/teardown on)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180129/bc00e80f/attachment.sig>
WARNING: multiple messages have this Message-ID (diff)
From: Eric Anholt <eric@anholt.net>
To: Linus Walleij <linus.walleij@linaro.org>,
Daniel Vetter <daniel.vetter@intel.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
Sean Paul <seanpaul@chromium.org>
Cc: linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/pl111: Support multiple endpoints on the CLCD
Date: Mon, 29 Jan 2018 15:55:41 -0800 [thread overview]
Message-ID: <87wp00w77m.fsf@anholt.net> (raw)
In-Reply-To: <20180126132033.19744-4-linus.walleij@linaro.org>
[-- Attachment #1.1: Type: text/plain, Size: 2090 bytes --]
Linus Walleij <linus.walleij@linaro.org> writes:
> The Versatile PL110 implementations use multiple endpoints:
> from the PL111 port, the lines are routed through a PLD,
> and from there forked so the same lines go to a VGA DAC and
> an external TFT panel connector. This is discrete wireing
> so there is no way to turn of one output, i.e. this is
> really two endpoints, not two ports.
>
> We model this with multiple endpoints, so we need to loop
> over the available endpoints, check for panel or bridge on
> each and accumulate the result before continuing.
>
> The code already will give the panel preference over the
> bridge, if present, so the output will be sent to the panel
> if both a panel and a bridge is present on two endpoints
> of the same port.
>
> If they all return -EPROBE_DEFER we return -EPROBE_DEFER
> as well.
>
> If just one endpoint is present on the port, the behaviour
> is the same as before.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Huh, from the binding I would have thought that we were describing
things to the point of the pins coming out of the PLD, not past whatever
splitting comes after that.
I'm also confused how this would work. You're talking about the DT
looking like:
clcd@10020000 {
compatible = "arm,pl111", "arm,primecell";
reg = <0x10020000 0x1000>;
interrupt-names = "combined";
interrupts = <0 44 4>;
clocks = <&oscclk1>, <&oscclk2>;
clock-names = "clcdclk", "apb_pclk";
max-memory-bandwidth = <94371840>; /* Bps, 1024x768@60 16bpp */
port {
dac_pads: endpoint1 {
remote-endpoint = <&vgadac>;
arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
};
tft_pads: endpoint2 {
remote-endpoint = <&tftpanel>;
arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
};
};
};
Are you anticipating that a DT would actually connect up to two
endpoints on the CLCD? How should we resolve the pads property, in that
case? Is there much point in supporting this, if we don't actually
support panels or bridges on both of the endpoints at once (since we
pick only one to do panel/bridge setup/teardown on)?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-01-29 23:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-26 13:20 [PATCH 1/4] drm/pl111: Error handling for CMA framebuffer Linus Walleij
2018-01-26 13:20 ` Linus Walleij
2018-01-26 13:20 ` [PATCH 2/4] drm/pl111: Properly detect the PL110+ variant Linus Walleij
2018-01-26 13:20 ` Linus Walleij
2018-01-29 23:45 ` Eric Anholt
2018-01-29 23:45 ` Eric Anholt
2018-01-30 15:39 ` Linus Walleij
2018-01-30 15:39 ` Linus Walleij
2018-01-26 13:20 ` [PATCH 3/4] drm/pl111: Handle the Versatile RGB/BGR565 mode Linus Walleij
2018-01-26 13:20 ` Linus Walleij
2018-01-26 13:20 ` [PATCH 4/4] drm/pl111: Support multiple endpoints on the CLCD Linus Walleij
2018-01-26 13:20 ` Linus Walleij
2018-01-29 23:55 ` Eric Anholt [this message]
2018-01-29 23:55 ` Eric Anholt
2018-02-01 12:49 ` Linus Walleij
2018-02-01 12:49 ` Linus Walleij
2018-01-29 23:39 ` [PATCH 1/4] drm/pl111: Error handling for CMA framebuffer Eric Anholt
2018-01-29 23:39 ` Eric Anholt
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=87wp00w77m.fsf@anholt.net \
--to=eric@anholt.net \
--cc=linux-arm-kernel@lists.infradead.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.