All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Neil Armstrong <narmstrong@baylibre.com>
Cc: airlied@linux.ie, khilman@baylibre.com, carlo@caione.org,
	Xing.Xu@amlogic.com, victor.wan@amlogic.com,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	jerry.cao@amlogic.com, linux-amlogic@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 1/3] drm: Add support for Amlogic Meson Graphic Controller
Date: Tue, 29 Nov 2016 09:50:24 +0100	[thread overview]
Message-ID: <20161129085024.tqf5takulvv7f34x@phenom.ffwll.local> (raw)
In-Reply-To: <99e71b1b-b0cc-ec54-6ca9-417d20195aca@baylibre.com>

Hi Neil,

On Mon, Nov 28, 2016 at 10:34:58AM +0100, Neil Armstrong wrote:
> On 11/28/2016 09:16 AM, Daniel Vetter wrote:
> > On Fri, Nov 25, 2016 at 05:03:09PM +0100, Neil Armstrong wrote:
> >> +static void meson_cvbs_encoder_disable(struct drm_encoder *encoder)
> >> +{
> >> +	struct meson_cvbs *meson_cvbs = encoder_to_meson_cvbs(encoder);
> >> +
> >> +	meson_venci_cvbs_disable(meson_cvbs->priv);
> >> +}
> >> +
> >> +static void meson_cvbs_encoder_enable(struct drm_encoder *encoder)
> >> +{
> >> +	struct meson_cvbs *meson_cvbs = encoder_to_meson_cvbs(encoder);
> >> +
> >> +	meson_venci_cvbs_enable(meson_cvbs->priv);
> >> +}
> > 
> > Personally I'd remove the indirection above, more direct code is easier to
> > read.
> 
> I understand, I'll maybe change the meson_venci_cvbs_XXable to be
> directly added to the ops.
> 
> I want to keep the registers setup in separate files and keep a clean
> DRM/HW separation.

I figured this is worth clarifying, and I'm somewhat guessing at your
motivation here for a clean drm/hw split. There's of course various levels
of how much you can split the drm side from your hw backend, but in
general that design approach is really unpopular with upstream. It goes by
the name of "midlayer", and the trouble with it is that it makes
subsystem refactoring more complicated.

For the driver itself it's nice, because it isolates you a bit from drm
core. But that exact isolation is the problem when someone wants (or more
often, needs to) refactor something across the entire subsystem. Then all
these driver-private little (or sometimes much bigger) abstractions get in
the way. That's way I suggested to remove it (both here and in the plane
code), because for upstream the overall subsystem matters more than each
individual driver. GPUs change fast, we need to be able to adapt fast,
too.

Anyway you're driver's pretty small, so personally I don't mind much. I'd
still think removing the indirection would be better though.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: daniel@ffwll.ch (Daniel Vetter)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/3] drm: Add support for Amlogic Meson Graphic Controller
Date: Tue, 29 Nov 2016 09:50:24 +0100	[thread overview]
Message-ID: <20161129085024.tqf5takulvv7f34x@phenom.ffwll.local> (raw)
In-Reply-To: <99e71b1b-b0cc-ec54-6ca9-417d20195aca@baylibre.com>

Hi Neil,

On Mon, Nov 28, 2016 at 10:34:58AM +0100, Neil Armstrong wrote:
> On 11/28/2016 09:16 AM, Daniel Vetter wrote:
> > On Fri, Nov 25, 2016 at 05:03:09PM +0100, Neil Armstrong wrote:
> >> +static void meson_cvbs_encoder_disable(struct drm_encoder *encoder)
> >> +{
> >> +	struct meson_cvbs *meson_cvbs = encoder_to_meson_cvbs(encoder);
> >> +
> >> +	meson_venci_cvbs_disable(meson_cvbs->priv);
> >> +}
> >> +
> >> +static void meson_cvbs_encoder_enable(struct drm_encoder *encoder)
> >> +{
> >> +	struct meson_cvbs *meson_cvbs = encoder_to_meson_cvbs(encoder);
> >> +
> >> +	meson_venci_cvbs_enable(meson_cvbs->priv);
> >> +}
> > 
> > Personally I'd remove the indirection above, more direct code is easier to
> > read.
> 
> I understand, I'll maybe change the meson_venci_cvbs_XXable to be
> directly added to the ops.
> 
> I want to keep the registers setup in separate files and keep a clean
> DRM/HW separation.

I figured this is worth clarifying, and I'm somewhat guessing at your
motivation here for a clean drm/hw split. There's of course various levels
of how much you can split the drm side from your hw backend, but in
general that design approach is really unpopular with upstream. It goes by
the name of "midlayer", and the trouble with it is that it makes
subsystem refactoring more complicated.

For the driver itself it's nice, because it isolates you a bit from drm
core. But that exact isolation is the problem when someone wants (or more
often, needs to) refactor something across the entire subsystem. Then all
these driver-private little (or sometimes much bigger) abstractions get in
the way. That's way I suggested to remove it (both here and in the plane
code), because for upstream the overall subsystem matters more than each
individual driver. GPUs change fast, we need to be able to adapt fast,
too.

Anyway you're driver's pretty small, so personally I don't mind much. I'd
still think removing the indirection would be better though.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Neil Armstrong <narmstrong@baylibre.com>
Cc: Xing.Xu@amlogic.com, victor.wan@amlogic.com,
	khilman@baylibre.com, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	linux-amlogic@lists.infradead.org, carlo@caione.org,
	jerry.cao@amlogic.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 1/3] drm: Add support for Amlogic Meson Graphic Controller
Date: Tue, 29 Nov 2016 09:50:24 +0100	[thread overview]
Message-ID: <20161129085024.tqf5takulvv7f34x@phenom.ffwll.local> (raw)
In-Reply-To: <99e71b1b-b0cc-ec54-6ca9-417d20195aca@baylibre.com>

Hi Neil,

On Mon, Nov 28, 2016 at 10:34:58AM +0100, Neil Armstrong wrote:
> On 11/28/2016 09:16 AM, Daniel Vetter wrote:
> > On Fri, Nov 25, 2016 at 05:03:09PM +0100, Neil Armstrong wrote:
> >> +static void meson_cvbs_encoder_disable(struct drm_encoder *encoder)
> >> +{
> >> +	struct meson_cvbs *meson_cvbs = encoder_to_meson_cvbs(encoder);
> >> +
> >> +	meson_venci_cvbs_disable(meson_cvbs->priv);
> >> +}
> >> +
> >> +static void meson_cvbs_encoder_enable(struct drm_encoder *encoder)
> >> +{
> >> +	struct meson_cvbs *meson_cvbs = encoder_to_meson_cvbs(encoder);
> >> +
> >> +	meson_venci_cvbs_enable(meson_cvbs->priv);
> >> +}
> > 
> > Personally I'd remove the indirection above, more direct code is easier to
> > read.
> 
> I understand, I'll maybe change the meson_venci_cvbs_XXable to be
> directly added to the ops.
> 
> I want to keep the registers setup in separate files and keep a clean
> DRM/HW separation.

I figured this is worth clarifying, and I'm somewhat guessing at your
motivation here for a clean drm/hw split. There's of course various levels
of how much you can split the drm side from your hw backend, but in
general that design approach is really unpopular with upstream. It goes by
the name of "midlayer", and the trouble with it is that it makes
subsystem refactoring more complicated.

For the driver itself it's nice, because it isolates you a bit from drm
core. But that exact isolation is the problem when someone wants (or more
often, needs to) refactor something across the entire subsystem. Then all
these driver-private little (or sometimes much bigger) abstractions get in
the way. That's way I suggested to remove it (both here and in the plane
code), because for upstream the overall subsystem matters more than each
individual driver. GPUs change fast, we need to be able to adapt fast,
too.

Anyway you're driver's pretty small, so personally I don't mind much. I'd
still think removing the indirection would be better though.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
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: daniel@ffwll.ch (Daniel Vetter)
To: linus-amlogic@lists.infradead.org
Subject: [RFC PATCH 1/3] drm: Add support for Amlogic Meson Graphic Controller
Date: Tue, 29 Nov 2016 09:50:24 +0100	[thread overview]
Message-ID: <20161129085024.tqf5takulvv7f34x@phenom.ffwll.local> (raw)
In-Reply-To: <99e71b1b-b0cc-ec54-6ca9-417d20195aca@baylibre.com>

Hi Neil,

On Mon, Nov 28, 2016 at 10:34:58AM +0100, Neil Armstrong wrote:
> On 11/28/2016 09:16 AM, Daniel Vetter wrote:
> > On Fri, Nov 25, 2016 at 05:03:09PM +0100, Neil Armstrong wrote:
> >> +static void meson_cvbs_encoder_disable(struct drm_encoder *encoder)
> >> +{
> >> +	struct meson_cvbs *meson_cvbs = encoder_to_meson_cvbs(encoder);
> >> +
> >> +	meson_venci_cvbs_disable(meson_cvbs->priv);
> >> +}
> >> +
> >> +static void meson_cvbs_encoder_enable(struct drm_encoder *encoder)
> >> +{
> >> +	struct meson_cvbs *meson_cvbs = encoder_to_meson_cvbs(encoder);
> >> +
> >> +	meson_venci_cvbs_enable(meson_cvbs->priv);
> >> +}
> > 
> > Personally I'd remove the indirection above, more direct code is easier to
> > read.
> 
> I understand, I'll maybe change the meson_venci_cvbs_XXable to be
> directly added to the ops.
> 
> I want to keep the registers setup in separate files and keep a clean
> DRM/HW separation.

I figured this is worth clarifying, and I'm somewhat guessing at your
motivation here for a clean drm/hw split. There's of course various levels
of how much you can split the drm side from your hw backend, but in
general that design approach is really unpopular with upstream. It goes by
the name of "midlayer", and the trouble with it is that it makes
subsystem refactoring more complicated.

For the driver itself it's nice, because it isolates you a bit from drm
core. But that exact isolation is the problem when someone wants (or more
often, needs to) refactor something across the entire subsystem. Then all
these driver-private little (or sometimes much bigger) abstractions get in
the way. That's way I suggested to remove it (both here and in the plane
code), because for upstream the overall subsystem matters more than each
individual driver. GPUs change fast, we need to be able to adapt fast,
too.

Anyway you're driver's pretty small, so personally I don't mind much. I'd
still think removing the indirection would be better though.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2016-11-29  8:50 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-25 16:03 [RFC PATCH 0/3] drm: Add support for the Amlogic Video Processing Unit Neil Armstrong
2016-11-25 16:03 ` Neil Armstrong
2016-11-25 16:03 ` Neil Armstrong
2016-11-25 16:03 ` [RFC PATCH 1/3] drm: Add support for Amlogic Meson Graphic Controller Neil Armstrong
2016-11-25 16:03   ` Neil Armstrong
2016-11-28  8:16   ` Daniel Vetter
2016-11-28  8:16     ` Daniel Vetter
2016-11-28  8:16     ` Daniel Vetter
2016-11-28  9:34     ` Neil Armstrong
2016-11-28  9:34       ` Neil Armstrong
2016-11-28  9:34       ` Neil Armstrong
2016-11-29  8:50       ` Daniel Vetter [this message]
2016-11-29  8:50         ` Daniel Vetter
2016-11-29  8:50         ` Daniel Vetter
2016-11-29  8:50         ` Daniel Vetter
2016-11-29  9:05         ` Neil Armstrong
2016-11-29  9:05           ` Neil Armstrong
2016-11-29  9:05           ` Neil Armstrong
2016-11-25 16:03 ` [RFC PATCH 2/3] ARM64: dts: meson-gx: Add Graphic Controller nodes Neil Armstrong
2016-11-25 16:03   ` Neil Armstrong
2016-11-25 16:03   ` Neil Armstrong
2016-11-25 16:03 ` [RFC PATCH 3/3] dt-bindings: display: add Amlogic Meson DRM Bindings Neil Armstrong
2016-11-25 16:03   ` Neil Armstrong
2016-11-25 16:03   ` Neil Armstrong
2016-11-25 16:03   ` Neil Armstrong
2016-11-28  8:33   ` Laurent Pinchart
2016-11-28  8:33     ` Laurent Pinchart
2016-11-28  8:33     ` Laurent Pinchart
2016-11-28  8:33     ` Laurent Pinchart
2016-11-28  9:23     ` Neil Armstrong
2016-11-28  9:23       ` Neil Armstrong
2016-11-28  9:23       ` Neil Armstrong
2016-11-28  9:23       ` Neil Armstrong
2016-11-28  9:37       ` Laurent Pinchart
2016-11-28  9:37         ` Laurent Pinchart
2016-11-28  9:37         ` Laurent Pinchart
2016-11-28  9:37         ` Laurent Pinchart
2016-11-28  9:56         ` Neil Armstrong
2016-11-28  9:56           ` Neil Armstrong
2016-11-28  9:56           ` Neil Armstrong
2016-11-28  9:56           ` Neil Armstrong
2016-11-28 10:02           ` Laurent Pinchart
2016-11-28 10:02             ` Laurent Pinchart
2016-11-28 10:02             ` Laurent Pinchart
2016-11-28 10:02             ` Laurent Pinchart
2016-11-28 10:25             ` Neil Armstrong
2016-11-28 10:25               ` Neil Armstrong
2016-11-28 10:25               ` Neil Armstrong
2016-11-28 10:25               ` Neil Armstrong

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=20161129085024.tqf5takulvv7f34x@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=Xing.Xu@amlogic.com \
    --cc=airlied@linux.ie \
    --cc=carlo@caione.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jerry.cao@amlogic.com \
    --cc=khilman@baylibre.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=victor.wan@amlogic.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.