All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Dave Airlie <airlied@gmail.com>,
	linux-fbdev@vger.kernel.org, Stephen Warren <swarren@nvidia.com>,
	Olof Johansson <olof@lixom.net>
Subject: Re: [RFC 2/6] x86: provide platform-devices for boot-framebuffers
Date: Mon, 01 Jul 2013 15:48:04 +0000	[thread overview]
Message-ID: <51D1A4B4.2040905@wwwdotorg.org> (raw)
In-Reply-To: <CANq1E4TJjmq2UFfarkdUF7s5KUPuzfUDiDU5BFfF-5QUsjpDwA@mail.gmail.com>

On 06/28/2013 04:11 AM, David Herrmann wrote:
> Hi
> 
> On Wed, Jun 26, 2013 at 10:49 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 06/24/2013 04:27 PM, David Herrmann wrote:
>>> The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
>>> x86 causes troubles when loading multiple fbdev drivers. The global
>>> "struct screen_info" does not provide any state-tracking about which
>>> drivers use the FBs. request_mem_region() theoretically works, but
>>> unfortunately vesafb/efifb ignore it due to quirks for broken boards.
>>>
>>> Avoid this by creating a "platform-framebuffer" device with a pointer
>>> to the "struct screen_info" as platform-data. Drivers can now create
>>> platform-drivers and the driver-core will refuse multiple drivers being
>>> active simultaneously.
>>>
>>> We keep the screen_info available for backwards-compatibility. Drivers
>>> can be converted in follow-up patches.
>>>
>>> Apart from "platform-framebuffer" devices, this also introduces a
>>> compatibility option for "simple-framebuffer" drivers which recently got
>>> introduced for OF based systems. If CONFIG_X86_SYSFB is selected, we
>>> try to match the screen_info against a simple-framebuffer supported
>>> format. If we succeed, we create a "simple-framebuffer" device instead
>>> of a platform-framebuffer.
...

>>> diff --git a/arch/x86/kernel/sysfb.c b/arch/x86/kernel/sysfb.c
...
>>> +#else /* CONFIG_X86_SYSFB */
>>> +
>>> +static bool parse_mode(const struct screen_info *si,
>>> +                    struct simplefb_platform_data *mode)
>>> +{
>>> +     return false;
>>> +}
>>> +
>>> +static int create_simplefb(const struct screen_info *si,
>>> +                        const struct simplefb_platform_data *mode)
>>> +{
>>> +     return -EINVAL;
>>> +}
>>> +
>>> +#endif /* CONFIG_X86_SYSFB */
>>
>> Following on from my ifdef comment above, I believe those versions of
>> those functions will always cause add_sysfb() to return -ENODEV, so you
>> may as well provide a static inline for add_sysfb() instead.
> 
> No. add_sysfb() is supposed to always succeed. However, if
> parse_mode/create_simplefb fail, it creates a "platform-framebuffer"
> as fallback. I don't see any way to avoid these ifdefs. Considering
> the explanation above, could you elaborate how you think this should
> work?

Ah, I wasn't getting the fallback mechanism; that if creating a simplefb
wasn't possible or didn't succeed, a platformfb device would be created
instead.

Perhaps the following might be slightly clearer; there are certainly
fewer nesting levels:

static __init int add_sysfb(void)
{
	const struct screen_info *si = &screen_info;
	struct simplefb_platform_data mode;
	struct platform_device *pd;
	bool compatible = false;
	int ret;

	compatible = parse_mode(si, &mode);
	if (compatible) {
		ret = create_simplefb(si, &mode);
		if (!ret)
			return 0;
	}

	pd = platform_device_register_resndata(NULL,
					"platform-framebuffer", 0,
					NULL, 0, si, sizeof(*si));
	ret = IS_ERR(pd) ? PTR_ERR(pd) : 0;

	return ret;
}


WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Dave Airlie <airlied@gmail.com>,
	linux-fbdev@vger.kernel.org, Stephen Warren <swarren@nvidia.com>,
	Olof Johansson <olof@lixom.net>
Subject: Re: [RFC 2/6] x86: provide platform-devices for boot-framebuffers
Date: Mon, 01 Jul 2013 09:48:04 -0600	[thread overview]
Message-ID: <51D1A4B4.2040905@wwwdotorg.org> (raw)
In-Reply-To: <CANq1E4TJjmq2UFfarkdUF7s5KUPuzfUDiDU5BFfF-5QUsjpDwA@mail.gmail.com>

On 06/28/2013 04:11 AM, David Herrmann wrote:
> Hi
> 
> On Wed, Jun 26, 2013 at 10:49 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 06/24/2013 04:27 PM, David Herrmann wrote:
>>> The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
>>> x86 causes troubles when loading multiple fbdev drivers. The global
>>> "struct screen_info" does not provide any state-tracking about which
>>> drivers use the FBs. request_mem_region() theoretically works, but
>>> unfortunately vesafb/efifb ignore it due to quirks for broken boards.
>>>
>>> Avoid this by creating a "platform-framebuffer" device with a pointer
>>> to the "struct screen_info" as platform-data. Drivers can now create
>>> platform-drivers and the driver-core will refuse multiple drivers being
>>> active simultaneously.
>>>
>>> We keep the screen_info available for backwards-compatibility. Drivers
>>> can be converted in follow-up patches.
>>>
>>> Apart from "platform-framebuffer" devices, this also introduces a
>>> compatibility option for "simple-framebuffer" drivers which recently got
>>> introduced for OF based systems. If CONFIG_X86_SYSFB is selected, we
>>> try to match the screen_info against a simple-framebuffer supported
>>> format. If we succeed, we create a "simple-framebuffer" device instead
>>> of a platform-framebuffer.
...

>>> diff --git a/arch/x86/kernel/sysfb.c b/arch/x86/kernel/sysfb.c
...
>>> +#else /* CONFIG_X86_SYSFB */
>>> +
>>> +static bool parse_mode(const struct screen_info *si,
>>> +                    struct simplefb_platform_data *mode)
>>> +{
>>> +     return false;
>>> +}
>>> +
>>> +static int create_simplefb(const struct screen_info *si,
>>> +                        const struct simplefb_platform_data *mode)
>>> +{
>>> +     return -EINVAL;
>>> +}
>>> +
>>> +#endif /* CONFIG_X86_SYSFB */
>>
>> Following on from my ifdef comment above, I believe those versions of
>> those functions will always cause add_sysfb() to return -ENODEV, so you
>> may as well provide a static inline for add_sysfb() instead.
> 
> No. add_sysfb() is supposed to always succeed. However, if
> parse_mode/create_simplefb fail, it creates a "platform-framebuffer"
> as fallback. I don't see any way to avoid these ifdefs. Considering
> the explanation above, could you elaborate how you think this should
> work?

Ah, I wasn't getting the fallback mechanism; that if creating a simplefb
wasn't possible or didn't succeed, a platformfb device would be created
instead.

Perhaps the following might be slightly clearer; there are certainly
fewer nesting levels:

static __init int add_sysfb(void)
{
	const struct screen_info *si = &screen_info;
	struct simplefb_platform_data mode;
	struct platform_device *pd;
	bool compatible = false;
	int ret;

	compatible = parse_mode(si, &mode);
	if (compatible) {
		ret = create_simplefb(si, &mode);
		if (!ret)
			return 0;
	}

	pd = platform_device_register_resndata(NULL,
					"platform-framebuffer", 0,
					NULL, 0, si, sizeof(*si));
	ret = IS_ERR(pd) ? PTR_ERR(pd) : 0;

	return ret;
}

  reply	other threads:[~2013-07-01 15:48 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-24 22:27 [RFC 0/6] SimpleDRM Driver (was: dvbe driver) David Herrmann
2013-06-24 22:27 ` David Herrmann
2013-06-24 22:27 ` [RFC 1/6] fbdev: simplefb: add init through platform_data David Herrmann
2013-06-24 22:27   ` David Herrmann
2013-06-26 20:39   ` Stephen Warren
2013-06-26 20:39     ` Stephen Warren
2013-06-28 10:03     ` David Herrmann
2013-06-28 10:03       ` David Herrmann
2013-06-24 22:27 ` [RFC 2/6] x86: provide platform-devices for boot-framebuffers David Herrmann
2013-06-24 22:27   ` David Herrmann
2013-06-26 20:49   ` Stephen Warren
2013-06-26 20:49     ` Stephen Warren
2013-06-28 10:11     ` David Herrmann
2013-06-28 10:11       ` David Herrmann
2013-07-01 15:48       ` Stephen Warren [this message]
2013-07-01 15:48         ` Stephen Warren
2013-06-24 22:27 ` [RFC 3/6] drm: add SimpleDRM driver David Herrmann
2013-06-24 22:27   ` David Herrmann
2013-06-25  1:05   ` Andy Lutomirski
2013-06-25  1:05     ` Andy Lutomirski
2013-06-28  9:59     ` David Herrmann
2013-06-28  9:59       ` David Herrmann
2013-06-26 20:58   ` Stephen Warren
2013-06-26 20:58     ` Stephen Warren
2013-06-28 10:01     ` David Herrmann
2013-06-28 10:01       ` David Herrmann
2013-06-24 22:27 ` [RFC 4/6] drm: simpledrm: add fbdev fallback support David Herrmann
2013-06-24 22:27   ` David Herrmann
2013-06-26 20:59   ` Stephen Warren
2013-06-26 20:59     ` Stephen Warren
2013-06-28 10:14     ` David Herrmann
2013-06-28 10:14       ` David Herrmann
2013-06-24 22:27 ` [RFC 5/6] drm: add helpers to kick out firmware drivers David Herrmann
2013-06-24 22:27   ` David Herrmann
2013-06-24 22:27 ` [RFC 6/6] drm: nouveau: kick out firmware drivers during probe David Herrmann
2013-06-24 22:27   ` David Herrmann
2013-06-26 21:30 ` [RFC 0/6] SimpleDRM Driver (was: dvbe driver) Stephen Warren
2013-06-26 21:30   ` Stephen Warren
2013-06-28 10:43   ` David Herrmann
2013-06-28 10:43     ` David Herrmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51D1A4B4.2040905@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=airlied@gmail.com \
    --cc=dh.herrmann@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=swarren@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.