[RFC 1/8] TILER-DMM: DMM-PAT driver for TI TILER

[Laurent Pinchart]

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