Skip to contentSkip to conversation

Patch "ASoC: sunxi: Add bindings for sun8i to SPDIF" has been added to the 4.9-stable tree

PATCH [email protected] 4 participants 11 messages Nov 9, 2017 – Nov 13, 2017

Subsystems (4)
Stable branch Device tree bindings ASoC Arm/Allwinner sunXi SoC support
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

ASoC: sunxi: Add bindings for sun8i to SPDIF

to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
asoc-sunxi-add-bindings-for-sun8i-to-spdif.patch
and it can be found in the queue-4.9 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From foo@baz Thu Nov 9 09:48:01 CET 2017

From: Marcus Cooper <[email protected]>
Date: Thu, 19 Jan 2017 20:52:57 +0100
Subject: ASoC: sunxi: Add bindings for sun8i to SPDIF

From: Marcus Cooper <[email protected]>

[ Upstream commit cb5c978f9a56c459d5f13901efcfe44b97c4182d ]

The H3 SoC uses the same SPDIF block as found in earlier SoCs, but the transmit fifo is at a different address.

Signed-off-by Marcus Cooper <[email protected]>
Acked-by Maxime Ripard <[email protected]>
Signed-off-by Mark Brown <[email protected]>
Signed-off-by Sasha Levin <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt |    1 +
 1 file changed, 1 insertion(+)
Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt +1 -0
@@ -10,6 +10,7 @@ Required properties:
   - compatible		: should be one of the following:
     - "allwinner,sun4i-a10-spdif": for the Allwinner A10 SoC
     - "allwinner,sun6i-a31-spdif": for the Allwinner A31 SoC
+    - "allwinner,sun8i-h3-spdif": for the Allwinner H3 SoC
 
   - reg			: Offset and length of the register set for the device.

Patches currently in stable-queue which might be from [email protected] are

queue-4.9/asoc-sunxi-add-bindings-for-sun8i-to-spdif.patch

maintainer
#1 lore raw
Quoted 6 lines · On Thu, Nov 09, 2017 at 10:09:10AM +0100, [email protected] wrote:

This is a note to let you know that I've just added the patch titled

ASoC: sunxi: Add bindings for sun8i to SPDIF

The H3 SoC uses the same SPDIF block as found in earlier SoCs, but the transmit fifo is at a different address.

This doesn't seem like a good idea - note how the changelog says that the transmit FIFO is at a different address, I'd expect this means that people won't be able to use the new compatible without a corresponding code change.

#2 lore raw
Quoted 6 lines · Mark Brown
Quoted 3 lines · On Thu, Nov 09, 2017 at 10:09:10AM +0100, [email protected] wrote:

This is a note to let you know that I've just added the patch titled

ASoC: sunxi: Add bindings for sun8i to SPDIF

Quoted 7 lines
Quoted 2 lines

The H3 SoC uses the same SPDIF block as found in earlier SoCs, but the transmit fifo is at a different address.

This doesn't seem like a good idea - note how the changelog says that the transmit FIFO is at a different address, I'd expect this means that people won't be able to use the new compatible without a corresponding code change.

Interesting. I keep trying to automate DT patch selection to deal with issues as this, but it seems like there is always something...

I agree with Mark. I think it would make sense to pick 1bd92af877 as well to deal with this issue.

Signature · 2 lines
Thanks,
Sasha
maintainer
#3 lore raw
Quoted 7 lines · Alexander (Sasha Levin)
Quoted 4 lines · Mark Brown

This doesn't seem like a good idea - note how the changelog says that the transmit FIFO is at a different address, I'd expect this means that people won't be able to use the new compatible without a corresponding code change.

Quoted 5 lines

Interesting. I keep trying to automate DT patch selection to deal with issues as this, but it seems like there is always something...

I agree with Mark. I think it would make sense to pick 1bd92af877 as well to deal with this issue.

Yeah, if they both go in together it's fine by me (though it's a little more than just a device ID).

#4 lore raw
Quoted 8 lines · Mark Brown
Quoted 6 lines · Alexander (Sasha Levin)
Quoted 4 lines · Mark Brown

This doesn't seem like a good idea - note how the changelog says that the transmit FIFO is at a different address, I'd expect this means that people won't be able to use the new compatible without a corresponding code change.

Quoted 8 lines
Quoted 5 lines

Interesting. I keep trying to automate DT patch selection to deal with issues as this, but it seems like there is always something...

I agree with Mark. I think it would make sense to pick 1bd92af877 as well to deal with this issue.

Yeah, if they both go in together it's fine by me (though it's a little more than just a device ID).

It's a quirk too :)

Signature · 2 lines
Thanks,
Sasha
author maintainer
#5 lore raw
Quoted 12 lines · Alexander (Sasha Levin)
Quoted 11 lines · Mark Brown
Quoted 9 lines · Alexander (Sasha Levin)
Quoted 4 lines · Mark Brown

This doesn't seem like a good idea - note how the changelog says that the transmit FIFO is at a different address, I'd expect this means that people won't be able to use the new compatible without a corresponding code change.

Interesting. I keep trying to automate DT patch selection to deal with issues as this, but it seems like there is always something...

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

I agree with Mark. I think it would make sense to pick 1bd92af877 as well to deal with this issue.

Yeah, if they both go in together it's fine by me (though it's a little more than just a device ID).

It's a quirk too :)

Ok, but 1bd92af877 does not apply cleanly (or even not cleanly) to 4.9, can someone provide me a backport?

thanks,

greg k-h

#6 lore raw
Quoted 16 lines · On Fri, Nov 10, 2017 at 02:34:31PM +0100, [email protected] wrote:
Quoted 15 lines · Alexander (Sasha Levin)
Quoted 14 lines · Mark Brown
Quoted 12 lines · Alexander (Sasha Levin)
Quoted 4 lines · Mark Brown

This doesn't seem like a good idea - note how the changelog says that the transmit FIFO is at a different address, I'd expect this means that people won't be able to use the new compatible without a corresponding code change.

Interesting. I keep trying to automate DT patch selection to deal with issues as this, but it seems like there is always something...

I agree with Mark. I think it would make sense to pick 1bd92af877 as well to deal with this issue.

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

Yeah, if they both go in together it's fine by me (though it's a little more than just a device ID).

It's a quirk too :)

Ok, but 1bd92af877 does not apply cleanly (or even not cleanly) to 4.9, can someone provide me a backport?

Sure, please pick the following 3 commits, should be no conflicts then:

- 96e53c41e1f81c9e9d1ce38d3f28b95668b71dcf - just dead code removal,
avoids conflicts later.
- 7762681a3ada5fca6017e75ea7f9cdac08fc50b9 - adds a basic quirks
structure.
- 1bd92af877abfeddcc4b83a35482ed4139591acf - adds support for H2 SoC.

Signature · 2 lines
Thanks,
Sasha
author maintainer
#7 lore raw
Quoted 22 lines · On Fri, Nov 10, 2017 at 04:04:22PM +0000, [email protected] wrote:
Quoted 21 lines · On Fri, Nov 10, 2017 at 02:34:31PM +0100, [email protected] wrote:
Quoted 19 lines · Alexander (Sasha Levin)
Quoted 8 lines · Mark Brown
Quoted 6 lines · Alexander (Sasha Levin)
Quoted 4 lines · Mark Brown

This doesn't seem like a good idea - note how the changelog says that the transmit FIFO is at a different address, I'd expect this means that people won't be able to use the new compatible without a corresponding code change.

Quoted 8 lines
Quoted 5 lines

Interesting. I keep trying to automate DT patch selection to deal with issues as this, but it seems like there is always something...

I agree with Mark. I think it would make sense to pick 1bd92af877 as well to deal with this issue.

Yeah, if they both go in together it's fine by me (though it's a little more than just a device ID).

It's a quirk too :)

Quoted 7 lines
Quoted 2 lines

Ok, but 1bd92af877 does not apply cleanly (or even not cleanly) to 4.9, can someone provide me a backport?

Sure, please pick the following 3 commits, should be no conflicts then:

- 96e53c41e1f81c9e9d1ce38d3f28b95668b71dcf - just dead code removal,
avoids conflicts later.

This commit claims the hardware is now supported by a different driver. Is that support in 4.9? I couldn't figure it out :(

thanks,

greg k-h

maintainer
#8 lore raw
Quoted 7 lines · On Fri, Nov 10, 2017 at 05:36:32PM +0100, [email protected] wrote:
Quoted 2 lines · On Fri, Nov 10, 2017 at 04:04:22PM +0000, [email protected] wrote:

- 96e53c41e1f81c9e9d1ce38d3f28b95668b71dcf - just dead code removal,
avoids conflicts later.

This commit claims the hardware is now supported by a different driver. Is that support in 4.9? I couldn't figure it out :(

I suspect this isn't worth the effort - it's defintely more than a simple quirk anyway.

#9 lore raw
Quoted 6 lines · Mark Brown
Quoted 4 lines · On Fri, Nov 10, 2017 at 05:36:32PM +0100, [email protected] wrote:
Quoted 2 lines · On Fri, Nov 10, 2017 at 04:04:22PM +0000, [email protected] wrote:

- 96e53c41e1f81c9e9d1ce38d3f28b95668b71dcf - just dead code removal,
avoids conflicts later.

Quoted 7 lines
Quoted 2 lines

This commit claims the hardware is now supported by a different driver. Is that support in 4.9? I couldn't figure it out :(

From what I can tell its that way since 3.11.

I suspect this isn't worth the effort - it's defintely more than a simple quirk anyway.

But as Mark points out, this is getting a bit too complicated and risky.

Signature · 2 lines
Thanks,
Sasha
author maintainer
#10 lore raw
Quoted 10 lines · On Sat, Nov 11, 2017 at 08:24:18PM +0000, [email protected] wrote:
Quoted 8 lines · Mark Brown
Quoted 7 lines · On Fri, Nov 10, 2017 at 05:36:32PM +0100, [email protected] wrote:
Quoted 2 lines · On Fri, Nov 10, 2017 at 04:04:22PM +0000, [email protected] wrote:

- 96e53c41e1f81c9e9d1ce38d3f28b95668b71dcf - just dead code removal,
avoids conflicts later.

This commit claims the hardware is now supported by a different driver. Is that support in 4.9? I couldn't figure it out :(

Quoted 7 lines
Quoted 4 lines

From what I can tell its that way since 3.11.

I suspect this isn't worth the effort - it's defintely more than a simple quirk anyway.

But as Mark points out, this is getting a bit too complicated and risky.

Ok, now dropped, thanks.

greg k-h