Platform device registration and enumeration

[maximus21]

Dear developers,
I want to raise my concern with the current way of declaring platform devices for codecs and sound cards in bcm2708.c.
I believe it is wrong. Board config file should deal only with what's on board, including i2s interface. If now every developer starts to add commercial and homemade devices to the file I doubt that it will make it to the mainstream. It also makes it difficult to maintain an up to date kernel. Development of addon boards specifically for RPi would be obstructed by the need to compile custom made kernel and incorporating bcm2708 into a kernel version that will suit the end user. To sum up, the work being done is very valuable as it opens new functionality. Unfortunately, the way it is implemented now makes it available only to a limited number of RPi users.
Solutions:

1. device registration and enumeration in card driver - not recommended by the kernel community but may well suit non-configurable codecs and cards that don't use SPI or I2C
2. work together with the platform developers to design and implement device declaration and enumeration routines whereby users would configure devices attached to different buses without the need to recompile the whole kernel and modules.
3. other suggestions are welcome.

[koalo]

The Raspberry Pi board file will not make it into mainstream anyway I guess (neither the one with I2S, nor the one without in the current "official raspberry pi kernel").
The target is using device tree. The idea behind the current structure is, that the board file can be seamlessly replaced by the device tree and therefore your first idea would be counterproductive.
The second one would be a nice idea, but I think the device tree is already a step into this direction, therefore I doubt that a ASoC specific solution (or even a Raspberry Pi specific solution) would be accepted by the community.
I hope I find the time next month to build a mainstream patch. If anyone would like to support this: My current problem is to get an (arbitrary) I2C device running with the mainstream kernel.

[maximus21]

Could you please explain the purpose for the intended patch?

[koalo]

The intention is to put my driver upstream.

[maximus21]

upstream to raspberrypi/linux or kernel.org?

[koalo]

kernel.org

[maximus21]

Florian, I don't see the point in having the driver outside RPi kernel tree as it relies on physical implementation of clocks on the board. Moreover, BCM2835 is the only bcm2708 platform chip capable of running linux. No other device can benefit from the driver. If there are alternative boards with BCM2835 then maybe...but the I'd expect them to borrow as much from RPi implementation as possible, including your driver.

[koalo]

Do I understand you correctly, that you think there should not be any BCM2835 specific stuff in the kernel.org sources?
If yes, then you should have a look there.

[maximus21]

Not exactly. The driver must be made very generic without any reference to RPi implementation. Implement setting daifmt, pll, div to be called from the card driver. Create an interface (data structure) for passing non-integer clock division settings. And then forgetting about all macros and helpers specific to RPi.
Who would benefit from this work besides RPi users and Broadcom?

[koalo]

The work has to be done anyway for better support of multiple codecs and the amount of macros and helpers is small enough.
I don't think the idea of Linux is to have a generic kernel and a large amount of kernels for each platform.

[maximus21]

Glad that you are not afraid of the work :) I can help with reviewing and testing I2S module after I get back from holidays. Still not sure why you need I2C. Is it to make codecs work on RPi running the mainstream kernel?

[koalo]

Thanks! I know that there might be an undiscovered stumbling block that prevents using I2S with the mainstream kernel, but I am really interested if this is actually the case.
I2C is needed for accessing the codecs - not all, but all that I have used so far. Until now, I failed to get the device tree entries right so that the I2C bus is accessed, but that should be only a matter of time, because I2C for RPi is officially supported by the mainstream kernel.

[maximus21]

popcornmix has stated:
We will move the main firmware branch to 3.10 in a few weeks.
Moving to dev tree and 2835 machine is desirable but not planned by me.
It is a significant amount of work, and will cause breakage.
A number of drivers (like vchiq and dwc_otg) are not supported by 2835 and will need patching in.

So there will be no support for important peripherals potentially meaning no networking. I won't be able to test and debug through serial port so I could join the party only when ethernet is working. How far did you get with device tree?

[koalo]

I will not proceed any further in this topic before the mid of this month.
You are right, unfortunately there is no network support for the mainstream
kernel.

2013/10/2 maximus21 [email protected]

popcornmix has stated:
We will move the main firmware branch to 3.10 in a few weeks.
Moving to dev tree and 2835 machine is desirable but not planned by me.
It is a significant amount of work, and will cause breakage.
A number of drivers (like vchiq and dwc_otg) are not supported by 2835 and
will need patching in.

So there will be no support for important peripherals potentially meaning
no networking. I won't be able to test and debug through serial port so I
could join the party only when ethernet is working. How far did you get
with device tree?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-25525186
.

[koalo]

There is now network support for the mainstream kernel and device tree is a short term goal of the foundation. A proprietary technique should not be necessary.

[maximus21]

Finally! After finishing my project with the new 3.10 RasPi kernel I will take a look at your device tree version.