RE: [alsa-devel] WL1273 FM Radio driver...
On Tue, 2011-02-08 at 13:02 +0200, Peter Ujfalusi wrote: For both configuration we have a set of HCI commands to configure the FM audio path and one of my concerns is to know if the wl1273_codec should handle the audio path configuration and the switch between FM and BT SCO? It would be better if the codec could handle the configuration, depending on which DAI is in use. If we can send HCI commands from kernel, I think that would be the cleanest way. Yes, I would have done just that - and we talked a lot about it locally - if I had known how to do it. I started to work on it and also talked to some BT people but it didn't seem feasible at the time. Advice welcome of course... Cheers, Matti Hi, Below the set of HCI commands that we have identified to configure the FM and BT SCO audio paths: - External Audio Connection o START BT SCO Connection # BT audio Path PCMFM audio Path I2S hcitool cmd 0x3F 0X195 FF FF FF FF FF FF FF FF 01 02 FF 00 00 00 00 # BT AUDIO Codec Configuration: MASTER hcitool cmd 0x3F 0X106 00 03 00 40 1F 00 00 01 00 00 00 00 10 00 02 00 00 10 00 02 00 01 00 00 00 00 00 00 00 00 00 00 o STOP BT SCO Connection # BT AUDIO Codec Configuration: SLAVE hcitool cmd 0x3F 0X106 00 03 01 40 1F 00 00 01 00 00 00 00 10 00 02 00 00 10 00 02 00 01 00 00 00 00 00 00 00 00 00 00 - Internal Audio Connection o START BT SCO Connection # BT audio Path PCM # FM audio Path None hcitool cmd 0x3F 0X195 FF FF FF FF FF FF FF FF 01 00 FF 00 00 00 00 # BT AUDIO Codec Configuration: MASTER hcitool cmd 0x3F 0X106 00 03 00 40 1F 00 00 01 00 00 00 00 10 00 02 00 00 10 00 02 00 01 00 00 00 00 00 00 00 00 00 00 o STOP BT SCO Connection # BT audio Path None FM audio Path None hcitool cmd 0x3F 0X195 FF FF FF FF FF FF FF FF 00 00 FF 00 00 00 00 o FM Audio Path configuration # BT audio Path None FM audio Path PCM hcitool cmd 0x3F 0X195 FF FF FF FF FF FF FF FF 00 01 FF 00 00 00 00 Please note that the BT SCO Codec settings are platform specific. Selma. - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: Les Montalets- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros 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.
RE: Memory allocation in Video4Linux
Hi Laurent,
You make this very clear, thank you!
The ISP on Medfield do have its own IOMMU. And I also think an IOMMU layer for
ISP is needed.
I'm not quite understand unless hardware design doesn't give you a choice
about that,. Can you explain more on that?
Also regarding to the VCMM (Virtual Contiguous Memory Manager) or CMA, is it
also an option?
Thanks
Wen
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: 2011年2月10日 17:29
To: Gao, Bin
Cc: Wang, Wen W; Kanigeri, Hari K; Iyer, Sundar; Yang, Jianwei;
linux-media@vger.kernel.org; umg-meego-handset-ker...@umglistsvr.jf.intel.com;
Jozef Kruger
Subject: Re: Memory allocation in Video4Linux
Hi Wen,
On Thursday 10 February 2011 08:59:38 Gao, Bin wrote:
Penwell has IOMMU feature?
As far as I know only part of Intel server processors have this feature
which is designed originally for VT(virtualization technology).
Wen,
Can you refer to other ISP Soc drivers and see how they are dealing with
this issue? I don't understand why you need to manage MMU inside ISP, I
think the real problem is how can we allocate a large number of memory
pages from IA side where ISP can access to by DMA. Any ISP document can be
shared to help us understand what's the problem?
I second this request. It's not totally clear to me from this mail thread
whether your ISP has its own MMU (which would then be considered as an IOMMU),
or accesses the system memory through other means (continuous buffers,
scatter-gather lists, ...).
If the Medfield ISP includes an IOMMU, the IOMMU layer is probably what you
want to use. Memory can then be allocated using a simple vmalloc(), and pages
can be mapped to the ISP memory space using the IOMMU.
Please note that, unless the ISP IOMMU is already supported by the Linux
kernel, you will obviously need to implement an IOMMU driver for it. What you
shouldn't do is put that code in the ISP driver (unless hardware design
doesn't give you a choice about that, but I need to see more documentation to
answer this question).
--
Regards,
Laurent Pinchart
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{���bj)��骅w* jg�报 �茛j/�赇z罐���2���ㄨ���)摺�a囤�� �G���h��j:+v���w��佶
Re: Memory allocation in Video4Linux
Hi Wen, On Thursday 10 February 2011 10:44:58 Wang, Wen W wrote: Hi Laurent, You make this very clear, thank you! The ISP on Medfield do have its own IOMMU. And I also think an IOMMU layer for ISP is needed. I'm not quite understand unless hardware design doesn't give you a choice about that,. Can you explain more on that? Basically, Linux aims for driver reusability. That means that separate pieces of hardware, even when they are designed to work together, should be handled by separate, indepedent drivers. This might make the initial development a bit longer, as proper abstraction APIs need to be designed when they don't exist, but it cuts down time to market later when a hardware block is reused in a different silicon or board. A good example of that approach is I2C sensors. They're supported by drivers that are completely independent of the ISP they are connected to, and use the V4L2 subdev in-kernel API to communicate with the ISP in a hardware-indepedent way. IOMMU is such an API. It lets you implement support for your particular IOMMU in a self-contained drivers, which can then be used by device drivers (such as the ISP driver). For this to work, the hardware needs to have at least some level of separation between the different components. With I2C that's easy, the sensor can be controlled completely indepedently from the ISP. With the ISP IOMMU, it would more or less depend on how the registers are layed out in memory. If the ISP IOMMU registers are grouped together and separated from the other ISP registers, you should be fine. If they are mixed with ISP registers (an hypotetical bad case would for instance be if the ISP IOMMU required you to set bits in the TLB entries that describe the format of the video data stored in a page), such an abstraction would be much more difficult to achieve, and sometimes even impossible. Also regarding to the VCMM (Virtual Contiguous Memory Manager) or CMA, is it also an option? I'm not sure about VCMM, it seems to be an attempt to unify memory management across IOMMUs and system MMU. I don't think you need to worry about it now, IOMMU should be enough for your needs. CMA, as its name implies, is a contiguous memory allocator. As your ISP has an IOMMU, you don't need to allocate contiguous memory, so CMA isn't useful for your hardware. -- 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: Memory allocation in Video4Linux
Hi Bin, the ISP in Medfield has it's own MMU. This needs to be programmed. So in fact we have 2 problems: 1. how to allocate large memory address space (allocating pages is not the problem). 2. if we re-use OS functionality for this, we need to keep the ISP MMU up to date. This means it needs to be programmed with the L1 page table base address and the TLB needs to be flushed whenever something changes in the page tables. I don't think you need any ISP specific documentation for this. The ISP MMU behaves the same as the IA MMU does. Best regards, Jozef On 02/09/2011 11:59 PM, Gao, Bin wrote: Penwell has IOMMU feature? As far as I know only part of Intel server processors have this feature which is designed originally for VT(virtualization technology). Wen, Can you refer to other ISP Soc drivers and see how they are dealing with this issue? I don't understand why you need to manage MMU inside ISP, I think the real problem is how can we allocate a large number of memory pages from IA side where ISP can access to by DMA. Any ISP document can be shared to help us understand what's the problem? -Bin -Original Message- From: umg-meego-handset-kernel-boun...@umglistsvr.jf.intel.com [mailto:umg-meego-handset-kernel-boun...@umglistsvr.jf.intel.com] On Behalf Of Wang, Wen W Sent: Tuesday, February 08, 2011 11:27 PM To: Kanigeri, Hari K; Iyer, Sundar; Yang, Jianwei; linux-media@vger.kernel.org; umg-meego-handset-ker...@umglistsvr.jf.intel.com Cc: Jozef Kruger Subject: Re: [Umg-meego-handset-kernel] Memory allocation in Video4Linux Hi Hari, You are right. What we need is virtual address. Currently we alloc pages (alloc_pages()) for any request. Store those pages for an image buffer into a list. We also manage the virtual address for ISP by ourself (the range from 0 to 4GB) and the page table for our MMU which is independent to system MMU page table. Thanks Wen -Original Message- From: Kanigeri, Hari K Sent: 2011年2月9日 15:22 To: Iyer, Sundar; Wang, Wen W; Yang, Jianwei; linux-media@vger.kernel.org; umg-meego-handset-ker...@umglistsvr.jf.intel.com Cc: Jozef Kruger Subject: RE: Memory allocation in Video4Linux -Original Message- From: umg-meego-handset-kernel-boun...@umglistsvr.jf.intel.com [mailto:umg-meego-handset-kernel-boun...@umglistsvr.jf.intel.com] On Behalf Of Iyer, Sundar Sent: Wednesday, February 09, 2011 12:20 PM To: Wang, Wen W; Yang, Jianwei; linux-media@vger.kernel.org; umg-meego- handset-ker...@umglistsvr.jf.intel.com Cc: Jozef Kruger Subject: Re: [Umg-meego-handset-kernel] Memory allocation in Video4Linux I remember some Continous Memory Allocator (CMA) being iterated down a few versions on some mailing lists? IIRC, it is also for large buffers and management for video IPs. I believe CMA is for allocating physically contiguous memory and from what Wen mentioned he also needs virtual memory management, which the IOMMU will provide. Please check the open source discussion on CMA, the last I heard CMA proposal was shot down. Reference: http://www.spinics.net/lists/linux-media/msg26875.html Wen, how are you currently allocating physical memory ? Thank you, Best regards, Hari ___ Umg-meego-handset-kernel mailing list umg-meego-handset-ker...@umglistsvr.jf.intel.com http://umglistsvr.jf.intel.com/mailman/listinfo/umg-meego-handset-kernel -- Jozef Kruger Senior Customer Solutions Architect Silicon Hive Inc. 2025 Gateway Place, Suite 230 San Jose, CA 95110 phone: +1 408 512 2969 cell: +1 408 644 7533 fax: +1 408 437 6014 jozef.kru...@siliconhive.com http://www.siliconhive.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: [alsa-devel] WL1273 FM Radio driver...
Hello. On Thu, 2011-02-10 at 09:35 +, ext Bensaid, Selma wrote: On Tue, 2011-02-08 at 13:02 +0200, Peter Ujfalusi wrote: For both configuration we have a set of HCI commands to configure the FM audio path and one of my concerns is to know if the wl1273_codec should handle the audio path configuration and the switch between FM and BT SCO? It would be better if the codec could handle the configuration, depending on which DAI is in use. If we can send HCI commands from kernel, I think that would be the cleanest way. Yes, I would have done just that - and we talked a lot about it locally - if I had known how to do it. I started to work on it and also talked to some BT people but it didn't seem feasible at the time. Advice welcome of course... Cheers, Matti Hi, Below the set of HCI commands that we have identified to configure the FM and BT SCO audio paths: - External Audio Connection o START BT SCO Connection # BT audio Path PCMFM audio Path I2S hcitool cmd 0x3F 0X195 FF FF FF FF FF FF FF FF 01 02 FF 00 00 00 00 # BT AUDIO Codec Configuration: MASTER hcitool cmd 0x3F 0X106 00 03 00 40 1F 00 00 01 00 00 00 00 10 00 02 00 00 10 00 02 00 01 00 00 00 00 00 00 00 00 00 00 o STOP BT SCO Connection # BT AUDIO Codec Configuration: SLAVE hcitool cmd 0x3F 0X106 00 03 01 40 1F 00 00 01 00 00 00 00 10 00 02 00 00 10 00 02 00 01 00 00 00 00 00 00 00 00 00 00 - Internal Audio Connection o START BT SCO Connection # BT audio Path PCM # FM audio Path None hcitool cmd 0x3F 0X195 FF FF FF FF FF FF FF FF 01 00 FF 00 00 00 00 # BT AUDIO Codec Configuration: MASTER hcitool cmd 0x3F 0X106 00 03 00 40 1F 00 00 01 00 00 00 00 10 00 02 00 00 10 00 02 00 01 00 00 00 00 00 00 00 00 00 00 o STOP BT SCO Connection # BT audio Path None FM audio Path None hcitool cmd 0x3F 0X195 FF FF FF FF FF FF FF FF 00 00 FF 00 00 00 00 o FM Audio Path configuration # BT audio Path None FM audio Path PCM hcitool cmd 0x3F 0X195 FF FF FF FF FF FF FF FF 00 01 FF 00 00 00 00 Please note that the BT SCO Codec settings are platform specific. Selma. We know these messages, they are mentioned in the documentation and we use them already, but we send them from the user space. The problem is how to send the messages from the driver within the kernel. Thanks, Matti - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: Les Montalets- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros 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: Memory allocation in Video4Linux
Wang, Wen W wrote: Hi Hans, Thanks for your point and videobuf2 is also what I want to use. But since our development kernel version right now is still 2.6.35, I need to find way to work with current videobuf framework. Hi Wen, If you're bound to use that kernel version, then one option to consider might be backporting the videobuf2 to that kernel. 2.6.35 isn't so old. You'd save work by not implementing the buffer handling on your own AND also, you wouldn't later need to port the driver to use videobuf2. I would suggest not to start using the old videobuf at this point. With the current ISPs with their own MMUs it really does more harm than good. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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: [alsa-devel] WL1273 FM Radio driver...
On Thu, Feb 10, 2011 at 02:10:40PM +0200, Matti J. Aaltonen wrote: But I got the following quick comment from a local BT expert: No you cannot change line discipline if bt is already in use. And it's not uart interface but hci interface. uart can be replaced with sdio for example and you still have the same hci interface. Yes, it only works when the device is idle - if your device needs to be shared with other bits of the system while doing this you'd need to present a virtual interface up the way. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] WL1273 FM Radio driver...
On Thu, 2011-02-10 at 12:28 +, ext Mark Brown wrote: On Thu, Feb 10, 2011 at 02:10:40PM +0200, Matti J. Aaltonen wrote: But I got the following quick comment from a local BT expert: No you cannot change line discipline if bt is already in use. And it's not uart interface but hci interface. uart can be replaced with sdio for example and you still have the same hci interface. Yes, it only works when the device is idle - if your device needs to be shared with other bits of the system while doing this you'd need to present a virtual interface up the way. And a comment to the above from the earlier mentioned local BT expert: It would need some hack to generic hci code. Or maybe some kind of management api extension. That should be a few line only.. but getting it to upstream sounds like mission impossible. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] WL1273 FM Radio driver...
On Thu, Feb 10, 2011 at 02:57:47PM +0200, Matti J. Aaltonen wrote: And a comment to the above from the earlier mentioned local BT expert: It would need some hack to generic hci code. Or maybe some kind of management api extension. That should be a few line only.. but getting it to upstream sounds like mission impossible. I don't see any particular problem getting something like that upstream if it works over multiple devices; we've already got stuff like that for the Amstrad Delta platform. -- 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: Tuning channels with DViCO FusionHDTV7 Dual Express
On Wed, Feb 09, 2011 at 08:25:32PM -0500, Andy Walls wrote: On Tue, 2011-02-08 at 22:41 -0700, Dave Johansen wrote: On Tue, Feb 8, 2011 at 9:51 AM, Dave Johansen davejohan...@gmail.com wrote: On Tue, Feb 8, 2011 at 8:25 AM, Mark Zimmerman markz...@frii.com wrote: On Mon, Feb 07, 2011 at 06:54:30PM -0500, Andy Walls wrote: You perhaps could A. provide the smallest window of known good vs known bad kernel versions. Maybe someone with time and hardware can 'git bisect' the issue down to the problem commit. (I'm guessing this problem might be specific to a particular 64 bit platform IOMMU type, given the bad dma_ops pointer.) FYI: I am on the process of doing a git bisect (10 kernels to go) to track down this problem: http://www.mail-archive.com/linux-media@vger.kernel.org/msg25342.html Which may or may not be related to the problem in this thread. I'm using Mythbuntu 10.10 x64, which I believe uses 2.6.35 but I will check tonight, so if the issue you're tracking down really is related to 2.6.36, then I imagine that my problem wouldn't be caused by what you're looking into. Plus, every time I've looked at dmesg the firmware has loaded properly, so I'm guessing I'm on 2.6.35 and being affected by a different issue. Thanks for the heads up, Dave So I don't know how useful this is, but I tried Mythbuntu 10.10 x86 and it works like a charm. So the issue appears to be isolated to the x64 build. You validated my guess. :) If there's anything I can do to help figure out what the cause of this issue is in the x64 build, then please let me know and I'll do my best to help out. So this increases the likelyhood that this is a kernel problem introduced outside of the drivers/media directory. To find it, someone needs to clone out the kernel with git; start a git bisect using the lastest known good and earliest known bad kernel versions; and build, install, and test kernels until the problem is found, as outlined here: http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/ http://manpages.ubuntu.com/manpages/maverick/man1/git-bisect.1.html The build, install and test kernels step is the pain. Let's say it takes a 2 core AMD64 machine about 17 minutes to build a minimal kernel. The number of kernels that need to be tested will be roughly log2(Number of commits between known good and bad kernels). So 30,000 commits will require roughly 15 kernel builds to narrow the problem. If it takes 20 minutes per iteration, that's 5 hours to find the problem. That someone also needs 64 bit hardware and a board supported by the cx23885 driver that also exhibits the problem. I have an HVR-1850 and a 64-bit machine, but I haven't tested it yet. I do not have 5 hours free. Sorry. The slowest part of the process for me was deciding to start. After that, the 'install, test, and reboot back into a good kernel' cycle takes about 10 minutes, then I start the next build and walk away. By squeezing in one cycle in the morning before leaving for work, and one or two in the evening, I have gotten this far: Bisecting: 37 revisions left to test after this (roughly 5 steps) -- 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 PATCHES FOR 2.6.39] gspca for_v2.6.39
The following changes since commit 6148a47ac3872092d4bc438bec6dff16654d: Merge branch 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6 (2011-02-09 16:56:33 -0800) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v2.6.39 Jean-François Moine (16): gspca - sonixj: Move the avg lum computation to a separate function gspca - sonixj: Better scanning of isochronous packets gspca - sonixj: Have the same JPEG quality for encoding and decoding gspca - sonixj: Update the JPEG quality for best image transfer gspca - sonixj: Fix start sequence of sensor mt9v111 gspca - sonixj: Adjust autogain for sensor mt9v111 gspca - sonixj: Simplify GPIO setting when audio present gspca - sonixj: Same init for all bridges but the sn9c102p gspca - sonixj: Set both pins for infrared of mt9v111 webcams gspca - sonixj, zc3xx: Let some bandwidth for audio when USB 1.1 gspca - ov534: Use the new control mechanism gspca - ov534: Add the webcam 06f8:3002 and sensor ov767x gspca - ov534: Add saturation control for ov767x gspca - sonixj: The pin S_PWR_DN is inverted for sensor mi0360 gspca - ov519: Add the sensor ov2610ae gspca - ov519: Add the 800x600 resolution for sensors ov2610/2610ae Documentation/video4linux/gspca.txt |1 + drivers/media/video/gspca/ov519.c | 90 +++- drivers/media/video/gspca/ov534.c | 980 +-- drivers/media/video/gspca/sonixj.c | 353 - drivers/media/video/gspca/zc3xx.c |4 + 5 files changed, 912 insertions(+), 516 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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
