[alsa-devel] [linux-next] ASoC: sound/soc/samsung/neo1973_wm8753.c build failure
Hi,
I got below build error: ( on linux-next 20110831 ) CC sound/soc/samsung/neo1973_wm8753.o sound/soc/samsung/neo1973_wm8753.c: In function 'neo1973_wm8753_init': sound/soc/samsung/neo1973_wm8753.c:325: error: implicit declaration of function 'machine_is_neo1973_gta01' make[3]: *** [sound/soc/samsung/neo1973_wm8753.o] Error 1 make[2]: *** [sound/soc/samsung] Error 2 make[1]: *** [sound/soc] Error 2 make: *** [sound] Error 2
I think the root cause is below commit: commit 6f82f4db "ARM: Update (and cut down) mach-types" removes neo1973_gta01 entry.
I'm not sure if we should add back the neo1973_gta01 entry to mach-types or remove all machine_is_neo1973_gta01() calls in neo1973_wm8753.c. Comments?
Regards, Axel
On Wed, Sep 14, 2011 at 05:18:13PM +0800, Axel Lin wrote:
Hi,
I got below build error: ( on linux-next 20110831 ) CC sound/soc/samsung/neo1973_wm8753.o sound/soc/samsung/neo1973_wm8753.c: In function 'neo1973_wm8753_init': sound/soc/samsung/neo1973_wm8753.c:325: error: implicit declaration of function 'machine_is_neo1973_gta01' make[3]: *** [sound/soc/samsung/neo1973_wm8753.o] Error 1 make[2]: *** [sound/soc/samsung] Error 2 make[1]: *** [sound/soc] Error 2 make: *** [sound] Error 2
I think the root cause is below commit: commit 6f82f4db "ARM: Update (and cut down) mach-types" removes neo1973_gta01 entry.
I'm not sure if we should add back the neo1973_gta01 entry to mach-types or remove all machine_is_neo1973_gta01() calls in neo1973_wm8753.c. Comments?
neo1973_gta01 was added to the database in October 2006. Five months later, neo1973_gta02 was registered by the same person (Harald Welte), and gta02 has been merged.
Therefore, I suggest that the GTA01 will never be submitted now, moreover I suggest that neo1973_gta01 was probably a prototype and neo1973_gta02 was probably the production platform.
So I suggest these references should be removed. If the platform is not going to be merged its pointless carrying the baggage around in drivers. Maybe Harald can confirm?
On Wed, Sep 14, 2011 at 08:19:17PM +0100, Russell King wrote:
Therefore, I suggest that the GTA01 will never be submitted now, moreover
I'm not entirely sure about that, while...
I suggest that neo1973_gta01 was probably a prototype and neo1973_gta02 was probably the production platform.
...this is true a substantial proportion of the GTA01 devices out there are in the hands of people who might hack on it.
On Thu, Sep 15, 2011 at 12:28:09AM +0100, Mark Brown wrote:
On Wed, Sep 14, 2011 at 08:19:17PM +0100, Russell King wrote:
Therefore, I suggest that the GTA01 will never be submitted now, moreover
I'm not entirely sure about that, while...
I suggest that neo1973_gta01 was probably a prototype and neo1973_gta02 was probably the production platform.
...this is true a substantial proportion of the GTA01 devices out there are in the hands of people who might hack on it.
Point at a mainline kernel which includes support for the neo1973_gta01 platform.
I assert that there have been none - had there been it would not have been removed from mach-types, as it would've been marked as existing in mainline.
On Thu, Sep 15, 2011 at 12:38:39AM +0100, Russell King wrote:
On Thu, Sep 15, 2011 at 12:28:09AM +0100, Mark Brown wrote:
On Wed, Sep 14, 2011 at 08:19:17PM +0100, Russell King wrote:
...this is true a substantial proportion of the GTA01 devices out there are in the hands of people who might hack on it.
Point at a mainline kernel which includes support for the neo1973_gta01 platform.
I don't recall saying that there has been one; however I have seen reasonable (if sporadic) efforts at getting the two boards mainlined - it took years to get GTA02 in there but it did happen.
On Thu, Sep 15, 2011 at 10:46:41AM +0100, Mark Brown wrote:
On Thu, Sep 15, 2011 at 12:38:39AM +0100, Russell King wrote:
On Thu, Sep 15, 2011 at 12:28:09AM +0100, Mark Brown wrote:
On Wed, Sep 14, 2011 at 08:19:17PM +0100, Russell King wrote:
...this is true a substantial proportion of the GTA01 devices out there are in the hands of people who might hack on it.
Point at a mainline kernel which includes support for the neo1973_gta01 platform.
I don't recall saying that there has been one; however I have seen reasonable (if sporadic) efforts at getting the two boards mainlined - it took years to get GTA02 in there but it did happen.
Look - we have a fundamental problem with the mach-types file, and that is it's growing completely out of hand. The full file is 150k representing some 3600 platforms. When it's postprocessed, it produces a 1.3MB header file.
Of that, only 21k or around 500 platforms have been merged into the kernel, producing a 180k header file.
The amount of effort required to maintain that file is getting rediculous - manually removing entries for SoCs rather than platforms, manually removing entries which have been partially edited which could conflict with other entries etc. Something _has_ to change - and it has - and did about six months ago.
We now have a sane policy: entries which aren't fully up to date are automatically dropped. Entries for which there is no platform support file merged within 12 months of the entries last edit are dropped also automatically dropped.
This policy results in a 50k file, representing around 1100 platforms exploding to about 400k of header file. I think that is a reasonable compromise, and I think the policy is entirely reasonable.
Lastly, GTA01 board support was added to the ALSA stuff in 2008 without the main platform support in arch/arm - so it can't be usefully used. It's been three years since that was done and still there is no sign of the main platform support appearing. It's been five years since the entry was created in the machine database.
Face it, GTA01 is dead as far as mainline is concerned.
If it's not dead then it needs sorting out. Either way there's two valid states: 1. fully merged, or 2. none of it is merged. There's no real half-way house state - certainly not one which should persist for three years. (It would be reasonable for maybe a couple of kernel releases but more than that is becoming very much a joke.)
On 09/15/2011 01:00 PM, Russell King wrote:
[...] We now have a sane policy: entries which aren't fully up to date are automatically dropped. Entries for which there is no platform support file merged within 12 months of the entries last edit are dropped also automatically dropped.
Partly unrelated, but what about these platforms which can be fully described with DT and don't need a platform file?
[...] Lastly, GTA01 board support was added to the ALSA stuff in 2008 without the main platform support in arch/arm - so it can't be usefully used. It's been three years since that was done and still there is no sign of the main platform support appearing. It's been five years since the entry was created in the machine database.
Face it, GTA01 is dead as far as mainline is concerned.
If it's not dead then it needs sorting out. Either way there's two valid states: 1. fully merged, or 2. none of it is merged. There's no real half-way house state - certainly not one which should persist for three years. (It would be reasonable for maybe a couple of kernel releases but more than that is becoming very much a joke.)
The code for GTA01 is out there and could be merged into mainline, but I think it would be dead code since there doesn't seem to be really any interest in the device anymore.
So just get rid of the gta01 portions of the neo1973_wm8753 driver. If GTA01 support ever gets merged we can still revert the removal.
- Lars
On Thu, Sep 15, 2011 at 01:53:04PM +0200, Lars-Peter Clausen wrote:
On 09/15/2011 01:00 PM, Russell King wrote:
[...] We now have a sane policy: entries which aren't fully up to date are automatically dropped. Entries for which there is no platform support file merged within 12 months of the entries last edit are dropped also automatically dropped.
Partly unrelated, but what about these platforms which can be fully described with DT and don't need a platform file?
The theory is with DT is that machine_is_xxx() is no longer required, because they're fully described by DT. Such a kernel should not care whether it's running on board XYZ or ABC because the differences are wrapped up in the DT description of it.
Moreover, DT boards do not have machine IDs - their machine ID is "~0" which will be universal for all DT using platforms. So machine_is_xxx() really has no meaning at all when using DT. Basically, DT makes machine IDs obsolete.
The code for GTA01 is out there and could be merged into mainline, but I think it would be dead code since there doesn't seem to be really any interest in the device anymore.
So just get rid of the gta01 portions of the neo1973_wm8753 driver. If GTA01 support ever gets merged we can still revert the removal.
Agreed.
On Thu, 15 Sep 2011 13:53:04 +0200, Lars-Peter Clausen said:
On 09/15/2011 01:00 PM, Russell King wrote:
[...] We now have a sane policy: entries which aren't fully up to date are automatically dropped. Entries for which there is no platform support file merged within 12 months of the entries last edit are dropped also automatically dropped.
Partly unrelated, but what about these platforms which can be fully described with DT and don't need a platform file?
Then those platforms won't notice if their now-unused entries evaporate out of the platform file, right?
On Thu, Sep 15, 2011 at 12:00:56PM +0100, Russell King wrote:
We now have a sane policy: entries which aren't fully up to date are automatically dropped. Entries for which there is no platform support file merged within 12 months of the entries last edit are dropped also automatically dropped.
Yes, yes - I'm aware of this.
Face it, GTA01 is dead as far as mainline is concerned.
If it's not dead then it needs sorting out. Either way there's two valid states: 1. fully merged, or 2. none of it is merged. There's no real half-way house state - certainly not one which should persist for three years. (It would be reasonable for maybe a couple of kernel releases but more than that is becoming very much a joke.)
I'm not really aware of what's going on with the arch/arm code but from an ASoC point of view it's one of the platforms people seem to usefully care about; there's more traffic than for most machines. Obviously the problems with s3c24xx aren't going to have been helpful either.
participants (5)
-
Axel Lin -
Lars-Peter Clausen -
Mark Brown -
Russell King -
Valdis.Kletnieks＠vt.edu