> -----Original Message----- > From: Laurent Pinchart [mailto:laurent.pinchart@xxxxxxxxxxxxxxxx] > Sent: Wednesday, July 28, 2010 5:00 AM > To: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > Cc: Hiremath, Vaibhav; Sin, David; > linux-omap@xxxxxxxxxxxxxxx; Tony Lindgren; Russell King; Ohad > Ben-Cohen; Kanigeri, Hari; Shilimkar, Santosh; Molnar, Lajos > Subject: Re: [RFC 1/8] TILER-DMM: DMM-PAT driver for TI TILER > > > On Tuesday 27 July 2010 21:53:28 Hiremath, Vaibhav wrote: > > On Wednesday 28 July 2010 00:35:00 Sin, David wrote: > > > On Tuesday 27 July 2010 01:38:00 Hiremath, Vaibhav wrote: > > > > On Saturday 24 July 2010 04:52:00 Sin, David wrote: > > [snip] > > > > > [Hiremath, Vaibhav] If I understand correctly, DMM stands for > > > > dynamic memory manager. Is it something which can only be > > > > used with Video devices? Any specific reason why this is part > > > > of drivers/media/video/ directory, > > > > > > [dhs] Any device can use TILER memory, but there is a big > advantage, > > > performance-wise, for 2-Dimensional macro block based > buffers. This HW > > > is intended for image/video hardware accelerators (e.g. > OMAP4 IVA-HD). > > > Plus there's the added advantage of doing zero-copy flips > and rotations > > > for the OMAP display and image sub-systems. > > > > [Hiremath, Vaibhav] When you mention Tiler memory, you > meant Tiler Virtual > > memory which is independent of physical memory. Driver > requesting/using > > Tiler is responsible for allocating physical memory. Is > that understanding > > correct? [dhs] Yes this is correct. I'm referring to the 33 bit 4 GB TILER virtual memory. > > > > If yes, then feature wise it is same as VRFB in OMAP3, > where it provides > > virtual address space and driver requesting VRFB is responsible for > > physical memory allocation. There could be additional features, > > enhancement and stuff but zero-copy rotation for DSS, then > its same as > > VRFB. > > > > Don't you think is would be very difficult to use for > drivers with such > > proposals, I can comment from DSS point of view, > > > > In case of OMAP4 80% of code is being re-used from OMAP3 > (located under > > drivers/video/omap2/), which is currently supported hardware > > rotation/mirroring and hardly tied to VRFB API's. > > > > Now with this driver we have to do something, > > > > cpu_is_omap34xx() > > VRFB > > else if cpu_is_omap44xx() > > Tiler > > > > I am not sure about further OMAP series of devices, where > we might have > > something else with DSS IP reuse (along with software). And > I believe > > Tiler is not part of DSS at all. Again if some other > devices are using > > Tiler API's it would become more difficult to re-use the > code when same IP > > is being used in multiple SoC's. > > > > Does it make sense to you to have registration based > mechanism (function > > pointer) where you register your hardware > capabilities/API's, driver don't > > have to dependent on underneath hardware block. Ofcource if > driver intend > > to use some specific/custom feature supported by some > hardware block then > > he has to call that API under cpu_is_xxxx > > I think I agree with it. The tiler provides dynamic views on > arbitrary > physical memory. Ideally it shouldn't be tied to the > media/video subsystem > (obviously it should still provide an interface for V4L drivers). > > It's getting a bit hard to comment on the proposal, as > there's no public > documentation I'm aware of beside the Documentation/arm/TILER > file in the > patch set, and that information is far too concise and vague. > > -- > Regards, > > Laurent Pinchart > [dhs] I understand what you're stating here, conceptually, but I'm missing some details. Do you mean that there needs to be a generic layer between a given video memory allocator and V4L? and that set of APIs should point to specific functions based on availability (e.g. VRFB, TILER, future TILER, other IP, etc)? Laurent: The TRM for DMM-TILER should be publicly available already, but for some reason, I'm not able to see the link. I will work on this... -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
