From: Michael Tretter <m.tretter@pengutronix.de>
To: Stephen Boyd <sboyd@kernel.org>
Cc: devicetree@vger.kernel.org, dshah@xilinx.com,
mturquette@baylibre.com, tejasp@xilinx.com, rajanv@xilinx.com,
robh+dt@kernel.org, michals@xilinx.com, rvisaval@xilinx.com,
kernel@pengutronix.de, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 00/12] soc: xilinx: vcu: Convert driver to clock provider
Date: Mon, 21 Dec 2020 10:19:59 +0100 [thread overview]
Message-ID: <20201221091959.GB22033@pengutronix.de> (raw)
In-Reply-To: <160808624070.1580929.14530755991373122337@swboyd.mtv.corp.google.com>
On Tue, 15 Dec 2020 18:37:20 -0800, Stephen Boyd wrote:
> Quoting Michael Tretter (2020-12-15 03:56:32)
> > On Sat, 12 Dec 2020 21:50:00 -0800, Stephen Boyd wrote:
> > > Quoting Michael Tretter (2020-11-15 23:55:20)
> > > > Hello,
> > > >
> > > > the xlnx_vcu soc driver is actually a clock provider of a PLL and four output
> > > > clocks created from the PLL via dividers.
> > > >
> > > > This series reworks the xlnx_vcu driver to use the common clock framework to
> > > > enable other drivers to use the clocks. I originally posted a series to expose
> > > > the output clocks as fixed clocks [0]. This series now implements the full
> > > > tree from the PLL to the output clocks. Therefore, I am sending a separate
> > > > series that focuses on the clocks, but it depends on v4 of the previous series
> > > > [1].
> > >
> > > After this series is this anything besides a clk provider? If it's only
> > > providing clks it would make sense to move the driver into drivers/clk/
> > >
> >
> > 1. The driver is also responsible for resetting the entire VCU (the
> > VCU_GASKET_INIT register). This isn't something that an individual encoder or
> > decoder driver should be doing. However, other clock drivers also implement a
> > reset controller.
>
> Right.
>
> >
> > 2. There are several registers for AXI performance monitoring in the VCU
> > System-Level Control register space. Right now, these are not used by the
> > driver and I have no plans to actually use them, but this might be an argument
> > against the move.
>
> I suppose if/when that happens we can have a small parent driver that
> probes the compatible string and makes two child platform devices, one
> for the clk part and one for the PMU? That would let us keep the code in
> drivers/clk/ for ease of find-ability. This assumes that the PMU
> registers don't overlap with the clk/reset registers. We usually put the
> clk and reset controllers together if they use the same registers and
> need to make sure the frameworks don't stomp on each other.
>
> >
> > I think it is OK to move the driver to drivers/clk/, but I don't have a strong
> > opinion about it.
> >
>
> Ok. I'm not too strong on it either, but drivers/soc/ is sort of a
> dumping ground for random soc things. I'm not looking at it closely but
> if the driver is in drivers/clk/ I'd be more inclined to look after the
> clk bits.
OK, I will move the driver to drivers/clk/xilinx/
Michael
WARNING: multiple messages have this Message-ID (diff)
From: Michael Tretter <m.tretter@pengutronix.de>
To: Stephen Boyd <sboyd@kernel.org>
Cc: devicetree@vger.kernel.org, dshah@xilinx.com, tejasp@xilinx.com,
mturquette@baylibre.com, rajanv@xilinx.com, robh+dt@kernel.org,
michals@xilinx.com, linux-arm-kernel@lists.infradead.org,
kernel@pengutronix.de, linux-clk@vger.kernel.org,
rvisaval@xilinx.com
Subject: Re: [PATCH 00/12] soc: xilinx: vcu: Convert driver to clock provider
Date: Mon, 21 Dec 2020 10:19:59 +0100 [thread overview]
Message-ID: <20201221091959.GB22033@pengutronix.de> (raw)
In-Reply-To: <160808624070.1580929.14530755991373122337@swboyd.mtv.corp.google.com>
On Tue, 15 Dec 2020 18:37:20 -0800, Stephen Boyd wrote:
> Quoting Michael Tretter (2020-12-15 03:56:32)
> > On Sat, 12 Dec 2020 21:50:00 -0800, Stephen Boyd wrote:
> > > Quoting Michael Tretter (2020-11-15 23:55:20)
> > > > Hello,
> > > >
> > > > the xlnx_vcu soc driver is actually a clock provider of a PLL and four output
> > > > clocks created from the PLL via dividers.
> > > >
> > > > This series reworks the xlnx_vcu driver to use the common clock framework to
> > > > enable other drivers to use the clocks. I originally posted a series to expose
> > > > the output clocks as fixed clocks [0]. This series now implements the full
> > > > tree from the PLL to the output clocks. Therefore, I am sending a separate
> > > > series that focuses on the clocks, but it depends on v4 of the previous series
> > > > [1].
> > >
> > > After this series is this anything besides a clk provider? If it's only
> > > providing clks it would make sense to move the driver into drivers/clk/
> > >
> >
> > 1. The driver is also responsible for resetting the entire VCU (the
> > VCU_GASKET_INIT register). This isn't something that an individual encoder or
> > decoder driver should be doing. However, other clock drivers also implement a
> > reset controller.
>
> Right.
>
> >
> > 2. There are several registers for AXI performance monitoring in the VCU
> > System-Level Control register space. Right now, these are not used by the
> > driver and I have no plans to actually use them, but this might be an argument
> > against the move.
>
> I suppose if/when that happens we can have a small parent driver that
> probes the compatible string and makes two child platform devices, one
> for the clk part and one for the PMU? That would let us keep the code in
> drivers/clk/ for ease of find-ability. This assumes that the PMU
> registers don't overlap with the clk/reset registers. We usually put the
> clk and reset controllers together if they use the same registers and
> need to make sure the frameworks don't stomp on each other.
>
> >
> > I think it is OK to move the driver to drivers/clk/, but I don't have a strong
> > opinion about it.
> >
>
> Ok. I'm not too strong on it either, but drivers/soc/ is sort of a
> dumping ground for random soc things. I'm not looking at it closely but
> if the driver is in drivers/clk/ I'd be more inclined to look after the
> clk bits.
OK, I will move the driver to drivers/clk/xilinx/
Michael
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-12-21 10:24 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-16 7:55 [PATCH 00/12] soc: xilinx: vcu: Convert driver to clock provider Michael Tretter
2020-11-16 7:55 ` Michael Tretter
2020-11-16 7:55 ` [PATCH 01/12] ARM: dts: define indexes for output clocks Michael Tretter
2020-11-16 7:55 ` Michael Tretter
2020-12-02 14:33 ` Michal Simek
2020-12-02 14:33 ` Michal Simek
2020-12-07 19:21 ` Rob Herring
2020-12-07 19:21 ` Rob Herring
2020-12-13 5:44 ` Stephen Boyd
2020-12-13 5:44 ` Stephen Boyd
2020-11-16 7:55 ` [PATCH 02/12] clk: divider: fix initialization with parent_hw Michael Tretter
2020-11-16 7:55 ` Michael Tretter
2020-12-02 14:28 ` Michal Simek
2020-12-02 14:28 ` Michal Simek
2020-12-13 5:42 ` Stephen Boyd
2020-12-13 5:42 ` Stephen Boyd
2020-11-16 7:55 ` [PATCH 03/12] soc: xilinx: vcu: drop coreclk from struct xlnx_vcu Michael Tretter
2020-11-16 7:55 ` Michael Tretter
2020-11-16 7:55 ` [PATCH 04/12] soc: xilinx: vcu: add helper to wait for PLL locked Michael Tretter
2020-11-16 7:55 ` Michael Tretter
2020-11-16 7:55 ` [PATCH 05/12] soc: xilinx: vcu: add helpers for configuring PLL Michael Tretter
2020-11-16 7:55 ` Michael Tretter
2020-11-16 7:55 ` [PATCH 06/12] soc: xilinx: vcu: implement PLL disable Michael Tretter
2020-11-16 7:55 ` Michael Tretter
2020-11-16 7:55 ` [PATCH 07/12] soc: xilinx: vcu: register PLL as fixed rate clock Michael Tretter
2020-11-16 7:55 ` Michael Tretter
2020-12-02 14:41 ` Michal Simek
2020-12-02 14:41 ` Michal Simek
2020-11-16 7:55 ` [PATCH 08/12] soc: xilinx: vcu: implement clock provider for output clocks Michael Tretter
2020-11-16 7:55 ` Michael Tretter
2020-12-02 14:49 ` Michal Simek
2020-12-02 14:49 ` Michal Simek
2020-12-13 5:55 ` Stephen Boyd
2020-12-13 5:55 ` Stephen Boyd
2020-12-15 11:38 ` Michael Tretter
2020-12-15 11:38 ` Michael Tretter
2020-12-16 1:09 ` Stephen Boyd
2020-12-16 1:09 ` Stephen Boyd
2020-12-21 9:18 ` Michael Tretter
2020-12-21 9:18 ` Michael Tretter
2020-11-16 7:55 ` [PATCH 09/12] soc: xilinx: vcu: make pll post divider explicit Michael Tretter
2020-11-16 7:55 ` Michael Tretter
2020-12-02 14:51 ` Michal Simek
2020-12-02 14:51 ` Michal Simek
2020-11-16 7:55 ` [PATCH 10/12] soc: xilinx: vcu: make the PLL configurable Michael Tretter
2020-11-16 7:55 ` Michael Tretter
2020-12-02 14:54 ` Michal Simek
2020-12-02 14:54 ` Michal Simek
2020-11-16 7:55 ` [PATCH 11/12] soc: xilinx: vcu: remove calculation of PLL configuration Michael Tretter
2020-11-16 7:55 ` Michael Tretter
2020-11-16 7:55 ` [PATCH 12/12] soc: xilinx: vcu: use bitfields for register definition Michael Tretter
2020-11-16 7:55 ` Michael Tretter
2020-12-13 5:47 ` Stephen Boyd
2020-12-13 5:47 ` Stephen Boyd
2020-12-03 7:46 ` [PATCH 00/12] soc: xilinx: vcu: Convert driver to clock provider Michal Simek
2020-12-03 7:46 ` Michal Simek
2020-12-03 9:00 ` Michael Tretter
2020-12-03 9:00 ` Michael Tretter
2020-12-03 9:14 ` Michal Simek
2020-12-03 9:14 ` Michal Simek
2020-12-13 5:50 ` Stephen Boyd
2020-12-13 5:50 ` Stephen Boyd
2020-12-15 11:56 ` Michael Tretter
2020-12-15 11:56 ` Michael Tretter
2020-12-16 2:37 ` Stephen Boyd
2020-12-16 2:37 ` Stephen Boyd
2020-12-21 9:19 ` Michael Tretter [this message]
2020-12-21 9:19 ` Michael Tretter
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=20201221091959.GB22033@pengutronix.de \
--to=m.tretter@pengutronix.de \
--cc=devicetree@vger.kernel.org \
--cc=dshah@xilinx.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=michals@xilinx.com \
--cc=mturquette@baylibre.com \
--cc=rajanv@xilinx.com \
--cc=robh+dt@kernel.org \
--cc=rvisaval@xilinx.com \
--cc=sboyd@kernel.org \
--cc=tejasp@xilinx.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.