Re: Hauppauge HVR-930C problems

[Mihai Dobrescu]

I've got the sources, I've successfully built everything.
Where should I expect to have the binary files after the make install?

Thank you.

On Tue, Jan 10, 2012 at 10:35 PM, Mauro Carvalho Chehab
 wrote:
> On 10-01-2012 18:23, Mihai Dobrescu wrote:
>> I can't find dvb-fe-util tool.
>
> http://git.linuxtv.org/v4l-utils.git/blob/ad284d9ef6600e091515b0abd7cec64736097265:/utils/dvb/dvb-fe-tool.c
>
> Regards,
> Mauro
>
>>
>> On Tue, Jan 10, 2012 at 9:41 PM, Mauro Carvalho Chehab
>>  wrote:
>>> On 10-01-2012 17:30, Mihai Dobrescu wrote:
 Hello,

 Just compiled the latest again, but still no difference.
 kaffeine doesn't see any source in channels dialog, two devices are in
 'Configure Television' dialog: DRXK DVB-C - device not connected - as
 Device 1 and DRXK DVB-C DVB-T as Device 2. Concerning the last one, no
 source is selected, as I am in Romania, which is not in the list
 scan_w finds nothing.

 What should I do next?
>>>
>>> Kaffeine doesn't work with MFE tuners (at least not the version I have).
>>> It only sees one delivery system.
>>>
>>> If you're using the very latest version of the driver (the one at the
>>> media-build tree), you can use the dvb-fe-util tool to change
>>> the delivery system to DVB-C or to DVB-T.
>>>
>>> The tool is now part of the v4l-utils.
>>>
>>> You may also request a Kaffeine developer or to submit a patch for it,
>>> in order to add support on it to detect the frontend supported
>>> delivery systems and to change it dynamically.
>>>

 Regards, Mike.

 On Tue, Jan 10, 2012 at 4:42 PM, Fredrik Lingvall
  wrote:
> On 12/25/11 16:56, Fredrik Lingvall wrote:
>>
>> On 12/18/11 10:20, Fredrik Lingvall wrote:
>>>
>>> On 12/17/11 20:53, Mihai Dobrescu wrote:




 Mihai,

 I got some success. I did this,

 # cd /usr/src (for example)

 # git clone git://linuxtv.org/media_build.git

 # emerge dev-util/patchutils
 # emerge Proc-ProcessTable

 # cd media_build
 # ./build
 # make install

 Which will install the latest driver on your running kernel (just in
 case
 make sure /usr/src/linux points to your running kernel sources). Then
 reboot.

 You should now see that (among other) modules have loaded:

 # lsmod

 

 em28xx                 93528  1 em28xx_dvb
 v4l2_common             5254  1 em28xx
 videobuf_vmalloc        4167  1 em28xx
 videobuf_core          15151  2 em28xx,videobuf_vmalloc

 Then try w_scan and dvbscan etc. I got mythtv to scan too now. There
 were
 some warnings and timeouts and I'm not sure if this is normal or not.

 You can also do a dmesg -c while scanning to monitor the changes en the
 kernel log.

 Regards,

 /Fredrik


 In my case I have:

 lsmod |grep em2
 em28xx_dvb             12608  0
 dvb_core               76187  1 em28xx_dvb
 em28xx                 82436  1 em28xx_dvb
 v4l2_common             5087  1 em28xx
 videodev               70123  2 em28xx,v4l2_common
 videobuf_vmalloc        3783  1 em28xx
 videobuf_core          12991  2 em28xx,videobuf_vmalloc
 rc_core                11695  11

 rc_hauppauge,ir_lirc_codec,ir_mce_kbd_decoder,ir_sanyo_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,em28xx,ir_nec_decoder
 tveeprom               12441  1 em28xx
 i2c_core               14232  9

 xc5000,drxk,em28xx_dvb,em28xx,v4l2_common,videodev,tveeprom,nvidia,i2c_i801

 yet, w_scan founds nothing.
>>>
>>>
>>> I was able to scan using the "media_build" install method described 
>>> above
>>> but when trying to watch a free channel the image and sound was 
>>> stuttering
>>> severly. I have tried both MythTV and mplayer with similar results.
>>>
>>> I created the channel list for mplayer with:
>>>
>>> lintv ~ # dvbscan -x0 -fc /usr/share/dvb/dvb-c/no-Oslo-Get -o zap >
>>> .mplayer/channels.conf
>>>
>>> And, for example,  I get this output from mplayer plus a very (blocky)
>>> stuttering image and sound:
>>>
>>> lin-tv ~ # mplayer dvb://1@"TV8 Oslo" -ao jack
>>>
>>
>> I did some more tests with release snapshots 2011-12-13, 2011-12-21, and
>> 2011-12-25, respectively. I did this by changing
>>
>> LATEST_TAR :=
>> http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2
>> LATEST_TAR_MD5 :=
>> http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2.md5
>>
>> in linux/Makefile to the corresponding release.
>>
>> Res

Re: Using OMAP3 ISP live display and snapshot sample applications

[James]

Hi Laurent,

On Sun, Jan 8, 2012 at 7:30 PM, Laurent Pinchart
 wrote:
> Hi James,
>
> On Sunday 08 January 2012 02:14:55 James wrote:
>
> [snip]
>
>> BTW, can you send me the defconfig file you used for testing on overo as I
>> couldn‘t compile your branch with mine.
>
> Attached.
>
>> I forgot to mentioned that I'm trying out the application with the MT9V032
>> camera first on both Tobi & Chestnut board. Not with the new monochrome
>> sensor yet.
>
> --
> Regards,
>
> Laurent Pinchart

Thanks for the defconfig.

I'll proceed to try to build a fresh kernel based on your branch
"omap3isp-sensors-board".

I guess this is a better branch or should I try the YUV branch or others?

Test1 with MT9V032 and Test2 with monochrome sensor Y12.

Thanks.

-- 
Regards,
James
--
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 v4 2/2] [media] V4L: atmel-isi: add clk_prepare()/clk_unprepare() functions

[Josh Wu]

Signed-off-by: Josh Wu 
Acked-by: Nicolas Ferre 
---
v2: made the label name to be consistent.
v4: add goto for handling pclk prepare error.

 drivers/media/video/atmel-isi.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index 9fe4519..ec3f6a0 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -922,7 +922,9 @@ static int __devexit atmel_isi_remove(struct 
platform_device *pdev)
isi->fb_descriptors_phys);
 
iounmap(isi->regs);
+   clk_unprepare(isi->mck);
clk_put(isi->mck);
+   clk_unprepare(isi->pclk);
clk_put(isi->pclk);
kfree(isi);
 
@@ -955,6 +957,10 @@ static int __devinit atmel_isi_probe(struct 
platform_device *pdev)
if (IS_ERR(pclk))
return PTR_ERR(pclk);
 
+   ret = clk_prepare(pclk);
+   if (ret)
+   goto err_clk_prepare_pclk;
+
isi = kzalloc(sizeof(struct atmel_isi), GFP_KERNEL);
if (!isi) {
ret = -ENOMEM;
@@ -978,6 +984,10 @@ static int __devinit atmel_isi_probe(struct 
platform_device *pdev)
goto err_clk_get;
}
 
+   ret = clk_prepare(isi->mck);
+   if (ret)
+   goto err_clk_prepare_mck;
+
/* Set ISI_MCK's frequency, it should be faster than pixel clock */
ret = clk_set_rate(isi->mck, pdata->mck_hz);
if (ret < 0)
@@ -1059,10 +1069,14 @@ err_alloc_ctx:
isi->fb_descriptors_phys);
 err_alloc_descriptors:
 err_set_mck_rate:
+   clk_unprepare(isi->mck);
+err_clk_prepare_mck:
clk_put(isi->mck);
 err_clk_get:
kfree(isi);
 err_alloc_isi:
+   clk_unprepare(pclk);
+err_clk_prepare_pclk:
clk_put(pclk);
 
return ret;
-- 
1.6.3.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: [PATCH RESEND v3 2/2] [media] V4L: atmel-isi: add clk_prepare()/clk_unprepare() functions

[Wu, Josh]

Hi, Guennadi

Thank you. I will send v4 version to apply your suggestion.

On Tuesday, January 10, 2012 7:29 PM, Guennadi Liakhovetski wrote:

> Hi Josh

> Right, sorry, I missed this one, I somehow developed an idea, that it
has 
> been merged into the original patch, adding ISI_MCK handling. Now, I
also 
> notice one detail, that we could improve:

> On Tue, 10 Jan 2012, Josh Wu wrote:

>> Signed-off-by: Josh Wu 
>> Acked-by: Nicolas Ferre 
>> ---
>> Hi, Mauro
>> 
>> The first patch of this serie, [PATCH 1/2 v3] V4L: atmel-isi: add
code to enable/disable ISI_MCK clock, is already queued in media tree. 
>> But this patch (the second one of this serie) is not acked yet. Would
it be ok to for you to ack this patch?
>> 
>> Best Regards,
>> Josh Wu
>> 
>> v2: made the label name to be consistent.
>> 
>>  drivers/media/video/atmel-isi.c |   15 +++
>>  1 files changed, 15 insertions(+), 0 deletions(-)
>> 
>> diff --git a/drivers/media/video/atmel-isi.c
b/drivers/media/video/atmel-isi.c
>> index ea4eef4..91ebcfb 100644
>> --- a/drivers/media/video/atmel-isi.c
>> +++ b/drivers/media/video/atmel-isi.c
>> @@ -922,7 +922,9 @@ static int __devexit atmel_isi_remove(struct
platform_device *pdev)
>>  isi->fb_descriptors_phys);
>>  
>>  iounmap(isi->regs);
>> +clk_unprepare(isi->mck);
>>  clk_put(isi->mck);
>> +clk_unprepare(isi->pclk);
>>  clk_put(isi->pclk);
>>  kfree(isi);
>>  
>> @@ -955,6 +957,12 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
>>  if (IS_ERR(pclk))
>>  return PTR_ERR(pclk);
>>  
>> +ret = clk_prepare(pclk);
>> +if (ret) {
>> +clk_put(pclk);
>> +return ret;

> Don't think it's a good idea here. You already have clk_put(pclk) on
the 
> error handling path below. So, just put a "goto err_clk_prepare_pclk"
here 
> and the respective error below.

Right. I'll fix it in v4.

> Thanks
> Guennadi

>> +}
>> +
>>  isi = kzalloc(sizeof(struct atmel_isi), GFP_KERNEL);
>>  if (!isi) {
>>  ret = -ENOMEM;
>> @@ -978,6 +986,10 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
>>  goto err_clk_get;
>>  }
>>  
>> +ret = clk_prepare(isi->mck);
>> +if (ret)
>> +goto err_clk_prepare_mck;
>> +
>>  /* Set ISI_MCK's frequency, it should be faster than pixel clock
*/
>>  ret = clk_set_rate(isi->mck, pdata->mck_hz);
>>  if (ret < 0)
>> @@ -1059,10 +1071,13 @@ err_alloc_ctx:
>>  isi->fb_descriptors_phys);
>>  err_alloc_descriptors:
>>  err_set_mck_rate:
>> +clk_unprepare(isi->mck);
>> +err_clk_prepare_mck:
>>  clk_put(isi->mck);
>>  err_clk_get:
>>  kfree(isi);
>>  err_alloc_isi:
>> +clk_unprepare(pclk);
>>  clk_put(pclk);
>>  
>>  return ret;
>> -- 
>> 1.6.3.3
>> 

> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/

Best Regards,
Josh Wu
--
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: Adding support for PCTV-80e Tuner

[Devin Heitmueller]

On Tue, Jan 10, 2012 at 9:27 PM, Patrick Dickey  wrote:
> Hello everyone,
>
> A few months ago, I posted a 25-patch series on the PCTV-80e Tuner to
> the mailing list, which was nacked. I've since rewrote the patches, but
> have an issue that I need some advice with.  I took Devin's advice, and
> created two patches using his hg patches. The only modifications that I
> made were to remove the Makefile and Kconfig entries, and then to move
> the drivers to the staging/media/frontends/drx39xyj directory.
>
> I've got a couple of problems/questions, and am looking for opinions on
> how to deal with them. I included the mailing list in this, because
> there might be someone who's had similar issues, and because this issue
> might come up in the future with other projects.
>
> So, here are my problems.
>
> 1. If I try to make the media_git with just the two patches included, I
> get compilation errors in em28xx-cards.c. This is because it needs the
> drx39xxj.h file, which is in drivers/staging/media/frontends/drx39xyj
> (and hasn't been compiled).
>
> 2. If I add an entry into the drivers/media Makefile and Kconfig,
> pointing to the drvers/staging/media/frontends/drx39xyj directory, it
> fails to compile because drx39xxj.c requires dvb_frontend.h from
> drivers/media/dvb/dvb-core, which hasn't been compiled yet.
>
> The short question is how do I handle this situation?
>
> The longer questions are
>
> 1.  Do I make entries in the drx39xyj/Makefile and Kconfig that point
> back to the dvb/dvb-core directory (or add the drivers/dvb/ entry before
> the drivers/staging/media/frontends/drx39xyj/ entry in the
> Makefile/Kconfig entries in drivers/media/)?
>
> 2.  Do I submit my two patches, knowing that they will break compilation
> of the media_git tree at the em28xx-cards.c file?
>
> 3.  Do I comment out the entries in em28xx-cards.c (or remove them from
> the patches altogether), so that everything will be made and we can work
> on the compilation and coding style issues in the drx39xyj files? (I
> would do this in a third patch, so that I can preserve Devin's original
> patches as much as possible)
>
> Right now, I have two patches that create the drivers and add them to
> the em28xx files where necessary, and that update the licensing and
> authorship (Devin's original updates). And I have a third patch, which
> adds a ccflags-y entry to the em28xx Makefile, pointing to the
> drivers/staging/media/frontends/drx39xyj directory (for finding the
> files it needs).
>
> Thanks for any information and advice. And if I should have just
> directed this to Devin and/or Mauro (or waited for a reply from an
> earlier email to Mauro), I'm sorry for the inconvenience that sending
> this to the entire list may have caused.
>
> Have a great day:)
> Patrick.

It's a brand new driver, so my suggestion would be to just tweak my
original patch to not include the Makefile change or em28xx-cards.c
(and note that you did such in the patch description).  From that
point on it won't matter if anything there compiles.  Then put your 25
patches on top of mine, and finally do a patch with the description
"add support for PCTV 80e product" which adds in the Makefile change
and the change to em28xx-cards.c.

That allows all the history to be preserved while ensuring that none
of your intermediate patches break compilation.

This is the sort of thing you can get away with when it's a brand new
driver (since it isn't used by anything until you explicitly add
support for a particular product).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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] drivers: video: mx3_camera: Convert mx3_camera to use module_platform_driver()

[Fabio Estevam]

Using module_platform_driver makes the code smaller and simpler.

Signed-off-by: Fabio Estevam 
---
 drivers/media/video/mx3_camera.c |   14 +-
 1 files changed, 1 insertions(+), 13 deletions(-)

diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index f44323f..7452277 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -1286,19 +1286,7 @@ static struct platform_driver mx3_camera_driver = {
.remove = __devexit_p(mx3_camera_remove),
 };
 
-
-static int __init mx3_camera_init(void)
-{
-   return platform_driver_register(&mx3_camera_driver);
-}
-
-static void __exit mx3_camera_exit(void)
-{
-   platform_driver_unregister(&mx3_camera_driver);
-}
-
-module_init(mx3_camera_init);
-module_exit(mx3_camera_exit);
+module_platform_driver(mx3_camera_driver);
 
 MODULE_DESCRIPTION("i.MX3x SoC Camera Host driver");
 MODULE_AUTHOR("Guennadi Liakhovetski ");
-- 
1.7.1

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

Adding support for PCTV-80e Tuner

[Patrick Dickey]

Hello everyone,

A few months ago, I posted a 25-patch series on the PCTV-80e Tuner to
the mailing list, which was nacked. I've since rewrote the patches, but
have an issue that I need some advice with.  I took Devin's advice, and
created two patches using his hg patches. The only modifications that I
made were to remove the Makefile and Kconfig entries, and then to move
the drivers to the staging/media/frontends/drx39xyj directory.

I've got a couple of problems/questions, and am looking for opinions on
how to deal with them. I included the mailing list in this, because
there might be someone who's had similar issues, and because this issue
might come up in the future with other projects.

So, here are my problems.

1. If I try to make the media_git with just the two patches included, I
get compilation errors in em28xx-cards.c. This is because it needs the
drx39xxj.h file, which is in drivers/staging/media/frontends/drx39xyj
(and hasn't been compiled).

2. If I add an entry into the drivers/media Makefile and Kconfig,
pointing to the drvers/staging/media/frontends/drx39xyj directory, it
fails to compile because drx39xxj.c requires dvb_frontend.h from
drivers/media/dvb/dvb-core, which hasn't been compiled yet.

The short question is how do I handle this situation?

The longer questions are

1.  Do I make entries in the drx39xyj/Makefile and Kconfig that point
back to the dvb/dvb-core directory (or add the drivers/dvb/ entry before
the drivers/staging/media/frontends/drx39xyj/ entry in the
Makefile/Kconfig entries in drivers/media/)?

2.  Do I submit my two patches, knowing that they will break compilation
of the media_git tree at the em28xx-cards.c file?

3.  Do I comment out the entries in em28xx-cards.c (or remove them from
the patches altogether), so that everything will be made and we can work
on the compilation and coding style issues in the drx39xyj files? (I
would do this in a third patch, so that I can preserve Devin's original
patches as much as possible)

Right now, I have two patches that create the drivers and add them to
the em28xx files where necessary, and that update the licensing and
authorship (Devin's original updates). And I have a third patch, which
adds a ccflags-y entry to the em28xx Makefile, pointing to the
drivers/staging/media/frontends/drx39xyj directory (for finding the
files it needs).

Thanks for any information and advice. And if I should have just
directed this to Devin and/or Mauro (or waited for a reply from an
earlier email to Mauro), I'm sorry for the inconvenience that sending
this to the entire list may have caused.

Have a great day:)
Patrick.
--
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] [media] [PATCH] don't reset the delivery system on DTV_CLEAR

[Mauro Carvalho Chehab]

As a DVBv3 application may be relying on the delivery system,
don't reset it at DTV_CLEAR. For DVBv5 applications, the
delivery system should be set anyway.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index a904793..b15db4f 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -909,7 +909,6 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
 
c->state = DTV_CLEAR;
 
-   c->delivery_system = fe->ops.delsys[0];
dprintk("%s() Clearing cache for delivery system %d\n", __func__,
c->delivery_system);
 
@@ -2377,6 +2376,8 @@ int dvb_register_frontend(struct dvb_adapter* dvb,
 * Initialize the cache to the proper values according with the
 * first supported delivery system (ops->delsys[0])
 */
+
+fe->dtv_property_cache.delivery_system = fe->ops.delsys[0];
dvb_frontend_clear_cache(fe);
 
mutex_unlock(&frontend_mutex);
-- 
1.7.7.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

Re: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

[InKi Dae]

2012/1/10 Rob Clark :
> On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae  wrote:
>> 2012/1/10 Rob Clark :
>>> On Mon, Jan 9, 2012 at 4:10 AM, InKi Dae  wrote:
 note : in case of sharing a buffer between v4l2 and drm driver, the
 memory info would be copied vb2_xx_buf to xx_gem or xx_gem to
 vb2_xx_buf through sg table. in this case, only memory info is used to
 share, not some objects.
>>>
>>> which v4l2/vb2 patches are you looking at?  The patches I was using,
>>> vb2 holds a reference to the 'struct dma_buf *' internally, not just
>>> keeping the sg_table
>>>
>>
>> yes, not keeping the sg_table. I mean... see a example below please.
>>
>> static void vb2_dma_contig_map_dmabuf(void *mem_priv)
>> {
>>    struct sg_table *sg;
>>     ...
>>     sg = dma_buf_map_attachment(buf->db_attach, dir);
>>     ...
>>     buf->dma_addr = sg_dma_address(sg->sgl);
>>     ...
>> }
>>
>> at least with no IOMMU, the memory information(containing physical
>> memory address) would be copied to vb2_xx_buf object if drm gem
>> exported its own buffer and vb2 wants to use that buffer at this time,
>> sg table is used to share that buffer. and the problem I pointed out
>> is that this buffer(also physical memory region) could be released by
>> vb2 framework(as you know, vb2_xx_buf object and the memory region for
>> buf->dma_addr pointing) but the Exporter(drm gem) couldn't know that
>> so some problems would be induced once drm gem tries to release or
>> access that buffer. and I have tried to resolve this issue adding
>> get_shared_cnt() callback to dma-buf.h but I'm not sure that this is
>> good way. maybe there would be better way.
>
> the exporter (in this case your driver's drm/gem bits) shouldn't
> release that mapping / sgtable until the importer (in this case v4l2)
> calls dma_buf_unmap fxn..
>
> It would be an error if the importer did a dma_buf_put() without first
> calling dma_buf_unmap_attachment() (if currently mapped) and then
> dma_buf_detach() (if currently attached).  Perhaps somewhere there
> should be some sanity checking debug code which could be enabled to do
> a WARN_ON() if the importer does the wrong thing.  It shouldn't really
> be part of the API, I don't think, but it actually does seem like a
> good thing, esp. as new drivers start trying to use dmabuf, to have
> some debug options which could be enabled.
>
> It is entirely possible that something was missed on the vb2 patches,
> but the way it is intended to work is like this:
> https://github.com/robclark/kernel-omap4/blob/0961428143cd10269223e3d0f24bc3a66a96185f/drivers/media/video/videobuf2-core.c#L92
>
> where it does a detach() before the dma_buf_put(), and the vb2-contig
> backend checks here that it is also unmapped():
> https://github.com/robclark/kernel-omap4/blob/0961428143cd10269223e3d0f24bc3a66a96185f/drivers/media/video/videobuf2-dma-contig.c#L251
>

I think that we also used same concept as your. for this, you can
refer to Dave's repository below and see the drm_prime_gem_destroy
function.
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-prime-dmabuf&id=7cb374d6642e838e0e4836042e057e6d9139dcad

but when it comes to releasing resources, I mistakely understood some
parts of dmabuf concept so thank you for Rob and Sumit. that is very
useful.

> BR,
> -R
>
>> Thanks.
>>
>>> BR,
>>> -R
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Antti Palosaari]

On 01/10/2012 03:28 PM, Jim Darby wrote:

I've been using a PCTV Nanostick T2 USB DVB-T2 receiver (one of the few
that supports DVB-T2) for over six months with a 3.0 kernel with no
problems.

The key drivers in use are em28xx, cxd2820r and tda18271.

Seeing the 3.2 kernel I thought I'd upgrade and now I seem to have hit a
problem.


Do you have possibility to test Kernel 3.1?
Also latest LinuxTV.org devel could be interesting to see. There is one 
patch that changes em28xx driver endpoint configuration. But as that 
patch is going for 3.3 it should not be cause of issue, but I wonder if 
it could fix... Use media_build.git if possible.



The Nanostick works fine for between 5 and 25 minutes and then without
any error messages cuts out. The TS drops to a tiny stream of non-TS
data. It seems to contain a lot of 0x00s and 0xffs.

It looks like the problem of many years ago when the frontends would be
shut down if they were closed for more than a few minutes. However, it
would appear that the frontend fds are still open (according to fuser).

Some more system details:

This is running on a 32-bit system.

Everything works fine if I boot with the 3.0.0 kernel.

The user-land application is kaffeine.

There is a PCI DVB-T card in the system which operates fine even when
the Nanostick stops producing the correct output.


Which is that card? I wonder if there is same drivers used like tda18271...


I'm more than happy to build kernels and add debugging. I'm basically
just trying to find the maintainer for these modules so we can figure
out what's going wrong and fix it before 3.2 escapes into several
distros and we have this problem on a larger scale.


I am maintainer of the cxd2820r. Mike knows tda18271 and maybe Mauro 
em28xx...



Many thanks for your help,

Jim.



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

[GIT PULL FOR 3.3 v2] HDIC HD29L2 DMB-TH demodulator driver

[Antti Palosaari]

Mauro,

That is 2nd attempt to PULL that to the Kernel. If possible send that 
still to the 3.3...


As a DTMB support in out API is not ready I decided to move whole driver 
to the staging.


I fixed most of those findings you pointed out and left one bit 
operation without fix (find_first_bit) still because it gave one warning...


drivers/media/dvb/frontends/hd29l2.c: In function ‘hd29l2_rd_reg_mask’:
drivers/media/dvb/frontends/hd29l2.c:139:2: warning: passing argument 1 
of ‘find_first_bit’ from incompatible pointer type
include/asm-generic/bitops/find.h:35:22: note: expected ‘const long 
unsigned int *’ but argument is of type ‘u8 *’




Antti


The following changes since commit 2f78604a433a12571ec3e54054fbfacc7525b307:

  [media] Added model Sveon STV40 (2012-01-07 12:02:20 -0200)

are available in the git repository at:
  git://linuxtv.org/anttip/media_tree.git hdic_v2

Antti Palosaari (8):
  HDIC HD29L2 DMB-TH demodulator driver
  HDIC HD29L2 DMB-TH USB2.0 reference design driver
  hd29l2: synch for latest DVB core changes
  mxl5007t: bugfix DVB-T 7 MHz and 8 MHz bandwidth
  hd29l2: add debug for used IF frequency
  dvb-core: define general callback value for demodulator
  hd29l2: fix review findings
  hd29l2: move to staging

 drivers/media/common/tuners/mxl5007t.c |2 +
 drivers/media/dvb/dvb-core/dvb_frontend.h  |1 +
 drivers/media/dvb/dvb-usb/Kconfig  |7 +
 drivers/media/dvb/dvb-usb/Makefile |3 +
 drivers/media/dvb/dvb-usb/hdic.c   |  365 
 drivers/media/dvb/dvb-usb/hdic.h   |   45 ++
 drivers/staging/media/Kconfig  |2 +
 drivers/staging/media/Makefile |1 +
 drivers/staging/media/hd29l2/Kconfig   |7 +
 drivers/staging/media/hd29l2/Makefile  |4 +
 drivers/staging/media/hd29l2/TODO  |3 +
 drivers/staging/media/hd29l2/hd29l2.c  |  861 


 drivers/staging/media/hd29l2/hd29l2.h  |   66 +++
 drivers/staging/media/hd29l2/hd29l2_priv.h |  314 ++
 14 files changed, 1681 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/dvb/dvb-usb/hdic.c
 create mode 100644 drivers/media/dvb/dvb-usb/hdic.h
 create mode 100644 drivers/staging/media/hd29l2/Kconfig
 create mode 100644 drivers/staging/media/hd29l2/Makefile
 create mode 100644 drivers/staging/media/hd29l2/TODO
 create mode 100644 drivers/staging/media/hd29l2/hd29l2.c
 create mode 100644 drivers/staging/media/hd29l2/hd29l2.h
 create mode 100644 drivers/staging/media/hd29l2/hd29l2_priv.h

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

[PATCH v2] [media] tda18271-fe: Fix support for ISDB-T

[Mauro Carvalho Chehab]

Signed-off-by: Mauro Carvalho Chehab 
---

V2: ISDB-T can use 6, 7 or 8MHz for bandwidth. So, the code should
handle it just like DVB-T.

 drivers/media/common/tuners/tda18271-fe.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/media/common/tuners/tda18271-fe.c 
b/drivers/media/common/tuners/tda18271-fe.c
index d3d91ea..2e67f44 100644
--- a/drivers/media/common/tuners/tda18271-fe.c
+++ b/drivers/media/common/tuners/tda18271-fe.c
@@ -946,6 +946,7 @@ static int tda18271_set_params(struct dvb_frontend *fe)
map = &std_map->atsc_6;
bw = 600;
break;
+   case SYS_ISDBT:
case SYS_DVBT:
case SYS_DVBT2:
if (bw <= 600) {
-- 
1.7.7.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

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Andy Walls]

Steven Toth  wrote:

>> status SCVYL | signal  | snr 00ee | ber  | unc  |
>> FE_HAS_LOCK
>> status SCVYL | signal  | snr 00f0 | ber  | unc  |
>> FE_HAS_LOCK
>>
>> and when it stopped working, this time an hour later, nothing had
>changed.
>> In fact, it looks like the driver keeps lock even when it's not
>recording at
>> all.
>>
>> Any ideas anyone? Looks like the tuner is OK
>
>It sounds signal, hardware or heat/environmental related, unlikely to
>be driver related.
>
>-- 
>Steven Toth - Kernel Labs
>http://www.kernellabs.com
>--
>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

Any chance that transfer buffers are being slowly dropped out of rotation?

That would explain captures stopping after a variable amount of time.  (Early 
cx18 driver versions had that problem.)

Regards,
Andy


--
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 5/6] [media] cx231xx: cx231xx_devused is racy

[Mauro Carvalho Chehab]

cx231xx_devused is racy. Re-implement it in a proper way,
to remove the risk of mangling it.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/video/cx231xx/cx231xx-cards.c |   36 +-
 1 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c 
b/drivers/media/video/cx231xx/cx231xx-cards.c
index bd82f01..1f2fbbf 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -854,7 +854,7 @@ void cx231xx_release_resources(struct cx231xx *dev)
usb_put_dev(dev->udev);
 
/* Mark device as unused */
-   cx231xx_devused &= ~(1 << dev->devno);
+   clear_bit(dev->devno, &cx231xx_devused);
 
kfree(dev->video_mode.alt_max_pkt_size);
kfree(dev->vbi_mode.alt_max_pkt_size);
@@ -1039,21 +1039,21 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
return -ENODEV;
 
/* Check to see next free device and mark as used */
-   nr = find_first_zero_bit(&cx231xx_devused, CX231XX_MAXBOARDS);
-   cx231xx_devused |= 1 << nr;
-
-   if (nr >= CX231XX_MAXBOARDS) {
-   cx231xx_err(DRIVER_NAME
-": Supports only %i cx231xx boards.\n", CX231XX_MAXBOARDS);
-   cx231xx_devused &= ~(1 << nr);
-   return -ENOMEM;
-   }
+   do {
+   nr = find_first_zero_bit(&cx231xx_devused, CX231XX_MAXBOARDS);
+   if (nr >= CX231XX_MAXBOARDS) {
+   /* No free device slots */
+   cx231xx_err(DRIVER_NAME ": Supports only %i devices.\n",
+   CX231XX_MAXBOARDS);
+   return -ENOMEM;
+   }
+   } while (test_and_set_bit(nr, &cx231xx_devused));
 
/* allocate memory for our device state and initialize it */
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (dev == NULL) {
cx231xx_err(DRIVER_NAME ": out of memory!\n");
-   cx231xx_devused &= ~(1 << nr);
+   clear_bit(dev->devno, &cx231xx_devused);
return -ENOMEM;
}
 
@@ -1129,7 +1129,7 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
if (assoc_desc->bFirstInterface != ifnum) {
cx231xx_err(DRIVER_NAME ": Not found "
"matching IAD interface\n");
-   cx231xx_devused &= ~(1 << nr);
+   clear_bit(dev->devno, &cx231xx_devused);
kfree(dev);
dev = NULL;
return -ENODEV;
@@ -1148,7 +1148,7 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
retval = v4l2_device_register(&interface->dev, &dev->v4l2_dev);
if (retval) {
cx231xx_errdev("v4l2_device_register failed\n");
-   cx231xx_devused &= ~(1 << nr);
+   clear_bit(dev->devno, &cx231xx_devused);
kfree(dev);
dev = NULL;
return -EIO;
@@ -1156,7 +1156,7 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
/* allocate device struct */
retval = cx231xx_init_dev(&dev, udev, nr);
if (retval) {
-   cx231xx_devused &= ~(1 << dev->devno);
+   clear_bit(dev->devno, &cx231xx_devused);
v4l2_device_unregister(&dev->v4l2_dev);
kfree(dev);
dev = NULL;
@@ -1181,7 +1181,7 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
 
if (dev->video_mode.alt_max_pkt_size == NULL) {
cx231xx_errdev("out of memory!\n");
-   cx231xx_devused &= ~(1 << nr);
+   clear_bit(dev->devno, &cx231xx_devused);
v4l2_device_unregister(&dev->v4l2_dev);
kfree(dev);
dev = NULL;
@@ -1215,7 +1215,7 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
 
if (dev->vbi_mode.alt_max_pkt_size == NULL) {
cx231xx_errdev("out of memory!\n");
-   cx231xx_devused &= ~(1 << nr);
+   clear_bit(dev->devno, &cx231xx_devused);
v4l2_device_unregister(&dev->v4l2_dev);
kfree(dev);
dev = NULL;
@@ -1250,7 +1250,7 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
 
if (dev->sliced_cc_mode.alt_max_pkt_size == NULL) {
cx231xx_errdev("out of memory!\n");
-   cx231xx_devused &= ~(1 << nr);
+   clear_bit(dev->devno, &cx231xx_devused);
v4l2_device_unregister(&dev->v4l2_dev);
kfree(dev);
dev = NULL;
@@ -1286,7 +1286,7 @@ static int cx231xx_usb_probe(struct usb_interface 
*interface,
 
if (dev->ts1_mode.alt_max_pkt_size == NULL) {
cx231xx_errdev("out of memory!\n");
-   cx231xx_devused &= ~(1 << nr);
+   clea

[PATCH 2/6] [media] cx231xx-input: stop polling if the device got removed.

[Mauro Carvalho Chehab]

If the device got removed, stops polling it. Also, un-registers
it at input/evdev, as it won't work anymore. We can't free the
IR structure yet, as the ir_remove method will be called later.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/video/cx231xx/cx231xx-input.c |6 +-
 drivers/media/video/ir-kbd-i2c.c|   17 +
 2 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/media/video/cx231xx/cx231xx-input.c 
b/drivers/media/video/cx231xx/cx231xx-input.c
index 45e14ca..8a75a90 100644
--- a/drivers/media/video/cx231xx/cx231xx-input.c
+++ b/drivers/media/video/cx231xx/cx231xx-input.c
@@ -27,12 +27,16 @@
 static int get_key_isdbt(struct IR_i2c *ir, u32 *ir_key,
 u32 *ir_raw)
 {
+   int rc;
u8  cmd, scancode;
 
dev_dbg(&ir->rc->input_dev->dev, "%s\n", __func__);
 
/* poll IR chip */
-   if (1 != i2c_master_recv(ir->c, &cmd, 1))
+   rc = i2c_master_recv(ir->c, &cmd, 1);
+   if (rc < 0)
+   return rc;
+   if (rc != 1)
return -EIO;
 
/* it seems that 0xFE indicates that a button is still hold
diff --git a/drivers/media/video/ir-kbd-i2c.c b/drivers/media/video/ir-kbd-i2c.c
index 3ab875d..37d0c20 100644
--- a/drivers/media/video/ir-kbd-i2c.c
+++ b/drivers/media/video/ir-kbd-i2c.c
@@ -244,7 +244,7 @@ static int get_key_avermedia_cardbus(struct IR_i2c *ir,
 
 /* --- */
 
-static void ir_key_poll(struct IR_i2c *ir)
+static int ir_key_poll(struct IR_i2c *ir)
 {
static u32 ir_key, ir_raw;
int rc;
@@ -253,20 +253,28 @@ static void ir_key_poll(struct IR_i2c *ir)
rc = ir->get_key(ir, &ir_key, &ir_raw);
if (rc < 0) {
dprintk(2,"error\n");
-   return;
+   return rc;
}
 
if (rc) {
dprintk(1, "%s: keycode = 0x%04x\n", __func__, ir_key);
rc_keydown(ir->rc, ir_key, 0);
}
+   return 0;
 }
 
 static void ir_work(struct work_struct *work)
 {
+   int rc;
struct IR_i2c *ir = container_of(work, struct IR_i2c, work.work);
 
-   ir_key_poll(ir);
+   rc = ir_key_poll(ir);
+   if (rc == -ENODEV) {
+   rc_unregister_device(ir->rc);
+   ir->rc = NULL;
+   return;
+   }
+
schedule_delayed_work(&ir->work, 
msecs_to_jiffies(ir->polling_interval));
 }
 
@@ -446,7 +454,8 @@ static int ir_remove(struct i2c_client *client)
cancel_delayed_work_sync(&ir->work);
 
/* unregister device */
-   rc_unregister_device(ir->rc);
+   if (ir->rc)
+   rc_unregister_device(ir->rc);
 
/* free memory */
kfree(ir);
-- 
1.7.7.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 4/6] [media] cx231xx: Fix unregister logic

[Mauro Carvalho Chehab]

There are several weirdness at the unregister logic.

First of all, IR has a poll thread. This thread needs to be
removed, as it uses some resources associated to the main driver.
So, the driver needs to explicitly unregister the I2C client for
ir-kbd-i2c.

If, for some reason, the driver needs to wait for a close()
to happen, not all memories will be freed, because the free
logic were in the wrong place.

Also, v4l2_device_unregister() seems to be called too early,
as devices are still using it.

Finally, even with the device disconnected, there is one
USB function call that will still try to talk with it.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/video/cx231xx/cx231xx-cards.c |   29 ++
 drivers/media/video/cx231xx/cx231xx-core.c  |3 ++
 drivers/media/video/cx231xx/cx231xx-input.c |5 +++-
 drivers/media/video/cx231xx/cx231xx.h   |1 +
 drivers/media/video/ir-kbd-i2c.c|8 ---
 5 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c 
b/drivers/media/video/cx231xx/cx231xx-cards.c
index 2a28882..bd82f01 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -843,15 +843,25 @@ void cx231xx_release_resources(struct cx231xx *dev)
 
cx231xx_remove_from_devlist(dev);
 
+   cx231xx_ir_exit(dev);
+
/* Release I2C buses */
cx231xx_dev_uninit(dev);
 
-   cx231xx_ir_exit(dev);
+   /* delete v4l2 device */
+   v4l2_device_unregister(&dev->v4l2_dev);
 
usb_put_dev(dev->udev);
 
/* Mark device as unused */
cx231xx_devused &= ~(1 << dev->devno);
+
+   kfree(dev->video_mode.alt_max_pkt_size);
+   kfree(dev->vbi_mode.alt_max_pkt_size);
+   kfree(dev->sliced_cc_mode.alt_max_pkt_size);
+   kfree(dev->ts1_mode.alt_max_pkt_size);
+   kfree(dev);
+   dev = NULL;
 }
 
 /*
@@ -1329,9 +1339,6 @@ static void cx231xx_usb_disconnect(struct usb_interface 
*interface)
 
flush_request_modules(dev);
 
-   /* delete v4l2 device */
-   v4l2_device_unregister(&dev->v4l2_dev);
-
/* wait until all current v4l2 io is finished then deallocate
   resources */
mutex_lock(&dev->lock);
@@ -1344,6 +1351,9 @@ static void cx231xx_usb_disconnect(struct usb_interface 
*interface)
 "deallocation are deferred on close.\n",
 video_device_node_name(dev->vdev));
 
+   /* Even having users, it is safe to remove the RC i2c driver */
+   cx231xx_ir_exit(dev);
+
dev->state |= DEV_MISCONFIGURED;
if (dev->USE_ISO)
cx231xx_uninit_isoc(dev);
@@ -1354,21 +1364,14 @@ static void cx231xx_usb_disconnect(struct usb_interface 
*interface)
wake_up_interruptible(&dev->wait_stream);
} else {
dev->state |= DEV_DISCONNECTED;
-   cx231xx_release_resources(dev);
}
 
cx231xx_close_extension(dev);
 
mutex_unlock(&dev->lock);
 
-   if (!dev->users) {
-   kfree(dev->video_mode.alt_max_pkt_size);
-   kfree(dev->vbi_mode.alt_max_pkt_size);
-   kfree(dev->sliced_cc_mode.alt_max_pkt_size);
-   kfree(dev->ts1_mode.alt_max_pkt_size);
-   kfree(dev);
-   dev = NULL;
-   }
+   if (!dev->users)
+   cx231xx_release_resources(dev);
 }
 
 static struct usb_driver cx231xx_usb_driver = {
diff --git a/drivers/media/video/cx231xx/cx231xx-core.c 
b/drivers/media/video/cx231xx/cx231xx-core.c
index d4457f9..39e9878 100644
--- a/drivers/media/video/cx231xx/cx231xx-core.c
+++ b/drivers/media/video/cx231xx/cx231xx-core.c
@@ -166,6 +166,9 @@ int cx231xx_send_usb_command(struct cx231xx_i2c *i2c_bus,
u8 _i2c_nostop = 0;
u8 _i2c_reserve = 0;
 
+   if (dev->state & DEV_DISCONNECTED)
+   return -ENODEV;
+
/* Get the I2C period, nostop and reserve parameters */
_i2c_period = i2c_bus->i2c_period;
_i2c_nostop = i2c_bus->i2c_nostop;
diff --git a/drivers/media/video/cx231xx/cx231xx-input.c 
b/drivers/media/video/cx231xx/cx231xx-input.c
index 8a75a90..96176e9 100644
--- a/drivers/media/video/cx231xx/cx231xx-input.c
+++ b/drivers/media/video/cx231xx/cx231xx-input.c
@@ -106,11 +106,14 @@ int cx231xx_ir_init(struct cx231xx *dev)
ir_i2c_bus = cx231xx_boards[dev->model].ir_i2c_master;
dev_dbg(&dev->udev->dev, "Trying to bind ir at bus %d, addr 0x%02x\n",
ir_i2c_bus, info.addr);
-   i2c_new_device(&dev->i2c_bus[ir_i2c_bus].i2c_adap, &info);
+   dev->ir_i2c_client = i2c_new_device(&dev->i2c_bus[ir_i2c_bus].i2c_adap, 
&info);
 
return 0;
 }
 
 void cx231xx_ir_exit(struct cx231xx *dev)
 {
+   if (dev->ir_i2c_client)
+   i2c_unregister_device(dev->ir_i2c_client);
+   dev->ir_i2c_client = NULL;
 }
diff --git a/driver

[PATCH 3/6] [media] mb86a20s: implement get_frontend()

[Mauro Carvalho Chehab]

Reports the auto-detected parameters to userspace.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb/frontends/mb86a20s.c |  196 +++-
 1 files changed, 193 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb/frontends/mb86a20s.c 
b/drivers/media/dvb/frontends/mb86a20s.c
index 82d3301..38778a8 100644
--- a/drivers/media/dvb/frontends/mb86a20s.c
+++ b/drivers/media/dvb/frontends/mb86a20s.c
@@ -525,16 +525,206 @@ static int mb86a20s_set_frontend(struct dvb_frontend *fe)
return rc;
 }
 
+static int mb86a20s_get_modulation(struct mb86a20s_state *state,
+  unsigned layer)
+{
+   int rc;
+   static unsigned char reg[] = {
+   [0] = 0x86, /* Layer A */
+   [1] = 0x8a, /* Layer B */
+   [2] = 0x8e, /* Layer C */
+   };
+
+   if (layer > ARRAY_SIZE(reg))
+   return -EINVAL;
+   rc = mb86a20s_writereg(state, 0x6d, reg[layer]);
+   if (rc < 0)
+   return rc;
+   rc = mb86a20s_readreg(state, 0x6e);
+   if (rc < 0)
+   return rc;
+   switch ((rc & 0x70) >> 4) {
+   case 0:
+   return DQPSK;
+   case 1:
+   return QPSK;
+   case 2:
+   return QAM_16;
+   case 3:
+   return QAM_64;
+   default:
+   return QAM_AUTO;
+   }
+}
+
+static int mb86a20s_get_fec(struct mb86a20s_state *state,
+   unsigned layer)
+{
+   int rc;
+
+   static unsigned char reg[] = {
+   [0] = 0x87, /* Layer A */
+   [1] = 0x8b, /* Layer B */
+   [2] = 0x8f, /* Layer C */
+   };
+
+   if (layer > ARRAY_SIZE(reg))
+   return -EINVAL;
+   rc = mb86a20s_writereg(state, 0x6d, reg[layer]);
+   if (rc < 0)
+   return rc;
+   rc = mb86a20s_readreg(state, 0x6e);
+   if (rc < 0)
+   return rc;
+   switch (rc) {
+   case 0:
+   return FEC_1_2;
+   case 1:
+   return FEC_2_3;
+   case 2:
+   return FEC_3_4;
+   case 3:
+   return FEC_5_6;
+   case 4:
+   return FEC_7_8;
+   default:
+   return FEC_AUTO;
+   }
+}
+
+static int mb86a20s_get_interleaving(struct mb86a20s_state *state,
+unsigned layer)
+{
+   int rc;
+
+   static unsigned char reg[] = {
+   [0] = 0x88, /* Layer A */
+   [1] = 0x8c, /* Layer B */
+   [2] = 0x90, /* Layer C */
+   };
+
+   if (layer > ARRAY_SIZE(reg))
+   return -EINVAL;
+   rc = mb86a20s_writereg(state, 0x6d, reg[layer]);
+   if (rc < 0)
+   return rc;
+   rc = mb86a20s_readreg(state, 0x6e);
+   if (rc < 0)
+   return rc;
+   if (rc > 3)
+   return -EINVAL; /* Not used */
+   return rc;
+}
+
+static int mb86a20s_get_segment_count(struct mb86a20s_state *state,
+ unsigned layer)
+{
+   int rc, count;
+
+   static unsigned char reg[] = {
+   [0] = 0x89, /* Layer A */
+   [1] = 0x8d, /* Layer B */
+   [2] = 0x91, /* Layer C */
+   };
+
+   if (layer > ARRAY_SIZE(reg))
+   return -EINVAL;
+   rc = mb86a20s_writereg(state, 0x6d, reg[layer]);
+   if (rc < 0)
+   return rc;
+   rc = mb86a20s_readreg(state, 0x6e);
+   if (rc < 0)
+   return rc;
+   count = (rc >> 4) & 0x0f;
+
+   return count;
+}
+
 static int mb86a20s_get_frontend(struct dvb_frontend *fe)
 {
+   struct mb86a20s_state *state = fe->demodulator_priv;
struct dtv_frontend_properties *p = &fe->dtv_property_cache;
+   int i, rc;
 
-   /* FIXME: For now, it does nothing */
-
+   /* Fixed parameters */
+   p->delivery_system = SYS_ISDBT;
p->bandwidth_hz = 600;
+
+   if (fe->ops.i2c_gate_ctrl)
+   fe->ops.i2c_gate_ctrl(fe, 0);
+
+   /* Check for partial reception */
+   rc = mb86a20s_writereg(state, 0x6d, 0x85);
+   if (rc >= 0)
+   rc = mb86a20s_readreg(state, 0x6e);
+   if (rc >= 0)
+   p->isdbt_partial_reception = (rc & 0x10) ? 1 : 0;
+
+   /* Get per-layer data */
+   p->isdbt_layer_enabled = 0;
+   for (i = 0; i < 3; i++) {
+   rc = mb86a20s_get_segment_count(state, i);
+   if (rc >= 0 && rc < 14)
+   p->layer[i].segment_count = rc;
+   if (rc == 0x0f)
+   continue;
+   p->isdbt_layer_enabled |= 1 << i;
+   rc = mb86a20s_get_modulation(state, i);
+   if (rc >= 0)
+   p->layer[i].modulation = rc;
+   rc = mb86a20s_get_fec(state, i);
+

[PATCH 6/6] [media] cx231xx: fix device disconnect checks

[Mauro Carvalho Chehab]

The driver were using DEV_MISCONFIGURED on some places, and
DEV_DISCONNECTED on others. In a matter of fact, DEV_MISCONFIGURED
were set only during the usb disconnect callback, with
was confusing.

Also, the alsa driver never checks if the device is present,
before doing some dangerous things.

Remove DEV_MISCONFIGURED, replacing it by DEV_DISCONNECTED.

Also, fixes the other usecases for DEV_DISCONNECTED.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/video/cx231xx/cx231xx-audio.c |   20 
 drivers/media/video/cx231xx/cx231xx-cards.c |5 ++---
 drivers/media/video/cx231xx/cx231xx-dvb.c   |4 ++--
 drivers/media/video/cx231xx/cx231xx-vbi.c   |2 +-
 drivers/media/video/cx231xx/cx231xx-video.c |   14 --
 drivers/media/video/cx231xx/cx231xx.h   |1 -
 6 files changed, 29 insertions(+), 17 deletions(-)

diff --git a/drivers/media/video/cx231xx/cx231xx-audio.c 
b/drivers/media/video/cx231xx/cx231xx-audio.c
index 30d13c1..e5742a0 100644
--- a/drivers/media/video/cx231xx/cx231xx-audio.c
+++ b/drivers/media/video/cx231xx/cx231xx-audio.c
@@ -111,6 +111,9 @@ static void cx231xx_audio_isocirq(struct urb *urb)
struct snd_pcm_substream *substream;
struct snd_pcm_runtime *runtime;
 
+   if (dev->state & DEV_DISCONNECTED)
+   return;
+
switch (urb->status) {
case 0: /* success */
case -ETIMEDOUT:/* NAK */
@@ -196,6 +199,9 @@ static void cx231xx_audio_bulkirq(struct urb *urb)
struct snd_pcm_substream *substream;
struct snd_pcm_runtime *runtime;
 
+   if (dev->state & DEV_DISCONNECTED)
+   return;
+
switch (urb->status) {
case 0: /* success */
case -ETIMEDOUT:/* NAK */
@@ -273,6 +279,9 @@ static int cx231xx_init_audio_isoc(struct cx231xx *dev)
 
cx231xx_info("%s: Starting ISO AUDIO transfers\n", __func__);
 
+   if (dev->state & DEV_DISCONNECTED)
+   return -ENODEV;
+
sb_size = CX231XX_ISO_NUM_AUDIO_PACKETS * dev->adev.max_pkt_size;
 
for (i = 0; i < CX231XX_AUDIO_BUFS; i++) {
@@ -331,6 +340,9 @@ static int cx231xx_init_audio_bulk(struct cx231xx *dev)
 
cx231xx_info("%s: Starting BULK AUDIO transfers\n", __func__);
 
+   if (dev->state & DEV_DISCONNECTED)
+   return -ENODEV;
+
sb_size = CX231XX_NUM_AUDIO_PACKETS * dev->adev.max_pkt_size;
 
for (i = 0; i < CX231XX_AUDIO_BUFS; i++) {
@@ -432,6 +444,11 @@ static int snd_cx231xx_capture_open(struct 
snd_pcm_substream *substream)
return -ENODEV;
}
 
+   if (dev->state & DEV_DISCONNECTED) {
+   cx231xx_errdev("Can't open. the device was removed.\n");
+   return -ENODEV;
+   }
+
/* Sets volume, mute, etc */
dev->mute = 0;
 
@@ -571,6 +588,9 @@ static int snd_cx231xx_capture_trigger(struct 
snd_pcm_substream *substream,
struct cx231xx *dev = snd_pcm_substream_chip(substream);
int retval;
 
+   if (dev->state & DEV_DISCONNECTED)
+   return -ENODEV;
+
spin_lock(&dev->adev.slock);
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c 
b/drivers/media/video/cx231xx/cx231xx-cards.c
index 1f2fbbf..7577e6e 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -1337,6 +1337,8 @@ static void cx231xx_usb_disconnect(struct usb_interface 
*interface)
if (!dev->udev)
return;
 
+   dev->state |= DEV_DISCONNECTED;
+
flush_request_modules(dev);
 
/* wait until all current v4l2 io is finished then deallocate
@@ -1354,16 +1356,13 @@ static void cx231xx_usb_disconnect(struct usb_interface 
*interface)
/* Even having users, it is safe to remove the RC i2c driver */
cx231xx_ir_exit(dev);
 
-   dev->state |= DEV_MISCONFIGURED;
if (dev->USE_ISO)
cx231xx_uninit_isoc(dev);
else
cx231xx_uninit_bulk(dev);
-   dev->state |= DEV_DISCONNECTED;
wake_up_interruptible(&dev->wait_frame);
wake_up_interruptible(&dev->wait_stream);
} else {
-   dev->state |= DEV_DISCONNECTED;
}
 
cx231xx_close_extension(dev);
diff --git a/drivers/media/video/cx231xx/cx231xx-dvb.c 
b/drivers/media/video/cx231xx/cx231xx-dvb.c
index da9a4a0..7c4e360 100644
--- a/drivers/media/video/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/video/cx231xx/cx231xx-dvb.c
@@ -196,7 +196,7 @@ static inline int dvb_isoc_copy(struct cx231xx *dev, struct 
urb *urb)
if (!dev)
return 0;
 
-   if ((dev->state & DEV_DISCONNECTED) || (dev->state & DEV_MISCONFIGURED))
+   if (dev->state & DEV_DISCONNECTED)
return 0;
 
if (urb->status < 0) {
@@ -228,7 +228,7 @@ stat

[PATCH 1/6] [media] tda18271-fe: Fix support for ISDB-T

[Mauro Carvalho Chehab]

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/common/tuners/tda18271-fe.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/media/common/tuners/tda18271-fe.c 
b/drivers/media/common/tuners/tda18271-fe.c
index d3d91ea..7e30304 100644
--- a/drivers/media/common/tuners/tda18271-fe.c
+++ b/drivers/media/common/tuners/tda18271-fe.c
@@ -946,6 +946,10 @@ static int tda18271_set_params(struct dvb_frontend *fe)
map = &std_map->atsc_6;
bw = 600;
break;
+   case SYS_ISDBT:
+   map = &std_map->dvbt_6;
+   bw = 600;
+   break;
case SYS_DVBT:
case SYS_DVBT2:
if (bw <= 600) {
-- 
1.7.7.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

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Steven Toth]

> status SCVYL | signal  | snr 00ee | ber  | unc  |
> FE_HAS_LOCK
> status SCVYL | signal  | snr 00f0 | ber  | unc  |
> FE_HAS_LOCK
>
> and when it stopped working, this time an hour later, nothing had changed.
> In fact, it looks like the driver keeps lock even when it's not recording at
> all.
>
> Any ideas anyone? Looks like the tuner is OK

It sounds signal, hardware or heat/environmental related, unlikely to
be driver related.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
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][BUG] it913x-fe fix typo error making SNR levels unstable.

[Malcolm Priestley]

Fix error where SNR unstable and jumps levels.

Signed-off-by: Malcolm Priestley 
---
 drivers/media/dvb/frontends/it913x-fe.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb/frontends/it913x-fe.c 
b/drivers/media/dvb/frontends/it913x-fe.c
index 7290801..ccc36bf 100644
--- a/drivers/media/dvb/frontends/it913x-fe.c
+++ b/drivers/media/dvb/frontends/it913x-fe.c
@@ -525,7 +525,7 @@ static int it913x_fe_read_snr(struct dvb_frontend *fe, u16 
*snr)
 
ret = it913x_read_reg(state, 0x2c, reg, sizeof(reg));
 
-   snr_val = (u32)(reg[2] << 16) | (reg[1] < 8) | reg[0];
+   snr_val = (u32)(reg[2] << 16) | (reg[1] << 8) | reg[0];
 
ret |= it913x_read_reg(state, 0xf78b, reg, 1);
if (reg[0])
-- 
1.7.7.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: [PATCH 1/1] v4l: Ignore ctrl_class in the control framework

[Sakari Ailus]

Hi Hans,

Hans Verkuil wrote:

On Tuesday, January 10, 2012 20:14:22 Sakari Ailus wrote:

Back in the old days there was probably a reason to require that controls
that are being used to access using VIDIOC_{TRY,G,S}_EXT_CTRLS belonged to
the same class. These days such reason does not exist, or at least cannot be
remembered, and concrete examples of the opposite can be seen: a single
(sub)device may well offer controls that belong to different classes and
there is no reason to deny changing them atomically.

This patch removes the check for v4l2_ext_controls.ctrl_class in the control
framework. The control framework issues the s_ctrl() op to the drivers
separately so changing the behaviour does not really change how this works
from the drivers' perspective.


What is the rationale of this patch? It does change the behavior of the API.
There are still some drivers that use the extended control API without the
control framework (pvrusb2, and some other cx2341x-based drivers), and that
do test the ctrl_class argument.


These drivers still don't use the control framework. I don't see benefit 
in checking the class for those drivers that don't really care about it.


Also, to be able to set controls without artificial limitations 
applications have to set the ctrl_class field on some devices and on 
some they must not.



I don't see any substantial gain by changing the current behavior of the
control framework.

Apps can just set ctrl_class to 0 and then the control framework will no
longer check the control class. And yes, this still has to be properly
documented in the spec.


That's a good point, indeed. Should the spec then say "on some drivers 
you must set it while on some you must not"? The difficulty, albeit not 
sure if it's a practical one, is that I don't think there's anything 
that would hint applications into which of the two classes a driver 
belongs to.



The reason for the ctrl_class check is that without the control framework it
was next to impossible to allow atomic setting of controls of different
classes, since control of different classes would typically also be handled
by different drivers. By limiting the controls to one class it made it much
easier for drivers to implement this API.


Ok. But I don't think this patch would have any effect on those drivers.

Regards,

--
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: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Jim Darby]

On 10/01/12 13:54, Steven Toth wrote:

The Nanostick works fine for between 5 and 25 minutes and then without any
error messages cuts out. The TS drops to a tiny stream of non-TS data. It
seems to contain a lot of 0x00s and 0xffs.

What does femon show for demodulator statistics?

Well... I downloaded the latest dvb-apps via mecurial from linuxtv.org 
and the following happened at the start while it was working:


status SCVYL | signal  | snr 00ef | ber  | unc  | 
FE_HAS_LOCK
status SCVYL | signal  | snr 00f1 | ber  | unc  | 
FE_HAS_LOCK
status SCVYL | signal  | snr 00ee | ber  | unc  | 
FE_HAS_LOCK
status SCVYL | signal  | snr 00f0 | ber  | unc  | 
FE_HAS_LOCK
status SCVYL | signal  | snr 00f2 | ber  | unc  | 
FE_HAS_LOCK
status SCVYL | signal  | snr 00ee | ber  | unc  | 
FE_HAS_LOCK
status SCVYL | signal  | snr 00f0 | ber  | unc  | 
FE_HAS_LOCK


and when it stopped working, this time an hour later, nothing had 
changed. In fact, it looks like the driver keeps lock even when it's not 
recording at all.


Any ideas anyone? Looks like the tuner is OK

The thing that's really confusing me is the totally random amounts of 
time it takes before it fails. This time it was over an hour. For 
reference though this was the first time I'd tried it with standard 
definition transmissions. Not only lower data rate but also DVB-T rather 
than DVB-T2.


Many thanks,

Jim.
--
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 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

[Mauro Carvalho Chehab]

On 10-01-2012 19:45, Antti Palosaari wrote:
> On 01/05/2012 05:37 PM, Mauro Carvalho Chehab wrote:
>> With all these series applied, it is now possible to use frontend 0
>> for all delivery systems. As the current tools don't support changing
>> the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
>> be used to change between them:
>>
>> For example, to use DVB-T with the standard scan:
>>
>> $ ./dvb-fe-tool -d DVBT&&  scan /usr/share/dvb/dvb-t/au-Adelaide
>>
>> [1] 
>> http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/dvb-utils
> 
> I tested that now using nanoStick T2 cxd2820r driver. I got it working 
> somehow, but I suspect there is some bugs at least for DVB-C. But forget 
> those as now.

Well, we need to hardly test the DVB drivers after a 200+ patch series.
Regressions will happen. I've cached a few already, but I'm sure there
are others that are not that trivial.

> As it now registers only one frontend I must switch mode using dvb-fe-tool 
> when I want to use DVB-C. Argh.
> 
> I don't see reason why it was needed to remove old DVB-C frontend1. Why it 
> wasn't possible to leave FE1
> as it was and enhance only functionality of FE0 like it is now? For that 
> strategy we doesn't break old set-ups as now happens.

This were discussed in the past:

http://www.spinics.net/lists/linux-media/msg35542.html

In fact, I've proposed this strategy as one of the alternatives for MFE
(approach 4):

> Approach 4) fe0 is a frontend "superset"
>
> *adapter0
> *frontend0 (DVB-S/DVB-S2/DVB-T/DVB-T2/DVB-C/ISDB-T) - aka: FE superset
> *frontend1 (DVB-S/DVB-S2)
> *frontend2 (DVB-T/DVB-T2)
> *frontend3 (DVB-C)
> *frontend4 (ISDB-T)

The arguments where that it would be confusing and it could be complex
to maintain.

I think that the better is to see what happens with the applications
during this kernel cycle, and then decide what to do. A quick fix for 
the issue at the applications side is very easy: for DVBv5.5 and upper,
just try to force the frontend to change to the new delivery system
via a DVBv5 call. If it accepts, it is a multi frontend devnode.

A better fix is to also implement DTV_ENUM_DELSYS.

Regards,
Mauro
--
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: [ANNOUNCE] DVBv5 tools version 0.0.1

[Mauro Carvalho Chehab]

On 10-01-2012 19:36, Antti Palosaari wrote:
> Behaviour of new FE is strange for my eyes. Could you look and explain if it 
> is intentional?
> 
> [crope@localhost dvb]$ ./dvb-fe-tool
> Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:
> CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 
> CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO 
> CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO 
> CAN_QPSK CAN_TRANSMISSION_MODE_AUTO
> DVB API Version 5.5, Current v5 delivery system: DVBT
> Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A
> [crope@localhost dvb]$ czap "MTV3 "
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> reading channels from file '/home/crope/.czap/channels.conf'
>  11 MTV3 :33000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3
>  11 MTV3 : f 33000, s 6875000, i 2, fec 0, qam 4, v 0x131, a 0x231, s 0x3
> ERROR: frontend device is not a QAM (DVB-C) device

The selected delivery system is DVB-T. As czap doesn't have any code to
force it to DVB-C, this is expected.

Basically, czap needs a patch like this one:
http://linuxtv.org/hg/dvb-apps/rev/0c9932885287

(I've made the patch for scan just as an example, but I'll hardly have 
enough time to fix it everything inside dvb-apps)

> [crope@localhost dvb]$ ./dvb-fe-tool --set-delsys=DVBC/ANNEX_A
> Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:
> CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 
> CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO 
> CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO 
> CAN_QPSK CAN_TRANSMISSION_MODE_AUTO
> DVB API Version 5.5, Current v5 delivery system: DVBT
> Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A
> Changing delivery system to: DVBC/ANNEX_A
> [crope@localhost dvb]$ ./dvb-fe-tool
> Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:
> CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 
> CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO 
> CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO 
> CAN_QPSK CAN_TRANSMISSION_MODE_AUTO
> DVB API Version 5.5, Current v5 delivery system: DVBC/ANNEX_A
> Supported delivery systems: DVBT DVBT2 [DVBC/ANNEX_A]
> [crope@localhost dvb]$ czap "MTV3 "
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> reading channels from file '/home/crope/.czap/channels.conf'
>  11 MTV3 :33000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3
>  11 MTV3 : f 33000, s 6875000, i 2, fec 0, qam 4, v 0x131, a 0x231, s 0x3
> status 00 | signal  | snr 00c6 | ber  | unc  |

Ok, it worked.

> [crope@localhost dvb]$ ./dvb-fe-tool
> Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:
> CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 
> CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO 
> CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO 
> CAN_QPSK CAN_TRANSMISSION_MODE_AUTO
> DVB API Version 5.5, Current v5 delivery system: DVBT
> Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A

That's weird. The dvb_frontend_clear_cache() returns the delivery
system to its original state.

The enclosed patch will likely fix this issue.

-
[PATCH] don't reset the delivery system on DTV_CLEAR

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index a904793..4ff4b43 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -909,7 +909,6 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
 
c->state = DTV_CLEAR;
 
-   c->delivery_system = fe->ops.delsys[0];
dprintk("%s() Clearing cache for delivery system %d\n", __func__,
c->delivery_system);
 
@@ -2377,6 +2376,8 @@ int dvb_register_frontend(struct dvb_adapter* dvb,
 * Initialize the cache to the proper values according with the
 * first supported delivery system (ops->delsys[0])
 */
+
+   c->delivery_system = fe->ops.delsys[0];
dvb_frontend_clear_cache(fe);
 
mutex_unlock(&frontend_mutex);

--
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 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

[Antti Palosaari]

On 01/05/2012 05:37 PM, Mauro Carvalho Chehab wrote:

With all these series applied, it is now possible to use frontend 0
for all delivery systems. As the current tools don't support changing
the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
be used to change between them:

For example, to use DVB-T with the standard scan:

$ ./dvb-fe-tool -d DVBT&&  scan /usr/share/dvb/dvb-t/au-Adelaide

[1] 
http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/dvb-utils


I tested that now using nanoStick T2 cxd2820r driver. I got it working 
somehow, but I suspect there is some bugs at least for DVB-C. But forget 
those as now.


As it now registers only one frontend I must switch mode using 
dvb-fe-tool when I want to use DVB-C. Argh.


I don't see reason why it was needed to remove old DVB-C frontend1. Why 
it wasn't possible to leave FE1 as it was and enhance only functionality 
of FE0 like it is now? For that strategy we doesn't break old set-ups as 
now happens.


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: [ANNOUNCE] DVBv5 tools version 0.0.1

[Antti Palosaari]

Behaviour of new FE is strange for my eyes. Could you look and explain 
if it is intentional?


[crope@localhost dvb]$ ./dvb-fe-tool
Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:
	CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 
CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO 
CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 
CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO

DVB API Version 5.5, Current v5 delivery system: DVBT
Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A
[crope@localhost dvb]$ czap "MTV3 "
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/home/crope/.czap/channels.conf'
 11 MTV3 :33000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3
 11 MTV3 : f 33000, s 6875000, i 2, fec 0, qam 4, v 0x131, a 0x231, 
s 0x3

ERROR: frontend device is not a QAM (DVB-C) device
[crope@localhost dvb]$ ./dvb-fe-tool --set-delsys=DVBC/ANNEX_A
Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:
	CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 
CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO 
CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 
CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO

DVB API Version 5.5, Current v5 delivery system: DVBT
Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A
Changing delivery system to: DVBC/ANNEX_A
[crope@localhost dvb]$ ./dvb-fe-tool
Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:
	CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 
CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO 
CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 
CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO

DVB API Version 5.5, Current v5 delivery system: DVBC/ANNEX_A
Supported delivery systems: DVBT DVBT2 [DVBC/ANNEX_A]
[crope@localhost dvb]$ czap "MTV3 "
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/home/crope/.czap/channels.conf'
 11 MTV3 :33000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3
 11 MTV3 : f 33000, s 6875000, i 2, fec 0, qam 4, v 0x131, a 0x231, 
s 0x3

status 00 | signal  | snr 00c6 | ber  | unc  |
^C
[crope@localhost dvb]$ ./dvb-fe-tool
Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:
	CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 
CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO 
CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 
CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO

DVB API Version 5.5, Current v5 delivery system: DVBT
Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A
[crope@localhost dvb]$ czap "MTV3 "
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/home/crope/.czap/channels.conf'
 11 MTV3 :33000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3
 11 MTV3 : f 33000, s 6875000, i 2, fec 0, qam 4, v 0x131, a 0x231, 
s 0x3

ERROR: frontend device is not a QAM (DVB-C) device
[crope@localhost dvb]$ ./dvb-fe-tool
Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:
	CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 
CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO 
CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 
CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO

DVB API Version 5.5, Current v5 delivery system: DVBT
Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A
[crope@localhost dvb]$

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

[PATCH] [media] dvb_ca_en50221: fix compilation breakage

[Mauro Carvalho Chehab]

As reported by Toralf:

the build failed with :
  CC [M]  drivers/media/dvb/dvb-core/dvb_ca_en50221.o
In file included from arch/x86/include/asm/uaccess.h:573:0,
 from include/linux/poll.h:14,
 from drivers/media/dvb/dvb-core/dvbdev.h:27,
 from drivers/media/dvb/dvb-core/dvb_ca_en50221.h:27,
 from drivers/media/dvb/dvb-core/dvb_ca_en50221.c:41:
In function "copy_from_user", inlined from "dvb_ca_en50221_io_write" at 
drivers/media/dvb/dvb-core/dvb_ca_en50221.c:1314:26: 
arch/x86/include/asm/uaccess_32.h:211:26: error: call to 
"copy_from_user_overflow" declared with attribute error: copy_from_user() 
buffer size is not provably correct

Reported-by: Toralf Foerster 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb/dvb-core/dvb_ca_en50221.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_ca_en50221.c 
b/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
index 7ea517b..9be65a3 100644
--- a/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
+++ b/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
@@ -1306,6 +1306,10 @@ static ssize_t dvb_ca_en50221_io_write(struct file *file,
/* fragment the packets & store in the buffer */
while (fragpos < count) {
fraglen = ca->slot_info[slot].link_buf_size - 2;
+   if (fraglen < 0)
+   break;
+   if (fraglen > HOST_LINK_BUF_SIZE - 2)
+   fraglen = HOST_LINK_BUF_SIZE - 2;
if ((count - fragpos) < fraglen)
fraglen = count - fragpos;
 
-- 
1.7.7.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

Re: [PATCH 1/1] v4l: Ignore ctrl_class in the control framework

[Hans Verkuil]

Hi Sakari,

On Tuesday, January 10, 2012 20:14:22 Sakari Ailus wrote:
> Back in the old days there was probably a reason to require that controls
> that are being used to access using VIDIOC_{TRY,G,S}_EXT_CTRLS belonged to
> the same class. These days such reason does not exist, or at least cannot be
> remembered, and concrete examples of the opposite can be seen: a single
> (sub)device may well offer controls that belong to different classes and
> there is no reason to deny changing them atomically.
> 
> This patch removes the check for v4l2_ext_controls.ctrl_class in the control
> framework. The control framework issues the s_ctrl() op to the drivers
> separately so changing the behaviour does not really change how this works
> from the drivers' perspective.

What is the rationale of this patch? It does change the behavior of the API.
There are still some drivers that use the extended control API without the
control framework (pvrusb2, and some other cx2341x-based drivers), and that
do test the ctrl_class argument.

I don't see any substantial gain by changing the current behavior of the
control framework.

Apps can just set ctrl_class to 0 and then the control framework will no
longer check the control class. And yes, this still has to be properly
documented in the spec.

The reason for the ctrl_class check is that without the control framework it
was next to impossible to allow atomic setting of controls of different
classes, since control of different classes would typically also be handled
by different drivers. By limiting the controls to one class it made it much
easier for drivers to implement this API.

Regards,

Hans

> 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/video/v4l2-ctrls.c |   18 +-
>  1 files changed, 5 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/video/v4l2-ctrls.c 
> b/drivers/media/video/v4l2-ctrls.c
> index da1f4c2..fff3bb3 100644
> --- a/drivers/media/video/v4l2-ctrls.c
> +++ b/drivers/media/video/v4l2-ctrls.c
> @@ -1855,9 +1855,6 @@ static int prepare_ext_ctrls(struct v4l2_ctrl_handler 
> *hdl,
>  
>   cs->error_idx = i;
>  
> - if (cs->ctrl_class && V4L2_CTRL_ID2CLASS(id) != cs->ctrl_class)
> - return -EINVAL;
> -
>   /* Old-style private controls are not allowed for
>  extended controls */
>   if (id >= V4L2_CID_PRIVATE_BASE)
> @@ -1918,13 +1915,10 @@ static int prepare_ext_ctrls(struct v4l2_ctrl_handler 
> *hdl,
>  }
>  
>  /* Handles the corner case where cs->count == 0. It checks whether the
> -   specified control class exists. If that class ID is 0, then it checks
> -   whether there are any controls at all. */
> -static int class_check(struct v4l2_ctrl_handler *hdl, u32 ctrl_class)
> +   there are any controls at all. */
> +static int handler_check(struct v4l2_ctrl_handler *hdl)
>  {
> - if (ctrl_class == 0)
> - return list_empty(&hdl->ctrl_refs) ? -EINVAL : 0;
> - return find_ref_lock(hdl, ctrl_class | 1) ? 0 : -EINVAL;
> + return list_empty(&hdl->ctrl_refs) ? -EINVAL : 0;
>  }
>  
>  
> @@ -1938,13 +1932,12 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, 
> struct v4l2_ext_controls *cs
>   int i, j;
>  
>   cs->error_idx = cs->count;
> - cs->ctrl_class = V4L2_CTRL_ID2CLASS(cs->ctrl_class);
>  
>   if (hdl == NULL)
>   return -EINVAL;
>  
>   if (cs->count == 0)
> - return class_check(hdl, cs->ctrl_class);
> + return handler_check(hdl);
>  
>   if (cs->count > ARRAY_SIZE(helper)) {
>   helpers = kmalloc(sizeof(helper[0]) * cs->count, GFP_KERNEL);
> @@ -2160,13 +2153,12 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh, 
> struct v4l2_ctrl_handler *hdl,
>   int ret;
>  
>   cs->error_idx = cs->count;
> - cs->ctrl_class = V4L2_CTRL_ID2CLASS(cs->ctrl_class);
>  
>   if (hdl == NULL)
>   return -EINVAL;
>  
>   if (cs->count == 0)
> - return class_check(hdl, cs->ctrl_class);
> + return handler_check(hdl);
>  
>   if (cs->count > ARRAY_SIZE(helper)) {
>   helpers = kmalloc(sizeof(helper[0]) * cs->count, GFP_KERNEL);
> 
--
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: Hauppauge HVR-930C problems

[Mauro Carvalho Chehab]

On 10-01-2012 18:23, Mihai Dobrescu wrote:
> I can't find dvb-fe-util tool.

http://git.linuxtv.org/v4l-utils.git/blob/ad284d9ef6600e091515b0abd7cec64736097265:/utils/dvb/dvb-fe-tool.c

Regards,
Mauro

> 
> On Tue, Jan 10, 2012 at 9:41 PM, Mauro Carvalho Chehab
>  wrote:
>> On 10-01-2012 17:30, Mihai Dobrescu wrote:
>>> Hello,
>>>
>>> Just compiled the latest again, but still no difference.
>>> kaffeine doesn't see any source in channels dialog, two devices are in
>>> 'Configure Television' dialog: DRXK DVB-C - device not connected - as
>>> Device 1 and DRXK DVB-C DVB-T as Device 2. Concerning the last one, no
>>> source is selected, as I am in Romania, which is not in the list
>>> scan_w finds nothing.
>>>
>>> What should I do next?
>>
>> Kaffeine doesn't work with MFE tuners (at least not the version I have).
>> It only sees one delivery system.
>>
>> If you're using the very latest version of the driver (the one at the
>> media-build tree), you can use the dvb-fe-util tool to change
>> the delivery system to DVB-C or to DVB-T.
>>
>> The tool is now part of the v4l-utils.
>>
>> You may also request a Kaffeine developer or to submit a patch for it,
>> in order to add support on it to detect the frontend supported
>> delivery systems and to change it dynamically.
>>
>>>
>>> Regards, Mike.
>>>
>>> On Tue, Jan 10, 2012 at 4:42 PM, Fredrik Lingvall
>>>  wrote:
 On 12/25/11 16:56, Fredrik Lingvall wrote:
>
> On 12/18/11 10:20, Fredrik Lingvall wrote:
>>
>> On 12/17/11 20:53, Mihai Dobrescu wrote:
>>>
>>>
>>>
>>>
>>> Mihai,
>>>
>>> I got some success. I did this,
>>>
>>> # cd /usr/src (for example)
>>>
>>> # git clone git://linuxtv.org/media_build.git
>>>
>>> # emerge dev-util/patchutils
>>> # emerge Proc-ProcessTable
>>>
>>> # cd media_build
>>> # ./build
>>> # make install
>>>
>>> Which will install the latest driver on your running kernel (just in
>>> case
>>> make sure /usr/src/linux points to your running kernel sources). Then
>>> reboot.
>>>
>>> You should now see that (among other) modules have loaded:
>>>
>>> # lsmod
>>>
>>> 
>>>
>>> em28xx 93528  1 em28xx_dvb
>>> v4l2_common 5254  1 em28xx
>>> videobuf_vmalloc4167  1 em28xx
>>> videobuf_core  15151  2 em28xx,videobuf_vmalloc
>>>
>>> Then try w_scan and dvbscan etc. I got mythtv to scan too now. There
>>> were
>>> some warnings and timeouts and I'm not sure if this is normal or not.
>>>
>>> You can also do a dmesg -c while scanning to monitor the changes en the
>>> kernel log.
>>>
>>> Regards,
>>>
>>> /Fredrik
>>>
>>>
>>> In my case I have:
>>>
>>> lsmod |grep em2
>>> em28xx_dvb 12608  0
>>> dvb_core   76187  1 em28xx_dvb
>>> em28xx 82436  1 em28xx_dvb
>>> v4l2_common 5087  1 em28xx
>>> videodev   70123  2 em28xx,v4l2_common
>>> videobuf_vmalloc3783  1 em28xx
>>> videobuf_core  12991  2 em28xx,videobuf_vmalloc
>>> rc_core11695  11
>>>
>>> rc_hauppauge,ir_lirc_codec,ir_mce_kbd_decoder,ir_sanyo_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,em28xx,ir_nec_decoder
>>> tveeprom   12441  1 em28xx
>>> i2c_core   14232  9
>>>
>>> xc5000,drxk,em28xx_dvb,em28xx,v4l2_common,videodev,tveeprom,nvidia,i2c_i801
>>>
>>> yet, w_scan founds nothing.
>>
>>
>> I was able to scan using the "media_build" install method described above
>> but when trying to watch a free channel the image and sound was 
>> stuttering
>> severly. I have tried both MythTV and mplayer with similar results.
>>
>> I created the channel list for mplayer with:
>>
>> lintv ~ # dvbscan -x0 -fc /usr/share/dvb/dvb-c/no-Oslo-Get -o zap >
>> .mplayer/channels.conf
>>
>> And, for example,  I get this output from mplayer plus a very (blocky)
>> stuttering image and sound:
>>
>> lin-tv ~ # mplayer dvb://1@"TV8 Oslo" -ao jack
>>
>
> I did some more tests with release snapshots 2011-12-13, 2011-12-21, and
> 2011-12-25, respectively. I did this by changing
>
> LATEST_TAR :=
> http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2
> LATEST_TAR_MD5 :=
> http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2.md5
>
> in linux/Makefile to the corresponding release.
>
> Results:
>
> * linux-media-2011-12-13.tar.bz2
>
> The ./build script builds the drivers cleanly, scanning works, but
>  watching video does not work correctly.
>
> * linux-media-2011-12-21.tar.bz2
>
> The ./build script fails at the as3645a.c file (on this machine but I can
> build it on two other machines using the same

Re: Hauppauge HVR-930C problems

[Mihai Dobrescu]

I can't find dvb-fe-util tool.

On Tue, Jan 10, 2012 at 9:41 PM, Mauro Carvalho Chehab
 wrote:
> On 10-01-2012 17:30, Mihai Dobrescu wrote:
>> Hello,
>>
>> Just compiled the latest again, but still no difference.
>> kaffeine doesn't see any source in channels dialog, two devices are in
>> 'Configure Television' dialog: DRXK DVB-C - device not connected - as
>> Device 1 and DRXK DVB-C DVB-T as Device 2. Concerning the last one, no
>> source is selected, as I am in Romania, which is not in the list
>> scan_w finds nothing.
>>
>> What should I do next?
>
> Kaffeine doesn't work with MFE tuners (at least not the version I have).
> It only sees one delivery system.
>
> If you're using the very latest version of the driver (the one at the
> media-build tree), you can use the dvb-fe-util tool to change
> the delivery system to DVB-C or to DVB-T.
>
> The tool is now part of the v4l-utils.
>
> You may also request a Kaffeine developer or to submit a patch for it,
> in order to add support on it to detect the frontend supported
> delivery systems and to change it dynamically.
>
>>
>> Regards, Mike.
>>
>> On Tue, Jan 10, 2012 at 4:42 PM, Fredrik Lingvall
>>  wrote:
>>> On 12/25/11 16:56, Fredrik Lingvall wrote:

 On 12/18/11 10:20, Fredrik Lingvall wrote:
>
> On 12/17/11 20:53, Mihai Dobrescu wrote:
>>
>>
>>
>>
>> Mihai,
>>
>> I got some success. I did this,
>>
>> # cd /usr/src (for example)
>>
>> # git clone git://linuxtv.org/media_build.git
>>
>> # emerge dev-util/patchutils
>> # emerge Proc-ProcessTable
>>
>> # cd media_build
>> # ./build
>> # make install
>>
>> Which will install the latest driver on your running kernel (just in
>> case
>> make sure /usr/src/linux points to your running kernel sources). Then
>> reboot.
>>
>> You should now see that (among other) modules have loaded:
>>
>> # lsmod
>>
>> 
>>
>> em28xx                 93528  1 em28xx_dvb
>> v4l2_common             5254  1 em28xx
>> videobuf_vmalloc        4167  1 em28xx
>> videobuf_core          15151  2 em28xx,videobuf_vmalloc
>>
>> Then try w_scan and dvbscan etc. I got mythtv to scan too now. There
>> were
>> some warnings and timeouts and I'm not sure if this is normal or not.
>>
>> You can also do a dmesg -c while scanning to monitor the changes en the
>> kernel log.
>>
>> Regards,
>>
>> /Fredrik
>>
>>
>> In my case I have:
>>
>> lsmod |grep em2
>> em28xx_dvb             12608  0
>> dvb_core               76187  1 em28xx_dvb
>> em28xx                 82436  1 em28xx_dvb
>> v4l2_common             5087  1 em28xx
>> videodev               70123  2 em28xx,v4l2_common
>> videobuf_vmalloc        3783  1 em28xx
>> videobuf_core          12991  2 em28xx,videobuf_vmalloc
>> rc_core                11695  11
>>
>> rc_hauppauge,ir_lirc_codec,ir_mce_kbd_decoder,ir_sanyo_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,em28xx,ir_nec_decoder
>> tveeprom               12441  1 em28xx
>> i2c_core               14232  9
>>
>> xc5000,drxk,em28xx_dvb,em28xx,v4l2_common,videodev,tveeprom,nvidia,i2c_i801
>>
>> yet, w_scan founds nothing.
>
>
> I was able to scan using the "media_build" install method described above
> but when trying to watch a free channel the image and sound was stuttering
> severly. I have tried both MythTV and mplayer with similar results.
>
> I created the channel list for mplayer with:
>
> lintv ~ # dvbscan -x0 -fc /usr/share/dvb/dvb-c/no-Oslo-Get -o zap >
> .mplayer/channels.conf
>
> And, for example,  I get this output from mplayer plus a very (blocky)
> stuttering image and sound:
>
> lin-tv ~ # mplayer dvb://1@"TV8 Oslo" -ao jack
>

 I did some more tests with release snapshots 2011-12-13, 2011-12-21, and
 2011-12-25, respectively. I did this by changing

 LATEST_TAR :=
 http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2
 LATEST_TAR_MD5 :=
 http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2.md5

 in linux/Makefile to the corresponding release.

 Results:

 * linux-media-2011-12-13.tar.bz2

 The ./build script builds the drivers cleanly, scanning works, but
  watching video does not work correctly.

 * linux-media-2011-12-21.tar.bz2

 The ./build script fails at the as3645a.c file (on this machine but I can
 build it on two other machines using the same kernel and kernel
 2.6.39-gentoo-r3, respectively). I can build it with make menuconfig etc
 (where I disabled stuff I don't need, eg. disabling [ ] Media Controller 
 API
 (EXPERIMENTAL) ). The em28xx generate a kernel core dump though [1].

 * linux-media-2011-12-25.tar.bz2

 Same problem

Re: Hauppauge HVR-930C problems

[Mauro Carvalho Chehab]

On 10-01-2012 17:30, Mihai Dobrescu wrote:
> Hello,
> 
> Just compiled the latest again, but still no difference.
> kaffeine doesn't see any source in channels dialog, two devices are in
> 'Configure Television' dialog: DRXK DVB-C - device not connected - as
> Device 1 and DRXK DVB-C DVB-T as Device 2. Concerning the last one, no
> source is selected, as I am in Romania, which is not in the list
> scan_w finds nothing.
> 
> What should I do next?

Kaffeine doesn't work with MFE tuners (at least not the version I have). 
It only sees one delivery system.

If you're using the very latest version of the driver (the one at the
media-build tree), you can use the dvb-fe-util tool to change 
the delivery system to DVB-C or to DVB-T.

The tool is now part of the v4l-utils.

You may also request a Kaffeine developer or to submit a patch for it, 
in order to add support on it to detect the frontend supported
delivery systems and to change it dynamically.

> 
> Regards, Mike.
> 
> On Tue, Jan 10, 2012 at 4:42 PM, Fredrik Lingvall
>  wrote:
>> On 12/25/11 16:56, Fredrik Lingvall wrote:
>>>
>>> On 12/18/11 10:20, Fredrik Lingvall wrote:

 On 12/17/11 20:53, Mihai Dobrescu wrote:
>
>
>
>
> Mihai,
>
> I got some success. I did this,
>
> # cd /usr/src (for example)
>
> # git clone git://linuxtv.org/media_build.git
>
> # emerge dev-util/patchutils
> # emerge Proc-ProcessTable
>
> # cd media_build
> # ./build
> # make install
>
> Which will install the latest driver on your running kernel (just in
> case
> make sure /usr/src/linux points to your running kernel sources). Then
> reboot.
>
> You should now see that (among other) modules have loaded:
>
> # lsmod
>
> 
>
> em28xx 93528  1 em28xx_dvb
> v4l2_common 5254  1 em28xx
> videobuf_vmalloc4167  1 em28xx
> videobuf_core  15151  2 em28xx,videobuf_vmalloc
>
> Then try w_scan and dvbscan etc. I got mythtv to scan too now. There
> were
> some warnings and timeouts and I'm not sure if this is normal or not.
>
> You can also do a dmesg -c while scanning to monitor the changes en the
> kernel log.
>
> Regards,
>
> /Fredrik
>
>
> In my case I have:
>
> lsmod |grep em2
> em28xx_dvb 12608  0
> dvb_core   76187  1 em28xx_dvb
> em28xx 82436  1 em28xx_dvb
> v4l2_common 5087  1 em28xx
> videodev   70123  2 em28xx,v4l2_common
> videobuf_vmalloc3783  1 em28xx
> videobuf_core  12991  2 em28xx,videobuf_vmalloc
> rc_core11695  11
>
> rc_hauppauge,ir_lirc_codec,ir_mce_kbd_decoder,ir_sanyo_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,em28xx,ir_nec_decoder
> tveeprom   12441  1 em28xx
> i2c_core   14232  9
>
> xc5000,drxk,em28xx_dvb,em28xx,v4l2_common,videodev,tveeprom,nvidia,i2c_i801
>
> yet, w_scan founds nothing.


 I was able to scan using the "media_build" install method described above
 but when trying to watch a free channel the image and sound was stuttering
 severly. I have tried both MythTV and mplayer with similar results.

 I created the channel list for mplayer with:

 lintv ~ # dvbscan -x0 -fc /usr/share/dvb/dvb-c/no-Oslo-Get -o zap >
 .mplayer/channels.conf

 And, for example,  I get this output from mplayer plus a very (blocky)
 stuttering image and sound:

 lin-tv ~ # mplayer dvb://1@"TV8 Oslo" -ao jack

>>>
>>> I did some more tests with release snapshots 2011-12-13, 2011-12-21, and
>>> 2011-12-25, respectively. I did this by changing
>>>
>>> LATEST_TAR :=
>>> http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2
>>> LATEST_TAR_MD5 :=
>>> http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2.md5
>>>
>>> in linux/Makefile to the corresponding release.
>>>
>>> Results:
>>>
>>> * linux-media-2011-12-13.tar.bz2
>>>
>>> The ./build script builds the drivers cleanly, scanning works, but
>>>  watching video does not work correctly.
>>>
>>> * linux-media-2011-12-21.tar.bz2
>>>
>>> The ./build script fails at the as3645a.c file (on this machine but I can
>>> build it on two other machines using the same kernel and kernel
>>> 2.6.39-gentoo-r3, respectively). I can build it with make menuconfig etc
>>> (where I disabled stuff I don't need, eg. disabling [ ] Media Controller API
>>> (EXPERIMENTAL) ). The em28xx generate a kernel core dump though [1].
>>>
>>> * linux-media-2011-12-25.tar.bz2
>>>
>>> Same problem as 2011-12-21.
>>>
>>> Regards,
>>>
>>> /Fredrik
>>>
>>
>> Here's some more test results.
>>
>> I have upgraded the kernel to 3.1.6-gentoo (where I enabled DVB when I build
>> the kernel). Both
>>
>> http://linuxtv.org/downloads/drivers/linux-media-

Re: Hauppauge HVR-930C problems

[Mihai Dobrescu]

Hello,

Just compiled the latest again, but still no difference.
kaffeine doesn't see any source in channels dialog, two devices are in
'Configure Television' dialog: DRXK DVB-C - device not connected - as
Device 1 and DRXK DVB-C DVB-T as Device 2. Concerning the last one, no
source is selected, as I am in Romania, which is not in the list
scan_w finds nothing.

What should I do next?

Regards, Mike.

On Tue, Jan 10, 2012 at 4:42 PM, Fredrik Lingvall
 wrote:
> On 12/25/11 16:56, Fredrik Lingvall wrote:
>>
>> On 12/18/11 10:20, Fredrik Lingvall wrote:
>>>
>>> On 12/17/11 20:53, Mihai Dobrescu wrote:




 Mihai,

 I got some success. I did this,

 # cd /usr/src (for example)

 # git clone git://linuxtv.org/media_build.git

 # emerge dev-util/patchutils
 # emerge Proc-ProcessTable

 # cd media_build
 # ./build
 # make install

 Which will install the latest driver on your running kernel (just in
 case
 make sure /usr/src/linux points to your running kernel sources). Then
 reboot.

 You should now see that (among other) modules have loaded:

 # lsmod

 

 em28xx                 93528  1 em28xx_dvb
 v4l2_common             5254  1 em28xx
 videobuf_vmalloc        4167  1 em28xx
 videobuf_core          15151  2 em28xx,videobuf_vmalloc

 Then try w_scan and dvbscan etc. I got mythtv to scan too now. There
 were
 some warnings and timeouts and I'm not sure if this is normal or not.

 You can also do a dmesg -c while scanning to monitor the changes en the
 kernel log.

 Regards,

 /Fredrik


 In my case I have:

 lsmod |grep em2
 em28xx_dvb             12608  0
 dvb_core               76187  1 em28xx_dvb
 em28xx                 82436  1 em28xx_dvb
 v4l2_common             5087  1 em28xx
 videodev               70123  2 em28xx,v4l2_common
 videobuf_vmalloc        3783  1 em28xx
 videobuf_core          12991  2 em28xx,videobuf_vmalloc
 rc_core                11695  11

 rc_hauppauge,ir_lirc_codec,ir_mce_kbd_decoder,ir_sanyo_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,em28xx,ir_nec_decoder
 tveeprom               12441  1 em28xx
 i2c_core               14232  9

 xc5000,drxk,em28xx_dvb,em28xx,v4l2_common,videodev,tveeprom,nvidia,i2c_i801

 yet, w_scan founds nothing.
>>>
>>>
>>> I was able to scan using the "media_build" install method described above
>>> but when trying to watch a free channel the image and sound was stuttering
>>> severly. I have tried both MythTV and mplayer with similar results.
>>>
>>> I created the channel list for mplayer with:
>>>
>>> lintv ~ # dvbscan -x0 -fc /usr/share/dvb/dvb-c/no-Oslo-Get -o zap >
>>> .mplayer/channels.conf
>>>
>>> And, for example,  I get this output from mplayer plus a very (blocky)
>>> stuttering image and sound:
>>>
>>> lin-tv ~ # mplayer dvb://1@"TV8 Oslo" -ao jack
>>>
>>
>> I did some more tests with release snapshots 2011-12-13, 2011-12-21, and
>> 2011-12-25, respectively. I did this by changing
>>
>> LATEST_TAR :=
>> http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2
>> LATEST_TAR_MD5 :=
>> http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2.md5
>>
>> in linux/Makefile to the corresponding release.
>>
>> Results:
>>
>> * linux-media-2011-12-13.tar.bz2
>>
>> The ./build script builds the drivers cleanly, scanning works, but
>>  watching video does not work correctly.
>>
>> * linux-media-2011-12-21.tar.bz2
>>
>> The ./build script fails at the as3645a.c file (on this machine but I can
>> build it on two other machines using the same kernel and kernel
>> 2.6.39-gentoo-r3, respectively). I can build it with make menuconfig etc
>> (where I disabled stuff I don't need, eg. disabling [ ] Media Controller API
>> (EXPERIMENTAL) ). The em28xx generate a kernel core dump though [1].
>>
>> * linux-media-2011-12-25.tar.bz2
>>
>> Same problem as 2011-12-21.
>>
>> Regards,
>>
>> /Fredrik
>>
>
> Here's some more test results.
>
> I have upgraded the kernel to 3.1.6-gentoo (where I enabled DVB when I build
> the kernel). Both
>
> http://linuxtv.org/downloads/drivers/linux-media-2012-01-07.tar.bz2
>
> and
>
> http://linuxtv.org/downloads/drivers/linux-media-2012-01-08.tar.bz2
>
> now builds using the
>
> lin-tv ~ # cd /usr/src
> lin-tv src # git clone git://linuxtv.org/media_build.git
> lin-tv src # cd media_build
> lin-tv media_build # ./build
> lin-tv media_build # make install
>
> method. Scanning and (finally) watching video works but not flawlessly.
>
> I also suspect that I don't find all channels when I scan. I have scanned
> using,
>
> * dvbscan -x 0 -fc /usr/share/dvb/dvb-c/no-Oslo-Get > .mplayer/channels.conf
> * Kaffeine  (1.2.2)
> * MythTV (0.25_pre20120103)
>
> respectively. Both kaffeine and mythtv reports a very low signal level (0%)
> and an SNR of only 1%. (k

[PATCH 1/1] v4l: Ignore ctrl_class in the control framework

[Sakari Ailus]

Back in the old days there was probably a reason to require that controls
that are being used to access using VIDIOC_{TRY,G,S}_EXT_CTRLS belonged to
the same class. These days such reason does not exist, or at least cannot be
remembered, and concrete examples of the opposite can be seen: a single
(sub)device may well offer controls that belong to different classes and
there is no reason to deny changing them atomically.

This patch removes the check for v4l2_ext_controls.ctrl_class in the control
framework. The control framework issues the s_ctrl() op to the drivers
separately so changing the behaviour does not really change how this works
from the drivers' perspective.

Signed-off-by: Sakari Ailus 
---
 drivers/media/video/v4l2-ctrls.c |   18 +-
 1 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index da1f4c2..fff3bb3 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -1855,9 +1855,6 @@ static int prepare_ext_ctrls(struct v4l2_ctrl_handler 
*hdl,
 
cs->error_idx = i;
 
-   if (cs->ctrl_class && V4L2_CTRL_ID2CLASS(id) != cs->ctrl_class)
-   return -EINVAL;
-
/* Old-style private controls are not allowed for
   extended controls */
if (id >= V4L2_CID_PRIVATE_BASE)
@@ -1918,13 +1915,10 @@ static int prepare_ext_ctrls(struct v4l2_ctrl_handler 
*hdl,
 }
 
 /* Handles the corner case where cs->count == 0. It checks whether the
-   specified control class exists. If that class ID is 0, then it checks
-   whether there are any controls at all. */
-static int class_check(struct v4l2_ctrl_handler *hdl, u32 ctrl_class)
+   there are any controls at all. */
+static int handler_check(struct v4l2_ctrl_handler *hdl)
 {
-   if (ctrl_class == 0)
-   return list_empty(&hdl->ctrl_refs) ? -EINVAL : 0;
-   return find_ref_lock(hdl, ctrl_class | 1) ? 0 : -EINVAL;
+   return list_empty(&hdl->ctrl_refs) ? -EINVAL : 0;
 }
 
 
@@ -1938,13 +1932,12 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, 
struct v4l2_ext_controls *cs
int i, j;
 
cs->error_idx = cs->count;
-   cs->ctrl_class = V4L2_CTRL_ID2CLASS(cs->ctrl_class);
 
if (hdl == NULL)
return -EINVAL;
 
if (cs->count == 0)
-   return class_check(hdl, cs->ctrl_class);
+   return handler_check(hdl);
 
if (cs->count > ARRAY_SIZE(helper)) {
helpers = kmalloc(sizeof(helper[0]) * cs->count, GFP_KERNEL);
@@ -2160,13 +2153,12 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh, struct 
v4l2_ctrl_handler *hdl,
int ret;
 
cs->error_idx = cs->count;
-   cs->ctrl_class = V4L2_CTRL_ID2CLASS(cs->ctrl_class);
 
if (hdl == NULL)
return -EINVAL;
 
if (cs->count == 0)
-   return class_check(hdl, cs->ctrl_class);
+   return handler_check(hdl);
 
if (cs->count > ARRAY_SIZE(helper)) {
helpers = kmalloc(sizeof(helper[0]) * cs->count, GFP_KERNEL);
-- 
1.7.2.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

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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:Tue Jan 10 19:00:22 CET 2012
git hash:2f78604a433a12571ec3e54054fbfacc7525b307
gcc version:  i686-linux-gcc (GCC) 4.6.1
host hardware:x86_64
host os:  3.1-2.slh.1-amd64

linux-git-arm-eabi-enoxys: ERRORS
linux-git-arm-eabi-omap: ERRORS
linux-git-armv5-ixp: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: ERRORS
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-rc1-i686: WARNINGS
linux-2.6.31.12-x86_64: ERRORS
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-rc1-x86_64: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.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: [RFC] Future TTM DMA direction

[Jerome Glisse]

On Mon, Jan 09, 2012 at 11:11:06AM +0100, Daniel Vetter wrote:
> On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote:
> > Hi!
> > 
> > When TTM was originally written, it was assumed that GPU apertures
> > could address pages directly, and that the CPU could access those
> > pages without explicit synchronization. The process of binding a
> > page to a GPU translation table was a simple one-step operation, and
> > we needed to worry about fragmentation in the GPU aperture only.
> > 
> > Now that we "sort of" support DMA memory there are three things I
> > think are missing:
> > 
> > 1) We can't gracefully handle coherent DMA OOMs or coherent DMA
> > (Including CMA) memory fragmentation leading to failed allocations.
> > 2) We can't handle dynamic mapping of pages into and out of dma, and
> > corresponding IOMMU space shortage or fragmentation, and CPU
> > synchronization.
> > 3) We have no straightforward way of moving pages between devices.
> > 
> > I think a reasonable way to support this is to make binding to a
> > non-fixed (system page based) TTM memory type a two-step binding
> > process, so that a TTM placement consists of (DMA_TYPE, MEMORY_TYPE)
> > instead of only (MEMORY_TYPE).
> > 
> > In step 1) the bo is bound to a specific DMA type. These could be
> > for example:
> > (NONE, DYNAMIC, COHERENT, CMA),  device dependent types could be
> > allowed as well.
> > In this step, we perform dma_sync_for_device, or allocate
> > dma-specific pages maintaining LRU lists so that if we receive a DMA
> > memory allocation OOM, we can unbind bo:s bound to the same DMA
> > type. Standard graphics cards would then, for example, use the NONE
> > DMA type when run on bare metal or COHERENT when run on Xen. A
> > "COHERENT" OOM condition would then lead to eviction of another bo.
> > (Note that DMA eviction might involve data copies and be costly, but
> > still better than failing).
> > Binding with the DYNAMIC memory type would mean that CPU accesses
> > are disallowed, and that user-space CPU page mappings might need to
> > be killed, with a corresponding sync_for_cpu if they are faulted in
> > again (perhaps on a page-by-page basis). Any attempt to bo_kmap() a
> > bo page bound to DYNAMIC DMA mapping should trigger a BUG.
> > 
> > In step 2) The bo is bound to the GPU in the same way it's done
> > today. Evicting from DMA will of course also trigger an evict from
> > GPU, but an evict from GPU will not trigger a DMA evict.
> > 
> > Making a bo "anonymous" and thus moveable between devices would then
> > mean binding it to the "NONE" DMA type.
> > 
> > Comments, suggestions?
> 
> Well I think we need to solve outstanding issues in the dma_buf framework
> first. Currently dma_buf isn't really up to par to handle coherency
> between the cpu and devices and there's also not yet any way to handle dma
> address space fragmentation/exhaustion.
> 
> I fear that if you jump ahead with improving the ttm support alone we
> might end up with something incompatible to the stuff dma_buf eventually
> will grow, resulting in decent amounts of wasted efforts.
> 
> Cc'ed a bunch of relevant lists to foster input from people.
> 
> For a starter you seem to want much more low-level integration with the
> dma api than existing users commonly need. E.g. if I understand things
> correctly drivers just call dma_alloc_coherent and the platform/board code
> then decides whether the device needs a contigious allocation from cma or
> whether something else is good, too (e.g. vmalloc for the cpu + iommu).
> Another thing is that I think doing lru eviction in case of dma address
> space exhaustion (or fragmentation) needs at least awereness of what's
> going on in the upper layers. iommus are commonly shared between devices
> and I presume that two ttm drivers sitting behind the same iommu and
> fighting over it's resources can lead to some hilarious outcomes.
> 
> Cheers, Daniel

I am with Daniel here, while i think the ttm API change you propose are
good idea, i think most of the issue you are listing need to be addressed
at lower level. If ttm keeps doing its own things for GPU in its own little
area we gonna endup in a dma getto ;)

dma space exhaustion is somethings that is highly platform specific, on
x86 platform it's very unlikely to happen for AMD, Intel or NVidia GPU.
While on the ARM platform it's more likely situation, at least on current
generation.

I believe that the dma api to allocate memory are just too limited for the
kind of device and support we are having. The association to a device is
too restrictive. I would rather see some new API to allocate DMA/IOMMU,
something more flexible and more in line with the dma-buf work.

I believe all dma allocation have a set of restriction. dma mask of the
device, is there an iommu or not, iommu dma mask if any, iommu has a limited
address space (note that recent x86 iommu don't have such limit). In the
end it's not only the device dma mask that matter but also the i

[PATCH] mxl5007t: bugfix DVB-T 7 MHz and 8 MHz bandwidth

[Antti Palosaari]

DVB-T did not work at all - only 6 MHz was working but it is not 
commonly used.

Fix it.

Signed-off-by: Antti Palosaari 
---
 drivers/media/common/tuners/mxl5007t.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/media/common/tuners/mxl5007t.c 
b/drivers/media/common/tuners/mxl5007t.c

index 8f4899b..69e453e 100644
--- a/drivers/media/common/tuners/mxl5007t.c
+++ b/drivers/media/common/tuners/mxl5007t.c
@@ -644,8 +644,10 @@ static int mxl5007t_set_params(struct dvb_frontend *fe)
break;
case 700:
bw = MxL_BW_7MHz;
+   break;
case 800:
bw = MxL_BW_8MHz;
+   break;
default:
return -EINVAL;
}
--
1.7.4.4
--
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 1/4] DVB: dib0700, move Nova-TD Stick to a separate set

[Jiri Slaby]

To properly support the three LEDs which are on the stick, we need
a special handling in the ->frontend_attach function. Thus let's have
a separate ->frontend_attach instead of ifs in the common one.

The hadnling itself will be added in further patches.

Signed-off-by: Jiri Slaby 
---
 drivers/media/dvb/dvb-usb/dib0700_devices.c |   57 --
 1 files changed, 52 insertions(+), 5 deletions(-)

diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c 
b/drivers/media/dvb/dvb-usb/dib0700_devices.c
index 81ef4b4..3c6ee54 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -3892,7 +3892,58 @@ struct dvb_usb_device_properties dib0700_devices[] = {
}
},
 
-   .num_device_descs = 6,
+   .num_device_descs = 1,
+   .devices = {
+   {   "Hauppauge Nova-TD Stick (52009)",
+   { &dib0700_usb_id_table[35], NULL },
+   { NULL },
+   },
+   },
+
+   .rc.core = {
+   .rc_interval  = DEFAULT_RC_INTERVAL,
+   .rc_codes = RC_MAP_DIB0700_RC5_TABLE,
+   .module_name  = "dib0700",
+   .rc_query = dib0700_rc_query_old_firmware,
+   .allowed_protos   = RC_TYPE_RC5 |
+   RC_TYPE_RC6 |
+   RC_TYPE_NEC,
+   .change_protocol = dib0700_change_protocol,
+   },
+   }, { DIB0700_DEFAULT_DEVICE_PROPERTIES,
+
+   .num_adapters = 2,
+   .adapter = {
+   {
+   .num_frontends = 1,
+   .fe = {{
+   .caps = DVB_USB_ADAP_HAS_PID_FILTER | 
DVB_USB_ADAP_PID_FILTER_CAN_BE_TURNED_OFF,
+   .pid_filter_count = 32,
+   .pid_filter   = stk70x0p_pid_filter,
+   .pid_filter_ctrl  = stk70x0p_pid_filter_ctrl,
+   .frontend_attach  = stk7070pd_frontend_attach0,
+   .tuner_attach = dib7070p_tuner_attach,
+
+   DIB0700_DEFAULT_STREAMING_CONFIG(0x02),
+   }},
+   .size_of_priv = sizeof(struct 
dib0700_adapter_state),
+   }, {
+   .num_frontends = 1,
+   .fe = {{
+   .caps = DVB_USB_ADAP_HAS_PID_FILTER | 
DVB_USB_ADAP_PID_FILTER_CAN_BE_TURNED_OFF,
+   .pid_filter_count = 32,
+   .pid_filter   = stk70x0p_pid_filter,
+   .pid_filter_ctrl  = stk70x0p_pid_filter_ctrl,
+   .frontend_attach  = stk7070pd_frontend_attach1,
+   .tuner_attach = dib7070p_tuner_attach,
+
+   DIB0700_DEFAULT_STREAMING_CONFIG(0x03),
+   }},
+   .size_of_priv = sizeof(struct 
dib0700_adapter_state),
+   }
+   },
+
+   .num_device_descs = 5,
.devices = {
{   "DiBcom STK7070PD reference design",
{ &dib0700_usb_id_table[17], NULL },
@@ -3902,10 +3953,6 @@ struct dvb_usb_device_properties dib0700_devices[] = {
{ &dib0700_usb_id_table[18], NULL },
{ NULL },
},
-   {   "Hauppauge Nova-TD Stick (52009)",
-   { &dib0700_usb_id_table[35], NULL },
-   { NULL },
-   },
{   "Hauppauge Nova-TD-500 (84xxx)",
{ &dib0700_usb_id_table[36], NULL },
{ NULL },
-- 
1.7.8


--
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 3/4] DVB: dib0700, add corrected Nova-TD frontend_attach

[Jiri Slaby]

This means cut & paste from the former f. attach. But while at it write
to the right GPIO to turn on the right LED. Also turn the other two
off jsut for sure.

Signed-off-by: Jiri Slaby 
---
 drivers/media/dvb/dvb-usb/dib0700_devices.c |   36 +-
 1 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c 
b/drivers/media/dvb/dvb-usb/dib0700_devices.c
index e5c2bd2..3ab45ae 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -3105,6 +3105,38 @@ static int stk7070pd_frontend_attach1(struct 
dvb_usb_adapter *adap)
return adap->fe_adap[0].fe == NULL ? -ENODEV : 0;
 }
 
+/**
+ * novatd_frontend_attach - Nova-TD specific attach
+ *
+ * Nova-TD has GPIO0, 1 and 2 for LEDs. So do not fiddle with them except for
+ * information purposes.
+ */
+static int novatd_frontend_attach(struct dvb_usb_adapter *adap)
+{
+   struct dvb_usb_device *dev = adap->dev;
+
+   if (adap->id == 0) {
+   stk7070pd_init(dev);
+
+   /* turn the power LED on, the other two off (just in case) */
+   dib0700_set_gpio(dev, GPIO0, GPIO_OUT, 0);
+   dib0700_set_gpio(dev, GPIO1, GPIO_OUT, 0);
+   dib0700_set_gpio(dev, GPIO2, GPIO_OUT, 1);
+
+   if (dib7000p_i2c_enumeration(&dev->i2c_adap, 2, 18,
+stk7070pd_dib7000p_config) != 0) {
+   err("%s: dib7000p_i2c_enumeration failed.  Cannot 
continue\n",
+   __func__);
+   return -ENODEV;
+   }
+   }
+
+   adap->fe_adap[0].fe = dvb_attach(dib7000p_attach, &dev->i2c_adap,
+   adap->id == 0 ? 0x80 : 0x82,
+   &stk7070pd_dib7000p_config[adap->id]);
+   return adap->fe_adap[0].fe == NULL ? -ENODEV : 0;
+}
+
 /* S5H1411 */
 static struct s5h1411_config pinnacle_801e_config = {
.output_mode   = S5H1411_PARALLEL_OUTPUT,
@@ -3876,7 +3908,7 @@ struct dvb_usb_device_properties dib0700_devices[] = {
.pid_filter_count = 32,
.pid_filter   = stk70x0p_pid_filter,
.pid_filter_ctrl  = stk70x0p_pid_filter_ctrl,
-   .frontend_attach  = stk7070pd_frontend_attach0,
+   .frontend_attach  = novatd_frontend_attach,
.tuner_attach = dib7070p_tuner_attach,
 
DIB0700_DEFAULT_STREAMING_CONFIG(0x02),
@@ -3889,7 +3921,7 @@ struct dvb_usb_device_properties dib0700_devices[] = {
.pid_filter_count = 32,
.pid_filter   = stk70x0p_pid_filter,
.pid_filter_ctrl  = stk70x0p_pid_filter_ctrl,
-   .frontend_attach  = stk7070pd_frontend_attach1,
+   .frontend_attach  = novatd_frontend_attach,
.tuner_attach = dib7070p_tuner_attach,
 
DIB0700_DEFAULT_STREAMING_CONFIG(0x03),
-- 
1.7.8


--
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 4/4] DVB: dib0700, add support for Nova-TD LEDs

[Jiri Slaby]

Add an override of read_status to intercept lock status. This allows
us to switch LEDs appropriately on and off with signal un/locked.

The second phase is to override sleep to properly turn off both.

This is a hackish way to achieve that.

Thanks to Mike Krufky for his help.

Signed-off-by: Jiri Slaby 
---
 drivers/media/dvb/dvb-usb/dib0700.h |2 +
 drivers/media/dvb/dvb-usb/dib0700_devices.c |   41 ++-
 2 files changed, 42 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb/dvb-usb/dib0700.h 
b/drivers/media/dvb/dvb-usb/dib0700.h
index 9bd6d51..7de125c 100644
--- a/drivers/media/dvb/dvb-usb/dib0700.h
+++ b/drivers/media/dvb/dvb-usb/dib0700.h
@@ -48,6 +48,8 @@ struct dib0700_state {
u8 disable_streaming_master_mode;
u32 fw_version;
u32 nb_packet_buffer_size;
+   int (*read_status)(struct dvb_frontend *, fe_status_t *);
+   int (*sleep)(struct dvb_frontend* fe);
u8 buf[255];
 };
 
diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c 
b/drivers/media/dvb/dvb-usb/dib0700_devices.c
index 3ab45ae..f9e966a 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -3105,6 +3105,35 @@ static int stk7070pd_frontend_attach1(struct 
dvb_usb_adapter *adap)
return adap->fe_adap[0].fe == NULL ? -ENODEV : 0;
 }
 
+static int novatd_read_status_override(struct dvb_frontend *fe,
+   fe_status_t *stat)
+{
+   struct dvb_usb_adapter *adap = fe->dvb->priv;
+   struct dvb_usb_device *dev = adap->dev;
+   struct dib0700_state *state = dev->priv;
+   int ret;
+
+   ret = state->read_status(fe, stat);
+
+   if (!ret)
+   dib0700_set_gpio(dev, adap->id == 0 ? GPIO1 : GPIO0, GPIO_OUT,
+   !!(*stat & FE_HAS_LOCK));
+
+   return ret;
+}
+
+static int novatd_sleep_override(struct dvb_frontend* fe)
+{
+   struct dvb_usb_adapter *adap = fe->dvb->priv;
+   struct dvb_usb_device *dev = adap->dev;
+   struct dib0700_state *state = dev->priv;
+
+   /* turn off LED */
+   dib0700_set_gpio(dev, adap->id == 0 ? GPIO1 : GPIO0, GPIO_OUT, 0);
+
+   return state->sleep(fe);
+}
+
 /**
  * novatd_frontend_attach - Nova-TD specific attach
  *
@@ -3114,6 +3143,7 @@ static int stk7070pd_frontend_attach1(struct 
dvb_usb_adapter *adap)
 static int novatd_frontend_attach(struct dvb_usb_adapter *adap)
 {
struct dvb_usb_device *dev = adap->dev;
+   struct dib0700_state *st = dev->priv;
 
if (adap->id == 0) {
stk7070pd_init(dev);
@@ -3134,7 +3164,16 @@ static int novatd_frontend_attach(struct dvb_usb_adapter 
*adap)
adap->fe_adap[0].fe = dvb_attach(dib7000p_attach, &dev->i2c_adap,
adap->id == 0 ? 0x80 : 0x82,
&stk7070pd_dib7000p_config[adap->id]);
-   return adap->fe_adap[0].fe == NULL ? -ENODEV : 0;
+
+   if (adap->fe_adap[0].fe == NULL)
+   return -ENODEV;
+
+   st->read_status = adap->fe_adap[0].fe->ops.read_status;
+   adap->fe_adap[0].fe->ops.read_status = novatd_read_status_override;
+   st->sleep = adap->fe_adap[0].fe->ops.sleep;
+   adap->fe_adap[0].fe->ops.sleep = novatd_sleep_override;
+
+   return 0;
 }
 
 /* S5H1411 */
-- 
1.7.8


--
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 2/4] DVB: dib0700, separate stk7070pd initialization

[Jiri Slaby]

The start is common for both stk7070pd and novatd specific routine.
This is just a preparation for the next patch.

Signed-off-by: Jiri Slaby 
---
 drivers/media/dvb/dvb-usb/dib0700_devices.c |   22 ++
 1 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c 
b/drivers/media/dvb/dvb-usb/dib0700_devices.c
index 3c6ee54..e5c2bd2 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -3066,19 +3066,25 @@ static struct dib7000p_config 
stk7070pd_dib7000p_config[2] = {
}
 };
 
-static int stk7070pd_frontend_attach0(struct dvb_usb_adapter *adap)
+static void stk7070pd_init(struct dvb_usb_device *dev)
 {
-   dib0700_set_gpio(adap->dev, GPIO6, GPIO_OUT, 1);
+   dib0700_set_gpio(dev, GPIO6, GPIO_OUT, 1);
msleep(10);
-   dib0700_set_gpio(adap->dev, GPIO9, GPIO_OUT, 1);
-   dib0700_set_gpio(adap->dev, GPIO4, GPIO_OUT, 1);
-   dib0700_set_gpio(adap->dev, GPIO7, GPIO_OUT, 1);
-   dib0700_set_gpio(adap->dev, GPIO10, GPIO_OUT, 0);
+   dib0700_set_gpio(dev, GPIO9, GPIO_OUT, 1);
+   dib0700_set_gpio(dev, GPIO4, GPIO_OUT, 1);
+   dib0700_set_gpio(dev, GPIO7, GPIO_OUT, 1);
+   dib0700_set_gpio(dev, GPIO10, GPIO_OUT, 0);
 
-   dib0700_ctrl_clock(adap->dev, 72, 1);
+   dib0700_ctrl_clock(dev, 72, 1);
 
msleep(10);
-   dib0700_set_gpio(adap->dev, GPIO10, GPIO_OUT, 1);
+   dib0700_set_gpio(dev, GPIO10, GPIO_OUT, 1);
+}
+
+static int stk7070pd_frontend_attach0(struct dvb_usb_adapter *adap)
+{
+   stk7070pd_init(adap->dev);
+
msleep(10);
dib0700_set_gpio(adap->dev, GPIO0, GPIO_OUT, 1);
 
-- 
1.7.8


--
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 05/11] mm: mmzone: MIGRATE_CMA migration type added

[Michal Nazarewicz]

On Tue, 10 Jan 2012 15:38:36 +0100, Mel Gorman  wrote:


On Thu, Dec 29, 2011 at 01:39:06PM +0100, Marek Szyprowski wrote:

From: Michal Nazarewicz 



@@ -35,13 +35,35 @@
  */
 #define PAGE_ALLOC_COSTLY_ORDER 3

-#define MIGRATE_UNMOVABLE 0
-#define MIGRATE_RECLAIMABLE   1
-#define MIGRATE_MOVABLE   2
-#define MIGRATE_PCPTYPES  3 /* the number of types on the pcp lists */
-#define MIGRATE_RESERVE   3
-#define MIGRATE_ISOLATE   4 /* can't allocate from here */
-#define MIGRATE_TYPES 5
+enum {
+   MIGRATE_UNMOVABLE,
+   MIGRATE_RECLAIMABLE,
+   MIGRATE_MOVABLE,
+   MIGRATE_PCPTYPES,   /* the number of types on the pcp lists */
+   MIGRATE_RESERVE = MIGRATE_PCPTYPES,
+   /*
+* MIGRATE_CMA migration type is designed to mimic the way
+* ZONE_MOVABLE works.  Only movable pages can be allocated
+* from MIGRATE_CMA pageblocks and page allocator never
+* implicitly change migration type of MIGRATE_CMA pageblock.
+*
+* The way to use it is to change migratetype of a range of
+* pageblocks to MIGRATE_CMA which can be done by
+* __free_pageblock_cma() function.  What is important though
+* is that a range of pageblocks must be aligned to
+* MAX_ORDER_NR_PAGES should biggest page be bigger then
+* a single pageblock.
+*/
+   MIGRATE_CMA,
+   MIGRATE_ISOLATE,/* can't allocate from here */
+   MIGRATE_TYPES
+};


MIGRATE_CMA is being added whether or not CONFIG_CMA is set. This
increases the size of the pageblock bitmap and where that is just 1 bit
per pageblock in the system, it may be noticable on large machines.


Wasn't aware of that, will do.  In fact, in earlier versions in was done this 
way,
but resulted in more #ifdefs.




+
+#ifdef CONFIG_CMA
+#  define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
+#else
+#  define is_migrate_cma(migratetype) false
+#endif



Use static inlines.


I decide to use #define for the sake of situations like
is_migrate_cma(get_pageblock_migratetype(page)).  With a static inline it will 
have
to read pageblock's migrate type even if !CONFIG_CMA.  A macro gets rid of this
operation all together.


 #define for_each_migratetype_order(order, type) \
for (order = 0; order < MAX_ORDER; order++) \
@@ -54,6 +76,11 @@ static inline int get_pageblock_migratetype(struct page 
*page)
return get_pageblock_flags_group(page, PB_migrate, PB_migrate_end);
 }

+static inline bool is_pageblock_cma(struct page *page)
+{
+   return is_migrate_cma(get_pageblock_migratetype(page));
+}
+


This allows additional calls to get_pageblock_migratetype() even if
CONFIG_CMA is not set.


 struct free_area {
struct list_headfree_list[MIGRATE_TYPES];
unsigned long   nr_free;
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index d305080..af650db 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -37,4 +37,7 @@ extern void unset_migratetype_isolate(struct page *page);
 int alloc_contig_range(unsigned long start, unsigned long end);
 void free_contig_range(unsigned long pfn, unsigned nr_pages);

+/* CMA stuff */
+extern void init_cma_reserved_pageblock(struct page *page);
+
 #endif
diff --git a/mm/Kconfig b/mm/Kconfig
index 011b110..e080cac 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -192,7 +192,7 @@ config COMPACTION
 config MIGRATION
bool "Page migration"
def_bool y
-   depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION
+   depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION || CMA
help
  Allows the migration of the physical location of pages of processes
  while the virtual addresses are not changed. This is useful in
diff --git a/mm/compaction.c b/mm/compaction.c
index 8733441..46783b4 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -21,6 +21,11 @@
 #define CREATE_TRACE_POINTS
 #include 

+static inline bool is_migrate_cma_or_movable(int migratetype)
+{
+   return is_migrate_cma(migratetype) || migratetype == MIGRATE_MOVABLE;
+}
+


That is not a name that helps any. migrate_async_suitable() would be
marginally better.


 /**
  * isolate_freepages_range() - isolate free pages, must hold zone->lock.
  * @zone:  Zone pages are in.
@@ -213,7 +218,7 @@ isolate_migratepages_range(struct zone *zone, struct 
compact_control *cc,
 */
pageblock_nr = low_pfn >> pageblock_order;
if (!cc->sync && last_pageblock_nr != pageblock_nr &&
-   get_pageblock_migratetype(page) != 
MIGRATE_MOVABLE) {
+   is_migrate_cma_or_movable(get_pageblock_migratetype(page))) 
{
low_pfn += pageblock_nr_pages;
low_pfn = ALIGN(low_pfn, pageblock_nr_pages) - 1;
last_pageblock_nr = pageblock_nr;


I know I

Re: [PATCH 02/11] mm: compaction: introduce isolate_{free,migrate}pages_range().

[Michal Nazarewicz]

On Tue, 10 Jan 2012 14:43:51 +0100, Mel Gorman  wrote:


On Thu, Dec 29, 2011 at 01:39:03PM +0100, Marek Szyprowski wrote:

From: Michal Nazarewicz 



+static unsigned long
+isolate_freepages_range(struct zone *zone,
+   unsigned long start_pfn, unsigned long end_pfn,
+   struct list_head *freelist)
 {
-   unsigned long zone_end_pfn, end_pfn;
-   int nr_scanned = 0, total_isolated = 0;
-   struct page *cursor;
-
-   /* Get the last PFN we should scan for free pages at */
-   zone_end_pfn = zone->zone_start_pfn + zone->spanned_pages;
-   end_pfn = min(blockpfn + pageblock_nr_pages, zone_end_pfn);
+   unsigned long nr_scanned = 0, total_isolated = 0;
+   unsigned long pfn = start_pfn;
+   struct page *page;

-   /* Find the first usable PFN in the block to initialse page cursor */
-   for (; blockpfn < end_pfn; blockpfn++) {
-   if (pfn_valid_within(blockpfn))
-   break;
-   }
-   cursor = pfn_to_page(blockpfn);
+   VM_BUG_ON(!pfn_valid(pfn));
+   page = pfn_to_page(pfn);


The existing code is able to find the first usable PFN in a pageblock
with pfn_valid_within(). It's allowed to do that because it knows
the pageblock is valid so calling pfn_valid() is unnecessary.

It is curious to change this to something that can sometimes BUG_ON
!pfn_valid(pfn) instead of having a PFN walker that knows how to
handle pfn_valid().


Actually, this walker seem redundant since one is already present in
isolate_freepages(), ie. if !pfn_valid(pfn) then the loop in
isolate_freepages() will “continue;” and the function will never get
called.


+cleanup:
+   /*
+* Undo what we have done so far, and return.  We know all pages from
+* [start_pfn, pfn) are free because we have just freed them.  If one of
+* the page in the range was not freed, we would end up here earlier.
+*/
+   for (; start_pfn < pfn; ++start_pfn)
+   __free_page(pfn_to_page(start_pfn));
+   return 0;


This returns 0 even though you could have isolated some pages.


The loop's intention is to “unisolate” (ie. free) anything that got
isolated, so at the end number of isolated pages in in fact zero.


Overall, there would have been less contortion if you
implemented isolate_freepages_range() in terms of the existing
isolate_freepages_block. Something that looked kinda like this not
compiled untested illustration.

static unsigned long isolate_freepages_range(struct zone *zone,
unsigned long start_pfn, unsigned long end_pfn,
struct list_head *list)
{
unsigned long pfn = start_pfn;
unsigned long isolated;

for (pfn = start_pfn; pfn < end_pfn; pfn += pageblock_nr_pages) {
if (!pfn_valid(pfn))
continue;
isolated += isolate_freepages_block(zone, pfn, list);
}

return isolated;
}

I neglected to update isolate_freepages_block() to take the end_pfn
meaning it will in fact isolate too much but that would be easy to
address.


This is not a problem since my isolate_freepages_range() implementation
can go beyond end_pfn, anyway.

Of course, the function taking end_pfn is an optimisation since it does
not have to compute zone_end each time.


It would be up to yourself whether to shuffle the tracepoint
around because with this example it will be triggered once per
pageblock. You'd still need the cleanup code and freelist check in
isolate_freepages_block() of course.

The point is that it would minimise the disruption to the existing
code and easier to get details like pfn_valid() right without odd
contortions, more gotos than should be necessary and trying to keep
pfn and page straight.


Even though I'd personally go with my approach, I see merit in your point,
so will change.


 }

 /* Returns true if the page is within a block suitable for migration to */



@@ -365,17 +403,49 @@ static isolate_migrate_t isolate_migratepages(struct zone 
*zone,
nr_isolated++;

/* Avoid isolating too much */
-   if (cc->nr_migratepages == COMPACT_CLUSTER_MAX)
+   if (cc->nr_migratepages == COMPACT_CLUSTER_MAX) {
+   ++low_pfn;
break;
+   }
}


This minor optimisation is unrelated to the implementation of
isolate_migratepages_range() and should be in its own patch.


It's actually not a mere minor optimisation, but rather making the function work
according to the documentation added, ie. that it returns “PFN of the first page
that was not scanned”.

--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-me

Re: Hauppague 930C

[Devin Heitmueller]

On Tue, Jan 10, 2012 at 8:46 AM, Elestedt, Fredrik  wrote:
> Hi,
>
> I've searched high and low now for a recent post on analog support for
> the Hauppauge 930C, but I can't find a thing.
> Anyone have any update for me?

The status is unchanged:  there is no driver for the analog video
decoder, and nobody is currently working on writing one (no datasheets
are publicly available so it would have to be reverse engineered).

Regards,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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 07/11] mm: add optional memory reclaim in split_free_page()

[Mel Gorman]

On Thu, Dec 29, 2011 at 01:39:08PM +0100, Marek Szyprowski wrote:
> split_free_page() function is used by migration code to grab a free page
> once the migration has been finished. This function must obey the same
> rules as memory allocation functions to keep the correct level of
> memory watermarks. Memory compaction code calls it under locks, so it
> cannot perform any *_slowpath style reclaim. However when this function
> is called by migration code for Contiguous Memory Allocator, the sleeping
> context is permitted and the function can make a real reclaim to ensure
> that the call succeeds.
> 
> The reclaim code is based on the __alloc_page_slowpath() function.
> 

This feels like it's at the wrong level entirely.

> Signed-off-by: Marek Szyprowski 
> Signed-off-by: Kyungmin Park 
> CC: Michal Nazarewicz 
> ---
>  include/linux/mm.h |2 +-
>  mm/compaction.c|6 ++--
>  mm/internal.h  |2 +-
>  mm/page_alloc.c|   79 +++
>  4 files changed, 65 insertions(+), 24 deletions(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 4baadd1..8b15b21 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -450,7 +450,7 @@ void put_page(struct page *page);
>  void put_pages_list(struct list_head *pages);
>  
>  void split_page(struct page *page, unsigned int order);
> -int split_free_page(struct page *page);
> +int split_free_page(struct page *page, int force_reclaim);
>  
>  /*
>   * Compound pages have a destructor function.  Provide a
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 46783b4..d6c5cb7 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -46,7 +46,7 @@ static inline bool is_migrate_cma_or_movable(int 
> migratetype)
>  unsigned long
>  isolate_freepages_range(struct zone *zone,
>   unsigned long start_pfn, unsigned long end_pfn,
> - struct list_head *freelist)
> + struct list_head *freelist, int force_reclaim)

bool

but this is the first hint that something is wrong with the
layering. The function is about "isolating free pages" but this patch
is making it also about reclaim. If CMA cares about the watermarks,
it should be the one calling try_to_free_pages(), not wedging it into
the side of compaction.

>  {
>   unsigned long nr_scanned = 0, total_isolated = 0;
>   unsigned long pfn = start_pfn;
> @@ -67,7 +67,7 @@ isolate_freepages_range(struct zone *zone,
>   goto next;
>  
>   /* Found a free page, break it into order-0 pages */
> - n = split_free_page(page);
> + n = split_free_page(page, force_reclaim);
>   total_isolated += n;
>   if (freelist) {
>   struct page *p = page;

Second hint - split_free_page() is not a name that indicates it should
have anything to do with reclaim.

> @@ -376,7 +376,7 @@ static void isolate_freepages(struct zone *zone,
>   if (suitable_migration_target(page)) {
>   end_pfn = min(pfn + pageblock_nr_pages, zone_end_pfn);
>   isolated = isolate_freepages_range(zone, pfn,
> - end_pfn, freelist);
> + end_pfn, freelist, false);
>   nr_freepages += isolated;
>   }
>   spin_unlock_irqrestore(&zone->lock, flags);
> diff --git a/mm/internal.h b/mm/internal.h
> index 4a226d8..8b80027 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -129,7 +129,7 @@ struct compact_control {
>  unsigned long
>  isolate_freepages_range(struct zone *zone,
>   unsigned long start, unsigned long end,
> - struct list_head *freelist);
> + struct list_head *freelist, int force_reclaim);
>  unsigned long
>  isolate_migratepages_range(struct zone *zone, struct compact_control *cc,
>  unsigned long low_pfn, unsigned long end_pfn);
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 8b47c85..a3d5892 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1302,17 +1302,65 @@ void split_page(struct page *page, unsigned int order)
>   set_page_refcounted(page + i);
>  }
>  
> +static inline
> +void wake_all_kswapd(unsigned int order, struct zonelist *zonelist,
> + enum zone_type high_zoneidx,
> + enum zone_type classzone_idx)
> +{
> + struct zoneref *z;
> + struct zone *zone;
> +
> + for_each_zone_zonelist(zone, z, zonelist, high_zoneidx)
> + wakeup_kswapd(zone, order, classzone_idx);
> +}
> +
> +/*
> + * Trigger memory pressure bump to reclaim at least 2^order of free pages.
> + * Does similar work as it is done in __alloc_pages_slowpath(). Used only
> + * by migration code to allocate contiguous memory range.
> + */
> +static int __force_memory_r

Re: Hauppauge HVR-930C problems

[Fredrik Lingvall]

On 12/25/11 16:56, Fredrik Lingvall wrote:

On 12/18/11 10:20, Fredrik Lingvall wrote:

On 12/17/11 20:53, Mihai Dobrescu wrote:




Mihai,

I got some success. I did this,

# cd /usr/src (for example)

# git clone git://linuxtv.org/media_build.git

# emerge dev-util/patchutils
# emerge Proc-ProcessTable

# cd media_build
# ./build
# make install

Which will install the latest driver on your running kernel (just in 
case

make sure /usr/src/linux points to your running kernel sources). Then
reboot.

You should now see that (among other) modules have loaded:

# lsmod



em28xx 93528  1 em28xx_dvb
v4l2_common 5254  1 em28xx
videobuf_vmalloc4167  1 em28xx
videobuf_core  15151  2 em28xx,videobuf_vmalloc

Then try w_scan and dvbscan etc. I got mythtv to scan too now. There 
were

some warnings and timeouts and I'm not sure if this is normal or not.

You can also do a dmesg -c while scanning to monitor the changes en the
kernel log.

Regards,

/Fredrik


In my case I have:

lsmod |grep em2
em28xx_dvb 12608  0
dvb_core   76187  1 em28xx_dvb
em28xx 82436  1 em28xx_dvb
v4l2_common 5087  1 em28xx
videodev   70123  2 em28xx,v4l2_common
videobuf_vmalloc3783  1 em28xx
videobuf_core  12991  2 em28xx,videobuf_vmalloc
rc_core11695  11
rc_hauppauge,ir_lirc_codec,ir_mce_kbd_decoder,ir_sanyo_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,em28xx,ir_nec_decoder 


tveeprom   12441  1 em28xx
i2c_core   14232  9
xc5000,drxk,em28xx_dvb,em28xx,v4l2_common,videodev,tveeprom,nvidia,i2c_i801 



yet, w_scan founds nothing.


I was able to scan using the "media_build" install method described 
above but when trying to watch a free channel the image and sound was 
stuttering severly. I have tried both MythTV and mplayer with similar 
results.


I created the channel list for mplayer with:

lintv ~ # dvbscan -x0 -fc /usr/share/dvb/dvb-c/no-Oslo-Get -o zap > 
.mplayer/channels.conf


And, for example,  I get this output from mplayer plus a very 
(blocky) stuttering image and sound:


lin-tv ~ # mplayer dvb://1@"TV8 Oslo" -ao jack



I did some more tests with release snapshots 2011-12-13, 2011-12-21, 
and 2011-12-25, respectively. I did this by changing


LATEST_TAR := 
http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2
LATEST_TAR_MD5 := 
http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2.md5


in linux/Makefile to the corresponding release.

Results:

* linux-media-2011-12-13.tar.bz2

The ./build script builds the drivers cleanly, scanning works, but  
watching video does not work correctly.


* linux-media-2011-12-21.tar.bz2

The ./build script fails at the as3645a.c file (on this machine but I 
can build it on two other machines using the same kernel and kernel 
2.6.39-gentoo-r3, respectively). I can build it with make menuconfig 
etc (where I disabled stuff I don't need, eg. disabling [ ] Media 
Controller API (EXPERIMENTAL) ). The em28xx generate a kernel core 
dump though [1].


* linux-media-2011-12-25.tar.bz2

Same problem as 2011-12-21.

Regards,

/Fredrik



Here's some more test results.

I have upgraded the kernel to 3.1.6-gentoo (where I enabled DVB when I 
build the kernel). Both


http://linuxtv.org/downloads/drivers/linux-media-2012-01-07.tar.bz2

and

http://linuxtv.org/downloads/drivers/linux-media-2012-01-08.tar.bz2

now builds using the

lin-tv ~ # cd /usr/src
lin-tv src # git clone git://linuxtv.org/media_build.git
lin-tv src # cd media_build
lin-tv media_build # ./build
lin-tv media_build # make install

method. Scanning and (finally) watching video works but not flawlessly.

I also suspect that I don't find all channels when I scan. I have 
scanned using,


* dvbscan -x 0 -fc /usr/share/dvb/dvb-c/no-Oslo-Get > 
.mplayer/channels.conf

* Kaffeine  (1.2.2)
* MythTV (0.25_pre20120103)

respectively. Both kaffeine and mythtv reports a very low signal level 
(0%) and an SNR of only 1%. (kaffeine). I'm not sure if the driver 
reports this correctly though.


Whatching live TV works on some channels but not all. HD channels seems 
more difficult than SD channels,  and I have not figured out why some 
channels work and some don't. I get


Signal 0% | S/N 2.6dB | BE 0 | (_L_S) Partial Lock

and no video on many channels in mythtv.

Regards,

/Fredrik





--
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 05/11] mm: mmzone: MIGRATE_CMA migration type added

[Mel Gorman]

On Thu, Dec 29, 2011 at 01:39:06PM +0100, Marek Szyprowski wrote:
> From: Michal Nazarewicz 
> 
> The MIGRATE_CMA migration type has two main characteristics:
> (i) only movable pages can be allocated from MIGRATE_CMA
> pageblocks and (ii) page allocator will never change migration
> type of MIGRATE_CMA pageblocks.
> 
> This guarantees (to some degree) that page in a MIGRATE_CMA page
> block can always be migrated somewhere else (unless there's no
> memory left in the system).
> 
> It is designed to be used for allocating big chunks (eg. 10MiB)
> of physically contiguous memory.  Once driver requests
> contiguous memory, pages from MIGRATE_CMA pageblocks may be
> migrated away to create a contiguous block.
> 
> To minimise number of migrations, MIGRATE_CMA migration type
> is the last type tried when page allocator falls back to other
> migration types then requested.
> 
> Signed-off-by: Michal Nazarewicz 
> [m.szyprowski: removed CONFIG_CMA_MIGRATE_TYPE]
> Signed-off-by: Marek Szyprowski 
> Signed-off-by: Kyungmin Park 
> ---
>  include/linux/mmzone.h |   41 
>  include/linux/page-isolation.h |3 ++
>  mm/Kconfig |2 +-
>  mm/compaction.c|   11 +--
>  mm/page_alloc.c|   68 ++-
>  mm/vmstat.c|1 +
>  6 files changed, 99 insertions(+), 27 deletions(-)
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 188cb2f..e38b85d 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -35,13 +35,35 @@
>   */
>  #define PAGE_ALLOC_COSTLY_ORDER 3
>  
> -#define MIGRATE_UNMOVABLE 0
> -#define MIGRATE_RECLAIMABLE   1
> -#define MIGRATE_MOVABLE   2
> -#define MIGRATE_PCPTYPES  3 /* the number of types on the pcp lists */
> -#define MIGRATE_RESERVE   3
> -#define MIGRATE_ISOLATE   4 /* can't allocate from here */
> -#define MIGRATE_TYPES 5
> +enum {
> + MIGRATE_UNMOVABLE,
> + MIGRATE_RECLAIMABLE,
> + MIGRATE_MOVABLE,
> + MIGRATE_PCPTYPES,   /* the number of types on the pcp lists */
> + MIGRATE_RESERVE = MIGRATE_PCPTYPES,
> + /*
> +  * MIGRATE_CMA migration type is designed to mimic the way
> +  * ZONE_MOVABLE works.  Only movable pages can be allocated
> +  * from MIGRATE_CMA pageblocks and page allocator never
> +  * implicitly change migration type of MIGRATE_CMA pageblock.
> +  *
> +  * The way to use it is to change migratetype of a range of
> +  * pageblocks to MIGRATE_CMA which can be done by
> +  * __free_pageblock_cma() function.  What is important though
> +  * is that a range of pageblocks must be aligned to
> +  * MAX_ORDER_NR_PAGES should biggest page be bigger then
> +  * a single pageblock.
> +  */
> + MIGRATE_CMA,
> + MIGRATE_ISOLATE,/* can't allocate from here */
> + MIGRATE_TYPES
> +};

MIGRATE_CMA is being added whether or not CONFIG_CMA is set. This
increases the size of the pageblock bitmap and where that is just 1 bit
per pageblock in the system, it may be noticable on large machines.

> +
> +#ifdef CONFIG_CMA
> +#  define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
> +#else
> +#  define is_migrate_cma(migratetype) false
> +#endif
>  

Use static inlines.

>  #define for_each_migratetype_order(order, type) \
>   for (order = 0; order < MAX_ORDER; order++) \
> @@ -54,6 +76,11 @@ static inline int get_pageblock_migratetype(struct page 
> *page)
>   return get_pageblock_flags_group(page, PB_migrate, PB_migrate_end);
>  }
>  
> +static inline bool is_pageblock_cma(struct page *page)
> +{
> + return is_migrate_cma(get_pageblock_migratetype(page));
> +}
> +

This allows additional calls to get_pageblock_migratetype() even if
CONFIG_CMA is not set.

>  struct free_area {
>   struct list_headfree_list[MIGRATE_TYPES];
>   unsigned long   nr_free;
> diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
> index d305080..af650db 100644
> --- a/include/linux/page-isolation.h
> +++ b/include/linux/page-isolation.h
> @@ -37,4 +37,7 @@ extern void unset_migratetype_isolate(struct page *page);
>  int alloc_contig_range(unsigned long start, unsigned long end);
>  void free_contig_range(unsigned long pfn, unsigned nr_pages);
>  
> +/* CMA stuff */
> +extern void init_cma_reserved_pageblock(struct page *page);
> +
>  #endif
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 011b110..e080cac 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -192,7 +192,7 @@ config COMPACTION
>  config MIGRATION
>   bool "Page migration"
>   def_bool y
> - depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION
> + depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION || CMA
>   help
> Allows the migration of the physical location of pages of processes
> while the virtual addresses are not changed. This 

Re: [PATCH 04/11] mm: page_alloc: introduce alloc_contig_range()

[Mel Gorman]

On Thu, Dec 29, 2011 at 01:39:05PM +0100, Marek Szyprowski wrote:
> From: Michal Nazarewicz 
> 
> This commit adds the alloc_contig_range() function which tries
> to allocate given range of pages.  It tries to migrate all
> already allocated pages that fall in the range thus freeing them.
> Once all pages in the range are freed they are removed from the
> buddy system thus allocated for the caller to use.
> 
> __alloc_contig_migrate_range() borrows some code from KAMEZAWA
> Hiroyuki's __alloc_contig_pages().
> 
> Signed-off-by: Michal Nazarewicz 
> Signed-off-by: Marek Szyprowski 
> ---
>  include/linux/page-isolation.h |3 +
>  mm/page_alloc.c|  190 
> 
>  2 files changed, 193 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
> index 051c1b1..d305080 100644
> --- a/include/linux/page-isolation.h
> +++ b/include/linux/page-isolation.h
> @@ -33,5 +33,8 @@ test_pages_isolated(unsigned long start_pfn, unsigned long 
> end_pfn);
>  extern int set_migratetype_isolate(struct page *page);
>  extern void unset_migratetype_isolate(struct page *page);
>  
> +/* The below functions must be run on a range from a single zone. */
> +int alloc_contig_range(unsigned long start, unsigned long end);
> +void free_contig_range(unsigned long pfn, unsigned nr_pages);
>  
>  #endif
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f88b320..47b0a85 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -57,6 +57,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -5711,6 +5712,195 @@ out:
>   spin_unlock_irqrestore(&zone->lock, flags);
>  }
>  
> +static unsigned long pfn_align_to_maxpage_down(unsigned long pfn)
> +{
> + return pfn & ~(MAX_ORDER_NR_PAGES - 1);
> +}
> +
> +static unsigned long pfn_align_to_maxpage_up(unsigned long pfn)
> +{
> + return ALIGN(pfn, MAX_ORDER_NR_PAGES);
> +}
> +
> +static struct page *
> +__cma_migrate_alloc(struct page *page, unsigned long private, int **resultp)
> +{
> + return alloc_page(GFP_HIGHUSER_MOVABLE);
> +}
> +
> +static int __alloc_contig_migrate_range(unsigned long start, unsigned long 
> end)
> +{

This is compiled in even if !CONFIG_CMA

> + /* This function is based on compact_zone() from compaction.c. */
> +
> + unsigned long pfn = start;
> + int ret = -EBUSY;
> + unsigned tries = 0;
> +
> + struct compact_control cc = {
> + .nr_migratepages = 0,
> + .order = -1,
> + .zone = page_zone(pfn_to_page(start)),
> + .sync = true,
> + };

Handle the case where start and end PFNs are in different zones. It
should never happen but it should be caught, warned about and an
error returned because someone will eventually get it wrong.

> + INIT_LIST_HEAD(&cc.migratepages);
> +
> + migrate_prep_local();
> +
> + while (pfn < end || cc.nr_migratepages) {
> + /* Abort on signal */
> + if (fatal_signal_pending(current)) {
> + ret = -EINTR;
> + goto done;
> + }
> +
> + /* Get some pages to migrate. */
> + if (list_empty(&cc.migratepages)) {
> + cc.nr_migratepages = 0;
> + pfn = isolate_migratepages_range(cc.zone, &cc,
> +  pfn, end);
> + if (!pfn) {
> + ret = -EINTR;
> + goto done;
> + }
> + tries = 0;
> + }
> +
> + /* Try to migrate. */
> + ret = migrate_pages(&cc.migratepages, __cma_migrate_alloc,
> + 0, false, true);
> +
> + /* Migrated all of them? Great! */
> + if (list_empty(&cc.migratepages))
> + continue;
> +
> + /* Try five times. */
> + if (++tries == 5) {
> + ret = ret < 0 ? ret : -EBUSY;
> + goto done;
> + }
> +
> + /* Before each time drain everything and reschedule. */
> + lru_add_drain_all();
> + drain_all_pages();

Why drain everything on each migration failure? I do not see how it
would help.

> + cond_resched();

The cond_resched() should be outside the failure path if it exists at
all.

> + }
> + ret = 0;
> +
> +done:
> + /* Make sure all pages are isolated. */
> + if (!ret) {
> + lru_add_drain_all();
> + drain_all_pages();
> + if (WARN_ON(test_pages_isolated(start, end)))
> + ret = -EBUSY;
> + }

Another global IPI seems overkill. Drain pages only from the local CPU
(drain_pages(get_cpu()); put_cpu()) and test if the pages are isolated.
Then and only then do a global drain before trying again, warning and
ret

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Steven Toth]

> The Nanostick works fine for between 5 and 25 minutes and then without any
> error messages cuts out. The TS drops to a tiny stream of non-TS data. It
> seems to contain a lot of 0x00s and 0xffs.

What does femon show for demodulator statistics?

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
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

Hauppague 930C

[Elestedt, Fredrik]

Hi,

I've searched high and low now for a recent post on analog support for
the Hauppauge 930C, but I can't find a thing.
Anyone have any update for me?

I've got DVB-C working, but there are very few channels available
there compared to analog (not DVB-T if I go everything right)

Thanks,
Fredrik
--
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 02/11] mm: compaction: introduce isolate_{free,migrate}pages_range().

[Mel Gorman]

On Thu, Dec 29, 2011 at 01:39:03PM +0100, Marek Szyprowski wrote:
> From: Michal Nazarewicz 
> 
> This commit introduces isolate_freepages_range() and
> isolate_migratepages_range() functions.  The first one replaces
> isolate_freepages_block() and the second one extracts functionality
> from isolate_migratepages().
> 
> They are more generic and instead of operating on pageblocks operate
> on PFN ranges.
> 
> Signed-off-by: Michal Nazarewicz 
> Signed-off-by: Marek Szyprowski 
> ---
>  mm/compaction.c |  184 
> ++-
>  1 files changed, 127 insertions(+), 57 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 899d956..ae73b6f 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -54,55 +54,86 @@ static unsigned long release_freepages(struct list_head 
> *freelist)
>   return count;
>  }
>  
> -/* Isolate free pages onto a private freelist. Must hold zone->lock */
> -static unsigned long isolate_freepages_block(struct zone *zone,
> - unsigned long blockpfn,
> - struct list_head *freelist)
> +/**
> + * isolate_freepages_range() - isolate free pages, must hold zone->lock.
> + * @zone:Zone pages are in.
> + * @start_pfn:   The first PFN to start isolating.
> + * @end_pfn: The one-past-last PFN.
> + * @freelist:A list to save isolated pages to.
> + *
> + * If @freelist is not provided, holes in range (either non-free pages
> + * or invalid PFNs) are considered an error and function undos its
> + * actions and returns zero.
> + *
> + * If @freelist is provided, function will simply skip non-free and
> + * missing pages and put only the ones isolated on the list.
> + *
> + * Returns number of isolated pages.  This may be more then end_pfn-start_pfn
> + * if end fell in a middle of a free page.
> + */
> +static unsigned long
> +isolate_freepages_range(struct zone *zone,
> + unsigned long start_pfn, unsigned long end_pfn,
> + struct list_head *freelist)
>  {
> - unsigned long zone_end_pfn, end_pfn;
> - int nr_scanned = 0, total_isolated = 0;
> - struct page *cursor;
> -
> - /* Get the last PFN we should scan for free pages at */
> - zone_end_pfn = zone->zone_start_pfn + zone->spanned_pages;
> - end_pfn = min(blockpfn + pageblock_nr_pages, zone_end_pfn);
> + unsigned long nr_scanned = 0, total_isolated = 0;
> + unsigned long pfn = start_pfn;
> + struct page *page;
>  
> - /* Find the first usable PFN in the block to initialse page cursor */
> - for (; blockpfn < end_pfn; blockpfn++) {
> - if (pfn_valid_within(blockpfn))
> - break;
> - }
> - cursor = pfn_to_page(blockpfn);
> + VM_BUG_ON(!pfn_valid(pfn));
> + page = pfn_to_page(pfn);

The existing code is able to find the first usable PFN in a pageblock
with pfn_valid_within(). It's allowed to do that because it knows
the pageblock is valid so calling pfn_valid() is unnecessary.

It is curious to change this to something that can sometimes BUG_ON
!pfn_valid(pfn) instead of having a PFN walker that knows how to
handle pfn_valid().

>  
>   /* Isolate free pages. This assumes the block is valid */

You leave this comment intact but you are no longer scanning a page
block. It is in fact assuming that the entire range is valid.

> - for (; blockpfn < end_pfn; blockpfn++, cursor++) {
> - int isolated, i;
> - struct page *page = cursor;
> + while (pfn < end_pfn) {
> + int n = 0, i;
>  
> - if (!pfn_valid_within(blockpfn))
> - continue;
> - nr_scanned++;
> + if (!pfn_valid_within(pfn))
> + goto next;
> + ++nr_scanned;
>  
>   if (!PageBuddy(page))
> - continue;
> + goto next;
>  
>   /* Found a free page, break it into order-0 pages */
> - isolated = split_free_page(page);
> - total_isolated += isolated;
> - for (i = 0; i < isolated; i++) {
> - list_add(&page->lru, freelist);
> - page++;
> + n = split_free_page(page);
> + total_isolated += n;
> + if (freelist) {
> + struct page *p = page;
> + for (i = n; i; --i, ++p)
> + list_add(&p->lru, freelist);

Maybe it's just me, but the original code of

for (i = 0; i < isolated; i++) {
list_add(&page->lru, freelist);
page++;
}

Was a lot easier to read than this increment/decrement with zero
check for loop. Even 

for (i = 0; i < n; i++)
list_add(&p[i].lru, freelist)

would have been a bit easier to parse. I also don't even get why you
renamed "isolated" to the less obvious name "n".

Neither 

Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Jim Darby]

I've been using a PCTV Nanostick T2 USB DVB-T2 receiver (one of the few 
that supports DVB-T2) for over six months with a 3.0 kernel with no 
problems.


The key drivers in use are em28xx, cxd2820r and tda18271.

Seeing the 3.2 kernel I thought I'd upgrade and now I seem to have hit a 
problem.


The Nanostick works fine for between 5 and 25 minutes and then without 
any error messages cuts out. The TS drops to a tiny stream of non-TS 
data. It seems to contain a lot of 0x00s and 0xffs.


It looks like the problem of many years ago when the frontends would be 
shut down if they were closed for more than a few minutes. However, it 
would appear that the frontend fds are still open (according to fuser).


Some more system details:

This is running on a 32-bit system.

Everything works fine if I boot with the 3.0.0 kernel.

The user-land application is kaffeine.

There is a PCI DVB-T card in the system which operates fine even when 
the Nanostick stops producing the correct output.


I'm more than happy to build kernels and add debugging. I'm basically 
just trying to find the maintainer for these modules so we can figure 
out what's going wrong and fix it before 3.2 escapes into several 
distros and we have this problem on a larger scale.


Many thanks for your help,

Jim.
--
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] drivers: media: au0828: Fix dependency for VIDEO_AU0828

[Fabio Estevam]

Fix the following build warning:

warning: (VIDEO_AU0828) selects DVB_AU8522 which has unmet direct dependencies 
(MEDIA_SUPPORT && DVB_CAPTURE_DRIVERS && DVB_CORE && I2C && VIDEO_V4L2)

Signed-off-by: Fabio Estevam 
---
 drivers/media/video/au0828/Kconfig |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/au0828/Kconfig 
b/drivers/media/video/au0828/Kconfig
index 0c3a5ba..81ba9d9 100644
--- a/drivers/media/video/au0828/Kconfig
+++ b/drivers/media/video/au0828/Kconfig
@@ -2,6 +2,7 @@
 config VIDEO_AU0828
tristate "Auvitek AU0828 support"
depends on I2C && INPUT && DVB_CORE && USB && VIDEO_V4L2
+   depends on DVB_CAPTURE_DRIVERS
select I2C_ALGOBIT
select VIDEO_TVEEPROM
select VIDEOBUF_VMALLOC
-- 
1.7.1

--
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: [RFC PATCH v2 4/8] media: videobuf2: introduce VIDEOBUF2_PAGE memops

[Ming Lei]

Hi,

On Tue, Jan 10, 2012 at 6:20 PM, Marek Szyprowski
 wrote:

>> Sorry, could you describe the abuse problem in a bit detail?
>
> Videobuf2 requires memory module handlers to provide vaddr method to provide 
> a pointer in
> kernel virtual address space to video data (buffer content). It is used for 
> example by

Yes, this is what the patch is doing, __get_free_pages just  returns
the kernel virtual
address which will be passed to driver.

> read()/write() io method emulator. Memory allocator/handler should not be 
> specific to any
> particular use case in the device driver. That's the design. Simple.

Most of the patch is copied from videobuf-vmalloc.c, and the
interfaces are totally same
with videobuf-vmalloc.c.

>
> I your case you want to give pointer to struct page from the memory allocator 
> to the

In my case, the pointer to struct page is not required to the driver
at all, so I think you
have misunderstood the patch, don't I?

> driver. The cookie method has been introduced exactly for this purpose. 
> Memory allocator
> also provides a simple inline function to convert generic 'void *' return 
> type from cookie
> method to allocator specific structure/pointer. 
> vb2_dma_contig_plane_dma_addr() and
> vb2_dma_sg_plane_desc() were examples how does passing allocator specific 
> type though the
> cookie method works.

thanks,
--
Ming Lei
--
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: [ANN] Notes on IRC meeting on new sensor control interface, 2012-01-09 14:00 GMT+2

[Tuukka Toivonen]

On Tuesday 10 January 2012 12:05:48 Laurent Pinchart wrote:
> > > That was my question, how does the user decide whether hblank or vblank
> > > is preferred ?
> > 
> > I think that should be defined in the configuration itself. It's very
> > unlikely there's any need to change this dynamically.
> 
> Sure, but that's not my point. How does the user decide in the first place
> when writing the configuration ?

As Sakari finally told,
- More vertical blanking
  -> less rolling shutter effect (ie. less slanted image) and more time to do
  some processing between frames if wanted or needed
- More horizontal blanking -> smoother data rate, especially if there are
  buffers which can contain just couple of lines

I would say that generally vertical blanking is preferred unless there are
small buffers which allow required decrease in data rate for later stages in
image processing pipeline with larger horizontal blanking.

- Tuukka
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--
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 RESEND v3 2/2] [media] V4L: atmel-isi: add clk_prepare()/clk_unprepare() functions

[Guennadi Liakhovetski]

Hi Josh

Right, sorry, I missed this one, I somehow developed an idea, that it has 
been merged into the original patch, adding ISI_MCK handling. Now, I also 
notice one detail, that we could improve:

On Tue, 10 Jan 2012, Josh Wu wrote:

> Signed-off-by: Josh Wu 
> Acked-by: Nicolas Ferre 
> ---
> Hi, Mauro
> 
> The first patch of this serie, [PATCH 1/2 v3] V4L: atmel-isi: add code to 
> enable/disable ISI_MCK clock, is already queued in media tree. 
> But this patch (the second one of this serie) is not acked yet. Would it be 
> ok to for you to ack this patch?
> 
> Best Regards,
> Josh Wu
> 
> v2: made the label name to be consistent.
> 
>  drivers/media/video/atmel-isi.c |   15 +++
>  1 files changed, 15 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
> index ea4eef4..91ebcfb 100644
> --- a/drivers/media/video/atmel-isi.c
> +++ b/drivers/media/video/atmel-isi.c
> @@ -922,7 +922,9 @@ static int __devexit atmel_isi_remove(struct 
> platform_device *pdev)
>   isi->fb_descriptors_phys);
>  
>   iounmap(isi->regs);
> + clk_unprepare(isi->mck);
>   clk_put(isi->mck);
> + clk_unprepare(isi->pclk);
>   clk_put(isi->pclk);
>   kfree(isi);
>  
> @@ -955,6 +957,12 @@ static int __devinit atmel_isi_probe(struct 
> platform_device *pdev)
>   if (IS_ERR(pclk))
>   return PTR_ERR(pclk);
>  
> + ret = clk_prepare(pclk);
> + if (ret) {
> + clk_put(pclk);
> + return ret;

Don't think it's a good idea here. You already have clk_put(pclk) on the 
error handling path below. So, just put a "goto err_clk_prepare_pclk" here 
and the respective error below.

Thanks
Guennadi

> + }
> +
>   isi = kzalloc(sizeof(struct atmel_isi), GFP_KERNEL);
>   if (!isi) {
>   ret = -ENOMEM;
> @@ -978,6 +986,10 @@ static int __devinit atmel_isi_probe(struct 
> platform_device *pdev)
>   goto err_clk_get;
>   }
>  
> + ret = clk_prepare(isi->mck);
> + if (ret)
> + goto err_clk_prepare_mck;
> +
>   /* Set ISI_MCK's frequency, it should be faster than pixel clock */
>   ret = clk_set_rate(isi->mck, pdata->mck_hz);
>   if (ret < 0)
> @@ -1059,10 +1071,13 @@ err_alloc_ctx:
>   isi->fb_descriptors_phys);
>  err_alloc_descriptors:
>  err_set_mck_rate:
> + clk_unprepare(isi->mck);
> +err_clk_prepare_mck:
>   clk_put(isi->mck);
>  err_clk_get:
>   kfree(isi);
>  err_alloc_isi:
> + clk_unprepare(pclk);
>   clk_put(pclk);
>  
>   return ret;
> -- 
> 1.6.3.3
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: [RFC 06/17] v4l: Add selections documentation.

[Tomasz Stanislawski]

Hi Sakari,


Hi Laurent,

Thanks for the comments!

Laurent Pinchart wrote:

On Tuesday 20 December 2011 21:27:58 Sakari Ailus wrote:

[snip]


diff --git a/Documentation/DocBook/media/v4l/dev-subdev.xml
b/Documentation/DocBook/media/v4l/dev-subdev.xml index 0916a73..722db60
100644
--- a/Documentation/DocBook/media/v4l/dev-subdev.xml
+++ b/Documentation/DocBook/media/v4l/dev-subdev.xml


[snip]



This sounds a bit confusing to me. One issue is that composing is not formally
defined. I think it would help if you could draw a diagram that shows how the
operations are applied, and modify the text to describe the diagram, using the
natural order of the compose and crop operations on sink and source pads.


I drew a diagram based on your suggestion, but I'd prefer the formal
definition would come from someone who needs composition and better
understands the use cases.

Also cc Tomasz.


+
+Order of configuration and format propagation
+
+The order of image processing steps will always be from
+  the sink pad towards the source pad. This is also reflected in
+  the order in which the configuration must be performed by the
+  user. The format is propagated within the subdev along the later
+  processing steps. For example, setting the sink pad format
+  causes all the selection rectangles and the source pad format to
+  be set to sink pad format --- if allowed by the hardware, and if
+  not, then closest possible. The coordinates to a step always
+  refer to the active size of the previous step.


This also sounds a bit ambiguous if I try to ignore the fact that I know how
it works :-) You should at least make it explicit that propagation inside
subdevs is performed by the driver(s), and that propagation outside subdevs is
to be handled by userspace.


Agreed. I'll reword it.



[snip]


+The are four types of selection targets: active, default,
+  bounds and padding. The ACTIVE targets are the targets which
+  configure the hardware. The DEFAULT target provides the default
+  for the ACTIVE selection. The BOUNDS target will return the
+  maximum width and height of the target.


What about the minimum ?


There are multiple problems with idea of the maximal rectangle because 
one has to provide definition how to compare size of two rectangles. If 
you had to compare rectangles 10x1, 1x10, 5x5 which would you choose as 
the largest? Such problems may appear if HW has width, height and size 
constraints. One encounters similar problem with definition of the 
smallest rectangle. I prefer to define "is larger" as "contains". 
Rectangle 10x10 contains all three overmentioned rectangles therefore it 
is the maximal rectangle. The problem with such a definition is that 
such a rectangle may not be accepted by HW.




Good question. We could also specify that the minimum is obtained by
using the V4L2_SUBDEV_SEL_FLAG_LE flag with the BOUNDS target.



As I remember bounds rectangle is fixed and there is no such a thing as 
minimal/maximal bounds. For V4L2 video node API, the bounds rectangle is 
read-only value describing rectangle that contains all pixels.

Could you describe the use case that utilities minimal bounds rectangle?


The PADDED target
+  provides the width and height for the padded image,


Is it valid for both crop and compose rectangles ?


I think all targets are valid for all rectangles. Should I mention that?

The practical use cases may be more limited, though. I wonder if I
should remove the padded targets until we get use cases for them. I
included them for the reason that they also exist in the V4L2.

Tomasz, Sylwester: do you have use for the PADDED targets?


S5P-TV and S5P-JPEG (by Andrzej Pietrasiewicz) makes use of PADDED 
target. The padded target is very hardware/application dependent 
parameter. It is defined only for composing targets. Basically it refers 
to all pixels that are modified by the hardware. In S5P-TV the padded 
rectangle is equal to active rectangle. However, if having no good idea 
about padded area, then it is always safe/consistent to make padded 
rectangle equal to bounds one.




I think we also must define what will be done in cases where crop (on
either sink or source) / scaling / composition is not supported by the
subdev. That's currently undefined. I think it'd be most clear to return
an error code but I'm not sure which one --- EINVAL is an obvious
candidate but that is also returned when the pad is wrong. It looks
still like the best choice to me.


Maybe one should return EPERM or EACCES if S_SELECTION is called on 
read-only target. Other idea is to introduce V4L2_SEL_FLAG_RDONLY flag 
which is set by VIDIOC_G_SELECTION for a given target. The driver may 
return EINVAL if target is not supported. It would imply that support 
for the target is not implemented in the driver.


Regards,
Tomasz Stanislawski




and is
+  directly affected by the ACTIVE target. The PADDED targets may
+  be configurable d

[PATCH RESEND v3 2/2] [media] V4L: atmel-isi: add clk_prepare()/clk_unprepare() functions

[Josh Wu]

Signed-off-by: Josh Wu 
Acked-by: Nicolas Ferre 
---
Hi, Mauro

The first patch of this serie, [PATCH 1/2 v3] V4L: atmel-isi: add code to 
enable/disable ISI_MCK clock, is already queued in media tree. 
But this patch (the second one of this serie) is not acked yet. Would it be ok 
to for you to ack this patch?

Best Regards,
Josh Wu

v2: made the label name to be consistent.

 drivers/media/video/atmel-isi.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index ea4eef4..91ebcfb 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -922,7 +922,9 @@ static int __devexit atmel_isi_remove(struct 
platform_device *pdev)
isi->fb_descriptors_phys);
 
iounmap(isi->regs);
+   clk_unprepare(isi->mck);
clk_put(isi->mck);
+   clk_unprepare(isi->pclk);
clk_put(isi->pclk);
kfree(isi);
 
@@ -955,6 +957,12 @@ static int __devinit atmel_isi_probe(struct 
platform_device *pdev)
if (IS_ERR(pclk))
return PTR_ERR(pclk);
 
+   ret = clk_prepare(pclk);
+   if (ret) {
+   clk_put(pclk);
+   return ret;
+   }
+
isi = kzalloc(sizeof(struct atmel_isi), GFP_KERNEL);
if (!isi) {
ret = -ENOMEM;
@@ -978,6 +986,10 @@ static int __devinit atmel_isi_probe(struct 
platform_device *pdev)
goto err_clk_get;
}
 
+   ret = clk_prepare(isi->mck);
+   if (ret)
+   goto err_clk_prepare_mck;
+
/* Set ISI_MCK's frequency, it should be faster than pixel clock */
ret = clk_set_rate(isi->mck, pdata->mck_hz);
if (ret < 0)
@@ -1059,10 +1071,13 @@ err_alloc_ctx:
isi->fb_descriptors_phys);
 err_alloc_descriptors:
 err_set_mck_rate:
+   clk_unprepare(isi->mck);
+err_clk_prepare_mck:
clk_put(isi->mck);
 err_clk_get:
kfree(isi);
 err_alloc_isi:
+   clk_unprepare(pclk);
clk_put(pclk);
 
return ret;
-- 
1.6.3.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: [PATCH] media i.MX27 camera: properly detect frame loss.

[Guennadi Liakhovetski]

Hi Javier

On Mon, 2 Jan 2012, Javier Martin wrote:

> As V4L2 specification states, frame_count must also
> regard lost frames so that the user can handle that
> case properly.
> 
> This patch adds a mechanism to increment the frame
> counter even when a video buffer is not available
> and a discard buffer is used.
> 
> Signed-off-by: Javier Martin 
> ---
>  drivers/media/video/mx2_camera.c |   54 
> --
>  1 files changed, 34 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/media/video/mx2_camera.c 
> b/drivers/media/video/mx2_camera.c
> index ca76dd2..b244714 100644
> --- a/drivers/media/video/mx2_camera.c
> +++ b/drivers/media/video/mx2_camera.c
> @@ -256,6 +256,7 @@ struct mx2_camera_dev {
>   size_t  discard_size;
>   struct mx2_fmt_cfg  *emma_prp;
>   u32 frame_count;
> + unsigned intfirstirq;

_if_ we indeed end up using this field, it seems it can be just a bool.

>  };
>  
>  /* buffer for one video frame */
> @@ -370,6 +371,7 @@ static int mx2_camera_add_device(struct soc_camera_device 
> *icd)
>  
>   pcdev->icd = icd;
>   pcdev->frame_count = 0;
> + pcdev->firstirq = 1;
>  
>   dev_info(icd->parent, "Camera driver attached to camera %d\n",
>icd->devnum);
> @@ -572,6 +574,7 @@ static void mx2_videobuf_queue(struct videobuf_queue *vq,
>   struct soc_camera_host *ici =
>   to_soc_camera_host(icd->parent);
>   struct mx2_camera_dev *pcdev = ici->priv;
> + struct mx2_fmt_cfg *prp = pcdev->emma_prp;
>   struct mx2_buffer *buf = container_of(vb, struct mx2_buffer, vb);
>   unsigned long flags;
>  
> @@ -584,6 +587,26 @@ static void mx2_videobuf_queue(struct videobuf_queue *vq,
>   list_add_tail(&vb->queue, &pcdev->capture);
>  
>   if (mx27_camera_emma(pcdev)) {
> + if (prp->cfg.channel == 1) {
> + writel(PRP_CNTL_CH1EN |
> + PRP_CNTL_CSIEN |
> + prp->cfg.in_fmt |
> + prp->cfg.out_fmt |
> + PRP_CNTL_CH1_LEN |
> + PRP_CNTL_CH1BYP |
> + PRP_CNTL_CH1_TSKIP(0) |
> + PRP_CNTL_IN_TSKIP(0),
> + pcdev->base_emma + PRP_CNTL);
> + } else {
> + writel(PRP_CNTL_CH2EN |
> + PRP_CNTL_CSIEN |
> + prp->cfg.in_fmt |
> + prp->cfg.out_fmt |
> + PRP_CNTL_CH2_LEN |
> + PRP_CNTL_CH2_TSKIP(0) |
> + PRP_CNTL_IN_TSKIP(0),
> + pcdev->base_emma + PRP_CNTL);
> + }

Is this related and why is this needed?

>   goto out;
>   } else { /* cpu_is_mx25() */
>   u32 csicr3, dma_inten = 0;
> @@ -747,16 +770,6 @@ static void mx27_camera_emma_buf_init(struct 
> soc_camera_device *icd,
>   writel(pcdev->discard_buffer_dma,
>   pcdev->base_emma + PRP_DEST_RGB2_PTR);
>  
> - writel(PRP_CNTL_CH1EN |
> - PRP_CNTL_CSIEN |
> - prp->cfg.in_fmt |
> - prp->cfg.out_fmt |
> - PRP_CNTL_CH1_LEN |
> - PRP_CNTL_CH1BYP |
> - PRP_CNTL_CH1_TSKIP(0) |
> - PRP_CNTL_IN_TSKIP(0),
> - pcdev->base_emma + PRP_CNTL);
> -
>   writel((icd->user_width << 16) | icd->user_height,
>   pcdev->base_emma + PRP_SRC_FRAME_SIZE);
>   writel((icd->user_width << 16) | icd->user_height,
> @@ -784,15 +797,6 @@ static void mx27_camera_emma_buf_init(struct 
> soc_camera_device *icd,
>   pcdev->base_emma + PRP_SOURCE_CR_PTR);
>   }
>  
> - writel(PRP_CNTL_CH2EN |
> - PRP_CNTL_CSIEN |
> - prp->cfg.in_fmt |
> - prp->cfg.out_fmt |
> - PRP_CNTL_CH2_LEN |
> - PRP_CNTL_CH2_TSKIP(0) |
> - PRP_CNTL_IN_TSKIP(0),
> - pcdev->base_emma + PRP_CNTL);
> -
>   writel((icd->user_width << 16) | icd->user_height,
>   pcdev->base_emma + PRP_SRC_FRAME_SIZE);
>  
> @@ -1214,7 +1218,6 @@ static void mx27_camera_frame_done_emma(struct 
> mx2_camera_dev *pcdev,
>   vb->state = state;
>   do_gettimeofday(&vb->ts);
>   vb->field_count = pcdev->frame_count * 2;
> - pcdev->frame_count++;
>  
>   wake_up(&vb->done);
>   }

Wouldn't you achieve the same by simply initialising frame_count to -1 and 
incrementing it unconditi

Re: [ANN] Notes on IRC meeting on new sensor control interface, 2012-01-09 14:00 GMT+2

[Sakari Ailus]

Hi Laurent,

Laurent Pinchart wrote:

On Tuesday 10 January 2012 10:52:26 Sakari Ailus wrote:

Laurent Pinchart wrote:

On Tuesday 10 January 2012 10:42:58 Sakari Ailus wrote:

Laurent Pinchart wrote:

On Tuesday 10 January 2012 00:26:46 Sakari Ailus wrote:

Laurent Pinchart wrote:

On Monday 09 January 2012 23:32:06 Sakari Ailus wrote:

Laurent Pinchart wrote:

On Monday 09 January 2012 18:38:25 Sakari Ailus wrote:

...


A fourth section may be required as well: at this level the frame
rate (or frame time) range makes more sense than the low-level
blanking values. The blanking values can be calculated from the
frame time and a flag which tells whether either horizontal or
vertical blanking should be preferred.


How does one typically select between horizontal and vertical
blanking ? Do mixed modes make sense ?


There are minimums and maximums for both. You can increase the frame
time by increasing value for either or both of them --- to achieve
very long frame times you may have to use both, but that's not very
common in practice. I think we should have a flag to tell which one
should be increased first --- the effect would be to have the
minimum possible value on the other.


But how do you decide in practice which one to increase when you're
an application (or middleware) developer ?


I think it's the responsibility of this library to do that, unless the
user wants really, really precise control in which case they have to
deal with the blanking values directly. In general it should be the
library.


And how does the library decide ? :-)


frame_time = pixel_rate / ((width + hblank) * (height + vblank))

The user gives you frame time and the configuration contains the
information which one to prefer. Let's say the user prefers hblank (from



the above):

That was my question, how does the user decide whether hblank or vblank
is preferred ?


I think that should be defined in the configuration itself. It's very
unlikely there's any need to change this dynamically.


Sure, but that's not my point. How does the user decide in the first place
when writing the configuration ?


That's a policy decision. There may be multiple reasons for that, but 
the most obvious I can think of is a decision between amortised memory 
access rate and the rolling shutter effect. There may be other factors 
like time of year, phase of moon and colour of the neighbour's cat to 
name a few. :-)


It might also make sense to be able to specify a minimum for horizontal 
blanking which is bigger than the minimum the sensor allows. But that's 
going to the fine details.


--
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: [RFC PATCH v2 4/8] media: videobuf2: introduce VIDEOBUF2_PAGE memops

[Marek Szyprowski]

Hello,

On Friday, December 23, 2011 1:21 PM Ming Lei wrote:

> >> >> > Your current implementation also abuses the design and api of 
> >> >> > videobuf2 memory
> >> >> > allocators. If the allocator needs to return a custom structure to 
> >> >> > the driver
> >> >>
> >> >> I think returning vaddr is enough.
> >> >>
> >> >> > you should use cookie method. vaddr is intended to provide only a 
> >> >> > pointer to
> >> >> > kernel virtual mapping, but you pass a struct page * there.
> >> >>
> >> >> No, __get_free_pages returns virtual address instead of 'struct page *'.
> >> >
> >> > Then you MUST use cookie for it. vaddr method should return kernel 
> >> > virtual address
> >> > to the buffer video data. Some parts of videobuf2 relies on this - it is 
> >> > used by file
> >> > io emulator (read(), write() calls) and mmap equivalent for non-mmu 
> >> > systems.
> >> >
> >> > Manual casting in the driver is also a bad idea, that's why there are 
> >> > helper functions
> >>
> >> I don't see any casts are needed. The dma address can be got from vaddr 
> >> with
> >> dma_map_* easily in drivers, see the usage on patch 8/8(media: video: 
> >> introduce
> >> omap4 face detection module driver).
> >
> > Sorry, but I won't accept such driver/allocator which abuses the defined 
> > API. I've already
> > pointed what vaddr method is used for.
> 
> Sorry, could you describe the abuse problem in a bit detail?

Videobuf2 requires memory module handlers to provide vaddr method to provide a 
pointer in 
kernel virtual address space to video data (buffer content). It is used for 
example by 
read()/write() io method emulator. Memory allocator/handler should not be 
specific to any
particular use case in the device driver. That's the design. Simple.

I your case you want to give pointer to struct page from the memory allocator 
to the 
driver. The cookie method has been introduced exactly for this purpose. Memory 
allocator
also provides a simple inline function to convert generic 'void *' return type 
from cookie
method to allocator specific structure/pointer. vb2_dma_contig_plane_dma_addr() 
and 
vb2_dma_sg_plane_desc() were examples how does passing allocator specific type 
though the
cookie method works.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center



--
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: [ANN] Notes on IRC meeting on new sensor control interface, 2012-01-09 14:00 GMT+2

[Laurent Pinchart]

Hi Sakari,

On Tuesday 10 January 2012 10:52:26 Sakari Ailus wrote:
> Laurent Pinchart wrote:
> > On Tuesday 10 January 2012 10:42:58 Sakari Ailus wrote:
> >> Laurent Pinchart wrote:
> >>> On Tuesday 10 January 2012 00:26:46 Sakari Ailus wrote:
>  Laurent Pinchart wrote:
> > On Monday 09 January 2012 23:32:06 Sakari Ailus wrote:
> >> Laurent Pinchart wrote:
> >>> On Monday 09 January 2012 18:38:25 Sakari Ailus wrote:
>  ...
>  
>  A fourth section may be required as well: at this level the frame
>  rate (or frame time) range makes more sense than the low-level
>  blanking values. The blanking values can be calculated from the
>  frame time and a flag which tells whether either horizontal or
>  vertical blanking should be preferred.
> >>> 
> >>> How does one typically select between horizontal and vertical
> >>> blanking ? Do mixed modes make sense ?
> >> 
> >> There are minimums and maximums for both. You can increase the frame
> >> time by increasing value for either or both of them --- to achieve
> >> very long frame times you may have to use both, but that's not very
> >> common in practice. I think we should have a flag to tell which one
> >> should be increased first --- the effect would be to have the
> >> minimum possible value on the other.
> > 
> > But how do you decide in practice which one to increase when you're
> > an application (or middleware) developer ?
>  
>  I think it's the responsibility of this library to do that, unless the
>  user wants really, really precise control in which case they have to
>  deal with the blanking values directly. In general it should be the
>  library.
> >>> 
> >>> And how does the library decide ? :-)
> >> 
> >> frame_time = pixel_rate / ((width + hblank) * (height + vblank))
> >> 
> >> The user gives you frame time and the configuration contains the
> >> information which one to prefer. Let's say the user prefers hblank (from
> > 
> >> the above):
> > That was my question, how does the user decide whether hblank or vblank
> > is preferred ?
> 
> I think that should be defined in the configuration itself. It's very
> unlikely there's any need to change this dynamically.

Sure, but that's not my point. How does the user decide in the first place 
when writing the configuration ?

-- 
Regards,

Laurent Pinchart
--
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] s5p-mfc: Fix volatile controls setup

[Hans Verkuil]

Hi Kamil,

Sorry for the delay, I've been on vacation.

On Tuesday 03 January 2012 10:26:43 Kamil Debski wrote:
> Hi Laurent,
> 
> Thanks for pointing this out, my comment is below.
> Hans, I would be grateful if you could also read this and comment :)
> 
> > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> > Sent: 03 January 2012 02:14
> > 
> > Hi Kamil,
> > 
> > On Tuesday 27 December 2011 15:07:24 Kamil Debski wrote:
> > > Signed-off-by: Kamil Debski 
> > > Signed-off-by: Kyungmin Park 
> > > ---
> > > 
> > >  drivers/media/video/s5p-mfc/s5p_mfc_dec.c |2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_dec.c
> > > b/drivers/media/video/s5p-mfc/s5p_mfc_dec.c index 844a4d7..c25ec02
> > > 100644 --- a/drivers/media/video/s5p-mfc/s5p_mfc_dec.c
> > > +++ b/drivers/media/video/s5p-mfc/s5p_mfc_dec.c
> > > @@ -165,7 +165,7 @@ static struct mfc_control controls[] = {
> > > 
> > >   .maximum = 32,
> > >   .step = 1,
> > >   .default_value = 1,
> > > 
> > > - .flags = V4L2_CTRL_FLAG_VOLATILE,
> > > + .is_volatile = 1,
> > > 
> > >   },
> > >  
> > >  };
> > 
> > Why so ? is_volatile got removed in commit
> > 88365105d683187e02a4f75220eaf51fd0c0b6e0.
> 
> Yep, this commit broke MFC, as after it has been applied volatile flag was
> not set for any of the controls.
> 
> From 88365105d683187e02a4f75220eaf51fd0c0b6e0.
> -- drivers/media/video/s5p-mfc/s5p_mfc_dec.c
> -- index 32f8989..bfbe084 100644
> @@ -165,7 +165,7 @@ static struct mfc_control controls[] = {
>   .maximum = 32,
>   .step = 1,
>   .default_value = 1,
> - .is_volatile = 1,
> + .flags = V4L2_CTRL_FLAG_VOLATILE,
>   },
>  };

Hmm, this change should be reverted. 'is_volatile' is a field of your own 
struct, so there is no need to replace it. My mistake.

> 
> @@ -1020,7 +1020,7 @@ int s5p_mfc_dec_ctrls_setup(struct s5p_mfc_ctx *ctx)
>   return ctx->ctrl_handler.error;
>   }
>   if (controls[i].is_volatile && ctx->ctrls[i])
> - ctx->ctrls[i]->is_volatile = 1;
> + ctx->ctrls[i]->flags |= V4L2_CTRL_FLAG_VOLATILE;
>   }
>   return 0;
>  }

This change is fine.

> 
> See? In the controls array the is_volatile field was no longer set, but it
> was used
> in the s5p_mfc_dec_ctrls_setup. Thus is was always 0.
> 
> The v4l2_ctrl_new_custom/v4l2_ctrl_new_std functions set the flags field
> (which is done in v4l2_ctrl_fill).
> It is also possible to |= the flag with the current contents of the field.
> 
> - if (controls[i].is_volatile && ctx->ctrls[i])
> + if (ctx->ctrls[i])
> - ctx->ctrls[i]->flags |= V4L2_CTRL_FLAG_VOLATILE;
> + ctx->ctrls[i]->flags |= controls[i].flags;
> This is possible, as it would set all the flags set in controls[] array.

This is also an option, but then the is_volatile field should also be removed
from the mfc_control struct.

> 
> Also checking for V4L2_CTRL_FLAG_VOLATILE in controls[x].flags and then
> setting ctx->ctrls[i]->flags |= V4L2_CTRL_FLAG_VOLATILE is possible, but I
> think it is not
> necessary. The above solution should work fine as well.
> 
> The thing is that I did not notice Hans's commit and thought that it was my
> mistake in MFC.
> Thus I have fixed it in the simplest way. (It would be nice if I had been
> added to CC of that patch)

Will try to remember for the next time :-)

> Hans, if you could comment on which from the aforementioned solutions do
> you find the best?
> The one from my commit, or the proposed above?

Looking at it some more I would go for your commit to get it fixed quickly,
but I would recommend reworking the code in the longer term.

You have two types of controls: device specific, for which you can use 
v4l2_ctrl_new_custom() and struct v4l2_ctrl_config (no need for struct 
mfc_control), or standard controls for which you can use v4l2_ctrl_new_std.

So I would make an array of struct v4l2_ctrl_config containing the custom 
controls, and call v4l2_ctrl_new_std() in the control setup function for the 
standard controls. That way v4l2_ctrl_new_std() will fill in all the non-range 
fields for you (thus ensuring consistency). For the volatile control you will 
have to set the volatile flag manually.


> 
> Also - maybe VOLATILE flag for V4L2_CID_MIN_BUFFERS_FOR_CAPTURE should be
> set in v4l2_ctrl_fill?
> Though I am not sure it would be the case for all devices.

I think it shouldn't be set (yet). When we get more devices in the future we 
can reconsider.

Regards,

Hans

> 
> Best wishes,
> --
> Kamil Debski
> Linux Platform Group
> Samsung Poland R&D Center
--
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:

Re: [ANN] Notes on IRC meeting on new sensor control interface, 2012-01-09 14:00 GMT+2

[Sakari Ailus]

Laurent Pinchart wrote:

Hi Sakari,

On Tuesday 10 January 2012 10:42:58 Sakari Ailus wrote:

Laurent Pinchart wrote:

On Tuesday 10 January 2012 00:26:46 Sakari Ailus wrote:

Laurent Pinchart wrote:

On Monday 09 January 2012 23:32:06 Sakari Ailus wrote:

Laurent Pinchart wrote:

On Monday 09 January 2012 18:38:25 Sakari Ailus wrote:

...


A fourth section may be required as well: at this level the frame
rate (or frame time) range makes more sense than the low-level
blanking values. The blanking values can be calculated from the
frame time and a flag which tells whether either horizontal or
vertical blanking should be preferred.


How does one typically select between horizontal and vertical
blanking ? Do mixed modes make sense ?


There are minimums and maximums for both. You can increase the frame
time by increasing value for either or both of them --- to achieve
very long frame times you may have to use both, but that's not very
common in practice. I think we should have a flag to tell which one
should be increased first --- the effect would be to have the minimum
possible value on the other.


But how do you decide in practice which one to increase when you're an
application (or middleware) developer ?


I think it's the responsibility of this library to do that, unless the
user wants really, really precise control in which case they have to
deal with the blanking values directly. In general it should be the
library.


And how does the library decide ? :-)


frame_time = pixel_rate / ((width + hblank) * (height + vblank))

The user gives you frame time and the configuration contains the
information which one to prefer. Let's say the user prefers hblank (from
the above):


That was my question, how does the user decide whether hblank or vblank is
preferred ?


I think that should be defined in the configuration itself. It's very 
unlikely there's any need to change this dynamically.


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

[PATCH] [media] s5p-fimc: Fix incorrect control ID assignment

[Sachin Kamat]

This patch fixes the mismatch between control IDs (CID) and controls
for hflip, vflip and rotate.

Signed-off-by: Sachin Kamat 
---
 drivers/media/video/s5p-fimc/fimc-core.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/s5p-fimc/fimc-core.c 
b/drivers/media/video/s5p-fimc/fimc-core.c
index 07c6254..170f791 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -811,11 +811,11 @@ int fimc_ctrls_create(struct fimc_ctx *ctx)
v4l2_ctrl_handler_init(&ctx->ctrl_handler, 3);
 
ctx->ctrl_rotate = v4l2_ctrl_new_std(&ctx->ctrl_handler, &fimc_ctrl_ops,
-V4L2_CID_HFLIP, 0, 1, 1, 0);
+   V4L2_CID_ROTATE, 0, 270, 90, 0);
ctx->ctrl_hflip = v4l2_ctrl_new_std(&ctx->ctrl_handler, &fimc_ctrl_ops,
-   V4L2_CID_VFLIP, 0, 1, 1, 0);
+   V4L2_CID_HFLIP, 0, 1, 1, 0);
ctx->ctrl_vflip = v4l2_ctrl_new_std(&ctx->ctrl_handler, &fimc_ctrl_ops,
-   V4L2_CID_ROTATE, 0, 270, 90, 0);
+   V4L2_CID_VFLIP, 0, 1, 1, 0);
ctx->ctrls_rdy = ctx->ctrl_handler.error == 0;
 
return ctx->ctrl_handler.error;
-- 
1.7.4.1

--
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: [ANN] Notes on IRC meeting on new sensor control interface, 2012-01-09 14:00 GMT+2

[Laurent Pinchart]

Hi Sakari,

On Tuesday 10 January 2012 10:42:58 Sakari Ailus wrote:
> Laurent Pinchart wrote:
> > On Tuesday 10 January 2012 00:26:46 Sakari Ailus wrote:
> >> Laurent Pinchart wrote:
> >>> On Monday 09 January 2012 23:32:06 Sakari Ailus wrote:
>  Laurent Pinchart wrote:
> > On Monday 09 January 2012 18:38:25 Sakari Ailus wrote:
> >> ...
> >> 
> >> A fourth section may be required as well: at this level the frame
> >> rate (or frame time) range makes more sense than the low-level
> >> blanking values. The blanking values can be calculated from the
> >> frame time and a flag which tells whether either horizontal or
> >> vertical blanking should be preferred.
> > 
> > How does one typically select between horizontal and vertical
> > blanking ? Do mixed modes make sense ?
>  
>  There are minimums and maximums for both. You can increase the frame
>  time by increasing value for either or both of them --- to achieve
>  very long frame times you may have to use both, but that's not very
>  common in practice. I think we should have a flag to tell which one
>  should be increased first --- the effect would be to have the minimum
>  possible value on the other.
> >>> 
> >>> But how do you decide in practice which one to increase when you're an
> >>> application (or middleware) developer ?
> >> 
> >> I think it's the responsibility of this library to do that, unless the
> >> user wants really, really precise control in which case they have to
> >> deal with the blanking values directly. In general it should be the
> >> library.
> > 
> > And how does the library decide ? :-)
> 
> frame_time = pixel_rate / ((width + hblank) * (height + vblank))
> 
> The user gives you frame time and the configuration contains the
> information which one to prefer. Let's say the user prefers hblank (from
> the above):

That was my question, how does the user decide whether hblank or vblank is 
preferred ?

> (width + hblank) * frame_time = pixel_rate / (height + vblank_min)
> 
> hblank = pixel_rate / (height + vblank_min) / frame_time - width
> 
> width, height, pixel_rate and blankings are as in the pixel array.
> Elsewhere these values may depend on the link frequency and other
> factors so the pixel array is the only reliable place to do this.

-- 
Regards,

Laurent Pinchart
--
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: [ANN] Notes on IRC meeting on new sensor control interface, 2012-01-09 14:00 GMT+2

[Sakari Ailus]

Hi Laurent,

Laurent Pinchart wrote:

On Tuesday 10 January 2012 00:26:46 Sakari Ailus wrote:

Laurent Pinchart wrote:

On Monday 09 January 2012 23:32:06 Sakari Ailus wrote:

Laurent Pinchart wrote:

On Monday 09 January 2012 18:38:25 Sakari Ailus wrote:

...


A fourth section may be required as well: at this level the frame rate
(or frame time) range makes more sense than the low-level blanking
values. The blanking values can be calculated from the frame time and
a flag which tells whether either horizontal or vertical blanking
should be preferred.


How does one typically select between horizontal and vertical blanking
? Do mixed modes make sense ?


There are minimums and maximums for both. You can increase the frame
time by increasing value for either or both of them --- to achieve very
long frame times you may have to use both, but that's not very common in
practice. I think we should have a flag to tell which one should be
increased first --- the effect would be to have the minimum possible
value on the other.


But how do you decide in practice which one to increase when you're an
application (or middleware) developer ?


I think it's the responsibility of this library to do that, unless the
user wants really, really precise control in which case they have to
deal with the blanking values directly. In general it should be the
library.


And how does the library decide ? :-)



frame_time = pixel_rate / ((width + hblank) * (height + vblank))

The user gives you frame time and the configuration contains the 
information which one to prefer. Let's say the user prefers hblank (from 
the above):


(width + hblank) * frame_time = pixel_rate / (height + vblank_min)

hblank = pixel_rate / (height + vblank_min) / frame_time - width

width, height, pixel_rate and blankings are as in the pixel array. 
Elsewhere these values may depend on the link frequency and other 
factors so the pixel array is the only reliable place to do this.


--
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: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

[InKi Dae]

2012/1/10 InKi Dae :
> 2012/1/10 Semwal, Sumit :
>> On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark  wrote:
>>> On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae  wrote:
 2012/1/10 Rob Clark :
 at least with no IOMMU, the memory information(containing physical
 memory address) would be copied to vb2_xx_buf object if drm gem
 exported its own buffer and vb2 wants to use that buffer at this time,
 sg table is used to share that buffer. and the problem I pointed out
 is that this buffer(also physical memory region) could be released by
 vb2 framework(as you know, vb2_xx_buf object and the memory region for
 buf->dma_addr pointing) but the Exporter(drm gem) couldn't know that
 so some problems would be induced once drm gem tries to release or
 access that buffer. and I have tried to resolve this issue adding
 get_shared_cnt() callback to dma-buf.h but I'm not sure that this is
 good way. maybe there would be better way.
>> Hi Inki,
>> As also mentioned in the documentation patch, importer (the user of
>> the buffer) - in this case for current RFC patches on
>> v4l2-as-a-user[1] vb2 framework - shouldn't release the backing memory
>> of the buffer directly - it should only use the dma-buf callbacks in
>> the right sequence to let the exporter know that it is done using this
>> buffer, so the exporter can release it if allowed and needed.
>
> thank you for your comments.:) and below are some tables about dmabuf
> operations with ideal use and these tables indicate reference count of
> when buffer is created, shared and released. so if there are any
> problems, please let me know. P.S. these are just simple cases so
> there would be others.
>
>
> in case of using only drm gem and dmabuf,
>
> operations                       gem refcount    file f_count   buf refcount
> 
> 1. gem create                   A:1                                   A:0
> 2. export(handle A -> fd)    A:2                A:1              A:0
> 3. import(fd -> handle B)    A:2, B:1         A:2              A:1
> 4. file close(A)                  A:2, B:1         A:1              A:1
> 5. gem close(A)                A:1, B:1         A:1              A:1
> 6. gem close(B)                A:1, B:0         A:1              A:0
> 7. file close(A)                  A:0                A:0
> ---
> 3. handle B shares the buf of handle A.
> 6. release handle B but its buf.
> 7. release gem handle A and dmabuf of file A and also physical memory region.
>
>
> and in case of using drm gem, vb2 and dmabuf,
>
> operations                  gem, vb2 refcount    file f_count   buf refcount
> 
> 1. gem create                   A:1                 A:0
>   (GEM side)
> 2. export(handle A -> fd)    A:2                 A:1              A:0
>   (GEM side)
> 3. import(fd -> handle B)    A:2, B:1          A:2              A:1
>   (VB2 side)
> 4. file close(A)                  A:2, B:1          A:1              A:1
>   (VB2 side)
> 5. vb2 close(B)                 A:2, B:0          A:1              A:0
>   (VB2 side)
> 6. gem close(A)                A:1                A:1              A:0
>   (GEM side)
> 7. file close(A)                  A:0                A:0
>   (GEM side)
> 
> 3. vb2 handle B is shared with the buf of gem handle A.
> 5. release vb2 handle B and decrease refcount of the buf pointed by it.
> 7. release gem handle A and dmabuf of file A and also physical memory region.
>

Ah, sorry, it seems that file close shouldn't be called because
file->f_count of the file would be dropped by Importer and if f_count
is 0 then the file would be released by fput() so I'm not sure but
again:

in case of using only drm gem and dmabuf,

operations   gem refcount  file f_count   buf refcount
--
1. gem create(A)   A:1 A:0
2. export(handle A -> fd)A:2  A:1  A:0
3. import(fd -> handle B)A:2, B:1   A:2  A:1
4. gem close(B)A:2, B:release  A:1  A:0
5. gem close(A)A:1, A:1  A:0
6. gem close(A)A:release A:release A:release
-

and in case of using drm gem, vb2 and dmabuf,

operations  gem, vb2 refcountfile f_count   buf refcount

1. gem create  

Re: [RFC] Future TTM DMA direction

[Daniel Vetter]

Hi Thomas,

On Mon, Jan 09, 2012 at 12:01:28PM +0100, Thomas Hellstrom wrote:
> Thanks for your input. I think this is mostly orthogonal to dma_buf, and
> really a way to adapt TTM to be DMA-api aware. That's currently done
> within the TTM backends. CMA was mearly included as an example that
> might not be relevant.
> 
> I haven't followed dma_buf that closely lately, but if it's growing
> from being just
> a way to share buffer objects between devices to something providing
> also low-level
> allocators with fragmentation prevention, there's definitely an overlap.
> However, on the dma_buf meeting in Budapest there seemed to be
> little or no interest
> in robust buffer allocation / fragmentation prevention although I
> remember bringing
> it up to the point where I felt annoying :).

Well, I've shot at you quite a bit too, and I still think it's too much
for the first few iterations. But I also think we will need a cleverer
dma subsystem sooner or later (even if it's just around dma_buf) so that's
why I've dragged your rfc out of the drm corner ;-)

Cheers, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
--
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] [media] cx23885: handle errors from videobuf_dvb_get_frontend()

[Dan Carpenter]

The error handling in the original code wasn't complete so static
checkers complained about a potential NULL deference.

Signed-off-by: Dan Carpenter 
---
Compile tested only.  I don't think there is anything else that needs to
be done before returning, but it would be great if someone could look it
over.

diff --git a/drivers/media/video/cx23885/cx23885-video.c 
b/drivers/media/video/cx23885/cx23885-video.c
index a01cd11..7ad7b4f 100644
--- a/drivers/media/video/cx23885/cx23885-video.c
+++ b/drivers/media/video/cx23885/cx23885-video.c
@@ -1541,7 +1541,6 @@ static int cx23885_set_freq_via_ops(struct cx23885_dev 
*dev,
struct v4l2_control ctrl;
struct videobuf_dvb_frontend *vfe;
struct dvb_frontend *fe;
-   int err = 0;
 
struct analog_parameters params = {
.mode  = V4L2_TUNER_ANALOG_TV,
@@ -1563,8 +1562,10 @@ static int cx23885_set_freq_via_ops(struct cx23885_dev 
*dev,
params.frequency, f->tuner, params.std);
 
vfe = videobuf_dvb_get_frontend(&dev->ts2.frontends, 1);
-   if (!vfe)
-   err = -EINVAL;
+   if (!vfe) {
+   mutex_unlock(&dev->lock);
+   return -EINVAL;
+   }
 
fe = vfe->dvb.frontend;
 
--
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: [PATCHv18 0/11] Contiguous Memory Allocator

[Marek Szyprowski]

Hello,

To help everyone in testing and adapting our patches for his hardware 
platform I've rebased our patches onto the latest v3.2 Linux kernel and
prepared a few GIT branches in our public repository. These branches
contain our memory management related patches posted in the following
threads:

"[PATCHv18 0/11] Contiguous Memory Allocator":
http://www.spinics.net/lists/linux-mm/msg28125.html
later called CMAv18,

"[PATCH 00/14] DMA-mapping framework redesign preparation":
http://www.spinics.net/lists/linux-sh/msg09777.html
and
"[PATCH 0/8 v4] ARM: DMA-mapping framework redesign":
http://www.spinics.net/lists/arm-kernel/msg151147.html
with the following update:
http://www.spinics.net/lists/arm-kernel/msg154889.html
later called DMAv5.

These branches are available in our public GIT repository:

git://git.infradead.org/users/kmpark/linux-samsung
http://git.infradead.org/users/kmpark/linux-samsung/

The following branches are available:

1) 3.2-cma-v18
Vanilla Linux v3.2 with fixed CMA v18 patches (first patch replaced
with the one from v17 to fix SMP issues, see the respective thread).

2) 3.2-dma-v5
Vanilla Linux v3.2 + iommu/next (IOMMU maintainer's patches) branch
with DMA-preparation and DMA-mapping framework redesign patches.

3) 3.2-cma-v18-dma-v5
Previous two branches merged together (DMA-mapping on top of CMA)

4) 3.2-cma-v18-dma-v5-exynos
Previous branch rebased on top of iommu/next + kgene/for-next (Samsung
SoC platform maintainer's patches) with new Exynos4 IOMMU driver by 
KyongHo Cho and relevant glue code.

5) 3.2-dma-v5-exynos
Branch from point 2 rebased on top of iommu/next + kgene/for-next 
(Samsung SoC maintainer's patches) with new Exynos4 IOMMU driver by 
KyongHo Cho and relevant glue code.

I hope everyone will find a branch that suits his needs. :)

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center



--
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: [DVB Digital Devices Cine CT V6] status support

[Martin Herrman]

2012/1/9 Thomas Kaiser :

> Hello Martin
>
> I use the DD Cine CT V6 with DVB-C. It works without problems.
> I got the driver before Oliver integrated it in his tree. Therefor I did not
> compile Olivers tree, yet.
>
> At the moment I run the card on Ubuntu 11.10 with kernel 3.0.0-14.
>
> Hope this helps.
>
> Thomas

Hi Thomas,

that is very good news, thanks a lot for the confirmation. Time to
order one myself!

Regards,

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