[PATCH 00/29] staging: add drivers from the fbtft project

Greg KH greg at kroah.com
Sun Jan 18 01:42:49 UTC 2015


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 at tronnes.org>
> >>
> >>
> >>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.

thanks,

greg k-h


More information about the devel mailing list