With addition to AM335x device in TI's portfolio, and various boards
including community + development boards around it; it becomes more and more
important and critical to get support for the device/boards in the mainline.
We are working on it and fully committed to get all the patches to the
But when we say upstream it takes its own course of journey, and depends on
various aspects, majorly -
- Acceptance for huge code changes:-
After recent discussion in the ARM community, it is unlikely that, huge
number of code addition would get merged so easily.
In case of AM335x, we have almost ~7K lines of new code, we have already
submitted RFC version of all baseport patches. And, we will keep making
attempts to submit the patches, get it reviewed and try to get accepted;
and that's continuous process.
- New framework changes:-
As we know, whole omap support in the kernel is built and dependent on
HWMOD approach, it applies to all omap family of devices
(including all AM parts).
And, slowly we are moving towards adding DT support, and will take some
time to shape up.
Now as BeagleBone (based on AM335x) is picking up very fast and wide, we
will definitely have huge community base and hobbyist working on various
daughterboard's (aka capes) for the board. So it is required to maintain the
patches which will eventually make its way to mainline.
There is a strong felt need to maintain a kernel repository which closely
tracks Linux-omap and also provides a holding area for patches which cannot
be pushed upstream for various reasons (see below)"
1) We will host separate repository in github, maintaining various patches
for AM335x based BeagleBone -
- All required patches to get BeagleBone boot to the Linux prompt.
(Baseport: Voltage + Power + Clock + HWMOD + more)
- Device Tree patches
- Patches which are submitted to the respective maintainer or
This may include driver patches, platform hook up patch,
bug fixes, etc...
- Patches which can not be submitted to maintainer/sub-maintainer list
due to various known reasons, like, patches dependent on
baseport/driver which is not upstream yet.
As an example of how submissions will be accepted,
If someone would like to add support for SPI based LCD support,
then he will have spi client driver patch and platform hookup patch.
Client driver patch MUST be submitted to the subsystem
maintainer/list and I can/will merge it only after ack from
maintainer. Just send me a pull request once you have obtained
The platform hookup patch may be dependent on baseport, and can
not be submitted to the list; all such patches I will be queuing
it in my repo after review on the email@example.com
2) The plan is to follow Linux-omap/master very closely and as and when it
is updated. I will try to rebase this bi-weekly.
3) We will use existing beagleboard mailing list
(firstname.lastname@example.org) for both, discussion and for Patch
4) As part of rebasing process, I will apply TAG before re-writing history,
so that we retain commit-ids.
Please note that, this is not replacement for any external existing
The ONLY goal here is to, enable community to use latest and greatest kernel
from mainline with BeagleBone for their development.