[alsa-devel] [PATCH 14/28] Remove MACH_SMDKC210
The symbol is an orphan, get rid of it. Signed-off-by: Richard Weinberger <richard@nod.at> --- sound/soc/samsung/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index 454f41c..7ea576c 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -145,7 +145,7 @@ config SND_SOC_SAMSUNG_RX1950_UDA1380 config SND_SOC_SAMSUNG_SMDK_WM9713 tristate "SoC AC97 Audio support for SMDK with WM9713" - depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310 || MACH_SMDKC210) + depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310) select SND_SOC_WM9713 select SND_SAMSUNG_AC97 help -- 1.8.4.2
On Sun, Feb 09, 2014 at 07:47:52PM +0100, Richard Weinberger wrote:
The symbol is an orphan, get rid of it.
Please fix whatever script you're using to generate your mails, it's generating corrupt headers. Please also use subject lines consistent with the rest of the subsystem - between the two I very nearly just deleted this unread, it's only Paul's mail that made me look.
config SND_SOC_SAMSUNG_SMDK_WM9713 tristate "SoC AC97 Audio support for SMDK with WM9713" - depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310 || MACH_SMDKC210) + depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310)
Like I said to Paul this isn't fixing the actual issue - think about why the symbol was there in the first place and why it was removed. There is a problem here but this would make it less likely that it would be properly fixed.
On Mon, 2014-02-10 at 11:41 +0000, Mark Brown wrote:
On Sun, Feb 09, 2014 at 07:47:52PM +0100, Richard Weinberger wrote: Please fix whatever script you're using to generate your mails, it's generating corrupt headers.
I think Richard's mail didn't end up on lkml. But it's pretty clear what it must have looked like.
config SND_SOC_SAMSUNG_SMDK_WM9713 tristate "SoC AC97 Audio support for SMDK with WM9713" - depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310 || MACH_SMDKC210) + depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310)
Like I said to Paul this isn't fixing the actual issue - think about why the symbol was there in the first place and why it was removed. There is a problem here but this would make it less likely that it would be properly fixed.
Would you mind going through this one step at a time, just to make sure _I_ understand what it is that you'd like to see? If so, to be absolutely sure we start from the same point: do you agree that the above line now effectively reads depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || false || false) because there's neither a Kconfig symbol MACH_SMDKV310 nor a Kconfig symbol MACH_SMDKC210? Paul Bolle
On Mon, Feb 10, 2014 at 02:31:12PM +0100, Paul Bolle wrote:
On Mon, 2014-02-10 at 11:41 +0000, Mark Brown wrote:
On Sun, Feb 09, 2014 at 07:47:52PM +0100, Richard Weinberger wrote:
Please fix whatever script you're using to generate your mails, it's generating corrupt headers.
I think Richard's mail didn't end up on lkml. But it's pretty clear what it must have looked like.
I can see what it looked like from my inbox, but my mail client can't understand them at all and hence didn't think the mails were sent to me and just ignored them when hitting reply.
config SND_SOC_SAMSUNG_SMDK_WM9713 tristate "SoC AC97 Audio support for SMDK with WM9713" - depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310 || MACH_SMDKC210) + depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310)
Like I said to Paul this isn't fixing the actual issue - think about why the symbol was there in the first place and why it was removed. There is a problem here but this would make it less likely that it would be properly fixed.
Would you mind going through this one step at a time, just to make sure _I_ understand what it is that you'd like to see?
If so, to be absolutely sure we start from the same point: do you agree that the above line now effectively reads depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || false || false)
because there's neither a Kconfig symbol MACH_SMDKV310 nor a Kconfig symbol MACH_SMDKC210?
Yes, that's correct. Now, like I say think about what the symbol was there for in the first place.
On Mon, 2014-02-10 at 14:12 +0000, Mark Brown wrote:
On Mon, Feb 10, 2014 at 02:31:12PM +0100, Paul Bolle wrote:
If so, to be absolutely sure we start from the same point: do you agree that the above line now effectively reads depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || false || false)
because there's neither a Kconfig symbol MACH_SMDKV310 nor a Kconfig symbol MACH_SMDKC210?
Yes, that's correct. Now, like I say think about what the symbol was there for in the first place.
So, next step: the Kconfig symbols MACH_SMDKV310 and MACH_SMDKC210 were removed in commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT for EXYNOS SoCs"). That commit was part of v3.11. Correct? Thanks for your patience. Paul Bolle
On Mon, Feb 10, 2014 at 04:30:42PM +0100, Paul Bolle wrote:
On Mon, 2014-02-10 at 14:12 +0000, Mark Brown wrote:
Yes, that's correct. Now, like I say think about what the symbol was there for in the first place.
So, next step: the Kconfig symbols MACH_SMDKV310 and MACH_SMDKC210 were removed in commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT for EXYNOS SoCs"). That commit was part of v3.11. Correct?
Indeed, so we can see that these platforms were converted to use DT and the symbols were removed as a result. This means that a good fix here is to ensure that the driver can be used with DT platforms.
On Mon, 2014-02-10 at 16:36 +0000, Mark Brown wrote:
On Mon, Feb 10, 2014 at 04:30:42PM +0100, Paul Bolle wrote:
So, next step: the Kconfig symbols MACH_SMDKV310 and MACH_SMDKC210 were removed in commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT for EXYNOS SoCs"). That commit was part of v3.11. Correct?
Indeed, so we can see that these platforms were converted to use DT and the symbols were removed as a result. This means that a good fix here is to ensure that the driver can be used with DT platforms.
One of the problems I face is that I find it hard to understand how this stuff works in v3.10 (ie, before MACH_SMDKV310 and MACH_SMDKC210 were dropped). See, if you scan v3.10:arch/arm/mach-exynos/mach-smdkv310.c you'll notice the string "smdk-audio". If you grep that string you get a few hits. But none in v3.10:sound/soc/samsung/smdk_wm9713.c. And if you scan v3.10:sound/soc/samsung/smdk_wm9713.c for strings you'll find stuff like "wm9713-hifi", "wm9713-codec", and "soc-audio". But these don't show up in v3.10:arch/arm/mach-exynos/mach-smdkv310.c. So it's not obvious how these two files relate. And I'm left wondering why SND_SOC_SAMSUNG_SMDK_WM9713 actually depends on (among other symbols) MACH_SMDKV310 and MACH_SMDKC210 in v3.10. Paul Bolle
On Mon, Feb 10, 2014 at 11:09:19PM +0100, Paul Bolle wrote:
See, if you scan v3.10:arch/arm/mach-exynos/mach-smdkv310.c you'll notice the string "smdk-audio". If you grep that string you get a few hits. But none in v3.10:sound/soc/samsung/smdk_wm9713.c. And if you scan v3.10:sound/soc/samsung/smdk_wm9713.c for strings you'll find stuff like "wm9713-hifi", "wm9713-codec", and "soc-audio". But these don't show up in v3.10:arch/arm/mach-exynos/mach-smdkv310.c. So it's not obvious how these two files relate.
And I'm left wondering why SND_SOC_SAMSUNG_SMDK_WM9713 actually depends on (among other symbols) MACH_SMDKV310 and MACH_SMDKC210 in v3.10.
The hardware is physically present on those boards but must be selected with DIP switches, the device registration needs to be changed in the kernel when that happens (as the DT must be when it is in use).
On Wed, 2014-02-12 at 16:04 +0000, Mark Brown wrote:
On Mon, Feb 10, 2014 at 11:09:19PM +0100, Paul Bolle wrote:
See, if you scan v3.10:arch/arm/mach-exynos/mach-smdkv310.c you'll notice the string "smdk-audio". If you grep that string you get a few hits. But none in v3.10:sound/soc/samsung/smdk_wm9713.c. And if you scan v3.10:sound/soc/samsung/smdk_wm9713.c for strings you'll find stuff like "wm9713-hifi", "wm9713-codec", and "soc-audio". But these don't show up in v3.10:arch/arm/mach-exynos/mach-smdkv310.c. So it's not obvious how these two files relate.
And I'm left wondering why SND_SOC_SAMSUNG_SMDK_WM9713 actually depends on (among other symbols) MACH_SMDKV310 and MACH_SMDKC210 in v3.10.
The hardware is physically present on those boards but must be selected with DIP switches, the device registration needs to be changed in the kernel when that happens (as the DT must be when it is in use).
In v3.14-rc4 these two symbols suddenly got removed, see commit eaff64705dd5 ("ASoC: samsung: Remove invalid dependencies"). It does exactly what I proposed last year, see https://lkml.org/lkml/2013/7/14/27 . (That link currently shows a rather empty page; is lkml.org having problems again?) That commit is fine with me, of course. I now see no reason to continue my, rather slowly progressing, search for the problem that you wanted to get properly fixed. I suppose another commit already fixed it. Thanks, Paul Bolle
On Fri, Feb 28, 2014 at 10:43:09PM +0100, Paul Bolle wrote:
That commit is fine with me, of course. I now see no reason to continue my, rather slowly progressing, search for the problem that you wanted to get properly fixed. I suppose another commit already fixed it.
No, but it's someone from Samsung (Sachin works with the Samsung landing team at Linaro) not caring about those drivers on these boards any more and mentioning the DT conversion which is rather different to someone doing mechanical cleanup with no mention of where the symbols went. It should be fairly obvious that if the reason symbols are being removed due to DT conversion of the platforms then the default thing should be that the drivers be being converted to DT and appropriate DT entries being added to the board DTS files, but more generally the important thing is that some understanding is shown as to why the symbols vanished and why the mechanical fix suggested is OK.
participants (3)
-
Mark Brown -
Paul Bolle -
Richard Weinberger