* Re: [RFC v2 4/5] DT bindings documentation for Synopsys UDC platform driver
From: Rob Herring @ 2017-01-19 17:36 UTC (permalink / raw)
To: Raviteja Garimella
Cc: Mark Rutland, Greg Kroah-Hartman, Felipe Balbi,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484640308-25976-5-git-send-email-raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, Jan 17, 2017 at 01:35:07PM +0530, Raviteja Garimella wrote:
> This patch adds device tree bindings documentation for Synopsys
> USB device controller platform driver.
Bindings describe h/w, not drivers.
>
> Signed-off-by: Raviteja Garimella <raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/usb/snps,dw-ahb-udc.txt | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
> new file mode 100644
> index 0000000..0c18327
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
> @@ -0,0 +1,27 @@
> +Synopsys USB Device controller.
> +
> +The device node is used for Synopsys Designware Cores AHB
> +Subsystem Device Controller (UDC).
> +
> +This device node is used by UDCs integrated it Broadcom's
> +Northstar2 and Cygnus SoC's.
You need compatible strings for these in addition.
> +
> +Required properties:
> + - compatible: should be "snps,dw-ahb-udc"
This is a different IP than DWC2?
> + - reg: Offset and length of UDC register set
> + - interrupts: description of interrupt line
> + - phys: phandle to phy node.
> + - extcon: phandle to the extcon device. This is optional and
> + not required for those that don't require extcon support.
> + Extcon support will be required if the UDC is connected to
> + a Dual Role Device Phy that supports both Host and Device
> + mode based on the external cable.
Drop this. It should be a part of the phy. Also, I don't care to see new
users of extcon binding because it needs redoing.
--
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 v4 12/14] ARM: dts: da850: add the SATA node
From: Sergei Shtylyov @ 2017-01-19 17:45 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman, Sekhar Nori, Patrick Titiano,
Michael Turquette, Tejun Heo, Rob Herring, Mark Rutland,
Russell King, David Lechner
Cc: linux-ide-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1484832588-18413-13-git-send-email-bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 01/19/2017 04:29 PM, Bartosz Golaszewski wrote:
> Add the SATA node to the da850 device tree.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> arch/arm/boot/dts/da850.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 104155d..e9bf30e 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -403,6 +403,12 @@
> phy-names = "usb-phy";
> status = "disabled";
> };
> + sata: ahci@218000 {
No, according to devicetree.org the node name should be "sata@218000" and
the label can be whatever you want.
[...]
MBR, Sergei
--
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 v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding
From: Chris Paterson @ 2017-01-19 17:46 UTC (permalink / raw)
To: Ramesh Shanmugasundaram, Laurent Pinchart, Hans Verkuil
Cc: Geert Uytterhoeven, Rob Herring, Mark Rutland,
Mauro Carvalho Chehab, Sakari Ailus, Antti Palosaari,
Geert Uytterhoeven, Linux Media Mailing List,
devicetree@vger.kernel.org, Linux-Renesas
In-Reply-To: <HK2PR06MB0545BF36C3DD2D4D1B951C3FC3670@HK2PR06MB0545.apcprd06.prod.outlook.com>
Hello Hans,
Do you have any further feedback on this?
Thanks, Chris
> From: Ramesh Shanmugasundaram
> Sent: 10 January 2017 09:31
> Hi Laurent,
>
> > > >>> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram
> wrote:
> > > >>>> Add binding documentation for Renesas R-Car Digital Radio
> > > >>>> Interface
> > > >>>> (DRIF) controller.
> > > >>>>
> > > >>>> Signed-off-by: Ramesh Shanmugasundaram
> > > >>>> <ramesh.shanmugasundaram@bp.renesas.com> ---
> > > >>>>
> > > >>>> .../devicetree/bindings/media/renesas,drif.txt | 202
> > +++++++++++++
> > > >>>> 1 file changed, 202 insertions(+) create mode 100644
> > > >>>>
> > > >>>> Documentation/devicetree/bindings/media/renesas,drif.txt
> > > >>>>
> > > >>>> diff --git
> > > >>>> a/Documentation/devicetree/bindings/media/renesas,drif.txt
> > > >>>> b/Documentation/devicetree/bindings/media/renesas,drif.txt new
> > > >>>> file mode 100644 index 0000000..1f3feaf
> > > >>>> --- /dev/null
> > > >>>> +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > > >>>>
> > > >>>> +Optional properties of an internal channel when:
> > > >>>> + - It is the only enabled channel of the bond (or)
> > > >>>> + - If it acts as primary among enabled bonds
> > > >>>> +--------------------------------------------------------
> > > >>>> +- renesas,syncmd : sync mode
> > > >>>> + 0 (Frame start sync pulse mode. 1-bit
> > > >>>> +width
> > > >>>> pulse
> > > >>>> + indicates start of a frame)
> > > >>>> + 1 (L/R sync or I2S mode) (default)
> > > >>>> +- renesas,lsb-first : empty property indicates lsb bit is
> > received
> > > >>>> first.
> > > >>>> + When not defined msb bit is received
> > > >>>> +first
> > > >>>> +(default)
> > > >>>> +- renesas,syncac-active: Indicates sync signal polarity, 0/1
> > > >>>> +for
> > > >>>> low/high
> > >
> > > Shouldn't this be 'renesas,sync-active' instead of syncac-active?
> > >
> > > I'm not sure if syncac is intended or if it is a typo.
> > >
> > > >>>> + respectively. The default is 1 (active high)
> > > >>>> +- renesas,dtdl : delay between sync signal and start of
> > > >>>> reception.
> > > >>>> + The possible values are represented in
> > > >>>> + 0.5
> > clock
> > > >>>> + cycle units and the range is 0 to 4. The
> > default
> > > >>>> + value is 2 (i.e.) 1 clock cycle delay.
> > > >>>> +- renesas,syncdl : delay between end of reception and sync
> > > >>>> signal edge.
> > > >>>> + The possible values are represented in
> > > >>>> + 0.5
> > clock
> > > >>>> + cycle units and the range is 0 to 4 & 6.
> > > >>>> + The
> > > >>>> default
> > > >>>> + value is 0 (i.e.) no delay.
> > > >>>
> > > >>> Most of these properties are pretty similar to the video bus
> > > >>> properties defined at the endpoint level in
> > > >>> Documentation/devicetree/bindings/media/video-interfaces.txt. I
> > > >>> believe it would make sense to use OF graph and try to
> > > >>> standardize these properties similarly.
> > >
> > > Other than sync-active, is there really anything else that is similar?
> > > And even the sync-active isn't a good fit since here there is only
> > > one sync signal instead of two for video (h and vsync).
> >
> > That's why I said similar, not identical :-) My point is that, if we
> > consider that we could connect multiple sources to the DRIF, using OF
> > graph would make sense, and the above properties should then be
> > defined per endpoint.
>
> Thanks for the clarifications. I have some questions.
>
> - Assuming two devices are interfaced with DRIF and they are represented
> using two endpoints, the control signal related properties of DRIF might still
> need to be same for both endpoints? For e.g. syncac-active cannot be
> different in both endpoints?
>
> - I suppose "lsb-first", "dtdl" & "syncdl" may be defined per endpoint.
> However, h/w manual says same register values needs to be programmed
> for both the internal channels of a channel. Same with "syncmd" property.
>
> We could still define them as per endpoint property with a note that they
> need to be same. But I am not sure if that is what you intended?
>
> If we define them per endpoint we should then also try
> > standardize the ones that are not really Renesas-specific (that's at
> > least syncac-active).
>
> OK. I will call it "sync-active".
>
> For the syncmd and lsb-first properties, it could also
> > make sense to query them from the connected subdev at runtime, as
> > they're similar in purpose to formats and media bus configuration
> > (struct v4l2_mbus_config).
>
> May I know in bit more detail about what you had in mind? Please correct me
> if my understanding is wrong here but when I looked at the code
>
> 1) mbus_config is part of subdev_video_ops only. I assume we don't want to
> support this as part of tuner subdev. The next closest is pad_ops with "struct
> v4l2_mbus_framefmt" but it is fully video specific config unless I come up
> with new MEDIA_BUS_FMT_xxxx in media-bus-format.h and use the code
> field? For e.g.
>
> #define MEDIA_BUS_FMT_SDR_I2S_PADHI_BE 0x7001
> #define MEDIA_BUS_FMT_SDR_I2S_PADHI_LE 0x7002
>
> 2) The framework does not seem to mandate pad ops for all subdev. As the
> tuner can be any third party subdev, is it fair to assume that these properties
> can be queried from subdev?
>
> 3) Assuming pad ops is not available on the subdev shouldn't we still need a
> way to define these properties on DRIF DT?
>
> >
> > I'm not an SDR expert, so I'd like to have your opinion on this.
> >
> > > >> Note that the last two properties match the those in
> > > >> Documentation/devicetree/bindings/spi/sh-msiof.txt.
> > > >> We may want to use one DRIF channel as a plain SPI slave with the
> > > >> (modified) MSIOF driver in the future.
> > > >
> > > > Should I leave it as it is or modify these as in video-interfaces.txt?
> > > > Shall we conclude on this please?
> >
>
> Thanks,
> Ramesh
^ permalink raw reply
* Re: [PATCH v2 0/5] Reset Controller Nodes for TI Keystone platforms
From: santosh.shilimkar @ 2017-01-19 17:46 UTC (permalink / raw)
To: Suman Anna, Santosh Shilimkar
Cc: devicetree, Russell King, linux-kernel, Rob Herring,
Philipp Zabel, Andrew Davis, linux-arm-kernel
In-Reply-To: <e5b84f7c-fb55-25f2-8079-47b4a7ecde1a@oracle.com>
On 1/11/17 6:28 PM, santosh.shilimkar@oracle.com wrote:
> On 1/11/17 5:48 PM, Suman Anna wrote:
>> Hi Santosh,
>>
>> This is a slightly updated patch series for the reset controller nodes
>> for
>> TI Keystone2 SoCs. The only change is to rename the reset controller
>> nodes
>> from "psc-reset-controller" to just "reset-controller" following Rob
>> Herring's
>> comment on the Documentation update patch [1]. There are no changes to
>> the first
>> 2 patches. I have already posted a v2 for the Documentation update as
>> well.
>> Please pick this up instead of the v1 series [2].
>>
> I haven't picked up V1 so no worries. Even V2 I won't apply for another
> week to give some more time if there are any more comments on the
> bindings.
>
> Thanks for following up.
Series applied !!
^ permalink raw reply
* Re: [PATCH v3 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains
From: santosh.shilimkar @ 2017-01-19 17:51 UTC (permalink / raw)
To: Dave Gerlach, Ulf Hansson, Rafael J . Wysocki, Kevin Hilman,
Rob Herring
Cc: Nishanth Menon, devicetree, linux-pm, Lokesh Vutla, Keerthy,
Santosh Shilimkar, linux-kernel, Tero Kristo, Russell King,
Sudeep Holla, linux-arm-kernel
In-Reply-To: <bf9286b1-379d-1cc8-4eae-d268540dd2a6@ti.com>
On 1/4/17 2:06 PM, Dave Gerlach wrote:
> Santosh,
> On 01/04/2017 03:54 PM, Santosh Shilimkar wrote:
>> On 1/4/2017 12:55 PM, Dave Gerlach wrote:
>>> Hi,
>>> This is v3 of the series to add support for TI-SCI Generic PM Domains.
>>> Previous versions can be found here:
>>>
>>> v2: https://www.spinics.net/lists/kernel/msg2364612.html
>>> v1: http://www.spinics.net/lists/arm-kernel/msg525204.html
>>>
>>> This version is rebased on v4.10-rc2 but is the same as v2 with the
>>> exception of patch 2 in which the devicetree binding documentation
>>> needed to be updated to show the k2g_pds node should be a child of
>>> the pmmc node. Apart from that, the acks provided by Ulf were added
>>> to patches 1 and 3.
>>>
>>> Now that the TI-SCI series has been merged [1] this series will be ready
>>> to go in with an ack on the DT binding. Rob had raised some questions on
>>> the necessity ti,sci-id property but I believe these were properly
>>> addressed during the discussion of v2 so hopefully an ack is in order
>>> now.
>>>
>> How do you plan to merge this series with below patch ?
>>
>>> PM / Domains: Add generic data pointer to genpd data struct
>> I think this one goes via Rafael's tree. If you want me to merge this
>> along with other patches then will need his ack.
>>
>> Other way is to get that merged first via Rafael's tree and then
>> the remainder series.
>
> I'd be happy with it going in through your tree with an ack to avoid any
> delay but I'd say it's Rafael's call as it is a patch to the genpd core,
> even though at this point I am the only user.
>
Am going to send pull request over weekend, so if you would like
me take the series via arm-soc tree, please get Rafaels, ack and
let me know.
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH v3] mtd: spi-nor: add dt support for Everspin MRAMs
From: Rob Herring @ 2017-01-19 17:54 UTC (permalink / raw)
To: Cyrille Pitchen
Cc: Marek Vasut, Mark Rutland, devicetree@vger.kernel.org,
Rafał Miłecki, Masahiko Iwamoto,
linux-mtd@lists.infradead.org, Sascha Hauer,
Uwe Kleine-König, Geert Uytterhoeven, Jagan Teki
In-Reply-To: <82a0b0f7-a94b-70b5-1a5e-e5c04943a684@atmel.com>
On Tue, Jan 17, 2017 at 02:57:22PM +0100, Cyrille Pitchen wrote:
> Le 17/01/2017 à 14:16, Rafał Miłecki a écrit :
> > On 17 January 2017 at 12:03, Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de> wrote:
> >> The MR25 family doesn't support JEDEC, so they need explicit mentioning
> >> in the list of supported spi IDs. This makes it possible to add these
> >> using for example:
> >>
> >> compatible = "everspin,mr25h40";
> >
> > (...)
> >
> >> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> >> index 2c91c03e7eb0..3e920ec5c4d3 100644
> >> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> >> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> >> @@ -14,6 +14,8 @@ Required properties:
> >> at25df641
> >> at26df081a
> >> mr25h256
> >> + mr25h10
> >> + mr25h40
> >> mx25l4005a
> >> mx25l1606e
> >> mx25l6405d
> >
> > Uh, this is getting a never-ending-story...
> > If these chipsets don't support JEDEC, should we keep them in jedec,spi-nor.txt?
> >
>
> Maybe not but I think the new compatible strings should be documented
> somewhere. Currently jedec,spi-nor.txt already documents all the
> "m25p*-nonjedec" memories. So maybe just renaming the jedec,spi-nor.txt
> file into spi-nor.txt or mtd,spi-nor.txt could be a solution. Otherwise, we
> can let it as is. I have no idea of what would be the best solution.
As I read the description, the non-jedec chips don't support READ ID,
but I would assume they otherwise follow the JEDEC spec(s)?
> To be honest, I don't always fully understand the DT policy/philosophy and
> its requirements. I just thought when a new property or a new value is
> introduced it has to be documented.
> Generally speaking, when DT is involved in some series of patches, it often
> generates many discussions about the proper way to do thinks and about
> choosing the best between many technically functional solutions.
Doesn't that apply to any code review? Sounds like the kernel process to
me. If the DT review is more stringent, then I'll take that as a
complement.
> If you think jedec,spi-nor.txt is not suited to document the new value for
> the compatible string, why not, I perfectly understand your point.
>
> I don't mind choosing another way. I just want to be sure that, if not all,
> most of people agree on that solution and if possible, it is compliant with
> DT policy so everybody is happy and works together.
> That's why I involve DT people, even if it's a small detail, so they can
> advise us.
>
> Anyway, at some point we have to take a decision to carry on thinks.
> So actually, I would like to avoid a never-ending story :)
I don't know what's the right answer here with regards to renaming or
spliting things. In either case, that's a separate issue from this
patch.
Rob
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCH v3 1/6] dt-bindings: add device tree binding for Allwinner V3s pinctrl
From: Icenowy Zheng @ 2017-01-19 17:54 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring
Cc: devicetree, linux-doc, linux-kernel, linux-gpio, Icenowy Zheng,
linux-clk, linux-arm-kernel
Allwinner V3s SoC has a pin controller like other Allwinner SoCs and got
supported by the sunxi-pinctrl driver now.
Add a device tree binding for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index de1378b4efad..a1002735bc75 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -22,6 +22,7 @@ Required properties:
"allwinner,sun8i-a83t-pinctrl"
"allwinner,sun8i-h3-pinctrl"
"allwinner,sun8i-h3-r-pinctrl"
+ "allwinner,sun8i-v3s-pinctrl"
"allwinner,sun50i-a64-pinctrl"
"nextthing,gr8-pinctrl"
--
2.11.0
^ permalink raw reply related
* [PATCH v3 2/6] arm: sunxi: add support for V3s SoC
From: Icenowy Zheng @ 2017-01-19 17:54 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring
Cc: devicetree, linux-doc, linux-kernel, linux-gpio, Icenowy Zheng,
linux-clk, linux-arm-kernel
In-Reply-To: <20170119175448.11445-1-icenowy@aosc.xyz>
Allwinner V3s is a low-end single-core Cortex-A7 SoC, with 64MB
integrated DRAM, and several peripherals.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Documentation/arm/sunxi/README | 4 ++++
arch/arm/mach-sunxi/sunxi.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index cd0243302bc1..a455b305c62c 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -67,6 +67,10 @@ SunXi family
+ Datasheet
http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
+ - Allwinner V3s (sun8i)
+ + Datasheet
+ http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf
+
* Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
- Allwinner A80
+ Datasheet
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 2e2bde271205..f246bfc6cfe4 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -64,6 +64,7 @@ static const char * const sun8i_board_dt_compat[] = {
"allwinner,sun8i-a33",
"allwinner,sun8i-a83t",
"allwinner,sun8i-h3",
+ "allwinner,sun8i-v3s",
NULL,
};
--
2.11.0
^ permalink raw reply related
* [PATCH v3 3/6] clk: sunxi-ng: add support for V3s CCU
From: Icenowy Zheng @ 2017-01-19 17:54 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring
Cc: devicetree, linux-doc, linux-kernel, linux-gpio, Icenowy Zheng,
linux-clk, linux-arm-kernel
In-Reply-To: <20170119175448.11445-1-icenowy@aosc.xyz>
V3s has a similar but cut-down CCU to H3. Some muxes, especially clocks
about CSI, are different, which makes it to need a new CCU driver.
Add such a new driver for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
drivers/clk/sunxi-ng/Kconfig | 11 +
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 590 ++++++++++++++++++++++++++++++
drivers/clk/sunxi-ng/ccu-sun8i-v3s.h | 63 ++++
include/dt-bindings/clock/sun8i-v3s-ccu.h | 107 ++++++
include/dt-bindings/reset/sun8i-v3s-ccu.h | 78 ++++
6 files changed, 850 insertions(+)
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-v3s.h
create mode 100644 include/dt-bindings/clock/sun8i-v3s-ccu.h
create mode 100644 include/dt-bindings/reset/sun8i-v3s-ccu.h
diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index 8454c6e3dd65..1ca48255802f 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -109,4 +109,15 @@ config SUN8I_H3_CCU
select SUNXI_CCU_PHASE
default MACH_SUN8I
+config SUN8I_V3S_CCU
+ bool "Support for the Allwinner V3s CCU"
+ select SUNXI_CCU_DIV
+ select SUNXI_CCU_NK
+ select SUNXI_CCU_NKM
+ select SUNXI_CCU_NKMP
+ select SUNXI_CCU_NM
+ select SUNXI_CCU_MP
+ select SUNXI_CCU_PHASE
+ default MACH_SUN8I
+
endif
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 24fbc6e5deb8..d1cd81a0f112 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_SUN6I_A31_CCU) += ccu-sun6i-a31.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
+obj-$(CONFIG_SUN8I_V3S_CCU) += ccu-sun8i-v3s.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
new file mode 100644
index 000000000000..a3f505626878
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
@@ -0,0 +1,590 @@
+/*
+ * Copyright (c) 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * Based on ccu-sun8i-h3.c, which is:
+ * Copyright (c) 2016 Maxime Ripard. 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-sun8i-v3s.h"
+
+static SUNXI_CCU_NKMP_WITH_GATE_LOCK(pll_cpu_clk, "pll-cpu",
+ "osc24M", 0x000,
+ 8, 5, /* N */
+ 4, 2, /* K */
+ 0, 2, /* M */
+ 16, 2, /* P */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ 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 SUN8I_V3S_PLL_AUDIO_REG 0x008
+
+static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
+ "osc24M", 0x008,
+ 8, 7, /* N */
+ 0, 5, /* M */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ 0);
+
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video_clk, "pll-video",
+ "osc24M", 0x0010,
+ 8, 7, /* N */
+ 0, 4, /* M */
+ BIT(24), /* frac enable */
+ BIT(25), /* frac select */
+ 270000000, /* frac rate 0 */
+ 297000000, /* frac rate 1 */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ 0);
+
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
+ "osc24M", 0x0018,
+ 8, 7, /* N */
+ 0, 4, /* M */
+ BIT(24), /* frac enable */
+ BIT(25), /* frac select */
+ 270000000, /* frac rate 0 */
+ 297000000, /* frac rate 1 */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ 0);
+
+static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_ddr_clk, "pll-ddr",
+ "osc24M", 0x020,
+ 8, 5, /* N */
+ 4, 2, /* K */
+ 0, 2, /* M */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ 0);
+
+static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph0_clk, "pll-periph0",
+ "osc24M", 0x028,
+ 8, 5, /* N */
+ 4, 2, /* K */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ 2, /* post-div */
+ 0);
+
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_isp_clk, "pll-isp",
+ "osc24M", 0x002c,
+ 8, 7, /* N */
+ 0, 4, /* M */
+ BIT(24), /* frac enable */
+ BIT(25), /* frac select */
+ 270000000, /* frac rate 0 */
+ 297000000, /* frac rate 1 */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ 0);
+
+static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph1_clk, "pll-periph1",
+ "osc24M", 0x044,
+ 8, 5, /* N */
+ 4, 2, /* K */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ 2, /* post-div */
+ 0);
+
+static const char * const cpu_parents[] = { "osc32k", "osc24M",
+ "pll-cpu", "pll-cpu" };
+static SUNXI_CCU_MUX(cpu_clk, "cpu", cpu_parents,
+ 0x050, 16, 2, CLK_IS_CRITICAL);
+
+static SUNXI_CCU_M(axi_clk, "axi", "cpu", 0x050, 0, 2, 0);
+
+static const char * const ahb1_parents[] = { "osc32k", "osc24M",
+ "axi", "pll-periph0" };
+static struct ccu_div ahb1_clk = {
+ .div = _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
+
+ .mux = {
+ .shift = 12,
+ .width = 2,
+
+ .variable_prediv = {
+ .index = 3,
+ .shift = 6,
+ .width = 2,
+ },
+ },
+
+ .common = {
+ .reg = 0x054,
+ .features = CCU_FEATURE_VARIABLE_PREDIV,
+ .hw.init = CLK_HW_INIT_PARENTS("ahb1",
+ ahb1_parents,
+ &ccu_div_ops,
+ 0),
+ },
+};
+
+static struct clk_div_table apb1_div_table[] = {
+ { .val = 0, .div = 2 },
+ { .val = 1, .div = 2 },
+ { .val = 2, .div = 4 },
+ { .val = 3, .div = 8 },
+ { /* Sentinel */ },
+};
+static SUNXI_CCU_DIV_TABLE(apb1_clk, "apb1", "ahb1",
+ 0x054, 8, 2, apb1_div_table, 0);
+
+static const char * const apb2_parents[] = { "osc32k", "osc24M",
+ "pll-periph0", "pll-periph0" };
+static SUNXI_CCU_MP_WITH_MUX(apb2_clk, "apb2", apb2_parents, 0x058,
+ 0, 5, /* M */
+ 16, 2, /* P */
+ 24, 2, /* mux */
+ 0);
+
+static const char * const ahb2_parents[] = { "ahb1", "pll-periph0" };
+static const struct ccu_mux_fixed_prediv ahb2_fixed_predivs[] = {
+ { .index = 1, .div = 2 },
+};
+static struct ccu_mux ahb2_clk = {
+ .mux = {
+ .shift = 0,
+ .width = 1,
+ .fixed_predivs = ahb2_fixed_predivs,
+ .n_predivs = ARRAY_SIZE(ahb2_fixed_predivs),
+ },
+
+ .common = {
+ .reg = 0x05c,
+ .features = CCU_FEATURE_FIXED_PREDIV,
+ .hw.init = CLK_HW_INIT_PARENTS("ahb2",
+ ahb2_parents,
+ &ccu_mux_ops,
+ 0),
+ },
+};
+
+static SUNXI_CCU_GATE(bus_ce_clk, "bus-ce", "ahb1",
+ 0x060, BIT(5), 0);
+static SUNXI_CCU_GATE(bus_dma_clk, "bus-dma", "ahb1",
+ 0x060, BIT(6), 0);
+static SUNXI_CCU_GATE(bus_mmc0_clk, "bus-mmc0", "ahb1",
+ 0x060, BIT(8), 0);
+static SUNXI_CCU_GATE(bus_mmc1_clk, "bus-mmc1", "ahb1",
+ 0x060, BIT(9), 0);
+static SUNXI_CCU_GATE(bus_mmc2_clk, "bus-mmc2", "ahb1",
+ 0x060, BIT(10), 0);
+static SUNXI_CCU_GATE(bus_dram_clk, "bus-dram", "ahb1",
+ 0x060, BIT(14), 0);
+static SUNXI_CCU_GATE(bus_emac_clk, "bus-emac", "ahb2",
+ 0x060, BIT(17), 0);
+static SUNXI_CCU_GATE(bus_hstimer_clk, "bus-hstimer", "ahb1",
+ 0x060, BIT(19), 0);
+static SUNXI_CCU_GATE(bus_spi0_clk, "bus-spi0", "ahb1",
+ 0x060, BIT(20), 0);
+static SUNXI_CCU_GATE(bus_otg_clk, "bus-otg", "ahb1",
+ 0x060, BIT(24), 0);
+static SUNXI_CCU_GATE(bus_ehci0_clk, "bus-ehci0", "ahb1",
+ 0x060, BIT(26), 0);
+static SUNXI_CCU_GATE(bus_ohci0_clk, "bus-ohci0", "ahb1",
+ 0x060, BIT(29), 0);
+
+static SUNXI_CCU_GATE(bus_ve_clk, "bus-ve", "ahb1",
+ 0x064, BIT(0), 0);
+static SUNXI_CCU_GATE(bus_tcon0_clk, "bus-tcon0", "ahb1",
+ 0x064, BIT(4), 0);
+static SUNXI_CCU_GATE(bus_csi_clk, "bus-csi", "ahb1",
+ 0x064, BIT(8), 0);
+static SUNXI_CCU_GATE(bus_de_clk, "bus-de", "ahb1",
+ 0x064, BIT(12), 0);
+
+static SUNXI_CCU_GATE(bus_codec_clk, "bus-codec", "apb1",
+ 0x068, BIT(0), 0);
+static SUNXI_CCU_GATE(bus_pio_clk, "bus-pio", "apb1",
+ 0x068, BIT(5), 0);
+
+static SUNXI_CCU_GATE(bus_i2c0_clk, "bus-i2c0", "apb2",
+ 0x06c, BIT(0), 0);
+static SUNXI_CCU_GATE(bus_i2c1_clk, "bus-i2c1", "apb2",
+ 0x06c, BIT(1), 0);
+static SUNXI_CCU_GATE(bus_uart0_clk, "bus-uart0", "apb2",
+ 0x06c, BIT(16), 0);
+static SUNXI_CCU_GATE(bus_uart1_clk, "bus-uart1", "apb2",
+ 0x06c, BIT(17), 0);
+static SUNXI_CCU_GATE(bus_uart2_clk, "bus-uart2", "apb2",
+ 0x06c, BIT(18), 0);
+
+static SUNXI_CCU_GATE(bus_ephy_clk, "bus-ephy", "ahb1",
+ 0x070, BIT(0), 0);
+static SUNXI_CCU_GATE(bus_dbg_clk, "bus-dbg", "ahb1",
+ 0x070, BIT(7), 0);
+
+static const char * const mod0_default_parents[] = { "osc24M", "pll-periph0",
+ "pll-periph1" };
+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);
+
+static SUNXI_CCU_PHASE(mmc0_sample_clk, "mmc0_sample", "mmc0",
+ 0x088, 20, 3, 0);
+static SUNXI_CCU_PHASE(mmc0_output_clk, "mmc0_output", "mmc0",
+ 0x088, 8, 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);
+
+static SUNXI_CCU_PHASE(mmc1_sample_clk, "mmc1_sample", "mmc1",
+ 0x08c, 20, 3, 0);
+static SUNXI_CCU_PHASE(mmc1_output_clk, "mmc1_output", "mmc1",
+ 0x08c, 8, 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);
+
+static SUNXI_CCU_PHASE(mmc2_sample_clk, "mmc2_sample", "mmc2",
+ 0x090, 20, 3, 0);
+static SUNXI_CCU_PHASE(mmc2_output_clk, "mmc2_output", "mmc2",
+ 0x090, 8, 3, 0);
+
+static const char * const ce_parents[] = { "osc24M", "pll-periph0", };
+
+static SUNXI_CCU_MP_WITH_MUX_GATE(ce_clk, "ce", ce_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_GATE(usb_phy0_clk, "usb-phy0", "osc24M",
+ 0x0cc, BIT(8), 0);
+static SUNXI_CCU_GATE(usb_ohci0_clk, "usb-ohci0", "osc24M",
+ 0x0cc, BIT(16), 0);
+
+static const char * const dram_parents[] = { "pll-ddr", "pll-periph0-2x" };
+static SUNXI_CCU_M_WITH_MUX(dram_clk, "dram", dram_parents,
+ 0x0f4, 0, 4, 20, 2, CLK_IS_CRITICAL);
+
+static SUNXI_CCU_GATE(dram_ve_clk, "dram-ve", "dram",
+ 0x100, BIT(0), 0);
+static SUNXI_CCU_GATE(dram_csi_clk, "dram-csi", "dram",
+ 0x100, BIT(1), 0);
+static SUNXI_CCU_GATE(dram_ehci_clk, "dram-ehci", "dram",
+ 0x100, BIT(17), 0);
+static SUNXI_CCU_GATE(dram_ohci_clk, "dram-ohci", "dram",
+ 0x100, BIT(18), 0);
+
+static const char * const de_parents[] = { "pll-video", "pll-periph0" };
+static SUNXI_CCU_M_WITH_MUX_GATE(de_clk, "de", de_parents,
+ 0x104, 0, 4, 24, 2, BIT(31), 0);
+
+static const char * const tcon_parents[] = { "pll-video" };
+static SUNXI_CCU_M_WITH_MUX_GATE(tcon_clk, "tcon", tcon_parents,
+ 0x118, 0, 4, 24, 3, BIT(31), 0);
+
+static SUNXI_CCU_GATE(csi_misc_clk, "csi-misc", "osc24M",
+ 0x130, BIT(31), 0);
+
+static const char * const csi_mclk_parents[] = { "osc24M", "pll-video",
+ "pll-periph0", "pll-periph1" };
+static SUNXI_CCU_M_WITH_MUX_GATE(csi0_mclk_clk, "csi0-mclk", csi_mclk_parents,
+ 0x130, 0, 5, 8, 3, BIT(15), 0);
+
+static const char * const csi1_sclk_parents[] = { "pll-video", "pll-isp" };
+static SUNXI_CCU_M_WITH_MUX_GATE(csi1_sclk_clk, "csi-sclk", csi1_sclk_parents,
+ 0x134, 16, 4, 24, 3, BIT(31), 0);
+
+static SUNXI_CCU_M_WITH_MUX_GATE(csi1_mclk_clk, "csi-mclk", csi_mclk_parents,
+ 0x134, 0, 5, 8, 3, BIT(15), 0);
+
+static SUNXI_CCU_M_WITH_GATE(ve_clk, "ve", "pll-ve",
+ 0x13c, 16, 3, BIT(31), 0);
+
+static SUNXI_CCU_GATE(ac_dig_clk, "ac-dig", "pll-audio",
+ 0x140, BIT(31), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_GATE(avs_clk, "avs", "osc24M",
+ 0x144, BIT(31), 0);
+
+static const char * const mbus_parents[] = { "osc24M", "pll-periph0-2x", "pll-ddr" };
+static SUNXI_CCU_M_WITH_MUX_GATE(mbus_clk, "mbus", mbus_parents,
+ 0x15c, 0, 3, 24, 2, BIT(31), CLK_IS_CRITICAL);
+
+static const char * const mipi_csi_parents[] = { "pll-video", "pll-periph0",
+ "pll-isp" };
+static SUNXI_CCU_M_WITH_MUX_GATE(mipi_csi_clk, "mipi-csi", mipi_csi_parents,
+ 0x16c, 0, 3, 24, 2, BIT(31), 0);
+
+static struct ccu_common *sun8i_v3s_ccu_clks[] = {
+ &pll_cpu_clk.common,
+ &pll_audio_base_clk.common,
+ &pll_video_clk.common,
+ &pll_ve_clk.common,
+ &pll_ddr_clk.common,
+ &pll_periph0_clk.common,
+ &pll_isp_clk.common,
+ &pll_periph1_clk.common,
+ &cpu_clk.common,
+ &axi_clk.common,
+ &ahb1_clk.common,
+ &apb1_clk.common,
+ &apb2_clk.common,
+ &ahb2_clk.common,
+ &bus_ce_clk.common,
+ &bus_dma_clk.common,
+ &bus_mmc0_clk.common,
+ &bus_mmc1_clk.common,
+ &bus_mmc2_clk.common,
+ &bus_dram_clk.common,
+ &bus_emac_clk.common,
+ &bus_hstimer_clk.common,
+ &bus_spi0_clk.common,
+ &bus_otg_clk.common,
+ &bus_ehci0_clk.common,
+ &bus_ohci0_clk.common,
+ &bus_ve_clk.common,
+ &bus_tcon0_clk.common,
+ &bus_csi_clk.common,
+ &bus_de_clk.common,
+ &bus_codec_clk.common,
+ &bus_pio_clk.common,
+ &bus_i2c0_clk.common,
+ &bus_i2c1_clk.common,
+ &bus_uart0_clk.common,
+ &bus_uart1_clk.common,
+ &bus_uart2_clk.common,
+ &bus_ephy_clk.common,
+ &bus_dbg_clk.common,
+ &mmc0_clk.common,
+ &mmc0_sample_clk.common,
+ &mmc0_output_clk.common,
+ &mmc1_clk.common,
+ &mmc1_sample_clk.common,
+ &mmc1_output_clk.common,
+ &mmc2_clk.common,
+ &mmc2_sample_clk.common,
+ &mmc2_output_clk.common,
+ &ce_clk.common,
+ &spi0_clk.common,
+ &usb_phy0_clk.common,
+ &usb_ohci0_clk.common,
+ &dram_clk.common,
+ &dram_ve_clk.common,
+ &dram_csi_clk.common,
+ &dram_ohci_clk.common,
+ &dram_ehci_clk.common,
+ &de_clk.common,
+ &tcon_clk.common,
+ &csi_misc_clk.common,
+ &csi0_mclk_clk.common,
+ &csi1_sclk_clk.common,
+ &csi1_mclk_clk.common,
+ &ve_clk.common,
+ &ac_dig_clk.common,
+ &avs_clk.common,
+ &mbus_clk.common,
+ &mipi_csi_clk.common,
+};
+
+/* We hardcode the divider to 4 for now */
+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_periph0_2x_clk, "pll-periph0-2x",
+ "pll-periph0", 1, 2, 0);
+
+static struct clk_hw_onecell_data sun8i_v3s_hw_clks = {
+ .hws = {
+ [CLK_PLL_CPU] = &pll_cpu_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_VIDEO] = &pll_video_clk.common.hw,
+ [CLK_PLL_VE] = &pll_ve_clk.common.hw,
+ [CLK_PLL_DDR] = &pll_ddr_clk.common.hw,
+ [CLK_PLL_PERIPH0] = &pll_periph0_clk.common.hw,
+ [CLK_PLL_PERIPH0_2X] = &pll_periph0_2x_clk.hw,
+ [CLK_PLL_ISP] = &pll_isp_clk.common.hw,
+ [CLK_PLL_PERIPH1] = &pll_periph1_clk.common.hw,
+ [CLK_CPU] = &cpu_clk.common.hw,
+ [CLK_AXI] = &axi_clk.common.hw,
+ [CLK_AHB1] = &ahb1_clk.common.hw,
+ [CLK_APB1] = &apb1_clk.common.hw,
+ [CLK_APB2] = &apb2_clk.common.hw,
+ [CLK_AHB2] = &ahb2_clk.common.hw,
+ [CLK_BUS_CE] = &bus_ce_clk.common.hw,
+ [CLK_BUS_DMA] = &bus_dma_clk.common.hw,
+ [CLK_BUS_MMC0] = &bus_mmc0_clk.common.hw,
+ [CLK_BUS_MMC1] = &bus_mmc1_clk.common.hw,
+ [CLK_BUS_MMC2] = &bus_mmc2_clk.common.hw,
+ [CLK_BUS_DRAM] = &bus_dram_clk.common.hw,
+ [CLK_BUS_EMAC] = &bus_emac_clk.common.hw,
+ [CLK_BUS_HSTIMER] = &bus_hstimer_clk.common.hw,
+ [CLK_BUS_SPI0] = &bus_spi0_clk.common.hw,
+ [CLK_BUS_OTG] = &bus_otg_clk.common.hw,
+ [CLK_BUS_EHCI0] = &bus_ehci0_clk.common.hw,
+ [CLK_BUS_OHCI0] = &bus_ohci0_clk.common.hw,
+ [CLK_BUS_VE] = &bus_ve_clk.common.hw,
+ [CLK_BUS_TCON0] = &bus_tcon0_clk.common.hw,
+ [CLK_BUS_CSI] = &bus_csi_clk.common.hw,
+ [CLK_BUS_DE] = &bus_de_clk.common.hw,
+ [CLK_BUS_CODEC] = &bus_codec_clk.common.hw,
+ [CLK_BUS_PIO] = &bus_pio_clk.common.hw,
+ [CLK_BUS_I2C0] = &bus_i2c0_clk.common.hw,
+ [CLK_BUS_I2C1] = &bus_i2c1_clk.common.hw,
+ [CLK_BUS_UART0] = &bus_uart0_clk.common.hw,
+ [CLK_BUS_UART1] = &bus_uart1_clk.common.hw,
+ [CLK_BUS_UART2] = &bus_uart2_clk.common.hw,
+ [CLK_BUS_EPHY] = &bus_ephy_clk.common.hw,
+ [CLK_BUS_DBG] = &bus_dbg_clk.common.hw,
+ [CLK_MMC0] = &mmc0_clk.common.hw,
+ [CLK_MMC0_SAMPLE] = &mmc0_sample_clk.common.hw,
+ [CLK_MMC0_OUTPUT] = &mmc0_output_clk.common.hw,
+ [CLK_MMC1] = &mmc1_clk.common.hw,
+ [CLK_MMC1_SAMPLE] = &mmc1_sample_clk.common.hw,
+ [CLK_MMC1_OUTPUT] = &mmc1_output_clk.common.hw,
+ [CLK_CE] = &ce_clk.common.hw,
+ [CLK_SPI0] = &spi0_clk.common.hw,
+ [CLK_USB_PHY0] = &usb_phy0_clk.common.hw,
+ [CLK_USB_OHCI0] = &usb_ohci0_clk.common.hw,
+ [CLK_DRAM] = &dram_clk.common.hw,
+ [CLK_DRAM_VE] = &dram_ve_clk.common.hw,
+ [CLK_DRAM_CSI] = &dram_csi_clk.common.hw,
+ [CLK_DRAM_EHCI] = &dram_ehci_clk.common.hw,
+ [CLK_DRAM_OHCI] = &dram_ohci_clk.common.hw,
+ [CLK_DE] = &de_clk.common.hw,
+ [CLK_TCON0] = &tcon_clk.common.hw,
+ [CLK_CSI_MISC] = &csi_misc_clk.common.hw,
+ [CLK_CSI0_MCLK] = &csi0_mclk_clk.common.hw,
+ [CLK_CSI1_SCLK] = &csi1_sclk_clk.common.hw,
+ [CLK_CSI1_MCLK] = &csi1_mclk_clk.common.hw,
+ [CLK_VE] = &ve_clk.common.hw,
+ [CLK_AC_DIG] = &ac_dig_clk.common.hw,
+ [CLK_AVS] = &avs_clk.common.hw,
+ [CLK_MBUS] = &mbus_clk.common.hw,
+ [CLK_MIPI_CSI] = &mipi_csi_clk.common.hw,
+ },
+ .num = CLK_NUMBER,
+};
+
+static struct ccu_reset_map sun8i_v3s_ccu_resets[] = {
+ [RST_USB_PHY0] = { 0x0cc, BIT(0) },
+
+ [RST_MBUS] = { 0x0fc, BIT(31) },
+
+ [RST_BUS_CE] = { 0x2c0, BIT(5) },
+ [RST_BUS_DMA] = { 0x2c0, BIT(6) },
+ [RST_BUS_MMC0] = { 0x2c0, BIT(8) },
+ [RST_BUS_MMC1] = { 0x2c0, BIT(9) },
+ [RST_BUS_MMC2] = { 0x2c0, BIT(10) },
+ [RST_BUS_DRAM] = { 0x2c0, BIT(14) },
+ [RST_BUS_EMAC] = { 0x2c0, BIT(17) },
+ [RST_BUS_HSTIMER] = { 0x2c0, BIT(19) },
+ [RST_BUS_SPI0] = { 0x2c0, BIT(20) },
+ [RST_BUS_OTG] = { 0x2c0, BIT(23) },
+ [RST_BUS_EHCI0] = { 0x2c0, BIT(26) },
+ [RST_BUS_OHCI0] = { 0x2c0, BIT(29) },
+
+ [RST_BUS_VE] = { 0x2c4, BIT(0) },
+ [RST_BUS_TCON0] = { 0x2c4, BIT(3) },
+ [RST_BUS_CSI] = { 0x2c4, BIT(8) },
+ [RST_BUS_DE] = { 0x2c4, BIT(12) },
+ [RST_BUS_DBG] = { 0x2c4, BIT(31) },
+
+ [RST_BUS_EPHY] = { 0x2c8, BIT(2) },
+
+ [RST_BUS_CODEC] = { 0x2d0, BIT(0) },
+
+ [RST_BUS_I2C0] = { 0x2d8, BIT(0) },
+ [RST_BUS_I2C1] = { 0x2d8, BIT(1) },
+ [RST_BUS_UART0] = { 0x2d8, BIT(16) },
+ [RST_BUS_UART1] = { 0x2d8, BIT(17) },
+ [RST_BUS_UART2] = { 0x2d8, BIT(18) },
+};
+
+static const struct sunxi_ccu_desc sun8i_v3s_ccu_desc = {
+ .ccu_clks = sun8i_v3s_ccu_clks,
+ .num_ccu_clks = ARRAY_SIZE(sun8i_v3s_ccu_clks),
+
+ .hw_clks = &sun8i_v3s_hw_clks,
+
+ .resets = sun8i_v3s_ccu_resets,
+ .num_resets = ARRAY_SIZE(sun8i_v3s_ccu_resets),
+};
+
+static void __init sun8i_v3s_ccu_setup(struct device_node *node)
+{
+ void __iomem *reg;
+ u32 val;
+
+ 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;
+ }
+
+ /* Force the PLL-Audio-1x divider to 4 */
+ val = readl(reg + SUN8I_V3S_PLL_AUDIO_REG);
+ val &= ~GENMASK(19, 16);
+ writel(val | (3 << 16), reg + SUN8I_V3S_PLL_AUDIO_REG);
+
+ sunxi_ccu_probe(node, reg, &sun8i_v3s_ccu_desc);
+}
+CLK_OF_DECLARE(sun8i_v3s_ccu, "allwinner,sun8i-v3s-ccu",
+ sun8i_v3s_ccu_setup);
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-v3s.h b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.h
new file mode 100644
index 000000000000..4a4d36fdad96
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.h
@@ -0,0 +1,63 @@
+/*
+ * Copyright (c) 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * Based on ccu-sun8i-h3.h, which is:
+ * Copyright (c) 2016 Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * 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_SUN8I_H3_H_
+#define _CCU_SUN8I_H3_H_
+
+#include <dt-bindings/clock/sun8i-v3s-ccu.h>
+#include <dt-bindings/reset/sun8i-v3s-ccu.h>
+
+#define CLK_PLL_CPU 0
+#define CLK_PLL_AUDIO_BASE 1
+#define CLK_PLL_AUDIO 2
+#define CLK_PLL_AUDIO_2X 3
+#define CLK_PLL_AUDIO_4X 4
+#define CLK_PLL_AUDIO_8X 5
+#define CLK_PLL_VIDEO 6
+#define CLK_PLL_VE 7
+#define CLK_PLL_DDR 8
+#define CLK_PLL_PERIPH0 9
+#define CLK_PLL_PERIPH0_2X 10
+#define CLK_PLL_ISP 11
+#define CLK_PLL_PERIPH1 12
+/* Reserve one number for not implemented and not used PLL_DDR1 */
+
+/* The CPU clock is exported */
+
+#define CLK_AXI 15
+#define CLK_AHB1 16
+#define CLK_APB1 17
+#define CLK_APB2 18
+#define CLK_AHB2 19
+
+/* All the bus gates are exported */
+
+/* The first bunch of module clocks are exported */
+
+#define CLK_DRAM 58
+
+/* All the DRAM gates are exported */
+
+/* Some more module clocks are exported */
+
+#define CLK_MBUS 72
+
+/* And the GPU module clock is exported */
+
+#define CLK_NUMBER (CLK_MIPI_CSI + 1)
+
+#endif /* _CCU_SUN8I_H3_H_ */
diff --git a/include/dt-bindings/clock/sun8i-v3s-ccu.h b/include/dt-bindings/clock/sun8i-v3s-ccu.h
new file mode 100644
index 000000000000..c0d5d5599c87
--- /dev/null
+++ b/include/dt-bindings/clock/sun8i-v3s-ccu.h
@@ -0,0 +1,107 @@
+/*
+ * Copyright (c) 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * Based on sun8i-h3-ccu.h, which is:
+ * Copyright (C) 2016 Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * 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_SUN8I_V3S_H_
+#define _DT_BINDINGS_CLK_SUN8I_V3S_H_
+
+#define CLK_CPU 14
+
+#define CLK_BUS_CE 20
+#define CLK_BUS_DMA 21
+#define CLK_BUS_MMC0 22
+#define CLK_BUS_MMC1 23
+#define CLK_BUS_MMC2 24
+#define CLK_BUS_DRAM 25
+#define CLK_BUS_EMAC 26
+#define CLK_BUS_HSTIMER 27
+#define CLK_BUS_SPI0 28
+#define CLK_BUS_OTG 29
+#define CLK_BUS_EHCI0 30
+#define CLK_BUS_OHCI0 31
+#define CLK_BUS_VE 32
+#define CLK_BUS_TCON0 33
+#define CLK_BUS_CSI 34
+#define CLK_BUS_DE 35
+#define CLK_BUS_CODEC 36
+#define CLK_BUS_PIO 37
+#define CLK_BUS_I2C0 38
+#define CLK_BUS_I2C1 39
+#define CLK_BUS_UART0 40
+#define CLK_BUS_UART1 41
+#define CLK_BUS_UART2 42
+#define CLK_BUS_EPHY 43
+#define CLK_BUS_DBG 44
+
+#define CLK_MMC0 45
+#define CLK_MMC0_SAMPLE 46
+#define CLK_MMC0_OUTPUT 47
+#define CLK_MMC1 48
+#define CLK_MMC1_SAMPLE 49
+#define CLK_MMC1_OUTPUT 50
+#define CLK_MMC2 51
+#define CLK_MMC2_SAMPLE 52
+#define CLK_MMC2_OUTPUT 53
+#define CLK_CE 54
+#define CLK_SPI0 55
+#define CLK_USB_PHY0 56
+#define CLK_USB_OHCI0 57
+
+#define CLK_DRAM_VE 59
+#define CLK_DRAM_CSI 60
+#define CLK_DRAM_EHCI 61
+#define CLK_DRAM_OHCI 62
+#define CLK_DE 63
+#define CLK_TCON0 64
+#define CLK_CSI_MISC 65
+#define CLK_CSI0_MCLK 66
+#define CLK_CSI1_SCLK 67
+#define CLK_CSI1_MCLK 68
+#define CLK_VE 69
+#define CLK_AC_DIG 70
+#define CLK_AVS 71
+
+#define CLK_MIPI_CSI 73
+
+#endif /* _DT_BINDINGS_CLK_SUN8I_V3S_H_ */
diff --git a/include/dt-bindings/reset/sun8i-v3s-ccu.h b/include/dt-bindings/reset/sun8i-v3s-ccu.h
new file mode 100644
index 000000000000..b58ef21a2e18
--- /dev/null
+++ b/include/dt-bindings/reset/sun8i-v3s-ccu.h
@@ -0,0 +1,78 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * Based on sun8i-v3s-ccu.h, which is
+ * Copyright (C) 2016 Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * 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_SUN8I_V3S_H_
+#define _DT_BINDINGS_RST_SUN8I_V3S_H_
+
+#define RST_USB_PHY0 0
+
+#define RST_MBUS 1
+
+#define RST_BUS_CE 5
+#define RST_BUS_DMA 6
+#define RST_BUS_MMC0 7
+#define RST_BUS_MMC1 8
+#define RST_BUS_MMC2 9
+#define RST_BUS_DRAM 11
+#define RST_BUS_EMAC 12
+#define RST_BUS_HSTIMER 14
+#define RST_BUS_SPI0 15
+#define RST_BUS_OTG 17
+#define RST_BUS_EHCI0 18
+#define RST_BUS_OHCI0 22
+#define RST_BUS_VE 26
+#define RST_BUS_TCON0 27
+#define RST_BUS_CSI 30
+#define RST_BUS_DE 34
+#define RST_BUS_DBG 38
+#define RST_BUS_EPHY 39
+#define RST_BUS_CODEC 40
+#define RST_BUS_I2C0 46
+#define RST_BUS_I2C1 47
+#define RST_BUS_UART0 49
+#define RST_BUS_UART1 50
+#define RST_BUS_UART2 51
+
+#endif /* _DT_BINDINGS_RST_SUN8I_H3_H_ */
--
2.11.0
^ permalink raw reply related
* [PATCH v3 4/6] dt-bindings: add device binding for the CCU of Allwinner V3s
From: Icenowy Zheng @ 2017-01-19 17:54 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring
Cc: devicetree, linux-doc, linux-kernel, linux-gpio, Icenowy Zheng,
linux-clk, linux-arm-kernel
In-Reply-To: <20170119175448.11445-1-icenowy@aosc.xyz>
Allwinner V3s is now driven by sunxi-ng CCU driver.
Add devicetree binding for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
index 74d44a4273f2..f6032cf63f12 100644
--- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
@@ -7,6 +7,7 @@ Required properties :
- "allwinner,sun8i-a23-ccu"
- "allwinner,sun8i-a33-ccu"
- "allwinner,sun8i-h3-ccu"
+ - "allwinner,sun8i-v3s-ccu"
- "allwinner,sun50i-a64-ccu"
- reg: Must contain the registers base address and length
--
2.11.0
^ permalink raw reply related
* [PATCH v3 5/6] ARM: dts: sunxi: add dtsi file for V3s SoC
From: Icenowy Zheng @ 2017-01-19 17:54 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring
Cc: devicetree, linux-doc, linux-kernel, linux-gpio, Icenowy Zheng,
linux-clk, linux-arm-kernel
In-Reply-To: <20170119175448.11445-1-icenowy@aosc.xyz>
As we have the pinctrl and clock support for the V3s SoC, it's now to
run a mainline Linux on it.
So add a .dtsi file for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Changes in v3:
- Add USB nodes. (The PHY and MUSB patches are merged now)
Changes in v2:
- Added I2C here.
arch/arm/boot/dts/sun8i-v3s.dtsi | 312 +++++++++++++++++++++++++++++++++++++++
1 file changed, 312 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-v3s.dtsi
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
new file mode 100644
index 000000000000..d4628f4fa7f1
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -0,0 +1,312 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * 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.
+ */
+
+#include <dt-bindings/clock/sun8i-v3s-ccu.h>
+#include <dt-bindings/reset/sun8i-v3s-ccu.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&gic>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <0>;
+ clocks = <&ccu CLK_CPU>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ osc24M: osc24M_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ clock-output-names = "osc24M";
+ };
+
+ osc32k: osc32k_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ clock-output-names = "osc32k";
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ mmc0: mmc@01c0f000 {
+ compatible = "allwinner,sun7i-a20-mmc";
+ reg = <0x01c0f000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC0>,
+ <&ccu CLK_MMC0>,
+ <&ccu CLK_MMC0_OUTPUT>,
+ <&ccu CLK_MMC0_SAMPLE>;
+ clock-names = "ahb",
+ "mmc",
+ "output",
+ "sample";
+ resets = <&ccu RST_BUS_MMC0>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc1: mmc@01c10000 {
+ compatible = "allwinner,sun7i-a20-mmc";
+ reg = <0x01c10000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC1>,
+ <&ccu CLK_MMC1>,
+ <&ccu CLK_MMC1_OUTPUT>,
+ <&ccu CLK_MMC1_SAMPLE>;
+ clock-names = "ahb",
+ "mmc",
+ "output",
+ "sample";
+ resets = <&ccu RST_BUS_MMC1>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc2: mmc@01c11000 {
+ compatible = "allwinner,sun7i-a20-mmc";
+ reg = <0x01c11000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC2>,
+ <&ccu CLK_MMC2>,
+ <&ccu CLK_MMC2_OUTPUT>,
+ <&ccu CLK_MMC2_SAMPLE>;
+ clock-names = "ahb",
+ "mmc",
+ "output",
+ "sample";
+ resets = <&ccu RST_BUS_MMC2>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ usb_otg: usb@01c19000 {
+ compatible = "allwinner,sun8i-h3-musb";
+ reg = <0x01c19000 0x0400>;
+ clocks = <&ccu CLK_BUS_OTG>;
+ resets = <&ccu RST_BUS_OTG>;
+ interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mc";
+ phys = <&usbphy 0>;
+ phy-names = "usb";
+ extcon = <&usbphy 0>;
+ status = "disabled";
+ };
+
+ usbphy: phy@01c19400 {
+ compatible = "allwinner,sun8i-v3s-usb-phy";
+ reg = <0x01c19400 0x2c>,
+ <0x01c1a800 0x4>;
+ reg-names = "phy_ctrl",
+ "pmu0";
+ clocks = <&ccu CLK_USB_PHY0>;
+ clock-names = "usb0_phy";
+ resets = <&ccu RST_USB_PHY0>;
+ reset-names = "usb0_reset";
+ status = "disabled";
+ #phy-cells = <1>;
+ };
+
+ ccu: clock@01c20000 {
+ compatible = "allwinner,sun8i-v3s-ccu";
+ reg = <0x01c20000 0x400>;
+ clocks = <&osc24M>, <&osc32k>;
+ clock-names = "hosc", "losc";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ rtc: rtc@01c20400 {
+ compatible = "allwinner,sun6i-a31-rtc";
+ reg = <0x01c20400 0x54>;
+ interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ pio: pinctrl@01c20800 {
+ compatible = "allwinner,sun8i-v3s-pinctrl";
+ reg = <0x01c20800 0x400>;
+ interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_PIO>, <&osc24M>, <&osc32k>;
+ clock-names = "apb", "hosc", "losc";
+ gpio-controller;
+ #gpio-cells = <3>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+
+ i2c0_pins: i2c0 {
+ pins = "PB6", "PB7";
+ function = "i2c0";
+ };
+
+ uart0_pins_a: uart0@0 {
+ pins = "PB8", "PB9";
+ function = "uart0";
+ };
+
+ mmc0_pins_a: mmc0@0 {
+ pins = "PF0", "PF1", "PF2", "PF3",
+ "PF4", "PF5";
+ function = "mmc0";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+ };
+
+ timer@01c20c00 {
+ compatible = "allwinner,sun4i-a10-timer";
+ reg = <0x01c20c00 0xa0>;
+ interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&osc24M>;
+ };
+
+ wdt0: watchdog@01c20ca0 {
+ compatible = "allwinner,sun6i-a31-wdt";
+ reg = <0x01c20ca0 0x20>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ uart0: serial@01c28000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28000 0x400>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART0>;
+ resets = <&ccu RST_BUS_UART0>;
+ status = "disabled";
+ };
+
+ uart1: serial@01c28400 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28400 0x400>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART1>;
+ resets = <&ccu RST_BUS_UART1>;
+ status = "disabled";
+ };
+
+ uart2: serial@01c28800 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28800 0x400>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART2>;
+ resets = <&ccu RST_BUS_UART2>;
+ status = "disabled";
+ };
+
+ i2c0: i2c@01c2ac00 {
+ compatible = "allwinner,sun6i-a31-i2c";
+ reg = <0x01c2ac00 0x400>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C0>;
+ resets = <&ccu RST_BUS_I2C0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c1: i2c@01c2b000 {
+ compatible = "allwinner,sun6i-a31-i2c";
+ reg = <0x01c2b000 0x400>;
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C1>;
+ resets = <&ccu RST_BUS_I2C1>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ gic: interrupt-controller@01c81000 {
+ compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
+ reg = <0x01c81000 0x1000>,
+ <0x01c82000 0x1000>,
+ <0x01c84000 0x2000>,
+ <0x01c86000 0x2000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+ };
+ };
+};
--
2.11.0
^ permalink raw reply related
* [PATCH v3 6/6] ARM: dts: sunxi: add support for Lichee Pi Zero board
From: Icenowy Zheng @ 2017-01-19 17:54 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring
Cc: devicetree, linux-doc, linux-kernel, linux-gpio, Icenowy Zheng,
linux-clk, linux-arm-kernel
In-Reply-To: <20170119175448.11445-1-icenowy@aosc.xyz>
Lichee Pi Zero is a small-sized V3s board, which is
breadboard-compatible, and with a MicroUSB port with both OTG function
and power function.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Changes in v3:
- Add LEDs.
- Add USB-related nodes.
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 103 ++++++++++++++++++++++++++
2 files changed, 105 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cccdbcb557b6..3e099e9b1ad7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -853,7 +853,8 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-h3-orangepi-pc-plus.dtb \
sun8i-h3-orangepi-plus.dtb \
sun8i-h3-orangepi-plus2e.dtb \
- sun8i-r16-parrot.dtb
+ sun8i-r16-parrot.dtb \
+ sun8i-v3s-licheepi-zero.dtb
dtb-$(CONFIG_MACH_SUN9I) += \
sun9i-a80-optimus.dtb \
sun9i-a80-cubieboard4.dtb
diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
new file mode 100644
index 000000000000..387fc2aa546d
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
@@ -0,0 +1,103 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include "sun8i-v3s.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+/ {
+ model = "Lichee Pi Zero";
+ compatible = "licheepi,licheepi-zero", "allwinner,sun8i-v3s";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ blue_led {
+ label = "licheepi:blue:usr";
+ gpios = <&pio 6 1 GPIO_ACTIVE_LOW>; /* PG1 */
+ };
+
+ green_led {
+ label = "licheepi:green:usr";
+ gpios = <&pio 6 0 GPIO_ACTIVE_LOW>; /* PG0 */
+ default-state = "on";
+ };
+
+ red_led {
+ label = "licheepi:red:usr";
+ gpios = <&pio 6 2 GPIO_ACTIVE_LOW>; /* PG2 */
+ };
+ };
+};
+
+&mmc0 {
+ pinctrl-0 = <&mmc0_pins_a>;
+ pinctrl-names = "default";
+ broken-cd;
+ bus-width = <4>;
+ vmmc-supply = <®_vcc3v3>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-0 = <&uart0_pins_a>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v3] mtd: spi-nor: add dt support for Everspin MRAMs
From: Rob Herring @ 2017-01-19 17:56 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Marek Vasut, Mark Rutland, devicetree, Rafał Miłecki,
Masahiko Iwamoto, linux-mtd, kernel, Geert Uytterhoeven,
Cyrille Pitchen, Jagan Teki
In-Reply-To: <20170117110338.10756-1-u.kleine-koenig@pengutronix.de>
On Tue, Jan 17, 2017 at 12:03:38PM +0100, Uwe Kleine-König wrote:
> The MR25 family doesn't support JEDEC, so they need explicit mentioning
> in the list of supported spi IDs. This makes it possible to add these
> using for example:
>
> compatible = "everspin,mr25h40";
>
> There was already an entry for mr25h256. Move that one out of the "keep
> for compatibility" section and put in a new group for Everspin MRAMs.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Changes since (implicit) v1:
>
> - use Kib instead of kib
>
> Changes since v2:
>
> - update dt docs
> - handle already existing mr25h256 in m25p_ids[]
>
> Thanks to Cyrille for catching these.
>
> Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 2 ++
> drivers/mtd/devices/m25p80.c | 6 +++++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH 2/3] ARM64: dts: meson-gxbb: Add support for WeTek Hub and Play
From: Kevin Hilman @ 2017-01-19 18:02 UTC (permalink / raw)
To: Neil Armstrong
Cc: carlo, linux-amlogic, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <61c3c24d-57cd-b81d-0225-5aae14352397@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> On 01/18/2017 11:53 PM, Kevin Hilman wrote:
>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>
>>> Adds support for the WeTek Hub and Play2 boards.
>>> The Hub is an extremely small IPTv Set-Top-Box and the Play2 is a more
>>> traditionnal Satellite or Terrestrial and IPTv Set-Top-Box.
>>>
>>> Both are based on the p200 Reference Design and out-of-tree support is
>>> based on OpenELEC kernel at [1].
>>>
>>> [1] https://github.com/wetek-enigma/linux-amlogic
>>>
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>
>> Did you get the GPIO/button info from the LibreELEC tree or did you find
>> some schematics someplace? If you found any schematics, it would be
>> nice to have links in the DTS files.
>>
>> Kevin
>>
>
> It was in the dts of the LibreELEC tree, I found no schematics so far.
> I can respin a v2 with a link to the LibreELEC dts files.
No need for a respin. But I'll s/OpenELEC/LibreELEC/ in the commit
message when applying.
Kevin
^ permalink raw reply
* Applied "regulator: qcom-smd: Add PM8994 regulator support" to the regulator tree
From: Mark Brown @ 2017-01-19 18:04 UTC (permalink / raw)
To: Rajendra Nayak; +Cc: Bjorn Andersson, Mark Brown, Liam Girdwood
In-Reply-To: <20170118104637.3312-1-bjorn.andersson@linaro.org>
The patch
regulator: qcom-smd: Add PM8994 regulator support
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 14a1699225957328e4fb07db7e4751cc9d02ae11 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <rnayak@codeaurora.org>
Date: Wed, 18 Jan 2017 02:46:37 -0800
Subject: [PATCH] regulator: qcom-smd: Add PM8994 regulator support
This patch adds support for the PM8994 regulators found on msm8992,
msm8994 and msm8996 platforms.
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
[bjorn: Add DT binding doc and vdd_lvs1_2 supply]
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../bindings/regulator/qcom,smd-rpm-regulator.txt | 56 +++++++++++
drivers/regulator/qcom_smd-regulator.c | 102 +++++++++++++++++++++
2 files changed, 158 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
index 1f8d6f84b657..4e3dfb5b5f16 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
@@ -22,6 +22,7 @@ Regulator nodes are identified by their compatible:
"qcom,rpm-pm8841-regulators"
"qcom,rpm-pm8916-regulators"
"qcom,rpm-pm8941-regulators"
+ "qcom,rpm-pm8994-regulators"
"qcom,rpm-pma8084-regulators"
- vdd_s1-supply:
@@ -80,6 +81,56 @@ Regulator nodes are identified by their compatible:
- vdd_s10-supply:
- vdd_s11-supply:
- vdd_s12-supply:
+- vdd_l1-supply:
+- vdd_l2_l26_l28-supply:
+- vdd_l3_l11-supply:
+- vdd_l4_l27_l31-supply:
+- vdd_l5_l7-supply:
+- vdd_l6_l12_l32-supply:
+- vdd_l5_l7-supply:
+- vdd_l8_l16_l30-supply:
+- vdd_l9_l10_l18_l22-supply:
+- vdd_l9_l10_l18_l22-supply:
+- vdd_l3_l11-supply:
+- vdd_l6_l12_l32-supply:
+- vdd_l13_l19_l23_l24-supply:
+- vdd_l14_l15-supply:
+- vdd_l14_l15-supply:
+- vdd_l8_l16_l30-supply:
+- vdd_l17_l29-supply:
+- vdd_l9_l10_l18_l22-supply:
+- vdd_l13_l19_l23_l24-supply:
+- vdd_l20_l21-supply:
+- vdd_l20_l21-supply:
+- vdd_l9_l10_l18_l22-supply:
+- vdd_l13_l19_l23_l24-supply:
+- vdd_l13_l19_l23_l24-supply:
+- vdd_l25-supply:
+- vdd_l2_l26_l28-supply:
+- vdd_l4_l27_l31-supply:
+- vdd_l2_l26_l28-supply:
+- vdd_l17_l29-supply:
+- vdd_l8_l16_l30-supply:
+- vdd_l4_l27_l31-supply:
+- vdd_l6_l12_l32-supply:
+- vdd_lvs1_2-supply:
+ Usage: optional (pm8994 only)
+ Value type: <phandle>
+ Definition: reference to regulator supplying the input pin, as
+ described in the data sheet
+
+- vdd_s1-supply:
+- vdd_s2-supply:
+- vdd_s3-supply:
+- vdd_s4-supply:
+- vdd_s5-supply:
+- vdd_s6-supply:
+- vdd_s7-supply:
+- vdd_s8-supply:
+- vdd_s9-supply:
+- vdd_s10-supply:
+- vdd_s11-supply:
+- vdd_s12-supply:
- vdd_l1_l11-supply:
- vdd_l2_l3_l4_l27-supply:
- vdd_l5_l7-supply:
@@ -113,6 +164,11 @@ pm8941:
l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2,
lvs3, 5vs1, 5vs2
+pm8994:
+ s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, l1, l2, l3, l4, l5,
+ l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20,
+ l21, l22, l23, l24, l25, l26, l27, l28, l29, l30, l31, l32, lvs1, lvs2
+
pma8084:
s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, l1, l2, l3, l4, l5,
l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20,
diff --git a/drivers/regulator/qcom_smd-regulator.c b/drivers/regulator/qcom_smd-regulator.c
index 8ed46a9a55c8..f35994a2a5be 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -305,6 +305,56 @@ static const struct regulator_desc pm8916_buck_hvo_smps = {
.ops = &rpm_smps_ldo_ops,
};
+static const struct regulator_desc pm8994_hfsmps = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE( 375000, 0, 95, 12500),
+ REGULATOR_LINEAR_RANGE(1550000, 96, 158, 25000),
+ },
+ .n_linear_ranges = 2,
+ .n_voltages = 159,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8994_ftsmps = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(350000, 0, 199, 5000),
+ REGULATOR_LINEAR_RANGE(700000, 200, 349, 10000),
+ },
+ .n_linear_ranges = 2,
+ .n_voltages = 350,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8994_nldo = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(750000, 0, 63, 12500),
+ },
+ .n_linear_ranges = 1,
+ .n_voltages = 64,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8994_pldo = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE( 750000, 0, 63, 12500),
+ REGULATOR_LINEAR_RANGE(1550000, 64, 126, 25000),
+ REGULATOR_LINEAR_RANGE(3100000, 127, 163, 50000),
+ },
+ .n_linear_ranges = 3,
+ .n_voltages = 164,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8994_switch = {
+ .ops = &rpm_switch_ops,
+};
+
+static const struct regulator_desc pm8994_lnldo = {
+ .fixed_uV = 1740000,
+ .n_voltages = 1,
+ .ops = &rpm_smps_ldo_ops_fixed,
+};
+
struct rpm_regulator_data {
const char *name;
u32 type;
@@ -443,10 +493,62 @@ static const struct rpm_regulator_data rpm_pma8084_regulators[] = {
{}
};
+static const struct rpm_regulator_data rpm_pm8994_regulators[] = {
+ { "s1", QCOM_SMD_RPM_SMPA, 1, &pm8994_ftsmps, "vdd_s1" },
+ { "s2", QCOM_SMD_RPM_SMPA, 2, &pm8994_ftsmps, "vdd_s2" },
+ { "s3", QCOM_SMD_RPM_SMPA, 3, &pm8994_hfsmps, "vdd_s3" },
+ { "s4", QCOM_SMD_RPM_SMPA, 4, &pm8994_hfsmps, "vdd_s4" },
+ { "s5", QCOM_SMD_RPM_SMPA, 5, &pm8994_hfsmps, "vdd_s5" },
+ { "s6", QCOM_SMD_RPM_SMPA, 6, &pm8994_ftsmps, "vdd_s6" },
+ { "s7", QCOM_SMD_RPM_SMPA, 7, &pm8994_hfsmps, "vdd_s7" },
+ { "s8", QCOM_SMD_RPM_SMPA, 8, &pm8994_ftsmps, "vdd_s8" },
+ { "s9", QCOM_SMD_RPM_SMPA, 9, &pm8994_ftsmps, "vdd_s9" },
+ { "s10", QCOM_SMD_RPM_SMPA, 10, &pm8994_ftsmps, "vdd_s10" },
+ { "s11", QCOM_SMD_RPM_SMPA, 11, &pm8994_ftsmps, "vdd_s11" },
+ { "s12", QCOM_SMD_RPM_SMPA, 12, &pm8994_ftsmps, "vdd_s12" },
+ { "l1", QCOM_SMD_RPM_LDOA, 1, &pm8994_nldo, "vdd_l1" },
+ { "l2", QCOM_SMD_RPM_LDOA, 2, &pm8994_nldo, "vdd_l2_l26_l28" },
+ { "l3", QCOM_SMD_RPM_LDOA, 3, &pm8994_nldo, "vdd_l3_l11" },
+ { "l4", QCOM_SMD_RPM_LDOA, 4, &pm8994_nldo, "vdd_l4_l27_l31" },
+ { "l5", QCOM_SMD_RPM_LDOA, 5, &pm8994_lnldo, "vdd_l5_l7" },
+ { "l6", QCOM_SMD_RPM_LDOA, 6, &pm8994_pldo, "vdd_l6_l12_l32" },
+ { "l7", QCOM_SMD_RPM_LDOA, 7, &pm8994_lnldo, "vdd_l5_l7" },
+ { "l8", QCOM_SMD_RPM_LDOA, 8, &pm8994_pldo, "vdd_l8_l16_l30" },
+ { "l9", QCOM_SMD_RPM_LDOA, 9, &pm8994_pldo, "vdd_l9_l10_l18_l22" },
+ { "l10", QCOM_SMD_RPM_LDOA, 10, &pm8994_pldo, "vdd_l9_l10_l18_l22" },
+ { "l11", QCOM_SMD_RPM_LDOA, 11, &pm8994_nldo, "vdd_l3_l11" },
+ { "l12", QCOM_SMD_RPM_LDOA, 12, &pm8994_pldo, "vdd_l6_l12_l32" },
+ { "l13", QCOM_SMD_RPM_LDOA, 13, &pm8994_pldo, "vdd_l13_l19_l23_l24" },
+ { "l14", QCOM_SMD_RPM_LDOA, 14, &pm8994_pldo, "vdd_l14_l15" },
+ { "l15", QCOM_SMD_RPM_LDOA, 15, &pm8994_pldo, "vdd_l14_l15" },
+ { "l16", QCOM_SMD_RPM_LDOA, 16, &pm8994_pldo, "vdd_l8_l16_l30" },
+ { "l17", QCOM_SMD_RPM_LDOA, 17, &pm8994_pldo, "vdd_l17_l29" },
+ { "l18", QCOM_SMD_RPM_LDOA, 18, &pm8994_pldo, "vdd_l9_l10_l18_l22" },
+ { "l19", QCOM_SMD_RPM_LDOA, 19, &pm8994_pldo, "vdd_l13_l19_l23_l24" },
+ { "l20", QCOM_SMD_RPM_LDOA, 20, &pm8994_pldo, "vdd_l20_l21" },
+ { "l21", QCOM_SMD_RPM_LDOA, 21, &pm8994_pldo, "vdd_l20_l21" },
+ { "l22", QCOM_SMD_RPM_LDOA, 22, &pm8994_pldo, "vdd_l9_l10_l18_l22" },
+ { "l23", QCOM_SMD_RPM_LDOA, 23, &pm8994_pldo, "vdd_l13_l19_l23_l24" },
+ { "l24", QCOM_SMD_RPM_LDOA, 24, &pm8994_pldo, "vdd_l13_l19_l23_l24" },
+ { "l25", QCOM_SMD_RPM_LDOA, 25, &pm8994_pldo, "vdd_l25" },
+ { "l26", QCOM_SMD_RPM_LDOA, 26, &pm8994_nldo, "vdd_l2_l26_l28" },
+ { "l27", QCOM_SMD_RPM_LDOA, 27, &pm8994_nldo, "vdd_l4_l27_l31" },
+ { "l28", QCOM_SMD_RPM_LDOA, 28, &pm8994_nldo, "vdd_l2_l26_l28" },
+ { "l29", QCOM_SMD_RPM_LDOA, 29, &pm8994_pldo, "vdd_l17_l29" },
+ { "l30", QCOM_SMD_RPM_LDOA, 30, &pm8994_pldo, "vdd_l8_l16_l30" },
+ { "l31", QCOM_SMD_RPM_LDOA, 31, &pm8994_nldo, "vdd_l4_l27_l31" },
+ { "l32", QCOM_SMD_RPM_LDOA, 32, &pm8994_pldo, "vdd_l6_l12_l32" },
+ { "lvs1", QCOM_SMD_RPM_VSA, 1, &pm8994_switch, "vdd_lvs1_2" },
+ { "lvs2", QCOM_SMD_RPM_VSA, 2, &pm8994_switch, "vdd_lvs1_2" },
+
+ {}
+};
+
static const struct of_device_id rpm_of_match[] = {
{ .compatible = "qcom,rpm-pm8841-regulators", .data = &rpm_pm8841_regulators },
{ .compatible = "qcom,rpm-pm8916-regulators", .data = &rpm_pm8916_regulators },
{ .compatible = "qcom,rpm-pm8941-regulators", .data = &rpm_pm8941_regulators },
+ { .compatible = "qcom,rpm-pm8994-regulators", .data = &rpm_pm8994_regulators },
{ .compatible = "qcom,rpm-pma8084-regulators", .data = &rpm_pma8084_regulators },
{}
};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] ARM64: dts: meson-gxm: Rename q200 and q201 DT files for consistency
From: Kevin Hilman @ 2017-01-19 18:05 UTC (permalink / raw)
To: Neil Armstrong
Cc: devicetree, linux-kernel, carlo, linux-amlogic, afaerber,
linux-arm-kernel
In-Reply-To: <1484814117-7593-1-git-send-email-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> In order to keep consistency naming with the Nexbox A1 DTS file, remove the
> S912 SoC name in the GXM DT files.
>
> Suggested-by: Andreas Färber <afaerber@suse.de>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Thanks for the cleanup.
Applied to v4.11/dt64
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 2/4] Documentation: dt: add bindings for ti-cpufreq
From: Rob Herring @ 2017-01-19 18:07 UTC (permalink / raw)
To: Dave Gerlach
Cc: Viresh Kumar, Rafael J . Wysocki,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren, Nishanth Menon
In-Reply-To: <20170117131808.29798-3-d-gerlach-l0cyMroinI0@public.gmane.org>
On Tue, Jan 17, 2017 at 07:18:06AM -0600, Dave Gerlach wrote:
> Add the device tree bindings document for the TI CPUFreq/OPP driver
> on AM33xx, AM43xx, DRA7xx, and AM57xx SoCs. The operating-points-v2
> binding allows us to provide an opp-supported-hw property for each OPP
> to define when it is available. This driver is responsible for reading
> and parsing registers to determine which OPPs can be selectively enabled
> based on the specific SoC in use by matching against the opp-supported-hw
> data.
>
> Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
> ---
> v3->v4:
> Update to simplify binding, only use "syscon" now to pass control
> module register space and let driver handle offsets.
>
> .../devicetree/bindings/cpufreq/ti-cpufreq.txt | 128 +++++++++++++++++++++
> 1 file changed, 128 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
> new file mode 100644
> index 000000000000..58efa4c72545
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
> @@ -0,0 +1,128 @@
> +TI CPUFreq and OPP bindings
> +================================
> +
> +Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
> +families support different OPPs depending on the silicon variant in use.
> +The ti-cpufreq driver can use revision and an efuse value from the SoC to
> +provide the OPP framework with supported hardware information. This is
> +used to determine which OPPs from the operating-points-v2 table get enabled
> +when it is parsed by the OPP framework.
> +
> +Required properties:
> +--------------------
> +In 'cpus' nodes:
> +- operating-points-v2: Phandle to the operating-points-v2 table to use.
> +
> +In 'operating-points-v2' table:
> +- compatible: Should be
> + - 'operating-points-v2-ti-cpu' for am335x, am43xx, and dra7xx/am57xx SoCs
> +- syscon: A phandle pointing to a syscon node representing the control module
> + register space of the SoC.
> +
> +Optional properties:
> +--------------------
> +For each opp entry in 'operating-points-v2' table:
> +- opp-supported-hw: Two bitfields indicating:
> + 1. Which revision of the SoC the OPP is supported by
> + 2. Which eFuse bits indicate this OPP is available
> +
> + A bitwise AND is performed against these values and if any bit
> + matches, the OPP gets enabled.
> +
> +Example:
> +--------
> +
> +/* From arch/arm/boot/dts/am33xx.dtsi */
> +cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu@0 {
> + compatible = "arm,cortex-a8";
> + device_type = "cpu";
> + reg = <0>;
> +
> + operating-points-v2 = <&cpu0_opp_table>;
> +
> + clocks = <&dpll_mpu_ck>;
> + clock-names = "cpu";
> +
> + clock-latency = <300000>; /* From omap-cpufreq driver */
> + };
> +};
> +
> +/*
> + * cpu0 has different OPPs depending on SoC revision and some on revisions
> + * 0x2 and 0x4 have eFuse bits that indicate if they are available or not
> + */
> +cpu0_opp_table: opp_table0 {
Just "opp-table {"
> + compatible = "operating-points-v2-ti-cpu";
> + syscon = <&scm_conf>;
> +
> + /*
> + * The three following nodes are marked with opp-suspend
> + * because they can not be enabled simultaneously on a
> + * single SoC.
> + */
> + opp50@300000000 {
What's the 50, 100, 120 in the names?
> + opp-hz = /bits/ 64 <300000000>;
> + opp-microvolt = <950000 931000 969000>;
> + opp-supported-hw = <0x06 0x0010>;
> + opp-suspend;
> + };
> +
> + opp100@275000000 {
> + opp-hz = /bits/ 64 <275000000>;
> + opp-microvolt = <1100000 1078000 1122000>;
> + opp-supported-hw = <0x01 0x00FF>;
> + opp-suspend;
> + };
> +
> + opp100@300000000 {
> + opp-hz = /bits/ 64 <300000000>;
> + opp-microvolt = <1100000 1078000 1122000>;
> + opp-supported-hw = <0x06 0x0020>;
> + opp-suspend;
> + };
> +
> + opp100@500000000 {
> + opp-hz = /bits/ 64 <500000000>;
> + opp-microvolt = <1100000 1078000 1122000>;
> + opp-supported-hw = <0x01 0xFFFF>;
> + };
> +
> + opp100@600000000 {
> + opp-hz = /bits/ 64 <600000000>;
> + opp-microvolt = <1100000 1078000 1122000>;
> + opp-supported-hw = <0x06 0x0040>;
> + };
> +
> + opp120@600000000 {
> + opp-hz = /bits/ 64 <600000000>;
> + opp-microvolt = <1200000 1176000 1224000>;
> + opp-supported-hw = <0x01 0xFFFF>;
> + };
> +
> + opp120@720000000 {
> + opp-hz = /bits/ 64 <720000000>;
> + opp-microvolt = <1200000 1176000 1224000>;
> + opp-supported-hw = <0x06 0x0080>;
> + };
> +
> + oppturbo@720000000 {
> + opp-hz = /bits/ 64 <720000000>;
> + opp-microvolt = <1260000 1234800 1285200>;
> + opp-supported-hw = <0x01 0xFFFF>;
> + };
> +
> + oppturbo@800000000 {
> + opp-hz = /bits/ 64 <800000000>;
> + opp-microvolt = <1260000 1234800 1285200>;
> + opp-supported-hw = <0x06 0x0100>;
> + };
> +
> + oppnitro@1000000000 {
> + opp-hz = /bits/ 64 <1000000000>;
> + opp-microvolt = <1325000 1298500 1351500>;
> + opp-supported-hw = <0x04 0x0200>;
> + };
> +};
> --
> 2.11.0
>
--
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 v2 2/7] usb: usb: dsps: update device tree bindings
From: Rob Herring @ 2017-01-19 18:15 UTC (permalink / raw)
To: Alexandre Bailon
Cc: vinod.koul-ral2JQCrhuEAvxtiuMwx3w, b-liu-l0cyMroinI0,
dmaengine-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170117134540.9988-3-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Tue, Jan 17, 2017 at 02:45:35PM +0100, Alexandre Bailon wrote:
> In order to make CPPI 4.1 DMA driver more generic, accesses to USBSS
> have been removed. So it is not required anymore to define "glue"
> register's address and size in DT.
> Update dsps device tree bindings.
Looks like you are breaking compatibility here.
Are the glue registers already in the USB node? If so, then the DMA
driver just needs to ignore the first reg entry when 4 entries are
present. Or add a fixup to the DT somewhere.
>
> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/am33xx-usb.txt | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> index 20c2ff2..ef89010 100644
> --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> @@ -54,9 +54,9 @@ node.
> DMA
> ~~~
> - compatible: ti,am3359-cppi41
> -- reg: offset and length of the following register spaces: USBSS, USB
> +- reg: offset and length of the following register spaces: USB
> CPPI DMA Controller, USB CPPI DMA Scheduler, USB Queue Manager
> -- reg-names: glue, controller, scheduler, queuemgr
> +- reg-names: controller, scheduler, queuemgr
> - #dma-cells: should be set to 2. The first number represents the
> endpoint number (0 … 14 for endpoints 1 … 15 on instance 0 and 15 … 29
> for endpoints 1 … 15 on instance 1). The second number is 0 for RX and
> @@ -183,11 +183,10 @@ usb: usb@47400000 {
>
> cppi41dma: dma-controller@07402000 {
> compatible = "ti,am3359-cppi41";
> - reg = <0x47400000 0x1000
> - 0x47402000 0x1000
> + reg = <0x47402000 0x1000
> 0x47403000 0x1000
> 0x47404000 0x4000>;
> - reg-names = "glue", "controller", "scheduler", "queuemgr";
> + reg-names = "controller", "scheduler", "queuemgr";
> interrupts = <17>;
> interrupt-names = "glue";
> #dma-cells = <2>;
> --
> 2.10.2
>
--
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 1/3] Input: add STMicroelectronics FingerTip touchscreen driver
From: Rob Herring @ 2017-01-19 18:19 UTC (permalink / raw)
To: Andi Shyti
Cc: Dmitry Torokhov, Krzysztof Kozlowski, Chanwoo Choi,
Javier Martinez Canillas, linux-input, devicetree, linux-kernel,
linux-samsung-soc, Andi Shyti
In-Reply-To: <20170117135441.31450-2-andi.shyti@samsung.com>
On Tue, Jan 17, 2017 at 10:54:39PM +0900, Andi Shyti wrote:
> Add binding for the STMicroelectronics FingerTip (stmfts)
> touchscreen driver.
Bindings describe h/w not drivers.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> ---
> .../bindings/input/touchscreen/st,stmfts.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/st,stmfts.txt
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.txt b/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.txt
> new file mode 100644
> index 000000000000..788f4ba744db
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.txt
> @@ -0,0 +1,43 @@
> +* ST-Microelectronics FingerTip touchscreen controller
> +
> +The ST-Microelectronics FingerTip device provides a basic touchscreen
> +functionality. Along with it the user can enable the touchkey which can work as
> +a basic HOME and BACK key for phones.
> +
> +The driver supports also hovering as an absolute single touch event with x, y, z
> +coordinates.
> +
> +Required properties:
> +- compatible : must be "st,stmfts"
Seems too generic. Is this a single device?
> +- reg : I2C slave address, (e.g. 0x49)
> +- interrupt-parent : the phandle to the interrupt controller which provides
> + the interrupt
> +- interrupts : interrupt specification
> +- avdd-supply : analogic power supply
> +- vdd-supply : power supply
> +- touchscreen-size-x : see touchscreen.txt
> +- touchscreen-size-y : see touchscreen.txt
> +
> +Optional properties:
> +- touch-key-connected : specifies whether the touchkey feature is connected
> +- ledvdd-supply : power supply to the touch key leds
> +
> +Example:
> +
> +i2c@00000000 {
> +
> + /* ... */
> +
> + stmfts@49 {
> + compatible = "st,stmfts";
> + reg = <0x49>;
> + interrupt-parent = <&gpa1>;
> + interrupts = <1 IRQ_TYPE_NONE>;
> + touchscreen-size-x = <1599>;
> + touchscreen-size-y = <2559>;
> + touch-key-connected;
> + avdd-supply = <&ldo30_reg>;
> + vdd-supply = <&ldo31_reg>;
> + ledvdd-supply = <&ldo33_reg>;
> + };
> +};
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH v2 1/3] dt/bindings: da8xx-usb: Add binding for the CPPI 4.1 DMA controller
From: Rob Herring @ 2017-01-19 18:24 UTC (permalink / raw)
To: Sekhar Nori
Cc: Sergei Shtylyov, Alexandre Bailon,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA, khilman-rdvid1DuHRBWk0Htik3J/w,
ptitiano-rdvid1DuHRBWk0Htik3J/w, tony-4v6yS6AI5VpBDgjK7y7TUQ,
linux-omap-u79uwXL29TY76Z2rM5mHXA, b-liu-l0cyMroinI0,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <710c724c-3831-e9d1-406b-76bdfed7b948-l0cyMroinI0@public.gmane.org>
On Wed, Jan 18, 2017 at 02:03:44PM +0530, Sekhar Nori wrote:
> On Tuesday 17 January 2017 10:46 PM, Sergei Shtylyov wrote:
> > On 01/17/2017 05:20 PM, Alexandre Bailon wrote:
> >
> >> DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx cppi41 dma controller.
> >>
> >> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> >> ---
> >> .../devicetree/bindings/usb/da8xx-usb.txt | 42
> >> ++++++++++++++++++++++
> >> 1 file changed, 42 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt
> >> b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
> >> index ccb844a..aed3169 100644
> >> --- a/Documentation/devicetree/bindings/usb/da8xx-usb.txt
> >> +++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
> >> @@ -18,10 +18,26 @@ Required properties:
> >>
> >> - phy-names: Should be "usb-phy"
> >>
> >> + - dmas: specifies the dma channels
> >> +
> >> + - dma-names: specifies the names of the channels. Use "rxN" for receive
> >> + and "txN" for transmit endpoints. N specifies the endpoint number.
> >> +
> >> Optional properties:
> >> ~~~~~~~~~~~~~~~~~~~~
> >> - vbus-supply: Phandle to a regulator providing the USB bus power.
> >>
> >> +DMA
> >> +~~~
> >> +- compatible: ti,da8xx-cppi41
> >
> > Almost missed this -- wildcards in this property are forbidden.
> > We should use "ti,da830-cppi41" as a least common denominator.
>
> Documentation/devicetree/bindings/submitting-patches.txt states:
>
> "
> 5) The wildcard "<chip>" may be used in compatible strings, as in
> the following example:
>
> - compatible: Must contain '"nvidia,<chip>-pcie",
> "nvidia,tegra20-pcie"' where <chip> is tegra30, tegra132, ...
> "
>
> I take this to mean that using wildcards to denote an SoC family on
> which the same IP is present is okay to do. With that understanding, I
> think using ti,da8xx-cppi41 is fine too. Although I have no objections
> against using the more specific ti,da830-cppi41
You may document things using the variable like above, but the end
result of compatible strings should not have wildcards.
Rob
--
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 v4 2/4] Documentation: dt: add bindings for ti-cpufreq
From: Dave Gerlach @ 2017-01-19 18:31 UTC (permalink / raw)
To: Rob Herring
Cc: Viresh Kumar, Rafael J . Wysocki,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren, Nishanth Menon
In-Reply-To: <20170119180702.62xg2ta5pq4mf7sd@rob-hp-laptop>
On 01/19/2017 12:07 PM, Rob Herring wrote:
> On Tue, Jan 17, 2017 at 07:18:06AM -0600, Dave Gerlach wrote:
>> Add the device tree bindings document for the TI CPUFreq/OPP driver
>> on AM33xx, AM43xx, DRA7xx, and AM57xx SoCs. The operating-points-v2
>> binding allows us to provide an opp-supported-hw property for each OPP
>> to define when it is available. This driver is responsible for reading
>> and parsing registers to determine which OPPs can be selectively enabled
>> based on the specific SoC in use by matching against the opp-supported-hw
>> data.
>>
>> Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
>> ---
>> v3->v4:
>> Update to simplify binding, only use "syscon" now to pass control
>> module register space and let driver handle offsets.
>>
>> .../devicetree/bindings/cpufreq/ti-cpufreq.txt | 128 +++++++++++++++++++++
>> 1 file changed, 128 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>> new file mode 100644
>> index 000000000000..58efa4c72545
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>> @@ -0,0 +1,128 @@
>> +TI CPUFreq and OPP bindings
>> +================================
>> +
>> +Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
>> +families support different OPPs depending on the silicon variant in use.
>> +The ti-cpufreq driver can use revision and an efuse value from the SoC to
>> +provide the OPP framework with supported hardware information. This is
>> +used to determine which OPPs from the operating-points-v2 table get enabled
>> +when it is parsed by the OPP framework.
>> +
>> +Required properties:
>> +--------------------
>> +In 'cpus' nodes:
>> +- operating-points-v2: Phandle to the operating-points-v2 table to use.
>> +
>> +In 'operating-points-v2' table:
>> +- compatible: Should be
>> + - 'operating-points-v2-ti-cpu' for am335x, am43xx, and dra7xx/am57xx SoCs
>> +- syscon: A phandle pointing to a syscon node representing the control module
>> + register space of the SoC.
>> +
>> +Optional properties:
>> +--------------------
>> +For each opp entry in 'operating-points-v2' table:
>> +- opp-supported-hw: Two bitfields indicating:
>> + 1. Which revision of the SoC the OPP is supported by
>> + 2. Which eFuse bits indicate this OPP is available
>> +
>> + A bitwise AND is performed against these values and if any bit
>> + matches, the OPP gets enabled.
>> +
>> +Example:
>> +--------
>> +
>> +/* From arch/arm/boot/dts/am33xx.dtsi */
>> +cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + cpu@0 {
>> + compatible = "arm,cortex-a8";
>> + device_type = "cpu";
>> + reg = <0>;
>> +
>> + operating-points-v2 = <&cpu0_opp_table>;
>> +
>> + clocks = <&dpll_mpu_ck>;
>> + clock-names = "cpu";
>> +
>> + clock-latency = <300000>; /* From omap-cpufreq driver */
>> + };
>> +};
>> +
>> +/*
>> + * cpu0 has different OPPs depending on SoC revision and some on revisions
>> + * 0x2 and 0x4 have eFuse bits that indicate if they are available or not
>> + */
>> +cpu0_opp_table: opp_table0 {
>
> Just "opp-table {"
Ok.
>
>> + compatible = "operating-points-v2-ti-cpu";
>> + syscon = <&scm_conf>;
>> +
>> + /*
>> + * The three following nodes are marked with opp-suspend
>> + * because they can not be enabled simultaneously on a
>> + * single SoC.
>> + */
>> + opp50@300000000 {
>
> What's the 50, 100, 120 in the names?
Those are the names of the OPPs given in Table 5-7 of the AM335x data
manual, seen here http://www.ti.com/lit/ds/symlink/am3359.pdf . I
typically reference the table and document in the commit message of the
actual DT patches but didn't here for the binding.
Regards,
Dave
>
>> + opp-hz = /bits/ 64 <300000000>;
>> + opp-microvolt = <950000 931000 969000>;
>> + opp-supported-hw = <0x06 0x0010>;
>> + opp-suspend;
>> + };
>> +
>> + opp100@275000000 {
>> + opp-hz = /bits/ 64 <275000000>;
>> + opp-microvolt = <1100000 1078000 1122000>;
>> + opp-supported-hw = <0x01 0x00FF>;
>> + opp-suspend;
>> + };
>> +
>> + opp100@300000000 {
>> + opp-hz = /bits/ 64 <300000000>;
>> + opp-microvolt = <1100000 1078000 1122000>;
>> + opp-supported-hw = <0x06 0x0020>;
>> + opp-suspend;
>> + };
>> +
>> + opp100@500000000 {
>> + opp-hz = /bits/ 64 <500000000>;
>> + opp-microvolt = <1100000 1078000 1122000>;
>> + opp-supported-hw = <0x01 0xFFFF>;
>> + };
>> +
>> + opp100@600000000 {
>> + opp-hz = /bits/ 64 <600000000>;
>> + opp-microvolt = <1100000 1078000 1122000>;
>> + opp-supported-hw = <0x06 0x0040>;
>> + };
>> +
>> + opp120@600000000 {
>> + opp-hz = /bits/ 64 <600000000>;
>> + opp-microvolt = <1200000 1176000 1224000>;
>> + opp-supported-hw = <0x01 0xFFFF>;
>> + };
>> +
>> + opp120@720000000 {
>> + opp-hz = /bits/ 64 <720000000>;
>> + opp-microvolt = <1200000 1176000 1224000>;
>> + opp-supported-hw = <0x06 0x0080>;
>> + };
>> +
>> + oppturbo@720000000 {
>> + opp-hz = /bits/ 64 <720000000>;
>> + opp-microvolt = <1260000 1234800 1285200>;
>> + opp-supported-hw = <0x01 0xFFFF>;
>> + };
>> +
>> + oppturbo@800000000 {
>> + opp-hz = /bits/ 64 <800000000>;
>> + opp-microvolt = <1260000 1234800 1285200>;
>> + opp-supported-hw = <0x06 0x0100>;
>> + };
>> +
>> + oppnitro@1000000000 {
>> + opp-hz = /bits/ 64 <1000000000>;
>> + opp-microvolt = <1325000 1298500 1351500>;
>> + opp-supported-hw = <0x04 0x0200>;
>> + };
>> +};
>> --
>> 2.11.0
>>
--
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 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains
From: Dave Gerlach @ 2017-01-19 18:59 UTC (permalink / raw)
To: santosh.shilimkar@oracle.com, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Rob Herring
Cc: linux-arm-kernel, linux-kernel, linux-pm, devicetree,
Nishanth Menon, Keerthy, Russell King, Tero Kristo, Sudeep Holla,
Santosh Shilimkar, Lokesh Vutla
In-Reply-To: <25026532-fe4d-8215-9249-c5c7efcd8242@oracle.com>
Santosh,
On 01/19/2017 11:51 AM, santosh.shilimkar@oracle.com wrote:
> On 1/4/17 2:06 PM, Dave Gerlach wrote:
>> Santosh,
>> On 01/04/2017 03:54 PM, Santosh Shilimkar wrote:
>>> On 1/4/2017 12:55 PM, Dave Gerlach wrote:
>>>> Hi,
>>>> This is v3 of the series to add support for TI-SCI Generic PM Domains.
>>>> Previous versions can be found here:
>>>>
>>>> v2: https://www.spinics.net/lists/kernel/msg2364612.html
>>>> v1: http://www.spinics.net/lists/arm-kernel/msg525204.html
>>>>
>>>> This version is rebased on v4.10-rc2 but is the same as v2 with the
>>>> exception of patch 2 in which the devicetree binding documentation
>>>> needed to be updated to show the k2g_pds node should be a child of
>>>> the pmmc node. Apart from that, the acks provided by Ulf were added
>>>> to patches 1 and 3.
>>>>
>>>> Now that the TI-SCI series has been merged [1] this series will be
>>>> ready
>>>> to go in with an ack on the DT binding. Rob had raised some
>>>> questions on
>>>> the necessity ti,sci-id property but I believe these were properly
>>>> addressed during the discussion of v2 so hopefully an ack is in order
>>>> now.
>>>>
>>> How do you plan to merge this series with below patch ?
>>>
>>>> PM / Domains: Add generic data pointer to genpd data struct
>>> I think this one goes via Rafael's tree. If you want me to merge this
>>> along with other patches then will need his ack.
>>>
>>> Other way is to get that merged first via Rafael's tree and then
>>> the remainder series.
>>
>> I'd be happy with it going in through your tree with an ack to avoid any
>> delay but I'd say it's Rafael's call as it is a patch to the genpd core,
>> even though at this point I am the only user.
>>
> Am going to send pull request over weekend, so if you would like
> me take the series via arm-soc tree, please get Rafaels, ack and
> let me know.
Thanks for letting me know, unfortunately we have not yet reached
alignment on the binding so I do not believe we will be ready for merge
in time.
Regards,
Dave
>
> Regards,
> Santosh
>
>
^ permalink raw reply
* Re: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add support for 2 clocks
From: Wolfram Sang @ 2017-01-19 19:02 UTC (permalink / raw)
To: Chris Brandt
Cc: Ulf Hansson, Rob Herring, Mark Rutland, Simon Horman,
Wolfram Sang, Geert Uytterhoeven, devicetree, linux-mmc,
linux-renesas-soc
In-Reply-To: <20170118172502.13876-2-chris.brandt@renesas.com>
[-- Attachment #1: Type: text/plain, Size: 288 bytes --]
On Wed, Jan 18, 2017 at 12:25:00PM -0500, Chris Brandt wrote:
> Some controllers have 2 clock sources instead of 1, so they both need
> to be turned on/off.
>
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/3] mmc: sh_mobile_sdhi: explain clock bindings
From: Wolfram Sang @ 2017-01-19 19:02 UTC (permalink / raw)
To: Chris Brandt
Cc: Ulf Hansson, Rob Herring, Mark Rutland, Simon Horman,
Wolfram Sang, Geert Uytterhoeven, devicetree, linux-mmc,
linux-renesas-soc
In-Reply-To: <20170118172502.13876-3-chris.brandt@renesas.com>
[-- Attachment #1: Type: text/plain, Size: 376 bytes --]
On Wed, Jan 18, 2017 at 12:25:01PM -0500, Chris Brandt wrote:
> In the case of a single clock source, you don't need names. However,
> if the controller has 2 clock sources, you need to name them correctly
> so the driver can find the 2nd one.
>
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains
From: Santosh Shilimkar @ 2017-01-19 19:04 UTC (permalink / raw)
To: Dave Gerlach, Ulf Hansson, Rafael J . Wysocki, Kevin Hilman,
Rob Herring
Cc: Nishanth Menon, devicetree, linux-pm, Lokesh Vutla, Keerthy,
Santosh Shilimkar, linux-kernel, Tero Kristo, Russell King,
Sudeep Holla, linux-arm-kernel
In-Reply-To: <7e87e4cd-d859-b941-8cb8-118a8b0d2690@ti.com>
On 1/19/2017 10:59 AM, Dave Gerlach wrote:
> Santosh,
> On 01/19/2017 11:51 AM, santosh.shilimkar@oracle.com wrote:
>> On 1/4/17 2:06 PM, Dave Gerlach wrote:
[...]
>> Am going to send pull request over weekend, so if you would like
>> me take the series via arm-soc tree, please get Rafaels, ack and
>> let me know.
>
> Thanks for letting me know, unfortunately we have not yet reached
> alignment on the binding so I do not believe we will be ready for merge
> in time.
>
Thanks for clarification.
Regards,
Santosh
^ permalink raw reply
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