[linux-next] ASoC: sound/soc/samsung/neo1973_wm8753.c build failure

[linux-next] ASoC: sound/soc/samsung/neo1973_wm8753.c build failure

[Axel Lin]

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

Re: [linux-next] ASoC: sound/soc/samsung/neo1973_wm8753.c build failure

[Russell King]

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?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [linux-next] ASoC: sound/soc/samsung/neo1973_wm8753.c build failure

[Mark Brown]

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.

Re: [linux-next] ASoC: sound/soc/samsung/neo1973_wm8753.c build failure

[Russell King]

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.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [linux-next] ASoC: sound/soc/samsung/neo1973_wm8753.c build failure

[Mark Brown]

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.

Re: [linux-next] ASoC: sound/soc/samsung/neo1973_wm8753.c build failure

[Russell King]

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.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [linux-next] ASoC: sound/soc/samsung/neo1973_wm8753.c build failure

[Lars-Peter Clausen]

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

Re: [linux-next] ASoC: sound/soc/samsung/neo1973_wm8753.c build failure

[Russell King]

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.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [linux-next] ASoC: sound/soc/samsung/neo1973_wm8753.c build failure

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

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?

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: [linux-next] ASoC: sound/soc/samsung/neo1973_wm8753.c build failure

[Russell King]

On Fri, Sep 16, 2011 at 01:02:09PM -0400, Valdis.Kletnieks@vt.edu wrote:
> 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?

Just to be clear: DT SoCs should be described with DT_MACHINE_START()
rather than MACHINE_START().  DT_MACHINE_START() sets the machine ID
to ~0, so using machine_is_xxx() is _intentionally_ useless in that
case - the point of DT is that DT itself is used to describe the
platform differences, not code based on machine type numbers.

Essentially, as DT progresses, the machine IDs should eventually
disappear and become completely redundant.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [linux-next] ASoC: sound/soc/samsung/neo1973_wm8753.c build failure

[Mark Brown]

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.

Re: [linux-next] ASoC: sound/soc/samsung/neo1973_wm8753.c build failure

[Russell King]

On Thu, Sep 15, 2011 at 02:31:22PM +0100, Mark Brown wrote:
> On Thu, Sep 15, 2011 at 12:00:56PM +0100, Russell King wrote:
> > 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.

It sounds like you're in the perfect place to send them a warning
that something needs to happen on this, one way or the other.

Whether anyone volunteers should be used as a factor in deciding
how to deal with the small bits of GTA01 support in mainline.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [linux-next] ASoC: sound/soc/samsung/neo1973_wm8753.c build failure

[Mark Brown]

On Thu, Sep 15, 2011 at 08:16:30PM +0100, Russell King wrote:

> It sounds like you're in the perfect place to send them a warning
> that something needs to happen on this, one way or the other.

Lars-Peter is the main guy here and he already replied on this thread.

Re: [linux-next] ASoC: sound/soc/samsung/neo1973_wm8753.c build failure

[Harald Welte]

Hi Russell,

On Wed, Sep 14, 2011 at 08:19:17PM +0100, Russell King wrote:

> 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.

GTA01 was produced in a certain quantity, to be honest I don't remember
the details.  It was not just a prototype but actually sold + shipped to
quite a number of people.

> 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?

I can confirm that I personally definitely will not be working on
merging GTA01 related code.  However, the remaining "wider Openmoko
community" is surprisingly active, and I wouldn't be surprised at all if
somebody still wanted to do that, despite all that time having passed.

Regards,
	Harald
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)