On 07/11/2014 04:37 PM, Russell King - ARM Linux wrote:
> On Sat, Jul 05, 2014 at 01:58:37PM +0200, Sebastian Hesselbarth wrote:
>> On 07/05/2014 12:38 PM, Russell King wrote:
>>> Move the variant initialisation entirely to the CRTC init function -
>>> the variant suppo
On 07/05/2014 02:21 PM, Russell King - ARM Linux wrote:
> On Sat, Jul 05, 2014 at 01:58:37PM +0200, Sebastian Hesselbarth wrote:
>> On 07/05/2014 12:38 PM, Russell King wrote:
>>> Move the variant initialisation entirely to the CRTC init function -
>>> the variant suppo
On 07/05/2014 12:38 PM, Russell King wrote:
> Move the variant initialisation entirely to the CRTC init function -
> the variant support is really about the CRTC properties than the whole
> system, and we want to treat each CRTC individually when we support DT.
>
> Signed-off-by: Russell King
> -
On 03/23/2014 09:03 PM, Russell King - ARM Linux wrote:
> On Sun, Mar 23, 2014 at 07:12:05PM +0100, Sebastian Hesselbarth wrote:
>> On 03/23/2014 11:19 AM, Jean-Francois Moine wrote:
>>> On Fri, 21 Mar 2014 14:37:52 +0100
>>> Sebastian Hesselbarth wrote:
&g
On 03/23/2014 11:19 AM, Jean-Francois Moine wrote:
> On Fri, 21 Mar 2014 14:37:52 +0100
> Sebastian Hesselbarth wrote:
>>>Required properties;
>>> - - compatible: must be "nxp,tda998x"
>>> + - compatible: may be "nxp,tda9989", "n
On 03/21/2014 11:55 AM, Jean-Francois Moine wrote:
> The tda998x driver accepts only 3 chips from the TDA998x family.
> This patch changes the driver compatible strings to these chips.
Jean-Francois,
be careful with building a DT binding from a Linux driver. Although
we constantly struggle to def
On 03/20/2014 02:52 PM, Jean-Francois Moine wrote:
> On Thu, 20 Mar 2014 14:32:18 +0100
> Sebastian Hesselbarth wrote:
>
>> Ok, I had another round of google'ing and found this:
>> http://hipstercircuits.com/wp-content/uploads/2013/05/TDA19988.pdf
>>
>>
On 03/20/2014 02:01 PM, Jean-Francois Moine wrote:
> On Thu, 20 Mar 2014 13:32:24 +0100
> Sebastian Hesselbarth wrote:
>
>>> + - reg: I2C address - must be <0x70>
>>
>> TDA9983b datasheet says:
>>
>> "Bits A0 and A1 of the I2C-bus device
On 03/20/2014 09:58 AM, Jean-Francois Moine wrote:
> The I2C address (reg) is required for the TDA998x driver to be loaded
> and initialized.
>
> Signed-off-by: Jean-Francois Moine
> ---
> This patch applies to linux-next.
> ---
> Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 2 ++
>
On 02/28/14 14:47, Philipp Zabel wrote:
> Am Freitag, den 28.02.2014, 13:57 +0100 schrieb Sebastian Hesselbarth:
>> On 02/28/14 13:20, Tomi Valkeinen wrote:
>>> This series is a re-send of
>>> http://article.gmane.org/gmane.linux.drivers.devicetree/61739
>>>
On 02/28/14 14:14, Tomi Valkeinen wrote:
> On 28/02/14 14:57, Sebastian Hesselbarth wrote:
>
>> Out of curiosity, will there be DT nodes for pull-up resistors soon,
>> too? ;)
>
> If they don't work automatically, yes, we need DT nodes and drivers for
> them.
>
On 02/28/14 13:20, Tomi Valkeinen wrote:
> This series is a re-send of
> http://article.gmane.org/gmane.linux.drivers.devicetree/61739
>
...
> Shortly about the display components in the series, in the order of probable
> public interest:
>
> * Analog TV, DVI and HDMI Connectors represent a respect
On 02/02/2014 07:23 PM, Russell King - ARM Linux wrote:
> On Sun, Feb 02, 2014 at 07:06:06PM +0100, Jean-Francois Moine wrote:
>> - on encoder_destroy(), the function drm_i2c_encoder_destroy()
>>unregisters the i2c client, so, with a DT, a second encoder_init()
>>would crash.
>
> I think th
On 01/22/14 23:27, Russell King - ARM Linux wrote:
> On Sun, Jan 19, 2014 at 07:58:43PM +0100, Jean-Francois Moine wrote:
>> This patch adds the optional treatment of the tda998x IRQ.
>>
>> The interrupt function is used to know the display connection status
>> without polling and to speedup readin
On 01/12/2014 07:51 PM, Jean-Francois Moine wrote:
> On Sat, 11 Jan 2014 19:35:21 +0100
> Sebastian Hesselbarth wrote:
>
>> At least for the DT part, I'd suggest to not ask for interrupt directly
>> but use a proper gpios property. The can of course be converted t
On 01/11/2014 07:14 PM, Russell King - ARM Linux wrote:
> On Thu, Jan 09, 2014 at 12:04:12PM +0100, Jean-Francois Moine wrote:
>> @@ -1250,6 +1311,39 @@ tda998x_encoder_init(struct i2c_client *client,
>> priv->vip_cntrl_2 = video;
>> }
>>
>> +/* install the optional HDMI conne
useful feedback which has been incorporated.
I believe all the major issues have been addressed now.
Tested-by: Sebastian Hesselbarth
on Marvell Armada 510, SolidRun CuBox with quick-hack DT support added.
Let's please get this driver mainlined and start working on proper DT
support f
On 10/07/2013 05:53 PM, Mark Brown wrote:
On Mon, Oct 07, 2013 at 01:29:30PM +0200, Sebastian Hesselbarth wrote:
I2S _can_ support more than two channels, but only if you wire up more
DATA lines. Those are not available on Dove, so its I2S is limited to
two channel audio.
A lot of devices
On 10/07/2013 01:09 PM, Russell King - ARM Linux wrote:
On Mon, Oct 07, 2013 at 12:48:20PM +0200, Jean-Francois Moine wrote:
On Mon, 7 Oct 2013 10:44:04 +0100
Rabeeh did the most he could to have a working Cubox. He used bad
written drivers and he had not the time to think about how the drivers
: Darren Etheridge
Tested-by: Sebastian Hesselbarth
---
Changelog:
v1->v2:
- fix typo in commit line (s/workaound/workaround)
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.
Signed-off-by: Sebastian Hesselbarth
---
Changelog:
for v1:
- reword comment
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
---
drivers/gpu/drm/i2c/tda998x_drv.c |8
This fixes the wrong sync generation and sync calculation of TDA998x
for HS/VS-based sync detection.
Signed-off-by: Sebastian Hesselbarth
Tested-by: Darren Etheridge
---
Changelog:
v1->v2:
- revert calculation of hs/de_pix_s/e (Reported by Russell King)
Cc: David Airlie
Cc: Darren Etheri
From: Russell King
This patch adds tda998x specific parameters to allow it to be configured
for different boards using it. Also, this implements rudimentary audio
support for S/PDIF attached controllers.
Signed-off-by: Russell King
Signed-off-by: Sebastian Hesselbarth
Tested-by: Darren
ssell King
Tested-by: Darren Etheridge
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
---
drivers/gpu/drm/i2c/tda998x_drv.c | 16 +
From: Russell King
The npix/nline registers are supposed to be programmed with the total
number of pixels/lines, not the displayed pixels/lines, and not minus
one either.
Signed-off-by: Russell King
Tested-by: Darren Etheridge
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren
s may
set this to 0x12. This results in incorrect colours.
Fix this by ensuring that the register is always set to the power on
default setting.
Signed-off-by: Russell King
Tested-by: Darren Etheridge
Tested-by: Sebastian Hesselbarth
---
Changelog:
v1->v2:
- move reg_write to tda998x_reset
From: Russell King
TDA19988 devices need their RAM enabled in order to read EDID
information. Add support for this.
Signed-off-by: Russell King
Signed-off-by: Rob Clark
Tested-by: Darren Etheridge
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
a998x: prepare for video input configuration
drm/i2c: tda998x: add video and audio input configuration
Sebastian Hesselbarth (2):
drm/i2c: tda998x: fix sync generation and calculation
drm/i2c: tda998x: prepare for broken sync workaround
drivers/gpu/drm/i2c/tda998x_drv.c |
: Darren Etheridge
Tested-by: Sebastian Hesselbarth
---
Changelog:
v1->v2:
- fix typo in commit line (s/workaound/workaround)
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
drivers/
This fixes the wrong sync generation and sync calculation of TDA998x
for HS/VS-based sync detection.
Signed-off-by: Sebastian Hesselbarth
Tested-by: Darren Etheridge
---
Changelog:
v1->v2:
- revert calculation of hs/de_pix_s/e (Reported by Russell King)
Cc: David Airlie
Cc: Darren Etheri
Signed-off-by: Sebastian Hesselbarth
---
Changelog:
for v1:
- reword comment
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/i2c/tda998x_drv.c |8
1
From: Russell King
This patch adds tda998x specific parameters to allow it to be configured
for different boards using it. Also, this implements rudimentary audio
support for S/PDIF attached controllers.
Signed-off-by: Russell King
Signed-off-by: Sebastian Hesselbarth
Tested-by: Darren
ssell King
Tested-by: Darren Etheridge
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/i2c/tda998x_drv.c | 16 ++
a998x: prepare for video input configuration
drm/i2c: tda998x: add video and audio input configuration
Sebastian Hesselbarth (2):
drm/i2c: tda998x: fix sync generation and calculation
drm/i2c: tda998x: prepare for broken sync workaround
drivers/gpu/drm/i2c/tda998x_drv.c |
From: Russell King
The npix/nline registers are supposed to be programmed with the total
number of pixels/lines, not the displayed pixels/lines, and not minus
one either.
Signed-off-by: Russell King
Tested-by: Darren Etheridge
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren
s may
set this to 0x12. This results in incorrect colours.
Fix this by ensuring that the register is always set to the power on
default setting.
Signed-off-by: Russell King
Tested-by: Darren Etheridge
Tested-by: Sebastian Hesselbarth
---
Changelog:
v1->v2:
- move reg_write to tda998x_reset
From: Russell King
TDA19988 devices need their RAM enabled in order to read EDID
information. Add support for this.
Signed-off-by: Russell King
Signed-off-by: Rob Clark
Tested-by: Darren Etheridge
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
On 08/14/13 14:41, Russell King - ARM Linux wrote:
On Tue, Aug 06, 2013 at 12:20:16AM +0200, Sebastian Hesselbarth wrote:
+ de_pix_s = mode->htotal - mode->hdisplay;
+ de_pix_e = de_pix_s + mode->hdisplay;
+ hs_pix_s = mode->hsync_start - mo
On 08/14/13 16:12, Russell King - ARM Linux wrote:
On Tue, Aug 06, 2013 at 12:20:15AM +0200, Sebastian Hesselbarth wrote:
@@ -0,0 +1,23 @@
+#ifndef __TDA998X_H__
+#define __TDA998X_H__
+
+enum tda998x_audio_format {
+ AFMT_I2S,
+ AFMT_SPDIF,
+};
+
+struct tda998x_encoder_params
On 08/14/13 16:12, Russell King - ARM Linux wrote:
> On Tue, Aug 06, 2013 at 12:20:15AM +0200, Sebastian Hesselbarth wrote:
>> @@ -0,0 +1,23 @@
>> +#ifndef __TDA998X_H__
>> +#define __TDA998X_H__
>> +
>> +enum tda998x_audio_format {
>> +AFMT_I2S,
>
On 08/14/13 14:41, Russell King - ARM Linux wrote:
> On Tue, Aug 06, 2013 at 12:20:16AM +0200, Sebastian Hesselbarth wrote:
>> +de_pix_s = mode->htotal - mode->hdisplay;
>> +de_pix_e = de_pix_s + mode->hdisplay;
>> +hs_pix_s = mode
From: Darren Etheridge
Add a fixup function that will flip the hsync priority and
add a hskew value that is used to shift the tda998x to the
right by a variable number of pixels depending on the mode.
This works around an issue with the sync timings that tilcdc
is outputing.
Signed-off-by: Darre
-off-by: Darren Etheridge
Signed-off-by: Sebastian Hesselbarth
---
Changelog:
for v1:
- reword comment
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
---
drivers/gpu/drm/i2c
This fixes the wrong sync generation and sync calculation of TDA998x
for HS/VS-based sync detection.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at
From: Russell King
This patch adds tda998x specific parameters to allow it to be configured
for different boards using it. Also, this implements rudimentary audio
support for S/PDIF attached controllers.
Signed-off-by: Russell King
Signed-off-by: Sebastian Hesselbarth
---
Changelog:
for v1
ssell King
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
---
drivers/gpu/drm/i2c/tda998x_drv.c | 16 ++--
1 file changed, 10
From: Russell King
The npix/nline registers are supposed to be programmed with the total
number of pixels/lines, not the displayed pixels/lines, and not minus
one either.
Signed-off-by: Russell King
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc
s may
set this to 0x12. This results in incorrect colours.
Fix this by ensuring that the register is always set to the power on
default setting.
Signed-off-by: Russell King
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel V
From: Russell King
TDA19988 devices need their RAM enabled in order to read EDID
information. Add support for this.
Signed-off-by: Russell King
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel at
Sebastian Hesselbarth (1):
drm/i2c: tda998x: fix sync generation and calculation
arch/arm/boot/dts/am335x-boneblack.dts |2 +-
drivers/gpu/drm/i2c/tda998x_drv.c | 526 +++-
drivers/gpu/drm/tilcdc/tilcdc_crtc.c |7 +-
drivers/gpu/drm/tilcdc
From: Darren Etheridge
Add a fixup function that will flip the hsync priority and
add a hskew value that is used to shift the tda998x to the
right by a variable number of pixels depending on the mode.
This works around an issue with the sync timings that tilcdc
is outputing.
Signed-off-by: Darre
-off-by: Darren Etheridge
Signed-off-by: Sebastian Hesselbarth
---
Changelog:
for v1:
- reword comment
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/i2c
This fixes the wrong sync generation and sync calculation of TDA998x
for HS/VS-based sync detection.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker
From: Russell King
This patch adds tda998x specific parameters to allow it to be configured
for different boards using it. Also, this implements rudimentary audio
support for S/PDIF attached controllers.
Signed-off-by: Russell King
Signed-off-by: Sebastian Hesselbarth
---
Changelog:
for v1
s may
set this to 0x12. This results in incorrect colours.
Fix this by ensuring that the register is always set to the power on
default setting.
Signed-off-by: Russell King
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel V
ssell King
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/i2c/tda998x_drv.c | 16 ++--
1 file changed, 10 insert
Sebastian Hesselbarth (1):
drm/i2c: tda998x: fix sync generation and calculation
arch/arm/boot/dts/am335x-boneblack.dts |2 +-
drivers/gpu/drm/i2c/tda998x_drv.c | 526 +++-
drivers/gpu/drm/tilcdc/tilcdc_crtc.c |7 +-
drivers/gpu/drm/tilcdc
From: Russell King
The npix/nline registers are supposed to be programmed with the total
number of pixels/lines, not the displayed pixels/lines, and not minus
one either.
Signed-off-by: Russell King
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc
From: Russell King
TDA19988 devices need their RAM enabled in order to read EDID
information. Add support for this.
Signed-off-by: Russell King
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel
m/i2c: nxp-tda998x: ensure VIP output mux is properly set
drm/i2c: nxp-tda998x: fix npix/nline programming
drm/i2c: nxp-tda998x: prepare for video input configuration
drm/i2c: nxp-tda998x: add video and audio input configuration
Sebastian Hesselbarth:
drm/i2c: tda998x: fix sync generation and calcul
comprising the following patches?
Russell King:
drm/i2c: nxp-tda998x: fix EDID reading on TDA19988 devices
drm/i2c: nxp-tda998x: ensure VIP output mux is properly set
drm/i2c: nxp-tda998x: fix npix/nline programming
drm/i2c: nxp-tda998x: prepare for video input configuration
drm/i2c: nxp-tda998x: add v
On 07/25/2013 09:32 PM, Rob Clark wrote:
On Thu, Jul 25, 2013 at 2:32 PM, Darren Etheridge wrote:
Russell King and Sebastian Hasselbarth had proposed some very good changes
for the tda998x HDMI encoder driver. But when those changes were tested
on BeagleBone Black against the tilcdc driver man
On 07/25/2013 09:32 PM, Rob Clark wrote:
> On Thu, Jul 25, 2013 at 2:32 PM, Darren Etheridge
> wrote:
>> Russell King and Sebastian Hasselbarth had proposed some very good changes
>> for the tda998x HDMI encoder driver. But when those changes were tested
>> on BeagleBone Black against the tilcdc
On 07/13/2013 01:12 PM, Russell King - ARM Linux wrote:
On Sat, Jul 13, 2013 at 12:56:50PM +0200, Sylwester Nawrocki wrote:
On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Drake wrote:
On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine wrote:
On 07/13/2013 04:25 PM, Daniel Drake wrote:
On Sat, Jul 13, 2013 at 2:35 AM, Jean-Francois Moine wrote:
I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
modules. I set 3 clocks in the DT for the LCD0: lcdcl
On 07/13/2013 01:12 PM, Russell King - ARM Linux wrote:
> On Sat, Jul 13, 2013 at 12:56:50PM +0200, Sylwester Nawrocki wrote:
>> On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
>>> On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Drake wrote:
On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine
On 07/13/2013 04:25 PM, Daniel Drake wrote:
> On Sat, Jul 13, 2013 at 2:35 AM, Jean-Francois Moine
> wrote:
>> I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
>> driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
>> modules. I set 3 clocks in the DT for the
On 07/05/13 11:51, Grant Likely wrote:
On Fri, Jul 5, 2013 at 10:34 AM, Sebastian Hesselbarth
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
On 07/05/13 11:51, Grant Likely wrote:
> On Fri, Jul 5, 2013 at 10:34 AM, Sebastian Hesselbarth
> 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,
On 07/05/13 10:43, Grant Likely wrote:
> On Wed, Jul 3, 2013 at 10:02 AM, 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-
On 07/05/13 10:43, Grant Likely wrote:
On Wed, Jul 3, 2013 at 10:02 AM, 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";
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 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
w
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 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
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 the
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'; devicetree-disc...@lists.ozlabs.org; 'Jean-Francois
Moine'; 'Sas
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
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. C
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, Sas
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
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. A
On 07/04/13 09:05, Inki Dae wrote:
>> -Original Message-
>> From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth at gmail.com]
>> Sent: Wednesday, July 03, 2013 8:52 PM
>> To: Inki Dae
>> Cc: 'Russell King'; devicetree-discuss at lists.ozlab
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 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 nodes and dcon are part of dove.dtsi
because they are physically available on every D
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 = "marvell,armada-510-dis
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 to
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-display";
reg = <0 0x3f00 0x100>; /* video
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 sub-drivers
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-probin
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 nodes and dcon are part of dove.dtsi
>> because they are physically avail
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 = "marvell,armada-5
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
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-display";
>>> reg = <0 0x3f00 0x100>; /* vi
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 sub
On 07/02/2013 11:04 PM, Daniel Drake wrote:
On Tue, Jul 2, 2013 at 1:57 PM, 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 = "dis
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 (drivers
On 07/02/13 03:57, Daniel Drake wrote:
On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
wrote:
I prefer not to try to find the best clock (source) at all. Let the
user pass the clock name by e.g. platform_data (or DT) and just try to
get the requested pixclk or a integer multiple of it
On 07/01/2013 11:55 PM, Rob Clark wrote:
On Mon, Jul 1, 2013 at 4:52 AM, Sebastian Hesselbarth
wrote:
- TDA998x irq handling - ignored
- TDA998x sync fix - ignored
At least the sync fix, looks like I missed it (it probably is a good
idea to CC me if you want me to look at it). Looks like
On 07/01/2013 10:30 PM, Daniel Drake wrote:
Here is a new patch which should incorporate all your previous feedback.
Now each variant passes clock info to the main driver via a new
armada_clk_info structure.
A helper function in the core lets each variant find the best clock.
As you suggested we
1 - 100 of 167 matches
Mail list logo
