Den 18.01.2015 02:42, skrev Greg KH:
On Sun, Jan 18, 2015 at 02:30:17AM +0100, Noralf Tronnes wrote:
Den 18.01.2015 01:39, skrev Greg KH:
On Mon, Jan 12, 2015 at 06:06:44PM +0100, Noralf Tronnes wrote:
Here is a proposal to include in the staging tree the drivers from the
fbtft project at https://github.com/notro/fbtft. This project contains
a number of drivers small TFT LCD display modules, which are not
otherwise supported by the Linux kernel. This set of drivers appears
to be quite widely used in the RasberryPi community, and it's a shame
that they are not submitted to the upstream Linux kernel.
This is for now just a raw import, with only minimal changes compared
to the upstream version: I have not tried to fix any coding style
issue, or make any other improvement. I have only verified that the
entire set of drivers was building fine, which I believe is the main
rule when it comes to get code added to the staging tree.
Best regards,
Thomas Petazzoni
Hi,
I'm the maintainer of the fbtft project.
Even though I didn't know about this submission beforehand, I'm all for
having this in staging.
I didn't know about the staging tree, that drivers not meeting the strict
Linux coding practices still could be included.
Signed-off-by: Noralf Tronnes <notro@xxxxxxxxxxx>
Previously this project was almost only used by the Raspberry Pi community,
and some use on Beagle Bone Black, but in the last 6 months it has seen use
on
many more platforms (which I have lost count of). Not just ARM, but also
Intel Edison and Galileo.
In the same timeperiod there has been an explosion in display shields/capes
for the Raspberry Pi using these drivers.
I have also started to see fbtft being pulled into board specific kernel
trees.
Two months ago I started rewriting this project from scratch to make it a
better fit for inclusion. Fbtft was the first kernel programming I did, so I
have picked up a better understanding of the kernel since then.
I have also a much better understanding of the differences and similarities
between these LCD controllers, yielding better and cleaner abstractions.
It will take some time to get it ready for review, and even more time to get
the same controller/display coverage. I'm hoping to have something ready
for review during this year, but since it's a for fun freetime project, it's
hard
to predict when it's ready.
Status: https://github.com/notro/fbdbi/wiki
That implies that you are trying to come up with something to obsolete
what we have here, right? Or am I incorrect?
thanks,
greg k-h
Yes, you're right, I'm working on a successor that in time will obsolete
this.
But as I point out, it will take a while to complete the "framework" and
surely longer to support all the controllers.
Rewrites usually don't work, why not iterate this current codebase into
something clean and acceptable that we can merge properly? Adding this
codebase now, which you feel isn't going to go anywhere isn't a good
idea for me to do, I don't want "stale" code in the tree.
Also, iteration, while taking longer, ends up with a better end-solution
as everyone participates and provides help. Doing it all on your own
isn't a good idea, and isn't how successful kernel code is developed.
When I started this rewrite I didn't anticipate fbtft entering the kernel,
and to me it was easier to just start from scratch. However I'd much
rather go with proven practices, so I will do as you suggest.
At least the lcd register abstraction I've worked on, should be more or
less a bolt-on to fbtft.
Noralf.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
