Upstreaming Beagleboard.org Kernel Patches

Google Summer of Code
1

Hi everyone,

I am Emilio L�pez, a Computer Science student from Argentina. I was
looking at all the different GSoC project proposals available today and
I found an interesting one on the wiki titled "Upstreaming
Beagleboard.org Kernel Patches"[1]

I have some experience working with the Linux kernel; I've written a
clock driver[2] for sunxi boards (Allwinner A10, A13 SoCs) as well as
contributed some misc. DT patches[3], all of which should be landing on
mainline as soon as the 3.10 cycle starts.

I had a quick look at the patches on beagleboard's github[4]; there's a
lot of patches there, but most of the ones I looked at seemed to be in
good shape to be mainlined as-is or with little rework after the
respective maintainers comment on them.

Please let me know what should I do to apply to work on this as part of
GSoC. I will be idling on both #beagle and #beagle-gsoc if you want to
talk with me personally :slight_smile:

Cheers,

Emilio

[1]:
http://elinux.org/BeagleBoard/GSoC/Ideas#Upstreaming_Beagleboard.org_Kernel_Patches
[2]:
https://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=search;h=refs/heads/clk-next;s=emilio@elopez;st=author
[3]:
http://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/log/?h=for-next&qt=author&q=emilio%40elopez
[4]: https://github.com/beagleboard/kernel/tree/3.8

2

Hi everyone,

As per Tom's recommendation, I'm attaching my draft proposal for this
project; I'm open to all suggestions, comments and criticisms :slight_smile:

Thanks,

Emilio

proposal.odt (34.4 KB)

3

I'll first criticize the project, since "upstream all the patches" is overly broad :slight_smile: What I recommend is picking a small number or items and focussing on those. For example:

PWM: the pwm api that when into mainline doesn't have sysfs support like the competing api did, there are patches in the beagle tree to add 'pwm-test.ko' to create a sysfs entry, but that's a hack. So adding clean sysfs support to the pwm api would be great and allow us to drop a dozen patches.

IIO: the version of the IIO driver we have in the tree also doesn't create sysfs entries, so there's the iio-helper module and DT bindings. Fixing the drivers to have sysfs bindings again and/or expanding iio-helper would be a nice project.

There's a skeleton driver for an i2c pwm device in the beagle tree, taking that and converting the existing driver to that chip from a LED class driver to a generic PWM class driver with option pwm-leds on top would also be great.

The above examples would greatly help my with my robot project :slight_smile:

regards,

Koen

4

Hi,

I am Zubair Lutfullah, an MSc. Embedded Systems student at the University of Leeds, UK at the moment.

I have worked for two years on the Beagleboard-XM before starting my MSc. here and I know the amount of pain to go through when you want certain features from newer kernels and keep your stable kernel as is..

Good Luck I guess. Because I wanted to write a GSoC application on this idea as well.

Is there any limitation about how many people can work on the same project?

The only mention of such incidences on the GSoC FAQ's are

"10. Can a group apply for and work on a single proposal?

No, only an individual may work on a given project.

11. What happens if two students are accepted to work on the same project, e.g. from an organization's Ideas list?

That's fine, a little duplication is par for the course in open source."

In this particular case, I guess we can just work on different patches. That will speed things up a lot!

LIke I mentioned to Emilio earlier, this project is overly broad, just pick a topic and work on it. I estimate that 3 (PWM, IIO, i2c pwm driver) examples I mentioned will keep 3 students busy enough :slight_smile:

regards,

Koen

5

Hi,

Thank-you Koen for narrowing down the scope of the patch work.

I would like to give time to IIO sysfs.
Because among these three, I think the one that requires the most attention would be IIO. Fixing it so that it has sysfs bindings.
This would make it easy to access dozens of peripherals from maxim/analog etc who release IIO device drivers.[1]
It lays a foundation for other drivers and the maintenance overhead of patches and workarounds will keep rising until someone does it. (hopefully me :slight_smile: )

I assume Koen/Matt will be mentoring this project.
Do you have a further specific area in mind.
Would it be possible for you guys to give my draft proposal a skim before the deadline or should I work and refine it myself?

If (yes),
do you guys prefer working via the melange website for the draft.
OR I can make a google doc and give permissions;
else
no problem :slight_smile:

Whichever suits you…

Cheers
Zubair

[1] http://sourceforge.net/apps/mediawiki/iioutils/index.php?title=Device_List

6

Hi,

Thank-you Koen for narrowing down the scope of the patch work.

I would like to give time to IIO sysfs.
Because among these three, I think the one that requires the most attention would be IIO. Fixing it so that it has sysfs bindings.
This would make it easy to access dozens of peripherals from maxim/analog etc who release IIO device drivers.[1]

Most IIO drivers already have sysfs binding, I think it's part of the core IIO framework (correct if I'm wrong!), the TI ADC drivers had the sysfs entries and then lost them. So this project is not for generic IIO bindings :slight_smile:

I'm not an IIO expert, but here's what I think needs to get done for the ADC drivers:

1) support sysfs entries
2) fix the actual /dev/iio:deviceX usage, that doesn't seem to work currently
3) write a small test app to read from the device node and output to console, should be largely copy&paste from iio-utils and the in-kernel test app in staging/Documentation

That's the base work, when that's working:

4) Investigate LCD+touchscreen + ADC interaction, allocating 4 channels to the TS and using the remaining four for ADC should work, but people report weird interactions.

and/or

5) Write a hwmon driver that reads AIN7 and sets the correct mux in the PMIC to measure current consumption. using the shunt resistor attached to AIN7.

It lays a foundation for other drivers and the maintenance overhead of patches and workarounds will keep rising until someone does it. (hopefully me :slight_smile: )

I assume Koen/Matt will be mentoring this project.
Do you have a further specific area in mind.
Would it be possible for you guys to give my draft proposal a skim before the deadline or should I work and refine it myself?

Certainly!

If (yes),
           do you guys prefer working via the melange website for the draft.
           OR I can make a google doc and give permissions;

I think either is fine, if you make a change, just email this list. I think most mentors check their email more often than melange :slight_smile:

For students wanting to work on IIO for the TSADC block: we can provide known working i2c sensors with IIO support if needed. That should provide a way to see if your app is broken or the TSADC driver :slight_smile:

regards,

Koen

7

Thank-you very much!

I’ll research this more thoroughly and draft a proposal.
I hope someone is willing to mentor this area of development.

Get back to you soon! :slight_smile:

Cheers
Zubair

p.s feel free to ping if you come up with relevant ideas in the meantime.

8

Please don’t hijack threads. This makes it very difficult to give lengthy feedback to other students.