[alsa-devel] [PATCH] ASoC: rsnd: fixup SSI interrupts style of DeviceTree
From: Kuninori Morimoto kuninori.morimoto.gx@renesas.com
Current SSI interrupts has been set to each port. But it is too ugly style. SSI interrupts will be listed under rcar_sound,ssi node by this patch
Signed-off-by: Kuninori Morimoto kuninori.morimoto.gx@renesas.com ---
Mark
There is still no DT user for this driver at this point. No conflict happens on platform.
.../devicetree/bindings/sound/renesas,rsnd.txt | 50 ++++++++------------ sound/soc/sh/rcar/ssi.c | 2 +- 2 files changed, 21 insertions(+), 31 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index 8346cab..1fba56b 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -53,36 +53,26 @@ rcar_sound: rcar_sound@0xffd90000 { };
rcar_sound,ssi { - ssi0: ssi@0 { - interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>; - }; - ssi1: ssi@1 { - interrupts = <0 371 IRQ_TYPE_LEVEL_HIGH>; - }; - ssi2: ssi@2 { - interrupts = <0 372 IRQ_TYPE_LEVEL_HIGH>; - }; - ssi3: ssi@3 { - interrupts = <0 373 IRQ_TYPE_LEVEL_HIGH>; - }; - ssi4: ssi@4 { - interrupts = <0 374 IRQ_TYPE_LEVEL_HIGH>; - }; - ssi5: ssi@5 { - interrupts = <0 375 IRQ_TYPE_LEVEL_HIGH>; - }; - ssi6: ssi@6 { - interrupts = <0 376 IRQ_TYPE_LEVEL_HIGH>; - }; - ssi7: ssi@7 { - interrupts = <0 377 IRQ_TYPE_LEVEL_HIGH>; - }; - ssi8: ssi@8 { - interrupts = <0 378 IRQ_TYPE_LEVEL_HIGH>; - }; - ssi9: ssi@9 { - interrupts = <0 379 IRQ_TYPE_LEVEL_HIGH>; - }; + interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>, + <0 371 IRQ_TYPE_LEVEL_HIGH>, + <0 372 IRQ_TYPE_LEVEL_HIGH>, + <0 373 IRQ_TYPE_LEVEL_HIGH>, + <0 374 IRQ_TYPE_LEVEL_HIGH>, + <0 375 IRQ_TYPE_LEVEL_HIGH>, + <0 376 IRQ_TYPE_LEVEL_HIGH>, + <0 377 IRQ_TYPE_LEVEL_HIGH>, + <0 378 IRQ_TYPE_LEVEL_HIGH>, + <0 379 IRQ_TYPE_LEVEL_HIGH>; + ssi0: ssi@0 { }; + ssi1: ssi@1 { }; + ssi2: ssi@2 { }; + ssi3: ssi@3 { }; + ssi4: ssi@4 { }; + ssi5: ssi@5 { }; + ssi6: ssi@6 { }; + ssi7: ssi@7 { }; + ssi8: ssi@8 { }; + ssi9: ssi@9 { }; };
rcar_sound,dai { diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c index 2df723d..b311bc6 100644 --- a/sound/soc/sh/rcar/ssi.c +++ b/sound/soc/sh/rcar/ssi.c @@ -588,7 +588,7 @@ static void rsnd_of_parse_ssi(struct platform_device *pdev, /* * irq */ - ssi_info->pio_irq = irq_of_parse_and_map(np, 0); + ssi_info->pio_irq = irq_of_parse_and_map(node, i);
/* * DMA
On Fri, May 30, 2014 at 03:10:13AM -0700, Kuninori Morimoto wrote:
From: Kuninori Morimoto kuninori.morimoto.gx@renesas.com
Current SSI interrupts has been set to each port. But it is too ugly style. SSI interrupts will be listed under rcar_sound,ssi node by this patch
Signed-off-by: Kuninori Morimoto kuninori.morimoto.gx@renesas.com
Mark
There is still no DT user for this driver at this point. No conflict happens on platform.
.../devicetree/bindings/sound/renesas,rsnd.txt | 50 ++++++++------------ sound/soc/sh/rcar/ssi.c | 2 +- 2 files changed, 21 insertions(+), 31 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index 8346cab..1fba56b 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -53,36 +53,26 @@ rcar_sound: rcar_sound@0xffd90000 { };
rcar_sound,ssi {
ssi0: ssi@0 {interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>;};ssi1: ssi@1 {interrupts = <0 371 IRQ_TYPE_LEVEL_HIGH>;};ssi2: ssi@2 {interrupts = <0 372 IRQ_TYPE_LEVEL_HIGH>;};ssi3: ssi@3 {interrupts = <0 373 IRQ_TYPE_LEVEL_HIGH>;};ssi4: ssi@4 {interrupts = <0 374 IRQ_TYPE_LEVEL_HIGH>;};ssi5: ssi@5 {interrupts = <0 375 IRQ_TYPE_LEVEL_HIGH>;};ssi6: ssi@6 {interrupts = <0 376 IRQ_TYPE_LEVEL_HIGH>;};ssi7: ssi@7 {interrupts = <0 377 IRQ_TYPE_LEVEL_HIGH>;};ssi8: ssi@8 {interrupts = <0 378 IRQ_TYPE_LEVEL_HIGH>;};ssi9: ssi@9 {interrupts = <0 379 IRQ_TYPE_LEVEL_HIGH>;};
This looks like a backward step, especially as we use the ssiX blocks for DMA too.
Also, please just stop playing around with this stuff, other people are trying to use this code and changing it without a good technical reason is causing difficulty.
Hi Ben
Thank you for your feedback
From: Kuninori Morimoto kuninori.morimoto.gx@renesas.com
Current SSI interrupts has been set to each port. But it is too ugly style. SSI interrupts will be listed under rcar_sound,ssi node by this patch
Signed-off-by: Kuninori Morimoto kuninori.morimoto.gx@renesas.com
(snip)
This looks like a backward step, especially as we use the ssiX blocks for DMA too.
Also, please just stop playing around with this stuff, other people are trying to use this code and changing it without a good technical reason is causing difficulty.
Hmm... This driver is still under developing. And it is very difficult for me to care about out-of-tree Linux.
On Fri, May 30, 2014 at 03:43:50AM -0700, Kuninori Morimoto wrote:
Hi Ben
Thank you for your feedback
From: Kuninori Morimoto kuninori.morimoto.gx@renesas.com
Current SSI interrupts has been set to each port. But it is too ugly style. SSI interrupts will be listed under rcar_sound,ssi node by this patch
Signed-off-by: Kuninori Morimoto kuninori.morimoto.gx@renesas.com
(snip)
This looks like a backward step, especially as we use the ssiX blocks for DMA too.
Also, please just stop playing around with this stuff, other people are trying to use this code and changing it without a good technical reason is causing difficulty.
Hmm... This driver is still under developing. And it is very difficult for me to care about out-of-tree Linux.
Ok, but we really need to keep in mind that the DT should be kept as stable as possible. We may be out of tree at the moment, but we are trying our best to keep track and feed back our work. This is not helped if we have to do these changes when re-basing.
In my view this change does not help the readability, as we now have a large block of interrupts, where before we could easily work out which interrupt was mapped to which SSI.
Hi Ben
Hmm... This driver is still under developing. And it is very difficult for me to care about out-of-tree Linux.
Ok, but we really need to keep in mind that the DT should be kept as stable as possible. We may be out of tree at the moment, but we are trying our best to keep track and feed back our work. This is not helped if we have to do these changes when re-basing.
In my view this change does not help the readability, as we now have a large block of interrupts, where before we could easily work out which interrupt was mapped to which SSI.
OK. I thought that 1) current style was not good DT style 2) there is a chance to exchange it because upstream doesn't have user at this point. Can you accept if it can keep compatibility ?
On 30/05/14 12:23, Kuninori Morimoto wrote:
Hi Ben
Hmm... This driver is still under developing. And it is very difficult for me to care about out-of-tree Linux.
Ok, but we really need to keep in mind that the DT should be kept as stable as possible. We may be out of tree at the moment, but we are trying our best to keep track and feed back our work. This is not helped if we have to do these changes when re-basing.
In my view this change does not help the readability, as we now have a large block of interrupts, where before we could easily work out which interrupt was mapped to which SSI.
OK. I thought that 1) current style was not good DT style 2) there is a chance to exchange it because upstream doesn't have user at this point. Can you accept if it can keep compatibility ?
I think the current method is the nicer, it keeps the descriptions each ssi as close as possible to the ssi. So, in answer to #1 I think it is the best.
In answer to #2, it would be nicer not to unless you have a good reason to do this.
Hi Ben
I thought that 1) current style was not good DT style 2) there is a chance to exchange it because upstream doesn't have user at this point. Can you accept if it can keep compatibility ?
I think the current method is the nicer, it keeps the descriptions each ssi as close as possible to the ssi. So, in answer to #1 I think it is the best.
In answer to #2, it would be nicer not to unless you have a good reason to do this.
I re-considered about this patch. And I can agree with your opinion. I will skip this patch. Thank you for your help
participants (4)
-
Ben Dooks -
Ben Dooks -
Kuninori Morimoto -
Kuninori Morimoto