Upstreaming Beagleboard.org Kernel Patches

Google Summer of Code
1

Hi,

Congratulations to BB.org on making it as a mentoring organization for GSoC 2014 :).

I’m ZubairLK. Most of the BB.org members should (hopefully :wink: ) recognize me from GSoC 2013.

I was working on upstreaming the ADC patches to the mainline kernel.
The driver upgrade required a major rework.
But I managed to upstream continuous sampling support by the end.

I’d like to participate for GSoC 2014. And continue in the same area as I believe I can be more effective
due to my previous background with upstreaming and kernel development. Its exciting work :slight_smile:

Before posting here, I had a cursory look at 3.12 kernel for BBB on github and 3.13 mainline.

Quite a few of the small patches have already made it upstream. That’s great. :slight_smile:

I can work on upstreaming other patches bit by bit. Audio/omap-fix-dt folders have the most patches.
Again. Some have made it already…

I notice capmgr is completely missing from mainline.

I could look into that. Unless the community knows that the mainline folk have issues with it.
Which might mean a rework. Cape manager is an integral part of the BBB community. And upstreaming
it should be great. Can some mentors shed some light on this?

I’m completely open to guidance from senior members of the community as to which set of patches are a higher priority.
Or if I should invest time in some project.

Awaiting positive feedback

Thanks
ZubairLK

2

Hi,

Congratulations to BB.org on making it as a mentoring organization for
GSoC 2014 :).

Whoop!

I'm ZubairLK. Most of the BB.org members should (hopefully :wink: ) recognize
me from GSoC 2013.

Certainly!

I was working on upstreaming the ADC patches to the mainline kernel.
The driver upgrade required a major rework.
But I managed to upstream continuous sampling support by the end.

I'd like to participate for GSoC 2014. And continue in the same area as I
believe I can be more effective
due to my previous background with upstreaming and kernel development. Its
exciting work :slight_smile:

Glad you are looking at participating again.

Before posting here, I had a cursory look at 3.12 kernel for BBB on github
and 3.13 mainline.

Quite a few of the small patches have already made it upstream. That's
great. :slight_smile:

I can work on upstreaming other patches bit by bit. Audio/omap-fix-dt
folders have the most patches.
Again. Some have made it already..

I notice capmgr is completely missing from mainline.

I could look into that. Unless the community knows that the mainline folk
have issues with it.
Which might mean a rework. Cape manager is an integral part of the BBB
community. And upstreaming
it should be great. Can some mentors shed some light on this?

Working on upstreaming capemgr would be fantastic. Pantelis put a lot of
work into it, but ultimately wasn't funded for all of his efforts. He has
sent device tree overlay support patches to upstream lists and it seemed
like it was getting pretty close.

The last submission I'm aware of is: LKML: Pantelis Antoniou: [PATCH 0/3 - V2] Introducing Device Tree Overlays

I believe reviewing those patches and responding to the list with review
comments, suggestions and offers of help would be good.

I'm completely open to guidance from senior members of the community as to
which set of patches are a higher priority.
Or if I should invest time in some project.

Overall testing of and contributions to the mainline kernel activities is
good --- a greatly appreciated activity I hope you pursue and, I believe,
the most important task you can take on relative to the BeagleBoard.org
community.

For BeagleBone Black, I believe the biggest gaps in mainline are:
* Device Tree Overlays + CapeMgr
* SGX support for DRM drivers

Awaiting positive feedback

Kinda picky, no? :wink:

3

Hi,

I'm ZubairLK. Most of the BB.org members should (hopefully :wink: ) recognize me from GSoC 2013.

You should recognize me, I'm tcort from BB.org GSoC 2013 :slight_smile:

Upstreaming...
* Device Tree Overlays + CapeMgr

I really like this idea. Last summer when I was working on support for
BeagleBone capes within Minix, I wanted to look at the Linux device
tree fragments to get the settings for an LCD display (resolution,
horizontal front porch, etc) and to get the list of pins used by the
weather cape. It was hard tracking the files down because they weren't
in the kernel.org kernel. I think I found them eventually, but they
were in patch files in a git repo somewhere. Having them in the
kernel.org kernel would make them accessible and easy to find.
Additionally, I wanted to test a cape in Linux (to see if I had a
hardware problem or a software problem), but it was a new cape and it
needed a newer kernel than I was running. Figuring out where to get
the sources and how to patch and build the kernel was tough. I'd be
really happy if I could just use the kernel.org kernel and some
standard .config file.

Thomas

4

Hi,

> I'm ZubairLK. Most of the BB.org members should (hopefully :wink: )
recognize me from GSoC 2013.

You should recognize me, I'm tcort from BB.org GSoC 2013 :slight_smile:

Happy you are still active on the list.

> Upstreaming...
> * Device Tree Overlays + CapeMgr

I really like this idea. Last summer when I was working on support for
BeagleBone capes within Minix, I wanted to look at the Linux device
tree fragments to get the settings for an LCD display (resolution,
horizontal front porch, etc) and to get the list of pins used by the
weather cape. It was hard tracking the files down because they weren't
in the kernel.org kernel. I think I found them eventually, but they
were in patch files in a git repo somewhere. Having them in the
kernel.org kernel would make them accessible and easy to find.
Additionally, I wanted to test a cape in Linux (to see if I had a
hardware problem or a software problem), but it was a new cape and it
needed a newer kernel than I was running. Figuring out where to get
the sources and how to patch and build the kernel was tough. I'd be
really happy if I could just use the kernel.org kernel and some
standard .config file.

Are there more Minix or FreeBSD activities for BeagleBone for which you are
aware?

5

Nice to see you too tcort. Great to know GSoC leaves active members :slight_smile:

"

For BeagleBone Black, I believe the biggest gaps in mainline are:

  • Device Tree Overlays + CapeMgr
  • SGX support for DRM drivers
    "
    For DT Overlays and CapeMgr.

I checked out lkml. https://lkml.org/lkml/2013/11/5/338
There was a raging debate about the need for it as well. That can get tricky for a student like me…
Another patchset to note is the move from /proc/device-tree to /sys. Patches were by Grant Likely but not merged.
“Kobjectify device tree structures” https://lkml.org/lkml/2013/11/15/377

I don’t want to get caught in a place way above my league.
But there is no harm in starting the debate process again as part of GSoC :slight_smile:

  • SGX support for DRM drivers
    I assume you are talking about the patches in the beta Graphics SDK 5.01.01.01?
    Upstreaming is one thing. Getting them into the beagle tree smoothly should be easy. Or is it done somewhere perhaps?
    I’ll have a look on this angle later.

Doing both tasks could get too much…
But then again. Work on either one/both of them can be blocked by kernel mailing lists…

Regards
ZubairLK

6

fyi: here's the current sgx patchlist to make 5.00.00.01 -> 5.01.01.01
work with qt's embedded wm.. (no xorg/etc)

https://github.com/beagleboard/kernel/tree/3.13/patches/sgx

most of it is just ports of drivers (prcm/reset drivers from ti's
3.12.x tree) the drm revert is just noise and can be dropped at this
point, as TI hasn't released "any" drm/sgx drivers for am335x.

Regards,

7

Are there more Minix or FreeBSD activities for BeagleBone for which you are
aware?

KeesJ gave a talk at FOSDEM this month about Minix on ARM
(BeagleBoard/BeagleBone). The port is progressing well. There is a
video here: http://video.fosdem.org/2014/UB2252A_Lameere/Saturday/MINIX_3_on_ARM.webm
We're on the road to Minix 3.3.0 (due out in early summer) which
should have a much improved Minix/arm experience.

Looking through the GSoC projects, I found that OpenBSD has a
BeagleBone Black project idea:
http://www.openbsdfoundation.org/gsoc2014.html#arm-bootloader

8

The OpenBSD BBB project sounds interesting. I’ll look into it.

The sgx patches look to be in beta states… And attempts by the authors to upstream have faced resistance
The reset controller patch
http://www.spinics.net/lists/arm-kernel/msg259553.html
The PRCM driver
https://lkml.org/lkml/2013/9/2/279

The last patch. revert “drm: remove procfs code, take 2”…
If I read the log for this commit
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm?id=cb6458f97b53d7f73043206c18014b3ca63ac345
upstreaming it will get painful… no?

Both SGX/Capemgr seem monumental upstream efforts and face resistance from the kernel maintainers…
I’m finding it difficult to break it into bite sized chunks from a GSoC application perspective.
I guess a possible first task could be to port the sgx patches in 3.13 to 3.12 and get it working in our tree.

But I’d like a little help from mentors to break tasks down to a GSoC student level please…

Thanks
ZubairLK

9

The OpenBSD BBB project sounds interesting. I'll look into it.

The sgx patches look to be in beta states.. And attempts by the authors to
upstream have faced resistance
The reset controller patch
[PATCH v10] reset: Add driver for gpio-controlled reset pins — ARM, OMAP, Xscale Linux Kernel
The PRCM driver
LKML: Afzal Mohammed: [PATCH RFC 0/6] ARM: OMAP2+: AM43x/AM335x prcm reset driver

The last patch. revert "drm: remove procfs code, take 2"..
If I read the log for this commit
drm: remove procfs code, take 2 - kernel/git/torvalds/linux.git - Linux kernel source tree
upstreaming it will get painful.. no?

Just ignore that patch, the sgx "drm" bits where only written up to
3.8, and since we don't have any xorg/drm driver for am335x we can't
test that functionality anyways.

Both SGX/Capemgr seem monumental upstream efforts and face resistance from
the kernel maintainers..
I'm finding it difficult to break it into bite sized chunks from a GSoC
application perspective.
I guess a possible first task could be to port the sgx patches in 3.13 to
3.12 and get it working in our tree.

I already did:
https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.12/patches/sgx

just didn't push them to the shared v3.12.x tree, as i'm focusing on
v3.13.x/v3.14-rcX.

btw:

I think this gsoc topic made more sense in prior years when nothing
was upstream for the am335x.

Regards,

10

The sgx patches look to be in beta states… And attempts by the authors to
upstream have faced resistance
The reset controller patch
http://www.spinics.net/lists/arm-kernel/msg259553.html
The PRCM driver
https://lkml.org/lkml/2013/9/2/279

The last patch. revert “drm: remove procfs code, take 2”…
If I read the log for this commit
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm?id=cb6458f97b53d7f73043206c18014b3ca63ac345
upstreaming it will get painful… no?

Just ignore that patch, the sgx “drm” bits where only written up to
3.8, and since we don’t have any xorg/drm driver for am335x we can’t
test that functionality anyways.

I see.

Both SGX/Capemgr seem monumental upstream efforts and face resistance from
the kernel maintainers…
I’m finding it difficult to break it into bite sized chunks from a GSoC
application perspective.
I guess a possible first task could be to port the sgx patches in 3.13 to
3.12 and get it working in our tree.

I already did:
https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.12/patches/sgx

Great.

just didn’t push them to the shared v3.12.x tree, as i’m focusing on
v3.13.x/v3.14-rcX.

btw:

I think this gsoc topic made more sense in prior years when nothing
was upstream for the am335x.

I’m pretty sure there is still sizeable stuff left for a GSoC application…

Regards
ZubairLK

11

The sgx patches look to be in beta states… And attempts by the authors to
upstream have faced resistance
The reset controller patch
http://www.spinics.net/lists/arm-kernel/msg259553.html
The PRCM driver
https://lkml.org/lkml/2013/9/2/279

The last patch. revert “drm: remove procfs code, take 2”…
If I read the log for this commit
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm?id=cb6458f97b53d7f73043206c18014b3ca63ac345
upstreaming it will get painful… no?

Just ignore that patch, the sgx “drm” bits where only written up to
3.8, and since we don’t have any xorg/drm driver for am335x we can’t
test that functionality anyways.

I see.

Both SGX/Capemgr seem monumental upstream efforts and face resistance from
the kernel maintainers…
I’m finding it difficult to break it into bite sized chunks from a GSoC
application perspective.
I guess a possible first task could be to port the sgx patches in 3.13 to
3.12 and get it working in our tree.

I already did:
https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.12/patches/sgx

Great.

just didn’t push them to the shared v3.12.x tree, as i’m focusing on
v3.13.x/v3.14-rcX.

btw:

I think this gsoc topic made more sense in prior years when nothing
was upstream for the am335x.

I’m pretty sure there is still sizeable stuff left for a GSoC application…

Are you sufficiently aware of the work you can make specific recommendations on the Ideas page?

12

The goal is to bring the BB tree as close to mainline as possible.

Setting SGX and Capemgr aside, I tried going through the patch list in finer detail.

I compared the states of the bleeding edge mainline. 3.14-RC5 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/

And 3.12 https://github.com/beagleboard/kernel/tree/3.12/

It took quite a bit of time and effort. But I think its worth it.

Audio

/3.12/patches/audio/0001-ASoC-davinci-evm-Move-sysclk-logic-away-from-evm_hw_.patch Upstreamed already
/3.12/patches/audio/0002-ASoC-davinci-evm-Add-device-tree-binding.patch Upstreamed already
/3.12/patches/audio/0003-ASoC-davinci-mcasp-Add-DMA-register-locations-to-DT.patch Upstreamed already. But different patch title
/3.12/patches/audio/0004-ASoC-davinci-mcasp-Extract-DMA-channels-directly-fro.patch Upstreamed already
/3.12/patches/audio/0005-ASoC-davinci-mcasp-Interrupts-property-to-optional-a.patch Upstreamed already. Different Name
/3.12/patches/audio/0006-ASoC-davinci-Add-support-for-AM33xx-SoC-Audio.patch Upstreamed already
/3.12/patches/audio/0007-ASoC-davinci-mcasp-Remove-redundant-num-serializer-D.patch Upstreamed already

/3.12/patches/audio/0008-ASoC-davinci-evm-Add-named-clock-reference-to-DT-bin.patch Not Upstreamed.
/3.12/patches/audio/0009-ASoC-davinci-evm-HDMI-audio-support-for-TDA998x-trou.patch Not Upstreamed.

These are heavy duty patches adding hdmi audio support for BBB.
Activity on mailing lists…
http://thread.gmane.org/gmane.linux.alsa.devel/118086/focus=110209

/3.12/patches/audio/0010-ASoC-hdmi-codec-Add-devicetree-binding-with-document.patch Upstreamed
/3.12/patches/audio/0011-ASoC-hdmi-codec-Add-SNDRV_PCM_FMTBIT_32_LE-playback-.patch Upstreamed
/3.12/patches/audio/0012-ASoC-davinci-HDMI-audio-build-for-AM33XX-and-TDA998x.patch Not upstreamed. Related to HDMI above.
/3.12/patches/audio/0013-Audio-McASP-Add-McASP-Device-Tree-Bindings.patch Upstreamed
/3.12/patches/audio/0014-ASoc-McASP-Lift-Reset-on-CLK-Dividers-when-RX-TX.patch Not Upstreamed
/3.12/patches/audio/0015-ASoc-Davinci-EVM-Config-12MHz-CLK-for-AIC3x-Codec.patch Not Upstreamed.

Audio alone can be an uphill task to upstream if the mailing lists want things a certain way. I’ll have to go through the previous lkml thread in finer detail.

Cpufreq
/3.12/patches/cpufreq/0001-ARM-OMAP3-do-not-register-non-dt-OPP-tables-for-devi.patch Upstreamed
/3.12/patches/cpufreq/0002-ARM-OMAP2-add-missing-lateinit-hook-for-calling-pm-l.patch Upstreamed
/3.12/patches/cpufreq/0003-ARM-OMAP3-use-cpu0-cpufreq-driver-in-device-tree-sup.patch Upstreamed
/3.12/patches/cpufreq/0004-ARM-dts-OMAP3-add-clock-nodes-for-CPU.patch Not upstreamed
/3.12/patches/cpufreq/0005-hack-boneblack-enable-1Ghz-operation.patch Not upstreamed

Deassert hard reset
/3.12/patches/deassert-hard-reset/0001-ARM-omap-add-DT-support-for-deasserting-hardware-res.patch

DMA-devel
/3.12/patches/dma-devel/0001-da8xx-config-Enable-MMC-and-FS-options.patch Dont even know why this is there. Seems out of place.
/3.12/patches/dma-devel/0002-sound-soc-soc-dmaengine-pcm-Add-support-for-new-DMAE.patch Not upstreamed

DRM
/3.12/patches/drm/0001-drm-tilcdc-Add-I2C-HDMI-audio-config-for-tda998x.patch Not upstreamed. Relevant to HDMI audio above.

DTC-fixes
/3.12/patches/dtc-fixes/0001-Fix-util_is_printable_string.patch Not Upstreamed.
/3.12/patches/dtc-fixes/0002-fdtdump-properly-handle-multi-string-properties.patch Not Upstreamed.

DTC-overlays
/home/zubairlk/fresh/3.12/patches/dtc-overlays/0001-dtc-Dynamic-symbols-fixup-support.patch Not Upstreamed
/home/zubairlk/fresh/3.12/patches/dtc-overlays/0002-dtc-Dynamic-symbols-fixup-support-shipped.patch Not Upstreamed.

These overlays seem like heavy duty stuff…
Attracted attention on lkml in Nov 2013. But Panto’s second attempt in January seems to not have received any response :s
http://www.spinics.net/lists/devicetree/msg10654.html
https://lkml.org/lkml/2013/1/4/295

I guess these would be linked with capemgr in some way…

dts-fixes
/3.12/patches/dts-fixes/0001-dts-beaglebone-Add-I2C-definitions-for-EEPROMs-capes.patch Not upstreamed.
/3.12/patches/dts-fixes/0002-arm-beaglebone-dts-Add-capemanager-to-the-DTS.patch Not Upstreamed
/3.12/patches/dts-fixes/0003-OF-Compile-Device-Tree-sources-with-resolve-option.patch Not upstreamed
/3.12/patches/dts-fixes/0004-am335x-bone-enable-HDMI-on-black.patch Not upstreamed
capemgr and hdmi audio. Being unable to mainline a core functionality adds a significant overhead to patch maintenance…

general-fixes
/3.12/patches/general-fixes/0001-add-PM-firmware.patch Cant Upstream
/3.12/patches/general-fixes/0002-ARM-CUSTOM-Build-a-uImage-with-dtb-already-appended.patch Cant upstream
/3.12/patches/general-fixes/0003-defconfig-add-for-mainline-on-the-beaglebone.patch Cant upstream

These are hacks. Nice ones no doubt. but can’t upstream them

i2c-fixes
/3.12/patches/i2c-fixes/0001-i2c-EEPROM-In-kernel-memory-accessor-interface.patch Not Upstreamed
/3.12/patches/i2c-fixes/0002-grove-i2c-Add-rudimentary-grove-i2c-motor-control-dr.patch Not upstreamed.
Interesting driver for motor control. not sure if its upstream material though…

lcdc-fixes
/home/zubairlk/fresh/3.12/patches/lcdc-fixes/0001-gpu-drm-tilcdc-get-preferred_bpp-value-from-DT.patch Upstreamed
/home/zubairlk/fresh/3.12/patches/lcdc-fixes/0002-drm-tilcdc-fixing-i2c-slave-initialization-race.patch Upstreamed
/home/zubairlk/fresh/3.12/patches/lcdc-fixes/0003-drm-tilcdc-Fix-scheduling-while-atomic-from-irq-hand.patch Not upstreamed
/home/zubairlk/fresh/3.12/patches/lcdc-fixes/0004-tilcdc-Slave-panel-settings-read-from-DT-now.patch Not upstreamed

mmc-fixes
/3.12/patches/mmc-fixes/0001-omap-hsmmc-Correct-usage-of-of_find_node_by_name.patch Not upstreamed
/3.12/patches/mmc-fixes/0002-omap_hsmmc-Add-reset-gpio.patch Not upstreamed

Upstreaming mmc ones might lead to the BBB booting straight from mainline? That would be cool

net
/3.12/patches/net/0001-am33xx-cpsw-default-to-ethernet-hwaddr-from-efuse-if.patch Not upstreamed

Large patch.
Upstream effort has taken place https://www.mail-archive.com/linux-omap@vger.kernel.org/msg95056.html

of-fixes
/3.12/patches/of-fixes/0001-of-i2c-Export-single-device-registration-method.patch Not upstreamed.
/3.12/patches/of-fixes/0002-OF-Clear-detach-flag-on-attach.patch Not upstreamed
/3.12/patches/of-fixes/0003-OF-Introduce-device-tree-node-flag-helpers.patch Not upstreamed
/3.12/patches/of-fixes/0004-OF-export-of_property_notify.patch Not upstreamed
/3.12/patches/of-fixes/0005-OF-Export-all-DT-proc-update-functions.patch Not upstreamed
/3.12/patches/of-fixes/0006-OF-Introduce-utility-helper-functions.patch Not upstreamed
/3.12/patches/of-fixes/0007-OF-Introduce-Device-Tree-resolve-support.patch Not upstreamed
/3.12/patches/of-fixes/0008-OF-Introduce-DT-overlay-support.patch Not upstreamed

except for the first few, most seem like updates for capemgr/dynamic DT loading. Just had a cursory look. so i might be wrong.

omap-next-dt
3.12/patches/omap-next-dt/
0001-ARM-dts-AM33XX-Add-PMU-support.patch Upstreamed
3.12/patches/omap-next-dt/0002-ARM-dts-AM33xx-Correct-gpio-interrupt-cells-property.patch Upstreamed
3.12/patches/omap-next-dt/0003-ARM-dts-AM33XX-Add-EDMA-support.patch Upstreamed
3.12/patches/omap-next-dt/0004-ARM-dts-AM33XX-Add-SPI-DMA-support.patch Upstreamed
3.12/patches/omap-next-dt/0005-ARM-dts-AM33XX-Add-MMC-support-and-documentation.patch Upstreamed
3.12/patches/omap-next-dt/0006-ARM-dts-am335x-bone-add-CD-for-mmc1.patch Upstreamed
3.12/patches/omap-next-dt/0007-ARM-dts-am335x-boneblack-add-eMMC-DT-entry.patch Upstreamed
3.12/patches/omap-next-dt/0008-ARM-dts-am335x-bone-common-switch-mmc1-to-4-bit-mode.patch Upstreamed
3.12/patches/omap-next-dt/0009-ARM-dts-am335x-bone-common-add-cpu0-and-mmc1-trigger.patch Upstreamed
3.12/patches/omap-next-dt/0010-ARM-dts-AM33XX-use-pinmux-node-defined-in-included-f.patch Upstreamed
3.12/patches/omap-next-dt/0011-ARM-dts-AM33XX-don-t-redefine-OCP-bus-and-device-nod.patch Upstreamed
3.12/patches/omap-next-dt/0012-ARM-dts-AM33XX-add-ethernet-alias-s-for-am33xx.patch Upstreamed
3.12/patches/omap-next-dt/0013-ARM-dts-am335x-boneblack-move-fixed-regulator-to-boa.patch Upstreamed
3.12/patches/omap-next-dt/0014-ARM-dts-am335x-bone-common-correct-mux-mode-for-cmd-.patch Upstreamed

Nice work on upstreaming these ones!

pdev-fixes

3.12/patches/pdev-fixes/0001-pdev-Fix-platform-device-resource-linking.patch Not upstreamed
3.12/patches/pdev-fixes/0002-of-Link-platform-device-resources-properly.patch Not upstreamed
3.12/patches/pdev-fixes/0003-omap-Properly-handle-resources-for-omap_devices.patch Not upstreamed
3.12/patches/pdev-fixes/0004-omap-Avoid-crashes-in-the-case-of-hwmod-misconfigura.patch Not upstreamed

pinctrl-fixes
3.12/patches/pinctrl-fixes/0001-pinctrl-pinctrl-single-must-be-initialized-early.patch Not upstreamed

reset
3.12/patches/reset/0001-reset-Add-driver-for-gpio-controlled-reset-pins.patch Not upstreamed
Quite a bit of effort on it.
http://www.spinics.net/lists/arm-kernel/msg259553.html

tscadc
3.12/patches/tscadc/0001-Forwarding-changes-from-mfd-next.patch Upstreamed

3.12/patches/tscadc/0002-MFD-ti_tscadc-disable-TSC-control.patch Upstreamed
3.12/patches/tscadc/0003-IIO-ADC-ti_adc-Fix-1st-sample-read.patch Upstreamed
3.12/patches/tscadc/0004-iio-ti_am335x_adc-Added-iio_voltageX_scale.patch Not Upstreamed.

It has been a year already!? :s They pulled GSoC 2014 back i think?

I remember i didn’t do it because I used 1800mV hard coded values specific to BBB. But driver shouldn’t have that. Wanted to check TRM for a register to read or some configuration register etc. Didn’t have the time.

To sum up,

For GSoC 2014, I see significant work in several areas.

HDMI Audio support.
Net. Ethernet patch
MMC.
tiny fixes here n there…
These are BBB relevant only. Hardware specific. Makes it easier to upstream. I’d like to start with these ones.

reset: Add driver for gpio-controlled reset pins.
And Capemgr patches.

These are kernel framework relevant. They attract a lot of attention from kernel folk from all sorts of places
After HDMI audio and ethernet, i’d like to have an attempt at these…

With respect to schedule for 3 months. I can’t really say.

Awaiting feedback from mentors in the community…

Regards
ZubairLK

13

The goal is to bring the BB tree as close to mainline as possible.

Setting SGX and Capemgr aside, I tried going through the patch list in finer
detail.

I compared the states of the bleeding edge mainline. 3.14-RC5
kernel/git/torvalds/linux.git - Linux kernel source tree

And 3.12 GitHub - beagleboard/kernel at 3.12

It took quite a bit of time and effort. But I think its worth it.

Audio

/3.12/patches/audio/0001-ASoC-davinci-evm-Move-sysclk-logic-away-from-evm_hw_.patch
Upstreamed already
/3.12/patches/audio/0002-ASoC-davinci-evm-Add-device-tree-binding.patch
Upstreamed already
/3.12/patches/audio/0003-ASoC-davinci-mcasp-Add-DMA-register-locations-to-DT.patch
Upstreamed already. But different patch title
/3.12/patches/audio/0004-ASoC-davinci-mcasp-Extract-DMA-channels-directly-fro.patch
Upstreamed already
/3.12/patches/audio/0005-ASoC-davinci-mcasp-Interrupts-property-to-optional-a.patch
Upstreamed already. Different Name
/3.12/patches/audio/0006-ASoC-davinci-Add-support-for-AM33xx-SoC-Audio.patch
Upstreamed already
/3.12/patches/audio/0007-ASoC-davinci-mcasp-Remove-redundant-num-serializer-D.patch
Upstreamed already

/3.12/patches/audio/0008-ASoC-davinci-evm-Add-named-clock-reference-to-DT-bin.patch
Not Upstreamed.
/3.12/patches/audio/0009-ASoC-davinci-evm-HDMI-audio-support-for-TDA998x-trou.patch
Not Upstreamed.
These are heavy duty patches adding hdmi audio support for BBB.
Activity on mailing lists..
http://thread.gmane.org/gmane.linux.alsa.devel/118086/focus=110209

/3.12/patches/audio/0010-ASoC-hdmi-codec-Add-devicetree-binding-with-document.patch
Upstreamed
/3.12/patches/audio/0011-ASoC-hdmi-codec-Add-SNDRV_PCM_FMTBIT_32_LE-playback-.patch
Upstreamed
/3.12/patches/audio/0012-ASoC-davinci-HDMI-audio-build-for-AM33XX-and-TDA998x.patch
Not upstreamed. Related to HDMI above.
/3.12/patches/audio/0013-Audio-McASP-Add-McASP-Device-Tree-Bindings.patch
Upstreamed
/3.12/patches/audio/0014-ASoc-McASP-Lift-Reset-on-CLK-Dividers-when-RX-TX.patch
Not Upstreamed
/3.12/patches/audio/0015-ASoc-Davinci-EVM-Config-12MHz-CLK-for-AIC3x-Codec.patch
Not Upstreamed.

Audio alone can be an uphill task to upstream if the mailing lists want
things a certain way. I'll have to go through the previous lkml thread in
finer detail.

alot of these are now in mainline too, as some where backports/etc...

Cpufreq
/3.12/patches/cpufreq/0001-ARM-OMAP3-do-not-register-non-dt-OPP-tables-for-devi.patch
Upstreamed
/3.12/patches/cpufreq/0002-ARM-OMAP2-add-missing-lateinit-hook-for-calling-pm-l.patch
Upstreamed
/3.12/patches/cpufreq/0003-ARM-OMAP3-use-cpu0-cpufreq-driver-in-device-tree-sup.patch
Upstreamed
/3.12/patches/cpufreq/0004-ARM-dts-OMAP3-add-clock-nodes-for-CPU.patch Not
upstreamed
/3.12/patches/cpufreq/0005-hack-boneblack-enable-1Ghz-operation.patch Not
upstreamed

cpufreq-mainline:
This is all that is needed
https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.14/patches/dts/0002-arm-dts-am335x-boneblack-add-cpu0-opp-points.patch

Deassert hard reset
/3.12/patches/deassert-hard-reset/0001-ARM-omap-add-DT-support-for-deasserting-hardware-res.patch

DMA-devel
/3.12/patches/dma-devel/0001-da8xx-config-Enable-MMC-and-FS-options.patch
Dont even know why this is there. Seems out of place.
/3.12/patches/dma-devel/0002-sound-soc-soc-dmaengine-pcm-Add-support-for-new-DMAE.patch
Not upstreamed

DRM
/3.12/patches/drm/0001-drm-tilcdc-Add-I2C-HDMI-audio-config-for-tda998x.patch
Not upstreamed. Relevant to HDMI audio above.

DTC-fixes
/3.12/patches/dtc-fixes/0001-Fix-util_is_printable_string.patch Not
Upstreamed.
/3.12/patches/dtc-fixes/0002-fdtdump-properly-handle-multi-string-properties.patch
Not Upstreamed.

DTC-overlays
/home/zubairlk/fresh/3.12/patches/dtc-overlays/0001-dtc-Dynamic-symbols-fixup-support.patch
Not Upstreamed
/home/zubairlk/fresh/3.12/patches/dtc-overlays/0002-dtc-Dynamic-symbols-fixup-support-shipped.patch
Not Upstreamed.

These overlays seem like heavy duty stuff..
Attracted attention on lkml in Nov 2013. But Panto's second attempt in
January seems to not have received any response :s
http://www.spinics.net/lists/devicetree/msg10654.html
LKML: Pantelis Antoniou: dtc: Dynamic symbols & fixup support

I guess these would be linked with capemgr in some way..

dts-fixes
/3.12/patches/dts-fixes/0001-dts-beaglebone-Add-I2C-definitions-for-EEPROMs-capes.patch
Not upstreamed.
/3.12/patches/dts-fixes/0002-arm-beaglebone-dts-Add-capemanager-to-the-DTS.patch
Not Upstreamed
/3.12/patches/dts-fixes/0003-OF-Compile-Device-Tree-sources-with-resolve-option.patch
Not upstreamed
/3.12/patches/dts-fixes/0004-am335x-bone-enable-HDMI-on-black.patch Not
upstreamed
capemgr and hdmi audio. Being unable to mainline a core functionality adds a
significant overhead to patch maintenance..

general-fixes
/3.12/patches/general-fixes/0001-add-PM-firmware.patch Cant Upstream
/3.12/patches/general-fixes/0002-ARM-CUSTOM-Build-a-uImage-with-dtb-already-appended.patch
Cant upstream
/3.12/patches/general-fixes/0003-defconfig-add-for-mainline-on-the-beaglebone.patch
Cant upstream
These are hacks. Nice ones no doubt. but can't upstream them

i2c-fixes
/3.12/patches/i2c-fixes/0001-i2c-EEPROM-In-kernel-memory-accessor-interface.patch
Not Upstreamed
/3.12/patches/i2c-fixes/0002-grove-i2c-Add-rudimentary-grove-i2c-motor-control-dr.patch
Not upstreamed.
Interesting driver for motor control. not sure if its upstream material
though..

lcdc-fixes
/home/zubairlk/fresh/3.12/patches/lcdc-fixes/0001-gpu-drm-tilcdc-get-preferred_bpp-value-from-DT.patch
Upstreamed
/home/zubairlk/fresh/3.12/patches/lcdc-fixes/0002-drm-tilcdc-fixing-i2c-slave-initialization-race.patch
Upstreamed
/home/zubairlk/fresh/3.12/patches/lcdc-fixes/0003-drm-tilcdc-Fix-scheduling-while-atomic-from-irq-hand.patch
Not upstreamed
/home/zubairlk/fresh/3.12/patches/lcdc-fixes/0004-tilcdc-Slave-panel-settings-read-from-DT-now.patch
Not upstreamed

mmc-fixes
/3.12/patches/mmc-fixes/0001-omap-hsmmc-Correct-usage-of-of_find_node_by_name.patch
Not upstreamed
/3.12/patches/mmc-fixes/0002-omap_hsmmc-Add-reset-gpio.patch Not upstreamed

Upstreaming mmc ones might lead to the BBB booting straight from mainline?
That would be cool

mmc-fixes: not needed, mmc works out of the box on mainline...

net
/3.12/patches/net/0001-am33xx-cpsw-default-to-ethernet-hwaddr-from-efuse-if.patch
Not upstreamed
Large patch.
Upstream effort has taken place
[PATCHv2 RESEND] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt

by the sound of things, we might just have to do this in u-boot and
pass the mac address.

of-fixes
/3.12/patches/of-fixes/0001-of-i2c-Export-single-device-registration-method.patch
Not upstreamed.
/3.12/patches/of-fixes/0002-OF-Clear-detach-flag-on-attach.patch Not
upstreamed
/3.12/patches/of-fixes/0003-OF-Introduce-device-tree-node-flag-helpers.patch
Not upstreamed
/3.12/patches/of-fixes/0004-OF-export-of_property_notify.patch Not
upstreamed
/3.12/patches/of-fixes/0005-OF-Export-all-DT-proc-update-functions.patch Not
upstreamed
/3.12/patches/of-fixes/0006-OF-Introduce-utility-helper-functions.patch Not
upstreamed
/3.12/patches/of-fixes/0007-OF-Introduce-Device-Tree-resolve-support.patch
Not upstreamed
/3.12/patches/of-fixes/0008-OF-Introduce-DT-overlay-support.patch Not
upstreamed
except for the first few, most seem like updates for capemgr/dynamic DT
loading. Just had a cursory look. so i might be wrong.

omap-next-dt
3.12/patches/omap-next-dt/
0001-ARM-dts-AM33XX-Add-PMU-support.patch Upstreamed
3.12/patches/omap-next-dt/0002-ARM-dts-AM33xx-Correct-gpio-interrupt-cells-property.patch
Upstreamed
3.12/patches/omap-next-dt/0003-ARM-dts-AM33XX-Add-EDMA-support.patch
Upstreamed
3.12/patches/omap-next-dt/0004-ARM-dts-AM33XX-Add-SPI-DMA-support.patch
Upstreamed
3.12/patches/omap-next-dt/0005-ARM-dts-AM33XX-Add-MMC-support-and-documentation.patch
Upstreamed
3.12/patches/omap-next-dt/0006-ARM-dts-am335x-bone-add-CD-for-mmc1.patch
Upstreamed
3.12/patches/omap-next-dt/0007-ARM-dts-am335x-boneblack-add-eMMC-DT-entry.patch
Upstreamed
3.12/patches/omap-next-dt/0008-ARM-dts-am335x-bone-common-switch-mmc1-to-4-bit-mode.patch
Upstreamed
3.12/patches/omap-next-dt/0009-ARM-dts-am335x-bone-common-add-cpu0-and-mmc1-trigger.patch
Upstreamed
3.12/patches/omap-next-dt/0010-ARM-dts-AM33XX-use-pinmux-node-defined-in-included-f.patch
Upstreamed
3.12/patches/omap-next-dt/0011-ARM-dts-AM33XX-don-t-redefine-OCP-bus-and-device-nod.patch
Upstreamed
3.12/patches/omap-next-dt/0012-ARM-dts-AM33XX-add-ethernet-alias-s-for-am33xx.patch
Upstreamed
3.12/patches/omap-next-dt/0013-ARM-dts-am335x-boneblack-move-fixed-regulator-to-boa.patch
Upstreamed
3.12/patches/omap-next-dt/0014-ARM-dts-am335x-bone-common-correct-mux-mode-for-cmd-.patch
Upstreamed

Nice work on upstreaming these ones!

(we cheated, they were backports. :wink: )

pdev-fixes

3.12/patches/pdev-fixes/0001-pdev-Fix-platform-device-resource-linking.patch
Not upstreamed
3.12/patches/pdev-fixes/0002-of-Link-platform-device-resources-properly.patch
Not upstreamed
3.12/patches/pdev-fixes/0003-omap-Properly-handle-resources-for-omap_devices.patch
Not upstreamed
3.12/patches/pdev-fixes/0004-omap-Avoid-crashes-in-the-case-of-hwmod-misconfigura.patch
Not upstreamed

overlay related...

pinctrl-fixes
3.12/patches/pinctrl-fixes/0001-pinctrl-pinctrl-single-must-be-initialized-early.patch
Not upstreamed

reset
3.12/patches/reset/0001-reset-Add-driver-for-gpio-controlled-reset-pins.patch
Not upstreamed
Quite a bit of effort on it.
[PATCH v10] reset: Add driver for gpio-controlled reset pins — ARM, OMAP, Xscale Linux Kernel

tscadc
3.12/patches/tscadc/0001-Forwarding-changes-from-mfd-next.patch Upstreamed
3.12/patches/tscadc/0002-MFD-ti_tscadc-disable-TSC-control.patch Upstreamed
3.12/patches/tscadc/0003-IIO-ADC-ti_adc-Fix-1st-sample-read.patch Upstreamed
3.12/patches/tscadc/0004-iio-ti_am335x_adc-Added-iio_voltageX_scale.patch
Not Upstreamed.

It has been a year already!? :s They pulled GSoC 2014 back i think?

I remember i didn't do it because I used 1800mV hard coded values specific
to BBB. But driver shouldn't have that. Wanted to check TRM for a register
to read or some configuration register etc. Didn't have the time.

To sum up,

For GSoC 2014, I see significant work in several areas.

HDMI Audio support.
Net. Ethernet patch
MMC.
tiny fixes here n there..
These are BBB relevant *only*. Hardware specific. Makes it easier to
upstream. I'd like to start with these ones.

reset: Add driver for gpio-controlled reset pins.
And Capemgr patches.

These are kernel framework relevant. They attract a lot of attention from
kernel folk from all sorts of places
After HDMI audio and ethernet, i'd like to have an attempt at these..

With respect to schedule for 3 months. I can't really say.

Awaiting feedback from mentors in the community..

Regards,

14

Even the HDMI Audio ones? I thought those were still not upstreamed…
:confused:

15

Humm.. I thought those hit mainline, i remember back porting them to
v3.13.x but found my screen shook violently so i disabled them...
Kinda looks like they a helping push..

https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/log/?h=topic/davinci

http://lists.freedesktop.org/archives/dri-devel/2013-November/049324.html

Regards,

16

Great than.

HDMI Audio support needs help. I’ll start with upstreaming that.
Then move to capemgr. I have a feeling there will be a mailing list waiting time for capemgr.
So during that, I’ll check out all the little smaller fixes that could go upstream. Every bit helps :slight_smile:

Applications open tomorrow I believe. I’ll write up a proposal and post it here for feedback.
I hope someone is willing to mentor this project.

Regards
ZubairLK

p.s. I notice Koen is missing from the list…

17

HDMI Audio support needs help. I'll start with upstreaming that.

I would suggest looking into documentation to see if you can find
enough information to make any changes needed to the driver. I was
working on the driver for the HDMI chip (TDA19988) for Minix and found
out that there wasn't a full datasheet with register descriptions
available.

TC

18

Thanks for the heads up. But google gave me the datasheet from an unlikely source :slight_smile:

I have started work on the melange proposal. Would really love it if I could get some feedback for it

https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/zubairlk/5818821692620800

Thanks
ZubairLK

19

But google gave me the datasheet from an unlikely source :slight_smile:

Do you mind sharing? I've been looking for it for a year now. All I
can find is the pre-production draft TDA19988.pdf (Objective data
sheet) which doesn't have register descriptions. A similar chip's
datasheet, TDA9983B, has register descriptions but they don't line up
with the TDA19988 exactly.

Would really love it if I could get some feedback for it

When I go to the URL it says: "You are not logged in as the user in
the URL." I am logged though. At the top it says: "Logged in with
account linuxgeek@gmail.com - username: tcort"

20

But google gave me the datasheet from an unlikely source :slight_smile:

Do you mind sharing? I've been looking for it for a year now. All I
can find is the pre-production draft TDA19988.pdf (Objective data
sheet) which doesn't have register descriptions. A similar chip's
datasheet, TDA9983B, has register descriptions but they don't line up
with the TDA19988 exactly.

Much of it was documented here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i2c/tda998x_drv.c#n58

Otherwise, CircuitCo should have a copy somewhere, they might be able
to share it with you. But probally can't publish it.

Would really love it if I could get some feedback for it

When I go to the URL it says: "You are not logged in as the user in
the URL." I am logged though. At the top it says: "Logged in with
account linuxgeek@gmail.com - username: tcort"

Regards,