Re: [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
Hi Laurent, On Fri, Oct 26, 2012 at 11:35 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: That's on my to-do list, as well as porting the OMAP3 ISP driver to videobuf2, adding DT support, moving to the common clock framework (when that will be available for the OMAP3), supporting missing V4L2 features, ... All this in my spare time of course, otherwise it wouldn't be fun, would it ? ;-) Hmm, seems like a short to-do list ;) I would also like to move the tidspbridge to the DMA API, but I think we'll need to move step by step there, and using the OMAP IOMMU and IOVMM APIs as an intermediate step would allow splitting patches in reviewable chunks. I know it's a step backwards in term of OMAP IOMMU usage, but that's in my opinion a temporary nuisance to make the leap easier. Since tidspbridge is in staging I guess it's not a problem, though it sounds to me like using the correct API in the first place is going to make less churn. Thanks, Ohad. -- 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 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
On Thu, Oct 25, 2012 at 11:39 PM, Tony Lindgren t...@atomide.com wrote: Joerg and Ohad, do you have any opinions on this? I agree that there's some merit in having a separate header file for IOVMM, since it's a different layer from the IOMMU API. But in reality it's tightly coupled with OMAP's IOMMU, and ideally it really should go away and be replaced with the DMA API. For this reason, and for the fact that anyway there's only a single user for it (omap3isp) and there will never be any more, maybe we shouldn't pollute include/linux anymore. Anyone volunteering to remove IOVMM and adapt omap3isp to the DMA API instead ? ;) Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 12/15] drivers: add Contiguous Memory Allocator
Hi Marek, On Mon, Jan 30, 2012 at 9:43 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: Did you managed to fix this issue? Yes -- the recent increase in the vmalloc region triggered a bigger truncation in the system RAM than we had before, and therefore conflicted with the previous hardcoded region we were using. Long term, our plan is to get rid of those hardcoded values, but for the moment our remote RTOS still needs to know the physical address in advance. Right, thanks for spotting it, I will squash it to the next release. Thanks. With that hunk squashed in, feel free to add my Tested-by tag to the patches. Thanks! Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 12/15] drivers: add Contiguous Memory Allocator
Hi Marek,
On Fri, Jan 27, 2012 at 5:17 PM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
There have been some vmalloc layout changes merged to v3.3-rc1.
That was dead-on, thanks a lot!
I did then bump into a different allocation failure which happened
because dma_alloc_from_contiguous() computes 'mask' before capping the
'align' argument.
The early 'mask' computation was added in v18 (and therefore exists in
v19 too) and I was actually testing v17 previously, so I didn't notice
it before.
You may want to squash something like this:
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index f41e699..8455cb7 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -319,8 +319,7 @@ struct page *dma_alloc_from_contiguous(struct device *dev, i
unsigned int align)
{
struct cma *cma = dev_get_cma_area(dev);
- unsigned long pfn, pageno, start = 0;
- unsigned long mask = (1 align) - 1;
+ unsigned long mask, pfn, pageno, start = 0;
int ret;
if (!cma || !cma-count)
@@ -329,6 +328,8 @@ struct page *dma_alloc_from_contiguous(struct device *dev, i
if (align CONFIG_CMA_ALIGNMENT)
align = CONFIG_CMA_ALIGNMENT;
+ mask = (1 align) - 1;
+
pr_debug(%s(cma %p, count %d, align %d)\n, __func__, (void *)cma,
count, align);
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 12/15] drivers: add Contiguous Memory Allocator
Hi Marek,
With v19, I can't seem to allocate big regions anymore (e.g. 101MiB).
In particular, this seems to fail:
On Thu, Jan 26, 2012 at 11:00 AM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
+static int cma_activate_area(unsigned long base_pfn, unsigned long count)
+{
+ unsigned long pfn = base_pfn;
+ unsigned i = count pageblock_order;
+ struct zone *zone;
+
+ WARN_ON_ONCE(!pfn_valid(pfn));
+ zone = page_zone(pfn_to_page(pfn));
+
+ do {
+ unsigned j;
+ base_pfn = pfn;
+ for (j = pageblock_nr_pages; j; --j, pfn++) {
+ WARN_ON_ONCE(!pfn_valid(pfn));
+ if (page_zone(pfn_to_page(pfn)) != zone)
+ return -EINVAL;
The above WARN_ON_ONCE is triggered, and then the conditional is
asserted (page_zone() retuns a Movable zone, whereas zone is
Normal) and the function fails.
This happens to me on OMAP4 with your 3.3-rc1-cma-v19 branch (and a
bunch of remoteproc/rpmsg patches).
Do big allocations work for you ?
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 12/15] drivers: add Contiguous Memory Allocator
2012/1/27 Marek Szyprowski m.szyprow...@samsung.com: I've tested it with 256MiB on Exynos4 platform. Could you check if the problem also appears on 3.2-cma-v19 branch (I've uploaded it a few hours ago) Exactly what I needed, thanks :) Both v18 and v19 seem to work fine with 3.2. The above code has not been changed since v16, so I'm really surprised that it causes problems. Maybe the memory configuration or layout has been changed in 3.3-rc1 for OMAP4? Not sure what the culprit is, but it is only triggered with 3.3-rc1. I'll tell you if I find anything. Thanks! Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 12/15] drivers: add Contiguous Memory Allocator
2012/1/27 Marek Szyprowski m.szyprow...@samsung.com: Ohad, could you tell a bit more about your issue? Sure, feel free to ask. Does this 'large region' is a device private region (declared with dma_declare_contiguous()) Yes, it is. See omap_rproc_reserve_cma() in: http://git.kernel.org/?p=linux/kernel/git/ohad/remoteproc.git;a=commitdiff;h=dab6a2584550a629746fa1dea2be8ffbe1910277 Thanks, Ohad. -- 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: omap3isp hangs with 3.2-rc2
On Sun, Dec 18, 2011 at 11:47 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Investigation complete. http://patchwork.linuxtv.org/patch/8451/ Great, thanks a lot Laurent ! -- 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] omap3isp: fix compilation of ispvideo.c
On Wed, Nov 23, 2011 at 3:53 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Sunday 20 November 2011 17:54:26 Dmitry Artamonow wrote: Fix following build error by explicitely including linux/module.h header file. CC drivers/media/video/omap3isp/ispvideo.o drivers/media/video/omap3isp/ispvideo.c:1267: error: 'THIS_MODULE' undeclared here (not in a function) make[4]: *** [drivers/media/video/omap3isp/ispvideo.o] Error 1 make[3]: *** [drivers/media/video/omap3isp] Error 2 make[2]: *** [drivers/media/video] Error 2 make[1]: *** [drivers/media] Error 2 make: *** [drivers] Error 2 Signed-off-by: Dmitry Artamonow mad_s...@inbox.ru Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Mauro, can you pick this for v3.2, or would you like me to send a pull request ? Folks, was this one picked up by anyone ? We seem to still have this issue in mainline (at least in rc4). Thanks, Ohad. -- 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
omap3isp hangs with 3.2-rc2
Hi Laurent, With 3.2-rc2, omap3isp seems to silently hang in my setup (sensor-less OMAP3). Turning on lockdep yields the below messages, care to take a quick look ? Thanks! Ohad. root@zoom3:~# media-ctl -r -l 'OMAP3 ISP CCP2 input:0-OMAP3 ISP CCP2:0[1], OMAP3 ISP CCP 2:1-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -f 'OMAP3 ISP CCP2:0[SGRBG10 1280x1024], OMAP3 ISP CCP2:1[SGRBG10 1280x1024], OMAP3 ISP CCDC:1[SGRBG10 1280x1024], OMAP3 ISP CCDC:2[SGRBG10 12 80x1023]' [ 29.014221] Linux video capture interface: v2.00 [ 29.423675] omap3isp omap3isp: Revision 15.0 found [ 29.429168] omap-iommu omap-iommu.0: isp: version 1.1 Resetting all links to inactive Setting up link 2:0 - 1:0 [1] Setting up link 1:1 - 5:0 [1] Setting up link 5:1 - 6:0 [1] Setting up format SGRBG10 1280x1024 on pad OMAP3 ISP CCP2/0 Format set: SGRBG10 1280x1024 Setting up format SGRBG10 1280x1024 on pad OMAP3 ISP CCP2/1 Format set: SGRBG10 1280x1024 Setting up format SGRBG10 1280x1024 on pad OMAP3 ISP CCDC/0 Format set: SGRBG10 1280x1024 Setting up format SGRBG10 1280x1024 on pad OMAP3 ISP CCDC/1 Format set: SGRBG10 1280x1024 Setting up format SGRBG10 1280x1023 on pad OMAP3 ISP CCDC/2 Format set: SGRBG10 1280x1023 Setting up format SGRBG10 1280x1023 on pad OMAP3 ISP AEWB/0 Unable to set format: Invalid argument (-22) Setting up format SGRBG10 1280x1023 on pad OMAP3 ISP AF/0 Unable to set format: Invalid argument (-22) Setting up format SGRBG10 1280x1023 on pad OMAP3 ISP histogram/0 Unable to set format: Invalid argument (-22) At this point, running 'yavta.sh CCP2 input' and 'yavta.sh CCDC output' in two different terminals yields: root@zoom2:~# [ 55.867156] INFO: trying to register non-static key. [ 55.872161] the code is fine but needs lockdep annotation. [ 55.877624] turning off the locking correctness validator. [ 55.883178] [c001c8f0] (unwind_backtrace+0x0/0x134) from [c009304c] (__lock_acquire+0x79c/0xb54) [ 55.892333] [c009304c] (__lock_acquire+0x79c/0xb54) from [c0093a44] (lock_acquire+0x98/0x118) [ 55.901214] [c0093a44] (lock_acquire+0x98/0x118) from [c0498bb0] (_raw_spin_lock_irqsave+0x5c/0x70) [ 55.910675] [c0498bb0] (_raw_spin_lock_irqsave+0x5c/0x70) from [bf0393c4] (v4l2_event_queue+0x28/0x6c [videodev]) [ 55.921417] [bf0393c4] (v4l2_event_queue+0x28/0x6c [videodev]) from [bf0612b0] (ccdc_hs_vs_isr+0x3c/0x44 [omap3_isp]) [ 55.932464] [bf0612b0] (ccdc_hs_vs_isr+0x3c/0x44 [omap3_isp]) from [bf0614a8] (omap3isp_ccdc_isr+0x1f0/0x430 [omap3_isp]) [ 55.943847] [bf0614a8] (omap3isp_ccdc_isr+0x1f0/0x430 [omap3_isp]) from [bf057514] (isp_isr+0x174/0x284 [omap3_isp]) [ 55.954742] [bf057514] (isp_isr+0x174/0x284 [omap3_isp]) from [c00a41d4] (handle_irq_event_percpu+0x64/0x268) [ 55.965026] [c00a41d4] (handle_irq_event_percpu+0x64/0x268) from [c00a4414] (handle_irq_event+0x3c/0x5c) [ 55.974884] [c00a4414] (handle_irq_event+0x3c/0x5c) from [c00a7264] (handle_level_irq+0xac/0x118) [ 55.984130] [c00a7264] (handle_level_irq+0xac/0x118) from [c00a3c78] (generic_handle_irq+0x34/0x44) [ 55.993530] [c00a3c78] (generic_handle_irq+0x34/0x44) from [c0015c38] (handle_IRQ+0x4c/0xac) [ 56.002349] [c0015c38] (handle_IRQ+0x4c/0xac) from [c049961c] (__irq_svc+0x3c/0xe0) [ 56.010375] [c049961c] (__irq_svc+0x3c/0xe0) from [c005fe80] (__do_softirq+0x64/0x244) [ 56.018646] [c005fe80] (__do_softirq+0x64/0x244) from [c00602b8] (irq_exit+0xa0/0xa8) [ 56.026824] [c00602b8] (irq_exit+0xa0/0xa8) from [c0015c3c] (handle_IRQ+0x50/0xac) [ 56.034759] [c0015c3c] (handle_IRQ+0x50/0xac) from [c049961c] (__irq_svc+0x3c/0xe0) [ 56.042785] [c049961c] (__irq_svc+0x3c/0xe0) from [c0499340] (_raw_spin_unlock_irqrestore+0x34/0x5c) [ 56.052307] [c0499340] (_raw_spin_unlock_irqrestore+0x34/0x5c) from [bf059284] (omap3isp_video_queue_streamon+0x8c/0x9c [omap3_isp]) [ 56.064636] [bf059284] (omap3isp_video_queue_streamon+0x8c/0x9c [omap3_isp]) from [bf05b2b8] (isp_video_streamon+0x158/0x23c [omap3_isp]) [ 56.077392] [bf05b2b8] (isp_video_streamon+0x158/0x23c [omap3_isp]) from [bf034f28] (__video_do_ioctl+0x271c/0x5bb8 [videodev]) [ 56.089263] [bf034f28] (__video_do_ioctl+0x271c/0x5bb8 [videodev]) from [bf0323c4] (video_usercopy+0x138/0x50c [videodev]) [ 56.100708] [bf0323c4] (video_usercopy+0x138/0x50c [videodev]) from [bf031464] (v4l2_ioctl+0x88/0x150 [videodev]) [ 56.111358] [bf031464] (v4l2_ioctl+0x88/0x150 [videodev]) from [c011b3b0] (do_vfs_ioctl+0x7c/0x5b4) [ 56.120758] [c011b3b0] (do_vfs_ioctl+0x7c/0x5b4) from [c011b95c] (sys_ioctl+0x74/0x7c) [ 56.129028] [c011b95c] (sys_ioctl+0x74/0x7c) from [c0014b80] (ret_fast_syscall+0x0/0x3c) [ 71.577758] BUG: spinlock lockup on CPU#0, yavta/1302 [ 71.582824] lock: cf345e0c, .magic: , .owner: none/-1, .owner_cpu: 0 [ 71.590148] [c001c8f0] (unwind_backtrace+0x0/0x134) from [c0265034] (do_raw_spin_lock+0xb8/0x150) [ 71.599395] [c0265034] (do_raw_spin_lock+0xb8/0x150) from [c0498bb8] (_raw_spin_lock_irqsave+0x64/0x70) [
Re: [Linaro-mm-sig] [PATCHv16 0/9] Contiguous Memory Allocator
On Fri, Oct 7, 2011 at 6:27 PM, Arnd Bergmann a...@arndb.de wrote: IMHO it would be good to merge the entire series into 3.2, since the ARM portion fixes an important bug (double mapping of memory ranges with conflicting attributes) that we've lived with for far too long, but it really depends on how everyone sees the risk for regressions here. If something breaks in unfixable ways before the 3.2 release, we can always revert the patches and have another try later. I didn't thoroughly review the patches, but I did try them out (to be precise, I tried v15) on an OMAP4 PandaBoard, and really liked the result. The interfaces seem clean and convenient and things seem to work (I used a private CMA pool with rpmsg and remoteproc, but also noticed that several other drivers were utilizing the global pool). And with this in hand we can finally ditch the old reserve+ioremap approach. So from a user perspective, I sure do hope this patch set gets into 3.2; hopefully we can just fix anything that would show up during the 3.2 cycle. Marek, Michal (and everyone involved!), thanks so much for pushing this! Judging from the history of this patch set and the areas that it touches (and from the number of LWN articles ;) it looks like a considerable feat. FWIW, feel free to add my Tested-by: Ohad Ben-Cohen o...@wizery.com (small and optional comment: I think it'd be nice if dma_declare_contiguous would fail if called too late, otherwise users of that misconfigured device will end up using the global pool without easily knowing that something went wrong) Thanks, Ohad. -- 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 2/6] omap: iovmm: generic iommu api migration
On Wed, Jun 8, 2011 at 1:46 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Tuesday 07 June 2011 15:46:26 Ohad Ben-Cohen wrote: Where do you take care of those potential offsets today ? Or do you simply ignore the offsets and map the entire page ? Here http://marc.info/?l=linux-omapm=130693502326513w=2 :-) :) Ok so it seems iovmm will take care of that for now ? Let's get the basics working with the IOMMU API and then revise this when we switch from iovmm to the generic dma. Thanks, Ohad. -- 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 0/6] iommu: generic api migration and grouping
On Tue, Jun 7, 2011 at 10:52 AM, Roedel, Joerg joerg.roe...@amd.com wrote: Yup. Btw, is there any IOMMU hardware which supports non-natural alignment? In this case we need to expose these requirements somehow. Not sure there are. Let's start with natural alignment, and extend it only if someone with additional requirements shows up. -- 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 2/6] omap: iovmm: generic iommu api migration
Hi Laurent, On Tue, Jun 7, 2011 at 12:05 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: pgsz isn't used anymore, you can remove it. Ok. + order = get_order(bytes); Does iommu_map() handle offsets correctly, or does it expect pa to be aligned to an order (or other) boundary ? Right now we have a BUG_ON if pa is unaligned, but that can be changed if needed (do we want it to handle offsets ?). As Russell pointed out, we should use sg-length instead of sg_dma_length(sg). sg_dma_length(sg) is only valid after the scatter list has been DMA-mapped, which doesn't happen in the iovmm driver. This applies to all sg_dma_len(sg) calls. I'll make sure I don't introduce such calls, but it sounds like a separate patch should take care of the existing ones; pls tell me if you want me to send one. Thanks, Ohad. -- 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 0/6] iommu: generic api migration and grouping
On Tue, Jun 7, 2011 at 12:58 PM, Roedel, Joerg joerg.roe...@amd.com wrote: Btw, mind to split out your changes which move the iommu-api into drivers/iommu? I can merge them meanwhile into my iommu tree and start working on a proposal for the generic large page-size support. Sure, that will be great. Thanks! -- 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 1/6] omap: iommu: generic iommu api migration
Hi Laurent, On Tue, Jun 7, 2011 at 12:22 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: + BUG_ON(!IS_ALIGNED((long)omap_domain-pgtable, IOPGD_TABLE_SIZE)); Either __get_free_pages() guarantees that the allocated memory will be aligned on an IOPGD_TABLE_SIZE boundary, in which case the BUG_ON() is unnecessary, or doesn't offer such guarantee, in which case the BUG_ON() will oops randomly. Curious, does it oops randomly today ? (i just copied this from omap_iommu_probe, where it always existed). It is a bit ugly though, and thinking on it again, 16KB is not that big. We can just use kmalloc here, which does ensure the alignment (or, better yet, kzalloc, and then ditch the memset). In both cases BUG_ON() should probably be avoided. I disagree; we must check this so user data won't be harmed (hardware requirement), and if a memory allocation API fails to meet its requirements - that's really bad and user data is again at stake (much more will break, not only the iommu driver). This leaks omap_domain-pgtable. The free_pages() call in omap_iommu_remove() should be removed, as omap_iommu_probe() doesn't allocate the pages table anymore. thanks ! You can also remove the the struct iommu::iopgd field. No, I can't; it's used when the device is attached to an address space domain. You return 0 in the bogus pte/pgd cases. Is that intentional ? Yes, that's probably the most (if any) reasonable value to return here (all other iommu implementations are doing so too). Thanks, Ohad. -- 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 1/6] omap: iommu: generic iommu api migration
On Tue, Jun 7, 2011 at 2:40 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: My point is that if the allocator guarantees the alignment (not as a side effect of the implementation, but per its API) there's no need to check it again. As the alignement is required, we need an allocator that guarantees it anyway. I understand, but I'd still prefer to have an explicit check that the hardware alignment requirement is met. There's no cost in doing that (it's a cold path), and even if it would only fail once and with an extremely broken kernel - it's worth it. Will save huge amount of debugging pain (think of the poor guy that will have to debug this...). Thanks, Ohad. -- 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 2/6] omap: iovmm: generic iommu api migration
Hi Laurent, On Tue, Jun 7, 2011 at 2:26 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Right now we have a BUG_ON if pa is unaligned, but that can be changed if needed (do we want it to handle offsets ?). At least for the OMAP3 ISP we need to, as video buffers don't necessarily start on page boundaries. Where do you take care of those potential offsets today ? Or do you simply ignore the offsets and map the entire page ? Seems like omap's iommu (mostly) rejects unaligned pa addresses, see: 4abb761749abfb4ec403e4054f9dae2ee604e54f omap iommu: Reject unaligned addresses at setting page table entry (this doesn't seem to cover 4KB entries though, only large pages, sections and super sections) A separate patch is indeed needed, yes. As you're already working on iommu it might be simpler if you add it to your tree. Sure, i'll send it. Thanks, Ohad. -- 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 0/6] iommu: generic api migration and grouping
Hi Joerg, On Mon, Jun 6, 2011 at 1:09 PM, Roedel, Joerg joerg.roe...@amd.com wrote: The IOMMU-API already supports multiple page-sizes. See the 'order'-parameter of the map/unmap functions. This is insufficient; users need somehow to tell what page sizes are supported by the underlying hardware (we can't assume host page-sizes, and we want to use bigger pages whenever possible, to relax the TLB pressure). Further generalizing of iovmm strongly depends on our broader plans for providing a generic virtual memory manager and allocation framework (which, as discussed, should be separated from a specific mapper). The generic vmm for DMA is called DMA-API :) Any reason for not using that (those reasons should be fixed)? This is definitely something we will look into (dspbridge will need it too, not only omap3isp). Thanks, Ohad. -- 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 0/6] iommu: generic api migration and grouping
On Mon, Jun 6, 2011 at 12:10 PM, Arnd Bergmann a...@arndb.de wrote: I'd still prefer us to take small steps here, and not gate the omap iommu cleanups with Marek's generic dma_map_ops work though. Let's go forward and migrate omap's iommu to the generic iommu API, so new code will be able to use it (e.g. the long coming virtio-based IPC/AMP framework). Yes, of course. That's what I meant. Moving over omap to the IOMMU API is required anyway, so there is no point delaying that. Ok, great ! -- 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 0/6] iommu: generic api migration and grouping
On Mon, Jun 6, 2011 at 10:20 PM, Roedel, Joerg joerg.roe...@amd.com wrote: Well, it certainly makes sense to have a single implementation for this. But I want to hide this complexity to the user of the IOMMU-API. The best choice is to put this into the layer between the IOMMU-API and the backend implementation. I agree. The IOMMU API should take physically contiguous regions from the user, split them up according to page-sizes (/alignment requirements) supported by the hardware, and then tell the underlying implementation what to map where. That interface is not put into stone. There were other complains about the -unmap part recently, so there is certainly room for improvement there. Once the supported page sizes are exposed to the framework, the current -unmap API should probably be enough. 'va' + 'order' sounds like all the information an implementation needs to unmap a page. -- 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 0/6] iommu: generic api migration and grouping
Hi Arnd, On Fri, Jun 3, 2011 at 6:53 PM, Arnd Bergmann a...@arndb.de wrote: I think the future of iovmm is looking not so good. Marek Szyprowski is working on a generic version of the dma-mapping API (dma_map_ops) based on the iommu API. Nice! I missed Marek's work somehow. As far as I can tell, once we have that in place, we you can migrate omap3isp from iovmm to dma-mapping and remove iovmm. Sounds like a plan. I'd still prefer us to take small steps here, and not gate the omap iommu cleanups with Marek's generic dma_map_ops work though. Let's go forward and migrate omap's iommu to the generic iommu API, so new code will be able to use it (e.g. the long coming virtio-based IPC/AMP framework). We'll migrate iovmm/omap3isp just enough so they don't break, but once the generic dma_map_ops work materializes, we'd be able to complete the migration, remove iovmm, and decouple omap3isp from omap-specific iommu APIs for good. I've only moved the omap and msm implementations for now, to demonstrate the idea (and support the ARM diet :), but if this is found desirable, we can bring in intel-iommu.c and amd_iommu.c as well. Yes, very good idea. Great! (to move intel-iommu.c, we'll have to move the declaration of pci_find_upstream_pcie_bridge() from drivers/pci/pci.h to include/linux/pci.h, but that's probably not too bad). Thanks, Ohad. -- 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 0/6] iommu: generic api migration and grouping
Hi Kyungmin, On Fri, Jun 3, 2011 at 2:57 AM, Kyungmin Park kmp...@infradead.org wrote: Please see the RFC patch, ARM: DMA-mapping IOMMU integration http://www.spinics.net/lists/linux-mm/msg19856.html Marek's work somehow escaped me, thanks for the pointers ! Ohad. -- 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
[RFC 0/6] iommu: generic api migration and grouping
First stab at iommu consolidation:
- Migrate OMAP's iommu driver to the generic iommu API. With this in hand,
users can now start using the generic iommu layer instead of calling
omap-specific iommu API.
New code that requires functionality missing from the generic iommu api,
will add that functionality in the generic framework (e.g. adding framework
awareness to multi page sizes, supported by the underlying hardware, will
avoid the otherwise-inevitable code duplication when mapping a memory
region).
OMAP-specific api that is still exposed in the omap iommu driver can
now be either moved to the generic iommu framework, or just removed (if not
used).
This api (and other omap-specific primitives like struct iommu) needs to
be omapified (i.e. renamed to include an 'omap_' prefix). At this early
point of this patch set this is too much churn though, so I'll do that
in the following iteration, after (and if), the general direction is
accepted.
- Migrate OMAP's iovmm (virtual memory manager) driver to the generic
iommu API. With this in hand, iovmm no longer uses omap-specific api
for mapping/unmapping operations. Nevertheless, iovmm is still coupled
with omap's iommu even with this change: it assumes omap page sizes,
and it uses omap's iommu objects to maintain its internal state.
Further generalizing of iovmm strongly depends on our broader plans for
providing a generic virtual memory manager and allocation framework
(which, as discussed, should be separated from a specific mapper).
iovmm has a mainline user: omap3isp, and therefore must be maintained,
but new potential users will either have to generalize it, or come up
with a different generic framework that will replace it.
- Migrate OMAP's iommu mainline user, omap3isp, to the generic API as well
(so it doesn't break). As with iovmm, omap3isp still depends on
omap's iommu, mainly because iovmm depends on it, but also for
iommu context saving and restoring.
It is definitely desirable to completely remove omap3isp's dependency
on the omap-specific iommu layer, and that will be possible as the
required functionality will be added to generic framework.
- Create a dedicated iommu drivers folder (and put the base iommu code there)
- Move OMAP's and MSM's iommu drivers to that drivers iommu folder
Putting all iommu drivers together will ease finding similarities
between different platforms, with the intention of solving problems once,
in a generic framework which everyone can use.
I've only moved the omap and msm implementations for now, to demonstrate
the idea (and support the ARM diet :), but if this is found desirable,
we can bring in intel-iommu.c and amd_iommu.c as well.
Meta:
- This patch set is not bisectable; it was splitted (and ordered) this way
to ease its review. Later iterations of this patch set will fix that
(most likely by squashing the first three patches)
- Based on and tested with 3.0-rc1
- OMAP's iommu code was tested on both OMAP3 and OMAP4
- omap3isp code was tested with a sensor-less OMAP3 (memory-to-memory only)
(thanks Laurent Pinchart for showing me the magic needed to test omap3isp :)
- MSM code was only compile tested
Ohad Ben-Cohen (6):
omap: iommu: generic iommu api migration
omap: iovmm: generic iommu api migration
media: omap3isp: generic iommu api migration
drivers: iommu: move to a dedicated folder
omap: iommu/iovmm: move to dedicated iommu folder
msm: iommu: move to dedicated iommu drivers folder
arch/arm/mach-msm/Kconfig | 15 -
arch/arm/mach-msm/Makefile |2 +-
arch/arm/plat-omap/Kconfig | 12 -
arch/arm/plat-omap/Makefile|2 -
arch/arm/plat-omap/include/plat/iommu.h|3 +-
arch/arm/plat-omap/{ = include/plat}/iopgtable.h | 18 ++
arch/arm/plat-omap/include/plat/iovmm.h| 27 +-
arch/x86/Kconfig |5 +-
drivers/Kconfig|2 +
drivers/Makefile |1 +
drivers/base/Makefile |1 -
drivers/iommu/Kconfig | 32 +++
drivers/iommu/Makefile |5 +
drivers/{base = iommu}/iommu.c|0
.../mach-msm/iommu.c = drivers/iommu/msm-iommu.c |0
.../iommu/omap-iommu-debug.c |2 +-
.../iommu.c = drivers/iommu/omap-iommu.c | 290 +---
.../iovmm.c = drivers/iommu/omap-iovmm.c | 113 +---
drivers/media/video/Kconfig|2 +-
drivers/media/video/omap3isp/isp.c | 41 +++-
drivers/media/video/omap3isp/isp.h |3 +
drivers/media/video/omap3isp/ispccdc.c | 16 +-
drivers/media/video/omap3isp/ispstat.c |6 +-
drivers/media
[RFC 1/6] omap: iommu: generic iommu api migration
Migrate OMAP's iommu to the generic iommu api, so users can stay
generic, and non-omap-specific code can be removed and eventually
consolidated into a generic framework.
Tested on both OMAP3 and OMAP4.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/Kconfig |7 +-
arch/arm/plat-omap/include/plat/iommu.h |3 +-
arch/arm/plat-omap/iommu.c | 288 +++
arch/arm/plat-omap/iopgtable.h | 18 ++
4 files changed, 278 insertions(+), 38 deletions(-)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 49a4c75..1c3acb5 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -131,8 +131,13 @@ config OMAP_MBOX_KFIFO_SIZE
This can also be changed at runtime (via the mbox_kfifo_size
module parameter).
+config IOMMU_API
+ bool
+
+#can't be tristate; iommu api doesn't support un-registration
config OMAP_IOMMU
- tristate
+ bool
+ select IOMMU_API
config OMAP_IOMMU_DEBUG
tristate Export OMAP IOMMU internals in DebugFS
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 174f1b9..db1c492 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -167,8 +167,6 @@ extern void iopgtable_lookup_entry(struct iommu *obj, u32
da, u32 **ppgd,
extern size_t iopgtable_clear_entry(struct iommu *obj, u32 iova);
extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end);
-extern struct iommu *iommu_get(const char *name);
-extern void iommu_put(struct iommu *obj);
extern int iommu_set_isr(const char *name,
int (*isr)(struct iommu *obj, u32 da, u32 iommu_errs,
void *priv),
@@ -185,5 +183,6 @@ extern int foreach_iommu_device(void *data,
extern ssize_t iommu_dump_ctx(struct iommu *obj, char *buf, ssize_t len);
extern size_t dump_tlb_entries(struct iommu *obj, char *buf, ssize_t len);
+struct device *omap_find_iommu_device(const char *name);
#endif /* __MACH_IOMMU_H */
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 34fc31e..f06e99c 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -18,6 +18,8 @@
#include linux/ioport.h
#include linux/clk.h
#include linux/platform_device.h
+#include linux/iommu.h
+#include linux/mutex.h
#include asm/cacheflush.h
@@ -30,6 +32,19 @@
(__i (n)) (cr = __iotlb_read_cr((obj), __i), true); \
__i++)
+/**
+ * struct omap_iommu_domain - omap iommu domain
+ * @pgtable: the page table
+ * @iommu_dev: an omap iommu device attached to this domain. only a single
+ * iommu device can be attached for now.
+ * @lock: domain lock, should be taken when attaching/detaching
+ */
+struct omap_iommu_domain {
+ u32 *pgtable;
+ struct iommu *iommu_dev;
+ struct mutex lock;
+};
+
/* accommodate the difference between omap1 and omap2/3 */
static const struct iommu_functions *arch_iommu;
@@ -852,31 +867,50 @@ int iommu_set_da_range(struct iommu *obj, u32 start, u32
end)
EXPORT_SYMBOL_GPL(iommu_set_da_range);
/**
- * iommu_get - Get iommu handler
- * @name: target iommu name
+ * omap_find_iommu_device() - find an omap iommu device by name
+ * @name: name of the iommu device
+ *
+ * The generic iommu API requires the caller to provide the device
+ * he wishes to attach to a certain iommu domain. Users of that API
+ * may look up the device using PCI credentials when relevent, and when
+ * not, this helper should be used to find a specific iommu device by name.
+ *
+ * This may be relevant to other platforms as well (msm ?) so consider
+ * moving this to the generic iommu framework.
+ */
+struct device *omap_find_iommu_device(const char *name)
+{
+ return driver_find_device(omap_iommu_driver.driver, NULL,
+ (void *)name,
+ device_match_by_alias);
+}
+EXPORT_SYMBOL_GPL(omap_find_iommu_device);
+
+/**
+ * omap_iommu_attach() - attach iommu device to an iommu domain
+ * @dev: target omap iommu device
+ * @iopgd: page table
**/
-struct iommu *iommu_get(const char *name)
+static struct iommu *omap_iommu_attach(struct device *dev, u32 *iopgd)
{
int err = -ENOMEM;
- struct device *dev;
- struct iommu *obj;
-
- dev = driver_find_device(omap_iommu_driver.driver, NULL, (void *)name,
-device_match_by_alias);
- if (!dev)
- return ERR_PTR(-ENODEV);
-
- obj = to_iommu(dev);
+ struct iommu *obj = to_iommu(dev);
mutex_lock(obj-iommu_lock);
- if (obj-refcount++ == 0) {
- err = iommu_enable(obj);
- if (err)
- goto err_enable;
- flush_iotlb_all(obj);
+ /* an iommu device can only be attached once
[RFC 4/6] drivers: iommu: move to a dedicated folder
Create a dedicated folder for iommu drivers, and move the base
iommu implementation over there.
Grouping the varius iommu drivers in a single location will help
finding similar problems shared by different platforms, so they
could be solved once, in the iommu framework, instead of solved
differently (or duplicated) in each driver.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-msm/Kconfig |3 ---
arch/arm/plat-omap/Kconfig |3 ---
arch/x86/Kconfig|5 ++---
drivers/Kconfig |2 ++
drivers/Makefile|1 +
drivers/base/Makefile |1 -
drivers/iommu/Kconfig |3 +++
drivers/iommu/Makefile |1 +
drivers/{base = iommu}/iommu.c |0
9 files changed, 9 insertions(+), 10 deletions(-)
create mode 100644 drivers/iommu/Kconfig
create mode 100644 drivers/iommu/Makefile
rename drivers/{base = iommu}/iommu.c (100%)
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 1516896..efb7b7d 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -205,9 +205,6 @@ config MSM_GPIOMUX
config MSM_V2_TLMM
bool
-config IOMMU_API
- bool
-
config MSM_SCM
bool
endif
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 1c3acb5..1bb1981 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -131,9 +131,6 @@ config OMAP_MBOX_KFIFO_SIZE
This can also be changed at runtime (via the mbox_kfifo_size
module parameter).
-config IOMMU_API
- bool
-
#can't be tristate; iommu api doesn't support un-registration
config OMAP_IOMMU
bool
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index da34972..460d573 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -685,6 +685,7 @@ config AMD_IOMMU
select SWIOTLB
select PCI_MSI
select PCI_IOV
+ select IOMMU_API
depends on X86_64 PCI ACPI
---help---
With this option you can enable support for AMD IOMMU hardware in
@@ -720,9 +721,6 @@ config SWIOTLB
config IOMMU_HELPER
def_bool (CALGARY_IOMMU || GART_IOMMU || SWIOTLB || AMD_IOMMU)
-config IOMMU_API
- def_bool (AMD_IOMMU || DMAR)
-
config MAXSMP
bool Enable Maximum number of SMP Processors and NUMA Nodes
depends on X86_64 SMP DEBUG_KERNEL EXPERIMENTAL
@@ -1945,6 +1943,7 @@ config PCI_CNB20LE_QUIRK
config DMAR
bool Support for DMA Remapping Devices (EXPERIMENTAL)
depends on PCI_MSI ACPI EXPERIMENTAL
+ select IOMMU_API
help
DMA remapping (DMAR) devices support enables independent address
translations for Direct Memory Access (DMA) from devices.
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 3bb154d..9d51318 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -126,4 +126,6 @@ source drivers/hwspinlock/Kconfig
source drivers/clocksource/Kconfig
+source drivers/iommu/Kconfig
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 09f3232..2f7a71a 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -122,3 +122,4 @@ obj-y += ieee802154/
obj-y += clk/
obj-$(CONFIG_HWSPINLOCK) += hwspinlock/
+obj-$(CONFIG_IOMMU_API)+= iommu/
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 4c5701c..5ab0d07 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -13,7 +13,6 @@ obj-$(CONFIG_FW_LOADER) += firmware_class.o
obj-$(CONFIG_NUMA) += node.o
obj-$(CONFIG_MEMORY_HOTPLUG_SPARSE) += memory.o
obj-$(CONFIG_SMP) += topology.o
-obj-$(CONFIG_IOMMU_API) += iommu.o
ifeq ($(CONFIG_SYSFS),y)
obj-$(CONFIG_MODULES) += module.o
endif
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
new file mode 100644
index 000..2c5dfb4
--- /dev/null
+++ b/drivers/iommu/Kconfig
@@ -0,0 +1,3 @@
+# IOMMU_API always gets selected by whoever wants it.
+config IOMMU_API
+ bool
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
new file mode 100644
index 000..241ba4c
--- /dev/null
+++ b/drivers/iommu/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_IOMMU_API) += iommu.o
diff --git a/drivers/base/iommu.c b/drivers/iommu/iommu.c
similarity index 100%
rename from drivers/base/iommu.c
rename to drivers/iommu/iommu.c
--
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
[RFC 6/6] msm: iommu: move to dedicated iommu drivers folder
This should ease finding similarities with other platforms, with the intention of solving problems once in a generic framework which everyone can use. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- arch/arm/mach-msm/Kconfig | 12 arch/arm/mach-msm/Makefile |2 +- drivers/iommu/Kconfig | 11 +++ drivers/iommu/Makefile |1 + .../mach-msm/iommu.c = drivers/iommu/msm-iommu.c |0 5 files changed, 13 insertions(+), 13 deletions(-) rename arch/arm/mach-msm/iommu.c = drivers/iommu/msm-iommu.c (100%) diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig index efb7b7d..14ebda1 100644 --- a/arch/arm/mach-msm/Kconfig +++ b/arch/arm/mach-msm/Kconfig @@ -148,18 +148,6 @@ config MACH_MSM8960_RUMI3 endmenu -config MSM_IOMMU - bool MSM IOMMU Support - depends on ARCH_MSM8X60 || ARCH_MSM8960 - select IOMMU_API - default n - help - Support for the IOMMUs found on certain Qualcomm SOCs. - These IOMMUs allow virtualization of the address space used by most - cores within the multimedia subsystem. - - If unsure, say N here. - config IOMMU_PGTABLES_L2 def_bool y depends on MSM_IOMMU MMU SMP CPU_DCACHE_DISABLE=n diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile index 9519fd2..0bf4648 100644 --- a/arch/arm/mach-msm/Makefile +++ b/arch/arm/mach-msm/Makefile @@ -3,7 +3,7 @@ obj-y += clock.o obj-$(CONFIG_DEBUG_FS) += clock-debug.o obj-$(CONFIG_MSM_VIC) += irq-vic.o -obj-$(CONFIG_MSM_IOMMU) += iommu.o iommu_dev.o devices-iommu.o +obj-$(CONFIG_MSM_IOMMU) += iommu_dev.o devices-iommu.o obj-$(CONFIG_ARCH_MSM7X00A) += dma.o irq.o acpuclock-arm11.o obj-$(CONFIG_ARCH_MSM7X30) += dma.o diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 57378ac..e083ff0 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -19,3 +19,14 @@ config OMAP_IOMMU_DEBUG the internal state of OMAP IOMMU in debugfs. Say N unless you know you need this. + +config MSM_IOMMU + bool MSM IOMMU Support + depends on ARCH_MSM8X60 || ARCH_MSM8960 + select IOMMU_API + help + Support for the IOMMUs found on certain Qualcomm SOCs. + These IOMMUs allow virtualization of the address space used by most + cores within the multimedia subsystem. + + If unsure, say N here. diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile index c094875..bfb000a 100644 --- a/drivers/iommu/Makefile +++ b/drivers/iommu/Makefile @@ -2,3 +2,4 @@ obj-$(CONFIG_IOMMU_API) += iommu.o obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o +obj-$(CONFIG_MSM_IOMMU) += msm-iommu.o diff --git a/arch/arm/mach-msm/iommu.c b/drivers/iommu/msm-iommu.c similarity index 100% rename from arch/arm/mach-msm/iommu.c rename to drivers/iommu/msm-iommu.c -- 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
[RFC 5/6] omap: iommu/iovmm: move to dedicated iommu folder
Move OMAP's iommu drivers to the dedicated iommu drivers folder.
While OMAP's iovmm (virtual memory manager) driver does not strictly
belong to the iommu drivers folder, move it there as well, because
it's by no means OMAP-specific (in concept. technically it is still
coupled with the omap iommu), and exposing it will ease its generalization,
consolidation, or removal (once a generic virtual memory manager and allocator
would materialize).
Move omap's iommu debug driver to the generic folder as well, for the
same reasons.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/Kconfig | 14 --
arch/arm/plat-omap/Makefile|2 --
arch/arm/plat-omap/{ = include/plat}/iopgtable.h |0
drivers/iommu/Kconfig | 18 ++
drivers/iommu/Makefile |3 +++
.../iommu/omap-iommu-debug.c |2 +-
.../iommu.c = drivers/iommu/omap-iommu.c |2 +-
.../iovmm.c = drivers/iommu/omap-iovmm.c |2 +-
drivers/media/video/Kconfig|2 +-
9 files changed, 25 insertions(+), 20 deletions(-)
rename arch/arm/plat-omap/{ = include/plat}/iopgtable.h (100%)
rename arch/arm/plat-omap/iommu-debug.c = drivers/iommu/omap-iommu-debug.c
(99%)
rename arch/arm/plat-omap/iommu.c = drivers/iommu/omap-iommu.c (99%)
rename arch/arm/plat-omap/iovmm.c = drivers/iommu/omap-iovmm.c (99%)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 1bb1981..14f067f 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -131,20 +131,6 @@ config OMAP_MBOX_KFIFO_SIZE
This can also be changed at runtime (via the mbox_kfifo_size
module parameter).
-#can't be tristate; iommu api doesn't support un-registration
-config OMAP_IOMMU
- bool
- select IOMMU_API
-
-config OMAP_IOMMU_DEBUG
- tristate Export OMAP IOMMU internals in DebugFS
- depends on OMAP_IOMMU DEBUG_FS
- help
- Select this to see extensive information about
- the internal state of OMAP IOMMU in debugfs.
-
- Say N unless you know you need this.
-
config OMAP_IOMMU_IVA2
bool
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index f0233e6..9852622 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -18,8 +18,6 @@ obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
obj-$(CONFIG_ARCH_OMAP4) += omap_device.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
-obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o
-obj-$(CONFIG_OMAP_IOMMU_DEBUG) += iommu-debug.o
obj-$(CONFIG_CPU_FREQ) += cpu-omap.o
obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
diff --git a/arch/arm/plat-omap/iopgtable.h
b/arch/arm/plat-omap/include/plat/iopgtable.h
similarity index 100%
rename from arch/arm/plat-omap/iopgtable.h
rename to arch/arm/plat-omap/include/plat/iopgtable.h
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 2c5dfb4..57378ac 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -1,3 +1,21 @@
# IOMMU_API always gets selected by whoever wants it.
config IOMMU_API
bool
+
+# can't be tristate; iommu api doesn't support un-registration
+config OMAP_IOMMU
+ bool
+ select IOMMU_API
+
+config OMAP_IOVMM
+ tristate
+ select OMAP_IOMMU
+
+config OMAP_IOMMU_DEBUG
+ tristate Export OMAP IOMMU internals in DebugFS
+ depends on OMAP_IOVMM DEBUG_FS
+ help
+ Select this to see extensive information about
+ the internal state of OMAP IOMMU in debugfs.
+
+ Say N unless you know you need this.
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 241ba4c..c094875 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -1 +1,4 @@
obj-$(CONFIG_IOMMU_API) += iommu.o
+obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
+obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o
+obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
diff --git a/arch/arm/plat-omap/iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
similarity index 99%
rename from arch/arm/plat-omap/iommu-debug.c
rename to drivers/iommu/omap-iommu-debug.c
index f07cf2f..0f8c8dd 100644
--- a/arch/arm/plat-omap/iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -21,7 +21,7 @@
#include plat/iommu.h
#include plat/iovmm.h
-#include iopgtable.h
+#include plat/iopgtable.h
#define MAXCOLUMN 100 /* for short messages */
diff --git a/arch/arm/plat-omap/iommu.c b/drivers/iommu/omap-iommu.c
similarity index 99%
rename from arch/arm/plat-omap/iommu.c
rename to drivers/iommu/omap-iommu.c
index f06e99c..1526fea 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -25,7 +25,7 @@
#include plat/iommu.h
-#include iopgtable.h
+#include plat/iopgtable.h
#define for_each_iotlb_cr(obj, n, __i, cr) \
for (__i = 0
[RFC 3/6] media: omap3isp: generic iommu api migration
First step towards migrating omap3isp to the generic iommu api.
At this point we still need a handle of the omap-specific iommu, mainly
because we highly depend on omap's iovmm.
Migration will be fully completed only once omap's iovmm will be generalized
(or replaced by a generic virtual memory manager framework).
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/media/video/omap3isp/isp.c | 41 +-
drivers/media/video/omap3isp/isp.h |3 ++
drivers/media/video/omap3isp/ispccdc.c | 16 ++--
drivers/media/video/omap3isp/ispstat.c |6 ++--
drivers/media/video/omap3isp/ispvideo.c |4 +-
5 files changed, 50 insertions(+), 20 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 897a1cf..25bade9 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -80,6 +80,13 @@
#include isph3a.h
#include isphist.h
+/*
+ * this is provided as an interim solution until omap3isp doesn't need
+ * any omap-specific iommu API
+ */
+#define to_iommu(dev) \
+ (struct iommu *)platform_get_drvdata(to_platform_device(dev))
+
static unsigned int autoidle;
module_param(autoidle, int, 0444);
MODULE_PARM_DESC(autoidle, Enable OMAP3ISP AUTOIDLE support);
@@ -1975,7 +1982,8 @@ static int isp_remove(struct platform_device *pdev)
isp_cleanup_modules(isp);
omap3isp_get(isp);
- iommu_put(isp-iommu);
+ iommu_detach_device(isp-domain, isp-iommu_dev);
+ iommu_domain_free(isp-domain);
omap3isp_put(isp);
free_irq(isp-irq_num, isp);
@@ -2123,25 +2131,41 @@ static int isp_probe(struct platform_device *pdev)
}
/* IOMMU */
- isp-iommu = iommu_get(isp);
- if (IS_ERR_OR_NULL(isp-iommu)) {
- isp-iommu = NULL;
+ isp-iommu_dev = omap_find_iommu_device(isp);
+ if (!isp-iommu_dev) {
+ dev_err(isp-dev, omap_find_iommu_device failed\n);
ret = -ENODEV;
goto error_isp;
}
+ /* to be removed once iommu migration is complete */
+ isp-iommu = to_iommu(isp-iommu_dev);
+
+ isp-domain = iommu_domain_alloc();
+ if (!isp-domain) {
+ dev_err(isp-dev, can't alloc iommu domain\n);
+ ret = -ENOMEM;
+ goto error_isp;
+ }
+
+ ret = iommu_attach_device(isp-domain, isp-iommu_dev);
+ if (ret) {
+ dev_err(pdev-dev, can't attach iommu device: %d\n, ret);
+ goto free_domain;
+ }
+
/* Interrupt */
isp-irq_num = platform_get_irq(pdev, 0);
if (isp-irq_num = 0) {
dev_err(isp-dev, No IRQ resource\n);
ret = -ENODEV;
- goto error_isp;
+ goto detach_dev;
}
if (request_irq(isp-irq_num, isp_isr, IRQF_SHARED, OMAP3 ISP, isp)) {
dev_err(isp-dev, Unable to request IRQ\n);
ret = -EINVAL;
- goto error_isp;
+ goto detach_dev;
}
/* Entities */
@@ -2162,8 +2186,11 @@ error_modules:
isp_cleanup_modules(isp);
error_irq:
free_irq(isp-irq_num, isp);
+detach_dev:
+ iommu_detach_device(isp-domain, isp-iommu_dev);
+free_domain:
+ iommu_domain_free(isp-domain);
error_isp:
- iommu_put(isp-iommu);
omap3isp_put(isp);
error:
isp_put_clocks(isp);
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h
index 2620c40..1b54aa4 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -32,6 +32,7 @@
#include linux/io.h
#include linux/platform_device.h
#include linux/wait.h
+#include linux/iommu.h
#include plat/iommu.h
#include plat/iovmm.h
@@ -289,6 +290,8 @@ struct isp_device {
unsigned int subclk_resources;
struct iommu *iommu;
+ struct iommu_domain *domain;
+ struct device *iommu_dev;
struct isp_platform_callback platform_cb;
};
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index 39d501b..b59b06f 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -365,7 +365,7 @@ static void ccdc_lsc_free_request(struct isp_ccdc_device
*ccdc,
dma_unmap_sg(isp-dev, req-iovm-sgt-sgl,
req-iovm-sgt-nents, DMA_TO_DEVICE);
if (req-table)
- iommu_vfree(isp-iommu, req-table);
+ iommu_vfree(isp-domain, isp-iommu, req-table);
kfree(req);
}
@@ -437,8 +437,8 @@ static int ccdc_lsc_config(struct isp_ccdc_device *ccdc,
req-enable = 1;
- req-table = iommu_vmalloc(isp-iommu, 0, req-config.size,
- IOMMU_FLAG);
+ req-table = iommu_vmalloc
[RFC 2/6] omap: iovmm: generic iommu api migration
Migrate omap's iovmm (virtual memory manager) to the generic iommu api.
This brings iovmm a step forward towards being completely non
omap-specific (it's still assuming omap's iommu page sizes, and also
maintaining state inside omap's internal iommu structure, but it no
longer calls omap-specific iommu map/unmap api).
Further generalizing of iovmm (or complete removal) should take place
together with broader plans of providing a generic virtual memory manager
and allocation framework (de-coupled from specific mappers).
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/include/plat/iovmm.h | 27 +---
arch/arm/plat-omap/iovmm.c | 111 ++-
2 files changed, 82 insertions(+), 56 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/iovmm.h
b/arch/arm/plat-omap/include/plat/iovmm.h
index 32a2f6c..56ee2b9 100644
--- a/arch/arm/plat-omap/include/plat/iovmm.h
+++ b/arch/arm/plat-omap/include/plat/iovmm.h
@@ -13,6 +13,8 @@
#ifndef __IOMMU_MMAP_H
#define __IOMMU_MMAP_H
+#include linux/iommu.h
+
struct iovm_struct {
struct iommu*iommu; /* iommu object which this belongs to */
u32 da_start; /* area definition */
@@ -74,18 +76,21 @@ struct iovm_struct {
extern struct iovm_struct *find_iovm_area(struct iommu *obj, u32 da);
-extern u32 iommu_vmap(struct iommu *obj, u32 da,
+extern u32 iommu_vmap(struct iommu_domain *domain, struct iommu *obj, u32 da,
const struct sg_table *sgt, u32 flags);
-extern struct sg_table *iommu_vunmap(struct iommu *obj, u32 da);
-extern u32 iommu_vmalloc(struct iommu *obj, u32 da, size_t bytes,
- u32 flags);
-extern void iommu_vfree(struct iommu *obj, const u32 da);
-extern u32 iommu_kmap(struct iommu *obj, u32 da, u32 pa, size_t bytes,
- u32 flags);
-extern void iommu_kunmap(struct iommu *obj, u32 da);
-extern u32 iommu_kmalloc(struct iommu *obj, u32 da, size_t bytes,
- u32 flags);
-extern void iommu_kfree(struct iommu *obj, u32 da);
+extern struct sg_table *iommu_vunmap(struct iommu_domain *domain,
+ struct iommu *obj, u32 da);
+extern u32 iommu_vmalloc(struct iommu_domain *domain, struct iommu *obj,
+ u32 da, size_t bytes, u32 flags);
+extern void iommu_vfree(struct iommu_domain *domain, struct iommu *obj,
+ const u32 da);
+extern u32 iommu_kmap(struct iommu_domain *domain, struct iommu *obj, u32 da,
+ u32 pa, size_t bytes, u32 flags);
+extern void iommu_kunmap(struct iommu_domain *domain, struct iommu *obj,
+ u32 da);
+extern u32 iommu_kmalloc(struct iommu_domain *domain, struct iommu *obj,
+ u32 da, size_t bytes, u32 flags);
+extern void iommu_kfree(struct iommu_domain *domain, struct iommu *obj, u32
da);
extern void *da_to_va(struct iommu *obj, u32 da);
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 51ef43e..80bb2b6 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -15,6 +15,7 @@
#include linux/vmalloc.h
#include linux/device.h
#include linux/scatterlist.h
+#include linux/iommu.h
#include asm/cacheflush.h
#include asm/mach/map.h
@@ -456,15 +457,16 @@ static inline void sgtable_drain_kmalloc(struct sg_table
*sgt)
}
/* create 'da' - 'pa' mapping from 'sgt' */
-static int map_iovm_area(struct iommu *obj, struct iovm_struct *new,
-const struct sg_table *sgt, u32 flags)
+static int map_iovm_area(struct iommu_domain *domain, struct iovm_struct *new,
+ const struct sg_table *sgt, u32 flags)
{
int err;
unsigned int i, j;
struct scatterlist *sg;
u32 da = new-da_start;
+ int order;
- if (!obj || !sgt)
+ if (!domain || !sgt)
return -EINVAL;
BUG_ON(!sgtable_ok(sgt));
@@ -473,22 +475,22 @@ static int map_iovm_area(struct iommu *obj, struct
iovm_struct *new,
u32 pa;
int pgsz;
size_t bytes;
- struct iotlb_entry e;
pa = sg_phys(sg);
bytes = sg_dma_len(sg);
flags = ~IOVMF_PGSZ_MASK;
+
pgsz = bytes_to_iopgsz(bytes);
if (pgsz 0)
goto err_out;
- flags |= pgsz;
+
+ order = get_order(bytes);
pr_debug(%s: [%d] %08x %08x(%x)\n, __func__,
i, da, pa, bytes);
- iotlb_init_entry(e, da, pa, flags);
- err = iopgtable_store_entry(obj, e);
+ err = iommu_map(domain, da, pa, order, flags);
if (err)
goto err_out;
@@ -502,9 +504,11 @@ err_out:
for_each_sg(sgt-sgl, sg, i, j) {
size_t
[PATCH] media: omap3isp: fix a pontential NULL deref
Fix a potential NULL pointer dereference by skipping registration of
external entities in case none are provided.
This is useful at least when testing mere memory-to-memory scenarios.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/media/video/omap3isp/isp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 2a5fbe6..367ced3 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -1756,7 +1756,7 @@ static int isp_register_entities(struct isp_device *isp)
goto done;
/* Register external entities */
- for (subdevs = pdata-subdevs; subdevs-subdevs; ++subdevs) {
+ for (subdevs = pdata-subdevs; subdevs subdevs-subdevs; ++subdevs) {
struct v4l2_subdev *sensor;
struct media_entity *input;
unsigned int flags;
--
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: [PATCH] media: omap3isp: fix format string warning
On Mon, May 30, 2011 at 5:57 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Thanks for the patch, but I've already applied something similar to my tree. Sorry :-) np, thanks. I'm just playing with omap3isp a bit and wanted to get rid of that hey what did I do wrong this time feeling every time I recompiled it :) -- 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: omap3isp: fix format string warning
Trivially fix this:
drivers/media/video/omap3isp/isp.c: In function 'isp_isr_dbg':
drivers/media/video/omap3isp/isp.c:394: warning: zero-length gnu_printf format
string
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/media/video/omap3isp/isp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 472a693..a0d5e69 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -391,7 +391,7 @@ static inline void isp_isr_dbg(struct isp_device *isp, u32
irqstatus)
};
int i;
- dev_dbg(isp-dev, );
+ dev_dbg(isp-dev, %s\n, __func__);
for (i = 0; i ARRAY_SIZE(name); i++) {
if ((1 i) irqstatus)
--
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: [GIT PULL] TI WL 128x FM V4L2 driver
On Thu, Jan 27, 2011 at 11:54 AM, Mark Brown broo...@opensource.wolfsonmicro.com So what happens when both drivers are in the system? It sounds like you've got two different drivers for the same hardware. There must be some redundancy there if nothing else. Not really; TI's 127x/128x devices are built of completely separate hardware cores, with completely separate and independent drivers. You can use one, a subset, or all of the cores (/drivers) together on the same time. The mainline wl12xx driver you refer to is a mac80211 SDIO/SPI WLAN driver that has nothing to do with Manjunatha's FM driver. -- 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 v6 0/9] FM V4L2 drivers for WL128x
On Fri, Dec 3, 2010 at 2:50 PM, manjunatha_ha...@ti.com wrote: ... Can you please also stage this version? Since the files are becoming big to be posted as patches? You should really CC Greg for staging requests... Thanks Regards, Manjunatha Halli Manjunatha Halli (9): include:linux: videodev2.h: FM Rx control class Documentation:DocBook:v4l: Update the controls.xml for TI FM driver drivers:staging: ti-st: fmdrv common header file drivers:staging: ti-st: fmdrv_v4l2 sources drivers:staging: ti-st: fmdrv_common sources drivers:staging: ti-st: FM driver RX sources drivers:staging: ti-st: FM driver TX sources drivers:staging: ti-st: Kconfig Makefile change driver:staging:ti-st: Update TODO for FM V4L2 driver. Documentation/DocBook/v4l/controls.xml | 12 + drivers/staging/ti-st/Kconfig | 10 + drivers/staging/ti-st/Makefile | 2 + drivers/staging/ti-st/TODO | 10 +- drivers/staging/ti-st/fmdrv.h | 239 drivers/staging/ti-st/fmdrv_common.c | 2003 drivers/staging/ti-st/fmdrv_common.h | 402 +++ drivers/staging/ti-st/fmdrv_rx.c | 902 ++ drivers/staging/ti-st/fmdrv_rx.h | 59 + drivers/staging/ti-st/fmdrv_tx.c | 420 +++ drivers/staging/ti-st/fmdrv_tx.h | 37 + drivers/staging/ti-st/fmdrv_v4l2.c | 720 drivers/staging/ti-st/fmdrv_v4l2.h | 32 + include/linux/videodev2.h | 8 + 14 files changed, 4855 insertions(+), 1 deletions(-) create mode 100644 drivers/staging/ti-st/fmdrv.h create mode 100644 drivers/staging/ti-st/fmdrv_common.c create mode 100644 drivers/staging/ti-st/fmdrv_common.h create mode 100644 drivers/staging/ti-st/fmdrv_rx.c create mode 100644 drivers/staging/ti-st/fmdrv_rx.h create mode 100644 drivers/staging/ti-st/fmdrv_tx.c create mode 100644 drivers/staging/ti-st/fmdrv_tx.h create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.c create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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 v4 0/6] FM V4L2 drivers for WL128x
Hi Pavan, On Wed, Nov 17, 2010 at 6:32 PM, Ohad Ben-Cohen o...@wizery.com wrote: drivers/staging/ti-st/Kconfig | 10 + drivers/staging/ti-st/Makefile | 2 + drivers/staging/ti-st/fmdrv.h | 259 drivers/staging/ti-st/fmdrv_common.c | 2141 ++ drivers/staging/ti-st/fmdrv_common.h | 458 drivers/staging/ti-st/fmdrv_rx.c | 979 drivers/staging/ti-st/fmdrv_rx.h | 59 + drivers/staging/ti-st/fmdrv_tx.c | 461 drivers/staging/ti-st/fmdrv_tx.h | 37 + drivers/staging/ti-st/fmdrv_v4l2.c | 757 drivers/staging/ti-st/fmdrv_v4l2.h | 32 + 11 files changed, 5195 insertions(+), 0 deletions(-) Usually when a driver is added to staging, it should also have a TODO file specifying what needs to be done before the driver can be taken out of staging (at least as far as the author knows of today). It helps keeping track of the open issues in the driver, which is good for everyone - the author, the random contributor/observer, and probably even the staging maintainer. Can you please add such a TODO file ? ... Thanks Ohad, for the comments, We do have an internal TODO. In terms of functionality we have stuff like TX RDS which already has few CIDs in the extended controls. extend V4L2 for complete-scan, add in stop search during hw_seek .. etc... You need to understand and list the reasons why this driver cannot go directly to mainline; missing functionality is usually not the culprit. But I just wanted to ask whether this is good enough to be staged. Because as we begin to implement and add in the items in TODO - the patch set will keep continuing to grow. So Hans, Mauro, What do you think ? It would be real helpful - if this can be staged, it is becoming difficult to maintain for us. Greg has mentioned that staging acceptance rules are: 1. Code compiles 2. Is self sustained (does not touch code out of staging) 3. Has a clear roadmap out of staging (that TODO file) 4. Is maintained But I really think you should always prefer to upstream your code directly to mainline. Submit the code, have it reviewed by the relevant maintainers and upstream developers, and fix it appropriately until it is accepted. Only if you feel (/know) it would take substantial cleanup/redesign efforts until it is accepted upstream, then staging is indeed the way to go. But then you should know what gates it from upstream merger, and focus on that (rather than on adding functionality) until it is taken out of staging. IMHO adding functionality will just make it harder for you to take it out of staging eventually. Usually the opposite road is taken: first get a minimal driver accepted upstream, and then gradually add the missing functionality. Good luck, Ohad. -- 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 v4 0/6] FM V4L2 drivers for WL128x
Hi Manjunatha, On Tue, Nov 16, 2010 at 3:18 PM, manjunatha_ha...@ti.com wrote: drivers/staging/ti-st/Kconfig | 10 + drivers/staging/ti-st/Makefile | 2 + drivers/staging/ti-st/fmdrv.h | 259 drivers/staging/ti-st/fmdrv_common.c | 2141 ++ drivers/staging/ti-st/fmdrv_common.h | 458 drivers/staging/ti-st/fmdrv_rx.c | 979 drivers/staging/ti-st/fmdrv_rx.h | 59 + drivers/staging/ti-st/fmdrv_tx.c | 461 drivers/staging/ti-st/fmdrv_tx.h | 37 + drivers/staging/ti-st/fmdrv_v4l2.c | 757 drivers/staging/ti-st/fmdrv_v4l2.h | 32 + 11 files changed, 5195 insertions(+), 0 deletions(-) Usually when a driver is added to staging, it should also have a TODO file specifying what needs to be done before the driver can be taken out of staging (at least as far as the author knows of today). It helps keeping track of the open issues in the driver, which is good for everyone - the author, the random contributor/observer, and probably even the staging maintainer. Can you please add such a TODO file ? Thanks, Ohad. create mode 100644 drivers/staging/ti-st/fmdrv.h create mode 100644 drivers/staging/ti-st/fmdrv_common.c create mode 100644 drivers/staging/ti-st/fmdrv_common.h create mode 100644 drivers/staging/ti-st/fmdrv_rx.c create mode 100644 drivers/staging/ti-st/fmdrv_rx.h create mode 100644 drivers/staging/ti-st/fmdrv_tx.c create mode 100644 drivers/staging/ti-st/fmdrv_tx.h create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.c create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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
