linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: "Pali Rohár" <pali@kernel.org>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Andrew Lunn" <andrew@lunn.ch>,
	"Gregory Clement" <gregory.clement@bootlin.com>,
	"Sebastian Hesselbarth" <sebastian.hesselbarth@gmail.com>,
	"Vladimir Vid" <vladimir.vid@sartura.hr>,
	"Marek Behún" <kabel@kernel.org>,
	linux-clk@vger.kernel.org, linux-serial@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v7 3/6] dt-bindings: mvebu-uart: document DT bindings for marvell,armada-3700-uart-clock
Date: Fri, 15 Oct 2021 14:55:47 -0700	[thread overview]
Message-ID: <163433494758.1688384.5994009027317282677@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <20211015093701.pfvkighxsndj4ujg@pali>

Quoting Pali Rohár (2021-10-15 02:37:01)
> On Friday 15 October 2021 11:09:37 Pali Rohár wrote:
> > On Thursday 14 October 2021 17:13:03 Stephen Boyd wrote:
> > > Quoting Pali Rohár (2021-09-30 02:58:35)
> > > > diff --git a/Documentation/devicetree/bindings/clock/marvell,armada-3700-uart-clock.yaml b/Documentation/devicetree/bindings/clock/marvell,armada-3700-uart-clock.yaml
> > > > new file mode 100644
> > > > index 000000000000..175f5c8f2bc5
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/clock/marvell,armada-3700-uart-clock.yaml
> > > > @@ -0,0 +1,59 @@
> > > [..]
> > > > +  '#clock-cells':
> > > > +    const: 1
> > > > +
> > > > +required:
> > > > +  - compatible
> > > > +  - reg
> > > > +  - clocks
> > > > +  - clock-names
> > > > +  - '#clock-cells'
> > > > +
> > > > +additionalProperties: false
> > > > +
> > > > +examples:
> > > > +  - |
> > > > +    uartclk: clock-controller@12010 {
> > > 
> > > The uart device is at 0x12000 and the clock-controller is at 0x12010?
> > > This looks like a node is being put into DT to represent a clk driver.
> > > Why can't we register a clk from the uart device driver itself? I think
> > > we talked about this a month or two ago but it still isn't clear to me.
> > 
> > We have already talked about it and I have already wrote reasons. UART
> > clk is shared for both UART1 and UART2. And UART clk regs are in both
> > address spaces of UART1 and UART2. UART1 or UART2 can be independently
> > disabled on particular board (as pins are MPP which may be configured to
> > different function). So you have a board only with UART2, you have to
> > disable UART1 node, but at the same time you have to access UART clk to
> > drive UART2. And UART clk bits are in UART1 address space.
> 
> It is explained also in commit message of patch 2/6.

Cool, thanks for the pointer.

Why are the two uarts split into different device nodes? It looks like
it's one device that was split into two nodes because they're fairly
similar hardware blocks, and one or the other may not be used on the
board so we want to use status = "disabled" to indicate that. Sadly the
hardware team has delivered them as a single package into the SoC at
address 0x12000 and then stuck a common clk for both uarts into the same
uart wrapper. Here's a clk, job done!

Is it a problem to map UART1 address space when it isn't used on the
board? I'm trying to understand why it can't work to register two uart
ports from one device node and driver. It seems to be the main reason
why we're introducing another node for the clk registers when it feels
like it could all be handled in the existing uart driver.

For example, we could have a static clk pointer in the uart driver
indicating the clk has been registered, and then register the clk if
uart1 or uart2 is the first device to probe and then store that clk in a
global (with clk_hw_get_clk(), I think that's a thing now). If uart2
probes first it can take the reg property and subtract some number to
find the clk, and if uart1 probes first it can take the reg property and
add some number to find the clk. Either way, the binding doesn't change
in this case and we don't have to add another binding for this same uart
hardware.

Then if someone wants to cleanup the binding they can combine both uarts
into one node, make a new compatible string and add some property to
indicate that one or the other uart isn't used. Probably also add some
property to map the uart alias to the uart hardware block inside the
wrapper node.

  reply	other threads:[~2021-10-15 21:55 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30  9:58 [PATCH v7 0/6] serial: mvebu-uart: Support for higher baudrates Pali Rohár
2021-09-30  9:58 ` [PATCH v7 1/6] math64: New DIV_U64_ROUND_CLOSEST helper Pali Rohár
2021-09-30  9:58 ` [PATCH v7 2/6] serial: mvebu-uart: implement UART clock driver for configuring UART base clock Pali Rohár
2021-10-13 14:16   ` Gregory CLEMENT
2021-10-13 14:21     ` Pali Rohár
2021-09-30  9:58 ` [PATCH v7 3/6] dt-bindings: mvebu-uart: document DT bindings for marvell,armada-3700-uart-clock Pali Rohár
2021-10-06 21:07   ` Rob Herring
2021-10-15  0:13   ` Stephen Boyd
2021-10-15  9:09     ` Pali Rohár
2021-10-15  9:37       ` Pali Rohár
2021-10-15 21:55         ` Stephen Boyd [this message]
2021-10-15 22:08           ` [PATCH v7 3/6] dt-bindings: mvebu-uart: document DT bindings for marvell, armada-3700-uart-clock Mark Kettenis
2021-10-16  6:42           ` [PATCH v7 3/6] dt-bindings: mvebu-uart: document DT bindings for marvell,armada-3700-uart-clock Pali Rohár
2022-01-15  8:02             ` Stephen Boyd
2022-01-15 11:50               ` Pali Rohár
2022-01-15 12:05                 ` Marek Behún
2022-01-15 12:26                   ` Pali Rohár
2022-01-19 23:16                     ` Stephen Boyd
2022-01-20  0:06                       ` Pali Rohár
2022-01-20  6:01                         ` Stephen Boyd
2022-01-20  9:26                           ` Pali Rohár
2022-01-25 20:40                             ` Stephen Boyd
2021-09-30  9:58 ` [PATCH v7 4/6] dt-bindings: mvebu-uart: update information about UART clock Pali Rohár
2021-10-06 21:11   ` Rob Herring
2021-09-30  9:58 ` [PATCH v7 5/6] arm64: dts: marvell: armada-37xx: add device node for UART clock and use it Pali Rohár
2021-10-13 14:13   ` Gregory CLEMENT
2021-10-13 14:19     ` Pali Rohár
2021-09-30  9:58 ` [PATCH v7 6/6] serial: mvebu-uart: implement support for baudrates higher than 230400 Pali Rohár
2021-10-01 12:11 ` [PATCH v7 0/6] serial: mvebu-uart: Support for higher baudrates Pali Rohár
2021-11-03 21:42 ` Pali Rohár
2021-12-17 17:23   ` Gregory CLEMENT
2022-01-14 10:51     ` Pali Rohár
2022-01-14 22:56       ` Stephen Boyd
2022-01-14 23:05         ` Pali Rohár
2022-01-14 23:16           ` Stephen Boyd
2022-01-14 23:20             ` Pali Rohár

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=163433494758.1688384.5994009027317282677@swboyd.mtv.corp.google.com \
    --to=sboyd@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=gregory.clement@bootlin.com \
    --cc=kabel@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=pali@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=vladimir.vid@sartura.hr \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).