From: Ayan Halder <ayan.halder@arm.com>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: airlied@linux.ie, liviu.dudau@arm.com,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
daniel.vetter@intel.com, nd@arm.com
Subject: Re: [PATCH] drm: add drm_format_alpha_bits
Date: Fri, 12 Jan 2018 16:18:47 +0000 [thread overview]
Message-ID: <20180112161847.GB18191@arm.com> (raw)
In-Reply-To: <20180112155116.bqpyreloi6dkmqv3@flea.lan>
On Fri, Jan 12, 2018 at 04:51:16PM +0100, Maxime Ripard wrote:
> Hi,
>
> On Fri, Jan 12, 2018 at 03:43:49PM +0000, Ayan Halder wrote:
> > On Fri, Jan 12, 2018 at 04:28:34PM +0200, Ville Syrj?l? wrote:
> > > On Fri, Jan 12, 2018 at 02:21:16PM +0000, Ayan Halder wrote:
> > > > drm_format_info does not describe the number of bits used for the alpha
> > > > channel. That information is useful in a central place like drm_fourcc.c
> > > > where it can be queried by the drivers that want to determine if 'alpha
> > > > blending' is to be enabled or not.
> > > >
> > > > Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com>
> > > > Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
> > > > ---
> > > > drivers/gpu/drm/drm_fourcc.c | 154 ++++++++++++++++++++++++-------------------
> > > > include/drm/drm_fourcc.h | 3 +
> > > > 2 files changed, 89 insertions(+), 68 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > > > index 9c0152d..073001b 100644
> > > > --- a/drivers/gpu/drm/drm_fourcc.c
> > > > +++ b/drivers/gpu/drm/drm_fourcc.c
> > > <snip>
> > > > @@ -348,3 +348,21 @@ int drm_format_plane_height(int height, uint32_t format, int plane)
> > > > return height / info->vsub;
> > > > }
> > > > EXPORT_SYMBOL(drm_format_plane_height);
> > > > +
> > > > +/**
> > > > + * drm_format_alpha_bits - get the number of bits per pixel
> > > > + * representing alpha for format
> > > > + * @format: pixel format (DRM_FORMAT_*)
> > > > + *
> > > > + * Returns:
> > > > + * The number of bits per pixel representing alpha used by the
> > > > + * specified pixel format.
> > > > + */
> > > > +int drm_format_alpha_bits(uint32_t format)
> > > > +{
> > > > + const struct drm_format_info *info;
> > > > +
> > > > + info = drm_format_info(format);
> > > > + return info ? info->alpha : 0;
> > > > +}
> > > > +EXPORT_SYMBOL(drm_format_alpha_bits);
> > >
> > > Do you have an actual use for this function somewhere?
> >
> > Currently, we do not have a usage for this function. We need 'alpha'
> > field for each entry in 'drm_format_info' so as to determine whether
> > to enable/disable alpha blending in Mali display processor for the
> > particular color format.
>
> Do you need only the info that a particular channel has an alpha
> component, or do you also need the number of bits?
Currently, only the info whether alpha component is present in a
particular channel. I saw your patch and thought that instead of
returning true/false, it might be useful to capture the number of
alpha bits for each format.
> In the former case, then my serie sent earlier this week would help I
> guess.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Ayan Halder <ayan.halder@arm.com>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Ville Syrj?l? <ville.syrjala@linux.intel.com>,
nd@arm.com, airlied@linux.ie, liviu.dudau@arm.com,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
daniel.vetter@intel.com
Subject: Re: [PATCH] drm: add drm_format_alpha_bits
Date: Fri, 12 Jan 2018 16:18:47 +0000 [thread overview]
Message-ID: <20180112161847.GB18191@arm.com> (raw)
In-Reply-To: <20180112155116.bqpyreloi6dkmqv3@flea.lan>
On Fri, Jan 12, 2018 at 04:51:16PM +0100, Maxime Ripard wrote:
> Hi,
>
> On Fri, Jan 12, 2018 at 03:43:49PM +0000, Ayan Halder wrote:
> > On Fri, Jan 12, 2018 at 04:28:34PM +0200, Ville Syrj?l? wrote:
> > > On Fri, Jan 12, 2018 at 02:21:16PM +0000, Ayan Halder wrote:
> > > > drm_format_info does not describe the number of bits used for the alpha
> > > > channel. That information is useful in a central place like drm_fourcc.c
> > > > where it can be queried by the drivers that want to determine if 'alpha
> > > > blending' is to be enabled or not.
> > > >
> > > > Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com>
> > > > Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
> > > > ---
> > > > drivers/gpu/drm/drm_fourcc.c | 154 ++++++++++++++++++++++++-------------------
> > > > include/drm/drm_fourcc.h | 3 +
> > > > 2 files changed, 89 insertions(+), 68 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > > > index 9c0152d..073001b 100644
> > > > --- a/drivers/gpu/drm/drm_fourcc.c
> > > > +++ b/drivers/gpu/drm/drm_fourcc.c
> > > <snip>
> > > > @@ -348,3 +348,21 @@ int drm_format_plane_height(int height, uint32_t format, int plane)
> > > > return height / info->vsub;
> > > > }
> > > > EXPORT_SYMBOL(drm_format_plane_height);
> > > > +
> > > > +/**
> > > > + * drm_format_alpha_bits - get the number of bits per pixel
> > > > + * representing alpha for format
> > > > + * @format: pixel format (DRM_FORMAT_*)
> > > > + *
> > > > + * Returns:
> > > > + * The number of bits per pixel representing alpha used by the
> > > > + * specified pixel format.
> > > > + */
> > > > +int drm_format_alpha_bits(uint32_t format)
> > > > +{
> > > > + const struct drm_format_info *info;
> > > > +
> > > > + info = drm_format_info(format);
> > > > + return info ? info->alpha : 0;
> > > > +}
> > > > +EXPORT_SYMBOL(drm_format_alpha_bits);
> > >
> > > Do you have an actual use for this function somewhere?
> >
> > Currently, we do not have a usage for this function. We need 'alpha'
> > field for each entry in 'drm_format_info' so as to determine whether
> > to enable/disable alpha blending in Mali display processor for the
> > particular color format.
>
> Do you need only the info that a particular channel has an alpha
> component, or do you also need the number of bits?
Currently, only the info whether alpha component is present in a
particular channel. I saw your patch and thought that instead of
returning true/false, it might be useful to capture the number of
alpha bits for each format.
> In the former case, then my serie sent earlier this week would help I
> guess.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
next prev parent reply other threads:[~2018-01-12 16:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-12 14:21 [PATCH] drm: add drm_format_alpha_bits Ayan Halder
2018-01-12 14:21 ` Ayan Halder
2018-01-12 14:28 ` Ville Syrjälä
2018-01-12 14:28 ` Ville Syrjälä
2018-01-12 15:43 ` Ayan Halder
2018-01-12 15:51 ` Maxime Ripard
2018-01-12 16:18 ` Ayan Halder [this message]
2018-01-12 16:18 ` Ayan Halder
2018-01-12 15:53 ` Ville Syrjälä
2018-01-12 16:11 ` Ayan Halder
2018-01-12 16:25 ` Ville Syrjälä
2018-01-12 16:25 ` Ville Syrjälä
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180112161847.GB18191@arm.com \
--to=ayan.halder@arm.com \
--cc=airlied@linux.ie \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=maxime.ripard@free-electrons.com \
--cc=nd@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.