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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux