From: Rob Herring <robherring2@gmail.com>
To: Eric Anholt <eric@anholt.net>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Lee Jones <lee@kernel.org>,
linux-rpi-kernel@lists.infradead.org,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/7] drm/vc4: Add devicetree bindings for VC4.
Date: Mon, 24 Aug 2015 08:47:00 -0500 [thread overview]
Message-ID: <CAL_JsqJxiGUR5BxBPyR3-0NxqWsOxMGrWQA6cMXe2pjTom__nw@mail.gmail.com> (raw)
In-Reply-To: <874mjxwyx5.fsf@eliezer.anholt.net>
On Mon, Aug 17, 2015 at 1:30 PM, Eric Anholt <eric@anholt.net> wrote:
> Stephen Warren <swarren@wwwdotorg.org> writes:
>
>> On 08/12/2015 06:56 PM, Eric Anholt wrote:
>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>>
>> This one definitely needs a patch description, since someone might not
>> know what a VC4 is, and "git log" won't show the text from the binding
>> doc itself. I'd suggest adding the initial paragraph of the binding doc
>> as the patch description, or more.
>>
>>> diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
>
>>> +- hvss: List of references to HVS video scalers
>>> +- encoders: List of references to output encoders (HDMI, SDTV)
>>
>> Would it make sense to make all those nodes child node of the vc4
>> object. That way, there's no need to have these lists of objects; they
>> can be automatically built up as the DT is enumerated. I know that e.g.
>> the NVIDIA Tegra host1x binding works this way, and I think it may have
>> been inspired by other similar cases.
>
> I've looked at tegra, and the component system used by msm appears to be
> nicer than it. To follow tegra's model, it looks like I need to build
> this extra bus thing corresponding to host1x that is effectively the
> drivers/base/component.c code, so that I can get at vc4's structure from
> the component drivers.
>
>> Of course, this is only appropriate if the HW modules really are
>> logically children of the VC4 HW module. Perhaps they aren't. If they
>> aren't though, I wonder what this "vc4" module actually represents in HW?
>
> It's the subsystem, same as we use a subsystem node for msm, sti,
> rockchip, imx, and exynos. This appears to be the common model of how
> the collection of graphics-related components is represented in the DT.
I think most of these bindings are wrong. They are grouped together
because that is what DRM wants not because that reflects the h/w. So
convince me this is one block, not that it is what other people do.
Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
dri-devel
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Lee Jones <lee-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 1/7] drm/vc4: Add devicetree bindings for VC4.
Date: Mon, 24 Aug 2015 08:47:00 -0500 [thread overview]
Message-ID: <CAL_JsqJxiGUR5BxBPyR3-0NxqWsOxMGrWQA6cMXe2pjTom__nw@mail.gmail.com> (raw)
In-Reply-To: <874mjxwyx5.fsf-omZaPlIz5HhaEpDpdNBo/KxOck334EZe@public.gmane.org>
On Mon, Aug 17, 2015 at 1:30 PM, Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org> wrote:
> Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:
>
>> On 08/12/2015 06:56 PM, Eric Anholt wrote:
>>> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
>>
>> This one definitely needs a patch description, since someone might not
>> know what a VC4 is, and "git log" won't show the text from the binding
>> doc itself. I'd suggest adding the initial paragraph of the binding doc
>> as the patch description, or more.
>>
>>> diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
>
>>> +- hvss: List of references to HVS video scalers
>>> +- encoders: List of references to output encoders (HDMI, SDTV)
>>
>> Would it make sense to make all those nodes child node of the vc4
>> object. That way, there's no need to have these lists of objects; they
>> can be automatically built up as the DT is enumerated. I know that e.g.
>> the NVIDIA Tegra host1x binding works this way, and I think it may have
>> been inspired by other similar cases.
>
> I've looked at tegra, and the component system used by msm appears to be
> nicer than it. To follow tegra's model, it looks like I need to build
> this extra bus thing corresponding to host1x that is effectively the
> drivers/base/component.c code, so that I can get at vc4's structure from
> the component drivers.
>
>> Of course, this is only appropriate if the HW modules really are
>> logically children of the VC4 HW module. Perhaps they aren't. If they
>> aren't though, I wonder what this "vc4" module actually represents in HW?
>
> It's the subsystem, same as we use a subsystem node for msm, sti,
> rockchip, imx, and exynos. This appears to be the common model of how
> the collection of graphics-related components is represented in the DT.
I think most of these bindings are wrong. They are grouped together
because that is what DRM wants not because that reflects the h/w. So
convince me this is one block, not that it is what other people do.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/7] drm/vc4: Add devicetree bindings for VC4.
Date: Mon, 24 Aug 2015 08:47:00 -0500 [thread overview]
Message-ID: <CAL_JsqJxiGUR5BxBPyR3-0NxqWsOxMGrWQA6cMXe2pjTom__nw@mail.gmail.com> (raw)
In-Reply-To: <874mjxwyx5.fsf@eliezer.anholt.net>
On Mon, Aug 17, 2015 at 1:30 PM, Eric Anholt <eric@anholt.net> wrote:
> Stephen Warren <swarren@wwwdotorg.org> writes:
>
>> On 08/12/2015 06:56 PM, Eric Anholt wrote:
>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>>
>> This one definitely needs a patch description, since someone might not
>> know what a VC4 is, and "git log" won't show the text from the binding
>> doc itself. I'd suggest adding the initial paragraph of the binding doc
>> as the patch description, or more.
>>
>>> diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
>
>>> +- hvss: List of references to HVS video scalers
>>> +- encoders: List of references to output encoders (HDMI, SDTV)
>>
>> Would it make sense to make all those nodes child node of the vc4
>> object. That way, there's no need to have these lists of objects; they
>> can be automatically built up as the DT is enumerated. I know that e.g.
>> the NVIDIA Tegra host1x binding works this way, and I think it may have
>> been inspired by other similar cases.
>
> I've looked at tegra, and the component system used by msm appears to be
> nicer than it. To follow tegra's model, it looks like I need to build
> this extra bus thing corresponding to host1x that is effectively the
> drivers/base/component.c code, so that I can get at vc4's structure from
> the component drivers.
>
>> Of course, this is only appropriate if the HW modules really are
>> logically children of the VC4 HW module. Perhaps they aren't. If they
>> aren't though, I wonder what this "vc4" module actually represents in HW?
>
> It's the subsystem, same as we use a subsystem node for msm, sti,
> rockchip, imx, and exynos. This appears to be the common model of how
> the collection of graphics-related components is represented in the DT.
I think most of these bindings are wrong. They are grouped together
because that is what DRM wants not because that reflects the h/w. So
convince me this is one block, not that it is what other people do.
Rob
next prev parent reply other threads:[~2015-08-24 13:47 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-13 0:56 Raspberry Pi KMS-only driver Eric Anholt
2015-08-13 0:56 ` Eric Anholt
2015-08-13 0:56 ` Eric Anholt
2015-08-13 0:56 ` [PATCH 1/7] drm/vc4: Add devicetree bindings for VC4 Eric Anholt
2015-08-13 0:56 ` Eric Anholt
2015-08-13 0:56 ` Eric Anholt
2015-08-15 4:38 ` Stephen Warren
2015-08-15 4:38 ` Stephen Warren
2015-08-17 18:30 ` Eric Anholt
2015-08-17 18:30 ` Eric Anholt
2015-08-17 18:30 ` Eric Anholt
2015-08-24 13:47 ` Rob Herring [this message]
2015-08-24 13:47 ` Rob Herring
2015-08-24 13:47 ` Rob Herring
2015-08-25 20:42 ` Rob Clark
2015-08-25 20:42 ` Rob Clark
2015-08-25 20:42 ` Rob Clark
2015-08-25 23:22 ` Rob Herring
2015-08-25 23:22 ` Rob Herring
2015-08-25 23:22 ` Rob Herring
2015-08-26 11:52 ` Daniel Vetter
2015-08-26 11:52 ` Daniel Vetter
2015-08-26 11:52 ` Daniel Vetter
2015-08-26 12:09 ` Thierry Reding
2015-08-26 12:09 ` Thierry Reding
2015-08-26 12:09 ` Thierry Reding
2015-08-26 14:30 ` Rob Herring
2015-08-26 14:30 ` Rob Herring
2015-08-26 14:30 ` Rob Herring
2015-08-26 20:59 ` Dave Airlie
2015-08-26 20:59 ` Dave Airlie
2015-08-26 20:59 ` Dave Airlie
2015-08-27 0:35 ` Rob Herring
2015-08-27 0:35 ` Rob Herring
2015-08-27 0:35 ` Rob Herring
2015-08-26 11:51 ` Thierry Reding
2015-08-26 11:51 ` Thierry Reding
2015-08-26 11:51 ` Thierry Reding
2015-08-24 13:56 ` Rob Herring
2015-08-24 13:56 ` Rob Herring
2015-08-24 13:56 ` Rob Herring
2015-08-13 0:56 ` [PATCH 2/7] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver Eric Anholt
2015-08-13 0:56 ` Eric Anholt
2015-08-13 0:56 ` Eric Anholt
2015-08-15 4:39 ` Stephen Warren
2015-08-15 4:39 ` Stephen Warren
2015-08-15 4:39 ` Stephen Warren
2015-08-17 18:47 ` Eric Anholt
2015-08-17 18:47 ` Eric Anholt
2015-08-17 18:47 ` Eric Anholt
2015-08-13 0:56 ` [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi Eric Anholt
2015-08-13 0:56 ` Eric Anholt
2015-08-13 0:56 ` Eric Anholt
2015-08-13 7:51 ` Daniel Vetter
2015-08-13 7:51 ` Daniel Vetter
2015-08-13 7:51 ` Daniel Vetter
2015-08-13 20:44 ` Eric Anholt
2015-08-13 20:44 ` Eric Anholt
2015-08-13 20:44 ` Eric Anholt
2015-08-13 21:17 ` Daniel Vetter
2015-08-13 21:17 ` Daniel Vetter
2015-08-13 21:17 ` Daniel Vetter
2015-08-18 20:56 ` Eric Anholt
2015-08-18 20:56 ` Eric Anholt
2015-08-18 20:56 ` Eric Anholt
2015-08-13 21:29 ` Russell King - ARM Linux
2015-08-13 21:29 ` Russell King - ARM Linux
2015-08-13 21:29 ` Russell King - ARM Linux
2015-08-13 23:03 ` Eric Anholt
2015-08-13 23:03 ` Eric Anholt
2015-08-13 23:03 ` Eric Anholt
2015-08-13 11:45 ` Emil Velikov
2015-08-13 11:45 ` Emil Velikov
2015-08-13 11:45 ` Emil Velikov
2015-08-15 4:45 ` Stephen Warren
2015-08-15 4:45 ` Stephen Warren
2015-08-15 4:45 ` Stephen Warren
2015-08-17 17:56 ` Eric Anholt
2015-08-17 17:56 ` Eric Anholt
2015-08-17 17:56 ` Eric Anholt
2015-08-13 0:56 ` [PATCH 4/7] drm/vc4: Use the fbdev_cma helpers Eric Anholt
2015-08-13 0:56 ` Eric Anholt
2015-08-13 0:56 ` Eric Anholt
2015-08-13 0:56 ` [PATCH 5/7] drm/vc4: Allow vblank to be disabled Eric Anholt
2015-08-13 0:56 ` Eric Anholt
2015-08-13 0:56 ` Eric Anholt
2015-08-13 0:56 ` [PATCH 6/7] ARM: bcm2835: Add the DDC I2C controller to the device tree Eric Anholt
2015-08-13 0:56 ` Eric Anholt
2015-08-13 0:56 ` Eric Anholt
2015-08-15 4:51 ` Stephen Warren
2015-08-15 4:51 ` Stephen Warren
2015-08-15 4:51 ` Stephen Warren
2015-08-17 18:35 ` Eric Anholt
2015-08-17 18:35 ` Eric Anholt
2015-08-17 18:35 ` Eric Anholt
2015-08-13 0:56 ` [PATCH 7/7] ARM: bcm2835: Add VC4 " Eric Anholt
2015-08-13 0:56 ` Eric Anholt
2015-08-13 0:56 ` Eric Anholt
2015-08-15 4:54 ` Stephen Warren
2015-08-15 4:54 ` Stephen Warren
2015-08-15 4:54 ` Stephen Warren
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=CAL_JsqJxiGUR5BxBPyR3-0NxqWsOxMGrWQA6cMXe2pjTom__nw@mail.gmail.com \
--to=robherring2@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=eric@anholt.net \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=swarren@wwwdotorg.org \
/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.