Re: [PATCH 1/2] spi: bcm2835: add spi-bcm2835aux driver for the auxiliar spi1 and spi2

[Martin Sperl]

> On 24.07.2015, at 06:09, Stephen Warren  wrote:
> 
> I think I'd expect the shared registers to be:
> 
> bcm2835aux: misc@0x7e215000 {
>compatible = "brcm,bcm2835-aux";
>reg = <0x7e215000 0x08>;
> };
> 
> There are two 4-byte registers outside the UART/SPI blocks, and the
> compatible value should reflect what the block is, not that Linux may
> use a syscon driver to implement the driver for it.
> 
> In the client, I'd expect a more semantic naming for the reference;
> something like:
> 
>   brcm,aux = <&bcm2835aux 4>;
> 
> brcm, since it's a custom/vendor-specific property. aux is the name of
> the object that's referenced. Packing the phandle and data together into
> a single property reduces the number of separate properties, and is a
> typical thing to do in a client of a service in DT.

So in the end you are saying we need a separate driver to get written
(because of ‘compatible = "brcm,bcm2835-aux”;’)

That is unless you would allow:
compatible = compatible = "brcm,bcm2835-aux”, “syscon”;

If this is not acceptable, then where should such a driver go in the
kernel tree?

It would essentially implement the following:
bcm2835aux_enable(dev, device-id);
bcm2835aux_disable(dev, device-id);

Which would just set/clean the bits in the register while holding a lock.

As an alternative: maybe we could implement it as an IRQ driver
and when the irq is requested for that device, then the HW-block gets
enabled automatically (and disabled when released).

That way we may not need to have a separate driver that would enable
the uart1, but it would be sufficient to configure it as follows:

uart1: uart@7e215040 {
compatible = "brcm,bcm2835-aux-uart", "ns16550";
reg = <0x7e215040 0x40>;
interrupts = ;
clock-frequency = <5>;
reg-shift = <2>;
no-loopback-test;
status = "disabled";
};

(taken from the foundation device-tree)

Please clarify

Thanks,
Martin--
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/7] serial: 8250_omap: workaround for IP errata

[Sekhar Nori]

Hi Greg,

On Tuesday 14 July 2015 06:19 PM, Tony Lindgren wrote:
> * Peter Hurley  [150714 05:24]:
>> On 07/14/2015 04:02 AM, Sekhar Nori wrote:
>>> This series works around "Advisory 21" as documented in
>>> AM437x SoC errata[1]. This errata prevents UART module
>>> from idling after DMA is used. AM335x and DRA7x also suffer
>>> from the same errata and chip design team is in the process
>>> of updating the errata documents of those devices as well.
>>>
>>> Patch 1/7 fixes a related bug but can be applied independently.
>>
>> Looks good. Thanks Sekhar!
>>
>> For series,
>>
>> Reviewed-by: Peter Hurley 
> 
> Also things still work for me, and the dts changes should
> not cause merge conflicts during v4.3 merge window based on
> what I have queued. So please feel free to queue these
> all via the tty tree and add:
> 
> Acked-by: Tony Lindgren  

Looks like you have queued the first 6 patches of this series but left
out 7/7 which is a DTS update. Based on above, Tony is okay with you
going ahead and queuing that DTS patch too. Can you please go ahead and
queue 7/7 as well?

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

Re: [PATCH v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250

[Krzysztof Kozlowski]

On 24.07.2015 12:40, Kukjin Kim wrote:
> On 07/24/15 09:30, Michael Turquette wrote:
>> Quoting Kukjin Kim (2015-07-07 07:43:31)
>>> Bartlomiej Zolnierkiewicz wrote:
> 
> [...]
> 
> Chanwoo Choi (3):
>   clk: samsung: exynos3250: Add cpu clock configuration data and 
> instaniate cpu clock
>   ARM: dts: Add CPU OPP and regulator supply property for Exynos3250
>   ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver
>
>  arch/arm/boot/dts/exynos3250-monk.dts   |  4 
>  arch/arm/boot/dts/exynos3250-rinato.dts |  4 
>  arch/arm/boot/dts/exynos3250.dtsi   | 15 +++
>  arch/arm/mach-exynos/exynos.c   |  1 +
>  drivers/clk/samsung/clk-exynos3250.c| 32 
> ++--
>  include/dt-bindings/clock/exynos3250.h  |  1 +
>  6 files changed, 55 insertions(+), 2 deletions(-)

 Reviewed-by: Bartlomiej Zolnierkiewicz 

 Thank you for working on this.

>>> +1 Thanks.
>>>
>>> Mike and Sylwester, if you're OK on this series, I'd like to pick up in 
>>> Samsung
>>> tree together. And if you want, I could provide topic branch for clk tree.
>>
>> Kukjin,
>>
>> A topic branch would be great.
>>
> Sure, BTW it means you did 'ack' on this clk change? If not, please let
> em know ;-) I'll let you know once the topic branch is ready.

Dear Kukjin,

Will you handle this patchset and dependants (ARM: dts: Add CPU cooling
binding for Exynos3250-based Rinato/Monk board) for v4.3?

Best regards,
Krzysztof

--
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: rockchip: Add veyron-speedy board

[Romain Perier]

Hi Heiko,

yep, sorry.

In fact I rebased my work on 4.2-rc3... (I usually use linux-next for
my work... not this time...). Next time ask for a v3 ;)
Thanks,
Romain

2015-07-23 22:21 GMT+02:00 Heiko Stübner :
> Hi Romain,
>
> I've applied the patch to my dts branch for 4.3 after fixing some smallish
> issues:
>
>
> Am Donnerstag, 23. Juli 2015, 18:50:49 schrieb Romain Perier:
>> Which is formally known as The Asus C201 chromebook
>
> ^ typo the with small "t"
>
>>
>> Signed-off-by: Romain Perier 
>> Reviewed-by: Doug Anderson 
>> ---
>>
>> Changes in v2:
>>  - Remove dvs-gpio (not used in mainline yet)
>>  - Remove edp subnode in pinctrl (not used in mainline yet)
>>  - Reordering disable-wp correctly
>>
>>  Documentation/devicetree/bindings/arm/rockchip.txt |  10 +-
>>  arch/arm/boot/dts/Makefile |   3 +-
>>  arch/arm/boot/dts/rk3288-veyron-speedy.dts | 155
>> + 3 files changed, 166 insertions(+), 2 deletions(-)
>>  create mode 100644 arch/arm/boot/dts/rk3288-veyron-speedy.dts
>>
>> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
>> b/Documentation/devicetree/bindings/arm/rockchip.txt index
>> 6de18bd2..da02022 100644
>> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
>> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
>> @@ -37,4 +37,12 @@ Rockchip platforms device tree bindings
>>  - Google Pinky (dev-board):
>>  Required root node properties:
>>- compatible = "google,veyron-pinky-rev2", "google,veyron-pinky",
>> -  "google,veyron", "rockchip,rk3288";
>> \ No newline at end of file
>> +  "google,veyron", "rockchip,rk3288";
>> +
>> +- Google Speedy (Asus C201 Chromebook):
>> +Required root node properties:
>> +  - compatible = "google,veyron-speedy-rev9",
>> "google,veyron-speedy-rev8", + 
>> "google,veyron-speedy-rev7",
>> "google,veyron-speedy-rev6",
>> +  "google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
>> +  "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
>> +  "google,veyron-speedy", "google,veyron", 
>> "rockchip,rk3288";
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 4993b3b..bf5225a 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -490,7 +490,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>>   rk3288-firefly-beta.dtb \
>>   rk3288-firefly.dtb \
>>   rk3288-veyron-jerry.dtb \
>> - rk3288-veyron-pinky.dtb
>> + rk3288-veyron-pinky.dtb \
>> + rk3288-veyron-speedy.dtb
>>  dtb-$(CONFIG_ARCH_S3C24XX) += \
>>   s3c2416-smdk2416.dtb
>>  dtb-$(CONFIG_ARCH_S3C64XX) += \
>
> both the board description as well as the Makefile did not apply cleanly, as
> you seem to have based it on some unknown branch.
> Please try to base patches on either linux-next or my version specific topic
> branch - v4.3-armsoc/dts in this case.
>
>
>> diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
>> b/arch/arm/boot/dts/rk3288-veyron-speedy.dts new file mode 100644
>> index 000..fdb2a73
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
>> @@ -0,0 +1,155 @@
>> +/*
>> + * Google Veyron Speedy Rev 1+ board device tree source
>> + *
>> + * Copyright 2015 Google, Inc
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This file is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of the
>> + * License, or (at your option) any later version.
>> + *
>> + * This file is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + *  Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + *   

Re: [PATCH v3 5/6] iommu/mediatek: Add mt8173 IOMMU driver

[Yong Wu]

On Tue, 2015-07-21 at 15:59 +0100, Will Deacon wrote:
> Hi Yong Wu,
> 
> On Thu, Jul 16, 2015 at 10:04:34AM +0100, Yong Wu wrote:
> > This patch adds support for mediatek m4u (MultiMedia Memory Management
> > Unit).
> 
> [...]
> 
> > +static void mtk_iommu_tlb_flush_all(void *cookie)
> > +{
> > +   struct mtk_iommu_domain *domain = cookie;
> > +   void __iomem *base;
> > +
> > +   base = domain->data->base;
> > +   writel(F_INVLD_EN1 | F_INVLD_EN0, base + REG_MMU_INV_SEL);
> > +   writel(F_ALL_INVLD, base + REG_MMU_INVALIDATE);
> 
> This needs to be synchronous, so you probably want to call
> mtk_iommu_tlb_sync at the end.

>From our spec, we have to wait until HW done after tlb flush range.
But it don't need wait after tlb flush all.
so It isn't necessary to add mtk_iommu_tlb_sync in tlb_flush_all here.

> 
> > +}
> > +
> > +static void mtk_iommu_tlb_add_flush(unsigned long iova, size_t size,
> > +   bool leaf, void *cookie)
> > +{
> > +   struct mtk_iommu_domain *domain = cookie;
> > +   void __iomem *base = domain->data->base;
> > +   unsigned int iova_start = iova, iova_end = iova + size - 1;
> > +
> > +   writel(F_INVLD_EN1 | F_INVLD_EN0, base + REG_MMU_INV_SEL);
> > +
> > +   writel(iova_start, base + REG_MMU_INVLD_START_A);
> > +   writel(iova_end, base + REG_MMU_INVLD_END_A);
> > +   writel(F_MMU_INV_RANGE, base + REG_MMU_INVALIDATE);
> 
> Why are you using writel instead of writel_relaxed? I asked this before
> but I don't think you replied.

Sorry, I didn't notice _relax last time. I will improve in next version.
Thanks very much.

> 
> Will


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

Re: [PATCH v3 3/6] iommu: add ARM short descriptor page table allocator.

[Yong Wu]

Hi Will,
Thanks for your review so detail.
When you are free, please help me check whether it's ok if it's
changed like below.
Thanks very much.

On Tue, 2015-07-21 at 18:11 +0100, Will Deacon wrote:
> Hello,
> 
> This is looking better, but I still have some concerns.
> 
> On Thu, Jul 16, 2015 at 10:04:32AM +0100, Yong Wu wrote:
> > This patch is for ARM Short Descriptor Format.
> > 
> > Signed-off-by: Yong Wu 
> > ---
> >  drivers/iommu/Kconfig|   18 +
> >  drivers/iommu/Makefile   |1 +
> >  drivers/iommu/io-pgtable-arm-short.c |  742 
> > ++
> >  drivers/iommu/io-pgtable-arm.c   |3 -
> >  drivers/iommu/io-pgtable.c   |4 +
> >  drivers/iommu/io-pgtable.h   |   13 +
> >  6 files changed, 778 insertions(+), 3 deletions(-)
> >  create mode 100644 drivers/iommu/io-pgtable-arm-short.c
> 
> [...]
> 
> > +#define ARM_SHORT_PGDIR_SHIFT  20
> > +#define ARM_SHORT_PAGE_SHIFT   12
> > +#define ARM_SHORT_PTRS_PER_PTE \
> > +   (1 << (ARM_SHORT_PGDIR_SHIFT - ARM_SHORT_PAGE_SHIFT))
> > +#define ARM_SHORT_BYTES_PER_PTE\
> > +   (ARM_SHORT_PTRS_PER_PTE * sizeof(arm_short_iopte))
> > +
> > +/* level 1 pagetable */
> > +#define ARM_SHORT_PGD_TYPE_PGTABLE BIT(0)
> > +#define ARM_SHORT_PGD_SECTION_XN   (BIT(0) | BIT(4))
> > +#define ARM_SHORT_PGD_TYPE_SECTION BIT(1)
> > +#define ARM_SHORT_PGD_PGTABLE_XN   BIT(2)
> 
> This should be PXN, but I'm not even sure why we care for a table at
> level 1.

I will delete it.

> 
> > +#define ARM_SHORT_PGD_BBIT(2)
> > +#define ARM_SHORT_PGD_CBIT(3)
> > +#define ARM_SHORT_PGD_PGTABLE_NS   BIT(3)
> > +#define ARM_SHORT_PGD_IMPLEBIT(9)
> > +#define ARM_SHORT_PGD_TEX0 BIT(12)
> > +#define ARM_SHORT_PGD_SBIT(16)
> > +#define ARM_SHORT_PGD_nG   BIT(17)
> > +#define ARM_SHORT_PGD_SUPERSECTION BIT(18)
> > +#define ARM_SHORT_PGD_SECTION_NS   BIT(19)
> > +
> > +#define ARM_SHORT_PGD_TYPE_SUPERSECTION\
> > +   (ARM_SHORT_PGD_TYPE_SECTION | ARM_SHORT_PGD_SUPERSECTION)
> > +#define ARM_SHORT_PGD_SECTION_TYPE_MSK \
> > +   (ARM_SHORT_PGD_TYPE_SECTION | ARM_SHORT_PGD_SUPERSECTION)
> > +#define ARM_SHORT_PGD_PGTABLE_TYPE_MSK \
> > +   (ARM_SHORT_PGD_TYPE_SECTION | ARM_SHORT_PGD_TYPE_PGTABLE)
> > +#define ARM_SHORT_PGD_TYPE_IS_PGTABLE(pgd) \
> > +   (((pgd) & ARM_SHORT_PGD_PGTABLE_TYPE_MSK) == 
> > ARM_SHORT_PGD_TYPE_PGTABLE)
> > +#define ARM_SHORT_PGD_TYPE_IS_SECTION(pgd) \
> > +   (((pgd) & ARM_SHORT_PGD_SECTION_TYPE_MSK) == 
> > ARM_SHORT_PGD_TYPE_SECTION)
> > +#define ARM_SHORT_PGD_TYPE_IS_SUPERSECTION(pgd)\
> > +   (((pgd) & ARM_SHORT_PGD_SECTION_TYPE_MSK) == \
> > +   ARM_SHORT_PGD_TYPE_SUPERSECTION)
> > +#define ARM_SHORT_PGD_PGTABLE_MSK  0xfc00
> > +#define ARM_SHORT_PGD_SECTION_MSK  (~(SZ_1M - 1))
> > +#define ARM_SHORT_PGD_SUPERSECTION_MSK (~(SZ_16M - 1))
> > +
> > +/* level 2 pagetable */
> > +#define ARM_SHORT_PTE_TYPE_LARGE   BIT(0)
> > +#define ARM_SHORT_PTE_SMALL_XN BIT(0)
> > +#define ARM_SHORT_PTE_TYPE_SMALL   BIT(1)
> > +#define ARM_SHORT_PTE_BBIT(2)
> > +#define ARM_SHORT_PTE_CBIT(3)
> > +#define ARM_SHORT_PTE_SMALL_TEX0   BIT(6)
> > +#define ARM_SHORT_PTE_IMPLEBIT(9)
> 
> This is AP[2] for small pages.

Sorry, In our pagetable bit9 in PGD and PTE is PA[32] that is for  the
dram size over 4G. I didn't care it is different in PTE of the standard
spec.
And I don't use the AP[2] currently, so I only delete this line in next
time.

> 
> > +#define ARM_SHORT_PTE_SBIT(10)
> > +#define ARM_SHORT_PTE_nG   BIT(11)
> > +#define ARM_SHORT_PTE_LARGE_TEX0   BIT(12)
> > +#define ARM_SHORT_PTE_LARGE_XN BIT(15)
> > +#define ARM_SHORT_PTE_LARGE_MSK(~(SZ_64K - 1))
> > +#define ARM_SHORT_PTE_SMALL_MSK(~(SZ_4K - 1))
> > +#define ARM_SHORT_PTE_TYPE_MSK \
> > +   (ARM_SHORT_PTE_TYPE_LARGE | ARM_SHORT_PTE_TYPE_SMALL)
> > +#define ARM_SHORT_PTE_TYPE_IS_SMALLPAGE(pte)   \
> > +   (pte) & ARM_SHORT_PTE_TYPE_MSK) >> 1) << 1)\
> > +   == ARM_SHORT_PTE_TYPE_SMALL)
> 
> I see what you're trying to do here, but the shifting is confusing. I
> think it's better doing something like:
> 
>   ((pte) & ARM_SHORT_PTE_TYPE_SMALL) == ARM_SHORT_PTE_TYPE_SMALL
> 
> or even just:
> 
>   (pte) & ARM_SHORT_PTE_TYPE_SMALL

Thanks. I will use this:
((pte) & ARM_SHORT_PTE_TYPE_SMALL) == ARM_SHORT_PTE_TYPE_S

[PATCH 2/3] input: cyapa: add of match device support and description document

[Dudley Du]

Add of_match_device mechanism support for Cypress trackpad device, and
add the sample description document on how to adding the trackpad device node
in the device tree.

Signed-off-by: Dudley Du 
---
 .../devicetree/bindings/input/cypress,cyapa.txt| 44 ++
 .../devicetree/bindings/vendor-prefixes.txt|  1 +
 drivers/input/mouse/cyapa.c| 10 +
 3 files changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/cypress,cyapa.txt

diff --git a/Documentation/devicetree/bindings/input/cypress,cyapa.txt 
b/Documentation/devicetree/bindings/input/cypress,cyapa.txt
new file mode 100644
index 000..9be2b44
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cypress,cyapa.txt
@@ -0,0 +1,44 @@
+Cypress I2C Touchpad
+
+Required properties:
+- compatible: must be "cypress,cyapa".
+- reg: I2C address of the chip.
+- interrupt-parent: a phandle for the interrupt controller (see interrupt
+  binding[0]).
+- interrupts: interrupt to which the chip is connected (see interrupt
+  binding[0]).
+
+Optional properties:
+- wakeup-source: touchpad can be used as a wakeup source.
+- pinctrl-names: should be "default" (see pinctrl binding [1]).
+- pinctrl-0: a phandle pointing to the pin settings for the device (see
+  pinctrl binding [1]).
+- vcc-supply: a phandle for the regulator supplying 3.3V power.
+
+[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+[1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+
+Example:
+   &i2c0 {
+   /* ... */
+
+   /* Cypress Gen3 touchpad */
+   touchpad@67 {
+   compatible = "cypress,cyapa";
+   reg = <0x24>;
+   interrupt-parent = <&gpio>;
+   interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO 2 */
+   wakeup-source;
+   };
+
+   /* Cypress Gen5 and later touchpad */
+   touchpad@24 {
+   compatible = "cypress,cyapa";
+   reg = <0x24>;
+   interrupt-parent = <&gpio>;
+   interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO 2 */
+   wakeup-source;
+   };
+
+   /* ... */
+   };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d444757..57c0f5f 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -54,6 +54,7 @@ cortina   Cortina Systems, Inc.
 cosmic Cosmic Circuits
 crystalfontz   Crystalfontz America, Inc.
 cubietech  Cubietech, Ltd.
+cypressCypress Semiconductor Corporation
 dallas Maxim Integrated Products (formerly Dallas Semiconductor)
 davicomDAVICOM Semiconductor, Inc.
 delta  Delta Electronics, Inc.
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 2159c5e..3431510 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "cyapa.h"
 
 
@@ -1486,11 +1487,20 @@ static const struct acpi_device_id cyapa_acpi_id[] = {
 MODULE_DEVICE_TABLE(acpi, cyapa_acpi_id);
 #endif
 
+#ifdef CONFIG_OF
+static const struct of_device_id cyapa_of_match[] = {
+   { .compatible = "cypress,cyapa" },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, cyapa_of_match);
+#endif
+
 static struct i2c_driver cyapa_driver = {
.driver = {
.name = "cyapa",
.pm = &cyapa_pm_ops,
.acpi_match_table = ACPI_PTR(cyapa_acpi_id),
+   .of_match_table = of_match_ptr(cyapa_of_match),
},
 
.probe = cyapa_probe,
-- 
1.9.1


---
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---

--
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] input: cyapa: add regulator vcc support

[Dudley Du]

Add power management regulator vcc support.
It's described to be supported in the cypress,cyapa.txt document.

Signed-off-by: Dudley Du 
---
 drivers/input/mouse/cyapa.c | 28 
 drivers/input/mouse/cyapa.h |  1 +
 2 files changed, 29 insertions(+)

diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 6195ccb..2159c5e 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -1241,6 +1241,13 @@ static void cyapa_remove_sysfs_group(void *data)
sysfs_remove_group(&cyapa->client->dev.kobj, &cyapa_sysfs_group);
 }
 
+static void cyapa_disable_regulator(void *data)
+{
+   struct cyapa *cyapa = data;
+
+   regulator_disable(cyapa->vcc);
+}
+
 static int cyapa_probe(struct i2c_client *client,
   const struct i2c_device_id *dev_id)
 {
@@ -1274,6 +1281,27 @@ static int cyapa_probe(struct i2c_client *client,
sprintf(cyapa->phys, "i2c-%d-%04x/input0", client->adapter->nr,
client->addr);
 
+   cyapa->vcc = devm_regulator_get(dev, "vcc");
+   if (IS_ERR(cyapa->vcc)) {
+   error = PTR_ERR(cyapa->vcc);
+   dev_err(dev, "failed to get vcc regulator: %d\n", error);
+   return error;
+   }
+
+   error = regulator_enable(cyapa->vcc);
+   if (error) {
+   dev_err(dev, "failed to enable regulator: %d\n", error);
+   return error;
+   }
+
+   error = devm_add_action(dev, cyapa_disable_regulator, cyapa);
+   if (error) {
+   cyapa_disable_regulator(cyapa);
+   dev_err(dev, "failed to add disable regulator action: %d\n",
+   error);
+   return error;
+   }
+
error = cyapa_initialize(cyapa);
if (error) {
dev_err(dev, "failed to detect and initialize tp device.\n");
diff --git a/drivers/input/mouse/cyapa.h b/drivers/input/mouse/cyapa.h
index af12536..b812bba 100644
--- a/drivers/input/mouse/cyapa.h
+++ b/drivers/input/mouse/cyapa.h
@@ -321,6 +321,7 @@ struct cyapa {
u8 status[BL_STATUS_SIZE];
bool operational; /* true: ready for data reporting; false: not. */
 
+   struct regulator *vcc;
struct i2c_client *client;
struct input_dev *input;
char phys[32];  /* Device physical location */
-- 
1.9.1


---
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---

--
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] input: cyapa: fix output unwanted warning issue

[Dudley Du]

Avoid the driver generate warning message when the cyapa driver working
with the old Gen5 trackpad device which does not support the proximity function.
Those old Gen5 trackpad device all have the platform version less than 2.

Signed-off-by: Dudley Du 
---
 drivers/input/mouse/cyapa_gen5.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
index 6d7abbe..118ba97 100644
--- a/drivers/input/mouse/cyapa_gen5.c
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -2519,10 +2519,13 @@ static int cyapa_gen5_do_operational_check(struct cyapa 
*cyapa)
__func__);
 
/* By default, the trackpad proximity function is enabled. */
-   error = cyapa_pip_set_proximity(cyapa, true);
-   if (error)
-   dev_warn(dev, "%s: failed to enable proximity.\n",
-   __func__);
+   if (cyapa->platform_ver >= 2) {
+   error = cyapa_pip_set_proximity(cyapa, true);
+   if (error)
+   dev_warn(dev,
+   "%s: failed to enable proximity.\n",
+   __func__);
+   }
 
/* Get trackpad product information. */
error = cyapa_gen5_get_query_data(cyapa);
-- 
1.9.1


---
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---

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

[PATCH 0/3] cyapa patches instruction

[Dudley Du]

These patches are made based on Dmitry's next tree.
It's aimed to add regulator vcc and of match device tree supported, and also
fix the output unwanted wanring message issue when working with old Gen5
Trackpad device that doesn't support the proximity function.

Dudley Du (3):
  input: cyapa: add regulator vcc support
  input: cyapa: add of match device support and description document
  input: cyapa: fix output unwanted warning issue

 .../devicetree/bindings/input/cypress,cyapa.txt| 44 ++
 .../devicetree/bindings/vendor-prefixes.txt|  1 +
 drivers/input/mouse/cyapa.c| 38 +++
 drivers/input/mouse/cyapa.h|  1 +
 drivers/input/mouse/cyapa_gen5.c   | 11 --
 5 files changed, 91 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/cypress,cyapa.txt

-- 
1.9.1


---
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---

--
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 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx

[Tony Lindgren]

* Suman Anna  [150723 09:25]:
> Hi Tony,
> 
> On 07/23/2015 02:24 AM, Tony Lindgren wrote:
> > * Suman Anna  [150722 09:25]:
> >> On 07/22/2015 12:26 AM, Tony Lindgren wrote:
> >>>
> >>> I don't like using syscon for tinkering directly with SoC registers.
> >>
> >> This is not a SoC-level register, but a register within a sub-module of
> >> the DSP processor sub-system. The DSP_SYSTEM sub-module in general is
> >> described in Section 5.3.3 of the TRM [1], and it implements different
> >> functionalities like the PRCM handshaking, wakeup logic and DSP
> >> subsystem top-level configuration. It is a module present within the DSP
> >> processor sub-system, so can only be accessed when the sub-system is
> >> clocked and the appropriate reset is released.
> > 
> > OK so if it's specific to the DSP driver along the lines of sysc and
> > syss registers.
> 
> There will be those registers too within the MMU config register space,
> even for DRA7xx MMUs. This is different, think of it like a register in
> the Control module except that it is present within the DSP sub-system
> instead of at the SoC level.

And what is taking care of pm_runtime_get here to ensure the module
is powered and clocked?

I think you are missing a layer here and it's the Linux kernel side
device driver for DSP that initializes things.
 
> > Typically we handle these registers by mapping them to the PM runtime
> > functions for the interconnect so we can reset and idle the hardware
> > modules even if there is no driver, see for example
> > omap54xx_mmu_dsp_hwmod.
> 
> I haven't yet submitted the DRA7xx hwmods, but they will look almost
> exactly like the OMAP5 ones. The reset and idle on these are in general
> not effective at boot time since these are also controlled by a
> hard-reset line, so that's left to the drivers to deal with it through
> the omap_device_deassert_hardreset API.

If the MMU configuration is one time init, it may make sense to add
it to the hwmod reset function. However, if the Linux kernel side
driver needs to configure things depending on the DSP firmware, it
should be done in the kernel side device driver. 
 
> >>> We should use some Linux generic framework for configuring these
> >>> bits to avoid nasty dependencies between various hardware modules
> >>> on the SoC.
> >>>
> >>> What does DSP_SYS_MMU_CONFIG register do? It seems it's probably
> >>> a regulator or a gate clock? If so, it should be set up as a
> >>> regulator or a clock and then the omap-iommu driver can just
> >>> use regulator or clcok framework to request the resource.
> >>
> >> No, its neither. It is a control bit that dictates whether the
> >> processor/EDMA addresses go through the respective MMU or not. The
> >> register currently has 4 bits (bit 0 in each nibble), one each for
> >> enabling each MMU and requesting an MMU abort on each. The MMU
> >> integration and enablement notes are detailed in Section 5.3.6 of the
> >> TRM [1], and the DSP_SYS_MMU_CONFIG register layout is in Table 5-28
> >> (Page 1641).
> > 
> > OK yeah seems like it should be handled by the DSP driver during
> > probe after doing pm_runtime_get. Then the driver can configure
> > things like IOMMU and load firmware. Or am I missing something here?
> 
> The DSP (remoteproc) driver uses the generic IOMMU API, and all the
> IOMMU enabling sequence is transparent to the DSP driver. So, any
> configuration/enabling sequence specific to the IOMMU has to be handled
> within the respective IOMMU platform driver that gets integrated into
> the IOMMU API.

To me it seems you still need a DSP kernel driver to manage the
DSP hardware for PM runtime. I don't see how iommu and remoteproc
alone would be sufficient here. You end up sprinkling DSP driver
specific code to the iommu and remoteproc layers.

Regards,

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

Re: [PATCH v2 2/4] irqchip: bcm2835: If a parent interrupt is registered, chain from it.

[Stephen Warren]

On 07/22/2015 12:17 PM, Eric Anholt wrote:
> Stephen Warren  writes:
> 
>> On 07/13/2015 07:35 PM, Eric Anholt wrote:
>>> The BCM2836 (Raspberry Pi 2) uses two levels of interrupt
>>> handling with the CPU-local interrupts being the root, so we
>>> need to register ours as chained off of the CPU's local
>>> interrupt.
>> 
>> Sorry for the slow review; laziness after vacation!
>> 
>>> diff --git
>>> a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
>>> b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
>>
>>>
>>> 
+The BCM2836 contains the same interrupt controller with the same
>>> +interrupts, but the per-CPU interrupt controller is the root,
>>> and an +interrupt there indicates that the ARMCTRL has an
>>> interrupt to handle. + Required properties:
>>> 
>>> - compatible : should be "brcm,bcm2835-armctrl-ic"
>> 
>> Since there are some differences between the bcm2835 and bcm2836
>> HW blocks, I'd expect the compatible value to be different for
>> each. In particular...
> 
> Well, there are actually no differences within this block of the HW
> (HDL is unmodified), it's just where the output interrupt line gets
> consumed. But it's not much extra to add a new compatible value, so
> sure.

Mmm. I suppose that's true indeed.

So, I guess either of the following is fine for bcm2836 by me:

compatible = "brcm,bcm2836-armctrl-ic";
compatible = "brcm,bcm2836-armctrl-ic", "brcm,bcm2835-armctrl-ic";

The 2836 value is always needed since DT should contain the most
specific compatible value for the implementation. The 2835 value is
optional based on whether the HW block is 100% backwards-compatible
with the older HW block; a driver for the old block can run unmodified
against the new block. It's debatable whether that's true here; the
interface to this HW block itself is unchanged between
implementations, yet the way the driver for it integrates into the
system differs since it either is/isn't a top-level IRQ chip.
--
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] spi: bcm2835: add spi-bcm2835aux driver for the auxiliar spi1 and spi2

[Stephen Warren]

On 07/22/2015 10:28 AM, Martin Sperl wrote:
> 
> 
>> On 22.07.2015, at 03:55, Stephen Warren  wrote:
>>
>> However, I'd like to see a "semantic" driver for the shared register
>> region rather than a "syscon". IIUC, "syscon" simply provides a stylized
>> way for one driver to touch some shared registers directly without any
>> semantics. I'd strongly prefer to see a real driver inside Linux rather
>> than something that just lets drivers fiddle with the shared registers
>> willy nilly. Still, this aspect is an internal implementation detail
>> inside the kernel that we can change without external impact later if we
>> need.
>>
>> More concerning: The bcm283x HW doesn't implement a "syscon" module, but
>> some semantic IP block. The DT should contain a real compatible value
>> that describes what the HW block really is, not just "syscon". We could
>> bind the syscon driver to this compatible value if we have to for
> 
> So, do I understand you correctly that if we would call the node 
> bcm2835aux_enable as syscon with only the enable bit field register in it 
> and add a enable_reg (pointing to the above) and enable_reg_mask=2 or 4
> to the spi1/2 nodes then it would be acceptable? 
> 
> Would look like this:
> spi2@7e2150c0 {
> +compatible = "brcm,bcm2835-aux-spi";
> +reg = <0x7e2150c0 0x40>;
> +interrupts = <1 29>;
> +clocks = <&clk_spi>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +cs-gpios = <&gpio 43>, <&gpio 44>, <&gpio 45>;
> +enable_reg = <&bcm2835aux_enable>;
> +enable_reg_mask = 4;
> +};
> +
> +/* the necessary syscon config referenced above */
> +bcm2835aux_enable: bcm2835aux_enable@0x7e215004 {
> +compatible = "syscon";
> +reg = <0x7e215004 0x04>;
> +};
> 
> 
> The uart aux driver would use:
> +enable_reg = <&bcm2835aux_enable>;
> +enable_reg_mask = 1;

I think I'd expect the shared registers to be:

bcm2835aux: misc@0x7e215000 {
compatible = "brcm,bcm2835-aux";
reg = <0x7e215000 0x08>;
};

There are two 4-byte registers outside the UART/SPI blocks, and the
compatible value should reflect what the block is, not that Linux may
use a syscon driver to implement the driver for it.

In the client, I'd expect a more semantic naming for the reference;
something like:

brcm,aux = <&bcm2835aux 4>;

brcm, since it's a custom/vendor-specific property. aux is the name of
the object that's referenced. Packing the phandle and data together into
a single property reduces the number of separate properties, and is a
typical thing to do in a client of a service in DT.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250

[Kukjin Kim]

On 07/24/15 12:40, Kukjin Kim wrote:
> On 07/24/15 09:30, Michael Turquette wrote:
>> Quoting Kukjin Kim (2015-07-07 07:43:31)
>>> Bartlomiej Zolnierkiewicz wrote:
> 
> [...]
> 
> Chanwoo Choi (3):
>   clk: samsung: exynos3250: Add cpu clock configuration data and 
> instaniate cpu clock
>   ARM: dts: Add CPU OPP and regulator supply property for Exynos3250
>   ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver
>
>  arch/arm/boot/dts/exynos3250-monk.dts   |  4 
>  arch/arm/boot/dts/exynos3250-rinato.dts |  4 
>  arch/arm/boot/dts/exynos3250.dtsi   | 15 +++
>  arch/arm/mach-exynos/exynos.c   |  1 +
>  drivers/clk/samsung/clk-exynos3250.c| 32 
> ++--
>  include/dt-bindings/clock/exynos3250.h  |  1 +
>  6 files changed, 55 insertions(+), 2 deletions(-)

 Reviewed-by: Bartlomiej Zolnierkiewicz 

 Thank you for working on this.

>>> +1 Thanks.
>>>
>>> Mike and Sylwester, if you're OK on this series, I'd like to pick up in 
>>> Samsung
>>> tree together. And if you want, I could provide topic branch for clk tree.
>>
>> Kukjin,
>>
>> A topic branch would be great.
>>
> Sure, BTW it means you did 'ack' on this clk change? If not, please let
> em know ;-) I'll let you know once the topic branch is ready.
> 
Mike,

Done, the topic branch 'v4.3-topic/clk-samsung' in samsung tree is for
your clk tree.

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

Re: [PATCH v6 1/3] clk: samsung: exynos3250: Add cpu clock configuration data and instaniate cpu clock

[Kukjin Kim]

On 07/20/15 09:23, Chanwoo Choi wrote:
> Hi Sylwester,
> 
Hi Chanwoo,

> Please review this patch.
> 
Applied with Mike's ack BTW please make sure your patch has no problem
with checkpatch before submittingI've fixed them when I applied.

Thanks,
Kukjin

ERROR: code indent should use tabs where possible
#49: FILE: drivers/clk/samsung/clk-exynos3250.c:779:
+   (((apll) << 24) | ((pclk_dbg) << 20) | ((atb) << 16) |  \$

WARNING: please, no spaces at the start of a line
#49: FILE: drivers/clk/samsung/clk-exynos3250.c:779:
+   (((apll) << 24) | ((pclk_dbg) << 20) | ((atb) << 16) |  \$

ERROR: code indent should use tabs where possible
#50: FILE: drivers/clk/samsung/clk-exynos3250.c:780:
+   ((corem) << 4))$

WARNING: please, no spaces at the start of a line
#50: FILE: drivers/clk/samsung/clk-exynos3250.c:780:
+   ((corem) << 4))$

WARNING: please, no spaces at the start of a line
#55: FILE: drivers/clk/samsung/clk-exynos3250.c:785:
+   { 100, E3250_CPU_DIV0(1, 7, 4, 1), E3250_CPU_DIV1(7, 7), },$

WARNING: please, no spaces at the start of a line
#56: FILE: drivers/clk/samsung/clk-exynos3250.c:786:
+   {  90, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$

WARNING: please, no spaces at the start of a line
#57: FILE: drivers/clk/samsung/clk-exynos3250.c:787:
+   {  80, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$

WARNING: please, no spaces at the start of a line
#58: FILE: drivers/clk/samsung/clk-exynos3250.c:788:
+   {  70, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$

WARNING: please, no spaces at the start of a line
#59: FILE: drivers/clk/samsung/clk-exynos3250.c:789:
+   {  60, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$

WARNING: please, no spaces at the start of a line
#60: FILE: drivers/clk/samsung/clk-exynos3250.c:790:
+   {  50, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$

WARNING: please, no spaces at the start of a line
#61: FILE: drivers/clk/samsung/clk-exynos3250.c:791:
+   {  40, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$

WARNING: please, no spaces at the start of a line
#62: FILE: drivers/clk/samsung/clk-exynos3250.c:792:
+   {  30, E3250_CPU_DIV0(1, 5, 3, 1), E3250_CPU_DIV1(7, 7), },$

WARNING: please, no spaces at the start of a line
#63: FILE: drivers/clk/samsung/clk-exynos3250.c:793:
+   {  20, E3250_CPU_DIV0(1, 3, 3, 1), E3250_CPU_DIV1(7, 7), },$

WARNING: please, no spaces at the start of a line
#64: FILE: drivers/clk/samsung/clk-exynos3250.c:794:
+   {  10, E3250_CPU_DIV0(1, 1, 1, 1), E3250_CPU_DIV1(7, 7), },$

WARNING: please, no spaces at the start of a line
#65: FILE: drivers/clk/samsung/clk-exynos3250.c:795:
+   {  0 },$

total: 2 errors, 13 warnings, 63 lines checked

NOTE: Whitespace errors detected.
  You may wish to use scripts/cleanpatch or scripts/cleanfile

[PATCH v6 1_3] clk: samsung: exynos3250: Add cpu clock configuration
data and instaniate cpu clock.eml has style problems, please review.


> Best Regards,
> Chanwoo Choi
> 
> On 07/16/2015 04:46 PM, Krzysztof Kozlowski wrote:
>> 2015-07-02 9:42 GMT+09:00 Chanwoo Choi :
>>> This patch add CPU clock configuration data and instantiate the CPU clock 
>>> type
>>> for Exynos3250 to support Samsung specific cpu-clock type.
>>>
>>> Cc: Sylwester Nawrocki 
>>> Cc: Tomasz Figa 
>>> Signed-off-by: Chanwoo Choi 
>>> Acked-by: Kyungmin Park 
>>> Reviewed-by: Krzysztof Kozlowski 
>>> ---
>>>  drivers/clk/samsung/clk-exynos3250.c   | 32 
>>> ++--
>>>  include/dt-bindings/clock/exynos3250.h |  1 +
>>
>> Sylwester,
>>
>> I think this patch also waits for your review or ack.
>> The patchset is rebased on Bartlomiej's series for Exynos5250 cpufreq
>> so the easiest way would be to take it through samsung-soc tree.
>>
>> Best regards,
>> Krzysztof
>>
>>
>>>  2 files changed, 31 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/clk/samsung/clk-exynos3250.c 
>>> b/drivers/clk/samsung/clk-exynos3250.c
>>> index 538de66a759e..378ad5ad3492 100644
>>> --- a/drivers/clk/samsung/clk-exynos3250.c
>>> +++ b/drivers/clk/samsung/clk-exynos3250.c
>>> @@ -19,6 +19,7 @@
>>>  #include 
>>>
>>>  #include "clk.h"
>>> +#include "clk-cpu.h"
>>>  #include "clk-pll.h"
>>>
>>>  #define SRC_LEFTBUS0x4200
>>> @@ -319,8 +320,10 @@ static struct samsung_mux_clock mux_clks[] __initdata 
>>> = {
>>> MUX(CLK_MOUT_MPLL_USER_C, "mout_mpll_user_c", mout_mpll_user_p,
>>> SRC_CPU, 24, 1),
>>> MUX(CLK_MOUT_HPM, "mout_hpm", mout_hpm_p, SRC_CPU, 20, 1),
>>> -   MUX(CLK_MOUT_CORE, "mout_core", mout_core_p, SRC_CPU, 16, 1),
>>> -   MUX(CLK_MOUT_APLL, "mout_apll", mout_apll_p, SRC_CPU, 0, 1),
>>> +   MUX_F(CLK_MOUT_CORE, "mout_core", mout_core_p, SRC_CPU, 16, 1,
>>> +   CLK_SET_RATE_PARENT, 0),
>>> +   MUX_F(CLK_MOUT_APLL, "mout_apll", mout_apll_p, SRC_CPU, 0, 1,
>>> +   

Re: [PATCH v9 6/7] staging: add simple-fpga-bus

[atull]

On Thu, 23 Jul 2015, Jason Gunthorpe wrote:

> On Thu, Jul 23, 2015 at 02:55:52PM -0700, Moritz Fischer wrote:
> > Hi Alan,
> > 
> > I saw that your socfpga driver doesn't support the partial reconfig
> > use case (not a big deal).
> > What I currently do for Zynq is if I'm doing a non-partial reconfig is
> > that I disable input
> > level shifters and assert *all* resets while reprogramming in my FPGA
> > manager .write_init() and .write_complete().
> 
> I do this as well, but it is a bit more complex.. FPGA specific code
> has to run around and ensure all DMA is shut off, then we need to make
> sure no CPU issued AXI transactions can happen, then we can tear down
> the FPGA side.
> 
> If the FPGA is torn down while an AXI op is inprogress things go
> sideways, we have to work to prevent that :)
> 
> This happens almost for free, I use DT and the device model to
> disconnect the drivers. The drivers are careful to synchronously fence
> off in-progress DMA. Then drop the DT nodes associated with the
> FPGA, finally the actual FPGA cells can be reset.

Yes, the kernel gives us this almost for free.  That's what I like
about using DT overlays to control FPGA programming.

> 
> > In a partial reconfiguration situation, would I have separate
> > simple-fpga buses for each of the parts that I swap out, each with
> > it's own reset and bitfile attached?
> 
> I'd think of partial reconfiguration as another nested FPGA. The
> resets and so forth could be attached to soft controllers in the
> unswappable part of the FPGA.
> 
> DT nodes have to surround it in some way...
> 
> Jason
> 

Yes, in this way each PR chunk will need its own reset so it
won't wiggle busses and affect the rest of the system during PR.

I noticed that currently simple-fpga-bus.c holds an exclusive
ref of the fpga manager.  This would keep a 2nd pr from being
able to access the same fpga manager, so I'll have to change
it so that simple-fpga-bus.c will  put the ref before exiting
probe.

Alan
--
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/9] arm: twr-k70f120m: clock driver for Kinetis SoC

[Michael Turquette]

Quoting Paul Osmialowski (2015-07-04 14:50:03)
> Hi Arnd,
> 
> I'm attaching excerpt from Kinetis reference manual that may make 
> situation clearer.

Hi Paul,

Can you please post the patch in the body of the email instead of an
attachment? It makes it easier to review. Another small nitpick is that
the $SUBJECT for this patch might be better off as something like:

clk: mcg and sim clock drivers for twr-k70f120m Kinetis SoC

At least it helps me find the patch I care about when skimming the
series ;-)

> 
> These MCG and SIM registers are used only to determine configuration 
> (clock fixed rates and clock signal origins) at run time.
> 
> Namely, the real MCGOUTCLK source (in the middle) which is the parent for 
> core clock (CCLK) and peripheral clock (PCLK) is determined at run time by 
> reading MCG registers, let me quote commit message from Emcraft git repo:
> 
>   * Determine in run-time what oscillator module (OSC0 or OSC1) is used
>  as clock source for the main PLL.

According to [0] there are three options: a 32k RTC osc clock and osc0
both feed into a mux. You should model this 32k clock with the
fixed-rate binding.

>   * When OSC1 is selected, assume its frequency to be 12 MHz on all
>  boards (there is a 12 MHz oscillator on XTAL1/EXTAL1 on K70-SOM and
>  TWR-K70F120M boards).
> 
> In my .dts I'm trying to possibly follow real clock hierarchy, but to go 
> anywhere behind MCGOUTCLK would require ability to rewrite .dtb e.g. by 
> U-boot. But that's too demanding for any potential users of this BSP. So 
> let's asume that MCGOUTCLK is the root clock and a parent for CCLK and 
> PCLK.

I'm confused. The point of device tree is to solve problems like this;
i.e. board-specific differences such as different oscillator
frequencies.

OSC0 and OSC1 should each be a fixed-rate clock in your board-specific
TWR-K70F120M DTS (not a chip-specific file). They do not belong in the
cmu node, and they should use the "fixed-clock" binding. The 32k RTC osc
can probably go in your chip-specific .dtsi as a fixed-rate clock since
it appears to mandated in the reference manual[0].

These three fixed-rate clocks are your root clock nodes. Customers only
need to worry about this if they spin a board, and then they will need
to populate the frequencies of OSC0 and OSC1 in their board-specific
.dts.

Please break clk-kinetis.c into two files:
drivers/clk/kinetis/clk-mcg.c
drivers/clk/kinetis/clk-sim.c

Below is what your binding/dts should look like:

{
osc0: clock {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <5000>;
};

osc1: clock {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1200>;
};

rtc: clock {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <32768>;
};

soc: soc {
mcg: clock-controller@40064000 {
compatible = "fsl,kinetis-mcg";
clock-cells = <1>;
reg = <0x40064000 0x14>;
clocks = <&osc0>, <&osc1>, <&rtc>;
clock-names = "osc0", "osc1", "rtc";
};

sim: clock-controller@40047000 {
compatible = "fsl,kinetis-sim";
clock-cells = <1>;
reg = <0x40047000 0x1100>;
clocks = <&mcg MCG_MCGOUTCLK_DIV1>, <&mcg 
MCG_MCGOUTCLK_DIV2>, <&mcg MCG_MCGOUTCLK_DIV3> <&mcg MCG_MCGOUTCLK_DIV4>;
clock-names = "core", "bus", "flexbus", "flash";
};
};

uart0: serial@4006a000 {
compatible = "fsl,kinetis-lpuart";
reg = <0x4006a000 0x1000>;
clocks = <&sim SIM_SCGC4_UART1_CLK>;
clock-names = "gate";
};

I removed the interrupts and dma stuff from the uart0 node for clarity.
The above is the only style of binding that I have been accepting for
some time; first declare the clock controller and establish its register
space, and then consumers can consume clocks by providing the phandle to
the controller plus an offset corresponding to a unique clock. The
clock-names property makes it really easy to use with the clkdev stuff
(e.g. clk_get()).

I've covered this before on the mailing list so here is a link
describing how the qcom bindings do it in detail:

http://lkml.kernel.org/r/<20150416192014.19585.9663@quantum>

Technically you could encode the same bits as sub-nodes of the mcg and
sim nodes, but the shared header is how the magic happens with the
driver so it's best to keep the clock controller binding small and
light.

I think this means you can also get rid of kinetis_of_clk_get_name and
kinetis_clk_gate_get but my brain is tired so I'll leave that as an
exercise to

Re: [PATCH v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250

[Kukjin Kim]

On 07/24/15 09:30, Michael Turquette wrote:
> Quoting Kukjin Kim (2015-07-07 07:43:31)
>> Bartlomiej Zolnierkiewicz wrote:

[...]

 Chanwoo Choi (3):
   clk: samsung: exynos3250: Add cpu clock configuration data and 
 instaniate cpu clock
   ARM: dts: Add CPU OPP and regulator supply property for Exynos3250
   ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver

  arch/arm/boot/dts/exynos3250-monk.dts   |  4 
  arch/arm/boot/dts/exynos3250-rinato.dts |  4 
  arch/arm/boot/dts/exynos3250.dtsi   | 15 +++
  arch/arm/mach-exynos/exynos.c   |  1 +
  drivers/clk/samsung/clk-exynos3250.c| 32 
 ++--
  include/dt-bindings/clock/exynos3250.h  |  1 +
  6 files changed, 55 insertions(+), 2 deletions(-)
>>>
>>> Reviewed-by: Bartlomiej Zolnierkiewicz 
>>>
>>> Thank you for working on this.
>>>
>> +1 Thanks.
>>
>> Mike and Sylwester, if you're OK on this series, I'd like to pick up in 
>> Samsung
>> tree together. And if you want, I could provide topic branch for clk tree.
> 
> Kukjin,
> 
> A topic branch would be great.
> 
Sure, BTW it means you did 'ack' on this clk change? If not, please let
em know ;-) I'll let you know once the topic branch is ready.

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

Re: [PATCH v11 1/5] drm/layerscape: Add Freescale DCU DRM driver

[jianwei wang]

Hi Dave,

I think Freescale DCU DRM driver is ready now, can it land?

I have worked on this driver for about nine month. Daniel Vetter,
Thierry Reding, Mark yao,
Alexander Stein, Paul Bolle, Alison Wang, Stefan Agner reviewed this
pathset. The latest
version v11 has been send out about an week, and no more comments any more.

BR.
Jianwei

On Mon, Jul 20, 2015 at 5:53 PM, Jianwei Wang
 wrote:
> This patch add support for Two Dimensional Animation and Compositing
> Engine (2D-ACE) on the Freescale SoCs.
>
> 2D-ACE is a Freescale display controller. 2D-ACE describes
> the functionality of the module extremely well its name is a value
> that cannot be used as a token in programming languages.
> Instead the valid token "DCU" is used to tag the register names and
> function names.
>
> The Display Controller Unit (DCU) module is a system master that
> fetches graphics stored in internal or external memory and displays
> them on a TFT LCD panel. A wide range of panel sizes is supported
> and the timing of the interface signals is highly configurable.
> Graphics are read directly from memory and then blended in real-time,
> which allows for dynamic content creation with minimal CPU
> intervention.
>
> The features:
> (1) Full RGB888 output to TFT LCD panel.
> (2) Blending of each pixel using up to 4 source layers
> dependent
> on size of panel.
> (3) Each graphic layer can be placed with one pixel resolution
> in either axis.
> (4) Each graphic layer support RGB565 and RGB888 direct colors
> without alpha channel and BGRA BGRA ARGB1555 direct
> colors
> with an alpha channel and YUV422 format.
> (5) Each graphic layer support alpha blending with 8-bit
> resolution.
>
> This is a simplified version, only one primary plane, one
> framebuffer, one crtc, one connector and one encoder for TFT
> LCD panel.
>
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 
> Acked-by: Daniel Vetter 
> Reviewed-by: Alison Wang 
> ---
>
>
> Changed in V11
> -set regmap_config.cache_type to REGCACHE_FLAT
> Advanced by Alexander Stein
>
> Changed in V10
> -adjust commit log, remove meaningless statement
> -cleanup code for it's format and style.
> -remove platform related code out, including of tcon(vf610) and scfg(ls1021a)
> -remove useless sentences: encoder->crtc = crtc; and connector->encoder = 
> encoder; and so on
> -add vendor prefix for panel pandle
> -make a DCU_CTRLDESCLN(x, y)  to avoid high repetition
> -introduce per-SoC capability structure to avoid check on the OF node's 
> compatible string
> -Implement some functions: crtc enable and disable, enable and disable 
> VBLANK, plane atomic_disable and atomic_enable -atomic_check and so on
> -move DCU config sentence to the right place
> -move get resources functions to  ->probe()
> -move fsl,dcu.txt to video/ folder
> -add big-endian describe
> All advaced by Thierry Reding
>
> Changed in V9
>
> -put node after calling of_drm_find_panel
> -split clk_prepare_enable() to clk_prepare() and clk_enable(), just call 
> clk_prepare once, and check return value
> -check regmap_write/regmap_read return return value
> -remove useless ".owner= THIS_MODULE,"
> All advanced by Mark Yao
>
> Changed in V8
>
> - Remove useless code
>  #define DRIVER_NAME "fsl-dcu-drm"
>  MODULE_ALIAS("platform:fsl-dcu-drm");
> Adviced by Paul Bolle
>
> Changed in V7
>
> - Remove redundant functions and replace deprecated hooker
> Adviced by Daniel Vetter
> - Replace drm_platform_init with drm_dev_alloc/register
> Adviced by Daniel Vetter
>
> Changed in V6
>
> - Add NEC nl4827hc19_05b panel to panel-simple.c
> Adviced by Mark Yao
> - Add DRIVER_ATOMIC for driver_features
> Adviced by Mark Yao
> - check fsl_dev if it's NULL at PM suspend/resume
> Adviced by Mark Yao
>
> Changed in V5
>
> - Update commit message
> - Add layer registers initialization
> - Remove unused functions
> - Rename driver folder
> Adviced by Stefan Agner
> - Move pixel clock control functions to fsl_dcu_drm_drv.c
> - remove redundant enable the clock implicitly using regmap
> - Add maintainer message
>
> Changed in V4:
>
> -This version doesn't have functionality changed
> Just a minor adjustment.
>
> Changed in V3:
>
> - Test driver on Vybrid board and add compatible string
> - Remove unused functions
> - set default crtc for encoder
> - replace legacy functions with atomic help functions
> Adviced by Daniel Vetter
> - Set the unique name of the DRM device
> - Implement irq handle function for vblank interrupt
>
> Changed in v2:
> - Add atomic support
> Adviced by Daniel Vetter
> - Modify bindings file
> - Rename node for compatibility
> - Move platform related code out for compatibility
> Adviced by Stefan Agner
>
>
>  .../devicetree/bindings/video/fsl,dcu.txt  |  22 ++
>  MAINTAINERS|   8 +
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/fsl-d

[PATCH v4 7/7] arm64: dts: mt8173: Add subsystem clock controller device nodes

[James Liao]

This patch adds device nodes providing subsystem clocks on MT8173,
includes mmsys, imgsys, vdecsys, vencsys and vencltsys.

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

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index a2f63e4..8731d24 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -88,6 +88,13 @@
#clock-cells = <0>;
};
 
+   cpum_ck: dummy_clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   clock-output-names = "cpum_ck";
+   };
+
clk26m: oscillator@0 {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -227,6 +234,36 @@
clocks = <&uart_clk>;
status = "disabled";
};
+
+   mmsys: clock-controller@1400 {
+   compatible = "mediatek,mt8173-mmsys", "syscon";
+   reg = <0 0x1400 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   imgsys: clock-controller@1500 {
+   compatible = "mediatek,mt8173-imgsys", "syscon";
+   reg = <0 0x1500 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   vdecsys: clock-controller@1600 {
+   compatible = "mediatek,mt8173-vdecsys", "syscon";
+   reg = <0 0x1600 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   vencsys: clock-controller@1800 {
+   compatible = "mediatek,mt8173-vencsys", "syscon";
+   reg = <0 0x1800 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   vencltsys: clock-controller@1900 {
+   compatible = "mediatek,mt8173-vencltsys", "syscon";
+   reg = <0 0x1900 0 0x1000>;
+   #clock-cells = <1>;
+   };
};
 };
 
-- 
1.8.1.1.dirty

--
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/7] clk: mediatek: Fix rate and dependency of MT8173 clocks

[James Liao]

Remove the dependency from clk_null, and give all root clocks a
typical rate, include clkph_mck_o, usb_syspll_125m and hdmitx_dig_cts.

dpi_ck was removed due to no clock reference to it.

Replace parent clock of infra_cpum with cpum_ck, which is an external
clock and can be defined in the deivce tree.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-mt8173.c  | 13 ++---
 include/dt-bindings/clock/mt8173-clk.h |  1 -
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index 4b9e04c..50b3266 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -24,11 +24,9 @@
 
 static DEFINE_SPINLOCK(mt8173_clk_lock);
 
-static const struct mtk_fixed_factor root_clk_alias[] __initconst = {
-   FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
-   FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
-   FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
-   FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
+static const struct mtk_fixed_clk fixed_clks[] __initconst = {
+   FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m", 400 * MHZ),
+   FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk26m", 125 * 
MHZ),
 };
 
 static const struct mtk_fixed_factor top_divs[] __initconst = {
@@ -53,6 +51,7 @@ static const struct mtk_fixed_factor top_divs[] __initconst = 
{
FACTOR(CLK_TOP_CLKRTC_INT, "clkrtc_int", "clk26m", 1, 793),
FACTOR(CLK_TOP_FPC, "fpc_ck", "clk26m", 1, 1),
 
+   FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "tvdpll_445p5m", 1, 3),
FACTOR(CLK_TOP_HDMITXPLL_D2, "hdmitxpll_d2", "hdmitx_dig_cts", 1, 2),
FACTOR(CLK_TOP_HDMITXPLL_D3, "hdmitxpll_d3", "hdmitx_dig_cts", 1, 3),
 
@@ -611,7 +610,7 @@ static const struct mtk_gate infra_clks[] __initconst = {
GATE_ICG(CLK_INFRA_GCE, "infra_gce", "axi_sel", 6),
GATE_ICG(CLK_INFRA_L2C_SRAM, "infra_l2c_sram", "axi_sel", 7),
GATE_ICG(CLK_INFRA_M4U, "infra_m4u", "mem_sel", 8),
-   GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "clk_null", 15),
+   GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "cpum_ck", 15),
GATE_ICG(CLK_INFRA_KP, "infra_kp", "axi_sel", 16),
GATE_ICG(CLK_INFRA_CEC, "infra_cec", "clk26m", 18),
GATE_ICG(CLK_INFRA_PMICSPI, "infra_pmicspi", "pmicspi_sel", 22),
@@ -714,7 +713,7 @@ static void __init mtk_topckgen_init(struct device_node 
*node)
 
clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
 
-   mtk_clk_register_factors(root_clk_alias, ARRAY_SIZE(root_clk_alias), 
clk_data);
+   mtk_clk_register_fixed_clks(fixed_clks, ARRAY_SIZE(fixed_clks), 
clk_data);
mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs), clk_data);
mtk_clk_register_composites(top_muxes, ARRAY_SIZE(top_muxes), base,
&mt8173_clk_lock, clk_data);
diff --git a/include/dt-bindings/clock/mt8173-clk.h 
b/include/dt-bindings/clock/mt8173-clk.h
index 4ad76ed..7230c38 100644
--- a/include/dt-bindings/clock/mt8173-clk.h
+++ b/include/dt-bindings/clock/mt8173-clk.h
@@ -18,7 +18,6 @@
 /* TOPCKGEN */
 
 #define CLK_TOP_CLKPH_MCK_O1
-#define CLK_TOP_DPI2
 #define CLK_TOP_USB_SYSPLL_125M3
 #define CLK_TOP_HDMITX_DIG_CTS 4
 #define CLK_TOP_ARMCA7PLL_754M 5
-- 
1.8.1.1.dirty

--
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 5/7] clk: mediatek: Add subsystem clocks of MT8173

[James Liao]

Most multimedia subsystem clocks will be accessed by multiple
drivers, so it's a better way to manage these clocks in CCF.
This patch adds clock support for MM, IMG, VDEC, VENC and VENC_LT
subsystems.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-mt8173.c  | 267 +
 include/dt-bindings/clock/mt8173-clk.h |  97 +++-
 2 files changed, 361 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index a72ce82..2cf6620 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -27,6 +27,10 @@ static DEFINE_SPINLOCK(mt8173_clk_lock);
 static const struct mtk_fixed_clk fixed_clks[] __initconst = {
FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m", 400 * MHZ),
FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk26m", 125 * 
MHZ),
+   FIXED_CLK(CLK_TOP_DSI0_DIG, "dsi0_dig", "clk26m", 130 * MHZ),
+   FIXED_CLK(CLK_TOP_DSI1_DIG, "dsi1_dig", "clk26m", 130 * MHZ),
+   FIXED_CLK(CLK_TOP_LVDS_PXL, "lvds_pxl", "lvdspll", 148.5 * MHZ),
+   FIXED_CLK(CLK_TOP_LVDS_CTS, "lvds_cts", "lvdspll", 51.975 * MHZ),
 };
 
 static const struct mtk_fixed_factor top_divs[] __initconst = {
@@ -699,6 +703,183 @@ static const struct mtk_composite peri_clks[] __initconst 
= {
MUX(CLK_PERI_UART3_SEL, "uart3_ck_sel", uart_ck_sel_parents, 0x40c, 3, 
1),
 };
 
+static const struct mtk_gate_regs cg_regs_4_8_0 = {
+   .set_ofs = 0x0004,
+   .clr_ofs = 0x0008,
+   .sta_ofs = 0x,
+};
+
+#define GATE_IMG(_id, _name, _parent, _shift) {\
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = &cg_regs_4_8_0, \
+   .shift = _shift,\
+   .ops = &mtk_clk_gate_ops_setclr,\
+   }
+
+static const struct mtk_gate img_clks[] __initconst = {
+   GATE_IMG(CLK_IMG_LARB2_SMI, "img_larb2_smi", "mm_sel", 0),
+   GATE_IMG(CLK_IMG_CAM_SMI, "img_cam_smi", "mm_sel", 5),
+   GATE_IMG(CLK_IMG_CAM_CAM, "img_cam_cam", "mm_sel", 6),
+   GATE_IMG(CLK_IMG_SEN_TG, "img_sen_tg", "camtg_sel", 7),
+   GATE_IMG(CLK_IMG_SEN_CAM, "img_sen_cam", "mm_sel", 8),
+   GATE_IMG(CLK_IMG_CAM_SV, "img_cam_sv", "mm_sel", 9),
+   GATE_IMG(CLK_IMG_FD, "img_fd", "mm_sel", 11),
+};
+
+static const struct mtk_gate_regs mm0_cg_regs = {
+   .set_ofs = 0x0104,
+   .clr_ofs = 0x0108,
+   .sta_ofs = 0x0100,
+};
+
+static const struct mtk_gate_regs mm1_cg_regs = {
+   .set_ofs = 0x0114,
+   .clr_ofs = 0x0118,
+   .sta_ofs = 0x0110,
+};
+
+#define GATE_MM0(_id, _name, _parent, _shift) {\
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = &mm0_cg_regs,   \
+   .shift = _shift,\
+   .ops = &mtk_clk_gate_ops_setclr,\
+   }
+
+#define GATE_MM1(_id, _name, _parent, _shift) {\
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = &mm1_cg_regs,   \
+   .shift = _shift,\
+   .ops = &mtk_clk_gate_ops_setclr,\
+   }
+
+static const struct mtk_gate mm_clks[] __initconst = {
+   /* MM0 */
+   GATE_MM0(CLK_MM_SMI_COMMON, "mm_smi_common", "mm_sel", 0),
+   GATE_MM0(CLK_MM_SMI_LARB0, "mm_smi_larb0", "mm_sel", 1),
+   GATE_MM0(CLK_MM_CAM_MDP, "mm_cam_mdp", "mm_sel", 2),
+   GATE_MM0(CLK_MM_MDP_RDMA0, "mm_mdp_rdma0", "mm_sel", 3),
+   GATE_MM0(CLK_MM_MDP_RDMA1, "mm_mdp_rdma1", "mm_sel", 4),
+   GATE_MM0(CLK_MM_MDP_RSZ0, "mm_mdp_rsz0", "mm_sel", 5),
+   GATE_MM0(CLK_MM_MDP_RSZ1, "mm_mdp_rsz1", "mm_sel", 6),
+   GATE_MM0(CLK_MM_MDP_RSZ2, "mm_mdp_rsz2", "mm_sel", 7),
+   GATE_MM0(CLK_MM_MDP_TDSHP0, "mm_mdp_tdshp0", "mm_sel", 8),
+   GATE_MM0(CLK_MM_MDP_TDSHP1, "mm_mdp_tdshp1", "mm_sel", 9),
+   GATE_MM0(CLK_MM_MDP_WDMA, "mm_mdp_wdma", "mm_sel", 11),
+   GATE_MM0(CLK_MM_MDP_WROT0, "mm_mdp_wrot0", "mm_sel", 12),
+   GATE_MM0(CLK_MM_MDP_WROT1, "mm_mdp_wrot1", "mm_sel", 13),
+   GATE_MM0(CLK_MM_FAKE_ENG, "mm_fake_eng", "mm_sel", 14),
+   GATE_MM0(CLK_MM_MUTEX_32K, "mm_mutex_32k", "rtc_sel", 15),
+   GATE_MM0(CLK_MM_DISP_OVL0, "mm_disp_ovl0", "mm_sel", 16),
+   GATE_MM0(CLK_MM_DISP_OVL1, "mm_disp_ovl1", "mm_sel", 17),
+   GATE_MM0(CLK_MM

[PATCH v4 6/7] clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS

[James Liao]

Add REF2USB_TX clock support into MT8173 APMIXEDSYS. This clock
is needed by USB 3.0.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/Makefile  |   2 +-
 drivers/clk/mediatek/clk-apmixed.c | 137 +
 drivers/clk/mediatek/clk-mt8173.c  |  15 +++-
 drivers/clk/mediatek/clk-mtk.h |  26 +++
 drivers/clk/mediatek/clk-pll.c |   7 +-
 include/dt-bindings/clock/mt8173-clk.h |   3 +-
 6 files changed, 180 insertions(+), 10 deletions(-)
 create mode 100644 drivers/clk/mediatek/clk-apmixed.c

diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 8e4b2a4..95fdfac 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,4 +1,4 @@
-obj-y += clk-mtk.o clk-pll.o clk-gate.o
+obj-y += clk-mtk.o clk-pll.o clk-gate.o clk-apmixed.o
 obj-$(CONFIG_RESET_CONTROLLER) += reset.o
 obj-y += clk-mt8135.o
 obj-y += clk-mt8173.o
diff --git a/drivers/clk/mediatek/clk-apmixed.c 
b/drivers/clk/mediatek/clk-apmixed.c
new file mode 100644
index 000..09f2a7c
--- /dev/null
+++ b/drivers/clk/mediatek/clk-apmixed.c
@@ -0,0 +1,137 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: James Liao 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+#include "clk-mtk.h"
+
+#define REF2USB_TX_EN  BIT(0)
+#define REF2USB_TX_LPF_EN  BIT(1)
+#define REF2USB_TX_OUT_EN  BIT(2)
+#define REF2USB_EN_MASK(REF2USB_TX_EN | REF2USB_TX_LPF_EN | \
+REF2USB_TX_OUT_EN)
+
+struct mtk_ref2usb_tx {
+   struct clk_hw   hw;
+   void __iomem*base_addr;
+};
+
+static inline struct mtk_ref2usb_tx *to_mtk_ref2usb_tx(struct clk_hw *hw)
+{
+   return container_of(hw, struct mtk_ref2usb_tx, hw);
+}
+
+static int mtk_ref2usb_tx_is_prepared(struct clk_hw *hw)
+{
+   struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
+
+   return (readl(tx->base_addr) & REF2USB_EN_MASK) == REF2USB_EN_MASK;
+}
+
+static int mtk_ref2usb_tx_prepare(struct clk_hw *hw)
+{
+   struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
+   u32 val;
+
+   val = readl(tx->base_addr);
+
+   val |= REF2USB_TX_EN;
+   writel(val, tx->base_addr);
+   udelay(100);
+
+   val |= REF2USB_TX_LPF_EN;
+   writel(val, tx->base_addr);
+
+   val |= REF2USB_TX_OUT_EN;
+   writel(val, tx->base_addr);
+
+   return 0;
+}
+
+static void mtk_ref2usb_tx_unprepare(struct clk_hw *hw)
+{
+   struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
+   u32 val;
+
+   val = readl(tx->base_addr);
+   val &= ~REF2USB_EN_MASK;
+   writel(val, tx->base_addr);
+}
+
+static const struct clk_ops mtk_ref2usb_tx_ops = {
+   .is_prepared= mtk_ref2usb_tx_is_prepared,
+   .prepare= mtk_ref2usb_tx_prepare,
+   .unprepare  = mtk_ref2usb_tx_unprepare,
+};
+
+struct clk *mtk_clk_register_ref2usb_tx(const char *name,
+   const char *parent_name, void __iomem *reg)
+{
+   struct mtk_ref2usb_tx *tx;
+   struct clk_init_data init = {};
+   struct clk *clk;
+
+   tx = kzalloc(sizeof(*tx), GFP_KERNEL);
+   if (!tx)
+   return ERR_PTR(-ENOMEM);
+
+   tx->base_addr = reg;
+   tx->hw.init = &init;
+
+   init.name = name;
+   init.ops = &mtk_ref2usb_tx_ops;
+   init.parent_names = &parent_name;
+   init.num_parents = 1;
+
+   clk = clk_register(NULL, &tx->hw);
+
+   if (IS_ERR(clk)) {
+   pr_err("Failed to register clk %s: %ld\n", name, PTR_ERR(clk));
+   kfree(tx);
+   }
+
+   return clk;
+}
+
+void __init mtk_clk_register_apmixed_ex(struct device_node *node,
+   const struct mtk_clk_ex *clks, int num_clks,
+   struct clk_onecell_data *clk_data)
+{
+   void __iomem *base;
+   struct clk *clk;
+   int i;
+
+   base = of_iomap(node, 0);
+   if (!base) {
+   pr_err("%s(): ioremap failed\n", __func__);
+   return;
+   }
+
+   for (i = 0; i < num_clks; i++) {
+   const struct mtk_clk_ex *cke = &clks[i];
+
+   clk = cke->reg_clk_ex(cke->name, cke->parent,
+   base + cke->reg_ofs);
+
+   if (IS_ERR(clk)) {
+   pr_err("Failed to register clk %s: %ld\n", cke->name,
+   PTR_ERR(clk));
+   continue;
+   }
+
+   clk_data->clks[cke->id] = clk;
+   }
+}
diff --git a/dri

[PATCH v4 4/7] dt-bindings: ARM: Mediatek: Document devicetree bindings for clock controllers

[James Liao]

This adds the binding documentation for the mmsys, imgsys, vdecsys,
vencsys and vencltsys controllers found on Mediatek SoCs.

Signed-off-by: James Liao 
---
 .../bindings/arm/mediatek/mediatek,imgsys.txt  | 22 ++
 .../bindings/arm/mediatek/mediatek,mmsys.txt   | 22 ++
 .../bindings/arm/mediatek/mediatek,vdecsys.txt | 22 ++
 .../bindings/arm/mediatek/mediatek,vencltsys.txt   | 22 ++
 .../bindings/arm/mediatek/mediatek,vencsys.txt | 22 ++
 5 files changed, 110 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
new file mode 100644
index 000..b1f2ce1
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
@@ -0,0 +1,22 @@
+Mediatek imgsys controller
+
+
+The Mediatek imgsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+   - "mediatek,mt8173-imgsys", "syscon"
+- #clock-cells: Must be 1
+
+The imgsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+imgsys: clock-controller@1500 {
+   compatible = "mediatek,mt8173-imgsys", "syscon";
+   reg = <0 0x1500 0 0x1000>;
+   #clock-cells = <1>;
+};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
new file mode 100644
index 000..4385946
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
@@ -0,0 +1,22 @@
+Mediatek mmsys controller
+
+
+The Mediatek mmsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+   - "mediatek,mt8173-mmsys", "syscon"
+- #clock-cells: Must be 1
+
+The mmsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+mmsys: clock-controller@1400 {
+   compatible = "mediatek,mt8173-mmsys", "syscon";
+   reg = <0 0x1400 0 0x1000>;
+   #clock-cells = <1>;
+};
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
new file mode 100644
index 000..1faacf1
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
@@ -0,0 +1,22 @@
+Mediatek vdecsys controller
+
+
+The Mediatek vdecsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+   - "mediatek,mt8173-vdecsys", "syscon"
+- #clock-cells: Must be 1
+
+The vdecsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+vdecsys: clock-controller@1600 {
+   compatible = "mediatek,mt8173-vdecsys", "syscon";
+   reg = <0 0x1600 0 0x1000>;
+   #clock-cells = <1>;
+};
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
new file mode 100644
index 000..3cc299f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
@@ -0,0 +1,22 @@
+Mediatek vencltsys controller
+
+
+The Mediatek vencltsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+   - "mediatek,mt8173-vencltsys", "syscon"
+- #clock-cells: Must be 1
+
+The vencltsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+vencltsys: clock-controller@1900 {
+   compatible = "mediatek,mt8173-vencltsys", "syscon";
+   reg = <0 0x1900 0 0x1000>;
+   #clock-cells = <1>;
+};
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
new file mode 100644
index 000..5bb2866
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/med

[PATCH v4 3/7] clk: mediatek: mt8173: Fix enabling of critical clocks

[James Liao]

From: Sascha Hauer 

On the MT8173 the clocks are provided by different units. To enable
the critical clocks we must be sure that all parent clocks are already
registered, otherwise the parents of the critical clocks end up being
unused and get disabled later.

On MT8173, for example, it is the CLK_TOP clocks that have CLK_APMIXED
PLLs as their parents, so we cannot enable the CLK_TOP critical clocks
until the CLK_APMIXED clocks have all been registered.

To find a place where all parents are registered we try each time
after we've registered some clocks if all known providers are present
now and only then we enable the critical clocks.

Signed-off-by: Sascha Hauer 
Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-mt8173.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index 50b3266..a72ce82 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -699,6 +699,22 @@ static const struct mtk_composite peri_clks[] __initconst 
= {
MUX(CLK_PERI_UART3_SEL, "uart3_ck_sel", uart_ck_sel_parents, 0x40c, 3, 
1),
 };
 
+static struct clk_onecell_data *mt8173_top_clk_data;
+static struct clk_onecell_data *mt8173_pll_clk_data;
+
+static void __init mtk_clk_enable_critical(void)
+{
+   if (!mt8173_top_clk_data || !mt8173_pll_clk_data)
+   return;
+
+   clk_prepare_enable(mt8173_pll_clk_data->clks[CLK_APMIXED_ARMCA15PLL]);
+   clk_prepare_enable(mt8173_pll_clk_data->clks[CLK_APMIXED_ARMCA7PLL]);
+   clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_MEM_SEL]);
+   clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_DDRPHYCFG_SEL]);
+   clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_CCI400_SEL]);
+   clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_RTC_SEL]);
+}
+
 static void __init mtk_topckgen_init(struct device_node *node)
 {
struct clk_onecell_data *clk_data;
@@ -711,19 +727,19 @@ static void __init mtk_topckgen_init(struct device_node 
*node)
return;
}
 
-   clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
+   mt8173_top_clk_data = clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
 
mtk_clk_register_fixed_clks(fixed_clks, ARRAY_SIZE(fixed_clks), 
clk_data);
mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs), clk_data);
mtk_clk_register_composites(top_muxes, ARRAY_SIZE(top_muxes), base,
&mt8173_clk_lock, clk_data);
 
-   clk_prepare_enable(clk_data->clks[CLK_TOP_CCI400_SEL]);
-
r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
if (r)
pr_err("%s(): could not register clock provider: %d\n",
__func__, r);
+
+   mtk_clk_enable_critical();
 }
 CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt8173-topckgen", mtk_topckgen_init);
 
@@ -817,13 +833,13 @@ static void __init mtk_apmixedsys_init(struct device_node 
*node)
 {
struct clk_onecell_data *clk_data;
 
-   clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK);
+   mt8173_pll_clk_data = clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK);
if (!clk_data)
return;
 
mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
 
-   clk_prepare_enable(clk_data->clks[CLK_APMIXED_ARMCA15PLL]);
+   mtk_clk_enable_critical();
 }
 CLK_OF_DECLARE(mtk_apmixedsys, "mediatek,mt8173-apmixedsys",
mtk_apmixedsys_init);
-- 
1.8.1.1.dirty

--
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/7] clk: mediatek: Add fixed clocks support for Mediatek SoC.

[James Liao]

This patch adds fixed clocks support by using CCF fixed-rate
clock implementation.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-mtk.c | 23 +++
 drivers/clk/mediatek/clk-mtk.h | 19 ++-
 2 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 18444ae..f8307c3 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -49,6 +49,29 @@ err_out:
return NULL;
 }
 
+void mtk_clk_register_fixed_clks(const struct mtk_fixed_clk *clks, int num,
+   struct clk_onecell_data *clk_data)
+{
+   int i;
+   struct clk *clk;
+
+   for (i = 0; i < num; i++) {
+   const struct mtk_fixed_clk *rc = &clks[i];
+
+   clk = clk_register_fixed_rate(NULL, rc->name, rc->parent,
+   rc->parent ? 0 : CLK_IS_ROOT, rc->rate);
+
+   if (IS_ERR(clk)) {
+   pr_err("Failed to register clk %s: %ld\n",
+   rc->name, PTR_ERR(clk));
+   continue;
+   }
+
+   if (clk_data)
+   clk_data->clks[rc->id] = clk;
+   }
+}
+
 void mtk_clk_register_factors(const struct mtk_fixed_factor *clks, int num,
struct clk_onecell_data *clk_data)
 {
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index 9dda9d8..f083dfc 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -25,6 +25,23 @@
 
 #define MHZ (1000 * 1000)
 
+struct mtk_fixed_clk {
+   int id;
+   const char *name;
+   const char *parent;
+   unsigned long rate;
+};
+
+#define FIXED_CLK(_id, _name, _parent, _rate) {\
+   .id = _id,  \
+   .name = _name,  \
+   .parent = _parent,  \
+   .rate = _rate,  \
+   }
+
+void mtk_clk_register_fixed_clks(const struct mtk_fixed_clk *clks,
+   int num, struct clk_onecell_data *clk_data);
+
 struct mtk_fixed_factor {
int id;
const char *name;
@@ -41,7 +58,7 @@ struct mtk_fixed_factor {
.div = _div,\
}
 
-extern void mtk_clk_register_factors(const struct mtk_fixed_factor *clks,
+void mtk_clk_register_factors(const struct mtk_fixed_factor *clks,
int num, struct clk_onecell_data *clk_data);
 
 struct mtk_composite {
-- 
1.8.1.1.dirty

--
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 0/7] Add Mediatek MT8173 subsystem clocks support

[James Liao]

This patchset is based on 4.2-rc1 and [1], and contains subsystem
clocks support for Mediatek MT8173.

Previous reviews can be found in [2][3]. This patchset merge the 2
patchsets because of the dependency.

The most different from previous patchset are removing clk_null and
split usb clock support into a separated source file.

changes since v3:
- Remove clk_null dependency from root clocks.
- Use fixed-rate clocks with typical rate to replace clk_null.
- Add clk-apmixed.c to implement ref2usb_tx.
- Use clock-controller as the name of clock providers.

changes since v2:
- Rebase to 4.2-rc1.
- Add device tree nodes for subsystem clocks.
- Fine tune comments of patches.
- Add __init, __initconst and const to init data and functions.
- Removed unused code from init functions of subsystem clocks.

changes since v1:
- Add CA7PLL and CA15PLL as critical clocks.
- Use the same register descriptor for imgsys, vensys and vencltsys.
- Generalize apmixedsys special clocks registration.

[1] https://patchwork.kernel.org/patch/6446341/
[2] https://lkml.org/lkml/2015/7/10/254
[3] https://lkml.org/lkml/2015/7/10/230

James Liao (6):
  clk: mediatek: Add fixed clocks support for Mediatek SoC.
  clk: mediatek: Fix rate and dependency of MT8173 clocks
  dt-bindings: ARM: Mediatek: Document devicetree bindings for clock
controllers
  clk: mediatek: Add subsystem clocks of MT8173
  clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS
  arm64: dts: mt8173: Add subsystem clock controller device nodes

Sascha Hauer (1):
  clk: mediatek: mt8173: Fix enabling of critical clocks

 .../bindings/arm/mediatek/mediatek,imgsys.txt  |  22 ++
 .../bindings/arm/mediatek/mediatek,mmsys.txt   |  22 ++
 .../bindings/arm/mediatek/mediatek,vdecsys.txt |  22 ++
 .../bindings/arm/mediatek/mediatek,vencltsys.txt   |  22 ++
 .../bindings/arm/mediatek/mediatek,vencsys.txt |  22 ++
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  37 +++
 drivers/clk/mediatek/Makefile  |   2 +-
 drivers/clk/mediatek/clk-apmixed.c | 137 +
 drivers/clk/mediatek/clk-mt8173.c  | 321 -
 drivers/clk/mediatek/clk-mtk.c |  23 ++
 drivers/clk/mediatek/clk-mtk.h |  45 ++-
 drivers/clk/mediatek/clk-pll.c |   7 +-
 include/dt-bindings/clock/mt8173-clk.h | 101 ++-
 13 files changed, 756 insertions(+), 27 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
 create mode 100644 drivers/clk/mediatek/clk-apmixed.c

--
1.8.1.1.dirty

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

RE: [PATCH v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250

[Michael Turquette]

Quoting Kukjin Kim (2015-07-07 07:43:31)
> Bartlomiej Zolnierkiewicz wrote:
> > 
> > Hi,
> >
> Hi,
> 
> > On Thursday, July 02, 2015 09:42:38 AM Chanwoo Choi wrote:
> > > This patchset use cpufreq-dt driver to support Exynos3250 cpufreq and 
> > > tested it
> > > on Exynos3250-based Rinato board.
> > >
> > > Depends on:
> > > - next-20150701 tag (master branch) of linux-next kernel tree
> > > - This patch-set is based on Exynos5250 patch-set[1] because two patch-set
> > >   modify the 'arch/arm/mach-exynos/exynos.c' to add the compatible string.
> > >   [1] https://lkml.org/lkml/2015/6/29/361
> > >   : [PATCH v2 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 
> > > platform
> > >
> > > Changes from v5:
> > > (https://lkml.org/lkml/2015/7/1/324)
> > > - Reorder the cpu dt node in exynos3250-rinato/monk.dts alpabetically.
> > > - Add reviewed-by tag of Krzysztof Kozlowski 
> > >
> > > Changes from v4:
> > > (https://lkml.org/lkml/2014/10/20/215)
> > > - Rebased on latest linux-next git repository.
> > > - Remove unnecessary divider clock flag from divider of DIV_CPU0/DIV_CPU1 
> > > register
> > >
> > > Changes from v3:
> > > - This patchset is based on 3.18-rc1 with new patchset[3] of Thomas 
> > > Abraham
> > >   [3] [PATCH v11 0/6] cpufreq: use generic cpufreq drivers for exynos 
> > > platforms
> > >   - http://www.spinics.net/lists/arm-kernel/msg370412.html
> > >
> > > Changes from v2:
> > > - Rebased on new patchset of Thomas Abraham
> > >   and for-next branch of samsunc-clk.git of Tomasz Figa
> > >
> > > Changes from v1:
> > > - Rebased on new patchset[1] by Thomas Abraham
> > >   [1] [PATCH v10 0/6] cpufreq: use generic cpufreq drivers for exynos 
> > > platforms
> > >   - http://www.spinics.net/lists/arm-kernel/msg364790.html
> > > - Modify clk-cpu.c to support Exynos3250
> > > - Drop documentation patch on previous patchset[2]
> > >   [2] http://www.spinics.net/lists/cpufreq/msg10265.html
> > > - Add only operating-points for Exynos3250 without armclk-divider-table
> > >
> > > Chanwoo Choi (3):
> > >   clk: samsung: exynos3250: Add cpu clock configuration data and 
> > > instaniate cpu clock
> > >   ARM: dts: Add CPU OPP and regulator supply property for Exynos3250
> > >   ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver
> > >
> > >  arch/arm/boot/dts/exynos3250-monk.dts   |  4 
> > >  arch/arm/boot/dts/exynos3250-rinato.dts |  4 
> > >  arch/arm/boot/dts/exynos3250.dtsi   | 15 +++
> > >  arch/arm/mach-exynos/exynos.c   |  1 +
> > >  drivers/clk/samsung/clk-exynos3250.c| 32 
> > > ++--
> > >  include/dt-bindings/clock/exynos3250.h  |  1 +
> > >  6 files changed, 55 insertions(+), 2 deletions(-)
> > 
> > Reviewed-by: Bartlomiej Zolnierkiewicz 
> > 
> > Thank you for working on this.
> > 
> +1 Thanks.
> 
> Mike and Sylwester, if you're OK on this series, I'd like to pick up in 
> Samsung
> tree together. And if you want, I could provide topic branch for clk tree.

Kukjin,

A topic branch would be great.

Thanks,
Mike

> 
> Thanks,
> Kukjin
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
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 v9 6/7] staging: add simple-fpga-bus

[Jason Gunthorpe]

On Thu, Jul 23, 2015 at 02:55:52PM -0700, Moritz Fischer wrote:
> Hi Alan,
> 
> I saw that your socfpga driver doesn't support the partial reconfig
> use case (not a big deal).
> What I currently do for Zynq is if I'm doing a non-partial reconfig is
> that I disable input
> level shifters and assert *all* resets while reprogramming in my FPGA
> manager .write_init() and .write_complete().

I do this as well, but it is a bit more complex.. FPGA specific code
has to run around and ensure all DMA is shut off, then we need to make
sure no CPU issued AXI transactions can happen, then we can tear down
the FPGA side.

If the FPGA is torn down while an AXI op is inprogress things go
sideways, we have to work to prevent that :)

This happens almost for free, I use DT and the device model to
disconnect the drivers. The drivers are careful to synchronously fence
off in-progress DMA. Then drop the DT nodes associated with the
FPGA, finally the actual FPGA cells can be reset.

> In a partial reconfiguration situation, would I have separate
> simple-fpga buses for each of the parts that I swap out, each with
> it's own reset and bitfile attached?

I'd think of partial reconfiguration as another nested FPGA. The
resets and so forth could be attached to soft controllers in the
unswappable part of the FPGA.

DT nodes have to surround it in some way...

Jason
--
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 v9 6/7] staging: add simple-fpga-bus

[Moritz Fischer]

Hi Alan,

I saw that your socfpga driver doesn't support the partial reconfig
use case (not a big deal).
What I currently do for Zynq is if I'm doing a non-partial reconfig is
that I disable input
level shifters and assert *all* resets while reprogramming in my FPGA
manager .write_init() and .write_complete().
For a partial reconfig use case that obviously doesn't work, since I
don't want to
bring down the entire interconnect.
In a partial reconfiguration situation, would I have separate simple-fpga buses
for each of the parts that I swap out, each with it's own reset and
bitfile attached?

On Fri, Jul 17, 2015 at 8:51 AM,   wrote:
> From: Alan Tull 
>
> Add simple fpga bus.  This is a bus that configures an fpga and its
> bridges before populating the devices below it.  This is intended
> for use with device tree overlays.
>
> Note that FPGA bridges are seen as reset controllers so no special
> framework for FPGA bridges will need to be added.
>
> This supports fpga use where hardware blocks on a fpga will need
> drivers (as opposed to fpga used as an acceleration without drivers.)
>
> Signed-off-by: Alan Tull 
> ---
>  drivers/staging/fpga/Kconfig   |   11 ++
>  drivers/staging/fpga/Makefile  |1 +
>  drivers/staging/fpga/simple-fpga-bus.c |  323 
> 
>  3 files changed, 335 insertions(+)
>  create mode 100644 drivers/staging/fpga/simple-fpga-bus.c
>
> diff --git a/drivers/staging/fpga/Kconfig b/drivers/staging/fpga/Kconfig
> index 8254ca0..8d003e3 100644
> --- a/drivers/staging/fpga/Kconfig
> +++ b/drivers/staging/fpga/Kconfig
> @@ -11,4 +11,15 @@ config FPGA
>   kernel.  The FPGA framework adds a FPGA manager class and FPGA
>   manager drivers.
>
> +if FPGA
> +
> +config SIMPLE_FPGA_BUS
> +   bool "Simple FPGA Bus"
> +   depends on OF
> +   help
> + Simple FPGA Bus allows loading FPGA images under control of
> +Device Tree.
> +
> +endif # FPGA
> +
>  endmenu
> diff --git a/drivers/staging/fpga/Makefile b/drivers/staging/fpga/Makefile
> index 3313c52..6115213 100644
> --- a/drivers/staging/fpga/Makefile
> +++ b/drivers/staging/fpga/Makefile
> @@ -4,5 +4,6 @@
>
>  # Core FPGA Manager Framework
>  obj-$(CONFIG_FPGA) += fpga-mgr.o
> +obj-$(CONFIG_SIMPLE_FPGA_BUS)  += simple-fpga-bus.o
>
>  # FPGA Manager Drivers
> diff --git a/drivers/staging/fpga/simple-fpga-bus.c 
> b/drivers/staging/fpga/simple-fpga-bus.c
> new file mode 100644
> index 000..bf178d8
> --- /dev/null
> +++ b/drivers/staging/fpga/simple-fpga-bus.c
> @@ -0,0 +1,323 @@
> +/*
> + * Simple FPGA Bus
> + *
> + *  Copyright (C) 2013-2015 Altera Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * struct simple_fpga_bus - simple fpga bus private data
> + * @dev:   device from pdev
> + * @mgr:   the fpga manager associated with this bus
> + * @bridges:   an array of reset controls for controlling FPGA bridges
> + * associated with this bus
> + * @num_bridges: size of the bridges array
> + */
> +struct simple_fpga_bus {
> +   struct device *dev;
> +   struct fpga_manager *mgr;
> +   struct reset_control **bridges;
> +   int num_bridges;
> +};
> +
> +/**
> + * simple_fpga_bus_get_mgr - get associated fpga manager
> + * @priv: simple fpga bus private data
> + * pointer to fpga manager in priv->mgr on success
> + *
> + * Given a simple fpga bus, get a reference to its the fpga manager specified
> + * by its "fpga-mgr" device tree property.
> + *
> + * Return: 0 if success or if the fpga manager is not specified.
> + * Negative error code otherwise.
> + */
> +static int simple_fpga_bus_get_mgr(struct simple_fpga_bus *priv)
> +{
> +   struct device *dev = priv->dev;
> +   struct device_node *np = dev->of_node;
> +   struct fpga_manager *mgr;
> +   struct device_node *mgr_node;
> +
> +   /*
> +* Return 0 (not an error) if fpga manager is not specified.
> +* This supports the case where fpga was already configured.
> +*/
> +   mgr_node = of_parse_phandle(np, "fpga-mgr", 0);
> +   if (!mgr_node) {
> +   dev_dbg(dev, "could not find fpga-mgr DT property\n");
> +   return 0;
> +   }
> +
> +   mgr = of_fpga_mgr_get(mgr_node);

Re: [PATCH v2 09/11] ARM: dts: msm8974: Add smem reservation and node

[Andy Gross]

On Fri, Jun 26, 2015 at 02:50:17PM -0700, bj...@kryo.se wrote:
> From: Bjorn Andersson 
> 
> Signed-off-by: Bjorn Andersson 
> ---

Applied, thanks.

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the 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 v2 01/11] soc: qcom: Add device tree binding for SMEM

[Andy Gross]

On Fri, Jun 26, 2015 at 02:50:09PM -0700, bj...@kryo.se wrote:
> From: Bjorn Andersson 
> 
> Add device tree binding documentation for the Qualcom Shared Memory
> Manager.
> 
> Signed-off-by: Bjorn Andersson 



> + smem@fa0 {
> + compatible = "qcom,smem";
> +
> + memory-region = <&smem_region>;
> + reg = <0xfc428000 0x4000>;

I'll fixup the address here before applying.

Applied, thanks!

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the 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 v2 08/11] ARM: dts: msm8974: Add tcsr mutex node

[Andy Gross]

On Fri, Jun 26, 2015 at 02:50:16PM -0700, bj...@kryo.se wrote:
> From: Bjorn Andersson 
> 
> Signed-off-by: Bjorn Andersson 
> ---
>  arch/arm/boot/dts/qcom-msm8974.dtsi | 12 
>  1 file changed, 12 insertions(+)
> 

Applied, thanks!

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the 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 v2] ARM: dts: rockchip: Add veyron-speedy board

[Heiko Stübner]

Hi Romain,

I've applied the patch to my dts branch for 4.3 after fixing some smallish 
issues:


Am Donnerstag, 23. Juli 2015, 18:50:49 schrieb Romain Perier:
> Which is formally known as The Asus C201 chromebook

^ typo the with small "t"

> 
> Signed-off-by: Romain Perier 
> Reviewed-by: Doug Anderson 
> ---
> 
> Changes in v2:
>  - Remove dvs-gpio (not used in mainline yet)
>  - Remove edp subnode in pinctrl (not used in mainline yet)
>  - Reordering disable-wp correctly
> 
>  Documentation/devicetree/bindings/arm/rockchip.txt |  10 +-
>  arch/arm/boot/dts/Makefile |   3 +-
>  arch/arm/boot/dts/rk3288-veyron-speedy.dts | 155
> + 3 files changed, 166 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/boot/dts/rk3288-veyron-speedy.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> b/Documentation/devicetree/bindings/arm/rockchip.txt index
> 6de18bd2..da02022 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -37,4 +37,12 @@ Rockchip platforms device tree bindings
>  - Google Pinky (dev-board):
>  Required root node properties:
>- compatible = "google,veyron-pinky-rev2", "google,veyron-pinky",
> -  "google,veyron", "rockchip,rk3288";
> \ No newline at end of file
> +  "google,veyron", "rockchip,rk3288";
> +
> +- Google Speedy (Asus C201 Chromebook):
> +Required root node properties:
> +  - compatible = "google,veyron-speedy-rev9",
> "google,veyron-speedy-rev8", + 
> "google,veyron-speedy-rev7",
> "google,veyron-speedy-rev6",
> +  "google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
> +  "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
> +  "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 4993b3b..bf5225a 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -490,7 +490,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>   rk3288-firefly-beta.dtb \
>   rk3288-firefly.dtb \
>   rk3288-veyron-jerry.dtb \
> - rk3288-veyron-pinky.dtb
> + rk3288-veyron-pinky.dtb \
> + rk3288-veyron-speedy.dtb
>  dtb-$(CONFIG_ARCH_S3C24XX) += \
>   s3c2416-smdk2416.dtb
>  dtb-$(CONFIG_ARCH_S3C64XX) += \

both the board description as well as the Makefile did not apply cleanly, as 
you seem to have based it on some unknown branch.
Please try to base patches on either linux-next or my version specific topic 
branch - v4.3-armsoc/dts in this case.


> diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> b/arch/arm/boot/dts/rk3288-veyron-speedy.dts new file mode 100644
> index 000..fdb2a73
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> @@ -0,0 +1,155 @@
> +/*
> + * Google Veyron Speedy Rev 1+ board device tree source
> + *
> + * Copyright 2015 Google, Inc
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + *  Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR O

Re: [PATCH v3 2/2] iio: light: opt3001: Add device tree binding documentation

[Jonathan Cameron]

On 20/07/15 19:22, Andreas Dannenberg wrote:
> Hi Jon,
> 
> On 07/19/2015 08:17 AM, Jonathan Cameron wrote:
>> On 05/07/15 15:09, Jonathan Cameron wrote:
>>> On 02/07/15 23:27, Andreas Dannenberg wrote:
 Signed-off-by: Andreas Dannenberg 
>>> Utterly standard binding so unless someone shouts, I'll pick this
>>> up with the driver.
>> Applied to the togreg branch of iio.git - initially pushed
>> out as testing for the autobuilders to play with it.
> 
> Thanks. Found it on the 'testing' branch, pulled the entire branch,
> and successfully re-ran all my HW tests without any findings.
> 
> Regards,
> Andreas
That's an impressive level of dedication!

Thanks

Jonathan


--
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/2] iio: light: add APDS9960 ALS + promixity driver

[Jonathan Cameron]

On 20/07/15 01:07, Matt Ranostay wrote:
> On Sun, Jul 19, 2015 at 3:45 AM, Jonathan Cameron  wrote:
>> On 13/07/15 03:20, Matt Ranostay wrote:
>>> APDS9960 is a combination of ALS, proximity, and gesture sensors.
>>>
>>> This patch adds support for these functions along with gain control,
>>> integration time, and event thresholds.
>>>
>>> Signed-off-by: Matt Ranostay 
>> Mostly looking good.  You don't need to repeat standard docs and there
>> are a few bits and pieces inline.
>>
>> Jonathan
>>> ---
>>>  .../ABI/testing/sysfs-bus-iio-light-apds9960   |  128 +++
>>>  drivers/iio/light/Kconfig  |   12 +
>>>  drivers/iio/light/Makefile |1 +
>>>  drivers/iio/light/apds9960.c   | 1208 
>>> 
>>>  4 files changed, 1349 insertions(+)
>>>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-light-apds9960
>>>  create mode 100644 drivers/iio/light/apds9960.c
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-light-apds9960 
>>> b/Documentation/ABI/testing/sysfs-bus-iio-light-apds9960
>>> new file mode 100644
>>> index 000..010b8c8
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-bus-iio-light-apds9960
>>> @@ -0,0 +1,128 @@
>> As a general rule, don't document any attributes covered by more generic
>> docs.  Just leads to more ways to have out of date documentation!
>>> +What:/sys/bus/iio/devices/triggerX/name = 
>>> "apds9960-gestureX"
>>> +KernelVersion:   4.2
>>> +Contact: Matt Ranostay 
>>> +Description:
>>> + The APDS9960 kernel module provides a trigger which enables
>>> + the gesture engine that pushes motion data to the buffer when
>>> + it becomes available.
>>> +
>>> +What /sys/bus/iio/devices/iio:deviceX/in_proximity0_raw
>>> +Date:July 2015
>>> +KernelVersion:   4.2
>>> +Contact: Matt Ranostay 
>>> +Description:
>>> + Get the non-gesture proximity sensor value.
>> Looks like the generic docs need a wild card indexed version of these added
>> (curriously the 0 index channel is there which makes no sense without 
>> allowing
>> for higher indexes).
>>> +
>>> +What /sys/bus/iio/devices/iio:deviceX/in_proximity1_raw
>>> +Date:July 2015
>>> +KernelVersion:   4.2
>>> +Contact: Matt Ranostay 
>>> +Description:
>>> + Get the UP gesture photodiode proximity value.
>>> + Access is disabled to prevent the side effect of
>>> + userspace clearing the hardware FIFO.
>>> +
>>> +What /sys/bus/iio/devices/iio:deviceX/in_proximity2_raw
>>> +Date:July 2015
>>> +KernelVersion:   4.2
>>> +Contact: Matt Ranostay 
>>> +Description:
>>> + Get the DOWN gesture photodiode proximity value.
>>> + Access is disabled to prevent the side effect of
>>> + userspace clearing the hardware FIFO.
>>> +
>>> +What /sys/bus/iio/devices/iio:deviceX/in_proximity3_raw
>>> +Date:July 2015
>>> +KernelVersion:   4.2
>>> +Contact: Matt Ranostay 
>>> +Description:
>>> + Get the LEFT gesture photodiode proximity value.
>>> + Access is disabled to prevent the side effect of
>>> + userspace clearing the hardware FIFO.
>>> +
>>> +What /sys/bus/iio/devices/iio:deviceX/in_proximity4_raw
>>> +Date:July 2015
>>> +KernelVersion:   4.2
>>> +Contact: Matt Ranostay 
>>> +Description:
>>> + Get the RIGHT gesture photodiode proximity value.
>>> + Access is disabled to prevent the side effect of
>>> + userspace clearing the hardware FIFO.
>>> +
>>> +What /sys/bus/iio/devices/iio:deviceX/in_intensity_clear_raw
>>> +Date:July 2015
>>> +KernelVersion:   4.2
>>> +Contact: Matt Ranostay 
>>> +Description:
>>> + Get the current unprocessed illuminance for the clear/ALS
>>> + photodiode.
>>> +
>>> +What /sys/bus/iio/devices/iio:deviceX/in_intensity_red_raw
>>> +Date:July 2015
>>> +KernelVersion:   4.2
>>> +Contact: Matt Ranostay 
>>> +Description:
>>> + Get the current unprocessed illuminance value for the
>>> + red light wavelength photodiode.
>>> +
>>> +What /sys/bus/iio/devices/iio:deviceX/in_intensity_green_raw
>>> +Date:July 2015
>>> +KernelVersion:   4.2
>>> +Contact: Matt Ranostay 
>>> +Description:
>>> + Get the current unprocessed illuminance value for the
>>> + green light wavelength photodiode.
>>> +
>>> +What /sys/bus/iio/devices/iio:deviceX/in_intensity_blue_raw
>>> +Date:July 2015
>>> +KernelVersion:   4.2
>>> +Contact: Matt Ranostay 
>>> +Description:
>>> + Get the current unprocessed illuminance value for the
>>> + blue light wavelength photod

Re: [PATCH v3 2/2] iio: light: add APDS9960 ALS + promixity driver

[Jonathan Cameron]

>>> +static int apds9960_read_raw(struct iio_dev *indio_dev,
>>> +  struct iio_chan_spec const *chan,
>>> +  int *val, int *val2, long mask)
>>> +{
>>> + struct apds9960_data *data = iio_priv(indio_dev);
>>> + u16 buf;
>>> + int ret = -EINVAL;
>>> +
>>> + if (data->gesture_mode_running)
>>> + return -EBUSY;
>>> +
>>> + switch (mask) {
>>> + case IIO_CHAN_INFO_RAW:
>>> + apds9960_set_power_state(data, true);
>>> + switch (chan->type) {
>>> + case IIO_PROXIMITY:
>>> + if (chan->scan_index == -1) {
>>> + ret = regmap_read(data->regmap,
>>> +   chan->address, val);
>>> + if (!ret)
>>> + ret = IIO_VAL_INT;
>>> + } else {
>> If the channels don't have explicity channel mask entries for a polled
>> read then there will be no way of reading them anyway except through the
>> buffered interface.
> 
> What context do you mean by channel mask entries?
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW)  - or the processed variant.
> 
>>> + /*
>>> +  * Cannot poll the GESTURE channels which are
>>> +  * just usable with triggered buffers.
>>> +  */
>>> + ret = -EBUSY;
>>> + }
>>> + break;


--
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] backlight: pm8941-wled: Add default-brightness property

[Bjorn Andersson]

Add the possibility of specifying the default brightness in DT.

Signed-off-by: Bjorn Andersson 
---

This depends on the patch moving pm8941-wled to backlight [1]. The dt property
is used by several other backlight drivers, so I considered this to be a
"common" property and it's hence not prefixed with "qcom,".

[1] https://lkml.org/lkml/2015/7/21/906

 Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt | 1 +
 drivers/video/backlight/pm8941-wled.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt 
b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
index 424f8444a6cd..37503f8c3620 100644
--- a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
+++ b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
@@ -5,6 +5,7 @@ Required properties:
 - reg: slave address
 
 Optional properties:
+- default-brightness: value from: 0-4095
 - label: The name of the backlight device
 - qcom,cs-out: bool; enable current sink output
 - qcom,cabc: bool; enable content adaptive backlight control
diff --git a/drivers/video/backlight/pm8941-wled.c 
b/drivers/video/backlight/pm8941-wled.c
index c704c3236034..b875e58df0fc 100644
--- a/drivers/video/backlight/pm8941-wled.c
+++ b/drivers/video/backlight/pm8941-wled.c
@@ -373,6 +373,7 @@ static int pm8941_wled_probe(struct platform_device *pdev)
struct backlight_device *bl;
struct pm8941_wled *wled;
struct regmap *regmap;
+   u32 val = 0;
int rc;
 
regmap = dev_get_regmap(pdev->dev.parent, NULL);
@@ -395,8 +396,11 @@ static int pm8941_wled_probe(struct platform_device *pdev)
if (rc)
return rc;
 
+   of_property_read_u32(pdev->dev.of_node, "default-brightness", &val);
+
memset(&props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
+   props.brightness = val;
props.max_brightness = PM8941_WLED_REG_VAL_MAX;
bl = devm_backlight_device_register(&pdev->dev, wled->name,
&pdev->dev, wled,
-- 
1.8.2.2

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

Re: [PATCH v7 1/2] mfd: devicetree: add bindings for Atmel Flexcom

[Boris Brezillon]

On Thu, 23 Jul 2015 18:42:55 +0200
Cyrille Pitchen  wrote:

> This patch documents the DT bindings for the Atmel Flexcom which will be
> introduced by sama5d2x SoCs. These bindings will be used by the actual
> Flexcom driver to be sent in another patch.
> 
> Signed-off-by: Cyrille Pitchen 
> ---
>  .../devicetree/bindings/mfd/atmel-flexcom.txt  | 68 
> ++
>  1 file changed, 68 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt 
> b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
> new file mode 100644
> index ..a63226b7a9cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
> @@ -0,0 +1,68 @@
> +* Device tree bindings for Atmel Flexcom (Flexible Serial Communication Unit)
> +
> +The Atmel Flexcom is just a wrapper which embeds a SPI controller, an I2C
> +controller and an USART. Only one function can be used at a time and is 
> chosen
> +at boot time according to the device tree.
> +
> +Required properties:
> +- compatible:Should be "atmel,sama5d2-flexcom"
> +- reg:   Should be the pair (offset, size) for the 
> Flexcom
> + dedicated I/O registers (without USART, TWI or SPI
> + registers).
> +- clocks:Should be the Flexcom peripheral clock from PMC.
> +- #address-cells:Should be <2>
> +- #size-cells:   Should be <1>
> +- ranges:Should be a list of ranges.
> + One range per peripheral wrapped by the Flexcom. So each
> + range is a triplet (child_addr, parent_addr, size). The
> + first u32 of "child_addr" is the value to be set in the
> + Operating Mode bitfield of the Flexcom Mode Register.
> + Then "parent_addr" stores the base address of the
> + corresponding peripheral in the system memory. Finally,
> + "size" if the size of the memory region of this
> + peripheral.
> +
> +Required child:
> +A single available child for the serial controller to enable.
> +
> +Required properties of this child:
> +- reg:   Should be a pair (child_addr, size) with 
> child_addr
> + matching one of the parent ranges.
> +- clocks:Should be the very same phandle as for the parent's one.
> +
> +Other properties remain unchanged. See documentation of the respective 
> device:
> +- ../serial/atmel-usart.txt
> +- ../spi/spi_atmel.txt
> +- ../i2c/i2c-at91.txt
> +
> +Example:
> +
> +flexcom@f8034000 {
> + compatible = "atmel,sama5d2-flexcom";
> + reg = <0xf8034000 0x200>;
> + clocks = <&flx0_clk>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <1 0 0xf8034200 0x200  /* opmode 1: USART */
> +   2 0 0xf8034400 0x200  /* opmode 2: SPI */
> +   3 0 0xf8034600 0x200>;/* opmode 3: I2C */
> +
> + spi@f8034400 {

Should be:

spi@2,0 {

> + compatible = "atmel,at91rm9200-spi";
> + reg = <2 0 0x200>;
> + interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flx0_default>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&flx0_clk>;
> + clock-names = "spi_clk";
> + atmel,fifo-size = <32>;
> +
> + mtd_dataflash@0 {
> + compatible = "atmel,at25f512b";
> + reg = <0>;
> + spi-max-frequency = <2000>;
> + };
> + };
> +};



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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][v3] ARM: imx: pinctrl-imx: imx7d: add support for iomuxc lpsr

[Alonso Adrian]

Hi Shawn,

The approach you mention is already supported in FSL kernel tree see
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.14.38_6ul7d_beta&id=a37ea06ddccbefb8660af0ac259c30d98540bdc2

I will rework and proposed a new patch series soon.

Thanks for your reviews :)

Regards
Adrian

> -Original Message-
> From: linux-gpio-ow...@vger.kernel.org [mailto:linux-gpio-
> ow...@vger.kernel.org] On Behalf Of Shawn Guo
> Sent: Thursday, July 16, 2015 10:34 PM
> To: Alonso Lazcano Adrian-B38018
> Cc: Zhi Li; devicetree@vger.kernel.org; Li Frank-B20596; Garg Nitin-B37173;
> linus.wall...@linaro.org; linux-g...@vger.kernel.org; robh...@kernel.org;
> shawn@linaro.org; Huang Yongcai-B20788; linux-arm-
> ker...@lists.infradead.org; Gong Yibin-B38343
> Subject: Re: [PATCH][v3] ARM: imx: pinctrl-imx: imx7d: add support for iomuxc
> lpsr
> 
> On Thu, Jul 16, 2015 at 08:39:33PM +, Alonso Adrian wrote:
> > Hi All,
> >
> > I will sent a new patch series including documentation for pad group
> > id encoding in
> > Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
> >
> > Thanks for your comments :)
> 
> Do not get me wrong.  The problem with the patch is not merely missing the
> document update.
> 
> Shawn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the 
> body
> of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] Docs: dt: add generic MSI bindings

[David Daney]

On 07/23/2015 09:52 AM, Mark Rutland wrote:
[...]

+MSI clients
+===
+
+MSI clients are devices which generate MSIs. For each MSI they wish to
+generate, the doorbell and payload may be configured, though sideband
+information may not be configurable.
+
+Required properties:
+
+
+- msi-parent: A list of phandle + msi-specifier pairs, one for each MSI
+  controller which the device is capable of using.
+


We say here that "msi-parent" consists of pairs ...


+  This property is unordered, and MSIs may be allocated from any combination of
+  MSI controllers listed in the msi-parent property.
+
+  If a device has restrictions on the allocation of MSIs, these restrictions
+  must be described with additional properties.
+
+  When #msi-cells is non-zero, busses with an msi-parent will require
+  additional properties to describe the relationship between devices on the bus
+  and the set of MSIs they can potentially generate.
+
+
+Example
+===
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   msi_a: msi-controller@a {
+   reg = <0xa 0xf00>;
+   compatible = "vendor-a,some-controller";
+   msi-controller;
+   /* No sideband data, so #msi-cells omitted */
+   };
+
+   msi_b: msi-controller@b {
+   reg = <0xb 0xf00>;
+   compatible = "vendor-b,another-controller";
+   msi-controller;
+   /* Each device has some unique ID */
+   #msi-cells = <1>;
+   };
+
+   msi_c: msi-controller@c {
+   reg = <0xb 0xf00>;
+   compatible = "vendor-b,another-controller";
+   msi-controller;
+   /* Each device has some unique ID */
+   #msi-cells = <1>;
+   };
+
+   dev@0 {
+   reg = <0x0 0xf00>;
+   compatible = "vendor-c,some-device";
+
+   /* Can only generate MSIs to msi_a */
+   msi-parent = <&msi_a>;



My device-tree syntax foo is a little rusty, but doesn't "msi-parent" 
need a pair of elements?  This has only the phandle.



+   };
+
+   dev@1 {
+   reg = <0x1 0xf00>;
+   compatible = "vendor-c,some-device";
+
+   /*
+* Can generate MSIs to either A or B.
+*/
+   msi-parent = <&msi_a>, <&msi_b 0x17>;



... same here, ...


+   };
+
+   dev@2 {
+   reg = <0x2 0xf00>;
+   compatible = "vendor-c,some-device";
+   /*
+* Has different IDs at each MSI controller.
+* Can generate MSIs to all of the MSI controllers.
+*/
+   msi-parent = <&msi_a>, <&msi_b 0x17>, <&msi_c 0x53>;


... and here


+   };
+};


--
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/2] Add mt6795 basic chip support

[Matthias Brugger]

On Tuesday, July 14, 2015 02:58:11 PM Mars Cheng wrote:
> This patch adds basic chip support for Mediatek 8-core chip, mt6795.
> It is also named as Helio X10. It is based on:
> 1. 4.2-rc1
> 2. [PATCH v4 0/2] Add mt6580 basic chip support
> 
> The second one has added some device tree binding documentation for
> mt6580. mt6795 has some device tree binding modifications too.
> To cleanly apply this patch, please apply mt6580 patch set first.
> 
> Changes in v2
> 1. Remove clocks node & bootargs
> 2. Refine stdout-path setting
> 3. Use correct mask value in device tree for arm local timer
> 
> Mars Cheng (2):
>   Document: DT: Add bindings for mediatek MT6795 SoC Platform
>   arm64: dts: mediatek: add mt6795 support
> 
>  Documentation/devicetree/bindings/arm/mediatek.txt |   9 +-
>  .../bindings/arm/mediatek/mediatek,sysirq.txt  |   3 +-
>  .../devicetree/bindings/serial/mtk-uart.txt|   5 +-
>  arch/arm64/boot/dts/mediatek/Makefile  |   1 +
>  arch/arm64/boot/dts/mediatek/mt6795-evb.dts|  37 +
>  arch/arm64/boot/dts/mediatek/mt6795.dtsi   | 162
> + 6 files changed, 212 insertions(+), 5 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt6795-evb.dts
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt6795.dtsi

Your series is not based on v4.2-rc1, anyway I fixed it and applied to v4.2-
next/arm64

Thanks.
--
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] ARM/PCI: remove align_resource in pci_sys_data

[Lorenzo Pieralisi]

[CC'ing Thomas and Jason for pci-mvebu]

On Tue, Jul 21, 2015 at 07:48:39AM +0100, Zhou Wang wrote:
> This patch is needed in order to unify the PCIe designware framework for ARM 
> and
> ARM64 architectures. In the PCIe designware unification process we are calling
> pci_create_root_bus() passing a "sysdata" parameter that is the same for both
> ARM and ARM64 and is of type "struct pcie_port*". In the ARM case this will
> cause a problem with the function pcibios_align_resource(); in fact this will
> cast "dev->sysdata" to "struct pci_sys_data*", whereas designware had passed a
> "struct pcie_port*" pointer.
> 
> This patch solves the issue by removing "align_resource" from "pci_sys_data"
> struct and defining a static global function pointer in "bios32.c"
> 
> Signed-off-by: Gabriele Paoloni 
> Signed-off-by: Zhou Wang 

Arnd, Rob any opinion on this ? It is really the last blocking bit
to having common ARM/ARM64 drivers (and get rid of pci_sys_data) so I
would like to get this sorted asap (having a global function pointer
might be a temporary solution before moving it to the host bridge
structure).

Comments welcome.

Thanks !
Lorenzo

> ---
>  arch/arm/include/asm/mach/pci.h |  5 -
>  arch/arm/kernel/bios32.c| 12 
>  2 files changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
> index 28b9bb3..8a4e4de 100644
> --- a/arch/arm/include/asm/mach/pci.h
> +++ b/arch/arm/include/asm/mach/pci.h
> @@ -58,11 +58,6 @@ struct pci_sys_data {
>   /* IRQ mapping  
> */
>   int (*map_irq)(const struct pci_dev *, u8, u8);
>   /* Resource alignement requirements 
> */
> - resource_size_t (*align_resource)(struct pci_dev *dev,
> -   const struct resource *res,
> -   resource_size_t start,
> -   resource_size_t size,
> -   resource_size_t align);
>   void*private_data;  /* platform controller private data 
> */
>  };
>  
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index fc1..4cdc64d 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -17,6 +17,11 @@
>  #include 
>  
>  static int debug_pci;
> +static resource_size_t (*align_resource)(struct pci_dev *dev,
> +   const struct resource *res,
> +   resource_size_t start,
> +   resource_size_t size,
> +   resource_size_t align) = NULL;
>  
>  #ifdef CONFIG_PCI_MSI
>  struct msi_controller *pcibios_msi_controller(struct pci_dev *dev)
> @@ -468,7 +473,7 @@ static void pcibios_init_hw(struct device *parent, struct 
> hw_pci *hw,
>   sys->busnr   = busnr;
>   sys->swizzle = hw->swizzle;
>   sys->map_irq = hw->map_irq;
> - sys->align_resource = hw->align_resource;
> + align_resource = hw->align_resource;
>   INIT_LIST_HEAD(&sys->resources);
>  
>   if (hw->private_data)
> @@ -589,7 +594,6 @@ resource_size_t pcibios_align_resource(void *data, const 
> struct resource *res,
>   resource_size_t size, resource_size_t align)
>  {
>   struct pci_dev *dev = data;
> - struct pci_sys_data *sys = dev->sysdata;
>   resource_size_t start = res->start;
>  
>   if (res->flags & IORESOURCE_IO && start & 0x300)
> @@ -597,8 +601,8 @@ resource_size_t pcibios_align_resource(void *data, const 
> struct resource *res,
>  
>   start = (start + align - 1) & ~(align - 1);
>  
> - if (sys->align_resource)
> - return sys->align_resource(dev, res, start, size, align);
> + if (align_resource)
> + return align_resource(dev, res, start, size, align);
>  
>   return start;
>  }
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] mailbox: Add support for ST's Mailbox IP

[Jassi Brar]

On Thu, Jul 23, 2015 at 1:59 PM, Lee Jones  wrote:
>> On Fri, Jul 17, 2015 at 5:34 PM, Lee Jones  wrote:

>> > +static void sti_mbox_enable_channel(struct mbox_chan *chan)
>> > +{
>> > +   struct sti_channel *chan_info = chan->con_priv;
>> > +   struct sti_mbox_device *mdev = chan_info->mdev;
>> > +   struct sti_mbox_pdata *pdata = dev_get_platdata(mdev->dev);
>> > +   unsigned int instance = chan_info->instance;
>> > +   unsigned int channel = chan_info->channel;
>> > +   unsigned long flags;
>> > +   void __iomem *base;
>> > +
>> > +   base = mdev->base + (instance * sizeof(u32));
>> > +
>> Maybe have something simpler like MBOX_BASE(instance)? Or some inline
>> function to avoid this 5-lines ritual?
>
> I've checked and we can't do this, as the we need most (all?) of the
> intermediary variables too.  No ritual just to get the final variable
> for instance.
>
OK. How about ?
  #define MBOX_BASE(m, n)   ((m)->base + (n) * 4)
  void __iomem *base = MBOX_BASE(mdev, instance);


>> > +   spin_lock_irqsave(&sti_mbox_chan_lock, flags);
>> > +   mdev->enabled[instance] |= BIT(channel);
>> > +   writel_relaxed(BIT(channel), base + pdata->ena_set);
>> > +   spin_unlock_irqrestore(&sti_mbox_chan_lock, flags);
>> >
>> You don't need locking for SET/CLR type registers which are meant for
>> when they could be accessed by processors that can not share a lock.
>> So maybe drop the lock here and elsewhere.
>
> From what I can gather, I think we need this locking.  What happens if
> we get scheduled between setting the enabled bit in our cache and
> actually setting the ena_set bit?  We would be out of sync.
>
IIU what you mean... can't that still happen because of the  _relaxed()?
Anyways my point was about set/clr type regs. And you may look at if
channel really needs disabling while interrupts are handled? I think
it shouldn't because either it is going to be a to-fro communication
or random broadcasts without any guarantee of reception. But of course
you would know better your platform.
BTW  sti_mbox_channel_is_enabled() also needs to have locking around
enabled[] if you want to keep it.  And maybe embed sti_mbox_chan_lock
inside sti_mbox_device.

>> However, you need some mechanism to check if you succeeded 'owning'
>> the channel by reading back what you write to own the channel (not
>> sure which is that register here). Usually we need that action and
>> verification when we assign a channel to some user.
>
> I don't think we need to do that with this driver.  All of the
> allocation is controlled from within this code base.  The channels are
> pre-allocated and written into the co-proc's Firmware.
>
OK

>> > +   }
>> > +
>> Doesn't mbox->chans[i].con_priv need some locking here?
>
> Not that I can see.  Would you mind explaining further please?
>
Not anymore, after the clarification that we don't need a 'break' statement.

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

Re: [PATCH 3/6] mailbox: Add support for ST's Mailbox IP

[Alexey Klimov]

Hi Lee,

On Fri, Jul 17, 2015 at 3:04 PM, Lee Jones  wrote:
> ST's platforms currently support a maximum of 5 Mailboxes, one for
> each of the supported co-processors situated on the platform.  Each
> Mailbox is divided up into 4 instances which consist of 32 channels.
> Messages are passed between the application and co-processors using
> shared memory areas.  It is the Client's responsibility to manage
> these areas.
>
> Signed-off-by: Lee Jones 
> ---
>  drivers/mailbox/Kconfig   |   7 +
>  drivers/mailbox/Makefile  |   2 +
>  drivers/mailbox/mailbox-sti.c | 562 
> ++
>  3 files changed, 571 insertions(+)
>  create mode 100644 drivers/mailbox/mailbox-sti.c

[..]

> +static irqreturn_t sti_mbox_thread_handler(int irq, void *data)
> +{
> +   struct sti_mbox_device *mdev = data;
> +   struct sti_mbox_pdata *pdata = dev_get_platdata(mdev->dev);
> +   struct mbox_chan *chan;
> +   unsigned int instance;
> +
> +   for (instance = 0; instance < pdata->num_inst; instance++) {
> +keep_looking:
> +   chan = sti_mbox_irq_to_channel(mdev, instance);
> +   if (!chan)
> +   continue;
> +
> +   mbox_chan_received_data(chan, NULL);
> +   sti_mbox_clear_irq(chan);
> +   sti_mbox_enable_channel(chan);
> +   goto keep_looking;
> +   }
> +
> +   return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t sti_mbox_irq_handler(int irq, void *data)
> +{
> +   struct sti_mbox_device *mdev = data;
> +   struct sti_mbox_pdata *pdata = dev_get_platdata(mdev->dev);
> +   struct sti_channel *chan_info;
> +   struct mbox_chan *chan;
> +   unsigned int instance;
> +   int ret = IRQ_NONE;
> +
> +   for (instance = 0; instance < pdata->num_inst; instance++) {
> +   chan = sti_mbox_irq_to_channel(mdev, instance);
> +   if (!chan)
> +   continue;
> +   chan_info = chan->con_priv;
> +
> +   if (!sti_mbox_channel_is_enabled(chan)) {
> +   dev_warn(mdev->dev,
> +"Unexpected IRQ: %s\n"
> +"  instance: %d: channel: %d [enabled: 
> %x]\n",
> +mdev->name, chan_info->instance,
> +chan_info->channel, mdev->enabled[instance]);
> +   ret = IRQ_HANDLED;
> +   continue;
> +   }
> +
> +   sti_mbox_disable_channel(chan);
> +   ret = IRQ_WAKE_THREAD;
> +   }
> +
> +   if (ret == IRQ_NONE)
> +   dev_err(mdev->dev, "Spurious IRQ - was a channel 
> requested?\n");
> +
> +   return ret;
> +}

With such usage of ret variable can it happen that handling of last
but one channel/instance will set ret to IRQ_WAKE_THREAD and at the
same time handling of last channel/instance will set ret to
IRQ_HANDLED during iteration loop and finally generic subsystem will
not wake up thread handler because it will receive IRQ_HANDLED?
Just checking.


[..]

-- 
Thanks,
Alexey Klimov
--
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 05/11] mfd: devicetree: bindings: Add Qualcomm SMD based RPM DT binding

[Mark Brown]

On Thu, Jul 23, 2015 at 09:41:28AM -0700, Bjorn Andersson wrote:

> > We still need Mark to look at this.

> Mark, would you mind giving us a statement on the regulator subnode of
> this binding?

I have no idea what's going on here, sorry.  I've not been reading this
thread.


signature.asc
Description: Digital signature

[PATCH 3/3] Docs: dt: add PCI IOMMU map bindings

[Mark Rutland]

The existing IOMMU bindings are able to specify the relationship between
masters and IOMMUs, but they are insufficient for describing the general
case of hotpluggable busses such as PCI where the set of masters is not
known until runtime, and the relationship between masters and IOMMUs is
a property of the integration of the system.

This patch adds a generic binding for mapping PCI devices to IOMMUs,
using a new iommu-map property (specific to PCI*) which may be used to
map devices (identified by their Requester ID) to sideband data for the
IOMMU which they master through.

Signed-off-by: Mark Rutland 
---
 .../devicetree/bindings/pci/pci-iommu.txt  | 171 +
 1 file changed, 171 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt

diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt 
b/Documentation/devicetree/bindings/pci/pci-iommu.txt
new file mode 100644
index 000..56c8296
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pci-iommu.txt
@@ -0,0 +1,171 @@
+This document describes the generic device tree binding for describing the
+relationship between PCI(e) devices and IOMMU(s).
+
+Each PCI(e) device under a root complex is uniquely identified by its Requester
+ID (AKA RID). A Requester ID is a triplet of a Bus number, Device number, and
+Function number.
+
+For the purpose of this document, when treated as a numeric value, a RID is
+formatted such that:
+
+* Bits [15:8] are the Bus number.
+* Bits [7:3] are the Device number.
+* Bits [2:0] are the Function number.
+* Any other bits required for padding must be zero.
+
+IOMMUs may distinguish PCI devices through sideband data derived from the
+Requester ID. While a given PCI device can only master through one IOMMU, a
+root complex may split masters across a set of IOMMUs (e.g. with one IOMMU per
+bus).
+
+The generic 'iommus' property is insufficient to describe this relationship,
+and a mechanism is required to map from a PCI device to its IOMMU and sideband
+data.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+
+PCI root complex
+
+
+Optional properties
+---
+
+- iommu-map: Maps a Requester ID to an IOMMU and associated iommu-specifier
+  data.
+
+  The property is an arbitrary number of tuples of
+  (rid-base,iommu,iommu-base,length).
+
+  Any RID r in the interval [rid-base, rid-base + length) is associated with
+  the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
+
+- iommu-map-mask: A mask to be applied to each Requester ID prior to being
+  mapped to an iommu-specifier per the iommu-map property.
+
+
+Example (1)
+===
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   iommu: iommu@a {
+   reg = <0xa 0x1>;
+   compatible = "vendor,some-iommu";
+   #iommu-cells = <1>;
+   };
+
+   pci: pci@f {
+   reg = <0xf 0x1>;
+   compatible = "vendor,pcie-root-complex";
+   device_type = "pci";
+
+   /*
+* The sideband data provided to the IOMMU is the RID,
+* identity-mapped.
+*/
+   iommu-map = <0x0 &iommu 0x0 0x1>;
+   };
+};
+
+
+Example (2)
+===
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   iommu: iommu@a {
+   reg = <0xa 0x1>;
+   compatible = "vendor,some-iommu";
+   #iommu-cells = <1>;
+   };
+
+   pci: pci@f {
+   reg = <0xf 0x1>;
+   compatible = "vendor,pcie-root-complex";
+   device_type = "pci";
+
+   /*
+* The sideband data provided to the IOMMU is the RID with the
+* function bits masked out.
+*/
+   iommu-map = <0x0 &iommu 0x0 0x1>;
+   iommu-map-mask = <0xfff8>;
+   };
+};
+
+
+Example (3)
+===
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   iommu: iommu@a {
+   reg = <0xa 0x1>;
+   compatible = "vendor,some-iommu";
+   #iommu-cells = <1>;
+   };
+
+   pci: pci@f {
+   reg = <0xf 0x1>;
+   compatible = "vendor,pcie-root-complex";
+   device_type = "pci";
+
+   /*
+* The sideband data provided to the IOMMU is the RID,
+* but the high bits of the bus number are flipped.
+*/
+   iommu-map = <0x &iommu 0x8000 0x8000>,
+   <0x8000 &iommu 0x 0x8000>;
+   };
+};
+
+
+Example (4)
+===
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   iommu_a: iommu@a {
+   reg = <0xa 0x1>;
+   compatible = "vendor,some-iommu";
+   #iommu-cells = <1>;
+   };
+
+   iommu_b: iommu@b {
+   reg = <

[PATCH 1/3] Docs: dt: add generic MSI bindings

[Mark Rutland]

Currently msi-parent is used in a couple of drivers despite being fairly
underspecified. This patch adds a generic binding for MSIs (including
the existing msi-parent property) enabling the description of platform
devices capable of using MSIs.

While MSIs are primarily distinguished by doorbell and payload, some MSI
controllers (e.g. the GICv3 ITS) also use side-band information
accompanying the write to identify the master which originated the MSI,
to allow for sandboxing. This sideband information is non-probeable and
needs to be described in the DT. Other MSI controllers may have
additional configuration details which need to be described per-master.

This patch adds a generic msi-parent binding document, extending the
de-facto standard with a new (optional) #msi-cells which can be used to
express any per-master configuration and/or sideband data. This is
sufficient to describe non-hotpluggable devices.

For busses where sideband data may be derived from some bus-specific
master ID scheme, other properties will be required to describe the
mapping.

Signed-off-by: Mark Rutland 
---
 .../bindings/interrupt-controller/msi.txt  | 135 +
 1 file changed, 135 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/msi.txt

diff --git a/Documentation/devicetree/bindings/interrupt-controller/msi.txt 
b/Documentation/devicetree/bindings/interrupt-controller/msi.txt
new file mode 100644
index 000..c60c034
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/msi.txt
@@ -0,0 +1,135 @@
+This document describes the generic device tree binding for MSI controllers and
+their master(s).
+
+Message Signaled Interrupts (MSIs) are a class of interrupts generated by a
+write to an MMIO address.
+
+MSIs were originally specified by PCI (and are used with PCIe), but may also be
+used with other busses, and hence a mechanism is required to relate devices on
+those busses to the MSI controllers which they are capable of using,
+potentially including additional information.
+
+MSIs are distinguished by some combination of:
+
+- The doorbell (the MMIO address written to).
+  
+  Devices may be configured by software to write to arbitrary doorbells which
+  they can address. An MSI controller may feature a number of doorbells.
+
+- The payload (the value written to the doorbell).
+  
+  Devices may be configured to write an arbitrary payload chosen by software.
+  MSI controllers may have restrictions on permitted payloads.
+
+- Sideband information accompanying the write.
+  
+  Typically this is neither configurable nor probeable, and depends on the path
+  taken through the memory system (i.e. it is a property of the combination of
+  MSI controller and device rather than a property of either in isolation).
+
+
+MSI controllers:
+
+
+An MSI controller signals interrupts to a CPU when a write is made to an MMIO
+address by some master. An MSI controller may feature a number of doorbells.
+
+Required properties:
+
+
+- msi-controller: Identifies the node as an MSI controller.
+
+Optional properties:
+
+
+- #msi-cells: The number of cells in an msi-specifier, required if not zero.
+
+  Typically this will encode information related to sideband data, and will
+  not encode doorbells or payloads as these can be configured dynamically.
+
+  The meaning of the msi-specifier is defined by the device tree binding of
+  the specific MSI controller. 
+
+
+MSI clients
+===
+
+MSI clients are devices which generate MSIs. For each MSI they wish to
+generate, the doorbell and payload may be configured, though sideband
+information may not be configurable.
+
+Required properties:
+
+
+- msi-parent: A list of phandle + msi-specifier pairs, one for each MSI
+  controller which the device is capable of using.
+
+  This property is unordered, and MSIs may be allocated from any combination of
+  MSI controllers listed in the msi-parent property.
+
+  If a device has restrictions on the allocation of MSIs, these restrictions
+  must be described with additional properties.
+
+  When #msi-cells is non-zero, busses with an msi-parent will require
+  additional properties to describe the relationship between devices on the bus
+  and the set of MSIs they can potentially generate.
+
+
+Example
+===
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   msi_a: msi-controller@a {
+   reg = <0xa 0xf00>;
+   compatible = "vendor-a,some-controller";
+   msi-controller;
+   /* No sideband data, so #msi-cells omitted */
+   };
+
+   msi_b: msi-controller@b {
+   reg = <0xb 0xf00>;
+   compatible = "vendor-b,another-controller";
+   msi-controller;
+   /* Each device has some unique ID */
+   #msi-cells = <1>;
+   };
+
+   msi_c: msi-controller@c {

[PATCH 2/3] Docs: dt: Add PCI MSI map bindings

[Mark Rutland]

Currently msi-parent is used by a few bindings to describe the
relationship between a PCI root complex and a single MSI controller, but
this property does not have a generic binding document.

Additionally, msi-parent is insufficient to describe more complex
relationships between MSI controllers and devices under a root complex,
where devices may be able to target multiple MSI controllers, or where
MSI controllers use (non-probeable) sideband information to distinguish
devices.

This patch adds a generic binding for mapping PCI devices to MSI
controllers. This document covers msi-parent, and a new msi-map property
(specific to PCI*) which may be used to map devices (identified by their
Requester ID) to sideband data for each MSI controller that they may
target.

Signed-off-by: Mark Rutland 
---
 Documentation/devicetree/bindings/pci/pci-msi.txt | 220 ++
 1 file changed, 220 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt

diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt 
b/Documentation/devicetree/bindings/pci/pci-msi.txt
new file mode 100644
index 000..9b3cc81
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pci-msi.txt
@@ -0,0 +1,220 @@
+This document describes the generic device tree binding for describing the
+relationship between PCI devices and MSI controllers.
+
+Each PCI device under a root complex is uniquely identified by its Requester ID
+(AKA RID). A Requester ID is a triplet of a Bus number, Device number, and
+Function number.
+
+For the purpose of this document, when treated as a numeric value, a RID is
+formatted such that:
+
+* Bits [15:8] are the Bus number.
+* Bits [7:3] are the Device number.
+* Bits [2:0] are the Function number.
+* Any other bits required for padding must be zero.
+
+MSIs may be distinguished in part through the use of sideband data accompanying
+writes. In the case of PCI devices, this sideband data may be derived from the
+Requester ID. A mechanism is required to associate a device with both the MSI
+controllers it can address, and the sideband data that will be associated with
+its writes to those controllers.
+
+For generic MSI bindings, see
+Documentation/devicetree/bindings/interrupt-controller/msi.txt.
+
+
+PCI root complex
+
+
+Optional properties
+---
+
+- msi-map: Maps a Requester ID to an MSI controller and associated
+  msi-specifier data. The property is an arbitrary number of tuples of
+  (rid-base,msi-controller,msi-base,length), where:
+
+  * rid-base is a single cell describing the first RID matched by the entry.
+
+  * msi-controller is a single phandle to an MSI controller
+
+  * msi-base is an msi-specifier describing the msi-specifier produced for the
+first RID matched by the entry.
+
+  * length is a single cell describing how many consecutive RIDs are matched
+following the rid-base.
+
+  Any RID r in the interval [rid-base, rid-base + length) is associated with
+  the listed msi-controller, with the msi-specifier (r - rid-base + msi-base).
+
+- msi-map-mask: A mask to be applied to each Requester ID prior to being mapped
+  to an msi-specifier per the msi-map property.
+
+- msi-parent: Describes the MSI parent of the root complex itself. Where
+  the root complex and MSI controller do not pass sideband data with MSI
+  writes, this property may be used to describe the MSI controller(s)
+  used by PCI devices under the root complex, if defined as such in the
+  binding for the root complex.
+
+
+Example (1)
+===
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   msi: msi-controller@a {
+   reg = <0xa 0x1>;
+   compatible = "vendor,some-controller";
+   msi-controller;
+   #msi-cells = <1>;
+   };
+
+   pci: pci@f {
+   reg = <0xf 0x1>;
+   compatible = "vendor,pcie-root-complex";
+   device_type = "pci";
+
+   /*
+* The sideband data provided to the MSI controller is
+* the RID, identity-mapped.
+*/
+   msi-map = <0x0 &msi_a 0x0 0x1>,
+   };
+};
+
+
+Example (2)
+===
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   msi: msi-controller@a {
+   reg = <0xa 0x1>;
+   compatible = "vendor,some-controller";
+   msi-controller;
+   #msi-cells = <1>;
+   };
+
+   pci: pci@f {
+   reg = <0xf 0x1>;
+   compatible = "vendor,pcie-root-complex";
+   device_type = "pci";
+
+   /*
+* The sideband data provided to the MSI controller is
+* the RID, masked to only the device and function bits.
+*/
+   msi-map = <0x0 &msi_a 0x0 0x100>,
+   msi-map-mask = <0xff>
+   };
+};
+
+
+Example (3)
+===
+
+/ {
+   #address-cells = <

[PATCH 0/3] Generic PCI MSI + IOMMU topology bindings

[Mark Rutland]

Hi all,

Currently we have no generic/standard mechanisms for describing the
relationship between PCI root complexes and other components which may be
required to make them usable, specifically IOMMUs and MSI controllers.

There is an existing binding for IOMMUs, and there is a de-facto standard for
referring to MSI controllers, but the generic portion of these can only
describe a relationship with a root complex as opposed to a device under a root
complex. This falls apart where IOMMUs and MSI controllers may distinguish
individual devices based on non-probeable information.

This series adds a generic "glue" bindings for describing the relationship
between root complexes, IOMMUs, and MSI controllers. The existing de-facto
binding for MSI controllers is formalised, along with a (backwards compatible)
extension necessary for describing contemporary MSI controllers which make use
of (non-probeable) sideband data.

Thanks,
Mark.

Mark Rutland (3):
  Docs: dt: add generic MSI bindings
  Docs: dt: Add PCI MSI map bindings
  Docs: dt: add PCI IOMMU map bindings

 .../bindings/interrupt-controller/msi.txt  | 135 +
 .../devicetree/bindings/pci/pci-iommu.txt  | 171 
 Documentation/devicetree/bindings/pci/pci-msi.txt  | 220 +
 3 files changed, 526 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/msi.txt
 create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt
 create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt

-- 
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] ARM: dts: rockchip: Add veyron-speedy board

[Romain Perier]

Which is formally known as The Asus C201 chromebook

Signed-off-by: Romain Perier 
Reviewed-by: Doug Anderson 
---

Changes in v2:
 - Remove dvs-gpio (not used in mainline yet)
 - Remove edp subnode in pinctrl (not used in mainline yet)
 - Reordering disable-wp correctly

 Documentation/devicetree/bindings/arm/rockchip.txt |  10 +-
 arch/arm/boot/dts/Makefile |   3 +-
 arch/arm/boot/dts/rk3288-veyron-speedy.dts | 155 +
 3 files changed, 166 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/boot/dts/rk3288-veyron-speedy.dts

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt 
b/Documentation/devicetree/bindings/arm/rockchip.txt
index 6de18bd2..da02022 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -37,4 +37,12 @@ Rockchip platforms device tree bindings
 - Google Pinky (dev-board):
 Required root node properties:
   - compatible = "google,veyron-pinky-rev2", "google,veyron-pinky",
-"google,veyron", "rockchip,rk3288";
\ No newline at end of file
+"google,veyron", "rockchip,rk3288";
+
+- Google Speedy (Asus C201 Chromebook):
+Required root node properties:
+  - compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
+"google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
+"google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
+"google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
+"google,veyron-speedy", "google,veyron", "rockchip,rk3288";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4993b3b..bf5225a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -490,7 +490,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-firefly-beta.dtb \
rk3288-firefly.dtb \
rk3288-veyron-jerry.dtb \
-   rk3288-veyron-pinky.dtb
+   rk3288-veyron-pinky.dtb \
+   rk3288-veyron-speedy.dtb
 dtb-$(CONFIG_ARCH_S3C24XX) += \
s3c2416-smdk2416.dtb
 dtb-$(CONFIG_ARCH_S3C64XX) += \
diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts 
b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
new file mode 100644
index 000..fdb2a73
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
@@ -0,0 +1,155 @@
+/*
+ * Google Veyron Speedy Rev 1+ board device tree source
+ *
+ * Copyright 2015 Google, Inc
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ *  Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "rk3288-veyron-chromebook.dtsi"
+#include "cros-ec-sbs.dtsi"
+
+/ {
+   model = "Google Speedy";
+   compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
+"google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
+"google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
+"google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
+"google,veyron-speedy", "google,veyron", "rockchip,rk3288";
+
+

[PATCH v7 0/2] mfd: flexcom: add a driver for Flexcom

[Cyrille Pitchen]

ChangeLog

v7:
- read the operating mode from the very first u32 of the reg property from
  the first available child node (should be unique).
- update the DT bindings documentation accordingly.

v6:
- select the operating mode according to the "compatible" DT property of
  the first available child node (should be unique).
- remove the "atmel,flexcom-mode" DT property so the need of a header file
  defining macros for the possible values of this deprecated property.

v5:
- create a header file containing macros used by DT bindings
- use numeric constants instead of strings to select the Flexcom mode
- change the license to "GPL v2"
- update the DT binding documentation to make it more readable and add
  references to USART, SPI and I2C DT binding documentations. remove the
  useless label in the Example section.
- change the register prefix from FX_ to FLEX_ to match the Flexcom
  programmer datasheet.
- rename some variables to make them more understandable.

v4:
- check clk_prepare_enable() return code in atmel_flexcom_probe()
- add a commit message to the DT binding patch

v3:
- remove MODULE_ALIAS()
- add Acked-by from Boris Brezillon and Alexandre Belloni

v2:
- enhance the documentation of DT bindings and change the way the "ranges"
  property is used.
- replace __raw_readl() and __raw_writel() by readl() and writel().
- change the module license to "GPL" for v2 or later
- print the selected flexcom mode after the hardware version

v1:
This series of patches a support to the Atmel Flexcom, a wrapper which
integrates an USART, a SPI controller and a TWI controller. Only one
peripheral can be used at a time. The active function is selected though
the Flexcom Mode Register.

Cyrille Pitchen (2):
  mfd: devicetree: add bindings for Atmel Flexcom
  mfd: atmel-flexcom: add a driver for Atmel Flexible Serial
Communication Unit

 .../devicetree/bindings/mfd/atmel-flexcom.txt  |  68 +
 drivers/mfd/Kconfig|  11 ++
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/atmel-flexcom.c| 113 +
 4 files changed, 193 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
 create mode 100644 drivers/mfd/atmel-flexcom.c

-- 
1.8.2.2

--
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 v9 0/7] FPGA Manager Framework and Simple FPGA Bus

[atull]

On Thu, 23 Jul 2015, Greg KH wrote:

> On Fri, Jul 17, 2015 at 10:51:10AM -0500, at...@opensource.altera.com wrote:
> > From: Alan Tull 
> > 
> > This patchset adds two chunks plus documentation:
> >  * fpga manager core: exports ABI functions that write an image to a FPGA
> >  * DT Overlay support: simple-fpga-bus to handle FPGA from a DT overlay
> > 
> > The core's ABI is minimal to start with: only 6 functions.  This gives a
> > common interface for programming various FPGA such that any higher level
> > interfaces such as the DT Overlays or anything else that is added can be
> > shared and not be manufacturor-specific.
> > 
> > The DT Overlays support exists for the usage where the FPGA will contain
> > some "hardware" that will need drivers.  Where that use model is not
> > appealing, the core ABI can be used to add a different use model such as
> > using an FPGA as acceleration as has been discussed.
> > 
> > This patchset gets rid of the sysfs controls that allowed direct
> > control of a FPGA from userspace.
> > 
> > This patchset is under drivers/staging as the interface could change.
> > 
> > The bindings for the socpfga fpga manager already are upstreamed as
> > 1b4e119 Alan Tull : doc: add bindings document for altera fpga manager
> > 
> > The DT Support is dependent on Pantelis's dtc overlay patches from
> > https://github.com/pantoniou/dtc.git
> > and his DT overlays configfs interface patches and fixes from
> > https://github.com/pantoniou/linux-beagle-track-mainline
> > 
> > efb0c04 Pantelis Antoniou : gcl: Fix resource linking
> > 85e785e Pantelis Antoniou : ARM: DT: Enable symbols when CONFIG_OF_OVERLAY 
> > is used
> > af0321f Pantelis Antoniou : OF: DT-Overlay configfs interface (v5)
> > 4c1c675 Pantelis Antoniou : configfs: Implement binary attributes (v4)
> > 
> > 
> > Alan Tull (7):
> >   staging: usage documentation for FPGA manager core
> >   staging: usage documentation for simple fpga bus
> >   staging: add bindings document for simple fpga bus
> >   staging: fpga manager: add sysfs interface document
> >   staging: fpga manager core
> >   staging: add simple-fpga-bus
> >   staging: fpga manager: add driver for socfpga fpga manager
> > 
> >  drivers/staging/Kconfig|2 +
> >  drivers/staging/Makefile   |1 +
> >  .../Documentation/ABI/sysfs-class-fpga-manager |   26 +
> >  .../Documentation/bindings/simple-fpga-bus.txt |   61 ++
> >  drivers/staging/fpga/Documentation/fpga-mgr.txt|  117 
> >  .../staging/fpga/Documentation/simple-fpga-bus.txt |   48 ++
> >  drivers/staging/fpga/Kconfig   |   31 +
> >  drivers/staging/fpga/Makefile  |   10 +
> >  drivers/staging/fpga/fpga-mgr.c|  373 
> >  drivers/staging/fpga/simple-fpga-bus.c |  323 ++
> >  drivers/staging/fpga/socfpga.c |  616 
> > 
> 
> All drivers/staging/*/ directories need a TODO file that lists what
> needs to be done to it in order to get the code out of staging.  Please
> redo the series and add that.
> 
> >  include/linux/fpga/fpga-mgr.h  |  127 
> 
> This should be within drivers/staging/ all staging code should be
> self-contained.
> 
> Why isn't this going into the "real" part of the kernel?  Why staging?
> 

Hi Greg,

For v10 next week, I will likely break this into two patchsets, one for the
real kernel (drivers/fpga) and one for staging.

fpga-mgr.c can go into drivers/fpga since both Xilinx and Altera have
already been using this code.  It's not likely to change much.

The part that should go into staging is whatever interface is
controversial, that may change.  That's simple-fpga-bus.c and any
other interfaces that get added that use the functions exported by
fpga-mgr.c.  Maybe this 2nd patch set should be a RFC since it is still
dependent on some of Pantelis' stuff that's not in yet.

Alan Tull

> thanks,
> 
> greg k-h
> 
--
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/2] mfd: atmel-flexcom: add a driver for Atmel Flexible Serial Communication Unit

[Cyrille Pitchen]

This driver supports the new Atmel Flexcom. The Flexcom is a wrapper which
integrates one SPI controller, one I2C controller and one USART. Only one
function can be enabled at a time. This driver selects the function once
for all, when the Flexcom is probed, using the "reg" property of the first
(should be unique) available DT child node.

This driver has chosen to present the Flexcom to the system as a MFD so
the implementation is seamless for the existing Atmel SPI, I2C and USART
drivers.

Also the Flexcom embeds FIFOs: the latest patches of the SPI, I2C and
USART drivers take advantage of this new feature.

Signed-off-by: Cyrille Pitchen 
---
 drivers/mfd/Kconfig |  11 +
 drivers/mfd/Makefile|   1 +
 drivers/mfd/atmel-flexcom.c | 113 
 3 files changed, 125 insertions(+)
 create mode 100644 drivers/mfd/atmel-flexcom.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 653815950aa2..2c75472c679c 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -60,6 +60,17 @@ config MFD_AAT2870_CORE
  additional drivers must be enabled in order to use the
  functionality of the device.
 
+config MFD_ATMEL_FLEXCOM
+   tristate "Atmel Flexcom (Flexible Serial Communication Unit)"
+   select MFD_CORE
+   depends on OF
+   help
+ Select this to get support for Atmel Flexcom. This is a wrapper
+ which embeds a SPI controller, a I2C controller and a USART. Only
+ one function can be used at a time. The choice is done at boot time
+ by the probe function of this MFD driver according to a device tree
+ property.
+
 config MFD_ATMEL_HLCDC
tristate "Atmel HLCDC (High-end LCD Controller)"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index ea40e076cb61..0705eb2d873d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -160,6 +160,7 @@ obj-$(CONFIG_MFD_SPMI_PMIC) += qcom-spmi-pmic.o
 obj-$(CONFIG_TPS65911_COMPARATOR)  += tps65911-comparator.o
 obj-$(CONFIG_MFD_TPS65090) += tps65090.o
 obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
+obj-$(CONFIG_MFD_ATMEL_FLEXCOM)+= atmel-flexcom.o
 obj-$(CONFIG_MFD_ATMEL_HLCDC)  += atmel-hlcdc.o
 obj-$(CONFIG_MFD_INTEL_MSIC)   += intel_msic.o
 obj-$(CONFIG_MFD_PALMAS)   += palmas.o
diff --git a/drivers/mfd/atmel-flexcom.c b/drivers/mfd/atmel-flexcom.c
new file mode 100644
index ..0d06b70696b0
--- /dev/null
+++ b/drivers/mfd/atmel-flexcom.c
@@ -0,0 +1,113 @@
+/*
+ * Driver for Atmel Flexcom
+ *
+ * Copyright (C) 2015 Atmel Corporation
+ *
+ * Author: Cyrille Pitchen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* I/O register offsets */
+#define FLEX_MR0x0 /* Mode Register */
+#define FLEX_VERSION   0xfc/* Version Register */
+
+/* Mode Register bit fields */
+#define FLEX_MR_OPMODE_MASK0x3
+#define FLEX_MR_OPMODE_NO_COM  0x0
+#define FLEX_MR_OPMODE_USART   0x1
+#define FLEX_MR_OPMODE_SPI 0x2
+#define FLEX_MR_OPMODE_TWI 0x3
+
+
+static int atmel_flexcom_probe(struct platform_device *pdev)
+{
+   struct device_node *child, *np = pdev->dev.of_node;
+   struct clk *clk;
+   struct resource *res;
+   void __iomem *base;
+   u32 opmode;
+   int err;
+
+   child = of_get_next_available_child(np, NULL);
+   if (!child)
+   return -ENODEV;
+
+   /*
+* The Operating Mode is stored into the first u32 of the reg property
+* of the child.
+*/
+   err = of_property_read_u32_index(child, "reg", 0, &opmode);
+   of_node_put(child);
+   if (err)
+   return -EINVAL;
+
+   if ((opmode == FLEX_MR_OPMODE_NO_COM) ||
+   (opmode & ~FLEX_MR_OPMODE_MASK))
+   return -EINVAL;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(&pdev->dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
+
+   clk = devm_clk_get(&pdev->dev, NULL);
+   if (IS_ERR(clk))
+   return PTR_ERR(clk);
+
+   err = clk_prepare_enable(clk);
+   if (err)
+   return err;
+
+   /*
+* Set the Operating Mode in the Mode Register: only the selected device
+* is clocked. Hence, registers of

[PATCH v7 1/2] mfd: devicetree: add bindings for Atmel Flexcom

[Cyrille Pitchen]

This patch documents the DT bindings for the Atmel Flexcom which will be
introduced by sama5d2x SoCs. These bindings will be used by the actual
Flexcom driver to be sent in another patch.

Signed-off-by: Cyrille Pitchen 
---
 .../devicetree/bindings/mfd/atmel-flexcom.txt  | 68 ++
 1 file changed, 68 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt

diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt 
b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
new file mode 100644
index ..a63226b7a9cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
@@ -0,0 +1,68 @@
+* Device tree bindings for Atmel Flexcom (Flexible Serial Communication Unit)
+
+The Atmel Flexcom is just a wrapper which embeds a SPI controller, an I2C
+controller and an USART. Only one function can be used at a time and is chosen
+at boot time according to the device tree.
+
+Required properties:
+- compatible:  Should be "atmel,sama5d2-flexcom"
+- reg: Should be the pair (offset, size) for the Flexcom
+   dedicated I/O registers (without USART, TWI or SPI
+   registers).
+- clocks:  Should be the Flexcom peripheral clock from PMC.
+- #address-cells:  Should be <2>
+- #size-cells: Should be <1>
+- ranges:  Should be a list of ranges.
+   One range per peripheral wrapped by the Flexcom. So each
+   range is a triplet (child_addr, parent_addr, size). The
+   first u32 of "child_addr" is the value to be set in the
+   Operating Mode bitfield of the Flexcom Mode Register.
+   Then "parent_addr" stores the base address of the
+   corresponding peripheral in the system memory. Finally,
+   "size" if the size of the memory region of this
+   peripheral.
+
+Required child:
+A single available child for the serial controller to enable.
+
+Required properties of this child:
+- reg: Should be a pair (child_addr, size) with child_addr
+   matching one of the parent ranges.
+- clocks:  Should be the very same phandle as for the parent's one.
+
+Other properties remain unchanged. See documentation of the respective device:
+- ../serial/atmel-usart.txt
+- ../spi/spi_atmel.txt
+- ../i2c/i2c-at91.txt
+
+Example:
+
+flexcom@f8034000 {
+   compatible = "atmel,sama5d2-flexcom";
+   reg = <0xf8034000 0x200>;
+   clocks = <&flx0_clk>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <1 0 0xf8034200 0x200  /* opmode 1: USART */
+ 2 0 0xf8034400 0x200  /* opmode 2: SPI */
+ 3 0 0xf8034600 0x200>;/* opmode 3: I2C */
+
+   spi@f8034400 {
+   compatible = "atmel,at91rm9200-spi";
+   reg = <2 0 0x200>;
+   interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_flx0_default>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = <&flx0_clk>;
+   clock-names = "spi_clk";
+   atmel,fifo-size = <32>;
+
+   mtd_dataflash@0 {
+   compatible = "atmel,at25f512b";
+   reg = <0>;
+   spi-max-frequency = <2000>;
+   };
+   };
+};
-- 
1.8.2.2

--
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/2] mfd: atmel-flexcom: add a driver for Atmel Flexible Serial Communication Unit

[Cyrille Pitchen]

Hi all,

Le 23/07/2015 14:50, Boris Brezillon a écrit :
> On Thu, 23 Jul 2015 10:13:11 +0100
> Lee Jones  wrote:
> 
>> On Thu, 23 Jul 2015, Boris Brezillon wrote:
>>
>>> Hi Lee,
>>>
>>> On Thu, 23 Jul 2015 08:32:17 +0100
>>> Lee Jones  wrote:
>>>
 On Wed, 22 Jul 2015, Cyrille Pitchen wrote:
> + for_each_child_of_node(np, child) {
> + const char *compatible;
> + int cplen;
> +
> + if (!of_device_is_available(child))
> + continue;
> +
> + compatible = of_get_property(child, "compatible", &cplen);
> + if (!compatible || strlen(compatible) > cplen)
> + continue;
> +
> + if (strstr(compatible, "-usart")) {
> + opmode = FLEX_MR_OPMODE_USART;
> + break;
> + }
> +
> + if (strstr(compatible, "-spi")) {
> + opmode = FLEX_MR_OPMODE_SPI;
> + break;
> + }
> +
> + if (strstr(compatible, "-i2c")) {
> + opmode = FLEX_MR_OPMODE_TWI;
> + break;
> + }
> + }

 From what I understand Flexcom is a wrapper which can sit above any
 number of SPI, I2C and/or UART devices.  Devices which you don't
 really have any control over (source code wise).  So wouldn't it be
 better to match on the details you do have control over i.e. the node
 name, rather than the compatible string?

 I would personally match on of_find_node_by_name() to future-proof
 your implementation.
>>>
>>> Actually, I think using compatible strings is more future-proof than
>>> using the node names, because nothing in the DT bindings doc enforce the
>>> node name, and usually what we use to attach a node to a specific
>>> driver is the compatible string (this one is specified in the bindings
>>> doc).
>>
>> I know what you're saying, but what if someone uses the Flexcom driver
>> to wrap a different type of SPI driver where (for instance) the
>> compatible string used is "-".  Then we'd have to keep
>> adding more lines here to accommodate.
>>
>> Whereas if we used the child node name which only pertains to _this_
>> driver, we would then have full control and know that (unless it
>> Flexcom is used for a completely different type of serial controller)
>> we wouldn't have to keep expanding the code to accommodate.
> 
> You're right about the complexity implied by the compat string
> maintenance, but I still think using node names to detect the mode is
> a bad idea.
> 
> Let's take another example making both solution unsuitable: what if
> the flexcom-v2 exposes 2 devices of the same type, they will both have
> the same name and the same compatible string, and we'll have no way to
> detect the appropriate mode. That's why I think none of our suggestion
> is future-proof.
> 
>>
>>> Regarding the implementation itself, I would match the child node with
>>> an of_device_id table rather than trying to find a specific substring
>>> in the compatible string, but I think that's only a matter of taste.
>>
>> You mean duplicate each of the supported device's compatible strings
>> in this driver, then fetch the attributed of_match_device()->data
>> value?
>>
> 
> Yes, and that's definitely not a good idea, but I think Cyrille has
> found a better approach (I'll let him explain).

Indeed, what about taking advantage of the "ranges" property?

For the Flexcom:
#address-cells = <2>;
#size-cells = <1>;
ranges = <1 0 0xf8034200 0x200/* opmode 1: USART */
  2 0 0xf8034400 0x200/* opmode 2: SPI */
  3 0 0xf8034600 0x200>;  /* opmode 3: I2C */

Then for the single available child (for instance the SPI controller):
reg = <2 0 0x200>;

So the Operating Mode to be set into the Flexcom Mode Register is read from
the very first u32 of the "reg" property of the child.

No need to introduce any new DT property and the mapping remains easy to
maintain to follow hardware upgrades.

More details in v7 series.

> 
> Best Regards,
> 
> Boris
> 

Best Regards,

Cyrille
--
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 05/11] mfd: devicetree: bindings: Add Qualcomm SMD based RPM DT binding

[Bjorn Andersson]

On Thu 23 Jul 06:31 PDT 2015, Lee Jones wrote:

> On Mon, 13 Jul 2015, Bjorn Andersson wrote:
> 
> > On Tue 07 Jul 05:16 PDT 2015, Lee Jones wrote:
> > 
> > > FAO Mark and DT chaps,
> > > 
> > > > From: Bjorn Andersson 
> > > > 
> > > > Add binding documentation for the Qualcomm Resource Power Manager (RPM)
> > > > using shared memory (Qualcomm SMD) as transport mechanism. This is found
> > > > in 8974 and newer based devices.
> > > > 
> > > > The binding currently describes the rpm itself and the regulator
> > > > subnodes.
> > > > 
> > > > Signed-off-by: Bjorn Andersson 
> > > > ---
> > > >  .../devicetree/bindings/mfd/qcom-rpm-smd.txt   | 117 
> > > > +
> > > >  include/dt-bindings/mfd/qcom-smd-rpm.h |  28 +
> > > >  2 files changed, 145 insertions(+)
> > > >  create mode 100644 
> > > > Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
> > > >  create mode 100644 include/dt-bindings/mfd/qcom-smd-rpm.h
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt 
> > > > b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
> > 
> > [..]
> > 
> > > > +- qcom,smd-channels:
> > > > +   Usage: required
> > > > +   Value type: 
> > > > +   Definition: Shared Memory channel used for communication with 
> > > > the RPM
> > > 
> > > This is going to require a DT Ack.
> > > 
> > > Also, I don't see it being used anywhere.
> > 
> > It's a common property of all smd devices, defining the smd channel this
> > driver should bind to.
> 
> Well it's not in the kernel and I can't find the patch that uses it,
> so my points still stand.
> 

Patch 3 in this series defines the binding and patch 4 is an
implementation of this binding.

> > > > += EXAMPLE
> > > > +
> > > > +   smd {
> > > > +   compatible = "qcom,smd";
> > > 
> > > Is an SMD (Shared Memory Device?) real hardware?
> > > 
> > 
> > SMD is a mechanism for using shared memory for point-to-point
> > communication channels with remote processors in all Qualcomm platforms.
> > 
> > So it's not hardware, it's the control mechanism for communicating with
> > real hardware.
> 
> Then you can't have a node for it.  Virtual nodes which do not
> represent real h/w are not allowed in Device Tree.
> 

It represent the structure of a Qualcomm platform, but there's not a 1:1
mapping between this node and a discrete component. And without the
information it carries there's no way for us to reach e.g. the RPM -
which is a discrete physical component.

But I understand that this discussion should be held on patch 3 and with
the DT maintainers.

> > > > +   rpm {
> > > > +   interrupts = <0 168 1>;
> > > > +   qcom,ipc = <&apcs 8 0>;
> > > > +   qcom,smd-edge = <15>;
> > > 
> > > The child node won't probe without a compatible string.  Shouldn't
> > > "qcom,rpm-msm8974" be in here instead?
> > > 
> > 
> > These sub-nodes represents a logical grouping of the various channels
> > that exist to this remote processor. For the rpm there is only the
> > "rpm_requests" channel - used for sending regulator & clock requests.
> 
> Again, if it's not real h/w and don't have a proper driver, there
> should be no reason for this node to exist.
> 

We need to get hold of the interrupts and that regmap to be able to
communicate with the RPM. If this information is not in DT there will be
no communication - further we can not move it into the RPM node as with
all other remote processors (WiFi, DSP etc) these resources are shared
between a number of drivers.

> > > > +   rpm_requests {
> > > 
> > > This node appears to be undocumented.
> > 
> > This is the actual rpm device node, the smd & rpm nodes above are
> > included for completeness of the example.
> > 
> > They should perhaps be dropped to make this clearer.
> > 
> > > Does it represent real h/w?
> > > 
> > 
> > The other end of this smd channel is a micro controller that handles
> > regulator and clock requests for the platform - so this is hardware.
> > 
> > This is equivalent to the qcom_rpm driver, but instead of a hardware
> > like register window this uses the same packet based messaging mechanism
> > that's used for other remote peripherals in the Qualcomm platform.
> 
> This needs a good review by the DT guys.
> 

Sure

> > > > +   compatible = "qcom,rpm-msm8974";
> > > > +   qcom,smd-channels = "rpm_requests";
> > > > +
> > > > +   pm8941-regulators {
> > > > +   compatible = 
> > > > "qcom,rpm-pm8941-regulators";
> > > > +   vdd_l13_l20_l23_l24-supply = 
> > > > <&pm8941_boost>;
> > > 
> > > I'd like Mark to glance at this.
> > > 
> > 
> > Right.
> > 
> > > > +   pm8941_s3: s3 {
> > > > +   regulator-min-mic

Re: [PATCH v9 5/7] staging: fpga manager core

[atull]

On Wed, 22 Jul 2015, Moritz Fischer wrote:

Hi Miritz,

> Hi Alan,
> 
> a couple of small things I found while reworking the Zynq version to
> match the v9 patchset:
> 
> On Fri, Jul 17, 2015 at 8:51 AM,   wrote:
> > From: Alan Tull 
> >
...
> > +   ret = mgr->mops->write_complete(mgr);
> 
> Could we pass in flags here? This way the driver wouldn't have to keep
> track of the flags. For my case it would simplify the partial reconfig
> case.

Yes, that change will be very simple and makes sense to me.

> > +/*
> > + * FPGA Manager flags
> > + * FPGA_MGR_PARTIAL_RECONFIG: do partial reconfiguration if supported
> > + */
> > +#define FPGA_MGR_PARTIAL_RECONFIG (1)
> Could this be BIT(0) instead?

Yes, ha.  That's what it should have been.

> > +
> > +/**
> > + * struct fpga_manager_ops - ops for low level fpga manager drivers
> > + * @state: returns an enum value of the FPGA's state
> > + * @write_init: prepare the FPGA to receive confuration data
> > + * @write: write count bytes of configuration data to the FPGA
> > + * @write_complete: set FPGA to operating state after writing is done
> > + * @fpga_remove: optional: Set FPGA into a specific state during driver 
> > remove
> > + *
> > + * fpga_manager_ops are the low level functions implemented by a specific
> > + * fpga manager driver.  The optional ones are tested for NULL before being
> > + * called, so leaving them out is fine.
> > + */
> > +struct fpga_manager_ops {
> > +   enum fpga_mgr_states (*state)(struct fpga_manager *mgr);
> > +   int (*write_init)(struct fpga_manager *mgr, u32 flags,
> > + const char *buf, size_t count);
> > +   int (*write)(struct fpga_manager *mgr, const char *buf, size_t 
> > count);
> > +   int (*write_complete)(struct fpga_manager *mgr);
> See comment above, having the flags here would be very convenient for
> my usecase.

Yes

> > +   void (*fpga_remove)(struct fpga_manager *mgr);
> > +};
> > +
...
> 
> Overall looks pretty good. I still need to look at the bridge part,
> currently I have the resets and level shifters in the zynq-fpga
> driver,
> but maybe breaking them out makes sense.
> 
> Cheers,
> 
> Moritz
> 

Thanks for the review.  I'll probably send out a v10 next week including your
recommendations.

Alan

--
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 2/3] onkey: da9063: Add DA9062 OnKey capability to DA9063 OnKey driver

[S Twiss]

From: S Twiss 

Add DA9062 OnKey support into the existing DA9063 OnKey driver component by
using generic access tables for common register and bit mask definitions.

The following change will add generic register and bit mask support to the
DA9063 OnKey.

The following alterations have been made to the DA9063 OnKey:

- Addition of a da906x_chip_config structure to hold all
  generic registers and bitmasks for this type of OnKey component.
- Addition of an struct of_device_id table for DA9063 and DA9062
  defaults
- Refactoring functions to use struct da9063_onkey accesses to generic
  registers/masks instead of using defines from registers.h
- Re-work of da9063_onkey_probe() to use of_match_node() and
  dev_get_regmap() to provide initialisation of generic registers and
  masks and access to regmap

Signed-off-by: Steve Twiss 

---
Changes in V3:
 - No change
Changes in V2:
 - Altered Kconfig to use the line "Dialog DA9062/63 OnKey"
 - Rename of da9063_compatible_onkey_regmap to da906x_chip_config
 - char *name changed to const char *name
 - Rename struct da9063_compatible_onkey {} back to struct da9063_onkey

This patch applies against linux-next and next-20150708 


 drivers/input/misc/Kconfig|   8 +--
 drivers/input/misc/da9063_onkey.c | 129 ++
 2 files changed, 108 insertions(+), 29 deletions(-)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index d4f0a81..2610cfa 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -611,11 +611,11 @@ config INPUT_DA9055_ONKEY
  will be called da9055_onkey.
 
 config INPUT_DA9063_ONKEY
-   tristate "Dialog DA9063 OnKey"
-   depends on MFD_DA9063
+   tristate "Dialog DA9062/63 OnKey"
+   depends on MFD_DA9063 || MFD_DA9062
help
- Support the ONKEY of Dialog DA9063 Power Management IC as an
- input device reporting power button statue.
+ Support the ONKEY of Dialog DA9063 and DA9062 Power Management ICs
+ as an input device capable for reporting the power button status.
 
  To compile this driver as a module, choose M here: the module
  will be called da9063_onkey.
diff --git a/drivers/input/misc/da9063_onkey.c 
b/drivers/input/misc/da9063_onkey.c
index f577585..8eb697d 100644
--- a/drivers/input/misc/da9063_onkey.c
+++ b/drivers/input/misc/da9063_onkey.c
@@ -1,5 +1,5 @@
 /*
- * OnKey device driver for DA9063
+ * OnKey device driver for DA9063 and DA9062 PMICs
  * Copyright (C) 2015  Dialog Semiconductor Ltd.
  *
  * This program is free software; you can redistribute it and/or
@@ -24,36 +24,96 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
+struct da906x_chip_config {
+   /* REGS */
+   int onkey_status;
+   int onkey_pwr_signalling;
+   int onkey_fault_log;
+   int onkey_shutdown;
+   /* MASKS */
+   int onkey_nonkey_mask;
+   int onkey_nonkey_lock_mask;
+   int onkey_key_reset_mask;
+   int onkey_shutdown_mask;
+   /* NAMES */
+   const char *name;
+};
 
 struct da9063_onkey {
-   struct da9063 *hw;
struct delayed_work work;
struct input_dev *input;
struct device *dev;
+   struct regmap *regmap;
+   const struct da906x_chip_config *config;
+   char phys[32];
bool key_power;
 };
 
+static const struct da906x_chip_config da9063_regs = {
+   /* REGS */
+   .onkey_status = DA9063_REG_STATUS_A,
+   .onkey_pwr_signalling = DA9063_REG_CONTROL_B,
+   .onkey_fault_log = DA9063_REG_FAULT_LOG,
+   .onkey_shutdown = DA9063_REG_CONTROL_F,
+   /* MASKS */
+   .onkey_nonkey_mask = DA9063_NONKEY,
+   .onkey_nonkey_lock_mask = DA9063_NONKEY_LOCK,
+   .onkey_key_reset_mask = DA9063_KEY_RESET,
+   .onkey_shutdown_mask = DA9063_SHUTDOWN,
+   /* NAMES */
+   .name = DA9063_DRVNAME_ONKEY,
+};
+
+static const struct da906x_chip_config da9062_regs = {
+   /* REGS */
+   .onkey_status = DA9062AA_STATUS_A,
+   .onkey_pwr_signalling = DA9062AA_CONTROL_B,
+   .onkey_fault_log = DA9062AA_FAULT_LOG,
+   .onkey_shutdown = DA9062AA_CONTROL_F,
+   /* MASKS */
+   .onkey_nonkey_mask = DA9062AA_NONKEY_MASK,
+   .onkey_nonkey_lock_mask = DA9062AA_NONKEY_LOCK_MASK,
+   .onkey_key_reset_mask = DA9062AA_KEY_RESET_MASK,
+   .onkey_shutdown_mask = DA9062AA_SHUTDOWN_MASK,
+   /* NAMES */
+   .name = "da9062-onkey",
+};
+
+static const struct of_device_id da9063_compatible_reg_id_table[] = {
+   { .compatible = "dlg,da9063-onkey", .data = &da9063_regs },
+   { .compatible = "dlg,da9062-onkey", .data = &da9062_regs },
+   { },
+};
+
 static void da9063_poll_on(struct work_struct *work)
 {
-   struct da9063_onkey *onkey = container_of(work, struct da9063_onkey,
- work.work);
+   struct da9063_onkey *onkey = container_of(work,
+   str

[PATCH V3 0/3] da9062: Add DA9062 OnKey support using the existing DA9063 OnKey driver

[S Twiss]

From: S Twiss 

This patch set adds OnKey support for the Dialog DA9062 Power Management IC.
Changes are made to the existing DA9063 OnKey component so that functionality
in this device driver can be re-used to support the DA9062 OnKey.

This following patch set re-uses the existing kernel OnKey driver for chips
whose OnKey blocks are functionally similar to the DA9063 OnKey.

The main points for the MFD core and device tree changes are as follows.

- Alteration of the DA9063 OnKey Kconfig needs to be updated to depend on
  both MFD_DA9063 "or" MFD_DA9062. There is no explicit DA9062 OnKey Kconfig.
- The DA9062 MFD core should add a new OnKey resource as usual and an entry
  in the mfd_cell to support a component name and of_compatible for
  "da9062-onkey" and "dlg,da9062-onkey".
- The device tree binding support should include a compatible string for
  "dlg,da9062-onkey"

The main points for the OnKey changes are as follows:

A generic structure is used (called da906x_chip_config) to hold all generic
registers and bitmasks for use with this type of OnKey component.

Functions in the DA9063 OnKey will be refactored to use this compatibility
struct and all accesses to generic registers/masks will be made through
this table look-up instead of using defines from the register header files
directly

Linkage between the DA9062 MFD and the DA9063 OnKey driver is created through
the use of an of_match_table entry in the platform_driver structure.
A re-work of da9063_onkey_probe() is necessary to use the of_match_node() and
dev_get_regmap() functions: this will provide initialisation of the generic
registers and masks and allow access to the regmap according to the correct
device tree specification.

The addition of a of_device_id table for DA9063 and DA9062 default data
is created. 

In this patch set the following is provided:
 - [PATCH V3 1/3]: MFD changes in DA9062 to support OnKey
 - [PATCH V3 2/3]: Update existing DA9063 OnKey to add DA9062 support
 - [PATCH V3 3/3]: Device tree bindings for DA9062 OnKey component

This patch applies against linux-next and next-20150708 

Thank you,
Steve Twiss, Dialog Semiconductor Ltd.

S Twiss (3):
  mfd: da9062: Support for the DA9063 OnKey in the DA9062 core
  onkey: da9063: Add DA9062 OnKey capability to DA9063 OnKey driver
  devicetree: da9062: Add device tree bindings for DA9062 OnKey

 .../devicetree/bindings/input/da9062-onkey.txt |  36 ++
 Documentation/devicetree/bindings/mfd/da9062.txt   |   3 +
 drivers/input/misc/Kconfig |   8 +-
 drivers/input/misc/da9063_onkey.c  | 129 +
 drivers/mfd/da9062-core.c  |  11 ++
 5 files changed, 158 insertions(+), 29 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/da9062-onkey.txt

-- 
end-of-patch for PATCH V3

--
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 1/3] mfd: da9062: Support for the DA9063 OnKey in the DA9062 core

[S Twiss]

From: S Twiss 

Add MFD core driver support for a OnKey component

- MFD core adds the resource da9062_onkey_resources[] for the OnKey
- An appropriate value has been added into mfd_cell da9062_devs[] to
  support component .name = "da9062-onkey" and
  .of_compatible  = "dlg,da9062-onkey"

Signed-off-by: Steve Twiss 
Acked-by: Lee Jones 

---
Changes in V3:
 - Added Ack from Lee Jones
Changes in V2:
 - No change

This patch applies against linux-next and next-20150708 


 drivers/mfd/da9062-core.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
index 4cf0643..0732977 100644
--- a/drivers/mfd/da9062-core.c
+++ b/drivers/mfd/da9062-core.c
@@ -118,6 +118,10 @@ static struct resource da9062_wdt_resources[] = {
DEFINE_RES_NAMED(DA9062_IRQ_WDG_WARN, 1, "WD_WARN", IORESOURCE_IRQ),
 };
 
+static struct resource da9062_onkey_resources[] = {
+   DEFINE_RES_NAMED(DA9062_IRQ_ONKEY, 1, "ONKEY", IORESOURCE_IRQ),
+};
+
 static const struct mfd_cell da9062_devs[] = {
{
.name   = "da9062-core",
@@ -141,6 +145,13 @@ static const struct mfd_cell da9062_devs[] = {
.resources  = da9062_thermal_resources,
.of_compatible  = "dlg,da9062-thermal",
},
+   {
+   .name   = "da9062-onkey",
+   .num_resources  = ARRAY_SIZE(da9062_onkey_resources),
+   .resources  = da9062_onkey_resources,
+   .of_compatible = "dlg,da9062-onkey",
+   },
+
 };
 
 static int da9062_clear_fault_log(struct da9062 *chip)
-- 
end-of-patch for PATCH V3

--
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 3/3] devicetree: da9062: Add device tree bindings for DA9062 OnKey

[S Twiss]

From: S Twiss 

Add device tree bindings for the DA9062 OnKey driver component

Signed-off-by: Steve Twiss 

---
Changes in V3:
 - Child driver specifics separated out into separate document
   in this case ../input/da9062-onkey.txt
Changes in V2:
 - No change

This patch applies against linux-next and next-20150708 


 .../devicetree/bindings/input/da9062-onkey.txt | 36 ++
 Documentation/devicetree/bindings/mfd/da9062.txt   |  3 ++
 2 files changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/da9062-onkey.txt

diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt 
b/Documentation/devicetree/bindings/input/da9062-onkey.txt
new file mode 100644
index 000..c936902
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/da9062-onkey.txt
@@ -0,0 +1,36 @@
+* Dialog DA9062 OnKey Module
+
+This module is part of the DA9062. For more details about the whole
+chip see Documentation/devicetree/bindings/mfd/da9062.txt.
+
+This module provides KEY_POWER, KEY_SLEEP and events.
+
+Required properties:
+
+- compatible: should be "dlg,da9062-onkey"
+
+Nodes:
+
+- onkey : This node defines the OnKey settings for controlling the key
+  functionality of the device. The node should contain the compatible property
+  with the value "dlg,da9062-onkey".
+
+  Optional onkey properties:
+
+  - dlg,disable-key-power : Disable power-down using a long key-press. If this
+entry exists the OnKey driver will remove support for the KEY_POWER key
+press. If this entry does not exist then by default the key-press
+triggered power down is enabled and the OnKey will support both KEY_POWER
+and KEY_SLEEP.
+
+Example:
+
+   pmic0: da9062@58 {
+
+   onkey {
+   compatible = "dlg,da9063-onkey";
+   dlg,disable-key-power;
+   };
+
+   };
+
diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt 
b/Documentation/devicetree/bindings/mfd/da9062.txt
index 5765ed9..d2e1730 100644
--- a/Documentation/devicetree/bindings/mfd/da9062.txt
+++ b/Documentation/devicetree/bindings/mfd/da9062.txt
@@ -5,6 +5,7 @@ DA9062 consists of a large and varied group of sub-devices:
 Device   Supply NamesDescription
 --   ---
 da9062-regulator:   : LDOs & BUCKs
+da9062-onkey:   : On Key
 da9062-watchdog :   : Watchdog Timer
 
 ==
@@ -40,6 +41,8 @@ Sub-nodes:
   details of individual regulator device can be found in:
   Documentation/devicetree/bindings/regulator/regulator.txt
 
+- onkey : For more details about the onkey node see
+  Documentation/devicetree/bindings/input/da9062-onkey.txt
 
 - watchdog: This node defines the settings for the watchdog driver associated
   with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be added
-- 
end-of-patch for PATCH V3

--
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 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx

[Suman Anna]

Hi Tony,

On 07/23/2015 02:24 AM, Tony Lindgren wrote:
> * Suman Anna  [150722 09:25]:
>> On 07/22/2015 12:26 AM, Tony Lindgren wrote:
>>>
>>> I don't like using syscon for tinkering directly with SoC registers.
>>
>> This is not a SoC-level register, but a register within a sub-module of
>> the DSP processor sub-system. The DSP_SYSTEM sub-module in general is
>> described in Section 5.3.3 of the TRM [1], and it implements different
>> functionalities like the PRCM handshaking, wakeup logic and DSP
>> subsystem top-level configuration. It is a module present within the DSP
>> processor sub-system, so can only be accessed when the sub-system is
>> clocked and the appropriate reset is released.
> 
> OK so if it's specific to the DSP driver along the lines of sysc and
> syss registers.

There will be those registers too within the MMU config register space,
even for DRA7xx MMUs. This is different, think of it like a register in
the Control module except that it is present within the DSP sub-system
instead of at the SoC level.

> 
> Typically we handle these registers by mapping them to the PM runtime
> functions for the interconnect so we can reset and idle the hardware
> modules even if there is no driver, see for example
> omap54xx_mmu_dsp_hwmod.

I haven't yet submitted the DRA7xx hwmods, but they will look almost
exactly like the OMAP5 ones. The reset and idle on these are in general
not effective at boot time since these are also controlled by a
hard-reset line, so that's left to the drivers to deal with it through
the omap_device_deassert_hardreset API.

>  
>>> We should use some Linux generic framework for configuring these
>>> bits to avoid nasty dependencies between various hardware modules
>>> on the SoC.
>>>
>>> What does DSP_SYS_MMU_CONFIG register do? It seems it's probably
>>> a regulator or a gate clock? If so, it should be set up as a
>>> regulator or a clock and then the omap-iommu driver can just
>>> use regulator or clcok framework to request the resource.
>>
>> No, its neither. It is a control bit that dictates whether the
>> processor/EDMA addresses go through the respective MMU or not. The
>> register currently has 4 bits (bit 0 in each nibble), one each for
>> enabling each MMU and requesting an MMU abort on each. The MMU
>> integration and enablement notes are detailed in Section 5.3.6 of the
>> TRM [1], and the DSP_SYS_MMU_CONFIG register layout is in Table 5-28
>> (Page 1641).
> 
> OK yeah seems like it should be handled by the DSP driver during
> probe after doing pm_runtime_get. Then the driver can configure
> things like IOMMU and load firmware. Or am I missing something here?

The DSP (remoteproc) driver uses the generic IOMMU API, and all the
IOMMU enabling sequence is transparent to the DSP driver. So, any
configuration/enabling sequence specific to the IOMMU has to be handled
within the respective IOMMU platform driver that gets integrated into
the IOMMU API.

regards
Suman

> 
>  
>> [1] http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf

--
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/4] mfd: Add DT binding for Maxim MAX77802 IC

[Javier Martinez Canillas]

Hello Lee,

Thanks for your feedback.

On 07/23/2015 05:16 PM, Lee Jones wrote:
> On Fri, 17 Jul 2015, Javier Martinez Canillas wrote:
> 
>> The MAX77802 is a chip that contains regulators, 2 32kHz clocks,
>> a RTC and an I2C interface to program the individual components.
>>
>> The are already DT bindings for the regulators and clocks and
>> these reference to a bindings/mfd/max77802.txt file, that didn't
>> exist, for the details about the PMIC.
>>
>> Signed-off-by: Javier Martinez Canillas 
>>
>> ---
>>
>> Changes in v2:
>> - Use the correct "maxim,max77802" compatible string.
>>   Suggested by Krzysztof Kozlowski
>> - Use a pmic generic node name for the max77802 node example.
>>   Suggested by Sergei Shtylyov.
>>
>>  Documentation/devicetree/bindings/mfd/max77802.txt | 26 
>> ++
>>  1 file changed, 26 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt 
>> b/Documentation/devicetree/bindings/mfd/max77802.txt
>> new file mode 100644
>> index ..c60cdec50d36
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/max77802.txt
>> @@ -0,0 +1,26 @@
>> +Maxim MAX77802 multi-function device
>> +
>> +The Maxim MAX77802 is a power management chip (PMIC) that contains 10 high
>> +efficiency Buck regulators, 32 Low-dropout (LDO) regulators used to power
> 
> Would be good to capitalise the works in the acronyms, so
> "Low-DropOut" and "Power Management IC".
>

Ok.
 
>> +up application processors and peripherals, a 2-channel 32kHz clock outputs,
>> +a Real-Time-Clock (RTC) and a I2C interface to program the individual
>> +regulators, clocks outputs and the RTC.
>> +
>> +Binding for the built-in 32k clock generator block is defined separately
>> +in the bindings/clk/maxim,max77802.txt file and binding for the regulators
> 
> s/bindings/../
>

Ok.
 
>> +is defined in the bindings/regulator/max77802.txt file.
>> +
>> +Required properties:
>> +- compatible : Must be "maxim,max77802";
>> +- reg : Specifies the i2c slave address of PMIC block.
> 
> s/i2c/I2C/
> 
>> +- interrupts : This i2c device has an IRQ line connected to the main SoC.
> 
> As above.
>

Ok. I'll change it.
 
>> +- interrupt-parent : The parent interrupt controller.
>> +
>> +Example:
>> +
>> +max77802: pmic@09 {
>> +compatible = "maxim,max77802";
>> +interrupt-parent = <&intc>;
>> +interrupts = <26 0>;
> 
> Is there a define in include/dt-bindings/interrupt-controller to
> replace 0?  IRQ_TYPE_NONE perhaps.
>

Yes, I'll change that as well.
 
>> +reg = <0x09>;
>> +};
> 

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 2/2] regulator: 88pm800: Add support for configuration of dual phase on BUCK1

[Lee Jones]

On Tue, 21 Jul 2015, Vaibhav Hiremath wrote:

> 88PM860 device supports dual phase mode on BUCK1 output.
> In normal usecase, BUCK1A and BUCK1B operates independently with 3A
> capacity. And they both can work as a dual phase providing 6A capacity.
> 
> This patch updates the regulator driver to read the respective
> DT property and enable dual-phase mode on BUCK1.
> 
> Note that, this is init time (one time) initialization.
> 
> Signed-off-by: Vaibhav Hiremath 
> ---
>  drivers/regulator/88pm800.c | 31 +++
>  include/linux/mfd/88pm80x.h |  3 +++
>  2 files changed, 34 insertions(+)

[...]

> diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
> index a92d173..05d9bad 100644
> --- a/include/linux/mfd/88pm80x.h
> +++ b/include/linux/mfd/88pm80x.h
> @@ -295,6 +295,9 @@ enum {
>  #define PM860_BUCK4_MISC2(0x82)
>  #define PM860_BUCK4_FULL_DRV BIT(2)
>  
> +#define PM860_BUCK1_MISC (0x8E)

Why the over-bracketing?

> +#define BUCK1_DUAL_PHASE_SEL BIT(2)
> +
>  struct pm80x_rtc_pdata {
>   int vrtc;
>   int rtc_wakeup;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH-v2 1/2] mfd: devicetree: bindings: 88pm800: Add DT property for dual phase enable

[Lee Jones]

On Tue, 21 Jul 2015, Vaibhav Hiremath wrote:

> 88PM860 family of device supports dual phase mode on BUCK1 supply
> providing total 6A capacity.
> Note that by default they operate independently with 3A capacity.
> 
> This patch updates the devicetree binding with DT property
> to enable dual-phase mode on BUCK1.
> 
> Signed-off-by: Vaibhav Hiremath 
> ---
>  Documentation/devicetree/bindings/mfd/88pm800.txt | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/88pm800.txt 
> b/Documentation/devicetree/bindings/mfd/88pm800.txt
> index dec842f..2c82fcb 100644
> --- a/Documentation/devicetree/bindings/mfd/88pm800.txt
> +++ b/Documentation/devicetree/bindings/mfd/88pm800.txt
> @@ -9,6 +9,12 @@ Required parent device properties:
>  - #interrupt-cells   : should be 1.
> The cell is the 88pm80x local IRQ number
>  
> +Optional properties :
> +- marvell,88pm860-buck1-dualphase-en  : If set, enable dual phase on BUCK1,
> +  providing 6A capacity.
> +  Without this both BUCK1A and BUCK1B operates independently with 3A 
> capacity.
> +  (This property is only applicable to 88PM860)

You need to get Mark Brown to Ack this.

>  88pm80x family of devices consists of varied group of sub-devices:
>  
>  Device   Supply Names Description

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] mfd: 88pm800: Update the header file with 32K clk related macros

[Lee Jones]

On Tue, 21 Jul 2015, Vaibhav Hiremath wrote:

> Update header file with required macros for 32KHz buffered clock
> output of 88PM800 family of device.
> These macros will be used in clk provider driver.
> 
> Signed-off-by: Vaibhav Hiremath 
> ---
>  include/linux/mfd/88pm80x.h | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
> index 05d9bad..680e4eb 100644
> --- a/include/linux/mfd/88pm80x.h
> +++ b/include/linux/mfd/88pm80x.h
> @@ -91,6 +91,7 @@ enum {
>  /* Referance and low power registers */
>  #define PM800_LOW_POWER1 (0x20)
>  #define PM800_LOW_POWER2 (0x21)
> +#define PM800_LOW_POWER2_XO_LJ_ENBIT(5)
>  
>  #define PM800_LOW_POWER_CONFIG3  (0x22)
>  #define PM800_LDOBK_FREEZE   BIT(7)
> @@ -138,6 +139,13 @@ enum {
>  #define PM800_ALARM  BIT(5)
>  #define PM800_RTC1_USE_XOBIT(7)
>  
> +#define PM800_32K_OUTX_SEL_MASK  (0x3)
> +/* 32KHz clk output sel mode */
> +#define PM800_32K_OUTX_SEL_ZERO  (0x0)
> +#define PM800_32K_OUTX_SEL_INT_32KHZ (0x1)
> +#define PM800_32K_OUTX_SEL_XO_32KHZ  (0x2)
> +#define PM800_32K_OUTX_SEL_HIZ   (0x3)

Why do these need to be in brackets?

>  /* Regulator Control Registers: BUCK1,BUCK5,LDO1 have DVC */
>  
>  /* buck registers */
> @@ -208,6 +216,10 @@ enum {
>  #define PM800_PMOD_MEAS1 0x52
>  #define PM800_PMOD_MEAS2 0x53
>  
> +/* Oscillator control */
> +#define PM800_OSC_CNTRL1 (0x50)
> +#define PM800_OSC_CNTRL1_OSC_FREERUN_EN  BIT(1)
> +
>  #define PM800_GPADC0_MEAS1   0x54
>  #define PM800_GPADC0_MEAS2   0x55
>  #define PM800_GPADC1_MEAS1   0x56

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 8/9] nvmem: sunxi: Move the SID driver to the nvmem framework

[Srinivas Kandagatla]

On 23/07/15 16:18, Stefan Wahren wrote:

Hi Srinivas,

Am 20.07.2015 um 16:44 schrieb Srinivas Kandagatla:

From: Maxime Ripard 

Now that we have the nvmem framework, we can consolidate the common
driver code. Move the driver to the framework, and hopefully, it will
fix the sysfs file creation race.

Signed-off-by: Maxime Ripard 
[srinivas.kandagatla: Moved to regmap based EEPROM framework]
Signed-off-by: Srinivas Kandagatla 
---
  Documentation/ABI/testing/sysfs-driver-sunxi-sid   |  22 ---
  .../bindings/misc/allwinner,sunxi-sid.txt  |  17 ---
  .../bindings/nvmem/allwinner,sunxi-sid.txt |  21 +++
  drivers/misc/eeprom/Kconfig|  13 --
  drivers/misc/eeprom/Makefile   |   1 -
  drivers/misc/eeprom/sunxi_sid.c| 156 
  drivers/nvmem/Kconfig  |  11 ++
  drivers/nvmem/Makefile |   2 +
  drivers/nvmem/sunxi_sid.c  | 159 +
  9 files changed, 193 insertions(+), 209 deletions(-)
  delete mode 100644 Documentation/ABI/testing/sysfs-driver-sunxi-sid
  delete mode 100644 
Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
  create mode 100644 
Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
  delete mode 100644 drivers/misc/eeprom/sunxi_sid.c
  create mode 100644 drivers/nvmem/sunxi_sid.c

[...]
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index ff44fe9..4328b93 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -8,3 +8,5 @@ nvmem_core-y:= core.o
  # Devices
  obj-$(CONFIG_QCOM_QFPROM) += nvmem_qfprom.o
  nvmem_qfprom-y:= qfprom.o
+obj-$(CONFIG_NVMEM_SUNXI_SID)  += nvmem_sunxi_sid.o
+nvmem_sunxi_sid-y  := sunxi_sid.o


is it really necessary to have 2 lines for a single driver?

Why not the following line?

obj-$(CONFIG_NVMEM_SUNXI_SID)   += sunxi_sid.o

We can do that, but only reason i did it this way is to make the module 
naming consistent like nvmem_*.ko


--srini


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


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

Re: [PATCH 4/4] mfd: 88pm800: Add support for clk subdevice

[Lee Jones]

On Tue, 21 Jul 2015, Vaibhav Hiremath wrote:

> This patch adds mfd_cell/clk-subdevice for 88PM800 MFD
> (and family of devices).
> 
> Signed-off-by: Vaibhav Hiremath 
> ---
>  drivers/mfd/88pm800.c | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
> index f104a32..9723eac 100644
> --- a/drivers/mfd/88pm800.c
> +++ b/drivers/mfd/88pm800.c
> @@ -173,6 +173,14 @@ static const struct mfd_cell regulator_devs[] = {
>   },
>  };
>  
> +static struct mfd_cell clk_devs[] = {
> + {
> +  .name = "88pm80x-clk",
> +  .of_compatible = "marvell,88pm800-clk",
> +  .id = -1,
> + },
> +};

Why does each device in 88pm800.c have it's own mfd_cell?

Take the opportunity to correct the tabbing in the remainder of the
file.  Make that fix-up patch 1 of this set.  Then fixup this patch.

>  static const struct regmap_irq pm800_irqs[] = {
>   /* INT0 */
>   [PM800_IRQ_ONKEY] = {
> @@ -344,6 +352,17 @@ static int device_regulator_init(struct pm80x_chip *chip)
> ARRAY_SIZE(regulator_devs), NULL, 0, NULL);
>  }
>  
> +static int device_clk_init(struct pm80x_chip *chip)
> +{
> + if (chip->type == CHIP_PM800)
> + clk_devs[0].name = "88pm800-clk";
> + else if (chip->type == CHIP_PM860)
> + clk_devs[0].name = "88pm860-clk";
> +
> + return mfd_add_devices(chip->dev, 0, &clk_devs[0],
> +   ARRAY_SIZE(clk_devs), NULL, 0, NULL);
> +}
> +
>  static int device_irq_init_800(struct pm80x_chip *chip)
>  {
>   struct regmap *map = chip->regmap;
> @@ -513,6 +532,12 @@ static int device_800_init(struct pm80x_chip *chip)
>   goto out;
>   }
>  
> + ret = device_clk_init(chip);
> + if (ret) {
> + dev_err(chip->dev, "Failed to add clk subdev\n");
> + goto out;
> + }

Why do these have to be seperate?

>   return 0;
>  out_dev:
>   mfd_remove_devices(chip->dev);

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 1/9] nvmem: Add a simple NVMEM framework for nvmem providers

[Srinivas Kandagatla]

On 23/07/15 16:26, Stefan Wahren wrote:

Hi Srinivas,

Am 20.07.2015 um 16:43 schrieb Srinivas Kandagatla:

This patch adds just providers part of the framework just to enable easy
review.

Up until now, NVMEM drivers like eeprom were stored in drivers/misc,
where they all had to duplicate pretty much the same code to register
a sysfs file, allow in-kernel users to access the content of the devices
they were driving, etc.

This was also a problem as far as other in-kernel users were involved,
since the solutions used were pretty much different from on driver to
another, there was a rather big abstraction leak.

This introduction of this framework aims at solving this. It also
introduces DT representation for consumer devices to go get the data
they require (MAC Addresses, SoC/Revision ID, part numbers, and so on)
from the nvmems.

Having regmap interface to this framework would give much better
abstraction for nvmems on different buses.

Signed-off-by: Maxime Ripard 
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla 
---
  drivers/Kconfig|   2 +
  drivers/Makefile   |   1 +
  drivers/nvmem/Kconfig  |  13 ++
  drivers/nvmem/Makefile |   6 +
  drivers/nvmem/core.c   | 384 +
  include/linux/nvmem-consumer.h |  23 +++
  include/linux/nvmem-provider.h |  47 +
  7 files changed, 476 insertions(+)
  create mode 100644 drivers/nvmem/Kconfig
  create mode 100644 drivers/nvmem/Makefile
  create mode 100644 drivers/nvmem/core.c
  create mode 100644 include/linux/nvmem-consumer.h
  create mode 100644 include/linux/nvmem-provider.h


i've tested this patch with my mxs-ocotp driver [1].

So you can add

Tested-by: Stefan Wahren 


Thanks for tested-by, That helps.

--srini





Regards
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

Re: [PATCH v8 8/9] nvmem: sunxi: Move the SID driver to the nvmem framework

[Srinivas Kandagatla]

On 21/07/15 17:38, Stefan Wahren wrote:

Hi Srinivas,


Srinivas Kandagatla  hat am 20. Juli 2015 um
16:44 geschrieben:


From: Maxime Ripard 

Now that we have the nvmem framework, we can consolidate the common
driver code. Move the driver to the framework, and hopefully, it will
fix the sysfs file creation race.

Signed-off-by: Maxime Ripard 
[srinivas.kandagatla: Moved to regmap based EEPROM framework]
Signed-off-by: Srinivas Kandagatla 
---
Documentation/ABI/testing/sysfs-driver-sunxi-sid | 22 ---
.../bindings/misc/allwinner,sunxi-sid.txt | 17 ---
.../bindings/nvmem/allwinner,sunxi-sid.txt | 21 +++
drivers/misc/eeprom/Kconfig | 13 --
drivers/misc/eeprom/Makefile | 1 -
drivers/misc/eeprom/sunxi_sid.c | 156 
drivers/nvmem/Kconfig | 11 ++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/sunxi_sid.c | 159 +
9 files changed, 193 insertions(+), 209 deletions(-)
delete mode 100644 Documentation/ABI/testing/sysfs-driver-sunxi-sid
delete mode 100644
Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
create mode 100644
Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
delete mode 100644 drivers/misc/eeprom/sunxi_sid.c
create mode 100644 drivers/nvmem/sunxi_sid.c

[...]
-static int sunxi_sid_probe(struct platform_device *pdev)
-{
- struct sunxi_sid_data *sid_data;
- struct resource *res;
- const struct of_device_id *of_dev_id;
- u8 *entropy;
- unsigned int i;
-
- sid_data = devm_kzalloc(&pdev->dev, sizeof(struct sunxi_sid_data),
- GFP_KERNEL);
- if (!sid_data)
- return -ENOMEM;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- sid_data->reg_base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(sid_data->reg_base))
- return PTR_ERR(sid_data->reg_base);
-
- of_dev_id = of_match_device(sunxi_sid_of_match, &pdev->dev);
- if (!of_dev_id)
- return -ENODEV;
- sid_data->keysize = (int)of_dev_id->data;
-
- platform_set_drvdata(pdev, sid_data);
-
- sid_bin_attr.size = sid_data->keysize;
- if (device_create_bin_file(&pdev->dev, &sid_bin_attr))
- return -ENODEV;
-
- entropy = kzalloc(sizeof(u8) * sid_data->keysize, GFP_KERNEL);
- for (i = 0; i < sid_data->keysize; i++)
- entropy[i] = sunxi_sid_read_byte(sid_data, i);
- add_device_randomness(entropy, sid_data->keysize);
- kfree(entropy);
-


in case of porting a driver to a new framework, i would expect the same
features.
The ported driver do not add the Security ID to the device randomness.

What's the reason for this difference?
Not sure why it was discarded in the first place, but I can put it back 
which will atleast add some data to random pool.


--srini


Regards
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

Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS

[R, Vignesh]

On 7/16/2015 9:01 PM, R, Vignesh wrote:
> Hi,
> 
> On 07/16/2015 03:24 AM, Paul Walmsley wrote:
>> Hi,
>>
>> some comments.
>>
>> On Wed, 3 Jun 2015, Vignesh R wrote:
>>
>>> Add hwmod entries for the PWMSS on DRA7.
>>>
>>> Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock
>>> equal to L4PER2_L3_GICLK/2(l3_iclk_div/2).
>>> As per AM57x TRM SPRUHZ6[1], October 2014, Section 29.1.3 Table 29-4,
>>> clock source to PWMSS is L4PER2_L3_GICLK. But it is actually
>>> L4PER2_L3_GICLK/2. The TRM does not show the division by 2.
>>
>> Is the divide-by-two coming from PWMSS_EPWM.EPWM_TBCTL[HSPCLKDIV]?  Or is 
>> HSPCLKDIV a separate divider after the divide-by-2 you mention above?
> 
> No, it not related to HSPCLKDIV. The TRM wrongly states L4PER2_L3_GICLK
> as clock input for PWMSS. But actually  L4PER2_L4_GICLK(=L3_GICLK/2) is
> the clock input for PWMSS. This will be updated in TRM soon.
> 
>>
>>> [1] www.ti.com/lit/ug/spruhz6/spruhz6.pdf
>>>
>>> Signed-off-by: Vignesh R 
>>> ---
>>>
>>> v2:
>>>  * add TRM references.
>>>
>>>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 239 
>>> ++
>>>  1 file changed, 239 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
>>> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> index 0e64c2fac0b5..86a7ac9a3138 100644
>>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> @@ -362,6 +362,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
>>> },
>>>  };
>>>  
>>> +/* pwmss  */
>>> +static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
>>> +   .rev_offs   = 0x0,
>>> +   .sysc_offs  = 0x4,
>>> +   .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_RESET_STATUS,
>>
>> This doesn't match SPRUHZ6 Table 29-13 "PWMSS_SYSCONFIG".  There's no 
>> RESETSTATUS bit.  There is a SOFTRESET bit. 
>>
>> Could you please confirm whether this is intentional?
> 
> sorry my bad... I will change this in v3.
> 
>>
>>> +   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
>>> +   .sysc_fields= &omap_hwmod_sysc_type2,
>>> +};
>>> +
>>> +struct omap_hwmod_class dra7xx_epwmss_hwmod_class = {
>>> +   .name   = "epwmss",
>>> +   .sysc   = &dra7xx_epwmss_sysc,
>>> +};
>>> +
>>> +static struct omap_hwmod_class dra7xx_ecap_hwmod_class = {
>>> +   .name   = "ecap",
>>> +};
>>> +
>>> +static struct omap_hwmod_class dra7xx_eqep_hwmod_class = {
>>> +   .name   = "eqep",
>>> +};
>>> +
>>> +struct omap_hwmod_class dra7xx_ehrpwm_hwmod_class = {
>>> +   .name   = "ehrpwm",
>>> +};
>>> +
>>> +/* epwmss0 */
>>> +struct omap_hwmod dra7xx_epwmss0_hwmod = {
>>> +   .name   = "epwmss0",
>>> +   .class  = &dra7xx_epwmss_hwmod_class,
>>> +   .clkdm_name = "l4per2_clkdm",
>>> +   .main_clk   = "l4_root_clk_div",
>>> +   .prcm   = {
>>> +   .omap4  = {
>>> +   .modulemode = MODULEMODE_SWCTRL,
>>> +   .clkctrl_offs   = 
>>> DRA7XX_CM_L4PER2_PWMSS1_CLKCTRL_OFFSET,
>>> +   .context_offs   = 
>>> DRA7XX_RM_L4PER2_PWMSS1_CONTEXT_OFFSET,
>>> +   },
>>> +   },
>>
>> Per my comment on the previous patch, sounds like it might be better to 
>> mark this as HWMOD_SWSUP_SIDLE?  Then again, see the next comment below 
>> re: main_clk.
>>
>>> +};
>>> +
>>> +/* ecap0 */
>>> +struct omap_hwmod dra7xx_ecap0_hwmod = {
>>> +   .name   = "ecap0",
>>> +   .class  = &dra7xx_ecap_hwmod_class,
>>> +   .clkdm_name = "l4per2_clkdm",
>>> +   .main_clk   = "l4_root_clk_div",
>>
>> Looking at SPRUHZ6 Section 29.1.4.2 "PWMSS Modules Local Clock Gating", 
>> there appears to be a local "mini-PRCM" for the PWMSS which implements 
>> clock gating and reports back on the status of what I'd guess is the local 
>> clock gating FSM.
>>
>> So from that point of view, you should probably create a clock driver that 
>> manages both the clock gate request bit and the FSM status bit.  It should 
>> be something that can be reused for the other PWMSS IP blocks.  Then 
>> you'd create per-IP block clock nodes and set the main_clk to point to 
>> that node.
>>
> 
> Since, this register is within the config space of PWMSS, the individual
> gating and reporting for the modules within PWMSS
> (PWMSS_CLKCONFIG) is currently being taken care by pwm-tipwmss.c(almost
> the sole function this driver is doing). It has been the same since
> am335x. Adding new clock nodes will result in driver changes and also
> changes to am335x, am437x (and other platforms) hwmod files. It also
> involves adding new nodes to clocks.dtsi and it will be difficult to
> maintain backward compatibility for older platforms. Is it not better to
> keep this as is, in order to maintain consistency (with am335x, am437x
> etc) and also that these clock bits are within IP's config space?
> 
ping...

Regards
Vignesh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the

Re: [PATCH V3 2/3] devicetree: da9062: Add device tree bindings for DA9062 RTC

[Lee Jones]

On Tue, 21 Jul 2015, S Twiss wrote:

> From: S Twiss 
> 
> Add device tree bindings for the DA9062 RTC driver component
> 
> Signed-off-by: Steve Twiss 
> 
> ---
> Checks performed with linux-next/next-20150708/scripts/checkpatch.pl
>  da9062.txttotal: 0 errors, 0 warnings, 88 lines checked
> This patch applies against linux-next and next-20150708 
> 
> 
>  Documentation/devicetree/bindings/mfd/da9062.txt | 9 +
>  1 file changed, 9 insertions(+)

Applied, thanks.

> diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt 
> b/Documentation/devicetree/bindings/mfd/da9062.txt
> index 5765ed9..38802b5 100644
> --- a/Documentation/devicetree/bindings/mfd/da9062.txt
> +++ b/Documentation/devicetree/bindings/mfd/da9062.txt
> @@ -5,6 +5,7 @@ DA9062 consists of a large and varied group of sub-devices:
>  Device   Supply NamesDescription
>  --   ---
>  da9062-regulator:   : LDOs & BUCKs
> +da9062-rtc  :   : Real-Time Clock
>  da9062-watchdog :   : Watchdog Timer
>  
>  ==
> @@ -41,6 +42,10 @@ Sub-nodes:
>Documentation/devicetree/bindings/regulator/regulator.txt
>  
>  
> +- rtc : This node defines settings required for the Real-Time Clock 
> associated
> +  with the DA9062. There are currently no entries in this binding, however
> +  compatible = "dlg,da9062-rtc" should be added if a node is created.
> +
>  - watchdog: This node defines the settings for the watchdog driver associated
>with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be 
> added
>if a node is created.
> @@ -55,6 +60,10 @@ Example:
>   interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
>   interrupt-controller;
>  
> + rtc {
> + compatible = "dlg,da9062-rtc";
> + };
> +
>   watchdog {
>   compatible = "dlg,da9062-watchdog";
>   };

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 1/9] nvmem: Add a simple NVMEM framework for nvmem providers

[Stefan Wahren]

Hi Srinivas,

Am 20.07.2015 um 16:43 schrieb Srinivas Kandagatla:
> This patch adds just providers part of the framework just to enable easy
> review.
>
> Up until now, NVMEM drivers like eeprom were stored in drivers/misc,
> where they all had to duplicate pretty much the same code to register
> a sysfs file, allow in-kernel users to access the content of the devices
> they were driving, etc.
>
> This was also a problem as far as other in-kernel users were involved,
> since the solutions used were pretty much different from on driver to
> another, there was a rather big abstraction leak.
>
> This introduction of this framework aims at solving this. It also
> introduces DT representation for consumer devices to go get the data
> they require (MAC Addresses, SoC/Revision ID, part numbers, and so on)
> from the nvmems.
>
> Having regmap interface to this framework would give much better
> abstraction for nvmems on different buses.
>
> Signed-off-by: Maxime Ripard 
> [Maxime Ripard: intial version of eeprom framework]
> Signed-off-by: Srinivas Kandagatla 
> ---
>  drivers/Kconfig|   2 +
>  drivers/Makefile   |   1 +
>  drivers/nvmem/Kconfig  |  13 ++
>  drivers/nvmem/Makefile |   6 +
>  drivers/nvmem/core.c   | 384 
> +
>  include/linux/nvmem-consumer.h |  23 +++
>  include/linux/nvmem-provider.h |  47 +
>  7 files changed, 476 insertions(+)
>  create mode 100644 drivers/nvmem/Kconfig
>  create mode 100644 drivers/nvmem/Makefile
>  create mode 100644 drivers/nvmem/core.c
>  create mode 100644 include/linux/nvmem-consumer.h
>  create mode 100644 include/linux/nvmem-provider.h

i've tested this patch with my mxs-ocotp driver [1].

So you can add

Tested-by: Stefan Wahren 

Regards
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

Re: [PATCH V3 1/3] mfd: da9062: Support for the DA9063 RTC in the DA9062 core

[Lee Jones]

On Tue, 21 Jul 2015, S Twiss wrote:

> From: S Twiss 
> 
> Add MFD core driver support for a RTC component
> 
> - MFD core adds the RTC resources da9062_rtc_resources[] for the RTC
>   alarm and tick timer IRQ
> - An appropriate mfd_cell has been added into da9062_devs[] to support
>   a component .name = "da9062-rtc" and .of_compatible  = "dlg,da9062-rtc"
> 
> Signed-off-by: Steve Twiss 
> 
> ---
> Checks performed with linux-next/next-20150708/scripts/checkpatch.pl
>  da9062-core.c total: 0 errors, 0 warnings, 523 lines checked
> This patch applies against linux-next and next-20150708 
> 
> 
>  drivers/mfd/da9062-core.c | 11 +++
>  1 file changed, 11 insertions(+)

Applied, thanks.

> diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
> index 4cf0643..b43cd24 100644
> --- a/drivers/mfd/da9062-core.c
> +++ b/drivers/mfd/da9062-core.c
> @@ -118,6 +118,11 @@ static struct resource da9062_wdt_resources[] = {
>   DEFINE_RES_NAMED(DA9062_IRQ_WDG_WARN, 1, "WD_WARN", IORESOURCE_IRQ),
>  };
>  
> +static struct resource da9062_rtc_resources[] = {
> + DEFINE_RES_NAMED(DA9062_IRQ_ALARM, 1, "ALARM", IORESOURCE_IRQ),
> + DEFINE_RES_NAMED(DA9062_IRQ_TICK, 1, "TICK", IORESOURCE_IRQ),
> +};
> +
>  static const struct mfd_cell da9062_devs[] = {
>   {
>   .name   = "da9062-core",
> @@ -141,6 +146,12 @@ static const struct mfd_cell da9062_devs[] = {
>   .resources  = da9062_thermal_resources,
>   .of_compatible  = "dlg,da9062-thermal",
>   },
> + {
> + .name   = "da9062-rtc",
> + .num_resources  = ARRAY_SIZE(da9062_rtc_resources),
> + .resources  = da9062_rtc_resources,
> + .of_compatible  = "dlg,da9062-rtc",
> + },
>  };
>  
>  static int da9062_clear_fault_log(struct da9062 *chip)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 8/9] nvmem: sunxi: Move the SID driver to the nvmem framework

[Stefan Wahren]

Hi Srinivas,

Am 20.07.2015 um 16:44 schrieb Srinivas Kandagatla:
> From: Maxime Ripard 
>
> Now that we have the nvmem framework, we can consolidate the common
> driver code. Move the driver to the framework, and hopefully, it will
> fix the sysfs file creation race.
>
> Signed-off-by: Maxime Ripard 
> [srinivas.kandagatla: Moved to regmap based EEPROM framework]
> Signed-off-by: Srinivas Kandagatla 
> ---
>  Documentation/ABI/testing/sysfs-driver-sunxi-sid   |  22 ---
>  .../bindings/misc/allwinner,sunxi-sid.txt  |  17 ---
>  .../bindings/nvmem/allwinner,sunxi-sid.txt |  21 +++
>  drivers/misc/eeprom/Kconfig|  13 --
>  drivers/misc/eeprom/Makefile   |   1 -
>  drivers/misc/eeprom/sunxi_sid.c| 156 
>  drivers/nvmem/Kconfig  |  11 ++
>  drivers/nvmem/Makefile |   2 +
>  drivers/nvmem/sunxi_sid.c  | 159 
> +
>  9 files changed, 193 insertions(+), 209 deletions(-)
>  delete mode 100644 Documentation/ABI/testing/sysfs-driver-sunxi-sid
>  delete mode 100644 
> Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
>  create mode 100644 
> Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
>  delete mode 100644 drivers/misc/eeprom/sunxi_sid.c
>  create mode 100644 drivers/nvmem/sunxi_sid.c
>
> [...]
> diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> index ff44fe9..4328b93 100644
> --- a/drivers/nvmem/Makefile
> +++ b/drivers/nvmem/Makefile
> @@ -8,3 +8,5 @@ nvmem_core-y  := core.o
>  # Devices
>  obj-$(CONFIG_QCOM_QFPROM)+= nvmem_qfprom.o
>  nvmem_qfprom-y   := qfprom.o
> +obj-$(CONFIG_NVMEM_SUNXI_SID)+= nvmem_sunxi_sid.o
> +nvmem_sunxi_sid-y:= sunxi_sid.o

is it really necessary to have 2 lines for a single driver?

Why not the following line?

obj-$(CONFIG_NVMEM_SUNXI_SID)   += sunxi_sid.o

Regards
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

Re: [PATCH v2 3/4] mfd: Add DT binding for Maxim MAX77802 IC

[Lee Jones]

On Fri, 17 Jul 2015, Javier Martinez Canillas wrote:

> The MAX77802 is a chip that contains regulators, 2 32kHz clocks,
> a RTC and an I2C interface to program the individual components.
> 
> The are already DT bindings for the regulators and clocks and
> these reference to a bindings/mfd/max77802.txt file, that didn't
> exist, for the details about the PMIC.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
> Changes in v2:
> - Use the correct "maxim,max77802" compatible string.
>   Suggested by Krzysztof Kozlowski
> - Use a pmic generic node name for the max77802 node example.
>   Suggested by Sergei Shtylyov.
> 
>  Documentation/devicetree/bindings/mfd/max77802.txt | 26 
> ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt 
> b/Documentation/devicetree/bindings/mfd/max77802.txt
> new file mode 100644
> index ..c60cdec50d36
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/max77802.txt
> @@ -0,0 +1,26 @@
> +Maxim MAX77802 multi-function device
> +
> +The Maxim MAX77802 is a power management chip (PMIC) that contains 10 high
> +efficiency Buck regulators, 32 Low-dropout (LDO) regulators used to power

Would be good to capitalise the works in the acronyms, so
"Low-DropOut" and "Power Management IC".

> +up application processors and peripherals, a 2-channel 32kHz clock outputs,
> +a Real-Time-Clock (RTC) and a I2C interface to program the individual
> +regulators, clocks outputs and the RTC.
> +
> +Binding for the built-in 32k clock generator block is defined separately
> +in the bindings/clk/maxim,max77802.txt file and binding for the regulators

s/bindings/../

> +is defined in the bindings/regulator/max77802.txt file.
> +
> +Required properties:
> +- compatible : Must be "maxim,max77802";
> +- reg : Specifies the i2c slave address of PMIC block.

s/i2c/I2C/

> +- interrupts : This i2c device has an IRQ line connected to the main SoC.

As above.

> +- interrupt-parent : The parent interrupt controller.
> +
> +Example:
> +
> + max77802: pmic@09 {
> + compatible = "maxim,max77802";
> + interrupt-parent = <&intc>;
> + interrupts = <26 0>;

Is there a define in include/dt-bindings/interrupt-controller to
replace 0?  IRQ_TYPE_NONE perhaps.

> + reg = <0x09>;
> + };

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] mfd: da9062: Support for the DA9063 OnKey in the DA9062 core

[Lee Jones]

On Mon, 20 Jul 2015, S Twiss wrote:

> From: S Twiss 
> 
> Add MFD core driver support for a OnKey component
> 
> - MFD core adds the resource da9062_onkey_resources[] for the OnKey
> - An appropriate value has been added into mfd_cell da9062_devs[] to
>   support component .name = "da9062-onkey" and
>   .of_compatible  = "dlg,da9062-onkey"
> 
> Signed-off-by: Steve Twiss 
> 
> ---
> Checks performed with linux-next/next-20150708/scripts/checkpatch.pl
>  da9062-core.c total: 0 errors, 0 warnings, 523 lines checked
> Changes in V2:
>  - No change
> 
> This patch applies against linux-next and next-20150708 
> 
> 
>  drivers/mfd/da9062-core.c | 11 +++
>  1 file changed, 11 insertions(+)

For my own reference:
  Acked-by: Lee Jones 

> diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
> index 4cf0643..0732977 100644
> --- a/drivers/mfd/da9062-core.c
> +++ b/drivers/mfd/da9062-core.c
> @@ -118,6 +118,10 @@ static struct resource da9062_wdt_resources[] = {
>   DEFINE_RES_NAMED(DA9062_IRQ_WDG_WARN, 1, "WD_WARN", IORESOURCE_IRQ),
>  };
>  
> +static struct resource da9062_onkey_resources[] = {
> + DEFINE_RES_NAMED(DA9062_IRQ_ONKEY, 1, "ONKEY", IORESOURCE_IRQ),
> +};
> +
>  static const struct mfd_cell da9062_devs[] = {
>   {
>   .name   = "da9062-core",
> @@ -141,6 +145,13 @@ static const struct mfd_cell da9062_devs[] = {
>   .resources  = da9062_thermal_resources,
>   .of_compatible  = "dlg,da9062-thermal",
>   },
> + {
> + .name   = "da9062-onkey",
> + .num_resources  = ARRAY_SIZE(da9062_onkey_resources),
> + .resources  = da9062_onkey_resources,
> + .of_compatible = "dlg,da9062-onkey",
> + },
> +
>  };
>  
>  static int da9062_clear_fault_log(struct da9062 *chip)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 3/3] devicetree: da9062: Add device tree bindings for DA9062 OnKey

[Lee Jones]

On Mon, 20 Jul 2015, S Twiss wrote:

> From: S Twiss 
> 
> Add device tree bindings for the DA9062 OnKey driver component
> 
> Signed-off-by: Steve Twiss 
> 
> ---
> Checks performed with linux-next/next-20150708/scripts/checkpatch.pl
>  da9062.txttotal: 0 errors, 0 warnings, 97 lines checked
> This patch applies against linux-next and next-20150708 
> 
> 
>  Documentation/devicetree/bindings/mfd/da9062.txt | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt 
> b/Documentation/devicetree/bindings/mfd/da9062.txt
> index 5765ed9..7752093 100644
> --- a/Documentation/devicetree/bindings/mfd/da9062.txt
> +++ b/Documentation/devicetree/bindings/mfd/da9062.txt
> @@ -5,6 +5,7 @@ DA9062 consists of a large and varied group of sub-devices:
>  Device   Supply NamesDescription
>  --   ---
>  da9062-regulator:   : LDOs & BUCKs
> +da9062-onkey:   : On Key
>  da9062-watchdog :   : Watchdog Timer
>  
>  ==
> @@ -41,6 +42,18 @@ Sub-nodes:
>Documentation/devicetree/bindings/regulator/regulator.txt
>  
>  
> +- onkey : This node defines the OnKey settings for controlling the key
> +  functionality of the device. The node should contain the compatible 
> property
> +  with the value "dlg,da9063-onkey".
> +
> +  Optional onkey properties:
> +
> +  - dlg,disable-key-power : Disable power-down using a long key-press. If 
> this
> +entry exists the OnKey driver will remove support for the KEY_POWER key
> +press. If this entry does not exist then by default the key-press
> +triggered power down is enabled and the OnKey will support both KEY_POWER
> +and KEY_SLEEP.

Child driver specifics should be separated out into other SS'
documents, in this case ../input.

>  - watchdog: This node defines the settings for the watchdog driver associated
>with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be 
> added
>if a node is created.
> @@ -59,6 +72,11 @@ Example:
>   compatible = "dlg,da9062-watchdog";
>   };
>  
> + onkey {
> + compatible = "dlg,da9063-onkey";
> + dlg,disable-key-power;
> + };
> +
>   regulators {
>   DA9062_BUCK1: buck1 {
>   regulator-name = "BUCK1";

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/2] ARM: dts: am437x-gp-evm: Add wakeup interrupt source for pixcir_i2c_tsc

[Vignesh R]

Pixcir_i2c_tsc driver can now wakeup the system from lower power state
via pinctrl and IO daisy chain using generic wakeirq framwework. Add
optional wakeup irq entry to allow pixcir_i2c_tsc to wake system from
low power state.

Signed-off-by: Vignesh R 
---

v3:
 * Drop "irq" suffix from interrupt-names.

v2:
 * Add interrupt-names property.

 arch/arm/boot/dts/am437x-gp-evm.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 84aa30c3235a..99209a137c63 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -503,6 +503,10 @@
 
attb-gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
 
+   interrupts-extended = <&gpio3 22 GPIO_ACTIVE_HIGH>,
+ <&am43xx_pinmux 0x264>;
+   interrupt-names = "tsc", "wakeup";
+
touchscreen-size-x = <1024>;
touchscreen-size-y = <600>;
};
-- 
2.4.5

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

[PATCH v3 0/2] pixcir_i2c_ts: Add optional wakeup irq support

[Vignesh R]

This is the v3 of the patch series to add optional wake irq support for
pixcir_i2c_tsc.

Tested on am437x-gp-evm, with some out of tree patches to support
suspend/resume on am437x.


Vignesh R (2):
  input: touchscreen: pixcir_i2c_ts: Add support for optional wakeup
interrupt
  ARM: dts: am437x-gp-evm: Add wakeup interrupt source for
pixcir_i2c_tsc

 arch/arm/boot/dts/am437x-gp-evm.dts   |  4 
 drivers/input/touchscreen/pixcir_i2c_ts.c | 22 ++
 include/linux/input/pixcir_ts.h   |  1 +
 3 files changed, 23 insertions(+), 4 deletions(-)

-- 
2.4.5

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

[PATCH v3 1/2] input: touchscreen: pixcir_i2c_ts: Add support for optional wakeup interrupt

[Vignesh R]

On am437x-gp-evm, pixcir touchscreen can wake the system from low power
state by generating wake-up interrupt via pinctrl and IO daisy chain.
Add support for optional wakeup interrupt source by regsitering to
automated wake IRQ framework introduced by commit 4990d4fe327b ("PM /
Wakeirq: Add automated device wake IRQ handling").
This is similar in approach to commit 2a0b965cfb6e ("serial: omap: Add
support for optional wake-up")

Signed-off-by: Vignesh R 
---

v3:
 * handle error code returned by of_irq_get_byname()

v2:
 * use of_irq_get_byname()
 * remove enable/disable_wake_irq()

 drivers/input/touchscreen/pixcir_i2c_ts.c | 22 ++
 include/linux/input/pixcir_ts.h   |  1 +
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c 
b/drivers/input/touchscreen/pixcir_i2c_ts.c
index 8f3e243a62bf..3a4ab358bf52 100644
--- a/drivers/input/touchscreen/pixcir_i2c_ts.c
+++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
@@ -29,6 +29,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define PIXCIR_MAX_SLOTS   5 /* Max fingers supported by driver */
 
@@ -364,8 +366,6 @@ static int __maybe_unused pixcir_i2c_ts_suspend(struct 
device *dev)
goto unlock;
}
}
-
-   enable_irq_wake(client->irq);
} else if (input->users) {
ret = pixcir_stop(ts);
}
@@ -386,8 +386,6 @@ static int __maybe_unused pixcir_i2c_ts_resume(struct 
device *dev)
mutex_lock(&input->mutex);
 
if (device_may_wakeup(&client->dev)) {
-   disable_irq_wake(client->irq);
-
if (!input->users) {
ret = pixcir_stop(ts);
if (ret) {
@@ -445,6 +443,13 @@ static struct pixcir_ts_platform_data 
*pixcir_parse_dt(struct device *dev)
dev_dbg(dev, "%s: x %d, y %d, gpio %d\n", __func__,
pdata->x_max + 1, pdata->y_max + 1, pdata->gpio_attb);
 
+   pdata->wakeirq = of_irq_get_byname(dev->of_node, "wakeup");
+   if (pdata->wakeirq < 0 && pdata->wakeirq != -ENODATA &&
+   pdata->wakeirq != -EINVAL) {
+   dev_err(dev, "Failed to get wakeirq\n");
+   return ERR_PTR(pdata->wakeirq);
+   }
+
return pdata;
 }
 #else
@@ -564,11 +569,20 @@ static int pixcir_i2c_ts_probe(struct i2c_client *client,
i2c_set_clientdata(client, tsdata);
device_init_wakeup(&client->dev, 1);
 
+   /* Register wakeirq */
+   error = (pdata->wakeirq > 0) ?
+   dev_pm_set_dedicated_wake_irq(dev, pdata->wakeirq) :
+   dev_pm_set_wake_irq(dev, client->irq);
+   if (error)
+   dev_info(dev, "unable to setup wakeirq %d\n",
+error);
+
return 0;
 }
 
 static int pixcir_i2c_ts_remove(struct i2c_client *client)
 {
+   dev_pm_clear_wake_irq(&client->dev);
device_init_wakeup(&client->dev, 0);
 
return 0;
diff --git a/include/linux/input/pixcir_ts.h b/include/linux/input/pixcir_ts.h
index 7bae83b7c396..da573de5a5ee 100644
--- a/include/linux/input/pixcir_ts.h
+++ b/include/linux/input/pixcir_ts.h
@@ -58,6 +58,7 @@ struct pixcir_ts_platform_data {
int x_max;
int y_max;
int gpio_attb;  /* GPIO connected to ATTB line */
+   int wakeirq;
struct pixcir_i2c_chip_data chip;
 };
 
-- 
2.4.5

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

Re: [PATCH v4 1/2] mfd: dt-bindings: add the description about dvs gpio for rk808

[Lee Jones]

On Mon, 20 Jul 2015, Chris Zhong wrote:

> add the description about dvs1, dvs2, and add the example.
> 
> Signed-off-by: Chris Zhong 
> Reviewed-by: Doug Anderson 
> 
> ---
> 
> Changes in v4:
> - Remove the description about dvs-ok
> 
> Changes in v3:
> - Modify the syntax error
> 
> Changes in v2:
> - increase description about dvs pins
> 
>  Documentation/devicetree/bindings/mfd/rk808.txt | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

Applied, thanks.

> diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt 
> b/Documentation/devicetree/bindings/mfd/rk808.txt
> index 9e6e259..4ca6aab 100644
> --- a/Documentation/devicetree/bindings/mfd/rk808.txt
> +++ b/Documentation/devicetree/bindings/mfd/rk808.txt
> @@ -24,6 +24,10 @@ Optional properties:
>  - vcc10-supply: The input supply for LDO_REG6
>  - vcc11-supply: The input supply for LDO_REG8
>  - vcc12-supply: The input supply for SWITCH_REG2
> +- dvs-gpios:  buck1/2 can be controlled by gpio dvs, this is GPIO specifiers
> +  for 2 host gpio's used for dvs. The format of the gpio specifier depends in
> +  the gpio controller. If DVS GPIOs aren't present, voltage changes will 
> happen
> +  very quickly with no slow ramp time.
>  
>  Regulators: All the regulators of RK808 to be instantiated shall be
>  listed in a child node named 'regulators'. Each regulator is represented
> @@ -55,7 +59,9 @@ Example:
>   interrupt-parent = <&gpio0>;
>   interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
>   pinctrl-names = "default";
> - pinctrl-0 = <&pmic_int>;
> + pinctrl-0 = <&pmic_int &dvs_1 &dvs_2>;
> + dvs-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>,
> + <&gpio7 15 GPIO_ACTIVE_HIGH>;
>   reg = <0x1b>;
>   rockchip,system-power-controller;
>   wakeup-source;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] MAINTAINERS: add an entry for the Maxim MAX77802 PMIC drivers

[Lee Jones]

On Fri, 17 Jul 2015, Javier Martinez Canillas wrote:

> I added support for the max77802 drivers and have been maintaining them.
> So add an entry for these drivers to make tools like get_maintainer.pl
> to work and make people submitting patches add me to the CC list.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
>  MAINTAINERS | 8 
>  1 file changed, 8 insertions(+)

Applied, thanks.

> diff --git a/MAINTAINERS b/MAINTAINERS
> index d802d19a4ecc..5d964568f207 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6570,6 +6570,14 @@ S: Supported
>  F:   drivers/power/max14577_charger.c
>  F:   drivers/power/max77693_charger.c
>  
> +MAXIM MAX77802 MULTIFUNCTION PMIC DEVICE DRIVERS
> +M:   Javier Martinez Canillas 
> +L:   linux-ker...@vger.kernel.org
> +S:   Supported
> +F:   drivers/*/*max77802.c
> +F:   Documentation/devicetree/bindings/*/*max77802.txt
> +F:   include/dt-bindings/*/*max77802.h
> +
>  MAXIM PMIC AND MUIC DRIVERS FOR EXYNOS BASED BOARDS
>  M:   Chanwoo Choi 
>  M:   Krzysztof Kozlowski 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 6/6] dts: mt8173: Add iommu/smi nodes for mt8173

[Daniel Kurtz]

Hi Yong,

On Thu, Jul 16, 2015 at 5:04 PM, Yong Wu  wrote:
>
> This patch add the iommu/larbs nodes for mt8173

To what tree does this apply?
Please rebase these patches (especially this one) on an Matthias'
current v4.2-next/for-next.


>
> Signed-off-by: Yong Wu 
> ---
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi |   81 
> ++
>  1 file changed, 81 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index e81ac1f..7b8e73c 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "mt8173-pinfunc.h"
> @@ -240,6 +241,17 @@
> reg = <0 0x10200620 0 0x20>;
> };
>
> +   iommu: mmsys_iommu@10205000 {

This name should be generic, like this (this comment really applies to
the binding patch):

   iommu: iommu@10205000

> +   compatible = "mediatek,mt8173-m4u";
> +   reg = <0 0x10205000 0 0x1000>;
> +   interrupts = ;
> +   clocks = <&infracfg CLK_INFRA_M4U>;
> +   clock-names = "bclk";
> +   mediatek,larb = <&larb0 &larb1 &larb2
> +   &larb3 &larb4 &larb5>;

Tiny nit... please align the "&".

Otherwise, this one is:

Reviewed-by: Daniel Kurtz 

Thanks!
-Dan

> +   #iommu-cells = <2>;
> +   };
> +
> apmixedsys: clock-controller@10209000 {
> compatible = "mediatek,mt8173-apmixedsys";
> reg = <0 0x10209000 0 0x1000>;
> @@ -401,29 +413,98 @@
> #clock-cells = <1>;
> };
>
> +   larb0: larb@14021000 {
> +   compatible = "mediatek,mt8173-smi-larb";
> +   reg = <0 0x14021000 0 0x1000>;
> +   mediatek,smi = <&smi_common>;
> +   power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> +   clocks = <&mmsys CLK_MM_SMI_LARB0>,
> +<&mmsys CLK_MM_SMI_LARB0>;
> +   clock-names = "apb", "smi";
> +   };
> +
> +   smi_common: smi@14022000 {
> +   compatible = "mediatek,mt8173-smi";
> +   reg = <0 0x14022000 0 0x1000>;
> +   power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> +   clocks = <&mmsys CLK_MM_SMI_COMMON>,
> +<&mmsys CLK_MM_SMI_COMMON>;
> +   clock-names = "apb", "smi";
> +   };
> +
> +   larb4: larb@14027000 {
> +   compatible = "mediatek,mt8173-smi-larb";
> +   reg = <0 0x14027000 0 0x1000>;
> +   mediatek,smi = <&smi_common>;
> +   power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> +   clocks = <&mmsys CLK_MM_SMI_LARB4>,
> +<&mmsys CLK_MM_SMI_LARB4>;
> +   clock-names = "apb", "smi";
> +   };
> +
> imgsys: imgsys@1500 {
> compatible = "mediatek,mt8173-imgsys", "syscon";
> reg = <0 0x1500 0 0x1000>;
> #clock-cells = <1>;
> };
>
> +   larb2: larb@15001000 {
> +   compatible = "mediatek,mt8173-smi-larb";
> +   reg = <0 0x15001000 0 0x1000>;
> +   mediatek,smi = <&smi_common>;
> +   power-domains = <&scpsys MT8173_POWER_DOMAIN_ISP>;
> +   clocks = <&imgsys CLK_IMG_LARB2_SMI>,
> +<&imgsys CLK_IMG_LARB2_SMI>;
> +   clock-names = "apb", "smi";
> +   };
> +
> vdecsys: vdecsys@1600 {
> compatible = "mediatek,mt8173-vdecsys", "syscon";
> reg = <0 0x1600 0 0x1000>;
> #clock-cells = <1>;
> };
>
> +   larb1: larb@1601 {
> +   compatible = "mediatek,mt8173-smi-larb";
> +   reg = <0 0x1601 0 0x1000>;
> +   mediatek,smi = <&smi_common>;
> +   power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
> +   clocks = <&vdecsys CLK_VDEC_CKEN>,
> +<&vdecsys CLK_VDEC_LARB_CKEN>;
> +   clock-names = "apb", "smi";
> +   };
> +
> vencsys: vencsys@1800 {
> compatible = "mediatek,mt8173-vencsys", "syscon";
> reg = <0 0x1800 0 0x1000>

Re: [PATCH 1/3] Documentation: dt: dwc3: Add snps,configure-fladj property

[Felipe Balbi]

On Thu, Jul 23, 2015 at 11:07:09AM +, Badola Nikhil wrote:
> > -Original Message-
> > From: Mark Rutland [mailto:mark.rutl...@arm.com]
> > Sent: Thursday, July 23, 2015 4:27 PM
> > To: Badola Nikhil-B46172
> > Cc: linux-ker...@vger.kernel.org; devicetree@vger.kernel.org; ba...@ti.com
> > Subject: Re: [PATCH 1/3] Documentation: dt: dwc3: Add snps,configure-fladj
> > property
> > 
> > On Thu, Jul 23, 2015 at 11:52:19AM +0100, Badola Nikhil wrote:
> > > > -Original Message-
> > > > From: Mark Rutland [mailto:mark.rutl...@arm.com]
> > > > Sent: Thursday, July 23, 2015 3:27 PM
> > > > To: Badola Nikhil-B46172
> > > > Cc: linux-ker...@vger.kernel.org; devicetree@vger.kernel.org;
> > > > ba...@ti.com
> > > > Subject: Re: [PATCH 1/3] Documentation: dt: dwc3: Add
> > > > snps,configure-fladj property
> > > >
> > > > On Thu, Jul 23, 2015 at 11:09:21AM +0100, Nikhil Badola wrote:
> > > > > Add property snps,configure-fladj for enabling post silicon frame
> > > > > length adjustment
> > > > >
> > > > > Signed-off-by: Nikhil Badola 
> > > > > ---
> > > > >  Documentation/devicetree/bindings/usb/dwc3.txt | 1 +
> > > > >  1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
> > > > > b/Documentation/devicetree/bindings/usb/dwc3.txt
> > > > > index 0815eac..90c3972 100644
> > > > > --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> > > > > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> > > > > @@ -40,6 +40,7 @@ Optional properties:
> > > > >   - snps,hird-threshold: HIRD threshold
> > > > >   - snps,hsphy_interface: High-Speed PHY interface selection
> > > > > between
> > > > "utmi" for
> > > > > UTMI+ and "ulpi" for ULPI when the DWC_USB3_HSPHY_INTERFACE
> > > > > has
> > > > value 3.
> > > > > + - snps,configure-fladj: enables post-silicon frame length
> > > > > + adjustment
> > > >
> > > > Could you elaborate on what this means and why you think it's
> > necessary?
> > >
> > > This property enables the use of GFLADJ_30MHZ field value of gfladj
> > > register for frame length adjustment instead of considering from the
> > sideband input signal fladj_30mhz_reg from SOC.
> > > This is required when signal fladj_30mhz_reg is connected to a wrong
> > > value or is not valid as in our case, hence post-silicon.
> > 
> > Ok, so this is basically an override for the GFLADJ_30MHZ field of the 
> > gfladj
> > register when there was a problem at integration time.
> >
> 
> That's right. 
>  
> > > However this field can be used to adjust any offset ranging from 00h
> > > to 3Fh, from the clock source generating SOF(start of frame) packets.
> > > Thus, this property can be added to device tree with appropriate
> > adjustment value.
> > 
> > It takes a value? The description above makes it sound like a boolean
> > property.
> > 
> > I'd expect a description more like:
> > 
> > - snps,fladj-override: Value for GFLADJ_30MHZ when the fladj_30mhz_reg
> >   signal is invalid or incorrect.
> > 
> > Which makes it clear what the value is and when it should be set.
> 
> Agreed. Will change and send a new version of the patch-set.

BTW, I'm not going to accept this without a glue layer making use of it.
Also, this patch needs to go to linux-usb as well, please resend.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] devicetree: xilinx: add rtc node to zynqmp dtsi

[Sören Brinkmann]

Hi Suneel,

On Thu, 2015-07-23 at 04:22PM +0530, Suneel Garapati wrote:
> adds rtc controller node to zynqmp devicetree.
> 
> Signed-off-by: Suneel Garapati 
> ---
>  arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts | 4 
>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi  | 9 +
>  2 files changed, 13 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts 
> b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
> index 0a3f40e..b48ce47 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
> @@ -45,3 +45,7 @@
>  &uart0 {
>   status = "okay";
>  };
> +
> +&rtc {
> + status = "okay";
> +};
> \ No newline at end of file
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi 
> b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> index 11e0b00..b76ede1 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> @@ -220,6 +220,15 @@
>   #size-cells = <0>;
>   };
> 
> + rtc: rtc@ffa6 {
> + compatible = "xlnx,zynqmp-rtc";
> + status = "disabled";

do we need the status disabled here?

> + reg = <0x0 0xffa6 0x100>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 26 4>, <0 27 4>;
> + interrupt-names = "alm", "sec";

Descriptive names would be nice. What is 'alm' supposed to mean?

Thanks,
Sören
--
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] MAINTAINERS: add Device Tree binding doc for max77686 regulator

[Lee Jones]

On Fri, 17 Jul 2015, Javier Martinez Canillas wrote:

> The Device Tree binding documentation for the Maxim max77686 regulators
> has been moved from the Multi-Function Device DT binding section to its
> own Documentation/devicetree/bindings/regulator/max77686.txt file.
> 
> Use a wilcard so both the mfd and regulator DT bindings are resolved.
> 
> Signed-off-by: Javier Martinez Canillas 
> ---
> 
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2af741410533..d802d19a4ecc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6583,7 +6583,7 @@ F:  drivers/extcon/extcon-max77693.c
>  F:   drivers/rtc/rtc-max77686.c
>  F:   drivers/clk/clk-max77686.c
>  F:   Documentation/devicetree/bindings/mfd/max14577.txt
> -F:   Documentation/devicetree/bindings/mfd/max77686.txt
> +F:   Documentation/devicetree/bindings/*/max77686.txt
>  F:   Documentation/devicetree/bindings/mfd/max77693.txt
>  F:   Documentation/devicetree/bindings/clock/maxim,max77686.txt
>  F:   include/linux/mfd/max14577*.h

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/11] mfd: devicetree: bindings: Add Qualcomm SMD based RPM DT binding

[Lee Jones]

On Mon, 13 Jul 2015, Bjorn Andersson wrote:

> On Tue 07 Jul 05:16 PDT 2015, Lee Jones wrote:
> 
> > FAO Mark and DT chaps,
> > 
> > > From: Bjorn Andersson 
> > > 
> > > Add binding documentation for the Qualcomm Resource Power Manager (RPM)
> > > using shared memory (Qualcomm SMD) as transport mechanism. This is found
> > > in 8974 and newer based devices.
> > > 
> > > The binding currently describes the rpm itself and the regulator
> > > subnodes.
> > > 
> > > Signed-off-by: Bjorn Andersson 
> > > ---
> > >  .../devicetree/bindings/mfd/qcom-rpm-smd.txt   | 117 
> > > +
> > >  include/dt-bindings/mfd/qcom-smd-rpm.h |  28 +
> > >  2 files changed, 145 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
> > >  create mode 100644 include/dt-bindings/mfd/qcom-smd-rpm.h
> > > 
> > > diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt 
> > > b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
> 
> [..]
> 
> > > +- qcom,smd-channels:
> > > + Usage: required
> > > + Value type: 
> > > + Definition: Shared Memory channel used for communication with the RPM
> > 
> > This is going to require a DT Ack.
> > 
> > Also, I don't see it being used anywhere.
> 
> It's a common property of all smd devices, defining the smd channel this
> driver should bind to.

Well it's not in the kernel and I can't find the patch that uses it,
so my points still stand.

> > > += EXAMPLE
> > > +
> > > + smd {
> > > + compatible = "qcom,smd";
> > 
> > Is an SMD (Shared Memory Device?) real hardware?
> > 
> 
> SMD is a mechanism for using shared memory for point-to-point
> communication channels with remote processors in all Qualcomm platforms.
> 
> So it's not hardware, it's the control mechanism for communicating with
> real hardware.

Then you can't have a node for it.  Virtual nodes which do not
represent real h/w are not allowed in Device Tree.

> > > + rpm {
> > > + interrupts = <0 168 1>;
> > > + qcom,ipc = <&apcs 8 0>;
> > > + qcom,smd-edge = <15>;
> > 
> > The child node won't probe without a compatible string.  Shouldn't
> > "qcom,rpm-msm8974" be in here instead?
> > 
> 
> These sub-nodes represents a logical grouping of the various channels
> that exist to this remote processor. For the rpm there is only the
> "rpm_requests" channel - used for sending regulator & clock requests.

Again, if it's not real h/w and don't have a proper driver, there
should be no reason for this node to exist.

> > > + rpm_requests {
> > 
> > This node appears to be undocumented.
> 
> This is the actual rpm device node, the smd & rpm nodes above are
> included for completeness of the example.
> 
> They should perhaps be dropped to make this clearer.
> 
> > Does it represent real h/w?
> > 
> 
> The other end of this smd channel is a micro controller that handles
> regulator and clock requests for the platform - so this is hardware.
> 
> This is equivalent to the qcom_rpm driver, but instead of a hardware
> like register window this uses the same packet based messaging mechanism
> that's used for other remote peripherals in the Qualcomm platform.

This needs a good review by the DT guys.

> > > + compatible = "qcom,rpm-msm8974";
> > > + qcom,smd-channels = "rpm_requests";
> > > +
> > > + pm8941-regulators {
> > > + compatible = 
> > > "qcom,rpm-pm8941-regulators";
> > > + vdd_l13_l20_l23_l24-supply = 
> > > <&pm8941_boost>;
> > 
> > I'd like Mark to glance at this.
> > 
> 
> Right.
> 
> > > + pm8941_s3: s3 {
> > > + regulator-min-microvolt = 
> > > <180>;
> > > + regulator-max-microvolt = 
> > > <180>;
> > 
> > Aren't these fixed regulators?
> > 
> 
> In this system configuration most of the regulators have fixed values,
> but the regulators (hw) are not fixed.

I'm not sure that's how it works.  I believe 'max' and 'min' should
describe the upper and lower constraints of the regulator.  The actual
value it runs it is selected elsewhere.

We still need Mark to look at this.

> > > + };
> > > +
> > > + pm8941_boost: s4 {
> > > + regulator-min-microvolt = 
> > > <500>;
> > > + regulator-max-microvolt = 
> > > <500>;
> > > + };
> > > +
> > > + pm8941_l20: l20 {
> > > + regulator-min-microvolt = 
> > > <295>;
> > > + regulator-max-microvolt = 
> > > <295>;
> > > + };
> > > +   

Re: [PATCH v6 2/2] mfd: atmel-flexcom: add a driver for Atmel Flexible Serial Communication Unit

[Boris Brezillon]

On Thu, 23 Jul 2015 10:13:11 +0100
Lee Jones  wrote:

> On Thu, 23 Jul 2015, Boris Brezillon wrote:
> 
> > Hi Lee,
> > 
> > On Thu, 23 Jul 2015 08:32:17 +0100
> > Lee Jones  wrote:
> > 
> > > On Wed, 22 Jul 2015, Cyrille Pitchen wrote:
> > > > +   for_each_child_of_node(np, child) {
> > > > +   const char *compatible;
> > > > +   int cplen;
> > > > +
> > > > +   if (!of_device_is_available(child))
> > > > +   continue;
> > > > +
> > > > +   compatible = of_get_property(child, "compatible", 
> > > > &cplen);
> > > > +   if (!compatible || strlen(compatible) > cplen)
> > > > +   continue;
> > > > +
> > > > +   if (strstr(compatible, "-usart")) {
> > > > +   opmode = FLEX_MR_OPMODE_USART;
> > > > +   break;
> > > > +   }
> > > > +
> > > > +   if (strstr(compatible, "-spi")) {
> > > > +   opmode = FLEX_MR_OPMODE_SPI;
> > > > +   break;
> > > > +   }
> > > > +
> > > > +   if (strstr(compatible, "-i2c")) {
> > > > +   opmode = FLEX_MR_OPMODE_TWI;
> > > > +   break;
> > > > +   }
> > > > +   }
> > > 
> > > From what I understand Flexcom is a wrapper which can sit above any
> > > number of SPI, I2C and/or UART devices.  Devices which you don't
> > > really have any control over (source code wise).  So wouldn't it be
> > > better to match on the details you do have control over i.e. the node
> > > name, rather than the compatible string?
> > > 
> > > I would personally match on of_find_node_by_name() to future-proof
> > > your implementation.
> > 
> > Actually, I think using compatible strings is more future-proof than
> > using the node names, because nothing in the DT bindings doc enforce the
> > node name, and usually what we use to attach a node to a specific
> > driver is the compatible string (this one is specified in the bindings
> > doc).
> 
> I know what you're saying, but what if someone uses the Flexcom driver
> to wrap a different type of SPI driver where (for instance) the
> compatible string used is "-".  Then we'd have to keep
> adding more lines here to accommodate.
> 
> Whereas if we used the child node name which only pertains to _this_
> driver, we would then have full control and know that (unless it
> Flexcom is used for a completely different type of serial controller)
> we wouldn't have to keep expanding the code to accommodate.

You're right about the complexity implied by the compat string
maintenance, but I still think using node names to detect the mode is
a bad idea.

Let's take another example making both solution unsuitable: what if
the flexcom-v2 exposes 2 devices of the same type, they will both have
the same name and the same compatible string, and we'll have no way to
detect the appropriate mode. That's why I think none of our suggestion
is future-proof.

> 
> > Regarding the implementation itself, I would match the child node with
> > an of_device_id table rather than trying to find a specific substring
> > in the compatible string, but I think that's only a matter of taste.
> 
> You mean duplicate each of the supported device's compatible strings
> in this driver, then fetch the attributed of_match_device()->data
> value?
> 

Yes, and that's definitely not a good idea, but I think Cyrille has
found a better approach (I'll let him explain).

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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: [NET-NEXT PATCH] net: macb: Change capability mask for jumbo support

[Alexandre Belloni]

On 23/07/2015 at 15:44:25 +0530, Harini Katakam wrote :
> JUMBO and NO_GIGABIT_HALF have the same capability masks.
> Change one of them.
> 
> Signed-off-by: Harini Katakam 
Acked-by: Alexandre Belloni 


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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: [NET-NEXT PATCH] net: macb: Change capability mask for jumbo support

[Nicolas Ferre]

Le 23/07/2015 12:14, Harini Katakam a écrit :
> JUMBO and NO_GIGABIT_HALF have the same capability masks.
> Change one of them.
> 
> Signed-off-by: Harini Katakam 

Yes, indeed:
Acked-by: Nicolas Ferre 

> ---
>  drivers/net/ethernet/cadence/macb.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/cadence/macb.h 
> b/drivers/net/ethernet/cadence/macb.h
> index d746559..8fb80b2 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -399,7 +399,7 @@
>  #define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x2000
>  #define MACB_CAPS_SG_DISABLED0x4000
>  #define MACB_CAPS_MACB_IS_GEM0x8000
> -#define MACB_CAPS_JUMBO  0x0008
> +#define MACB_CAPS_JUMBO  0x0010
>  
>  /* Bit manipulation macros */
>  #define MACB_BIT(name)   \
> 


-- 
Nicolas Ferre
--
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] devicetree: xilinx: add rtc node to zynqmp dtsi

[Suneel Garapati]

adds rtc controller node to zynqmp devicetree.

Signed-off-by: Suneel Garapati 
---
 arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts | 4 
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi  | 9 +
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts 
b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
index 0a3f40e..b48ce47 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
@@ -45,3 +45,7 @@
 &uart0 {
status = "okay";
 };
+
+&rtc {
+   status = "okay";
+};
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi 
b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 11e0b00..b76ede1 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -220,6 +220,15 @@
#size-cells = <0>;
};

+   rtc: rtc@ffa6 {
+   compatible = "xlnx,zynqmp-rtc";
+   status = "disabled";
+   reg = <0x0 0xffa6 0x100>;
+   interrupt-parent = <&gic>;
+   interrupts = <0 26 4>, <0 27 4>;
+   interrupt-names = "alm", "sec";
+   };
+
spi0: spi@ff04 {
compatible = "cdns,spi-r1p6";
status = "disabled";
--
2.1.2
--
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] ARM: dts: Use stdout-path in STM32F429 Discovery board

[Andreas Färber]

Am 23.07.2015 um 07:09 schrieb Maxime Coquelin:
> This patch replaces use of linux,stdout-path by stdout-path as per

s/by/with/

> "chosen" DT bindings documentation.
> 
> Doing that, the "console" argument is no more needed in kernel command
> line.
> 
> Reported-by: Olof Johansson 
> Signed-off-by: Maxime Coquelin 
> ---
>  arch/arm/boot/dts/stm32f429-disco.dts | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Other than that,

Reviewed-by: Andreas Färber 

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/3] Documentation: dt: dwc3: Add snps,configure-fladj property

[Badola Nikhil]

> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Thursday, July 23, 2015 4:27 PM
> To: Badola Nikhil-B46172
> Cc: linux-ker...@vger.kernel.org; devicetree@vger.kernel.org; ba...@ti.com
> Subject: Re: [PATCH 1/3] Documentation: dt: dwc3: Add snps,configure-fladj
> property
> 
> On Thu, Jul 23, 2015 at 11:52:19AM +0100, Badola Nikhil wrote:
> > > -Original Message-
> > > From: Mark Rutland [mailto:mark.rutl...@arm.com]
> > > Sent: Thursday, July 23, 2015 3:27 PM
> > > To: Badola Nikhil-B46172
> > > Cc: linux-ker...@vger.kernel.org; devicetree@vger.kernel.org;
> > > ba...@ti.com
> > > Subject: Re: [PATCH 1/3] Documentation: dt: dwc3: Add
> > > snps,configure-fladj property
> > >
> > > On Thu, Jul 23, 2015 at 11:09:21AM +0100, Nikhil Badola wrote:
> > > > Add property snps,configure-fladj for enabling post silicon frame
> > > > length adjustment
> > > >
> > > > Signed-off-by: Nikhil Badola 
> > > > ---
> > > >  Documentation/devicetree/bindings/usb/dwc3.txt | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
> > > > b/Documentation/devicetree/bindings/usb/dwc3.txt
> > > > index 0815eac..90c3972 100644
> > > > --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> > > > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> > > > @@ -40,6 +40,7 @@ Optional properties:
> > > >   - snps,hird-threshold: HIRD threshold
> > > >   - snps,hsphy_interface: High-Speed PHY interface selection
> > > > between
> > > "utmi" for
> > > > UTMI+ and "ulpi" for ULPI when the DWC_USB3_HSPHY_INTERFACE
> > > > has
> > > value 3.
> > > > + - snps,configure-fladj: enables post-silicon frame length
> > > > + adjustment
> > >
> > > Could you elaborate on what this means and why you think it's
> necessary?
> >
> > This property enables the use of GFLADJ_30MHZ field value of gfladj
> > register for frame length adjustment instead of considering from the
> sideband input signal fladj_30mhz_reg from SOC.
> > This is required when signal fladj_30mhz_reg is connected to a wrong
> > value or is not valid as in our case, hence post-silicon.
> 
> Ok, so this is basically an override for the GFLADJ_30MHZ field of the gfladj
> register when there was a problem at integration time.
>

That's right. 
 
> > However this field can be used to adjust any offset ranging from 00h
> > to 3Fh, from the clock source generating SOF(start of frame) packets.
> > Thus, this property can be added to device tree with appropriate
> adjustment value.
> 
> It takes a value? The description above makes it sound like a boolean
> property.
> 
> I'd expect a description more like:
> 
> - snps,fladj-override: Value for GFLADJ_30MHZ when the fladj_30mhz_reg
>   signal is invalid or incorrect.
> 
> Which makes it clear what the value is and when it should be set.

Agreed. Will change and send a new version of the patch-set.

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

RE: [PATCH 3/3] arm: dts: ls1021a: Add snps,configure-gfladj property to USB3 node

[Badola Nikhil]

> -Original Message-
> From: Alexander Stein [mailto:alexander.st...@systec-electronic.com]
> Sent: Thursday, July 23, 2015 3:41 PM
> To: Badola Nikhil-B46172
> Cc: linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org
> Subject: Re: [PATCH 3/3] arm: dts: ls1021a: Add snps,configure-gfladj
> property to USB3 node
> 
> On Thursday 23 July 2015 15:42:58, Nikhil Badola wrote:
> > Add "snps,configure-gfladj" boolean property to USB3 node. This
> > property
>   ^^
> This does not match...
> 
> > is used to determine if frame length adjustment is required
> >
> > Signed-off-by: Nikhil Badola 
> > ---
> >  arch/arm/boot/dts/ls1021a.dtsi | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/boot/dts/ls1021a.dtsi
> > b/arch/arm/boot/dts/ls1021a.dtsi index c70bb27..f03f842 100644
> > --- a/arch/arm/boot/dts/ls1021a.dtsi
> > +++ b/arch/arm/boot/dts/ls1021a.dtsi
> > @@ -404,6 +404,7 @@
> > reg = <0x0 0x310 0x0 0x1>;
> > interrupts = ;
> > dr_mode = "host";
> > +   snps,configure-fladj = <0x20>;
>  ^
> ...that. The same is for the subject. I guess these "gfladj" are just 
> leftovers as
> patch 1 & 2 talk about "fladj"

Fladj stands for Frame Length ADJustment whereas the register used for this is 
gfladj.
Yes we intend to override fladj, hence using fladj in patch 1 and 2. I will 
remove gladj from 
subject and description.
Further, I will be changing the property to "snps,fladj-override" as suggested 
by Mark in patch 1
and send next patch version.
Please let me know if there are any other comments. 

> 
> Best regards,
> Alexander
> --
> Dipl.-Inf. Alexander Stein
> SYS TEC electronic GmbH
> alexander.st...@systec-electronic.com
> 
> Legal and Commercial Address:
> Am Windrad 2
> 08468 Heinsdorfergrund
> Germany
> 
> Office: +49 (0) 3765 38600-0
> Fax:+49 (0) 3765 38600-4100
> 
> Managing Directors:
>   Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
>   Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
> Commercial Registry:
>   Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010

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

Re: [PATCH v3 1/1] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation

[Lee Jones]

On Thu, 23 Jul 2015, Viresh Kumar wrote:

> Cc'ing few more people who were involved in opp-v2 discussions.
> 
> Guys, please take a closer look as this is the first user platform
> that wants to extend opp-v2 bindings with platform specific stuff.
> 
> On 21-07-15, 12:33, Lee Jones wrote:
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Lee Jones 
> > ---
> > 
> > Only submitting the binding document as requested by Viresh.
> > 
> > v2 => v3:
> >  - Using OPP v2
> >  - Moved OPPs out of the CPU node into their own one
> >  - Using generic 'opp-hz' property
> > 
> >  .../devicetree/bindings/cpufreq/cpufreq-st.txt | 77 
> > ++
> >  1 file changed, 77 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt 
> > b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> > new file mode 100644
> > index 000..a478eec
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> 
> These are used by cpufreq, but they aren't really cpufreq bindings.
> 
> These are opp bindings and must present at:
> Documentation/devicetree/bindings/power/opp/st.txt and we should move
> opp.txt in that folder as well..

Sure.

> > @@ -0,0 +1,77 @@
> > +Binding for ST's CPUFreq driver
> > +===
> > +
> > +Required properties [for working voltage scaling]:
> > +-
> > +
> > +Located in CPU's node:
> 
> I hope below registers are used to define which OPPs are valid for the
> CPU and so shouldn't these be present under opp node instead of CPU?

Yes, I neglected to change this when I moved the other bindings.

Will change.

> > +- st,syscfg: Phandle to Major number register
> > +   First cell: offset to major number
> > +- st,syscfg-eng: Phandle to Minor number and Pcode registers
> > +   First cell: offset to process code
> > +   Second cell: offset to minor number
> > +
> > +Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]:
> > +
> > + - opp{1..N}   : Each 'oppX' subnode will contain the 
> > following properties:
> > +  - opp-hz : CPU frequency [Hz] for this OPP
> 
> Not sure if you are required to re define it. In case you want to, the
> please add a link here to the bindings that define it. So that we
> don't think they are newer bindings.

Sure.

> > +  - st,avs : List of available voltages [uV] indexed by process 
> > code
> > +  - st,cuts: Cut version this OPP is suitable for [0xFF 
> > means ALL]
> > +  - st,substrate   : Substrate version this OPP is suitable for [0xFF 
> > means ALL]
> 
> @Stephen: Any idea if these can be relevant for other platforms and we
> can move them to generic bindings?
> 
> > +WARNING: The cpu0-opp-list will be provided by the bootloader.  Do not 
> > attempt to
> > +artificially synthesise the cpu0-opp-list node or any of its 
> > descendants.
> > +They are very platform specific and may damage the hardware if created
> > +incorrectly.
> > +
> > +Required properties [if voltage scaling properties are missing]:
> > +---
> > +
> > +Located in CPU's node:
> > +
> > +- operating-points : [See: ../power/opp.txt]
> > +
> > +Example [safe]:
> > +--
> > +
> > +cpus {
> > +   cpu@0 {
> > +/* kHz uV   */
> > +   operating-points = <150 0
> > +   120 0
> > +   80  0
> > +   50  0>;
> > +   };
> > +};
> 
> Why do you want to keep these as well?

We need this as a fall-back, in case anyone boots using a bootloader
which isn't equipped to supply the OPP list.  If this happens we can
not use voltage scaling and he best thing we can do is operate using
only frequency scaling.

> > +Example [unsafe]:
> > +
> > +
> > +cpus {
> > +   cpu@0 {
> > +   st,syscfg   = <&syscfg [major_offset]>;
> > +   st,syscfg-eng   = <&syscfg_eng [pcode_offset] 
> > [minor_offset]>;
> > +   operating-points-v2 = <&cpu0_opp_list>;
> > +   };
> > +};
> > +
> > +/*  */
> > +/* # WARNING: Do not attempt to copy/replicate this node, # */
> > +/* #  it is only to be supplied by the bootloader !!! # */
> > +/*  */
> > +cpu0-opp-list {
> > +   compatible = "operating-points-v2-sti";
> > +   opp0 {
> > +   opp-hz  = <12>;
> > +   st,avs  = <1110 1150 1100 1080 1040 1020 980 930>;
> > +   st,substrate= <0xff>;
> > +   st,cuts = <0xff>;
> > +   };
> > +

[PATCH v5 1/8] Documentation: add DT binding for ARM System Control and Power Interface(SCPI) protocol

[Sudeep Holla]

This patch adds devicetree binding for System Control and Power
Interface (SCPI) Message Protocol used between the Application Cores(AP)
and the System Control Processor(SCP). The MHU peripheral provides a
mechanism for inter-processor communication between SCP's M3 processor
and AP.

SCP offers control and management of the core/cluster power states,
various power domain DVFS including the core/cluster, certain system
clocks configuration, thermal sensors and many others.

Signed-off-by: Sudeep Holla 
Cc: Rob Herring 
Cc: Mark Rutland 
CC: Jassi Brar 
Cc: Liviu Dudau 
Cc: Lorenzo Pieralisi 
Cc: Jon Medhurst (Tixy) 
Cc: devicetree@vger.kernel.org
---
 Documentation/devicetree/bindings/arm/arm,scpi.txt | 151 +
 MAINTAINERS|   6 +
 2 files changed, 157 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/arm,scpi.txt

diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt 
b/Documentation/devicetree/bindings/arm/arm,scpi.txt
new file mode 100644
index ..e21cce646561
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -0,0 +1,151 @@
+System Control and Power Interface (SCPI) Message Protocol
+--
+
+Firmware implementing the SCPI described in ARM document number ARM DUI 0922B
+("ARM Compute Subsystem SCP: Message Interface Protocols")[0] can be used
+by Linux to initiate various system control and power operations.
+
+Required properties:
+
+- compatible : should be "arm,scpi"
+- mboxes: List of phandle and mailbox channel specifiers
+ All the channels reserved by remote SCP firmware for use by
+ SCPI message protocol should be specified in any order
+- shmem : List of phandle pointing to the shared memory(SHM) area between the
+ processors using these mailboxes for IPC, one for each mailbox
+ SHM can be any memory reserved for the purpose of this communication
+ between the processors.
+
+See Documentation/devicetree/bindings/mailbox/mailbox.txt
+for more details about the generic mailbox controller and
+client driver bindings.
+
+Clock bindings for the clocks based on SCPI Message Protocol
+
+
+This binding uses the common clock binding[1].
+
+Container Node
+==
+Required properties:
+- compatible : should be "arm,scpi-clocks"
+  All the clocks provided by SCP firmware via SCPI message
+  protocol much be listed as sub-nodes under this node.
+
+Sub-nodes
+=
+Required properties:
+- compatible : shall include one of the following
+   "arm,scpi-dvfs-clocks" - all the clocks that are variable and index 
based.
+   These clocks don't provide an entire range of values between the
+   limits but only discrete points within the range. The firmware
+   provides the mapping for each such operating frequency and the
+   index associated with it. The firmware also manages the
+   voltage scaling appropriately with the clock scaling.
+   "arm,scpi-variable-clocks" - all the clocks that are variable and 
provide full
+   range within the specified range. The firmware provides the
+   range of values within a specified range.
+
+Other required properties for all clocks(all from common clock binding):
+- #clock-cells : should be set to 1 as each of the SCPI clocks have multiple
+   outputs.
+- clock-output-names : shall be the corresponding names of the outputs.
+- clock-indices: The identifying number for the clocks(i.e.clock_id) in the
+   node. It can be non linear and hence provide the mapping of identifiers
+   into the clock-output-names array.
+
+SRAM and Shared Memory for SCPI
+---
+
+A small area of SRAM is reserved for SCPI communication between application
+processors and SCP.
+
+Required properties:
+- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
+
+The rest of the properties should follow the generic mmio-sram description
+found in ../../misc/sysram.txt
+
+Each sub-node represents the reserved area for SCPI.
+
+Required sub-node properties:
+- reg : The base offset and size of the reserved area with the SRAM
+- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
+  shared memory on Juno platforms
+
+[0] 
http://community.arm.com/servlet/JiveServlet/download/8401-45-18326/DUI0922B_scp_message_interface.pdf
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Example:
+
+sram: sram@5000 {
+   compatible = "arm,juno-sram-ns", "mmio-sram";
+   reg = <0x0 0x5000 0x0 0x1>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x0 0x5000 0x1>;
+
+   cpu_scp_lpri: scp-shmem@0 {
+   compatible = "arm,juno-scp-shmem";
+   reg =

RE: [PATCH 1/3] Documentation: dt: dwc3: Add snps,configure-fladj property

[Badola Nikhil]

> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Thursday, July 23, 2015 3:27 PM
> To: Badola Nikhil-B46172
> Cc: linux-ker...@vger.kernel.org; devicetree@vger.kernel.org; ba...@ti.com
> Subject: Re: [PATCH 1/3] Documentation: dt: dwc3: Add snps,configure-fladj
> property
> 
> On Thu, Jul 23, 2015 at 11:09:21AM +0100, Nikhil Badola wrote:
> > Add property snps,configure-fladj for enabling post silicon frame
> > length adjustment
> >
> > Signed-off-by: Nikhil Badola 
> > ---
> >  Documentation/devicetree/bindings/usb/dwc3.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
> > b/Documentation/devicetree/bindings/usb/dwc3.txt
> > index 0815eac..90c3972 100644
> > --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> > @@ -40,6 +40,7 @@ Optional properties:
> >   - snps,hird-threshold: HIRD threshold
> >   - snps,hsphy_interface: High-Speed PHY interface selection between
> "utmi" for
> > UTMI+ and "ulpi" for ULPI when the DWC_USB3_HSPHY_INTERFACE has
> value 3.
> > + - snps,configure-fladj: enables post-silicon frame length adjustment
> 
> Could you elaborate on what this means and why you think it's necessary?

This property enables the use of GFLADJ_30MHZ field value of gfladj register 
for frame length 
adjustment instead of considering from the sideband input signal 
fladj_30mhz_reg from SOC. 
This is required when signal fladj_30mhz_reg is connected to a wrong value or 
is not valid as 
in our case, hence post-silicon.

However this field can be used to adjust any offset ranging from 00h to 3Fh, 
from the
clock source generating SOF(start of frame) packets. Thus, this property can be 
added to device 
tree with appropriate adjustment value.

> 
> >
> >  This is usually a subnode to DWC3 glue to which it is connected.
> >
> > --
> > 2.1.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree"
> > in the body of a message to majord...@vger.kernel.org More
> majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> >
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] Documentation: dt: dwc3: Add snps,configure-fladj property

[Mark Rutland]

On Thu, Jul 23, 2015 at 11:52:19AM +0100, Badola Nikhil wrote:
> > -Original Message-
> > From: Mark Rutland [mailto:mark.rutl...@arm.com]
> > Sent: Thursday, July 23, 2015 3:27 PM
> > To: Badola Nikhil-B46172
> > Cc: linux-ker...@vger.kernel.org; devicetree@vger.kernel.org; ba...@ti.com
> > Subject: Re: [PATCH 1/3] Documentation: dt: dwc3: Add snps,configure-fladj
> > property
> > 
> > On Thu, Jul 23, 2015 at 11:09:21AM +0100, Nikhil Badola wrote:
> > > Add property snps,configure-fladj for enabling post silicon frame
> > > length adjustment
> > >
> > > Signed-off-by: Nikhil Badola 
> > > ---
> > >  Documentation/devicetree/bindings/usb/dwc3.txt | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
> > > b/Documentation/devicetree/bindings/usb/dwc3.txt
> > > index 0815eac..90c3972 100644
> > > --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> > > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> > > @@ -40,6 +40,7 @@ Optional properties:
> > >   - snps,hird-threshold: HIRD threshold
> > >   - snps,hsphy_interface: High-Speed PHY interface selection between
> > "utmi" for
> > > UTMI+ and "ulpi" for ULPI when the DWC_USB3_HSPHY_INTERFACE has
> > value 3.
> > > + - snps,configure-fladj: enables post-silicon frame length adjustment
> > 
> > Could you elaborate on what this means and why you think it's necessary?
> 
> This property enables the use of GFLADJ_30MHZ field value of gfladj register 
> for frame length 
> adjustment instead of considering from the sideband input signal 
> fladj_30mhz_reg from SOC. 
> This is required when signal fladj_30mhz_reg is connected to a wrong value or 
> is not valid as 
> in our case, hence post-silicon.

Ok, so this is basically an override for the GFLADJ_30MHZ field of the
gfladj register when there was a problem at integration time.

> However this field can be used to adjust any offset ranging from 00h to 3Fh, 
> from the
> clock source generating SOF(start of frame) packets. Thus, this property can 
> be added to device 
> tree with appropriate adjustment value.

It takes a value? The description above makes it sound like a boolean
property.

I'd expect a description more like:

- snps,fladj-override: Value for GFLADJ_30MHZ when the fladj_30mhz_reg
  signal is invalid or incorrect.

Which makes it clear what the value is and when it should be set.

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