omapdrm VRFB rotation

omapdrm VRFB rotation

[Ivaylo Dimitrov]

Hi,

Currently omapdrm supports TILER rotation only, which excludes omap3 and 
earlier SoCs. I have the hardware (N900/N950), time and will to 
implement VRFB rotation support in omapdrm driver, however, I'll 
appreciate some hints. Or, if there is already something ready, please 
point me to it so I can take it from where it is.

Besides partially reverting 517a8a9564c0dea98e6d4e2c7f0fe4cbb9b8c9ba and 
copying VRFB code from omapfb, is there anything else I shall take in 
consideration? Or, VRFB driver should not be a part of omapdrm, but a 
standalone one?

Regards,
Ivo

Re: omapdrm VRFB rotation

[Ivaylo Dimitrov]

Sorry, mail was sent to the old Tomi's address.

On 8.11.21 г. 19:05 ч., Ivaylo Dimitrov wrote:
> Hi,
> 
> Currently omapdrm supports TILER rotation only, which excludes omap3 and 
> earlier SoCs. I have the hardware (N900/N950), time and will to 
> implement VRFB rotation support in omapdrm driver, however, I'll 
> appreciate some hints. Or, if there is already something ready, please 
> point me to it so I can take it from where it is.
> 
> Besides partially reverting 517a8a9564c0dea98e6d4e2c7f0fe4cbb9b8c9ba and 
> copying VRFB code from omapfb, is there anything else I shall take in 
> consideration? Or, VRFB driver should not be a part of omapdrm, but a 
> standalone one?
> 
> Regards,
> Ivo

Re: omapdrm VRFB rotation

[Tomi Valkeinen]

Hi,

On 08/11/2021 19:43, Ivaylo Dimitrov wrote:
> Sorry, mail was sent to the old Tomi's address.
> 
> On 8.11.21 г. 19:05 ч., Ivaylo Dimitrov wrote:
>> Hi,
>>
>> Currently omapdrm supports TILER rotation only, which excludes omap3 
>> and earlier SoCs. I have the hardware (N900/N950), time and will to 
>> implement VRFB rotation support in omapdrm driver, however, I'll 
>> appreciate some hints. Or, if there is already something ready, please 
>> point me to it so I can take it from where it is.
>>
>> Besides partially reverting 517a8a9564c0dea98e6d4e2c7f0fe4cbb9b8c9ba 
>> and copying VRFB code from omapfb, is there anything else I shall take 
>> in consideration? Or, VRFB driver should not be a part of omapdrm, but 
>> a standalone one?

We already have DMM driver in the omapdrm module, and I think VRFB fits 
along just fine. I don't think there ever has been any other users for 
VRFB than DSS, and as it's such an old IP, I don't think there ever will.

I don't have any particular hints in mind.

Do you have omap4/5 so you can test that DMM still works after your changes?

  Tomi

Re: omapdrm VRFB rotation

[Ivaylo Dimitrov]

Hi,

On 9.11.21 г. 11:22 ч., Tomi Valkeinen wrote:
> Hi,
> 
> On 08/11/2021 19:43, Ivaylo Dimitrov wrote:
>> Sorry, mail was sent to the old Tomi's address.
>>
>> On 8.11.21 г. 19:05 ч., Ivaylo Dimitrov wrote:
>>> Hi,
>>>
>>> Currently omapdrm supports TILER rotation only, which excludes omap3 
>>> and earlier SoCs. I have the hardware (N900/N950), time and will to 
>>> implement VRFB rotation support in omapdrm driver, however, I'll 
>>> appreciate some hints. Or, if there is already something ready, 
>>> please point me to it so I can take it from where it is.
>>>
>>> Besides partially reverting 517a8a9564c0dea98e6d4e2c7f0fe4cbb9b8c9ba 
>>> and copying VRFB code from omapfb, is there anything else I shall 
>>> take in consideration? Or, VRFB driver should not be a part of 
>>> omapdrm, but a standalone one?
> 
> We already have DMM driver in the omapdrm module, and I think VRFB fits 
> along just fine. I don't think there ever has been any other users for 
> VRFB than DSS, and as it's such an old IP, I don't think there ever will.
> 

Ok, I guess if a need appears, it can always be moved out of omapdrm. 
The same applies to DMM/TILER code I guess.

> I don't have any particular hints in mind.
> 
> Do you have omap4/5 so you can test that DMM still works after your 
> changes?
> 

Yes, I have motorola droid4 (4430/sgx540) to test with. Which brings 
another issue on the table - I was not able to find a way to allocate a 
TILER dma_buf. The only way seems to be by using omap_bo_xxx functions, 
which is a 'vendor' API. Do I miss something or omapdrm is lacks 
functionality? Also, is there any particular reason why TILER is not 
enabled by default for dma_buf BOs? Is it a limited resource (like, 
there is a finite number of BOs that can use TILER) or there is some 
other reason. Also, is it possible to 'migrate' non-TILER BO to a TILER 
one? The same issue will arise with VRFB (with its 12 contexts on omap3) 
as well.

So, in short:
- omap3: VRFB driver to be added to omapdrm.
- omap3/omap4/omap5: dma_buf lacks TILER/VRFB support

Adding VRFB should be trivial, but I am more concerned about how to 
rotate dma_buf buffers. I imagine something like - on setting the plane 
"rotate" property, migrate physical address from 'normal' CMA memory to 
a TILER/VRFB one. Is that possible? What if we already have that bo 
mmap-ed? What if SGX MMU is already set up to access the memory? Or, is 
it possible to use TILER for read access, the same way VRFB can be 
set-up, so instead of writing through TILER/VRFB, DSS to be set-up to 
read FB memory through TILER/VRFB thus avoiding the need to migrate SG 
and/or page tables?

Thanks and regards,
Ivo

Re: omapdrm VRFB rotation

[Tomi Valkeinen]

On 10/11/2021 10:29, Ivaylo Dimitrov wrote:
> Hi,
> 
> On 9.11.21 г. 11:22 ч., Tomi Valkeinen wrote:
>> Hi,
>>
>> On 08/11/2021 19:43, Ivaylo Dimitrov wrote:
>>> Sorry, mail was sent to the old Tomi's address.
>>>
>>> On 8.11.21 г. 19:05 ч., Ivaylo Dimitrov wrote:
>>>> Hi,
>>>>
>>>> Currently omapdrm supports TILER rotation only, which excludes omap3 
>>>> and earlier SoCs. I have the hardware (N900/N950), time and will to 
>>>> implement VRFB rotation support in omapdrm driver, however, I'll 
>>>> appreciate some hints. Or, if there is already something ready, 
>>>> please point me to it so I can take it from where it is.
>>>>
>>>> Besides partially reverting 517a8a9564c0dea98e6d4e2c7f0fe4cbb9b8c9ba 
>>>> and copying VRFB code from omapfb, is there anything else I shall 
>>>> take in consideration? Or, VRFB driver should not be a part of 
>>>> omapdrm, but a standalone one?
>>
>> We already have DMM driver in the omapdrm module, and I think VRFB 
>> fits along just fine. I don't think there ever has been any other 
>> users for VRFB than DSS, and as it's such an old IP, I don't think 
>> there ever will.
>>
> 
> Ok, I guess if a need appears, it can always be moved out of omapdrm. 
> The same applies to DMM/TILER code I guess.

Yes.

>> I don't have any particular hints in mind.
>>
>> Do you have omap4/5 so you can test that DMM still works after your 
>> changes?
>>

So, first, a few clarifications about DMM/TILER. There are two somewhat 
separate things. I'm not sure what are the exactly correct words for 
these, but these are the terms I've used:

- DMM (sometimes called wrongly TILER 1D), which acts as a basic iommu. 
It doesn't do rotation, just mapping scattered pages to a contiguous 
memory view.

- TILER (or TILER 2D) which on top of the above, adds support for rotation.

> Yes, I have motorola droid4 (4430/sgx540) to test with. Which brings 
> another issue on the table - I was not able to find a way to allocate a 
> TILER dma_buf. The only way seems to be by using omap_bo_xxx functions, 
> which is a 'vendor' API. Do I miss something or omapdrm is lacks 

Yes, omap_bo_xxx is omap specific API. But I don't understand your 
question about omapdrm. omap_bo functions use omapdrm's API. The 
userspace can skip libdrm and just call the ioctls directly if they so want.

> functionality? Also, is there any particular reason why TILER is not 
> enabled by default for dma_buf BOs? Is it a limited resource (like, 
> there is a finite number of BOs that can use TILER) or there is some 

Yes, TILER is a limited resource, there's a maximum size for the 
currently mapped memory. Going through TILER is also slower, and while 
for 0 degree rotation the diff probably isn't much, it's still there.

Also TILER is not really quite supported, as I never got it working with 
all the YUV modes, and also because there's a HW issue, which may cause 
the device to lock up in some rare cases. And last, TILER creates such a 
memory layout that it's not possible to share it safely with dmabuf, as 
dmabuf lacks the features to properly describe the layout.

All that said, I think TILER should mostly work in upstream.

However, DMM is supported, and used by default. If you allocate a dumb 
buffer, it uses DMM by default.

> other reason. Also, is it possible to 'migrate' non-TILER BO to a TILER 
> one? The same issue will arise with VRFB (with its 12 contexts on omap3) 
> as well.

No, not possible to migrate.

> So, in short:
> - omap3: VRFB driver to be added to omapdrm.
> - omap3/omap4/omap5: dma_buf lacks TILER/VRFB support

Can you elaborate on what's missing?

> Adding VRFB should be trivial, but I am more concerned about how to 
> rotate dma_buf buffers. I imagine something like - on setting the plane 
> "rotate" property, migrate physical address from 'normal' CMA memory to 
> a TILER/VRFB one. Is that possible? What if we already have that bo 
> mmap-ed? What if SGX MMU is already set up to access the memory? Or, is 
> it possible to use TILER for read access, the same way VRFB can be 
> set-up, so instead of writing through TILER/VRFB, DSS to be set-up to 
> read FB memory through TILER/VRFB thus avoiding the need to migrate SG 
> and/or page tables?

I have to say I don't quite remember how VRFB works. But for TILER, we 
have to specifically allocate a TILER buffer. And then everyone else 
uses TILER 0 degree view, but DSS can use 0/90/180/270 view when showing 
it on the display.

But I think the case is the same for VRFB too: if you want to use VRFB, 
all access has to go through VRFB, as the pixels are written to memory 
in a special way.

  Tomi

Re: omapdrm VRFB rotation

[Ivaylo Dimitrov]

On 10.11.21 г. 11:01 ч., Tomi Valkeinen wrote:
> On 10/11/2021 10:29, Ivaylo Dimitrov wrote:
>> Hi,
>>
>> On 9.11.21 г. 11:22 ч., Tomi Valkeinen wrote:
>>> Hi,
>>>
>>> On 08/11/2021 19:43, Ivaylo Dimitrov wrote:
>>>> Sorry, mail was sent to the old Tomi's address.
>>>>
>>>> On 8.11.21 г. 19:05 ч., Ivaylo Dimitrov wrote:
>>>>> Hi,
>>>>>
>>>>> Currently omapdrm supports TILER rotation only, which excludes 
>>>>> omap3 and earlier SoCs. I have the hardware (N900/N950), time and 
>>>>> will to implement VRFB rotation support in omapdrm driver, however, 
>>>>> I'll appreciate some hints. Or, if there is already something 
>>>>> ready, please point me to it so I can take it from where it is.
>>>>>
>>>>> Besides partially reverting 
>>>>> 517a8a9564c0dea98e6d4e2c7f0fe4cbb9b8c9ba and copying VRFB code from 
>>>>> omapfb, is there anything else I shall take in consideration? Or, 
>>>>> VRFB driver should not be a part of omapdrm, but a standalone one?
>>>
>>> We already have DMM driver in the omapdrm module, and I think VRFB 
>>> fits along just fine. I don't think there ever has been any other 
>>> users for VRFB than DSS, and as it's such an old IP, I don't think 
>>> there ever will.
>>>
>>
>> Ok, I guess if a need appears, it can always be moved out of omapdrm. 
>> The same applies to DMM/TILER code I guess.
> 
> Yes.
> 
>>> I don't have any particular hints in mind.
>>>
>>> Do you have omap4/5 so you can test that DMM still works after your 
>>> changes?
>>>
> 
> So, first, a few clarifications about DMM/TILER. There are two somewhat 
> separate things. I'm not sure what are the exactly correct words for 
> these, but these are the terms I've used:
> 
> - DMM (sometimes called wrongly TILER 1D), which acts as a basic iommu. 
> It doesn't do rotation, just mapping scattered pages to a contiguous 
> memory view.
> 
> - TILER (or TILER 2D) which on top of the above, adds support for rotation.
> 

Thanks for the clarification, I'll try to stick to those.

>> Yes, I have motorola droid4 (4430/sgx540) to test with. Which brings 
>> another issue on the table - I was not able to find a way to allocate 
>> a TILER dma_buf. The only way seems to be by using omap_bo_xxx 
>> functions, which is a 'vendor' API. Do I miss something or omapdrm is 
>> lacks 
> 
> Yes, omap_bo_xxx is omap specific API. But I don't understand your 
> question about omapdrm. omap_bo functions use omapdrm's API. The 
> userspace can skip libdrm and just call the ioctls directly if they so 
> want.
> 

omap_bo functions/ioctls do, but if we try to use GBM dma_buf API 
(gbm_bo_create() and friends), we cannot allocate anything but CMA 
memory which omapdrm refuses to rotate, IIUC. Well at least I was not 
able to  make framebuffer rotate with GBM allocated BO.

The terms I use:
dma_buf - BO that is allocated using GBM API and seems to end up here: 
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/omapdrm/omap_gem.c#L1300. 
Seems it cannot go through the TILER.

omap_bo: BO that is allocated using omap_bo functions. IIUC this is 
basically a dumb buffer, but it can be allocated to be accesses through 
TILER by passing the appropriate flags to omap_bo_new().

>> functionality? Also, is there any particular reason why TILER is not 
>> enabled by default for dma_buf BOs? Is it a limited resource (like, 
>> there is a finite number of BOs that can use TILER) or there is some 
> 
> Yes, TILER is a limited resource, there's a maximum size for the 
> currently mapped memory. Going through TILER is also slower, and while 
> for 0 degree rotation the diff probably isn't much, it's still there.
> 

Yeah, so we should go through TILER only when needed. The same as VRFB.

> Also TILER is not really quite supported, as I never got it working with 
> all the YUV modes, and also because there's a HW issue, which may cause 
> the device to lock up in some rare cases. And last, TILER creates such a 
> memory layout that it's not possible to share it safely with dmabuf, as 
> dmabuf lacks the features to properly describe the layout.
> 
> All that said, I think TILER should mostly work in upstream.
> 

But, only from omap_bo BOs

> However, DMM is supported, and used by default. If you allocate a dumb 
> buffer, it uses DMM by default.
> 

not for dma_buf BOs though. Not really an issue as on omap3 there is no 
DMM so we must use CMA either ways.

>> other reason. Also, is it possible to 'migrate' non-TILER BO to a 
>> TILER one? The same issue will arise with VRFB (with its 12 contexts 
>> on omap3) as well.
> 
> No, not possible to migrate.
> 
>> So, in short:
>> - omap3: VRFB driver to be added to omapdrm.
>> - omap3/omap4/omap5: dma_buf lacks TILER/VRFB support
> 
> Can you elaborate on what's missing?
> 

GBM BOs (which I call dma_buf BOs) lack TILER support

>> Adding VRFB should be trivial, but I am more concerned about how to 
>> rotate dma_buf buffers. I imagine something like - on setting the 
>> plane "rotate" property, migrate physical address from 'normal' CMA 
>> memory to a TILER/VRFB one. Is that possible? What if we already have 
>> that bo mmap-ed? What if SGX MMU is already set up to access the 
>> memory? Or, is it possible to use TILER for read access, the same way 
>> VRFB can be set-up, so instead of writing through TILER/VRFB, DSS to 
>> be set-up to read FB memory through TILER/VRFB thus avoiding the need 
>> to migrate SG and/or page tables?
> 
> I have to say I don't quite remember how VRFB works.

it has 12 'contexts' that can represent up to that number of 'images' in 
memory with rotated views

> But for TILER, we 
> have to specifically allocate a TILER buffer. And then everyone else 
> uses TILER 0 degree view, but DSS can use 0/90/180/270 view when showing 
> it on the display.
> 

oh, so in theory omapdrm should be able to show dma_buf BOs rotated? We 
only lack a way to allocate TILER GBM BO, right?

I ported xf86-video-omap to use GBM API instead of omap_bo API and it 
works fine in native orientation. However, when it tries to set 
'rotated' property to framebuffer, it receives an error. Should I trace 
to see why it fails in the kernel or this is not supported?

> But I think the case is the same for VRFB too: if you want to use VRFB, 
> all access has to go through VRFB, as the pixels are written to memory 
> in a special way.
> 

Yes, I think you are right.

Sorry for asking so much questions but I want to have a clear picture on 
what is supposed to work and what is missing.

Thanks,
Ivo

Re: omapdrm VRFB rotation

[Tomi Valkeinen]

On 10/11/2021 11:50, Ivaylo Dimitrov wrote:
> 
> 
> On 10.11.21 г. 11:01 ч., Tomi Valkeinen wrote:
>> On 10/11/2021 10:29, Ivaylo Dimitrov wrote:
>>> Hi,
>>>
>>> On 9.11.21 г. 11:22 ч., Tomi Valkeinen wrote:
>>>> Hi,
>>>>
>>>> On 08/11/2021 19:43, Ivaylo Dimitrov wrote:
>>>>> Sorry, mail was sent to the old Tomi's address.
>>>>>
>>>>> On 8.11.21 г. 19:05 ч., Ivaylo Dimitrov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Currently omapdrm supports TILER rotation only, which excludes 
>>>>>> omap3 and earlier SoCs. I have the hardware (N900/N950), time and 
>>>>>> will to implement VRFB rotation support in omapdrm driver, 
>>>>>> however, I'll appreciate some hints. Or, if there is already 
>>>>>> something ready, please point me to it so I can take it from where 
>>>>>> it is.
>>>>>>
>>>>>> Besides partially reverting 
>>>>>> 517a8a9564c0dea98e6d4e2c7f0fe4cbb9b8c9ba and copying VRFB code 
>>>>>> from omapfb, is there anything else I shall take in consideration? 
>>>>>> Or, VRFB driver should not be a part of omapdrm, but a standalone 
>>>>>> one?
>>>>
>>>> We already have DMM driver in the omapdrm module, and I think VRFB 
>>>> fits along just fine. I don't think there ever has been any other 
>>>> users for VRFB than DSS, and as it's such an old IP, I don't think 
>>>> there ever will.
>>>>
>>>
>>> Ok, I guess if a need appears, it can always be moved out of omapdrm. 
>>> The same applies to DMM/TILER code I guess.
>>
>> Yes.
>>
>>>> I don't have any particular hints in mind.
>>>>
>>>> Do you have omap4/5 so you can test that DMM still works after your 
>>>> changes?
>>>>
>>
>> So, first, a few clarifications about DMM/TILER. There are two 
>> somewhat separate things. I'm not sure what are the exactly correct 
>> words for these, but these are the terms I've used:
>>
>> - DMM (sometimes called wrongly TILER 1D), which acts as a basic 
>> iommu. It doesn't do rotation, just mapping scattered pages to a 
>> contiguous memory view.
>>
>> - TILER (or TILER 2D) which on top of the above, adds support for 
>> rotation.
>>
> 
> Thanks for the clarification, I'll try to stick to those.
> 
>>> Yes, I have motorola droid4 (4430/sgx540) to test with. Which brings 
>>> another issue on the table - I was not able to find a way to allocate 
>>> a TILER dma_buf. The only way seems to be by using omap_bo_xxx 
>>> functions, which is a 'vendor' API. Do I miss something or omapdrm is 
>>> lacks 
>>
>> Yes, omap_bo_xxx is omap specific API. But I don't understand your 
>> question about omapdrm. omap_bo functions use omapdrm's API. The 
>> userspace can skip libdrm and just call the ioctls directly if they so 
>> want.
>>
> 
> omap_bo functions/ioctls do, but if we try to use GBM dma_buf API 
> (gbm_bo_create() and friends), we cannot allocate anything but CMA 
> memory which omapdrm refuses to rotate, IIUC. Well at least I was not 
> able to  make framebuffer rotate with GBM allocated BO.

Yes, I think that's true: libgbm doesn't support omap's TILER.

> The terms I use:
> dma_buf - BO that is allocated using GBM API and seems to end up here: 
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/omapdrm/omap_gem.c#L1300. 
> Seems it cannot go through the TILER.

Isn't that a gbm_bo? Or something =). dma_buf means a specific thing, 
which is not what you mean above.

> omap_bo: BO that is allocated using omap_bo functions. IIUC this is 
> basically a dumb buffer, but it can be allocated to be accesses through 
> TILER by passing the appropriate flags to omap_bo_new().

No, I don't think you can allocate a TILER buffer with omap_bo_new(), 
you need to use omap_bo_new_tiled().

>>> functionality? Also, is there any particular reason why TILER is not 
>>> enabled by default for dma_buf BOs? Is it a limited resource (like, 
>>> there is a finite number of BOs that can use TILER) or there is some 
>>
>> Yes, TILER is a limited resource, there's a maximum size for the 
>> currently mapped memory. Going through TILER is also slower, and while 
>> for 0 degree rotation the diff probably isn't much, it's still there.
>>
> 
> Yeah, so we should go through TILER only when needed. The same as VRFB.
> 
>> Also TILER is not really quite supported, as I never got it working 
>> with all the YUV modes, and also because there's a HW issue, which may 
>> cause the device to lock up in some rare cases. And last, TILER 
>> creates such a memory layout that it's not possible to share it safely 
>> with dmabuf, as dmabuf lacks the features to properly describe the 
>> layout.
>>
>> All that said, I think TILER should mostly work in upstream.
>>
> 
> But, only from omap_bo BOs

Yes.

>> However, DMM is supported, and used by default. If you allocate a dumb 
>> buffer, it uses DMM by default.
>>
> 
> not for dma_buf BOs though. Not really an issue as on omap3 there is no 
> DMM so we must use CMA either ways.

I think all allocations use DMM by default, if available. So gbm_bo 
should use DMM underneath on omap4/5.

>>> other reason. Also, is it possible to 'migrate' non-TILER BO to a 
>>> TILER one? The same issue will arise with VRFB (with its 12 contexts 
>>> on omap3) as well.
>>
>> No, not possible to migrate.
>>
>>> So, in short:
>>> - omap3: VRFB driver to be added to omapdrm.
>>> - omap3/omap4/omap5: dma_buf lacks TILER/VRFB support
>>
>> Can you elaborate on what's missing?
>>
> 
> GBM BOs (which I call dma_buf BOs) lack TILER support
> 
>>> Adding VRFB should be trivial, but I am more concerned about how to 
>>> rotate dma_buf buffers. I imagine something like - on setting the 
>>> plane "rotate" property, migrate physical address from 'normal' CMA 
>>> memory to a TILER/VRFB one. Is that possible? What if we already have 
>>> that bo mmap-ed? What if SGX MMU is already set up to access the 
>>> memory? Or, is it possible to use TILER for read access, the same way 
>>> VRFB can be set-up, so instead of writing through TILER/VRFB, DSS to 
>>> be set-up to read FB memory through TILER/VRFB thus avoiding the need 
>>> to migrate SG and/or page tables?
>>
>> I have to say I don't quite remember how VRFB works.
> 
> it has 12 'contexts' that can represent up to that number of 'images' in 
> memory with rotated views
> 
>> But for TILER, we have to specifically allocate a TILER buffer. And 
>> then everyone else uses TILER 0 degree view, but DSS can use 
>> 0/90/180/270 view when showing it on the display.
>>
> 
> oh, so in theory omapdrm should be able to show dma_buf BOs rotated? We 
> only lack a way to allocate TILER GBM BO, right?

Yes.

> I ported xf86-video-omap to use GBM API instead of omap_bo API and it 
> works fine in native orientation. However, when it tries to set 
> 'rotated' property to framebuffer, it receives an error. Should I trace 
> to see why it fails in the kernel or this is not supported?

Well, I have no idea what's going on there, but I just tested with the 
latest drm-misc-next, and at least a basic test with TILER works. I used 
kms++ and rottest.py.

Maybe you used omap_bo_new(), which does not give you a TILER buffer?

>> But I think the case is the same for VRFB too: if you want to use 
>> VRFB, all access has to go through VRFB, as the pixels are written to 
>> memory in a special way.
>>
> 
> Yes, I think you are right.
> 
> Sorry for asking so much questions but I want to have a clear picture on 
> what is supposed to work and what is missing.

No problem. I think it's very nice to get VRFB moved to omapdrm, as I 
believe that's the only feature missing from omapdrm which is supported 
in omapfb.

  Tomi