[Freedreno] [DPU PATCH 1/2] dt-bindings: msm/disp: Remove hw block offset DT entries for SDM845

[Sean Paul]

On Thu, Mar 29, 2018 at 10:04:33AM -0500, Rob Herring wrote:
> On Mon, Mar 19, 2018 at 1:19 AM,  <skolluku at codeaurora.org> wrote:
> > On 2018-03-18 18:19, Rob Herring wrote:
> >>
> >> On Wed, Mar 14, 2018 at 11:21:37AM +0530, Sravanthi Kollukuduru wrote:
> >>>
> >>> Remove DT entries of hw block offsets and other target specific catalog
> >>> information for SDM845.
> >>
> >>
> >> That is clear from the diff. The commit msg should answer why?
> >>
> > Will update the commit msg as below in the follow up patch :
> > "Currently, the downstream driver depends on the DT file for the hw offsets
> > and other target specific catalog information.
> > To align the driver with the upstream DT design, this information is now
> > removed from DT file and added in the driver source."
> 
> Based on the answer below, write whatever you want because until it is
> intended for upstream it doesn't matter (to me at least). Though,
> writing good commit messages should perhaps be practiced.
> 
> >>>
> >>> Signed-off-by: Sravanthi Kollukuduru <skolluku at codeaurora.org>
> >>> ---
> >>>  .../devicetree/bindings/display/msm/dpu.txt        | 530
> >>> ---------------------
> >>
> >>
> >> This file is not upstream. What tree is this for?
> >>
> > This is part of the qualcomm efforts to upstream the display controller
> > code.
> > The changes are hosted at
> > https://cgit.freedesktop.org/~seanpaul/dpu-staging/
> 
> Please make that abundantly clear in every patch for this so it is
> obvious to ignore it. Or just keep it on the msm/freedreno lists until
> you are submitting things upstream. 

FWIW, all of these patches are prefixed with "DPU PATCH". While that doesn't
scream "ignore", it is at least a signal that it's not the same as everything
else on the list.

> If you have specific binding
> questions/issues before them, I'm happy to discuss, but otherwise
> folks have more than enough to review just for upstream.

The goal is to get this driver upstream, and these patches are working towards
that goal. It's really helpful to get your feedback, and in general I think we
should encourage vendors to send patches early in order to avoid situations
where they waste a bunch of time implementing/fixing the wrong things.

Sean

> 
> Rob
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS