On Fri, Apr 26, 2019 at 2:42 AM Aaro Koskinen <aaro.koskinen@xxxxxx> wrote: > On Fri, Jan 18, 2019 at 12:20:28PM +0100, Daniel Vetter wrote: > > On Fri, Jan 18, 2019 at 11:08:28AM +0100, Greg Kroah-Hartman wrote: > > > There has not been any real work done on cleaning this driver up and > > > getting it out of the staging tree in years. Also, no new fb drivers > > > are being added to the tree, so it should be converted into a drm driver > > > as well. > > > > > > Due to the lack of interest in this codebase, just drop it. > > > > > > Cc: Arnaud Patard <arnaud.patard@xxxxxxxxxxx> > > > Cc: Mauro Carvalho Chehab <mchehab+samsung@xxxxxxxxxx> > > > Reported-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > > > Acked-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > Because of this I just lost fb/display on two of my computers... > > So I guess to reintroduce the support for this HW I need to write a new > DRM driver and no staging work anymore. Which of the current DRM drivers > would be best to be used as a template/example for a new driver? For a simple driver pick any of the recently merged ones using the drm_simple_display_pipe helpers, those will get rid of all the boilerplate for you. If you have vram, you might need the in-flight vram helpers that currently are worked on by Thomas Zimmermann (they refactor simple vram handling from about 5 drivers into a new helper, with the goal to make porting fbdev drivers even easier). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
