On Thu, Nov 9, 2017 at 9:00 AM, Greentime Hu <green.hu@xxxxxxxxx> wrote:
> 2017-11-08 18:03 GMT+08:00 Arnd Bergmann <arnd@xxxxxxxx>:
>> On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu <green.hu@xxxxxxxxx> wrote:
>>> From: Greentime Hu <greentime@xxxxxxxxxxxxx>
>>>
>>> Signed-off-by: Vincent Chen <vincentc@xxxxxxxxxxxxx>
>>> Signed-off-by: Greentime Hu <greentime@xxxxxxxxxxxxx>
>>> ---
>>> arch/nds32/configs/ae3xx_defconfig | 110 +++++++++++++++++++++++++++++++++++
>>> arch/nds32/configs/ag101p_defconfig | 109 ++++++++++++++++++++++++++++++++++
>>
>> Are those two incompatible? I would recommend starting without board
>> specific defconfig
>> files, it just gets messy once you get more than a few machines you
>> want to support.
>
> Thanks.
> These 2 are incompatible.
> They use different drivers. I may still keep these 2 defconfigs.
Using different drivers doesn't make machines incompatible. For instance, the
x86 desktop machine has drivers for all kinds of devices, but it uses
one configuration
that works on basically any x86 machine.
Similarly, we only have one defconfig file on arm64, and it works across very
diverse machines (phone, home routers, large servers, etc.).
All drivers should be written in a way to allow being built into the
kernel without
doing any harm when you don't have the respective hardware.
>>> +CONFIG_FB=y
>>> +# CONFIG_VGA_CONSOLE is not set
>>> +CONFIG_FRAMEBUFFER_CONSOLE=y
>>
>> You have a framebuffer console here, but no framebuffer driver?
>
> Thanks.
> I shall enable it when I push our framebuffer in the next time.
> I will disable it in the next version patch.
The fbdev subsystem is no longer recommended for new drivers, they
should be written on top of the DRM framework. You can use
CONFIG_DRM_FBDEV_EMULATION to get the framebuffer
console on top of that, but then you don't need to enable CONFIG_FB.
Please have a look at drivers/gpu/drm/tinydrm/ to see if you can either
use that directly, or take it as a skeleton for your own driver.
Arnd
