[PATCH v4 2/3] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()

[Anup Patel]

Just like other NAND controllers, the NAND READID command only works
in 8bit mode for all versions of BRCMNAND controller.

This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
before doing nand_scan_ident() to ensure that BRCMNAND controller
is in 8bit mode when NAND READID command is issued.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c
index dda96fa..641591d 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1912,6 +1912,7 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
struct mtd_info *mtd;
struct nand_chip *chip;
int ret;
+   u16 cfg_offs;
struct mtd_part_parser_data ppdata = { .of_node = dn };
 
ret = of_property_read_u32(dn, "reg", >cs);
@@ -1954,6 +1955,15 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
 
chip->controller = >controller;
 
+   /*
+* The bootloader might have configured 16bit mode but
+* NAND READID command only works in 8bit mode. We force
+* 8bit mode here to ensure that NAND READID commands works.
+*/
+   cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
+   nand_writereg(ctrl, cfg_offs,
+ nand_readreg(ctrl, cfg_offs) & CFG_BUS_WIDTH);
+
if (nand_scan_ident(mtd, 1, NULL))
return -ENXIO;
 
-- 
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 v4 0/3] NAND support for Broadcom NS2 SoC

[Anup Patel]

We enable NAND support for Broadcom NS2 SoC by reusing existing
BRCMNAND driver.

This patchset applies on-top of "arm64: Simple additions to
NS2 DT" v1 patchset and is available in ns2_nand_v4 branch of
https://github.com/Broadcom/arm64-linux.git.

The patchset is tested on NS2 SVK.

Changes since v3:
 - Include Brian's patch for magic number cleanup related to
   CFG and CFG_EXT registers
 - Base patch1 of v3 patchset upon Brian's cleanup patch

Changes since v2:
 - Dropped patch1 and patch2 because these are already merged
   by MTD maintainer.
 - Avoid using absolute node paths in ns2-svk.dts.

Changes since v1:
 - Dropped patch3 and patch4 because we don't need to reset
   BRCMNAND controller for NS2.
 - Added patch to force 8bit mode before doing nand_scan_ident()
   in brcmnand_init_cs().

Anup Patel (2):
  mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
  arm64: dts: Add BRCM IPROC NAND DT node for NS2

Brian Norris (1):
  mtd: brcmnand: factor out CFG and CFG_EXT bitfields

 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 +---
 arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
 drivers/mtd/nand/brcmnand/brcmnand.c | 48 +++-
 3 files changed, 75 insertions(+), 17 deletions(-)

-- 
1.9.1

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

Re: [PATCH 0/3] dmaengine: ti-dma-crossbar: channel reserving and edma3-tcc support

[Peter Ujfalusi]

Vinod,

On 10/29/2015 10:28 AM, Peter Ujfalusi wrote:
> Hi,
> 
> This series depends on the eDMA work I have done, which has been now applied:
> https://lkml.org/lkml/2015/10/16/64
> 
> DRA7 family of chips have both sDMA and eDMA. Currently only sDMA can be used
> becasue the old driver stack for eDMA did not allowed integration w/o hacks.
> 
> Due to the nature of eDMA the crossbar needs to know which eDMA events it can
> use to map incoming events towards the eDMA. In eDMA a channel is wired to be
> used with one specific event. For example eDMA event 14 can only be handled by
> eDMA channel 14.
> The eDMA itself can be shared by different processors in the system (ARM, DSP,
> etc) and since ARM/Linux is the master we need to know which channels are used
> by other cores. Also we need to mask out channels used for memcpy from the
> events we use for HW triggers.

Please ignore this series, I have found some issue with it and I just started
to debug it. Will post V2 as soon as I found the problem.

> 
> Regards,
> Peter
> ---
> Peter Ujfalusi (3):
>   dmaengine: ti-dma-crossbar: dra7: Use bitops instead of idr
>   dmaengine: ti-dma-crossbar: dra7: Support for reserving DMA event
> ranges
>   dmaengine: ti-dma-crossbar: dra7: Support for eDMA with new bindings
> 
>  .../devicetree/bindings/dma/ti-dma-crossbar.txt|  6 ++
>  drivers/dma/ti-dma-crossbar.c  | 81 
> +++---
>  2 files changed, 76 insertions(+), 11 deletions(-)
> 


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

Re: [PATCH v5 1/4] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC

[Krzysztof Kozlowski]

On 30.10.2015 15:25, Alim Akhtar wrote:
> From: Thomas Abraham 
> 
> Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device
> is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators.
> This also supports RTC and three 32.768KHz clock outputs.
> 
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Thomas Abraham 
> Signed-off-by: Alim Akhtar 
> ---
>  Documentation/devicetree/bindings/mfd/s2mps11.txt |   21 
> ++---
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 

Reviewed-by: Krzysztof Kozlowski 

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 v4 2/4] ARM: dts: Add SROMc to Exynos 5410

[Pavel Fedin]

 Hello!

> -Original Message-
> From: linux-samsung-soc-ow...@vger.kernel.org 
> [mailto:linux-samsung-soc-ow...@vger.kernel.org]
> On Behalf Of Pankaj Dubey
> Sent: Thursday, October 29, 2015 8:28 PM
> To: Pavel Fedin
> Cc: devicetree@vger.kernel.org; linux-arm-ker...@lists.infradead.org; 
> linux-samsung-soc;
> linux-ker...@vger.kernel.org; Rob Herring; Pawel Moll; Mark Rutland; Ian 
> Campbell; Kumar Gala;
> Kukjin Kim; Krzysztof Kozlowski
> Subject: Re: [PATCH v4 2/4] ARM: dts: Add SROMc to Exynos 5410
> 
> Hi Pavel,
> 
> On 29 October 2015 at 18:12, Pavel Fedin  wrote:
> > This machine uses own SoC device tree file, add missing part.
> >
> > Signed-off-by: Pavel Fedin 
> > ---
> >  arch/arm/boot/dts/exynos5410.dtsi | 15 +++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos5410.dtsi 
> > b/arch/arm/boot/dts/exynos5410.dtsi
> > index 4603356..da6a8fa0e 100644
> > --- a/arch/arm/boot/dts/exynos5410.dtsi
> > +++ b/arch/arm/boot/dts/exynos5410.dtsi
> > @@ -101,6 +101,15 @@
> > reg = <0x1000 0x100>;
> > };
> >
> > +   sromc: sromc@1225 {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   ranges;
> > +
> 
> We do not need to specify these three properties as they are already
> present in parent node "soc".

 We do, otherwise dtc complains about defaults of #address-cells = 2 and 
#size-cells=1, and without empty "ranges" subnode's resources are not correctly 
translated.

> 
> > +   compatible = "samsung,exynos-srom";
> > +   reg = <0x1225 0x14>;
> > +   };
> > +
> > pmu_system_controller: system-controller@1004 {
> > compatible = "samsung,exynos5410-pmu", "syscon";
> > reg = <0x1004 0x5000>;
> > @@ -133,6 +142,12 @@
> > <10  0 130 0>,
> > <11  0 131 0>;
> > };
> > +
> > +   arch_timer {
> > +   compatible = "arm,armv7-timer";
> > +   clock-frequency = <2400>;
> > +   };
> > +
> 
> This change should not be part of this patch.

 Ooops, thank you very much, this should not have been here at all. This is a 
leftover from my experiments, i was tracing DT parsing code and added it just 
for test, to see why timer gets probed as a subnode.
 Just forgot to remove it afterwards and it slipped into the patch.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

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

[PATCH v2 2/3] dmaengine: ti-dma-crossbar: dra7: Support for reserving DMA event ranges

[Peter Ujfalusi]

In eDMA the events are directly mapped to a DMA channel (for example DMA
event 14 can only be handled by DMA channel 14). If the memcpy is enabled
on the eDMA, there is a possibility that the crossbar driver would assign
DMA event number already allocated in eDMA for memcpy. Furthermore the
eDMA can be shared with DSP in which case the crossbar driver should also
avoid mapping xbar events to DSP used event numbers (or channels).

Signed-off-by: Peter Ujfalusi 
---
 .../devicetree/bindings/dma/ti-dma-crossbar.txt|  6 +++
 drivers/dma/ti-dma-crossbar.c  | 47 --
 2 files changed, 49 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt 
b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
index b152a75dceae..aead5869a28d 100644
--- a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
+++ b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
@@ -14,6 +14,10 @@ The DMA controller node need to have the following 
poroperties:
 
 Optional properties:
 - ti,dma-safe-map: Safe routing value for unused request lines
+- ti,reserved-dma-request-ranges: DMA request ranges which should not be used
+   when mapping xbar input to DMA request, they are either
+   allocated to be used by for example the DSP or they are used as
+   memcpy channels in eDMA.
 
 Notes:
 When requesting channel via ti,dra7-dma-crossbar, the DMA clinet must request
@@ -46,6 +50,8 @@ sdma_xbar: dma-router@4a002b78 {
#dma-cells = <1>;
dma-requests = <205>;
ti,dma-safe-map = <0>;
+   /* Protect the sDMA request ranges: 10-14 and 100-126 */
+   ti,reserved-dma-request-ranges = <10 5>, <100 27>;
dma-masters = <>;
 };
 
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 463ad6b18a32..dac7ae06cc58 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -292,14 +292,22 @@ static const struct of_device_id ti_dra7_master_match[] = 
{
{},
 };
 
+static inline void ti_dra7_xbar_reserve(int offset, int len, unsigned long *p)
+{
+   for (; len > 0; len--)
+   clear_bit(offset + (len - 1), p);
+}
+
 static int ti_dra7_xbar_probe(struct platform_device *pdev)
 {
struct device_node *node = pdev->dev.of_node;
const struct of_device_id *match;
struct device_node *dma_node;
struct ti_dra7_xbar_data *xbar;
+   struct property *prop;
struct resource *res;
u32 safe_val;
+   size_t sz;
void __iomem *iomem;
int i, ret;
 
@@ -347,6 +355,33 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
if (!of_property_read_u32(node, "ti,dma-safe-map", _val))
xbar->safe_val = (u16)safe_val;
 
+
+   prop = of_find_property(node, "ti,reserved-dma-request-ranges", );
+   if (prop) {
+   const char pname[] = "ti,reserved-dma-request-ranges";
+   u32 (*rsv_events)[2];
+   size_t nelm = sz / sizeof(*rsv_events);
+   int i;
+
+   if (!nelm)
+   return -EINVAL;
+
+   rsv_events = kcalloc(nelm, sizeof(*rsv_events), GFP_KERNEL);
+   if (!rsv_events)
+   return -ENOMEM;
+
+   ret = of_property_read_u32_array(node, pname, (u32 *)rsv_events,
+nelm * 2);
+   if (ret)
+   return ret;
+
+   for (i = 0; i < nelm; i++) {
+   ti_dra7_xbar_reserve(rsv_events[i][0], rsv_events[i][1],
+xbar->dma_inuse);
+   }
+   kfree(rsv_events);
+   }
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
iomem = devm_ioremap_resource(>dev, res);
if (IS_ERR(iomem))
@@ -362,15 +397,19 @@ static int ti_dra7_xbar_probe(struct platform_device 
*pdev)
platform_set_drvdata(pdev, xbar);
 
/* Reset the crossbar */
-   for (i = 0; i < xbar->dma_requests; i++)
-   ti_dra7_xbar_write(xbar->iomem, i, xbar->safe_val);
+   for (i = 0; i < xbar->dma_requests; i++) {
+   if (!test_bit(i, xbar->dma_inuse))
+   ti_dra7_xbar_write(xbar->iomem, i, xbar->safe_val);
+   }
 
ret = of_dma_router_register(node, ti_dra7_xbar_route_allocate,
 >dmarouter);
if (ret) {
/* Restore the defaults for the crossbar */
-   for (i = 0; i < xbar->dma_requests; i++)
-   ti_dra7_xbar_write(xbar->iomem, i, i);
+   for (i = 0; i < xbar->dma_requests; i++) {
+   if (!test_bit(i, xbar->dma_inuse))
+   ti_dra7_xbar_write(xbar->iomem, i, i);
+   }
}
 
return ret;
-- 
2.6.1

[PATCH v2 1/3] dmaengine: ti-dma-crossbar: dra7: Use bitops instead of idr

[Peter Ujfalusi]

The use of idr was nice, but it was a bit heavy and we did not need the
features it provides. Using simple bitmap to track allocated DMA channels
is adequate here and it will be easier to add support for reserving
channels later on.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/ti-dma-crossbar.c | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index a415edbe61b1..463ad6b18a32 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -198,7 +197,8 @@ struct ti_dra7_xbar_data {
void __iomem *iomem;
 
struct dma_router dmarouter;
-   struct idr map_idr;
+   struct mutex mutex;
+   unsigned long *dma_inuse;
 
u16 safe_val; /* Value to rest the crossbar lines */
u32 xbar_requests; /* number of DMA requests connected to XBAR */
@@ -225,7 +225,9 @@ static void ti_dra7_xbar_free(struct device *dev, void 
*route_data)
map->xbar_in, map->xbar_out);
 
ti_dra7_xbar_write(xbar->iomem, map->xbar_out, xbar->safe_val);
-   idr_remove(>map_idr, map->xbar_out);
+   mutex_lock(>mutex);
+   clear_bit(map->xbar_out, xbar->dma_inuse);
+   mutex_unlock(>mutex);
kfree(map);
 }
 
@@ -255,8 +257,17 @@ static void *ti_dra7_xbar_route_allocate(struct 
of_phandle_args *dma_spec,
return ERR_PTR(-ENOMEM);
}
 
-   map->xbar_out = idr_alloc(>map_idr, NULL, 0, xbar->dma_requests,
- GFP_KERNEL);
+   mutex_lock(>mutex);
+   map->xbar_out = find_first_zero_bit(xbar->dma_inuse,
+   xbar->dma_requests);
+   mutex_unlock(>mutex);
+   if (map->xbar_out == xbar->dma_requests) {
+   dev_err(>dev, "Run out of free DMA requests\n");
+   kfree(map);
+   return ERR_PTR(-ENOMEM);
+   }
+   set_bit(map->xbar_out, xbar->dma_inuse);
+
map->xbar_in = (u16)dma_spec->args[0];
 
dma_spec->args[0] = map->xbar_out + xbar->dma_offset;
@@ -299,8 +310,6 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
if (!xbar)
return -ENOMEM;
 
-   idr_init(>map_idr);
-
dma_node = of_parse_phandle(node, "dma-masters", 0);
if (!dma_node) {
dev_err(>dev, "Can't get DMA master node\n");
@@ -322,6 +331,12 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
}
of_node_put(dma_node);
 
+   xbar->dma_inuse = devm_kcalloc(>dev,
+  BITS_TO_LONGS(xbar->dma_requests),
+  sizeof(unsigned long), GFP_KERNEL);
+   if (!xbar->dma_inuse)
+   return -ENOMEM;
+
if (of_property_read_u32(node, "dma-requests", >xbar_requests)) {
dev_info(>dev,
 "Missing XBAR input information, using %u.\n",
@@ -343,6 +358,7 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
xbar->dmarouter.route_free = ti_dra7_xbar_free;
xbar->dma_offset = (u32)match->data;
 
+   mutex_init(>mutex);
platform_set_drvdata(pdev, xbar);
 
/* Reset the crossbar */
-- 
2.6.1

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

[PATCH v2 3/3] dmaengine: ti-dma-crossbar: dra7: Support for eDMA with new bindings

[Peter Ujfalusi]

Allow the crossbar driver to be used with the eDMA node with non legacy
binding.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/ti-dma-crossbar.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index dac7ae06cc58..e107779b1a2e 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -289,6 +289,10 @@ static const struct of_device_id ti_dra7_master_match[] = {
.compatible = "ti,edma3",
.data = (void *)TI_XBAR_EDMA_OFFSET,
},
+   {
+   .compatible = "ti,edma3-tpcc",
+   .data = (void *)TI_XBAR_EDMA_OFFSET,
+   },
{},
 };
 
-- 
2.6.1

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

Re: [PATCH 1/3] dmaengine: ti-dma-crossbar: dra7: Use bitops instead of idr

[Peter Ujfalusi]

For the record...

On 10/29/2015 10:28 AM, Peter Ujfalusi wrote:
> The use of idr was nice, but it was a bit heavy and we did not need the
> features it provides. Using simple bitmap to track allocated DMA channels
> is adequate here and it will be easier to add support for reserving
> channels later on.
> 
> Signed-off-by: Peter Ujfalusi 
> - map->xbar_out = idr_alloc(>map_idr, NULL, 0, xbar->dma_requests,
> -   GFP_KERNEL);
> + mutex_lock(>mutex);
> + map->xbar_out = find_next_zero_bit(xbar->dma_inuse, xbar->dma_requests,
> +0);

find_first_zero_bit() ;)

> + mutex_unlock(>mutex);
> + if (map->xbar_out) {

Well, this is obviously wrong... Should have been:
if (map->xbar_out == xbar->dma_requests) {


> + dev_err(>dev, "Run out of free DMA requests\n");
> + kfree(map);
> + return ERR_PTR(-ENOMEM);
> + }
> + set_bit(map->xbar_out, xbar->dma_inuse);
> +

-- 
Péter
--
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] gpio: xgene: add support to configure GPIO line as input, output or external IRQ pin

[Arnd Bergmann]

On Friday 30 October 2015 12:41:03 Quan Nguyen wrote:
> On Thu, Oct 29, 2015 at 8:28 PM, Linus Walleij  
> wrote:
> > On Mon, Oct 26, 2015 at 7:49 AM, Y Vo  wrote:
> > (...)
> >> +#define XGENE_HWIRQ_TO_GPIO(hwirq) ((hwirq) + XGENE_GPIO8_IDX)
> >> +#define XGENE_GPIO_TO_HWIRQ(gpio)  ((gpio) - XGENE_GPIO8_IDX)
> >> +#define GIC_IRQ_TO_GPIO_IRQ(hwirq) ((hwirq) - XGENE_GPIO8_HWIRQ)
> >> +#define GPIO_IRQ_TO_GIC_IRQ(hwirq) ((hwirq) + XGENE_GPIO8_HWIRQ)
> >
> > I'm a bit uneasy about this, maybe I just don't get it.
> >
> > What is this indexing into "GIC IRQ" that is starting to happen
> > here?
> >
> > The GIC (if that is drivers/irqchip/irq-gic.c) has a totally dynamic IRQ
> > translation and the Linux IRQs it is using may change. I am worried
> > that there is some reliance here on Linux IRQ having certain numbers
> > because there is certainly no ABI like that.
> >
> > Is this 0x48 really an index into the *hardware* offset in the GIC?
> >
> > And if it is: why are we not getting this hardware information from the
> > device tree like all other interrupt numbers and offsets?
> >
> > I'm worried about this.
> 
> The SPI40(0x48) through SPI45(0x4D) from GIC are mapped as external
> IRQ0 - IRQ5 in this GPIO block, so it is hardware offset not mapped
> irq number.
> 
> Below is detail:
> 
> + GIC: SPI40 (hwirq=0x48)  <=> SB-GPIO: (hwirq=0) (gpio line 8)
> + GIC: SPI41 (hwirq=0x49)  <=> SB-GPIO: (hwirq=1) (gpio line 9)
> ...
> + GIC: SPI45 (hwirq=0x4D)  <=> SB-GPIO: (hwirq=5) (gpio line 13)
> 
> These defines are to help translating between Gic hardware irq and
> SBGPIO hardware irq number.

But the numbers are already in DT, so don't duplicate them in the
source code but just use irq_of_parse_and_map() to get the parent
irq number.

> >> -   u32 *irq;
> >> +   void __iomem *regs;
> >> +   struct irq_domain *gic_domain;
> >> +   struct irq_domain *irq_domain;
> >
> > And there is some secondary gic_domain here, which is confusing
> > since the GIC does have an IRQ domain too.
> >
> > I think I want a clear explanation to how this GPIO controller interacts
> > with the GIC, and I want it to be part of the patch, as comments in the
> > code and in the commit message (which is way too small for a complex
> > patch like this).
> >
> > Otherwise I have no chance to understand what is really going on here.
> 
> SBGPIO currently is not capable to mask/unmask/... irqs, so these will
> rely on the parent (GIC) instead. To do so, we need keep a parent
> domain reference here "struct irq_domain *gic_domain" so we can find
> correspond parent irq in runtime.

Maybe rename the domain to 'parent_domain' or something like that
to avoid hardcoding any knowledge of the parent IRQ controller being
a GIC. If the same GPIO block gets reused on a PowerPC machine, we
want the driver to just work and not have any ARM specifics in it.

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

Re: [RESEND PATCH 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288

[Stephan Mueller]

Am Freitag, 30. Oktober 2015, 16:22:46 schrieb Zain Wang:

Hi Zain,

>Crypto driver support cbc/ecb two chainmode, and aes/des/des3 three cipher
>mode. The names registered are:
>ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
>You can alloc tags above in your case.
>
>And other algorithms and platforms will be added later on.
>
>Signed-off-by: Zain Wang 
>---
> drivers/crypto/Makefile|   1 +
> drivers/crypto/rk_crypto/Makefile  |   3 +
> drivers/crypto/rk_crypto/rk3288_crypto.c   | 393 
> drivers/crypto/rk_crypto/rk3288_crypto.h   | 291 
> .../crypto/rk_crypto/rk3288_crypto_ablkcipher.c| 502
>+ 5 files changed, 1190 insertions(+)
> create mode 100644 drivers/crypto/rk_crypto/Makefile
> create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.c
> create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.h
> create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto_ablkcipher.c
>
>diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
>index c3ced6f..00d103c 100644
>--- a/drivers/crypto/Makefile
>+++ b/drivers/crypto/Makefile
>@@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
> obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
> obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
> obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
>+obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto/
>diff --git a/drivers/crypto/rk_crypto/Makefile
>b/drivers/crypto/rk_crypto/Makefile new file mode 100644
>index 000..0f62d87
>--- /dev/null
>+++ b/drivers/crypto/rk_crypto/Makefile
>@@ -0,0 +1,3 @@
>+obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto_driver.o
>+rk_crypto_driver-objs := rk3288_crypto.o \
>+   rk3288_crypto_ablkcipher.o \
>diff --git a/drivers/crypto/rk_crypto/rk3288_crypto.c
>b/drivers/crypto/rk_crypto/rk3288_crypto.c new file mode 100644
>index 000..fe55d7e
>--- /dev/null
>+++ b/drivers/crypto/rk_crypto/rk3288_crypto.c
>@@ -0,0 +1,393 @@
>+/*
>+ *Crypto acceleration support for Rockchip RK3288
>+ *
>+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
>+ *
>+ * Author: Zain Wang 
>+ *
>+ * 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.
>+ *
>+ * Some ideas are from marvell/cesa.c and s5p-sss.c driver.
>+ */
>+
>+#include "rk3288_crypto.h"
>+#include 
>+#include 
>+#include 
>+#include 
>+#include 
>+
>+struct crypto_info_t *crypto_p;
>+
>+static int rk_crypto_enable_clk(struct crypto_info_t *dev)
>+{
>+  if (clk_prepare_enable(dev->clk)) {
>+  dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'clk'\n",
>+  __func__, __LINE__);
>+  return -ENOENT;
>+  }
>+  if (clk_prepare_enable(dev->aclk)) {
>+  dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
>+  __func__, __LINE__);
>+  goto err_aclk;
>+  }
>+  if (clk_prepare_enable(dev->hclk)) {
>+  dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
>+  __func__, __LINE__);
>+  goto err_hclk;
>+  }
>+  if (clk_prepare_enable(dev->pclk)) {
>+  dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'pclk'\n",
>+  __func__, __LINE__);
>+  goto err_pclk;
>+  }
>+  return 0;
>+
>+err_pclk:
>+  clk_disable_unprepare(dev->hclk);
>+err_hclk:
>+  clk_disable_unprepare(dev->aclk);
>+err_aclk:
>+  clk_disable_unprepare(dev->clk);
>+
>+  return -ENOENT;
>+}
>+
>+static void rk_crypto_disable_clk(struct crypto_info_t *dev)
>+{
>+  clk_disable_unprepare(dev->hclk);
>+  clk_disable_unprepare(dev->aclk);
>+  clk_disable_unprepare(dev->pclk);
>+  clk_disable_unprepare(dev->clk);
>+}
>+
>+static int check_alignment(struct scatterlist *sg_src,
>+ struct scatterlist *sg_dst,
>+ int align_mask)
>+{
>+  int in, out, align;
>+
>+  in = IS_ALIGNED((u32)sg_src->offset, 4) &&
>+   IS_ALIGNED(sg_src->length, align_mask);
>+  if (sg_dst == NULL)
>+  return in;
>+  out = IS_ALIGNED((u32)sg_dst->offset, 4) &&
>+IS_ALIGNED(sg_dst->length, align_mask);
>+  align = in && out;
>+
>+  return (align && (sg_src->length == sg_dst->length));
>+}
>+
>+static int rk_load_data(struct crypto_info_t *dev,
>+struct scatterlist *sg_src,
>+struct scatterlist *sg_dst)
>+{
>+  uint32_t count;
>+  int ret;
>+
>+  dev->aligned = dev->aligned ?
>+  check_alignment(sg_src, sg_dst, dev->align_size) :
>+  dev->aligned;
>+  if 

Re: [PATCH v3 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Krzysztof Kozlowski]

On 29.10.2015 20:43, Pavel Fedin wrote:
>  Hello!
> 
 Any vendor prefix here? How generic is this?
>>>
>>>  I just don't know... Does *everything* really need a vendor prefix? How 
>>> readable would that
>> be? "compatible" property already says
>>> that it's samsung-exynos-specific. And IMHO it's quite obvious that 
>>> properties of vendor-
>> specific device are automatically
>>> vendor-specific.
>>>  Ok, i am currently fixing up the rest and will post v4 soon, and will Cc: 
>>> it to devicetree
>> ML.
>>
>> Which my reply you are referring to? You stripped part of some
>> sentence and put it without *any context*. Just random sentence.
>> I asked for vendor prefix in few places... srom-timing? width? And I
>> do not remember where I used exactly these words.
> 
>  Ok, sorry, i promise to improve. :)
>  Anyway, i have figured out how to add sub-devices, and heavily modified the 
> whole thing. And indeed, vendor prefix is now very useful, so i added it to 
> all three properties. Making v4...

Actually now I found:
Documentation/devicetree/bindings/net/gpmc-eth.txt

Aren't you duplicating this work? This looks very, very similar.

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 v4 1/6] clk: sunxi: Let divs clocks read the base factor clock name from devicetree

[Chen-Yu Tsai]

On Wed, Oct 28, 2015 at 12:50 AM, Jens Kuske  wrote:
> Currently, the sunxi clock driver gets the name for the base factor clock
> of divs clocks from the name field in factors_data. This prevents reusing
> of the factor clock for clocks with same properties, but different name.
>
> This commit makes the divs setup function try to get a name from
> clock-output-names in the devicetree. It also removes the name field where
> possible and merges the sun4i PLL5 and PLL6 clocks.

This patch actually removes all static declarations of the name field,
which is a good thing!

>
> Signed-off-by: Jens Kuske 
> ---
>  drivers/clk/sunxi/clk-sunxi.c | 38 +++---
>  1 file changed, 27 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 9c79af0c..270de42 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -704,21 +704,12 @@ static const struct factors_data sun4i_pll5_data 
> __initconst = {
> .enable = 31,
> .table = _pll5_config,
> .getter = sun4i_get_pll5_factors,
> -   .name = "pll5",
> -};
> -
> -static const struct factors_data sun4i_pll6_data __initconst = {
> -   .enable = 31,
> -   .table = _pll5_config,
> -   .getter = sun4i_get_pll5_factors,
> -   .name = "pll6",
>  };
>
>  static const struct factors_data sun6i_a31_pll6_data __initconst = {
> .enable = 31,
> .table = _a31_pll6_config,
> .getter = sun6i_a31_get_pll6_factors,
> -   .name = "pll6x2",
>  };
>
>  static const struct factors_data sun5i_a13_ahb_data __initconst = {
> @@ -902,6 +893,7 @@ struct gates_data {
>
>  #define SUNXI_DIVS_MAX_QTY 4
>  #define SUNXI_DIVISOR_WIDTH2
> +#define SUNXI_DIVS_BASE_NAME_MAX_LEN   8
>
>  struct divs_data {
> const struct factors_data *factors; /* data for the factor clock */
> @@ -941,7 +933,7 @@ static const struct divs_data pll5_divs_data __initconst 
> = {
>  };
>
>  static const struct divs_data pll6_divs_data __initconst = {
> -   .factors = _pll6_data,
> +   .factors = _pll5_data,
> .ndivs = 4,
> .div = {
> { .shift = 0, .table = pll6_sata_tbl, .gate = 14 }, /* M, 
> SATA */
> @@ -983,6 +975,8 @@ static void __init sunxi_divs_clk_setup(struct 
> device_node *node,
> struct clk_gate *gate = NULL;
> struct clk_fixed_factor *fix_factor;
> struct clk_divider *divider;
> +   struct factors_data factors = *data->factors;
> +   char base_name[SUNXI_DIVS_BASE_NAME_MAX_LEN];
> void __iomem *reg;
> int ndivs = SUNXI_DIVS_MAX_QTY, i = 0;
> int flags, clkflags;
> @@ -991,8 +985,30 @@ static void __init sunxi_divs_clk_setup(struct 
> device_node *node,
> if (data->ndivs)
> ndivs = data->ndivs;
>
> +   /* Try to find a name for base factor clock */
> +   for (i = 0; i < ndivs; i++) {
> +   if (data->div[i].self) {
> +   of_property_read_string_index(node, 
> "clock-output-names",
> + i, );
> +   break;
> +   }
> +   }
> +   /* If we don't have a .self clk use the first output-name up to '_' */

This actually only works for the sun4i divs clocks. sun6i-a31-pll6 uses a
different naming convention. sun4i-a10-pll2 uses yet another, though that's
not a divs clock. Maybe we should work on unifying them. Maxime?

Other than these 2 bits of information, this patch looks good.


Regards
ChenYu

> +   if (factors.name == NULL) {
> +   of_property_read_string_index(node, "clock-output-names",
> + 0, _name);
> +
> +   for (i = 0; i < SUNXI_DIVS_BASE_NAME_MAX_LEN - 1 &&
> +   clk_name[i] != '_' &&
> +   clk_name[i] != '\0'; i++)
> +   base_name[i] = clk_name[i];
> +
> +   base_name[i] = '\0';
> +   factors.name = base_name;
> +   }
> +
> /* Set up factor clock that we will be dividing */
> -   pclk = sunxi_factors_clk_setup(node, data->factors);
> +   pclk = sunxi_factors_clk_setup(node, );
> parent = __clk_get_name(pclk);
>
> reg = of_iomap(node, 0);
> --
> 2.6.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 2/2] dma: add Qualcomm Technologies HIDMA channel driver

[kbuild test robot]

Hi Sinan,

[auto build test ERROR on lwn/docs-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Sinan-Kaya/dma-add-Qualcomm-Technologies-HIDMA-management-driver/20151030-111408
config: i386-allyesconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `hidma_selftest_sg.constprop.7':
>> qcom_hidma.c:(.text+0x175be6): undefined reference to `__udivdi3'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH v4 4/6] reset: sunxi: Add Allwinner H3 bus resets

[Arnd Bergmann]

On Tuesday 27 October 2015 17:50:24 Jens Kuske wrote:
> 
> +static int sun8i_h3_bus_reset_xlate(struct reset_controller_dev *rcdev,
> +   const struct of_phandle_args *reset_spec)
> +{
> +   unsigned int index = reset_spec->args[0];
> +
> +   if (index < 96)
> +   return index;
> +   else if (index < 128)
> +   return index + 32;
> +   else if (index < 160)
> +   return index + 64;
> +   else
> +   return -EINVAL;
> +}
> +
> 

This looks like you are doing something wrong and should either
put the actual number into DT, or use a two-cell representation,
with the first cell indicating the block (0, 1 or 2), and the
second cell the index.

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

Re: [RESEND PATCH 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288

[LABBE Corentin]

On Fri, Oct 30, 2015 at 04:22:46PM +0800, Zain Wang wrote:
> Crypto driver support cbc/ecb two chainmode, and aes/des/des3 three cipher 
> mode.
> The names registered are:
> ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
> You can alloc tags above in your case.
> 
> And other algorithms and platforms will be added later on.
> 
> Signed-off-by: Zain Wang 
> ---
>  drivers/crypto/Makefile|   1 +
>  drivers/crypto/rk_crypto/Makefile  |   3 +
>  drivers/crypto/rk_crypto/rk3288_crypto.c   | 393 
>  drivers/crypto/rk_crypto/rk3288_crypto.h   | 291 
>  .../crypto/rk_crypto/rk3288_crypto_ablkcipher.c| 502 
> +
>  5 files changed, 1190 insertions(+)
>  create mode 100644 drivers/crypto/rk_crypto/Makefile
>  create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.c
>  create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.h
>  create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto_ablkcipher.c
> 
> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
> index c3ced6f..00d103c 100644
> --- a/drivers/crypto/Makefile
> +++ b/drivers/crypto/Makefile
> @@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
>  obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
>  obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
>  obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
> +obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto/
> diff --git a/drivers/crypto/rk_crypto/Makefile 
> b/drivers/crypto/rk_crypto/Makefile
> new file mode 100644
> index 000..0f62d87
> --- /dev/null
> +++ b/drivers/crypto/rk_crypto/Makefile
> @@ -0,0 +1,3 @@
> +obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto_driver.o
> +rk_crypto_driver-objs := rk3288_crypto.o \
> +  rk3288_crypto_ablkcipher.o \
> diff --git a/drivers/crypto/rk_crypto/rk3288_crypto.c 
> b/drivers/crypto/rk_crypto/rk3288_crypto.c
> new file mode 100644
> index 000..fe55d7e
> --- /dev/null
> +++ b/drivers/crypto/rk_crypto/rk3288_crypto.c
> @@ -0,0 +1,393 @@
> +/*
> + *Crypto acceleration support for Rockchip RK3288
> + *
> + * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * Author: Zain Wang 
> + *
> + * 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.
> + *
> + * Some ideas are from marvell/cesa.c and s5p-sss.c driver.
> + */
> +
> +#include "rk3288_crypto.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct crypto_info_t *crypto_p;
> +
> +static int rk_crypto_enable_clk(struct crypto_info_t *dev)
> +{
> + if (clk_prepare_enable(dev->clk)) {
> + dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'clk'\n",
> + __func__, __LINE__);
> + return -ENOENT;
> + }
> + if (clk_prepare_enable(dev->aclk)) {
> + dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
> + __func__, __LINE__);
> + goto err_aclk;
> + }
> + if (clk_prepare_enable(dev->hclk)) {
> + dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
> + __func__, __LINE__);
> + goto err_hclk;
> + }
> + if (clk_prepare_enable(dev->pclk)) {
> + dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'pclk'\n",
> + __func__, __LINE__);
> + goto err_pclk;
> + }
> + return 0;
> +
> +err_pclk:
> + clk_disable_unprepare(dev->hclk);
> +err_hclk:
> + clk_disable_unprepare(dev->aclk);
> +err_aclk:
> + clk_disable_unprepare(dev->clk);
> +
> + return -ENOENT;
> +}
Please return the error value given by clk_prepare_enable()

> +
> +static void rk_crypto_disable_clk(struct crypto_info_t *dev)
> +{
> + clk_disable_unprepare(dev->hclk);
> + clk_disable_unprepare(dev->aclk);
> + clk_disable_unprepare(dev->pclk);
> + clk_disable_unprepare(dev->clk);
> +}
> +
> +static int check_alignment(struct scatterlist *sg_src,
> +struct scatterlist *sg_dst,
> +int align_mask)
> +{
> + int in, out, align;
> +
> + in = IS_ALIGNED((u32)sg_src->offset, 4) &&
> +  IS_ALIGNED(sg_src->length, align_mask);
> + if (sg_dst == NULL)
> + return in;
> + out = IS_ALIGNED((u32)sg_dst->offset, 4) &&
> +   IS_ALIGNED(sg_dst->length, align_mask);
> + align = in && out;
> +
> + return (align && (sg_src->length == sg_dst->length));
> +}
> +
> +static int rk_load_data(struct crypto_info_t *dev,
> +   struct scatterlist *sg_src,
> +   struct scatterlist *sg_dst)
> +{
> + uint32_t count;
u32 is prefered over 

[PATCH v4 3/3] arm64: dts: Add BRCM IPROC NAND DT node for NS2

[Anup Patel]

The NAND controller on NS2 SoC is compatible with existing
BRCM IPROC NAND driver so let's enable it in NS2 DT and
NS2 SVK DT.

This patch also fixes use of node labels in ns2-svk.dts.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Reviewed-by: Brian Norris 
---
 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 --
 arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
 2 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts 
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index e5950d5..6bb3d4d 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -50,18 +50,28 @@
device_type = "memory";
reg = <0x0 0x8000 0x 0x4000>;
};
+};
 
-   soc: soc {
-   i2c0: i2c@6608 {
-   status = "ok";
-   };
+ {
+   status = "ok";
+};
 
-   i2c1: i2c@660b {
-   status = "ok";
-   };
+ {
+   status = "ok";
+};
+
+ {
+   status = "ok";
+};
 
-   uart3: serial@6613 {
-   status = "ok";
-   };
+ {
+   nandcs@0 {
+   compatible = "brcm,nandcs";
+   reg = <0>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <8>;
+   nand-ecc-step-size = <512>;
+   #address-cells = <1>;
+   #size-cells = <1>;
};
 };
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f603277..9610822 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -212,5 +212,19 @@
compatible = "brcm,iproc-rng200";
reg = <0x6622 0x28>;
};
+
+   nand: nand@6646 {
+   compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+   reg = <0x6646 0x600>,
+ <0x67015408 0x600>,
+ <0x66460f00 0x20>;
+   reg-names = "nand", "iproc-idm", "iproc-ext";
+   interrupts = ;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   brcm,nand-has-wp;
+   };
};
 };
-- 
1.9.1

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

Re: [PATCH v4 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Krzysztof Kozlowski]

On 29.10.2015 21:42, Pavel Fedin wrote:
> Add documentation for new subnode properties, allowing bank configuration.
> Based on u-boot implementation, but heavily reworked.

Please, carefully look at:
Documentation/devicetree/bindings/net/gpmc-eth.txt
Documentation/devicetree/bindings/bus/ti-gpmc.txt

1. Try to re-use existing bindings. Although I see existing bank-width
and gpmc,device-width but yours samsung,srom-data-width seems better.
Maybe there are other to re-use?

2. The array of "PMC, Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs" is poorly
extendable and not very descriptive/readable. You mapped directly device
register which is the easier way for the driver but that is not the
purpose of binding.

3. Please provide ranges for valid values and units.

4. PMC is not a timing.

I doubt that TI GPMC could be used in Exynos SROM but please look at it
and get useful stuff from it.

Best regards,
Krzysztof

> 
> Signed-off-by: Pavel Fedin 
> ---
>  .../bindings/arm/samsung/exynos-srom.txt   | 50 
> +-
>  1 file changed, 48 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt 
> b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> index 33886d5..02ecc7f 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> @@ -5,8 +5,54 @@ Required properties:
>  
>  - reg: offset and length of the register set
>  
> -Example:
> +- #address-cells, #size-cells : should be '1' if the device has sub-nodes
> + with 'reg' property.
> +- ranges: allows valid 1:1 translation between child's address space and
> +   parent's address space
> +
> +Sub-nodes:
> +The SROM controller can be used to attach external peripherials. In this case
> +device nodes should be added as subnodes to the SROMc node. These subnodes,
> +except regular device specification, should contain the following properties,
> +describing configuration of the relevant SROM bank:
> +
> +Required properties:
> +- samsung,srom-bank : bank number (0 - 3)
> +
> +- samsung,srom-timing : array of 7 integers: PMC, Tacp, Tcah, Tcoh, Tacc, 
> Tcos,
> + Tacs
> +
> +Optional properties:
> +- samsung,srom-data-width : data width in bytes (1 or 2). If omitted, default
> + of 1 is used.
> +
> +Example: basic definition, no banks are configured
>   sromc@1257 {
>   compatible = "samsung,exynos-srom";
> - reg = <0x1257 0x10>;
> + reg = <0x1257 0x14>;
> + };
> +
> +Example: SROMc with smsc 911x ethernet chip on bank 3
> + sromc@1257 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + compatible = "samsung,exynos-srom";
> + reg = <0x1257 0x14>;
> +
> + ethernet@0700 {
> + compatible = "smsc,lan9115";
> + reg = <0x0700 0x1>;
> + phy-mode = "mii";
> + interrupt-parent = <>;
> + interrupts = <5 8>;
> + reg-io-width = <2>;
> + smsc,irq-push-pull;
> + smsc,force-internal-phy;
> +
> + samsung,srom-bank = <3>;
> + samsung,srom-data-width = <2>;
> + samsung,srom-timing = <1 9 12 1 9 1 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 v5 1/4] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC

[Alim Akhtar]

From: Thomas Abraham 

Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device
is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators.
This also supports RTC and three 32.768KHz clock outputs.

Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Abraham 
Signed-off-by: Alim Akhtar 
---
 Documentation/devicetree/bindings/mfd/s2mps11.txt |   21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index 890f0b0e1643..4c0543ceec25 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -1,5 +1,5 @@
 
-* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator
+* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator
 
 The Samsung S2MPS11 is a multi-function device which includes voltage and
 current regulators, RTC, charger controller and other sub-blocks. It is
@@ -7,8 +7,12 @@ interfaced to the host controller using an I2C interface. Each 
sub-block is
 addressed by the host system using different I2C slave addresses.
 
 Required properties:
-- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic"
- or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic".
+- compatible: Should be one of the following
+   - "samsung,s2mps11-pmic"
+   - "samsung,s2mps13-pmic"
+   - "samsung,s2mps14-pmic"
+   - "samsung,s2mps15-pmic"
+   - "samsung,s2mpu02-pmic".
 - reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
 
 Optional properties:
@@ -24,7 +28,7 @@ Optional properties:
   unwanted buck warm reset (setting buck voltages to default values).
 
 Optional nodes:
-- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 32.768
+- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) 
buffered 32.768
   KHz outputs, so to register these as clocks with common clock framework
   instantiate a sub-node named "clocks". It uses the common clock binding
   documented in :
@@ -37,12 +41,13 @@ Optional nodes:
 the clock which they consume.
 Clock   ID   Devices
 --
-32KhzAP0S2MPS11, S2MPS13, S2MPS14, S5M8767
-32KhzCP1S2MPS11, S2MPS13, S5M8767
-32KhzBT2S2MPS11, S2MPS13, S2MPS14, S5M8767
+32KhzAP0S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767
+32KhzCP1S2MPS11, S2MPS13, S2MPS15, S5M8767
+32KhzBT2S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767
 
   - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk",
"samsung,s2mps14-clk", "samsung,s5m8767-clk"
+The s2msp15 uses the same compatible as s2mps13, as both provides similar 
clocks.
 
 - regulators: The regulators of s2mps11 that have to be instantiated should be
 included in a sub-node named 'regulators'. Regulator nodes included in this
@@ -90,6 +95,7 @@ as per the datasheet of s2mps11.
- S2MPS11: 1 to 38
- S2MPS13: 1 to 40
- S2MPS14: 1 to 25
+   - S2MPS15: 1 to 27
- S2MPU02: 1 to 28
  - Example: LDO1, LDO2, LDO28
- BUCKn
@@ -97,6 +103,7 @@ as per the datasheet of s2mps11.
- S2MPS11: 1 to 10
- S2MPS13: 1 to 10
- S2MPS14: 1 to 5
+   - S2MPS15: 1 to 10
- S2MPU02: 1 to 7
  - Example: BUCK1, BUCK2, BUCK9
 
-- 
1.7.10.4

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

Re: [PATCH v4 3/6] pinctrl: sunxi: Add H3 PIO controller support

[Chen-Yu Tsai]

Hi,

On Wed, Oct 28, 2015 at 12:50 AM, Jens Kuske  wrote:
> The H3 uses the same pin controller as previous SoC's from Allwinner.
> Add support for the pins controlled by the main PIO controller.
>
> Signed-off-by: Jens Kuske 
> Acked-by: Maxime Ripard 
> ---
>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
>  drivers/pinctrl/sunxi/Kconfig  |   4 +
>  drivers/pinctrl/sunxi/Makefile |   1 +
>  drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c   | 516 
> +
>  4 files changed, 522 insertions(+)
>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
>
> diff --git 
> a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt 
> b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> index b321b26..e6ba602 100644
> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> @@ -18,6 +18,7 @@ Required properties:
>"allwinner,sun8i-a23-r-pinctrl"
>"allwinner,sun8i-a33-pinctrl"
>"allwinner,sun8i-a83t-pinctrl"
> +  "allwinner,sun8i-h3-pinctrl"
>
>  - reg: Should contain the register physical address and length for the
>pin controller.
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index e68fd95..89ab7f5 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -51,6 +51,10 @@ config PINCTRL_SUN8I_A23_R
> depends on RESET_CONTROLLER
> select PINCTRL_SUNXI_COMMON
>
> +config PINCTRL_SUN8I_H3
> +   def_bool MACH_SUN8I
> +   select PINCTRL_SUNXI_COMMON
> +
>  config PINCTRL_SUN9I_A80
> def_bool MACH_SUN9I
> select PINCTRL_SUNXI_COMMON
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index e080290..6bd818e 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -13,4 +13,5 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23)   += 
> pinctrl-sun8i-a23.o
>  obj-$(CONFIG_PINCTRL_SUN8I_A23_R)  += pinctrl-sun8i-a23-r.o
>  obj-$(CONFIG_PINCTRL_SUN8I_A33)+= pinctrl-sun8i-a33.o
>  obj-$(CONFIG_PINCTRL_SUN8I_A83T)   += pinctrl-sun8i-a83t.o
> +obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o
>  obj-$(CONFIG_PINCTRL_SUN9I_A80)+= pinctrl-sun9i-a80.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
> new file mode 100644
> index 000..98d465d
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
> @@ -0,0 +1,516 @@
> +/*
> + * Allwinner H3 SoCs pinctrl driver.
> + *
> + * Copyright (C) 2015 Jens Kuske 
> + *
> + * Based on pinctrl-sun8i-a23.c, which is:
> + * Copyright (C) 2014 Chen-Yu Tsai 
> + * Copyright (C) 2014 Maxime Ripard 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin sun8i_h3_pins[] = {



> +   SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac")), /* RXD3 */
> +   SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac")), /* RXD2 */
> +   SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac")), /* RXD1 */
> +   SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac")), /* RXD0 */
> +   SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac")), /* RXCK */
> +   SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac")), /* RXCTL/RCDV */

RXDV?

> +   SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac")), /* RXERR */
> +   SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 7),
> + 

Re: [RESEND PATCH 2/4] clk: rockchip: set an id for crypto clk

[Heiko Stuebner]

Hi Zain,

Am Freitag, 30. Oktober 2015, 16:22:47 schrieb Zain Wang:
> set an id for crypto clk, so that it can be called in other part.
> 
> Signed-off-by: Zain Wang 
> ---
>  drivers/clk/rockchip/clk-rk3288.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/rockchip/clk-rk3288.c 
> b/drivers/clk/rockchip/clk-rk3288.c
> index 9040878..d74bd5d 100644
> --- a/drivers/clk/rockchip/clk-rk3288.c
> +++ b/drivers/clk/rockchip/clk-rk3288.c
> @@ -295,7 +295,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[] 
> __initdata = {
>   RK3288_CLKGATE_CON(0), 4, GFLAGS),
>   GATE(0, "c2c_host", "aclk_cpu_src", 0,
>   RK3288_CLKGATE_CON(13), 8, GFLAGS),
> - COMPOSITE_NOMUX(0, "crypto", "aclk_cpu_pre", 0,
> + COMPOSITE_NOMUX(SRST_CRYPTO, "crypto", "aclk_cpu_pre", 0,

the id you want to use actually is a soft-reset index, not a clock-id.
You would need to add a real id, in this case with an sclk_ prefix.

>   RK3288_CLKSEL_CON(26), 6, 2, DFLAGS,
>   RK3288_CLKGATE_CON(5), 4, GFLAGS),
>   GATE(0, "aclk_bus_2pmu", "aclk_cpu_pre", CLK_IGNORE_UNUSED,
> 

It should probably look more like below, but as suggested by Stephen Boyd
in another thread, we should coordinate with Chris to add more necessary clock
ids in one go:
 8< ---
diff --git a/drivers/clk/rockchip/clk-rk3288.c 
b/drivers/clk/rockchip/clk-rk3288.c
index 9040878..9fd9f5a 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -295,7 +295,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[] 
__initdata = {
RK3288_CLKGATE_CON(0), 4, GFLAGS),
GATE(0, "c2c_host", "aclk_cpu_src", 0,
RK3288_CLKGATE_CON(13), 8, GFLAGS),
-   COMPOSITE_NOMUX(0, "crypto", "aclk_cpu_pre", 0,
+   COMPOSITE_NOMUX(SCLK_CRYPTO, "sclk_crypto", "aclk_cpu_pre", 0,
RK3288_CLKSEL_CON(26), 6, 2, DFLAGS,
RK3288_CLKGATE_CON(5), 4, GFLAGS),
GATE(0, "aclk_bus_2pmu", "aclk_cpu_pre", CLK_IGNORE_UNUSED,
diff --git a/include/dt-bindings/clock/rk3288-cru.h 
b/include/dt-bindings/clock/rk3288-cru.h
index c719aac..9e0a5e9 100644
--- a/include/dt-bindings/clock/rk3288-cru.h
+++ b/include/dt-bindings/clock/rk3288-cru.h
@@ -86,6 +86,7 @@
 #define SCLK_USBPHY480M_SRC122
 #define SCLK_PVTM_CORE 123
 #define SCLK_PVTM_GPU  124
+#define SCLK_CRYPTO125
 
 #define SCLK_MAC   151
 #define SCLK_MACREF_OUT152
-- 
2.6.1

 8< ---
--
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/4] Documentation: dt-bindings: Describe SROMc configuration

[Pavel Fedin]

 Hello!

> > Add documentation for new subnode properties, allowing bank configuration.
> > Based on u-boot implementation, but heavily reworked.
> 
> Please, carefully look at:
> Documentation/devicetree/bindings/net/gpmc-eth.txt
> Documentation/devicetree/bindings/bus/ti-gpmc.txt

 Thank you very much. Indeed, this looks very similar. By the way, should i 
document smsc over sromc in the same manner, writing
devicetree/bindings/net/sromc-eth.txt?

 This is a short reply for now, i'll make longer one (or just a new version) 
after studying these existing bindings and trying to
apply them.

 Pankaj:

> > + {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_ctl>, <_ebi>;
> > +
> > +   ethernet@0700 {
> > +   compatible = "smsc,lan9115";
> > +   reg = <0x0700 0x1>;
> > +   phy-mode = "mii";
> > +   interrupt-parent = <>;
> > +   interrupts = <5 8>;
> > +   reg-io-width = <2>;
> > +   smsc,irq-push-pull;
> > +   smsc,force-internal-phy;
> > +
> > +   samsung,srom-bank = <3>;
> > +   samsung,srom-data-width = <2>;
> > +   samsung,srom-timing = <1 9 12 1 9 1 1>;
> 
> I think this is not correct. We can't change binding of "smsc,lan9115"
> which is already documented here [1]. These samsung specific srom
> properties should be in srom node or its subnode, but not in this way.

 So, if you look at gpmc-eth.txt, you'll see that this approach is perfectly 
valid (this is a reply to another msg, just don't want
to post one more single-line reply).

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


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

RE: [PATCH v4 2/3] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()

[Anup Patel]

> -Original Message-
> From: Anup Patel [mailto:anup.pa...@broadcom.com]
> Sent: 30 October 2015 11:49
> To: David Woodhouse; Brian Norris; Linux MTD
> Cc: Rob Herring; Pawel Moll; Mark Rutland; Catalin Marinas; Will Deacon;
> Sudeep Holla; Ian Campbell; Kumar Gala; Ray Jui; Scott Branden; Florian 
> Fainelli;
> Pramod Kumar; Vikram Prakash; Sandeep Tripathy; Linux ARM Kernel; Device
> Tree; Linux Kernel; bcm-kernel-feedback-list; Anup Patel
> Subject: [PATCH v4 2/3] mtd: brcmnand: Force 8bit mode before doing
> nand_scan_ident()
> 
> Just like other NAND controllers, the NAND READID command only works in 8bit
> mode for all versions of BRCMNAND controller.
> 
> This patch forces 8bit mode for each NAND CS in brcmnand_init_cs() before
> doing nand_scan_ident() to ensure that BRCMNAND controller is in 8bit mode
> when NAND READID command is issued.
> 
> Signed-off-by: Anup Patel 
> Reviewed-by: Ray Jui 
> Reviewed-by: Scott Branden 
> ---
>  drivers/mtd/nand/brcmnand/brcmnand.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
> b/drivers/mtd/nand/brcmnand/brcmnand.c
> index dda96fa..641591d 100644
> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> @@ -1912,6 +1912,7 @@ static int brcmnand_init_cs(struct brcmnand_host
> *host)
>   struct mtd_info *mtd;
>   struct nand_chip *chip;
>   int ret;
> + u16 cfg_offs;
>   struct mtd_part_parser_data ppdata = { .of_node = dn };
> 
>   ret = of_property_read_u32(dn, "reg", >cs); @@ -1954,6
> +1955,15 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
> 
>   chip->controller = >controller;
> 
> + /*
> +  * The bootloader might have configured 16bit mode but
> +  * NAND READID command only works in 8bit mode. We force
> +  * 8bit mode here to ensure that NAND READID commands works.
> +  */
> + cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
> + nand_writereg(ctrl, cfg_offs,
> +   nand_readreg(ctrl, cfg_offs) & CFG_BUS_WIDTH);

This should have been "nand_readreg(ctrl, cfg_offs) & ~CFG_BUS_WIDTH".

My bad ...

--
Anup
--
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 v5 0/3] NAND support for Broadcom NS2 SoC

[Anup Patel]

We enable NAND support for Broadcom NS2 SoC by reusing existing
BRCMNAND driver.

This patchset applies on-top of "arm64: Simple additions to
NS2 DT" v1 patchset and is available in ns2_nand_v5 branch of
https://github.com/Broadcom/arm64-linux.git.

The patchset is tested on NS2 SVK.

Changes since v4:
 - Fix accidental typo in patch2 regarding use of CFG_BUS_WIDTH

Changes since v3:
 - Include Brian's patch for magic number cleanup related to
   CFG and CFG_EXT registers
 - Base patch1 of v3 patchset upon Brian's cleanup patch

Changes since v2:
 - Dropped patch1 and patch2 because these are already merged
   by MTD maintainer.
 - Avoid using absolute node paths in ns2-svk.dts.

Changes since v1:
 - Dropped patch3 and patch4 because we don't need to reset
   BRCMNAND controller for NS2.
 - Added patch to force 8bit mode before doing nand_scan_ident()
   in brcmnand_init_cs().

Anup Patel (2):
  mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
  arm64: dts: Add BRCM IPROC NAND DT node for NS2

Brian Norris (1):
  mtd: brcmnand: factor out CFG and CFG_EXT bitfields

 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 +---
 arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
 drivers/mtd/nand/brcmnand/brcmnand.c | 48 +++-
 3 files changed, 75 insertions(+), 17 deletions(-)

-- 
1.9.1

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

RE: [PATCH v4 0/3] NAND support for Broadcom NS2 SoC

[Anup Patel]

Hi All,

Please disregard this patchset.

There is an accidental typo in patch2.

We should use ~CFG_BUS_WIDTH instead of CFG_BUS_WIDTH
in patch2. I will quickly send v5 patchset to fix this.

Sorry, for the noise.

Regards,
Anup
--
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 0/4] [PATCH v4 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410

[Pavel Fedin]

 Hello!

> >  .../bindings/arm/samsung/exynos-srom.txt   | 50 ++-
> >  arch/arm/boot/dts/exynos5410-smdk5410.dts  | 41 +++
> >  arch/arm/boot/dts/exynos5410.dtsi  | 15 ++
> >  arch/arm/mach-exynos/Kconfig   |  2 +-
> >  drivers/soc/samsung/Kconfig|  2 +-
> >  drivers/soc/samsung/exynos-srom.c  | 58 
> > +-
> >  6 files changed, 162 insertions(+), 6 deletions(-)
> >
> 
> Something wrong here, I am not able to find V4 1/4 and 3/4 in this mailing 
> list.

 Which mailing list is "this"? I've just rechecked, i've got my messages back 
on both (linux-samsung-soc and linux-arm-kernel).

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


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

[RESEND PATCH 4/4] crypto: rk_crypto - add DT bindings documentation

[Zain Wang]

Add DT bindings documentation for the rk3288 crypto drivers.

Signed-off-by: Zain Wang 
---
 .../devicetree/bindings/crypto/rk-crypto.txt   | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/rk-crypto.txt

diff --git a/Documentation/devicetree/bindings/crypto/rk-crypto.txt 
b/Documentation/devicetree/bindings/crypto/rk-crypto.txt
new file mode 100644
index 000..1e50768
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/rk-crypto.txt
@@ -0,0 +1,31 @@
+Rockchip Electronics And Security Accelerator
+
+Required properties:
+- compatible: should be "rockchip,crypto"
+- reg: base physical address of the engine and length of memory mapped
+   region.
+- interrupts: interrupt number
+- clocks: clock specifiers
+- clock-names: "aclk_crypto" used to clock data
+  "hclk_crypto" used to clock data
+  "srst_crypto" used to clock crypto accelerator
+  "apb_pclk"used to clock dma
+-status: Enable
+
+Examples:
+
+   crypto: cypto-controller@ff8a {
+   compatible = "rockchip,crypto";
+   reg = <0xff8a 0x4000>;
+   interrupts = ;
+   clocks = < ACLK_CRYPTO>,
+< HCLK_CRYPTO>,
+< SRST_CRYPTO>,
+< ACLK_DMAC1>;
+
+   clock-names = "aclk_crypto",
+ "hclk_crypto",
+ "srst_crypto",
+ "apb_pclk";
+   status = "okay";
+   };
-- 
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

[RESEND PATCH 0/4] Crypto: add crypto accelerator support for rk3288

[Zain Wang]

This commit support three cipher(AES/DES/DES3) and two chainmode(ecb/cbc),
and the more algorithms or new hash drivers will be added later on.

Zain Wang (4):
  Crypto: Crypto driver support aes/des/des3 for rk3288
  clk: rockchip: set an id for crypto clk
  ARM: dts: rockchip: Add Crypto drivers for rk3288
  crypto: rk_crypto - add DT bindings documentation

 .../devicetree/bindings/crypto/rk-crypto.txt   |  31 ++
 arch/arm/boot/dts/rk3288.dtsi  |  16 +
 drivers/clk/rockchip/clk-rk3288.c  |   2 +-
 drivers/crypto/Makefile|   1 +
 drivers/crypto/rk_crypto/Makefile  |   3 +
 drivers/crypto/rk_crypto/rk3288_crypto.c   | 393 
 drivers/crypto/rk_crypto/rk3288_crypto.h   | 291 
 .../crypto/rk_crypto/rk3288_crypto_ablkcipher.c| 502 +
 8 files changed, 1238 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/crypto/rk-crypto.txt
 create mode 100644 drivers/crypto/rk_crypto/Makefile
 create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.c
 create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.h
 create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto_ablkcipher.c

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

[RESEND PATCH 3/4] ARM: dts: rockchip: Add Crypto drivers for rk3288

[Zain Wang]

Add Crypto drivers for rk3288 including crypto controller and dma clk.

Signed-off-by: Zain Wang 
---
 arch/arm/boot/dts/rk3288.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 6a79c9c..1706706 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -170,6 +170,22 @@
};
};
 
+   crypto: cypto-controller@ff8a {
+   compatible = "rockchip,crypto";
+   reg = <0xff8a 0x4000>;
+   interrupts = ;
+   clocks = < ACLK_CRYPTO>,
+< HCLK_CRYPTO>,
+< SRST_CRYPTO>,
+< ACLK_DMAC1>;
+
+   clock-names = "aclk_crypto",
+ "hclk_crypto",
+ "srst_crypto",
+ "apb_pclk";
+   status = "okay";
+   };
+
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
-- 
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

[RESEND PATCH 2/4] clk: rockchip: set an id for crypto clk

[Zain Wang]

set an id for crypto clk, so that it can be called in other part.

Signed-off-by: Zain Wang 
---
 drivers/clk/rockchip/clk-rk3288.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3288.c 
b/drivers/clk/rockchip/clk-rk3288.c
index 9040878..d74bd5d 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -295,7 +295,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[] 
__initdata = {
RK3288_CLKGATE_CON(0), 4, GFLAGS),
GATE(0, "c2c_host", "aclk_cpu_src", 0,
RK3288_CLKGATE_CON(13), 8, GFLAGS),
-   COMPOSITE_NOMUX(0, "crypto", "aclk_cpu_pre", 0,
+   COMPOSITE_NOMUX(SRST_CRYPTO, "crypto", "aclk_cpu_pre", 0,
RK3288_CLKSEL_CON(26), 6, 2, DFLAGS,
RK3288_CLKGATE_CON(5), 4, GFLAGS),
GATE(0, "aclk_bus_2pmu", "aclk_cpu_pre", CLK_IGNORE_UNUSED,
-- 
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 v5 1/3] mtd: brcmnand: factor out CFG and CFG_EXT bitfields

[Anup Patel]

From: Brian Norris 

Use enum instead of magic numbers for CFG and CFG_EXT bitfields.

Signed-off-by: Brian Norris 
Tested-by: Anup Patel 
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 38 +---
 1 file changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c
index 4cba03d..dda96fa 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -344,6 +344,28 @@ static const u8 brcmnand_cs_offsets_cs0[] = {
[BRCMNAND_CS_TIMING2]   = 0x14,
 };
 
+/*
+ * Bitfields for the CFG and CFG_EXT registers. Pre-v7.1 controllers only had
+ * one config register, but once the bitfields overflowed, newer controllers
+ * (v7.1 and newer) added a CFG_EXT register and shuffled a few fields around.
+ */
+enum {
+   CFG_BLK_ADR_BYTES_SHIFT = 8,
+   CFG_COL_ADR_BYTES_SHIFT = 12,
+   CFG_FUL_ADR_BYTES_SHIFT = 16,
+   CFG_BUS_WIDTH_SHIFT = 23,
+   CFG_BUS_WIDTH   = BIT(CFG_BUS_WIDTH_SHIFT),
+   CFG_DEVICE_SIZE_SHIFT   = 24,
+
+   /* Only for pre-v7.1 (with no CFG_EXT register) */
+   CFG_PAGE_SIZE_SHIFT = 20,
+   CFG_BLK_SIZE_SHIFT  = 28,
+
+   /* Only for v7.1+ (with CFG_EXT register) */
+   CFG_EXT_PAGE_SIZE_SHIFT = 0,
+   CFG_EXT_BLK_SIZE_SHIFT  = 4,
+};
+
 /* BRCMNAND_INTFC_STATUS */
 enum {
INTFC_FLASH_STATUS  = GENMASK(7, 0),
@@ -1720,17 +1742,19 @@ static int brcmnand_set_cfg(struct brcmnand_host *host,
}
device_size = fls64(cfg->device_size) - fls64(BRCMNAND_MIN_DEVSIZE);
 
-   tmp = (cfg->blk_adr_bytes << 8) |
-   (cfg->col_adr_bytes << 12) |
-   (cfg->ful_adr_bytes << 16) |
-   (!!(cfg->device_width == 16) << 23) |
-   (device_size << 24);
+   tmp = (cfg->blk_adr_bytes << CFG_BLK_ADR_BYTES_SHIFT) |
+   (cfg->col_adr_bytes << CFG_COL_ADR_BYTES_SHIFT) |
+   (cfg->ful_adr_bytes << CFG_FUL_ADR_BYTES_SHIFT) |
+   (!!(cfg->device_width == 16) << CFG_BUS_WIDTH_SHIFT) |
+   (device_size << CFG_DEVICE_SIZE_SHIFT);
if (cfg_offs == cfg_ext_offs) {
-   tmp |= (page_size << 20) | (block_size << 28);
+   tmp |= (page_size << CFG_PAGE_SIZE_SHIFT) |
+  (block_size << CFG_BLK_SIZE_SHIFT);
nand_writereg(ctrl, cfg_offs, tmp);
} else {
nand_writereg(ctrl, cfg_offs, tmp);
-   tmp = page_size | (block_size << 4);
+   tmp = (page_size << CFG_EXT_PAGE_SIZE_SHIFT) |
+ (block_size << CFG_EXT_BLK_SIZE_SHIFT);
nand_writereg(ctrl, cfg_ext_offs, tmp);
}
 
-- 
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 v5 3/3] arm64: dts: Add BRCM IPROC NAND DT node for NS2

[Anup Patel]

The NAND controller on NS2 SoC is compatible with existing
BRCM IPROC NAND driver so let's enable it in NS2 DT and
NS2 SVK DT.

This patch also fixes use of node labels in ns2-svk.dts.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Reviewed-by: Brian Norris 
---
 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 --
 arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
 2 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts 
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index e5950d5..6bb3d4d 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -50,18 +50,28 @@
device_type = "memory";
reg = <0x0 0x8000 0x 0x4000>;
};
+};
 
-   soc: soc {
-   i2c0: i2c@6608 {
-   status = "ok";
-   };
+ {
+   status = "ok";
+};
 
-   i2c1: i2c@660b {
-   status = "ok";
-   };
+ {
+   status = "ok";
+};
+
+ {
+   status = "ok";
+};
 
-   uart3: serial@6613 {
-   status = "ok";
-   };
+ {
+   nandcs@0 {
+   compatible = "brcm,nandcs";
+   reg = <0>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <8>;
+   nand-ecc-step-size = <512>;
+   #address-cells = <1>;
+   #size-cells = <1>;
};
 };
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f603277..9610822 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -212,5 +212,19 @@
compatible = "brcm,iproc-rng200";
reg = <0x6622 0x28>;
};
+
+   nand: nand@6646 {
+   compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+   reg = <0x6646 0x600>,
+ <0x67015408 0x600>,
+ <0x66460f00 0x20>;
+   reg-names = "nand", "iproc-idm", "iproc-ext";
+   interrupts = ;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   brcm,nand-has-wp;
+   };
};
 };
-- 
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 v5 2/3] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()

[Anup Patel]

Just like other NAND controllers, the NAND READID command only works
in 8bit mode for all versions of BRCMNAND controller.

This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
before doing nand_scan_ident() to ensure that BRCMNAND controller
is in 8bit mode when NAND READID command is issued.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c
index dda96fa..b410527 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1912,6 +1912,7 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
struct mtd_info *mtd;
struct nand_chip *chip;
int ret;
+   u16 cfg_offs;
struct mtd_part_parser_data ppdata = { .of_node = dn };
 
ret = of_property_read_u32(dn, "reg", >cs);
@@ -1954,6 +1955,15 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
 
chip->controller = >controller;
 
+   /*
+* The bootloader might have configured 16bit mode but
+* NAND READID command only works in 8bit mode. We force
+* 8bit mode here to ensure that NAND READID commands works.
+*/
+   cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
+   nand_writereg(ctrl, cfg_offs,
+ nand_readreg(ctrl, cfg_offs) & ~CFG_BUS_WIDTH);
+
if (nand_scan_ident(mtd, 1, NULL))
return -ENXIO;
 
-- 
1.9.1

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

Re: [PATCH v4 5/6] ARM: dts: sunxi: Add Allwinner H3 DTSI

[Chen-Yu Tsai]

Hi,

On Wed, Oct 28, 2015 at 12:50 AM, Jens Kuske  wrote:
> The Allwinner H3 is a home entertainment system oriented SoC with
> four Cortex-A7 cores and a Mali-400MP2 GPU.
>
> Signed-off-by: Jens Kuske 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 482 
> 
>  1 file changed, 482 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun8i-h3.dtsi
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> new file mode 100644
> index 000..c18b5f7
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -0,0 +1,482 @@
> +/*
> + * Copyright (C) 2015 Jens Kuske 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "skeleton.dtsi"
> +
> +#include 
> +#include 
> +
> +/ {
> +   interrupt-parent = <>;
> +
> +   cpus {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   cpu@0 {
> +   compatible = "arm,cortex-a7";
> +   device_type = "cpu";
> +   reg = <0>;
> +   };
> +
> +   cpu@1 {
> +   compatible = "arm,cortex-a7";
> +   device_type = "cpu";
> +   reg = <1>;
> +   };
> +
> +   cpu@2 {
> +   compatible = "arm,cortex-a7";
> +   device_type = "cpu";
> +   reg = <2>;
> +   };
> +
> +   cpu@3 {
> +   compatible = "arm,cortex-a7";
> +   device_type = "cpu";
> +   reg = <3>;
> +   };
> +   };
> +
> +   timer {
> +   compatible = "arm,armv7-timer";
> +   interrupts =  IRQ_TYPE_LEVEL_LOW)>,
> + IRQ_TYPE_LEVEL_LOW)>,
> + IRQ_TYPE_LEVEL_LOW)>,
> + IRQ_TYPE_LEVEL_LOW)>;
> +   clock-frequency = <2400>;
> +   arm,cpu-registers-not-fw-configured;
> +   };
> +
> +   memory {
> +   reg = <0x4000 0x8000>;
> +   };
> +
> +   clocks {
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges;
> +
> +   osc24M: osc24M_clk {
> +   #clock-cells = <0>;
> +   compatible = "fixed-clock";
> +   clock-frequency = <2400>;
> +   clock-output-names = "osc24M";
> +   };
> +
> +   osc32k: osc32k_clk {
> +   #clock-cells = <0>;
> +   compatible = "fixed-clock";
> +   clock-frequency = <32768>;
> +   clock-output-names = "osc32k";
> +   };
> +
> +   pll1: clk@01c2 {
> +   #clock-cells = <0>;
> +

Re: [PATCH 2/2] dma: add Qualcomm Technologies HIDMA channel driver

[kbuild test robot]

Hi Sinan,

[auto build test ERROR on lwn/docs-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Sinan-Kaya/dma-add-Qualcomm-Technologies-HIDMA-management-driver/20151030-111408
config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   ERROR: "__udivdi3" undefined!
>> ERROR: "dma_to_phys" undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH v9 6/8] scsi: ufs: make the UFS variant a platform device

[Hannes Reinecke]

On 10/28/2015 12:15 PM, Yaniv Gardi wrote:
> This change turns the UFS variant (SCSI_UFS_QCOM) into a UFS
> a platform device.
> In order to do so a few additional changes are required:
> 1. The ufshcd-pltfrm is no longer serves as a platform device.
>Now it only serves as a group of platform APIs such as PM APIs
>(runtime suspend/resume, system suspend/resume etc), parsers of
>clocks, regulators and pm_levels from DT.
> 2. What used to be the old platform "probe" is now "only"
>a pltfrm_init() routine, that does exactly the same, but only
>being called by the new probe function of the UFS variant.
> 
> Reviewed-by: Rob Herring 
> Reviewed-by: Gilad Broner 
> Signed-off-by: Yaniv Gardi 
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (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 v4 2/6] clk: sunxi: Add H3 clocks support

[Arnd Bergmann]

On Tuesday 27 October 2015 17:50:22 Jens Kuske wrote:
> +   of_property_read_string_index(node, "clock-output-names",
> + i, _name);
> +
> +   if (index == 17 || (index >= 29 && index <= 31))
> +   clk_parent = AHB2;
> +   else if (index <= 63 || index >= 128)
> +   clk_parent = AHB1;
> +   else if (index >= 64 && index <= 95)
> +   clk_parent = APB1;
> +   else if (index >= 96 && index <= 127)
> +   clk_parent = APB2;
> +
> +   clk_reg = reg + 4 * (index / 32);
> 

Same as for the reset driver, this probably means you should have one
cell to indicate which bus it is for, and another cell for the
index.

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

[PATCH v4 1/3] mtd: brcmnand: factor out CFG and CFG_EXT bitfields

[Anup Patel]

From: Brian Norris 

Use enum instead of magic numbers for CFG and CFG_EXT bitfields.

Signed-off-by: Brian Norris 
Tested-by: Anup Patel 
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 38 +---
 1 file changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c
index 4cba03d..dda96fa 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -344,6 +344,28 @@ static const u8 brcmnand_cs_offsets_cs0[] = {
[BRCMNAND_CS_TIMING2]   = 0x14,
 };
 
+/*
+ * Bitfields for the CFG and CFG_EXT registers. Pre-v7.1 controllers only had
+ * one config register, but once the bitfields overflowed, newer controllers
+ * (v7.1 and newer) added a CFG_EXT register and shuffled a few fields around.
+ */
+enum {
+   CFG_BLK_ADR_BYTES_SHIFT = 8,
+   CFG_COL_ADR_BYTES_SHIFT = 12,
+   CFG_FUL_ADR_BYTES_SHIFT = 16,
+   CFG_BUS_WIDTH_SHIFT = 23,
+   CFG_BUS_WIDTH   = BIT(CFG_BUS_WIDTH_SHIFT),
+   CFG_DEVICE_SIZE_SHIFT   = 24,
+
+   /* Only for pre-v7.1 (with no CFG_EXT register) */
+   CFG_PAGE_SIZE_SHIFT = 20,
+   CFG_BLK_SIZE_SHIFT  = 28,
+
+   /* Only for v7.1+ (with CFG_EXT register) */
+   CFG_EXT_PAGE_SIZE_SHIFT = 0,
+   CFG_EXT_BLK_SIZE_SHIFT  = 4,
+};
+
 /* BRCMNAND_INTFC_STATUS */
 enum {
INTFC_FLASH_STATUS  = GENMASK(7, 0),
@@ -1720,17 +1742,19 @@ static int brcmnand_set_cfg(struct brcmnand_host *host,
}
device_size = fls64(cfg->device_size) - fls64(BRCMNAND_MIN_DEVSIZE);
 
-   tmp = (cfg->blk_adr_bytes << 8) |
-   (cfg->col_adr_bytes << 12) |
-   (cfg->ful_adr_bytes << 16) |
-   (!!(cfg->device_width == 16) << 23) |
-   (device_size << 24);
+   tmp = (cfg->blk_adr_bytes << CFG_BLK_ADR_BYTES_SHIFT) |
+   (cfg->col_adr_bytes << CFG_COL_ADR_BYTES_SHIFT) |
+   (cfg->ful_adr_bytes << CFG_FUL_ADR_BYTES_SHIFT) |
+   (!!(cfg->device_width == 16) << CFG_BUS_WIDTH_SHIFT) |
+   (device_size << CFG_DEVICE_SIZE_SHIFT);
if (cfg_offs == cfg_ext_offs) {
-   tmp |= (page_size << 20) | (block_size << 28);
+   tmp |= (page_size << CFG_PAGE_SIZE_SHIFT) |
+  (block_size << CFG_BLK_SIZE_SHIFT);
nand_writereg(ctrl, cfg_offs, tmp);
} else {
nand_writereg(ctrl, cfg_offs, tmp);
-   tmp = page_size | (block_size << 4);
+   tmp = (page_size << CFG_EXT_PAGE_SIZE_SHIFT) |
+ (block_size << CFG_EXT_BLK_SIZE_SHIFT);
nand_writereg(ctrl, cfg_ext_offs, tmp);
}
 
-- 
1.9.1

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

Re: [PATCH v4 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Krzysztof Kozlowski]

On 30.10.2015 15:58, Pavel Fedin wrote:
>  Hello!
> 
>>> Add documentation for new subnode properties, allowing bank configuration.
>>> Based on u-boot implementation, but heavily reworked.
>>
>> Please, carefully look at:
>> Documentation/devicetree/bindings/net/gpmc-eth.txt
>> Documentation/devicetree/bindings/bus/ti-gpmc.txt
> 
>  Thank you very much. Indeed, this looks very similar. By the way, should i 
> document smsc over sromc in the same manner, writing
> devicetree/bindings/net/sromc-eth.txt?
> 
>  This is a short reply for now, i'll make longer one (or just a new version) 
> after studying these existing bindings and trying to
> apply them.

Existing SROMC bindings document is small so one document for everything
should be sufficient. This can be always split if new type of devices
will be using SROMC (BTW, do you know of any other devices using SROMC
on Exynos?).

> 
>  Pankaj:
> 
>>> + {
>>> +   pinctrl-names = "default";
>>> +   pinctrl-0 = <_ctl>, <_ebi>;
>>> +
>>> +   ethernet@0700 {
>>> +   compatible = "smsc,lan9115";
>>> +   reg = <0x0700 0x1>;
>>> +   phy-mode = "mii";
>>> +   interrupt-parent = <>;
>>> +   interrupts = <5 8>;
>>> +   reg-io-width = <2>;
>>> +   smsc,irq-push-pull;
>>> +   smsc,force-internal-phy;
>>> +
>>> +   samsung,srom-bank = <3>;
>>> +   samsung,srom-data-width = <2>;
>>> +   samsung,srom-timing = <1 9 12 1 9 1 1>;
>>
>> I think this is not correct. We can't change binding of "smsc,lan9115"
>> which is already documented here [1]. These samsung specific srom
>> properties should be in srom node or its subnode, but not in this way.
> 
>  So, if you look at gpmc-eth.txt, you'll see that this approach is perfectly 
> valid (this is a reply to another msg, just don't want
> to post one more single-line reply).


Yes, the binding of smsc,lan9115 is not changed.

Putting srom properties in separate bank node would be good also but
then some mapping (connection) between ethernet and bank should be added
probably...

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

[PATCH v2 0/3] dmaengine: ti-dma-crossbar: channel reserving and edma3-tpcc support

[Peter Ujfalusi]

Hi,

Changes since v1:
- Fixed issue introduced by the bitops patch: wrong error check, also switch to
  use find_first_zero_bit() instead of find_next_zero_bit()

Cover letter:

This series depends on the eDMA work I have done, which has been now applied:
https://lkml.org/lkml/2015/10/16/64

DRA7 family of chips have both sDMA and eDMA. Currently only sDMA can be used
becasue the old driver stack for eDMA did not allowed integration w/o hacks.

Due to the nature of eDMA the crossbar needs to know which eDMA events it can
use to map incoming events towards the eDMA. In eDMA a channel is wired to be
used with one specific event. For example eDMA event 14 can only be handled by
eDMA channel 14.
The eDMA itself can be shared by different processors in the system (ARM, DSP,
etc) and since ARM/Linux is the master we need to know which channels are used
by other cores. Also we need to mask out channels used for memcpy from the
events we use for HW triggers.

Regards,
Peter
---
Peter Ujfalusi (3):
  dmaengine: ti-dma-crossbar: dra7: Use bitops instead of idr
  dmaengine: ti-dma-crossbar: dra7: Support for reserving DMA event
ranges
  dmaengine: ti-dma-crossbar: dra7: Support for eDMA with new bindings

 .../devicetree/bindings/dma/ti-dma-crossbar.txt|  6 ++
 drivers/dma/ti-dma-crossbar.c  | 81 +++---
 2 files changed, 76 insertions(+), 11 deletions(-)

-- 
2.6.1

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

[RESEND PATCH 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288

[Zain Wang]

Crypto driver support cbc/ecb two chainmode, and aes/des/des3 three cipher mode.
The names registered are:
ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
You can alloc tags above in your case.

And other algorithms and platforms will be added later on.

Signed-off-by: Zain Wang 
---
 drivers/crypto/Makefile|   1 +
 drivers/crypto/rk_crypto/Makefile  |   3 +
 drivers/crypto/rk_crypto/rk3288_crypto.c   | 393 
 drivers/crypto/rk_crypto/rk3288_crypto.h   | 291 
 .../crypto/rk_crypto/rk3288_crypto_ablkcipher.c| 502 +
 5 files changed, 1190 insertions(+)
 create mode 100644 drivers/crypto/rk_crypto/Makefile
 create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.c
 create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.h
 create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto_ablkcipher.c

diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index c3ced6f..00d103c 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
 obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
 obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
 obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
+obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto/
diff --git a/drivers/crypto/rk_crypto/Makefile 
b/drivers/crypto/rk_crypto/Makefile
new file mode 100644
index 000..0f62d87
--- /dev/null
+++ b/drivers/crypto/rk_crypto/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto_driver.o
+rk_crypto_driver-objs := rk3288_crypto.o \
+rk3288_crypto_ablkcipher.o \
diff --git a/drivers/crypto/rk_crypto/rk3288_crypto.c 
b/drivers/crypto/rk_crypto/rk3288_crypto.c
new file mode 100644
index 000..fe55d7e
--- /dev/null
+++ b/drivers/crypto/rk_crypto/rk3288_crypto.c
@@ -0,0 +1,393 @@
+/*
+ *Crypto acceleration support for Rockchip RK3288
+ *
+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Zain Wang 
+ *
+ * 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.
+ *
+ * Some ideas are from marvell/cesa.c and s5p-sss.c driver.
+ */
+
+#include "rk3288_crypto.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct crypto_info_t *crypto_p;
+
+static int rk_crypto_enable_clk(struct crypto_info_t *dev)
+{
+   if (clk_prepare_enable(dev->clk)) {
+   dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'clk'\n",
+   __func__, __LINE__);
+   return -ENOENT;
+   }
+   if (clk_prepare_enable(dev->aclk)) {
+   dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
+   __func__, __LINE__);
+   goto err_aclk;
+   }
+   if (clk_prepare_enable(dev->hclk)) {
+   dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
+   __func__, __LINE__);
+   goto err_hclk;
+   }
+   if (clk_prepare_enable(dev->pclk)) {
+   dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'pclk'\n",
+   __func__, __LINE__);
+   goto err_pclk;
+   }
+   return 0;
+
+err_pclk:
+   clk_disable_unprepare(dev->hclk);
+err_hclk:
+   clk_disable_unprepare(dev->aclk);
+err_aclk:
+   clk_disable_unprepare(dev->clk);
+
+   return -ENOENT;
+}
+
+static void rk_crypto_disable_clk(struct crypto_info_t *dev)
+{
+   clk_disable_unprepare(dev->hclk);
+   clk_disable_unprepare(dev->aclk);
+   clk_disable_unprepare(dev->pclk);
+   clk_disable_unprepare(dev->clk);
+}
+
+static int check_alignment(struct scatterlist *sg_src,
+  struct scatterlist *sg_dst,
+  int align_mask)
+{
+   int in, out, align;
+
+   in = IS_ALIGNED((u32)sg_src->offset, 4) &&
+IS_ALIGNED(sg_src->length, align_mask);
+   if (sg_dst == NULL)
+   return in;
+   out = IS_ALIGNED((u32)sg_dst->offset, 4) &&
+ IS_ALIGNED(sg_dst->length, align_mask);
+   align = in && out;
+
+   return (align && (sg_src->length == sg_dst->length));
+}
+
+static int rk_load_data(struct crypto_info_t *dev,
+ struct scatterlist *sg_src,
+ struct scatterlist *sg_dst)
+{
+   uint32_t count;
+   int ret;
+
+   dev->aligned = dev->aligned ?
+   check_alignment(sg_src, sg_dst, dev->align_size) :
+   dev->aligned;
+   if (dev->aligned) {
+   count = min(dev->left_bytes, sg_src->length);
+   dev->left_bytes -= count;
+
+   ret = 

Re: [PATCH 1/2] dma: add Qualcomm Technologies HIDMA management driver

[Mark Rutland]

On Fri, Oct 30, 2015 at 10:15:09PM +0200, Andy Shevchenko wrote:
> On Fri, Oct 30, 2015 at 10:08 PM, Al Stone  wrote:
> > On 10/30/2015 01:01 PM, Mark Rutland wrote:
> >> On Fri, Oct 30, 2015 at 02:48:06PM -0400, Sinan Kaya wrote:
> 
> >> The CSRT is listed under "Want", not "Never" or "Don't Care", so Linaro
> >> have certainly not said that CSRT will not be supported. If anything,
> >> they have stated that the table should be supported.
> >
> > "Want" means interesting, and probably useful, but no clear indication that
> > anyone actually needs it.  At one point, we thought we might use the CSRT
> > for describing DMA, but it turns out we have not needed to.
> 
> Then you are going to have either 1 or 0 DMAC for slave devices, right?

I suspect that the currently supported platforms have 0. If not, we have
problems.

> The CSRT, unfortunately, the only way how to enumerate DMAC to be used
> by slave devices.
> You may look into drivers/dma/acpi-dma.c for usage in Linux.
> 
> Yes, I know about _DSD, but I don't think it will provide soon any
> other official mechanisms to what we have now. Better to ask Rafael
> and Mika.

_DSD is insufficient here, given that there is no prescribed way to use
it to describe DMA. Anything for that would have to go through ASWG
before we could use it.

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 v2 1/3] devicetree: mfd: Add binding for the TI LM3533

[Rob Herring]

On Fri, Oct 30, 2015 at 2:41 PM, Bjorn Andersson
 wrote:
> On Fri 30 Oct 11:42 PDT 2015, Lee Jones wrote:
>
> Rob, please see the discussion regarding ti,boost-freq-khz below. Should
> we both specify unit at the same time as we use standard units? (This is
> not the first time I have to change this back and forth)
>
>> On Tue, 27 Oct 2015, Bjorn Andersson wrote:
>>
> [..]
>> > +- ti,hwen-gpios:
>> > +   Usage: required
>> > +   Value type: 
>> > +   Definition: reference to gpio pin connected to the HWEN input; as
>> > +   specified in "gpio/gpio.txt"
>>
>> Why have you made this a vendor binding?
>>
>> *-gpios is a generic property.
>>
>
> Because the hwen gpio is a ti lm3533 specific thing, but I get what
> you're saying. Will drop the prefix.

Actually, that is fine. -gpios is common, but the rest is specific to
a binding. But if it is a common function, then a common name would be
fine. Enable gpios are common for example.

>> > +- ti,als-supply:
>> > +   Usage: optional
>> > +   Value type: 
>> > +   Definition: reference to regulator powering the V_als input; as
>> > +   specified in "regulator/regulator.txt"
>>
>> Same goes for *-supply.
>>
>
> Same here
>
>> > +- ti,boost-freq-khz:
>> > +   Usage: required
>> > +   Value type: 
>> > +   Definition: switch-frequency of the boost converter, must be either:
>> > +   500 or 1000
>>
>> Quite a few vendors are using 'boost' now.
>>
>
> The ti,boost-low-freq from the bq25890 binding is the only other
> property I can find that describes the same thing. So I'm not sure I
> follow you here.
>
>> Perhaps we need to create a set of generic bindings.
>>
>> Also, we usually measure DT bindings in HZ, not kHz.

Surprisingly, there are not enough examples to draw much conclusion.

> I thought we had defined frequencies to be in HZ and HZ only, but then
> Rob's comment that I need to actually specify the unit doesn't make any
> sense.

I don't think we decided, but let's decide now. Go with Hz.

Really, I first prefer the property name has units and second having
standardized units. But if there is a common property without units, I
prefer that even more.

> Do we want these properties in a standard unit or do we want them
> specifying the unit? Having both seems excessive.

You mean "freq" would imply the units? No, we want the actual units in
the property.

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

Re: [PATCH 1/3] PM / OPP: Add "opp-supported-hw" binding

[Stephen Boyd]

On 10/30, Viresh Kumar wrote:
> +- opp-supported-hw: User defined array containing a hierarchy of hardware
> +  version numbers, supported by the OPP. For example: a platform with 
> hierarchy
> +  of three levels of versions (A, B and C), this field should be like  Z>,
> +  where X corresponds to Version hierarchy A, Y corresponds to version 
> hierarchy
> +  B and Z corresponds to version hierarchy C.
> +
> +  Each level of hierarchy is represented by a 32 bit value, and so there can 
> be
> +  only 32 different supported version per hierarchy. i.e. 1 bit per version. 
> A
> +  value of 0x will enable the OPP for all versions for that hierarchy
> +  level. And a value of 0x will disable the OPP completely, and so we
> +  never want that to happen.

I suppose if you wanted to have 64 possible combinations of some
attribute you would just extend it to two 32 bit numbers in
sequence? I don't see the limitation here, and hopefully there
isn't a limitation so that we can specify sufficiently large
numbers with more bits if we need to.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 2/5] mfd: tps65912: Remove old driver in preparation for new driver

[Andrew F. Davis]

The old tps65912 driver is being replaced, delete old driver.

Signed-off-by: Andrew F. Davis 
Acked-by: Lee Jones 
---
 drivers/gpio/Kconfig   |   6 -
 drivers/gpio/Makefile  |   1 -
 drivers/gpio/gpio-tps65912.c   | 153 --
 drivers/mfd/Kconfig|  26 --
 drivers/mfd/Makefile   |   4 -
 drivers/mfd/tps65912-core.c| 175 ---
 drivers/mfd/tps65912-i2c.c | 139 -
 drivers/mfd/tps65912-irq.c | 217 -
 drivers/mfd/tps65912-spi.c | 141 -
 drivers/regulator/Kconfig  |   6 -
 drivers/regulator/Makefile |   1 -
 drivers/regulator/tps65912-regulator.c | 541 -
 include/linux/mfd/tps65912.h   | 328 
 13 files changed, 1738 deletions(-)
 delete mode 100644 drivers/gpio/gpio-tps65912.c
 delete mode 100644 drivers/mfd/tps65912-core.c
 delete mode 100644 drivers/mfd/tps65912-i2c.c
 delete mode 100644 drivers/mfd/tps65912-irq.c
 delete mode 100644 drivers/mfd/tps65912-spi.c
 delete mode 100644 drivers/regulator/tps65912-regulator.c
 delete mode 100644 include/linux/mfd/tps65912.h

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b4fc9e4..fb28483 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -838,12 +838,6 @@ config GPIO_TPS65910
  Select this option to enable GPIO driver for the TPS65910
  chip family.
 
-config GPIO_TPS65912
-   tristate "TI TPS65912 GPIO"
-   depends on (MFD_TPS65912_I2C || MFD_TPS65912_SPI)
-   help
- This driver supports TPS65912 gpio chip
-
 config GPIO_TWL4030
tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
depends on TWL4030_CORE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f79a7c4..605bf89 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -96,7 +96,6 @@ obj-$(CONFIG_GPIO_TIMBERDALE) += gpio-timberdale.o
 obj-$(CONFIG_GPIO_PALMAS)  += gpio-palmas.o
 obj-$(CONFIG_GPIO_TPS6586X)+= gpio-tps6586x.o
 obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
-obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
 obj-$(CONFIG_GPIO_TS5500)  += gpio-ts5500.o
 obj-$(CONFIG_GPIO_TWL4030) += gpio-twl4030.o
 obj-$(CONFIG_GPIO_TWL6040) += gpio-twl6040.o
diff --git a/drivers/gpio/gpio-tps65912.c b/drivers/gpio/gpio-tps65912.c
deleted file mode 100644
index 9cdbc0c..000
--- a/drivers/gpio/gpio-tps65912.c
+++ /dev/null
@@ -1,153 +0,0 @@
-/*
- * Copyright 2011 Texas Instruments Inc.
- *
- * Author: Margarita Olaya 
- *
- *  This program is free software; you can redistribute it and/or modify it
- *  under  the terms of the GNU General  Public License as published by the
- *  Free Software Foundation;  either version 2 of the License, or (at your
- *  option) any later version.
- *
- * This driver is based on wm8350 implementation.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-struct tps65912_gpio_data {
-   struct tps65912 *tps65912;
-   struct gpio_chip gpio_chip;
-};
-
-#define to_tgd(gc) container_of(gc, struct tps65912_gpio_data, gpio_chip)
-
-static int tps65912_gpio_get(struct gpio_chip *gc, unsigned offset)
-{
-   struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
-   struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-   int val;
-
-   val = tps65912_reg_read(tps65912, TPS65912_GPIO1 + offset);
-
-   if (val & GPIO_STS_MASK)
-   return 1;
-
-   return 0;
-}
-
-static void tps65912_gpio_set(struct gpio_chip *gc, unsigned offset,
- int value)
-{
-   struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
-   struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-
-   if (value)
-   tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
-   GPIO_SET_MASK);
-   else
-   tps65912_clear_bits(tps65912, TPS65912_GPIO1 + offset,
-   GPIO_SET_MASK);
-}
-
-static int tps65912_gpio_output(struct gpio_chip *gc, unsigned offset,
-   int value)
-{
-   struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
-   struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-
-   /* Set the initial value */
-   tps65912_gpio_set(gc, offset, value);
-
-   return tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
-   GPIO_CFG_MASK);
-}
-
-static int tps65912_gpio_input(struct gpio_chip *gc, unsigned offset)
-{
-   struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
-   struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-
-   return tps65912_clear_bits(tps65912, TPS65912_GPIO1 + offset,
-  

Re: [PATCH 2/2] dma: add Qualcomm Technologies HIDMA channel driver

[Arnd Bergmann]

On Friday 30 October 2015 17:36:45 Timur Tabi wrote:
> On 10/30/2015 05:28 PM, Arnd Bergmann wrote:
> >>> > >Why ENODEV? Could you make this handle restarted system calls?
> >> >
> >> >This is the self test code. It gets called from probe. If there is a
> >> >problem with the device or system configuration, I don't want to enable
> >> >this device. I can certainly return a different error code though.
> >> >What's a good code?
> > I see. probe() is not restartable, so it cannot be -ERESTARTSYS.
> >
> > Maybe better use wait_event_timeout and not handle the signals then.
> > It will eventually time out if something goes wrong.
> 
> What about -EPROBE_DEFER?  Isn't that "restartable"?  Granted, it's only 
> supposed to be used if the driver is dependent on another driver to 
> probe, so I'm not sure it applies here.  If the self-test fails, then it 
> is possible that it could succeed later?

No, this is different. The probe function can get called from all sorts
of contexts (sys_init_module, device_create, deferred probing), and not
all of them go back to user space when returning an error, so we cannot
deliver a signal to the calling process this way.

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

[PATCH v2 2/2] ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset

[Douglas Anderson]

From: Doug Anderson 

The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
has a hardware errata that causes everything to get confused when we get
a remote wakeup.  We'll use the reset that's in the CRU to reset the
port when it's in a bad state.

Note that we add the reset to both dwc2 controllers even though only one
has the errata in case we find some other use for this reset that's
unrelated to the current hardware errata.  Only the host port gets the
quirk property, though.

Signed-off-by: Douglas Anderson 
---
Changes in v2:
- Use a full PHY reset for safety; no PHY changes needed for that.

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

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 906e938fb6bf..58773beb283f 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -496,6 +496,9 @@
dr_mode = "host";
phys = <>;
phy-names = "usb2-phy";
+   resets = < SRST_USBHOST1_PHY>;
+   reset-names = "phy-full-reset";
+   snps,need-phy-full-reset-on-wake;
status = "disabled";
};
 
@@ -513,6 +516,8 @@
g-use-dma;
phys = <>;
phy-names = "usb2-phy";
+   resets = < SRST_USBOTG_PHY>;
+   reset-names = "phy-full-reset";
status = "disabled";
};
 
-- 
2.6.0.rc2.230.g3dd15c0

--
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] dma: add Qualcomm Technologies HIDMA channel driver

[Arnd Bergmann]

On Friday 30 October 2015 16:55:16 Timur Tabi wrote:
> 
> On 10/30/2015 04:42 PM, Sinan Kaya wrote:
> >>
> >> if (WARN_ON(!pdev->dev.dma_mask))
> >> return -ENXIO;
> >>
> >> The dma mask has to always be set by the platform code before probe()
> >> is called. If it is not set, you are not allowed to perform DMA.
> >
> > I tested this on an ACPI platform BTW when I was working on the initial
> > implementation.
> 
> PowerPC sets the mask to 32 bits by default:
> 
> http://lxr.free-electrons.com/ident?i=arch_setup_pdev_archdata
> 
> Should we do something similar in ARM64?  Today, we have to manually set 
> the DMA mask in all drivers.

We set the dma mask from the 'dma-ranges' property of the parent device,
but fall back to 32-bit because we did not manage to mandate this property
in time for all arm64 machines to use.

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

Re: [PATCH 2/2] sound: soc: Add Cygnus audio driver

[kbuild test robot]

Hi Simran,

[auto build test WARNING on asoc/for-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Simran-Rai/Add-audio-support-for-Broadcom-Cygnus-SoC/20151031-025721
config: tile-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile 

All warnings (new ones prefixed by >>):

   sound/soc/bcm/cygnus-pcm.c: In function 'cygnus_pcm_preallocate_dma_buffer':
>> sound/soc/bcm/cygnus-pcm.c:785:2: warning: format '%x' expects argument of 
>> type 'unsigned int', but argument 5 has type 'size_t' [-Wformat]

vim +785 sound/soc/bcm/cygnus-pcm.c

   769  
   770  static int cygnus_pcm_preallocate_dma_buffer(struct snd_pcm *pcm, int 
stream)
   771  {
   772  struct snd_pcm_substream *substream = 
pcm->streams[stream].substream;
   773  struct snd_soc_pcm_runtime *rtd = substream->private_data;
   774  struct snd_dma_buffer *buf = >dma_buffer;
   775  size_t size;
   776  
   777  size = cygnus_pcm_hw.buffer_bytes_max;
   778  
   779  buf->dev.type = SNDRV_DMA_TYPE_DEV;
   780  buf->dev.dev = pcm->card->dev;
   781  buf->private_data = NULL;
   782  buf->area = dma_alloc_coherent(pcm->card->dev, size,
   783  >addr, GFP_KERNEL);
   784  
 > 785  dev_dbg(rtd->cpu_dai->dev, "%s: size 0x%x @ 0x%p\n",
   786  __func__, size, buf->area);
   787  
   788  if (!buf->area) {
   789  dev_err(rtd->cpu_dai->dev, "%s: dma_alloc failed\n", 
__func__);
   790  return -ENOMEM;
   791  }
   792  buf->bytes = size;
   793  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH v2 0/2] Patches to fix remote wakeup on rk3288 dwc2 "host" port

[Douglas Anderson]

On the rk3288 USB host-only port (the one that's not the OTG-enabled
port) the PHY can get into a bad state when a wakeup is asserted (not
just a wakeup from full system suspend but also a wakeup from
autosuspend).

We can get the PHY out of its bad state by asserting its "port reset",
but unfortunately that seems to assert a reset onto the USB bus so it
could confuse things if we don't actually deenumerate / reenumerate the
device.

We can also get the PHY out of its bad state by fully resetting it using
the reset from the CRU (clock reset unit), which does a more full
reset.  The CRU-based reset appears to actually cause devices on the bus
to be removed and reinserted, which fixes the problem (albeit in a hacky
way).

It's unfortunate that we need to do a full re-enumeration of devices at
wakeup time, but this is better than alternative of letting the bus get
wedged.

I've tested this series atop a bit of a conglomeration of Heiko's github
"somewhat stable" branch (v4.3-rc3-876-g6509232) but with Greg KH's
usb-next merged in.

===

I've posted up a bunch of patches recently but tried to keep them in
separate series where it makes sense.  A summary of known patches:
All patches can be found with: https://patchwork.kernel.org/patch//

ACKed (thanks!) and not yet landed:
 7453801  usb: dwc2: host: Fix ahbcfg for rk3066
 7467521  usb: dwc2: host: Fix remote wakeup when not in DWC2_L2

Important, not yet reviewed:
 7421171  [1/2] usb: dwc2: host: Fix missing device insertions

Fixes no known issues, not yet reviewed:
 7421181  [2/2] usb: dwc2: host: Clear interrupts before handling them

Optimization to reduce probe time (may require simple rebase):
 7348131  [1/5] usb: dwc2: Restore GUSBCFG in dwc2_get_hwparams()
 7348221  [2/5] usb: dwc2: reset dwc2 core before dwc2_get_hwparams()
 7348191  [3/5] CHROMIUM: usb: dwc2: Avoid double-reset at boot time
 7348211  [4/5] usb: dwc2: Speed dwc2_get_hwparams() on some host-only ports
 7348201  [5/5] usb: dwc2: reduce dwc2 driver probe time
 7355241  usb: dwc2: Avoid more calls to dwc2_core_reset()

This series:
 usb: dwc2: optionally assert phy "full reset" when waking up
 ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset

Coming soon:
 RFT: usb: dwc2: bus suspend/resume that's not hibernate

Abandoned for now (can't get wakeup to work on mainline):
 6727091  [REPOST,1/3] USB: Export usb_wakeup_enabled_descendants()
 6727101  [REPOST,2/3] Documentation: dt-bindings: Add snps,need-phy-for-wake 
for dwc2 USB
 6727121  [REPOST,3/3] USB: dwc2: Don't turn off the usbphy in suspend if 
wakeup is enabled

Changes in v2:
- Use a full PHY reset for safety; no PHY changes needed for that.
- Cover letter explains outstanding patches

Doug Anderson (2):
  usb: dwc2: optionally assert phy "full reset" when waking up
  ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset

 Documentation/devicetree/bindings/usb/dwc2.txt |  7 +++
 arch/arm/boot/dts/rk3288.dtsi  |  5 +
 drivers/usb/dwc2/core.h|  5 +
 drivers/usb/dwc2/core_intr.c   | 14 ++
 drivers/usb/dwc2/platform.c| 13 +
 5 files changed, 44 insertions(+)

-- 
2.6.0.rc2.230.g3dd15c0

--
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] arm64: dts: Added syscon-reboot node for FSL's LS2085A SoC

[J. German Rivera]

Added sys-reboot node to the FSL's LS2085A SoC DT to leverage
the ARM-generic reboot mechanism for this SoC. This mechanism
is enabled through CONFIG_POWER_RESET_SYSCON.

Signed-off-by: J. German Rivera 
---
CHANGE HISTORY:

Changes in v2:
- Addressed comment form Stuart Yoder:
  * Removed "@" from reboot node

Changes in v3:
- Addressed comment form Stuart Yoder:
  * Expose only the reset register

Changes in v4:
- Addressed comment from Arnd Bergmann:
  * Changed compatible string to be more specific
  * Changed node name to 'syscon' instead of 'rstcr'
  * Changed address to lower case hex
- Addressed comment form Stuart Yoder:
  * Rebase on top of branch arm-soc/for-next

 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index e81cd48..a790a90 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -153,6 +153,18 @@
};
};

+   rstcr: syscon@1e6 {
+   compatible = "fsl,ls2085a-rstcr", "syscon";
+   reg = <0x0 0x1e6 0x0 0x4>;
+   };
+
+   reboot {
+   compatible ="syscon-reboot";
+   regmap = <>;
+   offset = <0x0>;
+   mask = <0x2>;
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low */
--
2.3.3

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

Re: [PATCH v8 1/5] Documentation: add sbsa-gwdt driver documentation

[Timur Tabi]

On 10/30/2015 02:05 PM, Mark Rutland wrote:

I was only asking why the interrupt was optional, and it seems per the
spec it's expected to be handed to an agent at a higher exception level.

That implies that the OS should only care about WS0, assuming that I've
understood correctly.


Yes, this my understand as well.  Apologies if I didn't get that across.

--
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 02/19] clk: sunxi: Add PLL3 clock

[Stephen Boyd]

On 10/30, Maxime Ripard wrote:
> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> index a9e1a5885846..40c32ffd912c 100644
> --- a/drivers/clk/sunxi/Makefile
> +++ b/drivers/clk/sunxi/Makefile
> @@ -9,8 +9,9 @@ obj-y += clk-a10-mod1.o
>  obj-y += clk-a10-pll2.o
>  obj-y += clk-a20-gmac.o
>  obj-y += clk-mod0.o
> -obj-y += clk-sun4i-display.o
>  obj-y += clk-simple-gates.o
> +obj-y += clk-sun4i-display.o

Put this in the right place in patch 1 please.

> +obj-y += clk-sun4i-pll3.o
>  obj-y += clk-sun8i-mbus.o
>  obj-y += clk-sun9i-core.o
>  obj-y += clk-sun9i-mmc.o
> diff --git a/drivers/clk/sunxi/clk-sun4i-pll3.c 
> b/drivers/clk/sunxi/clk-sun4i-pll3.c
> new file mode 100644
> index ..7ea178bf19fa
> --- /dev/null
> +++ b/drivers/clk/sunxi/clk-sun4i-pll3.c
> @@ -0,0 +1,84 @@
> +/*
> + * Copyright 2015 Maxime Ripard
> + *
> + * Maxime Ripard 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 

#include  for of_property_read_string()

> +#include 
> +#include 
> +
> +#define SUN4I_A10_PLL3_GATE_BIT  31
[...]
> +
> + clk = clk_register_composite(NULL, clk_name,
> +  , 1,
> +  NULL, NULL,
> +  >hw, _factor_ops,
> +  >hw, _gate_ops,
> +  0);
> + if (IS_ERR(clk)) {
> + pr_err("%s: Couldn't register the clock\n", clk_name);
> + goto free_mult;
> + }
> +
> + of_clk_add_provider(node, of_clk_src_simple_get, clk);

I hope this doesn't fail.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] PM / OPP: Remove 'operating-points-names' binding

[Stephen Boyd]

On 10/30, Viresh Kumar wrote:
> These aren't used until now by any DT files and wouldn't be used now as
> we have a better scheme in place now, i.e. opp-property-
> properties.
> 
> Remove the (useless) binding without breaking ABI.
> 
> Signed-off-by: Viresh Kumar 
> ---

Reviewed-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] PM / OPP: Add {opp-microvolt|opp-microamp|turbo-mode|opp-suspend}- binding

[Stephen Boyd]

On 10/30, Viresh Kumar wrote:
> Depending on the version of hardware or its properties, which are only
> known at runtime, various properties of the OPP can change. For example,
> an OPP with frequency 1.2 GHz, may have different voltage/current
> requirements based on the version of the hardware it is running on.
> Similarly, it may or may not be a turbo or suspend OPP on those
> circumstances.
> 
> In order to not replicate the same OPP tables for varying values of all
> such fields, this commit introduces the concept of opp-property-.
> The  can be chosen by the platform at runtime, and OPPs will be
> initialized depending on that name string. Currently support is extended
> for the following properties:
> - opp-microvolt-
> - opp-microamp-
> - turbo-mode-
> - opp-suspend-
> 
> If the name string isn't provided by the platform, or if it is provided
> but doesn't match the properties present in the OPP node, we will fall
> back to the original properties without the - string, if they are
> available.
> 
> Signed-off-by: Viresh Kumar 
> ---

Reviewed-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] PM / OPP: Add "opp-supported-hw" binding

[Stephen Boyd]

On 10/30, Viresh Kumar wrote:
> + opp_table {
> + compatible = "operating-points-v2";
> + status = "okay";
> + opp-shared;
> +
> + opp00 {

A side-note. I wonder if it would be better style to have the
node name be:

opp@6 {

At least it seems that the assumption is we can store all the
possible combinations of OPP values for a particular frequency in
the same node. Following this style would make dt compilation
fail if two nodes have the same frequency.

Also, this makes it sound like opp-supported-hw is really just
telling us if this is a supported frequency or not for the
particular device we're running on. The current wording makes it
sound like we could have two OPP nodes with the same frequency
but different voltages inside them, which we're trying to
discourage by compressing the tables into less nodes.

I think in Lee's case we're only going to use the cuts parameter
to figure out if the OPP is supported or not. On qcom platforms
we will only use one parameter for this property as well, the
speed bin. The slow/fast and version stuff will be handled by
named opp properties.

> + /*
> +  * Supports all substrate and process versions for 0xF
> +  * cuts, i.e. only first four cuts.
> +  */
> + opp-supported-hw = <0xF 0x 0x>
> + opp-hz = /bits/ 64 <6>;
> + opp-microvolt = <90 915000 925000>;

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 1/5] Documentation: tps65912: Add DT bindings for the TPS65912 PMIC

[Andrew F. Davis]

The TPS65912 PMIC contains several regulators and a GPIO controller.
Add bindings for the TPS65912 PMIC.

Signed-off-by: Andrew F. Davis 
---
 .../devicetree/bindings/gpio/gpio-tps65912.txt | 16 +++
 Documentation/devicetree/bindings/mfd/tps65912.txt | 51 ++
 .../bindings/regulator/tps65912-regulator.txt  | 28 
 3 files changed, 95 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/tps65912-regulator.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt 
b/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
new file mode 100644
index 000..ba8d633
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
@@ -0,0 +1,16 @@
+* TPS65912 GPIO Controller bindings
+
+Required properties:
+ - compatible  : Should be "ti,tps65912-gpio".
+ - gpio-controller : Marks the device node as a GPIO Controller.
+ - #gpio-cells : Should be two.  The first cell is the pin number and
+   the second cell is used to specify flags.
+   See ../gpio/gpio.txt for more information.
+
+Example:
+
+   gpio4: gpio {
+   compatible = "ti,tps65912-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
diff --git a/Documentation/devicetree/bindings/mfd/tps65912.txt 
b/Documentation/devicetree/bindings/mfd/tps65912.txt
new file mode 100644
index 000..65426b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65912.txt
@@ -0,0 +1,51 @@
+* TPS65912 Power Management Integrated Circuit bindings
+
+Required properties:
+ - compatible  : Should be "ti,tps65912".
+ - reg : Slave address or chip select number (I2C / SPI).
+ - interrupt-parent: The parent interrupt controller.
+ - interrupts  : The interrupt line the device is connected to.
+ - interrupt-controller: Marks the device node as an interrupt 
controller.
+ - #interrupt-cells: The number of cells to describe an IRQ, this should 
be 2.
+   The first cell is the IRQ number.
+   The second cell is the flags, encoded as the 
trigger masks from
+   ../interrupt-controller/interrupts.txt.
+
+Additional nodes defined in:
+ - Regulators: ../regulator/tps65912-regulator.txt
+ - GPIO: ../gpio/gpio-tps65912.txt.
+
+Example:
+
+   pmic: tps65912@2d {
+   compatible = "ti,tps65912";
+   reg = <0x2d>;
+   interrupt-parent = <>;
+   interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   regulators {
+   compatible = "ti,tps65912-regulator";
+
+   dcdc1 {
+   regulator-name = "vdd_core";
+   regulator-min-microvolt = <912000>;
+   regulator-max-microvolt = <1144000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   ldo1 {
+   regulator-name = "ldo1";
+   regulator-min-microvolt = <190>;
+   regulator-max-microvolt = <190>;
+   };
+   };
+
+   gpio4: gpio {
+   compatible = "ti,tps65912-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+   };
diff --git a/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt 
b/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
new file mode 100644
index 000..b81973d
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
@@ -0,0 +1,28 @@
+* TPS65912 regulator bindings
+
+Required properties:
+ - compatible  : Should be "ti,tps65912-regulator".
+ - list of regulators provided by this controller, must be named
+ after their hardware counterparts: dcdc[1-4] and ldo[1-10].
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+   regulator {
+   compatible = "ti,tps65912-regulator";
+
+   dcdc1 {
+   regulator-name = "vdd_core";
+   regulator-min-microvolt = <912000>;
+   regulator-max-microvolt = <1144000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   ldo1 {
+   regulator-name = "ldo1";
+   regulator-min-microvolt = <190>;
+   

[PATCH v6 0/5] mfd: tps65912: Driver rewrite with DT support

[Andrew F. Davis]

In an effort to cleanup this driver and add Device Tree support
the driver has been rewritten based on new driver styles and
modern kernel driver helpers. This has nearly halved the lines
of code while keeping all previous functionality.

Platform file based initialization has been dropped as there is
no examples of this use in the kernel.

v1 can be found here: [1] v2: [2] v3: [3] v4: [4] v5: [5]

Changes from v5:
 - Small formatting changes to DT Docs
 - Converted to_tps65912_gpio from macro to inline function

Changes from v4:
 - Use mfd core to add sub-devices

Changes from v3:
 - Reorganized regulator driver and related DT node
 - Other small fixes as discussed in v3 thread

Changes from v2:
 - Split the series further into subsystems

Changes from v1:
 - Split the rewrite into delete/create patches
 - Several small fixes as discussed in v1 thread

[1] http://www.spinics.net/lists/devicetree/msg93863.html
[2] http://www.spinics.net/lists/devicetree/msg95003.html
[3] http://www.spinics.net/lists/devicetree/msg95133.html
[4] http://www.spinics.net/lists/devicetree/msg96109.html
[5] http://www.spinics.net/lists/devicetree/msg100601.html

Andrew F. Davis (5):
  Documentation: tps65912: Add DT bindings for the TPS65912 PMIC
  mfd: tps65912: Remove old driver in preparation for new driver
  mfd: tps65912: Add driver for the TPS65912 PMIC
  regulator: tps65912: Add regulator driver for the TPS65912 PMIC
  gpio: tps65912: Add GPIO driver for the TPS65912 PMIC

 .../devicetree/bindings/gpio/gpio-tps65912.txt |  16 +
 Documentation/devicetree/bindings/mfd/tps65912.txt |  51 ++
 .../bindings/regulator/tps65912-regulator.txt  |  28 +
 drivers/gpio/Kconfig   |   2 +-
 drivers/gpio/gpio-tps65912.c   | 292 -
 drivers/mfd/Kconfig|  22 +-
 drivers/mfd/Makefile   |   3 +-
 drivers/mfd/tps65912-core.c| 297 -
 drivers/mfd/tps65912-i2c.c | 220 +++
 drivers/mfd/tps65912-irq.c | 217 ---
 drivers/mfd/tps65912-spi.c | 221 +++
 drivers/regulator/Kconfig  |   2 +-
 drivers/regulator/tps65912-regulator.c | 711 +
 include/linux/mfd/tps65912.h   | 211 +++---
 14 files changed, 815 insertions(+), 1478 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
 rewrite drivers/gpio/gpio-tps65912.c (69%)
 rewrite drivers/mfd/tps65912-core.c (95%)
 rewrite drivers/mfd/tps65912-i2c.c (93%)
 delete mode 100644 drivers/mfd/tps65912-irq.c
 rewrite drivers/mfd/tps65912-spi.c (92%)
 rewrite drivers/regulator/tps65912-regulator.c (94%)

-- 
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 1/2] drm/panel: Add Sharp LS043T1LE01 panel binding documentation

[Bjorn Andersson]

From: Werner Johansson 

Signed-off-by: Werner Johansson 
Signed-off-by: Bjorn Andersson 
---

Change since v1:
- Dropped -vid suffix from compatible

 .../bindings/display/panel/sharp,ls043t1le01.txt   | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt 
b/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt
new file mode 100644
index ..b3d4e073930a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt
@@ -0,0 +1,22 @@
+Sharp Microelectronics 4.3" qHD TFT LCD panel
+
+Required properties:
+- compatible: should be "sharp,ls043t1le01-qhd"
+- reg: DSI virtual channel of the peripheral
+- power-supply: phandle of the regulator that provides the supply voltage
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+- reset-gpios: a GPIO spec for the reset pin
+
+Example:
+
+   mdss_dsi@fd922800 {
+   panel@0 {
+   compatible = "sharp,ls043t1le01-qhd";
+   reg = <0>;
+   avdd-supply = <_l22>;
+   backlight = <_wled>;
+   reset-gpios = <_gpios 19 GPIO_ACTIVE_HIGH>;
+   };
+   };
-- 
2.4.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: [REPOST PATCH 0/3] dwc2 patches to allow wakeup on Rockchip rk3288

[Doug Anderson]

John,

On Mon, Oct 26, 2015 at 7:05 PM, John Youn  wrote:
> On 10/21/2015 9:23 AM, Doug Anderson wrote:
>> John,
>>
>> On Mon, Jul 6, 2015 at 11:27 AM, Douglas Anderson  
>> wrote:
>>> This series of patches, together with
>>>  from Chris Zhong and a
>>> dts change allow us to wake up from a USB device on rk3288 boards.
>>> The patches were tested on rk3288-jerry in the chromeos-3.14 kernel.
>>> The chromeos-3.14 kernel tested included a full set of dwc2 backports
>>> from upstream, so this is expected to function upstream once we get
>>> everything setup there.
>>>
>>>
>>> Douglas Anderson (3):
>>>   USB: Export usb_wakeup_enabled_descendants()
>>>   Documentation: dt-bindings: Add snps,need-phy-for-wake for dwc2 USB
>>>   USB: dwc2: Don't turn off the usbphy in suspend if wakeup is enabled
>>>
>>>  Documentation/devicetree/bindings/usb/dwc2.txt |  4 +++
>>>  drivers/usb/core/hub.c |  7 ++--
>>>  drivers/usb/dwc2/core.h|  2 ++
>>>  drivers/usb/dwc2/platform.c| 45 
>>> --
>>>  include/linux/usb/hcd.h|  5 +++
>>>  5 files changed, 58 insertions(+), 5 deletions(-)
>>
>> This series was posted a while ago.  Do you have any comments on it?
>> Should I repost it?
>>
>> Thanks!
>>
>> -Doug
>>
>
>
> Sorry, I must have missed it earlier.
>
> Could you repost based on latest and I'll review.

I tried today but something has changed in mainline Linux and the
rk3288 isn't waking up from USB even when I've configured it
correctly.  I can still send up the patches, but they won't actually
produce something that will work upstream.  :(

I'll keep it my back burner to investigate, though if someone else
(like maybe someone from Rockchip) wanted to, they could to it too...

...until we figure out what's going on we should probably consider
these patches abandoned.

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

Re: [PATCH 2/2] dma: add Qualcomm Technologies HIDMA channel driver

[Timur Tabi]

On 10/30/2015 04:42 PM, Sinan Kaya wrote:


if (WARN_ON(!pdev->dev.dma_mask))
return -ENXIO;

The dma mask has to always be set by the platform code before probe()
is called. If it is not set, you are not allowed to perform DMA.


I tested this on an ACPI platform BTW when I was working on the initial
implementation.


PowerPC sets the mask to 32 bits by default:

http://lxr.free-electrons.com/ident?i=arch_setup_pdev_archdata

Should we do something similar in ARM64?  Today, we have to manually set 
the DMA mask in all drivers.


--
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 2/2] dma: add Qualcomm Technologies HIDMA channel driver

[Arnd Bergmann]

On Friday 30 October 2015 17:42:26 Sinan Kaya wrote:
> On 10/30/2015 6:24 AM, Arnd Bergmann wrote:
> > On Thursday 29 October 2015 23:08:13 Sinan Kaya wrote:
> >> Signed-off-by: Sinan Kaya 
> >> ---
> >>   .../devicetree/bindings/dma/qcom_hidma.txt |   18 +
> >>   drivers/dma/Kconfig|   11 +
> >>   drivers/dma/Makefile   |4 +
> >>   drivers/dma/qcom_hidma.c   | 1717 
> >> 
> >>   drivers/dma/qcom_hidma.h   |   44 +
> >>   drivers/dma/qcom_hidma_ll.c| 1132 +
> >>   6 files changed, 2926 insertions(+)
> >>   create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
> >>   create mode 100644 drivers/dma/qcom_hidma.c
> >>   create mode 100644 drivers/dma/qcom_hidma.h
> >>   create mode 100644 drivers/dma/qcom_hidma_ll.c
> >>
> >> diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma.txt 
> >> b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
> >> new file mode 100644
> >> index 000..9a01635
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
> >> @@ -0,0 +1,18 @@
> >> +Qualcomm Technologies HIDMA Channel driver
> >> +
> >> +Required properties:
> >> +- compatible: must contain "qcom,hidma"
> >
> > Be more specific here. Also, should this be 'hisilicon,hidma-1.0' rather
> > than 'qcom'? I'm guessing from the name that this is a device you licensed
> > from them.
> >
> No, this is a QCOM part. I used the driver from hisilicon as a starting 
> point instead of starting from scratch. That's why, I kept the original 
> copy rights.

I meant the 'hidma' name. ;-)

> >> +- reg: Addresses for the transfer and event channel
> >> +- interrupts: Should contain the event interrupt
> >> +- desc-count: Number of asynchronous requests this channel can handle
> >> +- event-channel: The HW event channel completions will be delivered.
> >> +Example:
> >> +
> >> +  hidma_24: hidma@0x5c05 {
> >
> > Name should be 'dma-controller' in DT, not 'hidma'.
> will test and change.

no need to test, Linux ignores the node name.

> >
> > MODULE_NAME and HIDMA_DEFAULT_DESCRIPTOR_COUNT can be dropped
> 
> I'll remove the module_name. The default descriptor is used if 
> device-tree or acpi table does not have the descriptor count.

I missed that part. If the descriptor count is a hardware feature,
just make that property mandatory. OTOH, if this is an optimization
setting, better drop that property entirely.

> >> +#define HIDMA_RUNTIME_GET(dmadev) \
> >> +do {  \
> >> +  atomic_inc(&(dmadev)->pm_counter);  \
> >> +  TRC_PM((dmadev)->ddev.dev,  \
> >> +  "%s:%d pm_runtime_get %d\n", __func__, __LINE__,\
> >> +  atomic_read(&(dmadev)->pm_counter));\
> >> +  pm_runtime_get_sync((dmadev)->ddev.dev);\
> >> +} while (0)
> >> +
> >> +#define HIDMA_RUNTIME_SET(dmadev) \
> >> +do {  \
> >> +  atomic_dec(&(dmadev)->pm_counter);  \
> >> +  TRC_PM((dmadev)->ddev.dev,  \
> >> +  "%s:%d pm_runtime_put_autosuspend:%d\n",\
> >> +  __func__, __LINE__, \
> >> +  atomic_read(&(dmadev)->pm_counter));\
> >> +  pm_runtime_mark_last_busy((dmadev)->ddev.dev);  \
> >> +  pm_runtime_put_autosuspend((dmadev)->ddev.dev); \
> >> +} while (0)
> >
> > Inline functions.
> 
> ok, I was hoping to keep the file and line numbers as the PM stuff gets 
> called from multiple locations. should I call the inline functions with 
> __func__ and __LINE__ from another macro  like
> 
> #define HIDMA_RUNTIME_GET(dmadev)
>   func(dmadev, __func__, __LINE__)
> 
> etc.

I would just drop the debugging macros entirely here.

> >
> >> +struct hidma_dev {
> >> +  u8  evridx;
> >> +  u32 nr_descriptors;
> >> +
> >> +  void*lldev;
> >> +  void__iomem *dev_trca;
> >> +  void__iomem *dev_evca;
> >> +  int (*self_test)(struct hidma_dev *device);
> >> +  struct dentry   *debugfs;
> >> +  struct dentry   *stats;
> >> +
> >> +  /* used to protect the pending channel list*/
> >> +  spinlock_t  lock;
> >> +  dma_addr_t  dev_trca_phys;
> >> +  struct dma_device   ddev;
> >> +  struct tasklet_struct   tasklet;
> >
> > workqueue maybe?
> 
> is there an advantage of workqueue over tasklet? I'm open to suggestions.

tasklets are not normally used in new code. They are only marginally
faster than workqueues, but are executed in 

[PATCH v6 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC

[Andrew F. Davis]

This patch adds support for TPS65912 PMIC MFD core. It provides
communication through the I2C and SPI interfaces. It contains
the following components:

 - Regulators
 - GPIO controller

Signed-off-by: Andrew F. Davis 
Acked-by: Lee Jones 
---
 drivers/mfd/Kconfig  |  26 
 drivers/mfd/Makefile |   3 +
 drivers/mfd/tps65912-core.c  | 122 +++
 drivers/mfd/tps65912-i2c.c   |  81 ++
 drivers/mfd/tps65912-spi.c   |  80 ++
 include/linux/mfd/tps65912.h | 345 +++
 6 files changed, 657 insertions(+)
 create mode 100644 drivers/mfd/tps65912-core.c
 create mode 100644 drivers/mfd/tps65912-i2c.c
 create mode 100644 drivers/mfd/tps65912-spi.c
 create mode 100644 include/linux/mfd/tps65912.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 9a8df8e..1398340 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1167,6 +1167,32 @@ config MFD_TPS65910
  if you say yes here you get support for the TPS65910 series of
  Power Management chips.
 
+config MFD_TPS65912
+   tristate
+   select MFD_CORE
+   select REGMAP
+   select REGMAP_IRQ
+
+config MFD_TPS65912_I2C
+   tristate "TI TPS65912 Power Management chip with I2C"
+   select MFD_TPS65912
+   select REGMAP_I2C
+   depends on I2C
+   depends on OF || COMPILE_TEST
+   help
+ If you say yes here you get support for the TPS65912 series of
+ PM chips with I2C interface.
+
+config MFD_TPS65912_SPI
+   tristate "TI TPS65912 Power Management chip with SPI"
+   select MFD_TPS65912
+   select REGMAP_SPI
+   depends on SPI_MASTER
+   depends on OF || COMPILE_TEST
+   help
+ If you say yes here you get support for the TPS65912 series of
+ PM chips with SPI interface.
+
 config MFD_TPS80031
bool "TI TPS80031/TPS80032 Power Management chips"
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 004aa76..49c3530 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -69,6 +69,9 @@ obj-$(CONFIG_TPS6507X)+= tps6507x.o
 obj-$(CONFIG_MFD_TPS65217) += tps65217.o
 obj-$(CONFIG_MFD_TPS65218) += tps65218.o
 obj-$(CONFIG_MFD_TPS65910) += tps65910.o
+obj-$(CONFIG_MFD_TPS65912) += tps65912-core.o
+obj-$(CONFIG_MFD_TPS65912_I2C) += tps65912-i2c.o
+obj-$(CONFIG_MFD_TPS65912_SPI)  += tps65912-spi.o
 obj-$(CONFIG_MFD_TPS80031) += tps80031.o
 obj-$(CONFIG_MENELAUS) += menelaus.o
 
diff --git a/drivers/mfd/tps65912-core.c b/drivers/mfd/tps65912-core.c
new file mode 100644
index 000..93a382e
--- /dev/null
+++ b/drivers/mfd/tps65912-core.c
@@ -0,0 +1,122 @@
+/*
+ * Core functions for TI TPS65912x PMIC
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis 
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65218 driver and the previous TPS65912 driver by
+ * Margarita Olaya Cabrera 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static const struct mfd_cell tps65912_cells[] = {
+   {
+   .name = "tps65912-regulator",
+   .of_compatible = "ti,tps65912-regulator",
+   },
+   {
+   .name = "tps65912-gpio",
+   .of_compatible = "ti,tps65912-gpio",
+   },
+};
+
+static const struct regmap_irq tps65912_irqs[] = {
+   /* INT_STS IRQs */
+   REGMAP_IRQ_REG(TPS65912_IRQ_PWRHOLD_F, 0, TPS65912_INT_STS_PWRHOLD_F),
+   REGMAP_IRQ_REG(TPS65912_IRQ_VMON, 0, TPS65912_INT_STS_VMON),
+   REGMAP_IRQ_REG(TPS65912_IRQ_PWRON, 0, TPS65912_INT_STS_PWRON),
+   REGMAP_IRQ_REG(TPS65912_IRQ_PWRON_LP, 0, TPS65912_INT_STS_PWRON_LP),
+   REGMAP_IRQ_REG(TPS65912_IRQ_PWRHOLD_R, 0, TPS65912_INT_STS_PWRHOLD_R),
+   REGMAP_IRQ_REG(TPS65912_IRQ_HOTDIE, 0, TPS65912_INT_STS_HOTDIE),
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO1_R, 0, TPS65912_INT_STS_GPIO1_R),
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO1_F, 0, TPS65912_INT_STS_GPIO1_F),
+   /* INT_STS2 IRQs */
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO2_R, 1, TPS65912_INT_STS2_GPIO2_R),
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO2_F, 1, TPS65912_INT_STS2_GPIO2_F),
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO3_R, 1, TPS65912_INT_STS2_GPIO3_R),
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO3_F, 1, TPS65912_INT_STS2_GPIO3_F),
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO4_R, 1, TPS65912_INT_STS2_GPIO4_R),
+   

[PATCH v6 5/5] gpio: tps65912: Add GPIO driver for the TPS65912 PMIC

[Andrew F. Davis]

This patch adds support for the TPS65912 PMIC GPIOs.

TPS65912 has five configurable GPIOs that can be used for several
purposes.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Linus Walleij 
---
 drivers/gpio/Kconfig |   6 ++
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-tps65912.c | 139 +++
 3 files changed, 146 insertions(+)
 create mode 100644 drivers/gpio/gpio-tps65912.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index fb28483..82218fa 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -838,6 +838,12 @@ config GPIO_TPS65910
  Select this option to enable GPIO driver for the TPS65910
  chip family.
 
+config GPIO_TPS65912
+   tristate "TI TPS65912 GPIO"
+   depends on MFD_TPS65912
+   help
+ This driver supports TPS65912 gpio chip
+
 config GPIO_TWL4030
tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
depends on TWL4030_CORE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 605bf89..f79a7c4 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -96,6 +96,7 @@ obj-$(CONFIG_GPIO_TIMBERDALE) += gpio-timberdale.o
 obj-$(CONFIG_GPIO_PALMAS)  += gpio-palmas.o
 obj-$(CONFIG_GPIO_TPS6586X)+= gpio-tps6586x.o
 obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
+obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
 obj-$(CONFIG_GPIO_TS5500)  += gpio-ts5500.o
 obj-$(CONFIG_GPIO_TWL4030) += gpio-twl4030.o
 obj-$(CONFIG_GPIO_TWL6040) += gpio-twl6040.o
diff --git a/drivers/gpio/gpio-tps65912.c b/drivers/gpio/gpio-tps65912.c
new file mode 100644
index 000..8d2d442
--- /dev/null
+++ b/drivers/gpio/gpio-tps65912.c
@@ -0,0 +1,139 @@
+/*
+ * TI TPS65912x GPIO Driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis 
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the Arizona GPIO driver and the previous TPS65912 driver by
+ * Margarita Olaya Cabrera 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+struct tps65912_gpio {
+   struct gpio_chip gpio_chip;
+   struct tps65912 *tps;
+};
+
+static inline struct tps65912_gpio *to_tps65912_gpio(struct gpio_chip *chip)
+{
+   return container_of(chip, struct tps65912_gpio, gpio_chip);
+}
+
+static int tps65912_gpio_get(struct gpio_chip *gc, unsigned offset)
+{
+   struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+   int ret, val;
+
+   ret = regmap_read(gpio->tps->regmap, TPS65912_GPIO1 + offset, );
+   if (ret < 0)
+   return ret;
+
+   return val & GPIO_STS_MASK;
+}
+
+static void tps65912_gpio_set(struct gpio_chip *gc, unsigned offset,
+ int value)
+{
+   struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+
+   regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset,
+  GPIO_SET_MASK, value ? GPIO_SET_MASK : 0);
+}
+
+static int tps65912_gpio_output(struct gpio_chip *gc, unsigned offset,
+   int value)
+{
+   struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+
+   /* Set the initial value */
+   tps65912_gpio_set(gc, offset, value);
+
+   return regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset,
+ GPIO_CFG_MASK, GPIO_CFG_MASK);
+}
+
+static int tps65912_gpio_input(struct gpio_chip *gc, unsigned offset)
+{
+   struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+
+   return regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset,
+ GPIO_CFG_MASK, 0);
+}
+
+static struct gpio_chip template_chip = {
+   .label  = "tps65912-gpio",
+   .owner  = THIS_MODULE,
+   .direction_input= tps65912_gpio_input,
+   .direction_output   = tps65912_gpio_output,
+   .get= tps65912_gpio_get,
+   .set= tps65912_gpio_set,
+   .can_sleep  = true,
+   .ngpio  = 5,
+   .base   = -1,
+};
+
+static int tps65912_gpio_probe(struct platform_device *pdev)
+{
+   struct tps65912_gpio *gpio;
+   int ret;
+
+   gpio = devm_kzalloc(>dev, sizeof(*gpio), GFP_KERNEL);
+   if (!gpio)
+   return -ENOMEM;
+
+   gpio->tps = dev_get_drvdata(pdev->dev.parent);
+   gpio->gpio_chip = template_chip;
+   ret = gpiochip_add(>gpio_chip);

Re: [PATCH v2 1/3] devicetree: mfd: Add binding for the TI LM3533

[Bjorn Andersson]

On Fri 30 Oct 13:18 PDT 2015, Rob Herring wrote:

> On Fri, Oct 30, 2015 at 2:41 PM, Bjorn Andersson
>  wrote:
> > On Fri 30 Oct 11:42 PDT 2015, Lee Jones wrote:
> >
> > Rob, please see the discussion regarding ti,boost-freq-khz below. Should
> > we both specify unit at the same time as we use standard units? (This is
> > not the first time I have to change this back and forth)
> >
> >> On Tue, 27 Oct 2015, Bjorn Andersson wrote:
> >>
[..]
> > The ti,boost-low-freq from the bq25890 binding is the only other
> > property I can find that describes the same thing. So I'm not sure I
> > follow you here.
> >
> >> Perhaps we need to create a set of generic bindings.
> >>
> >> Also, we usually measure DT bindings in HZ, not kHz.
> 
> Surprisingly, there are not enough examples to draw much conclusion.
> 
> > I thought we had defined frequencies to be in HZ and HZ only, but then
> > Rob's comment that I need to actually specify the unit doesn't make any
> > sense.
> 
> I don't think we decided, but let's decide now. Go with Hz.
> 

+1

> Really, I first prefer the property name has units and second having
> standardized units. But if there is a common property without units, I
> prefer that even more.
> 

You can find this property in a variety of hardware, but I don't think
it would make much sense to define this single property in a common
place today.

This seems to be the first case where we specify the unit on one of
these properties though.

> > Do we want these properties in a standard unit or do we want them
> > specifying the unit? Having both seems excessive.
> 
> You mean "freq" would imply the units? No, we want the actual units in
> the property.
> 

You're right, frequency can be measured in other units than Hz, I can't
think of one that would be applicable here though.

Either way, I'll slap on a unit to the property name - Hz that is...

Thanks for your input.

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

[PATCH v2 6/6] gpio: tps65086: Add GPIO driver for the TPS65086 PMIC

[Andrew F. Davis]

Add support for the TPS65086 PMIC GPOs.

TPS65086 has four configurable GPOs that can be used for several
purposes.

Signed-off-by: Andrew F. Davis 
---
 drivers/gpio/Kconfig |   6 +++
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-tps65086.c | 115 +++
 3 files changed, 122 insertions(+)
 create mode 100644 drivers/gpio/gpio-tps65086.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b4fc9e4..ccb7e0d 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -824,6 +824,12 @@ config GPIO_TIMBERDALE
---help---
Add support for the GPIO IP in the timberdale FPGA.
 
+config GPIO_TPS65086
+   tristate "TI TPS65086 GPO"
+   depends on MFD_TPS65086
+   help
+ This driver supports the GPO on TI TPS65086x PMICs.
+
 config GPIO_TPS6586X
bool "TPS6586X GPIO"
depends on MFD_TPS6586X
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f79a7c4..2611c7e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -94,6 +94,7 @@ obj-$(CONFIG_GPIO_TC3589X)+= gpio-tc3589x.o
 obj-$(CONFIG_ARCH_TEGRA)   += gpio-tegra.o
 obj-$(CONFIG_GPIO_TIMBERDALE)  += gpio-timberdale.o
 obj-$(CONFIG_GPIO_PALMAS)  += gpio-palmas.o
+obj-$(CONFIG_GPIO_TPS65086)+= gpio-tps65086.o
 obj-$(CONFIG_GPIO_TPS6586X)+= gpio-tps6586x.o
 obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
 obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
diff --git a/drivers/gpio/gpio-tps65086.c b/drivers/gpio/gpio-tps65086.c
new file mode 100644
index 000..ef7a418
--- /dev/null
+++ b/drivers/gpio/gpio-tps65086.c
@@ -0,0 +1,115 @@
+/*
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis 
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65912 driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct tps65086_gpio {
+   struct gpio_chip gpio_chip;
+   struct tps65086 *tps;
+};
+
+static inline struct tps65086_gpio *to_tps65086_gpio(struct gpio_chip *chip)
+{
+   return container_of(chip, struct tps65086_gpio, gpio_chip);
+}
+
+static int tps65086_gpio_get(struct gpio_chip *gc, unsigned offset)
+{
+   struct tps65086_gpio *gpio = to_tps65086_gpio(gc);
+   int ret, val;
+
+   ret = regmap_read(gpio->tps->regmap, TPS65086_GPOCTRL, );
+   if (ret < 0)
+   return ret;
+
+   return val & BIT(4 + offset);
+}
+
+static void tps65086_gpio_set(struct gpio_chip *gc, unsigned offset,
+ int value)
+{
+   struct tps65086_gpio *gpio = to_tps65086_gpio(gc);
+
+   regmap_update_bits(gpio->tps->regmap, TPS65086_GPOCTRL,
+  BIT(4 + offset), value ? BIT(4 + offset) : 0);
+}
+
+static struct gpio_chip template_chip = {
+   .label  = "tps65086-gpio",
+   .owner  = THIS_MODULE,
+   .get= tps65086_gpio_get,
+   .set= tps65086_gpio_set,
+   .can_sleep  = true,
+   .ngpio  = 4,
+   .base   = -1,
+};
+
+static int tps65086_gpio_probe(struct platform_device *pdev)
+{
+   struct tps65086_gpio *gpio;
+   int ret;
+
+   gpio = devm_kzalloc(>dev, sizeof(*gpio), GFP_KERNEL);
+   if (!gpio)
+   return -ENOMEM;
+
+   gpio->tps = dev_get_drvdata(pdev->dev.parent);
+   gpio->gpio_chip = template_chip;
+   ret = gpiochip_add(>gpio_chip);
+   if (ret < 0) {
+   dev_err(>dev, "Could not register gpiochip, %d\n", ret);
+   return ret;
+   }
+
+   platform_set_drvdata(pdev, gpio);
+
+   return 0;
+}
+
+static int tps65086_gpio_remove(struct platform_device *pdev)
+{
+   struct tps65086_gpio *gpio = platform_get_drvdata(pdev);
+
+   gpiochip_remove(>gpio_chip);
+
+   return 0;
+}
+
+static const struct platform_device_id tps65086_gpio_id_table[] = {
+   { "tps65912-regulator", },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(platform, tps65086_gpio_id_table);
+
+static struct platform_driver tps65086_gpio_driver = {
+   .driver = {
+   .name = "tps65086-gpio",
+   },
+   .probe = tps65086_gpio_probe,
+   .remove = tps65086_gpio_remove,
+   .id_table = tps65086_gpio_id_table,
+};
+module_platform_driver(tps65086_gpio_driver);
+
+MODULE_AUTHOR("Andrew F. Davis ");
+MODULE_DESCRIPTION("TPS65086 GPIO driver");

[PATCH v2 0/6] Add support for the TI TPS65086 PMIC

[Andrew F. Davis]

This series adds support for the TPS65086 PMIC. It is a MFD with an I2C
interface, several regulators and load switches, and a GPO controller.

Based on v4.3-rc1 and needs b4fe8ba ("regmap: Add generic macro to define 
regmap_irq")
from Lee Jones' tree to build.

v1 can be found here: [1]

Changes from v1:
 - Split up DT Docs into separate patches
 - Use mfd core to instantiate sub-devices
 - Several small fixes as discussed in v1 thread

[1] http://www.spinics.net/lists/devicetree/msg98403.html

Andrew F. Davis (6):
  Documentation: tps65086: Add DT bindings for the TPS65086 PMIC
  Documentation: tps65086: Add DT bindings for the TPS65086 regulators
  Documentation: tps65086: Add DT bindings for the TPS65086 GPO
controller
  mfd: tps65086: Add driver for the TPS65086 PMIC
  regulator: tps65086: Add regulator driver for the TPS65086 PMIC
  gpio: tps65086: Add GPIO driver for the TPS65086 PMIC

 .../devicetree/bindings/gpio/gpio-tps65086.txt |  16 ++
 Documentation/devicetree/bindings/mfd/tps65086.txt |  46 
 .../bindings/regulator/tps65086-regulator.txt  |  35 +++
 drivers/gpio/Kconfig   |   6 +
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/gpio-tps65086.c   | 115 +
 drivers/mfd/Kconfig|  14 ++
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/tps65086.c | 157 +
 drivers/regulator/Kconfig  |   7 +
 drivers/regulator/Makefile |   1 +
 drivers/regulator/tps65086-regulator.c | 260 +
 include/linux/mfd/tps65086.h   | 120 ++
 13 files changed, 779 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tps65086.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/tps65086.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/tps65086-regulator.txt
 create mode 100644 drivers/gpio/gpio-tps65086.c
 create mode 100644 drivers/mfd/tps65086.c
 create mode 100644 drivers/regulator/tps65086-regulator.c
 create mode 100644 include/linux/mfd/tps65086.h

-- 
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 5/6] regulator: tps65086: Add regulator driver for the TPS65086 PMIC

[Andrew F. Davis]

Add support for TPS65086 PMIC regulators.

The regulators set consists of 3 Step-down Controllers, 3 Step-down
Converters, 3 LDOs, 3 Load Switches, and a Sink and Source LDO. The
output voltages are configurable and are meant to supply power to a
SoC and/or other components.

Signed-off-by: Andrew F. Davis 
---
 drivers/regulator/Kconfig  |   7 +
 drivers/regulator/Makefile |   1 +
 drivers/regulator/tps65086-regulator.c | 260 +
 3 files changed, 268 insertions(+)
 create mode 100644 drivers/regulator/tps65086-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 64bccff..24237cf 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -680,6 +680,13 @@ config REGULATOR_TPS6507X
  three step-down converters and two general-purpose LDO voltage 
regulators.
  It supports TI's software based Class-2 SmartReflex implementation.
 
+config REGULATOR_TPS65086
+   tristate "TI TPS65086 Power regulators"
+   depends on MFD_TPS65086
+   help
+ This driver provides support for the voltage regulators on
+ TI TPS65086 PMICs.
+
 config REGULATOR_TPS65090
tristate "TI TPS65090 Power regulator"
depends on MFD_TPS65090
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 0f81749..945d8ec 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_REGULATOR_TPS6105X) += tps6105x-regulator.o
 obj-$(CONFIG_REGULATOR_TPS62360) += tps62360-regulator.o
 obj-$(CONFIG_REGULATOR_TPS65023) += tps65023-regulator.o
 obj-$(CONFIG_REGULATOR_TPS6507X) += tps6507x-regulator.o
+obj-$(CONFIG_REGULATOR_TPS65086) += tps65086-regulator.o
 obj-$(CONFIG_REGULATOR_TPS65090) += tps65090-regulator.o
 obj-$(CONFIG_REGULATOR_TPS65217) += tps65217-regulator.o
 obj-$(CONFIG_REGULATOR_TPS65218) += tps65218-regulator.o
diff --git a/drivers/regulator/tps65086-regulator.c 
b/drivers/regulator/tps65086-regulator.c
new file mode 100644
index 000..f6d34c1
--- /dev/null
+++ b/drivers/regulator/tps65086-regulator.c
@@ -0,0 +1,260 @@
+/*
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis 
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65912 driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+enum tps65086_regulators { BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6, LDOA1,
+   LDOA2, LDOA3, SWA1, SWB1, SWB2, VTT };
+
+#define TPS65086_REGULATOR(_name, _id, _nv, _vr, _vm, _er, _em, _lr, _dr, _dm)\
+   [_id] = {   \
+   .desc = {   \
+   .name   = _name,\
+   .id = _id,  \
+   .ops= _ops, \
+   .n_voltages = _nv,  \
+   .type   = REGULATOR_VOLTAGE,\
+   .owner  = THIS_MODULE,  \
+   .vsel_reg   = _vr,  \
+   .vsel_mask  = _vm,  \
+   .enable_reg = _er,  \
+   .enable_mask= _em,  \
+   .volt_table = NULL, \
+   .linear_ranges  = _lr,  \
+   .n_linear_ranges= ARRAY_SIZE(_lr),  \
+   },  \
+   .decay_reg = _dr,   \
+   .decay_mask = _dm,  \
+   }
+
+#define TPS65086_SWITCH(_name, _id, _er, _em)  \
+   [_id] = {   \
+   .desc = {   \
+   .name   = _name,\
+   .id = _id,  \
+   .ops= _ops,  \
+   .type   = REGULATOR_VOLTAGE,\
+   .owner  = THIS_MODULE,  \

[PATCH v2 3/6] Documentation: tps65086: Add DT bindings for the TPS65086 GPO controller

[Andrew F. Davis]

The TPS65086 PMIC contains several regulators and a GPO controller.
Add bindings for the TPS65086 GPO controller.

Signed-off-by: Andrew F. Davis 
---
 Documentation/devicetree/bindings/gpio/gpio-tps65086.txt | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tps65086.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-tps65086.txt 
b/Documentation/devicetree/bindings/gpio/gpio-tps65086.txt
new file mode 100644
index 000..ba05107
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-tps65086.txt
@@ -0,0 +1,16 @@
+* TPS65086 GPO Controller bindings
+
+Required properties:
+ - compatible  : Should be "ti,tps65086-gpio".
+ - gpio-controller : Marks the device node as a GPIO Controller.
+ - #gpio-cells : Should be two. The first cell is the pin number
+   and the second cell is used to specify flags.
+   See ../gpio/gpio.txt for possible values.
+
+Example:
+
+   gpio4: gpio {
+   compatible = "ti,tps65086-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
-- 
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 4/6] mfd: tps65086: Add driver for the TPS65086 PMIC

[Andrew F. Davis]

Add support for the TPS65912 device. It provides communication
through I2C and contains the following components:

 - Regulators
 - Load switches
 - GPO controller

Signed-off-by: Andrew F. Davis 
---
 drivers/mfd/Kconfig  |  14 
 drivers/mfd/Makefile |   1 +
 drivers/mfd/tps65086.c   | 157 +++
 include/linux/mfd/tps65086.h | 120 +
 4 files changed, 292 insertions(+)
 create mode 100644 drivers/mfd/tps65086.c
 create mode 100644 include/linux/mfd/tps65086.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 99d6367..b46ee3b9 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1093,6 +1093,20 @@ config TPS6507X
  This driver can also be built as a module.  If so, the module
  will be called tps6507x.
 
+config MFD_TPS65086
+   tristate "TI TPS65086 Power Management Integrated Chips (PMICs)"
+   select REGMAP
+   select REGMAP_IRQ
+   select REGMAP_I2C
+   depends on I2C
+   depends on OF || COMPILE_TEST
+   help
+ If you say yes here you get support for the TPS65086 series of
+ Power Management chips.
+ This driver provides common support for accessing the device,
+ additional drivers must be enabled in order to use the
+ functionality of the device.
+
 config TPS65911_COMPARATOR
tristate
 
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a59e3fc..7adb902 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_MFD_WM8994)  += wm8994-core.o wm8994-irq.o 
wm8994-regmap.o
 obj-$(CONFIG_TPS6105X) += tps6105x.o
 obj-$(CONFIG_TPS65010) += tps65010.o
 obj-$(CONFIG_TPS6507X) += tps6507x.o
+obj-$(CONFIG_MFD_TPS65086) += tps65086.o
 obj-$(CONFIG_MFD_TPS65217) += tps65217.o
 obj-$(CONFIG_MFD_TPS65218) += tps65218.o
 obj-$(CONFIG_MFD_TPS65910) += tps65910.o
diff --git a/drivers/mfd/tps65086.c b/drivers/mfd/tps65086.c
new file mode 100644
index 000..d6f8bb8
--- /dev/null
+++ b/drivers/mfd/tps65086.c
@@ -0,0 +1,157 @@
+/*
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis 
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65912 driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static const struct mfd_cell tps65086_cells[] = {
+   {
+   .name = "tps65086-regulator",
+   .of_compatible = "ti,tps65086-regulator",
+   },
+   {
+   .name = "tps65912-gpio",
+   .of_compatible = "ti,tps65086-gpio",
+   },
+};
+
+static const struct regmap_range tps65086_yes_ranges[] = {
+   regmap_reg_range(TPS65086_IRQ, TPS65086_IRQ),
+   regmap_reg_range(TPS65086_PMICSTAT, TPS65086_SHUTDNSRC),
+   regmap_reg_range(TPS65086_GPOCTRL, TPS65086_GPOCTRL),
+   regmap_reg_range(TPS65086_PG_STATUS1, TPS65086_OC_STATUS),
+};
+
+static const struct regmap_access_table tps65086_volatile_table = {
+   .yes_ranges = tps65086_yes_ranges,
+   .n_yes_ranges = ARRAY_SIZE(tps65086_yes_ranges),
+};
+
+static const struct regmap_config tps65086_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .cache_type = REGCACHE_RBTREE,
+   .volatile_table = _volatile_table,
+};
+
+static const struct regmap_irq tps65086_irqs[] = {
+   REGMAP_IRQ_REG(TPS65086_IRQ_DIETEMP, 0, TPS65086_IRQ_DIETEMP_MASK),
+   REGMAP_IRQ_REG(TPS65086_IRQ_SHUTDN, 0, TPS65086_IRQ_SHUTDN_MASK),
+   REGMAP_IRQ_REG(TPS65086_IRQ_FAULT, 0, TPS65086_IRQ_FAULT_MASK),
+};
+
+static struct regmap_irq_chip tps65086_irq_chip = {
+   .name = "tps65086",
+   .status_base = TPS65086_IRQ,
+   .mask_base = TPS65086_IRQ_MASK,
+   .ack_base = TPS65086_IRQ,
+   .init_ack_masked = true,
+   .num_regs = 1,
+   .irqs = tps65086_irqs,
+   .num_irqs = ARRAY_SIZE(tps65086_irqs),
+};
+
+static const struct of_device_id tps65086_of_match_table[] = {
+   { .compatible = "ti,tps65086", },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, tps65086_of_match_table);
+
+static int tps65086_probe(struct i2c_client *client,
+ const struct i2c_device_id *ids)
+{
+   struct tps65086 *tps;
+   unsigned int version;
+   int ret;
+
+   tps = devm_kzalloc(>dev, sizeof(*tps), GFP_KERNEL);
+   if (!tps)
+   return -ENOMEM;
+
+   i2c_set_clientdata(client, tps);
+   

Re: [PATCH 2/2] sound: soc: Add Cygnus audio driver

[simran rai]

Hi Arnd,


On 10/30/2015 4:28 PM, Arnd Bergmann wrote:

On Saturday 31 October 2015 07:20:17 kbuild test robot wrote:

  > 785  dev_dbg(rtd->cpu_dai->dev, "%s: size 0x%x @ 0x%p\n",
786  __func__, size, buf->area);


Both reports are for the same bug: the "0x%x" should be "0x%zx".

There is another bug in the same line: "0x%p" should be "%pK",
to avoid the duplicate "0x" and to not leak the pointer when
kptr_restrict is set.

Arnd
I will fix both of these in the next patchset, early next week. If there 
are any other comments/suggestions, please let me know. Thanks for the 
feedback.


Simran
--
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] mtd: ofpart: document the lock flag.

[Brian Norris]

From: Michal Suchanek 

The lock flag of ofpart is undocumented. Add to binding doc.

Signed-off-by: Michal Suchanek 
Signed-off-by: Brian Norris 
Cc: Sascha Hauer 
---
It seems my reasoning here [1] was wrong (thanks Sascha!). This is a rewrite of
Michal's binding doc from [2].

Note that this property is still broken for the CONFIG_MTD_PARTITIONED_MASTER=y
case.

[1] http://lists.infradead.org/pipermail/linux-mtd/2015-October/062822.html
[2] http://lists.infradead.org/pipermail/linux-mtd/2015-August/061155.html

 Documentation/devicetree/bindings/mtd/partition.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/partition.txt 
b/Documentation/devicetree/bindings/mtd/partition.txt
index 8e5557da1955..a7d4d35550e3 100644
--- a/Documentation/devicetree/bindings/mtd/partition.txt
+++ b/Documentation/devicetree/bindings/mtd/partition.txt
@@ -23,6 +23,8 @@ Optional properties:
   partition should only be mounted read-only. This is usually used for flash
   partitions containing early-boot firmware images or data which should not be
   clobbered.
+- lock : Do not unlock the partition at initialization time (not supported on
+  all devices)
 
 Examples:
 
-- 
2.6.0.rc2.230.g3dd15c0

--
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 04/19] clk: sunxi: Add TCON channel1 clock

[Stephen Boyd]

On 10/30, Maxime Ripard wrote:
> The TCON is a controller generating the timings to output videos signals,
> acting like both a CRTC and an encoder.
> 
> It has two channels depending on the output, each channel being driven by
> its own clock (and own clock controller).
> 
> Add a driver for the channel 1 clock.
> 
> Signed-off-by: Maxime Ripard 

Similar comments apply to patches 3 and 4. Was the same code
copy/pasted two more times and then changed to have different
values? Looks like we should consolidate all that stuff into
something more generic so that we don't have the same problems 3
times.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dma: add Qualcomm Technologies HIDMA channel driver

[Timur Tabi]

On 10/30/2015 05:28 PM, Arnd Bergmann wrote:

> >Why ENODEV? Could you make this handle restarted system calls?

>
>This is the self test code. It gets called from probe. If there is a
>problem with the device or system configuration, I don't want to enable
>this device. I can certainly return a different error code though.
>What's a good code?

I see. probe() is not restartable, so it cannot be -ERESTARTSYS.

Maybe better use wait_event_timeout and not handle the signals then.
It will eventually time out if something goes wrong.


What about -EPROBE_DEFER?  Isn't that "restartable"?  Granted, it's only 
supposed to be used if the driver is dependent on another driver to 
probe, so I'm not sure it applies here.  If the self-test fails, then it 
is possible that it could succeed later?


--
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 2/2] sound: soc: Add Cygnus audio driver

[Arnd Bergmann]

On Saturday 31 October 2015 07:20:17 kbuild test robot wrote:
>  > 785  dev_dbg(rtd->cpu_dai->dev, "%s: size 0x%x @ 0x%p\n",
>786  __func__, size, buf->area);
> 

Both reports are for the same bug: the "0x%x" should be "0x%zx".

There is another bug in the same line: "0x%p" should be "%pK",
to avoid the duplicate "0x" and to not leak the pointer when
kptr_restrict is set.

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

[PATCH v3 1/3] devicetree: mfd: Add binding for the TI LM3533

[Bjorn Andersson]

Add the binding for the Texas Instruments LM3533 lighting power
solution.

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- Drop vendor prefix of vendor properties
- Specify unit of various properties
- Fix reference paths

Changes since v1:
- Added unit to boost-freq and als-resistance (as the frequency now comes with
  a unit specifier I changed it to be expressed in kHz)

 Documentation/devicetree/bindings/mfd/lm3533.txt | 184 +++
 1 file changed, 184 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/lm3533.txt

diff --git a/Documentation/devicetree/bindings/mfd/lm3533.txt 
b/Documentation/devicetree/bindings/mfd/lm3533.txt
new file mode 100644
index ..963cee153a4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lm3533.txt
@@ -0,0 +1,184 @@
+Texas Instruments LM3533 binding
+
+This binding describes the Texas Instruments LM3533, a lighting power solution
+for smartphone handsets. The common properties are described directly in the
+node, while each individual component are described in an optional subnode.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be:
+   "ti,lm3533"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: i2c address of the LM3533 chip
+
+- als-supply:
+   Usage: optional
+   Value type: 
+   Definition: reference to regulator powering the V_als input; as
+   specified in "../regulator/regulator.txt"
+
+- hwen-gpios:
+   Usage: required
+   Value type: 
+   Definition: reference to gpio pin connected to the HWEN input; as
+   specified in "../gpio/gpio.txt"
+
+- ti,boost-freq-hz:
+   Usage: required
+   Value type: 
+   Definition: switch-frequency of the boost converter, must be either:
+   50 or 100
+
+- ti,boost-ovp-mv:
+   Usage: required
+   Value type: 
+   Definition: over-voltage protection limit, in mV. Must be one of:
+   16000, 24000, 32000 or 4
+
+- #address-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 1
+
+- #size-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 0
+
+= ALS SUBNODE
+The ambient light sensor subnode must be named "als", it carries the light
+sensor related properties.
+
+- ti,als-resistance-ohm:
+   Usage: required (unless ti,pwm-mode is specified)
+   Value type: 
+   Definition: specifies the resistor value (R_als), in Ohm. Valid values
+   ranges from 20 to 1574 Ohm.
+
+- ti,pwm-mode:
+   Usage: optional
+   Value type: 
+   Definition: specifies, if present, that the als should operate in PWM
+   mode - rather than analog mode
+
+= BACKLIGHT NODES
+Backlight subnodes must be named "backlight", they carry the backlight related
+properties.
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: specifies which of the two backlights this node corresponds
+   to
+
+- default-brightness:
+   Usage: optional
+   Value type: <32>
+   Definition: specifies the default brightness for the backlight, in
+   units of brightness [0-255]
+
+- label:
+   Usage: required
+   Value type: 
+   Definition: specifies a name of this backlight
+
+- led-max-microamp:
+   Usage: required
+   Value type: 
+   Definition: specifies the max current for this backlight, in uA, as
+   described in "../leds/common.txt"
+
+- ti,pwm-zones:
+   Usage: optional
+   Value type: 
+   Definition: lists the ALS zones to be PWM controlled for this backlight,
+   the values in the list are in the range [0 - 4]
+
+= LED NODES
+LED subnodes must be named "led", they carry the LED related properties.
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: specifies which of the four LEDs this node corresponds to
+
+- linux,default-trigger:
+   Usage: optional
+   Value type: 
+   Definition: specifies the default trigger for the LED, as described in
+   "../leds/common.txt"
+
+- label:
+   Usage: required
+   Value type: 
+   Definition: specifies a name of this LED, as described in
+   "../leds/common.txt"
+
+- led-max-microamp:
+   Usage: required
+   Value type: 
+   Definition: specifies the max current for this LED, in uA, as described
+   in "../leds/common.txt"
+
+- ti,pwm-zones:
+   Usage: optional
+   Value type: 
+   Definition: lists the ALS zones to be PWM controlled for this LED, the
+   values in the list are in the range [0 - 4]
+
+= EXAMPLE
+
+i2c@1246 {
+   compatible = "qcom,i2c-qup-v1.1.1";
+   ...
+
+   lm3533@36 {
+   compatible = "ti,lm3533";
+   reg = 

Re: [PATCH v2 1/3] gpio: xgene: add support to configure GPIO line as input, output or external IRQ pin

[Marc Zyngier]

On Fri, 30 Oct 2015 12:41:03 +0700
Quan Nguyen  wrote:

> Forgive me for not turn on plain text mode my last email.
> 
> Hi Linus,
> 
> My name is Quan Nguyen, I'm working with Y Vo on this patch.
> 
> Allow me to explain as below:
> 
> In current implementation, gic irq resources were used in both sbgpio
> and gpios-key nodes, and this causes confusion.
> To avoid this, we introduce sbgpio driver as interrupt controller, it
> now provides 6 external irq pins mapped from gpio line 8-13. The
> gpio-keys node now uses sbgpio irq resources instead.
> 
> -- Quan
> 
> 
> On Thu, Oct 29, 2015 at 8:28 PM, Linus Walleij  
> wrote:
> > On Mon, Oct 26, 2015 at 7:49 AM, Y Vo  wrote:
> >
> >> Add support to configure GPIO line as input, output or external IRQ pin.
> >>
> >> Signed-off-by: Y Vo 
> >
> > As I will say again, this description is too terse, add lots of information
> > on how IRQs work on this controller please. I get confused.
> 
> How about:
> +
> Enable X-Gene standby GPIO driver as interrupt controller, it provides
> 6 external irq pins via gpio line 8-13.
> +
> >
> > (...)
> >
> >> +#define XGENE_GPIO8_HWIRQ  0x48
> >> +#define XGENE_GPIO8_IDX8
> > (...)
> >> +#define XGENE_HWIRQ_TO_GPIO(hwirq) ((hwirq) + XGENE_GPIO8_IDX)
> >> +#define XGENE_GPIO_TO_HWIRQ(gpio)  ((gpio) - XGENE_GPIO8_IDX)
> >> +#define GIC_IRQ_TO_GPIO_IRQ(hwirq) ((hwirq) - XGENE_GPIO8_HWIRQ)
> >> +#define GPIO_IRQ_TO_GIC_IRQ(hwirq) ((hwirq) + XGENE_GPIO8_HWIRQ)
> >
> > I'm a bit uneasy about this, maybe I just don't get it.
> >
> > What is this indexing into "GIC IRQ" that is starting to happen
> > here?
> >
> > The GIC (if that is drivers/irqchip/irq-gic.c) has a totally dynamic IRQ
> > translation and the Linux IRQs it is using may change. I am worried
> > that there is some reliance here on Linux IRQ having certain numbers
> > because there is certainly no ABI like that.
> >
> > Is this 0x48 really an index into the *hardware* offset in the GIC?
> >
> > And if it is: why are we not getting this hardware information from the
> > device tree like all other interrupt numbers and offsets?
> >
> > I'm worried about this.
> 
> The SPI40(0x48) through SPI45(0x4D) from GIC are mapped as external
> IRQ0 - IRQ5 in this GPIO block, so it is hardware offset not mapped
> irq number.
> 
> Below is detail:
> 
> + GIC: SPI40 (hwirq=0x48)  <=> SB-GPIO: (hwirq=0) (gpio line 8)
> + GIC: SPI41 (hwirq=0x49)  <=> SB-GPIO: (hwirq=1) (gpio line 9)
> ...
> + GIC: SPI45 (hwirq=0x4D)  <=> SB-GPIO: (hwirq=5) (gpio line 13)
> 
> These defines are to help translating between Gic hardware irq and
> SBGPIO hardware irq number.
> 
> >
> >> -   u32 *irq;
> >> +   void __iomem *regs;
> >> +   struct irq_domain *gic_domain;
> >> +   struct irq_domain *irq_domain;
> >
> > And there is some secondary gic_domain here, which is confusing
> > since the GIC does have an IRQ domain too.
> >
> > I think I want a clear explanation to how this GPIO controller interacts
> > with the GIC, and I want it to be part of the patch, as comments in the
> > code and in the commit message (which is way too small for a complex
> > patch like this).
> >
> > Otherwise I have no chance to understand what is really going on here.
> 
> SBGPIO currently is not capable to mask/unmask/... irqs, so these will
> rely on the parent (GIC) instead. To do so, we need keep a parent
> domain reference here "struct irq_domain *gic_domain" so we can find
> correspond parent irq in runtime.

All this only means one thing: this should be implemented as a
hierarchical domain, just like any other "random widget stacked on top
of the GIC". Digging into the internals of the GIC driver is not
acceptable anymore, and this patch is just horrible.

There is plenty of examples in the tree for you to look at and rewrite
that code using the abstractions that are already in place.

In the meantime, I am NAKing this patch. Please include the irqchip
maintainers in the next iteration of this series.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
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] dma: add Qualcomm Technologies HIDMA channel driver

[Arnd Bergmann]

On Thursday 29 October 2015 23:08:13 Sinan Kaya wrote:
> This patch adds support for hidma engine. The driver
> consists of two logical blocks. The DMA engine interface
> and the low-level interface. This version of the driver
> does not support virtualization on this release and only
> memcpy interface support is included.

Does that mean you can have slave device support eventually?

If so, please put that into the binding document already.

> Signed-off-by: Sinan Kaya 
> ---
>  .../devicetree/bindings/dma/qcom_hidma.txt |   18 +
>  drivers/dma/Kconfig|   11 +
>  drivers/dma/Makefile   |4 +
>  drivers/dma/qcom_hidma.c   | 1717 
> 
>  drivers/dma/qcom_hidma.h   |   44 +
>  drivers/dma/qcom_hidma_ll.c| 1132 +
>  6 files changed, 2926 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
>  create mode 100644 drivers/dma/qcom_hidma.c
>  create mode 100644 drivers/dma/qcom_hidma.h
>  create mode 100644 drivers/dma/qcom_hidma_ll.c
> 
> diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma.txt 
> b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
> new file mode 100644
> index 000..9a01635
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
> @@ -0,0 +1,18 @@
> +Qualcomm Technologies HIDMA Channel driver
> +
> +Required properties:
> +- compatible: must contain "qcom,hidma"

Be more specific here. Also, should this be 'hisilicon,hidma-1.0' rather
than 'qcom'? I'm guessing from the name that this is a device you licensed
from them.

> +- reg: Addresses for the transfer and event channel
> +- interrupts: Should contain the event interrupt
> +- desc-count: Number of asynchronous requests this channel can handle
> +- event-channel: The HW event channel completions will be delivered.
> +Example:
> +
> + hidma_24: hidma@0x5c05 {

Name should be 'dma-controller' in DT, not 'hidma'.

> + compatible = "qcom,hidma";
> + reg = <0 0x5c05 0x0 0x1000>,
> +   <0 0x5c0b 0x0 0x1000>;
> + interrupts = <0 389 0>;
> + desc-count = <10>;
> + event-channel = /bits/ 8 <4>;
> + };

Remove the /bits/.

> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 76a5a5e..2645185 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -512,6 +512,17 @@ config QCOM_HIDMA_MGMT
> OS would run QCOM_HIDMA driver and the hypervisor would run
> the QCOM_HIDMA_MGMT driver.
>  
> +config QCOM_HIDMA
> + tristate "Qualcomm Technologies HIDMA support"
> + select DMA_ENGINE
> + select DMA_VIRTUAL_CHANNELS
> + help
> +   Enable support for the Qualcomm Technologies HIDMA controller.
> +   The HIDMA controller supports optimized buffer copies
> +   (user to kernel, kernel to kernel, etc.).  It only supports
> +   memcpy/memset interfaces. The core is not intended for general
> +   purpose slave DMA.
> +
>  config XILINX_VDMA
>   tristate "Xilinx AXI VDMA Engine"
>   depends on (ARCH_ZYNQ || MICROBLAZE)
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index 3d25ffd..5665df2 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -53,6 +53,10 @@ obj-$(CONFIG_PL330_DMA) += pl330.o
>  obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
>  obj-$(CONFIG_PXA_DMA) += pxa_dma.o
>  obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
> +obj-$(CONFIG_QCOM_HIDMA) +=  qcom_hdma.o
> +qcom_hdma-objs:= qcom_hidma_ll.o qcom_hidma.o
> +

The driver is linked into a single module, so all the EXPORT_SYMBOL
statements can be dropped.

> +/* Default idle time is 2 seconds. This parameter can
> + * be overridden by changing the following
> + * /sys/bus/platform/devices/QCOM8061:/power/autosuspend_delay_ms
> + * during kernel boot.
> + */
> +#define AUTOSUSPEND_TIMEOUT  2000
> +#define HIDMA_DEFAULT_DESCRIPTOR_COUNT   16
> +#define MODULE_NAME  "hidma"

MODULE_NAME and HIDMA_DEFAULT_DESCRIPTOR_COUNT can be dropped


> +#define HIDMA_RUNTIME_GET(dmadev)\
> +do { \
> + atomic_inc(&(dmadev)->pm_counter);  \
> + TRC_PM((dmadev)->ddev.dev,  \
> + "%s:%d pm_runtime_get %d\n", __func__, __LINE__,\
> + atomic_read(&(dmadev)->pm_counter));\
> + pm_runtime_get_sync((dmadev)->ddev.dev);\
> +} while (0)
> +
> +#define HIDMA_RUNTIME_SET(dmadev)\
> +do { \
> + atomic_dec(&(dmadev)->pm_counter);  \
> + TRC_PM((dmadev)->ddev.dev,  \
> + "%s:%d 

Re: [PATCH v2 1/4] clocksource: rockchip: Make the driver more compatible

[Daniel Lezcano]

On 10/30/2015 04:43 AM, Caesar Wang wrote:

Hi Daniel,

在 2015年10月01日 03:14, Heiko Stübner 写道:

Hi Daniel,

Am Dienstag, 29. September 2015, 06:18:03 schrieb Daniel Lezcano:

On 09/25/2015 04:14 AM, Caesar Wang wrote:

Build the arm64 SoCs (e.g.: RK3368) on Rockchip platform,
There are some failure with build up on timer driver for rockchip.

Says:
/tmp/ccdAnNy5.s:47: Error: missing immediate expression at  operand
1 --
`dsb`
...

The problem was different semantics of dsb on btw arm32 and arm64,
Here we can convert the dsb with insteading of dsb(sy).The "sy" param
is the default which you are allow to omit, so on arm32 dsb()and
dsb(sy)
are the same.

Signed-off-by: Caesar Wang 

Acked-by: Daniel Lezcano 

as you have "just" Acked these patches, I guess you are expecting them
to go
through the same tree as the devicetree changes, right?


I'm wonder if someone will apply this series patchs but the wait.:-)
In fact, I'm no sure that the Acked is really meaning.:-


Yes, by acking the patch I say I am ok with it and I agree it can go 
through another tree.


I suggest before sending patches you read carefully the file 
Documentation/SubmittingPatches.


Especially, 11), 12) and 13).

Thanks.

  -- Daniel


--
  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 v4 2/4] ARM: dts: Add SROMc to Exynos 5410

[Pavel Fedin]

 Hello!

> >>> +   sromc: sromc@1225 {
> >>> +   #address-cells = <1>;
> >>> +   #size-cells = <1>;
> >>> +   ranges;
> >>> +
> >>
> >> We do not need to specify these three properties as they are already
> >> present in parent node "soc".
> >
> >   We do, otherwise dtc complains about defaults of #address-cells = 2 and 
> > #size-cells=1, and
> without empty "ranges" subnode's resources are not correctly translated.
> >
> 
> First of all this patch will not give this error. So this part should
> not be a part of this patch.
> You should be getting above error after applying v4 4/4 "ARM: dts: Add
> Ethernet chip to SMDK5410". So if its failing for ethernet subnode, you
> can move this address-cells and size-cells in dts file just above
> ethernet node as shown below:
> 
> index 311e7be..d69981d 100644
> --- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
> +++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
> @@ -95,6 +95,9 @@
>   };
> 
>{
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges;
>  pinctrl-names = "default";
>  pinctrl-0 = <_ctl>, <_ebi>;
> 

 IMHO this makes little of sense, because in this case you would have to 
duplicate these properties for every supported machine. address-cells, 
size-cells and ranges belong to the controller itself, not to its children.
 Of course i could split up the patch into two, first introduce sromc, second 
introduce mapping. But does it worth that? Both patches would be 3 lines of 
code each.
 Anyway, this specific talk is outdated by now, please check out neighbor 
topic, we are discussing significantly improved binding with Krzystof.

> And another question still remains open, we can't just like that change
> "smsc,lan9115" binding by adding samsung specific properties.

 I am sorry, but you either do not understand us with Krzystof, or not reading 
at all...
 This is not a change in the binding. And these properties do not belong to 
smsc at all. They would be added to *ANY* device which sits on top of SROMc. 
This is more like a bus-specific extra. It's similar to "reg" property having 
different meanings for different buses.

> Probably you can check suggestions from Krzysztof, where he pointed out
> some hint on how other places this is getting used.

 Did you read them? I did, and they do exactly the same thing as i do.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


--
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] Revert "h8300: clocksource"

[Arnd Bergmann]

On Friday 30 October 2015 11:26:08 Daniel Lezcano wrote:
> This reverts commit 618b902d8c098f2fff188119da7b3184c4bc5483.
> 
> The renesas architecture have been dropped and re-introduced two years
> after with a supposed improvement of the code.
> 
> While looking at the timer drivers, I see it did not passed a correct code
> review process. No maintainters were in Cc, not code review and no ack
> from them (Thomas and I).
> 
> Even if those drivers where already in the tree several years ago, that
> does not prevent them, when re-introduced, to be reviewed again and at
> least acked by the maintainer.
> 
> Even if the patches where on lkml@, that does not prevent the different
> sub-system maintainers to be in Cc.

Agreed.

> Instead of that, these drivers passed silently through another tree (arm-soc
> I guess).

No need to speculate when you can look it up easily (it wasn't us):

$ git log --oneline --merges --ancestry-path 
618b902d8c098f2fff188119da7b3184c4bc5483.. | tail -n1
55a7d4b85ca1 Merge tag 'for-4.2' of 
git://git.sourceforge.jp/gitroot/uclinux-h8/linux
$ git show 55a7d4b85ca1
commit 55a7d4b85ca1f723d26b8956e8faeff730d0d240
Merge: aefbef10e3ae 07834743f42b
Author: Linus Torvalds 
Date:   Thu Jun 25 13:07:24 2015 -0700

Merge tag 'for-4.2' of git://git.sourceforge.jp/gitroot/uclinux-h8/linux

Pull Renesas H8/300 architecture re-introduction from Yoshinori Sato.

We dropped arch/h8300 two years ago as stale and old, this is a new and
more modern rewritten arch support for the same architecture.


I reviewed the series before it was merged, but failed to notice that you
were not on Cc, and I did not look at the clocksource drivers in much
detail (if at all).

> There is legacy code to be removed.
>
> Signed-off-by: Daniel Lezcano 

I found that Yoshinori Sato has always addressed all review comments very
quickly by rewriting the code in a proper manner when mistakes were
pointed out in the other drivers. Maybe you can describe now what the
problems are with the three drivers to give him a chance to fix them?

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

[PATCH] dts/ls2080a: update the DTS for QSPI and DSPI support

[Yuan Yao]

Signed-off-by: Yuan Yao 
---
 arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts | 9 -
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi| 4 ++--
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
index 4cb996d..e8801fa 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
@@ -178,7 +178,14 @@
 
  {
status = "okay";
-   qflash0: s25fl008k {
+   flash0: s25fl256s1@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "st,m25p80";
+   spi-max-frequency = <2000>;
+   reg = <0>;
+   };
+   flash2: s25fl256s1@2 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "st,m25p80";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index e81cd48..fd82908 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -250,7 +250,7 @@
 
dspi: dspi@210 {
status = "disabled";
-   compatible = "fsl,vf610-dspi";
+   compatible = "fsl,ls2080a-dspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x210 0x0 0x1>;
@@ -371,7 +371,7 @@
 
qspi: quadspi@20c {
status = "disabled";
-   compatible = "fsl,vf610-qspi";
+   compatible = "fsl,ls2080a-qspi", "fsl,ls1021a-qspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x20c 0x0 0x1>,
-- 
2.1.0.27.g96db324

--
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] Revert "h8300: clocksource"

[Daniel Lezcano]

This reverts commit 618b902d8c098f2fff188119da7b3184c4bc5483.

The renesas architecture have been dropped and re-introduced two years
after with a supposed improvement of the code.

While looking at the timer drivers, I see it did not passed a correct code
review process. No maintainters were in Cc, not code review and no ack
from them (Thomas and I).

Even if those drivers where already in the tree several years ago, that
does not prevent them, when re-introduced, to be reviewed again and at
least acked by the maintainer.

Even if the patches where on lkml@, that does not prevent the different
sub-system maintainers to be in Cc.

Instead of that, these drivers passed silently through another tree (arm-soc
I guess).

Revert these drivers in order to have them re-submitted and reviewed again.

There is legacy code to be removed.

Signed-off-by: Daniel Lezcano 

Conflicts:
drivers/clocksource/Kconfig
drivers/clocksource/Makefile
drivers/clocksource/h8300_timer16.c
drivers/clocksource/h8300_timer8.c
drivers/clocksource/h8300_tpu.c
---
 .../bindings/timer/renesas,16bit-timer.txt |  25 --
 .../bindings/timer/renesas,8bit-timer.txt  |  25 --
 .../devicetree/bindings/timer/renesas,tpu.txt  |  21 --
 drivers/clocksource/Kconfig|   7 -
 drivers/clocksource/Makefile   |   3 -
 drivers/clocksource/h8300_timer16.c| 253 
 drivers/clocksource/h8300_timer8.c | 317 -
 drivers/clocksource/h8300_tpu.c| 206 -
 8 files changed, 857 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/timer/renesas,16bit-timer.txt
 delete mode 100644 
Documentation/devicetree/bindings/timer/renesas,8bit-timer.txt
 delete mode 100644 Documentation/devicetree/bindings/timer/renesas,tpu.txt
 delete mode 100644 drivers/clocksource/h8300_timer16.c
 delete mode 100644 drivers/clocksource/h8300_timer8.c
 delete mode 100644 drivers/clocksource/h8300_tpu.c

diff --git a/Documentation/devicetree/bindings/timer/renesas,16bit-timer.txt 
b/Documentation/devicetree/bindings/timer/renesas,16bit-timer.txt
deleted file mode 100644
index e879244..000
--- a/Documentation/devicetree/bindings/timer/renesas,16bit-timer.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* Renesas H8/300 16bit timer
-
-The 16bit timer is a 16bit timer/counter with configurable clock inputs and
-programmable compare match.
-
-Required Properties:
-
-  - compatible: must contain "renesas,16bit-timer"
-  - reg: base address and length of the registers block for the timer module.
-  - interrupts: interrupt-specifier for the timer, IMIA
-  - clocks: a list of phandle, one for each entry in clock-names.
-  - clock-names: must contain "peripheral_clk" for the functional clock.
-  - renesas,channel: timer channel number.
-
-Example:
-
-   timer16: timer@68 {
-   compatible = "reneas,16bit-timer";
-   reg = <0x68 8>, <0x60 8>;
-   interrupts = <24>;
-   renesas,channel = <0>;
-   clocks = <>;
-   clock-names = "peripheral_clk";
-   };
-
diff --git a/Documentation/devicetree/bindings/timer/renesas,8bit-timer.txt 
b/Documentation/devicetree/bindings/timer/renesas,8bit-timer.txt
deleted file mode 100644
index 9dca375..000
--- a/Documentation/devicetree/bindings/timer/renesas,8bit-timer.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* Renesas H8/300 8bit timer
-
-The 8bit timer is a 8bit timer/counter with configurable clock inputs and
-programmable compare match.
-
-This implement only supported cascade mode.
-
-Required Properties:
-
-  - compatible: must contain "renesas,8bit-timer"
-  - reg: base address and length of the registers block for the timer module.
-  - interrupts: interrupt-specifier for the timer, CMIA and TOVI
-  - clocks: a list of phandle, one for each entry in clock-names.
-  - clock-names: must contain "fck" for the functional clock.
-
-Example:
-
-   timer8_0: timer@80 {
-   compatible = "renesas,8bit-timer";
-   reg = <0x80 10>;
-   interrupts = <36>;
-   clocks = <>;
-   clock-names = "fck";
-   };
-
diff --git a/Documentation/devicetree/bindings/timer/renesas,tpu.txt 
b/Documentation/devicetree/bindings/timer/renesas,tpu.txt
deleted file mode 100644
index f8b2589..000
--- a/Documentation/devicetree/bindings/timer/renesas,tpu.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-* Renesas H8/300 Timer Pluse Unit
-
-The TPU is a 16bit timer/counter with configurable clock inputs and
-programmable compare match.
-This implementation support only cascade mode.
-
-Required Properties:
-
-  - compatible: must contain "renesas,tpu"
-  - reg: base address and length of the registers block in 2 channel.
-  - clocks: a list of phandle, one for each entry in clock-names.
-  - clock-names: must contain 

Re: [PATCH v3] Input: tsc2005 - Add support for tsc2004

[Arnd Bergmann]

On Thursday 29 October 2015 20:01:51 Michael Welling wrote:
> On Fri, Oct 30, 2015 at 09:39:05AM +0900, Mark Brown wrote:
> > On Thu, Oct 29, 2015 at 03:23:31PM -0700, Dmitry Torokhov wrote:
> > 
> > > However, you have regmap in the driver core already. Mark, is it
> > > possible to have regmap API also allow doing raw underlying protocol
> > > transfer so that consumers could issue command requests without needing
> > > to know if they need to do it over i2c or spi or whatever. Or we need a
> > > notion of command registers in regmap...
> > 
> > I don't think it's a good idea to break the encapsulation of the regmap
> > and export the raw I/O functionality directly, there seem to be more bad
> > ways of using that than good.  The driver must at some point know what
> > bus it is dealing with and be able to manage this itself.
> > 
> > I don't know what "command registers" are.
> 
> With this device, if the MSB of the first byte of the transaction is 1 then
> a convertor command is encoded in that byte instead of a register address.
> 
> So here is my plan:
> - Add a function pointer for tsc2005_cmd in the struct tsc2005
> - Put the spi and i2c tsc2005_cmd versions in their respective drivers
> - Pass the cmd functions to the core via tsc200x_probe
> 
> Any objections?

Sounds good. If you end up needing more than one function pointer,
better pass a 'const' pointer to a structure of function pointers that
you can declare statically in the driver.

> Other review suggestions before I code the revision?
> Am I doing too much with a single patch?

Yes.

Please split out the DT binding changes into a separate patch, and
start with one patch that just moves the common parts out of the SPI
driver before you add the new driver.

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

Re: [PATCH 1/2] dma: add Qualcomm Technologies HIDMA management driver

[Arnd Bergmann]

On Thursday 29 October 2015 23:08:12 Sinan Kaya wrote:
> diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt 
> b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> new file mode 100644
> index 000..81674ab
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> @@ -0,0 +1,42 @@
> +Qualcomm Technologies HIDMA Management interface
> +
> +Required properties:
> +- compatible: must contain "qcom,hidma_mgmt"

No underscores in the name please. Also try to be more specific, in case this
device shows up in more than one SoC and they end up not being 100% compatible
we want to be able to tell them apart.

> +- reg: Address range for DMA device
> +- interrupts: Should contain the one interrupt shared by all channels
> +- nr-channels: Number of channels supported by this DMA controller.
> +- max-write: Maximum write burst in bytes. A memcpy requested is
> +  fragmented to multiples of this amount.
> +- max-read: Maximum read burst in bytes. A memcpy request is
> +  fragmented to multiples of this amount.
> +- max-wxactions: Maximum write transactions to perform in a burst
> +- max-rdactions: Maximum read transactions to perform in a burst
> +- max-memset-limit: Maximum memset limit
> +- ch-priority-#n: Priority of the channel
> +- ch-weight-#n: Round robin weight of the channel

For the last two, you can just use a multi-cell property, using one
cell per channel.

> +
> +#define MODULE_NAME  "hidma-mgmt"
> +#define PREFIX   MODULE_NAME ": "

These can be removed, just use dev_info() etc for messages, to include
a unique identifier.

> +#define AUTOSUSPEND_TIMEOUT  2000
> +
> +#define HIDMA_RUNTIME_GET(dmadev)\
> +do { \
> + atomic_inc(&(dmadev)->pm_counter);  \
> + TRC_PM(&(dmadev)->pdev->dev,\
> + "%s:%d pm_runtime_get %d\n", __func__, __LINE__,\
> + atomic_read(&(dmadev)->pm_counter));\
> + pm_runtime_get_sync(&(dmadev)->pdev->dev);  \
> +} while (0)
> +
> +#define HIDMA_RUNTIME_SET(dmadev)\
> +do { \
> + atomic_dec(&(dmadev)->pm_counter);  \
> + TRC_PM(&(dmadev)->pdev->dev,\
> + "%s:%d pm_runtime_put_autosuspend:%d\n",\
> + __func__, __LINE__, \
> + atomic_read(&(dmadev)->pm_counter));\
> + pm_runtime_mark_last_busy(&(dmadev)->pdev->dev);\
> + pm_runtime_put_autosuspend(&(dmadev)->pdev->dev);   \
> +} while (0)

Better use inline functions.

> +struct qcom_hidma_mgmt_dev {
> + u8 max_wr_xactions;
> + u8 max_rd_xactions;
> + u8 max_memset_limit;
> + u16 max_write_request;
> + u16 max_read_request;
> + u16 nr_channels;
> + u32 chreset_timeout;
> + u32 sw_version;
> + u8 *priority;
> + u8 *weight;
> +
> + atomic_tpm_counter;
> + /* Hardware device constants */
> + dma_addr_t dev_physaddr;

No need to store the physaddr, it's write-only here.

> +
> +static unsigned int debug_pm;
> +module_param(debug_pm, uint, 0644);
> +MODULE_PARM_DESC(debug_pm,
> +  "debug runtime power management transitions (default: 0)");
> +
> +#define TRC_PM(...) do { \
> + if (debug_pm)   \
> + dev_info(__VA_ARGS__);  \
> + } while (0)
> +

Once you are done debugging the driver and have a final version, please
remove these.

> +#if IS_ENABLED(CONFIG_DEBUG_FS)
> +
> +#define HIDMA_SHOW(dma, name) \
> + seq_printf(s, #name "=0x%x\n", dma->name)

Only used once, just remove.

> +#define HIDMA_READ_SHOW(dma, name, offset) \
> + do { \
> + u32 val; \
> + val = readl(dma->dev_virtaddr + offset); \
> + seq_printf(s, name "=0x%x\n", val); \
> + } while (0)

Inline function.

> +/**
> + * qcom_hidma_mgmt_info: display HIDMA device info
> + *
> + * Display the info for the current HIDMA device.
> + */
> +static int qcom_hidma_mgmt_info(struct seq_file *s, void *unused)
> +{
> + struct qcom_hidma_mgmt_dev *mgmtdev = s->private;
> + u32 val;
> + int i;
> +
> + HIDMA_RUNTIME_GET(mgmtdev);
> + HIDMA_SHOW(mgmtdev, sw_version);
> +
> + val = readl(mgmtdev->dev_virtaddr + CFG_OFFSET);
> + seq_printf(s, "ENABLE=%d\n", val & 0x1);
> +
> + val = readl(mgmtdev->dev_virtaddr + CHRESET_TIMEOUUT_OFFSET);
> + seq_printf(s, "reset_timeout=%d\n", val & CHRESET_TIMEOUUT_MASK);
> +
> + val = readl(mgmtdev->dev_virtaddr + MHICFG_OFFSET);
> + seq_printf(s, "nr_event_channel=%d\n",
> + (val >> NR_EV_CHANNEL_BIT_POS) & NR_CHANNEL_MASK);
> + seq_printf(s, "nr_tr_channel=%d\n", 

Re: [RFC v4 02/11] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.

[Daniel Vetter]

On Wed, Oct 28, 2015 at 06:13:49PM +0100, Philipp Zabel wrote:
> Hi Daniel,
> 
> Am Montag, den 19.10.2015, 10:56 +0200 schrieb Daniel Vetter:
> > On Fri, Oct 16, 2015 at 10:12:04PM +0200, Philipp Zabel wrote:
> > > From: CK Hu 
> > > 
> > > This patch adds an initial DRM driver for the Mediatek MT8173 DISP
> > > subsystem. It currently supports two fixed output streams from the
> > > OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively.
> > > 
> > > Signed-off-by: CK Hu 
> > > Signed-off-by: YT Shen 
> > > Signed-off-by: Philipp Zabel 
> > 
> > Bunch of drive-by comments below to point out deprecated functions and
> > more common approaches used by other drivers. Don't consider this a full
> > review ;-)
> 
> Much appreciated all the same.
> 
> > Cheers, Daniel
> > 
> > > ---
> > > Changes since v3:
> > >  - Removed crtc enabling/disabling on bind/unbind, the enable/disable
> > >callbacks should suffice.
> > >  - Find sibling components in the device tree via compatible value
> > 
> > btw for DT components stuff there's piles of RFCs floating around to
> > extract this into helper libraries. Would be great we could push one of
> > them forward.
> 
> The non-mediatek-specific part currently is the
> 
>   for_each_child_of_node(bus_node, node) {
>   of_id = of_match_node(dt_ids, node);
>   if (!of_id)
>   continue;
>   if (!of_device_is_available(node))
>   continue;
> 
>   /* ... */
>   }
> 
> loop. This is somewhat similar to a combination of
> for_each_matching_node_and_match and for_each_available_child_of_node.
> for_each_available_matching_child_of_node_and_match would be quite a
> mouthful though.
> 
> [...]
> > > +struct mtk_drm_crtc {
> > > + struct drm_crtc base;
> > > + unsigned intpipe;
> > > + boolenabled;
> > > + struct mtk_crtc_ddp_context *ctx;
> > > +
> > > + struct drm_pending_vblank_event *event;
> > > + boolpending_needs_vblank;
> > > +};
> > > +
> > > +struct mtk_crtc_ddp_context {
> > > + struct device   *dev;
> > > + struct drm_device   *drm_dev;
> > > + struct mtk_drm_crtc *crtc;
> > > + struct mtk_drm_planeplanes[OVL_LAYER_NR];
> > > + int pipe;
> > > +
> > > + void __iomem*config_regs;
> > > + struct device   *mutex_dev;
> > > + u32 ddp_comp_nr;
> > > + struct mtk_ddp_comp *ddp_comp;
> > 
> > All the above probably should just be moved into mtk_drm_crtc. At least I
> > don't understand why you need this indirection.
> 
> Agreed. This was needed for a debugfs patch that I have left out for
> now.
> 
> > > +
> > > + boolpending_config;
> > > + unsigned intpending_width;
> > > + unsigned intpending_height;
> > > +
> > > + boolpending_ovl_config[OVL_LAYER_NR];
> > > + boolpending_ovl_enable[OVL_LAYER_NR];
> > > + unsigned intpending_ovl_addr[OVL_LAYER_NR];
> > > + unsigned intpending_ovl_pitch[OVL_LAYER_NR];
> > > + unsigned intpending_ovl_format[OVL_LAYER_NR];
> > > + int pending_ovl_x[OVL_LAYER_NR];
> > > + int pending_ovl_y[OVL_LAYER_NR];
> > > + unsigned intpending_ovl_size[OVL_LAYER_NR];
> > > + boolpending_ovl_dirty[OVL_LAYER_NR];
> > 
> > This works since you only touch these in the atomic_commit phase, but the
> > recommend way to do this with atomic is to subclass drm_crtc_state:
> >
> > struct mtk_crtc_state {
> > struct drm_crtc_state base;
> > 
> > /* all the pending_ stuff above */
> > };
> > 
> > Then you just pass the mtk to your irq handler to do the update.
> 
> I'll move these into mtk_crtc_state, but I'm not sure what you mean with
> the last sentence. Currently I pass the mtk_crtc_ddp_context to the irq
> handler. I can get to the mtk_crtc_state from that.

That works too.

> > > +static int mtk_drm_bind(struct device *dev)
> > > +{
> > > + return drm_platform_init(_drm_driver, to_platform_device(dev));
> > 
> > This is deprecated, please use drm_dev_alloc/drm_dev_register instead and
> > remove your ->load driver callback.
> 
> Will replace drm_platform_init with drm_dev_alloc/drm_dev_register and
> integrate mtk_drm_load into mtk_drm_bind.
> 
> > > +int mtk_drm_gem_dumb_map_offset(struct drm_file *file_priv,
> > > + struct drm_device *dev, uint32_t handle,
> > > + uint64_t *offset)
> > > +{
> > > + struct drm_gem_object *obj;
> > > + int ret;
> > 

RE: [PATCH v4 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Pavel Fedin]

 Hello!

> Please, carefully look at:
> Documentation/devicetree/bindings/net/gpmc-eth.txt
> Documentation/devicetree/bindings/bus/ti-gpmc.txt
> 
> 1. Try to re-use existing bindings. Although I see existing bank-width
> and gpmc,device-width but yours samsung,srom-data-width seems better.
> Maybe there are other to re-use?

 I've done this and this is what i currently came up with. I'd like to discuss 
this before respin because nobody needs this
back-and-forth bouncing.
--- cut exynos5410.dtsi ---
sromc: sromc@1225 {
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x0400 0x2
  1 0 0x0500 0x2
  2 0 0x0600 0x2
  3 0 0x0700 0x2>;

compatible = "samsung,exynos-srom";
reg = <0x1225 0x14>;
};
--- cut exynos5410.dtsi ---
--- cut exynos5410-smdk5410.dts ---
 {
pinctrl-names = "default";
pinctrl-0 = <_ctl>, <_ebi>;

ethernet@3 {
compatible = "smsc,lan9115";
reg = <3 0 0x1>;
phy-mode = "mii";
interrupt-parent = <>;
interrupts = <5 8>;
reg-io-width = <2>;
smsc,irq-push-pull;
smsc,force-internal-phy;

samsung,srom-config = <1 9 12 1 9 1 1>;
};
};
--- cut exynos5410-smdk5410.dts ---

 1. After writing proper ranges i was able to get rid of dedicated bank number 
property, because now it is the first value in
device's "reg".
 2. I noticed that smsc binding already uses reg-io-width property. I searched 
for it, and it appears to be reused by many devices.
So, i decided to use it to specify bank width, since it's already there. 
ti-gpmc uses bank-width because it supports configurations
like reg-io-width = 4 && bank-width = 2. I don't know if it's possible to do 
the same with SROMc, Exynos doc doesn't tell anything
about 32-bit accesses. But, if you want to support it too, i would suggest the 
following algorithm:
if (have bank-width)
width = bank-width
else if (have reg-io-width)
width = reg-io-width
else
width = 1 /* default */
 3. About samsung,srom-config array. I have the following reasons to keep if 
this way:
- listing every property under own name is just too much typing
- these values really do not make sense without each other, or partialy. I 
would say that in array form they are even better
readable, because it is the same order in which they go into the register. 
However, it is still a nice idea do document them, but...
my PDF has "confidential" watermark on it, and this would mean that i 
essentially copy some information from it into Linux doc. Is
it okay to do this?
 If you still dislike the array, i'll redo is a set of properties like 
samsung,srom-tacs, samsung,srom-tcos, etc.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

--
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: rockchip: Setup ethernet0 alias for u-boot

[Geert Uytterhoeven]

Hi Sjoerd,

On Thu, Oct 29, 2015 at 9:44 PM, Sjoerd Simons
 wrote:
> Add an ethernet0 alias for the wired network card and an all 0 default
> mac address so that u-boot can find the device-node and fill in the
> mac address.

Thanks a lot!

I had the same issue on another board, and adding an "ethernet0" alias
fixes it.

> @@ -130,6 +134,8 @@
>  };
>
>   {
> +   /* To be filled in by U-Boot */
> +   mac-address = [00 00 00 00 00 00];
> status = "ok";
>  };

Note that in my case I didn't have to add an empty mac-address property.
U-Boot (2015.04-something --- don't have the sources) seems to add a
"local-mac-address" property automatically.

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 2/2] power: Add support for TI BQ24261 charger

[Andy Shevchenko]

On Thu, Oct 29, 2015 at 6:34 PM, Ramakrishna Pallala
 wrote:
> Add new charger driver support for TI BQ24261 charger IC.
>
> TI BQ24261 charger driver relies on extcon notifications to get the
> charger cable type and based on that it will set the charging parameters.


> +/*
> + * bq24261_charger.c - BQ24261 Charger driver
> + *
> + * Copyright (C) 2014 Intel Corporation
> + * Author: Jenny TC 

Authors:

> + * Ramakrishna Pallala 
> + *

> +#include 
> +#include 
> +#include 

> +#include 

Isn't this one is included in previous?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DEV_NAME "bq24261-charger"
> +
> +#define EXCEPTION_MONITOR_DELAY(60 * HZ)
> +#define WDT_RESET_DELAY(15 * HZ)
> +
> +/* BQ24261 registers */
> +#define BQ24261_STAT_CTRL0_ADDR0x00
> +#define BQ24261_CTRL_ADDR  0x01
> +#define BQ24261_BATT_VOL_CTRL_ADDR 0x02
> +#define BQ24261_VENDOR_REV_ADDR0x03
> +#define BQ24261_TERM_FCC_ADDR  0x04
> +#define BQ24261_VINDPM_STAT_ADDR   0x05
> +#define BQ24261_ST_NTC_MON_ADDR0x06
> +
> +#define BQ24261_RESET_ENABLE   BIT(7)
> +

Might be a good idea to put comment line preceded each group to refer
which register it covers.

> +#define BQ24261_FAULT_MASK GENMASK(2, 0)

Either use GENMASK in each case, or put plain number.

> +#define BQ24261_VOVP   0x01
> +#define BQ24261_LOW_SUPPLY 0x02
> +#define BQ24261_THERMAL_SHUTDOWN   0x03
> +#define BQ24261_BATT_TEMP_FAULT0x04
> +#define BQ24261_TIMER_FAULT0x05
> +#define BQ24261_BATT_OVP   0x06
> +#define BQ24261_NO_BATTERY 0x07
> +#define BQ24261_STAT_MASK  (0x03 << 4)
> +#define BQ24261_STAT_READY 0x00

Would be (0x00 << 4) better to explicitly show how you apply this?

> +#define BQ24261_STAT_CHRG_PRGRSS   (0x01 << 4)
> +#define BQ24261_STAT_CHRG_DONE (0x02 << 4)
> +#define BQ24261_STAT_FAULT (0x03 << 4)
> +#define BQ24261_BOOST_MASK BIT(6)
> +#define BQ24261_ENABLE_BOOST   BIT(6)

Similar, don't mix styles BIT vs. plain numbers. Here (0x01 << 6) looks better.

Why do you need separate _MASK for one bit fields like this?

> +#define BQ24261_TMR_RST_MASK   (0x01 << 7)

Ditto.

> +#define BQ24261_TMR_RST(0x01 << 7)
> +
> +#define BQ24261_CE_MASKBIT(1)

Ditto

> +#define BQ24261_CE_DISABLE BIT(1)
> +
> +#define BQ24261_HiZ_MASK   BIT(0)

Ditto

> +#define BQ24261_HiZ_ENABLE BIT(0)
> +
> +#define BQ24261_ICHRG_MASK GENMASK(7, 3)
> +
> +#define BQ24261_ITERM_MASK GENMASK(2, 0)
> +#define BQ24261_MIN_ITERM  50 /* 50 mA */
> +#define BQ24261_MAX_ITERM  300 /* 300 mA */
> +
> +#define BQ24261_VBREG_MASK GENMASK(7, 2)
> +#define BQ24261_VBREG_MIN_CV   3500
> +#define BQ24261_VBREG_MAX_CV   4440
> +#define BQ24261_VBREG_CV_DIV   20
> +#define BQ24261_VBREG_CV_BIT_POS   2
> +
> +#define BQ24261_INLMT_MASK GENMASK(6, 4)
> +#define BQ24261_INLMT_100  0x00
> +#define BQ24261_INLMT_150  (0x01 << 4)
> +#define BQ24261_INLMT_500  (0x02 << 4)
> +#define BQ24261_INLMT_900  (0x03 << 4)
> +#define BQ24261_INLMT_1500 (0x04 << 4)
> +#define BQ24261_INLMT_2000 (0x05 << 4)
> +#define BQ24261_INLMT_2500 (0x06 << 4)
> +
> +#define BQ24261_TE_MASKBIT(2)
> +#define BQ24261_TE_ENABLE  BIT(2)
> +#define BQ24261_STAT_ENABLE_MASK   BIT(3)
> +#define BQ24261_STAT_ENABLEBIT(3)
> +
> +#define BQ24261_VENDOR_MASKGENMASK(7, 5)
> +#define BQ24261_PART_MASK  GENMASK(4, 3)
> +#define BQ24261_REV_MASK   (0x07)
> +#define VENDOR_BQ2426X (0x02 << 5)
> +#define REV_BQ24261(0x06)
> +
> +#define BQ24261_TS_MASKBIT(3)
> +#define BQ24261_TS_ENABLED BIT(3)
> +#define BQ24261_BOOST_ILIM_MASKBIT(4)
> +#define BQ24261_BOOST_ILIM_500ma   (0x0)
> +#define BQ24261_BOOST_ILIM_1A  BIT(4)
> +#define BQ24261_VINDPM_OFF_MASKBIT(0)
> +#define BQ24261_VINDPM_OFF_5V  (0x0)
> +#define BQ24261_VINDPM_OFF_12V BIT(0)
> +
> +#define BQ24261_SAFETY_TIMER_MASK  GENMASK(6, 5)
> +#define BQ24261_SAFETY_TIMER_40MIN 0x00
> +#define BQ24261_SAFETY_TIMER_6HR   (0x01 << 5)
> +#define BQ24261_SAFETY_TIMER_9HR   (0x02 << 5)
> +#define BQ24261_SAFETY_TIMER_DISABLED  (0x03 << 5)
> +
> +/* Settings for Voltage / DPPM 

Re: [PATCH v4 2/4] ARM: dts: Add SROMc to Exynos 5410

[Pankaj Dubey]

Hi Pavel,

On Friday 30 October 2015 12:11 PM, Pavel Fedin wrote:

  Hello!


-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org 
[mailto:linux-samsung-soc-ow...@vger.kernel.org]
On Behalf Of Pankaj Dubey
Sent: Thursday, October 29, 2015 8:28 PM
To: Pavel Fedin
Cc: devicetree@vger.kernel.org; linux-arm-ker...@lists.infradead.org; 
linux-samsung-soc;
linux-ker...@vger.kernel.org; Rob Herring; Pawel Moll; Mark Rutland; Ian 
Campbell; Kumar Gala;
Kukjin Kim; Krzysztof Kozlowski
Subject: Re: [PATCH v4 2/4] ARM: dts: Add SROMc to Exynos 5410

Hi Pavel,

On 29 October 2015 at 18:12, Pavel Fedin  wrote:

This machine uses own SoC device tree file, add missing part.

Signed-off-by: Pavel Fedin 
---
  arch/arm/boot/dts/exynos5410.dtsi | 15 +++
  1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5410.dtsi 
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..da6a8fa0e 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,15 @@
 reg = <0x1000 0x100>;
 };

+   sromc: sromc@1225 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+


We do not need to specify these three properties as they are already
present in parent node "soc".


  We do, otherwise dtc complains about defaults of #address-cells = 2 and #size-cells=1, 
and without empty "ranges" subnode's resources are not correctly translated.



First of all this patch will not give this error. So this part should 
not be a part of this patch.
You should be getting above error after applying v4 4/4 "ARM: dts: Add 
Ethernet chip to SMDK5410". So if its failing for ethernet subnode, you 
can move this address-cells and size-cells in dts file just above 
ethernet node as shown below:


index 311e7be..d69981d 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -95,6 +95,9 @@
 };

  {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
pinctrl-names = "default";
pinctrl-0 = <_ctl>, <_ebi>;

And another question still remains open, we can't just like that change 
"smsc,lan9115" binding by adding samsung specific properties. If you 
want to do and there is no other way, you need to update DT binding of 
"smsc,lan9115" and get it reviewed.
Probably you can check suggestions from Krzysztof, where he pointed out 
some hint on how other places this is getting used.



Thanks,
Pankaj Dubey



+   compatible = "samsung,exynos-srom";
+   reg = <0x1225 0x14>;
+   };
+
 pmu_system_controller: system-controller@1004 {
 compatible = "samsung,exynos5410-pmu", "syscon";
 reg = <0x1004 0x5000>;
@@ -133,6 +142,12 @@
 <10  0 130 0>,
 <11  0 131 0>;
 };
+
+   arch_timer {
+   compatible = "arm,armv7-timer";
+   clock-frequency = <2400>;
+   };
+


This change should not be part of this patch.


  Ooops, thank you very much, this should not have been here at all. This is a 
leftover from my experiments, i was tracing DT parsing code and added it just 
for test, to see why timer gets probed as a subnode.
  Just forgot to remove it afterwards and it slipped into the patch.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



--
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 5/6] ARM: dts: sunxi: Add Allwinner H3 DTSI

[Jean-Francois Moine]

On Tue, 27 Oct 2015 17:50:25 +0100
Jens Kuske  wrote:

> The Allwinner H3 is a home entertainment system oriented SoC with
> four Cortex-A7 cores and a Mali-400MP2 GPU.
> 
> Signed-off-by: Jens Kuske 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 482 
> 
>  1 file changed, 482 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun8i-h3.dtsi
> 
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> new file mode 100644
> index 000..c18b5f7
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
[snip]
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + dma: dma-controller@01c02000 {
> + compatible = "allwinner,sun8i-h3-dma";
> + reg = <0x01c02000 0x1000>;
> + interrupts = ;
> + clocks = <_gates 6>;
> + resets = <_rst 6>;
> + #dma-cells = <1>;
> + };
[snip]
> +
> + bus_rst: reset@01c202c0 {
> + #reset-cells = <1>;
> + compatible = "allwinner,sun8i-h3-bus-reset";
> + reg = <0x01c202c0 0x1c>;
> + };
> +
[snip]
> + uart0: serial@01c28000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28000 0x400>;
> + interrupts = ;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <_gates 112>;
> + resets = <_rst 144>;
> + dmas = < 6>, < 6>;
> + dma-names = "rx", "tx";
> + status = "disabled";
> + };

The reset definitions would be clearer with declarations as the other
Allwinner SoCs and without driver hack:

soc {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;

dma: dma-controller@01c02000 {
compatible = "allwinner,sun8i-h3-dma";
reg = <0x01c02000 0x1000>;
interrupts = ;
clocks = <_gates 6>;
resets = <_reg0 6>;
#dma-cells = <1>;
};
...
rst_reg0: reset@01c202c0 {
#reset-cells = <1>;
compatible = "allwinner,sun6i-a31-clock-reset";
reg = <0x01c202c0 0x04>;
};
...
rst_reg4: reset@01c202d8 {
#reset-cells = <1>;
compatible = "allwinner,sun6i-a31-clock-reset";
reg = <0x01c202d8 0x04>;
};
   ...
uart0: serial@01c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
clocks = <_gates 112>;
resets = <_reg4 16>;
dmas = < 6>, < 6>;
dma-names = "rx", "tx";
status = "disabled";
};

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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] gpio: dt-bindings: document the official use of "ngpios"

[Geert Uytterhoeven]

Hi Linus,

On Fri, Oct 30, 2015 at 12:03 PM, Linus Walleij
 wrote:
> There are a bunch of drivers that utilize the "ngpios" DT property
> without any vendor prefix. Try to start cleaning up the mess by
> defining what we mean by this property.
>
> Cc: devicetree@vger.kernel.org
> Cc: Pramod Kumar 
> Cc: Jonas Gorski 
> Signed-off-by: Linus Walleij 
> ---
>  Documentation/devicetree/bindings/gpio/gpio.txt | 24 
>  1 file changed, 24 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt 
> b/Documentation/devicetree/bindings/gpio/gpio.txt
> index 63b1b9039ce8..9b081e6143a0 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio.txt
> @@ -129,6 +129,30 @@ Every GPIO controller node must contain both an empty 
> "gpio-controller"
>  property, and a #gpio-cells integer property, which indicates the number of
>  cells in a gpio-specifier.
>
> +Optionally, a GPIO controller may have a "ngpios" property. This property
> +indicates the number of in-use slots of available slots for GPIOs. The
> +typical example is something like this: the hardware register is 32 bits
> +wide, but only 18 of the bits have a physical counterpart. The driver is
> +generally written so that all 32 bits can be used, but the IP block is reused
> +in a lot of designs, some using all 32 bits, some using 18 and some using
> +12. In this case, setting "ngpios = <18>;" informs the driver that only the
> +first 18 GPIOs, at local offset 0 .. 17, are in use.
> +
> +If these GPIOs do not happen to be the first N GPIOs at offset 0...N, an

0...N-1

> +additional bitmask is needed to specify which GPIOs are actually in use,
> +and which are dummies. The bindings for this case has not yet been
> +specified, but should be specified if/when such hardware appears.
> +
> +Example:
> +
> +gpio-controller@ {
> +   compatible = "foo";
> +   reg = <0x 0x1000>;
> +   gpio-controller;
> +   #gpio-cells = <2>;
> +   ngpios = <18>;
> +}

The rcar-gpio driver uses the last number from the "gpio-ranges" to deduce
the number of GPIOs to driver. Should this be changed?

Thanks!

Gr{oetje,eeting}s,

Geert

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

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

[PATCH] arm64: renesas: salvator-x: Setup ethernet0 alias for U-Boot

[Geert Uytterhoeven]

Add an ethernet0 alias for the wired network card so that U-Boot can
find the device-node and add an appropriate "local-mac-address"
property.

Signed-off-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 86b70ce3d0599d6e..d16506338f020427 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -41,6 +41,7 @@
aliases {
serial0 = 
serial1 = 
+   ethernet0 = 
};
 
chosen {
-- 
1.9.1

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

Re: [PATCH v5 1/4] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC

[Alim Akhtar]

On 10/30/2015 01:12 PM, Krzysztof Kozlowski wrote:

On 30.10.2015 15:25, Alim Akhtar wrote:

From: Thomas Abraham 

Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device
is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators.
This also supports RTC and three 32.768KHz clock outputs.

Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Abraham 
Signed-off-by: Alim Akhtar 
---
  Documentation/devicetree/bindings/mfd/s2mps11.txt |   21 ++---
  1 file changed, 14 insertions(+), 7 deletions(-)



Reviewed-by: Krzysztof Kozlowski 


Thanks Krzysztof.


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

[PATCH] gpio: dt-bindings: document the official use of "ngpios"

[Linus Walleij]

There are a bunch of drivers that utilize the "ngpios" DT property
without any vendor prefix. Try to start cleaning up the mess by
defining what we mean by this property.

Cc: devicetree@vger.kernel.org
Cc: Pramod Kumar 
Cc: Jonas Gorski 
Signed-off-by: Linus Walleij 
---
 Documentation/devicetree/bindings/gpio/gpio.txt | 24 
 1 file changed, 24 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt 
b/Documentation/devicetree/bindings/gpio/gpio.txt
index 63b1b9039ce8..9b081e6143a0 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -129,6 +129,30 @@ Every GPIO controller node must contain both an empty 
"gpio-controller"
 property, and a #gpio-cells integer property, which indicates the number of
 cells in a gpio-specifier.
 
+Optionally, a GPIO controller may have a "ngpios" property. This property
+indicates the number of in-use slots of available slots for GPIOs. The
+typical example is something like this: the hardware register is 32 bits
+wide, but only 18 of the bits have a physical counterpart. The driver is
+generally written so that all 32 bits can be used, but the IP block is reused
+in a lot of designs, some using all 32 bits, some using 18 and some using
+12. In this case, setting "ngpios = <18>;" informs the driver that only the
+first 18 GPIOs, at local offset 0 .. 17, are in use.
+
+If these GPIOs do not happen to be the first N GPIOs at offset 0...N, an
+additional bitmask is needed to specify which GPIOs are actually in use,
+and which are dummies. The bindings for this case has not yet been
+specified, but should be specified if/when such hardware appears.
+
+Example:
+
+gpio-controller@ {
+   compatible = "foo";
+   reg = <0x 0x1000>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   ngpios = <18>;
+}
+
 The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
 providing automatic GPIO request and configuration as part of the
 gpio-controller's driver probe function.
-- 
2.4.3

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

Re: [PATCH] Revert "h8300: clocksource"

[Daniel Lezcano]

On 10/30/2015 12:19 PM, Arnd Bergmann wrote:

On Friday 30 October 2015 11:26:08 Daniel Lezcano wrote:

This reverts commit 618b902d8c098f2fff188119da7b3184c4bc5483.


[ ... ]


I found that Yoshinori Sato has always addressed all review comments very
quickly by rewriting the code in a proper manner when mistakes were
pointed out in the other drivers. Maybe you can describe now what the
problems are with the three drivers to give him a chance to fix them?


I agree it is a good argument to give him the opportunity to fix the code.

Yoshinori Sato, can you please do a cleanup in the init functions to 
comply with the other drivers, use CLOCKSOURCE_OF_DECLARE and remove the 
module exit code ?


Thanks.

  -- Daniel

--
  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 2/3] panel/panasonic-vvx10f034n00: Add DT bindings

[bjorn]

From: Werner Johansson 

This patch adds bindings for the Panasonic VVX10F034N00
WUXGA panel.

Signed-off-by: Werner Johansson 
Signed-off-by: Bjorn Andersson 
---
 .../bindings/panel/panasonic,vvx10f034n00.txt| 20 
 1 file changed, 20 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/panel/panasonic,vvx10f034n00.txt

diff --git a/Documentation/devicetree/bindings/panel/panasonic,vvx10f034n00.txt 
b/Documentation/devicetree/bindings/panel/panasonic,vvx10f034n00.txt
new file mode 100644
index 000..37dedf6
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/panasonic,vvx10f034n00.txt
@@ -0,0 +1,20 @@
+Panasonic 10" WUXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "panasonic,vvx10f034n00"
+- reg: DSI virtual channel of the peripheral
+- power-supply: phandle of the regulator that provides the supply voltage
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   mdss_dsi@fd922800 {
+   panel@0 {
+   compatible = "panasonic,vvx10f034n00";
+   reg = <0>;
+   power-supply = <_vsp>;
+   backlight = <_wled>;
+   };
+   };
-- 
2.3.2 (Apple Git-55)

--
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] ahci: qoriq: Rename LS2085A SoC support code to LS2080A

[Tejun Heo]

On Thu, Oct 29, 2015 at 02:22:15PM +0800, Tang Yuantian wrote:
> Freescale is renaming the LS2085A SoC to LS2080A.
> This patch addresses the same.
> 
> Signed-off-by: Tang Yuantian 

Applied 1-3 to libata/for-4.4 with cosmetic updates.

Thanks.

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

Re: [PATCH 1/3] PM / OPP: Add "opp-supported-hw" binding

[Viresh Kumar]

On 30-10-15, 14:49, Stephen Boyd wrote:
> I suppose if you wanted to have 64 possible combinations of some
> attribute you would just extend it to two 32 bit numbers in
> sequence? I don't see the limitation here, and hopefully there
> isn't a limitation so that we can specify sufficiently large
> numbers with more bits if we need to.

Yeah, we discussed this earlier when Lee had the same query and I
suggested the exact same thing to him then.

-- 
viresh
--
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/4] clocksource: rockchip: Make the driver more compatible

[Heiko Stuebner]

Hi Daniel,

Am Freitag, 30. Oktober 2015, 11:42:29 schrieb Daniel Lezcano:
> On 10/30/2015 04:43 AM, Caesar Wang wrote:
> > Hi Daniel,
> >
> > 在 2015年10月01日 03:14, Heiko Stübner 写道:
> >> Hi Daniel,
> >>
> >> Am Dienstag, 29. September 2015, 06:18:03 schrieb Daniel Lezcano:
> >>> On 09/25/2015 04:14 AM, Caesar Wang wrote:
>  Build the arm64 SoCs (e.g.: RK3368) on Rockchip platform,
>  There are some failure with build up on timer driver for rockchip.
> 
>  Says:
>  /tmp/ccdAnNy5.s:47: Error: missing immediate expression at  operand
>  1 --
>  `dsb`
>  ...
> 
>  The problem was different semantics of dsb on btw arm32 and arm64,
>  Here we can convert the dsb with insteading of dsb(sy).The "sy" param
>  is the default which you are allow to omit, so on arm32 dsb()and
>  dsb(sy)
>  are the same.
> 
>  Signed-off-by: Caesar Wang 
> >>> Acked-by: Daniel Lezcano 
> >> as you have "just" Acked these patches, I guess you are expecting them
> >> to go
> >> through the same tree as the devicetree changes, right?
> >
> > I'm wonder if someone will apply this series patchs but the wait.:-)
> > In fact, I'm no sure that the Acked is really meaning.:-
> 
> Yes, by acking the patch I say I am ok with it and I agree it can go 
> through another tree.

although I guess the two clocksource changes could very well just go
through your tree. dsb() -> dsb(sy) is supposed to be equal and the second
one is just cosmetics.  The Kconfig and dts changes need to wait in any case
for 4.5 ... but I guess that may be true for the clocksource changes as well?


Heiko

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