[PATCH RFC 06/15] drm/armada: move variant initialisation to CRTC init

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

[PATCH RFC 06/15] drm/armada: move variant initialisation to CRTC init

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

[PATCH RFC 06/15] drm/armada: move variant initialisation to CRTC init

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

[PATCH v2] drm/i2c: tda998x: Change the compatible strings

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

[PATCH v2] drm/i2c: tda998x: Change the compatible strings

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

[PATCH v2] drm/i2c: tda998x: Change the compatible strings

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

[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation

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 >> >>

[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation

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

[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation

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 ++ >

[PATCH 0/9] Doc/DT: DT bindings for various display components

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 >>>

[PATCH 0/9] Doc/DT: DT bindings for various display components

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. > >

[PATCH 0/9] Doc/DT: DT bindings for various display components

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

[PATCH v5 00/23]

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

[PATCH v3 15/24] drm/i2c: tda998x: use irq for connection status and EDID read

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

[PATCH v2 13/28] drm/i2c: tda998x: use irq for connection status and EDID read

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 to >

[PATCH v2 13/28] drm/i2c: tda998x: use irq for connection status and EDID read

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

Re: [PATCH 0/5] Armada DRM stuff

useful feedback which has been incorporated. I believe all the major issues have been addressed now. Tested-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com on Marvell Armada 510, SolidRun CuBox with quick-hack DT support added. Let's please get this driver mainlined and start working

Re: [PATCH 5/5] DRM: Armada: add support for drm tda19988 driver

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

Re: [PATCH 5/5] DRM: Armada: add support for drm tda19988 driver

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

[PATCH v2 8/8] drm/tilcdc fixup mode to workaround sync for tda998x

puting. Signed-off-by: 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 <rmk+kernel at arm.linux.org.uk> Cc: Daniel Vetter

[PATCH v2 7/8] drm/i2c: tda998x: prepare for broken sync workaround

Signed-off-by: Sebastian Hesselbarth --- Changelog: for v1: - reword comment Cc: David Airlie Cc: Darren Etheridge Cc: Rob Clark Cc: Russell King <rmk+kernel at arm.linux.org.uk> Cc: Daniel Vetter Cc: dri-devel at lists.freedesktop.org Cc: linux-kernel at vger.kernel.org --- drivers/g

[PATCH v2 6/8] drm/i2c: tda998x: fix sync generation and calculation

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

[PATCH v2 5/8] drm/i2c: tda998x: add video and audio input configuration

ux.org.uk> Signed-off-by: Sebastian Hesselbarth Tested-by: Darren Etheridge --- Changelog: for v1: - set AUDIO_DIV to SERCLK/16 for modes with pixclk >100MHz - also calculate CTS v1->v2: - Remove CTS calculation as it isn't used in current TDA998x setup (Reported by Russell King) - Remo

[PATCH v2 4/8] drm/i2c: tda998x: prepare for video input configuration

er configuration. Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk> Tested-by: Darren Etheridge Tested-by: Sebastian Hesselbarth --- Cc: David Airlie Cc: Darren Etheridge Cc: Rob Clark Cc: Russell King <rmk+kernel at arm.linux.org.uk> Cc: Daniel Vetter Cc: dri-devel at lis

[PATCH v2 3/8] drm/i2c: tda998x: fix npix/nline programming

en Etheridge Tested-by: Sebastian Hesselbarth --- Cc: David Airlie Cc: Darren Etheridge Cc: Rob Clark Cc: Russell King <rmk+kernel at arm.linux.org.uk> Cc: Daniel Vetter Cc: dri-devel at lists.freedesktop.org Cc: linux-kernel at vger.kernel.org --- drivers/gpu/drm/i2c/tda998x_drv.c |4 ++

[PATCH v2 2/8] drm/i2c: tda998x: ensure VIP output mux is properly set

o 0x24 on powerup, but other drivers 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 <rmk+kernel at arm.linux.org.uk> Tested-by: Darren Etheridge Tested-by: Sebastian

[PATCH v2 1/8] drm/i2c: tda998x: fix EDID reading on TDA19988 devices

From: Russell King <rmk+ker...@arm.linux.org.uk> TDA19988 devices need their RAM enabled in order to read EDID information. Add support for this. Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk> Signed-off-by: Rob Clark Tested-by: Darren Etheridge Tested-by: Sebastian

[PATCH v2 0/8] Several NXP TDA998x patches

: 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 | 481

[PATCH 5/8] drm/i2c: tda998x: add video and audio input configuration

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, >

[PATCH 6/8] drm/i2c: tda998x: fix sync generation and calculation

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

Re: [PATCH 5/8] drm/i2c: tda998x: add video and audio input configuration

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

Re: [PATCH 6/8] drm/i2c: tda998x: fix sync generation and calculation

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 - mode-hdisplay

[PATCH v2 1/8] drm/i2c: tda998x: fix EDID reading on TDA19988 devices

Tested-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Cc: David Airlie airl...@linux.ie Cc: Darren Etheridge detheri...@ti.com Cc: Rob Clark robdcl...@gmail.com Cc: Russell King rmk+ker...@arm.linux.org.uk Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: dri-devel@lists.freedesktop.org Cc

[PATCH v2 3/8] drm/i2c: tda998x: fix npix/nline programming

...@ti.com Tested-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Cc: David Airlie airl...@linux.ie Cc: Darren Etheridge detheri...@ti.com Cc: Rob Clark robdcl...@gmail.com Cc: Russell King rmk+ker...@arm.linux.org.uk Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: dri-devel

[PATCH v2 2/8] drm/i2c: tda998x: ensure VIP output mux is properly set

on powerup, but other drivers 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 rmk+ker...@arm.linux.org.uk Tested-by: Darren Etheridge detheri...@ti.com Tested-by: Sebastian

[PATCH v2 0/8] Several NXP TDA998x patches

: 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 | 481

[PATCH v2 4/8] drm/i2c: tda998x: prepare for video input configuration

. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Tested-by: Darren Etheridge detheri...@ti.com Tested-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Cc: David Airlie airl...@linux.ie Cc: Darren Etheridge detheri...@ti.com Cc: Rob Clark robdcl...@gmail.com Cc: Russell King rmk+ker

[PATCH v2 5/8] drm/i2c: tda998x: add video and audio input configuration

-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com Tested-by: Darren Etheridge detheri...@ti.com --- Changelog: for v1: - set AUDIO_DIV to SERCLK/16 for modes with pixclk 100MHz - also calculate CTS v1-v2: - Remove CTS calculation as it isn't used in current TDA998x setup (Reported

[PATCH v2 7/8] drm/i2c: tda998x: prepare for broken sync workaround

detheri...@ti.com Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Changelog: for v1: - reword comment Cc: David Airlie airl...@linux.ie Cc: Darren Etheridge detheri...@ti.com Cc: Rob Clark robdcl...@gmail.com Cc: Russell King rmk+ker...@arm.linux.org.uk Cc: Daniel Vetter

[PATCH v2 6/8] drm/i2c: tda998x: fix sync generation and calculation

This fixes the wrong sync generation and sync calculation of TDA998x for HS/VS-based sync detection. Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com Tested-by: Darren Etheridge detheri...@ti.com --- Changelog: v1-v2: - revert calculation of hs/de_pix_s/e (Reported by Russell

[PATCH v2 8/8] drm/tilcdc fixup mode to workaround sync for tda998x

. Signed-off-by: Darren Etheridge detheri...@ti.com Tested-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Changelog: v1-v2: - fix typo in commit line (s/workaound/workaround) Cc: David Airlie airl...@linux.ie Cc: Darren Etheridge detheri...@ti.com Cc: Rob Clark robdcl...@gmail.com Cc

[PATCH 8/8] drm/tilcdc fixup mode to workaound sync for tda998x

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.

[PATCH 7/8] drm/i2c: tda998x: prepare for broken sync workaround

pected reference pixel. Signed-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 <rmk+kernel at arm.linux.org.uk> Cc: Daniel Vetter Cc: dri-devel at lists.freedesktop.o

[PATCH 6/8] drm/i2c: tda998x: fix sync generation and calculation

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 <rmk+kernel at arm.linux.org.uk> Cc: Daniel Vetter Cc: dri

[PATCH 5/8] drm/i2c: tda998x: add video and audio input configuration

ux.org.uk> Signed-off-by: Sebastian Hesselbarth --- Changelog: for v1: - set AUDIO_DIV to SERCLK/16 for modes with pixclk >100MHz - also calculate CTS Cc: David Airlie Cc: Darren Etheridge Cc: Rob Clark Cc: Russell King <rmk+kernel at arm.linux.org.uk> Cc: Daniel

[PATCH 4/8] drm/i2c: tda998x: prepare for video input configuration

er configuration. Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk> Tested-by: Sebastian Hesselbarth --- Cc: David Airlie Cc: Darren Etheridge Cc: Rob Clark Cc: Russell King <rmk+kernel at arm.linux.org.uk> Cc: Daniel Vetter Cc: dri-devel at lists.freedesktop.org Cc: lin

[PATCH 3/8] drm/i2c: tda998x: fix npix/nline programming

From: Russell King <rmk+ker...@arm.linux.org.uk> 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 <rmk+kernel at arm.linux.org.uk> Tested-by: Sebastian

[PATCH 2/8] drm/i2c: tda998x: ensure VIP output mux is properly set

o 0x24 on powerup, but other drivers 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 <rmk+kernel at arm.linux.org.uk> Tested-by: Sebastian Hesselbarth --- Cc: David Airlie

[PATCH 1/8] drm/i2c: tda998x: fix EDID reading on TDA19988 devices

From: Russell King <rmk+ker...@arm.linux.org.uk> TDA19988 devices need their RAM enabled in order to read EDID information. Add support for this. Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk> Tested-by: Sebastian Hesselbarth --- Cc: David Airlie Cc: Darren Etheri

[PATCH 0/8] Several NXP TDA998x patches

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

[PATCH 1/8] drm/i2c: tda998x: fix EDID reading on TDA19988 devices

From: Russell King rmk+ker...@arm.linux.org.uk TDA19988 devices need their RAM enabled in order to read EDID information. Add support for this. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Tested-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Cc: David Airlie airl

[PATCH 3/8] drm/i2c: tda998x: fix npix/nline programming

From: Russell King rmk+ker...@arm.linux.org.uk 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 rmk+ker...@arm.linux.org.uk Tested-by: Sebastian Hesselbarth

[PATCH 0/8] Several NXP TDA998x patches

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

[PATCH 2/8] drm/i2c: tda998x: ensure VIP output mux is properly set

on powerup, but other drivers 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 rmk+ker...@arm.linux.org.uk Tested-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Cc

[PATCH 4/8] drm/i2c: tda998x: prepare for video input configuration

. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Tested-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Cc: David Airlie airl...@linux.ie Cc: Darren Etheridge detheri...@ti.com Cc: Rob Clark robdcl...@gmail.com Cc: Russell King rmk+ker...@arm.linux.org.uk Cc: Daniel Vetter

[PATCH 5/8] drm/i2c: tda998x: add video and audio input configuration

-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Changelog: for v1: - set AUDIO_DIV to SERCLK/16 for modes with pixclk 100MHz - also calculate CTS Cc: David Airlie airl...@linux.ie Cc: Darren Etheridge detheri...@ti.com Cc: Rob Clark robdcl...@gmail.com Cc: Russell King rmk+ker

[PATCH 7/8] drm/i2c: tda998x: prepare for broken sync workaround

pixel. Signed-off-by: Darren Etheridge detheri...@ti.com Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Changelog: for v1: - reword comment Cc: David Airlie airl...@linux.ie Cc: Darren Etheridge detheri...@ti.com Cc: Rob Clark robdcl...@gmail.com Cc: Russell King rmk+ker

[PATCH 8/8] drm/tilcdc fixup mode to workaound sync for tda998x

From: Darren Etheridge detheri...@ti.com 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.

Re: [PATCH 0/2] drm/tilcdc drm/i2c/tda998x workaround for sync issues on TI SoC

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 video and audio input configuration Sebastian Hesselbarth: drm/i2c: tda998x: fix sync generation

[PATCH 0/2] drm/tilcdc drm/i2c/tda998x workaround for sync issues on TI SoC

rising 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 video

[PATCH 0/2] drm/tilcdc drm/i2c/tda998x workaround for sync issues on TI SoC

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

Re: [PATCH 0/2] drm/tilcdc drm/i2c/tda998x workaround for sync issues on TI SoC

On 07/25/2013 09:32 PM, Rob Clark wrote: On Thu, Jul 25, 2013 at 2:32 PM, Darren Etheridge detheri...@ti.com 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

Re: DT binding review for Armada display subsystem

On 07/13/2013 04:25 PM, Daniel Drake wrote: On Sat, Jul 13, 2013 at 2:35 AM, Jean-Francois Moine moin...@free.fr 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

Re: DT binding review for Armada display subsystem

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 Draked...@laptop.org wrote: On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois

DT binding review for Armada display subsystem

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

DT binding review for Armada display subsystem

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

Best practice device tree design for display subsystems/DRM

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,

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'; devicetree-disc...@lists.ozlabs.org; 'Jean-Francois Moine'; 'Sascha Hauer'; 'Daniel Drake

Re: Best practice device tree design for display subsystems/DRM

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

Re: Best practice device tree design for display subsystems/DRM

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

Re: Best practice device tree design for display subsystems/DRM

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

Re: Best practice device tree design for display subsystems/DRM

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

Re: Best practice device tree design for display subsystems/DRM

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

Re: Best practice device tree design for display subsystems/DRM

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 =

Best practice device tree design for display subsystems/DRM

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:

Best practice device tree design for display subsystems/DRM

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.

Best practice device tree design for display subsystems/DRM

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/0

Best practice device tree design for display subsystems/DRM

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 star

Best practice device tree design for display subsystems/DRM

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.

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.hesselbarth at gmail.com] >> Sent: Wednesday, July 03, 2013 8:52 PM >> To: Inki Dae >> Cc: 'Russell King'; devicetree-discuss at lists.ozlabs.org; 'Je

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 node is meaningful to other subsystems? Yes, because fbdev could also use it

Re: Best practice device tree design for display subsystems/DRM

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 =

Re: Best practice device tree design for display subsystems/DRM

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

Best practice device tree design for display subsystems/DRM

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

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 nodes and dcon are part of dove.dtsi >> because they are physically

Best practice device tree design for display subsystems/DRM

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 =

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 node is meaningful to other >> subsystems? > > Yes, because fbdev could

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-display"; >>> reg = <0 0x3f00 0x100>; /*

Best practice device tree design for display subsystems/DRM

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

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 > 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

Re: armada_drm clock selection - try 2

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

Re: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

On 07/01/2013 11:55 PM, Rob Clark wrote: On Mon, Jul 1, 2013 at 4:52 AM, Sebastian Hesselbarth sebastian.hesselba...@gmail.com 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

Re: armada_drm clock selection - try 2

On 07/02/13 03:57, Daniel Drake wrote: On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth sebastian.hesselba...@gmail.com 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

Re: Best practice device tree design for display subsystems/DRM

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

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 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

Re: Best practice device tree design for display subsystems/DRM

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

Best practice device tree design for display subsystems/DRM

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

armada_drm clock selection - try 2

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 reque

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

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 C

armada_drm clock selection - try 2

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

  1   2   >