* Re: [PATCH 3/4] dt-bindings: Update domain-idle-state binding to use correct compatibles
From: Sudeep Holla @ 2016-10-26 8:57 UTC (permalink / raw)
To: Kevin Hilman, Lina Iyer
Cc: devicetree, ulf.hansson, lorenzo.pieralisi, Juri.Lelli, linux-pm,
sboyd, linux-arm-msm, rjw, brendan.jackman, Sudeep Holla,
andy.gross, linux-arm-kernel
In-Reply-To: <7hh980taqp.fsf@baylibre.com>
On 25/10/16 21:49, Kevin Hilman wrote:
> Lina Iyer <lina.iyer@linaro.org> writes:
>
>> Update domain-idle-state binding to use "domain-idle-state" compatible
>> from Documentation/devicetree/bindings/arm/idle-states.txt.
>>
>> Cc: <devicetree@vger.kernel.org>
>> Cc: Rob Herring <robh@kernel.org>
>> Suggested-by: Sudeep Holla <sudeep.holla@arm.com>
>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> ---
>> Documentation/devicetree/bindings/power/power_domain.txt | 9 +++++----
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> With no current users for this, I don't see the point of adding a
> compatible now.
>
> IMO, this should wait and be added with the identified user we can
> discuss it then.
>
No, IMO it needs to be used for the proposed SoC idle/genpd solution.
I understand the nodes that are "arm,idle-state" compatible can be used
for this new SoC hierarchical idle management, but it was never defined
for that use originally. So this new feature must be advertised by the
firmware with the presence of "domain-idle-state".
Yes we might have other ways to detect that but I have already seen that
broken on the reference platform, so we need alternate/DT way to specify
that.
Not all existing "arm,idle-state" compatible nodes will be capable of
supporting this new SoC idle feature. It's just better and safer for a
new feature getting added that relies on DT to have a new compatible.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH] ARM: sti: stih410-clocks: Add PROC_STFE as a critical clock
From: Peter Griffin @ 2016-10-26 8:56 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, kernel, patrice.chotard,
devicetree
In-Reply-To: <20161026085141.GJ8574@dell>
Hi Lee,
On Wed, 26 Oct 2016, Lee Jones wrote:
> > > > If the clock is enabled when Linux boots, the Linux clock framework *needs*
> > > > to assume the hardware may have been used in previous boot stages, and it should
> > > > not attempt to disable the clock.
> > >
> > > None of the boot loaders we use do this.
> >
> > But the Linux kernel isn't just used by us. It is not uncommon for STB
> > bootloaders to get information from the frontend as part of the boot process.
>
> Okay, this is the clincher. Since we need to support non-standard
> bootloaders, it's difficult to guarantee that the clock will be
> disabled at boot. For this reason, I believe that we can call this a
> critical clock.
>
That's good news as the STi maintainer already acked and applied the patch.
Peter.
^ permalink raw reply
* Re: [PATCH/RFT v2 02/17] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.
From: Sekhar Nori @ 2016-10-26 8:56 UTC (permalink / raw)
To: David Lechner, Axel Haslam
Cc: devicetree, Sergei Shtylyov, Greg KH, manjunath.goudar, linux-usb,
Johan Hovold, linux-kernel, robh+dt, Alan Stern, Mark Brown,
Kevin Hilman, linux-arm-kernel, Alexandre Bailon
In-Reply-To: <c3af8517-c452-ae8c-6840-dd8a684e4ab2@lechnology.com>
On Tuesday 25 October 2016 09:23 PM, David Lechner wrote:
> Hi Sekhar,
>
> On 10/25/2016 05:17 AM, Sekhar Nori wrote:
>> On Tuesday 25 October 2016 03:07 PM, Axel Haslam wrote:
>>> Hi Sekar,
>>>
>>> On Tue, Oct 25, 2016 at 10:10 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>> On Monday 24 October 2016 10:16 PM, ahaslam@baylibre.com wrote:
>>>>> From: David Lechner <david@lechnology.com>
>>>>>
>>>>> The CFGCHIP registers are used by a number of devices, so using a
>>>>> syscon
>>>>> device to share them. The first consumer of this will by the
>>>>> phy-da8xx-usb
>>>>> driver.
>>>>>
>>>>> Signed-off-by: David Lechner <david@lechnology.com>
>>>>> [Axel: minor fix: change id to -1]
>>>>
>>>> Can you please clarify this change? There could be other syscon devices
>>>> on the chip for other common registers. Why use the singular device-id?
>>>>
>>>
>>> in the case of non DT boot, the phy driver is looking for "syscon" :
>>>
>>> d_phy->regmap = syscon_regmap_lookup_by_pdevname("syscon");
>>>
>>> if we register the syscon driver with id = 0, the actual name of the
>>> syscon
>>> device will be "syscon.0" and the phy driver will fail to probe, because
>>> the strncmp match in the syscon driver (syscon_match_pdevname)
>>> will fail.
>>>
>>> should i change the phy driver instead?
>>
>> Yes, please. Forcing only one syscon region for the whole chip will be
>> too restrictive, I am pretty sure.
>>
>> Thanks,
>> Sekhar
>>
>
> In the previous review, you requested that this be changed to -1 [1].
>
> If we change it back to 0, it will also require reverting a patch to the
> phy driver that has already been merged[2].
Sigh. Sorry about going around in circles on this one. Lets go with what
you have. If and when there is a need for another syscon node, the
driver and platform code can be updated. At least we will know why the
change is being done at that time.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH RESEND 1/2] dt: bindings: add allwinner,otg-routed property for phy-sun4i-usb
From: Icenowy Zheng @ 2016-10-26 8:52 UTC (permalink / raw)
To: Hans de Goede, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Kishon Vijay Abraham I
Cc: Mark Rutland, Reinder de Haan,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
In-Reply-To: <55fe59fc-6e93-d519-2d7c-264c48820fc4-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
26.10.2016, 16:28, "Hans de Goede" <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>:
> Hi,
>
> On 25-10-16 06:11, Icenowy Zheng wrote:
>> On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
>> the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
>> (which is a Host-only controller, but more stable and easy to implement).
>>
>> This property marks whether on a certain board which controller should be
>> attached to the PHY.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>
> Icenowy, I appreciate your work on this, but we really need full otg
> support with dynamic switching rather then hardwiring the routing, so
> this cannot go in as is.
Now I have both PHY0 controllers' drivers.
In the tree of https://github.com/Icenowy/linux/tree/ice-a64-v6.1 , I have already
enabled MUSB controller.
And this patchset is for those prefer a stable USB host implement to dual-role
implementation. MUSB is a good UDC, but not a good host controller. My USB
sound card cannot work on MUSB on A33. Even connecting a R8's MUSB (Serial
Gadget) to an A33's MUSB cannot work.
See the IRC log between Andre and me,
https://irclog.whitequark.org/linux-sunxi/2016-10-24#18012695; .
>
> NACK.
>
> Regards,
>
> Hans
>
>> ---
>> Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> index 287150d..a63c766 100644
>> --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> @@ -36,6 +36,12 @@ Optional properties:
>> - usb1_vbus-supply : regulator phandle for controller usb1 vbus
>> - usb2_vbus-supply : regulator phandle for controller usb2 vbus
>>
>> +Optional properties for H3 or A64 SoCs:
>> +- allwinner,otg-routed : USB0 (OTG) PHY is routed to OHCI/EHCI pair rather than
>> + MUSB. (boolean, if this property is set, the OHCI/EHCI
>> + controllers at PHY0 should be enabled and the MUSB
>> + controller must *NOT* be enabled)
>> +
>> Example:
>> usbphy: phy@0x01c13400 {
>> #phy-cells = <1>;
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH] ARM: sti: stih410-clocks: Add PROC_STFE as a critical clock
From: Lee Jones @ 2016-10-26 8:51 UTC (permalink / raw)
To: Peter Griffin
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-F5mvAk5X5gdBDgjK7y7TUQ, patrice.chotard-qxv4g6HH51o,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161025134940.GA3993@griffinp-ThinkPad-X1-Carbon-2nd>
> > > If the clock is enabled when Linux boots, the Linux clock framework *needs*
> > > to assume the hardware may have been used in previous boot stages, and it should
> > > not attempt to disable the clock.
> >
> > None of the boot loaders we use do this.
>
> But the Linux kernel isn't just used by us. It is not uncommon for STB
> bootloaders to get information from the frontend as part of the boot process.
Okay, this is the clincher. Since we need to support non-standard
bootloaders, it's difficult to guarantee that the clock will be
disabled at boot. For this reason, I believe that we can call this a
critical clock.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 RESEND 1/2] dt: bindings: add allwinner,otg-routed property for phy-sun4i-usb
From: Hans de Goede @ 2016-10-26 8:28 UTC (permalink / raw)
To: icenowy-ymACFijhrKM, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Kishon Vijay Abraham I
Cc: Mark Rutland, Reinder de Haan, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161025041139.46454-1-icenowy-ymACFijhrKM@public.gmane.org>
Hi,
On 25-10-16 06:11, Icenowy Zheng wrote:
> On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
> the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
> (which is a Host-only controller, but more stable and easy to implement).
>
> This property marks whether on a certain board which controller should be
> attached to the PHY.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
Icenowy, I appreciate your work on this, but we really need full otg
support with dynamic switching rather then hardwiring the routing, so
this cannot go in as is.
NACK.
Regards,
Hans
> ---
> Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> index 287150d..a63c766 100644
> --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> @@ -36,6 +36,12 @@ Optional properties:
> - usb1_vbus-supply : regulator phandle for controller usb1 vbus
> - usb2_vbus-supply : regulator phandle for controller usb2 vbus
>
> +Optional properties for H3 or A64 SoCs:
> +- allwinner,otg-routed : USB0 (OTG) PHY is routed to OHCI/EHCI pair rather than
> + MUSB. (boolean, if this property is set, the OHCI/EHCI
> + controllers at PHY0 should be enabled and the MUSB
> + controller must *NOT* be enabled)
> +
> Example:
> usbphy: phy@0x01c13400 {
> #phy-cells = <1>;
>
^ permalink raw reply
* Re: [PATCH resent v3 2/3] dts: omap5: board-common: enable twl6040 headset jack detection
From: Peter Ujfalusi @ 2016-10-26 8:02 UTC (permalink / raw)
To: H. Nikolaus Schaller, Benoît Cousson, Tony Lindgren,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Russell King
Cc: devicetree, letux-kernel, linux-kernel, ldewangan, kernel, marek,
linux-omap
In-Reply-To: <b918b86fd1d1f7e6fb2c15bb507b84d5cf1f0d3e.1477417090.git.hns@goldelico.com>
On 10/25/16 20:38, H. Nikolaus Schaller wrote:
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
I'm not sure if this is valid for igep0500 as I have not seen the schematics.
It might be safer to enable the jack detection only for omap5-uevm?
In any case:
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
> arch/arm/boot/dts/omap5-board-common.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi
> index b04adee..ab60a8e 100644
> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
> @@ -124,6 +124,7 @@
> compatible = "ti,abe-twl6040";
> ti,model = "omap5-uevm";
>
> + ti,jack-detection;
> ti,mclk-freq = <19200000>;
>
> ti,mcpdm = <&mcpdm>;
>
--
Péter
^ permalink raw reply
* Re: [PATCH v6 1/5] ARM: davinci: da8xx: add usb phy clocks
From: Sekhar Nori @ 2016-10-26 7:59 UTC (permalink / raw)
To: David Lechner, Kevin Hilman, Rob Herring, Mark Rutland
Cc: Axel Haslam, Sergei Shtylyov, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1477451211-31979-2-git-send-email-david@lechnology.com>
On Wednesday 26 October 2016 08:36 AM, David Lechner wrote:
> Up to this point, the USB phy clock configuration was handled manually in
> the board files and in the usb drivers. This adds proper clocks so that
> the usb drivers can use clk_get and clk_enable and not have to worry about
> the details. Also, the related code is removed from the board files and
> replaced with the new clock registration functions.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
>
> I have added "ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable"
> from Axel Haslam to this patch.
>
> In the review of Axel's patch, Sekhar said:
>
>> We should not be using a NULL device pointer here. Can you pass the musb
>> device pointer available in the same file? Also, da850_clks[] in da850.c
>> needs to be fixed to add the matching device name.
>
> However, the musb device may not be registered. The usb20_clk can be used to
> supply a 48MHz clock to USB 1.1 (ohci) without using the musb device. So, I am
> inclined to leave this as NULL.
But clock look-up has nothing to do with device being registered AFAICT.
It is used to identify the clock consumer. Passing NULL there means the
clock is not associated with any device. Which is not correct as we are
specifically looking at MUSB module clock.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH resent v3 3/3] ASoC: omap-abe-twl6040: fix typo in bindings documentation
From: Peter Ujfalusi @ 2016-10-26 7:59 UTC (permalink / raw)
To: H. Nikolaus Schaller, Benoît Cousson, Tony Lindgren,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Russell King
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
letux-kernel-S0jZdbWzriLCfDggNXIi3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ldewangan-DDmLM1+adcrQT0dZR+AlfA,
kernel-Jl6IXVxNIMRxAtABVqVhTwC/G2K4zDHf,
marek-xXXSsgcRVICgSpxsJD1C4w, linux-omap-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <f2ade237f55685f4fdb2aaa127995f3ccb986bb3.1477417090.git.hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
On 10/25/16 20:38, H. Nikolaus Schaller wrote:
> Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
Acked-by: Peter Ujfalusi <perter.ujfalusi-l0cyMroinI0@public.gmane.org>
> ---
> Documentation/devicetree/bindings/sound/omap-abe-twl6040.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/omap-abe-twl6040.txt b/Documentation/devicetree/bindings/sound/omap-abe-twl6040.txt
> index fd40c85..462b04e8 100644
> --- a/Documentation/devicetree/bindings/sound/omap-abe-twl6040.txt
> +++ b/Documentation/devicetree/bindings/sound/omap-abe-twl6040.txt
> @@ -12,7 +12,7 @@ Required properties:
>
> Optional properties:
> - ti,dmic: phandle for the OMAP dmic node if the machine have it connected
> -- ti,jack_detection: Need to be present if the board capable to detect jack
> +- ti,jack-detection: Need to be present if the board capable to detect jack
> insertion, removal.
>
> Available audio endpoints for the audio-routing table:
>
--
Péter
--
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 3/3] ARM: dts: socfpga: Enable QSPI on the Cyclone5 sockit
From: Steffen Trumtrar @ 2016-10-26 7:22 UTC (permalink / raw)
To: Graham Moore
Cc: Dinh Nguyen, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dinguyen-DgEjT+Ai2ygdnm+yROfE0A,
dinh.linux-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5e0adad1-8ef2-029f-cfcd-4a07c962fda2-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
Hi!
On Tue, Oct 25, 2016 at 10:38:10AM -0500, Graham Moore wrote:
> On 10/20/2016 09:12 AM, Dinh Nguyen wrote:
> >
> >
> > On 10/20/2016 02:19 AM, Steffen Trumtrar wrote:
> >
> > > > + cdns,tslch-ns = <4>;
> > > > +
> > > > + partition@qspi-boot {
> > > > + /* 8MB for raw data. */
> > > > + label = "Flash 0 Raw Data";
> > > > + reg = <0x0 0x800000>;
> > > > + };
> > > > +
> > > > + partition@qspi-rootfs {
> > > > + /* 120MB for jffs2 data. */
> > > > + label = "Flash 0 jffs2 Filesystem";
> > > > + reg = <0x800000 0x7800000>;
> > > > + };
> > > > + };
> > > > +};
> > > > +
> > >
> > > What is the current preferred way of handling the partitions?
> > > This doesn't fit my Sockit configuration for example. So I would always
> > > have to patch the devicetree.
> >
> > I'm not 100% sure on this. Graham, do you have any insight?
> > >
>
> Well, strictly speaking, these partitions are only for the socdk, the Altera
> dev kit. Our sample designs and file systems expect this layout.
The thing is, that I don't think these partitions belong in a mainline
dts at all. But I'm not sure what the current policy is.
>
> Therefore, these partitions are not required for any other dev kits, and can
> probably be left out.
>
> Or, Steffen, if you have a standard layout you'd like to see, then put that
> in there.
>
Well in my case, it actually doesn't really matter. All the boards
I use do not have u-boot as bootloader but barebox. And barebox uses
devicetree fixups for adding the partition layout that fits the
particular use case. All other partitions are thrown out.
I don't know if u-boot does something like this.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
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/6] dt/bindings: adjust bindings for Layerscape SCFG MSI
From: M.H. Lian @ 2016-10-26 6:55 UTC (permalink / raw)
To: Robin Murphy, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Cc: Marc Zyngier, Stuart Yoder, Scott Wood, Leo Li, Shawn Guo,
Mingkai Hu
In-Reply-To: <0416d929-dfef-da09-8d9a-d1db8575afef@arm.com>
Hi Robin,
Please see my comments inline.
Thanks,
Minghuan
> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy@arm.com]
> Sent: Tuesday, October 25, 2016 9:01 PM
> To: M.H. Lian <minghuan.lian@nxp.com>; linux-arm-
> kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicetree@vger.kernel.org
> Cc: Marc Zyngier <marc.zyngier@arm.com>; Stuart Yoder
> <stuart.yoder@nxp.com>; Leo Li <leoyang.li@nxp.com>; Scott Wood
> <scott.wood@nxp.com>; Shawn Guo <shawnguo@kernel.org>; Mingkai Hu
> <mingkai.hu@nxp.com>
> Subject: Re: [PATCH 1/6] dt/bindings: adjust bindings for Layerscape SCFG
> MSI
>
> On 25/10/16 13:35, Minghuan Lian wrote:
> > 1. The different version of a SoC may have different MSI
> > implementation. But compatible "fsl,<soc-name>-msi" can not describe
> > the SoC version.
>
> Can't it?
>
> compatible = "fsl-ls1043a-rev11-msi";
>
> Oh, I guess it can!
>
> Joking aside, if there are multiple versions of a piece of hardware which
> require *different* treatment by drivers, then it is obviously wrong to use
> the same compatible string because *they are not compatible*.
>
[Minghuan Lian] Yes, but Rev1.0 and Rev1.1 SoC will use the same dts files.
We cannot create different dts files for each revision of the same kind of SoC.
It means that there are different variants in the different versions of the same SoC that will use the same compatible string.
So I have to use SoC match interface to get the versions.
I'm too radical. I do not want to first check SoC family via compatible string and then check revision via SoC match or SVR.
I selected the "SoC match" like the following to get the related information at only one place.
static struct soc_device_attribute soc_msi_matches[] = {
{ .family = "QorIQ LS1021A",
.data = &ls1021_msi_cfg },
{ .family = "QorIQ LS1012A",
.data = &ls1021_msi_cfg },
{ .family = "QorIQ LS1043A", .revision = "1.0",
.data = &ls1021_msi_cfg },
{ .family = "QorIQ LS1043A", .revision = "1.1",
.data = &ls1043_rev11_msi_cfg },
{ .family = "QorIQ LS1046A",
.data = &ls1046_msi_cfg },
{ },
};
I will remain the SoC related compatible and try to describe the difference via some kind of the property.
> > The MSI driver will use SoC match interface to get SoC type and
> > version instead of compatible string. So all MSI node can use the
> > common compatible "fsl,ls-scfg-msi" and the original compatible is
> > unnecessary.
>
> If there is some common level of functionality that *all* variants support
> without the driver having to know which one is which, then there might be
> some sense in having an additional common compatible to represent that
> level of functionality, e.g.
>
> compatible = "fsl-ls1043a-rev11-msi", "fsl,ls-scfg-msi";
>
> But if, say, new variants turn out to have less functionality, rather than more,
> then there's probably not much point, and we should stick to specific,
> accurate, compatible strings.
>
> DT is not specific to a kernel version, nor even to Linux. A string which triggers
> some board-specific magic in a specific version of a Linux driver does not
> describe the hardware.
>
> Robin.
>
> > 2. Layerscape SoCs may have one or several MSI controllers.
> > In order to increase MSI interrupt number of a PCIe, the patch moves
> > all MSI node into the parent node "msi-controller". So a PCIe can
> > request MSI from all the MSI controllers.
> >
> > Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
> > ---
> > .../interrupt-controller/fsl,ls-scfg-msi.txt | 57 +++++++++++++++++++--
> -
> > 1 file changed, 49 insertions(+), 8 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > index 9e38949..29f95fd 100644
> > ---
> > a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-sc
> > +++ fg-msi.txt
> > @@ -1,18 +1,28 @@
> > * Freescale Layerscape SCFG PCIe MSI controller
> >
> > +Layerscape SoCs may have one or multiple MSI controllers.
> > +Each MSI controller must be showed as a child node.
> > +
> > Required properties:
> >
> > -- compatible: should be "fsl,<soc-name>-msi" to identify
> > - Layerscape PCIe MSI controller block such as:
> > - "fsl,1s1021a-msi"
> > - "fsl,1s1043a-msi"
> > +- compatible: should be "fsl,ls-scfg-msi"
> > +- #address-cells: must be 2
> > +- #size-cells: must be 2
> > +- ranges: allows valid 1:1 translation between child's address space and
> > + parent's address space
> > - msi-controller: indicates that this is a PCIe MSI controller node
> > +
> > +Required child node:
> > +A child node must exist to represent the MSI controller.
> > +The following are properties specific to those nodes:
> > +
> > - reg: physical base address of the controller and length of memory
> mapped.
> > - interrupts: an interrupt to the parent interrupt controller.
> >
> > Optional properties:
> > - interrupt-parent: the phandle to the parent interrupt controller.
> >
> > +Notes:
> > This interrupt controller hardware is a second level interrupt
> > controller that is hooked to a parent interrupt controller: e.g: ARM
> > GIC for ARM-based platforms. If interrupt-parent is not provided, the
> > default parent interrupt @@ -22,9 +32,40 @@ MSI controller node
> >
> > Examples:
> >
> > - msi1: msi-controller@1571000 {
> > - compatible = "fsl,1s1043a-msi";
> > - reg = <0x0 0x1571000 0x0 0x8>,
> > + msi: msi-controller {
> > + compatible = "fsl,ls-scfg-msi";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > msi-controller;
> > - interrupts = <0 116 0x4>;
> > +
> > + msi0@1580000 {
> > + reg = <0x0 0x1580000 0x0 0x10000>;
> > + interrupts = <0 116 0x4>,
> > + <0 111 0x4>,
> > + <0 112 0x4>,
> > + <0 113 0x4>;
> > + };
> > +
> > + msi1@1590000 {
> > + reg = <0x0 0x1590000 0x0 0x10000>;
> > + interrupts = <0 126 0x4>,
> > + <0 121 0x4>,
> > + <0 122 0x4>,
> > + <0 123 0x4>;
> > + };
> > +
> > + msi2@15a0000 {
> > + reg = <0x0 0x15a0000 0x0 0x10000>;
> > + interrupts = <0 160 0x4>,
> > + <0 155 0x4>,
> > + <0 156 0x4>,
> > + <0 157 0x4>;
> > + };
> > + };
> > +
> > + pcie@3400000 {
> > + ...
> > + msi-parent = <&msi>;
> > + ...
> > };
> >
^ permalink raw reply
* Re: [PATCH v2] drm/mediatek: fixed the calc method of data rate per lane
From: CK Hu @ 2016-10-26 6:41 UTC (permalink / raw)
To: Jitao Shi
Cc: Mark Rutland, stonea168, dri-devel, Andy Yan, Ajay Kumar,
Vincent Palatin, cawa.cheng, Russell King, devicetree, Pawel Moll,
Ian Campbell, Rob Herring, linux-mediatek, yingjoe.chen,
Matthias Brugger, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Kumar Gala
In-Reply-To: <1477374045-2837-1-git-send-email-jitao.shi@mediatek.com>
Hi, Jitao:
On Tue, 2016-10-25 at 13:40 +0800, Jitao Shi wrote:
> Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
> Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
> signal will cause h-time larger than normal and reduce FPS.
> Need to multiply a coefficient to offset the extra signal's effect.
> coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
> Ths_exit)/(htotal*bpp/lane_number))
>
> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
> ---
> Change since v1:
> - phy_timing2 and phy_timing3 refer clock cycle time.
> - define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 103 +++++++++++++++++++++++-------------
> 1 file changed, 67 insertions(+), 36 deletions(-)
>
[snip...]
>
> -static void dsi_phy_timconfig(struct mtk_dsi *dsi)
> +static void dsi_phy_timconfig(struct mtk_dsi *dsi, u32 phy_timing0,
> + u32 phy_timing1, u32 phy_timing2,
> + u32 phy_timing3)
> {
> - u32 timcon0, timcon1, timcon2, timcon3;
> - unsigned int ui, cycle_time;
> - unsigned int lpx;
> -
> - ui = 1000 / dsi->data_rate + 0x01;
> - cycle_time = 8000 / dsi->data_rate + 0x01;
> - lpx = 5;
> -
> - timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
> - timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
> - (4 * lpx);
> - timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> - (NS_TO_CYCLE(0x150, cycle_time) << 16);
> - timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> - NS_TO_CYCLE(0x40, cycle_time);
> -
> - writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
> - writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
> - writel(timcon2, dsi->regs + DSI_PHY_TIMECON2);
> - writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
Why do you move these calculation to mtk_dsi_poweron()? You can keep
calculation here and just do some modification.
Regards,
CK
> + writel(phy_timing0, dsi->regs + DSI_PHY_TIMECON0);
> + writel(phy_timing1, dsi->regs + DSI_PHY_TIMECON1);
> + writel(phy_timing2, dsi->regs + DSI_PHY_TIMECON2);
> + writel(phy_timing3, dsi->regs + DSI_PHY_TIMECON3);
> }
>
> static void mtk_dsi_enable(struct mtk_dsi *dsi)
> @@ -202,19 +188,51 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> {
> struct device *dev = dsi->dev;
> int ret;
> + u64 bit_clock, total_bits;
> + u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
> + u32 phy_timing0, phy_timing1, phy_timing2, phy_timing3;
> + u32 ui, cycle_time;
>
> if (++dsi->refcount != 1)
> return 0;
>
> + switch (dsi->format) {
> + case MIPI_DSI_FMT_RGB565:
> + bit_per_pixel = 16;
> + break;
> + case MIPI_DSI_FMT_RGB666_PACKED:
> + bit_per_pixel = 18;
> + break;
> + case MIPI_DSI_FMT_RGB666:
> + case MIPI_DSI_FMT_RGB888:
> + default:
> + bit_per_pixel = 24;
> + break;
> + }
> + /**
> + * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
> + * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
> + * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
> + * + Thstrail + Ths_exit + Ths_zero) /
> + * (htotal * byte_per_pixel /lane_number)
> + */
> + bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
> + htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
> + dsi->vm.hsync_len;
> + htotal_bits = htotal * bit_per_pixel;
> +
> /**
> - * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
> - * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
> - * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
> - * we set mipi_ratio is 1.05.
> + * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
> */
> - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> + overhead_cycles = LPX + (HS_PRPR >> 8) + (HS_ZERO >> 16) +
> + (HS_TRAIL >> 24) + (DA_HS_EXIT >> 24);
> + overhead_bits = overhead_cycles * dsi->lanes * 8;
> + total_bits = htotal_bits + overhead_bits;
>
> - ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
> + dsi->data_rate = DIV_ROUND_UP_ULL(bit_clock * total_bits,
> + htotal_bits * dsi->lanes);
> +
> + ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
> if (ret < 0) {
> dev_err(dev, "Failed to set data rate: %d\n", ret);
> goto err_refcount;
> @@ -236,7 +254,20 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>
> mtk_dsi_enable(dsi);
> mtk_dsi_reset(dsi);
> - dsi_phy_timconfig(dsi);
> +
> + ui = 1000 / dsi->data_rate + 0x01;
> + cycle_time = 8000 / dsi->data_rate + 0x01;
> +
> + phy_timing0 = LPX | HS_PRPR | HS_ZERO | HS_TRAIL;
> + phy_timing1 = TA_GO | TA_SURE | TA_GET | DA_HS_EXIT;
> + phy_timing2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> + (NS_TO_CYCLE(0x150, cycle_time) << 16);
> + phy_timing3 = (2 * LPX) << 16 |
> + NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> + NS_TO_CYCLE(0x40, cycle_time);
> +
> + dsi_phy_timconfig(dsi, phy_timing0, phy_timing1, phy_timing2,
> + phy_timing3);
>
> return 0;
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH V3 1/9] PM / OPP: Reword binding supporting multiple regulators per device
From: Viresh Kumar @ 2016-10-26 6:32 UTC (permalink / raw)
To: Rafael Wysocki, nm, sboyd, Viresh Kumar
Cc: linaro-kernel, linux-pm, linux-kernel, Vincent Guittot, robh,
d-gerlach, broonie, Viresh Kumar, devicetree
In-Reply-To: <cover.1477463128.git.viresh.kumar@linaro.org>
On certain platforms (like TI), DVFS for a single device (CPU) requires
configuring multiple power supplies.
The OPP bindings already contains binding and example to explain this
case, but it isn't sufficient. For example, there is no way for the code
parsing these bindings to know which voltage values belong to which
power supply. Also its not possible to know the order in which the
supplies need to be configured while switching OPPs.
This patch tries to clarify on those details and does some minor changes
as well.
Note that the bindings do not specify the order in which the regulators
need to be programmed and the order in which the entries are added for
the supplies.
The user of the bindings (like the kernel) shall know these details
already and the DT is responsible to supply only the readings for the
regulators.
Cc: Mark Brown <broonie@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
---
Documentation/devicetree/bindings/opp/opp.txt | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index ee91cbdd95ee..af476df510f1 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -86,8 +86,13 @@ properties.
Single entry is for target voltage and three entries are for <target min max>
voltages.
- Entries for multiple regulators must be present in the same order as
- regulators are specified in device's DT node.
+ Entries for multiple regulators shall be provided in the same field separated
+ by angular brackets <>. The OPP binding doesn't provide any provisions to
+ relate the values to their power supplies or the order in which the supplies
+ need to be configured.
+
+ Entries for all regulators shall be of the same size, i.e. either all use a
+ single value or triplets.
- opp-microvolt-<name>: Named opp-microvolt property. This is exactly similar to
the above opp-microvolt property, but allows multiple voltage ranges to be
@@ -104,10 +109,12 @@ properties.
Should only be set if opp-microvolt is set for the OPP.
- Entries for multiple regulators must be present in the same order as
- regulators are specified in device's DT node. If this property isn't required
- for few regulators, then this should be marked as zero for them. If it isn't
- required for any regulator, then this property need not be present.
+ Entries for multiple regulators shall be provided in the same field separated
+ by angular brackets <>. If current values aren't required for a regulator,
+ then it shall be filled with 0. If current values aren't required for any of
+ the regulators, then this field is not required. The OPP binding doesn't
+ provide any provisions to relate the values to their power supplies or the
+ order in which the supplies need to be configured.
- opp-microamp-<name>: Named opp-microamp property. Similar to
opp-microvolt-<name> property, but for microamp instead.
@@ -386,10 +393,12 @@ Example 4: Handling multiple regulators
/ {
cpus {
cpu@0 {
- compatible = "arm,cortex-a7";
+ compatible = "vendor,cpu-type";
...
- cpu-supply = <&cpu_supply0>, <&cpu_supply1>, <&cpu_supply2>;
+ vcc0-supply = <&cpu_supply0>;
+ vcc1-supply = <&cpu_supply1>;
+ vcc2-supply = <&cpu_supply2>;
operating-points-v2 = <&cpu0_opp_table>;
};
};
--
2.7.1.410.g6faf27b
^ permalink raw reply related
* [PATCH v6 5/5] ARM: DTS: da850: Add usb phy node
From: David Lechner @ 2016-10-26 3:06 UTC (permalink / raw)
To: Sekhar Nori, Kevin Hilman, Rob Herring, Mark Rutland
Cc: David Lechner, Axel Haslam, Sergei Shtylyov, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1477451211-31979-1-git-send-email-david@lechnology.com>
Add a node for the new usb phy driver.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/da850.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 6bbf20d..33fcdce 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -376,6 +376,11 @@
>;
status = "disabled";
};
+ usb_phy: usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <1>;
+ status = "disabled";
+ };
gpio: gpio@226000 {
compatible = "ti,dm6441-gpio";
gpio-controller;
--
2.7.4
^ permalink raw reply related
* [PATCH v6 4/5] ARM: DTS: da850: Add cfgchip syscon node
From: David Lechner @ 2016-10-26 3:06 UTC (permalink / raw)
To: Sekhar Nori, Kevin Hilman, Rob Herring, Mark Rutland
Cc: devicetree, David Lechner, Sergei Shtylyov, linux-kernel,
Axel Haslam, linux-arm-kernel
In-Reply-To: <1477451211-31979-1-git-send-email-david@lechnology.com>
Add a syscon node for the SoC CFGCHIPn registers. This is needed for
the new usb phy driver.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/da850.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b9..6bbf20d 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -188,6 +188,10 @@
};
};
+ cfgchip: cfgchip@1417c {
+ compatible = "ti,da830-cfgchip", "syscon";
+ reg = <0x1417c 0x14>;
+ };
edma0: edma@0 {
compatible = "ti,edma3-tpcc";
/* eDMA3 CC0: 0x01c0 0000 - 0x01c0 7fff */
--
2.7.4
^ permalink raw reply related
* [PATCH v6 3/5] ARM: davinci: da8xx: Add USB PHY platform declaration
From: David Lechner @ 2016-10-26 3:06 UTC (permalink / raw)
To: Sekhar Nori, Kevin Hilman, Rob Herring, Mark Rutland
Cc: David Lechner, Axel Haslam, Sergei Shtylyov, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1477451211-31979-1-git-send-email-david@lechnology.com>
There is now a proper phy driver for the DA8xx SoC USB PHY. This adds the
platform device declarations needed to use it.
Signed-off-by: David Lechner <david@lechnology.com>
---
da8xx-usb-phy device id is changed to -1 since there is only one da8xx-usb-phy
device.
arch/arm/mach-davinci/board-da830-evm.c | 28 +++++-----------------------
arch/arm/mach-davinci/board-omapl138-hawk.c | 5 +++++
arch/arm/mach-davinci/include/mach/da8xx.h | 1 +
arch/arm/mach-davinci/usb-da8xx.c | 11 +++++++++++
4 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 3051cb6..c62766e 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -26,7 +26,6 @@
#include <linux/platform_data/mtd-davinci.h>
#include <linux/platform_data/mtd-davinci-aemif.h>
#include <linux/platform_data/spi-davinci.h>
-#include <linux/platform_data/usb-davinci.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -106,30 +105,8 @@ static irqreturn_t da830_evm_usb_ocic_irq(int irq, void *dev_id)
static __init void da830_evm_usb_init(void)
{
- u32 cfgchip2;
int ret;
- /*
- * Set up USB clock/mode in the CFGCHIP2 register.
- * FYI: CFGCHIP2 is 0x0000ef00 initially.
- */
- cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
-
- /*
- * We have to override VBUS/ID signals when MUSB is configured into the
- * host-only mode -- ID pin will float if no cable is connected, so the
- * controller won't be able to drive VBUS thinking that it's a B-device.
- * Otherwise, we want to use the OTG mode and enable VBUS comparators.
- */
- cfgchip2 &= ~CFGCHIP2_OTGMODE;
-#ifdef CONFIG_USB_MUSB_HOST
- cfgchip2 |= CFGCHIP2_FORCE_HOST;
-#else
- cfgchip2 |= CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN;
-#endif
-
- __raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
-
/* USB_REFCLKIN is not used. */
ret = da8xx_register_usb20_phy_clk(false);
if (ret)
@@ -141,6 +118,11 @@ static __init void da830_evm_usb_init(void)
pr_warn("%s: USB 1.1 PHY CLK registration failed: %d\n",
__func__, ret);
+ ret = da8xx_register_usb_phy();
+ if (ret)
+ pr_warn("%s: USB PHY registration failed: %d\n",
+ __func__, ret);
+
ret = davinci_cfg_reg(DA830_USB0_DRVVBUS);
if (ret)
pr_warn("%s: USB 2.0 PinMux setup failed: %d\n", __func__, ret);
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index 8691a25..c5cb8d9 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -260,6 +260,11 @@ static __init void omapl138_hawk_usb_init(void)
pr_warn("%s: USB 1.1 PHY CLK registration failed: %d\n",
__func__, ret);
+ ret = da8xx_register_usb_phy();
+ if (ret)
+ pr_warn("%s: USB PHY registration failed: %d\n",
+ __func__, ret);
+
ret = gpio_request_one(DA850_USB1_VBUS_PIN,
GPIOF_DIR_OUT, "USB1 VBUS");
if (ret < 0) {
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index c32444b..38d932e 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -92,6 +92,7 @@ int da8xx_register_watchdog(void);
int da8xx_register_usb_refclkin(int rate);
int da8xx_register_usb20_phy_clk(bool use_usb_refclkin);
int da8xx_register_usb11_phy_clk(bool use_usb_refclkin);
+int da8xx_register_usb_phy(void);
int da8xx_register_usb20(unsigned mA, unsigned potpgt);
int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
int da8xx_register_emac(void);
diff --git a/arch/arm/mach-davinci/usb-da8xx.c b/arch/arm/mach-davinci/usb-da8xx.c
index 71a6d85..9c30bff 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -7,6 +7,7 @@
#include <linux/platform_data/usb-davinci.h>
#include <linux/platform_device.h>
#include <linux/mfd/da8xx-cfgchip.h>
+#include <linux/phy/phy.h>
#include <linux/usb/musb.h>
#include <mach/clock.h>
@@ -243,6 +244,16 @@ int __init da8xx_register_usb11_phy_clk(bool use_usb_refclkin)
return ret;
}
+static struct platform_device da8xx_usb_phy = {
+ .name = "da8xx-usb-phy",
+ .id = -1,
+};
+
+int __init da8xx_register_usb_phy(void)
+{
+ return platform_device_register(&da8xx_usb_phy);
+}
+
#if IS_ENABLED(CONFIG_USB_MUSB_HDRC)
static struct musb_hdrc_config musb_config = {
--
2.7.4
^ permalink raw reply related
* [PATCH v6 2/5] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.
From: David Lechner @ 2016-10-26 3:06 UTC (permalink / raw)
To: Sekhar Nori, Kevin Hilman, Rob Herring, Mark Rutland
Cc: David Lechner, Axel Haslam, Sergei Shtylyov, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1477451211-31979-1-git-send-email-david@lechnology.com>
The CFGCHIP registers are used by a number of devices, so using a syscon
device to share them. The first consumer of this will by the phy-da8xx-usb
driver.
Signed-off-by: David Lechner <david@lechnology.com>
---
syscon device id is changed to -1 since there is only one syscon device.
arch/arm/mach-davinci/board-da830-evm.c | 4 ++++
arch/arm/mach-davinci/board-da850-evm.c | 4 ++++
arch/arm/mach-davinci/board-mityomapl138.c | 4 ++++
arch/arm/mach-davinci/board-omapl138-hawk.c | 4 ++++
arch/arm/mach-davinci/devices-da8xx.c | 28 ++++++++++++++++++++++++++++
arch/arm/mach-davinci/include/mach/da8xx.h | 2 ++
6 files changed, 46 insertions(+)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 605d444..3051cb6 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -586,6 +586,10 @@ static __init void da830_evm_init(void)
struct davinci_soc_info *soc_info = &davinci_soc_info;
int ret;
+ ret = da8xx_register_cfgchip();
+ if (ret)
+ pr_warn("%s: CFGCHIP registration failed: %d\n", __func__, ret);
+
ret = da830_register_gpio();
if (ret)
pr_warn("%s: GPIO init failed: %d\n", __func__, ret);
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 8e4539f..ec5cb10 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1345,6 +1345,10 @@ static __init void da850_evm_init(void)
{
int ret;
+ ret = da8xx_register_cfgchip();
+ if (ret)
+ pr_warn("%s: CFGCHIP registration failed: %d\n", __func__, ret);
+
ret = da850_register_gpio();
if (ret)
pr_warn("%s: GPIO init failed: %d\n", __func__, ret);
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index bc4e63f..1a6d430 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -514,6 +514,10 @@ static void __init mityomapl138_init(void)
{
int ret;
+ ret = da8xx_register_cfgchip();
+ if (ret)
+ pr_warn("%s: CFGCHIP registration failed: %d\n", __func__, ret);
+
/* for now, no special EDMA channels are reserved */
ret = da850_register_edma(NULL);
if (ret)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index d4930b6..8691a25 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -294,6 +294,10 @@ static __init void omapl138_hawk_init(void)
{
int ret;
+ ret = da8xx_register_cfgchip();
+ if (ret)
+ pr_warn("%s: CFGCHIP registration failed: %d\n", __func__, ret);
+
ret = da850_register_gpio();
if (ret)
pr_warn("%s: GPIO init failed: %d\n", __func__, ret);
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index add3771..31a99db 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -11,6 +11,7 @@
* (at your option) any later version.
*/
#include <linux/init.h>
+#include <linux/platform_data/syscon.h>
#include <linux/platform_device.h>
#include <linux/dma-contiguous.h>
#include <linux/serial_8250.h>
@@ -1089,3 +1090,30 @@ int __init da850_register_sata(unsigned long refclkpn)
return platform_device_register(&da850_sata_device);
}
#endif
+
+static struct syscon_platform_data da8xx_cfgchip_platform_data = {
+ .label = "cfgchip",
+};
+
+static struct resource da8xx_cfgchip_resources[] = {
+ {
+ .start = DA8XX_SYSCFG0_BASE + DA8XX_CFGCHIP0_REG,
+ .end = DA8XX_SYSCFG0_BASE + DA8XX_CFGCHIP4_REG + 3,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device da8xx_cfgchip_device = {
+ .name = "syscon",
+ .id = -1,
+ .dev = {
+ .platform_data = &da8xx_cfgchip_platform_data,
+ },
+ .num_resources = ARRAY_SIZE(da8xx_cfgchip_resources),
+ .resource = da8xx_cfgchip_resources,
+};
+
+int __init da8xx_register_cfgchip(void)
+{
+ return platform_device_register(&da8xx_cfgchip_device);
+}
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index c367530..c32444b 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -61,6 +61,7 @@ extern unsigned int da850_max_speed;
#define DA8XX_CFGCHIP1_REG 0x180
#define DA8XX_CFGCHIP2_REG 0x184
#define DA8XX_CFGCHIP3_REG 0x188
+#define DA8XX_CFGCHIP4_REG 0x18c
#define DA8XX_SYSCFG1_BASE (IO_PHYS + 0x22C000)
#define DA8XX_SYSCFG1_VIRT(x) (da8xx_syscfg1_base + (x))
@@ -116,6 +117,7 @@ void da8xx_rproc_reserve_cma(void);
int da8xx_register_rproc(void);
int da850_register_gpio(void);
int da830_register_gpio(void);
+int da8xx_register_cfgchip(void);
extern struct platform_device da8xx_serial_device[];
extern struct emac_platform_data da8xx_emac_pdata;
--
2.7.4
^ permalink raw reply related
* [PATCH v6 1/5] ARM: davinci: da8xx: add usb phy clocks
From: David Lechner @ 2016-10-26 3:06 UTC (permalink / raw)
To: Sekhar Nori, Kevin Hilman, Rob Herring, Mark Rutland
Cc: David Lechner, Axel Haslam, Sergei Shtylyov, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1477451211-31979-1-git-send-email-david@lechnology.com>
Up to this point, the USB phy clock configuration was handled manually in
the board files and in the usb drivers. This adds proper clocks so that
the usb drivers can use clk_get and clk_enable and not have to worry about
the details. Also, the related code is removed from the board files and
replaced with the new clock registration functions.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
I have added "ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable"
from Axel Haslam to this patch.
In the review of Axel's patch, Sekhar said:
> We should not be using a NULL device pointer here. Can you pass the musb
> device pointer available in the same file? Also, da850_clks[] in da850.c
> needs to be fixed to add the matching device name.
However, the musb device may not be registered. The usb20_clk can be used to
supply a 48MHz clock to USB 1.1 (ohci) without using the musb device. So, I am
inclined to leave this as NULL.
arch/arm/mach-davinci/board-da830-evm.c | 22 ++-
arch/arm/mach-davinci/board-omapl138-hawk.c | 16 +-
arch/arm/mach-davinci/include/mach/da8xx.h | 3 +
arch/arm/mach-davinci/usb-da8xx.c | 232 +++++++++++++++++++++++++++-
4 files changed, 252 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 3d8cf8c..605d444 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -115,18 +115,6 @@ static __init void da830_evm_usb_init(void)
*/
cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
- /* USB2.0 PHY reference clock is 24 MHz */
- cfgchip2 &= ~CFGCHIP2_REFFREQ;
- cfgchip2 |= CFGCHIP2_REFFREQ_24MHZ;
-
- /*
- * Select internal reference clock for USB 2.0 PHY
- * and use it as a clock source for USB 1.1 PHY
- * (this is the default setting anyway).
- */
- cfgchip2 &= ~CFGCHIP2_USB1PHYCLKMUX;
- cfgchip2 |= CFGCHIP2_USB2PHYCLKMUX;
-
/*
* We have to override VBUS/ID signals when MUSB is configured into the
* host-only mode -- ID pin will float if no cable is connected, so the
@@ -143,6 +131,16 @@ static __init void da830_evm_usb_init(void)
__raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
/* USB_REFCLKIN is not used. */
+ ret = da8xx_register_usb20_phy_clk(false);
+ if (ret)
+ pr_warn("%s: USB 2.0 PHY CLK registration failed: %d\n",
+ __func__, ret);
+
+ ret = da8xx_register_usb11_phy_clk(false);
+ if (ret)
+ pr_warn("%s: USB 1.1 PHY CLK registration failed: %d\n",
+ __func__, ret);
+
ret = davinci_cfg_reg(DA830_USB0_DRVVBUS);
if (ret)
pr_warn("%s: USB 2.0 PinMux setup failed: %d\n", __func__, ret);
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index ee62486..d4930b6 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -243,7 +243,6 @@ static irqreturn_t omapl138_hawk_usb_ocic_irq(int irq, void *dev_id)
static __init void omapl138_hawk_usb_init(void)
{
int ret;
- u32 cfgchip2;
ret = davinci_cfg_reg_list(da850_hawk_usb11_pins);
if (ret) {
@@ -251,12 +250,15 @@ static __init void omapl138_hawk_usb_init(void)
return;
}
- /* Setup the Ref. clock frequency for the HAWK at 24 MHz. */
-
- cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
- cfgchip2 &= ~CFGCHIP2_REFFREQ;
- cfgchip2 |= CFGCHIP2_REFFREQ_24MHZ;
- __raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+ /* USB_REFCLKIN is not used. */
+ ret = da8xx_register_usb20_phy_clk(false);
+ if (ret)
+ pr_warn("%s: USB 2.0 PHY CLK registration failed: %d\n",
+ __func__, ret);
+ ret = da8xx_register_usb11_phy_clk(false);
+ if (ret)
+ pr_warn("%s: USB 1.1 PHY CLK registration failed: %d\n",
+ __func__, ret);
ret = gpio_request_one(DA850_USB1_VBUS_PIN,
GPIOF_DIR_OUT, "USB1 VBUS");
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index f9f9713..c367530 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -88,6 +88,9 @@ int da850_register_edma(struct edma_rsv_info *rsv[2]);
int da8xx_register_i2c(int instance, struct davinci_i2c_platform_data *pdata);
int da8xx_register_spi_bus(int instance, unsigned num_chipselect);
int da8xx_register_watchdog(void);
+int da8xx_register_usb_refclkin(int rate);
+int da8xx_register_usb20_phy_clk(bool use_usb_refclkin);
+int da8xx_register_usb11_phy_clk(bool use_usb_refclkin);
int da8xx_register_usb20(unsigned mA, unsigned potpgt);
int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
int da8xx_register_emac(void);
diff --git a/arch/arm/mach-davinci/usb-da8xx.c b/arch/arm/mach-davinci/usb-da8xx.c
index f141f51..71a6d85 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -1,20 +1,248 @@
/*
* DA8xx USB
*/
-#include <linux/dma-mapping.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
#include <linux/init.h>
#include <linux/platform_data/usb-davinci.h>
#include <linux/platform_device.h>
+#include <linux/mfd/da8xx-cfgchip.h>
#include <linux/usb/musb.h>
+#include <mach/clock.h>
#include <mach/common.h>
#include <mach/cputype.h>
#include <mach/da8xx.h>
-#include <mach/irqs.h>
+
+#include "clock.h"
#define DA8XX_USB0_BASE 0x01e00000
#define DA8XX_USB1_BASE 0x01e25000
+static struct clk usb_refclkin = {
+ .name = "usb_refclkin",
+ .set_rate = davinci_simple_set_rate,
+};
+
+static struct clk_lookup usb_refclkin_lookup =
+ CLK(NULL, "usb_refclkin", &usb_refclkin);
+
+/**
+ * da8xx_register_usb_refclkin - register USB_REFCLKIN clock
+ *
+ * @rate: The clock rate in Hz
+ *
+ * This clock is only needed if the board provides an external USB_REFCLKIN
+ * signal, in which case it will be used as the parent of usb20_phy_clk and/or
+ * usb11_phy_clk.
+ */
+int __init da8xx_register_usb_refclkin(int rate)
+{
+ int ret;
+
+ usb_refclkin.rate = rate;
+ ret = clk_register(&usb_refclkin);
+ if (ret)
+ return ret;
+
+ clkdev_add(&usb_refclkin_lookup);
+
+ return 0;
+}
+
+static void usb20_phy_clk_enable(struct clk *clk)
+{
+ struct clk *usb20_clk;
+ u32 val;
+ u32 timeout = 500000; /* 500 msec */
+
+ val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ usb20_clk = clk_get(NULL, "usb20");
+ if (IS_ERR(usb20_clk)) {
+ pr_err("could not get usb20 clk\n");
+ return;
+ }
+
+ /* The USB 2.O PLL requires that the USB 2.O PSC is enabled as well. */
+ clk_prepare_enable(usb20_clk);
+
+ /*
+ * Turn on the USB 2.0 PHY, but just the PLL, and not OTG. The USB 1.1
+ * host may use the PLL clock without USB 2.0 OTG being used.
+ */
+ val &= ~(CFGCHIP2_RESET | CFGCHIP2_PHYPWRDN);
+ val |= CFGCHIP2_PHY_PLLON;
+
+ writel(val, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ while (--timeout) {
+ val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+ if (val & CFGCHIP2_PHYCLKGD)
+ goto done;
+ udelay(1);
+ }
+
+ pr_err("Timeout waiting for USB 2.0 PHY clock good.\n");
+done:
+ clk_disable_unprepare(usb20_clk);
+ clk_put(usb20_clk);
+}
+
+static void usb20_phy_clk_disable(struct clk *clk)
+{
+ u32 val;
+
+ val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+ val |= CFGCHIP2_PHYPWRDN;
+ writel(val, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+}
+
+static int usb20_phy_clk_set_parent(struct clk *clk, struct clk *parent)
+{
+ u32 val;
+
+ val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ /* Set the mux depending on the parent clock. */
+ if (parent == &usb_refclkin) {
+ val &= ~CFGCHIP2_USB2PHYCLKMUX;
+ } else if (strcmp(parent->name, "pll0_aux_clk") == 0) {
+ val |= CFGCHIP2_USB2PHYCLKMUX;
+ } else {
+ pr_err("Bad parent on USB 2.0 PHY clock.\n");
+ return -EINVAL;
+ }
+
+ /* reference frequency also comes from parent clock */
+ val &= ~CFGCHIP2_REFFREQ_MASK;
+ switch (clk_get_rate(parent)) {
+ case 12000000:
+ val |= CFGCHIP2_REFFREQ_12MHZ;
+ break;
+ case 13000000:
+ val |= CFGCHIP2_REFFREQ_13MHZ;
+ break;
+ case 19200000:
+ val |= CFGCHIP2_REFFREQ_19_2MHZ;
+ break;
+ case 20000000:
+ val |= CFGCHIP2_REFFREQ_20MHZ;
+ break;
+ case 24000000:
+ val |= CFGCHIP2_REFFREQ_24MHZ;
+ break;
+ case 26000000:
+ val |= CFGCHIP2_REFFREQ_26MHZ;
+ break;
+ case 38400000:
+ val |= CFGCHIP2_REFFREQ_38_4MHZ;
+ break;
+ case 40000000:
+ val |= CFGCHIP2_REFFREQ_40MHZ;
+ break;
+ case 48000000:
+ val |= CFGCHIP2_REFFREQ_48MHZ;
+ break;
+ default:
+ pr_err("Bad parent clock rate on USB 2.0 PHY clock.\n");
+ return -EINVAL;
+ }
+
+ writel(val, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ return 0;
+}
+
+static struct clk usb20_phy_clk = {
+ .name = "usb20_phy",
+ .clk_enable = usb20_phy_clk_enable,
+ .clk_disable = usb20_phy_clk_disable,
+ .set_parent = usb20_phy_clk_set_parent,
+};
+
+static struct clk_lookup usb20_phy_clk_lookup =
+ CLK(NULL, "usb20_phy", &usb20_phy_clk);
+
+/**
+ * da8xx_register_usb20_phy_clk - register USB0PHYCLKMUX clock
+ *
+ * @use_usb_refclkin: Selects the parent clock - either "usb_refclkin" if true
+ * or "pll0_aux" if false.
+ */
+int __init da8xx_register_usb20_phy_clk(bool use_usb_refclkin)
+{
+ struct clk *parent;
+ int ret = 0;
+
+ parent = clk_get(NULL, use_usb_refclkin ? "usb_refclkin" : "pll0_aux");
+ if (IS_ERR(parent))
+ return PTR_ERR(parent);
+
+ usb20_phy_clk.parent = parent;
+ ret = clk_register(&usb20_phy_clk);
+ if (!ret)
+ clkdev_add(&usb20_phy_clk_lookup);
+
+ clk_put(parent);
+
+ return ret;
+}
+
+static int usb11_phy_clk_set_parent(struct clk *clk, struct clk *parent)
+{
+ u32 val;
+
+ val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ /* Set the USB 1.1 PHY clock mux based on the parent clock. */
+ if (parent == &usb20_phy_clk) {
+ val &= ~CFGCHIP2_USB1PHYCLKMUX;
+ } else if (parent == &usb_refclkin) {
+ val |= CFGCHIP2_USB1PHYCLKMUX;
+ } else {
+ pr_err("Bad parent on USB 1.1 PHY clock.\n");
+ return -EINVAL;
+ }
+
+ writel(val, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ return 0;
+}
+
+static struct clk usb11_phy_clk = {
+ .name = "usb11_phy",
+ .set_parent = usb11_phy_clk_set_parent,
+};
+
+static struct clk_lookup usb11_phy_clk_lookup =
+ CLK(NULL, "usb11_phy", &usb11_phy_clk);
+
+/**
+ * da8xx_register_usb11_phy_clk - register USB1PHYCLKMUX clock
+ *
+ * @use_usb_refclkin: Selects the parent clock - either "usb_refclkin" if true
+ * or "usb20_phy" if false.
+ */
+int __init da8xx_register_usb11_phy_clk(bool use_usb_refclkin)
+{
+ struct clk *parent;
+ int ret = 0;
+
+ parent = clk_get(NULL, use_usb_refclkin ? "usb_refclkin" : "usb20_phy");
+ if (IS_ERR(parent))
+ return PTR_ERR(parent);
+
+ usb11_phy_clk.parent = parent;
+ ret = clk_register(&usb11_phy_clk);
+ if (!ret)
+ clkdev_add(&usb11_phy_clk_lookup);
+
+ clk_put(parent);
+
+ return ret;
+}
+
#if IS_ENABLED(CONFIG_USB_MUSB_HDRC)
static struct musb_hdrc_config musb_config = {
--
2.7.4
^ permalink raw reply related
* [PATCH v6 0/5] da8xx USB PHY platform devices and clocks
From: David Lechner @ 2016-10-26 3:06 UTC (permalink / raw)
To: Sekhar Nori, Kevin Hilman, Rob Herring, Mark Rutland
Cc: David Lechner, Axel Haslam, Sergei Shtylyov,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
It has been almost 6 months since the v5 submission, so here is a recap:
* There were a number of phy and usb dependencies that were submitted
separately.
* The last of the usb dependencies has finally made its way into linux-next
today.
* This series was recently included in "[PATCH/RFT v2 00/17] Add DT support for
ohci-da8xx". I am breaking it back out again as a standalone series.
v6 changes:
* Combine "ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable"
from the "[PATCH/RFT v2 00/17] Add DT support for ohci-da8xx" series with
the "ARM: davinci: da8xx: add usb phy clocks" patch in this series.
* Change the syscon and da8xx-usb-phy device ids to -1.
v5 changes: renamed "usbphy" to "usb_phy" or "usb-phy" as appropriate
v4 changes: fix strict checkpatch complaint
v3 changes:
* Fixed the davinci device tree declarations to use the preferred DT address
convention so that the items I have added can be correct too.
* Moved that davinci clock init so that we don't have to call ioremap in the
clock mux functions.
* Added a new "syscon" device for the CFGCHIP registers. This is used by the
USB PHY driver and will be used in the future in common clock framework
drivers.
* USB clocks are moved to a common file instead of having duplicated code.
* PHY driver uses syscon for CFGCHIP registers instead of using them directly.
David Lechner (5):
ARM: davinci: da8xx: add usb phy clocks
ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.
ARM: davinci: da8xx: Add USB PHY platform declaration
ARM: DTS: da850: Add cfgchip syscon node
ARM: DTS: da850: Add usb phy node
arch/arm/boot/dts/da850.dtsi | 9 ++
arch/arm/mach-davinci/board-da830-evm.c | 52 +++---
arch/arm/mach-davinci/board-da850-evm.c | 4 +
arch/arm/mach-davinci/board-mityomapl138.c | 4 +
arch/arm/mach-davinci/board-omapl138-hawk.c | 23 ++-
arch/arm/mach-davinci/devices-da8xx.c | 28 ++++
arch/arm/mach-davinci/include/mach/da8xx.h | 6 +
arch/arm/mach-davinci/usb-da8xx.c | 243 +++++++++++++++++++++++++++-
8 files changed, 327 insertions(+), 42 deletions(-)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
From: Ding Tianhong @ 2016-10-26 2:59 UTC (permalink / raw)
To: Mark Rutland
Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Scott Wood,
devicetree-u79uwXL29TY76Z2rM5mHXA, Shawn Guo,
stuart.yoder-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161024133945.GL15620@leverpostej>
On 2016/10/24 21:39, Mark Rutland wrote:
> On Mon, Oct 24, 2016 at 09:23:10PM +0800, Ding Tianhong wrote:
>> On 2016/10/24 21:16, Mark Rutland wrote:
>>> On Mon, Oct 24, 2016 at 08:40:01PM +0800, Ding Tianhong wrote:
>>>> On 2016/10/24 19:16, Mark Rutland wrote:
>>>>> Is "161x01" the *exact* erratum number, or is the 'x' a wildcard?
>>>>
>>>> The 'x' is a wildcard, it will cover 161001 to 161601 several numbers,
>>>
>>> Given you're using a wildcard, I take it that this is a *part* number?
>>
>> Yes, I was doubt how to fix this, should I choose a better erratum number?
>
> Typically, we expect that each vendor has some central database of their
> errata, with each having a unique ID.
>
> If Huawei do not have such a database, I do not think that we should
> invent an erratum number here.
>
Hi Marko<\x1a
After discussion with our chip developer, we decide the 161601 as the *exact* erratum number for this chip to cover
all the problem and register this in our company's database, thanks.
Ding
> Thanks,
> Mark.
>
> .
>
--
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 v8 0/8] power: add power sequence library
From: Peter Chen @ 2016-10-26 1:27 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Peter Chen, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
broonie-DgEjT+Ai2ygdnm+yROfE0A, sre-DgEjT+Ai2ygdnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w, heiko-4mtYJXux2i+zQB+pC5nmwQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
linux-usb-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ,
mail-APzI5cXaD1zVlRWJc41N0YvC60bnQu0Y,
troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR,
festevam-Re5JQEeQqe8AvxtiuMwx3w, oscar-Bdbr4918Nnnk1uMJSBkQmQ,
stephen.boyd-QSEj5FYQhm4dnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
stillcompiling-Re5JQEeQqe8AvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, mka-F7+t8E8rja9g9hUCZPvPmw,
vaibhav.hiremath-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <5513671.XlE8bb9pVt-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
On Tue, Oct 18, 2016 at 02:35:38AM +0200, Rafael J. Wysocki wrote:
> On Monday, October 17, 2016 09:30:59 AM Peter Chen wrote:
> > On Fri, Oct 14, 2016 at 02:09:31PM +0200, Rafael J. Wysocki wrote:
> > > On Friday, October 14, 2016 10:59:47 AM Peter Chen wrote:
> > > > Hi all,
> > > >
> > > > This is a follow-up for my last power sequence framework patch set [1].
> > > > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> > > > power sequence instances will be added at postcore_initcall, the match
> > > > criteria is compatible string first, if the compatible string is not
> > > > matched between dts and library, it will try to use generic power sequence.
> > > >
> > > > The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > > > if only one power sequence instance is needed, for more power sequences
> > > > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver).
> > > >
> > > > In future, if there are special power sequence requirements, the special
> > > > power sequence library can be created.
> > > >
> > > > This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > > > two hot-plug devices to simulate this use case, the related binding
> > > > change is updated at patch [1/6], The udoo board changes were tested
> > > > using my last power sequence patch set.[3]
> > > >
> > > > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > > > need to power on itself before it can be found by ULPI bus.
> > > >
> > > > [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > > > [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > > > [3] http://www.spinics.net/lists/linux-usb/msg142815.html
> > > >
> > > > Changes for v8:
> > > > - Allocate one extra pwrseq instance if pwrseq_get has succeed, it can avoid
> > > > preallocate instances problem which the number of instance is decided at
> > > > compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8]
> > > > - Delete pwrseq_compatible_sample.c which is the demo purpose to show compatible
> > > > match method. [Patch 2/8]
> > > > - Add Maciej S. Szmigiero's tested-by. [Patch 7/8]
> > > >
> > > > Changes for v7:
> > > > - Create kinds of power sequence instance at postcore_initcall, and match
> > > > the instance with node using compatible string, the beneit of this is
> > > > the host driver doesn't need to consider which pwrseq instance needs
> > > > to be used, and pwrseq core will match it, however, it eats some memories
> > > > if less power sequence instances are used. [Patch 2/8]
> > > > - Add pwrseq_compatible_sample.c to test match pwrseq using device_id. [Patch 2/8]
> > > > - Fix the comments Vaibhav Hiremath adds for error path for clock and do not
> > > > use device_node for parameters at pwrseq_on. [Patch 2/8]
> > > > - Simplify the caller to use power sequence, follows Alan's commnets [Patch 4/8]
> > > > - Tested three pwrseq instances together using both specific compatible string and
> > > > generic libraries.
> > > >
> > > > Changes for v6:
> > > > - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
> > > > - Change chipidea core of_node assignment for coming user. (patch [5/6])
> > > > - Applies Joshua Clayton's three dts changes for two boards,
> > > > the USB device's reg has only #address-cells, but without #size-cells.
> > > >
> > > > Changes for v5:
> > > > - Delete pwrseq_register/pwrseq_unregister, which is useless currently
> > > > - Fix the linker error when the pwrseq user is compiled as module
> > > >
> > > > Changes for v4:
> > > > - Create the patch on next-20160722
> > > > - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
> > > > - Using more friendly wait method for reset gpio [Patch 2/6]
> > > > - Support multiple input clocks [Patch 2/6]
> > > > - Add Rob Herring's ack for DT changes
> > > > - Add Joshua Clayton's Tested-by
> > > >
> > > > Changes for v3:
> > > > - Delete "power-sequence" property at binding-doc, and change related code
> > > > at both library and user code.
> > > > - Change binding-doc example node name with Rob's comments
> > > > - of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
> > > > add additional code request gpio with proper gpio flags
> > > > - Add Philipp Zabel's Ack and MAINTAINER's entry
> > > >
> > > > Changes for v2:
> > > > - Delete "pwrseq" prefix and clock-names for properties at dt binding
> > > > - Should use structure not but its pointer for kzalloc
> > > > - Since chipidea core has no of_node, let core's of_node equals glue
> > > > layer's at core's probe
> > > >
> > > > Joshua Clayton (2):
> > > > ARM: dts: imx6qdl: Enable usb node children with <reg>
> > > > ARM: dts: imx6q-evi: Fix onboard hub reset line
> > > >
> > > > Peter Chen (6):
> > > > binding-doc: power: pwrseq-generic: add binding doc for generic power
> > > > sequence library
> > > > power: add power sequence library
> > > > binding-doc: usb: usb-device: add optional properties for power
> > > > sequence
> > > > usb: core: add power sequence handling for USB devices
> > > > usb: chipidea: let chipidea core device of_node equal's glue layer
> > > > device of_node
> > > > ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
> > > >
> > > > .../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++++++
> > > > .../devicetree/bindings/usb/usb-device.txt | 10 +-
> > > > MAINTAINERS | 9 +
> > > > arch/arm/boot/dts/imx6q-evi.dts | 25 +--
> > > > arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 ++-
> > > > arch/arm/boot/dts/imx6qdl.dtsi | 6 +
> > > > drivers/power/Kconfig | 1 +
> > > > drivers/power/Makefile | 1 +
> > > > drivers/power/pwrseq/Kconfig | 19 ++
> > > > drivers/power/pwrseq/Makefile | 2 +
> > > > drivers/power/pwrseq/core.c | 191 +++++++++++++++++++++
> > > > drivers/power/pwrseq/pwrseq_generic.c | 183 ++++++++++++++++++++
> > > > drivers/usb/chipidea/core.c | 27 ++-
> > > > drivers/usb/core/hub.c | 41 ++++-
> > > > drivers/usb/core/hub.h | 1 +
> > > > include/linux/power/pwrseq.h | 72 ++++++++
> > > > 16 files changed, 621 insertions(+), 41 deletions(-)
> > > > create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> > > > create mode 100644 drivers/power/pwrseq/Kconfig
> > > > create mode 100644 drivers/power/pwrseq/Makefile
> > > > create mode 100644 drivers/power/pwrseq/core.c
> > > > create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
> > > > create mode 100644 include/linux/power/pwrseq.h
> > >
> > > Meta question: Who's the maintainer you are targetting this at?
> > >
> >
> > Sebastian Reichel mentioned it is better through your tree.
> > I could be the maintainer for it, and send "GIT PULL" for you
> > through my git
> > (https://git.kernel.org/cgit/linux/kernel/git/peter.chen/usb.git/)
> > Is it ok for you?
>
> Let me review the series first. :-)
>
A nice ping..., thanks.
Just see someone is also waiting this series.
http://www.spinics.net/lists/devicetree/msg147655.html
--
Best Regards,
Peter Chen
--
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 4/5] mm: make processing of movable_node arch-specific
From: Reza Arbab @ 2016-10-26 0:49 UTC (permalink / raw)
To: Balbir Singh
Cc: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rob Herring, Frank Rowand, Andrew Morton, Bharata B Rao,
Nathan Fontenot, Stewart Smith, Alistair Popple, Aneesh Kumar K.V,
Tang Chen, linux-kernel, linuxppc-dev, devicetree, linux-mm
In-Reply-To: <112504e9-561d-e0da-7a40-73996c678b56@gmail.com>
On Wed, Oct 26, 2016 at 09:34:18AM +1100, Balbir Singh wrote:
>I still believe we need your changes, I was wondering if we've tested
>it against normal memory nodes and checked if any memblock
>allocations end up there. Michael showed me some memblock
>allocations on node 1 of a two node machine with movable_node
The movable_node option is x86-only. Both of those nodes contain normal
memory, so allocations on both are allowed.
>> Longer; if you use "movable_node", x86 can identify these nodes at
>> boot. They call memblock_mark_hotplug() while parsing the SRAT. Then,
>> when the zones are initialized, those markings are used to determine
>> ZONE_MOVABLE.
>>
>> We have no analog of this SRAT information, so our movable nodes can
>> only be created post boot, by hotplugging and explicitly onlining
>> with online_movable.
>
>Is this true for all of system memory as well or only for nodes
>hotplugged later?
As far as I know, power has nothing like the SRAT that tells us, at
boot, which memory is hotpluggable. So there is nothing to wire the
movable_node option up to.
Of course, any memory you hotplug afterwards is, by definition,
hotpluggable. So we can still create movable nodes that way.
--
Reza Arbab
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] of: fdt: Add a space to the pr_fmt string
From: Frank Rowand @ 2016-10-26 0:34 UTC (permalink / raw)
To: Fabio Estevam, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
festevam-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1477414933-24050-1-git-send-email-fabio.estevam-3arQi8VN3Tc@public.gmane.org>
On 10/25/16 10:02, Fabio Estevam wrote:
> Add a space to the fdt messages so they can look a bit better:
>
> OF: fdt: Machine model: Freescale i.MX28 Evaluation Kit
>
> instead of
>
> OF: fdt:Machine model: Freescale i.MX28 Evaluation Kit
>
> Signed-off-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> ---
> drivers/of/fdt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index c89d5d2..9f98e43 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -9,7 +9,7 @@
> * version 2 as published by the Free Software Foundation.
> */
>
> -#define pr_fmt(fmt) "OF: fdt:" fmt
> +#define pr_fmt(fmt) "OF: fdt: " fmt
>
> #include <linux/crc32.h>
> #include <linux/kernel.h>
>
Hi Fabio,
They say great minds think alike. I sent this same patch just a few
days ago. http://www.spinics.net/lists/devicetree/msg146251.html
Thanks for noticing the problem and sending a patch.
Please run scripts/getmaintainer.pl before sending patches. You
left me off the list for your patch.
-Frank
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: mvebu: Update comment for main PLL frequency
From: Chris Packham @ 2016-10-25 23:52 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Chris Packham, Jason Cooper, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
The actual frequency was updated in commit ae142bd99765 ("ARM: mvebu:
Fix the main PLL frequency on Armada 375, 38x and 39x SoCs") but the
comment was not updated. Update it now.
Signed-off-by: Chris Packham <chris.packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
arch/arm/boot/dts/armada-38x.dtsi | 2 +-
arch/arm/boot/dts/armada-39x.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index cc952cf8ec30..45fa92f9cf5c 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -65,7 +65,7 @@
};
clocks {
- /* 2 GHz fixed main PLL */
+ /* 1 GHz fixed main PLL */
mainpll: mainpll {
compatible = "fixed-clock";
#clock-cells = <0>;
diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
index 2d7668848c5a..7450e9fea45d 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -661,7 +661,7 @@
};
clocks {
- /* 2 GHz fixed main PLL */
+ /* 1 GHz fixed main PLL */
mainpll: mainpll {
compatible = "fixed-clock";
#clock-cells = <0>;
diff --git a/arch/arm/boot/dts/armada-39x.dtsi b/arch/arm/boot/dts/armada-39x.dtsi
index 34cba87f9200..de171baffcf6 100644
--- a/arch/arm/boot/dts/armada-39x.dtsi
+++ b/arch/arm/boot/dts/armada-39x.dtsi
@@ -573,7 +573,7 @@
};
clocks {
- /* 2 GHz fixed main PLL */
+ /* 1 GHz fixed main PLL */
mainpll: mainpll {
compatible = "fixed-clock";
#clock-cells = <0>;
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [linux-sunxi] Re: [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2
From: André Przywara @ 2016-10-25 23:52 UTC (permalink / raw)
To: moinejf-Re5JQEeQqe8AvxtiuMwx3w, Maxime Ripard
Cc: Dave Airlie, Liam Girdwood, Mark Brown, Rob Herring,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161025161441.6b248efe9229bd80e3f7a33c-GANU6spQydw@public.gmane.org>
On 25/10/16 15:14, Jean-Francois Moine wrote:
> On Mon, 24 Oct 2016 16:04:19 +0200
> Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
>> Hi,
>
> Hi Maxime,
>
>> On Fri, Oct 21, 2016 at 09:26:18AM +0200, Jean-Francois Moine wrote:
>>> Allwinner's recent SoCs, as A64, A83T and H3, contain a new display
>>> engine, DE2.
>>> This patch adds a DRM video driver for this device.
>>>
>>> Signed-off-by: Jean-Francois Moine <moinejf-GANU6spQydw@public.gmane.org>
>>
>> Output from checkpatch:
>> total: 0 errors, 20 warnings, 83 checks, 1799 lines checked
>>
>>> ---
>>> .../bindings/display/sunxi/sunxi-de2.txt | 83 +++
>>> drivers/gpu/drm/Kconfig | 2 +
>>> drivers/gpu/drm/Makefile | 1 +
>>> drivers/gpu/drm/sunxi/Kconfig | 21 +
>>> drivers/gpu/drm/sunxi/Makefile | 7 +
>>> drivers/gpu/drm/sunxi/de2_crtc.c | 475 +++++++++++++++++
>>> drivers/gpu/drm/sunxi/de2_crtc.h | 63 +++
>>> drivers/gpu/drm/sunxi/de2_de.c | 591 +++++++++++++++++++++
>>> drivers/gpu/drm/sunxi/de2_drm.h | 47 ++
>>> drivers/gpu/drm/sunxi/de2_drv.c | 378 +++++++++++++
>>> drivers/gpu/drm/sunxi/de2_plane.c | 119 +++++
>>> 11 files changed, 1787 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
>>> create mode 100644 drivers/gpu/drm/sunxi/Kconfig
>>> create mode 100644 drivers/gpu/drm/sunxi/Makefile
>>> create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
>>> create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
>>> create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
>>> create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
>>> create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
>>> create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt b/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
>>> new file mode 100644
>>> index 0000000..f9cd67a
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
>>> @@ -0,0 +1,83 @@
>>> +Allwinner sunxi Display Engine 2 subsystem
>>> +==========================================
>>> +
>>> +The sunxi DE2 subsystem contains a display controller (DE2),
>>
>> sunxi is a made up name, and doesn't really mean anything. You can
>> call it either sun8i (because it was introduced in that family).
>
> OK.
>
>>> +one or two LCD controllers (TCON) and their external interfaces.
>>> +
>>> +Display controller
>>> +==================
>>> +
>>> +Required properties:
>>> +
>>> +- compatible: value should be one of the following
>>> + "allwinner,sun8i-a83t-display-engine"
>>> + "allwinner,sun8i-h3-display-engine"
>>> +
>>> +- clocks: must include clock specifiers corresponding to entries in the
>>> + clock-names property.
>>> +
>>> +- clock-names: must contain
>>> + "gate": for DE activation
>>> + "clock": DE clock
>>
>> We've been calling them bus and mod.
>
> I can understand "bus" (which is better than "apb"), but why "mod"?
>
>>> +
>>> +- resets: phandle to the reset of the device
>>> +
>>> +- ports: phandle's to the LCD ports
>>
>> Please use the OF graph.
>
> These ports are references to the graph of nodes. See
> http://www.kernelhub.org/?msg=911825&p=2
>
> [snip]
>>> diff --git a/drivers/gpu/drm/sunxi/de2_crtc.c b/drivers/gpu/drm/sunxi/de2_crtc.c
>>> new file mode 100644
>>> index 0000000..dae0fab
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/sunxi/de2_crtc.c
>>> @@ -0,0 +1,475 @@
>>> +/*
>>> + * Allwinner DRM driver - DE2 CRTC
>>> + *
>>> + * Copyright (C) 2016 Jean-Francois Moine <moinejf-GANU6spQydw@public.gmane.org>
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU General Public License as
>>> + * published by the Free Software Foundation; either version 2 of
>>> + * the License, or (at your option) any later version.
>>> + */
>>> +
>>> +#include <linux/component.h>
>>> +#include <drm/drm_crtc_helper.h>
>>> +#include <drm/drm_atomic_helper.h>
>>> +#include <asm/io.h>
>>> +#include <linux/of_irq.h>
>>> +
>>> +#include "de2_drm.h"
>>> +#include "de2_crtc.h"
>>> +
>>> +/* I/O map */
>>> +
>>> +struct tcon {
>>> + u32 gctl;
>>> +#define TCON_GCTL_TCON_En BIT(31)
>>> + u32 gint0;
>>> +#define TCON_GINT0_TCON1_Vb_Int_En BIT(30)
>>> +#define TCON_GINT0_TCON1_Vb_Int_Flag BIT(14)
>>> + u32 gint1;
>>> + u32 dum0[13];
>>> + u32 tcon0_ctl; /* 0x40 */
>>> +#define TCON0_CTL_TCON_En BIT(31)
>>> + u32 dum1[19];
>>> + u32 tcon1_ctl; /* 0x90 */
>>> +#define TCON1_CTL_TCON_En BIT(31)
>>> +#define TCON1_CTL_Interlace_En BIT(20)
>>> +#define TCON1_CTL_Start_Delay_SHIFT 4
>>> +#define TCON1_CTL_Start_Delay_MASK GENMASK(8, 4)
>>> + u32 basic0; /* XI/YI */
>>> + u32 basic1; /* LS_XO/LS_YO */
>>> + u32 basic2; /* XO/YO */
>>> + u32 basic3; /* HT/HBP */
>>> + u32 basic4; /* VT/VBP */
>>> + u32 basic5; /* HSPW/VSPW */
>>> + u32 dum2;
>>> + u32 ps_sync; /* 0xb0 */
>>> + u32 dum3[15];
>>> + u32 io_pol; /* 0xf0 */
>>> +#define TCON1_IO_POL_IO0_inv BIT(24)
>>> +#define TCON1_IO_POL_IO1_inv BIT(25)
>>> +#define TCON1_IO_POL_IO2_inv BIT(26)
>>> + u32 io_tri;
>>> + u32 dum4[2];
>>> +
>>> + u32 ceu_ctl; /* 0x100 */
>>> +#define TCON_CEU_CTL_ceu_en BIT(31)
>>> + u32 dum5[3];
>>> + u32 ceu_rr;
>>> + u32 ceu_rg;
>>> + u32 ceu_rb;
>>> + u32 ceu_rc;
>>> + u32 ceu_gr;
>>> + u32 ceu_gg;
>>> + u32 ceu_gb;
>>> + u32 ceu_gc;
>>> + u32 ceu_br;
>>> + u32 ceu_bg;
>>> + u32 ceu_bb;
>>> + u32 ceu_bc;
>>> + u32 ceu_rv;
>>> + u32 ceu_gv;
>>> + u32 ceu_bv;
>>> + u32 dum6[45];
>>> +
>>> + u32 mux_ctl; /* 0x200 */
>>> + u32 dum7[63];
>>> +
>>> + u32 fill_ctl; /* 0x300 */
>>> + u32 fill_start0;
>>> + u32 fill_end0;
>>> + u32 fill_data0;
>>> +};
>>
>> Please use defines instead of the structures.
>
> I think that structures are more readable.
I think for the kernel we don't use C structs to model register frames.
The main argument against it is that putting them into a structure puts
the actual offset into the hands of the compiler, which is free to
insert padding and alignment - within the rules of the ABI. This happens
to work when we use 32-bit registers and maybe char fillers only. Most
ABIs seem to agree on this part, but there is no guarantee.
In fact all those various ABIs used by the kernel could have subtle
differences between architectures (for instance for alignment of 64-bit
members), so we produce potentially non-portable code.
Also I find it actually harder to read, since the manual refers to
register offset addresses, which makes it hard to match with the code,
especially if we deviate with the register naming. The fact that we have
occasional *comments* to denote the actual offset is a hint that
something is sub-optimal.
Also having these dummy fillers is really error prone once we insert new
registers, as the fill value has to be adjusted accordingly.
So can we stick with what the kernel uses elsewhere and don't pretend
that because the current GCC compiles that fine on ARM it will be good
forever?
Thanks!
Andre.
--
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
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