[RFC 00/21] drm: fb emulation: Step 3: Remove FB_KMS_HELPER config from drivers

[Archit Taneja]

Hi,

On 07/13/2015 09:07 PM, Daniel Vetter wrote:
> On Mon, Jul 13, 2015 at 11:30:34AM -0400, Alex Deucher wrote:
>> On Mon, Jul 13, 2015 at 2:43 AM, Archit Taneja <architt at codeaurora.org> wrote:
>>> With the top level DRM_FBDEV_EMULATION option, drivers don't need to
>>> select DRM_FB_KMS_HELPER or other FB related config options in the
>>> driver.
>>>
>>> Even if FBDEV_EMULATION isn't select, the stubbed out versions of
>>> the drm_fb_helper functions will be called.
>>>
>>> There are some drivers which still need some FB stuff even after
>>> these changes. They are qxl, udl and nouveau. These are handled a bit
>>> differently compared to the other patches.
>>
>> Series is:
>> Acked-by: Alex Deucher <alexander.deucher at amd.com>
>
> Archit for merging I think I'll just keep the current set of patches I
> have for testing (well until there's a real bug discovered). Can you
> please collect all the acks/r-bs/t-d when resending so I don't have to
> digg them out when we merge the final versions of these?
>

Sure. I'll keep a track of this.

Speaking of bugs, there was one thing I noticed in the series which I
am not sure about.

One of the new helpers wraps around framebuffer_alloc(). Most drivers
tend to pass the drm_device's dev pointer to this, and this is what I
do in the helper too.

But some drivers(nouveau, radeon, qxl and some more) pass their
pci_dev's dev pointer.

Looking at the framebuffer code, it looks like the 'dev' we pass to
framebuffer_alloc is what is used as the parent device when
creating a fb device.

After this patch set, all drivers will use drm_device's dev when
calling framebuffer_alloc. I was wondering if this could cause any
fbcon issues?

Archit

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project