'; dri-devel@lists.freedesktop.org
Subject: Re: Best practice device tree design for display subsystems/DRM
On 07/03/13 13:43, Inki Dae wrote:
I do not understand why you keep referring to the SoC dtsi. Im my
example, I said that it is made up and joined from both SoC dtsi and
board dts.
So
On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote:
Sorry but I'd like to say that this cannot be used commonly. Shouldn't
you
really consider Linux framebuffer or other subsystems? The above dtsi
file
On 07/04/13 10:33, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote:
Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
really consider Linux framebuffer or other subsystems? The above dtsi file
is specific to DRM subsystem. And I think
On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote:
A componentized device never completes and it doesn't have to. A
componentized device can start once there is a path from an input
(crtc, i2s unit) to an output (connector, speaker).
Sorry for the incomplete reply.
If you read all
On 07/04/13 10:53, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 10:33, Sascha Hauer wrote:
A componentized device never completes and it doesn't have to. A
componentized device can start once there is a path from an input
(crtc, i2s
On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote:
Wrong. Please read the example with the diagrams I gave. Consider
what happens if you have two display devices connected to a single
output, one which fixes the
On 07/04/13 11:23, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 11:10:35AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 10:53, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 10:33, Sascha Hauer wrote:
A componentized device never
On 07/04/13 11:30, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote:
On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote:
Wrong. Please read the example with the diagrams I gave. Consider
On 07/04/13 12:09, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 11:44:41AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 11:30, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote:
On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote:
On Thu, Jul 04,
On Thu, Jul 04, 2013 at 12:58:29PM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 12:09, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 11:44:41AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 11:30, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote:
On Thu, Jul
On Tue, Jul 2, 2013 at 9:25 PM, Russell King r...@arm.linux.org.uk wrote:
On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
I am against a super node which contains lcd and dcon/ire nodes. You can
enable those devices on a per board basis. We add them to dove.dtsi but
On Wed, Jul 3, 2013 at 10:02 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible = marvell,armada-510-display;
reg = 0
On Fri, Jul 05, 2013 at 09:37:34AM +0100, Grant Likely wrote:
Alternatively, you can have the same effect with a property or set of
properties in the controller node that contains phandles to the
required devices. That would provide the driver with the same
information about which devices must
On Fri, Jul 5, 2013 at 9:50 AM, Russell King r...@arm.linux.org.uk wrote:
On Fri, Jul 05, 2013 at 09:37:34AM +0100, Grant Likely wrote:
Alternatively, you can have the same effect with a property or set of
properties in the controller node that contains phandles to the
required devices. That
On 07/05/13 10:43, Grant Likely wrote:
On Wed, Jul 3, 2013 at 10:02 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible =
On Fri, Jul 5, 2013 at 10:34 AM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com wrote:
So for the discussion, I can see that there have been some voting for
super-node, some for node-to-node linking. Although I initially proposed
super-nodes, I can also happily live with node-to-node
On Fri, Jul 5, 2013 at 11:07 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
Again the difference between supernodes and graphs is that the supernode
approach does not contain information about what components are needed
to do something useful with the device. You simply have to wait until
On 07/03/13 11:53, Russell King wrote:
On Wed, Jul 03, 2013 at 06:48:41PM +0900, Inki Dae wrote:
That's not whether we can write device driver or not. dtsi is common spot in
other subsystems. Do you think the cardX node is meaningful to other
subsystems?
Yes, because fbdev could also use it
On 07/03/13 11:52, Russell King wrote:
On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible =
On 07/03/13 13:32, Russell King wrote:
On Wed, Jul 03, 2013 at 12:52:37PM +0200, Sebastian Hesselbarth wrote:
But honestly, I see no way around it and it is the only way
to allow to even have the decision for one or two cards at all.
There is no way for auto-probing the users intention...
On Wed, Jul 03, 2013 at 08:43:20PM +0900, Inki Dae wrote:
In case of fbdev, framebuffer driver would use lcd0 or lcd1 driver, or lcd0
and lcd1 drivers which are placed in drivers/video/backlight/.
No, that's totally wrong. Framebuffer drivers are not backlights.
Framebuffer drivers go in
@lists.freedesktop.org
Subject: Re: Best practice device tree design for display subsystems/DRM
On 07/03/13 13:43, Inki Dae wrote:
I do not understand why you keep referring to the SoC dtsi. Im my
example, I said that it is made up and joined from both SoC dtsi and
board dts.
So, of course, lcd controller
King'
Subject: Re: Best practice device tree design for display subsystems/DRM
On 07/04/13 09:05, Inki Dae wrote:
-Original Message-
From: Sebastian Hesselbarth [mailto:sebastian.hesselba...@gmail.com]
Sent: Wednesday, July 03, 2013 8:52 PM
To: Inki Dae
Cc: 'Russell King
On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote:
Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
really consider Linux framebuffer or other subsystems? The above dtsi file
is specific to DRM subsystem. And I think the dtsi file has no any
On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 10:33, Sascha Hauer wrote:
A componentized device never completes and it doesn't have to. A
componentized device can start once there is a path from an input
(crtc, i2s unit) to an output (connector, speaker).
On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote:
On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote:
Sorry but I'd like to say that this cannot be used commonly.
Shouldn't you
really consider
On Thu, Jul 04, 2013 at 11:10:35AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 10:53, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 10:33, Sascha Hauer wrote:
A componentized device never completes and it doesn't have to. A
On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote:
On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote:
Wrong. Please read the example with the diagrams I gave. Consider
what happens if you have two
On Thu, Jul 04, 2013 at 10:08:29AM +0100, Russell King wrote:
On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote:
A componentized device never completes and it doesn't have to. A
componentized device can start once there is a path from an input
(crtc, i2s unit) to an output
On Thu, Jul 04, 2013 at 11:40:17AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 11:23, Sascha Hauer wrote:
With this you can describe the whole graph of devices you have in the
devicetree. The examples in this file have a path from a camera sensor
via a MIPI converter to a capture
On Thu, Jul 04, 2013 at 11:44:41AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 11:30, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote:
On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King
On Wed, Jul 3, 2013 at 5:02 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible = marvell,armada-510-display;
reg = 0
...
Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
really consider Linux framebuffer or other subsystems? The above dtsi file
is specific to DRM subsystem. And I think the dtsi file has no any
dependency on certain subsystem so board dtsi file should
On Thu, Jul 4, 2013 at 5:28 PM, Dave Airlie airl...@gmail.com wrote:
...
Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
really consider Linux framebuffer or other subsystems? The above dtsi file
is specific to DRM subsystem. And I think the dtsi file
;
devicetree-disc...@lists.ozlabs.org;
dri-devel@lists.freedesktop.org; Russell King; Sebastian Hesselbarth
Subject: Re: Best practice device tree design for display subsystems/DRM
On Tue, Jul 2, 2013 at 3:02 PM, Dave Airlie airl...@gmail.com wrote:
On Wed, Jul 3, 2013 at 7:50 AM, Sascha
On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote:
On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
I am against a super
On Tue, 2 Jul 2013 11:43:59 -0600
Daniel Drake d...@laptop.org wrote:
Hi,
Hi Daniel,
I'm looking into implementing devicetree support in armada_drm and
would like to better understand the best practice here.
Adding DT support for a DRM driver seems to be complicated by the fact
that DRM
On Tue, Jul 02, 2013 at 11:43:59AM -0600, Daniel Drake wrote:
exynos seems to take a the same approach. Components are separate in
the device tree, and each component is implemented as a platform
driver or i2c driver. However all the drivers are built together in
the same module, and the
On Tue, Jul 2, 2013 at 12:43 PM, Russell King r...@arm.linux.org.uk wrote:
I will point out that relying on driver probing orders has already been
stated by driver model people to be unsafe. This is why I will not
adopt such a solution for my driver; it is a bad design.
Just to clarify, what
On Tue, Jul 02, 2013 at 12:54:41PM -0600, Daniel Drake wrote:
On Tue, Jul 2, 2013 at 12:43 PM, Russell King r...@arm.linux.org.uk wrote:
I will point out that relying on driver probing orders has already been
stated by driver model people to be unsafe. This is why I will not
adopt such a
On Tue, Jul 02, 2013 at 08:42:55PM +0200, Jean-Francois Moine wrote:
It seems that you did not look at the NVIDIA Tegra driver (I got its
general concept for my own driver, but I used a simple atomic counter):
- at probe time, the main driver (drivers/gpu/host1x/drm/drm.c) scans
the DT and
On 07/02/2013 09:19 PM, Russell King wrote:
On Tue, Jul 02, 2013 at 08:42:55PM +0200, Jean-Francois Moine wrote:
It seems that you did not look at the NVIDIA Tegra driver (I got its
general concept for my own driver, but I used a simple atomic counter):
- at probe time, the main driver
On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
I am against a super node which contains lcd and dcon/ire nodes. You can
enable those devices on a per board basis. We add them to dove.dtsi but
disable them by default (status = disabled).
The DRM driver itself should get
On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com wrote:
I am against a super node which contains lcd and dcon/ire nodes. You can
enable those devices on a per board basis. We add them to dove.dtsi but
disable them by default (status = disabled).
The DRM
On 07/02/2013 11:04 PM, Daniel Drake wrote:
On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com wrote:
I am against a super node which contains lcd and dcon/ire nodes. You can
enable those devices on a per board basis. We add them to dove.dtsi but
disable them
On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote:
Have you also considered how suspend/resume works in such a place,
where every driver is independent? The ChromeOS guys have bitched
before about the exynos driver which is has lots of sub-drivers, how
do you control the s/r ordering
On Tue, Jul 02, 2013 at 11:14:45PM +0100, Russell King wrote:
On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote:
Have you also considered how suspend/resume works in such a place,
where every driver is independent? The ChromeOS guys have bitched
before about the exynos driver
...@lists.ozlabs.org; dri-
de...@lists.freedesktop.org; Sebastian Hesselbarth
Subject: Re: Best practice device tree design for display subsystems/DRM
On Tue, Jul 02, 2013 at 12:54:41PM -0600, Daniel Drake wrote:
On Tue, Jul 2, 2013 at 12:43 PM, Russell King r...@arm.linux.org.uk
wrote:
I
; devicetree-disc...@lists.ozlabs.org; dri-
de...@lists.freedesktop.org; Russell King
Subject: Re: Best practice device tree design for display subsystems/DRM
On 07/02/2013 11:04 PM, Daniel Drake wrote:
On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com wrote:
I
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible = marvell,armada-510-display;
reg = 0 0x3f00 0x100; /* video-mem hole */
/* later:
Subject: Re: Best practice device tree design for display subsystems/DRM
On 07/03/13 11:02, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible = marvell,armada-510
On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote:
On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer wrote:
+1 for not encoding the projected usecase of the graphics subsystem into
the devicetree. Whether the two LCD controllers shall be used together
or separately should
Subject: Re: Best practice device tree design for display subsystems/DRM
On 07/03/13 11:53, Russell King wrote:
On Wed, Jul 03, 2013 at 06:48:41PM +0900, Inki Dae wrote:
That's not whether we can write device driver or not. dtsi is common
spot in
other subsystems. Do you think the cardX
Am Dienstag, den 02.07.2013, 18:46 -0700 schrieb Stéphane Marchesin:
On Tue, Jul 2, 2013 at 3:02 PM, Dave Airlie airl...@gmail.com wrote:
On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
On Tue, Jul 02,
On 07/03/13 08:55, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote:
Have you also considered how suspend/resume works in such a place,
where every driver is independent? The ChromeOS guys have bitched
before about the exynos driver which is has lots of
On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible = marvell,armada-510-display;
reg = 0 0x3f00 0x100;
On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
I am against a super node which contains lcd and dcon/ire nodes. You can
enable those devices on a per board basis. We add them to dove.dtsi but
disable them
On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
I am against a super node which contains lcd and dcon/ire nodes. You can
enable
On Tue, Jul 2, 2013 at 3:02 PM, Dave Airlie airl...@gmail.com wrote:
On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
I am against a
On Tue, Jul 2, 2013 at 9:46 PM, Stéphane Marchesin
stephane.marche...@gmail.com wrote:
On Tue, Jul 2, 2013 at 3:02 PM, Dave Airlie airl...@gmail.com wrote:
On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
60 matches
Mail list logo
