[PATCH V4 08/16] irqchip: crossbar: Fix kerneldoc warning

[Sricharan R]

From: Nishanth Menon n...@ti.com

Adding missing properties for kerneldoc (@write) and cleanup
of harmless warnings while we are here.

kerneldoc warnings:
Warning(drivers/irqchip/irq-crossbar.c:27): missing initial short description 
on line:
 * struct crossbar_device: crossbar device description
Info(drivers/irqchip/irq-crossbar.c:27): Scanning doc for struct
Warning(drivers/irqchip/irq-crossbar.c:39): No description found for parameter 
'write'
2 warnings

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/irqchip/irq-crossbar.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index f7eda9f..cee556b 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -22,12 +22,14 @@
 #define IRQ_SKIP   -3
 #define GIC_IRQ_START  32
 
-/*
+/**
+ * struct crossbar_device - crossbar device description
  * @int_max: maximum number of supported interrupts
  * @safe_map: safe default value to initialize the crossbar
  * @irq_map: array of interrupts to crossbar number mapping
  * @crossbar_base: crossbar base address
  * @register_offsets: offsets for each irq number
+ * @write: register write function pointer
  */
 struct crossbar_device {
uint int_max;
-- 
1.7.9.5

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

[PATCH V4 04/16] irqchip: crossbar: Initialise the crossbar with a safe value

[Sricharan R]

From: Nishanth Menon n...@ti.com

Since crossbar is s/w configurable, the initial settings of the
crossbar cannot be assumed to be sane. This implies that:
a) On initialization all un-reserved crossbars must be initialized to
   a known 'safe' value.
b) When unmapping the interrupt, the safe value must be written to
   ensure that the crossbar mapping matches with interrupt controller
   usage.

So provide a safe value in the dt data to map if
'0' is not safe for the platform and use it during init and unmap

While at this, fix the below checkpatch warning.
Fixes checkpatch warning:
WARNING: Unnecessary space before function pointer arguments
 #37: FILE: drivers/irqchip/irq-crossbar.c:37:
 +  void (*write) (int, int);

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 .../devicetree/bindings/arm/omap/crossbar.txt  |3 +++
 drivers/irqchip/irq-crossbar.c |   19 +--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt 
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
index 0795765..5f45c78 100644
--- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -22,6 +22,9 @@ Optional properties:
   SOC-specific hard-wiring of those irqs which unexpectedly bypasses the
   crossbar. These irqs have a crossbar register, but still cannot be used.
 
+- ti,irqs-safe-map: integer which maps to a safe configuration to use
+  when the interrupt controller irq is unused (when not provided, default is 0)
+
 Examples:
crossbar_mpu: @4a02 {
compatible = ti,irq-crossbar;
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 0533a71..4be30c0 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -23,16 +23,18 @@
 
 /*
  * @int_max: maximum number of supported interrupts
+ * @safe_map: safe default value to initialize the crossbar
  * @irq_map: array of interrupts to crossbar number mapping
  * @crossbar_base: crossbar base address
  * @register_offsets: offsets for each irq number
  */
 struct crossbar_device {
uint int_max;
+   uint safe_map;
uint *irq_map;
void __iomem *crossbar_base;
int *register_offsets;
-   void (*write) (int, int);
+   void (*write)(int, int);
 };
 
 static struct crossbar_device *cb;
@@ -88,8 +90,10 @@ static void crossbar_domain_unmap(struct irq_domain *d, 
unsigned int irq)
 {
irq_hw_number_t hw = irq_get_irq_data(irq)-hwirq;
 
-   if (hw  GIC_IRQ_START)
+   if (hw  GIC_IRQ_START) {
cb-irq_map[hw - GIC_IRQ_START] = IRQ_FREE;
+   cb-write(hw - GIC_IRQ_START, cb-safe_map);
+   }
 }
 
 static int crossbar_domain_xlate(struct irq_domain *d,
@@ -214,6 +218,17 @@ static int __init crossbar_of_init(struct device_node 
*node)
reserved += size;
}
 
+   of_property_read_u32(node, ti,irqs-safe-map, cb-safe_map);
+
+   /* Initialize the crossbar with safe map to start with */
+   for (i = 0; i  max; i++) {
+   if (cb-irq_map[i] == IRQ_RESERVED ||
+   cb-irq_map[i] == IRQ_SKIP)
+   continue;
+
+   cb-write(i, cb-safe_map);
+   }
+
register_routable_domain_ops(routable_irq_domain_ops);
return 0;
 
-- 
1.7.9.5

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

[PATCH V4 16/16] irqchip: crossbar: Allow for quirky hardware with direct hardwiring of GIC

[Sricharan R]

From: Nishanth Menon n...@ti.com

On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10, 131,
132, 133 are direct wired to hardware blocks bypassing crossbar.
This quirky implementation is *NOT* supposed to be the expectation
of crossbar hardware usage. However, these are already marked in our
description of the hardware with SKIP and RESERVED where appropriate.

Unfortunately, we need to be able to refer to these hardwired IRQs.
So, to request these, crossbar driver can use the existing information
from it's table that these SKIP/RESERVED maps are direct wired sources
and generic allocation/programming of crossbar should be avoided.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 .../devicetree/bindings/arm/omap/crossbar.txt  |   12 ++--
 drivers/irqchip/irq-crossbar.c |   20 ++--
 2 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt 
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
index 35356b6..51a85c3 100644
--- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -44,8 +44,10 @@ Documentation/devicetree/bindings/arm/gic.txt for further 
details.
 
 An interrupt consumer on an SoC using crossbar will use:
interrupts = GIC_SPI request_number interrupt_level
-request number shall be between 0 to that described by
-ti,max-crossbar-sources
+When the request number is between 0 to that described by
+ti,max-crossbar-sources, it is assumed to be a crossbar mapping. If the
+request_number is greater than ti,max-crossbar-sources, then it is mapped as 
a
+quirky hardware mapping direct to GIC.
 
 Example:
device_x@0x4a023000 {
@@ -53,3 +55,9 @@ Example:
interrupts = GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH;
...
};
+
+   device_y@0x4a033000 {
+   /* Direct mapped GIC SPI 1 used */
+   interrupts = GIC_SPI DIRECT_IRQ(1) IRQ_TYPE_LEVEL_HIGH;
+   ...
+   };
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 83f803b..85c2985 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -86,8 +86,13 @@ static inline int allocate_free_irq(int cb_no)
 
 static inline bool needs_crossbar_write(irq_hw_number_t hw)
 {
-   if (hw  GIC_IRQ_START)
-   return true;
+   int cb_no;
+
+   if (hw  GIC_IRQ_START) {
+   cb_no = cb-irq_map[hw - GIC_IRQ_START];
+   if (cb_no != IRQ_RESERVED  cb_no != IRQ_SKIP)
+   return true;
+   }
 
return false;
 }
@@ -130,8 +135,19 @@ static int crossbar_domain_xlate(struct irq_domain *d,
 {
int ret;
int req_num = intspec[1];
+   int direct_map_num;
 
if (req_num = cb-max_crossbar_sources) {
+   direct_map_num = req_num - cb-max_crossbar_sources;
+   if (direct_map_num  cb-int_max) {
+   ret = cb-irq_map[direct_map_num];
+   if (ret == IRQ_RESERVED || ret == IRQ_SKIP) {
+   /* We use the interrupt num as h/w irq num */
+   ret = direct_map_num;
+   goto found;
+   }
+   }
+
pr_err(%s: requested crossbar number %d  max %d\n,
   __func__, req_num, cb-max_crossbar_sources);
return -EINVAL;
-- 
1.7.9.5

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

[PATCH V4 15/16] documentation: dt: omap: crossbar: Add description for interrupt consumer

[Sricharan R]

From: Nishanth Menon n...@ti.com

The current crossbar description does not include the description
required for the consumer of the crossbar, a.k.a devices whoes events
pass through the crossbar into the GIC interrupt controller.

So, provide documentation for the same.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 .../devicetree/bindings/arm/omap/crossbar.txt  |   17 +
 1 file changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt 
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
index 6923531..35356b6 100644
--- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -36,3 +36,20 @@ Examples:
ti,irqs-reserved = 0 1 2 3 5 6 131 132 139 140;
ti,irqs-skip = 10 133 139 140;
};
+
+Consumer:
+
+See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
+Documentation/devicetree/bindings/arm/gic.txt for further details.
+
+An interrupt consumer on an SoC using crossbar will use:
+   interrupts = GIC_SPI request_number interrupt_level
+request number shall be between 0 to that described by
+ti,max-crossbar-sources
+
+Example:
+   device_x@0x4a023000 {
+   /* Crossbar 8 used */
+   interrupts = GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH;
+   ...
+   };
-- 
1.7.9.5

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

[PATCH V4 14/16] irqchip: crossbar: Introduce centralized check for crossbar write

[Sricharan R]

From: Nishanth Menon n...@ti.com

This is a basic check to ensure that crossbar register needs to be
written. This ensures that we have a common check which is used in
both map and unmap logic.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/irqchip/irq-crossbar.c |   14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index c9f068c..83f803b 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -84,10 +84,20 @@ static inline int allocate_free_irq(int cb_no)
return -ENODEV;
 }
 
+static inline bool needs_crossbar_write(irq_hw_number_t hw)
+{
+   if (hw  GIC_IRQ_START)
+   return true;
+
+   return false;
+}
+
 static int crossbar_domain_map(struct irq_domain *d, unsigned int irq,
   irq_hw_number_t hw)
 {
-   cb-write(hw - GIC_IRQ_START, cb-irq_map[hw - GIC_IRQ_START]);
+   if (needs_crossbar_write(hw))
+   cb-write(hw - GIC_IRQ_START, cb-irq_map[hw - GIC_IRQ_START]);
+
return 0;
 }
 
@@ -106,7 +116,7 @@ static void crossbar_domain_unmap(struct irq_domain *d, 
unsigned int irq)
 {
irq_hw_number_t hw = irq_get_irq_data(irq)-hwirq;
 
-   if (hw  GIC_IRQ_START) {
+   if (needs_crossbar_write(hw)) {
cb-irq_map[hw - GIC_IRQ_START] = IRQ_FREE;
cb-write(hw - GIC_IRQ_START, cb-safe_map);
}
-- 
1.7.9.5

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

[PATCH V4 11/16] irqchip: crossbar: Set cb pointer to null in case of error

[Sricharan R]

If crossbar_of_init returns with a error, then set the cb pointer
to null.

Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/irqchip/irq-crossbar.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index afc35fd..a8c6156 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -250,6 +250,8 @@ err_base:
iounmap(cb-crossbar_base);
 err_cb:
kfree(cb);
+
+   cb = NULL;
return ret;
 }
 
-- 
1.7.9.5

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

[PATCH V4 05/16] irqchip: crossbar: Change allocation logic by reversing search for free irqs

[Sricharan R]

From: Nishanth Menon n...@ti.com

Reverse the search algorithm to ensure that address mapping and IRQ
allocation logics are proper. This makes the below bugs visible sooner.

class 1. address space errors - example:
reg = a size_b
ti,max-irqs =  is a wrong parameter

class 2: irq-reserved list - which decides which entries in the
address space is not actually wired in

class 3: wrong list of routable-irqs.

In general allocating from max to min tends to have benefits in
ensuring the different issues that may be present in dts is easily
caught at definition time, rather than at a later point in time.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/irqchip/irq-crossbar.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 4be30c0..a39cb31 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -58,7 +58,7 @@ static inline int get_prev_map_irq(int cb_no)
 {
int i;
 
-   for (i = 0; i  cb-int_max; i++)
+   for (i = cb-int_max - 1; i = 0; i--)
if (cb-irq_map[i] == cb_no)
return i;
 
@@ -69,7 +69,7 @@ static inline int allocate_free_irq(int cb_no)
 {
int i;
 
-   for (i = 0; i  cb-int_max; i++) {
+   for (i = cb-int_max - 1; i = 0; i--) {
if (cb-irq_map[i] == IRQ_FREE) {
cb-irq_map[i] = cb_no;
return i;
-- 
1.7.9.5

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

[PATCH V4 07/16] irqchip: crossbar: Fix sparse and checkpatch warnings

[Sricharan R]

From: Nishanth Menon n...@ti.com

There is absolutely no need for crossbar driver to expose functions and
variables into global namespace. So make them all static

Also fix a couple of checkpatch warnings.

Fixes sparse warnings:
drivers/irqchip/irq-crossbar.c:129:29: warning: symbol 
'routable_irq_domain_ops' was not declared. Should it be static?
drivers/irqchip/irq-crossbar.c:261:12: warning: symbol 'irqcrossbar_init' was 
not declared. Should it be static?

Checkpatch warnings:
WARNING: Prefer kcalloc over kzalloc with multiply
+   cb-irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);

WARNING: Prefer kcalloc over kzalloc with multiply
+   cb-register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/irqchip/irq-crossbar.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 88fbe0f..f7eda9f 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -15,6 +15,7 @@
 #include linux/of_irq.h
 #include linux/slab.h
 #include linux/irqchip/arm-gic.h
+#include linux/irqchip/irq-crossbar.h
 
 #define IRQ_FREE   -1
 #define IRQ_RESERVED   -2
@@ -118,7 +119,7 @@ found:
return 0;
 }
 
-const struct irq_domain_ops routable_irq_domain_ops = {
+static const struct irq_domain_ops routable_irq_domain_ops = {
.map = crossbar_domain_map,
.unmap = crossbar_domain_unmap,
.xlate = crossbar_domain_xlate
@@ -139,7 +140,7 @@ static int __init crossbar_of_init(struct device_node *node)
goto err1;
 
of_property_read_u32(node, ti,max-irqs, max);
-   cb-irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);
+   cb-irq_map = kcalloc(max, sizeof(int), GFP_KERNEL);
if (!cb-irq_map)
goto err2;
 
@@ -184,7 +185,7 @@ static int __init crossbar_of_init(struct device_node *node)
}
 
 
-   cb-register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
+   cb-register_offsets = kcalloc(max, sizeof(int), GFP_KERNEL);
if (!cb-register_offsets)
goto err3;
 
-- 
1.7.9.5

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

[PATCH V4 09/16] irqchip: crossbar: Return proper error value

[Sricharan R]

From: Nishanth Menon n...@ti.com

crossbar_of_init always returns -ENOMEM in case of errors.
There can be other causes of failure like invalid data from
DT. So return a appropriate error value for that case.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/irqchip/irq-crossbar.c |   14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index cee556b..10d723d 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -129,19 +129,25 @@ static const struct irq_domain_ops 
routable_irq_domain_ops = {
 
 static int __init crossbar_of_init(struct device_node *node)
 {
-   int i, size, max, reserved = 0, entry;
+   int i, size, max = 0, reserved = 0, entry;
const __be32 *irqsr;
+   int ret = -ENOMEM;
 
cb = kzalloc(sizeof(*cb), GFP_KERNEL);
 
if (!cb)
-   return -ENOMEM;
+   return ret;
 
cb-crossbar_base = of_iomap(node, 0);
if (!cb-crossbar_base)
goto err1;
 
of_property_read_u32(node, ti,max-irqs, max);
+   if (!max) {
+   pr_err(missing 'ti,max-irqs' property\n);
+   ret = -EINVAL;
+   goto err2;
+   }
cb-irq_map = kcalloc(max, sizeof(int), GFP_KERNEL);
if (!cb-irq_map)
goto err2;
@@ -162,6 +168,7 @@ static int __init crossbar_of_init(struct device_node *node)
   i, entry);
if (entry  max) {
pr_err(Invalid reserved entry\n);
+   ret = -EINVAL;
goto err3;
}
cb-irq_map[entry] = IRQ_RESERVED;
@@ -205,6 +212,7 @@ static int __init crossbar_of_init(struct device_node *node)
break;
default:
pr_err(Invalid reg-size property\n);
+   ret = -EINVAL;
goto err4;
break;
}
@@ -243,7 +251,7 @@ err2:
iounmap(cb-crossbar_base);
 err1:
kfree(cb);
-   return -ENOMEM;
+   return ret;
 }
 
 static const struct of_device_id crossbar_match[] __initconst = {
-- 
1.7.9.5

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

[PATCH V4 10/16] irqchip: crossbar: Change the goto naming

[Sricharan R]

From: Nishanth Menon n...@ti.com

Using err1,2,3,4 etc makes it hard to ensure a new exit path in the
middle will not result in spurious changes, so rename the error paths
as per the function it does.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/irqchip/irq-crossbar.c |   23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 10d723d..afc35fd 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -140,17 +140,17 @@ static int __init crossbar_of_init(struct device_node 
*node)
 
cb-crossbar_base = of_iomap(node, 0);
if (!cb-crossbar_base)
-   goto err1;
+   goto err_cb;
 
of_property_read_u32(node, ti,max-irqs, max);
if (!max) {
pr_err(missing 'ti,max-irqs' property\n);
ret = -EINVAL;
-   goto err2;
+   goto err_base;
}
cb-irq_map = kcalloc(max, sizeof(int), GFP_KERNEL);
if (!cb-irq_map)
-   goto err2;
+   goto err_base;
 
cb-int_max = max;
 
@@ -169,7 +169,7 @@ static int __init crossbar_of_init(struct device_node *node)
if (entry  max) {
pr_err(Invalid reserved entry\n);
ret = -EINVAL;
-   goto err3;
+   goto err_irq_map;
}
cb-irq_map[entry] = IRQ_RESERVED;
}
@@ -187,7 +187,7 @@ static int __init crossbar_of_init(struct device_node *node)
if (entry  max) {
pr_err(Invalid skip entry\n);
ret = -EINVAL;
-   goto err3;
+   goto err_irq_map;
}
cb-irq_map[entry] = IRQ_SKIP;
}
@@ -196,7 +196,7 @@ static int __init crossbar_of_init(struct device_node *node)
 
cb-register_offsets = kcalloc(max, sizeof(int), GFP_KERNEL);
if (!cb-register_offsets)
-   goto err3;
+   goto err_irq_map;
 
of_property_read_u32(node, ti,reg-size, size);
 
@@ -213,7 +213,7 @@ static int __init crossbar_of_init(struct device_node *node)
default:
pr_err(Invalid reg-size property\n);
ret = -EINVAL;
-   goto err4;
+   goto err_reg_offset;
break;
}
 
@@ -230,7 +230,6 @@ static int __init crossbar_of_init(struct device_node *node)
}
 
of_property_read_u32(node, ti,irqs-safe-map, cb-safe_map);
-
/* Initialize the crossbar with safe map to start with */
for (i = 0; i  max; i++) {
if (cb-irq_map[i] == IRQ_RESERVED ||
@@ -243,13 +242,13 @@ static int __init crossbar_of_init(struct device_node 
*node)
register_routable_domain_ops(routable_irq_domain_ops);
return 0;
 
-err4:
+err_reg_offset:
kfree(cb-register_offsets);
-err3:
+err_irq_map:
kfree(cb-irq_map);
-err2:
+err_base:
iounmap(cb-crossbar_base);
-err1:
+err_cb:
kfree(cb);
return ret;
 }
-- 
1.7.9.5

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

[PATCH V4 13/16] irqchip: crossbar: Introduce ti,max-crossbar-sources to identify valid crossbar mapping

[Sricharan R]

From: Nishanth Menon n...@ti.com

Currently we attempt to map any crossbar value to an IRQ, however,
this is not correct from hardware perspective. There is a max crossbar
event number upto which hardware supports. So describe the same in
device tree using 'ti,max-crossbar-sources' property and use it to
validate requests.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 .../devicetree/bindings/arm/omap/crossbar.txt  |2 ++
 drivers/irqchip/irq-crossbar.c |   21 ++--
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt 
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
index 5f45c78..6923531 100644
--- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -10,6 +10,7 @@ Required properties:
 - compatible : Should be ti,irq-crossbar
 - reg: Base address and the size of the crossbar registers.
 - ti,max-irqs: Total number of irqs available at the interrupt controller.
+- ti,max-crossbar-sources: Maximum number of crossbar sources that can be 
routed.
 - ti,reg-size: Size of a individual register in bytes. Every individual
register is assumed to be of same size. Valid sizes are 1, 2, 4.
 - ti,irqs-reserved: List of the reserved irq lines that are not muxed using
@@ -30,6 +31,7 @@ Examples:
compatible = ti,irq-crossbar;
reg = 0x4a002a48 0x130;
ti,max-irqs = 160;
+   ti,max-crossbar-sources = MAX_SOURCES;
ti,reg-size = 2;
ti,irqs-reserved = 0 1 2 3 5 6 131 132 139 140;
ti,irqs-skip = 10 133 139 140;
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 518d712..c9f068c 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -26,6 +26,7 @@
  * struct crossbar_device - crossbar device description
  * @int_max: maximum number of supported interrupts
  * @safe_map: safe default value to initialize the crossbar
+ * @max_crossbar_sources: Maximum number of crossbar sources
  * @irq_map: array of interrupts to crossbar number mapping
  * @crossbar_base: crossbar base address
  * @register_offsets: offsets for each irq number
@@ -34,6 +35,7 @@
 struct crossbar_device {
uint int_max;
uint safe_map;
+   uint max_crossbar_sources;
uint *irq_map;
void __iomem *crossbar_base;
int *register_offsets;
@@ -117,12 +119,19 @@ static int crossbar_domain_xlate(struct irq_domain *d,
 unsigned int *out_type)
 {
int ret;
+   int req_num = intspec[1];
 
-   ret = get_prev_map_irq(intspec[1]);
+   if (req_num = cb-max_crossbar_sources) {
+   pr_err(%s: requested crossbar number %d  max %d\n,
+  __func__, req_num, cb-max_crossbar_sources);
+   return -EINVAL;
+   }
+
+   ret = get_prev_map_irq(req_num);
if (ret = 0)
goto found;
 
-   ret = allocate_free_irq(intspec[1]);
+   ret = allocate_free_irq(req_num);
 
if (ret  0)
return ret;
@@ -153,6 +162,14 @@ static int __init crossbar_of_init(struct device_node 
*node)
if (!cb-crossbar_base)
goto err_cb;
 
+   of_property_read_u32(node, ti,max-crossbar-sources,
+cb-max_crossbar_sources);
+   if (!cb-max_crossbar_sources) {
+   pr_err(missing 'ti,max-crossbar-sources' property\n);
+   ret = -EINVAL;
+   goto err_base;
+   }
+
of_property_read_u32(node, ti,max-irqs, max);
if (!max) {
pr_err(missing 'ti,max-irqs' property\n);
-- 
1.7.9.5

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

[PATCH V4 12/16] irqchip: crossbar: Add kerneldoc for crossbar_domain_unmap callback

[Sricharan R]

Adding kerneldoc for unmap callback function.

Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/irqchip/irq-crossbar.c |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index a8c6156..518d712 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -89,6 +89,17 @@ static int crossbar_domain_map(struct irq_domain *d, 
unsigned int irq,
return 0;
 }
 
+/**
+ * crossbar_domain_unmap - unmap a crossbar-irq connection
+ * @d: domain of irq to unmap
+ * @irq: virq number
+ *
+ * We do not maintain a use count of total number of map/unmap
+ * calls for a particular irq to find out if a irq can be really
+ * unmapped. This is because unmap is called during irq_dispose_mapping(irq),
+ * after which irq is anyways unusable. So an explicit map has to be called
+ * after that.
+ */
 static void crossbar_domain_unmap(struct irq_domain *d, unsigned int irq)
 {
irq_hw_number_t hw = irq_get_irq_data(irq)-hwirq;
-- 
1.7.9.5

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

[PATCH V4 01/16] irqchip: crossbar: Dont use '0' to mark reserved interrupts

[Sricharan R]

From: Nishanth Menon n...@ti.com

Today '0' is actually reserved, but may not be the same in the future.

So, use a flag to mark the GIC interrupts that are reserved.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/irqchip/irq-crossbar.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 3d15d16..20105bc 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -17,6 +17,7 @@
 #include linux/irqchip/arm-gic.h
 
 #define IRQ_FREE   -1
+#define IRQ_RESERVED   -2
 #define GIC_IRQ_START  32
 
 /*
@@ -139,7 +140,7 @@ static int __init crossbar_of_init(struct device_node *node)
pr_err(Invalid reserved entry\n);
goto err3;
}
-   cb-irq_map[entry] = 0;
+   cb-irq_map[entry] = IRQ_RESERVED;
}
}
 
@@ -170,7 +171,7 @@ static int __init crossbar_of_init(struct device_node *node)
 * reserved irqs. so find and store the offsets once.
 */
for (i = 0; i  max; i++) {
-   if (!cb-irq_map[i])
+   if (cb-irq_map[i] == IRQ_RESERVED)
continue;
 
cb-register_offsets[i] = reserved;
-- 
1.7.9.5

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

[PATCH V4 00/16] irqchip: crossbar: Driver fixes

[Sricharan R]

This series does some cleanups, fixes for handling two interrupts
getting mapped twice to same crossbar and provides support for
hardwired IRQ and crossbar definitions.

On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10,
131, 132, 133 are direct wired to hardware blocks bypassing
crossbar. This quirky implementation is *NOT* supposed to be the
expectation of crossbar hardware usage. This series adds support
to represent such hard-wired irqs through DT and avoid generic
allocation/programming of crossbar in the driver.

This way of supporting hard-wired irqs was a result of
the below discussions.
http://www.spinics.net/lists/arm-kernel/msg329946.html

Based on 3.16 rc2 mainline.

All the patches are available here
 g...@github.com:Sricharanti/sricharan.git crossbar_updates

The fixes series[1] earlier posted is merged in to this.
[1] http://www.spinics.net/lists/arm-kernel/msg328273.html

[V2] Merged the above series and rebased on 3.15 mainline

[V3] Modified patch#3 to get irqs-skip properties from DT,
 merged path#8 for checkpatch warning to other relevant
 patches and fixed comments for other patches.

[V4] Based on 3.16rc2 and fixed Jason's ja...@lakedaemon.net comments.

Nishanth Menon (14):
  irqchip: crossbar: Dont use '0' to mark reserved interrupts
  irqchip: crossbar: Check for premapped crossbar before allocating
  irqchip: crossbar: Introduce ti,irqs-skip to skip irqs that bypass
crossbar
  irqchip: crossbar: Initialise the crossbar with a safe value
  irqchip: crossbar: Change allocation logic by reversing search for
free irqs
  irqchip: crossbar: Remove IS_ERR_VALUE check
  irqchip: crossbar: Fix sparse and checkpatch warnings
  irqchip: crossbar: Fix kerneldoc warning
  irqchip: crossbar: Return proper error value
  irqchip: crossbar: Change the goto naming
  irqchip: crossbar: Introduce ti,max-crossbar-sources to identify
valid crossbar mapping
  irqchip: crossbar: Introduce centralized check for crossbar write
  documentation: dt: omap: crossbar: Add description for interrupt
consumer
  irqchip: crossbar: Allow for quirky hardware with direct hardwiring
of GIC

Sricharan R (2):
  irqchip: crossbar: Set cb pointer to null in case of error
  irqchip: crossbar: Add kerneldoc for crossbar_domain_unmap callback

 .../devicetree/bindings/arm/omap/crossbar.txt  |   36 +
 drivers/irqchip/irq-crossbar.c |  168 +---
 2 files changed, 179 insertions(+), 25 deletions(-)

-- 
1.7.9.5

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

[PATCH V4 03/16] irqchip: crossbar: Introduce ti,irqs-skip to skip irqs that bypass crossbar

[Sricharan R]

From: Nishanth Menon n...@ti.com

When, in the system due to varied reasons, interrupts might be unusable
due to hardware behavior, but register maps do exist, then those interrupts
should be skipped while mapping irq to crossbars.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 .../devicetree/bindings/arm/omap/crossbar.txt  |6 ++
 drivers/irqchip/irq-crossbar.c |   20 
 2 files changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt 
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
index fb88585..0795765 100644
--- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -17,6 +17,11 @@ Required properties:
 so crossbar bar driver should not consider them as free
 lines.
 
+Optional properties:
+- ti,irqs-skip: This is similar to ti,irqs-reserved, but these are for
+  SOC-specific hard-wiring of those irqs which unexpectedly bypasses the
+  crossbar. These irqs have a crossbar register, but still cannot be used.
+
 Examples:
crossbar_mpu: @4a02 {
compatible = ti,irq-crossbar;
@@ -24,4 +29,5 @@ Examples:
ti,max-irqs = 160;
ti,reg-size = 2;
ti,irqs-reserved = 0 1 2 3 5 6 131 132 139 140;
+   ti,irqs-skip = 10 133 139 140;
};
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 51d4b87..0533a71 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -18,6 +18,7 @@
 
 #define IRQ_FREE   -1
 #define IRQ_RESERVED   -2
+#define IRQ_SKIP   -3
 #define GIC_IRQ_START  32
 
 /*
@@ -160,6 +161,25 @@ static int __init crossbar_of_init(struct device_node 
*node)
}
}
 
+   /* Skip irqs hardwired to bypass the crossbar */
+   irqsr = of_get_property(node, ti,irqs-skip, size);
+   if (irqsr) {
+   size /= sizeof(__be32);
+
+   for (i = 0; i  size; i++) {
+   of_property_read_u32_index(node,
+  ti,irqs-skip,
+  i, entry);
+   if (entry  max) {
+   pr_err(Invalid skip entry\n);
+   ret = -EINVAL;
+   goto err3;
+   }
+   cb-irq_map[entry] = IRQ_SKIP;
+   }
+   }
+
+
cb-register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
if (!cb-register_offsets)
goto err3;
-- 
1.7.9.5

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

[PATCH V4 02/16] irqchip: crossbar: Check for premapped crossbar before allocating

[Sricharan R]

From: Nishanth Menon n...@ti.com

If irq_of_parse_and_map is executed twice, the same crossbar is mapped to two
different GIC interrupts. This is completely undesirable. Instead, check
if the requested crossbar event is pre-allocated and provide that GIC
mapping back to caller if already allocated.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/irqchip/irq-crossbar.c |   16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 20105bc..51d4b87 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -51,6 +51,17 @@ static inline void crossbar_writeb(int irq_no, int cb_no)
writeb(cb_no, cb-crossbar_base + cb-register_offsets[irq_no]);
 }
 
+static inline int get_prev_map_irq(int cb_no)
+{
+   int i;
+
+   for (i = 0; i  cb-int_max; i++)
+   if (cb-irq_map[i] == cb_no)
+   return i;
+
+   return -ENODEV;
+}
+
 static inline int allocate_free_irq(int cb_no)
 {
int i;
@@ -88,11 +99,16 @@ static int crossbar_domain_xlate(struct irq_domain *d,
 {
unsigned long ret;
 
+   ret = get_prev_map_irq(intspec[1]);
+   if (!IS_ERR_VALUE(ret))
+   goto found;
+
ret = allocate_free_irq(intspec[1]);
 
if (IS_ERR_VALUE(ret))
return ret;
 
+found:
*out_hwirq = ret + GIC_IRQ_START;
return 0;
 }
-- 
1.7.9.5

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

[PATCH V4 06/16] irqchip: crossbar: Remove IS_ERR_VALUE check

[Sricharan R]

From: Nishanth Menon n...@ti.com

IS_ERR_VALUE makes sense only *if* there could be valid values in
negative error range. But in the cases that we do use it, there is no
such case. Just remove the same.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/irqchip/irq-crossbar.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index a39cb31..88fbe0f 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -102,15 +102,15 @@ static int crossbar_domain_xlate(struct irq_domain *d,
 unsigned long *out_hwirq,
 unsigned int *out_type)
 {
-   unsigned long ret;
+   int ret;
 
ret = get_prev_map_irq(intspec[1]);
-   if (!IS_ERR_VALUE(ret))
+   if (ret = 0)
goto found;
 
ret = allocate_free_irq(intspec[1]);
 
-   if (IS_ERR_VALUE(ret))
+   if (ret  0)
return ret;
 
 found:
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/2] arm: dts: dra7: add crossbar dt support

[Sricharan R]

This series introduces DT support for crossbar device and
changes dra7 peripherals to use crossbar number instead of irq.

This depends on below driver fixes and cleanup series.
http://marc.info/?l=linux-omapm=140376708127157w=2

[V2] Rebased on 3.15 mainline.
[V3] Added ti,irqs-skip property and ti,irqs-safe-map property to
 crossbar dt node.
[V4] Introduced macros MAX_SOURCES and DIRECT_IRQ

R Sricharan (2):
  arm: dts: dra7: add routable-irqs property for gic node
  arm: dts: dra7: add crossbar device binding

 arch/arm/boot/dts/dra7.dtsi |  139 +--
 1 file changed, 81 insertions(+), 58 deletions(-)

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

[PATCH V4 2/2] arm: dts: dra7: add crossbar device binding

[Sricharan R]

From: R Sricharan r.sricha...@ti.com

There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. The crossbar device is used to map
a peripheral input to a free mpu's interrupt controller line.

Here, adding a new crossbar device node and replacing all the peripheral
interrupt numbers with its fixed crossbar input lines.

Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Cc: Benoit Cousson bcous...@baylibre.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
 arch/arm/boot/dts/dra7.dtsi |  138 +--
 1 file changed, 80 insertions(+), 58 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1cf4ee1..961be6b 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -12,6 +12,9 @@
 
 #include skeleton.dtsi
 
+#define MAX_SOURCES 400
+#define DIRECT_IRQ(irq) (MAX_SOURCES + irq)
+
 / {
#address-cells = 1;
#size-cells = 1;
@@ -80,8 +83,8 @@
ti,hwmods = l3_main_1, l3_main_2;
reg = 0x4400 0x100,
  0x4500 0x1000;
-   interrupts = GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH,
-GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
+   interrupts = GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI DIRECT_IRQ(10) IRQ_TYPE_LEVEL_HIGH;
 
prm: prm@4ae06000 {
compatible = ti,dra7-prm;
@@ -156,10 +159,10 @@
sdma: dma-controller@4a056000 {
compatible = ti,omap4430-sdma;
reg = 0x4a056000 0x1000;
-   interrupts = GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH,
-GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH,
-GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH,
-GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH;
+   interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
#dma-cells = 1;
#dma-channels = 32;
#dma-requests = 127;
@@ -168,7 +171,7 @@
gpio1: gpio@4ae1 {
compatible = ti,omap4-gpio;
reg = 0x4ae1 0x200;
-   interrupts = GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH;
+   interrupts = GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio1;
gpio-controller;
#gpio-cells = 2;
@@ -179,7 +182,7 @@
gpio2: gpio@48055000 {
compatible = ti,omap4-gpio;
reg = 0x48055000 0x200;
-   interrupts = GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH;
+   interrupts = GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio2;
gpio-controller;
#gpio-cells = 2;
@@ -190,7 +193,7 @@
gpio3: gpio@48057000 {
compatible = ti,omap4-gpio;
reg = 0x48057000 0x200;
-   interrupts = GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH;
+   interrupts = GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio3;
gpio-controller;
#gpio-cells = 2;
@@ -201,7 +204,7 @@
gpio4: gpio@48059000 {
compatible = ti,omap4-gpio;
reg = 0x48059000 0x200;
-   interrupts = GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH;
+   interrupts = GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio4;
gpio-controller;
#gpio-cells = 2;
@@ -212,7 +215,7 @@
gpio5: gpio@4805b000 {
compatible = ti,omap4-gpio;
reg = 0x4805b000 0x200;
-   interrupts = GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH;
+   interrupts = GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio5;
gpio-controller;
#gpio-cells = 2;
@@ -223,7 +226,7 @@
gpio6: gpio@4805d000 {
compatible = ti,omap4-gpio;
reg = 0x4805d000 0x200;
-   interrupts = GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH;
+   interrupts = 

[PATCH V4 1/2] arm: dts: dra7: add routable-irqs property for gic node

[Sricharan R]

From: R Sricharan r.sricha...@ti.com

There is a IRQ crossbar device in the soc, which maps the
irq requests from the peripherals to the mpu interrupt
controller's inputs. The gic provides the support for such
IPs in the form of routable-irqs. So adding the property
here to gic node.

Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Cc: Benoit Cousson bcous...@baylibre.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
 arch/arm/boot/dts/dra7.dtsi |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index c29945e..1cf4ee1 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -45,6 +45,7 @@
compatible = arm,cortex-a15-gic;
interrupt-controller;
#interrupt-cells = 3;
+   arm,routable-irqs = 192;
reg = 0x48211000 0x1000,
  0x48212000 0x1000,
  0x48214000 0x2000,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap 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: DRA7-evm: Enable SATA PHY and USB PHY power supplies

[Tony Lindgren]

* Nishanth Menon n...@ti.com [140625 15:29]:
 On 06/25/2014 07:56 AM, Roger Quadros wrote:
  The SATA and USB PHYs need the 1.8V and 3.3V supplies.
  The PHY drivers/framework don't yet support regulator
  supply so we have to keep these regulators always-on till
  then.
  
  Signed-off-by: Roger Quadros rog...@ti.com
  ---
   arch/arm/boot/dts/dra7-evm.dts | 2 ++
   1 file changed, 2 insertions(+)
  
  diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
  index 4adc280..99a1f79 100644
  --- a/arch/arm/boot/dts/dra7-evm.dts
  +++ b/arch/arm/boot/dts/dra7-evm.dts
  @@ -241,6 +241,7 @@
  regulator-min-microvolt = 180;
  regulator-max-microvolt = 180;
  regulator-boot-on;
  +   regulator-always-on;
  };
   
  ldo9_reg: ldo9 {
  @@ -266,6 +267,7 @@
  regulator-min-microvolt = 330;
  regulator-max-microvolt = 330;
  regulator-boot-on;
  +   regulator-always-on;
  };
  };
  };
  
 
 Why not fix phy driver/framework as needed? the trouble is people
 always forget to remove always-on... who actually audits old logs and
 fixes stuff back up?

Yes I agree let's not play with the regulator-always-on unless
absolutely necessary.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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 00/16] irqchip: crossbar: Driver fixes

[Tony Lindgren]

* Sricharan R r.sricha...@ti.com [140626 00:14]:
 This series does some cleanups, fixes for handling two interrupts
 getting mapped twice to same crossbar and provides support for
 hardwired IRQ and crossbar definitions.
 
 On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10,
 131, 132, 133 are direct wired to hardware blocks bypassing
 crossbar. This quirky implementation is *NOT* supposed to be the
 expectation of crossbar hardware usage. This series adds support
 to represent such hard-wired irqs through DT and avoid generic
 allocation/programming of crossbar in the driver.
 
 This way of supporting hard-wired irqs was a result of
 the below discussions.
 http://www.spinics.net/lists/arm-kernel/msg329946.html
 
 Based on 3.16 rc2 mainline.

Jason, once these patches look OK for merging, can you please
set them up into an immutable branch so I too can merge them in?

The immutable branch is needed so I can eventually apply
the related .dts changes to enable the crossbar interrupts.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/2] arm: dts: dra7: add crossbar device binding

[Tony Lindgren]

* Sricharan R r.sricha...@ti.com [140626 00:29]:
 From: R Sricharan r.sricha...@ti.com
 
 There is a IRQ crossbar device in the soc, which
 maps the irq requests from the peripherals to the
 mpu interrupt controller's inputs. The Peripheral irq
 requests are connected to only one crossbar
 input and the output of the crossbar is connected to only one
 controller's input line. The crossbar device is used to map
 a peripheral input to a free mpu's interrupt controller line.
 
 Here, adding a new crossbar device node and replacing all the peripheral
 interrupt numbers with its fixed crossbar input lines.

I think these two patches need to be a single patch to avoid
breaking booting for git bisect inbetween these patches?

Regards,

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

Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards

[Tony Lindgren]

* Gupta, Pekon pe...@ti.com [140618 01:52]:
 Hi,
 
 From: Jason Kridner [mailto:jkrid...@gmail.com]
 On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon pe...@ti.com wrote:
 From: Jason Kridner
 [...]
  * The devicetree sources, including the primary boot .dts files, will
  eventually be removed from the kernel source tree. I'm not too sure if
  and when it'll really happen, but starting up a project to maintain
  the definitive beagleboard.org board devicetree files outside the
  kernel seems to make sense. Given the interdependency of the boot .dtb
  and the overlay .dtbo files, combining them into a single repository
  where every distribution can pick them up seems like a natural and
  obvious choice. There are of course some dependencies on kernel
  versions, but I believe most of those have settled out by now and we
  should be OK moving forward.
 
  +1
  Yes, moving cape DTS out of kernel tree should help developers.
  There are quite a few cape patches floating in mail-lists, but as cape
  DTS is still not accepted in mainline so they get lost and forgotten.
  So one place for collecting all this is a good idea.
 
 
  However, somehow the universal I/O DTS looked seemed complicated:
  (1)
  All capes work standalone, but due to share pin-mux some cape
  combinations cannot be used simultaneously. But most users of
  BeagleBone are already well-versed with DT and kernel infrastructure,
  so they need not be spoon fed to get a out-of-box working solution
  for each combination. If there is proper documentation is available
  about compatibility of capes with each other, then users will figure
  out themselves.
 
 I think you have too much confidence in users. If this doesn't hurt
 power users, then why is it bad have an option to spoon feed? This
 doesn't prevent anyone with knowledge of DT from doing their own
 thing.
 
 Fair enough.
 But plz give a try to u-boot alternative below. It works at my end.
 
 
  (2)
  Also, there was a talk of enabling and disabling DT fragments via u-boot.
  That should also be explored instead of complicating cape DTS.
 
 Link? Relevance?
 
 we can modify DT from u-boot itself [1].
 Example:  MMC2 pin-mux conflicts with NAND and NOR capes.
 But using following sequence of commands, you can modify DTB via
 u-boot and make NAND cape work _without_any_hack_ in patch [2].
 
 /* load DTB */
 u-boot tftp 0x8100 am335x-boneblack.dtb
 u-boot fdt addr 0x8100
 /* disable MMC2 node */
 u-boot fdt list /ocp/mmc@481d8000
 u-boot fdt set  /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
 u-boot fdt list /ocp/mmc@481d8000 status
 /* enable GPMC node */
 u-boot fdt list /ocp/gpmc
 u-boot fdt set  /ocp/gpmc status \o\k\a\y
 u-boot fdt list /ocp/gpmc status
 /* enable ELM node */
 u-boot fdt list /ocp/elm
 u-boot fdt set  /ocp/elm status \o\k\a\y
 u-boot fdt list /ocp/elm status
 /* boot uImage */
 tftp 0x8200 uImage
 bootm 0x8200 - 0x8100
 
 Note: fdt set command does not accept string literals
 as binding values, it internally converts them to string, so
 escape sequenced characters were used here..
 okay == \o\k\a\y
 disabled == \d\i\s\a\b\l\e\d
 
 
 Hope above solves the pre-requisite because of which 'Tony Lindgren 
 t...@atomide.com'
 was unable to accept cape related DTS into his tree [3]

Yes. If the capes are disabled by default we can have at
least some of them included in the mainline kernel and
enabled by the bootloader as needed. I'd like to hear back
from the u-boot people too on this approach naturally.

And some things we still cannot merge if they overlap for
GPMC bindings for example. So we have to carefully check
the generated .dtb file with dtc -I dtb -O dts.

Regards,

Tony
 
 [1] http://www.denx.de/wiki/view/DULG/UBootCmdFDT
 [2] http://www.spinics.net/lists/linux-omap/msg107307.html
 [3] http://www.spinics.net/lists/linux-omap/msg107354.html
 
 
 with regards, pekon
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/2] arm: dts: dra7: add crossbar device binding

[Sricharan R]

Hi Tony,

On Thursday 26 June 2014 01:14 PM, Tony Lindgren wrote:
 * Sricharan R r.sricha...@ti.com [140626 00:29]:
 From: R Sricharan r.sricha...@ti.com

 There is a IRQ crossbar device in the soc, which
 maps the irq requests from the peripherals to the
 mpu interrupt controller's inputs. The Peripheral irq
 requests are connected to only one crossbar
 input and the output of the crossbar is connected to only one
 controller's input line. The crossbar device is used to map
 a peripheral input to a free mpu's interrupt controller line.

 Here, adding a new crossbar device node and replacing all the peripheral
 interrupt numbers with its fixed crossbar input lines.
 
 I think these two patches need to be a single patch to avoid
 breaking booting for git bisect inbetween these patches?
  This does not cause booting issues. irq_desc gets allocated linearly,
   but that does not create boot issues.

Regards,
 Sricharan
  

--
To unsubscribe from this list: send the line unsubscribe linux-omap 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: DRA7-evm: Enable SATA PHY and USB PHY power supplies

[Roger Quadros]

On 06/26/2014 10:31 AM, Tony Lindgren wrote:
 * Nishanth Menon n...@ti.com [140625 15:29]:
 On 06/25/2014 07:56 AM, Roger Quadros wrote:
 The SATA and USB PHYs need the 1.8V and 3.3V supplies.
 The PHY drivers/framework don't yet support regulator
 supply so we have to keep these regulators always-on till
 then.

 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  arch/arm/boot/dts/dra7-evm.dts | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
 index 4adc280..99a1f79 100644
 --- a/arch/arm/boot/dts/dra7-evm.dts
 +++ b/arch/arm/boot/dts/dra7-evm.dts
 @@ -241,6 +241,7 @@
 regulator-min-microvolt = 180;
 regulator-max-microvolt = 180;
 regulator-boot-on;
 +   regulator-always-on;
 };
  
 ldo9_reg: ldo9 {
 @@ -266,6 +267,7 @@
 regulator-min-microvolt = 330;
 regulator-max-microvolt = 330;
 regulator-boot-on;
 +   regulator-always-on;
 };
 };
 };


 Why not fix phy driver/framework as needed? the trouble is people
 always forget to remove always-on... who actually audits old logs and
 fixes stuff back up?
 
 Yes I agree let's not play with the regulator-always-on unless
 absolutely necessary.
 
Agreed. PHY framework must deal with this. Till then USB, SATA and most likely 
PCIe as well will not work on DRA7-evm.

cheers,
-roger

--
To unsubscribe from this list: send the line unsubscribe linux-omap 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] ARM: DRA7: hwmod: Add OCP2SCP3 module

[Roger Quadros]

Kishon,

On 06/25/2014 08:46 PM, Kishon Vijay Abraham I wrote:
 
 On Wednesday 18 June 2014 05:46 PM, Roger Quadros wrote:
 This module is needed for the SATA and PCIe PHYs.

 Signed-off-by: Roger Quadros rog...@ti.com
 Tested-by: Roger Quadros rog...@ti.com
 
 I used this patch for testing PCIe.
 Tested-by: Kishon Vijay Abraham I kis...@ti.com

There is a v2 of this patch in reply to the original patch. Could you please 
give your Tested-by tag on that one?
Thanks.

cheers,
-roger

 ---
  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 25 +
  1 file changed, 25 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
 index 20b4398..cedef6b 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
 @@ -1215,6 +1215,30 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
  },
  };
  
 +/* ocp2scp3 */
 +static struct omap_hwmod dra7xx_ocp2scp3_hwmod;
 +
 +/* l4_cfg - ocp2scp3 */
 +static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = {
 +.master = dra7xx_l4_cfg_hwmod,
 +.slave  = dra7xx_ocp2scp3_hwmod,
 +.clk= l4_root_clk_div,
 +.user   = OCP_USER_MPU | OCP_USER_SDMA,
 +};
 +
 +static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
 +.name   = ocp2scp3,
 +.class  = dra7xx_ocp2scp_hwmod_class,
 +.clkdm_name = l3init_clkdm,
 +.prcm = {
 +.omap4 = {
 +.clkctrl_offs = 
 DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
 +.context_offs = 
 DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
 +.modulemode   = MODULEMODE_HWCTRL,
 +},
 +},
 +};
 +
  /*
   * 'qspi' class
   *
 @@ -2672,6 +2696,7 @@ static struct omap_hwmod_ocp_if 
 *dra7xx_hwmod_ocp_ifs[] __initdata = {
  dra7xx_l4_per1__mmc4,
  dra7xx_l4_cfg__mpu,
  dra7xx_l4_cfg__ocp2scp1,
 +dra7xx_l4_cfg__ocp2scp3,
  dra7xx_l3_main_1__qspi,
  dra7xx_l4_cfg__sata,
  dra7xx_l4_cfg__smartreflex_core,


--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/2] arm: dts: dra7: add crossbar device binding

[Tony Lindgren]

* Sricharan R r.sricha...@ti.com [140626 01:36]:
 Hi Tony,
 
 On Thursday 26 June 2014 01:14 PM, Tony Lindgren wrote:
  * Sricharan R r.sricha...@ti.com [140626 00:29]:
  From: R Sricharan r.sricha...@ti.com
 
  There is a IRQ crossbar device in the soc, which
  maps the irq requests from the peripherals to the
  mpu interrupt controller's inputs. The Peripheral irq
  requests are connected to only one crossbar
  input and the output of the crossbar is connected to only one
  controller's input line. The crossbar device is used to map
  a peripheral input to a free mpu's interrupt controller line.
 
  Here, adding a new crossbar device node and replacing all the peripheral
  interrupt numbers with its fixed crossbar input lines.
  
  I think these two patches need to be a single patch to avoid
  breaking booting for git bisect inbetween these patches?
   This does not cause booting issues. irq_desc gets allocated linearly,
but that does not create boot issues.

OK

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/7] mailbox/omap: remove OMAP1 mailbox driver

[Tony Lindgren]

* Suman Anna s-a...@ti.com [140624 17:45]:
 There are no existing users for OMAP1 mailbox driver
 in kernel. Commit ab6f775 Removing dead OMAP_DSP
 has cleaned up all the dead code related to the only
 possible user, including the creation of the mailbox
 platform device.
 
 Remove this stale driver so that the OMAP mailbox
 driver can be simplified and streamlined better for
 converting to mailbox framework.
 
 Cc: Aaro Koskinen aaro.koski...@iki.fi
 Signed-off-by: Suman Anna s-a...@ti.com

For the omap1_defconfig change:

Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Tony Lindgren]

* Pekon Gupta pe...@ti.com [140624 05:26]:
 +
 +gpmc {
 + ranges = 0 0 0 0x0100;/* address range = 16MB (minimum GPMC 
 partition) */
 + nand@0,0 {
 + status = disabled;
 + reg = 0 0 4;  /* device IO registers */

Hmm so what about other capes potentially also using GPMC CS0?

Can you please do a check with two .dtsi files trying to use
GPMC CS0 and see what the produced .dtb file looks like after
decompiling it with dtc?

I'd assume the 16MB GPMC partition will be just fine for many
devices and can be also be larger if NOR needs it so maybe it
can be handled for almost all the cases.

The names for devices must be unique though to avoid them
getting merged. And I don't know if gpmc.c skips disabled devices
properly.

Regards,

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

Re: [PATCH v3 6/7] OMAPDSS: DPI: Add support for multiple instances

[Tomi Valkeinen]

On 04/06/14 09:41, Archit Taneja wrote:
 Register DPI outputs, and assign the port_num to them as specified by the
 'reg' property in the DPI ports in DT.
 
 To support multiple DPI instances, dpi_get_channel needs to take the DPI
 instance's reg-id to get the corresponding channel. Make it take this
 argument.We just pass 0 in the non-DT path, since we don't support multiple
 instances in the non-DT case.
 
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/video/fbdev/omap2/dss/dpi.c | 26 +++---
  1 file changed, 23 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/video/fbdev/omap2/dss/dpi.c 
 b/drivers/video/fbdev/omap2/dss/dpi.c
 index b579022..3e204a8 100644
 --- a/drivers/video/fbdev/omap2/dss/dpi.c
 +++ b/drivers/video/fbdev/omap2/dss/dpi.c
 @@ -616,7 +616,7 @@ static void dpi_init_pll(struct dpi_data *dpi)
   * the channel in some more dynamic manner, or get the channel as a user
   * parameter.
   */
 -static enum omap_channel dpi_get_channel(void)
 +static enum omap_channel dpi_get_channel(int reg)
  {
   switch (omapdss_get_version()) {
   case OMAPDSS_VER_OMAP24xx:
 @@ -710,7 +710,7 @@ static void dpi_init_output(struct platform_device *pdev)
   out-id = OMAP_DSS_OUTPUT_DPI;
   out-output_type = OMAP_DISPLAY_TYPE_DPI;
   out-name = dpi.0;
 - out-dispc_channel = dpi_get_channel();
 + out-dispc_channel = dpi_get_channel(0);
   out-ops.dpi = dpi_ops;
   out-owner = THIS_MODULE;
  
 @@ -730,11 +730,31 @@ static void dpi_init_output_port(struct platform_device 
 *pdev,
  {
   struct dpi_data *dpi = port-data;
   struct omap_dss_device *out = dpi-output;
 + int r;
 + u32 reg;
 +
 + r = of_property_read_u32(port, reg, reg);
 + if (r)
 + reg = 0;
 +
 + switch (reg) {
 + case 2:
 + out-name = dpi.2;
 + break;
 + case 1:
 + out-name = dpi.1;
 + break;
 + case 0:
 + default:
 + out-name = dpi.0;
 + break;
 + }

I don't think it makes sense to use reg word anywhere else than when
getting the property from the DT data. What we need here is port number.
That port number is just stored in reg property in the DT data. So
rather do:

of_property_read_u32(port, reg, port_num);

and use the port_num (or such) everywhere, including the subject of the
next patch.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 4/7] OMAPDSS: DSS: init dss ports cleanly

[Tomi Valkeinen]

On 04/06/14 09:41, Archit Taneja wrote:
 The init/uninit port functions are used to set up the DPI and SDI outputs 
 under
 the dss platform device. A 'reg' property is used to determine whether the 
 node
 is DPI or SDI for OMAP34xx DSS revision. For other DSS revisions, only DPI
 output exists.
 
 For multiple DPI output instances(introduced in DRA7xx DSS), we would use the
 'reg' property in dts to specify the DPI output instance.
 
 The current functions work fine if there is only one DPI output instance in
 DSS. For multiple DPI instances, it would get complicated to figure out 
 whether
 'reg' is used to specify whether the output is SDI, or another DPI instance.
 
 We create a list of port types supported for each DSS rev, with the index of 
 the
 port in the list matching the reg id. This allows us to have a more generic 
 way
 to init/uninit ports within DSS, and support multiple DPI ports.
 
 Also, make the uninit_port functions iterative since we will have multiple DPI
 ports to uninit in the future.
 
 Signed-off-by: Archit Taneja arc...@ti.com
 ---

 +#ifdef CONFIG_OMAP2_DSS_DPI
  int dpi_init_port(struct platform_device *pdev, struct device_node *port) 
 __init;
  void dpi_uninit_port(struct device_node *port) __exit;
 +#else
 +static inline int __init dpi_init_port(struct platform_device *pdev,
 + struct device_node *port)
 +{
 + WARN(%s: DPI not compiled in\n, __func__);
 + return 0;
 +}

If I'm not mistaken, this, and the SDI one, will be called if the DT
data contains DPI/SDI port, but the DPI/SDI support is not compiled in.
I don't think that's a reason to give a warning, there's nothing wrong
with leaving the DPI/SDI support out.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 0/7] OMAPDSS: Support multiple DPI instances

[Tomi Valkeinen]

On 04/06/14 09:40, Archit Taneja wrote:
 DSS on DRA7x has 3 DPI outputs. In order to get them to work. We need to make
 the DPI driver support multiple DPI instances. We also need to tweak the
 DT parsing done to match an encoder/connector/panel driver to find the
 corresponding omapdss output. This series tries to achieve the above 2 tasks.
 
 Changes in v3:
 
 - Make indexes in port lists not depend on DPI and SDI CONFIGs.
 - Cleaner code in dss_init_ports/uninit_ports.
 - Split up the patch which creates multi DPI instances.
 - Switch to a simpler way of extracting DPI driver data from dssdev.
 - Change some of the dss-of fucntions, such that
   omapdss_of_find_source_for_first_ep is simplified.
 
 Archit Taneja (7):
   OMAPDSS: DPI: Use DPI driver data
   OMAPDSS: DPI: Allocate driver data
   OMAPDSS: DPI: Store dpi_data pointer in the DT port's data
   OMAPDSS: DSS: init dss ports cleanly
   OMAPDSS: DT: Get source endpoint by matching reg-id
   OMAPDSS: DPI: Add support for multiple instances
   omapdss: DSS: add reg-id param to dpi_select_source
 
  .../fbdev/omap2/displays-new/encoder-tfp410.c  |   1 +
  .../fbdev/omap2/displays-new/encoder-tpd12s015.c   |   1 +
  drivers/video/fbdev/omap2/dss/dpi.c| 259 
 ++---
  drivers/video/fbdev/omap2/dss/dss-of.c |  58 +++--
  drivers/video/fbdev/omap2/dss/dss.c| 108 +++--
  drivers/video/fbdev/omap2/dss/dss.h|  34 ++-
  drivers/video/fbdev/omap2/dss/output.c |  19 +-
  drivers/video/fbdev/omap2/dss/sdi.c|   2 +-
  include/video/omapdss.h|   5 +-
  9 files changed, 354 insertions(+), 133 deletions(-)

Other than the couple minor comments I had, the series looks good.

 Tomi





signature.asc
Description: OpenPGP digital signature

Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards

[Tom Rini]

On 06/26/2014 03:50 AM, Tony Lindgren wrote:
 * Gupta, Pekon pe...@ti.com [140618 01:52]:
 Hi,

 From: Jason Kridner [mailto:jkrid...@gmail.com]
 On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon pe...@ti.com wrote:
 From: Jason Kridner
 [...]
 * The devicetree sources, including the primary boot .dts files, will
 eventually be removed from the kernel source tree. I'm not too sure if
 and when it'll really happen, but starting up a project to maintain
 the definitive beagleboard.org board devicetree files outside the
 kernel seems to make sense. Given the interdependency of the boot .dtb
 and the overlay .dtbo files, combining them into a single repository
 where every distribution can pick them up seems like a natural and
 obvious choice. There are of course some dependencies on kernel
 versions, but I believe most of those have settled out by now and we
 should be OK moving forward.

 +1
 Yes, moving cape DTS out of kernel tree should help developers.
 There are quite a few cape patches floating in mail-lists, but as cape
 DTS is still not accepted in mainline so they get lost and forgotten.
 So one place for collecting all this is a good idea.


 However, somehow the universal I/O DTS looked seemed complicated:
 (1)
 All capes work standalone, but due to share pin-mux some cape
 combinations cannot be used simultaneously. But most users of
 BeagleBone are already well-versed with DT and kernel infrastructure,
 so they need not be spoon fed to get a out-of-box working solution
 for each combination. If there is proper documentation is available
 about compatibility of capes with each other, then users will figure
 out themselves.

 I think you have too much confidence in users. If this doesn't hurt
 power users, then why is it bad have an option to spoon feed? This
 doesn't prevent anyone with knowledge of DT from doing their own
 thing.

 Fair enough.
 But plz give a try to u-boot alternative below. It works at my end.


 (2)
 Also, there was a talk of enabling and disabling DT fragments via u-boot.
 That should also be explored instead of complicating cape DTS.

 Link? Relevance?

 we can modify DT from u-boot itself [1].
 Example:  MMC2 pin-mux conflicts with NAND and NOR capes.
 But using following sequence of commands, you can modify DTB via
 u-boot and make NAND cape work _without_any_hack_ in patch [2].

 /* load DTB */
 u-boot tftp 0x8100 am335x-boneblack.dtb
 u-boot fdt addr 0x8100
 /* disable MMC2 node */
 u-boot fdt list /ocp/mmc@481d8000
 u-boot fdt set  /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
 u-boot fdt list /ocp/mmc@481d8000 status
 /* enable GPMC node */
 u-boot fdt list /ocp/gpmc
 u-boot fdt set  /ocp/gpmc status \o\k\a\y
 u-boot fdt list /ocp/gpmc status
 /* enable ELM node */
 u-boot fdt list /ocp/elm
 u-boot fdt set  /ocp/elm status \o\k\a\y
 u-boot fdt list /ocp/elm status
 /* boot uImage */
 tftp 0x8200 uImage
 bootm 0x8200 - 0x8100

 Note: fdt set command does not accept string literals
 as binding values, it internally converts them to string, so
 escape sequenced characters were used here..
 okay == \o\k\a\y
 disabled == \d\i\s\a\b\l\e\d


 Hope above solves the pre-requisite because of which 'Tony Lindgren 
 t...@atomide.com'
 was unable to accept cape related DTS into his tree [3]
 
 Yes. If the capes are disabled by default we can have at
 least some of them included in the mainline kernel and
 enabled by the bootloader as needed. I'd like to hear back
 from the u-boot people too on this approach naturally.
 
 And some things we still cannot merge if they overlap for
 GPMC bindings for example. So we have to carefully check
 the generated .dtb file with dtc -I dtb -O dts.

This sounds really problematic to me from an end-user horror point of
view.  And fortunately 3.17 is going to have some level of overlay
support so we can set this problem aside (and even treat the am335x gp
evm profileN trees as overlays too).

-- 
Tom
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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: DRA7-evm: Enable SATA PHY and USB PHY power supplies

[Roger Quadros]

+Tero

On 06/26/2014 12:36 PM, Roger Quadros wrote:
 On 06/26/2014 10:31 AM, Tony Lindgren wrote:
 * Nishanth Menon n...@ti.com [140625 15:29]:
 On 06/25/2014 07:56 AM, Roger Quadros wrote:
 The SATA and USB PHYs need the 1.8V and 3.3V supplies.
 The PHY drivers/framework don't yet support regulator
 supply so we have to keep these regulators always-on till
 then.

 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  arch/arm/boot/dts/dra7-evm.dts | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/arch/arm/boot/dts/dra7-evm.dts 
 b/arch/arm/boot/dts/dra7-evm.dts
 index 4adc280..99a1f79 100644
 --- a/arch/arm/boot/dts/dra7-evm.dts
 +++ b/arch/arm/boot/dts/dra7-evm.dts
 @@ -241,6 +241,7 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-boot-on;
 +  regulator-always-on;
};
  
ldo9_reg: ldo9 {
 @@ -266,6 +267,7 @@
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
regulator-boot-on;
 +  regulator-always-on;
};
};
};


 Why not fix phy driver/framework as needed? the trouble is people
 always forget to remove always-on... who actually audits old logs and
 fixes stuff back up?

 Yes I agree let's not play with the regulator-always-on unless
 absolutely necessary.

 Agreed. PHY framework must deal with this. Till then USB, SATA and most 
 likely PCIe as well will not work on DRA7-evm.
 

I tried the below patch to enable the relevant regulators in the PHY drivers 
but still couldn't manage to get USB to work. The same 1.8V regulator is used 
to supply 3 pins
-vdda_usb1: DPLL_USB and HS_USB1 analog supply
-vdda_usb2: HS_USB2 analog supply
-vdda_usb3: DPLL_USB_OTG_SS and USB3.0 Rx/Tx analog supply

It seems that the regulator auto disable kicks in before the phy driver enables 
the regulator thus causing some kind of malfunction. I'm not sure whether this 
is due to DPLL_USB supply glitch or HS_USB1 analog supply glitch.

In any case, the DPLL_USB (clock driver?) needs to enable the 1.8V regulator in 
addition to the HS_USB PHY driver to prevent this supply glitch.

Tero, any suggestions about this? If we are not concerned about disabling 
DPLL_USB anytime then the regulator might just as well be always-on. 
Alternatively can we place a regulator_get(), regulator_enable() in 
drivers/clk/ti/dpll.c?

cheers,
-roger
---

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4adc280..23379ab 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -495,3 +495,11 @@
};
};
 };
+
+usb2_phy1 {
+   vdda3v3-supply = ldousb_reg;
+};
+
+usb3_phy1 {
+   vdda1v8-supply = ldo3_reg;
+};
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 7007c11..bb1a768 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -30,6 +30,7 @@
 #include linux/phy/omap_control_phy.h
 #include linux/phy/phy.h
 #include linux/of_platform.h
+#include linux/regulator/consumer.h
 
 #define USB2PHY_DISCON_BYP_LATCH (1  31)
 #define USB2PHY_ANA_CONFIG1 0x4c
@@ -107,6 +108,18 @@ static int omap_usb_power_off(struct phy *x)
 
omap_control_phy_power(phy-control_dev, 0);
 
+   if (phy-pwr) {
+   int ret;
+
+   ret = regulator_disable(phy-pwr);
+   if (ret) {
+   dev_err(phy-dev, failed to disable regulator\n);
+   return ret;
+   } else {
+   dev_info(phy-dev, disabled regulator\n);
+   }
+   }
+
return 0;
 }
 
@@ -114,6 +127,18 @@ static int omap_usb_power_on(struct phy *x)
 {
struct omap_usb *phy = phy_get_drvdata(x);
 
+   if (phy-pwr) {
+   int ret;
+
+   ret = regulator_enable(phy-pwr);
+   if (ret) {
+   dev_err(phy-dev, failed to enable regulator\n);
+   return ret;
+   } else {
+   dev_info(phy-dev, enabled regulator\n);
+   }
+   }
+
omap_control_phy_power(phy-control_dev, 1);
 
return 0;
@@ -253,6 +278,14 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-control_dev = control_pdev-dev;
omap_control_phy_power(phy-control_dev, 0);
 
+   /* phy-supply */
+   phy-pwr = devm_regulator_get_optional(phy-dev, vdda3v3);
+   if (IS_ERR(phy-pwr)) {
+   if (PTR_ERR(phy-pwr) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   phy-pwr = NULL;
+   }
+
otg-set_host   = omap_usb_set_host;

[PATCH] arm: mach-omap2: gpmc: ignore non-available nodes

[Guido Martínez]

Currently, child nodes of the gpmc node are iterated and probed
regardless of their 'status' property. This means adding 'status =
disabled;' has no effect.

This patch changes the iteration to only probe nodes marked as
available.

Signed-off-by: Guido Martínez gu...@vanguardiasur.com.ar
---
 arch/arm/mach-omap2/gpmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2c0c281..8bc1338 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1615,7 +1615,7 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
 
-   for_each_child_of_node(pdev-dev.of_node, child) {
+   for_each_available_child_of_node(pdev-dev.of_node, child) {
 
if (!child-name)
continue;
-- 
2.0.0

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

Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Guido Martínez]

Hi Tony, Pekon

On Thu, Jun 26, 2014 at 03:40:44AM -0700, Tony Lindgren wrote:
 * Pekon Gupta pe...@ti.com [140624 05:26]:
  +
  +gpmc {
  +   ranges = 0 0 0 0x0100;/* address range = 16MB (minimum GPMC 
  partition) */
  +   nand@0,0 {
  +   status = disabled;
  +   reg = 0 0 4;  /* device IO registers */
 
 Hmm so what about other capes potentially also using GPMC CS0?
 
 Can you please do a check with two .dtsi files trying to use
 GPMC CS0 and see what the produced .dtb file looks like after
 decompiling it with dtc?
 
 I'd assume the 16MB GPMC partition will be just fine for many
 devices and can be also be larger if NOR needs it so maybe it
 can be handled for almost all the cases.
 
 The names for devices must be unique though to avoid them
 getting merged. And I don't know if gpmc.c skips disabled devices
 properly.
It doesn't. I've just sent a patch for it.

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html

Regards,
Guido

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

-- 
Guido Martínez, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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: DRA7-evm: Enable SATA PHY and USB PHY power supplies

[Tero Kristo]

On 06/26/2014 05:22 PM, Roger Quadros wrote:

+Tero

On 06/26/2014 12:36 PM, Roger Quadros wrote:

On 06/26/2014 10:31 AM, Tony Lindgren wrote:

* Nishanth Menon n...@ti.com [140625 15:29]:

On 06/25/2014 07:56 AM, Roger Quadros wrote:

The SATA and USB PHYs need the 1.8V and 3.3V supplies.
The PHY drivers/framework don't yet support regulator
supply so we have to keep these regulators always-on till
then.

Signed-off-by: Roger Quadros rog...@ti.com
---
  arch/arm/boot/dts/dra7-evm.dts | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4adc280..99a1f79 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -241,6 +241,7 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-boot-on;
+   regulator-always-on;
};

ldo9_reg: ldo9 {
@@ -266,6 +267,7 @@
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
regulator-boot-on;
+   regulator-always-on;
};
};
};



Why not fix phy driver/framework as needed? the trouble is people
always forget to remove always-on... who actually audits old logs and
fixes stuff back up?


Yes I agree let's not play with the regulator-always-on unless
absolutely necessary.


Agreed. PHY framework must deal with this. Till then USB, SATA and most likely 
PCIe as well will not work on DRA7-evm.



I tried the below patch to enable the relevant regulators in the PHY drivers 
but still couldn't manage to get USB to work. The same 1.8V regulator is used 
to supply 3 pins
-vdda_usb1: DPLL_USB and HS_USB1 analog supply
-vdda_usb2: HS_USB2 analog supply
-vdda_usb3: DPLL_USB_OTG_SS and USB3.0 Rx/Tx analog supply

It seems that the regulator auto disable kicks in before the phy driver enables 
the regulator thus causing some kind of malfunction. I'm not sure whether this 
is due to DPLL_USB supply glitch or HS_USB1 analog supply glitch.

In any case, the DPLL_USB (clock driver?) needs to enable the 1.8V regulator in 
addition to the HS_USB PHY driver to prevent this supply glitch.

Tero, any suggestions about this? If we are not concerned about disabling 
DPLL_USB anytime then the regulator might just as well be always-on. 
Alternatively can we place a regulator_get(), regulator_enable() in 
drivers/clk/ti/dpll.c?


I believe dpll_usb needs to go down for the core to idle. Also, we are 
working on getting suspend-resume working on this platform, so having 
the regulator always on is a no-no.


Also, I am heavily against adding regulator tweaks within the clock 
driver, there needs to be another way.


-Tero



cheers,
-roger
---

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4adc280..23379ab 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -495,3 +495,11 @@
};
};
  };
+
+usb2_phy1 {
+   vdda3v3-supply = ldousb_reg;
+};
+
+usb3_phy1 {
+   vdda1v8-supply = ldo3_reg;
+};
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 7007c11..bb1a768 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -30,6 +30,7 @@
  #include linux/phy/omap_control_phy.h
  #include linux/phy/phy.h
  #include linux/of_platform.h
+#include linux/regulator/consumer.h

  #define USB2PHY_DISCON_BYP_LATCH (1  31)
  #define USB2PHY_ANA_CONFIG1 0x4c
@@ -107,6 +108,18 @@ static int omap_usb_power_off(struct phy *x)

omap_control_phy_power(phy-control_dev, 0);

+   if (phy-pwr) {
+   int ret;
+
+   ret = regulator_disable(phy-pwr);
+   if (ret) {
+   dev_err(phy-dev, failed to disable regulator\n);
+   return ret;
+   } else {
+   dev_info(phy-dev, disabled regulator\n);
+   }
+   }
+
return 0;
  }

@@ -114,6 +127,18 @@ static int omap_usb_power_on(struct phy *x)
  {
struct omap_usb *phy = phy_get_drvdata(x);

+   if (phy-pwr) {
+   int ret;
+
+   ret = regulator_enable(phy-pwr);
+   if (ret) {
+   dev_err(phy-dev, failed to enable regulator\n);
+   return ret;
+   } else {
+   dev_info(phy-dev, enabled regulator\n);
+   }
+   }
+
omap_control_phy_power(phy-control_dev, 1);

return 0;
@@ -253,6 +278,14 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-control_dev = control_pdev-dev;
   

Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards

[Jason Kridner]

On Thu, Jun 26, 2014 at 9:06 AM, Tom Rini tr...@ti.com wrote:
 On 06/26/2014 03:50 AM, Tony Lindgren wrote:
 * Gupta, Pekon pe...@ti.com [140618 01:52]:
 Hi,

 From: Jason Kridner [mailto:jkrid...@gmail.com]
 On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon pe...@ti.com wrote:
 From: Jason Kridner
 [...]
 * The devicetree sources, including the primary boot .dts files, will
 eventually be removed from the kernel source tree. I'm not too sure if
 and when it'll really happen, but starting up a project to maintain
 the definitive beagleboard.org board devicetree files outside the
 kernel seems to make sense. Given the interdependency of the boot .dtb
 and the overlay .dtbo files, combining them into a single repository
 where every distribution can pick them up seems like a natural and
 obvious choice. There are of course some dependencies on kernel
 versions, but I believe most of those have settled out by now and we
 should be OK moving forward.

 +1
 Yes, moving cape DTS out of kernel tree should help developers.
 There are quite a few cape patches floating in mail-lists, but as cape
 DTS is still not accepted in mainline so they get lost and forgotten.
 So one place for collecting all this is a good idea.


 However, somehow the universal I/O DTS looked seemed complicated:
 (1)
 All capes work standalone, but due to share pin-mux some cape
 combinations cannot be used simultaneously. But most users of
 BeagleBone are already well-versed with DT and kernel infrastructure,
 so they need not be spoon fed to get a out-of-box working solution
 for each combination. If there is proper documentation is available
 about compatibility of capes with each other, then users will figure
 out themselves.

 I think you have too much confidence in users. If this doesn't hurt
 power users, then why is it bad have an option to spoon feed? This
 doesn't prevent anyone with knowledge of DT from doing their own
 thing.

 Fair enough.
 But plz give a try to u-boot alternative below. It works at my end.


 (2)
 Also, there was a talk of enabling and disabling DT fragments via u-boot.
 That should also be explored instead of complicating cape DTS.

 Link? Relevance?

 we can modify DT from u-boot itself [1].
 Example:  MMC2 pin-mux conflicts with NAND and NOR capes.
 But using following sequence of commands, you can modify DTB via
 u-boot and make NAND cape work _without_any_hack_ in patch [2].

 /* load DTB */
 u-boot tftp 0x8100 am335x-boneblack.dtb
 u-boot fdt addr 0x8100
 /* disable MMC2 node */
 u-boot fdt list /ocp/mmc@481d8000
 u-boot fdt set  /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
 u-boot fdt list /ocp/mmc@481d8000 status
 /* enable GPMC node */
 u-boot fdt list /ocp/gpmc
 u-boot fdt set  /ocp/gpmc status \o\k\a\y
 u-boot fdt list /ocp/gpmc status
 /* enable ELM node */
 u-boot fdt list /ocp/elm
 u-boot fdt set  /ocp/elm status \o\k\a\y
 u-boot fdt list /ocp/elm status
 /* boot uImage */
 tftp 0x8200 uImage
 bootm 0x8200 - 0x8100

 Note: fdt set command does not accept string literals
 as binding values, it internally converts them to string, so
 escape sequenced characters were used here..
 okay == \o\k\a\y
 disabled == \d\i\s\a\b\l\e\d


 Hope above solves the pre-requisite because of which 'Tony Lindgren 
 t...@atomide.com'
 was unable to accept cape related DTS into his tree [3]

 Yes. If the capes are disabled by default we can have at
 least some of them included in the mainline kernel and
 enabled by the bootloader as needed. I'd like to hear back
 from the u-boot people too on this approach naturally.

Great.


 And some things we still cannot merge if they overlap for
 GPMC bindings for example. So we have to carefully check
 the generated .dtb file with dtc -I dtb -O dts.

 This sounds really problematic to me from an end-user horror point of
 view.  And fortunately 3.17 is going to have some level of overlay
 support so we can set this problem aside (and even treat the am335x gp
 evm profileN trees as overlays too).

Thank you Tom for chiming in. I think the end user experience is
horrific. Pekon should at least provide patches to u-boot that would
provide a mechanism to enable/disable a cape with a single operation,
rather than the individual devicetree nodes. This seems to really
break any ability to keep information about a cape consolidated or
usable by mere mortals.

I don't know that pushing it all into the kernel with overlays,
however, is the right answer. We've seen challenges with some
userspaces not exposing /lib/firmware in time and needing to compile
overlays into the kernel to make them work. More troublesome are the
types of errors end-users get when there are syntax errors, conflicts
or other failures, most notably because testing of loading all of the
various overlays in conflict with each other is adhoc at best. We've
gotten a lot of good feedback on using the pinmux-helper and
config-pin utility from end users who are still struggling to learn
how to do devicetree 

Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape

[Guido Martínez]

Hi Pekon,

I had some issues with this patch. Booting linux-next on a BeagleBone
Black with this exact LCD left me with an unusable white screen. Please
see below for some details.

On Tue, Jun 24, 2014 at 05:54:26PM +0530, Pekon Gupta wrote:
 This patch adds support for LCD4 cape as advertised on
   http://elinux.org/CircuitCo:BeagleBone_LCD4
 
 This cape has:
 * 480x272 TFT-LCD panel
  - LCD panel datasheet and timing information are sourced from [1]
  - LCD backlight is connected to 'EHRPWM1A' on cape board, but its used for
enabling backlight power-supply. So 'gpio-backlight' driver is used instead
of 'pwm-backlight' driver (Kconfig: BACKLIGHT_GPIO=y).
 
 * 4-wire resistive Touchscreen
 
 *Known constrains*
 As LCD panel pins (lcd_data, hsync, vsync, pclk) are shared with on-board
 NXP HDMI framer, so either HDMI or LCD-cape can be used at time. Thus while
 using this cape 'hdmi' DT node needs to be disabled in am335x-boneblack.dts
 
 [1] www.newhavendisplay.com/specs/NHD-4.3-480272MF-ATXI-T-1.pdf
 www.newhavendisplay.com/app_notes/OTA5180A.pdf
 
 Signed-off-by: Pekon Gupta pe...@ti.com
 ---
  arch/arm/boot/dts/am335x-bone-display-cape.dts | 104 
 +
  arch/arm/boot/dts/am335x-bone.dts  |   1 +
  arch/arm/boot/dts/am335x-boneblack.dts |   1 +
  3 files changed, 106 insertions(+)
  create mode 100644 arch/arm/boot/dts/am335x-bone-display-cape.dts
 
 diff --git a/arch/arm/boot/dts/am335x-bone-display-cape.dts 
 b/arch/arm/boot/dts/am335x-bone-display-cape.dts
 new file mode 100644
 index 000..f3b7cef
 --- /dev/null
 +++ b/arch/arm/boot/dts/am335x-bone-display-cape.dts
 @@ -0,0 +1,104 @@
 +/*
 + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * 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 DTS adds supports for display capes using LCD interface for display
 + * and GPIO or PWM interface for backlight controls.
 + */
 +
 +
 +am33xx_pinmux {
 + bbcape_backlight_pins: bbcape_backlight_pins {
 + pinctrl-single,pins = 
 + 0x48  (PIN_OUTPUT | MUX_MODE7)  /* 
 gpmc_a[2].GPIO1[18] (backlight control) */
 + ;
 + };
 +
 + bbcape_lcd_pins: bbcape_lcd_pins {
 + pinctrl-single,pins = 
 + 0xa0 (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_data0.lcd_data0 */
 + 0xa4 (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_data1.lcd_data1 */
 + 0xa8 (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_data2.lcd_data2 */
 + 0xac (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_data3.lcd_data3 */
 + 0xb0 (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_data4.lcd_data4 */
 + 0xb4 (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_data5.lcd_data5 */
 + 0xb8 (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_data6.lcd_data6 */
 + 0xbc (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_data7.lcd_data7 */
 + 0xc0 (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_data8.lcd_data8 */
 + 0xc4 (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_data9.lcd_data9 */
 + 0xc8 (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_data10.lcd_data10 */
 + 0xcc (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_data11.lcd_data11 */
 + 0xd0 (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_data12.lcd_data12 */
 + 0xd4 (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_data13.lcd_data13 */
 + 0xd8 (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_data14.lcd_data14 */
 + 0xdc (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_data15.lcd_data15 */
 + 0xe0 (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_vsync.lcd_vsync */
 + 0xe4 (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_hsync.lcd_hsync */
 + 0xe8 (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_pclk.lcd_pclk */
 + 0xec (PIN_OUTPUT | MUX_MODE0)   /* 
 lcd_ac_bias_en.lcd_ac_bias_en (lcd_en) */
 + 0x1a4 (PIN_OUTPUT_PULLUP | MUX_MODE7)   /* 
 mcasp0_fsr.gpio3[19] (lcd_disen) */
 + ;
 + };
 +
 + bbcape_touchscreen_pins: bbcape_touchscreen_pins {
 + pinctrl-single,pins = 
 + 0x184 (PIN_INPUT_PULLDOWN | MUX_MODE7)  /* 
 uart1_txd.gpio0[15] (enter) */
 + 0x40  (PIN_INPUT_PULLDOWN | MUX_MODE7)  /* 
 gpmc_a0.gpio1[16] (left) */
 + 0x44  (PIN_INPUT_PULLDOWN | MUX_MODE7)  /* 
 gpmc_a1.gpio1[17] (right) */
 + 0x4c  (PIN_INPUT_PULLDOWN | MUX_MODE7)  /* 
 gpmc_a3.gpio1[19] (up) */
 + 0x198 (PIN_INPUT_PULLDOWN | MUX_MODE7)  

Re: [PATCH] arm: mach-omap2: gpmc: ignore non-available nodes

[Ezequiel García]

On 26 Jun 12:02 PM, Guido Martínez wrote:
 Currently, child nodes of the gpmc node are iterated and probed
 regardless of their 'status' property. This means adding 'status =
 disabled;' has no effect.
 
 This patch changes the iteration to only probe nodes marked as
 available.
 
 Signed-off-by: Guido Martínez gu...@vanguardiasur.com.ar

Just a nit: the commit title doesn't match the recent commits. If you
run git log on this file, you'll find the pattern should be something
like:

ARM: OMAP2+: GPMC should only probe enabled devices

Other than this, the patch looks correct.

Thanks,
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] regulator: tps65917: Fix SMPS enable/disable/is_enable

[Nishanth Menon]

We use regmap regulator ops to enable/disable and check if regulator
is enabled for various SMPS. However, these depend on valid
enable_reg, enable_mask and enable_value in regulator descriptor.

So, similar to fix we did in commit 318dbb02b50c
(regulator: palmas: Fix SMPS enable/disable/is_enabled), populate the
same for TPS65917 SMPS registration. LDO definitions are already in place.

Fixes: d6f83370ed97 (regulator: palmas: Add tps65917 PMIC support)
Signed-off-by: Nishanth Menon n...@ti.com
---

Applies on:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
branch: topic/palmas (4c0c9ca Merge remote-tracking branch 
'regulator/fix/palmas' into regulator-palmas)

Note: Ignored the minor style check from checkpatch --strict as fixing
it would create an 80 char warning

 drivers/regulator/palmas-regulator.c |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/regulator/palmas-regulator.c 
b/drivers/regulator/palmas-regulator.c
index 7c8b441..c7aa1b1 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -1333,6 +1333,14 @@ static int tps65917_smps_registration(struct palmas_pmic 
*pmic,
pmic-current_reg_mode[id] = reg 
PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
 
+   pmic-desc[id].enable_reg =
+   PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE,
+   palmas_regs_info[id].ctrl_addr);
+   pmic-desc[id].enable_mask =
+   PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
+   /* set_mode overrides this value */
+   pmic-desc[id].enable_val = SMPS_CTRL_MODE_ON;
+
pmic-desc[id].type = REGULATOR_VOLTAGE;
pmic-desc[id].owner = THIS_MODULE;
 
-- 
1.7.9.5

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

Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape

[Darren Etheridge]

Guido, Pekon,

On 06/26/2014 10:40 AM, Guido Martínez wrote:

Hi Pekon,

I had some issues with this patch. Booting linux-next on a BeagleBone
Black with this exact LCD left me with an unusable white screen. Please
see below for some details.

On Tue, Jun 24, 2014 at 05:54:26PM +0530, Pekon Gupta wrote:

This patch adds support for LCD4 cape as advertised on
   http://elinux.org/CircuitCo:BeagleBone_LCD4

This cape has:
* 480x272 TFT-LCD panel
  - LCD panel datasheet and timing information are sourced from [1]
  - LCD backlight is connected to 'EHRPWM1A' on cape board, but its used for
enabling backlight power-supply. So 'gpio-backlight' driver is used instead
of 'pwm-backlight' driver (Kconfig: BACKLIGHT_GPIO=y).

* 4-wire resistive Touchscreen

*Known constrains*
As LCD panel pins (lcd_data, hsync, vsync, pclk) are shared with on-board
NXP HDMI framer, so either HDMI or LCD-cape can be used at time. Thus while
using this cape 'hdmi' DT node needs to be disabled in am335x-boneblack.dts

[1] www.newhavendisplay.com/specs/NHD-4.3-480272MF-ATXI-T-1.pdf
 www.newhavendisplay.com/app_notes/OTA5180A.pdf

Signed-off-by: Pekon Gupta pe...@ti.com
---


snip


+
+   panel {
+   status = disabled;
+   compatible = ti,tilcdc,panel;
+   pinctrl-names = default;
+   pinctrl-0 = bbcape_lcd_pins;
+   panel-info {
+   ac-bias   = 255;
+   ac-bias-intrpt= 0;
+   dma-burst-sz  = 16;
+   bpp   = 16;
+   fdd   = 0x80;
+   sync-edge = 0;
+   sync-ctrl = 0;

I had to set this to 1. Does that make sense?


+   raster-order  = 0;
+   fifo-th   = 0;
+   };
+   display-timings {
+   native-mode = timing0;
+   /* www.newhavendisplay.com/app_notes/OTA5180A.pdf */
+   timing0: 480x272 {
+   clock-frequency = 3000;
+   hactive = 480;
+   vactive = 272;
+   hfront-porch = 8;
+   hback-porch = 47;
+   hsync-len = 41;
+   vback-porch = 2;
+   vfront-porch = 3;
+   vsync-len = 10;
+   hsync-active = 0;
+   vsync-active = 0;
+   de-active = 1;
+   pixelclk-active = 0;

Are you sure these timings are ok? When enabling the sync control I get
an usable display, but it looks a bit funny. For example an all black
display looks very clear and has a dotted pattern.

I tried to take a picture of it but it doesn't show.


These timings look wrong to me, for instance this sets a clock frequency 
of 30MHz where as the linked app-note says 9MHz.  I think the LCD4 cape 
uses the same LCD panel as is used on the AM335x EVMSK.  Therefore the 
display timings from my DT patch for the EVMSK should work: 
https://patchwork.kernel.org/patch/4144801/


Darren



Also I'm just guessing about the timings, maybe it's something else?


+   };
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts 
b/arch/arm/boot/dts/am335x-bone.dts
index f16bfcf..41439dc 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -10,6 +10,7 @@
  #include am33xx.dtsi
  #include am335x-bone-common.dtsi
  #include am335x-bone-memory-cape.dts
+#include am335x-bone-display-cape.dts

  ldo3_reg {
regulator-min-microvolt = 180;
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index e6d7e54..03232c7 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -10,6 +10,7 @@
  #include am33xx.dtsi
  #include am335x-bone-common.dtsi
  #include am335x-bone-memory-cape.dts
+#include am335x-bone-display-cape.dts

  ldo3_reg {
regulator-min-microvolt = 180;
--
1.8.5.1.163.gd7aced9

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



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

Re: [PATCH 14/15] OMAPDSS: HDMI: remove the unused code

[Jyri Sarha]

On 06/24/2014 01:03 PM, Tomi Valkeinen wrote:

We no longer need the horrible driver internal videmode tables, which
were used to decide if a given videomode is a HDMI or DVI mode. So
remove all related code.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
  drivers/video/fbdev/omap2/dss/hdmi.h|  11 -
  drivers/video/fbdev/omap2/dss/hdmi_common.c | 316 
  2 files changed, 327 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h 
b/drivers/video/fbdev/omap2/dss/hdmi.h
index e3956defc1c3..262771b9b76b 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h

...

@@ -192,7 +187,6 @@ struct hdmi_video_format {

  struct hdmi_config {
struct omap_video_timings timings;
-   struct hdmi_cm cm;
struct hdmi_avi_infoframe infoframe;
enum hdmi_core_hdmi_dvi hdmi_dvi_mode;
  };


The HDMI audio finctionality is broken already now, but removing 
hdmi_config.cm will cause compilation failure if HDMI audio is enabled.


I'll mail a patch set to fix OMAP4+ HDMI audio shortly. The set should 
be applied on top of these patches and it fixes (obviously) the 
compilation issue too.


Best regards,
Jyri
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/12] OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value

[Jyri Sarha]

The OMAP5 HDMI audio implementation needs HDMI_AUDIO_LAYOUT_6CH in
hdmi_core_audio_layout enum. I found the correct value from ti-linux
3.8 tree.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 drivers/video/fbdev/omap2/dss/hdmi.h |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h 
b/drivers/video/fbdev/omap2/dss/hdmi.h
index 262771b..1f01068 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -160,7 +160,8 @@ enum hdmi_audio_blk_strt_end_sig {
 
 enum hdmi_core_audio_layout {
HDMI_AUDIO_LAYOUT_2CH = 0,
-   HDMI_AUDIO_LAYOUT_8CH = 1
+   HDMI_AUDIO_LAYOUT_8CH = 1,
+   HDMI_AUDIO_LAYOUT_6CH = 2
 };
 
 enum hdmi_core_cts_mode {
-- 
1.7.9.5

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

[PATCH 12/12] OMAPDSS: Remove all references obsolete HDMI audio callbacks

[Jyri Sarha]

In new model these callbacks are obsolete since the ASoC component
drivers are integrated into the HDMI drivers and no callbacks are
needed anymore.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 .../fbdev/omap2/displays-new/connector-hdmi.c  |   99 
 .../fbdev/omap2/displays-new/encoder-tpd12s015.c   |   56 ---
 include/video/omapdss.h|   31 --
 3 files changed, 186 deletions(-)

diff --git a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c 
b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
index 131c6e2..dd36d71 100644
--- a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
+++ b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
@@ -170,98 +170,6 @@ static bool hdmic_detect(struct omap_dss_device *dssdev)
return in-ops.hdmi-detect(in);
 }
 
-static int hdmic_audio_enable(struct omap_dss_device *dssdev)
-{
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata-in;
-   int r;
-
-   /* enable audio only if the display is active */
-   if (!omapdss_device_is_enabled(dssdev))
-   return -EPERM;
-
-   r = in-ops.hdmi-audio_enable(in);
-   if (r)
-   return r;
-
-   dssdev-audio_state = OMAP_DSS_AUDIO_ENABLED;
-
-   return 0;
-}
-
-static void hdmic_audio_disable(struct omap_dss_device *dssdev)
-{
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata-in;
-
-   in-ops.hdmi-audio_disable(in);
-
-   dssdev-audio_state = OMAP_DSS_AUDIO_DISABLED;
-}
-
-static int hdmic_audio_start(struct omap_dss_device *dssdev)
-{
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata-in;
-   int r;
-
-   /*
-* No need to check the panel state. It was checked when trasitioning
-* to AUDIO_ENABLED.
-*/
-   if (dssdev-audio_state != OMAP_DSS_AUDIO_ENABLED)
-   return -EPERM;
-
-   r = in-ops.hdmi-audio_start(in);
-   if (r)
-   return r;
-
-   dssdev-audio_state = OMAP_DSS_AUDIO_PLAYING;
-
-   return 0;
-}
-
-static void hdmic_audio_stop(struct omap_dss_device *dssdev)
-{
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata-in;
-
-   in-ops.hdmi-audio_stop(in);
-
-   dssdev-audio_state = OMAP_DSS_AUDIO_ENABLED;
-}
-
-static bool hdmic_audio_supported(struct omap_dss_device *dssdev)
-{
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata-in;
-
-   if (!omapdss_device_is_enabled(dssdev))
-   return false;
-
-   return in-ops.hdmi-audio_supported(in);
-}
-
-static int hdmic_audio_config(struct omap_dss_device *dssdev,
-   struct omap_dss_audio *audio)
-{
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata-in;
-   int r;
-
-   /* config audio only if the display is active */
-   if (!omapdss_device_is_enabled(dssdev))
-   return -EPERM;
-
-   r = in-ops.hdmi-audio_config(in, audio);
-   if (r)
-   return r;
-
-   dssdev-audio_state = OMAP_DSS_AUDIO_CONFIGURED;
-
-   return 0;
-}
-
 static int hdmic_set_hdmi_mode(struct omap_dss_device *dssdev, bool hdmi_mode)
 {
struct panel_drv_data *ddata = to_panel_data(dssdev);
@@ -296,13 +204,6 @@ static struct omap_dss_driver hdmic_driver = {
.detect = hdmic_detect,
.set_hdmi_mode  = hdmic_set_hdmi_mode,
.set_hdmi_infoframe = hdmic_set_infoframe,
-
-   .audio_enable   = hdmic_audio_enable,
-   .audio_disable  = hdmic_audio_disable,
-   .audio_start= hdmic_audio_start,
-   .audio_stop = hdmic_audio_stop,
-   .audio_supported= hdmic_audio_supported,
-   .audio_config   = hdmic_audio_config,
 };
 
 static int hdmic_probe_pdata(struct platform_device *pdev)
diff --git a/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c 
b/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
index c891d8f..235e3d5 100644
--- a/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
+++ b/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
@@ -193,55 +193,6 @@ static bool tpd_detect(struct omap_dss_device *dssdev)
return gpio_get_value_cansleep(ddata-hpd_gpio);
 }
 
-static int tpd_audio_enable(struct omap_dss_device *dssdev)
-{
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata-in;
-
-   return in-ops.hdmi-audio_enable(in);
-}
-
-static void tpd_audio_disable(struct omap_dss_device *dssdev)
-{
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata-in;
-
-   in-ops.hdmi-audio_disable(in);
-}
-
-static int 

[PATCH 00/12] Rework OMAP4+ HDMI audio support

[Jyri Sarha]

The patches are based on linux 3.16-rc2 and OMAPDSS HDMI infoframe
patches[1] from Tomi Valkeinen. The base, the patches, and couple of
additional not-to-be-merged omap2plus_defconfig patches can be found
here:

git://git.ti.com/~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git
 omap-hdmi-audio

The patch set fixes OMAP4+ HDMI audio. The structure of the
implementation looks a bit different than before. Instead of creating
a driver specific API for a separate ASoC component driver to connect
to, this implementation integrates an the ASoC cpu-dai component
driver into the HDMI driver. Also the other ASoC component drivers
needed for operational audio are automatically registered by the HDMI
driver. There is no need to add anything to the device tree as long as
the nodes needed for HDMI video are there.

Big part of the HDMI audio code is still unchanged and there is a need
for a cleanup there. Also there is still probably something wrong with
speaker mapping of multi-channel streams. I will get back to cleaning
up these issues later.

Best regards,
Jyri

[1] http://marc.info/?l=linux-fbdevm=140360425130951w=2

Jyri Sarha (12):
  ARM: OMAP2+: Remove non working OMAP HDMI audio initialization
  OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value
  OMAPDSS: hdmi_wp: Add function for getting hdmi_wp physical base
address
  OMAPDSS: hdmi_audio: Integrated ASoC DAI component driver
implementation
  OMAPDSS: Kconfig: Select audio dependencies if OMAP4_DSS_HDMI_AUDIO=y
  OMAPDSS: hdmi4: Register HDMI audio ASoC drivers from HDMI driver
  OMAPDSS: Kconfig: Select audio dependencies if OMAP5_DSS_HDMI_AUDIO=y
  OMAPDSS: hdmi5: Register HDMI audio ASoC drivers from HDMI driver
  ASoC: omap: Remove obsolete HDMI audio code and Kconfig options
  OMAPDSS: hdmi4: Remove callbacks for an external ASoC DAI driver
  OMAPDSS: hdmi5: Remove callbacks for an external ASoC DAI driver
  OMAPDSS: Remove all references to obsolete HDMI audio callbacks

 arch/arm/mach-omap2/devices.c  |   28 --
 .../fbdev/omap2/displays-new/connector-hdmi.c  |   99 --
 .../fbdev/omap2/displays-new/encoder-tpd12s015.c   |   56 ---
 drivers/video/fbdev/omap2/dss/Kconfig  |   24 +-
 drivers/video/fbdev/omap2/dss/Makefile |2 +
 drivers/video/fbdev/omap2/dss/hdmi.h   |   43 ++-
 drivers/video/fbdev/omap2/dss/hdmi4.c  |  158 +++--
 drivers/video/fbdev/omap2/dss/hdmi5.c  |  170 +++--
 drivers/video/fbdev/omap2/dss/hdmi_audio.c |  317 +
 drivers/video/fbdev/omap2/dss/hdmi_wp.c|6 +
 include/video/omapdss.h|   31 --
 sound/soc/omap/Kconfig |   13 -
 sound/soc/omap/Makefile|4 -
 sound/soc/omap/omap-hdmi-card.c|   87 -
 sound/soc/omap/omap-hdmi.c |  364 
 sound/soc/omap/omap-hdmi.h |   38 --
 16 files changed, 489 insertions(+), 951 deletions(-)
 create mode 100644 drivers/video/fbdev/omap2/dss/hdmi_audio.c
 delete mode 100644 sound/soc/omap/omap-hdmi-card.c
 delete mode 100644 sound/soc/omap/omap-hdmi.c
 delete mode 100644 sound/soc/omap/omap-hdmi.h

-- 
1.7.9.5

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

[PATCH 11/12] OMAPDSS: hdmi5: Remove callbacks for an external ASoC DAI driver

[Jyri Sarha]

Removes the OMAP5 HDMI audio callbacks for an external audio driver and
the old external DAI driver does not work anymore after this patch.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 drivers/video/fbdev/omap2/dss/hdmi5.c |  113 -
 1 file changed, 113 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c 
b/drivers/video/fbdev/omap2/dss/hdmi5.c
index b49b33b..ab801cf 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi5.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi5.c
@@ -517,112 +517,6 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev,
return r;
 }
 
-#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
-static int hdmi_audio_enable(struct omap_dss_device *dssdev)
-{
-   int r;
-
-   mutex_lock(hdmi.lock);
-
-   if (!hdmi_mode_has_audio(hdmi.cfg.cm.mode)) {
-   r = -EPERM;
-   goto err;
-   }
-
-   r = hdmi_wp_audio_enable(hdmi.wp, true);
-   if (r)
-   goto err;
-
-   mutex_unlock(hdmi.lock);
-   return 0;
-
-err:
-   mutex_unlock(hdmi.lock);
-   return r;
-}
-
-static void hdmi_audio_disable(struct omap_dss_device *dssdev)
-{
-   hdmi_wp_audio_enable(hdmi.wp, false);
-}
-
-static int hdmi_audio_start(struct omap_dss_device *dssdev)
-{
-   return hdmi_wp_audio_core_req_enable(hdmi.wp, true);
-}
-
-static void hdmi_audio_stop(struct omap_dss_device *dssdev)
-{
-   hdmi_wp_audio_core_req_enable(hdmi.wp, false);
-}
-
-static bool hdmi_audio_supported(struct omap_dss_device *dssdev)
-{
-   bool r;
-
-   mutex_lock(hdmi.lock);
-
-   r = hdmi_mode_has_audio(hdmi.cfg.cm.mode);
-
-   mutex_unlock(hdmi.lock);
-   return r;
-}
-
-static int hdmi_audio_config(struct omap_dss_device *dssdev,
-   struct omap_dss_audio *audio)
-{
-   int r;
-   u32 pclk = hdmi.cfg.timings.pixelclock;
-
-   mutex_lock(hdmi.lock);
-
-   if (!hdmi_mode_has_audio(hdmi.cfg.cm.mode)) {
-   r = -EPERM;
-   goto err;
-   }
-
-   r = hdmi5_audio_config(hdmi.core, hdmi.wp, audio, pclk);
-   if (r)
-   goto err;
-
-   mutex_unlock(hdmi.lock);
-   return 0;
-
-err:
-   mutex_unlock(hdmi.lock);
-   return r;
-}
-#else
-static int hdmi_audio_enable(struct omap_dss_device *dssdev)
-{
-   return -EPERM;
-}
-
-static void hdmi_audio_disable(struct omap_dss_device *dssdev)
-{
-}
-
-static int hdmi_audio_start(struct omap_dss_device *dssdev)
-{
-   return -EPERM;
-}
-
-static void hdmi_audio_stop(struct omap_dss_device *dssdev)
-{
-}
-
-static bool hdmi_audio_supported(struct omap_dss_device *dssdev)
-{
-   return false;
-}
-
-static int hdmi_audio_config(struct omap_dss_device *dssdev,
-   struct omap_dss_audio *audio)
-{
-   return -EPERM;
-}
-#endif
-
 static int hdmi_set_infoframe(struct omap_dss_device *dssdev,
const struct hdmi_avi_infoframe *avi)
 {
@@ -651,13 +545,6 @@ static const struct omapdss_hdmi_ops hdmi_ops = {
.read_edid  = hdmi_read_edid,
.set_infoframe  = hdmi_set_infoframe,
.set_hdmi_mode  = hdmi_set_hdmi_mode,
-
-   .audio_enable   = hdmi_audio_enable,
-   .audio_disable  = hdmi_audio_disable,
-   .audio_start= hdmi_audio_start,
-   .audio_stop = hdmi_audio_stop,
-   .audio_supported= hdmi_audio_supported,
-   .audio_config   = hdmi_audio_config,
 };
 
 static void hdmi_init_output(struct platform_device *pdev)
-- 
1.7.9.5

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

[PATCH 10/12] OMAPDSS: hdmi4: Remove callbacks for an external ASoC DAI driver

[Jyri Sarha]

Removes the OMAP4 HDMI audio callbacks for an external audio driver and
the old external DAI driver does not work anymore after this patch.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 drivers/video/fbdev/omap2/dss/hdmi4.c |  113 -
 1 file changed, 113 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c 
b/drivers/video/fbdev/omap2/dss/hdmi4.c
index 48f11f8..c56c8bc 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4.c
@@ -492,112 +492,6 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev,
return r;
 }
 
-#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
-static int hdmi_audio_enable(struct omap_dss_device *dssdev)
-{
-   int r;
-
-   mutex_lock(hdmi.lock);
-
-   if (!hdmi_mode_has_audio(hdmi.cfg.cm.mode)) {
-   r = -EPERM;
-   goto err;
-   }
-
-   r = hdmi_wp_audio_enable(hdmi.wp, true);
-   if (r)
-   goto err;
-
-   mutex_unlock(hdmi.lock);
-   return 0;
-
-err:
-   mutex_unlock(hdmi.lock);
-   return r;
-}
-
-static void hdmi_audio_disable(struct omap_dss_device *dssdev)
-{
-   hdmi_wp_audio_enable(hdmi.wp, false);
-}
-
-static int hdmi_audio_start(struct omap_dss_device *dssdev)
-{
-   return hdmi4_audio_start(hdmi.core, hdmi.wp);
-}
-
-static void hdmi_audio_stop(struct omap_dss_device *dssdev)
-{
-   hdmi4_audio_stop(hdmi.core, hdmi.wp);
-}
-
-static bool hdmi_audio_supported(struct omap_dss_device *dssdev)
-{
-   bool r;
-
-   mutex_lock(hdmi.lock);
-
-   r = hdmi_mode_has_audio(hdmi.cfg.cm.mode);
-
-   mutex_unlock(hdmi.lock);
-   return r;
-}
-
-static int hdmi_audio_config(struct omap_dss_device *dssdev,
-   struct omap_dss_audio *audio)
-{
-   int r;
-   u32 pclk = hdmi.cfg.timings.pixelclock;
-
-   mutex_lock(hdmi.lock);
-
-   if (!hdmi_mode_has_audio(hdmi.cfg.cm.mode)) {
-   r = -EPERM;
-   goto err;
-   }
-
-   r = hdmi4_audio_config(hdmi.core, hdmi.wp, audio, pclk);
-   if (r)
-   goto err;
-
-   mutex_unlock(hdmi.lock);
-   return 0;
-
-err:
-   mutex_unlock(hdmi.lock);
-   return r;
-}
-#else
-static int hdmi_audio_enable(struct omap_dss_device *dssdev)
-{
-   return -EPERM;
-}
-
-static void hdmi_audio_disable(struct omap_dss_device *dssdev)
-{
-}
-
-static int hdmi_audio_start(struct omap_dss_device *dssdev)
-{
-   return -EPERM;
-}
-
-static void hdmi_audio_stop(struct omap_dss_device *dssdev)
-{
-}
-
-static bool hdmi_audio_supported(struct omap_dss_device *dssdev)
-{
-   return false;
-}
-
-static int hdmi_audio_config(struct omap_dss_device *dssdev,
-   struct omap_dss_audio *audio)
-{
-   return -EPERM;
-}
-#endif
-
 static int hdmi_set_infoframe(struct omap_dss_device *dssdev,
const struct hdmi_avi_infoframe *avi)
 {
@@ -626,13 +520,6 @@ static const struct omapdss_hdmi_ops hdmi_ops = {
.read_edid  = hdmi_read_edid,
.set_infoframe  = hdmi_set_infoframe,
.set_hdmi_mode  = hdmi_set_hdmi_mode,
-
-   .audio_enable   = hdmi_audio_enable,
-   .audio_disable  = hdmi_audio_disable,
-   .audio_start= hdmi_audio_start,
-   .audio_stop = hdmi_audio_stop,
-   .audio_supported= hdmi_audio_supported,
-   .audio_config   = hdmi_audio_config,
 };
 
 static void hdmi_init_output(struct platform_device *pdev)
-- 
1.7.9.5

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

[PATCH 12/12] OMAPDSS: Remove all references to obsolete HDMI audio callbacks

[Jyri Sarha]

In new model these callbacks are obsolete since the ASoC component
drivers are integrated into the HDMI drivers and no callbacks are
needed anymore.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 .../fbdev/omap2/displays-new/connector-hdmi.c  |   99 
 .../fbdev/omap2/displays-new/encoder-tpd12s015.c   |   56 ---
 include/video/omapdss.h|   31 --
 3 files changed, 186 deletions(-)

diff --git a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c 
b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
index 131c6e2..dd36d71 100644
--- a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
+++ b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
@@ -170,98 +170,6 @@ static bool hdmic_detect(struct omap_dss_device *dssdev)
return in-ops.hdmi-detect(in);
 }
 
-static int hdmic_audio_enable(struct omap_dss_device *dssdev)
-{
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata-in;
-   int r;
-
-   /* enable audio only if the display is active */
-   if (!omapdss_device_is_enabled(dssdev))
-   return -EPERM;
-
-   r = in-ops.hdmi-audio_enable(in);
-   if (r)
-   return r;
-
-   dssdev-audio_state = OMAP_DSS_AUDIO_ENABLED;
-
-   return 0;
-}
-
-static void hdmic_audio_disable(struct omap_dss_device *dssdev)
-{
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata-in;
-
-   in-ops.hdmi-audio_disable(in);
-
-   dssdev-audio_state = OMAP_DSS_AUDIO_DISABLED;
-}
-
-static int hdmic_audio_start(struct omap_dss_device *dssdev)
-{
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata-in;
-   int r;
-
-   /*
-* No need to check the panel state. It was checked when trasitioning
-* to AUDIO_ENABLED.
-*/
-   if (dssdev-audio_state != OMAP_DSS_AUDIO_ENABLED)
-   return -EPERM;
-
-   r = in-ops.hdmi-audio_start(in);
-   if (r)
-   return r;
-
-   dssdev-audio_state = OMAP_DSS_AUDIO_PLAYING;
-
-   return 0;
-}
-
-static void hdmic_audio_stop(struct omap_dss_device *dssdev)
-{
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata-in;
-
-   in-ops.hdmi-audio_stop(in);
-
-   dssdev-audio_state = OMAP_DSS_AUDIO_ENABLED;
-}
-
-static bool hdmic_audio_supported(struct omap_dss_device *dssdev)
-{
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata-in;
-
-   if (!omapdss_device_is_enabled(dssdev))
-   return false;
-
-   return in-ops.hdmi-audio_supported(in);
-}
-
-static int hdmic_audio_config(struct omap_dss_device *dssdev,
-   struct omap_dss_audio *audio)
-{
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata-in;
-   int r;
-
-   /* config audio only if the display is active */
-   if (!omapdss_device_is_enabled(dssdev))
-   return -EPERM;
-
-   r = in-ops.hdmi-audio_config(in, audio);
-   if (r)
-   return r;
-
-   dssdev-audio_state = OMAP_DSS_AUDIO_CONFIGURED;
-
-   return 0;
-}
-
 static int hdmic_set_hdmi_mode(struct omap_dss_device *dssdev, bool hdmi_mode)
 {
struct panel_drv_data *ddata = to_panel_data(dssdev);
@@ -296,13 +204,6 @@ static struct omap_dss_driver hdmic_driver = {
.detect = hdmic_detect,
.set_hdmi_mode  = hdmic_set_hdmi_mode,
.set_hdmi_infoframe = hdmic_set_infoframe,
-
-   .audio_enable   = hdmic_audio_enable,
-   .audio_disable  = hdmic_audio_disable,
-   .audio_start= hdmic_audio_start,
-   .audio_stop = hdmic_audio_stop,
-   .audio_supported= hdmic_audio_supported,
-   .audio_config   = hdmic_audio_config,
 };
 
 static int hdmic_probe_pdata(struct platform_device *pdev)
diff --git a/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c 
b/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
index c891d8f..235e3d5 100644
--- a/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
+++ b/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
@@ -193,55 +193,6 @@ static bool tpd_detect(struct omap_dss_device *dssdev)
return gpio_get_value_cansleep(ddata-hpd_gpio);
 }
 
-static int tpd_audio_enable(struct omap_dss_device *dssdev)
-{
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata-in;
-
-   return in-ops.hdmi-audio_enable(in);
-}
-
-static void tpd_audio_disable(struct omap_dss_device *dssdev)
-{
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata-in;
-
-   in-ops.hdmi-audio_disable(in);
-}
-
-static int 

[PATCH 01/12] ARM: OMAP2+: Remove non working OMAP HDMI audio initialization

[Jyri Sarha]

This code is not working currently and it can be removed. There is a
conflict in sharing resources with the actual HDMI driver and with
the ASoC HDMI audio DAI driver.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 arch/arm/mach-omap2/devices.c |   28 
 1 file changed, 28 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 592ba0a..b6f8f34 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -297,33 +297,6 @@ static void omap_init_audio(void)
 static inline void omap_init_audio(void) {}
 #endif
 
-#if defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI) || \
-   defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI_MODULE)
-
-static struct platform_device omap_hdmi_audio = {
-   .name   = omap-hdmi-audio,
-   .id = -1,
-};
-
-static void __init omap_init_hdmi_audio(void)
-{
-   struct omap_hwmod *oh;
-   struct platform_device *pdev;
-
-   oh = omap_hwmod_lookup(dss_hdmi);
-   if (!oh)
-   return;
-
-   pdev = omap_device_build(omap-hdmi-audio-dai, -1, oh, NULL, 0);
-   WARN(IS_ERR(pdev),
-Can't build omap_device for omap-hdmi-audio-dai.\n);
-
-   platform_device_register(omap_hdmi_audio);
-}
-#else
-static inline void omap_init_hdmi_audio(void) {}
-#endif
-
 #if defined(CONFIG_SPI_OMAP24XX) || defined(CONFIG_SPI_OMAP24XX_MODULE)
 
 #include linux/platform_data/spi-omap2-mcspi.h
@@ -459,7 +432,6 @@ static int __init omap2_init_devices(void)
 */
omap_init_audio();
omap_init_camera();
-   omap_init_hdmi_audio();
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
-- 
1.7.9.5

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

[PATCH 05/12] OMAPDSS: Kconfig: Select audio dependencies if OMAP4_DSS_HDMI_AUDIO=y

[Jyri Sarha]

Adds help section and SND_SOC dependency to OMAP4_DSS_HDMI_AUDIO.
Selects SND_OMAP_SOC, SND_SOC_HDMI_CODEC, and SND_SIMPLE_CARD if
OMAP4_DSS_HDMI_AUDIO is enabled.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 drivers/video/fbdev/omap2/dss/Kconfig |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/dss/Kconfig 
b/drivers/video/fbdev/omap2/dss/Kconfig
index 3d5eb6c..871f722 100644
--- a/drivers/video/fbdev/omap2/dss/Kconfig
+++ b/drivers/video/fbdev/omap2/dss/Kconfig
@@ -6,6 +6,9 @@ menuconfig OMAP2_DSS
select VIDEOMODE_HELPERS
select OMAP2_DSS_INIT
select HDMI
+   select SND_OMAP_SOC if OMAP4_DSS_HDMI_AUDIO
+   select SND_SOC_HDMI_CODEC if OMAP4_DSS_HDMI_AUDIO
+   select SND_SIMPLE_CARD if OMAP4_DSS_HDMI_AUDIO
 help
  OMAP2+ Display Subsystem support.
 
@@ -75,7 +78,16 @@ config OMAP4_DSS_HDMI
  HDMI support for OMAP4 based SoCs.
 
 config OMAP4_DSS_HDMI_AUDIO
-   bool
+   bool HDMI audio support for OMAP4
+   depends on OMAP4_DSS_HDMI
+   depends on SND_SOC=y || OMAP2_DSS = SND_SOC
+   default y
+   help
+ HDMI audio support for OMAP4 based SoCs. Adds integrated
+ ASoC Digital Audio Interface component driver into OMAPDSS
+ module. If enabled OMAP2_DSS selects SND_OMAP_SOC,
+ SND_SOC_HDMI_CODEC, and SND_SIMPLE_CARD for full HDMI
+ audio support.
 
 config OMAP5_DSS_HDMI
bool HDMI support for OMAP5
-- 
1.7.9.5

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

[PATCH 08/12] OMAPDSS: hdmi5: Register HDMI audio ASoC drivers from HDMI driver

[Jyri Sarha]

Add audio datamember to hdmi struct and call register and unregister
functions form hdmi_audio.c. Register function registers the
integrated cpu dai, dummy HDMI codec, and simple-card machine driver
for complete HDMI audio support.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 drivers/video/fbdev/omap2/dss/hdmi5.c |   57 +
 1 file changed, 57 insertions(+)

diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c 
b/drivers/video/fbdev/omap2/dss/hdmi5.c
index 713e35a..b49b33b 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi5.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi5.c
@@ -43,6 +43,11 @@
 #include dss.h
 #include dss_features.h
 
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+#include sound/soc.h
+#include sound/soc-dai.h
+#endif
+
 static struct {
struct mutex lock;
struct platform_device *pdev;
@@ -57,6 +62,9 @@ static struct {
struct clk *sys_clk;
struct regulator *vdda_reg;
 
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+   struct hdmi_audio_data audio;
+#endif
bool core_enabled;
 
struct omap_dss_device output;
@@ -696,6 +704,33 @@ err:
return r;
 }
 
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+static int audio_start(struct hdmi_core_data *core, struct hdmi_wp_data *wp)
+{
+   hdmi_wp_audio_core_req_enable(wp, true);
+
+   return 0;
+}
+
+static void audio_stop(struct hdmi_core_data *core, struct hdmi_wp_data *wp)
+{
+   hdmi_wp_audio_core_req_enable(wp, false);
+}
+
+static struct snd_soc_dai_driver omap_hdmi_dai = {
+   .name = omap5-hdmi-dai,
+   .playback = {
+   .channels_min = 2,
+   .channels_max = 8,
+   .rates = (SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |
+ SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_88200 |
+ SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_176400 |
+ SNDRV_PCM_RATE_192000),
+   .formats = SNDRV_PCM_FMTBIT_S16_LE,
+   },
+};
+#endif
+
 /* HDMI HW IP initialisation */
 static int omapdss_hdmihw_probe(struct platform_device *pdev)
 {
@@ -752,6 +787,25 @@ static int omapdss_hdmihw_probe(struct platform_device 
*pdev)
 
hdmi_init_output(pdev);
 
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+   /* drvdata is only used by HDMI audio */
+   hdmi.audio.hdmi_lock = hdmi.lock;
+   hdmi.audio.wp = hdmi.wp;
+   hdmi.audio.core = hdmi.core;
+   hdmi.audio.cfg = hdmi.cfg;
+   hdmi.audio.hdmi_dai_drv = omap_hdmi_dai;
+   hdmi.audio.audio_start = audio_start;
+   hdmi.audio.audio_stop = audio_stop;
+   hdmi.audio.audio_config = hdmi5_audio_config;
+   dev_set_drvdata(pdev-dev, hdmi.audio);
+   r = hdmi_audio_register(pdev);
+   if (r) {
+   DSSERR(Registering HDMI audio failed\n);
+   hdmi_uninit_output(pdev);
+   pm_runtime_disable(pdev-dev);
+   return r;
+   }
+#endif
dss_debugfs_create_file(hdmi, hdmi_dump_regs);
 
return 0;
@@ -759,6 +813,9 @@ static int omapdss_hdmihw_probe(struct platform_device 
*pdev)
 
 static int __exit omapdss_hdmihw_remove(struct platform_device *pdev)
 {
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+   hdmi_audio_unregister(pdev);
+#endif
hdmi_uninit_output(pdev);
 
pm_runtime_disable(pdev-dev);
-- 
1.7.9.5

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

[PATCH 04/12] OMAPDSS: hdmi_audio: Integrated ASoC DAI component driver implementation

[Jyri Sarha]

Integrate ASoC DAI component driver in to the OMAP hdmi driver. The
patch also updates the relevant entry in ti,omap5-dss DT binding
document. The driver registers a dummy hdmi codec driver and a
simple-card driver to produce a fully functional ALSA device. The DAI
driver is implemented in hdmi_audio.c, but it still needs to be
registered from hdmi4.c or hdmi5.c.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 drivers/video/fbdev/omap2/dss/Makefile |2 +
 drivers/video/fbdev/omap2/dss/hdmi.h   |   38 +++-
 drivers/video/fbdev/omap2/dss/hdmi_audio.c |  317 
 3 files changed, 355 insertions(+), 2 deletions(-)
 create mode 100644 drivers/video/fbdev/omap2/dss/hdmi_audio.c

diff --git a/drivers/video/fbdev/omap2/dss/Makefile 
b/drivers/video/fbdev/omap2/dss/Makefile
index 245f933..8260987 100644
--- a/drivers/video/fbdev/omap2/dss/Makefile
+++ b/drivers/video/fbdev/omap2/dss/Makefile
@@ -14,5 +14,7 @@ omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o
 omapdss-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += hdmi_common.o hdmi_wp.o hdmi_pll.o \
hdmi_phy.o
 omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi4.o hdmi4_core.o
+omapdss-$(CONFIG_OMAP4_DSS_HDMI_AUDIO) += hdmi_audio.o
 omapdss-$(CONFIG_OMAP5_DSS_HDMI) += hdmi5.o hdmi5_core.o
+omapdss-$(CONFIG_OMAP5_DSS_HDMI_AUDIO) += hdmi_audio.o
 ccflags-$(CONFIG_OMAP2_DSS_DEBUG) += -DDEBUG
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h 
b/drivers/video/fbdev/omap2/dss/hdmi.h
index 927cb4d..cc6ecb5 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -25,6 +25,11 @@
 #include linux/hdmi.h
 #include video/omapdss.h
 
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) || 
defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+#include sound/dmaengine_pcm.h
+#include uapi/sound/asound.h
+#endif
+
 #include dss.h
 
 /* HDMI Wrapper */
@@ -338,6 +343,35 @@ int hdmi_parse_lanes_of(struct platform_device *pdev, 
struct device_node *ep,
struct hdmi_phy_data *phy);
 
 #if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) || 
defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+struct hdmi_audio_data {
+   /* These should be initialized when hdmi_audio_register() is called */
+   struct mutex *hdmi_lock;
+   struct hdmi_wp_data *wp;
+   struct hdmi_core_data *core;
+   struct hdmi_config *cfg;
+   struct snd_soc_dai_driver *hdmi_dai_drv;
+
+   int (*audio_start)(struct hdmi_core_data *core,
+  struct hdmi_wp_data *wp);
+   void (*audio_stop)(struct hdmi_core_data *core,
+  struct hdmi_wp_data *wp);
+   int (*audio_config)(struct hdmi_core_data *core,
+   struct hdmi_wp_data *wp,
+   struct omap_dss_audio *audio,
+   u32 pclk);
+
+   /* These are of audio implementation's private use */
+   struct snd_dmaengine_dai_dma_data dma_data;
+   struct omap_dss_audio dss_audio;
+   struct snd_aes_iec958 iec;
+   struct snd_cea_861_aud_if cea;
+   struct platform_device *codec_pdev;
+   struct platform_device *card_pdev;
+};
+
+int hdmi_audio_register(struct platform_device *pdev);
+void hdmi_audio_unregister(struct platform_device *pdev);
+
 int hdmi_compute_acr(u32 pclk, u32 sample_freq, u32 *n, u32 *cts);
 int hdmi_wp_audio_enable(struct hdmi_wp_data *wp, bool enable);
 int hdmi_wp_audio_core_req_enable(struct hdmi_wp_data *wp, bool enable);
@@ -345,9 +379,9 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp,
struct hdmi_audio_format *aud_fmt);
 void hdmi_wp_audio_config_dma(struct hdmi_wp_data *wp,
struct hdmi_audio_dma *aud_dma);
-static inline bool hdmi_mode_has_audio(int mode)
+static inline bool hdmi_mode_has_audio(struct hdmi_config *cfg)
 {
-   return mode == HDMI_HDMI ? true : false;
+   return cfg-hdmi_dvi_mode == HDMI_HDMI ? true : false;
 }
 #endif
 #endif
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_audio.c 
b/drivers/video/fbdev/omap2/dss/hdmi_audio.c
new file mode 100644
index 000..a8a0b78
--- /dev/null
+++ b/drivers/video/fbdev/omap2/dss/hdmi_audio.c
@@ -0,0 +1,317 @@
+/*
+ * OMAP4+ HDMI audio
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated
+ *
+ * Authors: Jyri Sarha jsa...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/err.h
+#include linux/string.h
+#include linux/platform_device.h
+#include sound/soc.h
+#include sound/pcm_params.h
+#include sound/dmaengine_pcm.h
+#include uapi/sound/asound.h
+#include sound/asoundef.h
+#include 

[PATCH 09/12] ASoC: omap: Remove obsolete HDMI audio code and Kconfig options

[Jyri Sarha]

Removes omap-hdmi DAI driver, omap-hdmi-card driver, the related
Kconfig options, and Makefile entries. The HDMI DAI drivers has been
integrated directly to OMAP4+ HDMI drivers and simple-card driver is
used instead of omap-hdmi-card driver.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 sound/soc/omap/Kconfig  |   13 --
 sound/soc/omap/Makefile |4 -
 sound/soc/omap/omap-hdmi-card.c |   87 --
 sound/soc/omap/omap-hdmi.c  |  364 ---
 sound/soc/omap/omap-hdmi.h  |   38 
 5 files changed, 506 deletions(-)
 delete mode 100644 sound/soc/omap/omap-hdmi-card.c
 delete mode 100644 sound/soc/omap/omap-hdmi.c
 delete mode 100644 sound/soc/omap/omap-hdmi.h

diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index d44463a..5c7b0aa 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -12,9 +12,6 @@ config SND_OMAP_SOC_MCBSP
 config SND_OMAP_SOC_MCPDM
tristate
 
-config SND_OMAP_SOC_HDMI
-   tristate
-
 config SND_OMAP_SOC_N810
tristate SoC Audio support for Nokia N810
depends on SND_OMAP_SOC  MACH_NOKIA_N810  I2C
@@ -100,16 +97,6 @@ config SND_OMAP_SOC_OMAP_ABE_TWL6040
  - PandaBoard (4430)
  - PandaBoardES (4460)
 
-config SND_OMAP_SOC_OMAP_HDMI
-   tristate SoC Audio support for Texas Instruments OMAP HDMI
-   depends on SND_OMAP_SOC  OMAP4_DSS_HDMI  OMAP2_DSS
-   select SND_OMAP_SOC_HDMI
-   select SND_SOC_HDMI_CODEC
-   select OMAP4_DSS_HDMI_AUDIO
-   help
- Say Y if you want to add support for SoC HDMI audio on Texas 
Instruments
- OMAP4 chips
-
 config SND_OMAP_SOC_OMAP3_PANDORA
tristate SoC Audio support for OMAP3 Pandora
depends on TWL4030_CORE  SND_OMAP_SOC  MACH_OMAP3_PANDORA
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index a725905..5832fe1 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -3,13 +3,11 @@ snd-soc-omap-objs := omap-pcm.o
 snd-soc-omap-dmic-objs := omap-dmic.o
 snd-soc-omap-mcbsp-objs := omap-mcbsp.o mcbsp.o
 snd-soc-omap-mcpdm-objs := omap-mcpdm.o
-snd-soc-omap-hdmi-objs := omap-hdmi.o
 
 obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o
 obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o
 obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o
 obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o
-obj-$(CONFIG_SND_OMAP_SOC_HDMI) += snd-soc-omap-hdmi.o
 
 # OMAP Machine Support
 snd-soc-n810-objs := n810.o
@@ -20,7 +18,6 @@ snd-soc-am3517evm-objs := am3517evm.o
 snd-soc-omap-abe-twl6040-objs := omap-abe-twl6040.o
 snd-soc-omap-twl4030-objs := omap-twl4030.o
 snd-soc-omap3pandora-objs := omap3pandora.o
-snd-soc-omap-hdmi-card-objs := omap-hdmi-card.o
 
 obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o
 obj-$(CONFIG_SND_OMAP_SOC_RX51) += snd-soc-rx51.o
@@ -30,4 +27,3 @@ obj-$(CONFIG_SND_OMAP_SOC_AM3517EVM) += snd-soc-am3517evm.o
 obj-$(CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040) += snd-soc-omap-abe-twl6040.o
 obj-$(CONFIG_SND_OMAP_SOC_OMAP_TWL4030) += snd-soc-omap-twl4030.o
 obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o
-obj-$(CONFIG_SND_OMAP_SOC_OMAP_HDMI) += snd-soc-omap-hdmi-card.o
diff --git a/sound/soc/omap/omap-hdmi-card.c b/sound/soc/omap/omap-hdmi-card.c
deleted file mode 100644
index f649fe8..000
--- a/sound/soc/omap/omap-hdmi-card.c
+++ /dev/null
@@ -1,87 +0,0 @@
-/*
- * omap-hdmi-card.c
- *
- * OMAP ALSA SoC machine driver for TI OMAP HDMI
- * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
- * Author: Ricardo Neri ricardo.n...@ti.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#include linux/module.h
-#include sound/pcm.h
-#include sound/soc.h
-#include asm/mach-types.h
-#include video/omapdss.h
-
-#define DRV_NAME omap-hdmi-audio
-
-static struct snd_soc_dai_link omap_hdmi_dai = {
-   .name = HDMI,
-   .stream_name = HDMI,
-   .cpu_dai_name = omap-hdmi-audio-dai,
-   .platform_name = omap-hdmi-audio-dai,
-   .codec_name = hdmi-audio-codec,
-   .codec_dai_name = hdmi-hifi,
-};
-
-static struct snd_soc_card snd_soc_omap_hdmi = {
-   .name = OMAPHDMI,
-   .owner = THIS_MODULE,
-   .dai_link = omap_hdmi_dai,
-   .num_links = 1,
-};
-
-static int omap_hdmi_probe(struct platform_device *pdev)
-{
-   struct snd_soc_card *card = 

[PATCH 03/12] OMAPDSS: hdmi_wp: Add function for getting hdmi_wp physical base address

[Jyri Sarha]

The hdmi_wp physical base address is needed for hdmi audio dma.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 drivers/video/fbdev/omap2/dss/hdmi.h|2 ++
 drivers/video/fbdev/omap2/dss/hdmi_wp.c |6 ++
 2 files changed, 8 insertions(+)

diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h 
b/drivers/video/fbdev/omap2/dss/hdmi.h
index 1f01068..927cb4d 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -250,6 +250,7 @@ struct hdmi_core_audio_config {
 
 struct hdmi_wp_data {
void __iomem *base;
+   phys_addr_t phys_base;
 };
 
 struct hdmi_pll_data {
@@ -317,6 +318,7 @@ void hdmi_wp_video_config_timing(struct hdmi_wp_data *wp,
 void hdmi_wp_init_vid_fmt_timings(struct hdmi_video_format *video_fmt,
struct omap_video_timings *timings, struct hdmi_config *param);
 int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp);
+phys_addr_t hdmi_wp_get_phys_addr(struct hdmi_wp_data *wp);
 
 /* HDMI PLL funcs */
 int hdmi_pll_enable(struct hdmi_pll_data *pll, struct hdmi_wp_data *wp);
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_wp.c 
b/drivers/video/fbdev/omap2/dss/hdmi_wp.c
index 496327e..eadd4ed 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_wp.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi_wp.c
@@ -247,6 +247,7 @@ int hdmi_wp_init(struct platform_device *pdev, struct 
hdmi_wp_data *wp)
DSSERR(can't get WP mem resource\n);
return -EINVAL;
}
+   wp-phys_base = res-start;
 
wp-base = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(wp-base)) {
@@ -256,3 +257,8 @@ int hdmi_wp_init(struct platform_device *pdev, struct 
hdmi_wp_data *wp)
 
return 0;
 }
+
+phys_addr_t hdmi_wp_get_phys_addr(struct hdmi_wp_data *wp)
+{
+   return wp-phys_base;
+}
-- 
1.7.9.5

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

[PATCH 07/12] OMAPDSS: Kconfig: Select audio dependencies if OMAP5_DSS_HDMI_AUDIO=y

[Jyri Sarha]

Adds help section and SND_SOC dependency to OMAP4_DSS_HDMI_AUDIO.
Selects SND_OMAP_SOC, SND_SOC_HDMI_CODEC, and SND_SIMPLE_CARD if
OMAP4_DSS_HDMI_AUDIO is enabled.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 drivers/video/fbdev/omap2/dss/Kconfig |   16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/Kconfig 
b/drivers/video/fbdev/omap2/dss/Kconfig
index 871f722..1cce26c 100644
--- a/drivers/video/fbdev/omap2/dss/Kconfig
+++ b/drivers/video/fbdev/omap2/dss/Kconfig
@@ -6,9 +6,9 @@ menuconfig OMAP2_DSS
select VIDEOMODE_HELPERS
select OMAP2_DSS_INIT
select HDMI
-   select SND_OMAP_SOC if OMAP4_DSS_HDMI_AUDIO
-   select SND_SOC_HDMI_CODEC if OMAP4_DSS_HDMI_AUDIO
-   select SND_SIMPLE_CARD if OMAP4_DSS_HDMI_AUDIO
+   select SND_OMAP_SOC if OMAP4_DSS_HDMI_AUDIO || OMAP5_DSS_HDMI_AUDIO
+   select SND_SOC_HDMI_CODEC if OMAP4_DSS_HDMI_AUDIO || 
OMAP5_DSS_HDMI_AUDIO
+   select SND_SIMPLE_CARD if OMAP4_DSS_HDMI_AUDIO || OMAP5_DSS_HDMI_AUDIO
 help
  OMAP2+ Display Subsystem support.
 
@@ -99,8 +99,16 @@ config OMAP5_DSS_HDMI
  specification.
 
 config OMAP5_DSS_HDMI_AUDIO
+   bool HDMI audio support for OMAP5
depends on OMAP5_DSS_HDMI
-   bool
+   depends on SND_SOC=y || OMAP2_DSS = SND_SOC
+   default y
+   help
+ HDMI audio support for OMAP5 based SoCs. Adds integrated
+ ASoC Digital Audio Interface component driver into OMAPDSS
+ module. If enabled OMAP2_DSS selects SND_OMAP_SOC,
+ SND_SOC_HDMI_CODEC, and SND_SIMPLE_CARD for full HDMI
+ audio support.
 
 config OMAP2_DSS_SDI
bool SDI support
-- 
1.7.9.5

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

[PATCH 06/12] OMAPDSS: hdmi4: Register HDMI audio ASoC drivers from HDMI driver

[Jyri Sarha]

Add audio datamember to hdmi struct and call register and unregister
functions form hdmi_audio.c. Register function registers the
integrated cpu dai, dummy HDMI codec, and simple-card machine driver
for complete HDMI audio support.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 drivers/video/fbdev/omap2/dss/hdmi4.c |   45 +
 1 file changed, 45 insertions(+)

diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c 
b/drivers/video/fbdev/omap2/dss/hdmi4.c
index 342ddb4..48f11f8 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4.c
@@ -34,6 +34,11 @@
 #include linux/regulator/consumer.h
 #include video/omapdss.h
 
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+#include sound/soc.h
+#include sound/soc-dai.h
+#endif
+
 #include hdmi4_core.h
 #include dss.h
 #include dss_features.h
@@ -52,6 +57,9 @@ static struct {
struct clk *sys_clk;
struct regulator *vdda_hdmi_dac_reg;
 
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+   struct hdmi_audio_data audio;
+#endif
bool core_enabled;
 
struct omap_dss_device output;
@@ -671,6 +679,21 @@ err:
return r;
 }
 
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+static struct snd_soc_dai_driver omap_hdmi_dai = {
+   .name = omap4-hdmi-dai,
+   .playback = {
+   .channels_min = 2,
+   .channels_max = 8,
+   .rates = (SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |
+ SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_88200 |
+ SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_176400 |
+ SNDRV_PCM_RATE_192000),
+   .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE,
+   },
+};
+#endif
+
 /* HDMI HW IP initialisation */
 static int omapdss_hdmihw_probe(struct platform_device *pdev)
 {
@@ -727,6 +750,25 @@ static int omapdss_hdmihw_probe(struct platform_device 
*pdev)
 
hdmi_init_output(pdev);
 
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+   /* drvdata is only used by HDMI audio */
+   hdmi.audio.hdmi_lock = hdmi.lock;
+   hdmi.audio.wp = hdmi.wp;
+   hdmi.audio.core = hdmi.core;
+   hdmi.audio.cfg = hdmi.cfg;
+   hdmi.audio.hdmi_dai_drv = omap_hdmi_dai;
+   hdmi.audio.audio_start = hdmi4_audio_start;
+   hdmi.audio.audio_stop = hdmi4_audio_stop;
+   hdmi.audio.audio_config = hdmi4_audio_config;
+   dev_set_drvdata(pdev-dev, hdmi.audio);
+   r = hdmi_audio_register(pdev);
+   if (r) {
+   DSSERR(Registering HDMI audio failed\n);
+   hdmi_uninit_output(pdev);
+   pm_runtime_disable(pdev-dev);
+   return r;
+   }
+#endif
dss_debugfs_create_file(hdmi, hdmi_dump_regs);
 
return 0;
@@ -734,6 +776,9 @@ static int omapdss_hdmihw_probe(struct platform_device 
*pdev)
 
 static int __exit omapdss_hdmihw_remove(struct platform_device *pdev)
 {
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+   hdmi_audio_unregister(pdev);
+#endif
hdmi_uninit_output(pdev);
 
pm_runtime_disable(pdev-dev);
-- 
1.7.9.5

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

Please ignore this orphan patch.

[Jyri Sarha]

Best regards,
Jyri
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Guido Martínez]

Hi Pekon,

On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
 Beaglebone Board can be connected to expansion boards to add devices to them.
 These expansion boards are called 'capes'. This patch adds support for
 following versions of Beaglebone(AM335x) NAND capes
 (a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
 (b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224
 Further information and datasheets can be found at [1] and [2]
 
 * How to boot from NAND using Memory Expander + NAND Cape ? *
  - Important: As BOOTSEL values are sampled only at POR, so after changing any
setting on SW2 (DIP switch), disconnect and reconnect all board power 
 supply
(including mini-USB console port) to POR the beaglebone.
 
  - Selection of ECC scheme
   for NAND cape(a), ROM code expects BCH8_HW ecc-scheme
   for NAND cape(b), ROM code expects BCH16_HW ecc-scheme
 
  - Selection of boot modes can be controlled via  DIP switch(SW2) present on
Memory Expander cape, so first boot via MMC or other sources to flash NAND
device and then switch to SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
SW2[SWITCH_BOOT] == OFF  follow default boot order  MMC- SPI - UART - 
 USB
SW2[SWITCH_BOOT] == ON   boot mode selected via DIP switch(SW2)
 
  - For NAND boot following switch settings need to be followed
SW2[ 1] = ON   (SYSBOOT[ 0]==0: NAND boot mode selected )
SW2[ 2] = ON   (SYSBOOT[ 1]==0:   -- do --  )
SW2[ 3] = OFF  (SYSBOOT[ 2]==1:   -- do --  )
SW2[ 4] = OFF  (SYSBOOT[ 3]==1:   -- do --  )
SW2[ 5] = ON   (SYSBOOT[ 4]==0:   -- do --  )
SW2[ 6] = OFF  (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
SW2[ 7] = ON   (SYSBOOT[ 9]==0: ECC done by ROM  )
SW2[ 8] = ON   (SYSBOOT[10]==0: Non Muxed device )
SW2[ 9] = ON   (SYSBOOT[11]==0:-- do --  )
 
 [1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
 [2] 
 http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module
 
 Signed-off-by: Pekon Gupta pe...@ti.com
 Reviewed-by: Javier Martinez Canillas jav...@dowhile0.org
 ---
  arch/arm/boot/dts/am335x-bone-memory-cape.dts | 127 
 ++
  arch/arm/boot/dts/am335x-bone.dts |   1 +
  arch/arm/boot/dts/am335x-boneblack.dts|   1 +
  3 files changed, 129 insertions(+)
  create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts
 
 diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts 
 b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
 new file mode 100644
 index 000..6d8ebd8
 --- /dev/null
 +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
 @@ -0,0 +1,127 @@
 +/*
 + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * 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 DTS adds supports for capes using GPMC interface to connect external
 + * memory like NAND, NOR Flash to Beaglebone-White and Beaglebone-Black.
 + */
 +
 +
 +am33xx_pinmux {
 + bbcape_nand_flash_pins: bbcape_nand_flash_pins {
 + pinctrl-single,pins = 
 + 0x00 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad0.gpmc_ad0 */
 + 0x04 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad1.gpmc_ad1 */
 + 0x08 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad2.gpmc_ad2 */
 + 0x0c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad3.gpmc_ad3 */
 + 0x10 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad4.gpmc_ad4 */
 + 0x14 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad5.gpmc_ad5 */
 + 0x18 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad6.gpmc_ad6 */
 + 0x1c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad7.gpmc_ad7 */
 + 0x20 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad8.gpmc_ad8 */
 + 0x24 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad9.gpmc_ad9 */
 + 0x28 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad10.gpmc_ad10 
 */
 + 0x2c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad11.gpmc_ad11 
 */
 + 0x30 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad12.gpmc_ad12 
 */
 + 0x34 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad13.gpmc_ad13 
 */
 + 0x38 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad14.gpmc_ad14 
 */
 + 0x3c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad15.gpmc_ad15 
 */
 + 0x70 (MUX_MODE0 | PIN_INPUT_PULLUP )/* 
 gpmc_wait0.gpmc_wait0 */
 + 0x74 (MUX_MODE0 | PIN_OUTPUT_PULLUP)/* 
 gpmc_wpn.gpmc_wpn */
 + 0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP)/* 
 gpmc_csn0.gpmc_csn0  */
 + 0x90 (MUX_MODE0 | PIN_OUTPUT)   /* 
 gpmc_advn_ale.gpmc_advn_ale */
 + 0x94 (MUX_MODE0 | 

Re: [PATCH 2/7] mailbox/omap: remove OMAP1 mailbox driver

[Aaro Koskinen]

Hi,

On Thu, Jun 26, 2014 at 03:28:14AM -0700, Tony Lindgren wrote:
 * Suman Anna s-a...@ti.com [140624 17:45]:
  There are no existing users for OMAP1 mailbox driver
  in kernel. Commit ab6f775 Removing dead OMAP_DSP
  has cleaned up all the dead code related to the only
  possible user, including the creation of the mailbox
  platform device.
  
  Remove this stale driver so that the OMAP mailbox
  driver can be simplified and streamlined better for
  converting to mailbox framework.
  
  Cc: Aaro Koskinen aaro.koski...@iki.fi
  Signed-off-by: Suman Anna s-a...@ti.com
 
 For the omap1_defconfig change:
 
 Acked-by: Tony Lindgren t...@atomide.com

I'm also OK with this change.

Acked-by: Aaro Koskinen aaro.koski...@iki.fi

A.
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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] staging: tidspbridge: fix an erroneous removal of parentheses

[Greg Kroah-Hartman]

On Tue, Jun 24, 2014 at 12:24:25AM -0500, Suman Anna wrote:
 Commit 4a9fdbb (staging: core: tiomap3430.c Fix line over 80 characters.)
 erroneously removed the parentheses around the function pointer leading
 to the following build error (when enabling the build of TI DSP/Bridge
 driver):
 
 drivers/staging/tidspbridge/core/tiomap3430.c: In function 
 'bridge_brd_monitor':
 drivers/staging/tidspbridge/core/tiomap3430.c:283:10: error: invalid type 
 argument of unary '*' (have 'u32')
 make[3]: *** [drivers/staging/tidspbridge/core/tiomap3430.o] Error 1
 
 Fix this build error properly.

This shows that no one really uses this driver :(

Can't we just delete the thing?

I'll go queue this up for 3.16-final, thanks.

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