[GIT PULL] drm/rockchip: fixes and new features

[Mark yao]

On 2015年07月01日 16:42, Tomasz Figa wrote:
> On Wed, Jul 1, 2015 at 5:32 PM, Mark yao <mark.yao at rock-chips.com> wrote:
>> On 2015年07月01日 16:03, Tomasz Figa wrote:
>>> Hi Mark,
>>>
>>> On Tue, Jun 30, 2015 at 3:50 PM, Mark yao <mark.yao at rock-chips.com> wrote:
>>>> Hi Dave.
>>>>
>>>>       Some fixes and some new features. I'd like you can pull them.
>>>>
>>>> The following changes since commit
>>>> c5fd936e992dd2829167d2adc63e151675ca6898:
>>>>
>>>>     drm/nouveau: Pause between setting gpu to D3hot and cutting the power
>>>> (2015-06-26 10:26:37 +1000)
>>>>
>>>> are available in the git repository at:
>>>>
>>>>     https://github.com/markyzq/kernel-drm-rockchip.git
>>>> drm-rockchip-2015-06-30
>>>>
>>>> for you to fetch changes up to 5295c05eb30d743987172853179333c80b8242bc:
>>>>
>>>>     drm/rockchip: default enable win2/3 area0 bit (2015-06-30 14:24:10
>>>> +0800)
>>>>
>>>> ----------------------------------------------------------------
>>>> Heiko Stübner (1):
>>>>         drm/rockchip: only call drm_fb_helper_hotplug_event if fb_helper
>>>> present
>>>>
>>>> Mark Yao (6):
>>>>         drm/rockchip: import dma_buf to gem
>>>>         drm/rockchip: vop: optimize virtual stride calculate
>>>>         drm/rockchip: vop: fix yuv plane support
>>>>         drm/rockchip: vop: support plane scale
>>>>         drm/rockchip: vop: switch cursor plane to window 3
>>>>         drm/rockchip: default enable win2/3 area0 bit
>>> Has this series been reviewed properly? I can see that at least
>>> "drm/rockchip: vop: support plane scale" is kind of "controversial".
>>
>> Sorry for that, can you review those patches, and give me some advices?
>>
>> https://lkml.org/lkml/2015/6/18/77
>> v2: https://lkml.org/lkml/2015/6/26/192
>>
> Yes, will do that.
>
> By the way, please feel free to ping patches on the lists if they idle
> without any comments or tags for while.
>
>>> By the way, if we're using window 3 for cursor plane, because the
>>> cursor window needs special handling, is it okay to expose the cusor
>>> window as an overlay plane to userspace, as we do currently?
>>
>> special handling? what means? "switch cursor plane to window 3" patch only
>> switch cursor
>>   windows from win1 to win3. tag window 3 as DRM_PLANE_TYPE_CURSOR, userspace
>> only
>> can found window 3 is a cursor plane.
>>
> Ah, this was a question slightly unrelated to that patch, but I just
> noticed in that patch that the hardware cursor window is still exposed
> to the userspace as overlay plane, even if it's not quite suitable for
> being such.

Oh, I know your mean, you mean that code:
         { .base = 0x00, .phy = &cursor_data, .type = 
DRM_PLANE_TYPE_OVERLAY },

right?

That is I plan to do.

hardware cursor window have a problem that hard to resolved.
the window can't support width virtual and can't move out of left top top.
But linux desktop or chromiumos should move cursor out of left or top.

I'm considering remove it or find a another way to reuse it.

> Best regards,
> Tomasz
>
>
>


-- 
Ｍark