[PATCH 0/6] drm/tinydrm: Move mipi_dbi
Daniel Vetter
daniel at ffwll.ch
Wed Jul 24 11:41:14 UTC 2019
On Tue, Jul 23, 2019 at 03:41:11PM +0200, Noralf Trønnes wrote:
> Den 23.07.2019 09.10, skrev Daniel Vetter:
> > On Mon, Jul 22, 2019 at 11:06:15AM -0700, Eric Anholt wrote:
> >> Noralf Trønnes <noralf at tronnes.org> writes:
> >>
> >>> This series ticks off the last tinydrm todo entry and moves out mipi_dbi
> >>> to be a core helper.
> >>>
> >>> It splits struct mipi_dbi into an interface part and a display pipeline
> >>> part (upload framebuffer over SPI). I also took the opportunity to
> >>> rename the ambiguous 'mipi' variable name to 'dbi'. This lines up with
> >>> the use of the 'dsi' variable name in the MIPI DSI helper.
> >>>
> >>> Note:
> >>> This depends on series: drm/tinydrm: Remove tinydrm.ko
> >>>
> >>> Series is also available here:
> >>> https://github.com/notro/linux/tree/move_mipi_dbi
> >>
> >> Congratulations on making it to this stage. This looks like a fine
> >> conclusion to tinydrm.
> >>
> >> Acked-by: Eric Anholt <eric at anholt.net>
> >
> > Yeah let me heap on the congrats too, this has ben a long but really
> > impressive journey to watch!
>
> Looking back it's suprising to me that I continued to work on this.
> After Linus took a dump on tinydrm I wasn't much interested in doing any
> further work on Linux, there are lots of other interesting projects to
> work on. Then you cc'ed me on a patch telling me that someone was using
> the simple display helper I made, and before I knew it I was knee deep
> in refactoring work.
Historical aside: That dump from Linus was one of the reasons we finally
decided to enact a code of conduct and enforce it against everyone. We
just can't afford to lose great people just because some big guns have a
hard time controlling their temper. Aside from it's just nicer to work
together with some respect.
> One big take away for me has been how much better my code becomes after
> going through a review process. Some times, looking back, I wonder - did
> I actually write that nice piece of code? And the real answer I guess is
> that I did the typing and often had the idea, but many times the fleshed
> out solution was not something that I came up with.
For me great review (both for as reviewer and as author) is when everyone
learns something. Personally I definitely learned a lot from all the small
driver work that's been going on the past few years - completely different
world compared to drivers mearsured in 100kloc units :-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list