Re: [PATCH v3 01/22] drm: Add GEM backed framebuffer library

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

 



Hi Noralf,

On Wednesday 16 Aug 2017 23:24:50 Noralf Trønnes wrote:
> Den 16.08.2017 23.08, skrev Laurent Pinchart:
> > On Wednesday 16 Aug 2017 23:03:36 Noralf Trønnes wrote:
> >> Den 16.08.2017 22.39, skrev Laurent Pinchart:
> >>> On Wednesday 16 Aug 2017 21:52:02 Noralf Trønnes wrote:
> >>>> Den 16.08.2017 19.24, skrev Eric Anholt:
> >>>>> Noralf Trønnes <noralf@xxxxxxxxxxx> writes:
> >>>>>> This library provides helpers for drivers that don't subclass
> >>>>>> drm_framebuffer and are backed by drm_gem_object. The code is
> >>>>>> taken from drm_fb_cma_helper.
> >>>>>> 
> >>>>>> Signed-off-by: Noralf Trønnes <noralf@xxxxxxxxxxx>
> >>>>>> Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
> >>>>>> ---
> >>>>>> +/**
> >>>>>> + * drm_gem_fb_destroy - Free GEM backed framebuffer
> >>>>>> + * @fb: DRM framebuffer
> >>>>>> + *
> >>>>>> + * Frees a GEM backed framebuffer with it's backing buffer(s) and
> >>>>>> the structure
> >>>>> 
> >>>>> grammar nit: "its"
> >>>>> 
> >>>>> Other than that,
> >>>>> 
> >>>>> Reviewed-by: Eric Anholt <eric@xxxxxxxxxx>
> >>>> 
> >>>> Thanks, applied to drm-misc.
> >>> 
> >>> The patches were posted on Sunday. If you don't give at least a week to
> >>> reviewers, I don't think they will keep bothering. I certainly won't.
> >> 
> >> Hi Laurent,
> >> 
> >> I actually didn't think there was much interest in this patchset since
> >> the first version of the patcheset was sent 31/7. Daniel gave me his rb
> >> if I fixed the docs a week ago. Instead of applying it directly I sent
> >> a new version to give Eric a chance to look at it since he showed
> >> interest in an rfc. So when I got his rb, I just applied.
> >> 
> >> All that being said, I do appreciate reviews since that improves the
> >> work. I will adapt to waiting a week if that's what's expected.
> > 
> > There are always exceptions, or at least borderline cases, but I think
> > that one week is a reasonable delay in the general case. If you're at v8
> > and your series has been acked by 10 people already it can be a different
> > story. Or if you're fixing a security issue that has to get in a late -rc
> > before the final kernel is released. Or lots of other cases probably.
> > 
> >> Sorry about the let down.
> > 
> > It's OK, I know it wasn't on purpose :-) Your reply is definitely
> > appreciated.
> > 
> > Could you post a follow-up patch to fix the few issues I mentioned (at
> > least the ones you agree with of course) ?
> 
> Yes, I'll do that.
> 
> I suck at writing documentation, so when I need documentation for say
> an argument, I copy it from another function with the same argument.
> Not always pretty obviously, so I rely on help from reviewers to ensure
> proper english. Daniel has helped me many times to flesh out the docs.

I know the feeling, it takes me at least 10 times longer to write 
documentation than to write code :-/ I try to comfort myself by thinking that 
I'm quick at writing code, not slow at writing documentation, but that doesn't 
always work :-)

I have found, however, than when you start writing a large block of 
documentation, after some time it speeds up. When your brain switches to 
documentation mode words come out faster. You could try filling up kerneldoc 
comments in one go at the end of the development (or, even better, at the 
start) and see how that works out for you.

-- 
Regards,

Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux