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
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
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
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
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
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
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
-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: 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
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 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
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
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
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 |
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 ++
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
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
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
: 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/
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
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,
>
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
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
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
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 |
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
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
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
: 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.
On 01/29/2013 06:23 PM, Rob Clark wrote:
Driver for the NXP TDA998X i2c hdmi encoder slave.
Rob,
good to see a driver for TDA998x comming! I'd love to test
it on CuBox (mach-dove) but there is no gpu driver I can hook up,
yet. Anyway, I will make some comments how I think the driver
should be
On 01/31/2013 03:23 PM, Rob Clark wrote:
On Wed, Jan 30, 2013 at 8:23 PM, Sebastian Hesselbarth
wrote:
On 01/29/2013 06:23 PM, Rob Clark wrote:
[...]
+
+/* The TDA9988 series of devices use a paged register scheme.. to
simplify
+ * things we encode the page # in upper bits of the register
On 05/17/13 13:33, Jean-Francois Moine wrote:
On Thu, 16 May 2013 20:25:10 +0100
Russell King - ARM Linux wrote:
What follows is my DRM driver for Dove, which I've been working on with
the Solid-run Cubox, which only offers HDMI output via the TDA19988
chip.
...
- device tree
Our driver d
This adds a video card node required for rmk's dove_drm driver. Reg
property matches reserved memory region (currently 16M at top of memory),
clocks property should carry extclk0 for now.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Cc
This adds device tree nodes for the lcd controllers found on Marvell
Dove SoCs. For now, there is no DT documentation and clocks property
should refer to clock connected to extclk0 pin.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Cc: dri
This RFC adds DT support to the DRM driver for Marvell Dove SoCs
posted by Russell King recently. For those booting DT with appended
ATAGs, remember to reduce probed memory by passing mem=1008M as
kernel parameter.
There was an include missing in Russell's RFC that is also added.
Seba
This adds OF support for the Dove DRM driver recently posted as RFC by
Russell King.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Cc: dri-devel@lists.freedesktop.org
Cc: Jason Cooper
Cc: Jean-Francois Moine
---
drivers/gpu/drm/dove
The RFC sent by Russell King was missing an include for tda998x. This
is just a compatible clone to remember Russell to add that later.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Cc: dri-devel@lists.freedesktop.org
Cc: Jason Cooper
Cc
On 05/18/2013 07:45 PM, Jean-Francois Moine wrote:
On Sat, 18 May 2013 19:12:18 +0200
Sebastian Hesselbarth wrote:
This adds OF support for the Dove DRM driver recently posted as RFC by
Russell King.
...
Jean-Francois,
one thing first: It is an RFC! It is to allow you to _test_ rmk&#
On 05/18/2013 07:46 PM, Jean-Francois Moine wrote:
On Sat, 18 May 2013 19:12:19 +0200
Sebastian Hesselbarth wrote:
The RFC sent by Russell King was missing an include for tda998x. This
is just a compatible clone to remember Russell to add that later.
Signed-off-by: Sebastian Hesselbarth
On 05/18/2013 07:33 PM, Jean-Francois Moine wrote:
On Sat, 18 May 2013 19:12:17 +0200
Sebastian Hesselbarth wrote:
This adds a video card node required for rmk's dove_drm driver. Reg
property matches reserved memory region (currently 16M at top of memory),
clocks property should carry ex
On 05/18/2013 08:58 PM, Jean-Francois Moine wrote:
On Sat, 18 May 2013 14:23:19 -0400
Rob Clark wrote:
These parameters should not be there. It seems to me that the DT is the
right place.
You might not want to directly have a hard DT dependency in tda998x,
as the encoder could be used on non
On 05/18/2013 10:26 PM, Russell King - ARM Linux wrote:
On Sat, May 18, 2013 at 09:30:09PM +0200, Sebastian Hesselbarth wrote:
The device for tda998x yes, but not the driver. Anyway, Russel decided
to have tda998x probed by his drm_driver.
For the simple reason that _that_ is how DRM slave
On 05/19/2013 08:01 AM, Jean-Francois Moine wrote:
On Sat, 18 May 2013 21:30:09 +0200
Sebastian Hesselbarth wrote:
So in the end, we will have a DT node for the HW controllers found
in Dove SoCs, a node for TDA998x, and a node for the video card, i.e.
_how_ lcd controllers, external encoders
handling is done threaded with a
workqueue to notify drm backend of HPD events.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Russell King
Cc: Rob Clark
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
This patch currently is based on top
On 05/19/2013 10:45 PM, Russell King - ARM Linux wrote:
On Sun, May 19, 2013 at 06:49:22PM +0200, Sebastian Hesselbarth wrote:
This adds an irq handler for HPD to the tda998x slave encoder driver
to trigger HPD change instead of polling. The gpio connected to int
pin of tda998x is passed
On 06/09/2013 09:32 PM, Russell King wrote:
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
---
Russell, Rob,
I have patches fixing TDA998x sync generation for p
On 06/09/13 21:29, Russell King wrote:
This patch adds support for the pair of LCD controllers on the Marvell
Armada 510 SoCs. This driver supports:
- multiple contiguous scanout buffers for video and graphics
- shm backed cacheable buffer objects for X pixmaps for Vivante GPU
acceleration
-
instead of registering a new device.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Russell King - ARM Linux
Cc: Darren Etheridge
Cc: linux-arm-ker...@lists.infradead.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/drm_encoder_slave.c
This fixes the wrong sync generation and sync calculation. It has only
been tested for progressive modes. Sync timings for a bunch of modes
have also been verified with an oscilloscope near-end (TDA998x input)
and far-end (DVI receiver output).
Signed-off-by: Sebastian Hesselbarth
---
Note: This
On 06/10/2013 11:48 PM, Russell King - ARM Linux wrote:
On Mon, Jun 10, 2013 at 01:10:18PM +0200, Sebastian Hesselbarth wrote:
On 06/09/13 21:29, Russell King wrote:
+static const struct armada_output_type armada_drm_conn_slave = {
+ .connector_type = DRM_MODE_CONNECTOR_HDMIA,
For a
This fixes the wrong sync generation and sync calculation for progressive
and interlaced modes. Sync timings for a bunch of modes have also been verified
with an oscilloscope near-end (TDA998x input) and far-end (DVI receiver output).
Signed-off-by: Sebastian Hesselbarth
---
Note: This patch is
This fixes the wrong sync generation and sync calculation for progressive
and interlaced modes. Sync timings for a bunch of modes have also been verified
with an oscilloscope near-end (TDA998x input) and far-end (DVI receiver output).
Signed-off-by: Sebastian Hesselbarth
---
Note: This patch is
On 06/11/13 09:24, Daniel Vetter wrote:
On Mon, Jun 10, 2013 at 11:23:42PM +0200, Sebastian Hesselbarth wrote:
Current DRM slave encoder API conflicts with auto-registration of i2c client
when using DT probed clients. To allow DRM slave encoders passed by DT, this
patch adds a check to
On 06/11/2013 05:10 PM, Francisco Jerez wrote:
Sebastian Hesselbarth writes:
- I think we could also drop the call to ->set_config since presumably an
of-enabled driver grabbed any required info already from the dt.
[...]
I think this way we could still share encoder slaves across t
This fixes the wrong sync generation and sync calculation. It has only
been tested for progressive and interlaced modes. Sync timings for a
bunch of modes have also been verified with an oscilloscope near-end
(TDA998x input) and far-end (DVI receiver output).
Signed-off-by: Sebastian Hesselbarth
On 06/20/2013 10:06 PM, Russell King - ARM Linux wrote:
On Thu, Jun 20, 2013 at 09:46:03PM +0200, Sebastian Hesselbarth wrote:
+ ref_pix = 3 + mode->hsync_start - mode->hdisplay;
+ de_pix_s = mode->htotal - mode->hdisplay;
+ de_pix_e = de_pix_s + mo
On 06/29/2013 05:06 PM, Daniel Drake wrote:
On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
wrote:
Sure... lets add some background info first: the big problem here is the
completely different register layouts for the clock register:
On Armada 510:
31:30 - select the clock input fro
On 06/29/2013 08:45 PM, Russell King - ARM Linux wrote:
On Sat, Jun 29, 2013 at 05:58:26PM +0200, Sebastian Hesselbarth wrote:
On 06/29/2013 05:06 PM, Daniel Drake wrote:
On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
wrote:
Sure... lets add some background info first: the big
On 07/01/13 02:01, Dave Airlie wrote:
how about instead of writing:
"However, at least I've taken the time to_think_ about what I'm doing
and realise that there_is_ scope here for the DRM core to improve,
rather than burying this stuff deep inside my driver like everyone else
has. That's no re
On 07/01/13 11:42, Daniel Vetter wrote:
On Mon, Jul 01, 2013 at 10:52:03AM +0200, Sebastian Hesselbarth wrote:
at least on this point I do share Russell's impression. I've sent
bunch of patches improving TDA998x and DRM+DT:
- TDA998x irq handling - ignored
- TDA998x sync fix - ignored
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
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/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/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/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/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 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 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: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 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 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/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 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 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 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
w
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/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/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/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 wrote:
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
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
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 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 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 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/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/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
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
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
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
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 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
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
1 - 100 of 167 matches
Mail list logo
