Re: [Linaro-mm-sig] [PATCH 11/15] mm: trigger page reclaim in alloc_contig_range() to stabilize watermarks
On Wed, 08 Feb 2012 03:04:18 +0100, sandeep patil psandee...@gmail.com wrote: There's another problem I am facing with zone watermarks and CMA. Test details: Memory : 480 MB of total memory, 128 MB CMA region Test case : around 600 MB of file transfer over USB RNDIS onto target System Load : ftpd with console running on target. No one is doing CMA allocations except for the DMA allocations done by the drivers. Result : After about 300MB transfer, I start getting GFP_ATOMIC allocation failures. This only happens if CMA region is reserved. [...] Total memory available is way above the zone watermarks. So, we ended up starving UNMOVABLE/RECLAIMABLE atomic allocations that cannot fallback on CMA region. This looks like something Mel warned me about. I don't really have a good solution for that yet. ;/ -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [trivial] mantis: Fix typo in mantis_hif.c
Correct typo Adater to Adapter in
drivers/media/dvb/mantis/mantis_hif.c
Signed-off-by: Masanari Iida standby2...@gmail.com
---
drivers/media/dvb/mantis/mantis_hif.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/mantis/mantis_hif.c
b/drivers/media/dvb/mantis/mantis_hif.c
index 672cf4d..10c68df 100644
--- a/drivers/media/dvb/mantis/mantis_hif.c
+++ b/drivers/media/dvb/mantis/mantis_hif.c
@@ -76,7 +76,7 @@ static int mantis_hif_write_wait(struct mantis_ca *ca)
udelay(500);
timeout++;
if (timeout 100) {
- dprintk(MANTIS_ERROR, 1, Adater(%d) Slot(0): Write
operation timed out!, mantis-num);
+ dprintk(MANTIS_ERROR, 1, Adapter(%d) Slot(0): Write
operation timed out!, mantis-num);
rc = -ETIMEDOUT;
break;
}
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] -EINVAL - -ENOTTY
I found one more place where -EINVAL is used instead of -ENOTTY:
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Note that drivers/media/dvb/dvb-core/dvbdev.c has the same code, but as far as
I can tell DVB is still using -EINVAL for unknown ioctls so I didn't change
that.
Regards,
Hans
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index d0d7281..52657fd 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -2421,7 +2421,7 @@ video_usercopy(struct file *file, unsigned int cmd,
unsigned long arg,
/* Handles IOCTL */
err = func(file, cmd, parg);
if (err == -ENOIOCTLCMD)
- err = -EINVAL;
+ err = -ENOTTY;
if (has_array_args) {
*kernel_ptr = user_ptr;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Issue with Afatech AF9015 DVB-T USB
Hello I am currently trying to use Afatech AF9015 DVB-T USB card. Generaly it is working fine on my PC and MIPS SoC. Except one part which is currently blocking me: Currently I am trying to record whole TS using dvbsnoop or dvbstream tool. It seems that I am unable to stream whole TS using following cmd: dvbstream 8192 Also: dvbsnoop -s ts -tsraw -crc does not work. It seems that dvbsnoop is blocked in read ... I make quick check and it seems that DVB_USB_ADAP_HAS_PID_FILTER is enabled for this card. Has anyone succeeded in making Afatech card working in necessary mode? Thanks in advance MD -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with Afatech AF9015 DVB-T USB
On 08.02.2012 14:24, Mile Davidović wrote: Hello I am currently trying to use Afatech AF9015 DVB-T USB card. Generaly it is working fine on my PC and MIPS SoC. Except one part which is currently blocking me: Currently I am trying to record whole TS using dvbsnoop or dvbstream tool. It seems that I am unable to stream whole TS using following cmd: dvbstream 8192 dvbstream -f 666000 -o 8192 stream.ts Also: dvbsnoop -s ts -tsraw -crc does not work. It seems that dvbsnoop is blocked in read ... I make quick check and it seems that DVB_USB_ADAP_HAS_PID_FILTER is enabled for this card. Has anyone succeeded in making Afatech card working in necessary mode? Thanks in advance MD regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] IT913X Version 1 and Version 2 keymaps
On 06.02.2012 19:06, Malcolm Priestley wrote:
On Mon, 2012-02-06 at 14:42 +0200, Antti Palosaari wrote:
On 02/02/2012 12:29 AM, Malcolm Priestley wrote:
IT913X V1 V2 keymaps
+static struct rc_map_table it913x_v1_rc[] = {
+ /* Type 1 */
That remote is already there. Use existing remote instead of adding new
one with different name. It is RC_MAP_MSI_DIGIVOX_III
The driver originally used this map.
RC_MAP_MSI_DIGIVOX_III and RC_MAP_KWORLD_315U also are the same map.
Yes it is. As you likely saw from the comments I have added:
/* This remote seems to be same as rc-kworld-315u.c. Anyhow, add new
remote since rc-kworld-315u.c lacks NEC extended address byte. */
The reason I was forced to add new keymap instead of fixing
RC_MAP_KWORLD_315U was simple I didn't have em28xx device to test and
fix it at that time. So I added new correct keymap. Fix should be done
for em28xx driver to handle 24bit NEC extended.
+ /* Type 2 - 20 buttons */
+ { 0x807f0d, KEY_0 },
+ { 0x807f0e, KEY_STOP },
That is NEC basic - 16 bit, not 24 bit. That remote seems to be here
also. It is RC_MAP_TERRATEC_SLIM_2. Use existing instead of define new.
All ITE NEC remotes are 32bit with 0xff00 mask. However, they are
modified to 24 bit or 16 bit.
That is wrong assumption. NEC sends always physically 32bit. Original
NEC is is still 16bit long as payload. Other 16bit are reduntant and are
used for checksum. If you XOR byte0 and byte1 you got 0xff. Same applies
for byte2 and byte3.
Using 0xff00 you give as example = 0xff XOR 0x00 = 0xFF.
And for remote in question, 0x80 XOR 7f = 0xFF.
The both maps need to merged because they share the same product ID.
Yes, thats tricky part. I still don't see idea to put all possible
remotes to one file. If you look AF9015 driver you can see same problem.
And maybe many others too. That was one reason for RC-core too. The idea
was to upload keytable from the userspace in that case.
+static struct rc_map_table it913x_v2_rc[] = {
+ /* Type 1 */
+ /* 9005 remote */
+ { 0x807f12, KEY_POWER2 }, /* Power (RED POWER BUTTON)*/
That is also 16 bit NEC basic.
This is a different map.
All the maps will soon need to be 32bit, HID type interfaces need the
32bit map uploaded.
It does not matter what HID wants. As those are simply checksums you can
calculate those easily in the driver. See af9015 for example. And some
other drivers too, IIRC DiBcom at least.
IMHO all NEC should be defined as full 32 bit code. I asked that many
times when RC-core was introduced and I was converting af9015 to
RC-core. But it is now differently, only payload bytes are defined to
the keytable and checksum bytes left out. That was spoken many times on
the mailing list. Try to search some discussion, af9015 + rc-core is
good starting point.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with Afatech AF9015 DVB-T USB
Thank You. Kind regards MD On Wed, Feb 8, 2012 at 2:33 PM, Antti Palosaari cr...@iki.fi wrote: On 08.02.2012 14:24, Mile Davidović wrote: Hello I am currently trying to use Afatech AF9015 DVB-T USB card. Generaly it is working fine on my PC and MIPS SoC. Except one part which is currently blocking me: Currently I am trying to record whole TS using dvbsnoop or dvbstream tool. It seems that I am unable to stream whole TS using following cmd: dvbstream 8192 dvbstream -f 666000 -o 8192 stream.ts Also: dvbsnoop -s ts -tsraw -crc does not work. It seems that dvbsnoop is blocked in read ... I make quick check and it seems that DVB_USB_ADAP_HAS_PID_FILTER is enabled for this card. Has anyone succeeded in making Afatech card working in necessary mode? Thanks in advance MD regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 11/15] mm: trigger page reclaim in alloc_contig_range() to stabilize watermarks
Hello,
On Friday, February 03, 2012 3:04 PM Mel Gorman wrote:
On Fri, Feb 03, 2012 at 01:18:54PM +0100, Marek Szyprowski wrote:
alloc_contig_range() performs memory allocation so it also should keep
track on keeping the correct level of memory watermarks. This commit adds
a call to *_slowpath style reclaim to grab enough pages to make sure that
the final collection of contiguous pages from freelists will not starve
the system.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
Tested-by: Rob Clark rob.cl...@linaro.org
Tested-by: Ohad Ben-Cohen o...@wizery.com
Tested-by: Benjamin Gaignard benjamin.gaign...@linaro.org
I still do not intend to ack this patch and any damage is confined to
CMA but I have a few comments anyway.
---
mm/page_alloc.c | 47 +++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 983ccba..371a79f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5632,6 +5632,46 @@ static int __alloc_contig_migrate_range(unsigned
long start, unsigned
long end)
return ret 0 ? 0 : ret;
}
+/*
+ * Trigger memory pressure bump to reclaim some pages in order to be able
to
+ * allocate 'count' pages in single page units. Does similar work as
+ *__alloc_pages_slowpath() function.
+ */
+static int __reclaim_pages(struct zone *zone, gfp_t gfp_mask, int count)
+{
+ enum zone_type high_zoneidx = gfp_zone(gfp_mask);
+ struct zonelist *zonelist = node_zonelist(0, gfp_mask);
+ int did_some_progress = 0;
+ int order = 1;
+ unsigned long watermark;
+
+ /*
+* Increase level of watermarks to force kswapd do his job
+* to stabilize at new watermark level.
+*/
+ min_free_kbytes += count * PAGE_SIZE / 1024;
There is a risk of overflow here although it is incredibly
small. Still, a potentially nicer way of doing this was
count (PAGE_SHIFT - 10)
+ setup_per_zone_wmarks();
+
Nothing prevents two or more processes updating the wmarks at the same
time which is racy and unpredictable. Today it is not much of a problem
but CMA makes this path hotter than it was and you may see weirdness
if two processes are updating zonelists at the same time. Swap-over-NFS
actually starts with a patch that serialises setup_per_zone_wmarks()
You also potentially have a BIG problem here if this happens
min_free_kbytes = 32768
Process a: min_free_kbytes += 65536
Process a: start direct reclaim
echo 16374 /proc/sys/vm/min_free_kbytes
Process a: exit direct_reclaim
Process a: min_free_kbytes -= 65536
min_free_kbytes now wraps negative and the machine hangs.
The damage is confined to CMA though so I am not going to lose sleep
over it but you might want to consider at least preventing parallel
updates to min_free_kbytes from proc.
Right. This approach was definitely too hacky. What do you think about
replacing
it with the following code (I assume that setup_per_zone_wmarks() serialization
patch will be merged anyway so I skipped it here):
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 82f4fa5..bb9ae41 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -371,6 +371,13 @@ struct zone {
/* see spanned/present_pages for more description */
seqlock_t span_seqlock;
#endif
+#ifdef CONFIG_CMA
+ /*
+* CMA needs to increase watermark levels during the allocation
+* process to make sure that the system is not starved.
+*/
+ unsigned long min_cma_pages;
+#endif
struct free_areafree_area[MAX_ORDER];
#ifndef CONFIG_SPARSEMEM
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 824fb37..1ca52f0 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5044,6 +5044,11 @@ void setup_per_zone_wmarks(void)
zone-watermark[WMARK_LOW] = min_wmark_pages(zone) + (tmp
2);
zone-watermark[WMARK_HIGH] = min_wmark_pages(zone) + (tmp
1);
+#ifdef CONFIG_CMA
+ zone-watermark[WMARK_MIN] += zone-min_cma_pages;
+ zone-watermark[WMARK_LOW] += zone-min_cma_pages;
+ zone-watermark[WMARK_HIGH] += zone-min_cma_pages;
+#endif
setup_zone_migrate_reserve(zone);
spin_unlock_irqrestore(zone-lock, flags);
}
@@ -5625,13 +5630,15 @@ static int __reclaim_pages(struct zone *zone, gfp_t
gfp_mask, int count)
struct zonelist *zonelist = node_zonelist(0, gfp_mask);
int did_some_progress = 0;
int order = 1;
- unsigned long watermark;
+ unsigned long watermark, flags;
/*
* Increase level of watermarks to force kswapd do his job
* to stabilize at new watermark level.
*/
- min_free_kbytes += count * PAGE_SIZE
[PATCH] media: davinci: added module.h to resolve unresolved macros
Included module.h explicitly to resolve the macros THIS_MODULE and MODULE_LICENSE. This avoids compilations errors as those defines were not declared. Signed-off-by: Henrique Camargo henri...@henriquecamargo.com Signed-off-by: Diogo Luvizon diogoluvi...@gmail.com --- drivers/media/video/davinci/isif.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/davinci/isif.c b/drivers/media/video/davinci/isif.c index 1e63852..5278fe7 100644 --- a/drivers/media/video/davinci/isif.c +++ b/drivers/media/video/davinci/isif.c @@ -34,6 +34,7 @@ #include linux/videodev2.h #include linux/clk.h #include linux/err.h +#include linux/module.h #include mach/mux.h -- 1.7.8.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] adding support for Xceive XC5000C tuner... | git://linuxtv.org/mkrufky/tuners xc5000
On Tue, Feb 7, 2012 at 12:56 AM, Michael Krufky mkru...@kernellabs.com wrote: On Tue, Feb 7, 2012 at 12:06 AM, Michael Krufky mkru...@kernellabs.com wrote: Please review / ack / merge: After speaking to Devin briefly on irc, I decided to make a few cleanups. The drivers don't actually need to specify a firmware file to the xc5000 driver at attach-time. Rather, it should specify the chip revision (if available) If unspecified, default to the XC5000A The following changes since commit 59b30294e14fa6a370fdd2bc2921cca1f977ef16: Mauro Carvalho Chehab (1): Merge branch 'v4l_for_linus' into staging/for_v3.4 are available in the git repository at: git://linuxtv.org/mkrufky/tuners xc5000 Michael Krufky (8): xc5000: allow drivers to set desired firmware in xc5000_attach xc5000: add XC5000C_DEFAULT_FIRMWARE: dvb-fe-xc5000c-41.024.5-31875.fw tuner: add support for Xceive XC5000C tveeprom: add support for Xceive XC5000C tuner remove unneeded #define's in xc5000.h xc5000: remove static dependencies on xc5000 created by previous changesets xc5000: drivers should specify chip revision rather than firmware xc5000: declare firmware configuration structures as static const drivers/media/common/tuners/tuner-types.c |4 ++ drivers/media/common/tuners/xc5000.c | 47 + drivers/media/common/tuners/xc5000.h |5 +++ drivers/media/video/tuner-core.c | 15 + drivers/media/video/tveeprom.c|2 +- include/media/tuner.h |1 + 6 files changed, 67 insertions(+), 7 deletions(-) Cheers, -Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Wed Feb 8 19:00:16 CET 2012 git hash:59b30294e14fa6a370fdd2bc2921cca1f977ef16 gcc version: i686-linux-gcc (GCC) 4.6.2 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 11/15] mm: trigger page reclaim in alloc_contig_range() to stabilize watermarks
2012/2/8 Michal Nazarewicz min...@mina86.com: On Wed, 08 Feb 2012 03:04:18 +0100, sandeep patil psandee...@gmail.com wrote: There's another problem I am facing with zone watermarks and CMA. Test details: Memory : 480 MB of total memory, 128 MB CMA region Test case : around 600 MB of file transfer over USB RNDIS onto target System Load : ftpd with console running on target. No one is doing CMA allocations except for the DMA allocations done by the drivers. Result : After about 300MB transfer, I start getting GFP_ATOMIC allocation failures. This only happens if CMA region is reserved. Total memory available is way above the zone watermarks. So, we ended up starving UNMOVABLE/RECLAIMABLE atomic allocations that cannot fallback on CMA region. This looks like something Mel warned me about. I don't really have a good solution for that yet. ;/ What if we have NR_FREE_CMA_PAGES in vmstat and use them to calculate __zone_watermark_ok()? However, it still doesn't solve the problem when we DON'T want to use NR_FREE_CMA_PAGES in case of MOVABLE allocations. Sandeep -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] tea575x-tuner improvements use in maxiradio
On Wednesday 08 February 2012 08:29:25 Hans Verkuil wrote:
On Tuesday, February 07, 2012 23:20:19 Ondrej Zary wrote:
On Sunday 05 February 2012 14:17:05 Hans Verkuil wrote:
These patches improve the tea575x-tuner module to make it up to date
with the latest V4L2 frameworks.
The maxiradio driver has also been converted to use the tea575x-tuner
and I've used that card to test it.
Unfortunately, this card can't read the data pin, so the new hardware
seek functionality has been tested only partially (yes, it seeks, but
when it finds a channel I can't read back the frequency).
Ondrej, are you able to test these patches for the sound cards that use
this tea575x tuner?
Note that these two patches rely on other work that I did and that
hasn't been merged yet. So it is best to pull from my git tree:
http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/radi
o-pc i2
You can use the v4l-utils repository
(http://git.linuxtv.org/v4l-utils.git) to test the drivers: the
v4l2-compliance test should succeed and with v4l2-ctl you can test the
hardware seek:
To seek down:
v4l2-ctl -d /dev/radio0 --freq-seek=dir=0
To seek up:
v4l2-ctl -d /dev/radio0 --freq-seek=dir=1
To do the compliance test:
v4l2-compliance -r /dev/radio0
It seems to work (tested with SF64-PCR - snd_fm801) but the seek is
severely broken. Reading the frequency immediately after seek does not
work, it always returns the old value (haven't found a delay that works).
Reading it later (copied back snd_tea575x_get_freq function) works. The
chip seeks randomly up or down, ignoring UP/DOWN flag and often stops at
wrong place (only noise) or even outside the FM range.
So I strongly suggest not to enable this (mis-)feature. The HW seems to
be completely broken (unless there's some weird bug in the code).
Well, it seemed like a good idea at the time :-) I'll remove this
'feature', it's really not worth our time to try and make this work for
these old cards.
I wonder if you are able to test the ISA radio-sf16fmr2.c driver? I'm not
sure if you have the hardware, but since I changed this driver to use the
proper isa kernel framework I'd like to have this tested if possible.
The driver works, provided that linux/slab.h is included. It oopses on rmmod
because dev_set_drvdata() call is missing from init.
This patch fixes all of that and also removes (now useless) static fmr2_card:
--- a/drivers/media/radio/radio-sf16fmr2.c
+++ b/drivers/media/radio/radio-sf16fmr2.c
@@ -9,6 +9,7 @@
#include linux/delay.h
#include linux/module.h /* Modules */
#include linux/init.h/* Initdata */
+#include linux/slab.h
#include linux/ioport.h /* request_region */
#include linux/io.h /* outb, outb_p */
#include linux/isa.h
@@ -32,7 +33,6 @@ struct fmr2 {
/* the port is hardwired so no need to support multiple cards */
#define FMR2_PORT 0x384
-static struct fmr2 fmr2_card;
/* TEA575x tuner pins */
#define STR_DATA (1 0)
@@ -188,7 +188,7 @@ static int fmr2_tea_ext_init(struct snd_tea575x *tea)
static int __init fmr2_probe(struct device *pdev, unsigned int dev)
{
- struct fmr2 *fmr2 = fmr2_card;
+ struct fmr2 *fmr2;
int err;
fmr2 = kzalloc(sizeof(*fmr2), GFP_KERNEL);
@@ -229,6 +229,7 @@ static int __init fmr2_probe(struct device *pdev, unsigned
int dev)
}
printk(KERN_INFO radio-sf16fmr2: SF16-FMR2 radio card at 0x%x.\n,
fmr2-io);
+ dev_set_drvdata(pdev, fmr2);
return 0;
}
--
Ondrej Zary
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] tea575x-tuner improvements use in maxiradio
On Wednesday, February 08, 2012 20:57:43 Ondrej Zary wrote:
On Wednesday 08 February 2012 08:29:25 Hans Verkuil wrote:
On Tuesday, February 07, 2012 23:20:19 Ondrej Zary wrote:
On Sunday 05 February 2012 14:17:05 Hans Verkuil wrote:
These patches improve the tea575x-tuner module to make it up to date
with the latest V4L2 frameworks.
The maxiradio driver has also been converted to use the tea575x-tuner
and I've used that card to test it.
Unfortunately, this card can't read the data pin, so the new hardware
seek functionality has been tested only partially (yes, it seeks, but
when it finds a channel I can't read back the frequency).
Ondrej, are you able to test these patches for the sound cards that use
this tea575x tuner?
Note that these two patches rely on other work that I did and that
hasn't been merged yet. So it is best to pull from my git tree:
http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/radi
o-pc i2
You can use the v4l-utils repository
(http://git.linuxtv.org/v4l-utils.git) to test the drivers: the
v4l2-compliance test should succeed and with v4l2-ctl you can test the
hardware seek:
To seek down:
v4l2-ctl -d /dev/radio0 --freq-seek=dir=0
To seek up:
v4l2-ctl -d /dev/radio0 --freq-seek=dir=1
To do the compliance test:
v4l2-compliance -r /dev/radio0
It seems to work (tested with SF64-PCR - snd_fm801) but the seek is
severely broken. Reading the frequency immediately after seek does not
work, it always returns the old value (haven't found a delay that works).
Reading it later (copied back snd_tea575x_get_freq function) works. The
chip seeks randomly up or down, ignoring UP/DOWN flag and often stops at
wrong place (only noise) or even outside the FM range.
So I strongly suggest not to enable this (mis-)feature. The HW seems to
be completely broken (unless there's some weird bug in the code).
Well, it seemed like a good idea at the time :-) I'll remove this
'feature', it's really not worth our time to try and make this work for
these old cards.
I wonder if you are able to test the ISA radio-sf16fmr2.c driver? I'm not
sure if you have the hardware, but since I changed this driver to use the
proper isa kernel framework I'd like to have this tested if possible.
The driver works, provided that linux/slab.h is included. It oopses on rmmod
because dev_set_drvdata() call is missing from init.
This patch fixes all of that and also removes (now useless) static fmr2_card:
Thanks! I'll apply the changes for the final pull request. That's probably
going to be in a week or two.
BTW, do you perhaps have a mirosound pcm20 card (or know someone who does)?
I'd like to update the radio-miropcm20 driver as well and it would be nice if
my changes can be tested.
Regards,
Hans
--- a/drivers/media/radio/radio-sf16fmr2.c
+++ b/drivers/media/radio/radio-sf16fmr2.c
@@ -9,6 +9,7 @@
#include linux/delay.h
#include linux/module.h/* Modules */
#include linux/init.h /* Initdata */
+#include linux/slab.h
#include linux/ioport.h/* request_region */
#include linux/io.h/* outb, outb_p */
#include linux/isa.h
@@ -32,7 +33,6 @@ struct fmr2 {
/* the port is hardwired so no need to support multiple cards */
#define FMR2_PORT0x384
-static struct fmr2 fmr2_card;
/* TEA575x tuner pins */
#define STR_DATA (1 0)
@@ -188,7 +188,7 @@ static int fmr2_tea_ext_init(struct snd_tea575x *tea)
static int __init fmr2_probe(struct device *pdev, unsigned int dev)
{
- struct fmr2 *fmr2 = fmr2_card;
+ struct fmr2 *fmr2;
int err;
fmr2 = kzalloc(sizeof(*fmr2), GFP_KERNEL);
@@ -229,6 +229,7 @@ static int __init fmr2_probe(struct device *pdev,
unsigned int dev)
}
printk(KERN_INFO radio-sf16fmr2: SF16-FMR2 radio card at 0x%x.\n,
fmr2-io);
+ dev_set_drvdata(pdev, fmr2);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] tea575x-tuner improvements use in maxiradio
On Wednesday 08 February 2012 21:30:07 Hans Verkuil wrote: On Wednesday, February 08, 2012 20:57:43 Ondrej Zary wrote: On Wednesday 08 February 2012 08:29:25 Hans Verkuil wrote: On Tuesday, February 07, 2012 23:20:19 Ondrej Zary wrote: On Sunday 05 February 2012 14:17:05 Hans Verkuil wrote: These patches improve the tea575x-tuner module to make it up to date with the latest V4L2 frameworks. The maxiradio driver has also been converted to use the tea575x-tuner and I've used that card to test it. Unfortunately, this card can't read the data pin, so the new hardware seek functionality has been tested only partially (yes, it seeks, but when it finds a channel I can't read back the frequency). Ondrej, are you able to test these patches for the sound cards that use this tea575x tuner? Note that these two patches rely on other work that I did and that hasn't been merged yet. So it is best to pull from my git tree: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/ radi o-pc i2 You can use the v4l-utils repository (http://git.linuxtv.org/v4l-utils.git) to test the drivers: the v4l2-compliance test should succeed and with v4l2-ctl you can test the hardware seek: To seek down: v4l2-ctl -d /dev/radio0 --freq-seek=dir=0 To seek up: v4l2-ctl -d /dev/radio0 --freq-seek=dir=1 To do the compliance test: v4l2-compliance -r /dev/radio0 It seems to work (tested with SF64-PCR - snd_fm801) but the seek is severely broken. Reading the frequency immediately after seek does not work, it always returns the old value (haven't found a delay that works). Reading it later (copied back snd_tea575x_get_freq function) works. The chip seeks randomly up or down, ignoring UP/DOWN flag and often stops at wrong place (only noise) or even outside the FM range. So I strongly suggest not to enable this (mis-)feature. The HW seems to be completely broken (unless there's some weird bug in the code). Well, it seemed like a good idea at the time :-) I'll remove this 'feature', it's really not worth our time to try and make this work for these old cards. I wonder if you are able to test the ISA radio-sf16fmr2.c driver? I'm not sure if you have the hardware, but since I changed this driver to use the proper isa kernel framework I'd like to have this tested if possible. The driver works, provided that linux/slab.h is included. It oopses on rmmod because dev_set_drvdata() call is missing from init. This patch fixes all of that and also removes (now useless) static fmr2_card: Thanks! I'll apply the changes for the final pull request. That's probably going to be in a week or two. BTW, do you perhaps have a mirosound pcm20 card (or know someone who does)? I'd like to update the radio-miropcm20 driver as well and it would be nice if my changes can be tested. Unfortunately not. I only have SF16-FMI, SF16-FMP, SF16-FMR2, SF64-PCR, SF64-PCE2, SF256-PCP. Another card should be on the way, looks like AOpen FX-3D Pro Radio on photo. -- Ondrej Zary -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/35] Add a driver for Terratec H7
Hello, On Sat, Jan 21, 2012 at 5:04 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Terratec H7 is a Cypress FX2 device with a mt2063 tuner and a drx-k demod. This series add support for it. It started with a public tree found at: http://linux.terratec.de/files/TERRATEC_H7/20110323_TERRATEC_H7_Linux.tar.gz The driver were almost completely re-written, and it is now working, at least with DVB-C. I don't have a DVB-T signal here for testing, but I suspect it should also work fine. The FX2 firmware has a NEC IR decoder. The driver has support for it. The default keytable has support for the black Terratec IR and for the grey IR with orange keys. Do I need to do anything special to make this driver work? I just installed the newest media drivers (by following instructions at http://git.linuxtv.org/media_build.git) on a maxhine running Xubuntu 11.10: tingo@kg-f4:~/work/media_ build$ uname -a Linux kg-f4 3.0.0-15-generic #26-Ubuntu SMP Fri Jan 20 17:23:00 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux This machine has a TerraTec H7 connected, lsusb shows: tingo@kg-f4:~/work/media_build$ sudo lsusb -s 1:6 Bus 001 Device 006: ID 0ccd:10a3 TerraTec Electronic GmbH But after installing the drivers, and after a reboot of the machine, the dvb-usb-az6007 driver doesn't load. If I manually do 'sudo modprobe dvb-usb-az6007', the driver loads, but all I get in dmesg is this: [ 1049.838911] WARNING: You are using an experimental version of the media stack. [ 1049.838917] As the driver is backported to an older kernel, it doesn't offer [ 1049.838922] enough quality for its usage in production. [ 1049.838925] Use it with care. [ 1049.838928] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 1049.838932] 59b30294e14fa6a370fdd2bc2921cca1f977ef16 Merge branch 'v4l_for_linus' into staging/for_v3.4 [ 1049.838936] 72565224609a23a60d10fcdf42f87a2fa8f7b16d [media] cxd2820r: sleep on DVB-T/T2 delivery system switch [ 1049.838941] 46de20a78ae4b122b79fc02633e9a6c3d539ecad [media] anysee: fix CI init [ 1049.857524] IR NEC protocol handler initialized [ 1049.892787] usbcore: registered new interface driver dvb_usb_az6007 [ 1049.905264] IR RC5(x) protocol handler initialized [ 1049.919476] IR RC6 protocol handler initialized [ 1049.929152] IR JVC protocol handler initialized [ 1049.943103] IR Sony protocol handler initialized [ 1049.956308] IR SANYO protocol handler initialized [ 1049.97] IR MCE Keyboard/mouse protocol handler initialized [ 1049.989256] lirc_dev: IR Remote Control driver registered, major 250 [ 1050.003618] IR LIRC bridge handler initialized [ 1445.609008] usb 1-2: USB disconnect, device number 5 [ 1449.944046] usb 1-2: new high speed USB device number 6 using ehci_hcd and there aren't anything created in /dev/dvb. What am I doing wrong? -- Regards, Torfinn Ingolfsen -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 11/31] v4l: Document raw bayer 4CC codes
Hi Prabhakar, Prabhakar Lad wrote: +The following first charcters are used by raw bayer formats: A small spelling mistake 'charcters', just pointing out since its a documentation file :-) Regards, --Prabhakar Lad Thanks; fixed for the next version of the patchset. Cheers, -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Q] Interleaved formats on the media bus
Hi Laurent, On 02/05/2012 02:30 PM, Laurent Pinchart wrote: On Saturday 04 February 2012 18:00:10 Sylwester Nawrocki wrote: On 02/04/2012 12:34 PM, Laurent Pinchart wrote: On Thursday 02 February 2012 12:14:08 Sylwester Nawrocki wrote: On 02/02/2012 10:55 AM, Laurent Pinchart wrote: Do all those sensors interleave the data in the same way ? This sounds quite No, each one uses it's own interleaving method. hackish and vendor-specific to me, I'm not sure if we should try to generalize that. Maybe vendor-specific media bus format codes would be the way to go. I don't expect ISPs to understand the format, they will likely be configured in pass-through mode. Instead of adding explicit support for all those weird formats to all ISP drivers, it might make sense to add a binary blob media bus code to be used by the ISP. This could work, except that there is no way to match a fourcc with media bus code. Different fourcc would map to same media bus code, making it impossible for the brigde to handle multiple sensors or one sensor supporting multiple interleaved formats. Moreover there is a need to map media bus code to the MIPI-CSI data ID. What if one sensor sends binary blob with MIPI-CSI User Define Data 1 and the other with User Define Data 2 ? My gut feeling is that the information should be retrieved from the sensor driver. This is all pretty vendor-specific, and adding explicit support for such sensors to each bridge driver wouldn't be very clean. Could the bridge We have many standard pixel codes in include/linux/v4l2-mediabus.h, yet each bridge driver supports only a subset of them. I wouldn't expect a sudden need for all existing bridge drivers to support some strange interleaved image formats. Those media bus codes are standard, so implementing explicit support for them in bridge drivers is fine with me. What I want to avoid is adding explicit support for sensor-specific formats to bridges. There should be no dependency between the bridge and the sensor. OK, I see your point. Naturally I agree here, even though sometimes the hardware engineers make this process of getting rid of the dependencies more painful that it really could be. query the sensor using a subdev operation ? There is also a MIPI-CSI2 receiver in between that needs to be configured. I.e. it must know that it processes the User Defined Data 1, which implies certain pixel alignment, etc. So far a media bus pixel codes have been a base information to handle such things. For CSI user-defined data types, I still think that the information required to configure the CSI receiver should come from the sensor. Only the sensor knows what user-defined data type it will generate. I agree. Should we have separate callback at the sensor ops for this or should it belong to a bigger data structure (like the frame description structure mentioned before) ? The latter might be more reasonable. Maybe we could create e.g. V4L2_MBUS_FMT_USER?, for each MIPI-CSI User Defined data identifier, but as I remember it was decided not to map MIPI-CSI data codes directly onto media bus pixel codes. Would setting the format directly on the sensor subdev be an option ? Do you mean setting a MIPI-CSI2 format ? No, I mean setting the media bus code on the sensor output pad to a vendor- specific value. I'm afraid we need a vendor/sensor specific format identifier since the sensor produces truly vendor specific format. In fact this format is made to overcome hardware limitations of the video bridge. We can of course standardize things like: embedded (non-image) data presence and size at beginning and an end of frame, MIPI-CSIS2 data type, interleaving method (different data type and/or virtual channel), etc. But still there will be some crap that is relevant to only one hardware type and it would need to be distinguished in some way. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/35] Add a driver for Terratec H7
On Wed, Feb 8, 2012 at 10:32 PM, Torfinn Ingolfsen tin...@gmail.com wrote: Do I need to do anything special to make this driver work? I just installed the newest media drivers (by following instructions at http://git.linuxtv.org/media_build.git) on a maxhine running Xubuntu 11.10: tingo@kg-f4:~/work/media_ build$ uname -a Linux kg-f4 3.0.0-15-generic #26-Ubuntu SMP Fri Jan 20 17:23:00 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux This machine has a TerraTec H7 connected, lsusb shows: tingo@kg-f4:~/work/media_build$ sudo lsusb -s 1:6 Bus 001 Device 006: ID 0ccd:10a3 TerraTec Electronic GmbH But after installing the drivers, and after a reboot of the machine, the dvb-usb-az6007 driver doesn't load. If I manually do 'sudo modprobe dvb-usb-az6007', the driver loads, but all I get in dmesg is this: [ 1049.838911] WARNING: You are using an experimental version of the media stack. [ 1049.838917] As the driver is backported to an older kernel, it doesn't offer [ 1049.838922] enough quality for its usage in production. [ 1049.838925] Use it with care. [ 1049.838928] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 1049.838932] 59b30294e14fa6a370fdd2bc2921cca1f977ef16 Merge branch 'v4l_for_linus' into staging/for_v3.4 [ 1049.838936] 72565224609a23a60d10fcdf42f87a2fa8f7b16d [media] cxd2820r: sleep on DVB-T/T2 delivery system switch [ 1049.838941] 46de20a78ae4b122b79fc02633e9a6c3d539ecad [media] anysee: fix CI init [ 1049.857524] IR NEC protocol handler initialized [ 1049.892787] usbcore: registered new interface driver dvb_usb_az6007 [ 1049.905264] IR RC5(x) protocol handler initialized [ 1049.919476] IR RC6 protocol handler initialized [ 1049.929152] IR JVC protocol handler initialized [ 1049.943103] IR Sony protocol handler initialized [ 1049.956308] IR SANYO protocol handler initialized [ 1049.97] IR MCE Keyboard/mouse protocol handler initialized [ 1049.989256] lirc_dev: IR Remote Control driver registered, major 250 [ 1050.003618] IR LIRC bridge handler initialized [ 1445.609008] usb 1-2: USB disconnect, device number 5 [ 1449.944046] usb 1-2: new high speed USB device number 6 using ehci_hcd and there aren't anything created in /dev/dvb. What am I doing wrong? Never mind. after adding this patch: http://patchwork.linuxtv.org/patch/9691/ and rebuilding the media drivers, the device is now detected: tingo@kg-f4:~$ dmesg | grep -i terratec [ 19.755806] dvb-usb: found a 'TerraTec DTV StarBox DVB-T/C USB2.0 (az6007)' in warm state. [ 20.949045] DVB: registering new adapter (TerraTec DTV StarBox DVB-T/C USB2.0 (az6007)) [ 23.732039] Registered IR keymap rc-nec-terratec-cinergy-xs [ 23.732442] dvb-usb: TerraTec DTV StarBox DVB-T/C USB2.0 (az6007) successfully initialized and connected. -- Regards, Torfinn Ingolfsen -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Receipt of non conform e-mail
The following e-mail is not conform and has been removed by the SMTP relay of the : Submitter : linux-media@vger.kernel.org (120.61.153.33) Subject : Delivery reports about your e-mail Recipient(s) : michela.bere...@lamberti.com Arkoon Virus found in file michela.bere...@lamberti.com.zip (virus W32/MyDoom-O in michela.bere...@lamberti.com.zip/michela.bere...@lamberti.com.zip/michela.bere...@lamberti.com.html .pif) Virus found in file michela.bere...@lamberti.com.zip (virus Troj/ZipMal-AW in michela.bere...@lamberti.com.zip/michela.bere...@lamberti.com.zip) Virus found in file michela.bere...@lamberti.com.zip (virus W32/MyDoom-O in michela.bere...@lamberti.com.zip) E-mail is infected by a virus, linked files will be removed. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
