On Mon, Dec 05, 2016 at 05:21:24PM +0100, Daniel Vetter wrote: > On Mon, Dec 05, 2016 at 12:11:46PM +0100, Thierry Reding wrote: > > On Mon, Dec 05, 2016 at 09:16:27AM +0100, Daniel Vetter wrote: > > > On Mon, Dec 05, 2016 at 08:57:43AM +0100, Thierry Reding wrote: > > > > On Sat, Dec 03, 2016 at 04:35:24AM +0000, Sharma, Shashank wrote: > > > > > Hi Thierry, > > > > > > > > > > If you can please have a look on this patch, I had written one to > > > > > parse HF-VSDB, which was covering SCDC detection too. > > > > > https://patchwork.kernel.org/patch/9452259/ > > > > > > > > I think there had been pushback before about caching capabilities from > > > > EDID, so from that point of view my patch is more inline with existing > > > > EDID parsing API. > > > > > > Hm, where was that pushback? We do have a bit a mess between explicitly > > > parsing stuff (e.g. eld) and stuffing parsed data into drm_display_info. > > > > You did object to a very similar patch some time ago that did a similar > > thing for DPCD stuff. And also Villa had commented on an earlier patch > > from Jose about concerns of bloating core structures: > > > > https://patchwork.freedesktop.org/patch/104806/ > > DPCD I complained about because somehow we ended up with 2 sets of > helpers, one filling a struct and the others returning directly. I > objected to the fact that there's 2 (and imo your patch duplicated even > more), not that I think one approach is clearly inferior to the other.
My recollection is that I had proposed that I do the work of transitioning users of the parsers to the cached information but you had said that it wasn't worth the churn and that we should just go with the existing scheme of passing around the DPCD buffer and extending the parsers as necessary.
