On Tue, Jan 21, 2014 at 12:52:36PM +0100, David Herrmann wrote:
> Hi
>
> On Tue, Jan 21, 2014 at 12:42 PM, Ville Syrjälä
> <ville.syrjala@xxxxxxxxxxxxxxx> wrote:
> > On Tue, Jan 21, 2014 at 12:17:35PM +0100, David Herrmann wrote:
> >> Hi
> >>
> >> On Tue, Jan 21, 2014 at 10:49 AM, Daniel Vetter <daniel@xxxxxxxx> wrote:
> >> > On Mon, Jan 20, 2014 at 08:26:28PM +0100, David Herrmann wrote:
> >> >> Lets make sure some basic expressions are always true:
> >> >> bpp != NULL
> >> >> width != NULL
> >> >> height != NULL
> >> >> stride = bpp * width < 2^32
> >> >> size = stride * height < 2^32
> >> >> PAGE_ALIGN(size) < 2^32
> >> >>
> >> >> At least the udl driver doesn't check for multiplication-overflows, so
> >> >> lets just make sure it will never happen. These checks allow drivers to do
> >> >> any 32bit math without having to test for mult-overflows themselves.
> >> >>
> >> >> The two divisions might hurt performance a bit, but dumb_create() is only
> >> >> used for scanout-buffers, so that should be fine. We could use 64bit math
> >> >> to avoid the divisions, but that may be slow on 32bit machines.. Or maybe
> >> >> there should just be a "safe_mult32()" helper, which currently doesn't
> >> >> exist (I think?).
> >> >>
> >> >> Signed-off-by: David Herrmann <dh.herrmann@xxxxxxxxx>
> >> >> ---
> >> >> drivers/gpu/drm/drm_crtc.c | 15 +++++++++++++++
> >> >> 1 file changed, 15 insertions(+)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >> >> index 266a01d..ff647fa 100644
> >> >> --- a/drivers/gpu/drm/drm_crtc.c
> >> >> +++ b/drivers/gpu/drm/drm_crtc.c
> >> >> @@ -3738,9 +3738,24 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
> >> >> void *data, struct drm_file *file_priv)
> >> >> {
> >> >> struct drm_mode_create_dumb *args = data;
> >> >> + u32 Bpp, stride, size;
> >> >
> >> > s/Bpp/bpp/
> >>
> >> It's actually "Bytes per pixel", not "Bits per pixel". We generally
> >> use "bpp" as "bits per pixel" so I'd like to avoid the confusion. But
> >> yeah, upper-case names are unusual so I can also use bytes_pp or sth
> >> similar?
> >
> > cpp is fairly commonly used for bytes per pixel, if you want to stick to
> > something short but still recognizable.
>
> Because "c" comes after "b"? Or is there any other logic here? But
> sounds good, will send a v2 shortly.
chars (octets) per pixel.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
