Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <cover.92acdec88ee4c280cb74e08ea22f0075e5fa055c.1553032382.git-series.maxime.ripard@bootlin.com>
 <fecde1c7b65caa0e876a2f01769289a883014712.1553032382.git-series.maxime.ripard@bootlin.com>
 <CACvgo51WMD5hsyLB5QTriGNwcPmeN4TDjscJV11M3PXFncPHeQ@mail.gmail.com> <20190402145114.bpt5atxxooufgzz5@flea>
In-Reply-To: <20190402145114.bpt5atxxooufgzz5@flea>
From:   Emil Velikov <emil.l.velikov@gmail.com>
Date:   Thu, 4 Apr 2019 17:24:03 +0100
Message-ID: <CACvgo53mNnH88nB2XkzBLQyXD8osGwBGL7ba=QXTx-T+Bp_iKA@mail.gmail.com>
Subject: Re: [RFC PATCH 01/20] drm: Remove users of drm_format_num_planes
To:     Maxime Ripard <maxime.ripard@bootlin.com>
Cc:     Daniel Vetter <daniel.vetter@intel.com>,
        David Airlie <airlied@linux.ie>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Sean Paul <seanpaul@chromium.org>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        Sakari Ailus <sakari.ailus@linux.intel.com>,
        "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
        ML dri-devel <dri-devel@lists.freedesktop.org>,
        Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
        Hans Verkuil <hans.verkuil@cisco.com>,
        Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
        linux-media@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 2 Apr 2019 at 15:51, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Hi Emil,
>
> On Tue, Apr 02, 2019 at 10:43:31AM +0100, Emil Velikov wrote:
> > On Tue, 19 Mar 2019 at 21:57, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > drm_format_num_planes() is basically a lookup in the drm_format_info table
> > > plus an access to the num_planes field of the appropriate entry.
> > >
> > > Most drivers are using this function while having access to the entry
> > > already, which means that we will perform an unnecessary lookup. Removing
> > > the call to drm_format_num_planes is therefore more efficient.
> > >
> > > Some drivers will not have access to that entry in the function, but in
> > > this case the overhead is minimal (we just have to call drm_format_info()
> > > to perform the lookup) and we can even avoid multiple, inefficient lookups
> > > in some places that need multiple fields from the drm_format_info
> > > structure.
> > >
> >
> > I'm not fan of the duplicated loop-ups either.
> >
> > > -int drm_format_num_planes(uint32_t format)
> > > -{
> > > -       const struct drm_format_info *info;
> > > -
> > > -       info = drm_format_info(format);
> > > -       return info ? info->num_planes : 1;
> > > -}
> > > -EXPORT_SYMBOL(drm_format_num_planes);
> > > -
> >
> > The existing users are not updated to cater for the num_planes != 0
> > case... Which seems non-existent scenario since all the current format
> > descriptions have 1+ planes.
> > Should we add a test (alike the ones in 6/20) to ensure, that no entry
> > has 0 planes? Is it even worth it or I'm a bit too paranoid?
> >
> > The above comments apply to 2/20.
>
> I'm not entirely sure what you mean. num_planes is returned as is in
> the drm_format_num_planes function and it doesn't check for the
> num_planes value itself.
>
> That being said, we could definitely add some more tests to check that
> we haven't falling into the situation you describe, since most of the
> drivers indeed don't check for that value themselves. But that seems
> pretty othorgonal to me?
>
Hmm I misread the old function as "return info->num_planes ?
info->num_planes : 1;"

Pardon for the noise.
-Emil