Re: [PATCH 1/3 repost] clocksource: sh_cmt: Document SoC specific bindings

[Geert Uytterhoeven]

Hi Simon,

On Wed, Aug 27, 2014 at 7:28 AM, Simon Horman
 wrote:
> n general Renesas hardware is not documented to the extent
> where the relationship between IP blocks on different SoCs can be assumed
> although they may appear to operate the same way. Furthermore the
> documentation typically does not specify a version for individual
> IP blocks. For these reasons a convention of using the SoC name in place
> of a version and providing SoC-specific compat strings has been adopted.
>
> Although not universally liked this convention is used in the bindings
> for the drivers a number of drivers for Renesas hardware. The purpose

s/the drivers //

> of this patch is to update the Renesas R-Car Compare Match Timer (CMT)
> driver to follow this convention.
>
> Signed-off-by: Simon Horman 



> ---
> * I plan to follow up with patches to use these new bindings in the
>   dtsi files for the affected SoCs.
> ---
>  .../devicetree/bindings/timer/renesas,cmt.txt  | 26 
> +-
>  1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt 
> b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> index a17418b..500bad2 100644
> --- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> @@ -16,10 +16,34 @@ Required Properties:
> (CMT0 on sh7372, sh73a0 and r8a7740)
>  - "renesas,cmt-32-fast" for the 32-bit CMT with fast clock support
> (CMT[234] on sh7372, sh73a0 and r8a7740)
> +- "renesas,cmt-32-fast-r8a7740" for the R8A7740 32-bit CMT with fast
> +   clock support (CMT[234])
> +- "renesas,cmt-32-fast-sh7372" for the SH7372 32-bit CMT with fast
> +   clock support (CMT[234])
> +- "renesas,cmt-32-fast-sh73a0" for the SH73A0 32-bit CMT with fast
> +   clock support (CMT[234])

> +- "renesas,cmt-32-r8a7740" for the R8a7740 32-bit CMT
> +   (CMT0)
> +- "renesas,cmt-32-sh7372" for the SH7372 32-bit CMT
> +   (CMT0)
> +- "renesas,cmt-32-sh73a0" for the SH73a0 32-bit CMT
> +   (CMT0)

I'd move these 3 non-fast "renesas,cmt-32-*" values up, under
"renesas,cmt-32".

>  - "renesas,cmt-48" for the 48-bit CMT
> (CMT1 on sh7372, sh73a0 and r8a7740)
>  - "renesas,cmt-48-gen2" for the second generation 48-bit CMT
> (CMT[01] on r8a73a4, r8a7790 and r8a7791)
> +- "renesas,cmt-48-r8a73a4" for the R8A73A4 48-bit CMT
> +   (CMT[01])
> +- "renesas,cmt-48-r8a7740" for the R8A7740 48-bit CMT
> +   (CMT1)
> +- "renesas,cmt-48-r8a7790" for the R8A7790 48-bit CMT
> +   (CMT[01])
> +- "renesas,cmt-48-r8a7791" for the R8A7791 48-bit CMT
> +   (CMT[01])
> +- "renesas,cmt-48-sh7372" for the SH7372 48-bit CMT
> +   (CMT1)
> +- "renesas,cmt-48-sh73a0" for the SH73A0 48-bit CMT
> +   (CMT1)

I'd split the above in original and gen2.

Perhaps you can also add blank lines in between the 4 blocks of
types; the list is getting long?

Apart from the minor issues above
Acked-by: Geert Uytterhoeven 
(for the whole series)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv10 2/2] arm: dts: Add Altera SDRAM EDAC bindings & devicetree entries.

[Borislav Petkov]

On Tue, Aug 26, 2014 at 03:28:10PM -0500, Dinh Nguyen wrote:
> If Boris is okay with driver part and everyone else is OK with the DTS
> portion, then I can apply the DTS patch to my tree, and Boris take the
> driver patch into his tree?

Actually, it would be easier for everyone involved if those patches go
together due to their dependency. So if you want me to take a look at
the EDAC parts again and give you my ack so that you can pick them all
up together and they go through your tree, let me know.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 6/6] devicetree: bindings: Document Renesas JPEG Processing Unit.

[Simon Horman]

On Wed, Aug 27, 2014 at 08:06:10AM +0200, Laurent Pinchart wrote:
> On Wednesday 27 August 2014 14:15:01 Simon Horman wrote:
> > On Tue, Aug 26, 2014 at 11:27:43AM +0200, Geert Uytterhoeven wrote:
> > > On Tue, Aug 26, 2014 at 11:01 AM, Simon Horman  wrote:
> > >> On Tue, Aug 26, 2014 at 10:03:34AM +0200, Geert Uytterhoeven wrote:
> > >>> On Tue, Aug 26, 2014 at 1:57 AM, Simon Horman wrote:
> >  On Mon, Aug 25, 2014 at 02:59:46PM +0200, Geert Uytterhoeven wrote:
> > > On Mon, Aug 25, 2014 at 2:35 PM, Mikhail Ulyanov wrote:
> > >> +  - compatible: should containg one of the following:
> > >> +   - "renesas,jpu-r8a7790" for R-Car H2
> > >> +   - "renesas,jpu-r8a7791" for R-Car M2
> > >> +   - "renesas,jpu-gen2" for R-Car second
> > >> generation
> > > 
> > > Isn't "renesas,jpu-gen2" meant as a fallback?
> > > 
> > > I.e. the DTS should have one of '7790 and '7791, AND the gen2
> > > fallback, so we can make the driver match against '7790 and '7791 is
> > > we find out about an incompatibility.
> >  
> >  Is there a document that clearly states that there is such a thing
> >  as jpu-gen2 in hardware? If not I would prefer not to add a binding
> >  for it.
> > >>> 
> > >>> We do have a document that describes the "JPEG Processing Unit (JPU)",
> > >>> as found in the following members of the "Second Generation R-Car
> > >>> Series Products": "R-Car H2", "R-Car M2-W", "R-Car M2-N", and "R-Car
> > >>> V2H".
> > >> 
> > >> Oh, that is nice :)
> > >> 
> > >> From my point of view that ticks a lot of boxes.
> > >> But I wonder if we can come up with a better name than jpu,-gen2.
> > > 
> > > "jpu-rcar-gen2"?
> > 
> > I guess that is a slight improvement.
> > 
> > But suppose some gen2 SoC exists or comes to exists that
> > has different IP. Suppose there is more than one that same
> > the same IP that is different to the SoCs covered by the
> > existing compat string?
> 
> That's exactly the information we need to request from the hardware team :-)

Agreed.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 6/6] devicetree: bindings: Document Renesas JPEG Processing Unit.

[Laurent Pinchart]

On Wednesday 27 August 2014 14:15:01 Simon Horman wrote:
> On Tue, Aug 26, 2014 at 11:27:43AM +0200, Geert Uytterhoeven wrote:
> > On Tue, Aug 26, 2014 at 11:01 AM, Simon Horman  wrote:
> >> On Tue, Aug 26, 2014 at 10:03:34AM +0200, Geert Uytterhoeven wrote:
> >>> On Tue, Aug 26, 2014 at 1:57 AM, Simon Horman wrote:
>  On Mon, Aug 25, 2014 at 02:59:46PM +0200, Geert Uytterhoeven wrote:
> > On Mon, Aug 25, 2014 at 2:35 PM, Mikhail Ulyanov wrote:
> >> +  - compatible: should containg one of the following:
> >> +   - "renesas,jpu-r8a7790" for R-Car H2
> >> +   - "renesas,jpu-r8a7791" for R-Car M2
> >> +   - "renesas,jpu-gen2" for R-Car second
> >> generation
> > 
> > Isn't "renesas,jpu-gen2" meant as a fallback?
> > 
> > I.e. the DTS should have one of '7790 and '7791, AND the gen2
> > fallback, so we can make the driver match against '7790 and '7791 is
> > we find out about an incompatibility.
>  
>  Is there a document that clearly states that there is such a thing
>  as jpu-gen2 in hardware? If not I would prefer not to add a binding
>  for it.
> >>> 
> >>> We do have a document that describes the "JPEG Processing Unit (JPU)",
> >>> as found in the following members of the "Second Generation R-Car
> >>> Series Products": "R-Car H2", "R-Car M2-W", "R-Car M2-N", and "R-Car
> >>> V2H".
> >> 
> >> Oh, that is nice :)
> >> 
> >> From my point of view that ticks a lot of boxes.
> >> But I wonder if we can come up with a better name than jpu,-gen2.
> > 
> > "jpu-rcar-gen2"?
> 
> I guess that is a slight improvement.
> 
> But suppose some gen2 SoC exists or comes to exists that
> has different IP. Suppose there is more than one that same
> the same IP that is different to the SoCs covered by the
> existing compat string?

That's exactly the information we need to request from the hardware team :-)

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/5] of: Add NVIDIA Tegra Legacy Interrupt Controller binding

[Thierry Reding]

On Tue, Aug 26, 2014 at 11:59:13AM -0600, Stephen Warren wrote:
> On 08/26/2014 12:41 AM, Thierry Reding wrote:
> >From: Thierry Reding 
> >
> >The Legacy Interrupt Controller found on NVIDIA Tegra SoCs is used by
> >the AVP coprocessor and can also serve as a backup for the ARM Cortex
> >CPU's local interrupt controller (GIC).
> >
> >The LIC is subdivided into multiple identical units, each handling 32
> >possible interrupt sources.
> 
> If I apply this series without patch 2, which is necessary to test the
> support for compatibility with old DTs, then I get the following very early
> on in boot:
> 
> Other than that, I would apply this.

Ugh... this is because before patch 3 the code would always initialize
all five controllers, even on Tegra20 where it doesn't exist. Patch 3
adds a check for that based on the chip ID, which due to other patches
merged for v3.17 isn't available at this point. One solution would be
for this to be moved into an initcall to make sure it's called after
initialization of the fuse driver so that tegra_get_chip_id() can read
the chip ID. But since you're not at all a fan of that I guess the best
we can do is to match on the top-level machine compatible instead of
using the chip ID.

Thierry


pgpMaDYBQ1IZT.pgp
Description: PGP signature

Re: [RFC 2/7] bcm47xx-nvram: add new broadcom nvram driver with dt support

[Rafał Miłecki]

On 24 August 2014 23:24, Hauke Mehrtens  wrote:
> +On NorthStar ARM SoCs the NAND flash is available at 0x1c00 and the
> +NOR flash is at 0x1e00
> +
> +Example:
> +
> +nvram0: nvram@0 {
> +   compatible = "brcm,bcm47xx-nvram";
> +   reg = <0x1c00 0x0100>;
> +};

Could we avoid that? Type of flash can easily be checked in the code.
All we need to do is to read BCMA_IOST register of BCMA_CORE_NS_ROM
core.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] Documentation: dts: fsl-usb: Document USB node compatible string for IP version

[Ramneek Mehresh]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, August 27, 2014 4:23 AM
> To: Mehresh Ramneek-B31383
> Cc: Badola Nikhil-B46172; linuxppc-...@lists.ozlabs.org;
> devicetree@vger.kernel.org
> Subject: Re: [PATCH] Documentation: dts: fsl-usb: Document USB node
> compatible string for IP version
> 
> On Fri, 2014-08-22 at 00:05 -0500, Mehresh Ramneek-B31383 wrote:
> >
> > -Original Message-
> > From: Badola Nikhil-B46172
> > Sent: Friday, August 22, 2014 10:18 AM
> > To: Wood Scott-B07421
> > Cc: linuxppc-...@lists.ozlabs.org; devicetree@vger.kernel.org; Mehresh
> > Ramneek-B31383
> > Subject: RE: [PATCH] Documentation: dts: fsl-usb: Document USB node
> > compatible string for IP version
> >
> > Adding Ramneek
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Friday, August 22, 2014 3:53 AM
> > > To: Badola Nikhil-B46172
> > > Cc: linuxppc-...@lists.ozlabs.org; devicetree@vger.kernel.org
> > > Subject: Re: [PATCH] Documentation: dts: fsl-usb: Document USB node
> > > compatible string for IP version
> > >
> > > On Thu, 2014-08-21 at 14:48 +0530, Nikhil Badola wrote:
> > > > Document compatible string containing IP version in USB device
> > > > tree node
> > > >
> > > > Signed-off-by: Nikhil Badola 
> > > > ---
> > > >  Documentation/devicetree/bindings/usb/fsl-usb.txt | 13
> > > > -
> > > >  1 file changed, 8 insertions(+), 5 deletions(-)
> > >
> > > Please CC devicetree@vger.kernel.org on all device tree patches (in
> > > addition to linuxppc-dev).
> > >
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/usb/fsl-usb.txt
> > > > b/Documentation/devicetree/bindings/usb/fsl-usb.txt
> > > > index 4779c02..5a3a0a8 100644
> > > > --- a/Documentation/devicetree/bindings/usb/fsl-usb.txt
> > > > +++ b/Documentation/devicetree/bindings/usb/fsl-usb.txt
> > > > @@ -10,7 +10,10 @@ Required properties :
> > > > controllers, or "fsl-usb2-dr" for dual role USB controllers
> > > > or "fsl,mpc5121-usb2-dr" for dual role USB controllers of MPC5121.
> > > > Wherever applicable, the IP version of the USB controller should
> > > > -   also be mentioned (for eg. fsl-usb2-dr-v2.2 for bsc9132).
> > > > +   also be mentioned in another string.
> > > > +   For multi port host USB controller with IP version , it 
> > > > should
> be
> > > > +   "fsl-usb2-mph-". For dual role USB controller with IP 
> > > > version
> > > > +   , it should be "fsl-usb2-dr-".
> > >
> > > It was documented before -- this is just making it more explicit, right?
> > >
> > > FWIW, the version number can be read out of a USB register, so I'd
> > > rather remove the suggestion to specify the version number and
> > > replace it with a reference to the ID register.
> > we have following two issues -
> > (a) our USBIP version register doesn't have consistent "version field
> > size" over multiple version(s). This is why we couldn't use it for
> > reading version info across various IP versions
> > (b) this register is not exposed in all SoC RMs (probably because of
> > above reason)
> 
> :-(
> 
> If this is just a problem with older chips, we could have a new compatible 
> name
> that designates the family of USB block versions with a sane version register.
> 
we could have done...but we have a requirement to write version specific code...
for instance, usb controller init sequence has changes from version 2.5 
onwards...
then there are version specific errata fixe(s) also. Hence we decided to go for
compatible string containing hw ip version (major no.) so that our 
workaround/code is
consistent with hw ip version(s) published in errata(s)
 
> > > > @@ -55,9 +58,9 @@ Example multi port host USB controller device node :
> > > > port1;
> > > > };
> > > >
> > > > -Example dual role USB controller device node :
> > > > +Example dual role USB controller version 2.5 device node :
> > > > usb@23000 {
> > > > -   compatible = "fsl-usb2-dr";
> > > > +   compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
> > > > reg = <23000 1000>;
> > > > #address-cells = <1>;
> > > > #size-cells = <0>;
> > >
> > > This example doesn't correspond to any device tree I see.  Even
> > > after your next patch that sets t2080's USB to v2.5, the addresses are
> different.
> > >
> > I reckon that the example emphasizes on showing how IP version
> > information is to be stored in "compatible string". Is it necessary to
> > make sure that we should always site actual values already used?
> 
> The more realistic the examples are, the better.
> 
understood...we agree 

> -Scott
> 

N�r��yb�X��ǧv�^�)޺{.n�+���z��z��z)w*jg����ݢj/���z�ޖ��2�ޙ&�)ߡ�a�����G���h��j:+v���w��٥

RE: [PATCH 1/9] ACPI / PM: Let acpi_dev_pm_detach() return an error code

[Zheng, Lv]

Hi,

> From: linux-acpi-ow...@vger.kernel.org 
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Ulf Hansson
> Sent: Tuesday, August 26, 2014 8:07 PM
> To: Rafael J. Wysocki; Brown, Len; Pavel Machek; Greg Kroah-Hartman; 
> linux...@vger.kernel.org
> 
> To give callers the option of acting on a errors while removing the
> pm_domain ops for the device in the ACPI power domain, let
> acpi_dev_pm_detach() return an int to provide the error code.
> 
> Signed-off-by: Ulf Hansson 
> ---
>  drivers/acpi/device_pm.c | 4 
>  include/linux/acpi.h | 7 +--
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
> index 67075f8..fa78abb 100644
> --- a/drivers/acpi/device_pm.c
> +++ b/drivers/acpi/device_pm.c
> @@ -1087,6 +1087,8 @@ EXPORT_SYMBOL_GPL(acpi_dev_pm_attach);
>   *
>   * Callers must ensure proper synchronization of this function with power
>   * management callbacks.
> + *
> + * Returns 0 on successfully detached power domain or negative error code.
>   */
>  void acpi_dev_pm_detach(struct device *dev, bool power_off)

Should the return type be "int" here?

Thanks and best regards
-Lv

>  {
> @@ -1107,7 +1109,9 @@ void acpi_dev_pm_detach(struct device *dev, bool 
> power_off)
>   acpi_device_wakeup(adev, ACPI_STATE_S0, false);
>   acpi_dev_pm_low_power(dev, adev, ACPI_STATE_S0);
>   }
> + return 0;
>   }
> + return -ENODEV;
>  }
>  EXPORT_SYMBOL_GPL(acpi_dev_pm_detach);
>  #endif /* CONFIG_PM */
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 5320153..a7bfdf6 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -576,7 +576,7 @@ static inline int acpi_subsys_freeze(struct device *dev) 
> { return 0; }
>  #if defined(CONFIG_ACPI) && defined(CONFIG_PM)
>  struct acpi_device *acpi_dev_pm_get_node(struct device *dev);
>  int acpi_dev_pm_attach(struct device *dev, bool power_on);
> -void acpi_dev_pm_detach(struct device *dev, bool power_off);
> +int acpi_dev_pm_detach(struct device *dev, bool power_off);
>  #else
>  static inline struct acpi_device *acpi_dev_pm_get_node(struct device *dev)
>  {
> @@ -586,7 +586,10 @@ static inline int acpi_dev_pm_attach(struct device *dev, 
> bool power_on)
>  {
>   return -ENODEV;
>  }
> -static inline void acpi_dev_pm_detach(struct device *dev, bool power_off) {}
> +static inline int acpi_dev_pm_detach(struct device *dev, bool power_off)
> +{
> + return -ENODEV;
> +}
>  #endif
> 
>  #ifdef CONFIG_ACPI
> --
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3 repost] clocksource: Document Renesas SoC specific bindings

[Simon Horman]

[Repost with correct deviceetree email address]

In general Renesas hardware is not documented to the extent where the
relationship between IP blocks on different SoCs can be assumed although
they may appear to operate the same way. Furthermore the documentation
typically does not specify a version for individual IP blocks. For these
reasons a convention of using the SoC name in place of a version and
providing SoC-specific compat strings has been adopted.

Although not universally liked this convention is used in the bindings for
the drivers a number of drivers for Renesas hardware. The purpose of this
patch is to update the Renesas clocksource drivers to follow this convention.

I plan to follow up with patches to use these new bindings in the
dtsi files for the affected SoCs.

Simon Horman (3):
  clocksource: sh_cmt: Document SoC specific bindings
  clocksource: sh_mtu2: Document r7s72100 binding
  clocksource: sh_tmu: Document r8a7779 binding

 .../devicetree/bindings/timer/renesas,cmt.txt  | 26 +-
 .../devicetree/bindings/timer/renesas,mtu2.txt |  6 +++--
 .../devicetree/bindings/timer/renesas,tmu.txt  |  6 +++--
 3 files changed, 33 insertions(+), 5 deletions(-)

-- 
2.0.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3 repost] clocksource: sh_mtu2: Document r7s72100 binding

[Simon Horman]

In general Renesas hardware is not documented to the extent
where the relationship between IP blocks on different SoCs can be assumed
although they may appear to operate the same way. Furthermore the
documentation typically does not specify a version for individual
IP blocks. For these reasons a convention of using the SoC name in place
of a version and providing SoC-specific compat strings has been adopted.

Although not universally liked this convention is used in the bindings
for the drivers a number of drivers for Renesas hardware. The purpose
of this patch is to update the Renesas R-Car Multi-Function Timer Pulse
Unit 2 (MTU2) driver to follow this convention.

Signed-off-by: Simon Horman 

---
* I plan to follow up with a patch patch to use the new binding in the
  dtsi files for the r7s72100 SoC.
---
 Documentation/devicetree/bindings/timer/renesas,mtu2.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/timer/renesas,mtu2.txt 
b/Documentation/devicetree/bindings/timer/renesas,mtu2.txt
index 917453f..ec4d334 100644
--- a/Documentation/devicetree/bindings/timer/renesas,mtu2.txt
+++ b/Documentation/devicetree/bindings/timer/renesas,mtu2.txt
@@ -8,7 +8,9 @@ are independent. The MTU2 hardware supports five channels 
indexed from 0 to 4.
 
 Required Properties:
 
-  - compatible: must contain "renesas,mtu2"
+  - compatible: must be one of the following.
+- "renesas,mtu2" for generic MTU2
+- "renesas,mtu2-r7s72100" for R7S72100 MTU2
 
   - reg: base address and length of the registers block for the timer module.
 
@@ -26,7 +28,7 @@ Required Properties:
 Example: R7S72100 (RZ/A1H) MTU2 node
 
mtu2: timer@fcff {
-   compatible = "renesas,mtu2";
+   compatible = "renesas,mtu2-r7s72100", "renesas,mtu2";
reg = <0xfcff 0x400>;
interrupts = <0 139 IRQ_TYPE_LEVEL_HIGH>,
 <0 146 IRQ_TYPE_LEVEL_HIGH>,
-- 
2.0.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3 repost] clocksource: sh_cmt: Document SoC specific bindings

[Simon Horman]

In general Renesas hardware is not documented to the extent
where the relationship between IP blocks on different SoCs can be assumed
although they may appear to operate the same way. Furthermore the
documentation typically does not specify a version for individual
IP blocks. For these reasons a convention of using the SoC name in place
of a version and providing SoC-specific compat strings has been adopted.

Although not universally liked this convention is used in the bindings
for the drivers a number of drivers for Renesas hardware. The purpose
of this patch is to update the Renesas R-Car Compare Match Timer (CMT)
driver to follow this convention.

Signed-off-by: Simon Horman 

---
* I plan to follow up with patches to use these new bindings in the
  dtsi files for the affected SoCs.
---
 .../devicetree/bindings/timer/renesas,cmt.txt  | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt 
b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
index a17418b..500bad2 100644
--- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
+++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
@@ -16,10 +16,34 @@ Required Properties:
(CMT0 on sh7372, sh73a0 and r8a7740)
 - "renesas,cmt-32-fast" for the 32-bit CMT with fast clock support
(CMT[234] on sh7372, sh73a0 and r8a7740)
+- "renesas,cmt-32-fast-r8a7740" for the R8A7740 32-bit CMT with fast
+   clock support (CMT[234])
+- "renesas,cmt-32-fast-sh7372" for the SH7372 32-bit CMT with fast
+   clock support (CMT[234])
+- "renesas,cmt-32-fast-sh73a0" for the SH73A0 32-bit CMT with fast
+   clock support (CMT[234])
+- "renesas,cmt-32-r8a7740" for the R8a7740 32-bit CMT
+   (CMT0)
+- "renesas,cmt-32-sh7372" for the SH7372 32-bit CMT
+   (CMT0)
+- "renesas,cmt-32-sh73a0" for the SH73a0 32-bit CMT
+   (CMT0)
 - "renesas,cmt-48" for the 48-bit CMT
(CMT1 on sh7372, sh73a0 and r8a7740)
 - "renesas,cmt-48-gen2" for the second generation 48-bit CMT
(CMT[01] on r8a73a4, r8a7790 and r8a7791)
+- "renesas,cmt-48-r8a73a4" for the R8A73A4 48-bit CMT
+   (CMT[01])
+- "renesas,cmt-48-r8a7740" for the R8A7740 48-bit CMT
+   (CMT1)
+- "renesas,cmt-48-r8a7790" for the R8A7790 48-bit CMT
+   (CMT[01])
+- "renesas,cmt-48-r8a7791" for the R8A7791 48-bit CMT
+   (CMT[01])
+- "renesas,cmt-48-sh7372" for the SH7372 48-bit CMT
+   (CMT1)
+- "renesas,cmt-48-sh73a0" for the SH73A0 48-bit CMT
+   (CMT1)
 
   - reg: base address and length of the registers block for the timer module.
   - interrupts: interrupt-specifier for the timer, one per channel.
@@ -36,7 +60,7 @@ Example: R8A7790 (R-Car H2) CMT0 node
them channels 0 and 1 in the documentation.
 
cmt0: timer@ffca {
-   compatible = "renesas,cmt-48-gen2";
+   compatible = "renesas,cmt-48-r8a7790", "renesas,cmt-48-gen2";
reg = <0 0xffca 0 0x1004>;
interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>,
 <0 142 IRQ_TYPE_LEVEL_HIGH>;
-- 
2.0.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3 repost] clocksource: sh_tmu: Document r8a7779 binding

[Simon Horman]

In general Renesas hardware is not documented to the extent
where the relationship between IP blocks on different SoCs can be assumed
although they may appear to operate the same way. Furthermore the
documentation typically does not specify a version for individual
IP blocks. For these reasons a convention of using the SoC name in place
of a version and providing SoC-specific compat strings has been adopted.

Although not universally liked this convention is used in the bindings
for the drivers a number of drivers for Renesas hardware. The purpose
of this patch is to update the Renesas R-Car Timer Unit (TMU)
driver to follow this convention.

Signed-off-by: Simon Horman 

---
* I plan to follow up with a patch patch to use the new binding in the
  dtsi files for the r8a7779 SoC.
---
 Documentation/devicetree/bindings/timer/renesas,tmu.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.txt 
b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
index 425d0c5..712ddfa 100644
--- a/Documentation/devicetree/bindings/timer/renesas,tmu.txt
+++ b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
@@ -8,7 +8,9 @@ are independent. The TMU hardware supports up to three channels.
 
 Required Properties:
 
-  - compatible: must contain "renesas,tmu"
+  - compatible: must contain one of the following.
+- "renesas,tmu" generic TMU
+- "renesas,tmu-r8a7779" R8A7779 TMU
 
   - reg: base address and length of the registers block for the timer module.
 
@@ -27,7 +29,7 @@ Optional Properties:
 Example: R8A7779 (R-Car H1) TMU0 node
 
tmu0: timer@ffd8 {
-   compatible = "renesas,tmu";
+   compatible = "renesas,tmu-r8a7779", "renesas,tmu";
reg = <0xffd8 0x30>;
interrupts = <0 32 IRQ_TYPE_LEVEL_HIGH>,
 <0 33 IRQ_TYPE_LEVEL_HIGH>,
-- 
2.0.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 6/6] devicetree: bindings: Document Renesas JPEG Processing Unit.

[Simon Horman]

On Tue, Aug 26, 2014 at 11:27:43AM +0200, Geert Uytterhoeven wrote:
> On Tue, Aug 26, 2014 at 11:01 AM, Simon Horman  wrote:
> > On Tue, Aug 26, 2014 at 10:03:34AM +0200, Geert Uytterhoeven wrote:
> >> On Tue, Aug 26, 2014 at 1:57 AM, Simon Horman  wrote:
> >> > On Mon, Aug 25, 2014 at 02:59:46PM +0200, Geert Uytterhoeven wrote:
> >> >> On Mon, Aug 25, 2014 at 2:35 PM, Mikhail Ulyanov
> >> >>  wrote:
> >> >> > +  - compatible: should containg one of the following:
> >> >> > +   - "renesas,jpu-r8a7790" for R-Car H2
> >> >> > +   - "renesas,jpu-r8a7791" for R-Car M2
> >> >> > +   - "renesas,jpu-gen2" for R-Car second 
> >> >> > generation
> >> >>
> >> >> Isn't "renesas,jpu-gen2" meant as a fallback?
> >> >>
> >> >> I.e. the DTS should have one of '7790 and '7791, AND the gen2 fallback,
> >> >> so we can make the driver match against '7790 and '7791 is we find
> >> >> out about an incompatibility.
> >> >
> >> > Is there a document that clearly states that there is such a thing
> >> > as jpu-gen2 in hardware? If not I would prefer not to add a binding for 
> >> > it.
> >>
> >> We do have a document that describes the "JPEG Processing Unit (JPU)",
> >> as found in the following members of the "Second Generation R-Car Series
> >> Products": "R-Car H2", "R-Car M2-W", "R-Car M2-N", and "R-Car V2H".
> >
> > Oh, that is nice :)
> >
> > From my point of view that ticks a lot of boxes.
> > But I wonder if we can come up with a better name than jpu,-gen2.
> 
> "jpu-rcar-gen2"?

I guess that is a slight improvement.

But suppose some gen2 SoC exists or comes to exists that
has different IP. Suppose there is more than one that same
the same IP that is different to the SoCs covered by the
existing compat string?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] Adding Skyworks SKY81452 MFD driver

[Gyungoh Yoo]

On Tue, Aug 26, 2014 at 09:22:58AM +0100, Lee Jones wrote:
> On Mon, 25 Aug 2014, Gyungoh Yoo wrote:
> > On Thu, Aug 21, 2014 at 10:45:02AM +0100, Lee Jones wrote:
> > > When you send patch-sets, you should send them connected to one
> > > another AKA threaded.  That way, when we're reviewing we can look at
> > > the other patches in the set for reference.  See the man page for `git
> > > send-email` for details.
> > > 
> > > 
> > > 
> > > > Signed-off-by: Gyungoh Yoo 
> > > > ---
> 
> [...]
> 
> > > > +static int sky81452_register_devices(struct device *dev,
> > > > +   const struct sky81452_platform_data *pdata)
> > > > +{
> > > > +   struct mfd_cell cells[] = {
> > > > +   {
> > > > +   .name = "sky81452-bl",
> > > > +   .platform_data = pdata->bl_pdata,
> > > > +   .pdata_size = sizeof(*pdata->bl_pdata),
> > > 
> > > Have you tested this with DT?
> > > 
> > > You're not passing the compatible string and not using
> > > of_platform_populate() so I'm struggling to see how it would work
> > > properly.
> > 
> > sky81452-bl and regulator-sky81452 is parsing the information
> > in regulator node of its parent node. So I thought these 2 drivers
> > don't need compatible attribute. That is what it didn't have
> > compatible string.
> > Is is mandatory that all drivers should have compatible attribute?
> 
> How do they obtain their DT nodes?

The backlight driver which is one of the child driver is obtain its DT node 
like this

np = of_get_child_by_name(dev->parent->of_node, "backlight");

> 
> [...]
> 
> > > > +   return mfd_add_devices(dev, -1, cells, ARRAY_SIZE(cells),
> > > > +   NULL, 0, NULL);
> > > 
> > > This doesn't really need to be in a function of its own.  Please put
> > > it in .probe().  Also check for the return value and present the user
> > > with an error message if it fails.
> > 
> > I think this need to be, in case of !CONFIG_OF.
> > Can you please explain more in details?
> 
> Then how to you obtain the shared register map you created?

regmap is stored in driver data in MFD.

i2c_set_clientdata(client, regmap);

The child drivers obain the regmap from the parent.

struct regmap *regmap = dev_get_drvdata(dev->parent);

> 
> [...]
> 
> -- 
> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 8/8] ASoC: add snd-soc-dummy DT support

[Kuninori Morimoto]

Hi Mark again

> But, How about this case ?
> 
>FE cpu:   CPU-A
>   codec: Codec-A
> 
>BE cpu:   CPU-B
>   codec: Codec-B

I found 1 method.
I can create it if we can assume that
"simple-card doen't support above style",

> If the documentation refers to the interface as for example "I2S0" then
> the DT should refer to it as I2S0 too.

simple-card is using "format" property now,
and I remember that someone want to exchange format in DPCM.

My 1st DPCM patch used "remote" property for specify FE/BE.
And, we can get DAI stream_name if we can update snd_soc_of_get_dai_name()
This means, we can use DPCM like below
if you can accept my previous "ASoC: dapm: enable DAI name on DAPM route"
What do you think ?

sound {
compatible = "simple-audio-card";

/* FrontEnd */
simple-audio-card,dai-link@0 {
...
format = "left_j";
remote = <&endpoint>;

cpu {
sound-dai = <&rcar_sound 0>;
};
codec { /* dummy */ };
};

/* BackEnd */
endpoint: simple-audio-card,dai-link@1 {
...
format = "left_j";

cpu { /* dummy */ };
codec1: codec {
sound-dai = <&ak4643>;
};
};
};

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv10 0/5] ARM: remove the sub-node and deprecate supports-highspeed property for dwmmc.

[Jaehoon Chung]

Hi,

On 08/26/2014 07:19 PM, Pavel Machek wrote:
> Hi!
> 
 Would you elaborate?

 If I have a device like a phone, I may want to put one "slot" inside
 phone for basic system, and offer second slot for user expansion
 (initially empty).
>>>
>>> if multiple slot is supported, then a mmcqd should be processing for 
>>> multiple slots.
>>> It's too inefficient, and affect the whole performance reduction.
>> Sorry, Discard this comment. it means dwmci, not mmcqd.
> 
> Well, that's a Linux problem, and for many applications, not even
> problem at all.
> 
> Device tree should describe hardware, and hardware can do multiple
> slots per controller, so device tree should describe multiple slots
> per controller.
> 
> Now, the configuration may be uncommon, but you are moving from good
> hardware description to bad hardware description.

Well, i don't think it's bad hardware description. And this policy is suggested 
by other mmc developers and maintainers.
At first time, I had also suggested same opinion with yours.
Refer to below..

https://patchwork.kernel.org/patch/4276481/

Best Regards,
Jaehoon Chung
> 
>   Pavel
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/1] power: Add simple gpio-restart driver

[Guenter Roeck]

On 08/26/2014 04:45 PM, David Riley wrote:

This driver registers a restart handler to set a GPIO line high/low
to reset a board based on devicetree bindings.

Signed-off-by: David Riley 
---
  .../devicetree/bindings/gpio/gpio-restart.txt  |  48 +++
  drivers/power/reset/Kconfig|   8 ++
  drivers/power/reset/Makefile   |   1 +
  drivers/power/reset/gpio-restart.c | 142 +
  4 files changed, 199 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-restart.txt
  create mode 100644 drivers/power/reset/gpio-restart.c

diff --git a/Documentation/devicetree/bindings/gpio/gpio-restart.txt 
b/Documentation/devicetree/bindings/gpio/gpio-restart.txt
new file mode 100644
index 000..7cd58788
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-restart.txt
@@ -0,0 +1,48 @@
+Driver a GPIO line that can be used to restart the system as a
+restart handler.
+
+The driver supports both level triggered and edge triggered power off.
+At driver load time, the driver will request the given gpio line and
+install a restart handler. If the optional properties 'input' is
+not found, the GPIO line will be driven in the inactive state.
+Otherwise its configured as an input.
+
+When do_kernel_restart is called the various restart handlers will be tried
+in order.  The gpio is configured as an output, and drive active, so
+triggering a level triggered power off condition. This will also cause an
+inactive->active edge condition, so triggering positive edge triggered
+power off. After a delay of 100ms, the GPIO is set to inactive, thus
+causing an active->inactive edge, triggering negative edge triggered power
+off. After another 100ms delay the GPIO is driver active again. If the
+power is still on and the CPU still running after a 3000ms delay, a
+WARN_ON(1) is emitted.
+
+Required properties:
+- compatible : should be "gpio-restart".
+- gpios : The GPIO to set high/low, see "gpios property" in
+  Documentation/devicetree/bindings/gpio/gpio.txt. If the pin should be
+  low to power down the board set it to "Active Low", otherwise set
+  gpio to "Active High".
+
+Optional properties:
+- input : Initially configure the GPIO line as an input. Only reconfigure
+  it to an output when the machine_restart function is called. If this optional
+  property is not specified, the GPIO is initialized as an output in its
+  inactive state.


Maybe describe this as open source ?


+- priority : A priority ranging from 0 to 255 (default 128) according to
+  the following guidelines:
+   0:  Restart handler of last resort, with limited restart
+   capabilities
+   128:Default restart handler; use if no other restart handler is
+   expected to be available, and/or if restart functionality is
+   sufficient to restart the entire system
+   255:Highest priority restart handler, will preempt all other
+   restart handlers
+
+Examples:
+
+gpio-restart {
+   compatible = "gpio-restart";
+   gpios = <&gpio 4 0>;
+   priority = /bits/ 8 <200>;
+};
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index ca41523..f07e26c 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -39,6 +39,14 @@ config POWER_RESET_GPIO
  If your board needs a GPIO high/low to power down, say Y and
  create a binding in your devicetree.

+config POWER_RESET_GPIO_RESTART
+   bool "GPIO restart driver"
+   depends on OF_GPIO && POWER_RESET
+   help
+ This driver supports restarting your board via a GPIO line.
+ If your board needs a GPIO high/low to restart, say Y and
+ create a binding in your devicetree.
+
  config POWER_RESET_HISI
bool "Hisilicon power-off driver"
depends on POWER_RESET && ARCH_HISI
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index a42e70e..199cb6e 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_POWER_RESET_AS3722) += as3722-poweroff.o
  obj-$(CONFIG_POWER_RESET_AXXIA) += axxia-reset.o
  obj-$(CONFIG_POWER_RESET_BRCMSTB) += brcmstb-reboot.o
  obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
+obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
  obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
  obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
  obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
diff --git a/drivers/power/reset/gpio-restart.c 
b/drivers/power/reset/gpio-restart.c
new file mode 100644
index 000..2cbff64
--- /dev/null
+++ b/drivers/power/reset/gpio-restart.c
@@ -0,0 +1,142 @@
+/*
+ * Toggles a GPIO pin to restart a device
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * 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,

Re: [PATCH v1 1/1] power: Add simple gpio-restart driver

[Olof Johansson]

Hi,



On Tue, Aug 26, 2014 at 4:45 PM, David Riley  wrote:
> This driver registers a restart handler to set a GPIO line high/low
> to reset a board based on devicetree bindings.
>
> Signed-off-by: David Riley 
> ---
>  .../devicetree/bindings/gpio/gpio-restart.txt  |  48 +++
>  drivers/power/reset/Kconfig|   8 ++
>  drivers/power/reset/Makefile   |   1 +
>  drivers/power/reset/gpio-restart.c | 142 
> +
>  4 files changed, 199 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-restart.txt
>  create mode 100644 drivers/power/reset/gpio-restart.c
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-restart.txt 
> b/Documentation/devicetree/bindings/gpio/gpio-restart.txt
> new file mode 100644
> index 000..7cd58788
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-restart.txt
> @@ -0,0 +1,48 @@
> +Driver a GPIO line that can be used to restart the system as a
> +restart handler.
> +
> +The driver supports both level triggered and edge triggered power off.
> +At driver load time, the driver will request the given gpio line and
> +install a restart handler. If the optional properties 'input' is
> +not found, the GPIO line will be driven in the inactive state.
> +Otherwise its configured as an input.
> +
> +When do_kernel_restart is called the various restart handlers will be tried
> +in order.

The above sentence documents the kernel behavior, not the hardware
description/binding.

> +The gpio is configured as an output, and drive active, so
> +triggering a level triggered power off condition. This will also cause an
> +inactive->active edge condition, so triggering positive edge triggered
> +power off.

> + After a delay of 100ms, the GPIO is set to inactive, thus
> +causing an active->inactive edge, triggering negative edge triggered power
> +off. After another 100ms delay the GPIO is driver active again. If the
> +power is still on and the CPU still running after a 3000ms delay, a
> +WARN_ON(1) is emitted.

It's possible that this behavior is inadequate for some hardware in
the future -- if so they can amend the binding (i.e. this comment is
an attempt at preemptive bikeshed avoidance :)

> +
> +Required properties:
> +- compatible : should be "gpio-restart".
> +- gpios : The GPIO to set high/low, see "gpios property" in
> +  Documentation/devicetree/bindings/gpio/gpio.txt. If the pin should be
> +  low to power down the board set it to "Active Low", otherwise set
> +  gpio to "Active High".
> +
> +Optional properties:
> +- input : Initially configure the GPIO line as an input. Only reconfigure
> +  it to an output when the machine_restart function is called. If this 
> optional
> +  property is not specified, the GPIO is initialized as an output in its
> +  inactive state.

Isn't this the same as configuring the pin as tristate? I think that
should probably be controlled by pinmux setup instead?

> +- priority : A priority ranging from 0 to 255 (default 128) according to
> +  the following guidelines:
> +   0:  Restart handler of last resort, with limited restart
> +   capabilities
> +   128:Default restart handler; use if no other restart handler is
> +   expected to be available, and/or if restart functionality is
> +   sufficient to restart the entire system
> +   255:Highest priority restart handler, will preempt all other
> +   restart handlers

This is sort of leaking linux implementation, but it's also a useful
feature to have in the description. It seems sane enough to me to use.

> +
> +Examples:
> +
> +gpio-restart {
> +   compatible = "gpio-restart";
> +   gpios = <&gpio 4 0>;
> +   priority = /bits/ 8 <200>;

I think it makes sense to just have this as a regular cell instead of
doing an 8-bit value -- it's how we normally handle these elsewhere.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: make arch-timer always on in rk3288 soc

[Kever Yang]

We need use the hrtimer, which need the arch-timer to be 'always-on'

Signed-off-by: Kever Yang 
---

 arch/arm/boot/dts/rk3288.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 5950b0a..698e6ea 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -76,6 +76,7 @@
 ,
 ;
clock-frequency = <2400>;
+   always-on;
};
 
i2c1: i2c@ff14 {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/1] power: Add simple gpio-restart driver

[Sebastian Reichel]

Hi David,

On Tue, Aug 26, 2014 at 04:45:05PM -0700, David Riley wrote:
> This driver registers a restart handler to set a GPIO line high/low
> to reset a board based on devicetree bindings.

Driver looks fine to me. I have some comments about the
Documentation, though:

> [...]
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-restart.txt 
> b/Documentation/devicetree/bindings/gpio/gpio-restart.txt
> new file mode 100644
> index 000..7cd58788
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-restart.txt
> @@ -0,0 +1,48 @@
> +Driver a GPIO line that can be used to restart the system as a
> +restart handler.

Please fix the Typo (first word).

> [...]
> +
> +The driver supports both level triggered and edge triggered power off.
> +At driver load time, the driver will request the given gpio line and
> +install a restart handler.

The wording is too driver centric IMHO. You are supposed to document
the binding in a generic way. Maybe start with something like:

"This binding supports level and edge triggered reset."

(power off is the wrong word, since there is already gpio-poweroff).

> +If the optional properties 'input' is +not found, the GPIO line
> +will be driven in the inactive state. Otherwise its configured
> +as an input.

What is this needed for?

> +When do_kernel_restart is called the various restart handlers will be tried
> +in order.  The gpio is configured as an output, and drive active, so
> +triggering a level triggered power off condition. This will also cause an
> +inactive->active edge condition, so triggering positive edge triggered
> +power off. After a delay of 100ms, the GPIO is set to inactive, thus
> +causing an active->inactive edge, triggering negative edge triggered power
> +off. After another 100ms delay the GPIO is driver active again. If the
> +power is still on and the CPU still running after a 3000ms delay, a
> +WARN_ON(1) is emitted.

I really appreciate the description of the driver (it made it easier
to review it :)), but Documentation/devicetree should avoid
Linuxisms. In other words: this is the wrong location for the
description.

> +Required properties:
> +- compatible : should be "gpio-restart".
> +- gpios : The GPIO to set high/low, see "gpios property" in
> +  Documentation/devicetree/bindings/gpio/gpio.txt. If the pin should be
> +  low to power down the board set it to "Active Low", otherwise set
> +  gpio to "Active High".
> +
> +Optional properties:
> +- input : Initially configure the GPIO line as an input. Only reconfigure
> +  it to an output when the machine_restart function is called. If this 
> optional
> +  property is not specified, the GPIO is initialized as an output in its
> +  inactive state.
> +- priority : A priority ranging from 0 to 255 (default 128) according to
> +  the following guidelines:
> + 0:  Restart handler of last resort, with limited restart
> + capabilities
> + 128:Default restart handler; use if no other restart handler is
> + expected to be available, and/or if restart functionality is
> + sufficient to restart the entire system
> + 255:Highest priority restart handler, will preempt all other
> + restart handlers

You should add a short information about the property type here
(e.g. "8 bit integer" for priority).

> +Examples:
> +
> +gpio-restart {
> + compatible = "gpio-restart";
> + gpios = <&gpio 4 0>;
> + priority = /bits/ 8 <200>;
> +};
> [...]

-- Sebastian


signature.asc
Description: Digital signature

Re: [alsa-devel] [PATCH 8/8] ASoC: add snd-soc-dummy DT support

[Kuninori Morimoto]

Hi Mark

> > > > >If we're already specifying the DAI links for the (D)PCM code it seems
> > > > >like we shouldn't also have to put DAPM routes for them in DT as well.
> 
> > > > Yes, and I think we shouldn't use anything except for datahsheet pin 
> > > > names
> > > > in the devicetree routing, because otherwise we are leaking driver
> > > > implementation details.
> 
> > It came from snd_soc_of_parse_audio_routing()
> > Do you mean this function itself is not good ?
> 
> That's intended to be routing analogue pins to each other, not for DAI
> links in DPCM - for DAI links we should be getting this information from
> elsewhere.
> 
> > > While I agree with the sentiment for this when it comes to DAIs we
> > > probably want to use the name the interfaces get in the documentation
> > > rather than pin names since they involve multiple pins working together.
> 
> > Sorry, but what does your "interfaces get in the documentation" mean ?
> 
> If the documentation refers to the interface as for example "I2S0" then
> the DT should refer to it as I2S0 too.

Hmm...
This means we need update DPCM interface ?
In my understanding, DPCM needs DAPM
routing information somehow in final stage.
But, we want to specify it as "DAI link" like interface.

Now, I have many questions.

If my understand is correct, my prev patch is OK for "DAPM final stage",
but we need wrapper for "DPCM interface" ?
It will exchanges "I2S0" to "ak4642 Playback" internally.
(And exchanges format too ?)

Is this needed as "DT interface" ?
Can non-DT code use "ak4642 Playback" directly ?
I'm wondering that some driver is using DPCM already (in non-DT) in upstream.

If we can use "I2S0" interface, it is understandable if FE/BE was

   FE cpu:   CPU-A
  codec: dummy

   BE cpu:   dummy
  codec: Codec-A

But, How about this case ?

   FE cpu:   CPU-A
  codec: Codec-A

   BE cpu:   CPU-B
  codec: Codec-B

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] thermal: rockchip: add driver for thermal

[Dmitry Torokhov]

Hi Caesar,

On Wed, Aug 27, 2014 at 07:41:42AM +0800, Caesar Wang wrote:
> Thermal is TS-ADC Controller module supports user-defined mode and automatic 
> mode.
> 
> User-defined mode refers,TSADC all the control signals entirely by software
> writing to register for direct control.
> 
> Automaic mode refers to the module automatically poll TSADC output,and the 
> results
> Were checked.
> 
> If you find that the temperature High in a period of time, an interrupt is 
> generated
> to the processor down-measures taken;if the temperature over a period of time 
> High,
> the resulting TSHUT gave CRU module,let it reset the entire chip, or via GPIO 
> give PMIC.
> 
> Signed-off-by: zhaoyifeng 
> Signed-off-by: Caesar Wang 
> Change-Id: I00e7df78c497704657aff16e602aa56b4c14c6f5
> ---
>  drivers/thermal/Kconfig|9 +
>  drivers/thermal/Makefile   |1 +
>  drivers/thermal/rockchip_thermal.c |  644 
> 
>  3 files changed, 654 insertions(+)
>  create mode 100644 drivers/thermal/rockchip_thermal.c
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 74226dc..43d2400 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -141,6 +141,15 @@ config SPEAR_THERMAL
> Enable this to plug the SPEAr thermal sensor driver into the Linux
> thermal framework.
>  
> +config ROCKCHIP_THERMAL
> + tristate "Rockchip thermal driver"
> + depends on ARCH_ROCKCHIP
> + help
> +   Support for Temperature Sensor ADC (TS-ADC) found on Rockchip SoCs.
> +   It supports one critical trip point and one passive trip point.  The
> +   cpufreq is used as the cooling device to throttle CPUs when the
> +   passive trip is crossed.
> +
>  config RCAR_THERMAL
>   tristate "Renesas R-Car thermal driver"
>   depends on ARCH_SHMOBILE || COMPILE_TEST
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 419c3cd..009a457 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -20,6 +20,7 @@ thermal_sys-$(CONFIG_CPU_THERMAL)   += cpu_cooling.o
>  
>  # platform thermal drivers
>  obj-$(CONFIG_SPEAR_THERMAL)  += spear_thermal.o
> +obj-$(CONFIG_ROCKCHIP_THERMAL)   += rockchip_thermal.o
>  obj-$(CONFIG_RCAR_THERMAL)   += rcar_thermal.o
>  obj-$(CONFIG_KIRKWOOD_THERMAL)  += kirkwood_thermal.o
>  obj-y+= samsung/
> diff --git a/drivers/thermal/rockchip_thermal.c 
> b/drivers/thermal/rockchip_thermal.c
> new file mode 100644
> index 000..dea4dc3
> --- /dev/null
> +++ b/drivers/thermal/rockchip_thermal.c
> @@ -0,0 +1,644 @@
> +/*
> + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "thermal_core.h"
> +
> +enum rockchip_thermal_trip {
> + ROCKCHIP_TRIP_PASSIVE,
> + ROCKCHIP_TRIP_CRITICAL,
> + ROCKCHIP_TRIP_NUM,
> +};
> +
> +struct rockchip_thermal_data {
> + const struct rockchip_tsadc_platform_data *pdata;
> + struct thermal_zone_device *tz;
> + struct thermal_cooling_device *cdev;
> + enum thermal_device_mode mode;
> + void __iomem *regs;
> +
> + signed long temp_passive;
> + signed long temp_critical;
> + signed long temp_force_shut;
> + signed long alarm_temp;
> + signed long last_temp;
> + bool irq_enabled;
> + int irq;
> + struct clk *tsadc_clk;
> + struct clk *tsadc_pclk;
> +};
> +
> +struct rockchip_tsadc_platform_data {
> + u8 irq_en;
> + signed long temp_passive;
> + signed long temp_critical;
> + signed long temp_force_shut;
> + int passive_delay;
> + int polling_delay;
> +
> + int (*irq_handle)(void __iomem *reg);
> + int (*initialize)(void __iomem *reg, signed long temp_force_shut);
> + int (*control)(void __iomem *reg, bool on);
> + u32 (*code_to_temp)(int temp);
> + u32 (*temp_to_code)(int temp);
> + void (*set_alarm_temp)(void __iomem *regs, signed long temp);
> +};
> +
> +/*TSADC V2 Sensor info define:*/
> +#define TSADCV2_AUTO_CON 0x04
> +#define TSADCV2_INT_EN   0x08
> +#define TSADCV2_INT_PD   0x0c
> +#define TSADCV2_DATA10x24
> +#define TSADCV2_COMP1_INT0x34
> +#define TSADCV2_COMP1_SHUT   0x44
> +#define TSADCV2_AUTO_PE

Re: [PATCH 3/9] PM / Domains: Add APIs to attach/detach a power domain for a device

[Rafael J. Wysocki]

On Tuesday, August 26, 2014 02:07:11 PM Ulf Hansson wrote:
> To maintain scalability let's add common methods to attach and detach
> a power domain for a device, dev_pm_domain_attach|detach().
> 
> Typically dev_pm_domain_attach() shall be invoked from subsystem level
> code at the probe phase to try to attach a device to it's power domain.
> The reversed actions may be done a the remove phase and then by invoking
> dev_pm_domain_detach().
> 
> The supported power domains at this point are the ACPI and the generic
> power domains.
> 
> Signed-off-by: Ulf Hansson 
> ---
>  drivers/base/power/common.c | 58 
> +
>  include/linux/pm.h  | 14 +++
>  2 files changed, 72 insertions(+)
> 
> diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c
> index df2e5ee..f544128 100644
> --- a/drivers/base/power/common.c
> +++ b/drivers/base/power/common.c
> @@ -11,6 +11,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  /**
>   * dev_pm_get_subsys_data - Create or refcount power.subsys_data for device.
> @@ -82,3 +84,59 @@ int dev_pm_put_subsys_data(struct device *dev)
>   return ret;
>  }
>  EXPORT_SYMBOL_GPL(dev_pm_put_subsys_data);
> +
> +/**
> + * dev_pm_domain_attach - Attach a device to it's power domain.
> + * @dev: Device to attach.
> + * @power_on: Used to indicate whether we should power on the device.
> + *
> + * The @dev may only be attached to a single power domain. By iterating 
> through
> + * the available alternatives we try to find a valid domain for the device.
> + *
> + * This function should typically be invoked from subsystem level code during
> + * the probe phase. Especially for those that's hold devices which requires
> + * power management through power domains.
> + *
> + * Callers must ensure proper synchronization of this function with power
> + * management callbacks.
> + *
> + * Returns 0 on successfully attached power domain or negative error code.
> + */
> +int dev_pm_domain_attach(struct device *dev, bool power_on)
> +{
> + int ret;
> +
> + ret = acpi_dev_pm_attach(dev, power_on);
> + if (ret == -EPROBE_DEFER)

This doesn't seem to be possible today.  At least I'm not sure how it can
happen.

> + return ret;
> + else
> + ret = genpd_dev_pm_attach(dev);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(dev_pm_domain_attach);

On a more general note, are you sure that the place where we call
acpi_dev_pm_attach() will always be suitable for calling genpd_dev_pm_attach()?

> +
> +/**
> + * dev_pm_domain_detach - Detach a device from it's power domain.
> + * @dev: Device to attach.
> + * @power_off: Used to indicate whether we should power off the device.
> + *
> + * The @dev may be attached to a power domain. By iterating through the
> + * available alternatives we detach it from it's power domain.
> + *
> + * This functions will reverse the actions from dev_pm_domain_attach() and
> + * thus detach the @dev from it's power domain. Typically it should be 
> invoked
> + * from subsystem level code during the remove phase.
> + *
> + * Callers must ensure proper synchronization of this function with power
> + * management callbacks.
> + *
> + * Returns 0 on successfully detached power domain or negative error code.
> + */
> +int dev_pm_domain_detach(struct device *dev, bool power_off)
> +{
> + if (acpi_dev_pm_detach(dev, power_off))
> + return genpd_dev_pm_detach(dev);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(dev_pm_domain_detach);
> diff --git a/include/linux/pm.h b/include/linux/pm.h
> index 72c0fe0..8176b07 100644
> --- a/include/linux/pm.h
> +++ b/include/linux/pm.h
> @@ -621,6 +621,20 @@ struct dev_pm_domain {
>   struct dev_pm_ops   ops;
>  };
>  
> +#ifdef CONFIG_PM
> +extern int dev_pm_domain_attach(struct device *dev, bool power_on);
> +extern int dev_pm_domain_detach(struct device *dev, bool power_off);
> +#else
> +static inline int dev_pm_domain_attach(struct device *dev, bool power_on)
> +{
> + return -ENODEV;
> +}
> +static inline int dev_pm_domain_detach(struct device *dev, bool power_off)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
>  /*
>   * The PM_EVENT_ messages are also used by drivers implementing the legacy
>   * suspend framework, based on the ->suspend() and ->resume() callbacks 
> common
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] ACPI / PM: Let acpi_dev_pm_detach() return an error code

[Rafael J. Wysocki]

On Tuesday, August 26, 2014 02:07:09 PM Ulf Hansson wrote:
> To give callers the option of acting on a errors while removing the
> pm_domain ops for the device in the ACPI power domain, let
> acpi_dev_pm_detach() return an int to provide the error code.
> 
> Signed-off-by: Ulf Hansson 
> ---
>  drivers/acpi/device_pm.c | 4 
>  include/linux/acpi.h | 7 +--
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
> index 67075f8..fa78abb 100644
> --- a/drivers/acpi/device_pm.c
> +++ b/drivers/acpi/device_pm.c
> @@ -1087,6 +1087,8 @@ EXPORT_SYMBOL_GPL(acpi_dev_pm_attach);
>   *
>   * Callers must ensure proper synchronization of this function with power
>   * management callbacks.
> + *
> + * Returns 0 on successfully detached power domain or negative error code.

"PM domain" here, please, not "power domain".

>   */
>  void acpi_dev_pm_detach(struct device *dev, bool power_off)

It looks like you've never compiled this, have you?

>  {
> @@ -1107,7 +1109,9 @@ void acpi_dev_pm_detach(struct device *dev, bool 
> power_off)
>   acpi_device_wakeup(adev, ACPI_STATE_S0, false);
>   acpi_dev_pm_low_power(dev, adev, ACPI_STATE_S0);
>   }
> + return 0;
>   }
> + return -ENODEV;

-EINVAL perhaps?

>  }
>  EXPORT_SYMBOL_GPL(acpi_dev_pm_detach);
>  #endif /* CONFIG_PM */
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 5320153..a7bfdf6 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -576,7 +576,7 @@ static inline int acpi_subsys_freeze(struct device *dev) 
> { return 0; }
>  #if defined(CONFIG_ACPI) && defined(CONFIG_PM)
>  struct acpi_device *acpi_dev_pm_get_node(struct device *dev);
>  int acpi_dev_pm_attach(struct device *dev, bool power_on);
> -void acpi_dev_pm_detach(struct device *dev, bool power_off);
> +int acpi_dev_pm_detach(struct device *dev, bool power_off);
>  #else
>  static inline struct acpi_device *acpi_dev_pm_get_node(struct device *dev)
>  {
> @@ -586,7 +586,10 @@ static inline int acpi_dev_pm_attach(struct device *dev, 
> bool power_on)
>  {
>   return -ENODEV;
>  }
> -static inline void acpi_dev_pm_detach(struct device *dev, bool power_off) {}
> +static inline int acpi_dev_pm_detach(struct device *dev, bool power_off)
> +{
> + return -ENODEV;
> +}
>  #endif
>  
>  #ifdef CONFIG_ACPI
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 1/1] power: Add simple gpio-restart driver

[David Riley]

This driver registers a restart handler to set a GPIO line high/low
to reset a board based on devicetree bindings.

Signed-off-by: David Riley 
---
 .../devicetree/bindings/gpio/gpio-restart.txt  |  48 +++
 drivers/power/reset/Kconfig|   8 ++
 drivers/power/reset/Makefile   |   1 +
 drivers/power/reset/gpio-restart.c | 142 +
 4 files changed, 199 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-restart.txt
 create mode 100644 drivers/power/reset/gpio-restart.c

diff --git a/Documentation/devicetree/bindings/gpio/gpio-restart.txt 
b/Documentation/devicetree/bindings/gpio/gpio-restart.txt
new file mode 100644
index 000..7cd58788
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-restart.txt
@@ -0,0 +1,48 @@
+Driver a GPIO line that can be used to restart the system as a
+restart handler.
+
+The driver supports both level triggered and edge triggered power off.
+At driver load time, the driver will request the given gpio line and
+install a restart handler. If the optional properties 'input' is
+not found, the GPIO line will be driven in the inactive state.
+Otherwise its configured as an input.
+
+When do_kernel_restart is called the various restart handlers will be tried
+in order.  The gpio is configured as an output, and drive active, so
+triggering a level triggered power off condition. This will also cause an
+inactive->active edge condition, so triggering positive edge triggered
+power off. After a delay of 100ms, the GPIO is set to inactive, thus
+causing an active->inactive edge, triggering negative edge triggered power
+off. After another 100ms delay the GPIO is driver active again. If the
+power is still on and the CPU still running after a 3000ms delay, a
+WARN_ON(1) is emitted.
+
+Required properties:
+- compatible : should be "gpio-restart".
+- gpios : The GPIO to set high/low, see "gpios property" in
+  Documentation/devicetree/bindings/gpio/gpio.txt. If the pin should be
+  low to power down the board set it to "Active Low", otherwise set
+  gpio to "Active High".
+
+Optional properties:
+- input : Initially configure the GPIO line as an input. Only reconfigure
+  it to an output when the machine_restart function is called. If this optional
+  property is not specified, the GPIO is initialized as an output in its
+  inactive state.
+- priority : A priority ranging from 0 to 255 (default 128) according to
+  the following guidelines:
+   0:  Restart handler of last resort, with limited restart
+   capabilities
+   128:Default restart handler; use if no other restart handler is
+   expected to be available, and/or if restart functionality is
+   sufficient to restart the entire system
+   255:Highest priority restart handler, will preempt all other
+   restart handlers
+
+Examples:
+
+gpio-restart {
+   compatible = "gpio-restart";
+   gpios = <&gpio 4 0>;
+   priority = /bits/ 8 <200>;
+};
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index ca41523..f07e26c 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -39,6 +39,14 @@ config POWER_RESET_GPIO
  If your board needs a GPIO high/low to power down, say Y and
  create a binding in your devicetree.
 
+config POWER_RESET_GPIO_RESTART
+   bool "GPIO restart driver"
+   depends on OF_GPIO && POWER_RESET
+   help
+ This driver supports restarting your board via a GPIO line.
+ If your board needs a GPIO high/low to restart, say Y and
+ create a binding in your devicetree.
+
 config POWER_RESET_HISI
bool "Hisilicon power-off driver"
depends on POWER_RESET && ARCH_HISI
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index a42e70e..199cb6e 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_POWER_RESET_AS3722) += as3722-poweroff.o
 obj-$(CONFIG_POWER_RESET_AXXIA) += axxia-reset.o
 obj-$(CONFIG_POWER_RESET_BRCMSTB) += brcmstb-reboot.o
 obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
+obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
 obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
 obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
 obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
diff --git a/drivers/power/reset/gpio-restart.c 
b/drivers/power/reset/gpio-restart.c
new file mode 100644
index 000..2cbff64
--- /dev/null
+++ b/drivers/power/reset/gpio-restart.c
@@ -0,0 +1,142 @@
+/*
+ * Toggles a GPIO pin to restart a device
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * 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 us

[PATCH v1 0/1] gpio-restart restart handler

[David Riley]

This driver builds upon Guenter Roeck's kernel restart handler patchset
to add a driver which registers a GPIO-based restart handler which restarts
the system by toggling a GPIO.

Changes are based off 3.17-rc2 with the following patches from v7 of
Guenter's patchset:
https://patchwork.kernel.org/patch/4746721/
https://patchwork.kernel.org/patch/4746731/
https://patchwork.kernel.org/patch/4747011/
https://patchwork.kernel.org/patch/4746741/
https://patchwork.kernel.org/patch/4746861/

David Riley (1):
  power: Add simple gpio-restart driver

 .../devicetree/bindings/gpio/gpio-restart.txt  |  48 +++
 drivers/power/reset/Kconfig|   8 ++
 drivers/power/reset/Makefile   |   1 +
 drivers/power/reset/gpio-restart.c | 142 +
 4 files changed, 199 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-restart.txt
 create mode 100644 drivers/power/reset/gpio-restart.c

-- 
2.0.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] thermal: rockchip: add driver for thermal

[Caesar Wang]

Thermal is TS-ADC Controller module supports user-defined mode and automatic 
mode.

User-defined mode refers,TSADC all the control signals entirely by software
writing to register for direct control.

Automaic mode refers to the module automatically poll TSADC output,and the 
results
Were checked.

If you find that the temperature High in a period of time, an interrupt is 
generated
to the processor down-measures taken;if the temperature over a period of time 
High,
the resulting TSHUT gave CRU module,let it reset the entire chip, or via GPIO 
give PMIC.

Signed-off-by: zhaoyifeng 
Signed-off-by: Caesar Wang 
Change-Id: I00e7df78c497704657aff16e602aa56b4c14c6f5
---
 drivers/thermal/Kconfig|9 +
 drivers/thermal/Makefile   |1 +
 drivers/thermal/rockchip_thermal.c |  644 
 3 files changed, 654 insertions(+)
 create mode 100644 drivers/thermal/rockchip_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 74226dc..43d2400 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -141,6 +141,15 @@ config SPEAR_THERMAL
  Enable this to plug the SPEAr thermal sensor driver into the Linux
  thermal framework.
 
+config ROCKCHIP_THERMAL
+   tristate "Rockchip thermal driver"
+   depends on ARCH_ROCKCHIP
+   help
+ Support for Temperature Sensor ADC (TS-ADC) found on Rockchip SoCs.
+ It supports one critical trip point and one passive trip point.  The
+ cpufreq is used as the cooling device to throttle CPUs when the
+ passive trip is crossed.
+
 config RCAR_THERMAL
tristate "Renesas R-Car thermal driver"
depends on ARCH_SHMOBILE || COMPILE_TEST
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 419c3cd..009a457 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -20,6 +20,7 @@ thermal_sys-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
 
 # platform thermal drivers
 obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
+obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
 obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
 obj-$(CONFIG_KIRKWOOD_THERMAL)  += kirkwood_thermal.o
 obj-y  += samsung/
diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
new file mode 100644
index 000..dea4dc3
--- /dev/null
+++ b/drivers/thermal/rockchip_thermal.c
@@ -0,0 +1,644 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "thermal_core.h"
+
+enum rockchip_thermal_trip {
+   ROCKCHIP_TRIP_PASSIVE,
+   ROCKCHIP_TRIP_CRITICAL,
+   ROCKCHIP_TRIP_NUM,
+};
+
+struct rockchip_thermal_data {
+   const struct rockchip_tsadc_platform_data *pdata;
+   struct thermal_zone_device *tz;
+   struct thermal_cooling_device *cdev;
+   enum thermal_device_mode mode;
+   void __iomem *regs;
+
+   signed long temp_passive;
+   signed long temp_critical;
+   signed long temp_force_shut;
+   signed long alarm_temp;
+   signed long last_temp;
+   bool irq_enabled;
+   int irq;
+   struct clk *tsadc_clk;
+   struct clk *tsadc_pclk;
+};
+
+struct rockchip_tsadc_platform_data {
+   u8 irq_en;
+   signed long temp_passive;
+   signed long temp_critical;
+   signed long temp_force_shut;
+   int passive_delay;
+   int polling_delay;
+
+   int (*irq_handle)(void __iomem *reg);
+   int (*initialize)(void __iomem *reg, signed long temp_force_shut);
+   int (*control)(void __iomem *reg, bool on);
+   u32 (*code_to_temp)(int temp);
+   u32 (*temp_to_code)(int temp);
+   void (*set_alarm_temp)(void __iomem *regs, signed long temp);
+};
+
+/*TSADC V2 Sensor info define:*/
+#define TSADCV2_AUTO_CON   0x04
+#define TSADCV2_INT_EN 0x08
+#define TSADCV2_INT_PD 0x0c
+#define TSADCV2_DATA1  0x24
+#define TSADCV2_COMP1_INT  0x34
+#define TSADCV2_COMP1_SHUT 0x44
+#define TSADCV2_AUTO_PERIOD0x68
+#define TSADCV2_AUTO_PERIOD_HT 0x6c
+
+#define TSADCV2_AUTO_SRC1_EN   (1 << 5)
+#define TSADCV2_AUTO_EN(1 << 0)
+#define TSADCV2_AUTO_DISABLE   ~(1 << 0)
+#define TSADCV2_AUTO_

[PATCH v2 2/2] dt-bindings: document Rockchip thermal

[Caesar Wang]

This add the necessary binding documentation for the thermal
found on Rockchip SoCs

Signed-off-by: zhaoyifeng 
Signed-off-by: Caesar Wang 

Change-Id: I822eba808c76ab51a5562eb61020a4aed4ff555e
---
 .../bindings/thermal/rockchip-thermal.txt  |   20 
 1 file changed, 20 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/thermal/rockchip-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
new file mode 100644
index 000..ff8db39
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -0,0 +1,20 @@
+* Temperature Sensor ADC (TSADC) on rockchip SoCs
+
+Required properties:
+- compatible : "rockchip,rk3288-tsadc"
+- reg : physical base address of the controller and length of memory mapped
+  region.
+- interrupts : The interrupt number to the cpu. The interrupt specifier format
+  depends on the interrupt controller.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Shall be "tsadc_clk" for the transfer-clock, and "tsadc_pclk" 
for
+the peripheral clock.
+
+Example:
+tsadc: tsadc@ff28 {
+   compatible = "rockchip,rk3288-tsadc";
+   reg = <0xff28 0x100>;
+   interrupts = ;
+   clocks = <&cru SCLK_TSADC>, <&cru PCLK_TSADC>;
+   clock-names = "tsadc_clk", "tsadc_pclk";
+};
-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/2] Rockchip soc theamal driver

[Caesar Wang]

This series adds support for the thermal Found on Rockhip RK32 SoCs.
Tested on RK3288 SDK board.

Changes in v2:
* address comments from Heiko Stubner:
- fix dt-bindings in rockchip-thermal.txt
- remove Author mark 
- rename TSADC_XXX->TSADC_XXX,it eill ready to merge compatible other 
SoCs.
- fix a identation
- remove clk_set_rate(),it's no necessary. 
- fix the SIMPLE_DEV_PM_OPS() function  style.

Caesar Wang (2):
  thermal: rockchip: add driver for thermal
  dt-bindings: document Rockchip thermal

 .../bindings/thermal/rockchip-thermal.txt  |   20 +
 drivers/thermal/Kconfig|9 +
 drivers/thermal/Makefile   |1 +
 drivers/thermal/rockchip_thermal.c |  642 
 4 files changed, 672 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
 create mode 100644 drivers/thermal/rockchip_thermal.c

-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation: dts: fsl-usb: Document USB node compatible string for IP version

[Scott Wood]

On Fri, 2014-08-22 at 00:05 -0500, Mehresh Ramneek-B31383 wrote:
> 
> -Original Message-
> From: Badola Nikhil-B46172 
> Sent: Friday, August 22, 2014 10:18 AM
> To: Wood Scott-B07421
> Cc: linuxppc-...@lists.ozlabs.org; devicetree@vger.kernel.org; Mehresh 
> Ramneek-B31383
> Subject: RE: [PATCH] Documentation: dts: fsl-usb: Document USB node 
> compatible string for IP version
> 
> Adding Ramneek
> 
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Friday, August 22, 2014 3:53 AM
> > To: Badola Nikhil-B46172
> > Cc: linuxppc-...@lists.ozlabs.org; devicetree@vger.kernel.org
> > Subject: Re: [PATCH] Documentation: dts: fsl-usb: Document USB node 
> > compatible string for IP version
> > 
> > On Thu, 2014-08-21 at 14:48 +0530, Nikhil Badola wrote:
> > > Document compatible string containing IP version in USB device tree 
> > > node
> > >
> > > Signed-off-by: Nikhil Badola 
> > > ---
> > >  Documentation/devicetree/bindings/usb/fsl-usb.txt | 13 
> > > -
> > >  1 file changed, 8 insertions(+), 5 deletions(-)
> > 
> > Please CC devicetree@vger.kernel.org on all device tree patches (in 
> > addition to linuxppc-dev).
> > 
> > >
> > > diff --git a/Documentation/devicetree/bindings/usb/fsl-usb.txt
> > > b/Documentation/devicetree/bindings/usb/fsl-usb.txt
> > > index 4779c02..5a3a0a8 100644
> > > --- a/Documentation/devicetree/bindings/usb/fsl-usb.txt
> > > +++ b/Documentation/devicetree/bindings/usb/fsl-usb.txt
> > > @@ -10,7 +10,10 @@ Required properties :
> > > controllers, or "fsl-usb2-dr" for dual role USB controllers
> > > or "fsl,mpc5121-usb2-dr" for dual role USB controllers of MPC5121.
> > > Wherever applicable, the IP version of the USB controller should
> > > -   also be mentioned (for eg. fsl-usb2-dr-v2.2 for bsc9132).
> > > +   also be mentioned in another string.
> > > +   For multi port host USB controller with IP version , it 
> > > should be
> > > +   "fsl-usb2-mph-". For dual role USB controller with IP version
> > > +   , it should be "fsl-usb2-dr-".
> > 
> > It was documented before -- this is just making it more explicit, right?
> > 
> > FWIW, the version number can be read out of a USB register, so I'd 
> > rather remove the suggestion to specify the version number and replace 
> > it with a reference to the ID register.
> we have following two issues -
> (a) our USBIP version register doesn't have consistent "version field size" 
> over 
> multiple version(s). This is why we couldn't use it for reading version info 
> across
> various IP versions
> (b) this register is not exposed in all SoC RMs (probably because of above 
> reason)

:-(

If this is just a problem with older chips, we could have a new
compatible name that designates the family of USB block versions with a
sane version register.

> > > @@ -55,9 +58,9 @@ Example multi port host USB controller device node :
> > >   port1;
> > >   };
> > >
> > > -Example dual role USB controller device node :
> > > +Example dual role USB controller version 2.5 device node :
> > >   usb@23000 {
> > > - compatible = "fsl-usb2-dr";
> > > + compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
> > >   reg = <23000 1000>;
> > >   #address-cells = <1>;
> > >   #size-cells = <0>;
> > 
> > This example doesn't correspond to any device tree I see.  Even after 
> > your next patch that sets t2080's USB to v2.5, the addresses are different.
> > 
> I reckon that the example emphasizes on showing how IP version information is
> to be stored in "compatible string". Is it necessary to make sure that we 
> should 
> always site actual values already used?

The more realistic the examples are, the better.

-Scott


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] doc: dt/bindings: input: Fix drv260x binding document

[Dmitry Torokhov]

On Fri, Aug 22, 2014 at 12:16:41PM -0500, Felipe Balbi wrote:
> On Fri, Aug 22, 2014 at 12:12:19PM -0500, Dan Murphy wrote:
> > Update the drv260x dt binding document:
> > - Change the node name to the devices function not the
> > device name.
> > - Add vbat-supply to the example.
> > - Fix indentation of the example.
> > 
> > Signed-off-by: Dan Murphy 
> 
> Reviewed-by: Felipe Balbi 

Applied, thank you.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] mfd: Add Ricoh RN5T618 PMIC core driver

[Beniamino Galvani]

Ricoh RN5T618 is a power management IC which integrates 3 step-down
DCDC converters, 7 low-dropout regulators, a Li-ion battery charger,
fuel gauge, ADC, GPIOs and a watchdog timer.

This commit adds a MFD core driver to support the I2C communication
with the device.

Signed-off-by: Beniamino Galvani 
---
 drivers/mfd/Kconfig |   11 +++
 drivers/mfd/Makefile|1 +
 drivers/mfd/rn5t618.c   |  129 ++
 include/linux/mfd/rn5t618.h |  210 +++
 4 files changed, 351 insertions(+)
 create mode 100644 drivers/mfd/rn5t618.c
 create mode 100644 include/linux/mfd/rn5t618.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 8d5fad2..fae8c5b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -582,6 +582,17 @@ config MFD_RC5T583
  Additional drivers must be enabled in order to use the
  different functionality of the device.
 
+config MFD_RN5T618
+   bool "Ricoh RN5T5618 PMIC"
+   depends on I2C=y
+   select MFD_CORE
+   select REGMAP_I2C
+   help
+ Say yes here to add support for the Ricoh RN5T618 PMIC. This
+ driver provides common support for accessing the device,
+ additional drivers must be enabled in order to use the
+ functionality of the device.
+
 config MFD_SEC_CORE
bool "SAMSUNG Electronics PMIC Series Support"
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f001487..b945899 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -160,6 +160,7 @@ obj-$(CONFIG_MFD_INTEL_MSIC)+= intel_msic.o
 obj-$(CONFIG_MFD_PALMAS)   += palmas.o
 obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
 obj-$(CONFIG_MFD_RC5T583)  += rc5t583.o rc5t583-irq.o
+obj-$(CONFIG_MFD_RN5T618)  += rn5t618.o
 obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
 obj-$(CONFIG_MFD_SYSCON)   += syscon.o
 obj-$(CONFIG_MFD_LM3533)   += lm3533-core.o lm3533-ctrlbank.o
diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c
new file mode 100644
index 000..72ad118
--- /dev/null
+++ b/drivers/mfd/rn5t618.c
@@ -0,0 +1,129 @@
+/*
+ * MFD core driver for Ricoh RN5T618 PMIC
+ *
+ * Copyright (C) 2014 Beniamino Galvani 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct mfd_cell rn5t618_cells[] = {
+   { .name = "rn5t618-regulator" },
+   { .name = "rn5t618-wdt" },
+};
+
+static bool rn5t618_volatile_reg(struct device *dev, unsigned int reg)
+{
+   switch (reg) {
+   case RN5T618_WATCHDOGCNT:
+   case RN5T618_DCIRQ:
+   case RN5T618_ILIMDATAH ... RN5T618_AIN0DATAL:
+   case RN5T618_IR_ADC1 ... RN5T618_IR_ADC3:
+   case RN5T618_IR_GPR:
+   case RN5T618_IR_GPF:
+   case RN5T618_MON_IOIN:
+   case RN5T618_INTMON:
+   return true;
+   default:
+   return false;
+   }
+}
+
+static const struct regmap_config rn5t618_regmap_config = {
+   .reg_bits   = 8,
+   .val_bits   = 8,
+   .volatile_reg   = rn5t618_volatile_reg,
+   .max_register   = RN5T618_MAX_REG,
+   .cache_type = REGCACHE_RBTREE,
+};
+
+static struct rn5t618 *rn5t618_pm_power_off;
+
+static void rn5t618_power_off(void)
+{
+   /* disable automatic repower-on */
+   regmap_update_bits(rn5t618_pm_power_off->regmap, RN5T618_REPCNT,
+  RN5T618_REPCNT_REPWRON, 0);
+   /* start power-off sequence */
+   regmap_update_bits(rn5t618_pm_power_off->regmap, RN5T618_SLPCNT,
+  RN5T618_SLPCNT_SWPWROFF, RN5T618_SLPCNT_SWPWROFF);
+}
+
+static int rn5t618_i2c_probe(struct i2c_client *i2c,
+const struct i2c_device_id *id)
+{
+   struct rn5t618 *priv;
+   int ret;
+
+   priv = devm_kzalloc(&i2c->dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   i2c_set_clientdata(i2c, priv);
+
+   priv->regmap = devm_regmap_init_i2c(i2c, &rn5t618_regmap_config);
+   if (IS_ERR(priv->regmap)) {
+   ret = PTR_ERR(priv->regmap);
+   dev_err(&i2c->dev, "regmap init failed: %d\n", ret);
+   return ret;
+   }
+
+   ret = mfd_add_devices(&i2c->dev, -1, rn5t618_cells,
+ ARRAY_SIZE(rn5t618_cells), NULL, 0, NULL);
+   if (ret) {
+   dev_err(&i2c->dev, "failed to add sub-devices: %d\n", ret);
+   return ret;
+   }
+
+   if (!pm_power_off) {
+   rn5t618_pm_power_off = priv;
+   pm_power_off = rn5t618_power_off;
+   }
+
+   dev

[PATCH 2/4] regulator: add driver for Ricoh RN5T618 regulators

[Beniamino Galvani]

This driver supports the 3 DCDC and 7 LDO regulators available on
Ricoh RN5T618 PMIC.

Signed-off-by: Beniamino Galvani 
---
 drivers/regulator/Kconfig |6 ++
 drivers/regulator/Makefile|1 +
 drivers/regulator/rn5t618-regulator.c |  143 +
 include/linux/mfd/rn5t618.h   |   14 
 4 files changed, 164 insertions(+)
 create mode 100644 drivers/regulator/rn5t618-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 2dc8289..9d14e62 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -459,6 +459,12 @@ config REGULATOR_RC5T583
  through regulator interface. The device supports multiple DCDC/LDO
  outputs which can be controlled by i2c communication.
 
+config REGULATOR_RN5T618
+   tristate "Ricoh RN5T618 voltage regulators"
+   depends on MFD_RN5T618
+   help
+ Say y here to support the regulators found on Ricoh RN5T618 PMIC.
+
 config REGULATOR_S2MPA01
tristate "Samsung S2MPA01 voltage regulator"
depends on MFD_SEC_CORE
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index aa4a6aa..f7c4473 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_REGULATOR_PBIAS) += pbias-regulator.o
 obj-$(CONFIG_REGULATOR_PCAP) += pcap-regulator.o
 obj-$(CONFIG_REGULATOR_PCF50633) += pcf50633-regulator.o
 obj-$(CONFIG_REGULATOR_RC5T583)  += rc5t583-regulator.o
+obj-$(CONFIG_REGULATOR_RN5T618)  += rn5t618-regulator.o
 obj-$(CONFIG_REGULATOR_S2MPA01) += s2mpa01.o
 obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
 obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
diff --git a/drivers/regulator/rn5t618-regulator.c 
b/drivers/regulator/rn5t618-regulator.c
new file mode 100644
index 000..e58d79a
--- /dev/null
+++ b/drivers/regulator/rn5t618-regulator.c
@@ -0,0 +1,143 @@
+/*
+ * Regulator driver for Ricoh RN5T618 PMIC
+ *
+ * Copyright (C) 2014 Beniamino Galvani 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct regulator_ops rn5t618_reg_ops = {
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .is_enabled = regulator_is_enabled_regmap,
+   .set_voltage_sel= regulator_set_voltage_sel_regmap,
+   .get_voltage_sel= regulator_get_voltage_sel_regmap,
+   .list_voltage   = regulator_list_voltage_linear,
+};
+
+#define REG(rid, ereg, emask, vreg, vmask, min, max, step) \
+   [RN5T618_##rid] = { \
+   .name   = #rid, \
+   .id = RN5T618_##rid,\
+   .type   = REGULATOR_VOLTAGE,\
+   .owner  = THIS_MODULE,  \
+   .ops= &rn5t618_reg_ops, \
+   .n_voltages = ((max) - (min)) / (step) + 1, \
+   .min_uV = (min),\
+   .uV_step= (step),   \
+   .enable_reg = RN5T618_##ereg,   \
+   .enable_mask= (emask),  \
+   .vsel_reg   = RN5T618_##vreg,   \
+   .vsel_mask  = (vmask),  \
+   }
+
+static struct regulator_desc rn5t618_regulators[] = {
+   /* DCDC */
+   REG(DCDC1, DC1CTL, BIT(0), DC1DAC, 0xff, 60, 350, 12500),
+   REG(DCDC2, DC2CTL, BIT(0), DC2DAC, 0xff, 60, 350, 12500),
+   REG(DCDC3, DC3CTL, BIT(0), DC3DAC, 0xff, 60, 350, 12500),
+   /* LDO */
+   REG(LDO1, LDOEN1, BIT(0), LDO1DAC, 0x7f, 90, 350, 25000),
+   REG(LDO2, LDOEN1, BIT(1), LDO2DAC, 0x7f, 90, 350, 25000),
+   REG(LDO3, LDOEN1, BIT(2), LDO3DAC, 0x7f, 60, 350, 25000),
+   REG(LDO4, LDOEN1, BIT(3), LDO4DAC, 0x7f, 90, 350, 25000),
+   REG(LDO5, LDOEN1, BIT(4), LDO5DAC, 0x7f, 90, 350, 25000),
+   /* LDO RTC */
+   REG(LDORTC1, LDOEN2, BIT(4), LDORTCDAC, 0x7f, 170, 350, 25000),
+   REG(LDORTC2, LDOEN2, BIT(5), LDORTC2DAC, 0x7f, 90, 350, 25000),
+};
+
+static struct of_regulator_match rn5t618_matches[] = {
+   [RN5T618_DCDC1] = { .name = "DCDC1" },
+   [RN5T618_DCDC2] = { .name = "DCDC2" },
+   [RN5T618_DCDC3] = { .na

[PATCH 4/4] mfd: rn5t618: document device tree bindings

[Beniamino Galvani]

This adds the device tree bindings documentation for Ricoh RN5T618.

Signed-off-by: Beniamino Galvani 
---
 Documentation/devicetree/bindings/mfd/rn5t618.txt |   36 +
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/rn5t618.txt

diff --git a/Documentation/devicetree/bindings/mfd/rn5t618.txt 
b/Documentation/devicetree/bindings/mfd/rn5t618.txt
new file mode 100644
index 000..937785a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rn5t618.txt
@@ -0,0 +1,36 @@
+* Ricoh RN5T618 PMIC
+
+Ricoh RN5T618 is a power management IC which integrates 3 step-down
+DCDC converters, 7 low-dropout regulators, a Li-ion battery charger,
+fuel gauge, ADC, GPIOs and a watchdog timer. It can be controlled
+through a I2C interface.
+
+Required properties:
+ - compatible: should be "ricoh,rn5t618"
+ - reg: the I2C slave address of the device
+
+Sub-nodes:
+ - regulators: the node is required if the regulator functionality is
+   needed. The valid regulator names are: DCDC1, DCDC2, DCDC3, LDO1,
+   LDO2, LDO3, LDO4, LDO5, LDORTC1 and LDORTC2.
+   The common bindings for each individual regulator can be found in:
+   Documentation/devicetree/bindings/regulator/regulator.txt
+
+Example:
+
+   pmic@32 {
+   compatible = "ricoh,rn5t618";
+   reg = <0x32>;
+
+   regulators {
+   DCDC1 {
+   regulator-min-microvolt = <105>;
+   regulator-max-microvolt = <105>;
+   };
+
+   DCDC2 {
+   regulator-min-microvolt = <1175000>;
+   regulator-max-microvolt = <1175000>;
+   };
+   };
+   };
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] watchdog: add driver for Ricoh RN5T618 watchdog

[Beniamino Galvani]

This adds a driver for the watchdog timer available in Ricoh RN5T618
PMIC. The device supports a programmable expiration time of 1, 8, 32
or 128 seconds.

Signed-off-by: Beniamino Galvani 
---
 drivers/watchdog/Kconfig   |   11 +++
 drivers/watchdog/Makefile  |1 +
 drivers/watchdog/rn5t618_wdt.c |  196 
 include/linux/mfd/rn5t618.h|4 +
 4 files changed, 212 insertions(+)
 create mode 100644 drivers/watchdog/rn5t618_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index f57312f..9eba6af 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -309,6 +309,17 @@ config ORION_WATCHDOG
  To compile this driver as a module, choose M here: the
  module will be called orion_wdt.
 
+config RN5T618_WATCHDOG
+   tristate "Ricoh RN5T618 watchdog"
+   depends on MFD_RN5T618
+   select WATCHDOG_CORE
+   help
+ If you say yes here you get support for watchdog on the Ricoh
+ RN5T618 PMIC.
+
+ This driver can also be built as a module.  If so, the module
+ will be called rn5t618_wdt.
+
 config SUNXI_WATCHDOG
tristate "Allwinner SoCs watchdog support"
depends on ARCH_SUNXI
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 468c320..0afa343 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_IOP_WATCHDOG) += iop_wdt.o
 obj-$(CONFIG_DAVINCI_WATCHDOG) += davinci_wdt.o
 obj-$(CONFIG_ORION_WATCHDOG) += orion_wdt.o
 obj-$(CONFIG_SUNXI_WATCHDOG) += sunxi_wdt.o
+obj-$(CONFIG_RN5T618_WATCHDOG) += rn5t618_wdt.o
 obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
 obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
 obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
diff --git a/drivers/watchdog/rn5t618_wdt.c b/drivers/watchdog/rn5t618_wdt.c
new file mode 100644
index 000..3a76ad7
--- /dev/null
+++ b/drivers/watchdog/rn5t618_wdt.c
@@ -0,0 +1,196 @@
+/*
+ * Watchdog driver for Ricoh RN5T618 PMIC
+ *
+ * Copyright (C) 2014 Beniamino Galvani 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "rn5t618-wdt"
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+static unsigned int heartbeat = -1;
+
+module_param(heartbeat, int, 0);
+MODULE_PARM_DESC(heartbeat, "Initial watchdog heartbeat in seconds");
+
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct rn5t618_wdt {
+   struct watchdog_device wdt_dev;
+   struct rn5t618 *rn5t618;
+};
+
+/*
+ * This array encodes the values of WDOGTIM field for the supported
+ * watchdog expiration times. If the watchdog is not accessed before
+ * the timer expiration, the PMU generates an interrupt and if the CPU
+ * doesn't clear it within one second the system is restarted.
+ */
+static const struct {
+   u8 reg_val;
+   int time;
+} rn5t618_wdt_map[] = {
+   { 0, 1 },
+   { 1, 8 },
+   { 2, 32 },
+   { 3, 128 },
+};
+
+static int rn5t618_wdt_set_timeout(struct watchdog_device *wdt_dev,
+  unsigned int timeout)
+{
+   struct rn5t618_wdt *wdt = watchdog_get_drvdata(wdt_dev);
+   int ret, i;
+
+   for (i = 0; i < ARRAY_SIZE(rn5t618_wdt_map); i++) {
+   if (rn5t618_wdt_map[i].time + 1 >= timeout)
+   break;
+   }
+
+   if (i == ARRAY_SIZE(rn5t618_wdt_map))
+   ret = -EINVAL;
+   else
+   ret = regmap_update_bits(wdt->rn5t618->regmap, RN5T618_WATCHDOG,
+RN5T618_WATCHDOG_WDOGTIM_M,
+rn5t618_wdt_map[i].reg_val);
+   if (!ret)
+   wdt_dev->timeout = rn5t618_wdt_map[i].time;
+
+   return ret;
+}
+
+static int rn5t618_wdt_start(struct watchdog_device *wdt_dev)
+{
+   struct rn5t618_wdt *wdt = watchdog_get_drvdata(wdt_dev);
+   int ret;
+
+   ret = rn5t618_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
+   if (ret)
+   return ret;
+
+   /* enable repower-on */
+   ret = regmap_update_bits(wdt->rn5t618->regmap, RN5T618_REPCNT,
+RN5T618_REPCNT_REPWRON,
+RN5T618_REPCNT_REPWRON);
+   if (ret)
+   return ret;
+
+   /* enable watchdog */
+   ret = regmap_update_bits(wdt->rn5t618->regmap, RN5T618_WATCHDOG,
+RN5T618_WATCHDOG_WDOGEN,
+RN5T618_WATCHDOG_WDOGEN);
+

[PATCH 0/4] Add support for Ricoh RN5T618 PMIC

[Beniamino Galvani]

Ricoh RN5T618 is a power management IC which includes 3 step-down DCDC
converters, 7 low-dropout regulators, a Li-ion battery charger, fuel
gauge, ADC, GPIOs and a watchdog timer.

This series adds a MFD core driver and separate drivers to support the
regulator and watchdog functionalities.

The patchset has been tested on a Tronsmart Vega S89 Elite TV box on
top of other patches needed to support the Amlogic Meson SoC. The tree
with all the changes is available at:

  https://github.com/bengal/linux/tree/rn5t618

Beniamino Galvani (4):
  mfd: Add Ricoh RN5T618 PMIC core driver
  regulator: add driver for Ricoh RN5T618 regulators
  watchdog: add driver for Ricoh RN5T618 watchdog
  mfd: rn5t618: document device tree bindings

 Documentation/devicetree/bindings/mfd/rn5t618.txt |   36 
 drivers/mfd/Kconfig   |   11 +
 drivers/mfd/Makefile  |1 +
 drivers/mfd/rn5t618.c |  129 
 drivers/regulator/Kconfig |6 +
 drivers/regulator/Makefile|1 +
 drivers/regulator/rn5t618-regulator.c |  143 +
 drivers/watchdog/Kconfig  |   11 +
 drivers/watchdog/Makefile |1 +
 drivers/watchdog/rn5t618_wdt.c|  196 ++
 include/linux/mfd/rn5t618.h   |  228 +
 11 files changed, 763 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/rn5t618.txt
 create mode 100644 drivers/mfd/rn5t618.c
 create mode 100644 drivers/regulator/rn5t618-regulator.c
 create mode 100644 drivers/watchdog/rn5t618_wdt.c
 create mode 100644 include/linux/mfd/rn5t618.h

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] powerpc: fsl_pci: Add forced PCI Agent enumeration

[Aaron Sierra]

The following commit prevents the MPC8548E on the XPedite5200 PrPMC
module from enumerating its PCI/PCI-X bus:

powerpc/fsl-pci: use 'Header Type' to identify PCIE mode

The previous patch prevents any Freescale PCI-X bridge from enumerating
the bus, if it is hardware strapped into Agent mode.

In PCI-X, the Host is responsible for driving the PCI-X initialization
pattern to devices on the bus, so that they know whether to operate in
conventional PCI or PCI-X mode as well as what the bus timing will be.
For a PCI-X PrPMC, the pattern is driven by the mezzanine carrier it is
installed onto. Therefore, PrPMCs are PCI-X Agents, but one per system
may still enumerate the bus.

This patch causes the device node of any PCI/PCI-X bridge strapped into
Agent mode to be checked for the fsl,pci-agent-force-enum property. If
the property is present in the node, the bridge will be allowed to
enumerate the bus.

Cc: Minghuan Lian 
Signed-off-by: Aaron Sierra 
---
 Documentation/devicetree/bindings/pci/fsl,pci.txt | 27 +++
 arch/powerpc/sysdev/fsl_pci.c |  3 ++-
 2 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/pci/fsl,pci.txt

diff --git a/Documentation/devicetree/bindings/pci/fsl,pci.txt 
b/Documentation/devicetree/bindings/pci/fsl,pci.txt
new file mode 100644
index 000..d8ac4a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/fsl,pci.txt
@@ -0,0 +1,27 @@
+* Bus Enumeration by Freescale PCI-X Agent
+
+Typically any Freescale PCI-X bridge hardware strapped into Agent mode
+is prevented from enumerating the bus. The PrPMC form-factor requires
+all mezzanines to be PCI-X Agents, but one per system may still
+enumerate the bus.
+
+The property defined below will allow a PCI-X bridge to be used for bus
+enumeration despite being strapped into Agent mode.
+
+Required properties:
+- fsl,pci-agent-force-enum : There is no value associated with this
+  property. The property itself is treated as a boolean.
+
+Example:
+
+   /* PCI-X bridge known to be PrPMC Monarch */
+   pci0: pci@ef008000 {
+   fsl,pci-agent-force-enum;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   compatible = "fsl,mpc8540-pcix", "fsl,mpc8540-pci";
+   device_type = "pci";
+   ...
+   ...
+   };
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 4bd091a..d13663f 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -522,7 +522,8 @@ int fsl_add_bridge(struct platform_device *pdev, int 
is_primary)
} else {
/* For PCI read PROG to identify controller mode */
early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, &progif);
-   if ((progif & 1) == 1)
+   if ((progif & 1) &&
+   !of_property_read_bool(dev, "fsl,pci-agent-force-enum"))
goto no_bridge;
}
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 3/5] RTC: RK808: add RTC driver for RK808

[Dmitry Torokhov]

Hi Chris,

On Tue, Aug 26, 2014 at 10:14:56PM +0800, Chris Zhong wrote:
> Adding RTC driver for supporting RTC device present inside RK808 PMIC.
> 
> Signed-off-by: Chris Zhong 
> Signed-off-by: Zhang Qing 
> 
> ---
> 
> Changes in v6:
> Adviced by doug
> - move RTC_READSEL setting into probe
> 
> Changes in v5:
> - fixed a bug about set_time failed
> 
> Changes in v4:
> - use &client->dev replace rk808->dev
> 
> Changes in v3: None
> Changes in v2:
> Adviced by javier.martinez
> - Add a separate clock driver, rather than in RTC driver
> 
>  drivers/rtc/Kconfig |   10 ++
>  drivers/rtc/Makefile|1 +
>  drivers/rtc/rtc-rk808.c |  412 
> +++
>  3 files changed, 423 insertions(+)
>  create mode 100644 drivers/rtc/rtc-rk808.c
> 
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index a168e96..aeab9d9 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -288,6 +288,16 @@ config RTC_DRV_MAX77686
> This driver can also be built as a module. If so, the module
> will be called rtc-max77686.
>  
> +config RTC_DRV_RK808
> + tristate "Rockchip RK808 RTC"
> + depends on MFD_RK808
> + help
> +   If you say yes here you will get support for the
> +   RTC of RK808 PMIC.
> +
> +   This driver can also be built as a module. If so, the module
> +   will be called rk808-rtc.
> +
>  config RTC_DRV_RS5C372
>   tristate "Ricoh R2025S/D, RS5C372A/B, RV5C386, RV5C387A"
>   help
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index 56f061c..91fe4647 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -109,6 +109,7 @@ obj-$(CONFIG_RTC_DRV_PUV3)+= rtc-puv3.o
>  obj-$(CONFIG_RTC_DRV_PXA)+= rtc-pxa.o
>  obj-$(CONFIG_RTC_DRV_R9701)  += rtc-r9701.o
>  obj-$(CONFIG_RTC_DRV_RC5T583)+= rtc-rc5t583.o
> +obj-$(CONFIG_RTC_DRV_RK808)  += rtc-rk808.o
>  obj-$(CONFIG_RTC_DRV_RP5C01) += rtc-rp5c01.o
>  obj-$(CONFIG_RTC_DRV_RS5C313)+= rtc-rs5c313.o
>  obj-$(CONFIG_RTC_DRV_RS5C348)+= rtc-rs5c348.o
> diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk808.c
> new file mode 100644
> index 000..00cd997
> --- /dev/null
> +++ b/drivers/rtc/rtc-rk808.c
> @@ -0,0 +1,412 @@
> +/*
> + * RTC driver for Rockchip RK808
> + *
> + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* RTC_CTRL_REG bitfields */
> +#define BIT_RTC_CTRL_REG_STOP_RTC_M  BIT(0)
> +#define BIT_RTC_CTRL_REG_RTC_READSEL_M   BIT(7)
> +#define BIT_RTC_INTERRUPTS_REG_IT_ALARM_MBIT(3)
> +#define RTC_STATUS_MASK  0xFE
> +
> +#define SECONDS_REG_MSK  0x7F
> +#define MINUTES_REG_MAK  0x7F
> +#define HOURS_REG_MSK0x3F
> +#define DAYS_REG_MSK 0x3F
> +#define MONTHS_REG_MSK   0x1F
> +#define YEARS_REG_MSK0xFF
> +#define WEEKS_REG_MSK0x7
> +
> +/* REG_SECONDS_REG through REG_YEARS_REG is how many registers? */
> +
> +#define NUM_TIME_REGS(RK808_WEEKS_REG - RK808_SECONDS_REG + 1)
> +#define NUM_ALARM_REGS   (RK808_ALARM_YEARS_REG - 
> RK808_ALARM_SECONDS_REG + 1)
> +
> +struct rk808_rtc {
> + struct rk808 *rk808;
> + struct rtc_device *rtc;
> + int irq;
> +};
> +
> +/* Read current time and date in RTC */
> +static int rk808_rtc_readtime(struct device *dev, struct rtc_time *tm)
> +{
> + struct rk808_rtc *rk808_rtc = dev_get_drvdata(dev);
> + struct rk808 *rk808 = rk808_rtc->rk808;
> + u8 rtc_data[NUM_TIME_REGS];
> + int ret;
> +
> + ret = regmap_bulk_read(rk808->regmap, RK808_SECONDS_REG,
> +rtc_data, NUM_TIME_REGS);
> + if (ret) {
> + dev_err(dev, "Failed to bulk read rtc_data: %d\n", ret);
> + return ret;
> + }
> +
> + tm->tm_sec = bcd2bin(rtc_data[0] & SECONDS_REG_MSK);
> + tm->tm_min = bcd2bin(rtc_data[1] & MINUTES_REG_MAK);
> + tm->tm_hour = bcd2bin(rtc_data[2] & HOURS_REG_MSK);
> + tm->tm_mday = bcd2bin(rtc_data[3] & DAYS_REG_MSK);
> + tm->tm_mon = (bcd2bin(rtc_data[4] & MONTHS_REG_MSK)) - 1;
> + tm->tm_year = (bcd2bin(rtc_data[5] & YEARS_REG_MSK)) + 100;
> + tm->tm_wday = bcd2bin(rtc_data[6] & WEEKS_REG_MSK);
> + dev_dbg(dev, "RTC date/time %4d-%02d-%02d(%d) %02d:%02d:%02d\n",
> + 1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
> +

Re: [RFC 3/7] bcm47xx-sprom: add Broadcom sprom parser driver

[Hauke Mehrtens]

On 08/25/2014 09:52 AM, Arnd Bergmann wrote:
> On Sunday 24 August 2014 23:24:41 Hauke Mehrtens wrote:
>> This driver needs an nvram driver and fetches the sprom values from the
>> nvram and provides it to any other driver. The calibration data for the
>> wifi chip the mac address and some more board description data is
>> stores in the sprom.
>>
>> This is based on a copy of arch/mips/bcm47xx/sprom.c and my plan is to
>> make the bcm47xx MIPS SoCs also use this driver some time later.
> 
>> Signed-off-by: Hauke Mehrtens 
>> ---
>>  .../devicetree/bindings/misc/bcm47xx-sprom.txt |  16 +
> 
> I'd prefer not to list the binding in a 'misc' category. Maybe we can
> have a new category and move the misc/sram.txt into the same?
> 
>>  drivers/misc/Kconfig   |  14 +
>>  drivers/misc/Makefile  |   1 +
>>  drivers/misc/bcm47xx-sprom.c   | 690 
>> +
> 
> On a similar note, putting the driver into drivers/misc seems
> suboptimal: misc drivers should by definition be something that
> is for some odd hardware with no external dependencies on it,
> whereas your driver seems to be used by multiple other drivers.
> 
> Would it make sense to put it into drivers/bcma when that is the
> only bus it is used on?

As Jonas already said this code should be used for the bcm53xx ARM code
and the bcm47xx MIPS code and it is needed for drivers/bcma/ and
drivers/ssb/ (ssb only for old mips devices). Do you have any better
idea than putting this to drivers/misc/ ? For the mips SoC we need the
code very early and will not use the driver interface but probably
directly call the function name.
> 
>>  4 files changed, 721 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/misc/bcm47xx-sprom.txt
>>  create mode 100644 drivers/misc/bcm47xx-sprom.c
>>
>> diff --git a/Documentation/devicetree/bindings/misc/bcm47xx-sprom.txt 
>> b/Documentation/devicetree/bindings/misc/bcm47xx-sprom.txt
>> new file mode 100644
>> index 000..eed2a4a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/bcm47xx-sprom.txt
>> @@ -0,0 +1,16 @@
>> +Broadcom bcm47xx/bcm53xx sprom converter
>> +
>> +This driver provbides an sprom based on a given nvram.
>> +
>> +Required properties:
>> +
>> +- compatible : brcm,bcm47xx-sprom
> 
> Please use a specific SoC here as the compatible string, not something
> with 'x' in it as a wildcard.

I will change that.

> 
>> +#define NVRAM_READ_VAL(type)
>> \
>> +static void nvram_read_ ## type (const struct bcm47xx_sprom_fill *fill, 
>> \
>> + const char *postfix, const char *name, \
>> + type *val, type allset)\
>> +{   \
>> +char buf[100];  \
>> +int err;\
>> +type var;   \
>> +\
>> +err = get_nvram_var(fill, postfix, name, buf, sizeof(buf)); \
>> +if (err < 0)\
>> +return; \
>> +err = kstrto ## type(strim(buf), 0, &var);  \
>> +if (err) {  \
>> +pr_warn("can not parse nvram name %s%s%s with value %s got 
>> %i\n",   \
>> +fill->prefix, name, postfix, buf, err); \
>> +return; \
>> +}   \
>> +if (allset && var == allset)\
>> +return; \
>> +*val = var; \
>> +}
>> +
>> +NVRAM_READ_VAL(u8)
>> +NVRAM_READ_VAL(s8)
>> +NVRAM_READ_VAL(u16)
>> +NVRAM_READ_VAL(u32)
>> +
>> +#undef NVRAM_READ_VAL
> 
> Hmm, multiline macros are ugly. How about using one function to read
> into an s64 internally using kstrtoll, and simple inline wrappers around
> that for the smaller types, doing the appropriate range check?

Yes that should work I will try it.

>> +static void bcm47xx_sprom_fill_r1234589(struct ssb_sprom *sprom,
>> +const struct bcm47xx_sprom_fill *fill)
>> +{
>> +nvram_read_u16(fill, NULL, "devid", &sprom->dev_id, 0);
>> +nvram_read_u8(fill, NULL, "ledbh0", &sprom->gpio0, 0xff);
>> +nvram_read_u8(fill, NULL, "ledbh1", &sprom->gpio1, 0xff);
>> +nvram_read_u8(fill, NULL, "ledbh2", &sprom->gpio2, 0xff);
>> +nvram_read_u8(fill, NULL, "ledbh3", &sprom->gpio3, 0xff);
>> +nvram_read_u8(fill, NULL, "aa2g", &sprom->ant_availa

Re: [RFC 4/7] bcma: register bcma as device tree driver

[Hauke Mehrtens]

On 08/25/2014 09:57 AM, Arnd Bergmann wrote:
> On Sunday 24 August 2014 23:24:42 Hauke Mehrtens wrote:
>> This driver is used by the bcm53xx ARM SoC code. Now it is possible to
>> give the address of the chipcommon core in device tree and bcma will
>> search for all the other cores.
>>
>> Signed-off-by: Hauke Mehrtens 
> 
> Looks good to me overall. Two small comments:
> 
>>  Documentation/devicetree/bindings/bus/bcma.txt | 46 +
>>  drivers/bcma/host_soc.c| 70 
>> ++
>>  include/linux/bcma/bcma.h  |  2 +
>>  3 files changed, 118 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/bus/bcma.txt
>>
>> diff --git a/Documentation/devicetree/bindings/bus/bcma.txt 
>> b/Documentation/devicetree/bindings/bus/bcma.txt
>> new file mode 100644
>> index 000..52fb929
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/bus/bcma.txt
>> @@ -0,0 +1,46 @@
>> +Broadcom AIX bcma bus driver
>> +
>> +
>> +Required properties:
>> +
>> +- compatible : brcm,bus-aix
>> +
>> +- reg : iomem address range of chipcommon core
>> +
>> +Optional properties:
>> +
>> +- sprom: reference to a sprom driver. This is needed for sprom less devices.
>> +Use bcm47xx_sprom for example.
>> +
>> +
>> +The cores on the AIX bus are auto detected by bcma. Detection of the
>> +IRQ number is not supported on BCM47xx/BCM53xx ARM SoCs, so it is
>> +possible to provide the IRQ number over device tree. The IRQ number and
>> +the device tree child entry will be added to the core with the matching
>> +reg address.
> 
> What is the problem with the interrupt numbers? Is that information
> missing completely from the data available to the brcm bus, or is it
> in an inconvenient format?

I do not have access to the datasheet, only to the vendor source code.
The irq numbers are hard coded in the vendor code, see:
https://github.com/RMerl/asuswrt-merlin/blob/master/release/src-rt-6.x.4708/linux/linux-2.6.36/arch/arm/plat-brcm/bcm5301x_pcie.c#L286

On the mips SoCs it was possible to read them from some register in the
mips core on the aix bus.

> 
>> +Example:
>> +
>> +   aix@1800 {
>> +   compatible = "brcm,bus-aix";
>> +   reg = <0x1800 0x1000>;
>> +   ranges = <0x 0x1800 0x0010>;
>> +   #address-cells = <1>;
>> +   #size-cells = <1>;
>> +   sprom = <&sprom0>;
>> +
>> +   gmac@0 {
>> +   reg = <0x18024000 0x1000>;
>> +   interrupts = ;
>> +   };
> 
> The @0 part seems wrong here: the address should generally match
> the first entry in the reg property, which would be gmac@18024000.
> 
> Also, you probably mean ethernet@ not gmac@.

Will change that.

>> +   gmac@1 {
>> +   reg = <0x18025000 0x1000>;
>> +   interrupts = ;
>> +   };
>> +
>> +   pcie@0 {
>> +   reg = <0x18012000 0x1000>;
>> +   interrupts = ;
>> +   };
>> +   };
> 
> We may require additional properties for the pcie node, depending on whether
> we want to use the DT probing interfaces for it, or whether it should just
> hardcode the settings used on brcm based on the ID.

I wrote a driver for the PCIe host controller and it also automatically
detects all needed memory addresses, it just had to provide the IRQ
number through device tree.

> 
>   Arnd
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv10 2/2] arm: dts: Add Altera SDRAM EDAC bindings & devicetree entries.

[Dinh Nguyen]

On Tue, Aug 26, 2014 at 3:28 PM, Dinh Nguyen
 wrote:
> On 08/26/2014 01:39 PM, Thor Thayer wrote:
>>
>> On 08/14/2014 01:49 PM, Pavel Machek wrote:
>>> On Mon 2014-08-11 10:18:13, ttha...@opensource.altera.com wrote:
 From: Thor Thayer 

 Add the Altera SDRAM EDAC bindings and device tree changes to the
 Altera SoC project.

 Signed-off-by: Thor Thayer 
>>> Acked-by: Pavel Machek 
>>>
>>>
>> Hi All,
>>
>> Any further comments or suggestions on this patch series? Thanks for the
>> review, Pavel!
>
> If Boris is okay with driver part and everyone else is OK with the DTS
> portion, then I can apply the DTS patch to my tree, and Boris take the
> driver patch into his tree?
>


Actually, I think I need to get an Ack-by from a DTS maintainer before
I can apply
this as it is introducing a new binding.

Sorry for the noise.

Dinh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 5/5] regulator: RK808: remove redundant code

[Doug Anderson]

Chris,

On Tue, Aug 26, 2014 at 7:18 AM, Chris Zhong  wrote:
> remove the redundant code, since pdata has been removed from stuct rk808
>
> Signed-off-by: Chris Zhong 
>
> ---
>
> Changes in v6:
> - remove the redundant code
>
> Changes in v5:
> - re-edit base on Mark's branch
>
> Changes in v4:
> - use &client->dev replace rk808->dev
>
> Changes in v3: None
> Changes in v2:
> Adviced by Mark Browm:
> - change of_find_node_by_name to find_child_by_name
> - use RK808_NUM_REGULATORS as the name of the constant
> - create a pdata when missing platform data
> - use the rk808_reg name to supply_regulator name
> - replace regulator_register with devm_regulator_register
> - some other problem with coding styl
>
>  drivers/regulator/rk808-regulator.c |   17 -
>  1 file changed, 4 insertions(+), 13 deletions(-)

Probably shouldn't land until we've solved problems around the
"platform data" in the MFD patch...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Generic communication of boot loader state to the OS

[jonsm...@gmail.com]

On Tue, Aug 26, 2014 at 3:02 PM, Russell King - ARM Linux
 wrote:
> On Tue, Aug 26, 2014 at 02:39:45PM -0400, jonsm...@gmail.com wrote:
>> On Tue, Aug 26, 2014 at 2:28 PM, Russell King - ARM Linux
>>  wrote:
>> > On Tue, Aug 26, 2014 at 12:10:00PM -0400, jonsm...@gmail.com wrote:
>> >> As a side effect this will eliminate the need for kernel command line
>> >> parameters describing boot state. Like console="". Over time it might
>> >> even be able to pass a DHCP IP address from uboot into the kernel.
>> >
>> > Err no.  Don't even think about that.  DHCP may be wonderful and all,
>> > but there's a fundamental issue with it: entries time out unless they
>> > are renewed.
>> >
>> > Why is that a problem?  Well, take a DHCP server which hands out
>> > dynamic addresses, and updates the DNS.  When the lease expires, it
>> > tears down the DNS entry.
>> >
>> > Now take a target booting using DHCP in uboot, which then mounts its
>> > root NFS.  If it tries to startup a DHCP client, the first thing the
>> > DHCP client does is to clean up the interface... resulting in it
>> > killing the root NFS connection.  If that doesn't happen, then you
>> > end up with a problem at shutdown, because DHCP clients always
>> > deconfigure the interface when they're killed off - resulting in
>> > "reboot" not being functional.
>>
>> I run the same configuration  -  uboot in flash, tftp to load kernel,
>> nfs mount the root. And I do reboot fifty times a day too.  I just put
>> everything on static IPs to avoid problems.
>>
>> Would this work if the DHCP client was notified that there already was
>> an IP lease in place?  It could remember that lease and then be
>> responsible for setting it into the interface and renewing it. Right
>> now there is no way to pass this information.
>>
>> Doesn't the DHCP client do the wrong thing simply because it lacks the
>> info to do something better?
>
> It can get the already configured IP address if the kernel (or initramfs)
> has already configured the interface - it's already available from the
> interface itself.  So it's not that there's no way to pass this to DHCP,
> it's that DHCP always starts out assuming that it's the new kid on the
> block.
>
> Solving that problem doesn't get away from the shutdown problem though.
> You can partially avoid it by not having interfaces brought down, but
> one of the things that distros commonly do is kill all processes during
> shutdown... which kills the DHCP client, and then causes the interface
> to be deconfigured... which then stalls the reboot operation because
> suddenly the root-NFS server is no longer available... Gosh, why did
> that happen I wonder...

I wonder if DHCP client couldn't be replaced with a udev event. Set a
timer in the kernel for the length of the lease. Then generate a udev
event when it is ready to expire. Udev event runs an app that gets a
new lease.  Now there is no process to kill on reboot and everyone is
happy.



>
> --
> FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
> according to speedtest.net.



-- 
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv10 2/2] arm: dts: Add Altera SDRAM EDAC bindings & devicetree entries.

[Dinh Nguyen]

On 08/26/2014 01:39 PM, Thor Thayer wrote:
> 
> On 08/14/2014 01:49 PM, Pavel Machek wrote:
>> On Mon 2014-08-11 10:18:13, ttha...@opensource.altera.com wrote:
>>> From: Thor Thayer 
>>>
>>> Add the Altera SDRAM EDAC bindings and device tree changes to the
>>> Altera SoC project.
>>>
>>> Signed-off-by: Thor Thayer 
>> Acked-by: Pavel Machek 
>>
>>
> Hi All,
> 
> Any further comments or suggestions on this patch series? Thanks for the
> review, Pavel!

If Boris is okay with driver part and everyone else is OK with the DTS
portion, then I can apply the DTS patch to my tree, and Boris take the
driver patch into his tree?

Thanks,
Dinh

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 2/5] ARM: imx6: gpc: Add PU power domain for GPU/VPU

[Ulf Hansson]

On 26 August 2014 15:46, Philipp Zabel  wrote:
> When generic pm domain support is enabled, the PGC can be used
> to completely gate power to the PU power domain containing GPU3D,
> GPU2D, and VPU cores.
> This code triggers the PGC powerdown sequence to disable the GPU/VPU
> isolation cells and gate power and then disables the PU regulator.
> To reenable, the reverse powerup sequence is triggered after the PU
> regulator is enabled again.
> The GPU and VPU devices in the PU power domain temporarily need
> to be clocked during powerup, so that the reset machinery can work.
>
> Signed-off-by: Philipp Zabel 
> ---
>  arch/arm/mach-imx/Kconfig |   1 +
>  arch/arm/mach-imx/gpc.c   | 203 
> ++
>  2 files changed, 204 insertions(+)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 9de84a2..78d69cf 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -50,6 +50,7 @@ config HAVE_IMX_ANATOP
>
>  config HAVE_IMX_GPC
> bool
> +   select PM_GENERIC_DOMAINS if PM
>
>  config HAVE_IMX_MMDC
> bool
> diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
> index 82ea74e..5eec828 100644
> --- a/arch/arm/mach-imx/gpc.c
> +++ b/arch/arm/mach-imx/gpc.c
> @@ -10,19 +10,41 @@
>   * http://www.gnu.org/copyleft/gpl.html
>   */
>
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include "common.h"
> +#include "hardware.h"
>
> +#define GPC_CNTR   0x000
>  #define GPC_IMR1   0x008
> +#define GPC_PGC_GPU_PDN0x260
> +#define GPC_PGC_GPU_PUPSCR 0x264
> +#define GPC_PGC_GPU_PDNSCR 0x268
>  #define GPC_PGC_CPU_PDN0x2a0
>
>  #define IMR_NUM4
>
> +#define GPU_VPU_PUP_REQBIT(1)
> +#define GPU_VPU_PDN_REQBIT(0)
> +
> +#define GPC_CLK_MAX6
> +
> +struct pu_domain {
> +   struct generic_pm_domain base;
> +   struct regulator *reg;
> +   struct clk *clk[GPC_CLK_MAX];
> +   int num_clks;
> +};
> +
>  static void __iomem *gpc_base;
>  static u32 gpc_wake_irqs[IMR_NUM];
>  static u32 gpc_saved_imrs[IMR_NUM];
> @@ -139,3 +161,184 @@ void __init imx_gpc_init(void)
> gic_arch_extn.irq_unmask = imx_gpc_irq_unmask;
> gic_arch_extn.irq_set_wake = imx_gpc_irq_set_wake;
>  }
> +
> +#ifdef CONFIG_PM

Hi Philipp,

Should this be CONFIG_PM_GENERIC_DOMAINS?

> +
> +static int imx6q_pm_pu_power_off(struct generic_pm_domain *genpd)
> +{
> +   struct pu_domain *pu = container_of(genpd, struct pu_domain, base);
> +   int iso, iso2sw;
> +   u32 val;
> +
> +   /* Read ISO and ISO2SW power down delays */
> +   val = readl_relaxed(gpc_base + GPC_PGC_GPU_PDNSCR);
> +   iso = val & 0x3f;
> +   iso2sw = (val >> 8) & 0x3f;
> +
> +   /* Gate off PU domain when GPU/VPU when powered down */
> +   writel_relaxed(0x1, gpc_base + GPC_PGC_GPU_PDN);
> +
> +   /* Request GPC to power down GPU/VPU */
> +   val = readl_relaxed(gpc_base + GPC_CNTR);
> +   val |= GPU_VPU_PDN_REQ;
> +   writel_relaxed(val, gpc_base + GPC_CNTR);
> +
> +   /* Wait ISO + ISO2SW IPG clock cycles */
> +   ndelay((iso + iso2sw) * 1000 / 66);
> +
> +   regulator_disable(pu->reg);
> +
> +   return 0;
> +}
> +
> +static int imx6q_pm_pu_power_on(struct generic_pm_domain *genpd)
> +{
> +   struct pu_domain *pu = container_of(genpd, struct pu_domain, base);
> +   int i, ret, sw, sw2iso;
> +   u32 val;
> +
> +   ret = regulator_enable(pu->reg);
> +   if (ret) {
> +   pr_err("%s: failed to enable regulator: %d\n", __func__, ret);
> +   return ret;
> +   }
> +
> +   /* Enable reset clocks for all devices in the PU domain */
> +   for (i = 0; i < pu->num_clks; i++)
> +   clk_prepare_enable(pu->clk[i]);
> +
> +   /* Gate off PU domain when GPU/VPU when powered down */
> +   writel_relaxed(0x1, gpc_base + GPC_PGC_GPU_PDN);
> +
> +   /* Read ISO and ISO2SW power down delays */
> +   val = readl_relaxed(gpc_base + GPC_PGC_GPU_PUPSCR);
> +   sw = val & 0x3f;
> +   sw2iso = (val >> 8) & 0x3f;
> +
> +   /* Request GPC to power up GPU/VPU */
> +   val = readl_relaxed(gpc_base + GPC_CNTR);
> +   val |= GPU_VPU_PUP_REQ;
> +   writel_relaxed(val, gpc_base + GPC_CNTR);
> +
> +   /* Wait ISO + ISO2SW IPG clock cycles */
> +   ndelay((sw + sw2iso) * 1000 / 66);
> +
> +   /* Disable reset clocks for all devices in the PU domain */
> +   for (i = 0; i < pu->num_clks; i++)
> +   clk_disable_unprepare(pu->clk[i]);
> +
> +   return 0;
> +}
> +
> +static struct generic_pm_domain imx6q_arm_domain = {
> +   .name = "ARM",
> +};
> +
> +static struct pu_domain imx6q_pu_domain = {
> +   .base = {
> +   .name = "PU",
> +   .po

Re: Generic communication of boot loader state to the OS

[Russell King - ARM Linux]

On Tue, Aug 26, 2014 at 02:39:45PM -0400, jonsm...@gmail.com wrote:
> On Tue, Aug 26, 2014 at 2:28 PM, Russell King - ARM Linux
>  wrote:
> > On Tue, Aug 26, 2014 at 12:10:00PM -0400, jonsm...@gmail.com wrote:
> >> As a side effect this will eliminate the need for kernel command line
> >> parameters describing boot state. Like console="". Over time it might
> >> even be able to pass a DHCP IP address from uboot into the kernel.
> >
> > Err no.  Don't even think about that.  DHCP may be wonderful and all,
> > but there's a fundamental issue with it: entries time out unless they
> > are renewed.
> >
> > Why is that a problem?  Well, take a DHCP server which hands out
> > dynamic addresses, and updates the DNS.  When the lease expires, it
> > tears down the DNS entry.
> >
> > Now take a target booting using DHCP in uboot, which then mounts its
> > root NFS.  If it tries to startup a DHCP client, the first thing the
> > DHCP client does is to clean up the interface... resulting in it
> > killing the root NFS connection.  If that doesn't happen, then you
> > end up with a problem at shutdown, because DHCP clients always
> > deconfigure the interface when they're killed off - resulting in
> > "reboot" not being functional.
> 
> I run the same configuration  -  uboot in flash, tftp to load kernel,
> nfs mount the root. And I do reboot fifty times a day too.  I just put
> everything on static IPs to avoid problems.
> 
> Would this work if the DHCP client was notified that there already was
> an IP lease in place?  It could remember that lease and then be
> responsible for setting it into the interface and renewing it. Right
> now there is no way to pass this information.
> 
> Doesn't the DHCP client do the wrong thing simply because it lacks the
> info to do something better?

It can get the already configured IP address if the kernel (or initramfs)
has already configured the interface - it's already available from the
interface itself.  So it's not that there's no way to pass this to DHCP,
it's that DHCP always starts out assuming that it's the new kid on the
block.

Solving that problem doesn't get away from the shutdown problem though.
You can partially avoid it by not having interfaces brought down, but
one of the things that distros commonly do is kill all processes during
shutdown... which kills the DHCP client, and then causes the interface
to be deconfigured... which then stalls the reboot operation because
suddenly the root-NFS server is no longer available... Gosh, why did
that happen I wonder...

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv10 1/2] edac: altera: Add Altera SDRAM EDAC support.

[Thor Thayer]

On 08/14/2014 01:49 PM, Pavel Machek wrote:

On Mon 2014-08-11 10:18:12, ttha...@opensource.altera.com wrote:

From: Thor Thayer 

This patch adds support for the CycloneV and ArriaV SDRAM controllers.
Correction and reporting of SBEs, Panic on DBEs.

Signed-off-by: Thor Thayer 

Acked-by: Pavel Machek 


Hi All,

Any further comments or suggestions on this patch series? Thanks for 
reviewing, Pavel!


Thor
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Generic communication of boot loader state to the OS

[Mark Rutland]

On Tue, Aug 26, 2014 at 07:31:09PM +0100, jonsm...@gmail.com wrote:
> On Tue, Aug 26, 2014 at 1:16 PM, Mark Rutland  wrote:
> > Hi Jon,
> >
> > On Tue, Aug 26, 2014 at 05:10:00PM +0100, jonsm...@gmail.com wrote:
> >> New thread split off from the simple-framebuffer discussion
> >>
> >> Is there a generic, underlying problem here that needs to be solved?
> >> AFAIK no one has designed a general purpose mechanism for
> >> communicating boot loader state to the OS. There is the existing
> >> device tree  node but it is limited compared to what is
> >> needed. Maybe we should step back and first design a good solution to
> >> this basic problem. Then specific solutions for things like
> >> framebuffers would fall out of the basic design.
> >
> > I think the fundamental problem here is unfortunately far too abstract
> > for the general solution to be any more concrete. The solution to "we
> > don't communicate boot state" is "we should communicate boot state".
> >
> > We can perhaps come up with general guidelines (for instance, the clock
> > subsystem has assigned-* properties), but I don't think there's a
> > one-size-fits-all solution.
> 
> I think it worth taking some time to consider if a one-size-fits-all
> solution exists for the general issues of communicating between the
> boot loader and the OS. Things are a lot better now, but I can
> remember have 20K byte long kernel command lines in the past.  Some
> random thoughts...

As I mentioned, I think we can set general guidelines. Some information
is just going to be device-specific, so enforcing a particular format
for everything is going to get in the way. There's no reason there can't
be common conventions, however.

> Do we even need a kernel command line any more?

I quite like being able to override options for test purposes, but we
don't necessarily have to require a non-empty command line.

> Could EARLY_PRINTK be made automatic with cooperation from the bootloader?

I believe Rob Herring's earlycon patches can set up an earlycon based on
stdout-path.

> Can we make it all the way from the boot loader to the GUI without
> having the display flash from mode setting?

If we communicate the display mode and the configuration of the clocks,
regulators, and memory allocations, probably. We already have the basic
bindings for all of these, so I think the bulk of the work would be
convincing the subsystems to do interact in the right way.

> Can I not auto-negotiate network links speed twice (a slow process)?

Perhaps. It depends on what information your particular network
controller setup needs to pass along (perhaps nothing whatsoever).

> Can 23 years of different solutions be collapsed into a general framework?

I think the only common thing here is that something in a subsystem
needs to parse the DT early and act on it. We already have initcalls.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Generic communication of boot loader state to the OS

[jonsm...@gmail.com]

On Tue, Aug 26, 2014 at 2:28 PM, Russell King - ARM Linux
 wrote:
> On Tue, Aug 26, 2014 at 12:10:00PM -0400, jonsm...@gmail.com wrote:
>> As a side effect this will eliminate the need for kernel command line
>> parameters describing boot state. Like console="". Over time it might
>> even be able to pass a DHCP IP address from uboot into the kernel.
>
> Err no.  Don't even think about that.  DHCP may be wonderful and all,
> but there's a fundamental issue with it: entries time out unless they
> are renewed.
>
> Why is that a problem?  Well, take a DHCP server which hands out
> dynamic addresses, and updates the DNS.  When the lease expires, it
> tears down the DNS entry.
>
> Now take a target booting using DHCP in uboot, which then mounts its
> root NFS.  If it tries to startup a DHCP client, the first thing the
> DHCP client does is to clean up the interface... resulting in it
> killing the root NFS connection.  If that doesn't happen, then you
> end up with a problem at shutdown, because DHCP clients always
> deconfigure the interface when they're killed off - resulting in
> "reboot" not being functional.

I run the same configuration  -  uboot in flash, tftp to load kernel,
nfs mount the root. And I do reboot fifty times a day too.  I just put
everything on static IPs to avoid problems.

Would this work if the DHCP client was notified that there already was
an IP lease in place?  It could remember that lease and then be
responsible for setting it into the interface and renewing it. Right
now there is no way to pass this information.

Doesn't the DHCP client do the wrong thing simply because it lacks the
info to do something better?

>
> Here, I run exactly that setup, and I have found that ubuntu suffers
> quite a bit from problems if you don't tell it to keep its fingers
> off the ethernet device configuration when running root-NFS - and
> believe me, when I'm working on something, I probably do several
> tens of remote reboots of targets via "reboot" - I know I've done
> about fifty today so far (many of them having to resort to the reset
> button because the kernel seems to be locking up rather than rebooting
> at the final stage.)
>
> --
> FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
> according to speedtest.net.



-- 
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 1/5] dt-bindings: Add RK808 device tree bindings document

[Doug Anderson]

Chris,

On Tue, Aug 26, 2014 at 7:11 AM, Chris Zhong  wrote:
> Add device tree bindings documentation and a header file
> for rockchip's RK808 pmic.
>
> Signed-off-by: Chris Zhong 
> Signed-off-by: Zhang Qing 
>
> ---
>
> Changes in v6:
> Advices by Mark Rutland
> - add description about clock-cells
> Advices by Doug
> - modify description about regulator
> - remove pinctrl description
>
> Changes in v5:
> Advices by Mark Brown
> - add description about regulator valid name.
> - add a header file "rockchip,rk808".
>
> Changes in v4:
> Advices by Doug
> - add a "#clock-cells" propertiy
> - update the example
>
> Changes in v3: None
> Changes in v2: None
>
>  Documentation/devicetree/bindings/mfd/rk808.txt |  150 
> +++
>  include/dt-bindings/clock/rockchip,rk808.h  |   11 ++
>  2 files changed, 161 insertions(+)


Is it worth picking a new example from
?  Then if someone
happens to copy your example the'll get slightly more sane things
(level low for interrupt, wakeup-source, proper "clock-output-name"
that's compatible with rk3288, etc.

Other than that this looks find to me:

Reviewed-by: Doug Anderson 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv10 2/2] arm: dts: Add Altera SDRAM EDAC bindings & devicetree entries.

[Thor Thayer]

On 08/14/2014 01:49 PM, Pavel Machek wrote:

On Mon 2014-08-11 10:18:13, ttha...@opensource.altera.com wrote:

From: Thor Thayer 

Add the Altera SDRAM EDAC bindings and device tree changes to the Altera SoC 
project.

Signed-off-by: Thor Thayer 

Acked-by: Pavel Machek 



Hi All,

Any further comments or suggestions on this patch series? Thanks for the 
review, Pavel!


Thor
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] ARM: DT: APQ8064: Add pinctrl support This patch adds device tree nodes to support pinctrl for apq8064 SOC

[Pramod Gurav]

CC: Rob Herring 
CC: Pawel Moll 
CC: Mark Rutland 
CC: Ian Campbell 
CC: Kumar Gala 
CC: devicetree@vger.kernel.org
CC: linux-arm-ker...@lists.infradead.org

Signed-off-by: Pramod Gurav 
---
 arch/arm/boot/dts/qcom-apq8064.dtsi |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index d66fb25..681e194 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -73,6 +73,17 @@
ranges;
compatible = "simple-bus";
 
+   msm_gpio: pinctrl@80 {
+   compatible = "qcom,apq8064-pinctrl";
+   reg = <0x80 0x4000>;
+
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   interrupts = <0 32 0x4>;
+   };
+
intc: interrupt-controller@200 {
compatible = "qcom,msm-qgic2";
interrupt-controller;
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Generic communication of boot loader state to the OS

[jonsm...@gmail.com]

On Tue, Aug 26, 2014 at 1:16 PM, Mark Rutland  wrote:
> Hi Jon,
>
> On Tue, Aug 26, 2014 at 05:10:00PM +0100, jonsm...@gmail.com wrote:
>> New thread split off from the simple-framebuffer discussion
>>
>> Is there a generic, underlying problem here that needs to be solved?
>> AFAIK no one has designed a general purpose mechanism for
>> communicating boot loader state to the OS. There is the existing
>> device tree  node but it is limited compared to what is
>> needed. Maybe we should step back and first design a good solution to
>> this basic problem. Then specific solutions for things like
>> framebuffers would fall out of the basic design.
>
> I think the fundamental problem here is unfortunately far too abstract
> for the general solution to be any more concrete. The solution to "we
> don't communicate boot state" is "we should communicate boot state".
>
> We can perhaps come up with general guidelines (for instance, the clock
> subsystem has assigned-* properties), but I don't think there's a
> one-size-fits-all solution.

I think it worth taking some time to consider if a one-size-fits-all
solution exists for the general issues of communicating between the
boot loader and the OS. Things are a lot better now, but I can
remember have 20K byte long kernel command lines in the past.  Some
random thoughts...

Do we even need a kernel command line any more?
Could EARLY_PRINTK be made automatic with cooperation from the bootloader?
Can we make it all the way from the boot loader to the GUI without
having the display flash from mode setting?
Can I not auto-negotiate network links speed twice (a slow process)?
Can 23 years of different solutions be collapsed into a general framework?

-- 
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Generic communication of boot loader state to the OS

[Russell King - ARM Linux]

On Tue, Aug 26, 2014 at 12:10:00PM -0400, jonsm...@gmail.com wrote:
> As a side effect this will eliminate the need for kernel command line
> parameters describing boot state. Like console="". Over time it might
> even be able to pass a DHCP IP address from uboot into the kernel.

Err no.  Don't even think about that.  DHCP may be wonderful and all,
but there's a fundamental issue with it: entries time out unless they
are renewed.

Why is that a problem?  Well, take a DHCP server which hands out
dynamic addresses, and updates the DNS.  When the lease expires, it
tears down the DNS entry.

Now take a target booting using DHCP in uboot, which then mounts its
root NFS.  If it tries to startup a DHCP client, the first thing the
DHCP client does is to clean up the interface... resulting in it
killing the root NFS connection.  If that doesn't happen, then you
end up with a problem at shutdown, because DHCP clients always
deconfigure the interface when they're killed off - resulting in
"reboot" not being functional.

Here, I run exactly that setup, and I have found that ubuntu suffers
quite a bit from problems if you don't tell it to keep its fingers
off the ethernet device configuration when running root-NFS - and
believe me, when I'm working on something, I probably do several
tens of remote reboots of targets via "reboot" - I know I've done
about fifty today so far (many of them having to resort to the reset
button because the kernel seems to be locking up rather than rebooting
at the final stage.)

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 3/5] RTC: RK808: add RTC driver for RK808

[Doug Anderson]

Chris,

On Tue, Aug 26, 2014 at 7:14 AM, Chris Zhong  wrote:
> Adding RTC driver for supporting RTC device present inside RK808 PMIC.
>
> Signed-off-by: Chris Zhong 
> Signed-off-by: Zhang Qing 
>
> ---
>
> Changes in v6:
> Adviced by doug
> - move RTC_READSEL setting into probe
>
> Changes in v5:
> - fixed a bug about set_time failed
>
> Changes in v4:
> - use &client->dev replace rk808->dev
>
> Changes in v3: None
> Changes in v2:
> Adviced by javier.martinez
> - Add a separate clock driver, rather than in RTC driver
>
>  drivers/rtc/Kconfig |   10 ++
>  drivers/rtc/Makefile|1 +
>  drivers/rtc/rtc-rk808.c |  412 
> +++
>  3 files changed, 423 insertions(+)
>  create mode 100644 drivers/rtc/rtc-rk808.c
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index a168e96..aeab9d9 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -288,6 +288,16 @@ config RTC_DRV_MAX77686
>   This driver can also be built as a module. If so, the module
>   will be called rtc-max77686.
>
> +config RTC_DRV_RK808
> +   tristate "Rockchip RK808 RTC"
> +   depends on MFD_RK808
> +   help
> + If you say yes here you will get support for the
> + RTC of RK808 PMIC.
> +
> + This driver can also be built as a module. If so, the module
> + will be called rk808-rtc.
> +
>  config RTC_DRV_RS5C372
> tristate "Ricoh R2025S/D, RS5C372A/B, RV5C386, RV5C387A"
> help
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index 56f061c..91fe4647 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -109,6 +109,7 @@ obj-$(CONFIG_RTC_DRV_PUV3)  += rtc-puv3.o
>  obj-$(CONFIG_RTC_DRV_PXA)  += rtc-pxa.o
>  obj-$(CONFIG_RTC_DRV_R9701)+= rtc-r9701.o
>  obj-$(CONFIG_RTC_DRV_RC5T583)  += rtc-rc5t583.o
> +obj-$(CONFIG_RTC_DRV_RK808)+= rtc-rk808.o
>  obj-$(CONFIG_RTC_DRV_RP5C01)   += rtc-rp5c01.o
>  obj-$(CONFIG_RTC_DRV_RS5C313)  += rtc-rs5c313.o
>  obj-$(CONFIG_RTC_DRV_RS5C348)  += rtc-rs5c348.o
> diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk808.c
> new file mode 100644
> index 000..00cd997
> --- /dev/null
> +++ b/drivers/rtc/rtc-rk808.c
> @@ -0,0 +1,412 @@
> +/*
> + * RTC driver for Rockchip RK808
> + *
> + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* RTC_CTRL_REG bitfields */
> +#define BIT_RTC_CTRL_REG_STOP_RTC_MBIT(0)
> +#define BIT_RTC_CTRL_REG_RTC_READSEL_M BIT(7)
> +#define BIT_RTC_INTERRUPTS_REG_IT_ALARM_M  BIT(3)
> +#define RTC_STATUS_MASK0xFE
> +
> +#define SECONDS_REG_MSK0x7F
> +#define MINUTES_REG_MAK0x7F
> +#define HOURS_REG_MSK  0x3F
> +#define DAYS_REG_MSK   0x3F
> +#define MONTHS_REG_MSK 0x1F
> +#define YEARS_REG_MSK  0xFF
> +#define WEEKS_REG_MSK  0x7
> +
> +/* REG_SECONDS_REG through REG_YEARS_REG is how many registers? */
> +
> +#define NUM_TIME_REGS  (RK808_WEEKS_REG - RK808_SECONDS_REG + 1)
> +#define NUM_ALARM_REGS (RK808_ALARM_YEARS_REG - RK808_ALARM_SECONDS_REG + 1)
> +
> +struct rk808_rtc {
> +   struct rk808 *rk808;
> +   struct rtc_device *rtc;
> +   int irq;
> +};
> +
> +/* Read current time and date in RTC */
> +static int rk808_rtc_readtime(struct device *dev, struct rtc_time *tm)
> +{
> +   struct rk808_rtc *rk808_rtc = dev_get_drvdata(dev);
> +   struct rk808 *rk808 = rk808_rtc->rk808;
> +   u8 rtc_data[NUM_TIME_REGS];
> +   int ret;

As per other thread, at the beginning to readtime() you should set
BIT_RTC_CTRL_REG_RTC_READSEL_M to 1.  At the end of readtime() you
should set it to 0.  Make sure you set it back to 0 in the error
condition, too.


> +   ret = regmap_bulk_read(rk808->regmap, RK808_SECONDS_REG,
> +  rtc_data, NUM_TIME_REGS);
> +   if (ret) {
> +   dev_err(dev, "Failed to bulk read rtc_data: %d\n", ret);
> +   return ret;
> +   }
> +
> +   tm->tm_sec = bcd2bin(rtc_data[0] & SECONDS_REG_MSK);
> +   tm->tm_min = bcd2bin(rtc_data[1] & MINUTES_REG_MAK);
> +   tm->tm_hour = bcd2bin(rtc_data[2] & HOURS_REG_MSK);
> +   tm->tm_mday = bcd2bin(rtc_data[3] & DAYS_REG_MSK);
> +   tm->tm_mon = (bcd2bin(rtc_data[4] & MONTHS_REG_MSK)) - 1;
> +   tm->tm_year = (bcd2bin(rtc_data[5] & YEARS_REG_MSK)) + 100;
>

Re: [PATCH v5 3/5] RTC: RK808: add RTC driver for RK808

[Doug Anderson]

Chris,

On Tue, Aug 26, 2014 at 2:47 AM, Chris Zhong  wrote:
>
> On 08/26/2014 11:22 AM, Doug Anderson wrote:
>>>
>>> +   int ret;
>>> >+
>>> >+   /* Has the RTC been programmed? */
>>> >+   ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
>>> >+BIT_RTC_CTRL_REG_RTC_V_OPT_M, 0);
>>
>> Can you explain what you're doing here?  The comment seems wrong since
>> it implies that you're checking something.
>>
>> >From what I can tell from the manual you're setting "RTC_READSEL" to 0
>> which means "Read access directly to dynamic registers.".  That's not
>> clear here, and RTC_V_OPT_M makes no sense to me.
>
>
> RK808 has a shadowed register for saving a "frozen" RTC time.
> When user setting "RTC_READSEL" to 1, the time will save in this shadowed
> register.
> In this case, user read rtc time register, actually get the time of that
> moment.
> So, I move it to probe, this bit needn't clear every time

OK, now that I understand what BIT_RTC_CTRL_REG_RTC_READSEL_M is, I
think that we need it here.

At the beginning to readtime() you should set
BIT_RTC_CTRL_REG_RTC_READSEL_M to 1.  At the end of readtime() you
should set it to 0.  Make sure you set it back to 0 in the error
condition, too.

If you don't use READSEL you can get in confusing situations when
times wrap over.  Pretend that it's 11:59:59 when you start.  You read
the seconds.  Then the time ticks and you read the minutes and hours.
You'll end up reporting 12:00:59 when you really should report
12:00:00 or 11:59:59


>>> >+   tm->tm_min = bcd2bin(rtc_data[1]) & MINUTES_REG_MAK;
>>> >+   tm->tm_hour = bcd2bin(rtc_data[2]) & HOURS_REG_MSK;
>>> >+   tm->tm_mday = bcd2bin(rtc_data[3]) & DAYS_REG_MSK;
>>> >+   tm->tm_mon = (bcd2bin(rtc_data[4]) & MONTHS_REG_MSK) - 1;
>>> >+   tm->tm_year = (bcd2bin(rtc_data[5]) & YEARS_REG_MSK) + 100;
>>> >+   tm->tm_wday = bcd2bin(rtc_data[6]) & WEEKS_REG_MSK;
>>> >+   dev_dbg(dev, "RTC date/time %4d-%02d-%02d(%d) %02d:%02d:%02d\n",
>>> >+   1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
>>> >+   tm->tm_wday, tm->tm_hour , tm->tm_min, tm->tm_sec);
>>> >+
>>> >+   return 0;
>>> >+}
>>> >+
>>> >+/*
>>> >+ * Set current time and date in RTC
>>> >+ */
>>> >+static int rk808_rtc_set_time(struct device *dev, struct rtc_time *tm)
>>
>> Make this "const struct rtc_time *tm"
>
> It will be a warning if add const.
> It should be match
> int (*set_time)(struct device *, struct rtc_time *);
> in rtc.h

Oh, right.  Thanks.


>>> +   rk808_rtc_set_time(&pdev->dev, &tm_def);
>>> >+   }
>>> >+
>>> >+   device_init_wakeup(&pdev->dev, 1);
>>
>> You can skip this.  We'll set "wakeup-source" in the device tree.
>> That will set I2C_CLIENT_WAKE.  That will cause the i2c core to call
>> device_init_wakeup() for you.
>
> If I remove it, wakealarm is disappear, even though I add "wakeup-source" in
> device tree.
> So, I keep it temporarily

OK, I think I understand.  It's because MFD doesn't percolate things
down to the devices.  The main device is setup as a wakeup-source but
not this one.  I think you can leave it as you have it..


>>> +   if (IS_ERR(rk808_rtc->rtc)) {
>>> >+   ret = PTR_ERR(rk808_rtc->rtc);
>>> >+   return ret;
>>> >+   }
>>> >+
>>> >+   alm_irq  = platform_get_irq(pdev, 0);
>>
>> Are you sure that platform_get_irq() works in this case?  In Javier's
>> in-flight max77802 driver he use regmap_irq_get_virq().
>>
>> ...oh, maybe your way does work!  You've got the rtc_resources to
>> specify things, so that looks good...
>>
>> ...but I tried testing it by doing:
>>
>> cd /sys/class/rtc/rtc0
>> echo +2 > wakealarm
>> sleep 5
>> grep 808 /proc/interrupts
>>
>> ...and I didn't see an interrupt go off.  Any idea why?
>
> It works well.

I figured it out.  We need
.  Maybe you
have a different bootloader or some other code in your kernel that
made it so you didn't see the problem.  ...and it's better to change
the IRQ in the dts to "level low".

-Doug
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Generic communication of boot loader state to the OS

[jonsm...@gmail.com]

On Tue, Aug 26, 2014 at 1:16 PM, Mark Rutland  wrote:
> Hi Jon,
>
> On Tue, Aug 26, 2014 at 05:10:00PM +0100, jonsm...@gmail.com wrote:
>> New thread split off from the simple-framebuffer discussion
>>
>> Is there a generic, underlying problem here that needs to be solved?
>> AFAIK no one has designed a general purpose mechanism for
>> communicating boot loader state to the OS. There is the existing
>> device tree  node but it is limited compared to what is
>> needed. Maybe we should step back and first design a good solution to
>> this basic problem. Then specific solutions for things like
>> framebuffers would fall out of the basic design.
>
> I think the fundamental problem here is unfortunately far too abstract
> for the general solution to be any more concrete. The solution to "we
> don't communicate boot state" is "we should communicate boot state".
>
> We can perhaps come up with general guidelines (for instance, the clock
> subsystem has assigned-* properties), but I don't think there's a
> one-size-fits-all solution.
>
>> So what are the requirements?
>> 1) Indicate that the boot loader has set up a device
>> 2) Indicate the purpose of that device
>> 3) Protect the resources in use
>> 4) Provide for a handoff to the OS specific device driver
>> 5) Communicate all of this via the device tree
>>
>> So what is a device tree syntax that would solve this general problem?
>> As a first design attempt, I would propose  (or ) child
>> nodes be added to the various core devices. By core device I mean the
>> top level device, like the framebuffer, not each dependent clock and
>> regulator.
>>
>> Inside the  nodes a compatible string would be used to designate
>> a device class the bootloader has assigned to the devices. For example
>> - serial, framebuffer, media, input, network.
>
> In general we should already know the class of device if we have a
> driver for said device, no?
>
> As far as I can tell all we need to have is a way of designating
> preferred devices and their preferred/current configuration. We have
> bits of that already (e.g. stdout-path, assigned-rate).
>
>> Some examples, I've deleted a lot of properties to make them smaller.
>> The boot loader could add these nodes either statically or
>> dynamically.
>>
>> uart0: uart@01c18000 {
>> compatible = "allwinner,sun4i-a10-uart";
>> clocks = <&ahb_gates 20>, <&uart2_clk>;
>> clock-names = "ahb", "mod";
>> boot {
>> compatible = "boot,serial";
>> baud = <192000>;
>> console;
>>};
>> };
>
> There's already the stdout-path (and stdin-path) binding for designating
> a serial port. I think we should improve support for those rather than
> introducing a new binding. The only painful part is describing the
> pre-configured rate if the OS needs to know.
>
>> reserved-memory {
>> display_reserved: framebuffer@7800 {
>> reg = <0x7800 0x80>;
>> };
>> };
>>
>> fb0: fb@01c1 {
>> compatible = "allwinner,sun4i-a10-framebuffer";
>> clocks = <&ahb_gates 18>, <&fb2_clk>;
>> clock-names = "ahb", "mod";
>> boot {
>> compatible = "boot,framebuffer";
>> memory-region = <&display_reserved>;
>> };
>> };
>
> I was under the impression that the reserved-memory binding could be
> used for handing over the memory in use by a framebuffer, so as far as I
> can see we only new thing to communicate would be the configured mode of
> the display.
>
> Do we have any systems with multiple displays where we need to specify
> which is preferred?
>
>> spi1: spi@01c16000 {
>> compatible = "allwinner,sun4i-a10-spi";
>> clocks = <&ahb_gates 22>, <&spi2_clk>;
>> clock-names = "ahb", "mod";
>>
>> flash0: flash@2 {
>> compatible = "atmel,at12345";
>> reg = <2>;
>> spi-max-frequency = <10>;
>> boot {
>> compatible = "boot,media";
>> };
>> };
>> };
>
> Is this a problem on existing systems? Do we need a DT property?
>
> If so, this would be better as something like /chosen/root-device (so
> you can't accidentally describe multiple devices as the boot medium).
>
>> An OS booting off from a device tree like this can then implement
>> support for boot, drivers if it chooses. If it doesn't implement
>> support for the boot tags, nothing changes from the current situation.
>>
>> The problem with clocks and regulators can be addressed by following
>> the chains of clocks/regulators in the parent nodes of the boot
>> sections. This would be implement by these frameworks providing a
>> "claim_all_xxx(DT node)" function.  A boot,framebuffer driver would
>> first call claim_all_clk(parent node) and claim_all_regulator(parent
>> node). Need to figure out exactly how these functions would work.
>
> I'm not sure I follow. What is the problem with clocks and regulators

Re: [PATCH v6 4/5] clk: RK808: Add clkout driver for RK808

[Doug Anderson]

Chris,

On Tue, Aug 26, 2014 at 7:16 AM, Chris Zhong  wrote:
> Signed-off-by: Chris Zhong 
>
> ---
>
> Changes in v6:
> Adviced by doug
> - use correct argument call of_clk_add_provider in probe
>
> Changes in v5:
> Adviced by doug
> - add some error checking in probe
> - move "rockchip,rk808.h" into the patch about dt-bindings
>
> Changes in v4:
> Adviced by doug
> - add "clock-output-names" propertiey
> - add a header file "rockchip,rk808.h"
>
> Changes in v3:
> - fix compile err
>
> Changes in v2:
> Adviced by javier.martinez
> - separated from rtc-rk808.
>
>  drivers/clk/Kconfig |9 +++
>  drivers/clk/Makefile|1 +
>  drivers/clk/clk-rk808.c |  163 
> +++
>  3 files changed, 173 insertions(+)
>  create mode 100644 drivers/clk/clk-rk808.c
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index cfd3af7..84e0590 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -38,6 +38,15 @@ config COMMON_CLK_MAX77686
> ---help---
>   This driver supports Maxim 77686 crystal oscillator clock.
>
> +config COMMON_CLK_RK808
> +   tristate "Clock driver for RK808"
> +   depends on MFD_RK808
> +   ---help---
> + This driver supports RK808 crystal oscillator clock. These
> + multi-function devices have two fixed-rate oscillators,
> + clocked at 32KHz each. Clkout1 is always on, Clkout2 can off
> + by control register.
> +
>  config COMMON_CLK_SI5351
> tristate "Clock driver for SiLabs 5351A/B/C"
> depends on I2C
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index f537a0b..99f53d5 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -28,6 +28,7 @@ obj-$(CONFIG_ARCH_NOMADIK)+= clk-nomadik.o
>  obj-$(CONFIG_ARCH_NSPIRE)  += clk-nspire.o
>  obj-$(CONFIG_COMMON_CLK_PALMAS)+= clk-palmas.o
>  obj-$(CONFIG_CLK_PPC_CORENET)  += clk-ppc-corenet.o
> +obj-$(CONFIG_COMMON_CLK_RK808) += clk-rk808.o
>  obj-$(CONFIG_COMMON_CLK_S2MPS11)   += clk-s2mps11.o
>  obj-$(CONFIG_COMMON_CLK_SI5351)+= clk-si5351.o
>  obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o
> diff --git a/drivers/clk/clk-rk808.c b/drivers/clk/clk-rk808.c
> new file mode 100644
> index 000..21f8b54
> --- /dev/null
> +++ b/drivers/clk/clk-rk808.c
> @@ -0,0 +1,163 @@
> +/*
> + * Clkout driver for Rockchip RK808
> + *
> + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * Author: Chris Zhong 

I probably would have removed "Author" here (like in other patches)
since it's below in MODULE_AUTHOR.  ...but I'm not a huge stickler for
it.



> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct rk808_clkout {
> +   struct rk808 *rk808;
> +   struct clk_onecell_data clk_data;
> +   struct clk_hw   clkout1_hw;
> +   struct clk_hw   clkout2_hw;
> +};
> +
> +static unsigned long rk808_clkout_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> +   return 32768;
> +}
> +
> +static int rk808_clkout1_is_prepared(struct clk_hw *hw)
> +{
> +   return 1;
> +}
> +
> +static int rk808_clkout2_control(struct clk_hw *hw, bool enable)
> +{
> +   struct rk808_clkout *rk808_clkout = container_of(hw,
> +struct rk808_clkout,
> +clkout2_hw);
> +   struct rk808 *rk808 = rk808_clkout->rk808;
> +
> +   return regmap_update_bits(rk808->regmap, RK808_CLK32OUT_REG,
> + CLK32KOUT2_EN, enable ? CLK32KOUT2_EN : 0);
> +}
> +
> +static int rk808_clkout2_prepare(struct clk_hw *hw)
> +{
> +   return rk808_clkout2_control(hw, 1);

nit: I'd pass "true" instead of 1.  I should have noticed earlier.

> +}
> +
> +static void rk808_clkout2_unprepare(struct clk_hw *hw)
> +{
> +   rk808_clkout2_control(hw, 0);

nit: I'd pass "false" instead of 0.

> +}
> +
> +static int rk808_clkout2_is_prepared(struct clk_hw *hw)
> +{
> +   struct rk808_clkout *rk808_clkout = container_of(hw,
> +struct rk808_clkout,
> +clkout2_hw);
> +   struct rk808 *rk808 = rk808_clkout->rk808;
> +   uint32_t val;
> +
> +   int ret = regmap_read(rk8

Re: [PATCH v3 1/5] of: Add NVIDIA Tegra Legacy Interrupt Controller binding

[Stephen Warren]

On 08/26/2014 12:41 AM, Thierry Reding wrote:

From: Thierry Reding 

The Legacy Interrupt Controller found on NVIDIA Tegra SoCs is used by
the AVP coprocessor and can also serve as a backup for the ARM Cortex
CPU's local interrupt controller (GIC).

The LIC is subdivided into multiple identical units, each handling 32
possible interrupt sources.


If I apply this series without patch 2, which is necessary to test the 
support for compatibility with old DTs, then I get the following very 
early on in boot:


Other than that, I would apply this.


[0.00] Preemptible hierarchical RCU implementation.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] [ cut here ]
[0.00] WARNING: CPU: 0 PID: 0 at 
drivers/soc/tegra/fuse/tegra-apbmisc.c:42 tegra_get_chip_id+0x30/0x44()
[0.00] Tegra Chip ID not yet available
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
3.17.0-rc2-00016-g6a550998848e #32
[0.00] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[0.00] [] (show_stack) from [] 
(dump_stack+0x84/0xd0)
[0.00] [] (dump_stack) from [] 
(warn_slowpath_common+0x64/0x88)
[0.00] [] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
[0.00] [] (warn_slowpath_fmt) from [] 
(tegra_get_chip_id+0x30/0x44)
[0.00] [] (tegra_get_chip_id) from [] 
(tegra_init_irq+0xb0/0x2d0)
[0.00] [] (tegra_init_irq) from [] 
(tegra_dt_init_irq+0x8/0x14)
[0.00] [] (tegra_dt_init_irq) from [] 
(init_IRQ+0x28/0x7c)
[0.00] [] (init_IRQ) from [] 
(start_kernel+0x21c/0x3a8)
[0.00] [] (start_kernel) from [<80008074>] (0x80008074)
[0.00] ---[ end trace cb88537fdc8fa200 ]---
[0.00] [ cut here ]
[0.00] WARNING: CPU: 0 PID: 0 at arch/arm/mach-tegra/irq.c:343 
tegra_init_irq+0x184/0x2d0()
[0.00] Found 5 interrupt controllers; expected 4.
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW  
3.17.0-rc2-00016-g6a550998848e #32
[0.00] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[0.00] [] (show_stack) from [] 
(dump_stack+0x84/0xd0)
[0.00] [] (dump_stack) from [] 
(warn_slowpath_common+0x64/0x88)
[0.00] [] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
[0.00] [] (warn_slowpath_fmt) from [] 
(tegra_init_irq+0x184/0x2d0)
[0.00] [] (tegra_init_irq) from [] 
(tegra_dt_init_irq+0x8/0x14)
[0.00] [] (tegra_dt_init_irq) from [] 
(init_IRQ+0x28/0x7c)
[0.00] [] (init_IRQ) from [] 
(start_kernel+0x21c/0x3a8)
[0.00] [] (start_kernel) from [<80008074>] (0x80008074)
[0.00] ---[ end trace cb88537fdc8fa201 ]---

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] of: Add NVIDIA Tegra flow controller bindings

[Stephen Warren]

On 08/26/2014 12:14 AM, Thierry Reding wrote:

From: Thierry Reding 

Add device tree bindings for the flow controller found on NVIDIA Tegra
SoCs.


I have applied patches 1,3 to Tegra's for-3.18/soc branch, and patch 2 
to Tegra's for-3.18/dt branch.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: Add rk808 PMIC to rk3288-evb-rk808

[Doug Anderson]

This adds initial support.  For now, regulators are always on and we
don't specify the input supply for all of the regulators.

Signed-off-by: huang lin 
Signed-off-by: Doug Anderson 
---
This patch is based on Chris's WIP rk808 series.

 arch/arm/boot/dts/rk3288-evb-rk808.dts | 131 +
 1 file changed, 131 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-evb-rk808.dts 
b/arch/arm/boot/dts/rk3288-evb-rk808.dts
index 9a88b6c..513c88e 100644
--- a/arch/arm/boot/dts/rk3288-evb-rk808.dts
+++ b/arch/arm/boot/dts/rk3288-evb-rk808.dts
@@ -16,3 +16,134 @@
 / {
compatible = "rockchip,rk3288-evb-rk808", "rockchip,rk3288";
 };
+
+&i2c0 {
+   status = "okay";
+
+   rk808: pmic@1b {
+   compatible = "rockchip,rk808";
+   clock-output-names = "xin32k", "rk808-clkout2";
+   interrupt-parent = <&gpio0>;
+   interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pmic_int>;
+   reg = <0x1b>;
+   rockchip,system-power-controller;
+   wakeup-source;
+   #clock-cells = <1>;
+
+   vcc8-supply = <&vcc_18>;
+   vcc9-supply = <&vcc_io>;
+   vcc10-supply = <&vcc_io>;
+   vcc12-supply = <&vcc_io>;
+   vddio-supply = <&vccio_pmu>;
+
+   regulators {
+   vdd_cpu: DCDC_REG1 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <75>;
+   regulator-max-microvolt = <130>;
+   regulator-name = "vdd_arm";
+   };
+
+   vdd_gpu: DCDC_REG2 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <85>;
+   regulator-max-microvolt = <125>;
+   regulator-name = "vdd_gpu";
+   };
+
+   vcc_ddr: DCDC_REG3 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-name = "vcc_ddr";
+   };
+
+   vcc_io: DCDC_REG4 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc_io";
+   };
+
+   vccio_pmu: LDO_REG1 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vccio_pmu";
+   };
+
+   vcc_tp: LDO_REG2 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc_tp";
+   };
+
+   vdd_10: LDO_REG3 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <100>;
+   regulator-name = "vdd_10";
+   };
+
+   vcc18_lcd: LDO_REG4 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-name = "vcc18_lcd";
+   };
+
+   vccio_sd: LDO_REG5 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vccio_sd";
+   };
+
+   vdd10_lcd: LDO_REG6 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <100>;
+   regulator-name = "vdd10

Re: [PATCH v2 2/5] MFD: RK808: Add new mfd driver for RK808

[Doug Anderson]

Hi,

On Tue, Aug 26, 2014 at 9:28 AM, Dmitry Torokhov
 wrote:
> Hi Lee,
>
> On Tue, Aug 26, 2014 at 10:22:05AM +0100, Lee Jones wrote:
>> On Mon, 25 Aug 2014, Chris Zhong wrote:
>> > On 08/20/2014 05:21 PM, Lee Jones wrote:
>> > >On Wed, 20 Aug 2014, Chris Zhong wrote:
>> > >
>> > >>The RK808 chip is a power management IC for multimedia and handheld
>> > >>devices. It contains the following components:
>> > >>
>> > >>- Regulators
>> > >>- RTC
>> > >>
>> > >>The rk808 core driver is registered as a platform driver and provides
>> > >>communication through I2C with the host device for the different
>> > >>components.
>> > >>
>> > >>Signed-off-by: Chris Zhong 
>> > >>---
>>
>> [...]
>>
>> > >>+ rk808->pdata = pdata;
>> > >Remove pdata from 'struct rk808'.  You can obtain it from dev.
>> >
>> > Can I keep this pdata in rk808, because it is used in the regulator driver.
>> > The one obtain from dev maybe empty.
>>
>> If the one in dev is empty, you should populate that instead.
>
> No, drivers should not populate platform data in devices - they do not
> own it (unlike drvdata). Platform data should be read-only so that if
> one would unbind and then try to re-bind the driver we'd end up in
> exactly same state as before.
>
> For DT systems we should be allocating platform data separately and make
> sure we clean up after ourselves.

Given Dmitry's advice it seems like Chris's old code (allocate pdata
and store it in the driver's private structures) was correct.  That
also seems to match what I've seen other drivers do.

Of course what Chris ended up doing was basically saying that "device
tree" is required for rk808 and that you can't pass data into the
driver using pdata (at least in v6 you can't specify
"rockchip,system-power-controller" unless you're using device tree).
To me that doesn't seem terrible.  ...though he should probably finish
what he started by:

* Moving "struct rk808_board" so it's private to the regulator .c file

* Don't even pretend you can get stuff from dev_get_platdata() in
rk808-regulator.c

* Add a dependency on "OF" in the Kconfig for rk808.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Generic communication of boot loader state to the OS

[Mark Rutland]

Hi Jon,

On Tue, Aug 26, 2014 at 05:10:00PM +0100, jonsm...@gmail.com wrote:
> New thread split off from the simple-framebuffer discussion
> 
> Is there a generic, underlying problem here that needs to be solved?
> AFAIK no one has designed a general purpose mechanism for
> communicating boot loader state to the OS. There is the existing
> device tree  node but it is limited compared to what is
> needed. Maybe we should step back and first design a good solution to
> this basic problem. Then specific solutions for things like
> framebuffers would fall out of the basic design.

I think the fundamental problem here is unfortunately far too abstract
for the general solution to be any more concrete. The solution to "we
don't communicate boot state" is "we should communicate boot state".

We can perhaps come up with general guidelines (for instance, the clock
subsystem has assigned-* properties), but I don't think there's a
one-size-fits-all solution.

> So what are the requirements?
> 1) Indicate that the boot loader has set up a device
> 2) Indicate the purpose of that device
> 3) Protect the resources in use
> 4) Provide for a handoff to the OS specific device driver
> 5) Communicate all of this via the device tree
> 
> So what is a device tree syntax that would solve this general problem?
> As a first design attempt, I would propose  (or ) child
> nodes be added to the various core devices. By core device I mean the
> top level device, like the framebuffer, not each dependent clock and
> regulator.
> 
> Inside the  nodes a compatible string would be used to designate
> a device class the bootloader has assigned to the devices. For example
> - serial, framebuffer, media, input, network.

In general we should already know the class of device if we have a
driver for said device, no?

As far as I can tell all we need to have is a way of designating
preferred devices and their preferred/current configuration. We have
bits of that already (e.g. stdout-path, assigned-rate).

> Some examples, I've deleted a lot of properties to make them smaller.
> The boot loader could add these nodes either statically or
> dynamically.
> 
> uart0: uart@01c18000 {
> compatible = "allwinner,sun4i-a10-uart";
> clocks = <&ahb_gates 20>, <&uart2_clk>;
> clock-names = "ahb", "mod";
> boot {
> compatible = "boot,serial";
> baud = <192000>;
> console;
>};
> };

There's already the stdout-path (and stdin-path) binding for designating
a serial port. I think we should improve support for those rather than
introducing a new binding. The only painful part is describing the
pre-configured rate if the OS needs to know.

> reserved-memory {
> display_reserved: framebuffer@7800 {
> reg = <0x7800 0x80>;
> };
> };
> 
> fb0: fb@01c1 {
> compatible = "allwinner,sun4i-a10-framebuffer";
> clocks = <&ahb_gates 18>, <&fb2_clk>;
> clock-names = "ahb", "mod";
> boot {
> compatible = "boot,framebuffer";
> memory-region = <&display_reserved>;
> };
> };

I was under the impression that the reserved-memory binding could be
used for handing over the memory in use by a framebuffer, so as far as I
can see we only new thing to communicate would be the configured mode of
the display.

Do we have any systems with multiple displays where we need to specify
which is preferred?

> spi1: spi@01c16000 {
> compatible = "allwinner,sun4i-a10-spi";
> clocks = <&ahb_gates 22>, <&spi2_clk>;
> clock-names = "ahb", "mod";
> 
> flash0: flash@2 {
> compatible = "atmel,at12345";
> reg = <2>;
> spi-max-frequency = <10>;
> boot {
> compatible = "boot,media";
> };
> };
> };

Is this a problem on existing systems? Do we need a DT property?

If so, this would be better as something like /chosen/root-device (so
you can't accidentally describe multiple devices as the boot medium).

> An OS booting off from a device tree like this can then implement
> support for boot, drivers if it chooses. If it doesn't implement
> support for the boot tags, nothing changes from the current situation.
> 
> The problem with clocks and regulators can be addressed by following
> the chains of clocks/regulators in the parent nodes of the boot
> sections. This would be implement by these frameworks providing a
> "claim_all_xxx(DT node)" function.  A boot,framebuffer driver would
> first call claim_all_clk(parent node) and claim_all_regulator(parent
> node). Need to figure out exactly how these functions would work.

I'm not sure I follow. What is the problem with clocks and regulators
that this tries to solve?

Are we just trying to leave them in their current configuration (rather
than disabling)? Are we trying to prevent other drivers from fiddling
with them? Something else

Re: [PATCH v6 2/5] MFD: RK808: Add new mfd driver for RK808

[Doug Anderson]

Chris,

On Tue, Aug 26, 2014 at 7:14 AM, Chris Zhong  wrote:
> +static struct regmap_irq_chip rk808_irq_chip = {
> +   .name = "rk808",
> +   .irqs = rk808_irqs,
> +   .num_irqs = ARRAY_SIZE(rk808_irqs),
> +   .num_regs = 2,
> +   .irq_reg_stride = 2,
> +   .status_base = RK808_INT_STS_REG1,
> +   .mask_base = RK808_INT_STS_MSK_REG1,
> +   .ack_base = RK808_INT_STS_REG1,

Can you add ".init_ack_masked = true" here?  If I don't do that and I
boot with the IRQ configured as "level low" then the system will just
keep getting IRQs that it can't handle and eventually disable the
whole rk808.  If I boot with the IRQ as "falling edge" then the system
will never get RTC alarms.

I posted this fixup with an explanation at
 and it could be
squashed into your patch.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 27/27] OMAPDSS: connector-analog-tv: Add DT support

[Laurent Pinchart]

Hi Tomi,

On Monday 16 December 2013 16:56:34 Tomi Valkeinen wrote:
> Signed-off-by: Tomi Valkeinen 
> ---
>  .../video/omap2/displays-new/connector-analog-tv.c | 66 ++-
>  1 file changed, 65 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/video/omap2/displays-new/connector-analog-tv.c
> b/drivers/video/omap2/displays-new/connector-analog-tv.c index
> ccd9073f706f..ebed25a86487 100644
> --- a/drivers/video/omap2/displays-new/connector-analog-tv.c
> +++ b/drivers/video/omap2/displays-new/connector-analog-tv.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> @@ -42,6 +43,12 @@ static const struct omap_video_timings tvc_pal_timings =
> { .interlace  = true,
>  };
> 
> +static const struct of_device_id tvc_of_match[];
> +
> +struct tvc_of_data {
> + enum omap_dss_venc_type connector_type;
> +};
> +
>  #define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
> 
>  static int tvc_connect(struct omap_dss_device *dssdev)
> @@ -92,7 +99,10 @@ static int tvc_enable(struct omap_dss_device *dssdev)
>   in->ops.atv->set_timings(in, &ddata->timings);
> 
>   in->ops.atv->set_type(in, ddata->connector_type);
> - in->ops.atv->invert_vid_out_polarity(in, ddata->invert_polarity);
> +
> + if (!ddata->dev->of_node)
> + in->ops.atv->invert_vid_out_polarity(in,
> + ddata->invert_polarity);
> 
>   r = in->ops.atv->enable(in);
>   if (r)
> @@ -205,6 +215,35 @@ static int tvc_probe_pdata(struct platform_device
> *pdev) return 0;
>  }
> 
> +static int tvc_probe_of(struct platform_device *pdev)
> +{
> + struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> + struct device_node *node = pdev->dev.of_node;
> + struct omap_dss_device *in;
> + const struct of_device_id *match;
> + const struct tvc_of_data *data;
> +
> + match = of_match_node(tvc_of_match, pdev->dev.of_node);
> + if (!match) {
> + dev_err(&pdev->dev, "unsupported device\n");
> + return -ENODEV;
> + }
> +
> + data = match->data;
> +
> + in = omapdss_of_find_source_for_first_ep(node);
> + if (IS_ERR(in)) {
> + dev_err(&pdev->dev, "failed to find video source\n");
> + return PTR_ERR(in);
> + }
> +
> + ddata->in = in;
> +
> + ddata->connector_type = data->connector_type;
> +
> + return 0;
> +}
> +
>  static int tvc_probe(struct platform_device *pdev)
>  {
>   struct panel_drv_data *ddata;
> @@ -222,6 +261,10 @@ static int tvc_probe(struct platform_device *pdev)
>   r = tvc_probe_pdata(pdev);
>   if (r)
>   return r;
> + } else if (pdev->dev.of_node) {
> + r = tvc_probe_of(pdev);
> + if (r)
> + return r;
>   } else {
>   return -ENODEV;
>   }
> @@ -263,12 +306,33 @@ static int __exit tvc_remove(struct platform_device
> *pdev) return 0;
>  }
> 
> +static const struct tvc_of_data tv_svideo_data = {
> + .connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
> +};
> +
> +static const struct tvc_of_data tv_composite_video_data = {
> + .connector_type = OMAP_DSS_VENC_TYPE_COMPOSITE,
> +};
> +
> +static const struct of_device_id tvc_of_match[] = {
> + {
> + .compatible = "svideo-connector",
> + .data = &tv_svideo_data,
> + },
> + {
> + .compatible = "composite-video-connector",

I've just noticed that this doesn't match the bindings that document the 
compatible value to be "composite-connector".

> + .data = &tv_composite_video_data,
> + },
> + {},
> +};
> +
>  static struct platform_driver tvc_connector_driver = {
>   .probe  = tvc_probe,
>   .remove = __exit_p(tvc_remove),
>   .driver = {
>   .name   = "connector-analog-tv",
>   .owner  = THIS_MODULE,
> + .of_match_table = tvc_of_match,
>   },
>  };

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/5] MFD: RK808: Add new mfd driver for RK808

[Doug Anderson]

Lee,

On Tue, Aug 26, 2014 at 1:32 AM, Lee Jones  wrote:
> On Mon, 25 Aug 2014, Doug Anderson wrote:
>> On Mon, Aug 25, 2014 at 6:31 AM, Chris Zhong  wrote:
>> > The RK808 chip is a power management IC for multimedia and handheld
>> > devices. It contains the following components:
>> >
>> > - Regulators
>> > - RTC
>> >
>> > The RK808 core driver is registered as a platform driver and provides
>> > communication through I2C with the host device for the different
>> > components.
>> >
>> > Signed-off-by: Chris Zhong 
>>
>> You need a Signed-off-by: Zhang Qing 
>>
>> > ---
>
> [...]
>
>> > +static struct rk808 *g_rk808;
>>
>> I think Lee's "Grim" comment here was that prefixing globals with "g_"
>> is not consistent with the Linux coding style.  Just remove the "g_".
>
> That and the seemingly unavoidable use of a global pointer.
>
> [...]
>
>> > +static const struct i2c_device_id rk808_ids[] = {
>> > +{ "rk808", 0 },
>>
>> I think Lee wanted the above to be:
>>
>>{ "rk808", },
>
> Right, but the ',' is now superfluous.

Yeah, I debated that.  Generally I like to have commas at the end just
like a like a semicolon at the end of the final statement (C requires
this, but other languages don't).  Anyway, neither here nor there.  ;)
 I'm happy having the comma removed.


> [...]
>
>> I didn't do a thorough review, just compared to Lee's old feedback.
>> Maybe a good idea to get in the habit to responding to others comments
>> with "Done" so others know you have addressed each comment?
>
> Please only do this locally or in your head.  Reading replies to
> reviews containing only a break-down of what has been fixed is a waste
> of everyone's time.  If/when replying to comments/observations that
> you do _not_ agree with, please snip out all of the ones that you _do_
> agree with.

Sorry for suggesting.  I actually find even an email filled with
nothing but "Done" helpful.  It give me a warm fuzzy that the person
spinning the code _actually_ looked at all the comments (and didn't
miss something).

...but it's really up to you.  If you hate the "Done"s then Chris
certainly shouldn't send them.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] dt-bindings: document Rockchip thermal

[Caesar Wang]

Heiko,
在 2014/8/24 7:03, Heiko Stübner 写道:

Hi Caesar,

Am Samstag, 23. August 2014, 08:15:33 schrieb Caesar Wang:

This add the necessary binding documentation for the thermal
found on Rockchip SoCs

Signed-off-by: zhaoyifeng 
Signed-off-by: Caesar Wang 
---
  .../bindings/thermal/rockchip-thermal.txt  |   33
 1 file changed, 33 insertions(+)
  create mode 100644
Documentation/devicetree/bindings/thermal/rockchip-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt new file
mode 100644
index 000..b556eae
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -0,0 +1,33 @@
+* Temperature Sensor ADC (TSADC) on rockchip SoCs
+
+Required properties:
+- compatible : "rockchip,rk3288-tsadc"
+- reg : physical base address of the controller and length of memory mapped
+  region.
+- interrupts : The interrupt number to the cpu. The interrupt specifier
format +  depends on the interrupt controller.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Shall be "tsadc_clk" for the transfer-clock, and
"tsadc_pclk" for +the peripheral clock.
+Optional properties:
+- clock-frequency : Thermal sensor's clock frequency.

see comment in patch2, this should probably use assigned-rate if at all
necessary (and the assigned-rate is not necessary to document here)



+- pinctrl-names : Should contain only one value - "default".
+- pinctrl-0 : Should contain only one value - &tsadc_int.

in general pinctrl settings are just board-specific settings and do not
need to be part of the binding documentation.
And in this case, are you sure that the tsadc uses some pin as interrupt?
Because in the TRM the TS-ADC interrupt is number 69 of the GIC itself
and not some pin accessible via pinctrl.



+- passive-temp : Temperature of trip 0.
+- critical-temp : Temperature of trip 1.
+- force-shut-temp : Temperature of force shut down.

please use the generic trip-points described in
Documentation/devicetree/bindings/thermal/thermal.txt
for this, instead of defining new properties


There are have 4 trip-points mode in thermal.txt.
It's ACTIVE、PASSAIVE、 HOT and  CRITICAL.

Do you have some suggestion for fix it if I need add shut-temp mode ?

- Caesar


Heiko


+Example:
+
+tsadc: tsadc@ff28 {
+   compatible = "rockchip,rk3288-tsadc";
+   reg = <0xff28 0x100>;
+   interrupts = ;
+   clock-frequency = <1>;
+   clocks = <&cru SCLK_TSADC>, <&cru PCLK_TSADC>;
+   clock-names = "tsadc_clk", "tsadc_pclk";
+   pinctrl-names = "default";
+   pinctrl-1 = <&tsadc_int>;
+   passive-temp = <80>;
+   critical-temp = <100>;
+   force-shut-temp = <120>;
+};






--
Best regards,
Caesar


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH v3] clk: shmobile: div6: support selectable-input clocks

[Laurent Pinchart]

Hi Ulrich,

Thank you for the patch.

On Tuesday 26 August 2014 17:11:18 Ulrich Hecht wrote:
> Adds support for DIV6 clocks with selectable parents as found in the
> r8a73a4, r8a7740, sh73a0, and other SoCs.

I find the commit message a bit misleading, it made me assume the patch added 
support for selecting the input at runtime, which it doesn't. How about 
something along the lines of "Add support for selecting the DIV6 parent at 
initialization time based on the current hardware configuration" ?

Please see below for a couple of minor comments.

> Signed-off-by: Ulrich Hecht 
> ---
> 
> Changes since v2:
> - add r8a73a4 to bindings
> - use u32 where appropriate
> - don't split error message
> 
> Changes since v1:
> - make sure unrelated register bits are preserved
> - use the plural for the clocks property in bindings
> 
>  .../bindings/clock/renesas,cpg-div6-clocks.txt | 12 +++-
>  drivers/clk/shmobile/clk-div6.c| 32 +++
>  2 files changed, 37 insertions(+), 7 deletions(-)
> 
> diff --git
> a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt
> b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt index
> 952e373..b002d2b 100644
> --- a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt
> +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt
> @@ -7,14 +7,24 @@ to 64.
>  Required Properties:
> 
>- compatible: Must be one of the following
> +- "renesas,r8a73a4-div6-clock" for R8A73A4 (R-Mobile APE6) DIV6 clocks
> +- "renesas,r8a7740-div6-clock" for R8A7740 (R-Mobile A1) DIV6 clocks
>  - "renesas,r8a7790-div6-clock" for R8A7790 (R-Car H2) DIV6 clocks
>  - "renesas,r8a7791-div6-clock" for R8A7791 (R-Car M2) DIV6 clocks
> +- "renesas,sh73a0-div6-clock" for SH73A0 (SH-MobileAG5) DIV6 clocks
>  - "renesas,cpg-div6-clock" for generic DIV6 clocks
>- reg: Base address and length of the memory resource used by the DIV6
> clock
> -  - clocks: Reference to the parent clock
> +  - clocks: Reference to the parent clock(s)
>- #clock-cells: Must be 0
>- clock-output-names: The name of the clock as a free-form string
> 
> +Optional Properties:
> +
> +  - renesas,src-shift: Bit position of the input clock selector (default:
> +fixed input clock)
> +  - renesas,src-width: Bit width of the input clock selector (default:
> fixed
> +input clock)

Should we mention that if one of the properties is set then the other must be 
set as well ?

If I'm not mistaken those properties don't apply to the H2 and M2 CPGs. Should 
that be mentioned in the bindings ?

> +
> 
>  Example
>  ---
> diff --git a/drivers/clk/shmobile/clk-div6.c
> b/drivers/clk/shmobile/clk-div6.c index f065f69..2282bec 100644
> --- a/drivers/clk/shmobile/clk-div6.c
> +++ b/drivers/clk/shmobile/clk-div6.c
> @@ -38,9 +38,12 @@ struct div6_clock {
> 
>  static int cpg_div6_clock_enable(struct clk_hw *hw)
>  {
> + u32 val;
>   struct div6_clock *clock = to_div6_clock(hw);

Could you please reverse the order of those two lines to match the coding 
style of the file ? I tend to sort local variables in "reverse christmas tree" 
order.

> - clk_writel(CPG_DIV6_DIV(clock->div - 1), clock->reg);
> + val = (clk_readl(clock->reg) & ~(CPG_DIV6_DIV_MASK | CPG_DIV6_CKSTP))
> + | CPG_DIV6_DIV(clock->div - 1);

Could you please align the | under the = ?

> + clk_writel(val, clock->reg);
> 
>   return 0;
>  }
> @@ -52,8 +55,8 @@ static void cpg_div6_clock_disable(struct clk_hw *hw)
>   /* DIV6 clocks require the divisor field to be non-zero when stopping
>* the clock.
>*/
> - clk_writel(CPG_DIV6_CKSTP | CPG_DIV6_DIV(CPG_DIV6_DIV_MASK),
> -clock->reg);
> + clk_writel(clk_readl(clock->reg) | CPG_DIV6_CKSTP | CPG_DIV6_DIV_MASK,
> + clock->reg);

Could you please align the clock under the clk_read ?

>  }
> 
>  static int cpg_div6_clock_is_enabled(struct clk_hw *hw)
> @@ -94,12 +97,14 @@ static int cpg_div6_clock_set_rate(struct clk_hw *hw,
> unsigned long rate, {
>   struct div6_clock *clock = to_div6_clock(hw);
>   unsigned int div = cpg_div6_clock_calc_div(rate, parent_rate);
> + u32 val;
> 
>   clock->div = div;
> 
> + val = clk_readl(clock->reg) & ~CPG_DIV6_DIV_MASK;
>   /* Only program the new divisor if the clock isn't stopped. */
> - if (!(clk_readl(clock->reg) & CPG_DIV6_CKSTP))
> - clk_writel(CPG_DIV6_DIV(clock->div - 1), clock->reg);
> + if (!(val & CPG_DIV6_CKSTP))
> + clk_writel(val | CPG_DIV6_DIV(clock->div - 1), clock->reg);
> 
>   return 0;
>  }
> @@ -121,6 +126,7 @@ static void __init cpg_div6_clock_init(struct
> device_node *np) const char *name;
>   struct clk *clk;
>   int ret;
> + u32 src_shift, src_width;

Same comment here, could you please split the declaration on two lines and 
move them above int ret ?

>   clock = kzalloc(sizeof

Re: [PATCH v2 2/5] MFD: RK808: Add new mfd driver for RK808

[Dmitry Torokhov]

Hi Lee,

On Tue, Aug 26, 2014 at 10:22:05AM +0100, Lee Jones wrote:
> On Mon, 25 Aug 2014, Chris Zhong wrote:
> > On 08/20/2014 05:21 PM, Lee Jones wrote:
> > >On Wed, 20 Aug 2014, Chris Zhong wrote:
> > >
> > >>The RK808 chip is a power management IC for multimedia and handheld
> > >>devices. It contains the following components:
> > >>
> > >>- Regulators
> > >>- RTC
> > >>
> > >>The rk808 core driver is registered as a platform driver and provides
> > >>communication through I2C with the host device for the different
> > >>components.
> > >>
> > >>Signed-off-by: Chris Zhong 
> > >>---
> 
> [...]
> 
> > >>+ rk808->pdata = pdata;
> > >Remove pdata from 'struct rk808'.  You can obtain it from dev.
> > 
> > Can I keep this pdata in rk808, because it is used in the regulator driver.
> > The one obtain from dev maybe empty.
> 
> If the one in dev is empty, you should populate that instead.

No, drivers should not populate platform data in devices - they do not
own it (unlike drvdata). Platform data should be read-only so that if
one would unbind and then try to re-bind the driver we'd end up in
exactly same state as before.

For DT systems we should be allocating platform data separately and make
sure we clean up after ourselves.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 0/5] Add rockchip RK808 pmic driver

[Lee Jones]

On Tue, 26 Aug 2014, Chris Zhong wrote:
> This is the initial version of the RK808 PMIC. This is a power management IC
> for multimedia products.
> 
> It provides regulators that are able to supply power to processor cores
> and other components. The chip provides other modules including RTC, Clockout
> 
> Chris Zhong (5):
>   dt-bindings: Add RK808 device tree bindings document
>   MFD: RK808: Add new mfd driver for RK808
>   RTC: RK808: add RTC driver for RK808
>   clk: RK808: Add clkout driver for RK808
>   regulator: RK808: remove redundant code

You're still sending your sets un-threaded.  Please see the `git
send-email` help for information on how to do that.  It makes things
so much easier to cross-reference if the patches stay together in ones
INBOX.

>  Documentation/devicetree/bindings/mfd/rk808.txt |  150 +
>  drivers/clk/Kconfig |9 +
>  drivers/clk/Makefile|1 +
>  drivers/clk/clk-rk808.c |  163 +
>  drivers/mfd/Kconfig |   13 +
>  drivers/mfd/Makefile|1 +
>  drivers/mfd/rk808.c |  257 ++
>  drivers/regulator/rk808-regulator.c |   17 +-
>  drivers/rtc/Kconfig |   10 +
>  drivers/rtc/Makefile|1 +
>  drivers/rtc/rtc-rk808.c |  412 
> +++
>  include/dt-bindings/clock/rockchip,rk808.h  |   11 +
>  include/linux/mfd/rk808.h   |  202 +++
>  13 files changed, 1234 insertions(+), 13 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mfd/rk808.txt
>  create mode 100644 drivers/clk/clk-rk808.c
>  create mode 100644 drivers/mfd/rk808.c
>  create mode 100644 drivers/rtc/rtc-rk808.c
>  create mode 100644 include/dt-bindings/clock/rockchip,rk808.h
>  create mode 100644 include/linux/mfd/rk808.h
> 

-- 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/5] MFD: RK808: Add new mfd driver for RK808

[Lee Jones]

On Tue, 26 Aug 2014, Chris Zhong wrote:

[...]

> Well, it might be better to delete the pdata from MFD.

Bingo!  That's what I've been trying to get at.

-- 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Generic communication of boot loader state to the OS

[jonsm...@gmail.com]

New thread split off from the simple-framebuffer discussion

Is there a generic, underlying problem here that needs to be solved?
AFAIK no one has designed a general purpose mechanism for
communicating boot loader state to the OS. There is the existing
device tree  node but it is limited compared to what is
needed. Maybe we should step back and first design a good solution to
this basic problem. Then specific solutions for things like
framebuffers would fall out of the basic design.

So what are the requirements?
1) Indicate that the boot loader has set up a device
2) Indicate the purpose of that device
3) Protect the resources in use
4) Provide for a handoff to the OS specific device driver
5) Communicate all of this via the device tree

So what is a device tree syntax that would solve this general problem?
As a first design attempt, I would propose  (or ) child
nodes be added to the various core devices. By core device I mean the
top level device, like the framebuffer, not each dependent clock and
regulator.

Inside the  nodes a compatible string would be used to designate
a device class the bootloader has assigned to the devices. For example
- serial, framebuffer, media, input, network.

Some examples, I've deleted a lot of properties to make them smaller.
The boot loader could add these nodes either statically or
dynamically.

uart0: uart@01c18000 {
compatible = "allwinner,sun4i-a10-uart";
clocks = <&ahb_gates 20>, <&uart2_clk>;
clock-names = "ahb", "mod";
boot {
compatible = "boot,serial";
baud = <192000>;
console;
   };
};

reserved-memory {
display_reserved: framebuffer@7800 {
reg = <0x7800 0x80>;
};
};

fb0: fb@01c1 {
compatible = "allwinner,sun4i-a10-framebuffer";
clocks = <&ahb_gates 18>, <&fb2_clk>;
clock-names = "ahb", "mod";
boot {
compatible = "boot,framebuffer";
memory-region = <&display_reserved>;
};
};

spi1: spi@01c16000 {
compatible = "allwinner,sun4i-a10-spi";
clocks = <&ahb_gates 22>, <&spi2_clk>;
clock-names = "ahb", "mod";

flash0: flash@2 {
compatible = "atmel,at12345";
reg = <2>;
spi-max-frequency = <10>;
boot {
compatible = "boot,media";
};
};
};

An OS booting off from a device tree like this can then implement
support for boot, drivers if it chooses. If it doesn't implement
support for the boot tags, nothing changes from the current situation.

The problem with clocks and regulators can be addressed by following
the chains of clocks/regulators in the parent nodes of the boot
sections. This would be implement by these frameworks providing a
"claim_all_xxx(DT node)" function.  A boot,framebuffer driver would
first call claim_all_clk(parent node) and claim_all_regulator(parent
node). Need to figure out exactly how these functions would work.

Driver handoff is the OS's problem. Under Linux the device specific
drivers could soft-link to the boot,xxx code. After the device
specific driver is fully initialized it would tell the boot,xxx driver
to let go.

As a side effect this will eliminate the need for kernel command line
parameters describing boot state. Like console="". Over time it might
even be able to pass a DHCP IP address from uboot into the kernel.

This is just a first attempt, how can we improve on this?

-- 
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 2/2] ARM: dts: qcom: Enable serial port on IFC6540 boards

[Georgi Djakov]

Enable the serial port on the IFC6540 boards.

Signed-off-by: Georgi Djakov 
---
 arch/arm/boot/dts/qcom-apq8084-ifc6540.dts |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts 
b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
index 4603e91..e41cb8a 100644
--- a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
+++ b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
@@ -3,4 +3,10 @@
 / {
model = "Qualcomm APQ8084/IFC6540";
compatible = "qcom,apq8084-ifc6540", "qcom,apq8084";
+
+   soc {
+   serial@f995e000 {
+   status = "okay";
+   };
+   };
 };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 1/2] ARM: dts: qcom: Add initial IFC6540 board device tree

[Georgi Djakov]

Add initial device tree for the IFC6540 Snapdragon 805 pico-itx
single-board computer.

Signed-off-by: Georgi Djakov 
---
 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/qcom-apq8084-ifc6540.dts |6 ++
 2 files changed, 7 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-apq8084-ifc6540.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b022972..df8453a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -345,6 +345,7 @@ dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
 dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8064-ifc6410.dtb \
qcom-apq8074-dragonboard.dtb \
+   qcom-apq8084-ifc6540.dtb \
qcom-apq8084-mtp.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb
diff --git a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts 
b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
new file mode 100644
index 000..4603e91
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
@@ -0,0 +1,6 @@
+#include "qcom-apq8084.dtsi"
+
+/ {
+   model = "Qualcomm APQ8084/IFC6540";
+   compatible = "qcom,apq8084-ifc6540", "qcom,apq8084";
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 0/2] ARM: dts: qcom: Add initial IFC6540 board support

[Georgi Djakov]

Add basic support for the IFC6540 single-board computer boards, that are
based on the APQ8084 SoC. The first patch adds the initial device tree
and the second enables the serial console.

Should go through the qcom/arm-soc tree.

Georgi Djakov (2):
  ARM: dts: qcom: Add initial IFC6540 board device tree
  ARM: dts: qcom: Enable serial port on IFC6540 boards

 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/qcom-apq8084-ifc6540.dts |   12 
 2 files changed, 13 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-apq8084-ifc6540.dts

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/8] qcom: spm-devices: Add SPM device manager for the SoC

[Lina Iyer]

On Mon, Aug 25, 2014 at 07:17:15PM -0700, Stephen Boyd wrote:

On 08/25/14 17:31, Lina Iyer wrote:

On Mon, Aug 25, 2014 at 04:40:33PM -0700, Stephen Boyd wrote:

On 08/19/14 15:15, Lina Iyer wrote:

diff --git a/Documentation/devicetree/bindings/arm/msm/spm.txt
b/Documentation/devicetree/bindings/arm/msm/spm.txt
new file mode 100644
index 000..318e024
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/spm.txt


We already have a binding document for SAW. Please add stuff there
because SPM is just a component of SAW.


I agree that SPM is just a component of the SAW. But the document there
seems to indicate regulator details, totally unrelated to the actual SAW
hardware functionality.


Huh? The SAW binding should be extended with whatever properties are
necessary. Probably the only thing we need is the delays. Everything
else can be determined from the compatible?


Thats not true. There are many voltage related properties that are yet
to come. Not everything else can be determined from the compatible flag.
The idea behind having SPM nodes in the DT is that different SoCs may
have the same version of SPM but may have to talk to different
components. The delays, the PMIC register and the PMIC data all change
with the components that SPM communicates.


SAW has a connection to the PMIC, does it not? If it isn't directly
connected we can come up with a different name for the node, but just
because the node name in the example is misleading doesn't mean we
should completely disregard what we already have.


Yes the SAW has a connection to the PMIC. But what the nodes represent
are just regulator nodes and have no bearing on the SAW. You could use
SPMI/I2C writes to convey the same value without having to go through
SAW using those nodes. I have no reasonable understanding as to why they
are called SAW regulators in the first place. They are just regulators.
The mechanism of using SPM to communicate with the PMIC does not exist
in the kernel and is not part of those nodes. So adding to that
confusion wasn't a wise choice for me.




@@ -0,0 +1,47 @@
+* Subsystem Power Manager (SAW2)
+
+S4 generation of MSMs have SPM hardware blocks to control the
Application
+Processor Sub-System power. These SPM blocks run individual state
machine
+to determine what the core (L2 or Krait/Scorpion) would do when the
WFI
+instruction is executed by the core.
+
+The devicetree representation of the SPM block should be:
+
+Required properties
+
+- compatible: Could be one of -
+"qcom,spm-v2.1"
+"qcom,spm-v3.0"
+- reg: The physical address and the size of the SPM's memory mapped
registers
+- qcom,cpu: phandle for the CPU that the SPM block is attached to.
+This field is required on only for SPMs that control the CPU.


We have a phandle from the CPU/L2 to the SAW, so this isn't necessary.


Sorry, I dont understand. Care to explain pls? Its necessary to know
what SPM instance controls which CPU or L2, so as to pick the right SPM
device to configure.


We have a phandle in the CPU nodes pointing to the SAW that is
associated with that CPU (qcom,saw). SPM is a part of a SAW. Thus there
is no need for this qcom,cpu property once the SAW node is used.
Instead, we can search the CPU and cache nodes for a qcom,saw that
matches the of_node for the platform device we're probing.


I agree thats doable. The cpu node can point to the SPM node or the
otherway as it is done here. I dont have a strong preference eitherway.
Lets resolve the earlier and we may have a solution for this, in our
hands.




+- qcom,saw2-cfg: SAW2 configuration register


Why? Compatible should indicate where this register is.


There are multiple versions of saw handled by the same driver and
distinguished by the version register. These SAW revisions differ in the
register offset organization. The variable holds the value to be
configured in the saw2-cfg register. I will update the documentation to
be more clear.

+- qcom,saw2-spm-ctl: The SPM control register


Why? Compatible should indicate where this register is.


See above.


Ah this is more register jam table in DT? cfg should probably be
described in desired clock rate and then the driver can figure out the
value by multiplying that the input clock rate. spm-ctl looks like it's
usually used to describe "enable", which seems rather obvious. Why isn't
the driver always writing the enable bit (bit 0)?


Kumar already had suggested that. I changed the code, but forgot to
update the documentation, which I noticed and amended in my local tree.
Waiting for some more comments and some changes in cpuidle stuff before
I submit the next rev. Thanks.
That said, figuring out the input clock rate and the multiplication is
still unnecessary. There are not much options on the hardware to change
clock rate and different parameters that will work well on a SoC. SPMs
are generic state machines and are designed to support multiple QCOM
SoCs and hence the configuration options. They dont gener

Re: [PATCH v8 3/3] ahci_xgene: Fix the link down in first attempt for the APM X-Gene SoC AHCI SATA host controller driver.

[Tejun Heo]

On Tue, Aug 26, 2014 at 12:17:35PM +0530, Suman Tripathi wrote:
> Didn't I ask you to update the comment to explain what's going on?
> [suman] : can you specifically tell which part of the comment is not clear
> and need more explanation?

The comment on top of the function doesn't seem to match what's being
implemented.  In addition, it's generally not very useful to list the
actual algorithm in text.  Put algorithm in code and explain the
summary and rationales for it in the comments.  Nothing explains why
the retries are being done.

> is the existing comment already sufficient?
> [suman] : The existing comment is sufficient .

No, this isn't.  You don't have to include a novel to explain it but
there's something different going on here and you should provide
information on why this sort of deviation is necessary.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH v3] clk: shmobile: div6: support selectable-input clocks

[Geert Uytterhoeven]

Hi Ulrich,

On Tue, Aug 26, 2014 at 5:11 PM, Ulrich Hecht
 wrote:
> Adds support for DIV6 clocks with selectable parents as found in the r8a73a4,
> r8a7740, sh73a0, and other SoCs.

Thanks!

> Signed-off-by: Ulrich Hecht 

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH v3] clk: shmobile: div6: support selectable-input clocks

[Ulrich Hecht]

Adds support for DIV6 clocks with selectable parents as found in the r8a73a4,
r8a7740, sh73a0, and other SoCs.

Signed-off-by: Ulrich Hecht 
---

Changes since v2:
- add r8a73a4 to bindings
- use u32 where appropriate
- don't split error message

Changes since v1:
- make sure unrelated register bits are preserved
- use the plural for the clocks property in bindings

 .../bindings/clock/renesas,cpg-div6-clocks.txt | 12 +++-
 drivers/clk/shmobile/clk-div6.c| 32 ++
 2 files changed, 37 insertions(+), 7 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt 
b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt
index 952e373..b002d2b 100644
--- a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt
@@ -7,14 +7,24 @@ to 64.
 Required Properties:
 
   - compatible: Must be one of the following
+- "renesas,r8a73a4-div6-clock" for R8A73A4 (R-Mobile APE6) DIV6 clocks
+- "renesas,r8a7740-div6-clock" for R8A7740 (R-Mobile A1) DIV6 clocks
 - "renesas,r8a7790-div6-clock" for R8A7790 (R-Car H2) DIV6 clocks
 - "renesas,r8a7791-div6-clock" for R8A7791 (R-Car M2) DIV6 clocks
+- "renesas,sh73a0-div6-clock" for SH73A0 (SH-MobileAG5) DIV6 clocks
 - "renesas,cpg-div6-clock" for generic DIV6 clocks
   - reg: Base address and length of the memory resource used by the DIV6 clock
-  - clocks: Reference to the parent clock
+  - clocks: Reference to the parent clock(s)
   - #clock-cells: Must be 0
   - clock-output-names: The name of the clock as a free-form string
 
+Optional Properties:
+
+  - renesas,src-shift: Bit position of the input clock selector (default:
+fixed input clock)
+  - renesas,src-width: Bit width of the input clock selector (default: fixed
+input clock)
+
 
 Example
 ---
diff --git a/drivers/clk/shmobile/clk-div6.c b/drivers/clk/shmobile/clk-div6.c
index f065f69..2282bec 100644
--- a/drivers/clk/shmobile/clk-div6.c
+++ b/drivers/clk/shmobile/clk-div6.c
@@ -38,9 +38,12 @@ struct div6_clock {
 
 static int cpg_div6_clock_enable(struct clk_hw *hw)
 {
+   u32 val;
struct div6_clock *clock = to_div6_clock(hw);
 
-   clk_writel(CPG_DIV6_DIV(clock->div - 1), clock->reg);
+   val = (clk_readl(clock->reg) & ~(CPG_DIV6_DIV_MASK | CPG_DIV6_CKSTP))
+   | CPG_DIV6_DIV(clock->div - 1);
+   clk_writel(val, clock->reg);
 
return 0;
 }
@@ -52,8 +55,8 @@ static void cpg_div6_clock_disable(struct clk_hw *hw)
/* DIV6 clocks require the divisor field to be non-zero when stopping
 * the clock.
 */
-   clk_writel(CPG_DIV6_CKSTP | CPG_DIV6_DIV(CPG_DIV6_DIV_MASK),
-  clock->reg);
+   clk_writel(clk_readl(clock->reg) | CPG_DIV6_CKSTP | CPG_DIV6_DIV_MASK,
+   clock->reg);
 }
 
 static int cpg_div6_clock_is_enabled(struct clk_hw *hw)
@@ -94,12 +97,14 @@ static int cpg_div6_clock_set_rate(struct clk_hw *hw, 
unsigned long rate,
 {
struct div6_clock *clock = to_div6_clock(hw);
unsigned int div = cpg_div6_clock_calc_div(rate, parent_rate);
+   u32 val;
 
clock->div = div;
 
+   val = clk_readl(clock->reg) & ~CPG_DIV6_DIV_MASK;
/* Only program the new divisor if the clock isn't stopped. */
-   if (!(clk_readl(clock->reg) & CPG_DIV6_CKSTP))
-   clk_writel(CPG_DIV6_DIV(clock->div - 1), clock->reg);
+   if (!(val & CPG_DIV6_CKSTP))
+   clk_writel(val | CPG_DIV6_DIV(clock->div - 1), clock->reg);
 
return 0;
 }
@@ -121,6 +126,7 @@ static void __init cpg_div6_clock_init(struct device_node 
*np)
const char *name;
struct clk *clk;
int ret;
+   u32 src_shift, src_width;
 
clock = kzalloc(sizeof(*clock), GFP_KERNEL);
if (!clock) {
@@ -150,7 +156,21 @@ static void __init cpg_div6_clock_init(struct device_node 
*np)
goto error;
}
 
-   parent_name = of_clk_get_parent_name(np, 0);
+   if (!of_property_read_u32(np, "renesas,src-shift", &src_shift)) {
+   if (!of_property_read_u32(np, "renesas,src-width",
+   &src_width)) {
+   unsigned int parent_idx =
+   (clk_readl(clock->reg) >> src_shift) &
+   (BIT(src_width) - 1);
+   parent_name = of_clk_get_parent_name(np, parent_idx);
+   } else {
+   pr_err("%s: renesas,src-shift without renesas,src-width 
in %s\n",
+  __func__, np->name);
+   goto error;
+   }
+   } else
+   parent_name = of_clk_get_parent_name(np, 0);
+
if (parent_name == NULL) {
pr_err("%s: failed to get %s DIV6 clock parent name\n",
   __func__, np->name);
-- 
1.8.4.5

--

Re: [PATCH 1/6] iommu/arm-smmu: add support for specifying clocks

[Will Deacon]

[adding Mike]

On Tue, Aug 19, 2014 at 08:03:09PM +0100, Olav Haugan wrote:
> Hi Will,

Hi Olav,

> On 8/19/2014 5:58 AM, Will Deacon wrote:
> > On Wed, Aug 13, 2014 at 01:51:34AM +0100, Mitchel Humpherys wrote:
> >> On some platforms with tight power constraints it is polite to only
> >> leave your clocks on for as long as you absolutely need them. Currently
> >> we assume that all clocks necessary for SMMU register access are always
> >> on.
> >>
> >> Add some optional device tree properties to specify any clocks that are
> >> necessary for SMMU register access and turn them on and off as needed.
> >>
> >> If no clocks are specified in the device tree things continue to work
> >> the way they always have: we assume all necessary clocks are always
> >> turned on.
> > 
> > How does this interact with an SMMU in bypass mode?
> 
> Do you mean if you have a platform that requires clock and power
> management but we leave the SMMU in bypass (i.e. no one calls into the
> SMMU driver) how are the clock/power managed?
> 
> Clients of the SMMU driver are required to vote for clocks and power
> when they know they need to use the SMMU. However, the clock and power
> needed to be on for the SMMU to service bus masters aren't necessarily
> the same as the ones needed to read/write registers...See below.

The case I'm thinking of is where a device masters through the IOMMU, but
doesn't make use of any translations. In this case, its transactions will
bypass the SMMU and I want to ensure that continues to happen, regardless of
the power state of the SMMU.

> >> +static int arm_smmu_enable_clocks(struct arm_smmu_device *smmu)
> >> +{
> >> +  int i, ret = 0;
> >> +
> >> +  for (i = 0; i < smmu->num_clocks; ++i) {
> >> +  ret = clk_prepare_enable(smmu->clocks[i]);
> >> +  if (ret) {
> >> +  dev_err(smmu->dev, "Couldn't enable clock #%d\n", i);
> >> +  while (i--)
> >> +  clk_disable_unprepare(smmu->clocks[i]);
> >> +  break;
> >> +  }
> >> +  }
> >> +
> >> +  return ret;
> >> +}
> >> +
> >> +static void arm_smmu_disable_clocks(struct arm_smmu_device *smmu)
> >> +{
> >> +  int i;
> >> +
> >> +  for (i = 0; i < smmu->num_clocks; ++i)
> >> +  clk_disable_unprepare(smmu->clocks[i]);
> >> +}
> > 
> > What stops theses from racing with each other when there are multiple
> > clocks? I also assume that the clk API ignores calls to clk_enable_prepare
> > for a clk that's already enabled? I couldn't find that code...
> 
> All the clock APIs are reference counted yes. Not sure what you mean by
> racing with each other? When you call to enable a clock the call does
> not return until the clock is already ON (or OFF).

I was thinking of an interrupt handler racing with normal code, but actually
you balance the clk enable/disable in the interrupt handlers. However, it's
not safe to call these clk functions from irq context anyway, since
clk_prepare may sleep.

> >> +int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
> >>  {
> >>unsigned long size;
> >>void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
> >> @@ -2027,10 +2124,16 @@ static int arm_smmu_device_dt_probe(struct 
> >> platform_device *pdev)
> >>}
> >>dev_notice(dev, "registered %d master devices\n", i);
> >>  
> >> -  err = arm_smmu_device_cfg_probe(smmu);
> >> +  err = arm_smmu_init_clocks(smmu);
> >>if (err)
> >>goto out_put_masters;
> >>  
> >> +  arm_smmu_enable_clocks(smmu);
> >> +
> >> +  err = arm_smmu_device_cfg_probe(smmu);
> >> +  if (err)
> >> +  goto out_disable_clocks;
> >> +
> >>parse_driver_options(smmu);
> >>  
> >>if (smmu->version > 1 &&
> >> @@ -2039,7 +2142,7 @@ static int arm_smmu_device_dt_probe(struct 
> >> platform_device *pdev)
> >>"found only %d context interrupt(s) but %d required\n",
> >>smmu->num_context_irqs, smmu->num_context_banks);
> >>err = -ENODEV;
> >> -  goto out_put_masters;
> >> +  goto out_disable_clocks;
> >>}
> >>  
> >>for (i = 0; i < smmu->num_global_irqs; ++i) {
> >> @@ -2061,12 +2164,16 @@ static int arm_smmu_device_dt_probe(struct 
> >> platform_device *pdev)
> >>spin_unlock(&arm_smmu_devices_lock);
> >>  
> >>arm_smmu_device_reset(smmu);
> >> +  arm_smmu_disable_clocks(smmu);
> > 
> > I wonder if this is really the right thing to do. Rather than the
> > fine-grained clock enable/disable you have, why don't we just enable in
> > domain_init and disable in domain_destroy, with refcounting for the clocks?
> > 
> 
> So the whole point of all of this is that we try to save power. As Mitch
> wrote in the commit text we want to only leave the clock and power on
> for as short period of time as possible.

Understood, but if the clocks are going up and down like yo-yos, then it's
not obvious that you end up saving any power at all. Have you tried
measuring the power consumption with different granularit

[PATCH v6 5/5] regulator: RK808: remove redundant code

[Chris Zhong]

remove the redundant code, since pdata has been removed from stuct rk808

Signed-off-by: Chris Zhong 

---

Changes in v6: 
- remove the redundant code

Changes in v5:
- re-edit base on Mark's branch

Changes in v4:
- use &client->dev replace rk808->dev

Changes in v3: None
Changes in v2:
Adviced by Mark Browm:
- change of_find_node_by_name to find_child_by_name
- use RK808_NUM_REGULATORS as the name of the constant
- create a pdata when missing platform data
- use the rk808_reg name to supply_regulator name
- replace regulator_register with devm_regulator_register
- some other problem with coding styl

 drivers/regulator/rk808-regulator.c |   17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/regulator/rk808-regulator.c 
b/drivers/regulator/rk808-regulator.c
index f00d6d8..f42952e 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -294,11 +294,10 @@ static struct of_regulator_match rk808_reg_matches[] = {
[RK808_ID_SWITCH2]  = { .name = "SWITCH_REG2" },
 };
 
-static int rk808_regulator_dts(struct rk808 *rk808)
+static int rk808_regulator_dts(struct i2c_client *client,
+  struct rk808_board *pdata)
 {
struct device_node *np, *reg_np;
-   struct i2c_client *client = rk808->i2c;
-   struct rk808_board *pdata = rk808->pdata;
int i, ret;
 
np = client->dev.of_node;
@@ -335,7 +334,7 @@ static int rk808_regulator_probe(struct platform_device 
*pdev)
 {
struct rk808 *rk808 = dev_get_drvdata(pdev->dev.parent);
struct i2c_client *client = rk808->i2c;
-   struct rk808_board *pdata = rk808->pdata;
+   struct rk808_board *pdata = dev_get_platdata(&client->dev);
struct regulator_config config = {};
struct regulator_dev *rk808_rdev;
struct regulator_init_data *reg_data;
@@ -343,22 +342,15 @@ static int rk808_regulator_probe(struct platform_device 
*pdev)
int ret = 0;
 
if (!pdata) {
-   dev_warn(&client->dev, "%s no pdata, create it\n", __func__);
pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return -ENOMEM;
}
 
-   ret = rk808_regulator_dts(rk808);
+   ret = rk808_regulator_dts(client, pdata);
if (ret)
return ret;
 
-   rk808->num_regulators = RK808_NUM_REGULATORS;
-   rk808->rdev = devm_kzalloc(&pdev->dev, RK808_NUM_REGULATORS *
-  sizeof(struct regulator_dev *), GFP_KERNEL);
-   if (!rk808->rdev)
-   return -ENOMEM;
-
/* Instantiate the regulators */
for (i = 0; i < RK808_NUM_REGULATORS; i++) {
reg_data = pdata->rk808_init_data[i];
@@ -382,7 +374,6 @@ static int rk808_regulator_probe(struct platform_device 
*pdev)
"failed to register %d regulator\n", i);
return PTR_ERR(rk808_rdev);
}
-   rk808->rdev[i] = rk808_rdev;
}
return 0;
 }
-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)

[Thierry Reding]

On Tue, Aug 26, 2014 at 08:58:34AM -0500, Jon Loeliger wrote:
> > >>
> > >> Drivers don't provide that information (dependencies) in any usable way. 
> > >> And
> > >> as you said yourself, it's already contained in phandles. So what we are
> > >> discussing here about? The proposal to use phandles for that is already 
> > >> on
> > >> the table since several month. ;)
> > >>
> > >> Sorry, but I don't understand what you want to propose.
> > >
> > > In many cases we simply don't know where phandles are stored since we
> > > don't have the type information in DT. But drivers already know the type
> > > of a specific phandle and where to get it from, so the proposal is to
> > > make that knowledge more generally useful so that it can be used for
> > > dependency resolution.
> > 
> > How?
> 
> Is the issue around which we are dancing here the timing of
> topsort and the probing?  When the driver is probed, sure, it
> touches and resolves a bunch of phandles and references other
> nodes and devices.  But that is at probe time, and it only has
> the context of itself then.
> 
> I think we need to do the complete topsort *before* we attempt
> to do any probing.  So three steps:
> 
> 1) Graph Construction
> Add a new "emit dependencies" function to driver bindings.
> Iterate over known devices or nodes in the DT in any order.
>   Call the "emit dependencies" function.  It adds all
>   dependency edges to a global graph by knowing what
>   phandles or other pieces it will need.
>   A driver with no "emit dependencies" function can be
>   added to the graph anywhere without loss of generality.
> Add any additional edges for whatever reason.
> 
> 2) Topsort the generated driver graph
> 
> 3) Call probe for real in topsort order

Yes, I think that makes a lot of sense. We need to provide a way to make
the dependency information available before probe time, otherwise we
don't gain anything. Whether we provide that in a form of a function
call or a table is an implementation detail.

I do think that requiring drivers to provide a function is going to make
things more complicated than necessary since that "emit dependencies"
function would need to copy a lot of the things that .probe() does
already. Sharing this information in a table sounds like a good idea. An
"emit dependencies" function in the core can use that data to resolve
dependencies whereas the driver core can equally use that information to
request the devices so that the drivers don't have to do so.

Thierry


pgptHf0d4kMgN.pgp
Description: PGP signature

[PATCH v6 4/5] clk: RK808: Add clkout driver for RK808

[Chris Zhong]

Signed-off-by: Chris Zhong 

---

Changes in v6:
Adviced by doug
- use correct argument call of_clk_add_provider in probe

Changes in v5:
Adviced by doug
- add some error checking in probe
- move "rockchip,rk808.h" into the patch about dt-bindings

Changes in v4:
Adviced by doug
- add "clock-output-names" propertiey
- add a header file "rockchip,rk808.h"

Changes in v3:
- fix compile err

Changes in v2:
Adviced by javier.martinez
- separated from rtc-rk808.

 drivers/clk/Kconfig |9 +++
 drivers/clk/Makefile|1 +
 drivers/clk/clk-rk808.c |  163 +++
 3 files changed, 173 insertions(+)
 create mode 100644 drivers/clk/clk-rk808.c

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index cfd3af7..84e0590 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -38,6 +38,15 @@ config COMMON_CLK_MAX77686
---help---
  This driver supports Maxim 77686 crystal oscillator clock. 
 
+config COMMON_CLK_RK808
+   tristate "Clock driver for RK808"
+   depends on MFD_RK808
+   ---help---
+ This driver supports RK808 crystal oscillator clock. These
+ multi-function devices have two fixed-rate oscillators,
+ clocked at 32KHz each. Clkout1 is always on, Clkout2 can off
+ by control register.
+
 config COMMON_CLK_SI5351
tristate "Clock driver for SiLabs 5351A/B/C"
depends on I2C
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index f537a0b..99f53d5 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_ARCH_NOMADIK)+= clk-nomadik.o
 obj-$(CONFIG_ARCH_NSPIRE)  += clk-nspire.o
 obj-$(CONFIG_COMMON_CLK_PALMAS)+= clk-palmas.o
 obj-$(CONFIG_CLK_PPC_CORENET)  += clk-ppc-corenet.o
+obj-$(CONFIG_COMMON_CLK_RK808) += clk-rk808.o
 obj-$(CONFIG_COMMON_CLK_S2MPS11)   += clk-s2mps11.o
 obj-$(CONFIG_COMMON_CLK_SI5351)+= clk-si5351.o
 obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o
diff --git a/drivers/clk/clk-rk808.c b/drivers/clk/clk-rk808.c
new file mode 100644
index 000..21f8b54
--- /dev/null
+++ b/drivers/clk/clk-rk808.c
@@ -0,0 +1,163 @@
+/*
+ * Clkout driver for Rockchip RK808
+ *
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Chris Zhong 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct rk808_clkout {
+   struct rk808 *rk808;
+   struct clk_onecell_data clk_data;
+   struct clk_hw   clkout1_hw;
+   struct clk_hw   clkout2_hw;
+};
+
+static unsigned long rk808_clkout_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+   return 32768;
+}
+
+static int rk808_clkout1_is_prepared(struct clk_hw *hw)
+{
+   return 1;
+}
+
+static int rk808_clkout2_control(struct clk_hw *hw, bool enable)
+{
+   struct rk808_clkout *rk808_clkout = container_of(hw,
+struct rk808_clkout,
+clkout2_hw);
+   struct rk808 *rk808 = rk808_clkout->rk808;
+
+   return regmap_update_bits(rk808->regmap, RK808_CLK32OUT_REG,
+ CLK32KOUT2_EN, enable ? CLK32KOUT2_EN : 0);
+}
+
+static int rk808_clkout2_prepare(struct clk_hw *hw)
+{
+   return rk808_clkout2_control(hw, 1);
+}
+
+static void rk808_clkout2_unprepare(struct clk_hw *hw)
+{
+   rk808_clkout2_control(hw, 0);
+}
+
+static int rk808_clkout2_is_prepared(struct clk_hw *hw)
+{
+   struct rk808_clkout *rk808_clkout = container_of(hw,
+struct rk808_clkout,
+clkout2_hw);
+   struct rk808 *rk808 = rk808_clkout->rk808;
+   uint32_t val;
+
+   int ret = regmap_read(rk808->regmap, RK808_CLK32OUT_REG, &val);
+
+   if (ret < 0)
+   return ret;
+
+   return (val & CLK32KOUT2_EN) ? 1 : 0;
+}
+
+static const struct clk_ops rk808_clkout1_ops = {
+   .is_prepared = rk808_clkout1_is_prepared,
+   .recalc_rate = rk808_clkout_recalc_rate,
+};
+
+static const struct clk_ops rk808_clkout2_ops = {
+   .prepare = rk808_clkout2_prepare,
+   .unprepare = rk808_clkout2_unprepare,
+   .is_prepared = rk808_clkout2_is_prepared,
+   .recalc_rate = rk808_clkout_recalc_rate,
+};
+
+static int rk808_clkout_probe(struct platform_d

[PATCH v6 3/5] RTC: RK808: add RTC driver for RK808

[Chris Zhong]

Adding RTC driver for supporting RTC device present inside RK808 PMIC.

Signed-off-by: Chris Zhong 
Signed-off-by: Zhang Qing 

---

Changes in v6:
Adviced by doug
- move RTC_READSEL setting into probe

Changes in v5:
- fixed a bug about set_time failed

Changes in v4:
- use &client->dev replace rk808->dev

Changes in v3: None
Changes in v2:
Adviced by javier.martinez
- Add a separate clock driver, rather than in RTC driver

 drivers/rtc/Kconfig |   10 ++
 drivers/rtc/Makefile|1 +
 drivers/rtc/rtc-rk808.c |  412 +++
 3 files changed, 423 insertions(+)
 create mode 100644 drivers/rtc/rtc-rk808.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index a168e96..aeab9d9 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -288,6 +288,16 @@ config RTC_DRV_MAX77686
  This driver can also be built as a module. If so, the module
  will be called rtc-max77686.
 
+config RTC_DRV_RK808
+   tristate "Rockchip RK808 RTC"
+   depends on MFD_RK808
+   help
+ If you say yes here you will get support for the
+ RTC of RK808 PMIC.
+
+ This driver can also be built as a module. If so, the module
+ will be called rk808-rtc.
+
 config RTC_DRV_RS5C372
tristate "Ricoh R2025S/D, RS5C372A/B, RV5C386, RV5C387A"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 56f061c..91fe4647 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -109,6 +109,7 @@ obj-$(CONFIG_RTC_DRV_PUV3)  += rtc-puv3.o
 obj-$(CONFIG_RTC_DRV_PXA)  += rtc-pxa.o
 obj-$(CONFIG_RTC_DRV_R9701)+= rtc-r9701.o
 obj-$(CONFIG_RTC_DRV_RC5T583)  += rtc-rc5t583.o
+obj-$(CONFIG_RTC_DRV_RK808)+= rtc-rk808.o
 obj-$(CONFIG_RTC_DRV_RP5C01)   += rtc-rp5c01.o
 obj-$(CONFIG_RTC_DRV_RS5C313)  += rtc-rs5c313.o
 obj-$(CONFIG_RTC_DRV_RS5C348)  += rtc-rs5c348.o
diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk808.c
new file mode 100644
index 000..00cd997
--- /dev/null
+++ b/drivers/rtc/rtc-rk808.c
@@ -0,0 +1,412 @@
+/*
+ * RTC driver for Rockchip RK808
+ *
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* RTC_CTRL_REG bitfields */
+#define BIT_RTC_CTRL_REG_STOP_RTC_MBIT(0)
+#define BIT_RTC_CTRL_REG_RTC_READSEL_M BIT(7)
+#define BIT_RTC_INTERRUPTS_REG_IT_ALARM_M  BIT(3)
+#define RTC_STATUS_MASK0xFE
+
+#define SECONDS_REG_MSK0x7F
+#define MINUTES_REG_MAK0x7F
+#define HOURS_REG_MSK  0x3F
+#define DAYS_REG_MSK   0x3F
+#define MONTHS_REG_MSK 0x1F
+#define YEARS_REG_MSK  0xFF
+#define WEEKS_REG_MSK  0x7
+
+/* REG_SECONDS_REG through REG_YEARS_REG is how many registers? */
+
+#define NUM_TIME_REGS  (RK808_WEEKS_REG - RK808_SECONDS_REG + 1)
+#define NUM_ALARM_REGS (RK808_ALARM_YEARS_REG - RK808_ALARM_SECONDS_REG + 1)
+
+struct rk808_rtc {
+   struct rk808 *rk808;
+   struct rtc_device *rtc;
+   int irq;
+};
+
+/* Read current time and date in RTC */
+static int rk808_rtc_readtime(struct device *dev, struct rtc_time *tm)
+{
+   struct rk808_rtc *rk808_rtc = dev_get_drvdata(dev);
+   struct rk808 *rk808 = rk808_rtc->rk808;
+   u8 rtc_data[NUM_TIME_REGS];
+   int ret;
+
+   ret = regmap_bulk_read(rk808->regmap, RK808_SECONDS_REG,
+  rtc_data, NUM_TIME_REGS);
+   if (ret) {
+   dev_err(dev, "Failed to bulk read rtc_data: %d\n", ret);
+   return ret;
+   }
+
+   tm->tm_sec = bcd2bin(rtc_data[0] & SECONDS_REG_MSK);
+   tm->tm_min = bcd2bin(rtc_data[1] & MINUTES_REG_MAK);
+   tm->tm_hour = bcd2bin(rtc_data[2] & HOURS_REG_MSK);
+   tm->tm_mday = bcd2bin(rtc_data[3] & DAYS_REG_MSK);
+   tm->tm_mon = (bcd2bin(rtc_data[4] & MONTHS_REG_MSK)) - 1;
+   tm->tm_year = (bcd2bin(rtc_data[5] & YEARS_REG_MSK)) + 100;
+   tm->tm_wday = bcd2bin(rtc_data[6] & WEEKS_REG_MSK);
+   dev_dbg(dev, "RTC date/time %4d-%02d-%02d(%d) %02d:%02d:%02d\n",
+   1900 + tm->tm_year, tm->tm_mon + 1, tm->tm_mday,
+   tm->tm_wday, tm->tm_hour , tm->tm_min, tm->tm_sec);
+
+   return 0;
+}
+
+/* Set current time and date in RTC */
+static int rk808_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+   struct rk808_rtc *rk808_rtc = dev_get_drvdata(dev);
+   struct rk808 *rk808 = rk808_rtc->rk808;
+   u8 rtc_data[NUM_TIM

[PATCH v6 2/5] MFD: RK808: Add new mfd driver for RK808

[Chris Zhong]

The RK808 chip is a power management IC for multimedia and handheld
devices. It contains the following components:

- Regulators
- RTC
- Clkout

The RK808 core driver is registered as a platform driver and provides
communication through I2C with the host device for the different
components.

Signed-off-by: Chris Zhong 
Signed-off-by: Zhang Qing 

---

Changes in v6:
Adviced by Lee Jones in v2
- rk808_i2c_client instead of g_rk808
- remove pdata form struct rk808

Changes in v5: None
Changes in v4:
Adviced by Lee Jones in v2
- modify the description in Kconfig
- remove some unnecessary header files
- remove dev from struct rk808
- use enum for define RK808_ID...

Changes in v3:
- fix compile err

Changes in v2:
Adviced by Mark Browm:
- use defines for register setting value
- remove rtc alarm disable in shutdown
- remove while(1) in shutdown
- remove read 0x2f in probe

 drivers/mfd/Kconfig   |   13 +++
 drivers/mfd/Makefile  |1 +
 drivers/mfd/rk808.c   |  257 +
 include/linux/mfd/rk808.h |  202 +++
 4 files changed, 473 insertions(+)
 create mode 100644 drivers/mfd/rk808.c
 create mode 100644 include/linux/mfd/rk808.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index de5abf2..2c7fdb2 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -582,6 +582,19 @@ config MFD_RC5T583
  Additional drivers must be enabled in order to use the
  different functionality of the device.
 
+config MFD_RK808
+   tristate "Rockchip RK808 Power Management chip"
+   depends on I2C
+   select MFD_CORE
+   select REGMAP_I2C
+   select REGMAP_IRQ
+   help
+ If you say yes here you get support for the RK808
+ Power Management chips.
+ This driver provides common support for accessing the device
+ through I2C interface. The device supports multiple sub-devices
+ including interrupts, RTC, LDO & DCDC regulators, and onkey.
+
 config MFD_SEC_CORE
bool "SAMSUNG Electronics PMIC Series Support"
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f001487..dbc28e7 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -160,6 +160,7 @@ obj-$(CONFIG_MFD_INTEL_MSIC)+= intel_msic.o
 obj-$(CONFIG_MFD_PALMAS)   += palmas.o
 obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
 obj-$(CONFIG_MFD_RC5T583)  += rc5t583.o rc5t583-irq.o
+obj-$(CONFIG_MFD_RK808)+= rk808.o
 obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
 obj-$(CONFIG_MFD_SYSCON)   += syscon.o
 obj-$(CONFIG_MFD_LM3533)   += lm3533-core.o lm3533-ctrlbank.o
diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
new file mode 100644
index 000..f0d6518
--- /dev/null
+++ b/drivers/mfd/rk808.c
@@ -0,0 +1,257 @@
+/*
+ * MFD core driver for Rockchip RK808
+ *
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Chris Zhong 
+ * Author: Zhang Qing 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct rk808_reg_data {
+   int addr;
+   int mask;
+   int value;
+};
+
+static const struct regmap_config rk808_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .max_register = RK808_IO_POL_REG,
+};
+
+static struct resource rtc_resources[] = {
+   {
+   .start  = RK808_IRQ_RTC_ALARM,
+   .end= RK808_IRQ_RTC_ALARM,
+   .flags  = IORESOURCE_IRQ,
+   }
+};
+
+static const struct mfd_cell rk808s[] = {
+   { .name = "rk808-clkout", },
+   { .name = "rk808-regulator", },
+   {
+   .name = "rk808-rtc",
+   .num_resources = ARRAY_SIZE(rtc_resources),
+   .resources = &rtc_resources[0],
+   },
+};
+
+static const struct rk808_reg_data pre_init_reg[] = {
+   { RK808_BUCK3_CONFIG_REG, BUCK_ILMIN_MASK,  BUCK_ILMIN_150MA },
+   { RK808_BUCK4_CONFIG_REG, BUCK_ILMIN_MASK,  BUCK_ILMIN_200MA },
+   { RK808_BOOST_CONFIG_REG, BOOST_ILMIN_MASK, BOOST_ILMIN_100MA },
+   { RK808_BUCK1_CONFIG_REG, BUCK1_RATE_MASK,  BUCK_ILMIN_200MA },
+   { RK808_BUCK2_CONFIG_REG, BUCK2_RATE_MASK,  BUCK_ILMIN_200MA },
+   { RK808_VB_MON_REG,   MASK_ALL, VB_LO_ACT |
+   VB_LO_SEL_3500MV },
+   { RK808_INT_STS_REG1, MASK_NONE,0 },
+   { RK808_INT_STS_REG2, MASK_NONE,0 },
+};
+
+static const struct regmap_irq r

[PATCH v6 1/5] dt-bindings: Add RK808 device tree bindings document

[Chris Zhong]

Add device tree bindings documentation and a header file
for rockchip's RK808 pmic.

Signed-off-by: Chris Zhong 
Signed-off-by: Zhang Qing 

---

Changes in v6:
Advices by Mark Rutland
- add description about clock-cells
Advices by Doug
- modify description about regulator
- remove pinctrl description

Changes in v5:
Advices by Mark Brown
- add description about regulator valid name.
- add a header file "rockchip,rk808".

Changes in v4:
Advices by Doug
- add a "#clock-cells" propertiy
- update the example

Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/mfd/rk808.txt |  150 +++
 include/dt-bindings/clock/rockchip,rk808.h  |   11 ++
 2 files changed, 161 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/rk808.txt
 create mode 100644 include/dt-bindings/clock/rockchip,rk808.h

diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt 
b/Documentation/devicetree/bindings/mfd/rk808.txt
new file mode 100644
index 000..6c39360
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rk808.txt
@@ -0,0 +1,150 @@
+RK808 Power Management Integrated Circuit
+
+Required properties:
+- compatible: "rockchip,rk808"
+- reg: I2C slave address
+- interrupt-parent: The parent interrupt controller.
+- interrupts: the interrupt outputs of the controller.
+- #clock-cells: RK808 has 2 clkout, they are always 32khz,
+  the value should be 1
+
+Optional properties:
+- clock-output-names: From common clock binding to override the
+  default output clock name
+- rockchip,system-power-controller: Telling whether or not this pmic is 
controlling
+  the system power.
+
+Regulators: All the regulators of RK808 to be instantiated shall be
+listed in a child node named 'regulators'. Each regulator is represented
+by a child node of the 'regulators' node.
+
+   regulator-name {
+   /* standard regulator bindings here */
+   };
+
+Following regulators of the RK808 PMIC block are supported. Note that
+the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO
+number as described in RK808 datasheet.
+
+   - DCDC_REGn
+   - valid values for n are 1 to 4.
+   - LDO_REGn
+   - valid values for n are 1 to 8.
+   - SWITCH_REGn
+   - valid values for n are 1 to 2
+
+Standard regulator bindings are used inside regulator subnodes. Check
+  Documentation/devicetree/bindings/regulator/regulator.txt
+for more details
+
+Example:
+   rk808: pmic@1b {
+   compatible = "rockchip,rk808";
+   interrupt-parent = <&gpio0>;
+   interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pmic_int>;
+   reg = <0x1b>;
+   #clock-cells = <1>;
+   clock-output-names = "xin32k0", "xin32k1";
+   rockchip,system-power-controller;
+
+   regulators {
+   rk808_dcdc1_reg: DCDC_REG1 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   regulator-name = "vdd_arm";
+   };
+
+   rk808_dcdc2_reg: DCDC_REG2 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <85>;
+   regulator-max-microvolt = <125>;
+   regulator-name = "vdd_gpu";
+   };
+
+   rk808_dcdc3_reg: DCDC_REG3 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-name = "vdd_ddr";
+   };
+
+   rk808_dcdc4_reg: DCDC_REG4 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vccio";
+   };
+
+   rk808_ldo1_reg: LDO_REG1 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   rk808_ldo2_reg: LDO_REG2 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+ 

[PATCH v6 0/5] Add rockchip RK808 pmic driver

[Chris Zhong]

This is the initial version of the RK808 PMIC. This is a power management IC
for multimedia products.

It provides regulators that are able to supply power to processor cores
and other components. The chip provides other modules including RTC, Clockout

Changes in v6:
- remove the redundant code
Adviced by doug
- use correct argument call of_clk_add_provider in probe
Adviced by doug
- move RTC_READSEL setting into probe
Adviced by Lee Jones in v2
- rk808_i2c_client instead of g_rk808
- remove pdata form struct rk808
Advices by Mark Rutland
- add description about clock-cells
Advices by Doug
- modify description about regulator
- remove pinctrl description

Changes in v5:
- re-edit base on Mark's branch
Adviced by doug
- add some error checking in probe
- move "rockchip,rk808.h" into the patch about dt-bindings
- fixed a bug about set_time failed
Advices by Mark Brown
- add description about regulator valid name.
- add a header file "rockchip,rk808".

Changes in v4:
- use &client->dev replace rk808->dev
Adviced by doug
- add "clock-output-names" propertiey
- add a header file "rockchip,rk808.h"
- use &client->dev replace rk808->dev
Adviced by Lee Jones in v2
- modify the description in Kconfig
- remove some unnecessary header files
- remove dev from struct rk808
- use enum for define RK808_ID...
Advices by Doug
- add a "#clock-cells" propertiy
- update the example

Changes in v3:
- fix compile err
- fix compile err

Changes in v2:
Adviced by Mark Browm:
- change of_find_node_by_name to find_child_by_name
- use RK808_NUM_REGULATORS as the name of the constant
- create a pdata when missing platform data
- use the rk808_reg name to supply_regulator name
- replace regulator_register with devm_regulator_register
- some other problem with coding style
Adviced by javier.martinez
- separated from rtc-rk808.c
Adviced by javier.martinez
- Add a separate clock driver, rather than in RTC driver
Adviced by Mark Browm:
- use defines for register setting value
- remove rtc alarm disable in shutdown
- remove while(1) in shutdown
- remove read 0x2f in probe

Chris Zhong (5):
  dt-bindings: Add RK808 device tree bindings document
  MFD: RK808: Add new mfd driver for RK808
  RTC: RK808: add RTC driver for RK808
  clk: RK808: Add clkout driver for RK808
  regulator: RK808: remove redundant code

 Documentation/devicetree/bindings/mfd/rk808.txt |  150 +
 drivers/clk/Kconfig |9 +
 drivers/clk/Makefile|1 +
 drivers/clk/clk-rk808.c |  163 +
 drivers/mfd/Kconfig |   13 +
 drivers/mfd/Makefile|1 +
 drivers/mfd/rk808.c |  257 ++
 drivers/regulator/rk808-regulator.c |   17 +-
 drivers/rtc/Kconfig |   10 +
 drivers/rtc/Makefile|1 +
 drivers/rtc/rtc-rk808.c |  412 +++
 include/dt-bindings/clock/rockchip,rk808.h  |   11 +
 include/linux/mfd/rk808.h   |  202 +++
 13 files changed, 1234 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/rk808.txt
 create mode 100644 drivers/clk/clk-rk808.c
 create mode 100644 drivers/mfd/rk808.c
 create mode 100644 drivers/rtc/rtc-rk808.c
 create mode 100644 include/dt-bindings/clock/rockchip,rk808.h
 create mode 100644 include/linux/mfd/rk808.h

-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)

[Jon Loeliger]

> >>
> >> Drivers don't provide that information (dependencies) in any usable way. 
> >> And
> >> as you said yourself, it's already contained in phandles. So what we are
> >> discussing here about? The proposal to use phandles for that is already on
> >> the table since several month. ;)
> >>
> >> Sorry, but I don't understand what you want to propose.
> >
> > In many cases we simply don't know where phandles are stored since we
> > don't have the type information in DT. But drivers already know the type
> > of a specific phandle and where to get it from, so the proposal is to
> > make that knowledge more generally useful so that it can be used for
> > dependency resolution.
> 
> How?

Is the issue around which we are dancing here the timing of
topsort and the probing?  When the driver is probed, sure, it
touches and resolves a bunch of phandles and references other
nodes and devices.  But that is at probe time, and it only has
the context of itself then.

I think we need to do the complete topsort *before* we attempt
to do any probing.  So three steps:

1) Graph Construction
Add a new "emit dependencies" function to driver bindings.
Iterate over known devices or nodes in the DT in any order.
Call the "emit dependencies" function.  It adds all
dependency edges to a global graph by knowing what
phandles or other pieces it will need.
A driver with no "emit dependencies" function can be
added to the graph anywhere without loss of generality.
Add any additional edges for whatever reason.

2) Topsort the generated driver graph

3) Call probe for real in topsort order
  
Alexander, I don't recall the details of your patch series.
Can you please remind us if it took this approach in the kernel?

> Anyway, I'm leaving this discussion. I've already made a proposal
> which solved most mentioned problems (imho) and even offered usable
> patches

Darn.  I think you clearly have a pony in this race, and it
would be good if you still participated.  Really.

> (ok, they suffer under the "not invented here" syndrom, but ...). ;)

There isn't a single thing in the entire Linux Kernel community
that was "invented here"; every aspect of it was NIH'ed by *someone*.
That's how it gets built, changed, maintained, fixed, etc.

> But please continue this discussion, I will try to not disturb it
> anymore.

I'm sorry to hear that.

> Regards,
> Alexander Holler

HTH,
jdl
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] iommu/arm-smmu: add support for iova_to_phys through ATS1PR

[Will Deacon]

Hi Mitch,

On Tue, Aug 19, 2014 at 07:12:41PM +0100, Mitchel Humpherys wrote:
> On Tue, Aug 19 2014 at 05:44:32 AM, Will Deacon  wrote:
> > We don't have writeq for arch/arm/.
> 
> Ah yes looks like this is an MSM-ism that never made it upstream since
> it wouldn't be guaranteed to be atomic. I'll make sure to do arm32
> compiles on upstream kernels for future patches, sorry!
> 
> I guess we could use  but I can
> also re-work this to be two separate writel's.

Yeah, just do two writels.

> >> +  }
> >> +
> >> +  mb();
> >
> > Why?
> 
> My thought was that if we start polling ATSR_ACTIVE prematurely (before
> the write to ATS1PR actually finishes) all heck could break loose? Not
> sure if that's a bogus assumption due to device memory being strongly
> ordered?

I think the device-memory guarantees should be enough. If not, we need a
comment explaining why.

> >> +  while (readl_relaxed(cb_base + ARM_SMMU_CB_ATSR) & ATSR_ACTIVE) {
> >> +  if (++count == ATSR_LOOP_TIMEOUT) {
> >> +  dev_err(dev,
> >> +  "iova to phys timed out on 0x%pa for %s. 
> >> Falling back to software table walk.\n",
> >> +  &iova, dev_name(dev));
> >> +  arm_smmu_disable_clocks(smmu);
> >> +  return arm_smmu_iova_to_phys_soft(domain, iova);
> >> +  }
> >> +  cpu_relax();
> >> +  }
> >
> > Do you know what happened to Olav's patches to make this sort of code
> > generic?
> 
> I assume you're talking about this, right?
> 
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/267943.html
> 
> Yeah looks like he never sent an update since it was part of a series
> that wasn't going to make it in (the qsmmu driver). I can always bring
> that patch (actually Matt Wagantall's patch) in here and rework this to
> use that.

Yup, I think it would be useful to revive that as a separate series.

> >
> >> @@ -2005,6 +2073,11 @@ int arm_smmu_device_cfg_probe(struct 
> >> arm_smmu_device *smmu)
> >>return -ENODEV;
> >>}
> >>  
> >> +  if (smmu->version == 1 || (!(id & ID0_ATOSNS) && (id & ID0_S1TS))) {
> >
> > Are you sure about this? The v2 spec says that is ATOSNS is clear then S1TS
> > is also clear.
> 
> I was looking at Section 4.1.1 of ARM IHI 0062C ID091613 which states:
> 
> In SMMUv2, the address translation registers are OPTIONAL. The
> address translation registers are implemented only when both:
> 
> o The SMMU_IDR0.S1TS bit is set to 1.
> o The SMMU_IDR0.ATOSNS bit is set to 0.
> 
> I assume you're referring to section 9.6.1 of the same document:
> 
> ATOSNS, bit[26]
> Address Translation Operations Not Supported. The possible values of
> this bit are:
> 
> 0 Address translation operations are supported. Stage 1
>   translation is not supported, that is, the S1TS bit is set to 0.
> 
> 1 Address translation operations are not supported. Stage 1
>   translation is supported, that is, the S1TS bit is set to 1.
> 
> If that really means that S1TS and ATOSNS always have the same value
> then Section 4.1.1 doesn't make any sense. Or am I missing something?

I'll get this checked, as those two paragraphs don't make an awful lot of
sense together.

Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 3/5] ARM: dts: imx6qdl: Add power-domain information to gpc node

[Philipp Zabel]

The PGC that is part of GPC controls isolation and power sequencing of the
power domains. The PU power domain will be handled by the generic pm domain
framework. It needs a phandle to the PU regulator to turn off power when
the domain is disabled, and a list of phandles to all clocks that must be
enabled during powerup for reset propagation.

Signed-off-by: Philipp Zabel 
---
Changes since v5:
 - Replaced clock indices with name macros
---
 arch/arm/boot/dts/imx6qdl.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index c701af9..0b1384c 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -670,6 +670,14 @@
reg = <0x020dc000 0x4000>;
interrupts = <0 89 IRQ_TYPE_LEVEL_HIGH>,
 <0 90 IRQ_TYPE_LEVEL_HIGH>;
+   pu-supply = <®_pu>;
+   clocks = <&clks IMX6QDL_CLK_GPU3D_CORE>,
+<&clks IMX6QDL_CLK_GPU3D_SHADER>,
+<&clks IMX6QDL_CLK_GPU2D_CORE>,
+<&clks IMX6QDL_CLK_GPU2D_AXI>,
+<&clks IMX6QDL_CLK_OPENVG_AXI>,
+<&clks IMX6QDL_CLK_VPU_AXI>;
+   #power-domain-cells = <1>;
};
 
gpr: iomuxc-gpr@020e {
-- 
2.1.0.rc1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 1/5] Documentation: Add device tree bindings for Freescale i.MX GPC

[Philipp Zabel]

The i.MX6 contains a power controller that controls power gating and
sequencing for the SoC's power domains.

Signed-off-by: Philipp Zabel 
---
 .../devicetree/bindings/power/fsl,imx-gpc.txt  | 54 ++
 1 file changed, 54 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.txt

diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt 
b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
new file mode 100644
index 000..eaa8c93
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
@@ -0,0 +1,54 @@
+Freescale i.MX General Power Controller
+===
+
+The i.MX6Q General Power Control (GPC) block contains DVFS load tracking
+counters and Power Gating Control (PGC) for the CPU and PU (GPU/VPU) power
+domains.
+
+Required properties:
+- compatible: Should be "fsl,imx6q-gpc" or "fsl,imx6sl-gpc"
+- reg: should be register base and length as documented in the
+  datasheet
+- interrupts: Should contain GPC interrupt request 1
+- pu-supply: Link to the LDO regulator powering the PU power domain
+- clocks: Clock phandles to devices in the PU power domain that need
+ to be enabled during domain power-up for reset propagation.
+- #power-domain-cells: Should be 1, see below:
+
+The gpc node is a power-controller as documented by the generic power domain
+bindings in Documentation/devicetree/bindings/power/power_domain.txt.
+
+Example:
+
+   gpc: gpc@020dc000 {
+   compatible = "fsl,imx6q-gpc";
+   reg = <0x020dc000 0x4000>;
+   interrupts = <0 89 0x04 0 90 0x04>;
+   pu-supply = <®_pu>;
+   clocks = <&clks 122>, <&clks 74>, <&clks 121>,
+<&clks 26>, <&clks 143>, <&clks 168>;
+   #power-domain-cells = <1>;
+   };
+
+
+Specifying power domain for IP modules
+==
+
+IP cores belonging to a power domain should contain a 'power-domain' property
+that is a phandle pointing to the gpc device node and a DOMAIN_INDEX specifying
+the power domain the device belongs to.
+
+Example of a device that is part of the PU power domain:
+
+   vpu: vpu@0204 {
+   reg = <0x0204 0x3c000>;
+   /* ... */
+   power-domain = <&gpc 1>;
+   /* ... */
+   };
+
+The following DOMAIN_INDEX values are valid for i.MX6Q:
+ARM_DOMAIN 0
+PU_DOMAIN  1
+The following additional DOMAIN_INDEX value is valid for i.MX6SL:
+DISPLAY_DOMAIN 2
-- 
2.1.0.rc1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 4/5] ARM: dts: imx6sl: Add power-domain information to gpc node

[Philipp Zabel]

The PGC that is part of GPC controls isolation and power sequencing of the
power domains. The PU power domain will be handled by the generic pm domain
framework. It needs a phandle to the PU regulator to turn off power when
the domain is disabled and a list of clocks to be enabled during powerup
for reset propagation.

Signed-off-by: Philipp Zabel 
---
 arch/arm/boot/dts/imx6sl.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index c75800c..7ae4847 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -581,6 +581,10 @@
compatible = "fsl,imx6sl-gpc", "fsl,imx6q-gpc";
reg = <0x020dc000 0x4000>;
interrupts = <0 89 IRQ_TYPE_LEVEL_HIGH>;
+   pu-supply = <®_pu>;
+   clocks = <&clks IMX6SL_CLK_GPU2D_OVG>,
+<&clks IMX6SL_CLK_GPU2D_PODF>;
+   #power-domain-cells = <1>;
};
 
gpr: iomuxc-gpr@020e {
-- 
2.1.0.rc1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 0/5] i.MX6 PU power domain support

[Philipp Zabel]

Hi,

this is a rebased and updated version of the series I sent previously:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/238377.html

It is based on the "PM / Domains: Generic OF-based support" series that Ulf
Hansson sent recently:

http://www.spinics.net/lists/arm-kernel/msg357003.html

Changes since v6:
 - imx6qdl.dtsi entry now uses clock name macros instead of index numbers

regards
Philipp

Philipp Zabel (5):
  Documentation: Add device tree bindings for Freescale i.MX GPC
  ARM: imx6: gpc: Add PU power domain for GPU/VPU
  ARM: dts: imx6qdl: Add power-domain information to gpc node
  ARM: dts: imx6sl: Add power-domain information to gpc node
  ARM: dts: imx6qdl: Allow disabling the PU regulator, add a enable ramp
delay

 .../devicetree/bindings/power/fsl,imx-gpc.txt  |  54 ++
 arch/arm/boot/dts/imx6qdl.dtsi |  11 +-
 arch/arm/boot/dts/imx6sl.dtsi  |   4 +
 arch/arm/mach-imx/Kconfig  |   1 +
 arch/arm/mach-imx/gpc.c| 203 +
 5 files changed, 272 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.txt

-- 
2.1.0.rc1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 5/5] ARM: dts: imx6qdl: Allow disabling the PU regulator, add a enable ramp delay

[Philipp Zabel]

The PU regulator is enabled during boot, but not necessarily always-on.
It can be disabled by the generic pm domain framework when the PU power
domain is shut down. The ramp delay of 150 us might be a bit conservative,
the value is taken from the Freescale kernel.

Signed-off-by: Philipp Zabel 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 0b1384c..d8d3d93 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -579,7 +579,8 @@
regulator-name = "vddpu";
regulator-min-microvolt = <725000>;
regulator-max-microvolt = <145>;
-   regulator-always-on;
+   regulator-enable-ramp-delay = <150>;
+   regulator-boot-on;
anatop-reg-offset = <0x140>;
anatop-vol-bit-shift = <9>;
anatop-vol-bit-width = <5>;
-- 
2.1.0.rc1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 2/5] ARM: imx6: gpc: Add PU power domain for GPU/VPU

[Philipp Zabel]

When generic pm domain support is enabled, the PGC can be used
to completely gate power to the PU power domain containing GPU3D,
GPU2D, and VPU cores.
This code triggers the PGC powerdown sequence to disable the GPU/VPU
isolation cells and gate power and then disables the PU regulator.
To reenable, the reverse powerup sequence is triggered after the PU
regulator is enabled again.
The GPU and VPU devices in the PU power domain temporarily need
to be clocked during powerup, so that the reset machinery can work.

Signed-off-by: Philipp Zabel 
---
 arch/arm/mach-imx/Kconfig |   1 +
 arch/arm/mach-imx/gpc.c   | 203 ++
 2 files changed, 204 insertions(+)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 9de84a2..78d69cf 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -50,6 +50,7 @@ config HAVE_IMX_ANATOP
 
 config HAVE_IMX_GPC
bool
+   select PM_GENERIC_DOMAINS if PM
 
 config HAVE_IMX_MMDC
bool
diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index 82ea74e..5eec828 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -10,19 +10,41 @@
  * http://www.gnu.org/copyleft/gpl.html
  */
 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include "common.h"
+#include "hardware.h"
 
+#define GPC_CNTR   0x000
 #define GPC_IMR1   0x008
+#define GPC_PGC_GPU_PDN0x260
+#define GPC_PGC_GPU_PUPSCR 0x264
+#define GPC_PGC_GPU_PDNSCR 0x268
 #define GPC_PGC_CPU_PDN0x2a0
 
 #define IMR_NUM4
 
+#define GPU_VPU_PUP_REQBIT(1)
+#define GPU_VPU_PDN_REQBIT(0)
+
+#define GPC_CLK_MAX6
+
+struct pu_domain {
+   struct generic_pm_domain base;
+   struct regulator *reg;
+   struct clk *clk[GPC_CLK_MAX];
+   int num_clks;
+};
+
 static void __iomem *gpc_base;
 static u32 gpc_wake_irqs[IMR_NUM];
 static u32 gpc_saved_imrs[IMR_NUM];
@@ -139,3 +161,184 @@ void __init imx_gpc_init(void)
gic_arch_extn.irq_unmask = imx_gpc_irq_unmask;
gic_arch_extn.irq_set_wake = imx_gpc_irq_set_wake;
 }
+
+#ifdef CONFIG_PM
+
+static int imx6q_pm_pu_power_off(struct generic_pm_domain *genpd)
+{
+   struct pu_domain *pu = container_of(genpd, struct pu_domain, base);
+   int iso, iso2sw;
+   u32 val;
+
+   /* Read ISO and ISO2SW power down delays */
+   val = readl_relaxed(gpc_base + GPC_PGC_GPU_PDNSCR);
+   iso = val & 0x3f;
+   iso2sw = (val >> 8) & 0x3f;
+
+   /* Gate off PU domain when GPU/VPU when powered down */
+   writel_relaxed(0x1, gpc_base + GPC_PGC_GPU_PDN);
+
+   /* Request GPC to power down GPU/VPU */
+   val = readl_relaxed(gpc_base + GPC_CNTR);
+   val |= GPU_VPU_PDN_REQ;
+   writel_relaxed(val, gpc_base + GPC_CNTR);
+
+   /* Wait ISO + ISO2SW IPG clock cycles */
+   ndelay((iso + iso2sw) * 1000 / 66);
+
+   regulator_disable(pu->reg);
+
+   return 0;
+}
+
+static int imx6q_pm_pu_power_on(struct generic_pm_domain *genpd)
+{
+   struct pu_domain *pu = container_of(genpd, struct pu_domain, base);
+   int i, ret, sw, sw2iso;
+   u32 val;
+
+   ret = regulator_enable(pu->reg);
+   if (ret) {
+   pr_err("%s: failed to enable regulator: %d\n", __func__, ret);
+   return ret;
+   }
+
+   /* Enable reset clocks for all devices in the PU domain */
+   for (i = 0; i < pu->num_clks; i++)
+   clk_prepare_enable(pu->clk[i]);
+
+   /* Gate off PU domain when GPU/VPU when powered down */
+   writel_relaxed(0x1, gpc_base + GPC_PGC_GPU_PDN);
+
+   /* Read ISO and ISO2SW power down delays */
+   val = readl_relaxed(gpc_base + GPC_PGC_GPU_PUPSCR);
+   sw = val & 0x3f;
+   sw2iso = (val >> 8) & 0x3f;
+
+   /* Request GPC to power up GPU/VPU */
+   val = readl_relaxed(gpc_base + GPC_CNTR);
+   val |= GPU_VPU_PUP_REQ;
+   writel_relaxed(val, gpc_base + GPC_CNTR);
+
+   /* Wait ISO + ISO2SW IPG clock cycles */
+   ndelay((sw + sw2iso) * 1000 / 66);
+
+   /* Disable reset clocks for all devices in the PU domain */
+   for (i = 0; i < pu->num_clks; i++)
+   clk_disable_unprepare(pu->clk[i]);
+
+   return 0;
+}
+
+static struct generic_pm_domain imx6q_arm_domain = {
+   .name = "ARM",
+};
+
+static struct pu_domain imx6q_pu_domain = {
+   .base = {
+   .name = "PU",
+   .power_off = imx6q_pm_pu_power_off,
+   .power_on = imx6q_pm_pu_power_on,
+   .power_off_latency_ns = 25000,
+   .power_on_latency_ns = 200,
+   },
+};
+
+static struct generic_pm_domain imx6sl_display_domain = {
+   .name = "DISPLAY",
+};
+
+static struct generic_pm_domain *imx_gpc_domains[] = {
+   &imx6q_arm_domain,
+   &imx6q_pu_domain.base,
+ 

Re: [PATCH v5 1/3] pwm: rockchip: Allow polarity invert on rk3288

[Thierry Reding]

On Mon, Aug 25, 2014 at 03:59:25PM -0700, Doug Anderson wrote:
> The rk3288 has the ability to invert the polarity of the PWM.  Let's
> enable that ability.  Note that this increases pwm_cells to 3 for
> rk3288.
> 
> Signed-off-by: Doug Anderson 
> Reviewed-by: Caesar Wang 
> ---
> Changes in v5: None
> Changes in v4:
> - Updated comment not to add caveats about pwm_cells 3.
> - rockchip_pwm_set_polarity() is now static.
> - Separate pwm_ops for v1 and v2; no set_polarity() in v1.
> - Added a blank line.
> 
> Changes in v3:
> - Don't store a private copy of polarity.
> - Use true instead of 1.
> - Cleanup init order with "has_invert".
> 
>  .../devicetree/bindings/pwm/pwm-rockchip.txt   |  4 +-
>  drivers/pwm/pwm-rockchip.c | 57 
> ++
>  2 files changed, 50 insertions(+), 11 deletions(-)

Applied, thanks.

Thierry


pgpR5B8GQC89c.pgp
Description: PGP signature

Re: [PATCH 2/9] PM / Domains: Add generic OF-based power domain look-up

[Philipp Zabel]

Hi Ulf,

Am Dienstag, den 26.08.2014, 14:07 +0200 schrieb Ulf Hansson:
> From: Tomasz Figa 
> 
> This patch introduces generic code to perform power domain look-up using
> device tree and automatically bind devices to their power domains.
> Generic device tree binding is introduced to specify power domains of
> devices in their device tree nodes.
> 
> Backwards compatibility with legacy Samsung-specific power domain
> bindings is provided, but for now the new code is not compiled when
> CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
> will change as soon as Exynos power domain code gets converted to use
> the generic framework in further patch.
> 
> Signed-off-by: Tomasz Figa 
> Signed-off-by: Ulf Hansson 

Thank you for updating this series. I've tested patches 1-4
using the PU power domain on i.MX6.

Tested-by: Philipp Zabel 

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/4] CMA & device tree, once again

[Marek Szyprowski]

Hello,

On 2014-08-09 02:28, Laura Abbott wrote:

On 7/14/2014 12:12 AM, Marek Szyprowski wrote:

Hello,

This is one more respin of the patches which add support for creating
reserved memory regions defined in device tree. The last attempt
(http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html)
ended in merging only half of the code, so right now we have complete
documentation merged and only basic code, which implements a half of it
is written in the documentation. Although the merged patches allow to
reserve memory, there is no way of using it for devices and drivers.

This situation makes CMA rather useless, as the main architecture (ARM),
which used it, has been converted from board-file based system
initialization to device tree. Thus there is no place to use direct
calls to dma_declare_contiguous() and some new solution, which bases on
device tree, is urgently needed.

This patch series fixes this issue. It provides two, already widely
discussed and already present in the kernel, drivers for reserved
memory: first based on DMA-coherent allocator, second using Contiguous
Memory Allocator. The first one nicely implements typical 'carved out'
reserved memory way of allocating contiguous buffers in a kernel-style
way. The memory is used exclusively by devices assigned to the given
memory region. The second one allows to reuse reserved memory for
movable kernel pages (like disk buffers, anonymous memory) and migrates
it out when device to allocates contiguous memory buffer. Both driver
provides memory buffers via standard dma-mapping API.

The patches have been rebased on top of latest CMA and mm changes merged
to akmp kernel tree.

To define a 64MiB CMA region following node is needed:

multimedia_reserved: multimedia_mem_region {
compatible = "shared-dma-pool";
reusable;
size = <0x400>;
alignment = <0x40>;
};

Similarly, one can define 64MiB region with DMA coherent memory:

multimedia_reserved: multimedia_mem_region {
compatible = "shared-dma-pool";
no-map;
size = <0x400>;
alignment = <0x40>;
};


Longer term, I think it would be good if we didn't have to use no-map with
the coherent memory. With no-map and dma-coherent.c right now, not only
do you lose out on the physical memory space, you also have to give up
the same amount of vmalloc space for mapping. On arm32, if you have the default
240MB vmalloc space, 64M is ~25% of the vmalloc space. At least on arm you can
make this up by remapping the memory as coherent.

I haven't seen this picked up anywhere yet so you are welcome to add

Tested-by: Laura Abbott 


Right, when the code reaches mainline I will add code which will remove 
no-map

requirement. Changing memory attributes can be handled in this case the same
way as for CMA.

Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/3] dt: Document Qualcomm APQ8084 pinctrl binding

[Georgi Djakov]

Define a new binding for the Qualcomm TLMM (Top-Level Mode Mux) based pin
controller inside the APQ8084.

Signed-off-by: Georgi Djakov 
---
 .../bindings/pinctrl/qcom,apq8084-pinctrl.txt  |  104 
 1 file changed, 104 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt
new file mode 100644
index 000..d0d9a8e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt
@@ -0,0 +1,104 @@
+Qualcomm APQ8084 TLMM block
+
+Required properties:
+- compatible: "qcom,apq8084-pinctrl"
+- reg: Should be the base address and length of the TLMM block.
+- interrupts: Should be the parent IRQ of the TLMM block.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells : Should be two.
+The first cell is the gpio pin number and the
+second cell is used for optional parameters.
+
+Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
+a general description of GPIO and interrupt bindings.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+Qualcomm's pin configuration nodes act as a container for an abitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, drive strength, etc.
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Each subnode only affects those parameters that are explicitly listed. In
+other words, a subnode that lists a mux function but no pin configuration
+parameters implies no information about any pin configuration parameters.
+Similarly, a pin subnode that describes a pullup parameter implies no
+information about e.g. the mux function.
+
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pin configuration subnode:
+
+ pins, function, bias-disable, bias-pull-down, bias-pull-up, drive-strength,
+ output-low, output-high.
+
+Non-empty subnodes must specify the 'pins' property.
+Note that not all properties are valid for all pins.
+
+Valid values for pins are:
+  gpio0-gpio146
+Supports mux, bias and drive-strength
+
+  sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data
+Supports bias and drive-strength
+
+Valid values for function are:
+adsp_ext, audio_ref, blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4, blsp_i2c5,
+blsp_i2c6, blsp_i2c7, blsp_i2c8, blsp_i2c9, blsp_i2c10, blsp_i2c11, blsp_i2c12,
+blsp_spi1, blsp_spi2, blsp_spi3, blsp_spi4, blsp_spi5, blsp_spi6, blsp_spi7,
+blsp_spi8, blsp_spi9, blsp_spi10, blsp_spi11, blsp_spi12, blsp_uart1,
+blsp_uart2, blsp_uart3, blsp_uart4, blsp_uart5, blsp_uart6, blsp_uart7,
+blsp_uart8, blsp_uart9, blsp_uart10, blsp_uart11, blsp_uart12, blsp_uim1,
+blsp_uim2, blsp_uim3, blsp_uim4, blsp_uim5, blsp_uim6, blsp_uim7, blsp_uim8,
+blsp_uim9, blsp_uim10, blsp_uim11, blsp_uim12, cam_mclk0, cam_mclk1, cam_mclk2,
+cam_mclk3, cci_async, cci_async_in0, cci_i2c0, cci_i2c1, cci_timer0, 
cci_timer1,
+cci_timer2, cci_timer3, cci_timer4, edp_hpd, gcc_gp1, gcc_gp2, gcc_gp3, 
gcc_obt,
+gcc_vtt, gp_mn, gp_pdm0, gp_pdm1, gp_pdm2, gp0_clk, gp1_clk, gpio, hdmi_cec,
+hdmi_ddc, hdmi_dtest, hdmi_hpd, hdmi_rcv, hsic, ldo_en, ldo_update, mdp_vsync,
+pci_e0, pci_e0_n, pci_e0_rst, pci_e1, pci_e1_rst, pci_e1_rst_n, 
pci_e1_clkreq_n,
+pri_mi2s, qua_mi2s, sata_act, sata_devsleep, sata_devsleep_n, sd_write,
+sdc_emmc_mode, sdc3, sdc4, sec_mi2s, slimbus, spdif_tx, spkr_i2s, spkr_i2s_ws,
+spss_geni, ter_mi2s, tsif1, tsif2, uim, uim_batt_alarm, gpio
+
+Example:
+
+   tlmm: pinctrl@fd51 {
+   compatible = "qcom,apq8084-pinctrl";
+   reg = <0xfd51 0x4000>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   interrupts = <0 208 0>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&uart2_default>;
+
+   uart2_default: uart2_default {
+   mux {
+   pins = "gpio4", "gpio5";
+   function = "blsp_uart2";
+   };
+
+   tx {
+   pins = "gpio4";
+   drive-strength = <4>;
+   bias-disable;
+ 

[PATCH v2 3/3] ARM: dts: qcom: Add TLMM DT node for APQ8084

[Georgi Djakov]

This patch adds the TLMM node for the APQ8084 platform.

Reviewed-by: Bjorn Andersson 
Signed-off-by: Georgi Djakov 
---
 arch/arm/boot/dts/qcom-apq8084.dtsi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi 
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index b5b156e..21d01e5 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -185,6 +185,16 @@
reg = <0xfc40 0x4000>;
};
 
+   tlmm: pinctrl@fd51 {
+   compatible = "qcom,apq8084-pinctrl";
+   reg = <0xfd51 0x4000>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   interrupts = <0 208 0>;
+   };
+
serial@f995e000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0xf995e000 0x1000>;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html