Hi Laurent,
On Fri, Oct 26, 2012 at 11:35 AM, Laurent Pinchart
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
On Thu, Oct 25, 2012 at 11:39 PM, Tony Lindgren 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 id
Hi Marek,
On Mon, Jan 30, 2012 at 9:43 AM, Marek Szyprowski
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.
Hi Marek,
On Fri, Jan 27, 2012 at 5:17 PM, Marek Szyprowski
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 capp
2012/1/27 Marek Szyprowski :
> 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/
2012/1/27 Marek Szyprowski :
> 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 chan
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
wrote:
> +static int cma_activate_area(unsigned long base_pfn, unsigned long count)
> +{
> + unsigned long pfn = base_pfn;
>
On Sun, Dec 18, 2011 at 11:47 PM, Laurent Pinchart
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 major
On Wed, Nov 23, 2011 at 3:53 AM, Laurent Pinchart
wrote:
> On Sunday 20 November 2011 17:54:26 Dmitry Artamonow wrote:
>> Fix following build error by explicitely including
>> header file.
>>
>> CC drivers/media/video/omap3isp/ispvideo.o
>> drivers/media/video/omap3isp/ispvideo.c:1267: err
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
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
(small and optional comment: I think it'd be nice if
dma_declare_contiguous would fail if called too late, otherwise users
of that miscon
On Wed, Jun 8, 2011 at 1:46 PM, Laurent Pinchart
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-o
Hi Laurent,
On Tue, Jun 7, 2011 at 2:26 PM, Laurent Pinchart
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.
On Tue, Jun 7, 2011 at 2:40 PM, Laurent Pinchart
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.
Hi Laurent,
On Tue, Jun 7, 2011 at 12:22 PM, Laurent Pinchart
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 unne
On Tue, Jun 7, 2011 at 12:58 PM, Roedel, Joerg 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!
--
Hi Laurent,
On Tue, Jun 7, 2011 at 12:05 PM, Laurent Pinchart
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 h
On Tue, Jun 7, 2011 at 10:52 AM, Roedel, Joerg 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 re
On Mon, Jun 6, 2011 at 10:20 PM, Roedel, Joerg 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
On Mon, Jun 6, 2011 at 6:35 PM, Roedel, Joerg wrote:
> On Mon, Jun 06, 2011 at 11:15:30AM -0400, Ohad Ben-Cohen wrote:
>
>> This is insufficient; users need somehow to tell what page sizes are
>> supported by the underlying hardware (we can't assume host page-sizes,
>&
On Mon, Jun 6, 2011 at 12:10 PM, Arnd Bergmann 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
Hi Joerg,
On Mon, Jun 6, 2011 at 1:09 PM, Roedel, Joerg 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
Hi Kyungmin,
On Fri, Jun 3, 2011 at 2:57 AM, Kyungmin Park 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 li
Hi Arnd,
On Fri, Jun 3, 2011 at 6:53 PM, Arnd Bergmann 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
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
---
arch/arm/pl
ual memory manager framework).
Signed-off-by: Ohad Ben-Cohen
---
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
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
---
arch/a
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
---
arch/arm/mach-msm/Kconfig | 12
arch/arm/mach-msm/Makefile
differently (or duplicated) in each driver.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-msm/Kconfig |3 ---
arch/arm/plat-omap/Kconfig |3 ---
arch/x86/Kconfig|5 ++---
drivers/Kconfig |2 ++
drivers/Makefile|1 +
drivers
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
---
arch/arm/plat-omap/Kconfig |7 +-
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 wa
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
---
drivers/media/video/omap3isp/isp.c |2 +-
1 files changed, 1 insertions
On Mon, May 30, 2011 at 5:57 PM, Laurent Pinchart
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
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
---
drivers/media/video/omap3isp/isp.c |2 +-
1 files changed, 1 insert
On Thu, Jan 27, 2011 at 11:54 AM, Mark Brown
> 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
On Fri, Dec 3, 2010 at 2:50 PM, 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
Hi Pavan,
> On Wed, Nov 17, 2010 at 6:32 PM, Ohad Ben-Cohen wrote:
>>> drivers/staging/ti-st/Kconfig | 10 +
>>> drivers/staging/ti-st/Makefile | 2 +
>>> drivers/staging/ti-st/fmdrv.h | 259
>>> driv
Hi Manjunatha,
On Tue, Nov 16, 2010 at 3:18 PM, 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
> ++
> dri
38 matches
Mail list logo
