Re: [PATCH v4 1/5] PCI: Add pci_bus_fixup_irqs().

[Bjorn Helgaas]

[+cc Matthew]

On Wed, Oct 07, 2015 at 01:08:40PM -0700, David Daney wrote:
> On 10/07/2015 12:44 PM, Bjorn Helgaas wrote:
> >Hi David,
> >
> >On Fri, Oct 02, 2015 at 11:43:59AM -0700, David Daney wrote:
> >>From: David Daney 
> >>
> >>pci_bus_fixup_irqs() works like pci_fixup_irqs(), except it only does
> >>the fixups for devices on the specified bus.
> >>
> >>Follow-on patch will use the new function.
> >>
> >>Signed-off-by: David Daney 
> >>---
> >>No change from v2.
> >>
> >>  drivers/pci/setup-irq.c | 30 ++
> >>  include/linux/pci.h |  4 
> >>  2 files changed, 34 insertions(+)
> >>
> >>diff --git a/drivers/pci/setup-irq.c b/drivers/pci/setup-irq.c
> >>index 95c225b..189ad17 100644
> >>--- a/drivers/pci/setup-irq.c
> >>+++ b/drivers/pci/setup-irq.c
> >>@@ -66,3 +66,33 @@ void pci_fixup_irqs(u8 (*swizzle)(struct pci_dev *, u8 
> >>*),
> >>pdev_fixup_irq(dev, swizzle, map_irq);
> >>  }
> >>  EXPORT_SYMBOL_GPL(pci_fixup_irqs);
> >>+
> >>+struct pci_bus_fixup_cb_info {
> >>+   u8 (*swizzle)(struct pci_dev *, u8 *);
> >>+   int (*map_irq)(const struct pci_dev *, u8, u8);
> >>+};
> >>+
> >>+static int pci_bus_fixup_irq_cb(struct pci_dev *dev, void *arg)
> >>+{
> >>+   struct pci_bus_fixup_cb_info *info = arg;
> >>+
> >>+   pdev_fixup_irq(dev, info->swizzle, info->map_irq);
> >>+   return 0;
> >>+}
> >>+
> >>+/*
> >>+ * Fixup the irqs only for devices on the given bus using supplied
> >>+ * swizzle and map_irq function pointers
> >>+ */
> >>+void pci_bus_fixup_irqs(struct pci_bus *bus,
> >>+   u8 (*swizzle)(struct pci_dev *, u8 *),
> >>+   int (*map_irq)(const struct pci_dev *, u8, u8))
> >>+{
> >>+   struct pci_bus_fixup_cb_info info;
> >>+
> >>+   info.swizzle = swizzle;
> >>+   info.map_irq = map_irq;
> >>+   pci_walk_bus(bus, pci_bus_fixup_irq_cb, );
> >
> >I don't like the existing pci_fixup_irqs(), so by transitivity, I
> >don't like pci_bus_fixup_irqs() either.
> 
> We are in agreement with respect to this point.
> 
> > The problem is that in both
> >cases this is a one-time pass over the tree, so we don't handle
> >hot-added devices correctly.
> >
> >I think we need to get rid of pci_fixup_irqs() and somehow integrate
> >it into the pci_device_add() path, where it would be done once for
> >every device we enumerate.
> 
> I also agree with this point.
> 
> > If we did that, I don't think you would
> >need to add pci_bus_fixup_irqs(), would you?
> 
> Nope.
> 
> However, such a change is essentially untestable by me.  So, I
> didn't attempt it.   pci_fixup_irqs() is used by alpha, arm, m68k,
> mips, sh, sparc, tile, unicore32 and other things as well.  If the
> core pci_device_add() code were to suddenly start doing the fixup,
> there would be the potential to break all these things I cannot
> test.

Yep, that's certainly a risk.  I can't test all those arches either,
but I think it's a risk worth taking because the end result is more
maintainable.

Matthew Minter did some really nice work on this last year, but it got
stalled somehow.  I wonder if we can resurrect it?  It seems like it
was pretty close to being ready.  Here's a pointer to the last posting
I saw:

http://lkml.kernel.org/r/141866-21068-1-git-send-email-m...@masarand.com

Bjorn
--
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] of: Add United Radiant Technology Corporation vendor prefix

[Maciej S. Szmigiero]

This adds vendor prefix for United Radiant Technology Corporation,
a provider of liquid crystal display technologies.

Signed-off-by: Maciej Szmigiero 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 82d2ac9..01e3cee 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -223,6 +223,7 @@ toshiba Toshiba Corporation
 toumaz Toumaz
 tplink TP-LINK Technologies Co., Ltd.
 truly  Truly Semiconductors Limited
+urtUnited Radiant Technology Corporation
 usiUniversal Scientific Industrial Co., Ltd.
 v3 V3 Semiconductor
 variscite  Variscite Ltd.

--
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 4/4] ARM: dts: Enable EC vboot context support on Peach boards

[Kukjin Kim]

On 09/21/15 22:38, Emilio López wrote:
> The Peach boards use the EC to store the vboot context information,
> so add the corresponding properties on the EC node to indicate so.
> 
> Reviewed-by: Krzysztof Kozlowski 
> Acked-by: Javier Martinez Canillas 
> Signed-off-by: Emilio López 
> ---
> 
> Changes from v1:
>  - none
> 
> Changes from v2:
>  - collect tags from Krzysztof & Javier
> 
>  arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 +
>  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> index 8f4d76c..ac02fb4 100644
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -935,6 +935,7 @@
>   pinctrl-0 = <_spi_cs _irq>;
>   reg = <0>;
>   spi-max-frequency = <3125000>;
> + google,has-vbc-nvram;
>  
>   controller-data {
>   samsung,spi-feedback-delay = <1>;
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index 7d5b386..b60dec0 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -898,6 +898,7 @@
>   pinctrl-0 = <_spi_cs _irq>;
>   reg = <0>;
>   spi-max-frequency = <3125000>;
> + google,has-vbc-nvram;
>  
>   controller-data {
>   samsung,spi-feedback-delay = <1>;

Applied, thanks.

- Kukjin
--
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: shmobile: porter: enable SATA0

[Sergei Shtylyov]

Enable SATA0 device for the Porter board.

This patch is analogous to the commit 5a62ec57004f ("ARM: shmobile:
henninger: enable SATA0") as there are no differences between the boards
in this respect.

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against 'renesas-devel-20151007-v4.3-rc4' tag of Simon Horman's
'renesas.git' repo.

 arch/arm/boot/dts/r8a7791-porter.dts |4 
 1 file changed, 4 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -154,3 +154,7 @@
cd-gpios = < 22 GPIO_ACTIVE_LOW>;
status = "okay";
 };
+
+ {
+   status = "okay";
+};

--
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] of: add URT UMSH-8596MD-xT panel DT bindings

[Maciej S. Szmigiero]

This patch adds DT bindings for United Radiant Technology
UMSH-8596MD-xT 7.0" WVGA TFT LCD panels.

Signed-off-by: Maciej Szmigiero 
---
 Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt

diff --git a/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt 
b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt
new file mode 100644
index 000..57c5fa4
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt
@@ -0,0 +1,12 @@
+United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel
+
+Supported are LVDS versions (-11T, -19T) and parallel ones
+(-T, -1T, -7T, -20T).
+
+Required properties:
+- compatible: should be one of:
+  "urt,umsh-8596md-t", "urt,umsh-8596md-1t", "urt,umsh-8596md-7t",
+  "urt,umsh-8596md-11t", "urt,umsh-8596md-19t" or "urt,umsh-8596md-20t".
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.

--
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 1/5] PCI: Add pci_bus_fixup_irqs().

[David Daney]

On 10/07/2015 12:44 PM, Bjorn Helgaas wrote:

Hi David,

On Fri, Oct 02, 2015 at 11:43:59AM -0700, David Daney wrote:

From: David Daney 

pci_bus_fixup_irqs() works like pci_fixup_irqs(), except it only does
the fixups for devices on the specified bus.

Follow-on patch will use the new function.

Signed-off-by: David Daney 
---
No change from v2.

  drivers/pci/setup-irq.c | 30 ++
  include/linux/pci.h |  4 
  2 files changed, 34 insertions(+)

diff --git a/drivers/pci/setup-irq.c b/drivers/pci/setup-irq.c
index 95c225b..189ad17 100644
--- a/drivers/pci/setup-irq.c
+++ b/drivers/pci/setup-irq.c
@@ -66,3 +66,33 @@ void pci_fixup_irqs(u8 (*swizzle)(struct pci_dev *, u8 *),
pdev_fixup_irq(dev, swizzle, map_irq);
  }
  EXPORT_SYMBOL_GPL(pci_fixup_irqs);
+
+struct pci_bus_fixup_cb_info {
+   u8 (*swizzle)(struct pci_dev *, u8 *);
+   int (*map_irq)(const struct pci_dev *, u8, u8);
+};
+
+static int pci_bus_fixup_irq_cb(struct pci_dev *dev, void *arg)
+{
+   struct pci_bus_fixup_cb_info *info = arg;
+
+   pdev_fixup_irq(dev, info->swizzle, info->map_irq);
+   return 0;
+}
+
+/*
+ * Fixup the irqs only for devices on the given bus using supplied
+ * swizzle and map_irq function pointers
+ */
+void pci_bus_fixup_irqs(struct pci_bus *bus,
+   u8 (*swizzle)(struct pci_dev *, u8 *),
+   int (*map_irq)(const struct pci_dev *, u8, u8))
+{
+   struct pci_bus_fixup_cb_info info;
+
+   info.swizzle = swizzle;
+   info.map_irq = map_irq;
+   pci_walk_bus(bus, pci_bus_fixup_irq_cb, );


I don't like the existing pci_fixup_irqs(), so by transitivity, I
don't like pci_bus_fixup_irqs() either.


We are in agreement with respect to this point.



 The problem is that in both
cases this is a one-time pass over the tree, so we don't handle
hot-added devices correctly.

I think we need to get rid of pci_fixup_irqs() and somehow integrate
it into the pci_device_add() path, where it would be done once for
every device we enumerate.


I also agree with this point.


 If we did that, I don't think you would
need to add pci_bus_fixup_irqs(), would you?


Nope.

However, such a change is essentially untestable by me.  So, I didn't 
attempt it.   pci_fixup_irqs() is used by alpha, arm, m68k, mips, sh, 
sparc, tile, unicore32 and other things as well.  If the core 
pci_device_add() code were to suddenly start doing the fixup, there 
would be the potential to break all these things I cannot test.


The new pci_bus_fixup_irqs() is really an optimization so that if we 
have multiple buses created by pci-host-generic.c, that we only iterate 
over each device once.  I believe that pci-host-generic.c would still 
operate without these patches 1/5 and 2/5, and could test that if you 
are OK with the remaining three patches.  Or we could merge all 5 and 
live a while longer with the ugliness that is already there.


David Daney

--
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 v12 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support

[Stefan Agner]

Hi Brian,

On 2015-09-29 13:57, Brian Norris wrote:
> Pushed this patch to l2-mtd.git, as it looks pretty much good. Although,
> I'd like raw read support...
> 
> On Wed, Sep 02, 2015 at 06:06:34PM -0700, Stefan Agner wrote:
>> This adds hardware ECC support using the BCH encoder in the NFC IP.
>> The ECC encoder supports up to 32-bit correction by using 60 error
>> correction bytes. There is no sub-page ECC step, ECC is calculated
>> always accross the whole page (up to 2k pages).
>>
>> Limitations:
>> - HW ECC: Only 2K page with 64+ OOB.
>> - HW ECC: Only 24 and 32-bit error correction implemented.
>>
>> Raw writes have been tested using the generic nand_write_page_raw
>> implementation. However, raw reads are currently not possible
>> because the controller need to know whether we are going to use
>> the ECC mode already at NAND_CMD_READ0 command time. At this point
>> we do not have the information whether it is a raw read or a
>> regular read at driver level...
> 
> Hmm, can you get this in ecc.read_page_raw()?

Even just a read_page_raw implementation doesn't help. The controller
requires the ECC to be configured at command issue time, and the driver
issues the command in the cmdfunc callback. The function
nand_do_read_ops calls cmdfunc before ecc.read_page_raw...

I could just bail out in the NAND_CMD_READ0 case, and execute the
command from within the ecc.read_page_raw callback function. A bit
hacky, but that would work.

For that case, it would be nicer if cmdfunc somehow provides the
information that a raw read is requested, we would have that information
in nand_do_read_ops. However, that would need an extension of the
cmdfunc interface... Also, not sure how that should look like.

--
Stefan
--
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] drm: panel-simple: implement URT UMSH-8596MD-xT panel support

[Maciej S. Szmigiero]

This patch implements support for United Radiant Technology
UMSH-8596MD-xT 7.0" WVGA TFT LCD panels in DRM panel-simple
driver.

Signed-off-by: Maciej Szmigiero 
---
This replaces "drm: panel-simple: add URT UMSH-8596MD-xT panel support"
submission.

 drivers/gpu/drm/panel/panel-simple.c | 54 
 1 file changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f97b73e..44d0deb9 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1096,6 +1096,42 @@ static const struct panel_desc shelly_sca07010_bfn_lnn = 
{
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
 };
 
+static const struct display_timing urt_umsh_8596md_timing = {
+   .pixelclock = { 3326, 3326, 3326 },
+   .hactive = { 800, 800, 800 },
+   .hfront_porch = { 41, 41, 41 },
+   .hback_porch = { 216 - 128, 216 - 128, 216 - 128 },
+   .hsync_len = { 71, 128, 128 },
+   .vactive = { 480, 480, 480 },
+   .vfront_porch = { 10, 10, 10 },
+   .vback_porch = { 35 - 2, 35 - 2, 35 - 2 },
+   .vsync_len = { 2, 2, 2 },
+   .flags = DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_NEGEDGE |
+   DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
+};
+
+static const struct panel_desc urt_umsh_8596md_lvds = {
+   .timings = _umsh_8596md_timing,
+   .num_timings = 1,
+   .bpc = 6,
+   .size = {
+   .width = 152,
+   .height = 91,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+};
+
+static const struct panel_desc urt_umsh_8596md_parallel = {
+   .timings = _umsh_8596md_timing,
+   .num_timings = 1,
+   .bpc = 6,
+   .size = {
+   .width = 152,
+   .height = 91,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+};
+
 static const struct of_device_id platform_of_match[] = {
{
.compatible = "ampire,am800480r3tmqwa1h",
@@ -1191,6 +1227,24 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "shelly,sca07010-bfn-lnn",
.data = _sca07010_bfn_lnn,
}, {
+   .compatible = "urt,umsh-8596md-t",
+   .data = _umsh_8596md_parallel,
+   }, {
+   .compatible = "urt,umsh-8596md-1t",
+   .data = _umsh_8596md_parallel,
+   }, {
+   .compatible = "urt,umsh-8596md-7t",
+   .data = _umsh_8596md_parallel,
+   }, {
+   .compatible = "urt,umsh-8596md-11t",
+   .data = _umsh_8596md_lvds,
+   }, {
+   .compatible = "urt,umsh-8596md-19t",
+   .data = _umsh_8596md_lvds,
+   }, {
+   .compatible = "urt,umsh-8596md-20t",
+   .data = _umsh_8596md_parallel,
+   }, {
/* sentinel */
}
 };

--
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 3/4] platform/chrome: Support reading/writing the vboot context

[Olof Johansson]

On Mon, Sep 21, 2015 at 10:38:22AM -0300, Emilio L??pez wrote:
> Some EC implementations include a small nvram space used to store
> verified boot context data. This patch offers a way to expose this
> data to userspace.
> 
> Reviewed-by: Javier Martinez Canillas 
> Signed-off-by: Emilio L??pez 

Applied, thanks!


-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

Re: [PATCH v3 3/3] dmaengine: mpc512x: initialize with subsys_initcall()

[Alexander Popov]

On 07.10.2015 17:17, Vinod Koul wrote:
> On Thu, Sep 24, 2015 at 08:28:57PM +0300, Alexander Popov wrote:
>> Initialize Freescale MPC512x DMA driver with subsys_initcall()
>> to allow the depending drivers to call dma_request_slave_channel()
>> during their probe.
> 
> Why can't we use defered probe ? I have been asking people to not move init
> levels and esnure we have right solutions using defered probe

Thanks, Vinod, I'll do it in v4.

Best regards,
Alexander

--
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] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Timo Sigurdsson]

sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209 PMU
driver, so add them to allow for voltage-scaling with cpufreq-dt. Also
add board-specific OPP to use slightly higher voltages at lower
frequencies since Kevin Hilman reported that not all BananaPi boards run
stable at the default voltages inherited by sun7i-a20.dtsi.

Signed-off-by: Timo Sigurdsson 
---
Changes since v2:

- (Re)Added board-specific OPP after Kevin Hilman reported problems with
the default voltages at lower frequencies
---
 arch/arm/boot/dts/sun7i-a20-bananapi.dts | 45 +---
 1 file changed, 41 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts 
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 9f7b472..39b6b67b 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -92,6 +92,20 @@
status = "okay";
 };
 
+ {
+   cpu-supply = <_dcdc2>;
+   operating-points = <
+   /* kHzuV */
+   96  140
+   912000  140
+   864000  135
+   72  125
+   528000  115
+   312000  110
+   144000  105
+   >;
+};
+
  {
status = "okay";
 };
@@ -119,13 +133,9 @@
status = "okay";
 
axp209: pmic@34 {
-   compatible = "x-powers,axp209";
reg = <0x34>;
interrupt-parent = <_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
-   interrupt-controller;
-   #interrupt-cells = <1>;
};
 };
 
@@ -182,6 +192,33 @@
};
 };
 
+#include "axp209.dtsi"
+
+_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpu";
+};
+
+_dcdc3 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-int-dll";
+};
+
+_ldo1 {
+   regulator-name = "vdd-rtc";
+};
+
+_ldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "avcc";
+};
+
 _usb1_vbus {
status = "okay";
 };
-- 
2.1.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: [PATCH-RFC 6/7] drivers: of: ifdef out cmdline section

[Rob Herring]

On Wed, Oct 7, 2015 at 11:27 AM,   wrote:
> On Tue, Oct 06, 2015 at 12:14:43PM -0500, Rob Herring wrote:
>> On Tue, Oct 6, 2015 at 10:47 AM, Daniel Walker  wrote:
>> > It looks like there's some seepage of cmdline stuff into
>> > the generic device tree code. This conflicts with the
>> > generic cmdline implementation so I remove it in the case
>> > when that's enabled.
>>
>> Nice series in general. I've had passing desire to do this every time
>> I run into the command line code.
>>
>> The DT handling of the command line is generic across architectures.
>> The current design is working around that the kernel command line code
>> is not that way. I think we can take this a bit further by making the
>> generic DT code add the command line string directly rather than
>> relying on the arch to do that. Then we can remove all command line
>> handling from the arch code. I would also look at whether we can make
>> boot_command_line static rather than directly accessed. We might have
>> to leave it public for now, but could treat it as static for generic
>> cmdline case.
>>
>
> Sorry I didn't respond sooner. I was waiting to see if there were more 
> replies.
>
> One of my colleague suggested something similar, I was reluctant to change 
> anything
> prior to sending it out so I could get more feedback on the direction.
>
> So your suggesting this patch be something like,
>
> #ifdef CONFIG_GENERIC_CMDLINE
> // call generic cmdline functions
> #else
> // keep what's there currently
> #endif

I think so yes, but I'd hope that the else case is empty. You've
converted the hard arches already. I'd guess the rest using DT would
be easy to convert as they either don't use DT for command line at all
or always use it.

> Then remove the arch specific generic cmdline changes in the architecture 
> code for the DT path..
> Most of them have two places where they add in the command line. One from the 
> device tree, and
> another place that's from the bootloader. For example , ARM has the device 
> tree call, then another
> for atags. I don't think these device tree changes would allow us to remove 
> the atags version, also
> the boot_command_line wouldn't be able to be static.

For ARM, yes, you will have to keep the ATAGS part, but ATAGS and DT
are mutually exclusive. I think that is generally true for other
arches.

Rob
--
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 0/17] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi all,

Friendly ping.   :)


Best regards,
- Yakir


On 09/22/2015 03:20 PM, Yakir Yang wrote:

Hi all,

The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM :)

This time I create this version on linux-next branch (tag is next-20150918),
and also applied this version to Heiko github eDP branch to verify the function.
(https://github.com/mmind/linux-rockchip/tree/tmp/edp-with-veyron)
Glad to say my chromebook "cnm,n116bgeea2" eDP panel just lighted rightly on
Heiko branch. And after back port this series to chromeos-3.14 tree, my rk3288
SDK board still can light my 2K DisplayPort monitor. So this time would be okay
on mainline kernel and chromeos-3.14 tree. ;)

Due to no Exynos board in my side, so I haven't verified the eDP function on
samsung platform, I only ensure that there are no obvious compiled error. Any
help would be greatly appreciated. :)

Thanks,
- Yakir

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
   the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
   attch function. Cause once platform failed at attach, core driver should
   still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
   patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
   from exynos_dp code, and rephrase reasonable commit message, and
   remove some controversial style (Krzysztof)
 -  analogix_dp_write_byte_to_dpcd(
 -  dp, DP_TEST_RESPONSE,
 +  analogix_dp_write_byte_to_dpcd(dp,
 +  DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
   to get the backword timing values. Krzysztof suggest me that driver could use
   the "of_property_read_bool" to get backword timing values, but that interfacs
   would modify the original drm_display_mode timing directly (whether those
   properties exists or not).
- Correct the misspell in commit message. (Krzysztof)
- Remove the empty line at the end of document, and correct the endpoint
   numbers in the example DT node, and remove the regulator iomux setting
   in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
   support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
   the exist "grf" syscon already. And rename the example DT node from
   "edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
   struct" to "static const struct". And correct the input paramters of
   devm_phy_create() interfaces. (Heiko)
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
   elemets in document. (Rob & Heiko)
- Fix compiled error (Heiko)
- Using the connector display info message to configure eDP driver input
   video mode, but hard code CRTC video output mode to RGBaaa.

Changes in v4:
- Update "analogix,hpd-gpios" to "hpd-gpios" DT propery. (Rob)
- Rename "analogix_dp-exynos.c" file name to "exynos_dp.c" (Jingoo)
- Create a separate folder for analogix code in bridge/ (Archit)
- Update commit message more readable. (Jingoo)
- Adjust the order from 05 to 04
- Provide backword compatibility with samsung. (Krzysztof)
- Split all DTS changes, and provide backward compatibility. Mark old
   properties as deprecated but still support them. (Krzysztof)
- Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
- Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
 "analogix,color-space" & "analogix,color-depth"   &
 "analogix,link-rate"   & "analogix,lane-count"&
 "analogix,ycbcr-coeff" & "analogix,dynamic-range" &
 "vsync-active-high"& "hsync-active-high"  & "interlaces"
- Separate all DTS changes to a separate patch. (Krzysztof)
- Remove some deprecated DT properties in rockchip dp document.
- Add commit message, and remove the redundant rockchip_dp_phy_init()
   function, 

Re: [PATCH] ARM: bcm2835: add label for uart0

[Stefan Wahren]

Am 07.10.2015 um 04:26 schrieb Stephen Warren:
> On 10/06/2015 03:53 PM, Eric Anholt wrote:
>> Stefan Wahren  writes:
>>
>>> This patch adds a label for uart0 to allow changing of uart0
>>> pins.
>>>
>>> Signed-off-by: Stefan Wahren 
>> This patch seems innocuous, but could you clarify for me how
>> exactly you change the uart0 pins, and why one would do that?
> I /assume/ this is so that some other DT file (that includes the
> edited file) can add some pinctrl-related properties to this DT node,
> using syntax such as:
>
>  {
> new content;
> };
>
> If so, the patch,
> Acked-by: Stephen Warren 

Your assumption is correct. In case the UART should be used on a custom
board with Raspberry Pi Compute Module and a microcontroller this change
is necessary to reference the UART:

 {
  // ...

  uart0_pins: uart0_pins {
brcm,pins = <36 37>;
brcm,function = ;
  };
}

 {
  pinctrl-names = "default";
  pinctrl-0 = <_pins>;
  status = "okay";
};

Thanks

Stefan

--
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 v4 2/4] drivers: clk: st: PLL rate change implementation for DVFS

[Gabriel Fernandez]

Change A9 PLL rate, as per requirement from the cpufreq framework,
for DVFS. For rate change, the A9 clock needs to be temporarily sourced
from PLL external to A9 and then sourced back to A9-PLL

Signed-off-by: Pankaj Dev 
Signed-off-by: Gabriel Fernandez 
---
 drivers/clk/st/clkgen-mux.c |   3 +
 drivers/clk/st/clkgen-pll.c | 221 ++--
 drivers/clk/st/clkgen.h |   2 +
 3 files changed, 216 insertions(+), 10 deletions(-)

diff --git a/drivers/clk/st/clkgen-mux.c b/drivers/clk/st/clkgen-mux.c
index 4f7f6c0..5dc5ce2 100644
--- a/drivers/clk/st/clkgen-mux.c
+++ b/drivers/clk/st/clkgen-mux.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include "clkgen.h"
 
 static DEFINE_SPINLOCK(clkgena_divmux_lock);
 static DEFINE_SPINLOCK(clkgenf_lock);
@@ -576,6 +577,7 @@ static struct clkgen_mux_data stih415_a9_mux_data = {
.offset = 0,
.shift = 1,
.width = 2,
+   .lock = _a9_lock,
 };
 static struct clkgen_mux_data stih416_a9_mux_data = {
.offset = 0,
@@ -586,6 +588,7 @@ static struct clkgen_mux_data stih407_a9_mux_data = {
.offset = 0x1a4,
.shift = 0,
.width = 2,
+   .lock = _a9_lock,
 };
 
 static const struct of_device_id mux_of_match[] = {
diff --git a/drivers/clk/st/clkgen-pll.c b/drivers/clk/st/clkgen-pll.c
index 092f82c..494848e 100644
--- a/drivers/clk/st/clkgen-pll.c
+++ b/drivers/clk/st/clkgen-pll.c
@@ -23,6 +23,7 @@
 #include "clkgen.h"
 
 static DEFINE_SPINLOCK(clkgena_c32_odf_lock);
+DEFINE_SPINLOCK(clkgen_a9_lock);
 
 /*
  * Common PLL configuration register bits for PLL800 and PLL1600 C65
@@ -39,6 +40,7 @@ static DEFINE_SPINLOCK(clkgena_c32_odf_lock);
 #define C32_IDF_MASK (0x7)
 #define C32_ODF_MASK (0x3f)
 #define C32_LDF_MASK (0x7f)
+#define C32_CP_MASK (0x1f)
 
 #define C32_MAX_ODFS (4)
 
@@ -51,15 +53,20 @@ struct clkgen_pll_data {
struct clkgen_field pdiv;
struct clkgen_field idf;
struct clkgen_field ldf;
+   struct clkgen_field cp;
unsigned int num_odfs;
struct clkgen_field odf[C32_MAX_ODFS];
struct clkgen_field odf_gate[C32_MAX_ODFS];
+   bool switch2pll_en;
+   struct clkgen_field switch2pll;
+   spinlock_t *lock;
const struct clk_ops *ops;
 };
 
 static const struct clk_ops st_pll1600c65_ops;
 static const struct clk_ops st_pll800c65_ops;
 static const struct clk_ops stm_pll3200c32_ops;
+static const struct clk_ops stm_pll3200c32_a9_ops;
 static const struct clk_ops st_pll1200c32_ops;
 
 static const struct clkgen_pll_data st_pll1600c65_ax = {
@@ -242,7 +249,11 @@ static const struct clkgen_pll_data st_pll3200c32_407_a9 = 
{
.num_odfs = 1,
.odf= { CLKGEN_FIELD(0x1b0, C32_ODF_MASK,   8) },
.odf_gate   = { CLKGEN_FIELD(0x1ac, 0x1,28) },
-   .ops= _pll3200c32_ops,
+   .switch2pll_en  = true,
+   .cp = CLKGEN_FIELD(0x1a8,   C32_CP_MASK,1),
+   .switch2pll = CLKGEN_FIELD(0x1a4,   0x1,1),
+   .lock = _a9_lock,
+   .ops= _pll3200c32_a9_ops,
 };
 
 /**
@@ -268,10 +279,26 @@ struct clkgen_pll {
struct clk_hw   hw;
struct clkgen_pll_data  *data;
void __iomem*regs_base;
+   spinlock_t  *lock;
+
+   u32 ndiv;
+   u32 idf;
+   u32 odf;
+   u32 cp;
 };
 
 #define to_clkgen_pll(_hw) container_of(_hw, struct clkgen_pll, hw)
 
+struct stm_pll {
+   unsigned long mdiv;
+   unsigned long ndiv;
+   unsigned long pdiv;
+   unsigned long odf;
+   unsigned long idf;
+   unsigned long ldf;
+   unsigned long cp;
+};
+
 static int clkgen_pll_is_locked(struct clk_hw *hw)
 {
struct clkgen_pll *pll = to_clkgen_pll(hw);
@@ -287,7 +314,7 @@ static int clkgen_pll_is_enabled(struct clk_hw *hw)
return !poweroff;
 }
 
-static int clkgen_pll_enable(struct clk_hw *hw)
+static int __clkgen_pll_enable(struct clk_hw *hw)
 {
struct clkgen_pll *pll = to_clkgen_pll(hw);
void __iomem *base =  pll->regs_base;
@@ -303,24 +330,62 @@ static int clkgen_pll_enable(struct clk_hw *hw)
ret = readl_relaxed_poll_timeout(base + field->offset, reg,
!!((reg >> field->shift) & field->mask),  0, 1);
 
-   if (!ret)
+   if (!ret) {
+   if (pll->data->switch2pll_en)
+   CLKGEN_WRITE(pll, switch2pll, 0);
+
pr_debug("%s:%s enabled\n", __clk_get_name(hw->clk), __func__);
+   }
 
return ret;
 }
 
-static void clkgen_pll_disable(struct clk_hw *hw)
+static int clkgen_pll_enable(struct clk_hw *hw)
+{
+   struct clkgen_pll *pll = to_clkgen_pll(hw);
+   unsigned long flags = 0;
+   int ret = 0;
+
+   if (pll->lock)
+   spin_lock_irqsave(pll->lock, flags);
+
+   ret = __clkgen_pll_enable(hw);
+
+   if 

Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi Javier,

On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:

Hello Yakir,

On 10/07/2015 08:25 AM, Yakir Yang wrote:

Hi all,

Friendly ping.   :)


Best regards,
- Yakir



Do you have a tree that I can use to test these patches?


Wow, thanks a lot, I do have a tree on github 
[https://github.com/yakir-Yang/linux/tree/analogix_dp],

crossing my finger, wish things works..;)

Thanks,
- Yakir



Best regards,



--
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 2/4] drivers: clk: st: PLL rate change implementation for DVFS

[Gabriel Fernandez]

Hi Stephen,

No there is no reason. I will fix it.

Thanks for review.

Best regards

Gabriel

On 6 October 2015 at 20:06, Stephen Boyd  wrote:
> On 10/05, Gabriel Fernandez wrote:
>> @@ -452,7 +651,7 @@ static const struct clk_ops st_pll1200c32_ops = {
>>  static struct clk * __init clkgen_pll_register(const char *parent_name,
>>   struct clkgen_pll_data  *pll_data,
>>   void __iomem *reg,
>> - const char *clk_name)
>> + const char *clk_name, spinlock_t *lock)
>
> Is there a reason we pass lock here but never use it in this
> function?
>
>>  {
>>   struct clkgen_pll *pll;
>>   struct clk *clk;
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
--
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 0/17] Add Analogix Core Display Port Driver

[Javier Martinez Canillas]

Hello Yakir,

On 10/07/2015 08:25 AM, Yakir Yang wrote:
> Hi all,
> 
> Friendly ping.   :)
> 
> 
> Best regards,
> - Yakir
> 
> 

Do you have a tree that I can use to test these patches?

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 v13 2/2] ARM: dts: vf-colibri: enable NAND flash controller

[Stefan Agner]

Enable NAND access by adding pinmux and NAND flash controller node
to device tree. The NAND chips currently used on the Colibri VF61
requires 8-bit ECC per 512 byte page, hence specify 32-bit ECC
strength per 2k page size.

Reviewed-by: Brian Norris 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri.dtsi | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
b/arch/arm/boot/dts/vf-colibri.dtsi
index 68ca125..e5949b9 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -52,6 +52,26 @@
pinctrl-0 = <_i2c0>;
 };
 
+ {
+   assigned-clocks = < VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_nfc>;
+   status = "okay";
+
+   nand@0 {
+   compatible = "fsl,vf610-nfc-nandcs";
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <32>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pwm0>;
@@ -156,6 +176,25 @@
>;
};
 
+   pinctrl_nfc: nfcgrp {
+   fsl,pins = <
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1182
-- 
2.6.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 v13 1/2] ARM: dts: vf610twr: add NAND flash controller peripherial

[Stefan Agner]

This adds the NAND flash controller (NFC) peripherial. The driver
supports the SLC NAND chips found on Freescale's Vybrid Tower System
Module. The Micron NAND chip on the module needs 4-bit ECC per 512
byte page. Use 24-bit ECC per 2k page, which is supported by the
driver.

Signed-off-by: Bill Pringlemeir 
Reviewed-by: Brian Norris 
Signed-off-by: Stefan Agner 
---
Hi Shawn,

This are the rebased dt changes of the Vybrid MTD NAND driver
patchset. The driver part has recently been merged:
https://lkml.org/lkml/2015/9/2/678

The driver is lined up fo 4.4, I hope those changes make it into
4.4 as well.

Changes since v12:
- Rebased (and fixed merge conflict)
- Fix indent

 arch/arm/boot/dts/vf610-twr.dts | 47 +
 arch/arm/boot/dts/vfxxx.dtsi| 11 ++
 2 files changed, 58 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 375ab23..5438ee4 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -237,6 +237,33 @@
>;
};
 
+   pinctrl_nfc: nfcgrp {
+   fsl,pins = <
+   VF610_PAD_PTD31__NF_IO150x28df
+   VF610_PAD_PTD30__NF_IO140x28df
+   VF610_PAD_PTD29__NF_IO130x28df
+   VF610_PAD_PTD28__NF_IO120x28df
+   VF610_PAD_PTD27__NF_IO110x28df
+   VF610_PAD_PTD26__NF_IO100x28df
+   VF610_PAD_PTD25__NF_IO9 0x28df
+   VF610_PAD_PTD24__NF_IO8 0x28df
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1582
@@ -274,6 +301,26 @@
};
 };
 
+ {
+   assigned-clocks = < VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_nfc>;
+   status = "okay";
+
+   nand@0 {
+   compatible = "fsl,vf610-nfc-nandcs";
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   nand-bus-width = <16>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <24>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pwm0>;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 6865137..6736bae 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -564,6 +564,17 @@
status = "disabled";
};
 
+   nfc: nand@400e {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-nfc";
+   reg = <0x400e 0x4000>;
+   interrupts = <83 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < VF610_CLK_NFC>;
+   clock-names = "nfc";
+   status = "disabled";
+   };
+
i2c2: i2c@400e6000 {
#address-cells = <1>;
#size-cells = <0>;
-- 
2.6.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 1/2] PCI: of: Add 64-bit address recognition without LPAE support

[Rob Herring]

On Wed, Oct 7, 2015 at 5:49 AM, Pavel Fedin  wrote:
> If non-LPAE kernel is booted up on a machine with 64-bit PCI resources,
> PCI controller probe fails with:
>
> PCI host bridge /pcie@1000 ranges:
>IO 0x3eff..0x3eff -> 0x
>   MEM 0x1000..0x3efe -> 0x1000
>   MEM 0x80..0xff -> 0x80
> pci-host-generic 3f00.pcie: resource collision: [mem 
> 0x-0x] conflicts with /pl011@900 [mem 
> 0x0900-0x09000fff]
> pci-host-generic: probe of 3f00.pcie failed with error -16
>
> This happens because res->start assignment in of_pci_range_to_resource()
> truncates the upper part of the address, because res->start is of
> phys_addr_t type, which is 32-bit on non-LPAE kernels.
>
> This patch adds explicit recognition of 64-bit resources, preventing from
> potential problems when e. g. 0x801234 would be converted to
> 0x1234.
>
> Signed-off-by: Pavel Fedin 
> ---
>  drivers/of/address.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 384574c..9a8f8c3 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -330,6 +330,12 @@ int of_pci_range_to_resource(struct of_pci_range *range,
> }
> res->start = port;
> } else {
> +#ifndef CONFIG_PHYS_ADDR_T_64BIT
> +   if (upper_32_bits(range->cpu_addr)) {

Drop the ifdef:

if ((sizeof(phys_addr_t) > 4) && upper_32_bits(range->cpu_addr)) {

Seems fine otherwise.

> +   err = -EINVAL;
> +   goto invalid_range;
> +   }
> +#endif
> res->start = range->cpu_addr;
> }
> res->end = res->start + range->size - 1;
> --
> 2.4.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: [PATCH v4 1/5] PCI: Add pci_bus_fixup_irqs().

[Matthew Minter]

On Wednesday 07 October 2015 18:08:47 Bjorn Helgaas wrote:
> [+cc Matthew]
> 
> On Wed, Oct 07, 2015 at 01:08:40PM -0700, David Daney wrote:
> > On 10/07/2015 12:44 PM, Bjorn Helgaas wrote:
> > >Hi David,
> > >
> > >On Fri, Oct 02, 2015 at 11:43:59AM -0700, David Daney wrote:
> > >>From: David Daney 
> > >>
> > >>pci_bus_fixup_irqs() works like pci_fixup_irqs(), except it only does
> > >>the fixups for devices on the specified bus.
> > >>
> > >>Follow-on patch will use the new function.
> > >>
> > >>Signed-off-by: David Daney 
> > >>---
> > >>No change from v2.
> > >>
> > >>  drivers/pci/setup-irq.c | 30 ++
> > >>  include/linux/pci.h |  4 
> > >>  2 files changed, 34 insertions(+)
> > >>
> > >>diff --git a/drivers/pci/setup-irq.c b/drivers/pci/setup-irq.c
> > >>index 95c225b..189ad17 100644
> > >>--- a/drivers/pci/setup-irq.c
> > >>+++ b/drivers/pci/setup-irq.c
> > >>@@ -66,3 +66,33 @@ void pci_fixup_irqs(u8 (*swizzle)(struct pci_dev *,
> > >>u8 *),> >>
> > >>  pdev_fixup_irq(dev, swizzle, map_irq);
> > >>  
> > >>  }
> > >>  EXPORT_SYMBOL_GPL(pci_fixup_irqs);
> > >>
> > >>+
> > >>+struct pci_bus_fixup_cb_info {
> > >>+ u8 (*swizzle)(struct pci_dev *, u8 *);
> > >>+ int (*map_irq)(const struct pci_dev *, u8, u8);
> > >>+};
> > >>+
> > >>+static int pci_bus_fixup_irq_cb(struct pci_dev *dev, void *arg)
> > >>+{
> > >>+ struct pci_bus_fixup_cb_info *info = arg;
> > >>+
> > >>+ pdev_fixup_irq(dev, info->swizzle, info->map_irq);
> > >>+ return 0;
> > >>+}
> > >>+
> > >>+/*
> > >>+ * Fixup the irqs only for devices on the given bus using supplied
> > >>+ * swizzle and map_irq function pointers
> > >>+ */
> > >>+void pci_bus_fixup_irqs(struct pci_bus *bus,
> > >>+ u8 (*swizzle)(struct pci_dev *, u8 *),
> > >>+ int (*map_irq)(const struct pci_dev *, u8, u8))
> > >>+{
> > >>+ struct pci_bus_fixup_cb_info info;
> > >>+
> > >>+ info.swizzle = swizzle;
> > >>+ info.map_irq = map_irq;
> > >>+ pci_walk_bus(bus, pci_bus_fixup_irq_cb, );
> > >
> > >I don't like the existing pci_fixup_irqs(), so by transitivity, I
> > >don't like pci_bus_fixup_irqs() either.
> > 
> > We are in agreement with respect to this point.
> > 
> > > The problem is that in both
> > >
> > >cases this is a one-time pass over the tree, so we don't handle
> > >hot-added devices correctly.
> > >
> > >I think we need to get rid of pci_fixup_irqs() and somehow integrate
> > >it into the pci_device_add() path, where it would be done once for
> > >every device we enumerate.
> > 
> > I also agree with this point.
> > 
> > > If we did that, I don't think you would
> > >
> > >need to add pci_bus_fixup_irqs(), would you?
> > 
> > Nope.
> > 
> > However, such a change is essentially untestable by me.  So, I
> > didn't attempt it.   pci_fixup_irqs() is used by alpha, arm, m68k,
> > mips, sh, sparc, tile, unicore32 and other things as well.  If the
> > core pci_device_add() code were to suddenly start doing the fixup,
> > there would be the potential to break all these things I cannot
> > test.
> 
> Yep, that's certainly a risk.  I can't test all those arches either,
> but I think it's a risk worth taking because the end result is more
> maintainable.
> 
> Matthew Minter did some really nice work on this last year, but it got
> stalled somehow.  I wonder if we can resurrect it?  It seems like it
> was pretty close to being ready.  Here's a pointer to the last posting
> I saw:
> 
> http://lkml.kernel.org/r/141866-21068-1-git-send-email-m...@masarand.com
> 
> Bjorn

Thanks for adding me into the loop,

Yes, I had been working on this last year, and got a patchset that was tested 
on arm, x86 (and amd64), and slightly tested on powerpc. However I was not 
able to test other architectures as they were not available in the software 
lab I work in but should in theory work on all arches the kernel runs on.

I can say that that patchset is being used by several projects out of tree 
currently but unfortunately due to a shift in priorities in the lab I was 
working for I lost access to the resources to develop and test the patch 
easily.

I have done some additional work personally on it but so far have not got 
anything that I am happy to submit for inclusion in tree. (due to a number of 
issues in structure and  a complication relating to weak functions where 
multiple variations of the same arch exist.

You can see in thread that is linked above 
(http://lkml.kernel.org/r/141866-21068-1-git-send-email-m...@masarand.com)
some feedback on the issues that need to be solved.

I also expect that the patchset needs to be pulled forward to a newer kernel 
as I have been working in a frozen tree without rebasing to reduce test 
complexity.

I would be happy to put some time this weekend if possible into reviewing the 
state of this and seeing if I can at least put together a version running on a 
recent kernel. I can also go over the 

Re: [PATCH] ARM: shmobile: porter: enable SATA0

[Simon Horman]

On Thu, Oct 08, 2015 at 01:00:06AM +0300, Sergei Shtylyov wrote:
> Enable SATA0 device for the Porter board.
> 
> This patch is analogous to the commit 5a62ec57004f ("ARM: shmobile:
> henninger: enable SATA0") as there are no differences between the boards
> in this respect.
> 
> Signed-off-by: Sergei Shtylyov 

Thanks, I have queued this up for v4.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: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Andrew]

On 2015-10-07 21:36, Rob Herring wrote:

On Wed, Oct 7, 2015 at 5:36 AM, Andrew  wrote:

On 2015-10-07 02:01, Laura Abbott wrote:


On 10/6/15 3:35 PM, Rob Herring wrote:


On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott 


wrote:


From: Laura Abbott 


This adds a base set of devicetree bindings for the Ion memory
manager. This supports setting up the generic set of heaps and
their properties.

Signed-off-by: Laura Abbott 
Signed-off-by: Andrew Andrianov 
---
  drivers/staging/android/ion/devicetree.txt | 53
++



I have no issue with this going in here, but I do have lots of 
issues

with this binding.


  1 file changed, 53 insertions(+)
  create mode 100644 drivers/staging/android/ion/devicetree.txt

diff --git a/drivers/staging/android/ion/devicetree.txt
b/drivers/staging/android/ion/devicetree.txt
new file mode 100644
index 000..4a0c941
--- /dev/null
+++ b/drivers/staging/android/ion/devicetree.txt
@@ -0,0 +1,53 @@
+Ion Memory Manager
+
+Ion is a memory manager that allows for sharing of buffers via 
dma-buf.
+Ion allows for different types of allocation via an abstraction 
called
+a 'heap'. A heap represents a specific type of memory. Each heap 
has

+a different type. There can be multiple instances of the same heap
+type.
+
+Required properties for Ion
+
+- compatible: "linux,ion"
+
+All child nodes of a linux,ion node are interpreted as heaps
+
+required properties for heaps
+
+- linux,ion-heap-id: The Ion heap id used for allocation selection
+- linux,ion-heap-type: Ion heap type defined in ion.h
+- linux,ion-heap-name: Human readble name of the heap
+
+
+Optional properties
+- memory-region: A phandle to a memory region. Required for DMA 
heap

type
+(see reserved-memory.txt for details on the reservation)
+- linux,ion-heap-align: Alignment for the heap.
+
+Example:
+
+   ion {
+   compatbile = "linux,ion";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ion-system-heap {
+   linux,ion-heap-id = <0>;
+   linux,ion-heap-type = 
;

+   linux,ion-heap-name = "system";



How does this vary across platforms? Is all of this being pushed 
down

to DT, because there is no coordination of this at the kernel ABI
level across platforms. In other words, why can't heap 0 be 
hardcoded

as system heap in the driver. It seems to me any 1 of these 3
properties could be used to derive the other 2.



Right now there is no guarantee heap IDs will be the same across
platforms. The heap IDs are currently part of the userspace ABI
as well since userspace clients must pass in a mask of the heap
IDs to allocate from. If we assume all existing clients could change,
heaps such as the system heap could be mandated to have the same
heap ID but we'd still run into problems if you have multiple
heaps of the same type (e.g. multiple carveouts)


Vendors largely ignore the kernel-userspace ABI and anything in
staging is not a ABI. So arguments about what the ABI is currently is
pointless IMO.

Pushing an inconsistent kernel ABI to DT is not the answer.


Totally agree here.





I don't really like the idea of enforcing any IDs here. As of now
heap ids are generally something VERY platform-specific
(or even product-specific). Personally I'd prefer something like this
for userspace apps:

int id1 = ion_get_heap_id("camera");
if (id1 < 0) {
  fprintf(stderr, "Invalid heap id");
  exit(1);
}

int id2 = ion_get_heap_id("backup-heap");
if (id2 < 0) {
  fprintf(stderr, "Invalid heap id");
  exit(1);
}


We've learned that creating number spaces like this are bad (irqs,
gpios, /dev nodes). We should move away from that. Why should
userspace care about IDs or what the IDs are? An ID is just encoding
certain implicit requirements. So are the strings here. Users should
express what capabilities, restrictions, etc. they have, and then the
kernel can find the best heap.


I'd argue about that point, since sometimes kernel might NOT know
all the hardware details behind some of the heaps or how they are going 
to
be used. Hence it can't decide a proper heap. And that's where things 
get ugly.


Real-world example: There are several on-chip SRAM banks that make up 
several

heaps. Say, IM0, IM1, IM2.

Technically - they are all DMA, and all work. But the hardware guys hand 
you

a handful of weird recommendations, like:
* Decoder will work faster if you use bank IM2 for internal buffers,
and prefer DDR bank A for decoded frames.
* DSP should stick with IM1, and please prefer DDR bank B for buffers

When several such devices are involved in one chain - things may get
even weirder. Having manual control over where allocations are made 
allows
us to keep all these voodoo magicks away from the kernel and (hopefully) 
keep

vendors from dirty hacks into ion itself.




...

Re: [PATCH] ARM: shmobile: porter: add SDHI0/2 DT support

[Sergei Shtylyov]

On 10/07/2015 06:39 AM, Simon Horman wrote:


Define the Porter board dependent part of the SDHI0/2 device nodes along with
the  necessary  voltage regulators (note that the Vcc regulators are dummy --
they are required but don't actually exist on the board). Also, GPIOs have to
be used for the CD and WP signals due to the SDHI driver constraints...

This patch is analogous to the commit 1299df03d719 (ARM: shmobile: henninger:
add SDHI0/2 DT support) as there  are no differences between those boards in
this respect.

Signed-off-by: Sergei Shtylyov 

---
This patch is against the 'renesas-devel-20151006-v4.3-rc4' tag of Simon
Horman's 'renesas.git' repo.


Thanks I have queued this up after addressing some issues
in the changelog that checkpatch complained about:



* text > 75 characters wide
* Missing '"' around name of patch referred to


   Sorry about that, forgot to run thru checkpatch.pl (as usual :-).

MBR, Sergei

--
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] devicetree: add binding for generic mmio clocksource

[Rob Herring]

On Wed, Oct 7, 2015 at 11:47 AM, Måns Rullgård  wrote:
> Mark Rutland  writes:
>
>> On Wed, Oct 07, 2015 at 04:37:13PM +0100, Mans Rullgard wrote:
>>> This adds a DT binding for a generic mmio clocksource as implemented
>>> by clocksource_mmio_init().
>>>
>>> Signed-off-by: Mans Rullgard 
>>> ---
>>> Changed in v2:
>>> - added sched_clock support
>>> ---
>>>  .../devicetree/bindings/timer/clocksource-mmio.txt | 28 
>>> ++
>>>  1 file changed, 28 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/timer/clocksource-mmio.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/timer/clocksource-mmio.txt 
>>> b/Documentation/devicetree/bindings/timer/clocksource-mmio.txt
>>> new file mode 100644
>>> index 000..cfb3601
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/timer/clocksource-mmio.txt
>>> @@ -0,0 +1,28 @@
>>> +Generic MMIO clocksource
>>> +
>>> +Required properties:
>>> +
>>> +- compatible: should be "clocksource-mmio"

I'm doubtful this matches any h/w. This would assume there is no other
control like enabling, reset, clock dividers, etc.

Who is your user of this?

>>> +- reg: the physical address of the counter register
>>> +- reg-io-width: size of counter register in bytes, should be 2 or 4
>>
>> Can this not be inferred from the reg?
>
> You're right, it can.
>
>> What about 8 byte counters?
>
> The existing code only supports 2 or 4, but that of course doesn't
> matter here.
>
>>> +- clocks: phandle to the source clock
>>
>> Is the frequency expected to be exactly the source clock frequency? I
>> imagine it's possible for there to be a divisor.
>
> There could of course be, though there isn't in the hardware I'm dealing
> with.  Is specifying it here preferable using a fixed-factor-clock?
>
>> We can add properties for that later, but we should be explcit as to
>> what we currently expect the relationship between the clock and the
>> clocksource to be.
>>
>>> +- clocksource-bits: number of valid bits
>>> +- clocksource-rating: rating of the clocksource
>>
>> NAK. This has no meaning w.r.t. the hardware. This should not be in the
>> DT. If there are criteria that bias this (e.g. frequency, latency), they
>> should either be described in the DT or determined dynamically.
>
> I had a bad feeling about this.  How would you suggest determining a
> suitable value from actual hardware parameters?

I wouldn't. I think there is general agreement that rating is broken.

This has come up a few times before in context of given a pile of
timer h/w how do you select one. Chosen properties have been one
example (I think that actually went in on Integrator, but we since
removed it). Think about what the properties of a timer are and then
you can decide based on properties for those. OMAP timers are a good
example.

>
>>> +- linux,sched-clock: boolean, register clocksource as sched_clock
>>
>> Likewise, this property doesn't belong in the DT for the same reasons as
>> clocksource-rating.
>
> What would be a proper way to select a sched_clock source?  I realise
> it's a Linux-specific thing and DT is supposed to be generic, but the
> information must be provided somehow.

The kernel already has some logic to do this. Most number of bits
followed by highest frequency will be the winning sched_clock. You
might also want to look at things like always on or not.

Rob

>
> --
> Måns Rullgård
> m...@mansr.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 2/4] spi: bcm2835: add bcm2835 auxiliary spi device driver

[Mark Brown]

On Tue, Oct 06, 2015 at 01:38:10PM +0200, Martin Sperl wrote:
> On 06.10.2015 13:23, Mark Brown wrote:
> >On Fri, Sep 11, 2015 at 11:22:04AM +, ker...@martin.sperl.org wrote:

> >>+   bs->irq = irq_of_parse_and_map(pdev->dev.of_node, 0);

> >Why are we using this unusual DT specific API here?  I'd expect to see
> >just use platform_get_irq() here and this seems to be the only DT
> >dependency in the driver.

> I copied it from spi-bcm2835.c, where it is also used in exactly that
> fashion.

> You want me to move to your recommended api instead for both drivers?

> >I'd expect to request the IRQ after we reset the hardware in order to
> >ensure that the hardware is in a known good state
> 
> Same copy/paste in this case - i can change the order for both
> drivers if you want.

Yes, that'd be better.  I'll just apply this now and you can send
followup patches fixing these for both drivers.


signature.asc
Description: Digital signature

Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Maxime Ripard]

Hi Timo,

On Mon, Oct 05, 2015 at 07:39:57PM +0200, Timo Sigurdsson wrote:
> Hi Kevin,
> 
> Kevin Hilman schrieb am 24.09.2015 19:57:
> > kernelci.org started finding boot faiulres[1] on bananapi linux-next
> > around next-20150918, but it was only failing in some labs and not
> > others.  I finally bisected it down to this patch, which landed in
> > linux-next in the form of 2d665a8a8350 ARM: dts: sunxi: Add regulators
> > for LeMaker BananaPi.  Reverting that commit on top of next-20150923
> > gets my bananapi booting again.
> > 
> > Note it's kind of an interesting boot failure.  The kernel boots fully
> > to a shell, but panics after running a few commands.  In particular
> > 'dmesg -n1' seems to trigger it usually[2].
> > 
> > Kevin
> > 
> > [1]
> > http://kernelci.org/boot/sun7i-a20-bananapi/job/next/kernel/next-20150923/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5602504359b514be146c326f
> > [2]
> > http://storage.kernelci.org/next/next-20150923/arm-multi_v7_defconfig/lab-khilman/boot-sun7i-a20-bananapi.html
> 
> following up on my last email: I'm back from my vacation and I tried to
> reproduce your problem, but my board doesn't seem to be affected, so I
> cannot trigger it.

weird.

> I still think that the lower voltages may be the cause of your problem
> with that specific board, so could you please test the attached patch on
> top of my patch that you first experienced the problem with? Please let 
> us know whether this solves your issue or whether we need to dig deeper.
> 
> Has anybody else been able to reproduce Kevin's issue?

I've talked to Kevin yesterday about that issue, and he's been away
from his boards for quite some time too, so we'll have to wait a bit
to solve that issue.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

[PATCH 2/2] PCI: of: Ignore resources with failed translation

[Pavel Fedin]

This patch allows PCI host controller to function even if part of resources
is unusable for some reason. An example is non-LPAE kernel on a machine
which has some 64-bit resources. Unusable resources will be just skipped
instead of a complete failure.

Signed-off-by: Pavel Fedin 
---
 drivers/of/of_pci.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 5751dc5..ea7c2b6 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -223,8 +223,10 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
}
 
err = of_pci_range_to_resource(, dev, res);
-   if (err)
-   goto conversion_failed;
+   if (err) {
+   kfree(res);
+   continue;
+   }
 
if (resource_type(res) == IORESOURCE_IO) {
if (!io_base) {
-- 
2.4.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 1/2] PCI: of: Add 64-bit address recognition without LPAE support

[Pavel Fedin]

If non-LPAE kernel is booted up on a machine with 64-bit PCI resources,
PCI controller probe fails with:

PCI host bridge /pcie@1000 ranges:
   IO 0x3eff..0x3eff -> 0x
  MEM 0x1000..0x3efe -> 0x1000
  MEM 0x80..0xff -> 0x80
pci-host-generic 3f00.pcie: resource collision: [mem 0x-0x] 
conflicts with /pl011@900 [mem 0x0900-0x09000fff]
pci-host-generic: probe of 3f00.pcie failed with error -16

This happens because res->start assignment in of_pci_range_to_resource()
truncates the upper part of the address, because res->start is of
phys_addr_t type, which is 32-bit on non-LPAE kernels.

This patch adds explicit recognition of 64-bit resources, preventing from
potential problems when e. g. 0x801234 would be converted to
0x1234.

Signed-off-by: Pavel Fedin 
---
 drivers/of/address.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 384574c..9a8f8c3 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -330,6 +330,12 @@ int of_pci_range_to_resource(struct of_pci_range *range,
}
res->start = port;
} else {
+#ifndef CONFIG_PHYS_ADDR_T_64BIT
+   if (upper_32_bits(range->cpu_addr)) {
+   err = -EINVAL;
+   goto invalid_range;
+   }
+#endif
res->start = range->cpu_addr;
}
res->end = res->start + range->size - 1;
-- 
2.4.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: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Mark Brown]

On Fri, Oct 02, 2015 at 05:29:22PM +0100, Charles Keepax wrote:
> Add additional bindings to allow configuration of the system specific
> microphone detection settings.

This all seems pretty much fine to me - the things it is controlling are
fairly specific to the way the former Wolfson devices do, they only
really make sense with a fairly particular algorithm which isn't widely
implemented.


signature.asc
Description: Digital signature

Re: [PATCH] ARM: shmobile: porter: add SDHI0/2 DT support

[Sergei Shtylyov]

Hello.

On 10/7/2015 6:39 AM, Simon Horman wrote:


Define the Porter board dependent part of the SDHI0/2 device nodes along with
the  necessary  voltage regulators (note that the Vcc regulators are dummy --
they are required but don't actually exist on the board). Also, GPIOs have to
be used for the CD and WP signals due to the SDHI driver constraints...

This patch is analogous to the commit 1299df03d719 (ARM: shmobile: henninger:
add SDHI0/2 DT support) as there  are no differences between those boards in
this respect.

Signed-off-by: Sergei Shtylyov 

---
This patch is against the 'renesas-devel-20151006-v4.3-rc4' tag of Simon
Horman's 'renesas.git' repo.


Thanks I have queued this up after addressing some issues
in the changelog that checkpatch complained about:

* text > 75 characters wide
* Missing '"' around name of patch referred to

Its looking like there is already quite a log shared between


   Lot?


r8a7791-porter.dts and r8a7791-henninger.dts. Do you have any
thoughts on consolidating or sharing common elements between
them somehow?


   I'm still planning to remove the Henninger's .dts for good. It was never 
sold and so had no users outside Renesas (and Cogent Embedded), I was told.


MBR, Sergei

--
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 v4 1/4] drivers: clk: st: Support for enable/disable in Clockgen PLLs

[Gabriel Fernandez]

The patch adds support for enable/disable of the Clockgen PLLs.
clkgen_pll_enable/clkgen_pll_disable added as generic function for all PLLs.

Signed-off-by: Pankaj Dev 
Signed-off-by: Gabriel Fernandez 
---
 drivers/clk/st/clkgen-pll.c | 60 -
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/st/clkgen-pll.c b/drivers/clk/st/clkgen-pll.c
index b2a332c..092f82c 100644
--- a/drivers/clk/st/clkgen-pll.c
+++ b/drivers/clk/st/clkgen-pll.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "clkgen.h"
 
@@ -43,6 +44,7 @@ static DEFINE_SPINLOCK(clkgena_c32_odf_lock);
 
 struct clkgen_pll_data {
struct clkgen_field pdn_status;
+   struct clkgen_field pdn_ctrl;
struct clkgen_field locked_status;
struct clkgen_field mdiv;
struct clkgen_field ndiv;
@@ -62,6 +64,7 @@ static const struct clk_ops st_pll1200c32_ops;
 
 static const struct clkgen_pll_data st_pll1600c65_ax = {
.pdn_status = CLKGEN_FIELD(0x0, 0x1,19),
+   .pdn_ctrl   = CLKGEN_FIELD(0x10,0x1,0),
.locked_status  = CLKGEN_FIELD(0x0, 0x1,31),
.mdiv   = CLKGEN_FIELD(0x0, C65_MDIV_PLL1600_MASK,  0),
.ndiv   = CLKGEN_FIELD(0x0, C65_NDIV_MASK,  8),
@@ -70,6 +73,7 @@ static const struct clkgen_pll_data st_pll1600c65_ax = {
 
 static const struct clkgen_pll_data st_pll800c65_ax = {
.pdn_status = CLKGEN_FIELD(0x0, 0x1,19),
+   .pdn_ctrl   = CLKGEN_FIELD(0xC, 0x1,1),
.locked_status  = CLKGEN_FIELD(0x0, 0x1,31),
.mdiv   = CLKGEN_FIELD(0x0, C65_MDIV_PLL800_MASK,   0),
.ndiv   = CLKGEN_FIELD(0x0, C65_NDIV_MASK,  8),
@@ -79,6 +83,7 @@ static const struct clkgen_pll_data st_pll800c65_ax = {
 
 static const struct clkgen_pll_data st_pll3200c32_a1x_0 = {
.pdn_status = CLKGEN_FIELD(0x0, 0x1,31),
+   .pdn_ctrl   = CLKGEN_FIELD(0x18,0x1,0),
.locked_status  = CLKGEN_FIELD(0x4, 0x1,31),
.ndiv   = CLKGEN_FIELD(0x0, C32_NDIV_MASK,  0x0),
.idf= CLKGEN_FIELD(0x4, C32_IDF_MASK,   0x0),
@@ -96,6 +101,7 @@ static const struct clkgen_pll_data st_pll3200c32_a1x_0 = {
 
 static const struct clkgen_pll_data st_pll3200c32_a1x_1 = {
.pdn_status = CLKGEN_FIELD(0xC, 0x1,31),
+   .pdn_ctrl   = CLKGEN_FIELD(0x18,0x1,1),
.locked_status  = CLKGEN_FIELD(0x10,0x1,31),
.ndiv   = CLKGEN_FIELD(0xC, C32_NDIV_MASK,  0x0),
.idf= CLKGEN_FIELD(0x10,C32_IDF_MASK,   0x0),
@@ -114,6 +120,7 @@ static const struct clkgen_pll_data st_pll3200c32_a1x_1 = {
 /* 415 specific */
 static const struct clkgen_pll_data st_pll3200c32_a9_415 = {
.pdn_status = CLKGEN_FIELD(0x0, 0x1,0),
+   .pdn_ctrl   = CLKGEN_FIELD(0x0, 0x1,0),
.locked_status  = CLKGEN_FIELD(0x6C,0x1,0),
.ndiv   = CLKGEN_FIELD(0x0, C32_NDIV_MASK,  9),
.idf= CLKGEN_FIELD(0x0, C32_IDF_MASK,   22),
@@ -125,6 +132,7 @@ static const struct clkgen_pll_data st_pll3200c32_a9_415 = {
 
 static const struct clkgen_pll_data st_pll3200c32_ddr_415 = {
.pdn_status = CLKGEN_FIELD(0x0, 0x1,0),
+   .pdn_ctrl   = CLKGEN_FIELD(0x0, 0x1,0),
.locked_status  = CLKGEN_FIELD(0x100,   0x1,0),
.ndiv   = CLKGEN_FIELD(0x8, C32_NDIV_MASK,  0),
.idf= CLKGEN_FIELD(0x0, C32_IDF_MASK,   25),
@@ -137,7 +145,8 @@ static const struct clkgen_pll_data st_pll3200c32_ddr_415 = 
{
 };
 
 static const struct clkgen_pll_data st_pll1200c32_gpu_415 = {
-   .pdn_status = CLKGEN_FIELD(0x144,   0x1,3),
+   .pdn_status = CLKGEN_FIELD(0x4, 0x1,0),
+   .pdn_ctrl   = CLKGEN_FIELD(0x4, 0x1,0),
.locked_status  = CLKGEN_FIELD(0x168,   0x1,0),
.ldf= CLKGEN_FIELD(0x0, C32_LDF_MASK,   3),
.idf= CLKGEN_FIELD(0x0, C32_IDF_MASK,   0),
@@ -149,6 +158,7 @@ static const struct clkgen_pll_data st_pll1200c32_gpu_415 = 
{
 /* 416 specific */
 static const struct clkgen_pll_data st_pll3200c32_a9_416 = {
.pdn_status = CLKGEN_FIELD(0x0, 0x1,0),
+   .pdn_ctrl   = CLKGEN_FIELD(0x0, 0x1,0),
   

[PATCH v4 4/4] ARM: STi: DT: Add support for stih418 A9 pll

[Gabriel Fernandez]

Add support for new PLL-type for stih418 A9-PLL.

Signed-off-by: Gabriel Fernandez 
---
 arch/arm/boot/dts/stih418-clock.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/stih418-clock.dtsi 
b/arch/arm/boot/dts/stih418-clock.dtsi
index 148e177..ae6d997 100644
--- a/arch/arm/boot/dts/stih418-clock.dtsi
+++ b/arch/arm/boot/dts/stih418-clock.dtsi
@@ -44,7 +44,7 @@
 
clockgen_a9_pll: clockgen-a9-pll {
#clock-cells = <1>;
-   compatible = "st,stih407-plls-c32-a9", 
"st,clkgen-plls-c32";
+   compatible = "st,stih418-plls-c28-a9", 
"st,clkgen-plls-c32";
 
clocks = <_sysin>;
 
-- 
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 v5 0/17] Add Analogix Core Display Port Driver

[Javier Martinez Canillas]

Hello Yakir,

On 10/07/2015 11:02 AM, Yakir Yang wrote:
> Hi Javier,
> 
> On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:
>> Hello Yakir,
>>
>> On 10/07/2015 08:25 AM, Yakir Yang wrote:
>>> Hi all,
>>>
>>> Friendly ping.   :)
>>>
>>>
>>> Best regards,
>>> - Yakir
>>>
>>>
>> Do you have a tree that I can use to test these patches?
> 
> Wow, thanks a lot, I do have a tree on github 
> [https://github.com/yakir-Yang/linux/tree/analogix_dp],
> crossing my finger, wish things works..;)
>

I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook
but the machine didn't boot. Unfortunately I need to do some soldering
to have a serial console on this board so don't have a kernel boot log.

I'll let you know if I can get more info about this issue.

Also, there is Kconfig recursive dependency that you may want to fix:

$ make exynos_defconfig
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_ANALOGIX_DP
drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is selected 
by DRM_EXYNOS_DP
drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on 
DRM_EXYNOS_FIMD
drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C
drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB
 
> Thanks,
> - Yakir
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 0/17] Add Analogix Core Display Port Driver

[Javier Martinez Canillas]

Hello Yakir,

On 10/07/2015 01:05 PM, Yakir Yang wrote:
> Hi Javier,
> 
> On 10/07/2015 05:26 PM, Javier Martinez Canillas wrote:
>> Hello Yakir,
>>
>> On 10/07/2015 11:02 AM, Yakir Yang wrote:
>>> Hi Javier,
>>>
>>> On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:
 Hello Yakir,

 On 10/07/2015 08:25 AM, Yakir Yang wrote:
> Hi all,
>
> Friendly ping.   :)
>
>
> Best regards,
> - Yakir
>
>
 Do you have a tree that I can use to test these patches?
>>> Wow, thanks a lot, I do have a tree on github 
>>> [https://github.com/yakir-Yang/linux/tree/analogix_dp],
>>> crossing my finger, wish things works..;)
>>>
>> I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook
>> but the machine didn't boot. Unfortunately I need to do some soldering
>> to have a serial console on this board so don't have a kernel boot log.
>>
>> I'll let you know if I can get more info about this issue.
> 
> Whoops, sorry for the failed, much appreciated for your works.
> 
> Besides, I thought maybe I can find a Peach Pit Chromebook in my side,
> I remember that some of our guys have brought one, but previously I
> thought that mainline kernel wouldn't run on Peach Pit directly.
> 

Great, mainline works correctly on all Exynos based Chromebooks.

> Maybe you can email me the method the run mainline kernel on Peach
> Pit, so I can debug the analogix_dp driver at the same time, that would
> be great.

I wrote a little blog post explaining how to run mainline on these boards:

http://blogs.s-osg.org/install-linux-mainline-kernel-distro-exynos-chromebooks/

That explains the simplest setup though so if you need a different one
(i.e: chain loading a non verified u-boot) or if you have any questions,
feel free to contact me in private and I can help you with the setup.

>> Also, there is Kconfig recursive dependency that you may want to fix:
>>
>> $ make exynos_defconfig
>> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
>> drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
>> drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on 
>> DRM_KMS_HELPER
>> drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by 
>> DRM_ANALOGIX_DP
>> drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is 
>> selected by DRM_EXYNOS_DP
>> drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on 
>> DRM_EXYNOS_FIMD
>> drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C
>> drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB
>>   
> 
> Yeah, recursive dependency detected, guess I should remove the
> "DRM_KMS_HELPER" from bridge analogix_dp Kconfig file, thanks
> for your remind.
> 
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -1,4 +1,3 @@
>  config DRM_ANALOGIX_DP
> tristate
> depends on DRM
> -   select DRM_KMS_HELPER
> 
> 

That fixes the recursive dependency issue indeed. Thanks.

> Thanks,
> - Yakir

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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/9] dmaengine: st_fdma: Add fdma suspend and resume callbacks.

[Vinod Koul]

On Fri, Sep 11, 2015 at 03:14:28PM +0100, Peter Griffin wrote:
> +#define ST_FDMA_PM   (_fdma_pm)
> +#else
> +#define ST_FDMA_PM   NULL
> +#endif
Pls use PM helpers you dont need to do this

-- 
~Vinod
--
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/3] Fix random hang up issue while kernel init

[James Liao]

This patch is based on v4.3-rc4, to fix system hanging up issue
while disabling unused clocks.

There is nothing different in mtk-scpsys.c and mt8173.dtsi from v1 [1].

Changes since v1:
- Rebase to v4.3-rc4.
- Add a patch to change the corresponding binding document.
- Add a separated patch to change the dtsi.

[1] https://patchwork.kernel.org/patch/7262411/

James Liao (3):
  dt-bindings: soc: Add clocks for Mediatek SCPSYS unit
  soc: mediatek: Fix random hang up issue while kernel init
  arm64: dts: mt8173: Add clocks for SCPSYS unit

 .../devicetree/bindings/soc/mediatek/scpsys.txt| 10 ++--
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  6 +-
 drivers/soc/mediatek/mtk-scpsys.c  | 67 ++
 3 files changed, 54 insertions(+), 29 deletions(-)

--
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

[PATCH v2 3/3] arm64: dts: mt8173: Add clocks for SCPSYS unit

[James Liao]

Add clocks needed by Mediatek VENC and VENC_LT power domianis.
These clocks were needed by accessing subsystem's registers,
so they need to be enabled before power on these subsystems.

Signed-off-by: James Liao 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 06a1564..30fb201 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -227,8 +227,10 @@
#power-domain-cells = <1>;
reg = <0 0x10006000 0 0x1000>;
clocks = <>,
-< CLK_TOP_MM_SEL>;
-   clock-names = "mfg", "mm";
+< CLK_TOP_MM_SEL>,
+< CLK_TOP_VENC_SEL>,
+< CLK_TOP_VENC_LT_SEL>;
+   clock-names = "mfg", "mm", "venc", "venc_lt";
infracfg = <>;
};
 
-- 
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

[PATCH v2 2/3] soc: mediatek: Fix random hang up issue while kernel init

[James Liao]

In kernel late init, it turns off all unused clocks, which
needs to access subsystem registers such as VENC and VENC_LT.

Accessing MT8173 VENC registers needs two top clocks, mm_sel and
venc_sel. Accessing VENC_LT registers needs mm_sel and venclt_sel.
So we need to keep these clocks on before accessing their registers.

This patch keeps venc_sel / venclt_sel clock on when
VENC / VENC_LT's power is on, to prevent system hang up while
accessing its registeres.

Signed-off-by: James Liao 
---
 drivers/soc/mediatek/mtk-scpsys.c | 67 +--
 1 file changed, 44 insertions(+), 23 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index 164a7d8..06032ba 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -54,12 +54,16 @@
 #define PWR_STATUS_USB BIT(25)
 
 enum clk_id {
+   MT8173_CLK_NONE,
MT8173_CLK_MM,
MT8173_CLK_MFG,
-   MT8173_CLK_NONE,
-   MT8173_CLK_MAX = MT8173_CLK_NONE,
+   MT8173_CLK_VENC,
+   MT8173_CLK_VENC_LT,
+   MT8173_CLK_MAX,
 };
 
+#define MAX_CLKS   2
+
 struct scp_domain_data {
const char *name;
u32 sta_mask;
@@ -67,7 +71,7 @@ struct scp_domain_data {
u32 sram_pdn_bits;
u32 sram_pdn_ack_bits;
u32 bus_prot_mask;
-   enum clk_id clk_id;
+   enum clk_id clk_id[MAX_CLKS];
 };
 
 static const struct scp_domain_data scp_domain_data[] __initconst = {
@@ -77,7 +81,7 @@ static const struct scp_domain_data scp_domain_data[] 
__initconst = {
.ctl_offs = SPM_VDE_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
-   .clk_id = MT8173_CLK_MM,
+   .clk_id = {MT8173_CLK_MM},
},
[MT8173_POWER_DOMAIN_VENC] = {
.name = "venc",
@@ -85,7 +89,7 @@ static const struct scp_domain_data scp_domain_data[] 
__initconst = {
.ctl_offs = SPM_VEN_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = MT8173_CLK_MM,
+   .clk_id = {MT8173_CLK_MM, MT8173_CLK_VENC},
},
[MT8173_POWER_DOMAIN_ISP] = {
.name = "isp",
@@ -93,7 +97,7 @@ static const struct scp_domain_data scp_domain_data[] 
__initconst = {
.ctl_offs = SPM_ISP_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(13, 12),
-   .clk_id = MT8173_CLK_MM,
+   .clk_id = {MT8173_CLK_MM},
},
[MT8173_POWER_DOMAIN_MM] = {
.name = "mm",
@@ -101,7 +105,7 @@ static const struct scp_domain_data scp_domain_data[] 
__initconst = {
.ctl_offs = SPM_DIS_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
-   .clk_id = MT8173_CLK_MM,
+   .clk_id = {MT8173_CLK_MM},
.bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 |
MT8173_TOP_AXI_PROT_EN_MM_M1,
},
@@ -111,7 +115,7 @@ static const struct scp_domain_data scp_domain_data[] 
__initconst = {
.ctl_offs = SPM_VEN2_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = MT8173_CLK_MM,
+   .clk_id = {MT8173_CLK_MM, MT8173_CLK_VENC_LT},
},
[MT8173_POWER_DOMAIN_AUDIO] = {
.name = "audio",
@@ -119,7 +123,7 @@ static const struct scp_domain_data scp_domain_data[] 
__initconst = {
.ctl_offs = SPM_AUDIO_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = MT8173_CLK_NONE,
+   .clk_id = {MT8173_CLK_NONE},
},
[MT8173_POWER_DOMAIN_USB] = {
.name = "usb",
@@ -127,7 +131,7 @@ static const struct scp_domain_data scp_domain_data[] 
__initconst = {
.ctl_offs = SPM_USB_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
-   .clk_id = MT8173_CLK_NONE,
+   .clk_id = {MT8173_CLK_NONE},
},
[MT8173_POWER_DOMAIN_MFG_ASYNC] = {
.name = "mfg_async",
@@ -135,7 +139,7 @@ static const struct scp_domain_data scp_domain_data[] 
__initconst = {
.ctl_offs = SPM_MFG_ASYNC_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = 0,
-   .clk_id = MT8173_CLK_MFG,
+   .clk_id = {MT8173_CLK_MFG},
},
[MT8173_POWER_DOMAIN_MFG_2D] = {
.name = "mfg_2d",
@@ -143,7 +147,7 @@ static const struct scp_domain_data scp_domain_data[] 
__initconst = {
.ctl_offs = 

[PATCH v7 5/6] mfd: da9150: Use relative paths in DT bindings document

[Adam Thomson]

When referencing other DT bindings documentation, use relative
path rather than absolute.

Signed-off-by: Adam Thomson 
Suggested-by: Lee Jones 
Acked-by: Lee Jones 
---

Changes in v6:
 - Rebase to v4.3-rc4

Changes in v5:
 - Rebase to v4.2

Changes in v3:
 - Initial version.


 Documentation/devicetree/bindings/mfd/da9150.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/da9150.txt 
b/Documentation/devicetree/bindings/mfd/da9150.txt
index 970801d..fd4dca7 100644
--- a/Documentation/devicetree/bindings/mfd/da9150.txt
+++ b/Documentation/devicetree/bindings/mfd/da9150.txt
@@ -17,13 +17,13 @@ Required properties:
   the IRQs from da9150 are delivered to.
 - interrupts: IRQ line info for da9150 chip.
 - interrupt-controller: da9150 has internal IRQs (own IRQ domain).
-  (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt 
for
+  (See ../interrupt-controller/interrupts.txt for
further information relating to interrupt properties)

 Sub-devices:
-- da9150-gpadc: See Documentation/devicetree/bindings/iio/adc/da9150-gpadc.txt
-- da9150-charger: See 
Documentation/devicetree/bindings/power/da9150-charger.txt
-- da9150-fg: See Documentation/devicetree/bindings/power/da9150-fg.txt
+- da9150-gpadc: See ../iio/adc/da9150-gpadc.txt
+- da9150-charger: See ../power/da9150-charger.txt
+- da9150-fg: See ../power/da9150-fg.txt

 Example:

--
1.9.3

--
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/6] power: da9150: Add DT bindings documentation for Fuel-Gauge

[Adam Thomson]

Signed-off-by: Adam Thomson 
Acked-by: Sebastian Reichel 
---

Changes in v6:
 - Rebase to v4.3-rc4

Changes in v5:
 - Rebase to v4.2

Changes in v4:
 - Update compatible string of fuel-gauge to "dlg,da9150-fuel-gauge".
 - Changed example node name to "fuel-gauge".

 .../devicetree/bindings/power/da9150-fg.txt| 23 ++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/da9150-fg.txt

diff --git a/Documentation/devicetree/bindings/power/da9150-fg.txt 
b/Documentation/devicetree/bindings/power/da9150-fg.txt
new file mode 100644
index 000..00236fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/da9150-fg.txt
@@ -0,0 +1,23 @@
+Dialog Semiconductor DA9150 Fuel-Gauge Power Supply bindings
+
+Required properties:
+- compatible: "dlg,da9150-fuel-gauge" for DA9150 Fuel-Gauge Power Supply
+
+Optional properties:
+- dlg,update-interval: Interval time (milliseconds) between battery level 
checks.
+- dlg,warn-soc-level: Battery discharge level (%) where warning event raised.
+  [1 - 100]
+- dlg,crit-soc-level: Battery discharge level (%) where critical event raised.
+  This value should be lower than the warning level.
+  [1 - 100]
+
+
+Example:
+
+   fuel-gauge {
+   compatible = "dlg,da9150-fuel-gauge";
+
+   dlg,update-interval = <1>;
+   dlg,warn-soc-level = /bits/ 8 <15>;
+   dlg,crit-soc-level = /bits/ 8 <5>;
+   };
--
1.9.3

--
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/3] ASoC: da7213: Add DT support to codec driver

[Adam Thomson]

This patch adds support for DT bindings in the codec driver.
As part of this support, the mclk data can now be provided and
used to control the mclk during codec operation.

Signed-off-by: Adam Thomson 
---
 sound/soc/codecs/da7213.c | 123 --
 1 file changed, 118 insertions(+), 5 deletions(-)

diff --git a/sound/soc/codecs/da7213.c b/sound/soc/codecs/da7213.c
index a9c86ef..ab1486b 100644
--- a/sound/soc/codecs/da7213.c
+++ b/sound/soc/codecs/da7213.c
@@ -1387,10 +1387,118 @@ static int da7213_set_bias_level(struct snd_soc_codec 
*codec,
return 0;
 }

+/* DT */
+static const struct of_device_id da7213_of_match[] = {
+   { .compatible = "dlg,da7213", },
+   { }
+};
+MODULE_DEVICE_TABLE(of, da7213_of_match);
+
+static enum da7213_micbias_voltage
+   da7213_of_micbias_lvl(struct snd_soc_codec *codec, u32 val)
+{
+   switch (val) {
+   case 1600:
+   return DA7213_MICBIAS_1_6V;
+   case 2200:
+   return DA7213_MICBIAS_2_2V;
+   case 2500:
+   return DA7213_MICBIAS_2_5V;
+   case 3000:
+   return DA7213_MICBIAS_3_0V;
+   default:
+   dev_warn(codec->dev, "Invalid micbias level\n");
+   return DA7213_MICBIAS_2_2V;
+   }
+}
+
+static enum da7213_dmic_data_sel
+   da7213_of_dmic_data_sel(struct snd_soc_codec *codec, const char *str)
+{
+   if (!strcmp(str, "lrise_rfall")) {
+   return DA7213_DMIC_DATA_LRISE_RFALL;
+   } else if (!strcmp(str, "lfall_rrise")) {
+   return DA7213_DMIC_DATA_LFALL_RRISE;
+   } else {
+   dev_warn(codec->dev, "Invalid DMIC data select type\n");
+   return DA7213_DMIC_DATA_LRISE_RFALL;
+   }
+}
+
+static enum da7213_dmic_samplephase
+   da7213_of_dmic_samplephase(struct snd_soc_codec *codec, const char *str)
+{
+   if (!strcmp(str, "on_clkedge")) {
+   return DA7213_DMIC_SAMPLE_ON_CLKEDGE;
+   } else if (!strcmp(str, "between_clkedge")) {
+   return DA7213_DMIC_SAMPLE_BETWEEN_CLKEDGE;
+   } else {
+   dev_warn(codec->dev, "Invalid DMIC sample phase\n");
+   return DA7213_DMIC_SAMPLE_ON_CLKEDGE;
+   }
+}
+
+static enum da7213_dmic_clk_rate
+   da7213_of_dmic_clkrate(struct snd_soc_codec *codec, u32 val)
+{
+   switch (val) {
+   case 150:
+   return DA7213_DMIC_CLK_1_5MHZ;
+   case 300:
+   return DA7213_DMIC_CLK_3_0MHZ;
+   default:
+   dev_warn(codec->dev, "Invalid DMIC clock rate\n");
+   return DA7213_DMIC_CLK_1_5MHZ;
+   }
+}
+
+static struct da7213_platform_data
+   *da7213_of_to_pdata(struct snd_soc_codec *codec)
+{
+   struct device_node *np = codec->dev->of_node;
+   struct da7213_platform_data *pdata;
+   const char *of_str;
+   u32 of_val32;
+
+   pdata = devm_kzalloc(codec->dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   dev_warn(codec->dev, "Failed to allocate memory for pdata\n");
+   return NULL;
+   }
+
+   if (of_property_read_u32(np, "dlg,micbias1-lvl", _val32) >= 0)
+   pdata->micbias1_lvl = da7213_of_micbias_lvl(codec, of_val32);
+   else
+   pdata->micbias1_lvl = DA7213_MICBIAS_2_2V;
+
+   if (of_property_read_u32(np, "dlg,micbias2-lvl", _val32) >= 0)
+   pdata->micbias2_lvl = da7213_of_micbias_lvl(codec, of_val32);
+   else
+   pdata->micbias2_lvl = DA7213_MICBIAS_2_2V;
+
+   if (!of_property_read_string(np, "dlg,dmic-data-sel", _str))
+   pdata->dmic_data_sel = da7213_of_dmic_data_sel(codec, of_str);
+   else
+   pdata->dmic_data_sel = DA7213_DMIC_DATA_LRISE_RFALL;
+
+   if (!of_property_read_string(np, "dlg,dmic-samplephase", _str))
+   pdata->dmic_samplephase =
+   da7213_of_dmic_samplephase(codec, of_str);
+   else
+   pdata->dmic_samplephase = DA7213_DMIC_SAMPLE_ON_CLKEDGE;
+
+   if (of_property_read_u32(np, "dlg,dmic-clkrate", _val32) >= 0)
+   pdata->dmic_clk_rate = da7213_of_dmic_clkrate(codec, of_val32);
+   else
+   pdata->dmic_clk_rate = DA7213_DMIC_CLK_3_0MHZ;
+
+   return pdata;
+}
+
+
 static int da7213_probe(struct snd_soc_codec *codec)
 {
struct da7213_priv *da7213 = snd_soc_codec_get_drvdata(codec);
-   struct da7213_platform_data *pdata = da7213->pdata;

/* Default to using ALC auto offset calibration mode. */
snd_soc_update_bits(codec, DA7213_ALC_CTRL1,
@@ -1450,8 +1558,15 @@ static int da7213_probe(struct snd_soc_codec *codec)
snd_soc_update_bits(codec, DA7213_LINE_CTRL,
DA7213_LINE_AMP_OE, DA7213_LINE_AMP_OE);

+   /* Handle DT/Platform data */
+   if (codec->dev->of_node)
+   da7213->pdata = 

[PATCH v7 6/6] mfd: da9150: Use DEFINE_RES_IRQ_NAMED() help macro for IRQ resource

[Adam Thomson]

Signed-off-by: Adam Thomson 
Suggested-by: Lee Jones 
Acked-by: Lee Jones 
---

Changes in v6:
 - Rebase to v4.3-rc4

Changes in v5:
 - Rebase to v4.2

Changes in v3:
 - Initial version.

 drivers/mfd/da9150-core.c | 35 +--
 1 file changed, 5 insertions(+), 30 deletions(-)

diff --git a/drivers/mfd/da9150-core.c b/drivers/mfd/da9150-core.c
index 85ca4b5..195fdcf 100644
--- a/drivers/mfd/da9150-core.c
+++ b/drivers/mfd/da9150-core.c
@@ -355,39 +355,14 @@ static const struct regmap_irq_chip 
da9150_regmap_irq_chip = {
 };

 static struct resource da9150_gpadc_resources[] = {
-   {
-   .name = "GPADC",
-   .start = DA9150_IRQ_GPADC,
-   .end = DA9150_IRQ_GPADC,
-   .flags = IORESOURCE_IRQ,
-   },
+   DEFINE_RES_IRQ_NAMED(DA9150_IRQ_GPADC, "GPADC"),
 };

 static struct resource da9150_charger_resources[] = {
-   {
-   .name = "CHG_STATUS",
-   .start = DA9150_IRQ_CHG,
-   .end = DA9150_IRQ_CHG,
-   .flags = IORESOURCE_IRQ,
-   },
-   {
-   .name = "CHG_TJUNC",
-   .start = DA9150_IRQ_TJUNC,
-   .end = DA9150_IRQ_TJUNC,
-   .flags = IORESOURCE_IRQ,
-   },
-   {
-   .name = "CHG_VFAULT",
-   .start = DA9150_IRQ_VFAULT,
-   .end = DA9150_IRQ_VFAULT,
-   .flags = IORESOURCE_IRQ,
-   },
-   {
-   .name = "CHG_VBUS",
-   .start = DA9150_IRQ_VBUS,
-   .end = DA9150_IRQ_VBUS,
-   .flags = IORESOURCE_IRQ,
-   },
+   DEFINE_RES_IRQ_NAMED(DA9150_IRQ_CHG, "CHG_STATUS"),
+   DEFINE_RES_IRQ_NAMED(DA9150_IRQ_TJUNC, "CHG_TJUNC"),
+   DEFINE_RES_IRQ_NAMED(DA9150_IRQ_VFAULT, "CHG_VFAULT"),
+   DEFINE_RES_IRQ_NAMED(DA9150_IRQ_VBUS, "CHG_VBUS"),
 };

 static struct resource da9150_fg_resources[] = {
--
1.9.3

--
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/2] arm64: dts: mt8173: Add thermal zone node for mt8173.

[Dawei Chien]

From: "Dawei.Chien" 

Add thermal zone node to mt8173.dtsi.

Signed-off-by: Dawei.Chien 
---
This patch is base on
https://patchwork.kernel.org/patch/7249821/
https://patchwork.kernel.org/patch/7249861/
https://patchwork.kernel.org/patch/7249891/
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   44 ++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 3b18f37..01a7c46c 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "mt8173-pinfunc.h"
 
 / {
@@ -116,6 +117,49 @@
clock-output-names = "clk32k";
};
 
+   thermal-zones {
+   cpu_thermal: cpu_thermal {
+   polling-delay-passive = <1000>; /* milliseconds */
+   polling-delay = <1000>; /* milliseconds */
+
+   thermal-sensors = < MT8173_THERMAL_ZONE_CA57>;
+   sustainable-power = <1500>;
+
+   trips {
+   threshold: trip-point@0 {
+   temperature = <68000>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+
+   target: trip-point@1 {
+   temperature = <85000>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+
+   cpu_crit: cpu_crit@0 {
+   temperature = <115000>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map@0 {
+   trip = <>;
+   cooling-device = < 0 0>;
+   contribution = <1024>;
+   };
+   map@1 {
+   trip = <>;
+   cooling-device = < 0 0>;
+   contribution = <2048>;
+   };
+   };
+   };
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <>;
-- 
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 v2 0/3] ASoC: da7213: Add DT support for codec

[Mark Brown]

On Wed, Oct 07, 2015 at 02:27:04PM +0100, Adam Thomson wrote:

> Adam Thomson (3):
>   ASoC: da7213: Add DT support to codec driver
>   ASoC: da7213: Add support to handle mclk data provided to driver
>   ASoC: da7213: Add bindings documentation for codec driver

Please remember to send the DT binding before the code as is normal,
this helps review the code as we know in advance what the code is
supposed to do.


signature.asc
Description: Digital signature

[PATCH v2 0/3] ASoC: da7213: Add DT support for codec

[Adam Thomson]

This patch set adds DT support to the codec driver, and supporting bindings
documentation.

Patch set is based against v4.3-rc4

Changes in v2:
 - Split mclk data support changes into separate patch
 - Use of_match_ptr() for match table assignment
 - Only call clk_prepare_enable/disable() if mclk data provided (not NULL).
 - Add error checking for clk_prepare_enable() usage.

Adam Thomson (3):
  ASoC: da7213: Add DT support to codec driver
  ASoC: da7213: Add support to handle mclk data provided to driver
  ASoC: da7213: Add bindings documentation for codec driver

 Documentation/devicetree/bindings/sound/da7213.txt |  41 +
 include/sound/da7213.h |   3 -
 sound/soc/codecs/da7213.c  | 190 +++--
 sound/soc/codecs/da7213.h  |   8 +-
 4 files changed, 221 insertions(+), 21 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/da7213.txt

--
1.9.3

--
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/6] mfd: da9150: Update DT bindings for Fuel-Gauge support

[Adam Thomson]

Signed-off-by: Adam Thomson 
Acked-by: Lee Jones 
---

Changes in v6:
 - Rebase to v4.3-rc4

Changes in v5:
 - Rebase to v4.2

Changes in v4:
 - Update compatible string of fuel-gauge to "da9150-fuel-gauge".
 - Node name tidy up, relating to maintainer comments on fuel-gauge DT
   binding doc.
 - Removed Ack to patch from Lee Jones, as this has now been modified slightly
   and didn't want to make assumptions of approval.

Changes in v3:
 - Removal of unwanted new-line.
 - Flesh out example bindings usage.

 Documentation/devicetree/bindings/mfd/da9150.txt | 27 
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/da9150.txt 
b/Documentation/devicetree/bindings/mfd/da9150.txt
index d0588ea..970801d 100644
--- a/Documentation/devicetree/bindings/mfd/da9150.txt
+++ b/Documentation/devicetree/bindings/mfd/da9150.txt
@@ -6,6 +6,7 @@ Device   Description
 --  ---
 da9150-gpadc   : General Purpose ADC
 da9150-charger : Battery Charger
+da9150-fg  : Battery Fuel-Gauge

 ==

@@ -22,7 +23,7 @@ Required properties:
 Sub-devices:
 - da9150-gpadc: See Documentation/devicetree/bindings/iio/adc/da9150-gpadc.txt
 - da9150-charger: See 
Documentation/devicetree/bindings/power/da9150-charger.txt
-
+- da9150-fg: See Documentation/devicetree/bindings/power/da9150-fg.txt

 Example:

@@ -34,10 +35,28 @@ Example:
interrupt-controller;

gpadc: da9150-gpadc {
-   ...
+   compatible = "dlg,da9150-gpadc";
+   #io-channel-cells = <1>;
+   };
+
+   charger {
+   compatible = "dlg,da9150-charger";
+
+   io-channels = < 0>,
+ < 2>,
+ < 8>,
+ < 5>;
+   io-channel-names = "CHAN_IBUS",
+  "CHAN_VBUS",
+  "CHAN_TJUNC",
+  "CHAN_VBAT";
};

-   da9150-charger {
-   ...
+   fuel-gauge {
+   compatible = "dlg,da9150-fuel-gauge";
+
+   dlg,update-interval = <1>;
+   dlg,warn-soc-level = /bits/ 8 <15>;
+   dlg,crit-soc-level = /bits/ 8 <5>
};
};
--
1.9.3

--
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: [RFT 0/3] usb: usb3503: Fix probing on Arndale board (missing phy)

[Marek Szyprowski]

Hello,

On 2015-10-07 02:30, Krzysztof Kozlowski wrote:

Introduction

This patchset tries to fix probing of usb3503 on Arndale board
if the Samsung PHY driver is probed later (or built as a module).

*The patchset was not tested on Arndale board.*
I don't have that board. Please test it and say if the usb3503 deferred probe
works fine and the issue is solved.

The patchset was tested on Odroid U3 board (which is different!)
in a simulated environment. It is not sufficient testing.


Difference
==
The usb3503 device driver can be used as a I2C device (on Odroid U3)
or as a platform device connected through phy (on Arndale). In the second
case the necessary phy reference has to be obtained and enabled.

For some details please look also at thread [0][1].

[0] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348524.html
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348875.html



I'm not sure that this is the correct approach. usb3503 chip is simply 
connected
to Exynos USB2 phy, so it visible on the USB bus. The real driver that 
controls USB2

PHY is Exynos EHCI driver and USB3503 should not mess around it.

In my opinion all that is needed in case of Arndale board is forcing 
reset of
usb3503 chip after successful EHCI and USB2 PHY initialization (for some 
reason

initialization of usb3503 chip must be done after usb host initialization).
However I have no idea which driver should trigger this reset. Right now 
I didn't
find any good solution for additional control for devices which are on 
autoprobed

bus like usb.

Best regards
--
Marek Szyprowski, PhD
Samsung R 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

Re: [PATCH v3 3/3] dmaengine: mpc512x: initialize with subsys_initcall()

[Vinod Koul]

On Thu, Sep 24, 2015 at 08:28:57PM +0300, Alexander Popov wrote:
> Initialize Freescale MPC512x DMA driver with subsys_initcall()
> to allow the depending drivers to call dma_request_slave_channel()
> during their probe.

Why can't we use defered probe ? I have been asking people to not move init
levels and esnure we have right solutions using defered probe

-- 
~Vinod
--
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/3] ASoC: da7213: Add DT support for codec

[Opensource [Adam Thomson]]

On October 07, 2015 15:11, Mark Brown wrote:

> > Adam Thomson (3):
> >   ASoC: da7213: Add DT support to codec driver
> >   ASoC: da7213: Add support to handle mclk data provided to driver
> >   ASoC: da7213: Add bindings documentation for codec driver
> 
> Please remember to send the DT binding before the code as is normal,
> this helps review the code as we know in advance what the code is
> supposed to do.

Ok, understood. Will make sure in the future I order them this way. Thanks.

Re: [PATCH] Documentation: dt: keystone: Fix up missing quotes

[santosh.shilim...@oracle.com]

On 10/7/15 10:04 AM, Nishanth Menon wrote:

Add missing commits for the suggest compatible flags in dt binding.

Fixes: 8841cbf666d6 ("Documentation: dt: keystone: provide SoC specific compatible 
flags")
Reported-by: Suman Anna 
Signed-off-by: Nishanth Menon 
---

This could be squashed since the original patch was not merged yet..
Apologies on the miss. (based on next-20151006)


I don't want to disturbs those tags now. Once the pulls get into the
queue, I will check if this can be applied on top of that, o.w
will queue that up later.

Thanks !!

Regards,
Santosh
--
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] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Maxime Ripard]

Hi Timo,

On Wed, Oct 07, 2015 at 05:49:18PM +0200, Timo Sigurdsson wrote:
> Hi Kevin,
> Hi Maxime,
> 
> Kevin Hilman schrieb am 07.10.2015 16:36:
> 
> > "Timo Sigurdsson"  writes:
> >> I still think that the lower voltages may be the cause of your problem
> >> with that specific board, so could you please test the attached patch on
> >> top of my patch that you first experienced the problem with? Please let 
> >> us know whether this solves your issue or whether we need to dig deeper.
> > 
> > Thanks for the patch.  Looks like it's the OPPs.
> > 
> > I went back to next-20150923 and verified it still fails.  Then, I
> > applied your patch and saw that it boots just fine.
> 
> Good. Then we can easily fix this, I guess.
> 
> @Maxime: How should we handle this? In its current form, the patch applies
> only to the BananaPi dts by overriding the inherited opp from the SoC dtsi.
> In an earlier discussion, it was said that this can be done, even though it
> might not be the most elegant approach. But then again, I think it
> shouldn't be necessary to change the opp in the sun7i-a20.dtsi for all A20
> boards since this is - to my knowledge - the first and only report that an
> A20 board has stability issues at the lower voltages (although not too many
> boards use voltage scaling yet).

If you count only the number of boards, indeed, but if you count the
number of devices actually used in the field, we cover already a
significant portion of them.

> So, would you prefer to keep this as a patch for BananaPi only, or
> change the dtsi for all A20 devices instead?

Yeah, we probably can keep that for bananapi only at the moment, and
try to generalize that afterwards.

> In case we keep it as it is, what is the correct commit to point to as
> "Fixes commit ..."? I'd say it fixes the initial opp commit for A20, since
> that's where these voltages were defined. But then again, if we don't
> change the dtsi, should I point to my regulator patch instead?

I don't think it fixes anything at this point. We droped your commit
that was using the A20 OPPs, so in the history so far we don't have
anything to fix, just enable cpufreq again.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [RFC PATCH v6 2/3] dtc: dts source location annotation

[Frank Rowand]

On 10/6/2015 10:32 PM, David Gibson wrote:
> On Tue, Oct 06, 2015 at 12:45:34AM -0700, Frank Rowand wrote:
>> On 10/5/2015 9:56 PM, David Gibson wrote:
>>> On Fri, Oct 02, 2015 at 09:52:48PM -0700, Frank Rowand wrote:
 From: Frank Rowand 

 Proof of concept patch.

 Annotates input source file and line number of nodes and properties
 as comments in output .dts file when --annotate flag is supplied.
>>
>> < snip >
>>
>>
 Index: b/srcpos.c
 ===
 --- a/srcpos.c
 +++ b/srcpos.c
 @@ -246,6 +246,41 @@ srcpos_copy(struct srcpos *pos)
return pos_new;
  }
  
 +struct srcpos *
 +srcpos_copy_all(struct srcpos *pos)
 +{
 +  struct srcpos *pos_new;
 +  struct srcfile_state *srcfile_state;
 +
 +  if (!pos)
 +  return NULL;
 +
 +  pos_new = srcpos_copy(pos);
 +
 +  if (pos_new) {
 +  /* allocate without free */
 +  srcfile_state = xmalloc(sizeof(struct srcfile_state));
 +  memcpy(srcfile_state, pos->file, sizeof(struct srcfile_state));
 +
 +  pos_new->file = srcfile_state;
 +  }
 +
 +  return pos_new;
 +}
>>>
>>> You still don't need this function.  srcfile_states have unlimited
>>> lifetime.
>>
>> My observation about this is buried in a late reply to v5, so
>> copying here:
>>
>>If I don't allocate a new copy of pos->file, then the file names are
>>incorrect.  I'm not sure why.  I can dig into this deeper to try to
>>understand what is going on if you want me to.
>>
>> It sounds like I do need to debug this.
> 
> That's weird.  Yeah, we need to debug this.

OK, I will dig into this.


> Btw, I was thinking about the filenames - in particular the way the
> current draft will give you very unwield full paths.  I was thinking
> about a different approach which should shorten those without
> requiring different invocation or hand hacking:
>* For the "base" dts file (the one passed on the command line),
>  always use just the basename (i.e. final piece of the file path)
>* For all other files, print the relative path from the directory
>  of the base file
> 
> /include/ directives already open files relative to the directory of
> the file including the /include/ so we have some of the mechanisms for
> this already.
> 
> I think this will require a moderate amount of extra work, so I
> wouldn't suggest it for the first cut, but does it sound like a good
> approach in principle to you?

Yes, I think that is a great way to approach it.  I'll take a look at
how much work this is, and if small enough I will add another patch
to the end of the series to do this.

-Frank

--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" 
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] devicetree: add binding for generic mmio clocksource

[Mark Rutland]

On Wed, Oct 07, 2015 at 04:37:13PM +0100, Mans Rullgard wrote:
> This adds a DT binding for a generic mmio clocksource as implemented
> by clocksource_mmio_init().
> 
> Signed-off-by: Mans Rullgard 
> ---
> Changed in v2:
> - added sched_clock support
> ---
>  .../devicetree/bindings/timer/clocksource-mmio.txt | 28 
> ++
>  1 file changed, 28 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/timer/clocksource-mmio.txt
> 
> diff --git a/Documentation/devicetree/bindings/timer/clocksource-mmio.txt 
> b/Documentation/devicetree/bindings/timer/clocksource-mmio.txt
> new file mode 100644
> index 000..cfb3601
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/clocksource-mmio.txt
> @@ -0,0 +1,28 @@
> +Generic MMIO clocksource
> +
> +Required properties:
> +
> +- compatible: should be "clocksource-mmio"
> +- reg: the physical address of the counter register
> +- reg-io-width: size of counter register in bytes, should be 2 or 4

Can this not be inferred from the reg?

What about 8 byte counters?

> +- clocks: phandle to the source clock

Is the frequency expected to be exactly the source clock frequency? I
imagine it's possible for there to be a divisor.

We can add properties for that later, but we should be explcit as to
what we currently expect the relationship between the clock and the
clocksource to be.

> +- clocksource-bits: number of valid bits
> +- clocksource-rating: rating of the clocksource

NAK. This has no meaning w.r.t. the hardware. This should not be in the
DT. If there are criteria that bias this (e.g. frequency, latency), they
should eitehr be describedi nteh DT or determined dynamically.

> +Optional properties:
> +
> +- clocksource-counts-down: indicates that counter counts down
> +- label: name of the clocksource
> +- linux,sched-clock: boolean, register clocksource as sched_clock

Likewise, this property doesn't belong in the DT for the same reasons as
clocksource-rating.

Mark.

> +
> +Example:
> +
> +clocksource {
> + compatible = "clocksource-mmio";
> + reg = <0x1 4>;
> + reg-io-width = <4>;
> + clocksource-bits = <32>;
> + clocksource-rating = <300>;
> + clocks = <>;
> + linux,sched_clock;
> +}
> -- 
> 2.5.3
> 
--
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 3/3] ASoC: da7213: Add bindings documentation for codec driver

[Rob Herring]

On Wed, Oct 7, 2015 at 8:27 AM, Adam Thomson
 wrote:
> Signed-off-by: Adam Thomson 
> ---
>  Documentation/devicetree/bindings/sound/da7213.txt | 41 
> ++
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/da7213.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/da7213.txt 
> b/Documentation/devicetree/bindings/sound/da7213.txt
> new file mode 100644
> index 000..7280e82
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/da7213.txt
> @@ -0,0 +1,41 @@
> +Dialog Semiconductor DA7213 Audio Codec bindings
> +
> +==
> +
> +Required properties:
> +- compatible : Should be "dlg,da7213"
> +- reg: Specifies the I2C slave address
> +
> +Optional properties:
> +- clocks : phandle and clock specifier for codec MCLK.
> +- clock-names : Clock name string for 'clocks' attribute, should be "mclk".
> +
> +- dlg,micbias1-lvl : Voltage (mV) for Mic Bias 1
> +   [<1600>, <2200>, <2500>, <3000>]
> +- dlg,micbias2-lvl : Voltage (mV) for Mic Bias 2
> +   [<1600>, <2200>, <2500>, <3000>]

Please append the units (-microvolt).

> +- dlg,dmic-data-sel : DMIC channel select based on clock edge.
> +   ["lrise_rfall", "lfall_rrise"]
> +- dlg,dmic-samplephase : When to sample audio from DMIC.
> +   ["on_clkedge", "between_clkedge"]

How about boolean for these two.

> +- dlg,dmic-clkrate : DMIC clock frequency (MHz).
> +   [<150>, <300>]

So 1.5GHz or 3GHz?

Add units (-hz).

> +
> +==
> +
> +Example:
> +
> +   codec_i2c: da7213@1a {
> +   compatible = "dlg,da7213";
> +   reg = <0x1a>;
> +
> +   clocks = < 201>;
> +   clock-names = "mclk";
> +
> +   dlg,micbias1-lvl = <2500>;
> +   dlg,micbias2-lvl = <2500>;
> +
> +   dlg,dmic-data-sel = "lrise_rfall";
> +   dlg,dmic-samplephase = "between_clkedge";
> +   dlg,dmic-clkrate = <300>;
> +   };
> --
> 1.9.3
>
--
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 2/4] drivers: clk: st: PLL rate change implementation for DVFS

[Stephen Boyd]

On 10/07, Gabriel Fernandez wrote:
> Change A9 PLL rate, as per requirement from the cpufreq framework,
> for DVFS. For rate change, the A9 clock needs to be temporarily sourced
> from PLL external to A9 and then sourced back to A9-PLL
> 
> Signed-off-by: Pankaj Dev 
> Signed-off-by: Gabriel Fernandez 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 1/2] WIP: Devicetree bindings for Ion

[Rob Herring]

On Wed, Oct 7, 2015 at 5:36 AM, Andrew  wrote:
> On 2015-10-07 02:01, Laura Abbott wrote:
>>
>> On 10/6/15 3:35 PM, Rob Herring wrote:
>>>
>>> On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott 
>>> wrote:

 From: Laura Abbott 


 This adds a base set of devicetree bindings for the Ion memory
 manager. This supports setting up the generic set of heaps and
 their properties.

 Signed-off-by: Laura Abbott 
 Signed-off-by: Andrew Andrianov 
 ---
   drivers/staging/android/ion/devicetree.txt | 53
 ++
>>>
>>>
>>> I have no issue with this going in here, but I do have lots of issues
>>> with this binding.
>>>
   1 file changed, 53 insertions(+)
   create mode 100644 drivers/staging/android/ion/devicetree.txt

 diff --git a/drivers/staging/android/ion/devicetree.txt
 b/drivers/staging/android/ion/devicetree.txt
 new file mode 100644
 index 000..4a0c941
 --- /dev/null
 +++ b/drivers/staging/android/ion/devicetree.txt
 @@ -0,0 +1,53 @@
 +Ion Memory Manager
 +
 +Ion is a memory manager that allows for sharing of buffers via dma-buf.
 +Ion allows for different types of allocation via an abstraction called
 +a 'heap'. A heap represents a specific type of memory. Each heap has
 +a different type. There can be multiple instances of the same heap
 +type.
 +
 +Required properties for Ion
 +
 +- compatible: "linux,ion"
 +
 +All child nodes of a linux,ion node are interpreted as heaps
 +
 +required properties for heaps
 +
 +- linux,ion-heap-id: The Ion heap id used for allocation selection
 +- linux,ion-heap-type: Ion heap type defined in ion.h
 +- linux,ion-heap-name: Human readble name of the heap
 +
 +
 +Optional properties
 +- memory-region: A phandle to a memory region. Required for DMA heap
 type
 +(see reserved-memory.txt for details on the reservation)
 +- linux,ion-heap-align: Alignment for the heap.
 +
 +Example:
 +
 +   ion {
 +   compatbile = "linux,ion";
 +   #address-cells = <1>;
 +   #size-cells = <0>;
 +
 +   ion-system-heap {
 +   linux,ion-heap-id = <0>;
 +   linux,ion-heap-type = ;
 +   linux,ion-heap-name = "system";
>>>
>>>
>>> How does this vary across platforms? Is all of this being pushed down
>>> to DT, because there is no coordination of this at the kernel ABI
>>> level across platforms. In other words, why can't heap 0 be hardcoded
>>> as system heap in the driver. It seems to me any 1 of these 3
>>> properties could be used to derive the other 2.
>>>
>>
>> Right now there is no guarantee heap IDs will be the same across
>> platforms. The heap IDs are currently part of the userspace ABI
>> as well since userspace clients must pass in a mask of the heap
>> IDs to allocate from. If we assume all existing clients could change,
>> heaps such as the system heap could be mandated to have the same
>> heap ID but we'd still run into problems if you have multiple
>> heaps of the same type (e.g. multiple carveouts)

Vendors largely ignore the kernel-userspace ABI and anything in
staging is not a ABI. So arguments about what the ABI is currently is
pointless IMO.

Pushing an inconsistent kernel ABI to DT is not the answer.

>
> I don't really like the idea of enforcing any IDs here. As of now
> heap ids are generally something VERY platform-specific
> (or even product-specific). Personally I'd prefer something like this
> for userspace apps:
>
> int id1 = ion_get_heap_id("camera");
> if (id1 < 0) {
>   fprintf(stderr, "Invalid heap id");
>   exit(1);
> }
>
> int id2 = ion_get_heap_id("backup-heap");
> if (id2 < 0) {
>   fprintf(stderr, "Invalid heap id");
>   exit(1);
> }

We've learned that creating number spaces like this are bad (irqs,
gpios, /dev nodes). We should move away from that. Why should
userspace care about IDs or what the IDs are? An ID is just encoding
certain implicit requirements. So are the strings here. Users should
express what capabilities, restrictions, etc. they have, and then the
kernel can find the best heap.

> ...
>
> int ret = ion_alloc(fd, 0x100, 0x4,
>   (id1 | id2),
>   0, );
>
>
> What concerns kernel stuff, things are simpler - we may just pass the heap
> to use
> by a reference in devicetree node for that driver. Something like that:
>
> ...
>ion-decoder-region : region_ddr {
>linux,ion-heap-id = <1>;
>linux,ion-heap-type = ;
>linux,ion-heap-name = "decoder_mem"
>memory-region = <_region>;
> };
> ...
> 

Re: [PATCH v2 1/2] devicetree: add binding for generic mmio clocksource

[Måns Rullgård]

Mark Rutland  writes:

> On Wed, Oct 07, 2015 at 04:37:13PM +0100, Mans Rullgard wrote:
>> This adds a DT binding for a generic mmio clocksource as implemented
>> by clocksource_mmio_init().
>> 
>> Signed-off-by: Mans Rullgard 
>> ---
>> Changed in v2:
>> - added sched_clock support
>> ---
>>  .../devicetree/bindings/timer/clocksource-mmio.txt | 28 
>> ++
>>  1 file changed, 28 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/timer/clocksource-mmio.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/timer/clocksource-mmio.txt 
>> b/Documentation/devicetree/bindings/timer/clocksource-mmio.txt
>> new file mode 100644
>> index 000..cfb3601
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/timer/clocksource-mmio.txt
>> @@ -0,0 +1,28 @@
>> +Generic MMIO clocksource
>> +
>> +Required properties:
>> +
>> +- compatible: should be "clocksource-mmio"
>> +- reg: the physical address of the counter register
>> +- reg-io-width: size of counter register in bytes, should be 2 or 4
>
> Can this not be inferred from the reg?

You're right, it can.

> What about 8 byte counters?

The existing code only supports 2 or 4, but that of course doesn't
matter here.

>> +- clocks: phandle to the source clock
>
> Is the frequency expected to be exactly the source clock frequency? I
> imagine it's possible for there to be a divisor.

There could of course be, though there isn't in the hardware I'm dealing
with.  Is specifying it here preferable using a fixed-factor-clock?

> We can add properties for that later, but we should be explcit as to
> what we currently expect the relationship between the clock and the
> clocksource to be.
>
>> +- clocksource-bits: number of valid bits
>> +- clocksource-rating: rating of the clocksource
>
> NAK. This has no meaning w.r.t. the hardware. This should not be in the
> DT. If there are criteria that bias this (e.g. frequency, latency), they
> should either be described in the DT or determined dynamically.

I had a bad feeling about this.  How would you suggest determining a
suitable value from actual hardware parameters?

>> +- linux,sched-clock: boolean, register clocksource as sched_clock
>
> Likewise, this property doesn't belong in the DT for the same reasons as
> clocksource-rating.

What would be a proper way to select a sched_clock source?  I realise
it's a Linux-specific thing and DT is supposed to be generic, but the
information must be provided somehow.

-- 
Måns Rullgård
m...@mansr.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