From: Thierry Reding <thierry.reding@gmail.com>
To: "Noralf Trønnes" <noralf@tronnes.org>,
thomas.petazzoni@free-electrons.com, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 2/7] drm/tinydrm: Add helper functions
Date: Mon, 6 Feb 2017 10:35:56 +0100 [thread overview]
Message-ID: <20170206093556.GF27607@ulmo.ba.sec> (raw)
In-Reply-To: <20170206090918.6rqr6l7pd62znl5j@phenom.ffwll.local>
[-- Attachment #1: Type: text/plain, Size: 5663 bytes --]
On Mon, Feb 06, 2017 at 10:09:18AM +0100, Daniel Vetter wrote:
> On Mon, Feb 06, 2017 at 09:56:29AM +0100, Thierry Reding wrote:
> > On Tue, Jan 31, 2017 at 05:03:14PM +0100, Noralf Trønnes wrote:
[...]
> > > +/**
> > > + * tinydrm_merge_clips - Merge clip rectangles
> > > + * @dst: Destination clip rectangle
> > > + * @src: Source clip rectangle(s)
> > > + * @num_clips: Number of @src clip rectangles
> > > + * @flags: Dirty fb ioctl flags
> > > + * @max_width: Maximum width of @dst
> > > + * @max_height: Maximum height of @dst
> > > + *
> > > + * This function merges @src clip rectangle(s) into @dst. If @src is NULL,
> > > + * @max_width and @min_width is used to set a full @dst clip rectangle.
> > > + *
> > > + * Returns:
> > > + * true if it's a full clip, false otherwise
> > > + */
> > > +bool tinydrm_merge_clips(struct drm_clip_rect *dst,
> > > + struct drm_clip_rect *src, unsigned int num_clips,
> > > + unsigned int flags, u32 max_width, u32 max_height)
> > > +{
> > > + unsigned int i;
> > > +
> > > + if (!src || !num_clips) {
> > > + dst->x1 = 0;
> > > + dst->x2 = max_width;
> > > + dst->y1 = 0;
> > > + dst->y2 = max_height;
> > > + return true;
> > > + }
> > > +
> > > + dst->x1 = ~0;
> > > + dst->y1 = ~0;
> > > + dst->x2 = 0;
> > > + dst->y2 = 0;
> > > +
> > > + for (i = 0; i < num_clips; i++) {
> > > + if (flags & DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
> > > + i++;
> > > + dst->x1 = min(dst->x1, src[i].x1);
> > > + dst->x2 = max(dst->x2, src[i].x2);
> > > + dst->y1 = min(dst->y1, src[i].y1);
> > > + dst->y2 = max(dst->y2, src[i].y2);
> > > + }
> > > +
> > > + if (dst->x2 > max_width || dst->y2 > max_height ||
> > > + dst->x1 >= dst->x2 || dst->y1 >= dst->y2) {
> > > + DRM_DEBUG_KMS("Illegal clip: x1=%u, x2=%u, y1=%u, y2=%u\n",
> > > + dst->x1, dst->x2, dst->y1, dst->y2);
> > > + dst->x1 = 0;
> > > + dst->y1 = 0;
> > > + dst->x2 = max_width;
> > > + dst->y2 = max_height;
> > > + }
> > > +
> > > + return (dst->x2 - dst->x1) == max_width &&
> > > + (dst->y2 - dst->y1) == max_height;
> > > +}
> > > +EXPORT_SYMBOL(tinydrm_merge_clips);
> >
> > Should this perhaps be part of drm_rect.c?
>
> drm_rect is about struct drm_rect, this here is struct drm_clip_rect. I
> think fixing this up is a lot bigger patch series, and we've postponed it
> already with the dirtyfb trakcing patches for the fbdev helpers. I think
> postponing once more is ok.
Okay, that's fine with me.
> > > +#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
> > > +/**
> > > + * tinydrm_of_find_backlight - Find backlight device in device-tree
> > > + * @dev: Device
> > > + *
> > > + * This function looks for a DT node pointed to by a property named 'backlight'
> > > + * and uses of_find_backlight_by_node() to get the backlight device.
> > > + * Additionally if the brightness property is zero, it is set to
> > > + * max_brightness.
> > > + *
> > > + * Returns:
> > > + * NULL if there's no backlight property.
> > > + * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
> > > + * is found.
> > > + * If the backlight device is found, a pointer to the structure is returned.
> > > + */
> > > +struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
> > > +{
[...]
> > > +}
> > > +EXPORT_SYMBOL(tinydrm_of_find_backlight);
> > > +
> > > +/**
> > > + * tinydrm_enable_backlight - Enable backlight helper
> > > + * @backlight: Backlight device
> > > + *
> > > + * Returns:
> > > + * Zero on success, negative error code on failure.
> > > + */
> > > +int tinydrm_enable_backlight(struct backlight_device *backlight)
> > > +{
[...]
> > > +}
> > > +EXPORT_SYMBOL(tinydrm_enable_backlight);
> > > +
> > > +/**
> > > + * tinydrm_disable_backlight - Disable backlight helper
> > > + * @backlight: Backlight device
> > > + *
> > > + * Returns:
> > > + * Zero on success, negative error code on failure.
> > > + */
> > > +int tinydrm_disable_backlight(struct backlight_device *backlight)
> > > +{
[...]
> > > +}
> > > +EXPORT_SYMBOL(tinydrm_disable_backlight);
> > > +#endif
> >
> > These look like they really should be part of the backlight subsystem. I
> > don't see anything DRM specific about them. Well, except for the error
> > messages.
>
> So this is a bit an unpopular opinion with some folks, but I don't require
> anyone to submit new code to subsystems outside of drm for new drivers.
> Simply because it takes months to get stuff landed, and in general it's
> not worth the trouble.
"Not worth the trouble" is very subjective. If you look at the Linux
kernel in general, one of the reasons why it works so well is because
the changes we make apply to the kernel as a whole. Yes, sometimes that
makes things more difficult and time-consuming, but it also means that
the end result will be much more widely usable and therefore benefits
everyone else in return. In my opinion that's a large part of why the
kernel is so successful.
> We have piles of stuff in drm and drm drivers that should be in core but
> isn't.
>
> Imo the only reasonable way is to merge as-is, then follow-up with a patch
> series to move the helper into the right subsystem. Most often
> unfortunately that follow-up patch series will just die.
Of course follow-up series die. That's because nobody cares to follow-up
once their code has been merged.
Collecting our own helpers or variants of subsystems is a great way of
isolating ourselves from the rest of the community. I don't think that's
a good solution in the long run at all.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-02-06 9:36 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-31 16:03 [PATCH v3 0/7] drm: Add support for tiny LCD displays Noralf Trønnes
2017-01-31 16:03 ` [PATCH v3 1/7] drm: Add DRM " Noralf Trønnes
2017-01-31 16:23 ` Daniel Vetter
2017-01-31 18:01 ` Noralf Trønnes
2017-01-31 20:10 ` Daniel Vetter
2017-02-06 9:17 ` Thierry Reding
2017-02-06 19:23 ` Noralf Trønnes
2017-02-07 6:58 ` Daniel Vetter
2017-02-07 11:48 ` Thierry Reding
2017-02-06 10:12 ` Jani Nikula
2017-01-31 16:03 ` [PATCH v3 2/7] drm/tinydrm: Add helper functions Noralf Trønnes
2017-02-06 8:56 ` Thierry Reding
2017-02-06 9:09 ` Daniel Vetter
2017-02-06 9:35 ` Thierry Reding [this message]
[not found] ` <CAKMK7uHgW15EPpPSU2se7r89JCGD_oTvn9ZJptYaNJAWMKb9Fg@mail.gmail.com>
2017-02-06 11:08 ` Thierry Reding
2017-02-06 15:53 ` Daniel Vetter
2017-02-06 22:11 ` Noralf Trønnes
2017-02-07 11:38 ` Thierry Reding
2017-02-06 22:28 ` Dave Airlie
2017-02-07 7:00 ` Daniel Vetter
2017-02-07 11:11 ` Thierry Reding
2017-02-07 11:21 ` Daniel Vetter
2017-02-07 11:44 ` Thierry Reding
2017-02-07 13:23 ` Daniel Vetter
2017-02-06 22:55 ` Rob Herring
2017-02-07 7:08 ` Daniel Vetter
2017-02-06 10:10 ` Jani Nikula
2017-01-31 16:03 ` [PATCH v3 3/7] drm/tinydrm: Add MIPI DBI support Noralf Trønnes
2017-02-06 8:48 ` Thierry Reding
2017-02-06 11:30 ` Jani Nikula
2017-02-06 11:53 ` Thierry Reding
2017-02-06 12:34 ` Andrzej Hajda
2017-02-06 15:45 ` Noralf Trønnes
2017-02-06 11:25 ` Jani Nikula
2017-01-31 16:03 ` [PATCH v3 4/7] of: Add vendor prefix for Multi-Inno Noralf Trønnes
2017-01-31 16:03 ` [PATCH v3 5/7] dt-bindings: display: Add common rotation property Noralf Trønnes
2017-02-01 17:41 ` Rob Herring
2017-02-03 12:16 ` Noralf Trønnes
2017-02-06 7:10 ` Thierry Reding
2017-01-31 16:03 ` [PATCH v3 6/7] dt-bindings: Add Multi-Inno MI0283QT binding Noralf Trønnes
2017-02-01 17:42 ` Rob Herring
2017-01-31 16:03 ` [PATCH v3 7/7] drm/tinydrm: Add support for Multi-Inno MI0283QT display Noralf Trønnes
2017-02-06 8:25 ` Thierry Reding
2017-02-07 12:00 ` [PATCH v3 0/7] drm: Add support for tiny LCD displays Thierry Reding
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=20170206093556.GF27607@ulmo.ba.sec \
--to=thierry.reding@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=noralf@tronnes.org \
--cc=thomas.petazzoni@free-electrons.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox