* Re: [PATCH 1/5] iio: xoadc: augment DT bindings a bit
From: Bjorn Andersson @ 2017-03-26 4:57 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170318133358.22314-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Sat 18 Mar 06:33 PDT 2017, Linus Walleij wrote:
> In order to accommodate in a logical manner for the premuxed channels
> in PM8921 and the similarly addressed channels in later PMICs, we
> need a twocell arrangement with premux and analog mux setting as
> a tuple to uniquely identify a hardware channel.
>
> These bindings are not yet in use, so it should be find to augment
s/find/fine?
> them before we actually start using it in drivers and device trees.
>
> This scheme came out of lengthy discussions and reverse-engineering
> and reading of the few information sources we have.
>
As there's no documentation of how this works I find it quite important
to make something that is intuitive - so more than you and I can use
this binding. So I like this.
> Suggested-by: Björn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> .../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 117 ++++++++++++---------
> 1 file changed, 69 insertions(+), 48 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> index 53cd146d8096..680bb7a29dd5 100644
> --- a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> @@ -19,32 +19,42 @@ Required properties:
> with PMIC variant but is typically something like 2.2 or 1.8V.
>
> The following required properties are standard for IO channels, see
> -iio-bindings.txt for more details:
> +iio-bindings.txt for more details, but noitice that this particular
> +ADC has a special adressing scheme that require two cells for
> +identifying each ADC channel:
>
> -- #address-cells: should be set to <1>
> +- #address-cells: should be set to <2>, the first cell is the
> + prescaler (on PM8058) or premux (on PM8921) with two valid bits
> + so legal values are 0x00, 0x01 or 0x02. The second cell
> + is the main analog mux setting (0x00..0x0f). The combination
> + of prescaler/premux and analog mux uniquely addresses a hardware
> + channel on all systems.
>
> - #size-cells: should be set to <0>
>
> -- #io-channel-cells: should be set to <1>
> +- #io-channel-cells: should be set to <2>, again the cells are
> + precaler or premux followed by the analog muxing line.
>
> - interrupts: should refer to the parent PMIC interrupt controller
> and reference the proper ADC interrupt.
>
> Required subnodes:
>
> -The ADC channels are configured as subnodes of the ADC. Since some of
> -them are used for calibrating the ADC, these nodes are compulsory:
> +The ADC channels are configured as subnodes of the ADC.
>
> -adc-channel@c {
> - reg = <0x0c>;
> +Since some of them are used for calibrating the ADC, these nodes are
> +compulsory:
> +
> +adc-channel@0c {
Shouldn't the @ be followed by the value of the first cell in "reg"?
(Which will collide if we name them all "adc-channel").
> + reg = <0x00 0x0c>;
> };
>
> -adc-channel@d {
> - reg = <0x0d>;
> +adc-channel@0d {
> + reg = <0x00 0x0d>;
> };
>
> -adc-channel@f {
> - reg = <0x0f>;
> +adc-channel@0f {
> + reg = <0x00 0x0f>;
> };
>
> These three nodes are used for absolute and ratiometric calibration
> @@ -52,13 +62,26 @@ and only need to have these reg values: they are by hardware definition
> 1:1 ratio converters that sample 625, 1250 and 0 milliV and create
> an interpolation calibration for all other ADCs.
>
> -Optional subnodes: any channels other than channel 0x0c, 0x0d and
> -0x0f are optional.
> +Optional subnodes: any channels other than channels [0x00 0x0c],
> +[0x00 0x0d] and [0x00 0x0f] are optional.
>
> Required channel node properties:
>
> - reg: should contain the hardware channel number in the range
> - 0 .. 0x0f (4 bits). The hardware only supports 16 channels.
> + 0 .. 0xff (8 bits).
> +
> + On PM8058 the hardware only supports 16 channels, but we get the same
> + channels repeating with its input divided down by 1 or 3. Channels 00,
> + 10, 20, ... f0 are the raw values, 04, 14, 24 .. f4 are "unity" channels
> + divided by 1, and 08, 18, 28 .. f8 are channels divided by 3. Bits 0
> + and 1 of the channel index should always be 0.
> +
> + On PM8921 the hardware supports more than 16 channels through a complex
> + routing matrix using a premux, so 00, 10, 20 .. f0 are the basic raw
> + channels while another set of channels appear for 04, 14, 24 .. f4,
> + and again some of the same channels appear again divided down by 3
> + in 08, 18, 28 .. f8. Again bits 0 and 1 of the channel index should
> + always be 0.
While I believe documenting this is a good thing I do not think it adds
value to this binding document (other than showing Rob the absurdness of
the addressing scheme). Please consider moving it to the driver (haven't
checked how you commented it yet) and drop it from here.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH 2/3] firmware: qcom: scm: Expose download-mode control
From: Bjorn Andersson @ 2017-03-26 5:13 UTC (permalink / raw)
To: Rob Herring
Cc: Andy Gross, Stephen Boyd, Mark Rutland, David Brown,
Srinivas Kandagatla, linux-kernel, linux-arm-msm, linux-soc,
devicetree
In-Reply-To: <20170324150633.2s3o3kiecnoeo4qt@rob-hp-laptop>
On Fri 24 Mar 08:06 PDT 2017, Rob Herring wrote:
> On Fri, Mar 17, 2017 at 09:15:22PM -0700, Bjorn Andersson wrote:
[..]
> > diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
> > index 20f26fbce875..8467a181f22c 100644
> > --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
> > +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
> > @@ -18,6 +18,7 @@ Required properties:
> > * Core, iface, and bus clocks required for "qcom,scm"
> > - clock-names: Must contain "core" for the core clock, "iface" for the interface
> > clock and "bus" for the bus clock per the requirements of the compatible.
> > +- qcom,dload-mode-addr: Specifies the address for the download mode magic (optional)
>
> Size? 1 cell, 2 cell(, red cell, blue cell) or follows #addr-cells?
>
I believe this implementation only applies to the 64-bit systems, but
it's probably better to make it follow (or at least claim that it
follows) #address-cells.
I can update the description to include this.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH v3 2/4] iio: Documentation: Add max9611 sysfs documentation
From: Geert Uytterhoeven @ 2017-03-26 8:38 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Wolfram Sang, Magnus Damm, Laurent Pinchart, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald, Rob Herring,
Mark Rutland, linux-iio-u79uwXL29TY76Z2rM5mHXA, Linux-Renesas,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1490369323-13866-3-git-send-email-jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
On Fri, Mar 24, 2017 at 4:28 PM, Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org> wrote:
> Add documentation for max9611 driver.
> Document attributes describing value of shunt resistor installed between
> RS+ and RS- voltage sense inputs.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
> ---
> Documentation/ABI/testing/sysfs-bus-iio-adc-max9611 | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-max9611
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611 b/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611
> new file mode 100644
> index 0000000..9c60824
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611
> @@ -0,0 +1,16 @@
> +What: /sys/bus/iio/devices/iio:deviceX/in_shunt_resistor_power
> +Date: March 2017
> +KernelVersion: 4.12
> +Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +Description: The value of the shunt resistor used to compute power drain on
> + common input voltage pin (RS+). In micro Ohms.
> +
> +What: /sys/bus/iio/devices/iio:deviceX/in_shunt_resistor_current
> +Date: March 2017
> +KernelVersion: 4.12
> +Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +Description: The value of the shunt resistor used to compute current flowing
> + between RS+ and RS- voltage sense inputs. In micro Ohms.
I'd add a blank line here, to make it clear the following paragraph applies
to both attributes above.
> + This attributes describe a single physical component, exposed
These attributes
> + as two distinct attributes as it is used to calculate two
> + different values.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 09/23] MAINTAINERS: Add file patterns for infiniband device tree bindings
From: Geert Uytterhoeven @ 2017-03-26 8:45 UTC (permalink / raw)
To: Doug Ledford
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sean Hefty,
Hal Rosenstock, linux-rdma
In-Reply-To: <1490409626.2404.42.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hi Doug,
On Sat, Mar 25, 2017 at 3:40 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Sun, 2017-03-12 at 14:16 +0100, Geert Uytterhoeven wrote:
>> Submitters of device tree binding documentation may forget to CC
>> the subsystem maintainer if this is missing.
>>
>> Signed-off-by: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
>> Cc: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> Cc: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: Hal Rosenstock <hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> ---
>> Please apply this patch directly if you want to be involved in device
>> tree binding documentation for your subsystem.
>
> I assume this is going through someone else' tree since I only see
That wasn't my intention, though, cfr. the quoted paragraph above
("you" and "your subsystem").
> patch 09 of 23 and not the entire series. But, for this specific
> patch:
>
> Acked-by: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 4/4] arm64: dts: salvator-x: Add current sense amplifiers
From: Geert Uytterhoeven @ 2017-03-26 8:49 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Wolfram Sang, Magnus Damm, Laurent Pinchart, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald, Rob Herring,
Mark Rutland, linux-iio-u79uwXL29TY76Z2rM5mHXA, Linux-Renesas,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1490369323-13866-5-git-send-email-jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
Hi Jacopo,
On Fri, Mar 24, 2017 at 4:28 PM, Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org> wrote:
> Add device nodes for two Maxim max961x current sense amplifiers
> sensing VDD_08 and DVFS_08 lines.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] ARM: dts: am335x-evmsk: adjust mmc2 param to allow suspend
From: Reizer, Eyal @ 2017-03-26 8:53 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, Rob Herring,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1490517995-12895-1-git-send-email-eyalr-l0cyMroinI0@public.gmane.org>
mmc2 used for wl12xx was missing the keep-power-in suspend
parameter. As a result the board couldn't reach suspend state.
Signed-off-by: Eyal Reizer <eyalr-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/am335x-evmsk.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index 9e43c44..9ba4b18 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -672,6 +672,7 @@
ti,non-removable;
bus-width = <4>;
cap-power-off-card;
+ keep-power-in-suspend;
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins>;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v3 0/4] iio: adc: Maxim max9611 driver
From: Geert Uytterhoeven @ 2017-03-26 9:07 UTC (permalink / raw)
To: Jacopo Mondi, Jonathan Cameron
Cc: Wolfram Sang, Magnus Damm, Laurent Pinchart, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald, Rob Herring, Mark Rutland,
linux-iio, Linux-Renesas, devicetree@vger.kernel.org
In-Reply-To: <1490369323-13866-1-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo, Jonathan,
On Fri, Mar 24, 2017 at 4:28 PM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> Third round for Maxim max9611/max9612 high-side current sense amplifier driver.
>
> For reference, a simplified integration schematic drawing is here reported:
>
> ----o----/\/\/-----o-------|LOAD|---
> | shunt |
> ____|______________|___
> | RS+ RS- |
> | |-----gain-----| |
> | | |
> | | |
> |max9611 |->| ADC |===== I2c
> |______________________|
>
> public datasheet available at
> https://datasheets.maximintegrated.com/en/ds/MAX9611-MAX9612.pdf
>
> In v2 all channels whose values are calculated using parameters
> depending on the applied gain have been transformed in "processed" channels.
>
> In v3 fixed DT bindings to use a more generic name for ADC nodes, and shunt
> resistor description property.
>
> output reported from iio_info tool:
> iio:device0: max9611_vdd
> 6 channels found:
> voltage0: (input)
> 1 channel-specific attributes found:
> attr 0: input value: 4.085000000
> voltage1: (input)
> 3 channel-specific attributes found:
> attr 0: scale value: 14
> attr 1: offset value: 1
> attr 2: raw value: 59
> shunt: (input)
> 2 channel-specific attributes found:
> attr 0: resistor_power value: 5000
> attr 1: resistor_current value: 5000
> power: (input)
> 1 channel-specific attributes found:
> attr 0: input value: 663.404000000
> temp: (input)
> 2 channel-specific attributes found:
> attr 0: scale value: 0.480076812
> attr 1: raw value: 59
> current: (input)
> 1 channel-specific attributes found:
> attr 0: input value: 817.000000000
I'm a bit puzzled about Jonathan's request to have two separate attributes
for the single shunt resistor value. While they do apply to two calculated
channels, they're the same physical property, and can never be different.
Furthermore, in the above output they do not show up as attributes of the
"power" and "current" channels, but as attributes of a separate "shunt"
channel. Is that intentional?
For comparison, with ina226 on BayLibre ACME, which uses a similar
configuration, I get:
iio:device0: ina226
5 channels found:
voltage0: (input)
6 channel-specific attributes found:
attr 0: scale value: 0.002500000
attr 1: raw value: 979
attr 2: integration_time value: 0.001100
attr 3: index value: 0
attr 4: en value: 0
attr 5: type value: le:u16/16>>0
voltage1: (input)
6 channel-specific attributes found:
attr 0: integration_time value: 0.001100
attr 1: raw value: 4007
attr 2: scale value: 1.250000000
attr 3: en value: 0
attr 4: index value: 1
attr 5: type value: le:u16/16>>0
power2: (input)
5 channel-specific attributes found:
attr 0: raw value: 49
attr 1: scale value: 25.000000000
attr 2: index value: 2
attr 3: type value: le:u16/16>>0
attr 4: en value: 0
current3: (input)
5 channel-specific attributes found:
attr 0: scale value: 1
attr 1: raw value: 245
attr 2: type value: le:u16/16>>0
attr 3: index value: 3
attr 4: en value: 0
timestamp: (input)
3 channel-specific attributes found:
attr 0: type value: le:s64/64>>0
attr 1: index value: 4
attr 2: en value: 0
6 device-specific attributes found:
attr 0: in_oversampling_ratio value: 4
attr 1: in_shunt_resistor value: 10000
attr 2: in_allow_async_readout value: 0
attr 3: integration_time_available value: 0.000140
0.000204 0.000332 0.000588 0.001100 0.002116 0.004156 0.008244
attr 4: in_sampling_frequency value: 114
attr 5: in_active value: 1
(note that the last "in_active" property does not exist in the mainline
version of the driver).
Here the shunt resistor value is a (single) device-specific attribute, which
makes more sense to me, as in-se the shunt resistor value is not a property
of just the "current" and "power" channels, but a property of the (external)
device configuration.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* script to setup pipeline was Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline
From: Pavel Machek @ 2017-03-26 9:12 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Steve Longerbeam, Russell King - ARM Linux, mark.rutland,
andrew-ct.chen, minghsiu.tsai, nick, songjun.wu, Hans Verkuil,
shuah, devel, markus.heiser, laurent.pinchart+renesas,
robert.jarzmik, geert, p.zabel, linux-media, devicetree, kernel,
arnd, tiffany.lin, bparrot, robh+dt, horms+renesas, mchehab,
linux-arm-kernel, niklas.soderlund+renesas, gregkh, linux-kernel,
Sakari
In-Reply-To: <20170312185845.5c18ffd0@vento.lan>
[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]
Hi!
> > I do agree with you that MC places a lot of burden on the user to
> > attain a lot of knowledge of the system's architecture.
>
> Setting up the pipeline is not the hard part. One could write a
> script to do that.
Can you try to write that script? I believe it would solve big part of
the problem.
> > And my other point is, I think most people who have a need to work with
> > the media framework on a particular platform will likely already be
> > quite familiar with that platform.
>
> I disagree. The most popular platform device currently is Raspberry PI.
>
> I doubt that almost all owners of RPi + camera module know anything
> about MC. They just use Raspberry's official driver with just provides
> the V4L2 interface.
>
> I have a strong opinion that, for hardware like RPi, just the V4L2
> API is enough for more than 90% of the cases.
Maybe V4L2 API is enough for 90% of the users. But I don't believe
that means that we should provide compatibility. V4L2 API is not good
enough for complex devices, and if we can make RPi people fix
userspace... that's a good thing.
> > The media graph for imx6 is fairly self-explanatory in my opinion.
> > Yes that graph has to be generated, but just with a simple 'media-ctl
> > --print-dot', I don't see how that is difficult for the user.
>
> Again, IMHO, the problem is not how to setup the pipeline, but, instead,
> the need to forward controls to the subdevices.
>
> To use a camera, the user needs to set up a set of controls for the
> image to make sense (bright, contrast, focus, etc). If the driver
> doesn't forward those controls to the subdevs, an application like
> "camorama" won't actually work for real, as the user won't be able
> to adjust those parameters via GUI.
I believe this can be fixed in libv4l2.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/4] iio: adc: Maxim max9611 driver
From: Jonathan Cameron @ 2017-03-26 9:18 UTC (permalink / raw)
To: Geert Uytterhoeven, Jacopo Mondi, Jonathan Cameron
Cc: Wolfram Sang, Magnus Damm, Laurent Pinchart, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald, Rob Herring, Mark Rutland,
linux-iio, Linux-Renesas, devicetree@vger.kernel.org
In-Reply-To: <CAMuHMdWojCNtJBQxP6E+hdscCQ7U28RGWsPfhXidxJDu-aTQOw@mail.gmail.com>
On 26 March 2017 10:07:58 BST, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>Hi Jacopo, Jonathan,
>
>On Fri, Mar 24, 2017 at 4:28 PM, Jacopo Mondi
><jacopo+renesas@jmondi.org> wrote:
>> Third round for Maxim max9611/max9612 high-side current sense
>amplifier driver.
>>
>> For reference, a simplified integration schematic drawing is here
>reported:
>>
>> ----o----/\/\/-----o-------|LOAD|---
>> | shunt |
>> ____|______________|___
>> | RS+ RS- |
>> | |-----gain-----| |
>> | | |
>> | | |
>> |max9611 |->| ADC |===== I2c
>> |______________________|
>>
>> public datasheet available at
>> https://datasheets.maximintegrated.com/en/ds/MAX9611-MAX9612.pdf
>>
>> In v2 all channels whose values are calculated using parameters
>> depending on the applied gain have been transformed in "processed"
>channels.
>>
>> In v3 fixed DT bindings to use a more generic name for ADC nodes, and
>shunt
>> resistor description property.
>>
>> output reported from iio_info tool:
>> iio:device0: max9611_vdd
>> 6 channels found:
>> voltage0: (input)
>> 1 channel-specific attributes found:
>> attr 0: input value: 4.085000000
>> voltage1: (input)
>> 3 channel-specific attributes found:
>> attr 0: scale value: 14
>> attr 1: offset value: 1
>> attr 2: raw value: 59
>> shunt: (input)
>> 2 channel-specific attributes found:
>> attr 0: resistor_power value: 5000
>> attr 1: resistor_current value: 5000
>> power: (input)
>> 1 channel-specific attributes found:
>> attr 0: input value: 663.404000000
>> temp: (input)
>> 2 channel-specific attributes found:
>> attr 0: scale value: 0.480076812
>> attr 1: raw value: 59
>> current: (input)
>> 1 channel-specific attributes found:
>> attr 0: input value: 817.000000000
>
>I'm a bit puzzled about Jonathan's request to have two separate
>attributes
>for the single shunt resistor value. While they do apply to two
>calculated
>channels, they're the same physical property, and can never be
>different.
Yes but under abi any attribute with no channel as part of name applies to all input channels.
On the inside part kind of sensible as sort of applies to all.
Here we would have a shunt on the temperature channel...
>
>Furthermore, in the above output they do not show up as attributes of
>the
>"power" and "current" channels, but as attributes of a separate "shunt"
>channel. Is that intentional?
>
Shouldn't be own channels, naming currently wrong. I raised that in review.
>For comparison, with ina226 on BayLibre ACME, which uses a similar
>configuration, I get:
>
> iio:device0: ina226
> 5 channels found:
> voltage0: (input)
> 6 channel-specific attributes found:
> attr 0: scale value: 0.002500000
> attr 1: raw value: 979
> attr 2: integration_time value: 0.001100
> attr 3: index value: 0
> attr 4: en value: 0
> attr 5: type value: le:u16/16>>0
> voltage1: (input)
> 6 channel-specific attributes found:
> attr 0: integration_time value: 0.001100
> attr 1: raw value: 4007
> attr 2: scale value: 1.250000000
> attr 3: en value: 0
> attr 4: index value: 1
> attr 5: type value: le:u16/16>>0
> power2: (input)
> 5 channel-specific attributes found:
> attr 0: raw value: 49
> attr 1: scale value: 25.000000000
> attr 2: index value: 2
> attr 3: type value: le:u16/16>>0
> attr 4: en value: 0
> current3: (input)
> 5 channel-specific attributes found:
> attr 0: scale value: 1
> attr 1: raw value: 245
> attr 2: type value: le:u16/16>>0
> attr 3: index value: 3
> attr 4: en value: 0
> timestamp: (input)
> 3 channel-specific attributes found:
> attr 0: type value: le:s64/64>>0
> attr 1: index value: 4
> attr 2: en value: 0
> 6 device-specific attributes found:
> attr 0: in_oversampling_ratio value: 4
> attr 1: in_shunt_resistor value: 10000
> attr 2: in_allow_async_readout value: 0
> attr 3: integration_time_available value: 0.000140
>0.000204 0.000332 0.000588 0.001100 0.002116 0.004156 0.008244
> attr 4: in_sampling_frequency value: 114
> attr 5: in_active value: 1
>
>(note that the last "in_active" property does not exist in the mainline
> version of the driver).
>
>Here the shunt resistor value is a (single) device-specific attribute,
>which
>makes more sense to me, as in-se the shunt resistor value is not a
>property
>of just the "current" and "power" channels, but a property of the
>(external)
>device configuration.
Sort of but userspace will be dumb about it and apply it to all channels. Only reason this isn't
happening here is userspace doesn't know about it.
So arguably we got it slightly wrong here...
J
>
>Thanks!
>
>Gr{oetje,eeting}s,
>
> Geert
>
>--
>Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
>geert@linux-m68k.org
>
>In personal conversations with technical people, I call myself a
>hacker. But
>when I'm talking to journalists I just say "programmer" or something
>like that.
> -- Linus Torvalds
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: [PATCH v3 3/4] iio: adc: Add Maxim max9611 ADC driver
From: jacopo @ 2017-03-26 10:02 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Jacopo Mondi, geert-Td1EMuHUCqxL1ZNQvxDV9g,
wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <834f03d3-36d2-9b86-6b1e-04a23d440e10-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Hi Jonathan,
On Sat, Mar 25, 2017 at 05:37:52PM +0000, Jonathan Cameron wrote:
> On 25/03/17 17:21, jacopo wrote:
> > Hi Jonathan,
> > thanks for review
[snip]
> >>> +
> >>> + indio_dev->dev.parent = &client->dev;
> >>> + indio_dev->dev.of_node = client->dev.of_node;
> >>> + indio_dev->name = client->dev.of_node->name;
> >> What's this going to give for the name? Name in IIO is supposed to
> >> be an indication of the part rather than anything more explicit.
> >> That's not easily obtained from device tree directly...
> >>
> >
> > I used the one coming from device tree as otherwise device entries
> > have the same name, and I wanted to have it to inclued the unit
> > address (eg. adc@7c and not just adc)
> > But from you comment I guess it's fine just adc, so I'll change this
> > back to v1).
> Should be the part number - so max9611 or similar..
>
> You can query the device node details directly if you need to identify
> which is which.
That would not help, as I've been suggested to use a generic "adc" in
node name property.
I can hard-code "max9611" here. That would not help with the fact that
two chips will appear in userspace with the same name (and that's why
I wanted to have the unit address).
Otherwise I can do what Quentin is suggesting in his review of
AST2400: have different name for each compatible entry, so that this
will appear as either max9611 or max9612 in userspace
Thanks
j
> >
> > Thanks
> > j
> >
> >>> + indio_dev->modes = INDIO_DIRECT_MODE;
> >>> + indio_dev->info = &indio_info;
> >>> + indio_dev->channels = max9611_channels;
> >>> + indio_dev->num_channels = ARRAY_SIZE(max9611_channels);
> >>> +
> >>> + return devm_iio_device_register(&client->dev, indio_dev);
> >>> +}
> >>> +
> >>> +static const struct of_device_id max9611_of_table[] = {
> >>> + {.compatible = "maxim,max9611"},
> >>> + {.compatible = "maxim,max9612"},
> >>> + { },
> >>> +};
> >>> +
> >>> +MODULE_DEVICE_TABLE(of, max9611_of_table);
> >>> +
> >>> +static struct i2c_driver max9611_driver = {
> >>> + .driver = {
> >>> + .name = DRIVER_NAME,
> >>> + .owner = THIS_MODULE,
> >>> + .of_match_table = max9611_of_table,
> >>> + },
> >>> + .probe = max9611_probe,
> >>> +};
> >>> +module_i2c_driver(max9611_driver);
> >>> +
> >>> +MODULE_AUTHOR("Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>");
> >>> +MODULE_DESCRIPTION("Maxim max9611/12 current sense amplifier with 12bit ADC");
> >>> +MODULE_LICENSE("GPL v2");
> >>>
> >>
>
^ permalink raw reply
* Re: [PATCH v3 3/4] iio: adc: Add Maxim max9611 ADC driver
From: Jonathan Cameron @ 2017-03-26 10:23 UTC (permalink / raw)
To: jacopo
Cc: Jacopo Mondi, geert-Td1EMuHUCqxL1ZNQvxDV9g,
wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170326100239.GB5981@w540>
On 26/03/17 11:02, jacopo wrote:
> Hi Jonathan,
>
> On Sat, Mar 25, 2017 at 05:37:52PM +0000, Jonathan Cameron wrote:
>> On 25/03/17 17:21, jacopo wrote:
>>> Hi Jonathan,
>>> thanks for review
>
> [snip]
>
>>>>> +
>>>>> + indio_dev->dev.parent = &client->dev;
>>>>> + indio_dev->dev.of_node = client->dev.of_node;
>>>>> + indio_dev->name = client->dev.of_node->name;
>>>> What's this going to give for the name? Name in IIO is supposed to
>>>> be an indication of the part rather than anything more explicit.
>>>> That's not easily obtained from device tree directly...
>>>>
>>>
>>> I used the one coming from device tree as otherwise device entries
>>> have the same name, and I wanted to have it to inclued the unit
>>> address (eg. adc@7c and not just adc)
>>> But from you comment I guess it's fine just adc, so I'll change this
>>> back to v1).
>> Should be the part number - so max9611 or similar..
>>
>> You can query the device node details directly if you need to identify
>> which is which.
>
> That would not help, as I've been suggested to use a generic "adc" in
> node name property.
>
> I can hard-code "max9611" here. That would not help with the fact that
> two chips will appear in userspace with the same name (and that's why
> I wanted to have the unit address)
This is just a convenience dating way back before device tree. The one
thing it is still useful for is identifying when a part is different from
what the devicetree suggests - particularly when fairly generic compatibles
are in use but the device has an ID register. In a lot of consumer
boards these chips get changed to 'newer' (i.e. cheaper) versions that
are more or less compatible without any devicetree changes (or
longer ago without it being reflected in difference in the board file).
If you want to know the device tree node it is easily available via
/sys/bus/iio/device/iio:deviceX/uevent for example.
Having just fired up a beaglebone blue I have:
root@beaglebone:/sys/bus/iio/devices/iio:device0# cat uevent
MAJOR=243
MINOR=0
DEVNAME=iio:device0
DEVTYPE=iio_device
OF_NAME=mpu9150
OF_FULLNAME=/ocp/i2c@4819c000/mpu9150@68
OF_COMPATIBLE_0=invensense,mpu9150
OF_COMPATIBLE_N=1
root@beaglebone:/sys/bus/iio/devices/iio:device0# cat name
mpu9150
Which is actually lying as it's a 9250 - my fault in this case as I
wrote the relevant bit of the device tree and it's not mainlined yet.
root@beaglebone:/sys/bus/iio/devices/iio:device1# cat uevent
MAJOR=243
MINOR=1
DEVNAME=iio:device1
DEVTYPE=iio_device
OF_NAME=bmp280
OF_FULLNAME=/ocp/i2c@4819c000/bmp280@76
OF_COMPATIBLE_0=bosch,bmp280
OF_COMPATIBLE_N=1
root@beaglebone:/sys/bus/iio/devices/iio:device1# cat name
bmp280
root@beaglebone:/sys/bus/iio/devices/iio:device2# cat uevent
MAJOR=243
MINOR=2
DEVNAME=iio:device2
DEVTYPE=iio_device
OF_NAME=adc
OF_FULLNAME=/ocp/tscadc@44e0d000/adc
OF_COMPATIBLE_0=ti,am3359-adc
OF_COMPATIBLE_N=1
root@beaglebone:/sys/bus/iio/devices/iio:device2# cat name
TI-am335x-adc
root@beaglebone:/sys/bus/iio/devices/iio:device3# cat uevent
MAJOR=243
MINOR=3
DEVNAME=iio:device3
DEVTYPE=iio_device
OF_NAME=ax8975
OF_FULLNAME=/ocp/i2c@4819c000/mpu9150@68/i2c-gate/ax8975@c
OF_COMPATIBLE_0=ak,ak8975
OF_COMPATIBLE_N=1
root@beaglebone:/sys/bus/iio/devices/iio:device3# cat name
ak8975
So all the info you could possibly want in in userspace is
available without using the name attribute - even down to
the complex nature of the path to that ak8975.
At various points in the past submitters have put drivers
in with the devicetree node or other bus related naming
and we haven't always picked up on it in review.
As we can't break userspace ABI not much we can do about it
now unfortunately.
Mind you, this has reminded me that I need to fix that mpu9150
case above before anyone mainlines the devicetree for the blue.
>
> Otherwise I can do what Quentin is suggesting in his review of
> AST2400: have different name for each compatible entry, so that this
> will appear as either max9611 or max9612 in userspace
>
That's ideal. It should be as specific as we can make it.
> Thanks
> j
>
>>>
>>> Thanks
>>> j
>>>
>>>>> + indio_dev->modes = INDIO_DIRECT_MODE;
>>>>> + indio_dev->info = &indio_info;
>>>>> + indio_dev->channels = max9611_channels;
>>>>> + indio_dev->num_channels = ARRAY_SIZE(max9611_channels);
>>>>> +
>>>>> + return devm_iio_device_register(&client->dev, indio_dev);
>>>>> +}
>>>>> +
>>>>> +static const struct of_device_id max9611_of_table[] = {
>>>>> + {.compatible = "maxim,max9611"},
>>>>> + {.compatible = "maxim,max9612"},
>>>>> + { },
>>>>> +};
>>>>> +
>>>>> +MODULE_DEVICE_TABLE(of, max9611_of_table);
>>>>> +
>>>>> +static struct i2c_driver max9611_driver = {
>>>>> + .driver = {
>>>>> + .name = DRIVER_NAME,
>>>>> + .owner = THIS_MODULE,
>>>>> + .of_match_table = max9611_of_table,
>>>>> + },
>>>>> + .probe = max9611_probe,
>>>>> +};
>>>>> +module_i2c_driver(max9611_driver);
>>>>> +
>>>>> +MODULE_AUTHOR("Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>");
>>>>> +MODULE_DESCRIPTION("Maxim max9611/12 current sense amplifier with 12bit ADC");
>>>>> +MODULE_LICENSE("GPL v2");
>>>>>
>>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 0/2] iio:imu:mpu6050 update bindings and add mpu9250 support.
From: Jonathan Cameron @ 2017-03-26 11:10 UTC (permalink / raw)
To: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Mark.Rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
Jonathan Cameron
The bindings for this driver are somewhat lagging the current situation.
I have update the existing binding for i2c parts, but not added the spi
binding as yet. That can follow later.
The main purpose of this series was to add explicit support for the mpu9250,
mostly to avoid the log message that the whoami value does match.
It's also more inituitive to support the part explicitly than to rely on
people reading the datasheet to see they actually have an mpu6500 and ak8975 in
a SIP.
If no one else does the SPI binding doc in the near future I'll get to it
eventually.
Jonathan
Jonathan Cameron (2):
iio:imu:mpu6050 update i2c bindings to reflect i2c-gate and supported
parts
iio:imu:mpu6050 add explicit mpu9250 support
.../devicetree/bindings/iio/imu/inv_mpu6050.txt | 23 ++++++++++++++++++++--
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 6 ++++++
drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 5 +++++
drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 2 ++
drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c | 1 +
5 files changed, 35 insertions(+), 2 deletions(-)
--
2.12.0
^ permalink raw reply
* [PATCH 1/2] iio:imu:mpu6050 update i2c bindings to reflect i2c-gate and supported parts
From: Jonathan Cameron @ 2017-03-26 11:10 UTC (permalink / raw)
To: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Mark.Rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
Jonathan Cameron
In-Reply-To: <20170326111100.2571-1-jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
These bindings are somewhat lagging the state of the driver. The i2c-gate
bindings are documented elsewhere, but it seems sensible to at least have
an example and cross reference in here. SPI bindings will need to be the
subject of a future patch.
Signed-off-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/iio/imu/inv_mpu6050.txt | 23 ++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt b/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt
index a9fc11e43b45..e18e04f3c6f4 100644
--- a/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt
+++ b/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt
@@ -3,14 +3,17 @@ InvenSense MPU-6050 Six-Axis (Gyro + Accelerometer) MEMS MotionTracking Device
http://www.invensense.com/mems/gyro/mpu6050.html
Required properties:
- - compatible : should be "invensense,mpu6050"
+ - compatible : should be "invensense,mpu6050", "invensense,mpu6500",
+ "invensense,mpu9150" or "invensense,icm20608"
- reg : the I2C address of the sensor
- interrupt-parent : should be the phandle for the interrupt controller
- interrupts : interrupt mapping for GPIO IRQ
Optional properties:
- mount-matrix: an optional 3x3 mounting rotation matrix
-
+ - i2c-gate node. These devices also support an auxiliary i2c bus. This is
+ simple enough to be described using the i2c-gate binding. See
+ i2c/i2c-gate.txt for more details.
Example:
mpu6050@68 {
@@ -28,3 +31,19 @@ Example:
"0", /* y2 */
"0.984807753012208"; /* z2 */
};
+
+
+ mpu9250@68 {
+ compatible = "invensense,mpu9250";
+ reg = <0x68>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <21 1>;
+ i2c-gate {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ax8975@c {
+ compatible = "ak,ak8975";
+ reg = <0x0c>;
+ };
+ };
+ };
--
2.12.0
^ permalink raw reply related
* [PATCH 2/2] iio:imu:mpu6050 add explicit mpu9250 support
From: Jonathan Cameron @ 2017-03-26 11:11 UTC (permalink / raw)
To: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Mark.Rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
Jonathan Cameron
In-Reply-To: <20170326111100.2571-1-jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
The mpu9250 is a SIP containing an mpu6500 and an ak8975. If this was all
there was too it there would be no need for explicit handling in the driver.
Arguably the bindings would also only reflect the presence of an mpu6500 with
the ak8975 hanging off it, as the kernel doesn't care that they are in one
package.
However, the WHOAMI value changes as well so best to add explicit support.
Signed-off-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt | 2 +-
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 6 ++++++
drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 5 +++++
drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 2 ++
drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c | 1 +
5 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt b/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt
index e18e04f3c6f4..10c1abdcc34d 100644
--- a/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt
+++ b/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt
@@ -4,7 +4,7 @@ http://www.invensense.com/mems/gyro/mpu6050.html
Required properties:
- compatible : should be "invensense,mpu6050", "invensense,mpu6500",
- "invensense,mpu9150" or "invensense,icm20608"
+ "invensense,mpu9150", "invensense,mpu9250" or "invensense,icm20608"
- reg : the I2C address of the sensor
- interrupt-parent : should be the phandle for the interrupt controller
- interrupts : interrupt mapping for GPIO IRQ
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
index b9fcbf18aa99..96dabbd2f004 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
@@ -114,6 +114,12 @@ static const struct inv_mpu6050_hw hw_info[] = {
.config = &chip_config_6050,
},
{
+ .whoami = INV_MPU9250_WHOAMI_VALUE,
+ .name = "MPU9250",
+ .reg = ®_set_6500,
+ .config = &chip_config_6050,
+ },
+ {
.whoami = INV_ICM20608_WHOAMI_VALUE,
.name = "ICM20608",
.reg = ®_set_6500,
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
index a8e6330cb906..64b5f5b92200 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
@@ -178,6 +178,7 @@ static const struct i2c_device_id inv_mpu_id[] = {
{"mpu6050", INV_MPU6050},
{"mpu6500", INV_MPU6500},
{"mpu9150", INV_MPU9150},
+ {"mpu9250", INV_MPU9250},
{"icm20608", INV_ICM20608},
{}
};
@@ -198,6 +199,10 @@ static const struct of_device_id inv_of_match[] = {
.data = (void *)INV_MPU9150
},
{
+ .compatible = "invensense,mpu9250",
+ .data = (void *)INV_MPU9250
+ },
+ {
.compatible = "invensense,icm20608",
.data = (void *)INV_ICM20608
},
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
index f0e8c5dd9fae..ef13de7a2c20 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
@@ -70,6 +70,7 @@ enum inv_devices {
INV_MPU6500,
INV_MPU6000,
INV_MPU9150,
+ INV_MPU9250,
INV_ICM20608,
INV_NUM_PARTS
};
@@ -226,6 +227,7 @@ struct inv_mpu6050_state {
#define INV_MPU6050_WHOAMI_VALUE 0x68
#define INV_MPU6500_WHOAMI_VALUE 0x70
#define INV_MPU9150_WHOAMI_VALUE 0x68
+#define INV_MPU9250_WHOAMI_VALUE 0x71
#define INV_ICM20608_WHOAMI_VALUE 0xAF
/* scan element definition */
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c
index 6e6476dfa188..74506e5ac0db 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c
@@ -82,6 +82,7 @@ static const struct spi_device_id inv_mpu_id[] = {
{"mpu6000", INV_MPU6000},
{"mpu6500", INV_MPU6500},
{"mpu9150", INV_MPU9150},
+ {"mpu9250", INV_MPU9250},
{"icm20608", INV_ICM20608},
{}
};
--
2.12.0
^ permalink raw reply related
* Re: [PATCH v2 1/5] dt-bindings: update device tree binding for Allwinner PRCM CCUs
From: Maxime Ripard @ 2017-03-26 13:10 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
In-Reply-To: <997781490224623-6UiXEAGCWRVxpj1cXAZ9Bg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 5263 bytes --]
On Thu, Mar 23, 2017 at 07:17:03AM +0800, Icenowy Zheng wrote:
>
>
> 23.03.2017, 04:09, "Maxime Ripard" <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>:
> > On Wed, Mar 22, 2017 at 02:22:22AM +0800, Icenowy Zheng wrote:
> >> 21.03.2017, 15:41, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> >> > On Thu, Mar 16, 2017 at 01:28:04AM +0800, Icenowy Zheng wrote:
> >> >> Many Allwinner SoCs after A31 have a CCU in PRCM block.
> >> >>
> >> >> Give the ones on H3 and A64 compatible strings.
> >> >>
> >> >> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> >> >> ---
> >> >> Changes in v2:
> >> >> - Add iosc for R_CCU's on H3/A64. (A31, A23 and A33 seem to have different
> >> >> clock for mux 3 of ar100 clk. Investgations are needed for them.)
> >> >>
> >> >> Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 18 +++++++++++++++++-
> >> >> 1 file changed, 17 insertions(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
> >> >> index 68512aa398a9..4a4addff595d 100644
> >> >> --- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
> >> >> +++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
> >> >> @@ -7,9 +7,11 @@ Required properties :
> >> >> - "allwinner,sun8i-a23-ccu"
> >> >> - "allwinner,sun8i-a33-ccu"
> >> >> - "allwinner,sun8i-h3-ccu"
> >> >> + - "allwinner,sun8i-h3-r-ccu"
> >> >> - "allwinner,sun8i-v3s-ccu"
> >> >> - "allwinner,sun9i-a80-ccu"
> >> >> - "allwinner,sun50i-a64-ccu"
> >> >> + - "allwinner,sun50i-a64-r-ccu"
> >> >> - "allwinner,sun50i-h5-ccu"
> >> >>
> >> >> - reg: Must contain the registers base address and length
> >> >> @@ -20,7 +22,11 @@ Required properties :
> >> >> - #clock-cells : must contain 1
> >> >> - #reset-cells : must contain 1
> >> >>
> >> >> -Example:
> >> >> +For the PRCM CCUs on H3/A64, one more clock is needed:
> >> >> +- "iosc": another frequency oscillator used for CPUS (usually at 32000Hz,
> >> >> + not the same with losc)
> >> >
> >> > This is called the internal oscillator in the datasheet, it would
> >> > probably make more sense to call it that way in the documentation too.
> >> >
> >> > This oscillator seems to be clocked at 16MHz, so we should represent
> >> > it as such.
> >> >
> >> > And I'm wondering, are you *sure* that it's fed directly from the
> >> > internal oscillator, or goes through the registers in the RTC, with
> >> > the 32 divider and 16 prescaler by default that makes it at roughly
> >> > the same rate (31.25kHz).
> >>
> >> In fact I know nothing about it -- I only represented the code in BSP
> >> clock driver.
> >>
> >> The mux value 3 varies from SoC to SoC. For A64/H5 it's 32000,
> >> for A33 it's 667000 (seems to be directly the internal OSC, as the
> >> user manual says the internal OSC is 600~700kHz; but it's named
> >> cpuosc rather than iosc in A33 BSP clock driver); for A80 it's even
> >> PLL_AUDIO.
> >
> > Where are you getting those info from?
> >
> > As far as I know, the A33 PRCM takes the hosc, losc, pll6 and CPU
> > (internal) oscillator:
> > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw5.c#L508
> >
> > The H3 takes the hosc and losc:
> > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw7.c#L379
> >
> > The A80 takes the hosc and losc:
> > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun9iw1.c#L281
> >
> > The A64 takes the hosc, losc, pll-periph0 and the iosc, which indeed
> > seems to be fed from the internal oscillator with the divider in the
> > RTC:
> > https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65-bsp2.0/arch/arm64/boot/dts/sun50iw1p1-clk.dtsi#L19
> > https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65-bsp2.0/drivers/clk/sunxi/clk-sun50iw1.c#L603
>
> But then in sunxi_init_clocks function, the iosc clock is initialized
> as a fixed clock with 32000Hz.
>
> The clock node in BSP device tree have a compatible of
> allwinner,fixed-clock, but not fixed-clock, which makes it not able
> to be really probed.
That clock is registered:
https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65-bsp2.0/drivers/clk/sunxi/clk-sun50iw1.c#L1193
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: clearfog: keep dts alphabetically ordered
From: Andrew Lunn @ 2017-03-26 14:02 UTC (permalink / raw)
To: Russell King
Cc: Mark Rutland, devicetree, Jason Cooper, Rob Herring,
Gregory Clement, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <E1crlBu-0002Gp-V4@rmk-PC.armlinux.org.uk>
On Sat, Mar 25, 2017 at 12:53:10PM +0000, Russell King wrote:
> Keep the clearfog DTS file ordered alphabetically - Florian placed the
> MDIO entry after pinctrl, which mis-orders the file.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline
From: Laurent Pinchart @ 2017-03-26 16:41 UTC (permalink / raw)
To: Pavel Machek
Cc: mark.rutland, andrew-ct.chen, minghsiu.tsai, sakari.ailus, nick,
songjun.wu, Hans Verkuil, Steve Longerbeam, robert.jarzmik,
markus.heiser, laurent.pinchart+renesas, g, shuah,
Russell King - ARM Linux, Mauro Carvalho Chehab, devel, geert,
Steve Longerbeam, linux-media, devicetree, kernel, arnd, mchehab,
bparrot, robh+dt, horms+renesas, tiffany.lin, Jacek Anaszewski,
linux-arm-kernel, niklas.soderlund+renesas, gregkh
In-Reply-To: <20170314182635.GA3744@amd>
Hi Pavel,
On Tuesday 14 Mar 2017 19:26:35 Pavel Machek wrote:
> Hi!
>
> >> Mid-layer is difficult... there are _hundreds_ of possible
> >> pipeline setups. If it should live in kernel or in userspace is a
> >> question... but I don't think having it in kernel helps in any way.
> >
> > Mid-layer is difficult, because we either need to feed some
> > library with knowledge for all kernel drivers or we need to improve
> > the MC API to provide more details.
> >
> > For example, several drivers used to expose entities via the
> > generic MEDIA_ENT_T_DEVNODE to represent entities of different
> >
> > types. See, for example, entities 1, 5 and 7 (and others) at:
> > > https://mchehab.fedorapeople.org/mc-next-gen/igepv2_omap3isp.png
>
> Well... we provide enough information, so that device-specific code
> does not have to be in kernel.
>
> There are few types of ENT_T_DEVNODE there. "ISP CCP2" does not really
> provide any functionality to the user. It just has to be there,
> because the pipeline needs to be connected. "ISP Preview" provides
> format conversion. "ISP Resizer" provides rescaling.
>
> I'm not sure if it ever makes sense to use "ISP Preview
> output". Normally you take data for display from "ISP Resizer
> output". (Would there be some power advantage from that?)
There was a bug on the preview engine to resizer hardware bus in OMAP34xx that
required capturing data from the preview engine output and performing the
scaling in memory-to-memory mode in some cases. You can also capture at the
preview engine output if you don't need scaling, or if you want to render on
the image before scaling (to draw pieces of a GUI for instance). There could
be other use cases.
> > A device-specific code could either be hardcoding the entity number
> > or checking for the entity strings to add some logic to setup
> > controls on those "unknown" entities, a generic app won't be able
> > to do anything with them, as it doesn't know what function(s) such
> > entity provide.
>
> Generic app should know if it wants RGGB10 data, then it can use "ISP
> CCDC output", or if it wants "cooked" data suitable for display, then
> it wants to use "ISP Resizer output". Once application knows what
> output it wants, there's just one path through the system. So being
> able to tell the ENT_T_DEVNODEs apart does not seem to be critical.
>
> OTOH, for useful camera application, different paths are needed at
> different phases.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline
From: Laurent Pinchart @ 2017-03-26 16:44 UTC (permalink / raw)
To: Hans Verkuil
Cc: Mauro Carvalho Chehab, Sakari Ailus, Russell King - ARM Linux,
Steve Longerbeam, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, fabio.estevam-3arQi8VN3Tc,
mchehab-DgEjT+Ai2ygdnm+yROfE0A, nick-gcszYUEDH4VrovVCs/uTlw,
markus.heiser-m1Uo1GnMJf0b1SvskN2V4Q,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw,
bparrot-l0cyMroinI0, geert-Td1EMuHUCqxL1ZNQvxDV9g,
arnd-r2nGTMty4D4, sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w,
minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w,
tiffany.lin-NuS5LvNUpcJWk0Htik3J/w,
jean-christophe.trotin-qxv4g6HH51o,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw,
robert.jarzmik-GANU6spQydw, songjun.wu-UWL1GkI3JZL3oGB3hsPCZA,
andrew-ct.chen-NuS5LvNUpcJWk0Htik3J/w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
shuah-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <e0a6c60b-1735-de0b-21f4-d8c3f4b3f10f-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
Hi Hans,
On Tuesday 14 Mar 2017 08:55:36 Hans Verkuil wrote:
> On 03/14/2017 04:45 AM, Mauro Carvalho Chehab wrote:
> > Hi Sakari,
> >
> > I started preparing a long argument about it, but gave up in favor of a
> > simpler one.
> >
> > Em Mon, 13 Mar 2017 14:46:22 +0200 Sakari Ailus escreveu:
> >> Drivers are written to support hardware, not particular use case.
> >
> > No, it is just the reverse: drivers and hardware are developed to
> > support use cases.
> >
> > Btw, you should remember that the hardware is the full board, not just the
> > SoC. In practice, the board do limit the use cases: several provide a
> > single physical CSI connector, allowing just one sensor.
> >
> >>> This situation is there since 2009. If I remember well, you tried to
> >>> write such generic plugin in the past, but never finished it, apparently
> >>> because it is too complex. Others tried too over the years.
> >>
> >> I'd argue I know better what happened with that attempt than you do. I
> >> had a prototype of a generic pipeline configuration library but due to
> >> various reasons I haven't been able to continue working on that since
> >> around 2012.
> > ...
> >
> >>> The last trial was done by Jacek, trying to cover just the exynos4
> >>> driver. Yet, even such limited scope plugin was not good enough, as it
> >>> was never merged upstream. Currently, there's no such plugins upstream.
> >>>
> >>> If we can't even merge a plugin that solves it for just *one* driver,
> >>> I have no hope that we'll be able to do it for the generic case.
> >>
> >> I believe Jacek ceased to work on that plugin in his day job; other than
> >> that, there are some matters left to be addressed in his latest patchset.
> >
> > The two above basically summaries the issue: the task of doing a generic
> > plugin on userspace, even for a single driver is complex enough to
> > not cover within a reasonable timeline.
> >
> > From 2009 to 2012, you were working on it, but didn't finish it.
> >
> > Apparently, nobody worked on it between 2013-2014 (but I may be wrong, as
> > I didn't check when the generic plugin interface was added to libv4l).
> >
> > In the case of Jacek's work, the first patch I was able to find was
> >
> > written in Oct, 2014:
> > https://patchwork.kernel.org/patch/5098111/
> > (not sure what happened with the version 1).
> >
> > The last e-mail about this subject was issued in Dec, 2016.
> >
> > In summary, you had this on your task for 3 years for an OMAP3
> > plugin (where you have a good expertise), and Jacek for 2 years,
> > for Exynos 4, where he should also have a good knowledge.
> >
> > Yet, with all that efforts, no concrete results were achieved, as none
> > of the plugins got merged.
> >
> > Even if they were merged, if we keep the same mean time to develop a
> > libv4l plugin, that would mean that a plugin for i.MX6 could take 2-3
> > years to be developed.
> >
> > There's a clear message on it:
> > - we shouldn't keep pushing for a solution via libv4l.
>
> Or:
> - userspace plugin development had a very a low priority and
> never got the attention it needed.
>
> I know that's *my* reason. I rarely if ever looked at it. I always assumed
> Sakari and/or Laurent would look at it. If this reason is also valid for
> Sakari and Laurent, then it is no wonder nothing has happened in all that
> time.
The reason is also valid for me. I'd really love to work on the userspace
side, but I just can't find time at the moment.
> We're all very driver-development-driven, and userspace gets very little
> attention in general. So before just throwing in the towel we should take
> a good look at the reasons why there has been little or no development: is
> it because of fundamental design defects, or because nobody paid attention
> to it?
>
> I strongly suspect it is the latter.
>
> In addition, I suspect end-users of these complex devices don't really care
> about a plugin: they want full control and won't typically use generic
> applications. If they would need support for that, we'd have seen much more
> interest. The main reason for having a plugin is to simplify testing and
> if this is going to be used on cheap hobbyist devkits.
>
> An additional complication is simply that it is hard to find fully supported
> MC hardware. omap3 boards are hard to find these days, renesas boards are
> not easy to get, freescale isn't the most popular either. Allwinner,
> mediatek, amlogic, broadcom and qualcomm all have closed source
> implementations or no implementation at all.
>
> I know it took me a very long time before I had a working omap3.
>
> So I am not at all surprised that little progress has been made.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 0/8] pinctrl: meson: add audio output pins
From: Jerome Brunet @ 2017-03-26 17:19 UTC (permalink / raw)
To: Linus Walleij, Carlo Caione, Kevin Hilman
Cc: Jerome Brunet, linux-gpio, linux-arm-kernel, linux-amlogic,
devicetree, linux-kernel
This patchset adds the pinctrl definition and the related device-tree
bindings of the i2s output and spdif output pins on the meson gxbb and
gxl SoCs.
This is part of the ongoing work to bring audio output support on the
meson family. It was tested on the gxbb p200 and gxl p230.
Changes since v1: [0]
* add a few comments in the changelog
* patched rebased on pinctrl/for-next + Neil patch on missing pins [1]
[0]: https://marc.info/?i=20170323165101.29262-1-jbrunet%40baylibre.com
[1]: https://marc.info/?i=20170323104112.16558-2-narmstrong%40baylibre.com
Jerome Brunet (8):
pinctrl: meson: gxbb: add i2s output pins
pinctrl: meson: gxbb: add spdif output pins
pinctrl: meson: gxl: add i2s output pins
pinctrl: meson: gxl: add spdif output pins
ARM64: dts: meson-gxbb: add i2s output pins
ARM64: dts: meson-gxbb: add spdif output pins
ARM64: dts: meson-gxl: add i2s output pins
ARM64: dts: meson-gxl: add spdif output pins
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 84 +++++++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 83 ++++++++++++++++++++++++++++
drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 49 +++++++++++++++++
drivers/pinctrl/meson/pinctrl-meson-gxl.c | 49 +++++++++++++++++
4 files changed, 265 insertions(+)
--
2.9.3
^ permalink raw reply
* [PATCH v2 5/8] ARM64: dts: meson-gxbb: add i2s output pins
From: Jerome Brunet @ 2017-03-26 17:19 UTC (permalink / raw)
To: Linus Walleij, Carlo Caione, Kevin Hilman
Cc: Jerome Brunet, linux-gpio, linux-arm-kernel, linux-amlogic,
devicetree, linux-kernel
In-Reply-To: <20170326171923.19269-1-jbrunet@baylibre.com>
Add EE and AO domains pins for the i2s output clocks and data to the gxbb
device tree.
Acked-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 63 +++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 34168a3b0dd1..a9cacbd6a1d6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -192,6 +192,48 @@
function = "pwm_ao_b";
};
};
+
+ i2s_am_clk_pins: i2s_am_clk {
+ mux {
+ groups = "i2s_am_clk";
+ function = "i2s_out_ao";
+ };
+ };
+
+ i2s_out_ao_clk_pins: i2s_out_ao_clk {
+ mux {
+ groups = "i2s_out_ao_clk";
+ function = "i2s_out_ao";
+ };
+ };
+
+ i2s_out_lr_clk_pins: i2s_out_lr_clk {
+ mux {
+ groups = "i2s_out_lr_clk";
+ function = "i2s_out_ao";
+ };
+ };
+
+ i2s_out_ch01_ao_pins: i2s_out_ch01_ao {
+ mux {
+ groups = "i2s_out_ch01_ao";
+ function = "i2s_out_ao";
+ };
+ };
+
+ i2s_out_ch23_ao_pins: i2s_out_ch23_ao {
+ mux {
+ groups = "i2s_out_ch23_ao";
+ function = "i2s_out_ao";
+ };
+ };
+
+ i2s_out_ch45_ao_pins: i2s_out_ch45_ao {
+ mux {
+ groups = "i2s_out_ch45_ao";
+ function = "i2s_out_ao";
+ };
+ };
};
};
@@ -432,6 +474,27 @@
function = "hdmi_i2c";
};
};
+
+ i2sout_ch23_y_pins: i2sout_ch23_y {
+ mux {
+ groups = "i2sout_ch23_y";
+ function = "i2s_out";
+ };
+ };
+
+ i2sout_ch45_y_pins: i2sout_ch45_y {
+ mux {
+ groups = "i2sout_ch45_y";
+ function = "i2s_out";
+ };
+ };
+
+ i2sout_ch67_y_pins: i2sout_ch67_y {
+ mux {
+ groups = "i2sout_ch67_y";
+ function = "i2s_out";
+ };
+ };
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 6/8] ARM64: dts: meson-gxbb: add spdif output pins
From: Jerome Brunet @ 2017-03-26 17:19 UTC (permalink / raw)
To: Linus Walleij, Carlo Caione, Kevin Hilman
Cc: Jerome Brunet, linux-gpio, linux-arm-kernel, linux-amlogic,
devicetree, linux-kernel
In-Reply-To: <20170326171923.19269-1-jbrunet@baylibre.com>
Add EE and AO domains pins for the spdif output to the gxbb device tree.
Acked-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index a9cacbd6a1d6..d1dc6a49df13 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -234,6 +234,20 @@
function = "i2s_out_ao";
};
};
+
+ spdif_out_ao_6_pins: spdif_out_ao_6 {
+ mux {
+ groups = "spdif_out_ao_6";
+ function = "spdif_out_ao";
+ };
+ };
+
+ spdif_out_ao_13_pins: spdif_out_ao_13 {
+ mux {
+ groups = "spdif_out_ao_13";
+ function = "spdif_out_ao";
+ };
+ };
};
};
@@ -495,6 +509,13 @@
function = "i2s_out";
};
};
+
+ spdif_out_y_pins: spdif_out_y {
+ mux {
+ groups = "spdif_out_y";
+ function = "spdif_out";
+ };
+ };
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 7/8] ARM64: dts: meson-gxl: add i2s output pins
From: Jerome Brunet @ 2017-03-26 17:19 UTC (permalink / raw)
To: Linus Walleij, Carlo Caione, Kevin Hilman
Cc: Jerome Brunet, linux-gpio, linux-arm-kernel, linux-amlogic,
devicetree, linux-kernel
In-Reply-To: <20170326171923.19269-1-jbrunet@baylibre.com>
Add EE and AO domains pins for the i2s output clocks and data the gxl
device tree
Acked-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 62 ++++++++++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 269458b05fd4..3dde55856234 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -160,6 +160,20 @@
function = "pwm_ao_b";
};
};
+
+ i2s_out_ch23_ao_pins: i2s_out_ch23_ao {
+ mux {
+ groups = "i2s_out_ch23_ao";
+ function = "i2s_out_ao";
+ };
+ };
+
+ i2s_out_ch45_ao_pins: i2s_out_ch45_ao {
+ mux {
+ groups = "i2s_out_ch45_ao";
+ function = "i2s_out_ao";
+ };
+ };
};
};
@@ -385,6 +399,54 @@
function = "hdmi_i2c";
};
};
+
+ i2s_am_clk_pins: i2s_am_clk {
+ mux {
+ groups = "i2s_am_clk";
+ function = "i2s_out";
+ };
+ };
+
+ i2s_out_ao_clk_pins: i2s_out_ao_clk {
+ mux {
+ groups = "i2s_out_ao_clk";
+ function = "i2s_out";
+ };
+ };
+
+ i2s_out_lr_clk_pins: i2s_out_lr_clk {
+ mux {
+ groups = "i2s_out_lr_clk";
+ function = "i2s_out";
+ };
+ };
+
+ i2s_out_ch01_pins: i2s_out_ch01 {
+ mux {
+ groups = "i2s_out_ch01";
+ function = "i2s_out";
+ };
+ };
+ i2sout_ch23_z_pins: i2sout_ch23_z {
+ mux {
+ groups = "i2sout_ch23_z";
+ function = "i2s_out";
+ };
+ };
+
+ i2sout_ch45_z_pins: i2sout_ch45_z {
+ mux {
+ groups = "i2sout_ch45_z";
+ function = "i2s_out";
+ };
+ };
+
+ i2sout_ch67_z_pins: i2sout_ch67_z {
+ mux {
+ groups = "i2sout_ch67_z";
+ function = "i2s_out";
+ };
+ };
};
eth-phy-mux {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 8/8] ARM64: dts: meson-gxl: add spdif output pins
From: Jerome Brunet @ 2017-03-26 17:19 UTC (permalink / raw)
To: Linus Walleij, Carlo Caione, Kevin Hilman
Cc: Jerome Brunet, linux-gpio, linux-arm-kernel, linux-amlogic,
devicetree, linux-kernel
In-Reply-To: <20170326171923.19269-1-jbrunet@baylibre.com>
Add EE and AO domains pins for the spdif output to the gxl device tree.
Acked-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 3dde55856234..8a08ad552e7a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -174,6 +174,20 @@
function = "i2s_out_ao";
};
};
+
+ spdif_out_ao_6_pins: spdif_out_ao_6 {
+ mux {
+ groups = "spdif_out_ao_6";
+ function = "spdif_out_ao";
+ };
+ };
+
+ spdif_out_ao_9_pins: spdif_out_ao_9 {
+ mux {
+ groups = "spdif_out_ao_9";
+ function = "spdif_out_ao";
+ };
+ };
};
};
@@ -447,6 +461,13 @@
function = "i2s_out";
};
};
+
+ spdif_out_h_pins: spdif_out_ao_h {
+ mux {
+ groups = "spdif_out_h";
+ function = "spdif_out";
+ };
+ };
};
eth-phy-mux {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 0/6] ARM: sunxi: Convert sun4i/sun7i series SoCs to sunxi-ng
From: Priit Laes @ 2017-03-26 17:20 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng, Russell King,
Chen-Yu Tsai, Maxime Ripard, Mark Rutland, Rob Herring,
Stephen Boyd, Michael Turquette, Philipp Zabel, Priit Laes
Hi,
This serie brings A10 (sun4i) and A20 (sun7i) SoCs into the
sunxi-ng world.
As mentioned in sun5i conversion, this is pretty much standard
stuff as all the required clocks were already implemented in
the sunxi-ng framework.
Unfortunately there's an issue with LVDS reset control that
causes issues with LVDS displays unless 'clk_ignore_unused'
option is used.
Need help with that :(
Changes from v1:
- Drop useless comments
- Add support for A10 / sun4i.
- Rename driver to sunxi-a10-a20.
- Add previously unimplemented clocks.
- Document the audio pll hardcoded post-divider
- Add Acked-by: Rob Herring <robh at kernel.org> on patch 4
Priit Laes (6):
clk: sunxi-ng: Add sun4i/sun7i CCU driver
ARM: sun7i: Convert to CCU
ARM: sun4i: Convert to CCU
dt-bindings: List devicetree binding for the CCU of Allwinner A20
dt-bindings: List devicetree binding for the CCU of Allwinner A10
clk: sunxi-ng: Display index when clock registration fails
Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 2 +-
arch/arm/boot/dts/sun4i-a10.dtsi | 636 +----
arch/arm/boot/dts/sun7i-a20.dtsi | 717 +-----
drivers/clk/sunxi-ng/Kconfig | 13 +-
drivers/clk/sunxi-ng/Makefile | 1 +-
drivers/clk/sunxi-ng/ccu-sunxi-a10-a20.c | 1532 ++++++++++-
drivers/clk/sunxi-ng/ccu-sunxi-a10-a20.h | 59 +-
drivers/clk/sunxi-ng/ccu_common.c | 4 +-
include/dt-bindings/clock/sunxi-a10-a20-ccu.h | 208 +-
include/dt-bindings/reset/sunxi-a10-a20-ccu.h | 66 +-
10 files changed, 2050 insertions(+), 1188 deletions(-)
create mode 100644 drivers/clk/sunxi-ng/ccu-sunxi-a10-a20.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sunxi-a10-a20.h
create mode 100644 include/dt-bindings/clock/sunxi-a10-a20-ccu.h
create mode 100644 include/dt-bindings/reset/sunxi-a10-a20-ccu.h
base-commit: 8e19fb843be8934d48b31fafbb32a4176f7feb65
--
git-series 0.9.1
^ permalink raw reply
* [PATCH v2 1/6] clk: sunxi-ng: Add sun4i/sun7i CCU driver
From: Priit Laes @ 2017-03-26 17:20 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng, Russell King,
Chen-Yu Tsai, Maxime Ripard, Mark Rutland, Rob Herring,
Stephen Boyd, Michael Turquette, Philipp Zabel, Priit Laes
In-Reply-To: <cover.a58841efb571d44013658505f3fa140536a89d1c.1490545262.git-series.plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org>
Introduce a clock controller driver for sun4i A10 and sun7i A20
series SoCs.
Signed-off-by: Priit Laes <plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org>
---
drivers/clk/sunxi-ng/Kconfig | 13 +-
drivers/clk/sunxi-ng/Makefile | 1 +-
drivers/clk/sunxi-ng/ccu-sunxi-a10-a20.c | 1532 ++++++++++++++++++-
drivers/clk/sunxi-ng/ccu-sunxi-a10-a20.h | 59 +-
include/dt-bindings/clock/sunxi-a10-a20-ccu.h | 208 ++-
include/dt-bindings/reset/sunxi-a10-a20-ccu.h | 66 +-
6 files changed, 1879 insertions(+)
create mode 100644 drivers/clk/sunxi-ng/ccu-sunxi-a10-a20.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sunxi-a10-a20.h
create mode 100644 include/dt-bindings/clock/sunxi-a10-a20-ccu.h
create mode 100644 include/dt-bindings/reset/sunxi-a10-a20-ccu.h
diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index 213cf64..abed614 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -65,6 +65,19 @@ config SUN50I_A64_CCU
default ARM64 && ARCH_SUNXI
depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
+config SUNXI_A10_A20_CCU
+ bool "Support for the Allwinner A10/A20 CCU"
+ select SUNXI_CCU_DIV
+ select SUNXI_CCU_MULT
+ select SUNXI_CCU_NK
+ select SUNXI_CCU_NKM
+ select SUNXI_CCU_NM
+ select SUNXI_CCU_MP
+ select SUNXI_CCU_PHASE
+ default MACH_SUN4I
+ default MACH_SUN7I
+ depends on MACH_SUN4I || MACH_SUN7I || COMPILE_TEST
+
config SUN5I_CCU
bool "Support for the Allwinner sun5i family CCM"
select SUNXI_CCU_DIV
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 6feaac0..90bab0e 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_SUNXI_CCU_MP) += ccu_mp.o
obj-$(CONFIG_SUN50I_A64_CCU) += ccu-sun50i-a64.o
obj-$(CONFIG_SUN5I_CCU) += ccu-sun5i.o
obj-$(CONFIG_SUN6I_A31_CCU) += ccu-sun6i-a31.o
+obj-$(CONFIG_SUNXI_A10_A20_CCU) += ccu-sunxi-a10-a20.o
obj-$(CONFIG_SUN8I_A23_CCU) += ccu-sun8i-a23.o
obj-$(CONFIG_SUN8I_A33_CCU) += ccu-sun8i-a33.o
obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o
diff --git a/drivers/clk/sunxi-ng/ccu-sunxi-a10-a20.c b/drivers/clk/sunxi-ng/ccu-sunxi-a10-a20.c
new file mode 100644
index 0000000..1884f5f
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sunxi-a10-a20.c
@@ -0,0 +1,1532 @@
+/*
+ * Copyright (c) 2017 Priit Laes. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of_address.h>
+
+#include "ccu_common.h"
+#include "ccu_reset.h"
+
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_mp.h"
+#include "ccu_mult.h"
+#include "ccu_nk.h"
+#include "ccu_nkm.h"
+#include "ccu_nkmp.h"
+#include "ccu_nm.h"
+#include "ccu_phase.h"
+
+#include "ccu-sunxi-a10-a20.h"
+
+static struct ccu_nkmp pll_core_clk = {
+ .enable = BIT(31),
+ .n = _SUNXI_CCU_MULT_OFFSET(8, 5, 0),
+ .k = _SUNXI_CCU_MULT(4, 2),
+ .m = _SUNXI_CCU_DIV(0, 2),
+ .p = _SUNXI_CCU_DIV(16, 2),
+ .common = {
+ .reg = 0x000,
+ .hw.init = CLK_HW_INIT("pll-core",
+ "hosc",
+ &ccu_nkmp_ops,
+ 0),
+ },
+};
+
+/*
+ * The Audio PLL is supposed to have 4 outputs: 3 fixed factors from
+ * the base (2x, 4x and 8x), and one variable divider (the one true
+ * pll audio).
+ *
+ * We don't have any need for the variable divider for now, so we just
+ * hardcode it to match with the clock names.
+ */
+#define SUN4I_PLL_AUDIO_REG 0x008
+static struct ccu_nm pll_audio_base_clk = {
+ .enable = BIT(31),
+ .n = _SUNXI_CCU_MULT_OFFSET(8, 7, 0),
+ .m = _SUNXI_CCU_DIV_OFFSET(0, 5, 0),
+ .common = {
+ .reg = 0x008,
+ .hw.init = CLK_HW_INIT("pll-audio-base",
+ "hosc",
+ &ccu_nm_ops,
+ 0),
+ },
+
+};
+
+static struct ccu_mult pll_video0_clk = {
+ .enable = BIT(31),
+ .mult = _SUNXI_CCU_MULT_OFFSET_MIN_MAX(0, 7, 0, 9, 127),
+ .frac = _SUNXI_CCU_FRAC(BIT(15), BIT(14),
+ 270000000, 297000000),
+ .common = {
+ .reg = 0x010,
+ .features = (CCU_FEATURE_FRACTIONAL |
+ CCU_FEATURE_ALL_PREDIV),
+ .prediv = 8,
+ .hw.init = CLK_HW_INIT("pll-video0",
+ "hosc",
+ &ccu_mult_ops,
+ 0),
+ },
+};
+
+static struct ccu_nkmp pll_ve_clk = {
+ .enable = BIT(31),
+ .n = _SUNXI_CCU_MULT_OFFSET(8, 5, 0),
+ .k = _SUNXI_CCU_MULT(4, 2),
+ .m = _SUNXI_CCU_DIV(0, 2),
+ .p = _SUNXI_CCU_DIV(16, 2),
+ .common = {
+ .reg = 0x018,
+ .hw.init = CLK_HW_INIT("pll-ve",
+ "hosc",
+ &ccu_nkmp_ops,
+ 0),
+ },
+};
+
+static struct ccu_nk pll_ddr_base_clk = {
+ .enable = BIT(31),
+ .n = _SUNXI_CCU_MULT_OFFSET(8, 5, 0),
+ .k = _SUNXI_CCU_MULT(4, 2),
+ .common = {
+ .reg = 0x020,
+ .hw.init = CLK_HW_INIT("pll-ddr-base",
+ "hosc",
+ &ccu_nk_ops,
+ 0),
+ },
+};
+
+static SUNXI_CCU_M(pll_ddr_clk, "pll-ddr", "pll-ddr-base", 0x020, 0, 2,
+ CLK_IS_CRITICAL);
+
+static struct ccu_div pll_ddr_other_clk = {
+ .div = _SUNXI_CCU_DIV_FLAGS(16, 2, CLK_DIVIDER_POWER_OF_TWO),
+
+ .common = {
+ .reg = 0x020,
+ .hw.init = CLK_HW_INIT("pll-ddr-other", "pll-ddr-base",
+ &ccu_div_ops,
+ 0),
+ },
+};
+
+static struct ccu_nk pll_periph_clk = {
+ .enable = BIT(31),
+ .n = _SUNXI_CCU_MULT_OFFSET(8, 5, 0),
+ .k = _SUNXI_CCU_MULT(4, 2),
+ .fixed_post_div = 2,
+ .common = {
+ .reg = 0x028,
+ .features = CCU_FEATURE_FIXED_POSTDIV,
+ .hw.init = CLK_HW_INIT("pll-periph",
+ "hosc",
+ &ccu_nk_ops,
+ 0),
+ },
+};
+/* Not documented on A10 */
+static SUNXI_CCU_GATE(pll_periph_sata_clk, "pll-periph-sata", "pll-periph",
+ 0x028, BIT(14), 0);
+
+static struct ccu_mult pll_video1_clk = {
+ .enable = BIT(31),
+ .mult = _SUNXI_CCU_MULT_OFFSET_MIN_MAX(0, 7, 0, 9, 127),
+ .frac = _SUNXI_CCU_FRAC(BIT(15), BIT(14),
+ 270000000, 297000000),
+ .common = {
+ .reg = 0x030,
+ .features = (CCU_FEATURE_FRACTIONAL |
+ CCU_FEATURE_ALL_PREDIV),
+ .prediv = 8,
+ .hw.init = CLK_HW_INIT("pll-video1",
+ "hosc",
+ &ccu_mult_ops,
+ 0),
+ },
+};
+
+/* Not present on A10 */
+static struct ccu_nk pll_gpu_clk = {
+ .enable = BIT(31),
+ .n = _SUNXI_CCU_MULT_OFFSET(8, 5, 0),
+ .k = _SUNXI_CCU_MULT(4, 2),
+ .common = {
+ .reg = 0x040,
+ .hw.init = CLK_HW_INIT("pll-gpu",
+ "hosc",
+ &ccu_nk_ops,
+ 0),
+ },
+};
+
+static SUNXI_CCU_GATE(hosc_clk, "hosc", "osc24M", 0x050, BIT(0), 0);
+
+static const char *const cpu_parents[] = { "osc32k", "hosc",
+ "pll-core", "pll-periph" };
+static const struct ccu_mux_fixed_prediv cpu_predivs[] = {
+ { .index = 3, .div = 3, },
+};
+
+#define SUN4I_AHB_REG 0x054
+static struct ccu_mux cpu_clk = {
+ .mux = {
+ .shift = 16,
+ .width = 2,
+ .fixed_predivs = cpu_predivs,
+ .n_predivs = ARRAY_SIZE(cpu_predivs),
+ },
+ .common = {
+ .reg = 0x054,
+ .features = CCU_FEATURE_FIXED_PREDIV,
+ .hw.init = CLK_HW_INIT_PARENTS("cpu",
+ cpu_parents,
+ &ccu_mux_ops,
+ CLK_IS_CRITICAL),
+ }
+};
+
+static SUNXI_CCU_M(axi_clk, "axi", "cpu", 0x054, 0, 2, 0);
+
+static const char *const ahb_parents[] = { "axi", "pll-periph",
+ "pll-periph-2x" };
+static const struct ccu_mux_fixed_prediv ahb_predivs[] = {
+ { .index = 2, .div = 2, },
+};
+
+/* Undocumented on A10 */
+static struct ccu_div ahb_clk = {
+ .div = _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
+ .mux = {
+ .shift = 6,
+ .width = 2,
+ .fixed_predivs = ahb_predivs,
+ .n_predivs = ARRAY_SIZE(ahb_predivs),
+ },
+
+ .common = {
+ .reg = 0x054,
+ .hw.init = CLK_HW_INIT_PARENTS("ahb",
+ ahb_parents,
+ &ccu_div_ops,
+ 0),
+ },
+};
+
+static struct clk_div_table apb0_div_table[] = {
+ { .val = 0, .div = 2 },
+ { .val = 1, .div = 2 },
+ { .val = 2, .div = 4 },
+ { .val = 3, .div = 8 },
+ { /* Sentinel */ },
+};
+static SUNXI_CCU_DIV_TABLE(apb0_clk, "apb0", "ahb",
+ 0x054, 8, 2, apb0_div_table, 0);
+
+static const char *const apb1_parents[] = { "hosc", "pll-periph", "osc32k" };
+static SUNXI_CCU_MP_WITH_MUX(apb1_clk, "apb1", apb1_parents, 0x058,
+ 0, 5, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ 0);
+
+/* Not present on A20 */
+static SUNXI_CCU_GATE(axi_dram_clk, "axi-dram", "ahb",
+ 0x05c, BIT(31), 0);
+
+static SUNXI_CCU_GATE(ahb_otg_clk, "ahb-otg", "ahb",
+ 0x060, BIT(0), 0);
+static SUNXI_CCU_GATE(ahb_ehci0_clk, "ahb-ehci0", "ahb",
+ 0x060, BIT(1), 0);
+static SUNXI_CCU_GATE(ahb_ohci0_clk, "ahb-ohci0", "ahb",
+ 0x060, BIT(2), 0);
+static SUNXI_CCU_GATE(ahb_ehci1_clk, "ahb-ehci1", "ahb",
+ 0x060, BIT(3), 0);
+static SUNXI_CCU_GATE(ahb_ohci1_clk, "ahb-ohci1", "ahb",
+ 0x060, BIT(4), 0);
+static SUNXI_CCU_GATE(ahb_ss_clk, "ahb-ss", "ahb",
+ 0x060, BIT(5), 0);
+static SUNXI_CCU_GATE(ahb_dma_clk, "ahb-dma", "ahb",
+ 0x060, BIT(6), 0);
+static SUNXI_CCU_GATE(ahb_bist_clk, "ahb-bist", "ahb",
+ 0x060, BIT(7), 0);
+static SUNXI_CCU_GATE(ahb_mmc0_clk, "ahb-mmc0", "ahb",
+ 0x060, BIT(8), 0);
+static SUNXI_CCU_GATE(ahb_mmc1_clk, "ahb-mmc1", "ahb",
+ 0x060, BIT(9), 0);
+static SUNXI_CCU_GATE(ahb_mmc2_clk, "ahb-mmc2", "ahb",
+ 0x060, BIT(10), 0);
+static SUNXI_CCU_GATE(ahb_mmc3_clk, "ahb-mmc3", "ahb",
+ 0x060, BIT(11), 0);
+static SUNXI_CCU_GATE(ahb_ms_clk, "ahb-ms", "ahb",
+ 0x060, BIT(12), 0);
+static SUNXI_CCU_GATE(ahb_nand_clk, "ahb-nand", "ahb",
+ 0x060, BIT(13), 0);
+static SUNXI_CCU_GATE(ahb_sdram_clk, "ahb-sdram", "ahb",
+ 0x060, BIT(14), CLK_IS_CRITICAL);
+
+static SUNXI_CCU_GATE(ahb_ace_clk, "ahb-ace", "ahb",
+ 0x060, BIT(16), 0);
+static SUNXI_CCU_GATE(ahb_emac_clk, "ahb-emac", "ahb",
+ 0x060, BIT(17), 0);
+static SUNXI_CCU_GATE(ahb_ts_clk, "ahb-ts", "ahb",
+ 0x060, BIT(18), 0);
+static SUNXI_CCU_GATE(ahb_spi0_clk, "ahb-spi0", "ahb",
+ 0x060, BIT(20), 0);
+static SUNXI_CCU_GATE(ahb_spi1_clk, "ahb-spi1", "ahb",
+ 0x060, BIT(21), 0);
+static SUNXI_CCU_GATE(ahb_spi2_clk, "ahb-spi2", "ahb",
+ 0x060, BIT(22), 0);
+static SUNXI_CCU_GATE(ahb_spi3_clk, "ahb-spi3", "ahb",
+ 0x060, BIT(23), 0);
+static SUNXI_CCU_GATE(ahb_pata_clk, "ahb-pata", "ahb",
+ 0x060, BIT(24), 0);
+/* Not documented on A20 */
+static SUNXI_CCU_GATE(ahb_sata_clk, "ahb-sata", "ahb",
+ 0x060, BIT(25), 0);
+/* Not present on A20 */
+static SUNXI_CCU_GATE(ahb_gps_clk, "ahb-gps", "ahb",
+ 0x060, BIT(26), 0);
+/* Not present on A10 */
+static SUNXI_CCU_GATE(ahb_hstimer_clk, "ahb-hstimer", "ahb",
+ 0x060, BIT(28), 0);
+
+static SUNXI_CCU_GATE(ahb_ve_clk, "ahb-ve", "ahb",
+ 0x064, BIT(0), 0);
+static SUNXI_CCU_GATE(ahb_tvd_clk, "ahb-tvd", "ahb",
+ 0x064, BIT(1), 0);
+static SUNXI_CCU_GATE(ahb_tve0_clk, "ahb-tve0", "ahb",
+ 0x064, BIT(2), 0);
+static SUNXI_CCU_GATE(ahb_tve1_clk, "ahb-tve1", "ahb",
+ 0x064, BIT(3), 0);
+static SUNXI_CCU_GATE(ahb_lcd0_clk, "ahb-lcd0", "ahb",
+ 0x064, BIT(4), 0);
+static SUNXI_CCU_GATE(ahb_lcd1_clk, "ahb-lcd1", "ahb",
+ 0x064, BIT(5), 0);
+static SUNXI_CCU_GATE(ahb_csi0_clk, "ahb-csi0", "ahb",
+ 0x064, BIT(8), 0);
+static SUNXI_CCU_GATE(ahb_csi1_clk, "ahb-csi1", "ahb",
+ 0x064, BIT(9), 0);
+/* Not present on A10 */
+static SUNXI_CCU_GATE(ahb_hdmi1_clk, "ahb-hdmi1", "ahb",
+ 0x064, BIT(10), 0);
+static SUNXI_CCU_GATE(ahb_hdmi0_clk, "ahb-hdmi0", "ahb",
+ 0x064, BIT(11), 0);
+static SUNXI_CCU_GATE(ahb_de_be0_clk, "ahb-de-be0", "ahb",
+ 0x064, BIT(12), 0);
+static SUNXI_CCU_GATE(ahb_de_be1_clk, "ahb-de-be1", "ahb",
+ 0x064, BIT(13), 0);
+static SUNXI_CCU_GATE(ahb_de_fe0_clk, "ahb-de-fe0", "ahb",
+ 0x064, BIT(14), 0);
+static SUNXI_CCU_GATE(ahb_de_fe1_clk, "ahb-de-fe1", "ahb",
+ 0x064, BIT(15), 0);
+/* Not present on A10 */
+static SUNXI_CCU_GATE(ahb_gmac_clk, "ahb-gmac", "ahb",
+ 0x064, BIT(17), 0);
+static SUNXI_CCU_GATE(ahb_mp_clk, "ahb-mp", "ahb",
+ 0x064, BIT(18), 0);
+static SUNXI_CCU_GATE(ahb_gpu_clk, "ahb-gpu", "ahb",
+ 0x064, BIT(20), 0);
+
+static SUNXI_CCU_GATE(apb0_codec_clk, "apb0-codec", "apb0",
+ 0x068, BIT(0), 0);
+static SUNXI_CCU_GATE(apb0_spdif_clk, "apb0-spdif", "apb0",
+ 0x068, BIT(1), 0);
+static SUNXI_CCU_GATE(apb0_ac97_clk, "apb0-ac97", "apb0",
+ 0x068, BIT(2), 0);
+static SUNXI_CCU_GATE(apb0_i2s0_clk, "apb0-i2s0", "apb0",
+ 0x068, BIT(3), 0);
+/* Not present on A10 */
+static SUNXI_CCU_GATE(apb0_i2s1_clk, "apb0-i2s1", "apb0",
+ 0x068, BIT(4), 0);
+static SUNXI_CCU_GATE(apb0_pio_clk, "apb0-pio", "apb0",
+ 0x068, BIT(5), 0);
+static SUNXI_CCU_GATE(apb0_ir0_clk, "apb0-ir0", "apb0",
+ 0x068, BIT(6), 0);
+static SUNXI_CCU_GATE(apb0_ir1_clk, "apb0-ir1", "apb0",
+ 0x068, BIT(7), 0);
+/* Not present on A10 */
+static SUNXI_CCU_GATE(apb0_i2s2_clk, "apb0-i2s2", "apb0",
+ 0x068, BIT(8), 0);
+static SUNXI_CCU_GATE(apb0_keypad_clk, "apb0-keypad", "apb0",
+ 0x068, BIT(10), 0);
+
+static SUNXI_CCU_GATE(apb1_i2c0_clk, "apb1-i2c0", "apb1",
+ 0x06c, BIT(0), 0);
+static SUNXI_CCU_GATE(apb1_i2c1_clk, "apb1-i2c1", "apb1",
+ 0x06c, BIT(1), 0);
+static SUNXI_CCU_GATE(apb1_i2c2_clk, "apb1-i2c2", "apb1",
+ 0x06c, BIT(2), 0);
+/* Not present on A10 */
+static SUNXI_CCU_GATE(apb1_i2c3_clk, "apb1-i2c3", "apb1",
+ 0x06c, BIT(3), 0);
+static SUNXI_CCU_GATE(apb1_can_clk, "apb1-can", "apb1",
+ 0x06c, BIT(4), 0);
+static SUNXI_CCU_GATE(apb1_scr_clk, "apb1-scr", "apb1",
+ 0x06c, BIT(5), 0);
+static SUNXI_CCU_GATE(apb1_ps20_clk, "apb1-ps20", "apb1",
+ 0x06c, BIT(6), 0);
+static SUNXI_CCU_GATE(apb1_ps21_clk, "apb1-ps21", "apb1",
+ 0x06c, BIT(7), 0);
+/* Not present on A10 */
+static SUNXI_CCU_GATE(apb1_i2c4_clk, "apb1-i2c4", "apb1",
+ 0x06c, BIT(15), 0);
+static SUNXI_CCU_GATE(apb1_uart0_clk, "apb1-uart0", "apb1",
+ 0x06c, BIT(16), 0);
+static SUNXI_CCU_GATE(apb1_uart1_clk, "apb1-uart1", "apb1",
+ 0x06c, BIT(17), 0);
+static SUNXI_CCU_GATE(apb1_uart2_clk, "apb1-uart2", "apb1",
+ 0x06c, BIT(18), 0);
+static SUNXI_CCU_GATE(apb1_uart3_clk, "apb1-uart3", "apb1",
+ 0x06c, BIT(19), 0);
+static SUNXI_CCU_GATE(apb1_uart4_clk, "apb1-uart4", "apb1",
+ 0x06c, BIT(20), 0);
+static SUNXI_CCU_GATE(apb1_uart5_clk, "apb1-uart5", "apb1",
+ 0x06c, BIT(21), 0);
+static SUNXI_CCU_GATE(apb1_uart6_clk, "apb1-uart6", "apb1",
+ 0x06c, BIT(22), 0);
+static SUNXI_CCU_GATE(apb1_uart7_clk, "apb1-uart7", "apb1",
+ 0x06c, BIT(23), 0);
+
+static const char *const mod0_default_parents[] = { "hosc", "pll-periph",
+ "pll-ddr-other" };
+static SUNXI_CCU_MP_WITH_MUX_GATE(nand_clk, "nand", mod0_default_parents, 0x080,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+
+/* Undocumented on A10 */
+static SUNXI_CCU_MP_WITH_MUX_GATE(ms_clk, "ms", mod0_default_parents, 0x084,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+
+static SUNXI_CCU_MP_WITH_MUX_GATE(mmc0_clk, "mmc0", mod0_default_parents, 0x088,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+/* Undocumented on A10 */
+static SUNXI_CCU_PHASE(mmc0_output_clk, "mmc0_output", "mmc0",
+ 0x088, 8, 3, 0);
+/* Undocumented on A10 */
+static SUNXI_CCU_PHASE(mmc0_sample_clk, "mmc0_sample", "mmc0",
+ 0x088, 20, 3, 0);
+
+static SUNXI_CCU_MP_WITH_MUX_GATE(mmc1_clk, "mmc1", mod0_default_parents, 0x08c,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+/* Undocumented on A10 */
+static SUNXI_CCU_PHASE(mmc1_output_clk, "mmc1_output", "mmc1",
+ 0x08c, 8, 3, 0);
+/* Undocumented on A10 */
+static SUNXI_CCU_PHASE(mmc1_sample_clk, "mmc1_sample", "mmc1",
+ 0x08c, 20, 3, 0);
+
+static SUNXI_CCU_MP_WITH_MUX_GATE(mmc2_clk, "mmc2", mod0_default_parents, 0x090,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+/* Undocumented on A10 */
+static SUNXI_CCU_PHASE(mmc2_output_clk, "mmc2_output", "mmc2",
+ 0x090, 8, 3, 0);
+/* Undocumented on A10 */
+static SUNXI_CCU_PHASE(mmc2_sample_clk, "mmc2_sample", "mmc2",
+ 0x090, 20, 3, 0);
+
+static SUNXI_CCU_MP_WITH_MUX_GATE(mmc3_clk, "mmc3", mod0_default_parents, 0x094,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+/* Undocumented on A10 */
+static SUNXI_CCU_PHASE(mmc3_output_clk, "mmc3_output", "mmc3",
+ 0x094, 8, 3, 0);
+/* Undocumented on A10 */
+static SUNXI_CCU_PHASE(mmc3_sample_clk, "mmc3_sample", "mmc3",
+ 0x094, 20, 3, 0);
+
+static SUNXI_CCU_MP_WITH_MUX_GATE(ts_clk, "ts", mod0_default_parents, 0x098,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+
+static SUNXI_CCU_MP_WITH_MUX_GATE(ss_clk, "ss", mod0_default_parents, 0x09c,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+
+static SUNXI_CCU_MP_WITH_MUX_GATE(spi0_clk, "spi0", mod0_default_parents, 0x0a0,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+
+static SUNXI_CCU_MP_WITH_MUX_GATE(spi1_clk, "spi1", mod0_default_parents, 0x0a4,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+
+static SUNXI_CCU_MP_WITH_MUX_GATE(spi2_clk, "spi2", mod0_default_parents, 0x0a8,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+
+/* Undocumented on A10 */
+static SUNXI_CCU_MP_WITH_MUX_GATE(pata_clk, "pata", mod0_default_parents, 0x0ac,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+
+/* TODO: Check whether A10 actually supports osc32k as 4th parent? */
+static const char *const ir_parents_sun4i[] = { "hosc", "pll-periph",
+ "pll-ddr-other" };
+static SUNXI_CCU_MP_WITH_MUX_GATE(ir0_sun4i_clk, "ir0", ir_parents_sun4i, 0x0b0,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+
+static SUNXI_CCU_MP_WITH_MUX_GATE(ir1_sun4i_clk, "ir1", ir_parents_sun4i, 0x0b4,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+static const char *const ir_parents_sun7i[] = { "hosc", "pll-periph",
+ "pll-ddr-other", "osc32k" };
+static SUNXI_CCU_MP_WITH_MUX_GATE(ir0_sun7i_clk, "ir0", ir_parents_sun7i, 0x0b0,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+
+static SUNXI_CCU_MP_WITH_MUX_GATE(ir1_sun7i_clk, "ir1", ir_parents_sun7i, 0x0b4,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+
+static const char *const audio_parents[] = { "pll-audio-8x", "pll-audio-4x",
+ "pll-audio-2x", "pll-audio" };
+static SUNXI_CCU_MUX_WITH_GATE(i2s0_clk, "i2s0", audio_parents,
+ 0x0b8, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
+
+static SUNXI_CCU_MUX_WITH_GATE(ac97_clk, "ac97", audio_parents,
+ 0x0bc, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
+
+/* Undocumented on A10 */
+static SUNXI_CCU_MUX_WITH_GATE(spdif_clk, "spdif", audio_parents,
+ 0x0c0, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
+
+static const char *const keypad_parents[] = { "hosc", "losc"};
+static const u8 keypad_table[] = { 0, 2 };
+static struct ccu_mp keypad_clk = {
+ .enable = BIT(31),
+ .m = _SUNXI_CCU_DIV(0, 5),
+ .p = _SUNXI_CCU_DIV(16, 2),
+ .mux = _SUNXI_CCU_MUX_TABLE(24, 2, keypad_table),
+ .common = {
+ .reg = 0x0c4,
+ .hw.init = CLK_HW_INIT_PARENTS("keypad",
+ keypad_parents,
+ &ccu_mp_ops,
+ 0),
+ },
+};
+
+/*
+ * TODO: SATA clock also supports external clock as parent via BIT(24)
+ * The external clock is probably an optional crystal or oscillator
+ * that can be connected to the SATA-CLKM / SATA-CLKP pins.
+ */
+static SUNXI_CCU_GATE(sata_clk, "sata", "pll-periph-sata",
+ 0x0c8, BIT(31), 0);
+
+static SUNXI_CCU_GATE(usb_ohci0_clk, "usb-ohci0", "pll-periph",
+ 0x0cc, BIT(6), 0);
+static SUNXI_CCU_GATE(usb_ohci1_clk, "usb-ohci1", "pll-periph",
+ 0x0cc, BIT(7), 0);
+static SUNXI_CCU_GATE(usb_phy_clk, "usb-phy", "pll-periph",
+ 0x0cc, BIT(8), 0);
+
+static SUNXI_CCU_MP_WITH_MUX_GATE(spi3_clk, "spi3", mod0_default_parents, 0x0d4,
+ 0, 4, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ BIT(31), /* gate */
+ 0);
+
+/* Not present on A10 */
+static SUNXI_CCU_MUX_WITH_GATE(i2s1_clk, "i2s1", audio_parents,
+ 0x0d8, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
+
+/* Not present on A10 */
+static SUNXI_CCU_MUX_WITH_GATE(i2s2_clk, "i2s2", audio_parents,
+ 0x0dc, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
+
+static SUNXI_CCU_GATE(dram_ve_clk, "dram-ve", "pll-ddr",
+ 0x100, BIT(0), 0);
+static SUNXI_CCU_GATE(dram_csi0_clk, "dram-csi0", "pll-ddr",
+ 0x100, BIT(1), 0);
+static SUNXI_CCU_GATE(dram_csi1_clk, "dram-csi1", "pll-ddr",
+ 0x100, BIT(2), 0);
+static SUNXI_CCU_GATE(dram_ts_clk, "dram-ts", "pll-ddr",
+ 0x100, BIT(3), 0);
+static SUNXI_CCU_GATE(dram_tvd_clk, "dram-tvd", "pll-ddr",
+ 0x100, BIT(4), 0);
+static SUNXI_CCU_GATE(dram_tve0_clk, "dram-tve0", "pll-ddr",
+ 0x100, BIT(5), 0);
+static SUNXI_CCU_GATE(dram_tve1_clk, "dram-tve1", "pll-ddr",
+ 0x100, BIT(6), 0);
+
+static SUNXI_CCU_GATE(dram_out_clk, "dram-out", "pll-ddr",
+ 0x100, BIT(15), 0);
+static SUNXI_CCU_GATE(dram_de_fe1_clk, "dram-de-fe1", "pll-ddr",
+ 0x100, BIT(24), 0);
+static SUNXI_CCU_GATE(dram_de_fe0_clk, "dram-de-fe0", "pll-ddr",
+ 0x100, BIT(25), 0);
+static SUNXI_CCU_GATE(dram_de_be0_clk, "dram-de-be0", "pll-ddr",
+ 0x100, BIT(26), 0);
+static SUNXI_CCU_GATE(dram_de_be1_clk, "dram-de-be1", "pll-ddr",
+ 0x100, BIT(27), 0);
+static SUNXI_CCU_GATE(dram_mp_clk, "dram-mp", "pll-ddr",
+ 0x100, BIT(28), 0);
+static SUNXI_CCU_GATE(dram_ace_clk, "dram-ace", "pll-ddr",
+ 0x100, BIT(29), 0);
+
+static const char *const de_parents[] = { "pll-video0", "pll-video1",
+ "pll-ddr-other" };
+static SUNXI_CCU_M_WITH_MUX_GATE(de_be0_clk, "de-be0", de_parents,
+ 0x104, 0, 4, 24, 2, BIT(31), 0);
+
+static SUNXI_CCU_M_WITH_MUX_GATE(de_be1_clk, "de-be1", de_parents,
+ 0x108, 0, 4, 24, 2, BIT(31), 0);
+
+static SUNXI_CCU_M_WITH_MUX_GATE(de_fe0_clk, "de-fe0", de_parents,
+ 0x10c, 0, 4, 24, 2, BIT(31), 0);
+
+static SUNXI_CCU_M_WITH_MUX_GATE(de_fe1_clk, "de-fe1", de_parents,
+ 0x110, 0, 4, 24, 2, BIT(31), 0);
+
+/* Undocumented on A10 */
+static SUNXI_CCU_M_WITH_MUX_GATE(de_mp_clk, "de-mp", de_parents,
+ 0x114, 0, 4, 24, 2, BIT(31), 0);
+
+static const char *const tcon_parents[] = { "pll-video0", "pll-video1",
+ "pll-video0-2x", "pll-video1-2x" };
+static SUNXI_CCU_MUX_WITH_GATE(tcon0_ch0_clk, "tcon0-ch0-sclk", tcon_parents,
+ 0x118, 24, 2, BIT(31), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_MUX_WITH_GATE(tcon1_ch0_clk, "tcon1-ch0-sclk", tcon_parents,
+ 0x11c, 24, 2, BIT(31), CLK_SET_RATE_PARENT);
+
+static const char *const csi_isp_parents[] = { "pll-video0", "pll-ve",
+ "pll-ddr-other", "pll-sata" };
+
+static SUNXI_CCU_M_WITH_MUX_GATE(csi_isp_clk, "csi-isp",
+ csi_isp_parents,
+ 0x120, 0, 4, 24, 2, BIT(31), 0);
+
+/* TVD clock setup for A10 */
+static const char *const tvd_parents[] = { "pll-video0", "pll-video1" };
+static SUNXI_CCU_MUX_WITH_GATE(tvd_sun4i_clk, "tvd", tvd_parents,
+ 0x128, 24, 1, BIT(31), 0);
+
+/* TVD clock setup for A20 */
+static SUNXI_CCU_MP_WITH_MUX_GATE(tvd_sclk2_sun7i_clk,
+ "tvd-sclk2", tvd_parents,
+ 0x128,
+ 0, 4, /* M */
+ 16, 4, /* P */
+ 8, 1, /* mux */
+ BIT(15), /* gate */
+ 0);
+static SUNXI_CCU_M_WITH_GATE(tvd_sclk1_sun7i_clk, "tvd-sclk1", "tvd-sclk2",
+ 0x128, 0, 4, BIT(31), 0);
+
+static SUNXI_CCU_M_WITH_MUX_GATE(tcon0_ch1_sclk2_clk, "tcon0-ch1-sclk2",
+ tcon_parents,
+ 0x12c, 0, 4, 24, 2, BIT(31),
+ CLK_SET_RATE_PARENT);
+
+static SUNXI_CCU_M_WITH_GATE(tcon0_ch1_clk,
+ "tcon0-ch1-sclk1", "tcon0-ch1-sclk2",
+ 0x12c, 11, 1, BIT(15),
+ CLK_SET_RATE_PARENT);
+
+static SUNXI_CCU_M_WITH_MUX_GATE(tcon1_ch1_sclk2_clk, "tcon1-ch1-sclk2",
+ tcon_parents,
+ 0x130, 0, 4, 24, 2, BIT(31),
+ CLK_SET_RATE_PARENT);
+
+static SUNXI_CCU_M_WITH_GATE(tcon1_ch1_clk,
+ "tcon1-ch1-sclk1", "tcon1-ch1-sclk2",
+ 0x130, 11, 1, BIT(15),
+ CLK_SET_RATE_PARENT);
+
+static const char *const csi_parents[] = { "hosc", "pll-video0", "pll-video1",
+ "pll-video0-2x", "pll-video1-2x"};
+static const u8 csi_table[] = { 0, 1, 2, 5, 6};
+static SUNXI_CCU_M_WITH_MUX_TABLE_GATE(csi0_clk, "csi0",
+ csi_parents, csi_table,
+ 0x134, 0, 5, 24, 3, BIT(31), 0);
+
+static SUNXI_CCU_M_WITH_MUX_TABLE_GATE(csi1_clk, "csi1",
+ csi_parents, csi_table,
+ 0x138, 0, 5, 24, 3, BIT(31), 0);
+
+static SUNXI_CCU_M_WITH_GATE(ve_clk, "ve", "pll-ve", 0x13c, 16, 8, BIT(31), 0);
+
+static SUNXI_CCU_GATE(codec_clk, "codec", "pll-audio",
+ 0x140, BIT(31), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_GATE(avs_clk, "avs", "hosc", 0x144, BIT(31), 0);
+
+static const char *const ace_parents[] = { "pll-ve", "pll-ddr-other" };
+static SUNXI_CCU_M_WITH_MUX_GATE(ace_clk, "ace", ace_parents,
+ 0x148, 0, 4, 24, 1, BIT(31), 0);
+
+static const char *const hdmi_parents[] = { "pll-video0", "pll-video0-2x",
+ "pll-vide01", "pll-video1-2x" };
+static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", hdmi_parents,
+ 0x150, 0, 4, 24, 2, BIT(31), 0);
+
+static const char *const gpu_parents_sun4i[] = { "pll-video0", "pll-ve",
+ "pll-ddr-other",
+ "pll-video1" };
+static SUNXI_CCU_M_WITH_MUX_GATE(gpu_sun4i_clk, "gpu", gpu_parents_sun4i,
+ 0x154, 0, 4, 24, 2, BIT(31), 0);
+
+static const char *const gpu_parents_sun7i[] = { "pll-video0", "pll-ve",
+ "pll-ddr-other", "pll-video1",
+ "pll-gpu" };
+static const u8 gpu_table_sun7i[] = { 0, 1, 2, 3, 4 };
+static SUNXI_CCU_M_WITH_MUX_TABLE_GATE(gpu_sun7i_clk, "gpu",
+ gpu_parents_sun7i, gpu_table_sun7i,
+ 0x154, 0, 4, 24, 3, BIT(31), 0);
+
+static const char *const mbus_parents[] = { "hosc", "pll-periph-2x",
+ "pll-ddr-other" };
+static SUNXI_CCU_MP_WITH_MUX_GATE(mbus_clk, "mbus", mbus_parents,
+ 0x15c, 0, 4, 16, 2, 24, 2, BIT(31),
+ CLK_IS_CRITICAL);
+
+static SUNXI_CCU_GATE(hdmi1_slow_clk, "hdmi1-slow", "hosc", 0x178, BIT(31), 0);
+
+static const char *const hdmi1_parents[] = { "pll-video0", "pll-video1" };
+static const u8 hdmi1_table[] = { 0, 1};
+static SUNXI_CCU_M_WITH_MUX_TABLE_GATE(hdmi1_clk, "hdmi1",
+ hdmi1_parents, hdmi1_table,
+ 0x17c, 0, 4, 24, 2, BIT(31), 0);
+
+static const char *const out_parents[] = { "hosc", "osc32k", "hosc" };
+static SUNXI_CCU_MP_WITH_MUX_GATE(out_a_clk, "out-a", out_parents,
+ 0x1f0, 8, 5, 20, 2, 24, 2, BIT(31), 0);
+static SUNXI_CCU_MP_WITH_MUX_GATE(out_b_clk, "out-b", out_parents,
+ 0x1f4, 8, 5, 20, 2, 24, 2, BIT(31), 0);
+
+static struct ccu_common *sun4i_a10_ccu_clks[] = {
+ &hosc_clk.common,
+ &pll_core_clk.common,
+ &pll_audio_base_clk.common,
+ &pll_video0_clk.common,
+ &pll_ve_clk.common,
+ &pll_ddr_base_clk.common,
+ &pll_ddr_clk.common,
+ &pll_ddr_other_clk.common,
+ &pll_periph_clk.common,
+ &pll_periph_sata_clk.common,
+ &pll_video1_clk.common,
+ &cpu_clk.common,
+ &axi_clk.common,
+ &axi_dram_clk.common,
+ &ahb_clk.common,
+ &apb0_clk.common,
+ &apb1_clk.common,
+ &ahb_otg_clk.common,
+ &ahb_ehci0_clk.common,
+ &ahb_ohci0_clk.common,
+ &ahb_ehci1_clk.common,
+ &ahb_ohci1_clk.common,
+ &ahb_ss_clk.common,
+ &ahb_dma_clk.common,
+ &ahb_bist_clk.common,
+ &ahb_mmc0_clk.common,
+ &ahb_mmc1_clk.common,
+ &ahb_mmc2_clk.common,
+ &ahb_mmc3_clk.common,
+ &ahb_ms_clk.common,
+ &ahb_nand_clk.common,
+ &ahb_sdram_clk.common,
+ &ahb_ace_clk.common,
+ &ahb_emac_clk.common,
+ &ahb_ts_clk.common,
+ &ahb_spi0_clk.common,
+ &ahb_spi1_clk.common,
+ &ahb_spi2_clk.common,
+ &ahb_spi3_clk.common,
+ &ahb_pata_clk.common,
+ &ahb_sata_clk.common,
+ &ahb_gps_clk.common,
+ &ahb_ve_clk.common,
+ &ahb_tvd_clk.common,
+ &ahb_tve0_clk.common,
+ &ahb_tve1_clk.common,
+ &ahb_lcd0_clk.common,
+ &ahb_lcd1_clk.common,
+ &ahb_csi0_clk.common,
+ &ahb_csi1_clk.common,
+ &ahb_hdmi0_clk.common,
+ &ahb_de_be0_clk.common,
+ &ahb_de_be1_clk.common,
+ &ahb_de_fe0_clk.common,
+ &ahb_de_fe1_clk.common,
+ &ahb_mp_clk.common,
+ &ahb_gpu_clk.common,
+ &apb0_codec_clk.common,
+ &apb0_spdif_clk.common,
+ &apb0_ac97_clk.common,
+ &apb0_i2s0_clk.common,
+ &apb0_pio_clk.common,
+ &apb0_ir0_clk.common,
+ &apb0_ir1_clk.common,
+ &apb0_keypad_clk.common,
+ &apb1_i2c0_clk.common,
+ &apb1_i2c1_clk.common,
+ &apb1_i2c2_clk.common,
+ &apb1_can_clk.common,
+ &apb1_scr_clk.common,
+ &apb1_ps20_clk.common,
+ &apb1_ps21_clk.common,
+ &apb1_uart0_clk.common,
+ &apb1_uart1_clk.common,
+ &apb1_uart2_clk.common,
+ &apb1_uart3_clk.common,
+ &apb1_uart4_clk.common,
+ &apb1_uart5_clk.common,
+ &apb1_uart6_clk.common,
+ &apb1_uart7_clk.common,
+ &nand_clk.common,
+ &ms_clk.common,
+ &mmc0_clk.common,
+ &mmc0_output_clk.common,
+ &mmc0_sample_clk.common,
+ &mmc1_clk.common,
+ &mmc1_output_clk.common,
+ &mmc1_sample_clk.common,
+ &mmc2_clk.common,
+ &mmc2_output_clk.common,
+ &mmc2_sample_clk.common,
+ &mmc3_clk.common,
+ &mmc3_output_clk.common,
+ &mmc3_sample_clk.common,
+ &ts_clk.common,
+ &ss_clk.common,
+ &spi0_clk.common,
+ &spi1_clk.common,
+ &spi2_clk.common,
+ &pata_clk.common,
+ &ir0_sun4i_clk.common,
+ &ir1_sun4i_clk.common,
+ &i2s0_clk.common,
+ &ac97_clk.common,
+ &spdif_clk.common,
+ &keypad_clk.common,
+ &sata_clk.common,
+ &usb_ohci0_clk.common,
+ &usb_ohci1_clk.common,
+ &usb_phy_clk.common,
+ &spi3_clk.common,
+ &dram_ve_clk.common,
+ &dram_csi0_clk.common,
+ &dram_csi1_clk.common,
+ &dram_ts_clk.common,
+ &dram_tvd_clk.common,
+ &dram_tve0_clk.common,
+ &dram_tve1_clk.common,
+ &dram_out_clk.common,
+ &dram_de_fe1_clk.common,
+ &dram_de_fe0_clk.common,
+ &dram_de_be0_clk.common,
+ &dram_de_be1_clk.common,
+ &dram_mp_clk.common,
+ &dram_ace_clk.common,
+ &de_mp_clk.common,
+ &csi_isp_clk.common,
+ &tvd_sun4i_clk.common,
+ &tcon0_ch1_sclk2_clk.common,
+ &tcon0_ch1_clk.common,
+ &tcon1_ch1_sclk2_clk.common,
+ &tcon1_ch1_clk.common,
+ &csi0_clk.common,
+ &csi1_clk.common,
+ &ve_clk.common,
+ &codec_clk.common,
+ &avs_clk.common,
+ &ace_clk.common,
+ &hdmi_clk.common,
+ &gpu_sun4i_clk.common,
+};
+
+static struct ccu_common *sun7i_a20_ccu_clks[] = {
+ &hosc_clk.common,
+ &pll_core_clk.common,
+ &pll_audio_base_clk.common,
+ &pll_video0_clk.common,
+ &pll_ve_clk.common,
+ &pll_ddr_base_clk.common,
+ &pll_ddr_clk.common,
+ &pll_ddr_other_clk.common,
+ &pll_periph_clk.common,
+ &pll_periph_sata_clk.common,
+ &pll_video1_clk.common,
+ &pll_gpu_clk.common,
+ &cpu_clk.common,
+ &axi_clk.common,
+ &ahb_clk.common,
+ &apb0_clk.common,
+ &apb1_clk.common,
+ &ahb_otg_clk.common,
+ &ahb_ehci0_clk.common,
+ &ahb_ohci0_clk.common,
+ &ahb_ehci1_clk.common,
+ &ahb_ohci1_clk.common,
+ &ahb_ss_clk.common,
+ &ahb_dma_clk.common,
+ &ahb_bist_clk.common,
+ &ahb_mmc0_clk.common,
+ &ahb_mmc1_clk.common,
+ &ahb_mmc2_clk.common,
+ &ahb_mmc3_clk.common,
+ &ahb_ms_clk.common,
+ &ahb_nand_clk.common,
+ &ahb_sdram_clk.common,
+ &ahb_ace_clk.common,
+ &ahb_emac_clk.common,
+ &ahb_ts_clk.common,
+ &ahb_spi0_clk.common,
+ &ahb_spi1_clk.common,
+ &ahb_spi2_clk.common,
+ &ahb_spi3_clk.common,
+ &ahb_pata_clk.common,
+ &ahb_sata_clk.common,
+ &ahb_hstimer_clk.common,
+ &ahb_ve_clk.common,
+ &ahb_tvd_clk.common,
+ &ahb_tve0_clk.common,
+ &ahb_tve1_clk.common,
+ &ahb_lcd0_clk.common,
+ &ahb_lcd1_clk.common,
+ &ahb_csi0_clk.common,
+ &ahb_csi1_clk.common,
+ &ahb_hdmi1_clk.common,
+ &ahb_hdmi0_clk.common,
+ &ahb_de_be0_clk.common,
+ &ahb_de_be1_clk.common,
+ &ahb_de_fe0_clk.common,
+ &ahb_de_fe1_clk.common,
+ &ahb_gmac_clk.common,
+ &ahb_mp_clk.common,
+ &ahb_gpu_clk.common,
+ &apb0_codec_clk.common,
+ &apb0_spdif_clk.common,
+ &apb0_ac97_clk.common,
+ &apb0_i2s0_clk.common,
+ &apb0_i2s1_clk.common,
+ &apb0_pio_clk.common,
+ &apb0_ir0_clk.common,
+ &apb0_ir1_clk.common,
+ &apb0_i2s2_clk.common,
+ &apb0_keypad_clk.common,
+ &apb1_i2c0_clk.common,
+ &apb1_i2c1_clk.common,
+ &apb1_i2c2_clk.common,
+ &apb1_i2c3_clk.common,
+ &apb1_can_clk.common,
+ &apb1_scr_clk.common,
+ &apb1_ps20_clk.common,
+ &apb1_ps21_clk.common,
+ &apb1_i2c4_clk.common,
+ &apb1_uart0_clk.common,
+ &apb1_uart1_clk.common,
+ &apb1_uart2_clk.common,
+ &apb1_uart3_clk.common,
+ &apb1_uart4_clk.common,
+ &apb1_uart5_clk.common,
+ &apb1_uart6_clk.common,
+ &apb1_uart7_clk.common,
+ &nand_clk.common,
+ &ms_clk.common,
+ &mmc0_clk.common,
+ &mmc0_output_clk.common,
+ &mmc0_sample_clk.common,
+ &mmc1_clk.common,
+ &mmc1_output_clk.common,
+ &mmc1_sample_clk.common,
+ &mmc2_clk.common,
+ &mmc2_output_clk.common,
+ &mmc2_sample_clk.common,
+ &mmc3_clk.common,
+ &mmc3_output_clk.common,
+ &mmc3_sample_clk.common,
+ &ts_clk.common,
+ &ss_clk.common,
+ &spi0_clk.common,
+ &spi1_clk.common,
+ &spi2_clk.common,
+ &pata_clk.common,
+ &ir0_sun7i_clk.common,
+ &ir1_sun7i_clk.common,
+ &i2s0_clk.common,
+ &ac97_clk.common,
+ &spdif_clk.common,
+ &keypad_clk.common,
+ &sata_clk.common,
+ &usb_ohci0_clk.common,
+ &usb_ohci1_clk.common,
+ &usb_phy_clk.common,
+ &spi3_clk.common,
+ &i2s1_clk.common,
+ &i2s2_clk.common,
+ &dram_ve_clk.common,
+ &dram_csi0_clk.common,
+ &dram_csi1_clk.common,
+ &dram_ts_clk.common,
+ &dram_tvd_clk.common,
+ &dram_tve0_clk.common,
+ &dram_tve1_clk.common,
+ &dram_out_clk.common,
+ &dram_de_fe1_clk.common,
+ &dram_de_fe0_clk.common,
+ &dram_de_be0_clk.common,
+ &dram_de_be1_clk.common,
+ &dram_mp_clk.common,
+ &dram_ace_clk.common,
+ &de_be0_clk.common,
+ &de_be1_clk.common,
+ &de_fe0_clk.common,
+ &de_fe1_clk.common,
+ &de_mp_clk.common,
+ &tcon0_ch0_clk.common,
+ &tcon1_ch0_clk.common,
+ &csi_isp_clk.common,
+ &tvd_sclk1_sun7i_clk.common,
+ &tvd_sclk2_sun7i_clk.common,
+ &tcon0_ch1_sclk2_clk.common,
+ &tcon0_ch1_clk.common,
+ &tcon1_ch1_sclk2_clk.common,
+ &tcon1_ch1_clk.common,
+ &csi0_clk.common,
+ &csi1_clk.common,
+ &ve_clk.common,
+ &codec_clk.common,
+ &avs_clk.common,
+ &ace_clk.common,
+ &hdmi_clk.common,
+ &gpu_sun7i_clk.common,
+ &mbus_clk.common,
+ &hdmi1_slow_clk.common,
+ &hdmi1_clk.common,
+ &out_a_clk.common,
+ &out_b_clk.common
+};
+
+/* Post-divider for pll-audio is hardcoded to 4 */
+static CLK_FIXED_FACTOR(pll_audio_clk, "pll-audio",
+ "pll-audio-base", 4, 1, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_audio_2x_clk, "pll-audio-2x",
+ "pll-audio-base", 2, 1, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_audio_4x_clk, "pll-audio-4x",
+ "pll-audio-base", 1, 1, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_audio_8x_clk, "pll-audio-8x",
+ "pll-audio-base", 1, 2, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_periph_2x_clk, "pll-periph-2x",
+ "pll-periph", 1, 2, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_video0_2x_clk, "pll-video0-2x",
+ "pll-video0", 1, 2, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_video1_2x_clk, "pll-video1-2x",
+ "pll-video1", 1, 2, CLK_SET_RATE_PARENT);
+
+
+static struct clk_hw_onecell_data sun4i_a10_hw_clks = {
+ .hws = {
+ [CLK_HOSC] = &hosc_clk.common.hw,
+ [CLK_PLL_CORE] = &pll_core_clk.common.hw,
+ [CLK_PLL_AUDIO_BASE] = &pll_audio_base_clk.common.hw,
+ [CLK_PLL_AUDIO] = &pll_audio_clk.hw,
+ [CLK_PLL_AUDIO_2X] = &pll_audio_2x_clk.hw,
+ [CLK_PLL_AUDIO_4X] = &pll_audio_4x_clk.hw,
+ [CLK_PLL_AUDIO_8X] = &pll_audio_8x_clk.hw,
+ [CLK_PLL_VIDEO0] = &pll_video0_clk.common.hw,
+ [CLK_PLL_VIDEO0_2X] = &pll_video0_2x_clk.hw,
+ [CLK_PLL_VE] = &pll_ve_clk.common.hw,
+ [CLK_PLL_DDR_BASE] = &pll_ddr_base_clk.common.hw,
+ [CLK_PLL_DDR] = &pll_ddr_clk.common.hw,
+ [CLK_PLL_DDR_OTHER] = &pll_ddr_other_clk.common.hw,
+ [CLK_PLL_PERIPH] = &pll_periph_clk.common.hw,
+ [CLK_PLL_PERIPH_2X] = &pll_periph_2x_clk.hw,
+ [CLK_PLL_PERIPH_SATA] = &pll_periph_sata_clk.common.hw,
+ [CLK_PLL_VIDEO1] = &pll_video1_clk.common.hw,
+ [CLK_PLL_VIDEO1_2X] = &pll_video1_2x_clk.hw,
+ [CLK_CPU] = &cpu_clk.common.hw,
+ [CLK_AXI] = &axi_clk.common.hw,
+ [CLK_AXI_DRAM] = &axi_dram_clk.common.hw,
+ [CLK_AHB] = &ahb_clk.common.hw,
+ [CLK_APB0] = &apb0_clk.common.hw,
+ [CLK_APB1] = &apb1_clk.common.hw,
+ [CLK_AHB_OTG] = &ahb_otg_clk.common.hw,
+ [CLK_AHB_EHCI0] = &ahb_ehci0_clk.common.hw,
+ [CLK_AHB_OHCI0] = &ahb_ohci0_clk.common.hw,
+ [CLK_AHB_EHCI1] = &ahb_ehci1_clk.common.hw,
+ [CLK_AHB_OHCI1] = &ahb_ohci1_clk.common.hw,
+ [CLK_AHB_SS] = &ahb_ss_clk.common.hw,
+ [CLK_AHB_DMA] = &ahb_dma_clk.common.hw,
+ [CLK_AHB_BIST] = &ahb_bist_clk.common.hw,
+ [CLK_AHB_MMC0] = &ahb_mmc0_clk.common.hw,
+ [CLK_AHB_MMC1] = &ahb_mmc1_clk.common.hw,
+ [CLK_AHB_MMC2] = &ahb_mmc2_clk.common.hw,
+ [CLK_AHB_MMC3] = &ahb_mmc3_clk.common.hw,
+ [CLK_AHB_MS] = &ahb_ms_clk.common.hw,
+ [CLK_AHB_NAND] = &ahb_nand_clk.common.hw,
+ [CLK_AHB_SDRAM] = &ahb_sdram_clk.common.hw,
+ [CLK_AHB_ACE] = &ahb_ace_clk.common.hw,
+ [CLK_AHB_EMAC] = &ahb_emac_clk.common.hw,
+ [CLK_AHB_TS] = &ahb_ts_clk.common.hw,
+ [CLK_AHB_SPI0] = &ahb_spi0_clk.common.hw,
+ [CLK_AHB_SPI1] = &ahb_spi1_clk.common.hw,
+ [CLK_AHB_SPI2] = &ahb_spi2_clk.common.hw,
+ [CLK_AHB_SPI3] = &ahb_spi3_clk.common.hw,
+ [CLK_AHB_PATA] = &ahb_pata_clk.common.hw,
+ [CLK_AHB_SATA] = &ahb_sata_clk.common.hw,
+ [CLK_AHB_GPS] = &ahb_gps_clk.common.hw,
+ [CLK_AHB_VE] = &ahb_ve_clk.common.hw,
+ [CLK_AHB_TVD] = &ahb_tvd_clk.common.hw,
+ [CLK_AHB_TVE0] = &ahb_tve0_clk.common.hw,
+ [CLK_AHB_TVE1] = &ahb_tve1_clk.common.hw,
+ [CLK_AHB_LCD0] = &ahb_lcd0_clk.common.hw,
+ [CLK_AHB_LCD1] = &ahb_lcd1_clk.common.hw,
+ [CLK_AHB_CSI0] = &ahb_csi0_clk.common.hw,
+ [CLK_AHB_CSI1] = &ahb_csi1_clk.common.hw,
+ [CLK_AHB_HDMI0] = &ahb_hdmi0_clk.common.hw,
+ [CLK_AHB_DE_BE0] = &ahb_de_be0_clk.common.hw,
+ [CLK_AHB_DE_BE1] = &ahb_de_be1_clk.common.hw,
+ [CLK_AHB_DE_FE0] = &ahb_de_fe0_clk.common.hw,
+ [CLK_AHB_DE_FE1] = &ahb_de_fe1_clk.common.hw,
+ [CLK_AHB_MP] = &ahb_mp_clk.common.hw,
+ [CLK_AHB_GPU] = &ahb_gpu_clk.common.hw,
+ [CLK_APB0_CODEC] = &apb0_codec_clk.common.hw,
+ [CLK_APB0_SPDIF] = &apb0_spdif_clk.common.hw,
+ [CLK_APB0_AC97] = &apb0_ac97_clk.common.hw,
+ [CLK_APB0_I2S0] = &apb0_i2s0_clk.common.hw,
+ [CLK_APB0_PIO] = &apb0_pio_clk.common.hw,
+ [CLK_APB0_IR0] = &apb0_ir0_clk.common.hw,
+ [CLK_APB0_IR1] = &apb0_ir1_clk.common.hw,
+ [CLK_APB0_KEYPAD] = &apb0_keypad_clk.common.hw,
+ [CLK_APB1_I2C0] = &apb1_i2c0_clk.common.hw,
+ [CLK_APB1_I2C1] = &apb1_i2c1_clk.common.hw,
+ [CLK_APB1_I2C2] = &apb1_i2c2_clk.common.hw,
+ [CLK_APB1_CAN] = &apb1_can_clk.common.hw,
+ [CLK_APB1_SCR] = &apb1_scr_clk.common.hw,
+ [CLK_APB1_PS20] = &apb1_ps20_clk.common.hw,
+ [CLK_APB1_PS21] = &apb1_ps21_clk.common.hw,
+ [CLK_APB1_UART0] = &apb1_uart0_clk.common.hw,
+ [CLK_APB1_UART1] = &apb1_uart1_clk.common.hw,
+ [CLK_APB1_UART2] = &apb1_uart2_clk.common.hw,
+ [CLK_APB1_UART3] = &apb1_uart3_clk.common.hw,
+ [CLK_APB1_UART4] = &apb1_uart4_clk.common.hw,
+ [CLK_APB1_UART5] = &apb1_uart5_clk.common.hw,
+ [CLK_APB1_UART6] = &apb1_uart6_clk.common.hw,
+ [CLK_APB1_UART7] = &apb1_uart7_clk.common.hw,
+ [CLK_NAND] = &nand_clk.common.hw,
+ [CLK_MS] = &ms_clk.common.hw,
+ [CLK_MMC0] = &mmc0_clk.common.hw,
+ [CLK_MMC0_OUTPUT] = &mmc0_output_clk.common.hw,
+ [CLK_MMC0_SAMPLE] = &mmc0_sample_clk.common.hw,
+ [CLK_MMC1] = &mmc1_clk.common.hw,
+ [CLK_MMC1_OUTPUT] = &mmc1_output_clk.common.hw,
+ [CLK_MMC1_SAMPLE] = &mmc1_sample_clk.common.hw,
+ [CLK_MMC2] = &mmc2_clk.common.hw,
+ [CLK_MMC2_OUTPUT] = &mmc2_output_clk.common.hw,
+ [CLK_MMC2_SAMPLE] = &mmc2_sample_clk.common.hw,
+ [CLK_MMC3] = &mmc3_clk.common.hw,
+ [CLK_MMC3_OUTPUT] = &mmc3_output_clk.common.hw,
+ [CLK_MMC3_SAMPLE] = &mmc3_sample_clk.common.hw,
+ [CLK_TS] = &ts_clk.common.hw,
+ [CLK_SS] = &ss_clk.common.hw,
+ [CLK_SPI0] = &spi0_clk.common.hw,
+ [CLK_SPI1] = &spi1_clk.common.hw,
+ [CLK_SPI2] = &spi2_clk.common.hw,
+ [CLK_PATA] = &pata_clk.common.hw,
+ [CLK_IR0] = &ir0_sun4i_clk.common.hw,
+ [CLK_IR1] = &ir1_sun4i_clk.common.hw,
+ [CLK_I2S0] = &i2s0_clk.common.hw,
+ [CLK_AC97] = &ac97_clk.common.hw,
+ [CLK_SPDIF] = &spdif_clk.common.hw,
+ [CLK_KEYPAD] = &keypad_clk.common.hw,
+ [CLK_SATA] = &sata_clk.common.hw,
+ [CLK_USB_OHCI0] = &usb_ohci0_clk.common.hw,
+ [CLK_USB_OHCI1] = &usb_ohci1_clk.common.hw,
+ [CLK_USB_PHY] = &usb_phy_clk.common.hw,
+ [CLK_SPI3] = &spi3_clk.common.hw,
+ [CLK_DRAM_VE] = &dram_ve_clk.common.hw,
+ [CLK_DRAM_CSI0] = &dram_csi0_clk.common.hw,
+ [CLK_DRAM_CSI1] = &dram_csi1_clk.common.hw,
+ [CLK_DRAM_TS] = &dram_ts_clk.common.hw,
+ [CLK_DRAM_TVD] = &dram_tvd_clk.common.hw,
+ [CLK_DRAM_TVE0] = &dram_tve0_clk.common.hw,
+ [CLK_DRAM_TVE1] = &dram_tve1_clk.common.hw,
+ [CLK_DRAM_OUT] = &dram_out_clk.common.hw,
+ [CLK_DRAM_DE_FE1] = &dram_de_fe1_clk.common.hw,
+ [CLK_DRAM_DE_FE0] = &dram_de_fe0_clk.common.hw,
+ [CLK_DRAM_DE_BE0] = &dram_de_be0_clk.common.hw,
+ [CLK_DRAM_DE_BE1] = &dram_de_be1_clk.common.hw,
+ [CLK_DRAM_MP] = &dram_mp_clk.common.hw,
+ [CLK_DRAM_ACE] = &dram_ace_clk.common.hw,
+ [CLK_DE_BE0] = &de_be0_clk.common.hw,
+ [CLK_DE_BE1] = &de_be1_clk.common.hw,
+ [CLK_DE_FE0] = &de_fe0_clk.common.hw,
+ [CLK_DE_FE1] = &de_fe1_clk.common.hw,
+ [CLK_DE_MP] = &de_mp_clk.common.hw,
+ [CLK_TCON0_CH0] = &tcon0_ch0_clk.common.hw,
+ [CLK_TCON1_CH0] = &tcon1_ch0_clk.common.hw,
+ [CLK_CSI_ISP] = &csi_isp_clk.common.hw,
+ [CLK_TVD] = &tvd_sun4i_clk.common.hw,
+ [CLK_TCON0_CH1_SCLK2] = &tcon0_ch1_sclk2_clk.common.hw,
+ [CLK_TCON0_CH1] = &tcon0_ch1_clk.common.hw,
+ [CLK_TCON1_CH1_SCLK2] = &tcon1_ch1_sclk2_clk.common.hw,
+ [CLK_TCON1_CH1] = &tcon1_ch1_clk.common.hw,
+ [CLK_CSI0] = &csi0_clk.common.hw,
+ [CLK_CSI1] = &csi1_clk.common.hw,
+ [CLK_VE] = &ve_clk.common.hw,
+ [CLK_CODEC] = &codec_clk.common.hw,
+ [CLK_AVS] = &avs_clk.common.hw,
+ [CLK_ACE] = &ace_clk.common.hw,
+ [CLK_HDMI] = &hdmi_clk.common.hw,
+ [CLK_GPU] = &gpu_sun7i_clk.common.hw,
+ },
+ .num = CLK_NUMBER_SUN4I,
+};
+static struct clk_hw_onecell_data sun7i_a20_hw_clks = {
+ .hws = {
+ [CLK_HOSC] = &hosc_clk.common.hw,
+ [CLK_PLL_CORE] = &pll_core_clk.common.hw,
+ [CLK_PLL_AUDIO_BASE] = &pll_audio_base_clk.common.hw,
+ [CLK_PLL_AUDIO] = &pll_audio_clk.hw,
+ [CLK_PLL_AUDIO_2X] = &pll_audio_2x_clk.hw,
+ [CLK_PLL_AUDIO_4X] = &pll_audio_4x_clk.hw,
+ [CLK_PLL_AUDIO_8X] = &pll_audio_8x_clk.hw,
+ [CLK_PLL_VIDEO0] = &pll_video0_clk.common.hw,
+ [CLK_PLL_VIDEO0_2X] = &pll_video0_2x_clk.hw,
+ [CLK_PLL_VE] = &pll_ve_clk.common.hw,
+ [CLK_PLL_DDR_BASE] = &pll_ddr_base_clk.common.hw,
+ [CLK_PLL_DDR] = &pll_ddr_clk.common.hw,
+ [CLK_PLL_DDR_OTHER] = &pll_ddr_other_clk.common.hw,
+ [CLK_PLL_PERIPH] = &pll_periph_clk.common.hw,
+ [CLK_PLL_PERIPH_2X] = &pll_periph_2x_clk.hw,
+ [CLK_PLL_PERIPH_SATA] = &pll_periph_sata_clk.common.hw,
+ [CLK_PLL_VIDEO1] = &pll_video1_clk.common.hw,
+ [CLK_PLL_VIDEO1_2X] = &pll_video1_2x_clk.hw,
+ [CLK_PLL_GPU] = &pll_gpu_clk.common.hw,
+ [CLK_CPU] = &cpu_clk.common.hw,
+ [CLK_AXI] = &axi_clk.common.hw,
+ [CLK_AHB] = &ahb_clk.common.hw,
+ [CLK_APB0] = &apb0_clk.common.hw,
+ [CLK_APB1] = &apb1_clk.common.hw,
+ [CLK_AHB_OTG] = &ahb_otg_clk.common.hw,
+ [CLK_AHB_EHCI0] = &ahb_ehci0_clk.common.hw,
+ [CLK_AHB_OHCI0] = &ahb_ohci0_clk.common.hw,
+ [CLK_AHB_EHCI1] = &ahb_ehci1_clk.common.hw,
+ [CLK_AHB_OHCI1] = &ahb_ohci1_clk.common.hw,
+ [CLK_AHB_SS] = &ahb_ss_clk.common.hw,
+ [CLK_AHB_DMA] = &ahb_dma_clk.common.hw,
+ [CLK_AHB_BIST] = &ahb_bist_clk.common.hw,
+ [CLK_AHB_MMC0] = &ahb_mmc0_clk.common.hw,
+ [CLK_AHB_MMC1] = &ahb_mmc1_clk.common.hw,
+ [CLK_AHB_MMC2] = &ahb_mmc2_clk.common.hw,
+ [CLK_AHB_MMC3] = &ahb_mmc3_clk.common.hw,
+ [CLK_AHB_MS] = &ahb_ms_clk.common.hw,
+ [CLK_AHB_NAND] = &ahb_nand_clk.common.hw,
+ [CLK_AHB_SDRAM] = &ahb_sdram_clk.common.hw,
+ [CLK_AHB_ACE] = &ahb_ace_clk.common.hw,
+ [CLK_AHB_EMAC] = &ahb_emac_clk.common.hw,
+ [CLK_AHB_TS] = &ahb_ts_clk.common.hw,
+ [CLK_AHB_SPI0] = &ahb_spi0_clk.common.hw,
+ [CLK_AHB_SPI1] = &ahb_spi1_clk.common.hw,
+ [CLK_AHB_SPI2] = &ahb_spi2_clk.common.hw,
+ [CLK_AHB_SPI3] = &ahb_spi3_clk.common.hw,
+ [CLK_AHB_PATA] = &ahb_pata_clk.common.hw,
+ [CLK_AHB_SATA] = &ahb_sata_clk.common.hw,
+ [CLK_AHB_HSTIMER] = &ahb_hstimer_clk.common.hw,
+ [CLK_AHB_VE] = &ahb_ve_clk.common.hw,
+ [CLK_AHB_TVD] = &ahb_tvd_clk.common.hw,
+ [CLK_AHB_TVE0] = &ahb_tve0_clk.common.hw,
+ [CLK_AHB_TVE1] = &ahb_tve1_clk.common.hw,
+ [CLK_AHB_LCD0] = &ahb_lcd0_clk.common.hw,
+ [CLK_AHB_LCD1] = &ahb_lcd1_clk.common.hw,
+ [CLK_AHB_CSI0] = &ahb_csi0_clk.common.hw,
+ [CLK_AHB_CSI1] = &ahb_csi1_clk.common.hw,
+ [CLK_AHB_HDMI1] = &ahb_hdmi1_clk.common.hw,
+ [CLK_AHB_HDMI0] = &ahb_hdmi0_clk.common.hw,
+ [CLK_AHB_DE_BE0] = &ahb_de_be0_clk.common.hw,
+ [CLK_AHB_DE_BE1] = &ahb_de_be1_clk.common.hw,
+ [CLK_AHB_DE_FE0] = &ahb_de_fe0_clk.common.hw,
+ [CLK_AHB_DE_FE1] = &ahb_de_fe1_clk.common.hw,
+ [CLK_AHB_GMAC] = &ahb_gmac_clk.common.hw,
+ [CLK_AHB_MP] = &ahb_mp_clk.common.hw,
+ [CLK_AHB_GPU] = &ahb_gpu_clk.common.hw,
+ [CLK_APB0_CODEC] = &apb0_codec_clk.common.hw,
+ [CLK_APB0_SPDIF] = &apb0_spdif_clk.common.hw,
+ [CLK_APB0_AC97] = &apb0_ac97_clk.common.hw,
+ [CLK_APB0_I2S0] = &apb0_i2s0_clk.common.hw,
+ [CLK_APB0_I2S1] = &apb0_i2s1_clk.common.hw,
+ [CLK_APB0_PIO] = &apb0_pio_clk.common.hw,
+ [CLK_APB0_IR0] = &apb0_ir0_clk.common.hw,
+ [CLK_APB0_IR1] = &apb0_ir1_clk.common.hw,
+ [CLK_APB0_I2S2] = &apb0_i2s2_clk.common.hw,
+ [CLK_APB0_KEYPAD] = &apb0_keypad_clk.common.hw,
+ [CLK_APB1_I2C0] = &apb1_i2c0_clk.common.hw,
+ [CLK_APB1_I2C1] = &apb1_i2c1_clk.common.hw,
+ [CLK_APB1_I2C2] = &apb1_i2c2_clk.common.hw,
+ [CLK_APB1_I2C3] = &apb1_i2c3_clk.common.hw,
+ [CLK_APB1_CAN] = &apb1_can_clk.common.hw,
+ [CLK_APB1_SCR] = &apb1_scr_clk.common.hw,
+ [CLK_APB1_PS20] = &apb1_ps20_clk.common.hw,
+ [CLK_APB1_PS21] = &apb1_ps21_clk.common.hw,
+ [CLK_APB1_I2C4] = &apb1_i2c4_clk.common.hw,
+ [CLK_APB1_UART0] = &apb1_uart0_clk.common.hw,
+ [CLK_APB1_UART1] = &apb1_uart1_clk.common.hw,
+ [CLK_APB1_UART2] = &apb1_uart2_clk.common.hw,
+ [CLK_APB1_UART3] = &apb1_uart3_clk.common.hw,
+ [CLK_APB1_UART4] = &apb1_uart4_clk.common.hw,
+ [CLK_APB1_UART5] = &apb1_uart5_clk.common.hw,
+ [CLK_APB1_UART6] = &apb1_uart6_clk.common.hw,
+ [CLK_APB1_UART7] = &apb1_uart7_clk.common.hw,
+ [CLK_NAND] = &nand_clk.common.hw,
+ [CLK_MS] = &ms_clk.common.hw,
+ [CLK_MMC0] = &mmc0_clk.common.hw,
+ [CLK_MMC0_OUTPUT] = &mmc0_output_clk.common.hw,
+ [CLK_MMC0_SAMPLE] = &mmc0_sample_clk.common.hw,
+ [CLK_MMC1] = &mmc1_clk.common.hw,
+ [CLK_MMC1_OUTPUT] = &mmc1_output_clk.common.hw,
+ [CLK_MMC1_SAMPLE] = &mmc1_sample_clk.common.hw,
+ [CLK_MMC2] = &mmc2_clk.common.hw,
+ [CLK_MMC2_OUTPUT] = &mmc2_output_clk.common.hw,
+ [CLK_MMC2_SAMPLE] = &mmc2_sample_clk.common.hw,
+ [CLK_MMC3] = &mmc3_clk.common.hw,
+ [CLK_MMC3_OUTPUT] = &mmc3_output_clk.common.hw,
+ [CLK_MMC3_SAMPLE] = &mmc3_sample_clk.common.hw,
+ [CLK_TS] = &ts_clk.common.hw,
+ [CLK_SS] = &ss_clk.common.hw,
+ [CLK_SPI0] = &spi0_clk.common.hw,
+ [CLK_SPI1] = &spi1_clk.common.hw,
+ [CLK_SPI2] = &spi2_clk.common.hw,
+ [CLK_PATA] = &pata_clk.common.hw,
+ [CLK_IR0] = &ir0_sun7i_clk.common.hw,
+ [CLK_IR1] = &ir1_sun7i_clk.common.hw,
+ [CLK_I2S0] = &i2s0_clk.common.hw,
+ [CLK_AC97] = &ac97_clk.common.hw,
+ [CLK_SPDIF] = &spdif_clk.common.hw,
+ [CLK_KEYPAD] = &keypad_clk.common.hw,
+ [CLK_SATA] = &sata_clk.common.hw,
+ [CLK_USB_OHCI0] = &usb_ohci0_clk.common.hw,
+ [CLK_USB_OHCI1] = &usb_ohci1_clk.common.hw,
+ [CLK_USB_PHY] = &usb_phy_clk.common.hw,
+ [CLK_SPI3] = &spi3_clk.common.hw,
+ [CLK_I2S1] = &i2s1_clk.common.hw,
+ [CLK_I2S2] = &i2s2_clk.common.hw,
+ [CLK_DRAM_VE] = &dram_ve_clk.common.hw,
+ [CLK_DRAM_CSI0] = &dram_csi0_clk.common.hw,
+ [CLK_DRAM_CSI1] = &dram_csi1_clk.common.hw,
+ [CLK_DRAM_TS] = &dram_ts_clk.common.hw,
+ [CLK_DRAM_TVD] = &dram_tvd_clk.common.hw,
+ [CLK_DRAM_TVE0] = &dram_tve0_clk.common.hw,
+ [CLK_DRAM_TVE1] = &dram_tve1_clk.common.hw,
+ [CLK_DRAM_OUT] = &dram_out_clk.common.hw,
+ [CLK_DRAM_DE_FE1] = &dram_de_fe1_clk.common.hw,
+ [CLK_DRAM_DE_FE0] = &dram_de_fe0_clk.common.hw,
+ [CLK_DRAM_DE_BE0] = &dram_de_be0_clk.common.hw,
+ [CLK_DRAM_DE_BE1] = &dram_de_be1_clk.common.hw,
+ [CLK_DRAM_MP] = &dram_mp_clk.common.hw,
+ [CLK_DRAM_ACE] = &dram_ace_clk.common.hw,
+ [CLK_DE_BE0] = &de_be0_clk.common.hw,
+ [CLK_DE_BE1] = &de_be1_clk.common.hw,
+ [CLK_DE_FE0] = &de_fe0_clk.common.hw,
+ [CLK_DE_FE1] = &de_fe1_clk.common.hw,
+ [CLK_DE_MP] = &de_mp_clk.common.hw,
+ [CLK_TCON0_CH0] = &tcon0_ch0_clk.common.hw,
+ [CLK_TCON1_CH0] = &tcon1_ch0_clk.common.hw,
+ [CLK_CSI_ISP] = &csi_isp_clk.common.hw,
+ [CLK_TVD_SCLK2] = &tvd_sclk2_sun7i_clk.common.hw,
+ [CLK_TVD] = &tvd_sclk1_sun7i_clk.common.hw,
+ [CLK_TCON0_CH1_SCLK2] = &tcon0_ch1_sclk2_clk.common.hw,
+ [CLK_TCON0_CH1] = &tcon0_ch1_clk.common.hw,
+ [CLK_TCON1_CH1_SCLK2] = &tcon1_ch1_sclk2_clk.common.hw,
+ [CLK_TCON1_CH1] = &tcon1_ch1_clk.common.hw,
+ [CLK_CSI0] = &csi0_clk.common.hw,
+ [CLK_CSI1] = &csi1_clk.common.hw,
+ [CLK_VE] = &ve_clk.common.hw,
+ [CLK_CODEC] = &codec_clk.common.hw,
+ [CLK_AVS] = &avs_clk.common.hw,
+ [CLK_ACE] = &ace_clk.common.hw,
+ [CLK_HDMI] = &hdmi_clk.common.hw,
+ [CLK_GPU] = &gpu_sun7i_clk.common.hw,
+ [CLK_MBUS] = &mbus_clk.common.hw,
+ [CLK_HDMI1_SLOW] = &hdmi1_slow_clk.common.hw,
+ [CLK_HDMI1] = &hdmi1_clk.common.hw,
+ [CLK_OUT_A] = &out_a_clk.common.hw,
+ [CLK_OUT_B] = &out_b_clk.common.hw,
+ },
+ .num = CLK_NUMBER_SUN7I,
+};
+
+static struct ccu_reset_map sun4i_a10_ccu_resets[] = {
+ [RST_USB_PHY0] = { 0x0cc, BIT(0) },
+ [RST_USB_PHY1] = { 0x0cc, BIT(1) },
+ [RST_USB_PHY2] = { 0x0cc, BIT(2) },
+ [RST_DE_BE0] = { 0x104, BIT(30) },
+ [RST_DE_BE1] = { 0x108, BIT(30) },
+ [RST_DE_FE0] = { 0x10c, BIT(30) },
+ [RST_DE_FE1] = { 0x110, BIT(30) },
+ [RST_DE_MP] = { 0x114, BIT(30) },
+ [RST_TCON0] = { 0x118, BIT(30) },
+ [RST_TCON1] = { 0x11c, BIT(30) },
+ [RST_CSI0] = { 0x134, BIT(30) },
+ [RST_CSI1] = { 0x138, BIT(30) },
+ [RST_VE] = { 0x13c, BIT(0) },
+ [RST_ACE] = { 0x148, BIT(16) },
+ [RST_LVDS] = { 0x14c, BIT(0) },
+ [RST_GPU] = { 0x154, BIT(30) },
+};
+
+static struct ccu_reset_map sun7i_a20_ccu_resets[] = {
+ [RST_USB_PHY0] = { 0x0cc, BIT(0) },
+ [RST_USB_PHY1] = { 0x0cc, BIT(1) },
+ [RST_USB_PHY2] = { 0x0cc, BIT(2) },
+ [RST_DE_BE0] = { 0x104, BIT(30) },
+ [RST_DE_BE1] = { 0x108, BIT(30) },
+ [RST_DE_FE0] = { 0x10c, BIT(30) },
+ [RST_DE_FE1] = { 0x110, BIT(30) },
+ [RST_DE_MP] = { 0x114, BIT(30) },
+ [RST_TCON0] = { 0x118, BIT(30) },
+ [RST_TCON1] = { 0x11c, BIT(30) },
+ [RST_CSI0] = { 0x134, BIT(30) },
+ [RST_CSI1] = { 0x138, BIT(30) },
+ [RST_VE] = { 0x13c, BIT(0) },
+ [RST_ACE] = { 0x148, BIT(16) },
+ [RST_LVDS] = { 0x14c, BIT(0) },
+ [RST_GPU] = { 0x154, BIT(30) },
+ [RST_HDMI_H] = { 0x170, BIT(0) },
+ [RST_HDMI_SYS] = { 0x170, BIT(1) },
+ [RST_HDMI_AUDIO_DMA] = { 0x170, BIT(2) },
+};
+
+static const struct sunxi_ccu_desc sun4i_a10_ccu_desc = {
+ .ccu_clks = sun4i_a10_ccu_clks,
+ .num_ccu_clks = ARRAY_SIZE(sun4i_a10_ccu_clks),
+
+ .hw_clks = &sun4i_a10_hw_clks,
+
+ .resets = sun4i_a10_ccu_resets,
+ .num_resets = ARRAY_SIZE(sun4i_a10_ccu_resets),
+};
+
+static const struct sunxi_ccu_desc sun7i_a20_ccu_desc = {
+ .ccu_clks = sun7i_a20_ccu_clks,
+ .num_ccu_clks = ARRAY_SIZE(sun7i_a20_ccu_clks),
+
+ .hw_clks = &sun7i_a20_hw_clks,
+
+ .resets = sun7i_a20_ccu_resets,
+ .num_resets = ARRAY_SIZE(sun7i_a20_ccu_resets),
+};
+
+static void init_clocks(void __iomem *reg)
+{
+ u32 val;
+
+ /* Force the PLL-Audio-1x divider to 4 */
+ val = readl(reg + SUN4I_PLL_AUDIO_REG);
+ val &= ~GENMASK(19, 16);
+ writel(val | (3 << 16), reg + SUN4I_PLL_AUDIO_REG);
+
+ /* Use PLL6 as parent for AHB */
+ val = readl(reg + SUN4I_AHB_REG);
+ val &= ~GENMASK(7, 6);
+ writel(val | (2 << 6), reg + SUN4I_AHB_REG);
+}
+
+static void __init sun4i_a10_ccu_setup(struct device_node *node)
+{
+ void __iomem *reg;
+
+ reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+ if (IS_ERR(reg)) {
+ pr_err("%s: Could not map the clock registers\n",
+ of_node_full_name(node));
+ return;
+ }
+
+ init_clocks(reg);
+
+ sunxi_ccu_probe(node, reg, &sun4i_a10_ccu_desc);
+}
+
+static void __init sun7i_a20_ccu_setup(struct device_node *node)
+{
+ void __iomem *reg;
+
+ reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+ if (IS_ERR(reg)) {
+ pr_err("%s: Could not map the clock registers\n",
+ of_node_full_name(node));
+ return;
+ }
+
+ init_clocks(reg);
+
+ sunxi_ccu_probe(node, reg, &sun7i_a20_ccu_desc);
+}
+
+CLK_OF_DECLARE(sun4i_a10_ccu, "allwinner,sun4i-a10-ccu",
+ sun4i_a10_ccu_setup);
+CLK_OF_DECLARE(sun7i_a20_ccu, "allwinner,sun7i-a20-ccu",
+ sun7i_a20_ccu_setup);
diff --git a/drivers/clk/sunxi-ng/ccu-sunxi-a10-a20.h b/drivers/clk/sunxi-ng/ccu-sunxi-a10-a20.h
new file mode 100644
index 0000000..bca224d
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sunxi-a10-a20.h
@@ -0,0 +1,59 @@
+/*
+ * Copyright 2017 Priit Laes
+ *
+ * Priit Laes <plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _CCU_SUNXI_A10_A20_H_
+#define _CCU_SUNXI_A10_A20_H_
+
+#include <dt-bindings/clock/sunxi-a10-a20-ccu.h>
+#include <dt-bindings/reset/sunxi-a10-a20-ccu.h>
+
+/* The HOSC is exported */
+#define CLK_PLL_CORE 2
+#define CLK_PLL_AUDIO_BASE 3
+#define CLK_PLL_AUDIO 4
+#define CLK_PLL_AUDIO_2X 5
+#define CLK_PLL_AUDIO_4X 6
+#define CLK_PLL_AUDIO_8X 7
+#define CLK_PLL_VIDEO0 8
+#define CLK_PLL_VIDEO0_2X 9
+#define CLK_PLL_VE 10
+#define CLK_PLL_DDR_BASE 11
+#define CLK_PLL_DDR 12
+#define CLK_PLL_DDR_OTHER 13
+#define CLK_PLL_PERIPH 14
+#define CLK_PLL_PERIPH_2X 15
+#define CLK_PLL_VIDEO1 17
+#define CLK_PLL_VIDEO1_2X 18
+#define CLK_PLL_GPU 19
+
+/* The CPU clock is exported */
+#define CLK_AXI 21
+#define CLK_AXI_DRAM 22
+#define CLK_AHB 23
+#define CLK_APB0 24
+#define CLK_APB1 25
+
+/* AHB gates are exported (23..68) */
+/* APB0 gates are exported (69..78) */
+/* APB1 gates are exported (79..95) */
+/* IP module clocks are exported (96..128) */
+/* DRAM gates are exported (129..142)*/
+/* Media (display engine clocks & etc) are exported (143..169) */
+
+#define CLK_NUMBER_SUN4I (CLK_GPU + 1)
+#define CLK_NUMBER_SUN7I (CLK_OUT_B + 1)
+
+#endif /* _CCU_SUNXI_A10_A20_H_ */
diff --git a/include/dt-bindings/clock/sunxi-a10-a20-ccu.h b/include/dt-bindings/clock/sunxi-a10-a20-ccu.h
new file mode 100644
index 0000000..364ccbe
--- /dev/null
+++ b/include/dt-bindings/clock/sunxi-a10-a20-ccu.h
@@ -0,0 +1,208 @@
+/*
+ * Copyright (C) 2017 Priit Laes <plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _DT_BINDINGS_CLK_SUNXI_A10_A20_H_
+#define _DT_BINDINGS_CLK_SUNXI_A10_A20_H_
+
+#define CLK_HOSC 1
+#define CLK_PLL_PERIPH_SATA 16
+#define CLK_CPU 20
+
+/* AHB Gates */
+#define CLK_AHB_OTG 26
+#define CLK_AHB_EHCI0 27
+#define CLK_AHB_OHCI0 28
+#define CLK_AHB_EHCI1 29
+#define CLK_AHB_OHCI1 30
+#define CLK_AHB_SS 31
+#define CLK_AHB_DMA 32
+#define CLK_AHB_BIST 33
+#define CLK_AHB_MMC0 34
+#define CLK_AHB_MMC1 35
+#define CLK_AHB_MMC2 36
+#define CLK_AHB_MMC3 37
+#define CLK_AHB_MS 38
+#define CLK_AHB_NAND 39
+#define CLK_AHB_SDRAM 40
+#define CLK_AHB_ACE 41
+#define CLK_AHB_EMAC 42
+#define CLK_AHB_TS 43
+#define CLK_AHB_SPI0 44
+#define CLK_AHB_SPI1 45
+#define CLK_AHB_SPI2 46
+#define CLK_AHB_SPI3 47
+#define CLK_AHB_PATA 48
+#define CLK_AHB_SATA 49
+#define CLK_AHB_GPS 50
+#define CLK_AHB_HSTIMER 51
+#define CLK_AHB_VE 52
+#define CLK_AHB_TVD 53
+#define CLK_AHB_TVE0 54
+#define CLK_AHB_TVE1 55
+#define CLK_AHB_LCD0 56
+#define CLK_AHB_LCD1 57
+#define CLK_AHB_CSI0 58
+#define CLK_AHB_CSI1 59
+#define CLK_AHB_HDMI0 60
+#define CLK_AHB_HDMI1 61
+#define CLK_AHB_DE_BE0 62
+#define CLK_AHB_DE_BE1 63
+#define CLK_AHB_DE_FE0 64
+#define CLK_AHB_DE_FE1 65
+#define CLK_AHB_GMAC 66
+#define CLK_AHB_MP 67
+#define CLK_AHB_GPU 68
+
+/* APB0 Gates */
+#define CLK_APB0_CODEC 69
+#define CLK_APB0_SPDIF 70
+#define CLK_APB0_I2S0 71
+#define CLK_APB0_AC97 72
+#define CLK_APB0_I2S1 73
+#define CLK_APB0_PIO 74
+#define CLK_APB0_IR0 75
+#define CLK_APB0_IR1 76
+#define CLK_APB0_I2S2 77
+#define CLK_APB0_KEYPAD 78
+
+/* APB1 Gates */
+#define CLK_APB1_I2C0 79
+#define CLK_APB1_I2C1 80
+#define CLK_APB1_I2C2 81
+#define CLK_APB1_I2C3 82
+#define CLK_APB1_CAN 83
+#define CLK_APB1_SCR 84
+#define CLK_APB1_PS20 85
+#define CLK_APB1_PS21 86
+#define CLK_APB1_I2C4 87
+#define CLK_APB1_UART0 88
+#define CLK_APB1_UART1 89
+#define CLK_APB1_UART2 90
+#define CLK_APB1_UART3 91
+#define CLK_APB1_UART4 92
+#define CLK_APB1_UART5 93
+#define CLK_APB1_UART6 94
+#define CLK_APB1_UART7 95
+
+/* IP clocks */
+#define CLK_NAND 96
+#define CLK_MS 97
+#define CLK_MMC0 98
+#define CLK_MMC0_OUTPUT 99
+#define CLK_MMC0_SAMPLE 100
+#define CLK_MMC1 101
+#define CLK_MMC1_OUTPUT 102
+#define CLK_MMC1_SAMPLE 103
+#define CLK_MMC2 104
+#define CLK_MMC2_OUTPUT 105
+#define CLK_MMC2_SAMPLE 106
+#define CLK_MMC3 107
+#define CLK_MMC3_OUTPUT 108
+#define CLK_MMC3_SAMPLE 109
+#define CLK_TS 110
+#define CLK_SS 111
+#define CLK_SPI0 112
+#define CLK_SPI1 113
+#define CLK_SPI2 114
+#define CLK_PATA 115
+#define CLK_IR0 116
+#define CLK_IR1 117
+#define CLK_I2S0 118
+#define CLK_AC97 119
+#define CLK_SPDIF 120
+#define CLK_KEYPAD 121
+#define CLK_SATA 122
+#define CLK_USB_OHCI0 123
+#define CLK_USB_OHCI1 124
+#define CLK_USB_PHY 125
+#define CLK_SPI3 126
+#define CLK_I2S1 127
+#define CLK_I2S2 128
+
+/* DRAM Gates */
+#define CLK_DRAM_VE 129
+#define CLK_DRAM_CSI0 130
+#define CLK_DRAM_CSI1 131
+#define CLK_DRAM_TS 132
+#define CLK_DRAM_TVD 133
+#define CLK_DRAM_TVE0 134
+#define CLK_DRAM_TVE1 135
+#define CLK_DRAM_OUT 136
+#define CLK_DRAM_DE_FE1 137
+#define CLK_DRAM_DE_FE0 138
+#define CLK_DRAM_DE_BE0 139
+#define CLK_DRAM_DE_BE1 140
+#define CLK_DRAM_MP 141
+#define CLK_DRAM_ACE 142
+
+/* Display Engine Clocks */
+#define CLK_DE_BE0 143
+#define CLK_DE_BE1 144
+#define CLK_DE_FE0 145
+#define CLK_DE_FE1 146
+#define CLK_DE_MP 147
+#define CLK_TCON0_CH0 148
+#define CLK_TCON1_CH0 149
+#define CLK_CSI_ISP 150
+#define CLK_TVD_SCLK2 151
+#define CLK_TVD 152
+#define CLK_TCON0_CH1_SCLK2 153
+#define CLK_TCON0_CH1 154
+#define CLK_TCON1_CH1_SCLK2 155
+#define CLK_TCON1_CH1 156
+#define CLK_CSI0 157
+#define CLK_CSI1 158
+#define CLK_CODEC 159
+#define CLK_VE 160
+#define CLK_AVS 161
+#define CLK_ACE 162
+#define CLK_HDMI 163
+#define CLK_GPU 164
+
+/* Following only exist on sun7i-a20 */
+#define CLK_MBUS 165
+#define CLK_HDMI1_SLOW 166
+#define CLK_HDMI1 167
+#define CLK_OUT_A 168
+#define CLK_OUT_B 169
+
+#endif /* _DT_BINDINGS_CLK_SUNXI_A10_A20_H_ */
diff --git a/include/dt-bindings/reset/sunxi-a10-a20-ccu.h b/include/dt-bindings/reset/sunxi-a10-a20-ccu.h
new file mode 100644
index 0000000..9845cee
--- /dev/null
+++ b/include/dt-bindings/reset/sunxi-a10-a20-ccu.h
@@ -0,0 +1,66 @@
+/*
+ * Copyright (C) 2017 Priit Laes <plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _DT_BINDINGS_RST_SUNXI_A10_A10_H
+#define _DT_BINDINGS_RST_SUNXI_A10_A10_H
+
+#define RST_USB_PHY0 1
+#define RST_USB_PHY1 2
+#define RST_USB_PHY2 3
+#define RST_DE_BE0 4
+#define RST_DE_BE1 5
+#define RST_DE_FE0 6
+#define RST_DE_FE1 7
+#define RST_DE_MP 8
+#define RST_TCON0 9
+#define RST_TCON1 10
+#define RST_CSI0 11
+#define RST_CSI1 12
+#define RST_VE 13
+#define RST_ACE 14
+#define RST_LVDS 15
+#define RST_GPU 16
+#define RST_HDMI_H 17
+#define RST_HDMI_SYS 18
+#define RST_HDMI_AUDIO_DMA 19
+
+#endif /* DT_BINDINGS_RST_SUNXI_A10_A10_H */
--
git-series 0.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox