[linux-sunxi] Re: [PATCH v3 2/9] drm/sun4i: tcon: Add TCON LCD support for R40
On Thu, Jan 2, 2020 at 9:17 PM Maxime Ripard wrote:
>
> On Thu, Jan 02, 2020 at 09:10:31PM +0530, Jagan Teki wrote:
> > On Thu, Jan 2, 2020 at 4:24 PM Maxime Ripard wrote:
> > >
> > > On Tue, Dec 31, 2019 at 06:35:21PM +0530, Jagan Teki wrote:
> > > > TCON LCD0, LCD1 in allwinner R40, are used for managing
> > > > LCD interfaces like RGB, LVDS and DSI.
> > > >
> > > > Like TCON TV0, TV1 these LCD0, LCD1 are also managed via
> > > > tcon top.
> > > >
> > > > Add support for it, in tcon driver.
> > > >
> > > > Signed-off-by: Jagan Teki
> > > > ---
> > > > Changes for v3:
> > > > - none
> > > >
> > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 8
> > > > 1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > index fad72799b8df..69611d38c844 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > @@ -1470,6 +1470,13 @@ static const struct sun4i_tcon_quirks
> > > > sun8i_a83t_tv_quirks = {
> > > > .has_channel_1 = true,
> > > > };
> > > >
> > > > +static const struct sun4i_tcon_quirks sun8i_r40_lcd_quirks = {
> > > > + .supports_lvds = true,
> > > > + .has_channel_0 = true,
> > > > + /* TODO Need to support TCON output muxing via GPIO pins */
> > > > + .set_mux= sun8i_r40_tcon_tv_set_mux,
> > >
> > > What is this muking about? And why is it a TODO?
> >
> > Muxing similar like how TCON TOP handle TV0, TV1 I have reused the
> > same so-that it would configure de port selection via
> > sun8i_tcon_top_de_config
> >
> > TCON output muxing have gpio with GPIOD and GPIOH bits, which select
> > which of LCD or TV TCON outputs to the LCD function pins. I have
> > marked these has TODO for further support as mentioned by Chen-Yu in
> > v1[1].
>
> It should be in the commit log.
Make sense.
>
> What's the plan to support that when needed? And that means that the
> LCD and TV outputs are mutually exclusive? We should at the very least
> check that both aren't enabled at the same time.
Yes, LCD or TV within the outselect seems to be mutually exclusive.
Like LCD0 or TV0 can output to GPIOD incase of TV0_OUTSEL and LCD1 or
TV1 can output to GPIOH incase of TV1_OUTSEL. I think checking them
before configuring TCON_TOP_PORT_SEL_REG would make sense, let me know
if you have any suggestions?
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/CAMty3ZB_6GyK%3DhhJU-8yAQiom1Uq25ojFbKaGrK1fmW8SnDV_A%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v3 6/9] dt-bindings: sun6i-dsi: Add R40 DPHY compatible (w/ A31 fallback)
On Thu, Jan 2, 2020 at 4:33 PM Maxime Ripard wrote: > > On Tue, Dec 31, 2019 at 06:35:25PM +0530, Jagan Teki wrote: > > The MIPI DSI PHY controller on Allwinner R40 is similar > > on the one on A31. > > > > Add R40 compatible and append A31 compatible as fallback. > > > > Signed-off-by: Jagan Teki > > --- > > Changes for v3: > > - update the binding in new yaml format > > > > .../devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git > > a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml > > b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml > > index 8841938050b2..0c283fe79402 100644 > > --- > > a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml > > +++ > > b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml > > @@ -18,6 +18,7 @@ properties: > > oneOf: > >- const: allwinner,sun6i-a31-mipi-dphy > >- items: > > + - const: allwinner,sun8i-r40-mipi-dphy > >- const: allwinner,sun50i-a64-mipi-dphy > >- const: allwinner,sun6i-a31-mipi-dphy > > This isn't doing what you say it does. > > Here you're stating that there's two valid values, one that is a > single element allwinner,sun6i-a31-mipi-dphy, and another which is a > list of three elements allwinner,sun8i-r40-mipi-dphy, > allwinner,sun50i-a64-mipi-dphy and allwinner,sun6i-a31-mipi-dphy, in > that order. I got it Maxime, thanks for pointing this. > > Did you run make dtbs_check and dt_bindings_check? I sure I didn't, thanks for the clue. Will do this on another patch as well. Jagan. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAMty3ZAwaqE31%3DrCiub3bRZBOa68ck5Ld%3DA7kVsQjssps9TCxg%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v3 2/9] drm/sun4i: tcon: Add TCON LCD support for R40
On Thu, Jan 2, 2020 at 4:24 PM Maxime Ripard wrote:
>
> On Tue, Dec 31, 2019 at 06:35:21PM +0530, Jagan Teki wrote:
> > TCON LCD0, LCD1 in allwinner R40, are used for managing
> > LCD interfaces like RGB, LVDS and DSI.
> >
> > Like TCON TV0, TV1 these LCD0, LCD1 are also managed via
> > tcon top.
> >
> > Add support for it, in tcon driver.
> >
> > Signed-off-by: Jagan Teki
> > ---
> > Changes for v3:
> > - none
> >
> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > index fad72799b8df..69611d38c844 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -1470,6 +1470,13 @@ static const struct sun4i_tcon_quirks
> > sun8i_a83t_tv_quirks = {
> > .has_channel_1 = true,
> > };
> >
> > +static const struct sun4i_tcon_quirks sun8i_r40_lcd_quirks = {
> > + .supports_lvds = true,
> > + .has_channel_0 = true,
> > + /* TODO Need to support TCON output muxing via GPIO pins */
> > + .set_mux= sun8i_r40_tcon_tv_set_mux,
>
> What is this muking about? And why is it a TODO?
Muxing similar like how TCON TOP handle TV0, TV1 I have reused the
same so-that it would configure de port selection via
sun8i_tcon_top_de_config
TCON output muxing have gpio with GPIOD and GPIOH bits, which select
which of LCD or TV TCON outputs to the LCD function pins. I have
marked these has TODO for further support as mentioned by Chen-Yu in
v1[1].
[1] https://patchwork.freedesktop.org/patch/310210/?series=62062=1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/CAMty3ZA0e8eJZWvAh0x%3DKGAZVL3apdao3COvR6j3-ckv0cdvcg%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v5 3/8] mailbox: sun6i-msgbox: Add a new mailbox driver
On Sat, 2019-12-14 at 22:24 -0600, Samuel Holland wrote:
> Allwinner sun6i, sun8i, sun9i, and sun50i SoCs contain a hardware
> message box used for communication between the ARM CPUs and the ARISC
> management coprocessor. This mailbox contains 8 unidirectional
> 4-message FIFOs.
>
> Add a driver for it, so it can be used for SCPI or other communication
> protocols.
>
> Signed-off-by: Samuel Holland
> ---
> drivers/mailbox/Kconfig| 9 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/sun6i-msgbox.c | 332 +
> 3 files changed, 343 insertions(+)
> create mode 100644 drivers/mailbox/sun6i-msgbox.c
>
[...]
> diff --git a/drivers/mailbox/sun6i-msgbox.c b/drivers/mailbox/sun6i-msgbox.c
> new file mode 100644
> index ..7a41e732457c
> --- /dev/null
> +++ b/drivers/mailbox/sun6i-msgbox.c
> @@ -0,0 +1,332 @@
[...]
> +static int sun6i_msgbox_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct mbox_chan *chans;
> + struct reset_control *reset;
> + struct resource *res;
> + struct sun6i_msgbox *mbox;
> + int i, ret;
> +
> + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
> + if (!mbox)
> + return -ENOMEM;
> +
> + chans = devm_kcalloc(dev, NUM_CHANS, sizeof(*chans), GFP_KERNEL);
> + if (!chans)
> + return -ENOMEM;
> +
> + for (i = 0; i < NUM_CHANS; ++i)
> + chans[i].con_priv = mbox;
> +
> + mbox->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(mbox->clk)) {
> + ret = PTR_ERR(mbox->clk);
> + dev_err(dev, "Failed to get clock: %d\n", ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(mbox->clk);
> + if (ret) {
> + dev_err(dev, "Failed to enable clock: %d\n", ret);
> + return ret;
> + }
> +
> + reset = devm_reset_control_get(dev, NULL);
Please use devm_reset_control_get_exclusive() explicitly.
regards
Philipp
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/1cb30ea7ed8acabb02dc78f6f054be19d4b5b609.camel%40pengutronix.de.
[linux-sunxi] Re: [PATCH 3/3] ARM: dts: sun8i: R40: Add SPI controllers nodes and pinmuxes
On Thu, Jan 2, 2020 at 6:42 PM Andre Przywara wrote:
>
> On Thu, 2 Jan 2020 10:57:11 +0100
> Maxime Ripard wrote:
>
> Hi Maxime,
>
> thanks for having a look!
>
> > On Thu, Jan 02, 2020 at 01:26:57AM +, Andre Przywara wrote:
> > > The Allwinner R40 SoC contains four SPI controllers, using the newer
> > > sun6i design (but at the legacy addresses).
> > > The controller seems to be fully compatible to the A64 one, so no driver
> > > changes are necessary.
> > > The first three controller can be used on two sets of pins, but SPI3 is
> > > only routed to one set on Port A.
> > >
> > > Tested by connecting a SPI flash to a Bananapi M2 Berry on the SPI0
> > > PortC header pins.
> > >
> > > Signed-off-by: Andre Przywara
> > > ---
> > > arch/arm/boot/dts/sun8i-r40.dtsi | 89
> > >
> > > 1 file changed, 89 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi
> > > b/arch/arm/boot/dts/sun8i-r40.dtsi
> > > index 8dcbc4465fbb..af437391dcf4 100644
> > > --- a/arch/arm/boot/dts/sun8i-r40.dtsi
> > > +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
> > > @@ -418,6 +418,41 @@
> > > bias-pull-up;
> > > };
> > >
> > > + spi0_pc_pins: spi0-pc-pins {
> > > + pins = "PC0", "PC1", "PC2", "PC23";
> > > + function = "spi0";
> > > + };
> > > +
> > > + spi0_pi_pins: spi0-pi-pins {
> > > + pins = "PI10", "PI11", "PI12", "PI13", "PI14";
> > > + function = "spi0";
> > > + };
> >
> > This split doesn't really work though :/
> >
> > The PC pins group has MOSI, MISO, CLK and CS0, while the PI pins group
> > has CS0, CLK, MOSI, MISO and CS1.
> >
> > Meaning that if a board uses a GPIO CS pin, we can't really express
> > that
>
> Does that actually work? I dimly remember checking our sunxi driver a while
> ago and I wasn't sure that would be functional there.
>
> > and any board using the PI pins for its SPI bus will try to
> > claim CS0 and CS1, no matter how many devices are connected on the bus
> > (and if there's one, there might be something else connected to PI14).
>
> True.
>
> > And you can't have a board using CS1 with the PC signals either.
> >
> > You should split away the CS pins into separate groups, like we're
> > doing with the A20 for example.
>
> Ah, yeah, makes sense, thanks for the pointer.
>
> > And please add /omit-if-no-ref/ to those groups.
>
> I was a bit reluctant to do this:
> First there does not seem to be any good documentation about it, neither in
> the official DT spec nor in dtc, even though I think I understand what it
> does ;-)
> Second it seems to break in U-Boot atm. Looks like applying your dtc patch
> fixes that, though. Do you know if U-Boot allows cherry-picking dtc patches?
> If yes, I could post your patch.
>
> But more importantly: what are the guidelines for using this tag? I
> understand the desire to provide every possible pin description on one hand,
> but wanting to avoid having *all of them* in *each* .dtb on the other.
I believe it would be nice to have them for all pin descriptions, but
having them
for the peripherals that only have one muxing option probably wouldn't have any
effect, as they would be set and referenced by default in the dtsi.
> But how does this play along with overlays? Shouldn't at least those
> interface pins that are exposed on headers stay in each .dtb? Can we actually
> make this decision in the SoC .dtsi file?
In upstream dtc, I sent a patch to make it ignore the flag if you
compile the dts
with overlay support, i.e. with the -@ flag.
> And should there be a dtc command line option to ignore those tags, or even
> to apply this tag (virtually) to every node?
That would probably end up trimming peripherals out, even enabled ones?
ChenYu
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/CAGb2v65TtEVcwD9RZda7Fja0Z4EZSyV06tAkJG147Hb7_nXq3A%40mail.gmail.com.
[linux-sunxi] Re: [PATCH 3/3] ARM: dts: sun8i: R40: Add SPI controllers nodes and pinmuxes
On Thu, 2 Jan 2020 10:57:11 +0100
Maxime Ripard wrote:
Hi Maxime,
thanks for having a look!
> On Thu, Jan 02, 2020 at 01:26:57AM +, Andre Przywara wrote:
> > The Allwinner R40 SoC contains four SPI controllers, using the newer
> > sun6i design (but at the legacy addresses).
> > The controller seems to be fully compatible to the A64 one, so no driver
> > changes are necessary.
> > The first three controller can be used on two sets of pins, but SPI3 is
> > only routed to one set on Port A.
> >
> > Tested by connecting a SPI flash to a Bananapi M2 Berry on the SPI0
> > PortC header pins.
> >
> > Signed-off-by: Andre Przywara
> > ---
> > arch/arm/boot/dts/sun8i-r40.dtsi | 89
> >
> > 1 file changed, 89 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi
> > b/arch/arm/boot/dts/sun8i-r40.dtsi
> > index 8dcbc4465fbb..af437391dcf4 100644
> > --- a/arch/arm/boot/dts/sun8i-r40.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
> > @@ -418,6 +418,41 @@
> > bias-pull-up;
> > };
> >
> > + spi0_pc_pins: spi0-pc-pins {
> > + pins = "PC0", "PC1", "PC2", "PC23";
> > + function = "spi0";
> > + };
> > +
> > + spi0_pi_pins: spi0-pi-pins {
> > + pins = "PI10", "PI11", "PI12", "PI13", "PI14";
> > + function = "spi0";
> > + };
>
> This split doesn't really work though :/
>
> The PC pins group has MOSI, MISO, CLK and CS0, while the PI pins group
> has CS0, CLK, MOSI, MISO and CS1.
>
> Meaning that if a board uses a GPIO CS pin, we can't really express
> that
Does that actually work? I dimly remember checking our sunxi driver a while ago
and I wasn't sure that would be functional there.
> and any board using the PI pins for its SPI bus will try to
> claim CS0 and CS1, no matter how many devices are connected on the bus
> (and if there's one, there might be something else connected to PI14).
True.
> And you can't have a board using CS1 with the PC signals either.
>
> You should split away the CS pins into separate groups, like we're
> doing with the A20 for example.
Ah, yeah, makes sense, thanks for the pointer.
> And please add /omit-if-no-ref/ to those groups.
I was a bit reluctant to do this:
First there does not seem to be any good documentation about it, neither in the
official DT spec nor in dtc, even though I think I understand what it does ;-)
Second it seems to break in U-Boot atm. Looks like applying your dtc patch
fixes that, though. Do you know if U-Boot allows cherry-picking dtc patches? If
yes, I could post your patch.
But more importantly: what are the guidelines for using this tag? I understand
the desire to provide every possible pin description on one hand, but wanting
to avoid having *all of them* in *each* .dtb on the other.
But how does this play along with overlays? Shouldn't at least those interface
pins that are exposed on headers stay in each .dtb? Can we actually make this
decision in the SoC .dtsi file?
And should there be a dtc command line option to ignore those tags, or even to
apply this tag (virtually) to every node?
Cheers,
Andre.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200102104158.06d9baa0%40donnerap.cambridge.arm.com.
