[PATCH RFC v2 1/2] ASoC: core: Update snd_soc_of_parse_daifmt() interface
Adds struct device_node **bitclkmaster and struct device_node **framemaster
function parameters. With the new syntax bitclock-master and frame-master
properties can explicitly indicate the dai-link bit-clock and frame masters
with a phandle. This patch also makes the minimal changes to simple-card
for it to work with the updated snd_soc_of_parse_daifmt(). Simple-card appears
to be the only user of snd_soc_of_parse_daifmt() for now.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
include/sound/soc.h |4 +++-
sound/soc/generic/simple-card.c |4 ++--
sound/soc/soc-core.c|8 +++-
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index f7de629..e40713a 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1228,7 +1228,9 @@ int snd_soc_of_parse_tdm_slot(struct device_node *np,
int snd_soc_of_parse_audio_routing(struct snd_soc_card *card,
const char *propname);
unsigned int snd_soc_of_parse_daifmt(struct device_node *np,
-const char *prefix);
+const char *prefix,
+struct device_node **bitclkmaster,
+struct device_node **framemaster);
int snd_soc_of_get_dai_name(struct device_node *of_node,
const char **dai_name);
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 21f1ccb..e0cc53b 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -121,7 +121,7 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
* bitclock-master,frame-master
* and specific format if it has
*/
- dai-fmt = snd_soc_of_parse_daifmt(np, NULL);
+ dai-fmt = snd_soc_of_parse_daifmt(np, NULL, NULL, NULL);
dai-fmt |= daifmt;
/*
@@ -201,7 +201,7 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
snd_soc_of_parse_card_name(priv-snd_card, simple-audio-card,name);
/* get CPU/CODEC common format via simple-audio-card,format */
- daifmt = snd_soc_of_parse_daifmt(node, simple-audio-card,)
+ daifmt = snd_soc_of_parse_daifmt(node, simple-audio-card,, NULL,
NULL)
(SND_SOC_DAIFMT_FORMAT_MASK | SND_SOC_DAIFMT_INV_MASK);
/* off-codec widgets */
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index b322cf2..7979dcc 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -4560,7 +4560,9 @@ int snd_soc_of_parse_audio_routing(struct snd_soc_card
*card,
EXPORT_SYMBOL_GPL(snd_soc_of_parse_audio_routing);
unsigned int snd_soc_of_parse_daifmt(struct device_node *np,
-const char *prefix)
+const char *prefix,
+struct device_node **bitclkmaster,
+struct device_node **framemaster)
{
int ret, i;
char prop[128];
@@ -4643,9 +4645,13 @@ unsigned int snd_soc_of_parse_daifmt(struct device_node
*np,
*/
snprintf(prop, sizeof(prop), %sbitclock-master, prefix);
bit = !!of_get_property(np, prop, NULL);
+ if (bit bitclkmaster)
+ *bitclkmaster = of_parse_phandle(np, prop, 0);
snprintf(prop, sizeof(prop), %sframe-master, prefix);
frame = !!of_get_property(np, prop, NULL);
+ if (frame framemaster)
+ *framemaster = of_parse_phandle(np, prop, 0);
switch ((bit 4) + frame) {
case 0x11:
--
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 RFC v2 2/2] ASoC: simple-card: Move dai-link level properties away from dai subnodes
The properties like format, bitclock-master, frame-master, bitclock-inversion, and frame-inversion should be common to the dais connected with a dai-link. For bitclock-master and frame-master properties to be unambiguous they need to indicate the mastering dai node with a phandle. Signed-off-by: Jyri Sarha jsa...@ti.com --- .../devicetree/bindings/sound/simple-card.txt | 88 sound/soc/generic/simple-card.c| 236 2 files changed, 188 insertions(+), 136 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt index 131aa2a..59b842b 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.txt +++ b/Documentation/devicetree/bindings/sound/simple-card.txt @@ -1,6 +1,6 @@ Simple-Card: -Simple-Card specifies audio DAI connection of SoC - codec. +Simple-Card specifies audio DAI connections of SoC - codec. Required properties: @@ -10,26 +10,51 @@ Optional properties: - simple-audio-card,name : User specified audio sound card name, one string property. -- simple-audio-card,format : CPU/CODEC common audio format. - i2s, right_j, left_j , dsp_a - dsp_b, ac97, pdm, msb, lsb - simple-audio-card,widgets: Please refer to widgets.txt. - simple-audio-card,routing: A list of the connections between audio components. Each entry is a pair of strings, the first being the connection's sink, the second being the connection's source. -- dai-tdm-slot-num : Please refer to tdm-slot.txt. -- dai-tdm-slot-width : Please refer to tdm-slot.txt. +Optional subnodes: + +- simple-audio-card,dai-link : Container for dai-link level + properties and the CPU and CODEC + sub-nodes. This container may be + omitted when the card has only one + DAI link. See the examples and the + section bellow. + +Dai-link subnode properties and subnodes: + +If dai-link subnode is omitted and the subnode properties are directly +under sound-node the subnode property and subnode names have to be +prefixed with simple-audio-card,-prefix. -Required subnodes: +Required dai-link subnodes: -- simple-audio-card,dai-link : container for the CPU and CODEC sub-nodes - This container may be omitted when the - card has only one DAI link. - See the examples. +- cpu : CPU sub-node +- codec: CODEC sub-node -- simple-audio-card,cpu: CPU sub-node -- simple-audio-card,codec : CODEC sub-node +Optional dai-link subnode properties: + +- format : CPU/CODEC common audio format. + i2s, right_j, left_j , dsp_a + dsp_b, ac97, pdm, msb, lsb +- frame-master : Indicates dai-link frame master. + phandle to a cpu or codec subnode. +- bitclock-master : Indicates dai-link bit clock master. + phandle to a cpu or codec subnode. +- bitclock-inversion : bool property. Add this if the + dai-link uses bit clock inversion. +- frame-inversion : bool property. Add this if the + dai-link uses frame clock inversion. + +For backward compatibility the frame-master and bitclock-master +properties can be used as booleans in codec subnode to indicate if the +codec is the dai-link frame or bit clock master. In this case the same +properties should not be present at dai-link level and the +bitclock-inversion and frame-inversion properties should also be placed +in the codec node if needed. Required CPU/CODEC subnodes properties: @@ -37,29 +62,21 @@ Required CPU/CODEC subnodes properties: Optional CPU/CODEC subnodes properties: -- format : CPU/CODEC specific audio format if needed. - see simple-audio-card,format -- frame-master : bool property. add this if subnode is frame master -- bitclock-master : bool property. add this if subnode is bitclock master -- bitclock-inversion
[PATCH RFC v2 0/2] Move dai-link level properties away from dai subnodes
This patch is implemented on top of late patches from Jean-Francois Moine [1]. These patches implement the main part of the simple-card changes discussed in alsa-devel mailing list [2]. Since RFC version of the patches: - ASoC: core: Update snd_soc_of_parse_daifmt() interface - Make minimal changes to simple-card for it to work with the updated snd_soc_of_parse_daifmt(). (Kuninori Morimoto's comment [3]). - ASoC: simple-card: Move dai-link level properties away from dai subnodes - Fix typo in DT binding document (Jean-Francois Moine's comment [4]). - Remove #define DEBUG - Remove accidental line wrap at simple-audio-card,name property descripition in the DT binding document [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/074592.html [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/074388.html [3] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/074699.html [4] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/074697.html Best regards, Jyri Jyri Sarha (2): ASoC: core: Update snd_soc_of_parse_daifmt() interface ASoC: simple-card: Move dai-link level properties away from dai subnodes .../devicetree/bindings/sound/simple-card.txt | 88 include/sound/soc.h|4 +- sound/soc/generic/simple-card.c| 236 sound/soc/soc-core.c |8 +- 4 files changed, 198 insertions(+), 138 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
Re: [PATCH RFC 2/2] ASoC: simple-card: Move dai-link level properties away from dai subnodes
On 03/23/2014 11:54 AM, Jean-Francois Moine wrote:
On Fri, 21 Mar 2014 18:47:23 +0200
Jyri Sarha jsa...@ti.com wrote:
The properties like format, bitclock-master, frame-master,
bitclock-inversion, and frame-inversion should be common to the dais
connected with a dai-link. For bitclock-master and frame-master
properties to be unambiguous they need to indicate the mastering dai
node with a phandle.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
[...]
-Required subnodes:
+Requred dai-link subnodes:
Typo: 'Required'
Fixed. Thanks!
[...]
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -8,6 +8,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#define DEBUG
Should be removed.
Removed. Thanks!
[...]
+ if (!bitclkmaster !framemaster) {
+ /* Master setting not found from dai_link level, revert back
+ to legacy DT parsing and take settings from codec node. */
+ dev_dbg(dev, %s: Revert to legacy daifmt parsing\n,
+ __func__);
+ dai_props-cpu_dai.fmt = dai_props-codec_dai.fmt =
+ snd_soc_of_parse_daifmt(np, NULL, NULL, NULL) |
+ (daifmt ~SND_SOC_DAIFMT_CLOCK_MASK);
We are here each time there is no bitclock-master and no frame-master,
i.e. each time for me. It could be simpler to keep the first 'daifmt'
instead of parsing again.
Sorry, I missed this and comments bellow first time around. I'll make
another patch set shortly.
Adding another check to test if we are parsing top level sound node
would save you from the legacy mode parsing. I'll do that and update the
DT binding document accordingly.
[...]
+ if (multi) {
+ struct device_node *np = NULL;
+ int i;
+ for (i = 0; (np = of_get_next_child(node, np)); i++) {
+ dev_dbg(dev, \tlink %d:\n, i);
+ ret = simple_card_dai_link_of(np, dev, dai_link + i,
+ dai_props + i);
I feel that my loop was quicker:
I was targeting for readability rather than speed. I doubt the
difference is significant since most string processing is anyway taking
most of the time anyway.
struct device_node *np = NULL;
for (;;) {
np = of_get_next_child(node, np);
if (!np)
break;
dev_dbg(dev, \tlink %d:\n, dai_link -
priv-snd_card.dai_link);
ret = simple_card_dai_link_of(np, dev, dai_link++,
dai_props++);
+ of_node_put(np);
+ if (ret 0)
+ return ret;
The np reference count is updated in of_get_next_child(), so:
if (ret 0) {
of_node_put(np);
return ret;
}
Oops, need to fix that. Thanks !
Otherwise, it works for me.
Tested-by: Jean-Francois Moine moin...@free.fr
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 v9 resend 1/3] mmc: omap_hsmmc: Enable SDIO interrupt
Hi,
I've tested the branch omap_hsmmc_sdio_irq_devm_cleanup on custom OMAP5
based board.
We have mwifiex connected to MMC3.
I used two approaches:
* Using dat1 line as GPIO with dynamic remuxing
* Using separate GPIO connected to dat1 with static mux settings
Both works just fine. Thanks Andreas for a great solution.
I have just one issue - how to define GPIO IRQ using DT in OMAP5 case.
As a temporary hack for testing I used a fixed GPIO number and
gpio_to_irq() call in omap_hsmmc_configure_wake_irq().
OMAP5 MMC3 has the following DT entry (omap5.dtsi):
mmc3: mmc@480ad000 {
compatible = ti,omap4-hsmmc;
reg = 0x480ad000 0x400;
interrupts = GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mmc3;
ti,needs-special-reset;
dmas = sdma 77, sdma 78;
dma-names = tx, rx;
};
What should be by board MMC3 setup?
Something like this?
mmc3 {
pinctrl-names = default, active, idle;
pinctrl-0 = mmc3_pins;
pinctrl-1 = mmc3_pins;
pinctrl-2 = mmc3_cirq_pin;
interrupts = GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH,
;
vmmc-supply = ldo2_reg;
bus-width = 4;
ti,non-removable;
};
I tried to specify the second interrupt as (wlsdio_data1 / gpio5_131):
gpio5 3 IRQ_TYPE_NONE
but it fails:
[2.275777] [ cut here ]
[2.280604] WARNING: CPU: 1 PID: 6 at
/home/lifshitz/workroot/OMAP5-eewiki/omap5-kernel/kernel/irq/manage.c:1418
request_threaded_irq+0x11c/0x12c()
[2.294414] Modules linked in:
[2.297611] CPU: 1 PID: 6 Comm: kworker/u4:0 Tainted: G W
3.14.0-rc4-cm-t54-test-suit+ #30
[2.307165] Workqueue: deferwq deferred_probe_work_func
[2.312629] [c001597c] (unwind_backtrace) from [c001283c]
(show_stack+0x10/0x14)
[2.320739] [c001283c] (show_stack) from [c06494dc]
(dump_stack+0x70/0x88)
[2.328294] [c06494dc] (dump_stack) from [c003a520]
(warn_slowpath_common+0x70/0x88)
[2.336761] [c003a520] (warn_slowpath_common) from [c003a554]
(warn_slowpath_null+0x1c/0x24)
[2.345940] [c003a554] (warn_slowpath_null) from [c0083ce4]
(request_threaded_irq+0x11c/0x12c)
[2.355312] [c0083ce4] (request_threaded_irq) from [c0085964]
(devm_request_threaded_irq+0x5c/0x90)
[2.361973] mmc1: host does not support reading read-only switch.
assuming write-enable.
[2.362020] mmc1: new SDHC card at address e624
[2.362331] mmcblk1: mmc1:e624 SU08G 7.40 GiB
[2.368152] mmcblk1: p1 p2
[2.385850] [c0085964] (devm_request_threaded_irq) from
[c047d958] (omap_hsmmc_configure_wake_irq+0x7c/0xfc)
[2.393150] usb 1-2: New USB device found, idVendor=0424, idProduct=3503
[2.393156] usb 1-2: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[2.393674] hub 1-2:1.0: USB hub found
[2.393769] hub 1-2:1.0: 3 ports detected
[2.419038] [c047d958] (omap_hsmmc_configure_wake_irq) from
[c047ea28] (omap_hsmmc_probe+0x5b4/0x854)
[2.429052] [c047ea28] (omap_hsmmc_probe) from [c0359ec0]
(platform_drv_probe+0x18/0x48)
[2.437879] [c0359ec0] (platform_drv_probe) from [c03580c8]
(really_probe+0x80/0x208)
[2.446427] [c03580c8] (really_probe) from [c0358360]
(driver_probe_device+0x30/0x48)
[2.454976] [c0358360] (driver_probe_device) from [c0356a58]
(bus_for_each_drv+0x5c/0x88)
[2.463891] [c0356a58] (bus_for_each_drv) from [c03582f4]
(device_attach+0x80/0xa0)
[2.472247] [c03582f4] (device_attach) from [c03577b4]
(bus_probe_device+0x84/0xa8)
[2.480617] [c03577b4] (bus_probe_device) from [c0357bb8]
(deferred_probe_work_func+0x68/0x98)
[2.489987] [c0357bb8] (deferred_probe_work_func) from [c00533c0]
(process_one_work+0x150/0x41c)
[2.499542] [c00533c0] (process_one_work) from [c0053d10]
(worker_thread+0xf4/0x31c)
[2.508011] [c0053d10] (worker_thread) from [c0059994]
(kthread+0xd4/0xe8)
[2.512785] usb 1-3: new high-speed USB device number 3 using ehci-omap
[2.522474] [c0059994] (kthread) from [c000e878]
(ret_from_fork+0x14/0x3c)
[2.530023] ---[ end trace 8d60f1d3adba88d7 ]---
Regards,
Dmitry
On 03/21/2014 06:10 PM, Balaji T K wrote:
On Friday 21 March 2014 05:50 PM, Andreas Fenkart wrote:
Thanks Andreas for the patch series
I rebased against latest mmc-next, made few changes to your patch.
I have hosted your series along with devm cleanups on a branch[1] for
testing
[1]
git://git.ti.com/~balajitk/ti-linux-kernel/omap-hsmmc.git
omap_hsmmc_sdio_irq_devm_cleanup
Can you please test on your platform and provide feedback.
Details about the changes below.
--
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: [alsa-devel] [PATCH RFC 2/2] ASoC: simple-card: Move dai-link level properties away from dai subnodes
On 03/24/2014 02:05 AM, Kuninori Morimoto wrote:
Hi Jyri
The properties like format, bitclock-master, frame-master,
bitclock-inversion, and frame-inversion should be common to the dais
connected with a dai-link. For bitclock-master and frame-master
properties to be unambiguous they need to indicate the mastering dai
node with a phandle.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
(snip)
/*
-* bitclock-inversion, frame-inversion
-* bitclock-master,frame-master
-* and specific format if it has
-*/
- dai-fmt = snd_soc_of_parse_daifmt(np, NULL);
- dai-fmt |= daifmt;
-
- /*
* dai-sysclk come from
* clocks = xxx (if system has common clock)
* or system-clock-frequency = xxx
[1/2] patch exchanged snd_soc_of_parse_daifmt() parameter,
but, user code exchanged in [2/2].
It breaks git-bisect.
Fixed that. Thanks!
+ dai_props-cpu_dai.fmt = daifmt;
+ switch (((np == bitclkmaster)4)|(np == framemaster)) {
+ case 0x11:
+ dai_props-cpu_dai.fmt |= SND_SOC_DAIFMT_CBS_CFS;
+ break;
+ case 0x10:
+ dai_props-cpu_dai.fmt |= SND_SOC_DAIFMT_CBS_CFM;
+ break;
+ case 0x01:
+ dai_props-cpu_dai.fmt |= SND_SOC_DAIFMT_CBM_CFS;
+ break;
+ default:
+ dai_props-cpu_dai.fmt |= SND_SOC_DAIFMT_CBM_CFM;
+ break;
+ }
The user of snd_soc_of_parse_daifmt() is only simple-card (?)
I think SND_SOC_DAIFMT_CBxx_CFx cared by snd_soc_of_parse_daifmt() somehow
is very reasonable.
Yes, that is what git grep tells me. snd_soc_of_parse_daifmt() can still
take care of SND_SOC_DAIFMT_CB?_CF? parsing in simple cases. I just felt
that adding the full phandle parsing to the function would break its
genericity and make the function parameters hard to understand.
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 RFC v3 1/2] ASoC: core: Update snd_soc_of_parse_daifmt() interface
Adds struct device_node **bitclkmaster and struct device_node **framemaster
function parameters. With the new syntax bitclock-master and frame-master
properties can explicitly indicate the dai-link bit-clock and frame masters
with a phandle. This patch also makes the minimal changes to simple-card
for it to work with the updated snd_soc_of_parse_daifmt(). Simple-card appears
to be the only user of snd_soc_of_parse_daifmt() for now.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
include/sound/soc.h |4 +++-
sound/soc/generic/simple-card.c |5 +++--
sound/soc/soc-core.c|8 +++-
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index f7de629..e40713a 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1228,7 +1228,9 @@ int snd_soc_of_parse_tdm_slot(struct device_node *np,
int snd_soc_of_parse_audio_routing(struct snd_soc_card *card,
const char *propname);
unsigned int snd_soc_of_parse_daifmt(struct device_node *np,
-const char *prefix);
+const char *prefix,
+struct device_node **bitclkmaster,
+struct device_node **framemaster);
int snd_soc_of_get_dai_name(struct device_node *of_node,
const char **dai_name);
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 21f1ccb..835fd02 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -121,7 +121,7 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
* bitclock-master,frame-master
* and specific format if it has
*/
- dai-fmt = snd_soc_of_parse_daifmt(np, NULL);
+ dai-fmt = snd_soc_of_parse_daifmt(np, NULL, NULL, NULL);
dai-fmt |= daifmt;
/*
@@ -201,7 +201,8 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
snd_soc_of_parse_card_name(priv-snd_card, simple-audio-card,name);
/* get CPU/CODEC common format via simple-audio-card,format */
- daifmt = snd_soc_of_parse_daifmt(node, simple-audio-card,)
+ daifmt = snd_soc_of_parse_daifmt(node, simple-audio-card,, NULL,
+NULL)
(SND_SOC_DAIFMT_FORMAT_MASK | SND_SOC_DAIFMT_INV_MASK);
/* off-codec widgets */
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index b322cf2..7979dcc 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -4560,7 +4560,9 @@ int snd_soc_of_parse_audio_routing(struct snd_soc_card
*card,
EXPORT_SYMBOL_GPL(snd_soc_of_parse_audio_routing);
unsigned int snd_soc_of_parse_daifmt(struct device_node *np,
-const char *prefix)
+const char *prefix,
+struct device_node **bitclkmaster,
+struct device_node **framemaster)
{
int ret, i;
char prop[128];
@@ -4643,9 +4645,13 @@ unsigned int snd_soc_of_parse_daifmt(struct device_node
*np,
*/
snprintf(prop, sizeof(prop), %sbitclock-master, prefix);
bit = !!of_get_property(np, prop, NULL);
+ if (bit bitclkmaster)
+ *bitclkmaster = of_parse_phandle(np, prop, 0);
snprintf(prop, sizeof(prop), %sframe-master, prefix);
frame = !!of_get_property(np, prop, NULL);
+ if (frame framemaster)
+ *framemaster = of_parse_phandle(np, prop, 0);
switch ((bit 4) + frame) {
case 0x11:
--
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 RFC v3 2/2] ASoC: simple-card: Move dai-link level properties away from dai subnodes
The properties like format, bitclock-master, frame-master, bitclock-inversion, and frame-inversion should be common to the dais connected with a dai-link. For bitclock-master and frame-master properties to be unambiguous they need to indicate the mastering dai node with a phandle. Signed-off-by: Jyri Sarha jsa...@ti.com --- .../devicetree/bindings/sound/simple-card.txt | 88 +++ sound/soc/generic/simple-card.c| 239 2 files changed, 190 insertions(+), 137 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt index 131aa2a..9b9df14 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.txt +++ b/Documentation/devicetree/bindings/sound/simple-card.txt @@ -1,6 +1,6 @@ Simple-Card: -Simple-Card specifies audio DAI connection of SoC - codec. +Simple-Card specifies audio DAI connections of SoC - codec. Required properties: @@ -10,26 +10,51 @@ Optional properties: - simple-audio-card,name : User specified audio sound card name, one string property. -- simple-audio-card,format : CPU/CODEC common audio format. - i2s, right_j, left_j , dsp_a - dsp_b, ac97, pdm, msb, lsb - simple-audio-card,widgets: Please refer to widgets.txt. - simple-audio-card,routing: A list of the connections between audio components. Each entry is a pair of strings, the first being the connection's sink, the second being the connection's source. -- dai-tdm-slot-num : Please refer to tdm-slot.txt. -- dai-tdm-slot-width : Please refer to tdm-slot.txt. +Optional subnodes: + +- simple-audio-card,dai-link : Container for dai-link level + properties and the CPU and CODEC + sub-nodes. This container may be + omitted when the card has only one + DAI link. See the examples and the + section bellow. + +Dai-link subnode properties and subnodes: + +If dai-link subnode is omitted and the subnode properties are directly +under sound-node the subnode property and subnode names have to be +prefixed with simple-audio-card,-prefix. -Required subnodes: +Required dai-link subnodes: -- simple-audio-card,dai-link : container for the CPU and CODEC sub-nodes - This container may be omitted when the - card has only one DAI link. - See the examples. +- cpu : CPU sub-node +- codec: CODEC sub-node -- simple-audio-card,cpu: CPU sub-node -- simple-audio-card,codec : CODEC sub-node +Optional dai-link subnode properties: + +- format : CPU/CODEC common audio format. + i2s, right_j, left_j , dsp_a + dsp_b, ac97, pdm, msb, lsb +- frame-master : Indicates dai-link frame master. + phandle to a cpu or codec subnode. +- bitclock-master : Indicates dai-link bit clock master. + phandle to a cpu or codec subnode. +- bitclock-inversion : bool property. Add this if the + dai-link uses bit clock inversion. +- frame-inversion : bool property. Add this if the + dai-link uses frame clock inversion. + +For backward compatibility the frame-master and bitclock-master +properties can be used as booleans in codec subnode to indicate if the +codec is the dai-link frame or bit clock master. In this case there +should be no dai-link node, the same properties should not be present +at sound-node level, and the bitclock-inversion and frame-inversion +properties should also be placed in the codec node if needed. Required CPU/CODEC subnodes properties: @@ -37,29 +62,21 @@ Required CPU/CODEC subnodes properties: Optional CPU/CODEC subnodes properties: -- format : CPU/CODEC specific audio format if needed. - see simple-audio-card,format -- frame-master : bool property. add this if subnode is frame master -- bitclock-master : bool property. add this if subnode is bitclock master --
[PATCH RFC v3 0/2] Move dai-link level properties away from dai subnodes
This patch is implemented on top of late patches from Jean-Francois Moine [1]. These patches implement the main part of the simple-card changes discussed in alsa-devel mailing list [2]. Since RFC v2 version of the patches, address remaining comments from Jean-Francois Moine [4]: - ASoC: simple-card: Move dai-link level properties away from dai subnodes - Only allow legacy parsing if there is no dai-link node. - Fix double unref in of_card parsing loop. Since RFC version of the patches: - ASoC: core: Update snd_soc_of_parse_daifmt() interface - Make minimal changes to simple-card for it to work with the updated snd_soc_of_parse_daifmt(). (Kuninori Morimoto's comment [3]). - ASoC: simple-card: Move dai-link level properties away from dai subnodes - Fix typo in DT binding document (Jean-Francois Moine's comment [4]). - Remove #define DEBUG - Remove accidental line wrap at simple-audio-card,name property descripition in the DT binding document [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/074592.html [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/074388.html [3] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/074699.html [4] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/074697.html Best regards, Jyri Jyri Sarha (2): ASoC: core: Update snd_soc_of_parse_daifmt() interface ASoC: simple-card: Move dai-link level properties away from dai subnodes .../devicetree/bindings/sound/simple-card.txt | 88 include/sound/soc.h|4 +- sound/soc/generic/simple-card.c| 238 sound/soc/soc-core.c |8 +- 4 files changed, 200 insertions(+), 138 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 V3 0/6] Add Display support for AM43xx
This patch series adds DSS support to the AM43x. The DPI LCD panel is supported on both am43x-epos-evm and am437x-gp-evm. The LCD panel is from OSD model: OSD057T0559-34TS Version 1 of this series can be found below[1]: [1]: https://patchwork.kernel.org/patch/3274421/ Tested on am43x-epos-evm and am437x-gp-evm. Dependent patches : Sourav patches adding device nodes for epos [2] and gp [3] evm [2]: https://patchwork.kernel.org/patch/3246701/ [3]: https://patchwork.kernel.org/patch/3246751/ AM43xx has a dedicated display pll. Hence tomi patch improving func clock handling is needed [4] [4]: https://patchwork.kernel.org/patch/3196221/ Tomi patch adding DT support to DSS [5] [5]: https://patchwork.kernel.org/patch/3516341/ Changes from V2: fixed minor comments on dt changes and added missing signoff Sathya Prakash M R (5): OMAPDSS: Add DSS features for AM43xx ARM: OMAP2+: AM43xx DSS Hwmod ARM: am43xx-clocks.dtsi: Set parent for disp_clk ARM: am4372.dtsi: add omapdss information ARM: DTS: AM43xx: Add DSS nodes Tomi Valkeinen (1): ARM: AM43xx: fix dpll init in bypass mode arch/arm/boot/dts/am4372.dtsi | 35 ++ arch/arm/boot/dts/am437x-gp-evm.dts| 77 arch/arm/boot/dts/am43x-epos-evm.dts | 73 +++ arch/arm/boot/dts/am43xx-clocks.dtsi |2 + arch/arm/mach-omap2/clkt_dpll.c|4 +- arch/arm/mach-omap2/display.c |2 + arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 104 arch/arm/mach-omap2/prcm43xx.h |1 + drivers/video/omap2/dss/dispc.c|1 + drivers/video/omap2/dss/dpi.c |2 + drivers/video/omap2/dss/dsi.c |1 + drivers/video/omap2/dss/dss.c | 11 +++ drivers/video/omap2/dss/dss_features.c | 67 ++ include/video/omapdss.h|1 + 14 files changed, 379 insertions(+), 2 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 V3 6/6] ARM: DTS: AM43xx: Add DSS nodes
Both the AM437x-Gp evm and Am43x-Epos evm
use the same LCD panel.
The lcd timings are added in respective dts files.
Adds display pinctrl and enables required gpio.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 77 ++
arch/arm/boot/dts/am43x-epos-evm.dts | 73
2 files changed, 150 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 2e79bda..a178e8d 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -24,6 +24,33 @@
brightness-levels = 0 51 53 56 62 75 101 152 255;
default-brightness-level = 8;
};
+
+ aliases {
+ display0 = lcd0;
+ };
+
+ lcd0: display {
+ compatible = osddisplays,osd057T0559-34ts, panel-dpi;
+ label = lcd;
+ panel-timing {
+ clock-frequency = 3300;
+ hactive = 800;
+ vactive = 480;
+ hfront-porch = 210;
+ hback-porch = 16;
+ hsync-len = 30;
+ vback-porch = 10;
+ vfront-porch = 22;
+ vsync-len = 13;
+ hsync-active = 0;
+ vsync-active = 0;
+ de-active = 1;
+ pixelclk-active = 1;
+ };
+ lcd_in: endpoint {
+ remote-endpoint = dpi_out;
+ };
+ };
};
am43xx_pinmux {
@@ -46,6 +73,40 @@
0x164 MUX_MODE0 /*
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
;
};
+
+ dss_pinctrl: dss_pinctrl {
+ pinctrl-single,pins =
+ 0x020 (PIN_OUTPUT_PULLUP | MUX_MODE1) /*gpmc ad 8 -
DSS DATA 23 */
+ 0x024 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x028 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x02C (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x030 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x034 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x038 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+ 0x03C (PIN_OUTPUT_PULLUP | MUX_MODE1) /*gpmc ad 15 -
DSS DATA 16 */
+ 0x0A0 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS DATA 0 */
+ 0x0A4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0A8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0AC (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0B0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0B4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0B8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0BC (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0C0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0C4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0C8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0CC (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0D0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0D4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0D8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+ 0x0DC (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS DATA 15 */
+ 0x0E0 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS VSYNC */
+ 0x0E4 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS HSYNC */
+ 0x0E8 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS PCLK */
+ 0x0EC (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS AC BIAS EN
*/
+ 0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* GPIO 5_8 to
select LCD / HDMI */
+ ;
+ };
};
i2c0 {
@@ -69,3 +130,19 @@
pinctrl-names = default;
pinctrl-0 = ecap0_pins;
};
+
+gpio5 {
+ status = okay;
+};
+
+dss {
+ status = ok;
+
+ pinctrl-names = default;
+ pinctrl-0 = dss_pinctrl;
+
+ dpi_out: endpoint@0 {
+ remote-endpoint = lcd_in;
+ data-lines = 24;
+ };
+};
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 2ebcde6..3f9643b 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -27,6 +27,33 @@
enable-active-high;
};
+ aliases {
+ display0 = lcd0;
+ };
+
+ lcd0: display {
+ compatible = osddisplays,osd057T0559-34ts, panel-dpi;
+ label = lcd;
+ panel-timing {
+ clock-frequency = 3300;
+ hactive = 800;
+ vactive = 480;
+ hfront-porch = 210;
+ hback-porch =
[PATCH V3 4/6] ARM: am43xx-clocks.dtsi: Set parent for disp_clk
Choose a parent for the disp_clk.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
arch/arm/boot/dts/am43xx-clocks.dtsi |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 85e7d4b..b20e192 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -512,6 +512,8 @@ disp_clk: disp_clk@44df4244 {
compatible = ti,mux-clock;
clocks = dpll_disp_m2_ck, dpll_core_m5_ck, dpll_per_m2_ck;
reg = 0x44df4244 0x4;
+ bit-mask = 0x3;
+ set-rate-parent;
};
dpll_extdev_ck: dpll_extdev_ck@44df2e60 {
--
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 V3 2/6] ARM: AM43xx: fix dpll init in bypass mode
From: Tomi Valkeinen tomi.valkei...@ti.com
On AM43xx, if a PLL is in bypass at kernel init, the code in
omap2_get_dpll_rate() will not realize this and will try to calculate
the clock rate using the multiplier and the divider, resulting in
errors.
omap2_init_dpll_parent() has similar issue.
Add the missing soc_is_am43xx() check to make the code work on AM43xx.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
arch/arm/mach-omap2/clkt_dpll.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index 924c230..14e9e45 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -209,7 +209,7 @@ u8 omap2_init_dpll_parent(struct clk_hw *hw)
if (v == OMAP3XXX_EN_DPLL_LPBYPASS ||
v == OMAP3XXX_EN_DPLL_FRBYPASS)
return 1;
- } else if (soc_is_am33xx() || cpu_is_omap44xx()) {
+ } else if (soc_is_am33xx() || cpu_is_omap44xx() || soc_is_am43xx()) {
if (v == OMAP4XXX_EN_DPLL_LPBYPASS ||
v == OMAP4XXX_EN_DPLL_FRBYPASS ||
v == OMAP4XXX_EN_DPLL_MNBYPASS)
@@ -255,7 +255,7 @@ unsigned long omap2_get_dpll_rate(struct clk_hw_omap *clk)
if (v == OMAP3XXX_EN_DPLL_LPBYPASS ||
v == OMAP3XXX_EN_DPLL_FRBYPASS)
return __clk_get_rate(dd-clk_bypass);
- } else if (soc_is_am33xx() || cpu_is_omap44xx()) {
+ } else if (soc_is_am33xx() || cpu_is_omap44xx() || soc_is_am43xx()) {
if (v == OMAP4XXX_EN_DPLL_LPBYPASS ||
v == OMAP4XXX_EN_DPLL_FRBYPASS ||
v == OMAP4XXX_EN_DPLL_MNBYPASS)
--
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 V3 3/6] ARM: OMAP2+: AM43xx DSS Hwmod
Add DSS hwmod structs for AM43xx.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 104
arch/arm/mach-omap2/prcm43xx.h |1 +
2 files changed, 105 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 9002fca..6a121db 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -19,6 +19,8 @@
#include omap_hwmod.h
#include omap_hwmod_33xx_43xx_common_data.h
#include prcm43xx.h
+#include omap_hwmod_common_data.h
+
/* IP blocks */
static struct omap_hwmod am43xx_l4_hs_hwmod = {
@@ -415,6 +417,76 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
},
};
+/* Display sub system - DSS */
+
+static struct omap_hwmod_dma_info am43xx_dss_sdma_chs[] = {
+ { .name = dispc, .dma_req = 5 },
+ { .dma_req = -1 },
+};
+
+struct omap_dss_dispc_dev_attr am43xx_dss_dispc_dev_attr = {
+ .manager_count = 1,
+ .has_framedonetv_irq= 0
+};
+
+
+static struct omap_hwmod_class_sysconfig am43xx_dispc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class am43xx_dispc_hwmod_class = {
+ .name = dispc,
+ .sysc = am43xx_dispc_sysc,
+};
+
+static struct omap_hwmod am43xx_dss_core_hwmod = {
+ .name = dss_core,
+ .class = omap2_dss_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = disp_clk,
+ .sdma_reqs = am43xx_dss_sdma_chs,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* display controller -dispc*/
+
+static struct omap_hwmod am43xx_dss_dispc_hwmod = {
+ .name = dss_dispc,
+ .class = am43xx_dispc_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = disp_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+ },
+ },
+ .dev_attr = am43xx_dss_dispc_dev_attr,
+};
+
+/*RFBI*/
+
+static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
+ .name = dss_rfbi,
+ .class = omap2_rfbi_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = disp_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+ },
+ },
+};
+
/* Interfaces */
static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
.master = am33xx_l3_main_hwmod,
@@ -654,6 +726,34 @@ static struct omap_hwmod_ocp_if am43xx_l3_s__qspi = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if am43xx_dss__l3_main = {
+ .master = am43xx_dss_core_hwmod,
+ .slave = am33xx_l3_main_hwmod,
+ .clk= disp_clk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_dss_core_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_dispc = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_dss_dispc_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_dss_rfbi_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
am33xx_l4_wkup__synctimer,
am43xx_l4_ls__timer8,
@@ -747,6 +847,10 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
am43xx_l4_ls__ocp2scp1,
am43xx_l3_s__usbotgss0,
am43xx_l3_s__usbotgss1,
+ am43xx_dss__l3_main,
+ am43xx_l4_ls__dss,
+ am43xx_l4_ls__dss_dispc,
+ am43xx_l4_ls__dss_rfbi,
NULL,
};
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index 7785be9..ad7b3e9 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -142,5 +142,6 @@
#define AM43XX_CM_PER_USBPHYOCP2SCP0_CLKCTRL_OFFSET0x05B8
#define AM43XX_CM_PER_USB_OTG_SS1_CLKCTRL_OFFSET0x0268
#define
Re: [PATCH] ARM: dts: am437x-gp-evm: Do not reset gpio5
On 03/21/2014 12:52 AM, Felipe Balbi wrote:
On Fri, Mar 21, 2014 at 10:50:13AM +0530, Lokesh Vutla wrote:
From: Dave Gerlach d-gerl...@ti.com
Do not reset GPIO5 at boot-up because GPIO5_7 is used
on AM437x GP-EVM to control VTT regulators on DDR3.
Without this some GP-EVM boards will fail to boot because
of DDR3 corruption.
Reported-by: Nishanth Menon n...@ti.com
Tested-by: Nishanth Menon n...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
every now and again we see a patch like this because yet another board
is using a GPIO to toggle DDR regulators.
Instead of constantly patching things like this, how about we try
something like below (build-tested only):
Why should we change all of them? Is it correct to leave every single
GPIO at the mercy of the bootloader in every situation? The reason we
see these patches only every now and again is because it's a special
case that should be handled only for that situation. I also don't think
it makes sense to make gpio's a unique case that never gets reset while
every other IP does by default.
Regards,
Dave
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 1f33f5d..f5962ff 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2610,6 +2610,10 @@ static int __init _setup_reset(struct omap_hwmod *oh)
if (oh-flags HWMOD_EXT_OPT_MAIN_CLK)
return -EPERM;
+ /* NEVER reset GPIO blocks */
+ if (strncmp(oh-name, gpio, 4) == 0)
+ return 0;
+
if (oh-rst_lines_cnt == 0) {
r = _enable(oh);
if (r) {
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 4243190..ce8b53a 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1130,6 +1130,29 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
static const struct of_device_id omap_gpio_match[];
+static void omap_gpio_init_context(struct gpio_bank *p)
+{
+ struct omap_gpio_reg_offs *regs = p-regs;
+ void __iomem *base = p-base;
+
+ p-context.ctrl = readl_relaxed(base + regs-ctrl);
+ p-context.oe= readl_relaxed(base + regs-direction);
+ p-context.wake_en = readl_relaxed(base + regs-wkup_en);
+ p-context.leveldetect0 = readl_relaxed(base + regs-leveldetect0);
+ p-context.leveldetect1 = readl_relaxed(base + regs-leveldetect1);
+ p-context.risingdetect = readl_relaxed(base + regs-risingdetect);
+ p-context.fallingdetect = readl_relaxed(base + regs-fallingdetect);
+ p-context.irqenable1= readl_relaxed(base + regs-irqenable);
+ p-context.irqenable2= readl_relaxed(base + regs-irqenable2);
+
+ if (regs-set_dataout p-regs-clr_dataout)
+ p-context.dataout = readl_relaxed(base + regs-set_dataout);
+ else
+ p-context.dataout = readl_relaxed(base + regs-dataout);
+
+ p-context_valid = true;
+}
+
static int omap_gpio_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
@@ -1246,6 +1269,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
omap_gpio_mod_init(bank);
omap_gpio_chip_init(bank);
omap_gpio_show_rev(bank);
+ omap_gpio_init_context(bank);
pm_runtime_put(bank-dev);
@@ -1325,8 +1349,6 @@ update_gpio_context_count:
return 0;
}
-static void omap_gpio_init_context(struct gpio_bank *p);
-
static int omap_gpio_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -1466,29 +1488,6 @@ void omap2_gpio_resume_after_idle(void)
}
#if defined(CONFIG_PM_RUNTIME)
-static void omap_gpio_init_context(struct gpio_bank *p)
-{
- struct omap_gpio_reg_offs *regs = p-regs;
- void __iomem *base = p-base;
-
- p-context.ctrl = readl_relaxed(base + regs-ctrl);
- p-context.oe= readl_relaxed(base + regs-direction);
- p-context.wake_en = readl_relaxed(base + regs-wkup_en);
- p-context.leveldetect0 = readl_relaxed(base + regs-leveldetect0);
- p-context.leveldetect1 = readl_relaxed(base + regs-leveldetect1);
- p-context.risingdetect = readl_relaxed(base + regs-risingdetect);
- p-context.fallingdetect = readl_relaxed(base + regs-fallingdetect);
- p-context.irqenable1= readl_relaxed(base + regs-irqenable);
- p-context.irqenable2= readl_relaxed(base + regs-irqenable2);
-
- if (regs-set_dataout p-regs-clr_dataout)
- p-context.dataout = readl_relaxed(base + regs-set_dataout);
- else
- p-context.dataout = readl_relaxed(base + regs-dataout);
-
- p-context_valid = true;
-}
-
static void omap_gpio_restore_context(struct gpio_bank *bank)
{
writel_relaxed(bank-context.wake_en,
Then, we can even remove
Re: [PATCH 6/9] mmc: omap_hsmmc: Enable SDIO interrupt
On 24 March 2014 15:59, Andreas Fenkart afenk...@gmail.com wrote:
Hi,
2014-03-24 13:43 GMT+01:00 Ulf Hansson ulf.hans...@linaro.org:
On 21 March 2014 17:17, Balaji T K balaj...@ti.com wrote:
From: Andreas Fenkart afenk...@gmail.com
There have been various patches floating around for enabling
the SDIO IRQ for hsmmc, but none of them ever got merged.
Probably the reason for not merging the SDIO interrupt patches
has been the lack of wake-up path for SDIO on some omaps that
has also needed remuxing the SDIO DAT1 line to a GPIO making
the patches complex.
This patch adds the minimal SDIO IRQ support to hsmmc for
omaps that do have the wake-up path. For those omaps, the
DAT1 line need to have the wake-up enable bit set, and the
wake-up interrupt is the same as for the MMC controller.
This patch has been tested on am3730 es1.2 with mwifiex
connected to MMC3 with mwifiex waking to Ethernet traffic
from off-idle mode. Note that for omaps that do not have
the SDIO wake-up path, this patch will not work for idle
modes and further patches for remuxing DAT1 to GPIO are
needed.
Based on earlier patches [1][2] by David Vrabel
david.vra...@csr.com, Steve Sakoman st...@sakoman.com
and Andreas Fenkart afenk...@gmail.com with the SDIO IRQ
handing improved following how sdhci.c is doing it.
For now, only support SDIO interrupt if we are booted with
a separate wake-irq configued via device tree. This is
because omaps need the wake-irq for idle states, and some
omaps need special quirks. And we don't want to add new
legacy mux platform init code callbacks any longer as we
are moving to DT based booting anyways.
To use it, you need to specify the wake-irq using the
interrupts-extended property.
[1]
http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453
[2] http://comments.gmane.org/gmane.linux.kernel.mmc/20446
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 207
++--
include/linux/platform_data/mmc-omap.h |1 +
2 files changed, 196 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 38a75bc..0275e0a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -29,6 +29,7 @@
#include linux/timer.h
#include linux/clk.h
#include linux/of.h
+#include linux/of_irq.h
#include linux/of_gpio.h
#include linux/of_device.h
#include linux/omap-dma.h
@@ -36,6 +37,7 @@
#include linux/mmc/core.h
#include linux/mmc/mmc.h
#include linux/io.h
+#include linux/irq.h
#include linux/gpio.h
#include linux/regulator/consumer.h
#include linux/pinctrl/consumer.h
@@ -106,6 +108,7 @@
#define TC_EN (1 1)
#define BWR_EN (1 4)
#define BRR_EN (1 5)
+#define CIRQ_EN(1 8)
#define ERR_EN (1 15)
#define CTO_EN (1 16)
#define CCRC_EN(1 17)
@@ -140,7 +143,6 @@
#define VDD_3V0300 /* 30 uV */
#define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
-#define AUTO_CMD23 (1 1)/* Auto CMD23 support */
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any
known
@@ -194,6 +196,7 @@ struct omap_hsmmc_host {
u32 sysctl;
u32 capa;
int irq;
+ int wake_irq;
int use_dma, dma_ch;
struct dma_chan *tx_chan;
struct dma_chan *rx_chan;
@@ -206,6 +209,11 @@ struct omap_hsmmc_host {
int req_in_progress;
unsigned long clk_rate;
unsigned intflags;
+#define HSMMC_RUNTIME_SUSPENDED (1 0)
+#define AUTO_CMD23 (1 1)/* Auto CMD23 support */
merge conflict here? I do not use HSMMC_RUNTIME_SUSPEND anymore
and of course, neither do I define AUTO_CMD23. :-)
+#define HSMMC_SWAKEUP_QUIRK(1 2)
+#define HSMMC_SDIO_IRQ_ENABLED (1 3)/* SDIO irq enabled */
+#define HSMMC_WAKE_IRQ_ENABLED (1 4)
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -510,27 +518,40 @@ static void omap_hsmmc_stop_clock(struct
omap_hsmmc_host *host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
-
Re: [PATCH 6/9] mmc: omap_hsmmc: Enable SDIO interrupt
2014-03-24 17:02 GMT+01:00 Ulf Hansson ulf.hans...@linaro.org:
On 24 March 2014 15:59, Andreas Fenkart afenk...@gmail.com wrote:
Hi,
2014-03-24 13:43 GMT+01:00 Ulf Hansson ulf.hans...@linaro.org:
On 21 March 2014 17:17, Balaji T K balaj...@ti.com wrote:
From: Andreas Fenkart afenk...@gmail.com
There have been various patches floating around for enabling
the SDIO IRQ for hsmmc, but none of them ever got merged.
Probably the reason for not merging the SDIO interrupt patches
has been the lack of wake-up path for SDIO on some omaps that
has also needed remuxing the SDIO DAT1 line to a GPIO making
the patches complex.
This patch adds the minimal SDIO IRQ support to hsmmc for
omaps that do have the wake-up path. For those omaps, the
DAT1 line need to have the wake-up enable bit set, and the
wake-up interrupt is the same as for the MMC controller.
This patch has been tested on am3730 es1.2 with mwifiex
connected to MMC3 with mwifiex waking to Ethernet traffic
from off-idle mode. Note that for omaps that do not have
the SDIO wake-up path, this patch will not work for idle
modes and further patches for remuxing DAT1 to GPIO are
needed.
Based on earlier patches [1][2] by David Vrabel
david.vra...@csr.com, Steve Sakoman st...@sakoman.com
and Andreas Fenkart afenk...@gmail.com with the SDIO IRQ
handing improved following how sdhci.c is doing it.
For now, only support SDIO interrupt if we are booted with
a separate wake-irq configued via device tree. This is
because omaps need the wake-irq for idle states, and some
omaps need special quirks. And we don't want to add new
legacy mux platform init code callbacks any longer as we
are moving to DT based booting anyways.
To use it, you need to specify the wake-irq using the
interrupts-extended property.
[1]
http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453
[2] http://comments.gmane.org/gmane.linux.kernel.mmc/20446
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 207
++--
include/linux/platform_data/mmc-omap.h |1 +
2 files changed, 196 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 38a75bc..0275e0a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -29,6 +29,7 @@
#include linux/timer.h
#include linux/clk.h
#include linux/of.h
+#include linux/of_irq.h
#include linux/of_gpio.h
#include linux/of_device.h
#include linux/omap-dma.h
@@ -36,6 +37,7 @@
#include linux/mmc/core.h
#include linux/mmc/mmc.h
#include linux/io.h
+#include linux/irq.h
#include linux/gpio.h
#include linux/regulator/consumer.h
#include linux/pinctrl/consumer.h
@@ -106,6 +108,7 @@
#define TC_EN (1 1)
#define BWR_EN (1 4)
#define BRR_EN (1 5)
+#define CIRQ_EN(1 8)
#define ERR_EN (1 15)
#define CTO_EN (1 16)
#define CCRC_EN(1 17)
@@ -140,7 +143,6 @@
#define VDD_3V0300 /* 30 uV */
#define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
-#define AUTO_CMD23 (1 1)/* Auto CMD23 support */
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any
known
@@ -194,6 +196,7 @@ struct omap_hsmmc_host {
u32 sysctl;
u32 capa;
int irq;
+ int wake_irq;
int use_dma, dma_ch;
struct dma_chan *tx_chan;
struct dma_chan *rx_chan;
@@ -206,6 +209,11 @@ struct omap_hsmmc_host {
int req_in_progress;
unsigned long clk_rate;
unsigned intflags;
+#define HSMMC_RUNTIME_SUSPENDED (1 0)
+#define AUTO_CMD23 (1 1)/* Auto CMD23 support */
merge conflict here? I do not use HSMMC_RUNTIME_SUSPEND anymore
and of course, neither do I define AUTO_CMD23. :-)
+#define HSMMC_SWAKEUP_QUIRK(1 2)
+#define HSMMC_SDIO_IRQ_ENABLED (1 3)/* SDIO irq enabled */
+#define HSMMC_WAKE_IRQ_ENABLED (1 4)
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -510,27 +518,40 @@ static void omap_hsmmc_stop_clock(struct
omap_hsmmc_host *host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
-
Re: [PATCH] ARM: dts: am437x-gp-evm: Do not reset gpio5
Hi, On Mon, Mar 24, 2014 at 10:29:58AM -0500, Dave Gerlach wrote: On 03/21/2014 12:52 AM, Felipe Balbi wrote: On Fri, Mar 21, 2014 at 10:50:13AM +0530, Lokesh Vutla wrote: From: Dave Gerlach d-gerl...@ti.com Do not reset GPIO5 at boot-up because GPIO5_7 is used on AM437x GP-EVM to control VTT regulators on DDR3. Without this some GP-EVM boards will fail to boot because of DDR3 corruption. Reported-by: Nishanth Menon n...@ti.com Tested-by: Nishanth Menon n...@ti.com Signed-off-by: Dave Gerlach d-gerl...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com every now and again we see a patch like this because yet another board is using a GPIO to toggle DDR regulators. Instead of constantly patching things like this, how about we try something like below (build-tested only): Why should we change all of them? Is it correct to leave every single GPIO at the mercy of the bootloader in every situation? The reason we see these it's not leaving anything at the mercy of the bootloader. It's simply looking at the HW itself and asking what's the current state of this GPIO ? patches only every now and again is because it's a special case that should I wouldn't call it special. A GPIO block is pretty dumb, its registers only give you current pin state, there's virtually no state machine involved whatsoever. be handled only for that situation. I also don't think it makes sense to make gpio's a unique case that never gets reset while every other IP does by default. Well, if it doesn't need to be reset, why would you spend that time resetting it ? In the GPIO case, you gain nothing by resetting the IP, nothing at all, other than now I'm sure the IP is in no-standby/no-idle but that can be easily read back from SYS[SC] registers anyway. The point is that we have two choices here: a) every time a new board comes around using GPIO as an enable signal for DDR, we spend a few days debugging why it's not booting. b) make sure no GPIO block is ever reset, so we never go through the debugging cycle again. -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: am437x-gp-evm: Do not reset gpio5
On 03/24/2014 01:50 PM, Felipe Balbi wrote: Hi, On Mon, Mar 24, 2014 at 10:29:58AM -0500, Dave Gerlach wrote: On 03/21/2014 12:52 AM, Felipe Balbi wrote: On Fri, Mar 21, 2014 at 10:50:13AM +0530, Lokesh Vutla wrote: From: Dave Gerlach d-gerl...@ti.com Do not reset GPIO5 at boot-up because GPIO5_7 is used on AM437x GP-EVM to control VTT regulators on DDR3. Without this some GP-EVM boards will fail to boot because of DDR3 corruption. Reported-by: Nishanth Menon n...@ti.com Tested-by: Nishanth Menon n...@ti.com Signed-off-by: Dave Gerlach d-gerl...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com every now and again we see a patch like this because yet another board is using a GPIO to toggle DDR regulators. Instead of constantly patching things like this, how about we try something like below (build-tested only): Why should we change all of them? Is it correct to leave every single GPIO at the mercy of the bootloader in every situation? The reason we see these it's not leaving anything at the mercy of the bootloader. It's simply looking at the HW itself and asking what's the current state of this GPIO ? And you assume here that every GPIO pin left in what ever state by bootloader is the correct state for kernel to function in? that is not exactly a good idea from even power consumption perspective - example GPIOs used by bootloader to detect board revision is not used in kernel, leaving such GPIOs active is not optimal, certain other GPIOs used by external peripherals might even be wrongly configured by bootloader issues - the idea of ti,no-reset-on-init is to ensure that we *know* which instances need special handling and we depend on bootloader configuration. Taking it a step further, why is not doing IP module kernel reset just a constraint for GPIO then? Why not leave every IP module in what ever state bootloader left it at? patches only every now and again is because it's a special case that should I wouldn't call it special. A GPIO block is pretty dumb, its registers only give you current pin state, there's virtually no state machine involved whatsoever. be handled only for that situation. I also don't think it makes sense to make gpio's a unique case that never gets reset while every other IP does by default. Well, if it doesn't need to be reset, why would you spend that time resetting it ? In the GPIO case, you gain nothing by resetting the IP, nothing at all, other than now I'm sure the IP is in no-standby/no-idle but that can be easily read back from SYS[SC] registers anyway. because, you do not know how else the system might be used. instead of assuming the bootloader or host OS (in a virtualized environment) will always be doing the right thing, kernel takes responsibility of peripherals and exceptions are clearly marked (such as with ti,no-reset-on-init;). The point is that we have two choices here: a) every time a new board comes around using GPIO as an enable signal for DDR, we spend a few days debugging why it's not booting. yeah - read the darned schematics - this is valid for anyone doing board/platform bringup - this is the right way to do it. b) make sure no GPIO block is ever reset, so we never go through the debugging cycle again. the holy grail of new bugs! Sigh! -- Regards, Nishanth Menon -- 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: dts: am437x-gp-evm: Do not reset gpio5
Hi, On Mon, Mar 24, 2014 at 02:01:30PM -0500, Nishanth Menon wrote: On 03/24/2014 01:50 PM, Felipe Balbi wrote: Hi, On Mon, Mar 24, 2014 at 10:29:58AM -0500, Dave Gerlach wrote: On 03/21/2014 12:52 AM, Felipe Balbi wrote: On Fri, Mar 21, 2014 at 10:50:13AM +0530, Lokesh Vutla wrote: From: Dave Gerlach d-gerl...@ti.com Do not reset GPIO5 at boot-up because GPIO5_7 is used on AM437x GP-EVM to control VTT regulators on DDR3. Without this some GP-EVM boards will fail to boot because of DDR3 corruption. Reported-by: Nishanth Menon n...@ti.com Tested-by: Nishanth Menon n...@ti.com Signed-off-by: Dave Gerlach d-gerl...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com every now and again we see a patch like this because yet another board is using a GPIO to toggle DDR regulators. Instead of constantly patching things like this, how about we try something like below (build-tested only): Why should we change all of them? Is it correct to leave every single GPIO at the mercy of the bootloader in every situation? The reason we see these it's not leaving anything at the mercy of the bootloader. It's simply looking at the HW itself and asking what's the current state of this GPIO ? And you assume here that every GPIO pin left in what ever state by bootloader is the correct state for kernel to function in? that is not exactly a good idea from even power consumption perspective - example right, it's a much better idea to reset the IP which, well, enables the f-ing DDR. Congrats! GPIOs used by bootloader to detect board revision is not used in kernel, leaving such GPIOs active is not optimal, certain other GPIOs used by external peripherals might even be wrongly configured by bootloader issues - the idea of ti,no-reset-on-init is to ensure that we *know* which instances need special handling and we depend on bootloader configuration. or you can just make your driver smarter and for GPIOs which are not used by the kernel, you ignore context save-restore. The problem is that our GPIO driver is so fucked up that nobody really cares about fixing it. If you really wanted to fix it, it wouldn't be really difficult to make use of pm_runtime's (and clock API's) usage counters to avoid keeping certain blocks up when not necessary. Taking it a step further, why is not doing IP module kernel reset just a constraint for GPIO then? Why not leave every IP module in what ever state bootloader left it at? yeah, that's exactly what I suggested. Thanks for clarifying what *I* *SAID*. patches only every now and again is because it's a special case that should I wouldn't call it special. A GPIO block is pretty dumb, its registers only give you current pin state, there's virtually no state machine involved whatsoever. be handled only for that situation. I also don't think it makes sense to make gpio's a unique case that never gets reset while every other IP does by default. Well, if it doesn't need to be reset, why would you spend that time resetting it ? In the GPIO case, you gain nothing by resetting the IP, nothing at all, other than now I'm sure the IP is in no-standby/no-idle but that can be easily read back from SYS[SC] registers anyway. because, you do not know how else the system might be used. instead of assuming the bootloader or host OS (in a virtualized environment) will always be doing the right thing, kernel takes responsibility of peripherals and exceptions are clearly marked (such as with ti,no-reset-on-init;). yada, yada, yada... The point is that we have two choices here: a) every time a new board comes around using GPIO as an enable signal for DDR, we spend a few days debugging why it's not booting. yeah - read the darned schematics - this is valid for anyone doing board/platform bringup - this is the right way to do it. sure, I'll let you handle that next time, be my guest. b) make sure no GPIO block is ever reset, so we never go through the debugging cycle again. the holy grail of new bugs! Sigh! right, our code so god-damned perfect, ain't it ? We better not touch it anymore. Fair enough, I withdraw my comments, do as you wish. -- balbi signature.asc Description: Digital signature
Re: [RFC 2/9] opp-modifier: Add opp-modifier-reg driver
On 03/18/2014 10:36 AM, Nishanth Menon wrote: On 03/17/2014 01:37 PM, Rob Herring wrote: On Mon, Mar 17, 2014 at 9:30 AM, Nishanth Menon n...@ti.com wrote: On 03/14/2014 04:00 PM, Rob Herring wrote: On Fri, Mar 14, 2014 at 2:25 PM, Dave Gerlach d-gerl...@ti.com wrote: Driver to read from a register and depending on either set bits or a specific known selectively enable or disable OPPs based on DT node. Can support opp-modifier-reg-bit where single bits within the register determine the availability of an OPP or opp-modifier-reg-val where a certain value inside the register or a portion of it determine what the maximum allowed OPP is. The driver expects a device that has already has its OPPs loaded and then will disable the OPPs not matching the criteria specified in the opp-modifier table. Signed-off-by: Dave Gerlach d-gerl...@ti.com --- .../devicetree/bindings/power/opp-modifier.txt | 111 + drivers/power/opp/Makefile | 1 + drivers/power/opp/opp-modifier-reg.c | 259 + 3 files changed, 371 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/opp-modifier.txt create mode 100644 drivers/power/opp/opp-modifier-reg.c diff --git a/Documentation/devicetree/bindings/power/opp-modifier.txt b/Documentation/devicetree/bindings/power/opp-modifier.txt new file mode 100644 index 000..af8a2e9 --- /dev/null +++ b/Documentation/devicetree/bindings/power/opp-modifier.txt @@ -0,0 +1,111 @@ +* OPP-Modifier - opp modifier to selectively enable operating points + +Many SoCs that have selectively modifiable OPPs can specify +all available OPPs in their operating-points listing and then define +opp_modifiers to enable or disable the OPPs that are actually available +on the specific hardware. + +* OPP Modifier Provider Uggg. Please stop designing around the current OPP binding which has the problem that the OPP table is not extensible to add more data. Define a new OPP binding that solves these problems. This is at least Generically, there are three different issues with current OPP bindings: a) ability to enable disable certain OPPs depending on SoC OTP/Efuse settings. More generically: ...depending on variety of factors. Agreed. The idea here was not to touch the existing OPP bindings, hence the opp modifier name. As Nishanth stated, this is not extending the binding; the opp-modifier just uses the frequency values as an identifier but the driver does not necessarily care where the OPPs already in the table came from, just that they correspond to the same frequencies it describes. And again, just to reiterate, nothing is binding the user to use the opp-modifier-reg child driver, any driver could be written to decide which OPPs to enable or disable. With that said, I do understand that this is far from a perfect solution to the issue of defining which OPPs are available, I meant it as a suggestion for a possible way forward. This could be used as a starting point for something even more generic. It's a common problem on many SoCs even if it is defined in completely different ways so this framework or one like it could give a common point to branch out from. If we don't want to move forward with a generic layer to handle OPP availability, what is the best option? Does anybody else have opinions on this? Regardless of what is decided if everyone can agree on a direction we can all move forward. Regards, Dave b) ability to reuse OPPs defined for one device node for another (cpu1 to reuse OPP definitions of cpu0) c) ability to add additional information per OPP. we can argue this is a superset of (a), but really, the problems are different. It is all additional data per OPP. Additional different information is of course for different problems. That doesn't mean we need different solutions. Previous proposals include making each OPP as a phandle, but there does not seem much traction in that direction either. - proposal here has nothing to do with (b) or (c). They may have nothing to do with each other, but they all have to do with the OPP binding. If we're going to change/extend the binding, then all issues need to be taken into account. We aren't extending the existing binding in this series. We are just defining how hardware description of which OPPs are valid here. the 3rd OPP related binding addition I've seen recently. But I wouldn't spend a lot of effort on a new OPP binding just to add the functionality you are adding here because I don't like the whole concept in general. This might be a common way to determine valid OPPs on TI chips, but I think it is too low level and I don't want to see Not just TI chips, but iMX, now, Marvell, Xilinx as well. potentially more as well. doing OTP/Efuse based decision on which OPPs are valid on a chip is not a TI specific thing. This was the reason for us to try to define something generic enough to be reused by more SoCs than
