On Wed, Nov 14, 2012 at 12:10:15PM +0100, Steffen Trumtrar wrote:
On Wed, Nov 14, 2012 at 12:02:15PM +0100, Thierry Reding wrote:
On Wed, Nov 14, 2012 at 11:59:25AM +0100, Steffen Trumtrar wrote:
On Wed, Nov 14, 2012 at 11:56:34AM +0100, Thierry Reding wrote:
On Mon, Nov 12, 2012 at 04
On Wed, Nov 14, 2012 at 12:43:19PM +0100, Steffen Trumtrar wrote:
[...]
+display-timings bindings
+
+
+display timings node
I didn't express myself very clearly here =). The way I think this
should be written is display-timings node.
+required properties:
+ -
On Wed, Nov 14, 2012 at 12:43:18PM +0100, Steffen Trumtrar wrote:
[...]
diff --git a/include/linux/videomode.h b/include/linux/videomode.h
[...]
+int videomode_from_timing(struct display_timings *disp, struct videomode *vm,
+ unsigned int index);
+#endif
Nit: should have
On Wed, Nov 14, 2012 at 12:43:19PM +0100, Steffen Trumtrar wrote:
[...]
+optional properties:
+ - native-mode: the native mode for the display, in case multiple modes are
+ provided. When omitted, assume the first node is the native.
I forgot: The first sentence in this description
On Wed, Nov 14, 2012 at 12:43:20PM +0100, Steffen Trumtrar wrote:
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/fbmon.c | 38 ++
include/linux/fb.h
On Wed, Nov 14, 2012 at 12:43:21PM +0100, Steffen Trumtrar wrote:
[...]
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
[...]
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static void dump_fb_videomode(struct fb_videomode *m)
static inline?
Thierry
pgpjEMXjaOx0a.pgp
Description: PGP
On Wed, Nov 14, 2012 at 12:43:22PM +0100, Steffen Trumtrar wrote:
[...]
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
[...]
@@ -504,6 +505,41 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int
vdisplay, int vrefresh,
}
EXPORT_SYMBOL(drm_gtf_mode);
+#if
On Wed, Nov 14, 2012 at 12:43:23PM +0100, Steffen Trumtrar wrote:
[...]
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+#endif
/**
Nit: there should be a blank line between the last two.
Thierry
pgpTTm3RVeMhV.pgp
Description: PGP signature
On Mon, Nov 12, 2012 at 04:37:01PM +0100, Steffen Trumtrar wrote:
[...]
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..2a23b18 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -33,6 +33,12 @@ config VIDEO_OUTPUT_CONTROL
This framework adds
On Mon, Nov 12, 2012 at 04:37:02PM +0100, Steffen Trumtrar wrote:
This adds support for reading display timings from DT or/and convert one of
those
timings to a videomode.
The of_display_timing implementation supports multiple children where each
property can have up to 3 values. All
On Mon, Nov 12, 2012 at 04:37:03PM +0100, Steffen Trumtrar wrote:
[...]
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int videomode_to_fb_videomode(struct videomode *vm, struct fb_videomode
*fbmode)
The other helpers are named destination-type_from_source-type(),
maybe this should follow that example
On Mon, Nov 12, 2012 at 04:37:04PM +0100, Steffen Trumtrar wrote:
[...]
diff --git a/include/linux/fb.h b/include/linux/fb.h
[...]
+extern int of_get_fb_videomode(struct device_node *np, struct fb_videomode
*fb, int index);
Similarily this should get a dummy for the !CONFIG_OF_VIDEOMODE case,
On Mon, Nov 12, 2012 at 04:37:05PM +0100, Steffen Trumtrar wrote:
[...]
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
[...]
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int videomode_to_display_mode(struct videomode *vm, struct drm_display_mode
*dmode)
This one as well may be
On Mon, Nov 12, 2012 at 04:37:06PM +0100, Steffen Trumtrar wrote:
[...]
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static void dump_drm_displaymode(struct drm_display_mode *m)
+{
+ pr_debug(drm_displaymode = %d %d %d %d %d %d %d %d %d\n,
+ m-hdisplay, m-hsync_start, m-hsync_end,
On Tue, Nov 13, 2012 at 10:46:53AM -0700, Stephen Warren wrote:
On 11/13/2012 04:08 AM, Thierry Reding wrote:
On Mon, Nov 12, 2012 at 04:37:02PM +0100, Steffen Trumtrar wrote:
This adds support for reading display timings from DT or/and
convert one of those timings to a videomode
On Tue, Nov 13, 2012 at 08:13:31AM -1000, Mitch Bradley wrote:
On 11/13/2012 7:51 AM, Thierry Reding wrote:
On Tue, Nov 13, 2012 at 10:46:53AM -0700, Stephen Warren wrote:
On 11/13/2012 04:08 AM, Thierry Reding wrote:
On Mon, Nov 12, 2012 at 04:37:02PM +0100, Steffen Trumtrar wrote
On Wed, Oct 31, 2012 at 10:28:08AM +0100, Steffen Trumtrar wrote:
[...]
+/**
+ * of_get_drm_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings
On Wed, Oct 31, 2012 at 10:28:01AM +0100, Steffen Trumtrar wrote:
[...]
+void timings_release(struct display_timings *disp)
+{
+ int i;
+
+ for (i = 0; i disp-num_timings; i++)
+ kfree(disp-timings[i]);
+}
+
+void display_timings_release(struct display_timings *disp)
On Wed, Oct 31, 2012 at 10:28:02AM +0100, Steffen Trumtrar wrote:
[...]
diff --git a/Documentation/devicetree/bindings/video/display-timings.txt
b/Documentation/devicetree/bindings/video/display-timings.txt
[...]
@@ -0,0 +1,139 @@
+display-timings bindings
+==
+
On Wed, Oct 31, 2012 at 10:28:03AM +0100, Steffen Trumtrar wrote:
[...]
+config OF_VIDEOMODE
+ def_bool y
+ depends on VIDEOMODE
+ help
+ helper to get videomodes from the devicetree
+
I think patches 3 and 4 need to be swapped, since patch 4 introduces the
VIDEOMODE
On Sun, Oct 07, 2012 at 03:38:33PM +0200, Laurent Pinchart wrote:
Hi Steffen,
On Friday 05 October 2012 17:51:21 Steffen Trumtrar wrote:
On Thu, Oct 04, 2012 at 12:51:00PM -0600, Stephen Warren wrote:
On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
Get videomode from devicetree in a
On Tue, Oct 09, 2012 at 09:26:08AM +0200, Steffen Trumtrar wrote:
Hi Laurent,
On Mon, Oct 08, 2012 at 10:52:04PM +0200, Laurent Pinchart wrote:
Hi Steffen,
On Monday 08 October 2012 14:48:01 Steffen Trumtrar wrote:
On Mon, Oct 08, 2012 at 02:13:50PM +0200, Laurent Pinchart wrote:
On Thu, Oct 04, 2012 at 07:59:19PM +0200, Steffen Trumtrar wrote:
[...]
diff --git a/include/linux/of_display_timings.h
b/include/linux/of_display_timings.h
new file mode 100644
index 000..1ad719e
--- /dev/null
+++ b/include/linux/of_display_timings.h
@@ -0,0 +1,85 @@
+/*
+ *
On Thu, Oct 04, 2012 at 07:59:20PM +0200, Steffen Trumtrar wrote:
[...]
diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
[...]
+#if defined(CONFIG_DRM)
This should be:
#if IS_ENABLED(CONFIG_DRM)
or the code below won't be included if DRM is built as a module. But see
On Mon, Oct 15, 2012 at 04:17:51PM +0200, Steffen Trumtrar wrote:
Hi Leela,
On Mon, Oct 15, 2012 at 04:24:43PM +0530, Leela Krishna Amudala wrote:
Hello Steffen,
To which version of the kernel we can expect this patch set to be merged
into?
Because I'm waiting for this from long
On Thu, Oct 04, 2012 at 07:59:19PM +0200, Steffen Trumtrar wrote:
[...]
diff --git a/include/linux/of_display_timings.h
b/include/linux/of_display_timings.h
[...]
+struct display_timings {
+ unsigned int num_timings;
+ unsigned int default_timing;
+
+ struct signal_timing
On Mon, Oct 08, 2012 at 09:49:21AM +0200, Steffen Trumtrar wrote:
On Mon, Oct 08, 2012 at 10:07:45AM +0300, Tomi Valkeinen wrote:
On Thu, 2012-10-04 at 19:59 +0200, Steffen Trumtrar wrote:
[...]
+
+ disp-num_timings = 0;
+
+ for_each_child_of_node(timings_np, entry) {
+
);
ir-pwled = 0;
+ rc_unregister_device(ir-rc);
kfree(ir);
dev-ir = NULL;
--
1.7.8.4
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
pgpKQJqA04XGG.pgp
Description: PGP signature
* Thierry Reding wrote:
* Mauro Carvalho Chehab wrote:
That means that all we need is to get rid of TM6000_QUIRK_NO_USB_DELAY.
I've just reviewed my patches again and it seems that no-USB-delay quirk
patch was only partially applied. The actual location where it was introduced
The original patch used the fast USB quirk to enable fast access to
registers in the tm6000_read_write_usb(). The applied patch moved the
check to the tm6000_reset(), probably due to some merge conflicts.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/media/video
Function parameters on subsequent lines should never be aligned with the
function name but rather be indented.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/media/video/tm6000/tm6000-video.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git
Checking for dev-int_in is useless because it returns the address of
the embedded struct tm6000_endpoint, which will always be positive and
therefore true.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/media/video/tm6000/tm6000-input.c |2 +-
drivers/media/video
* Antti Palosaari wrote:
That question is related to that kind of indentation generally, not
only that patch.
On 12/06/2011 03:39 PM, Thierry Reding wrote:
Function parameters on subsequent lines should never be aligned with the
function name but rather be indented
* Mauro Carvalho Chehab wrote:
On 05-12-2011 05:21, Thierry Reding wrote:
* linu...@stefanringel.de wrote:
From: Stefan Ringellinu...@stefanringel.de
Signed-off-by: Stefan Ringellinu...@stefanringel.de
Your commit message needs more details. Why do you think this is a bugfix?
Also
* Mauro Carvalho Chehab wrote:
That means that all we need is to get rid of TM6000_QUIRK_NO_USB_DELAY.
I've just reviewed my patches again and it seems that no-USB-delay quirk
patch was only partially applied. The actual location where it was introduced
was in tm6000_read_write_usb() to allow
* linu...@stefanringel.de wrote:
From: Stefan Ringel linu...@stefanringel.de
Signed-off-by: Stefan Ringel linu...@stefanringel.de
Your commit message needs more details. Why do you think this is a bugfix?
Also this commit seems to effectively revert (and then partially reimplement)
a patch
* Mauro Carvalho Chehab wrote:
Em 01-09-2011 02:24, Thierry Reding escreveu:
* Mauro Carvalho Chehab wrote:
Em 31-08-2011 17:53, Mauro Carvalho Chehab escreveu:
Em 04-08-2011 04:14, Thierry Reding escreveu:
When the last user closes the device, perform a lightweight reset of the
device
* Andrew Goff wrote:
Hi Thierry,
I have been having problems with the radio tuner in my leadtek 1800h
card. This card has the xc2028 tuner. Using fmtools i would get an
error message similar to - frequency out of range 0.0 - 0.0.
After seeing you patches at the beginning of last month I
* Mauro Carvalho Chehab wrote:
Em 01-09-2011 02:19, Thierry Reding escreveu:
* Mauro Carvalho Chehab wrote:
Em 04-08-2011 04:14, Thierry Reding escreveu:
Instead of selecting the default interface setting when preparing
isochronous transfers, select it on the first call to open() to make
Some devices support fast access to registers using the USB interface
while others require a certain delay after each operation. This commit
adds a quirk that can be enabled by devices that don't need the delay.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/staging
The Cinergy Hybrid cards are known not to need an artificial delay after
USB accesses so the quirk can safely be enabled.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/staging/tm6000/tm6000-cards.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions
* Thierry Reding wrote:
Some devices support fast access to registers using the USB interface
while others require a certain delay after each operation. This commit
adds a quirk that can be enabled by devices that don't need the delay.
Signed-off-by: Thierry Reding thierry.red...@avionic
The Cinergy Hybrid cards are known not to need an artificial delay after
USB accesses so the quirk can safely be enabled.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/staging/tm6000/tm6000-cards.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions
Some devices support fast access to registers using the USB interface
while others require a certain delay after each operation. This commit
adds a quirk that can be enabled by devices that don't need the delay.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/staging
* Mauro Carvalho Chehab wrote:
Hi Thierry,
Em 04-08-2011 04:13, Thierry Reding escreveu:
This patch series fixes up some issues with the tm6000 driver. These
patches were tested with a Cinergy Hybrid XE which is the only one I
have access to, so it would be nice if someone with access
* Mauro Carvalho Chehab wrote:
Em 04-08-2011 04:14, Thierry Reding escreveu:
The TM6010 supports much larger I2C transfers than currently specified.
In fact the Windows driver seems to use 81 bytes per packet by default.
This commit improves the speed of firmware loading a bit
* Mauro Carvalho Chehab wrote:
Em 04-08-2011 04:14, Thierry Reding escreveu:
In radio mode, no frequency offset is needed. While at it, split off the
frequency offset computation for digital TV into a separate function.
Nah, it is better to keep the offset calculation
* Mauro Carvalho Chehab wrote:
Em 04-08-2011 04:14, Thierry Reding escreveu:
---
drivers/staging/tm6000/tm6000-core.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index
* Mauro Carvalho Chehab wrote:
Em 04-08-2011 04:14, Thierry Reding escreveu:
Instead of selecting the default interface setting when preparing
isochronous transfers, select it on the first call to open() to make
sure it is available earlier.
Hmm... I fail to see what this is needed
* Mauro Carvalho Chehab wrote:
Em 31-08-2011 17:53, Mauro Carvalho Chehab escreveu:
Em 04-08-2011 04:14, Thierry Reding escreveu:
When the last user closes the device, perform a lightweight reset of the
device to bring it into a well-known state.
Note that this is not always enough
, so I have high hopes that
it's also fixed.
Thierry Reding (21):
[media] tuner/xc2028: Add I2C flush callback.
[media] tuner/xc2028: Fix frequency offset for radio mode.
[staging] tm6000: Miscellaneous cleanups.
[staging] tm6000: Use correct input in radio mode.
[staging] tm6000: Implement
In radio mode, no frequency offset is needed. While at it, split off the
frequency offset computation for digital TV into a separate function.
---
drivers/media/common/tuners/tuner-xc2028.c | 137 +++-
1 files changed, 75 insertions(+), 62 deletions(-)
diff --git
In radio mode, the correct input is rinput. The pseudo index 5 is used
but cannot be used to index the vinput array because that only has 3
elements.
---
drivers/staging/tm6000/tm6000-stds.c | 28 +++-
1 files changed, 15 insertions(+), 13 deletions(-)
diff --git
This commit fixes a number of coding style issues as well as some issues
reported by checkpatch and sparse.
---
drivers/staging/tm6000/tm6000-alsa.c |4 +-
drivers/staging/tm6000/tm6000-cards.c | 18 ++---
drivers/staging/tm6000/tm6000-core.c | 17 ++---
---
drivers/staging/tm6000/tm6000-core.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index e14bd3d..2c156dd 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++
When loading the firmware, complete each chunk by sending an I2C flush
command to the frontend. Some devices like the tm6000 seem to require
this to properly flush the I2C buffers.
The current code in tm6000 executes the flush command once after each
I2C transfer, which slows down the firmware
This brings the IRQ callback implementation more in line with how other
drivers do it.
---
drivers/staging/tm6000/tm6000-video.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-video.c
b/drivers/staging/tm6000/tm6000-video.c
---
drivers/staging/tm6000/tm6000-cards.c |5 +
drivers/staging/tm6000/tm6000-i2c.c |5 -
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 202f454..c3b84c9 100644
---
The TM6010 supports much larger I2C transfers than currently specified.
In fact the Windows driver seems to use 81 bytes per packet by default.
This commit improves the speed of firmware loading a bit.
---
drivers/staging/tm6000/tm6000-cards.c |1 +
drivers/staging/tm6000/tm6000-i2c.c |
The register ACTIVE_VIDEO_IF register should be named ACTIVE_IF since it
controls more than just the video interface.
---
drivers/staging/tm6000/tm6000-alsa.c |4 ++--
drivers/staging/tm6000/tm6000-core.c | 12 ++--
drivers/staging/tm6000/tm6000-regs.h |4 +++-
3 files changed,
Video data is useless in radio mode, so the corresponding interface can
be safely disabled. This should reduce the amount of isochronous traffic
noticeably.
---
drivers/staging/tm6000/tm6000-core.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git
This commit introduces the usb_lock mutex to ensure that a USB request
always gets the proper response. While this is currently not really
necessary it will become important as there are more users.
---
drivers/staging/tm6000/tm6000-cards.c |1 +
drivers/staging/tm6000/tm6000-core.c |3
This commit uses sentinel entries to terminate the TV standard register
tables instead of hard-coding their size, allowing further entries to be
added more easily. It is also more space-efficient if the tables have a
varying number of entries.
---
drivers/staging/tm6000/tm6000-stds.c | 610
When the USB device is disconnected, the device usage bit is not cleared
properly. This leads to errors when a device is unplugged and replugged
several times until all TM6000_MAXBOARDS bits are used and keeps the
driver from binding to the device.
---
drivers/staging/tm6000/tm6000-cards.c |5
Instead of selecting the default interface setting when preparing
isochronous transfers, select it on the first call to open() to make
sure it is available earlier.
---
drivers/staging/tm6000/tm6000-video.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git
When the last user closes the device, perform a lightweight reset of the
device to bring it into a well-known state.
Note that this is not always enough with the TM6010, which sometimes
needs a hard reset to get into a working state again.
---
drivers/staging/tm6000/tm6000-core.c | 43
This fixes a memory leak where isochronous buffers would be set up for
each video buffer, while it is sufficient to set them up only once per
device.
---
drivers/staging/tm6000/tm6000-video.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git
---
drivers/staging/tm6000/tm6000-stds.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-stds.c
b/drivers/staging/tm6000/tm6000-stds.c
index f44451b..9a4145d 100644
--- a/drivers/staging/tm6000/tm6000-stds.c
+++
When releasing hardware resources, the DMA buffer allocated to the PCM
device needs to be freed to prevent a memory leak.
---
drivers/staging/tm6000/tm6000-alsa.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-alsa.c
If the radio device is opened there is no need to initialize the video
buffer queue because it is not used.
---
drivers/staging/tm6000/tm6000-video.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-video.c
---
drivers/staging/tm6000/tm6000-cards.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 94fd138..ab3aa2c 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++
Implicitly setting the tuner frequency each time the device is opened
seems no longer necessary, so it is removed. This speeds up opening the
device by about 120 ms.
It also avoids excessive firmware reloads because the default will load
the BASE and F8MHZ type firmwares independent of which
Hi,
I have a piece of software that uses libvlc to playback analog video using
V4L2. When stress-testing the software by repeatedly starting and stopping
playback, the device I use (TerraTec Cinergy Hybrid Stick [0ccd:00a5]) goes
into a very strange state, where it hangs when dequeuing a buffer.
101 - 173 of 173 matches
Mail list logo
