Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko

[Frans Klaver]

On Tue, Dec 29, 2015 at 3:06 PM, Sebastian Frias <sf84@xxxxxxxxxxx> wrote:
> On 12/29/2015 02:49 PM, Frans Klaver wrote:
>>
>> On Tue, Dec 29, 2015 at 2:15 PM, Sebastian Frias <sf84@xxxxxxxxxxx> wrote:
>>>
>>> Hi,
>>>
>>> We are wondering what is the recommended way of adding support for a
>>> framebuffer driver on the Linux kernel.
>>> Below you can find a patch with a proposed solution.
>>
>>
>> That's not really a solution to add a driver to the kernel. You'd have
>> to include some actual driver code as well.
>
>
> We are not attempting to upstream the driver yet, that's why its code is not
> included.
>
> The patch is an attempt to allow the user to enable Framebuffer support by
> providing an option for the user and then setting FB_CFB_FILLRECT,
> FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
>
> It does the job, but we feel (and you have sort of confirmed it) that it may
> not be a good idea to do it that way.
>
>>
>>
>>> Our frambuffer driver source code is provided separately, but right now
>>> it
>>> requires "cfb_fillrect", "cfb_copyarea" and "cfb_imageblit" to be
>>> provided
>>> by the kernel.
>>>
>>> Our current kernel fork (based on 3.4) hardcodes FB_CFB_FILLRECT,
>>> FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
>>> Since we are in the process of migrating to 4.x and upstreaming changes
>>> along the way, we would like to know if the patch below is the way to go
>>> with it or if you have suggestions to improve it.
>>
>>
>> Is the below patch really a patch you intend to upstream, or are you
>> just wondering about what your Kconfig entry should look like when you
>> upstream your driver?
>
>
> Right now we don't know if the driver will be upstreamed.
> Let me rephrase my question:
>
> - how would you recommend enabling FB_CFB_FILLRECT, FB_CFB_COPYAREA and
> FB_CFB_IMAGEBLIT for a driver that is not included in the kernel's tree?
>
> If that is not possible, I guess we will have to keep a forked tree until
> the driver is upstreamed, but we would like to avoid that, hence the
> question.

I guess you'll have to keep on doing that indeed. I'm not aware of any
location where out-of-tree drivers are considered. You should try
again when you have some actual code to upstream.

Cheers,
Frans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/