Re: [PATCH v2 00/14] Platform Framebuffers and SimpleDRM

2013-07-10 Thread David Herrmann
Hi

On Tue, Jul 9, 2013 at 11:02 PM, Stephen Warren  wrote:
> On 07/04/2013 06:25 AM, David Herrmann wrote:
>> Hi
>>
>> This series changes the way we handle firmware framebuffers on x86 systems. 
>> On
>> other architectures the recently introduced "simple-framebuffer"
>> platform-devices provide a sane and proper way to handle firmware 
>> framebuffers.
>> So why not use it on x86, too?
>
> Tested-by: Stephen Warren 
>
> (This time I didn't see any issue with the FB content being blank; I
> must have forgotten a console= command-line parameter or something the
> last time around)

I think I had some error in the pseudo_palette handling (which I now
copied from simplefb.c), but I am not sure why it didn't work in v1.
Thanks a lot for testing!

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


Re: [PATCH v2 00/14] Platform Framebuffers and SimpleDRM

2013-07-09 Thread Stephen Warren
On 07/04/2013 06:25 AM, David Herrmann wrote:
> Hi
> 
> This series changes the way we handle firmware framebuffers on x86 systems. On
> other architectures the recently introduced "simple-framebuffer"
> platform-devices provide a sane and proper way to handle firmware 
> framebuffers.
> So why not use it on x86, too?

Tested-by: Stephen Warren 

(This time I didn't see any issue with the FB content being blank; I
must have forgotten a console= command-line parameter or something the
last time around)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 00/14] Platform Framebuffers and SimpleDRM

2013-07-05 Thread David Herrmann
Hi

On Thu, Jul 4, 2013 at 7:48 PM, H. Peter Anvin  wrote:
> On 07/04/2013 05:25 AM, David Herrmann wrote:
>>
>>   - What FB formats are common on x86 that we should add to
>> SIMPLEFB_FORMATS?
>> (other than ARGB/XRGB32)
>
>
> The common pixel formats on x86 are:
>
> - Palettized 4-bit planar (bigendian, i.e. MSB to the left)
> - Palettized 8-bit packed (one byte per pixel)

Unlikely to be supported with DRM. But if users want it, we can always
add a shadow-buffer and advertise it as RGB332 or alike. Otherwise,
they have to use fbdev as usual, which sounds reasonable to me.

> - 16-bit RGB555 (16-bit littleendian words with R=14:10, G=9:5, B=4:0)

DRM_FORMAT_XRGB1555

> - 16-bit RGB565 (16-bit littleendian words with R=15:11, G=10:5, B=4:0)

DRM_FORMAT_RGB565

> - 24-bit RGB888 in littleendian order (first byte in memory is B,
>   second is G, third is R)

DRM_FORMAT_RGB888

> - 32-bit ARGB (first byte in memory is B, second G, third R, fourth
>   unused in the framebuffer proper)

DRM_FORMAT_ARGB

> - 32-bit RGB10:10:10 (I *believe* 32-bit littleendian words with
>   R=29:20, G=19:10, B=9:0)

DRM_FORMAT_XRGB2101010

Thanks for the hints, I will add these to patch #5.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 00/14] Platform Framebuffers and SimpleDRM

2013-07-04 Thread H. Peter Anvin

On 07/04/2013 05:25 AM, David Herrmann wrote:

  - What FB formats are common on x86 that we should add to SIMPLEFB_FORMATS?
(other than ARGB/XRGB32)


The common pixel formats on x86 are:

- Palettized 4-bit planar (bigendian, i.e. MSB to the left)
- Palettized 8-bit packed (one byte per pixel)
- 16-bit RGB555 (16-bit littleendian words with R=14:10, G=9:5, B=4:0)
- 16-bit RGB565 (16-bit littleendian words with R=15:11, G=10:5, B=4:0)
- 24-bit RGB888 in littleendian order (first byte in memory is B,
  second is G, third is R)
- 32-bit ARGB (first byte in memory is B, second G, third R, fourth
  unused in the framebuffer proper)
- 32-bit RGB10:10:10 (I *believe* 32-bit littleendian words with
  R=29:20, G=19:10, B=9:0)

-hpa

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


[PATCH v2 00/14] Platform Framebuffers and SimpleDRM

2013-07-04 Thread David Herrmann
Hi

This series changes the way we handle firmware framebuffers on x86 systems. On
other architectures the recently introduced "simple-framebuffer"
platform-devices provide a sane and proper way to handle firmware framebuffers.
So why not use it on x86, too?

This series adds x86 setup code to create proper platform-devices for firmware
framebuffers. For backwards compatibility, efi-fb, vesa-fb and platform-fb
devices are created and vesafb.c, efifb.c bind to the right device. We no
longer have vesafb and efifb load unconditionally on "screen_info".
If a fw-FB is compatible to "simple-framebuffer" devices, we create these
instead. We can then use the generic arch-independent simplefb.c on x86 without
any vesafb/efifb conflicts.

Last but not least, the series introduces SimpleDRM, which is basically simplefb
but as DRM driver with all the usual benefits. SimpleDRM is also the motivation
behind this series, but probably only of interest for the dri-devel
mailing-list.

* Patches 1 & 2 modify simplefb.c to accept framebuffer information via plain
  old platform_data and allow real hw drivers to remove simplefb on conflicts.

* Patches 3 & 4 add x86 setup code to create the right platform-device for any
  found firmware framebuffer.

* Patches 5 - 7 modify simplefb.c, vesafb.c, efifb.c to use these new devices
  and support common x86 formats.

* Patch 8 fixes fbcon to require console binding to avoid crashes during
  framebuffer hotplugging

* Patches 9-14: Introduce SimpleDRM

Changes in v2:
 - We now provide efi-framebuffer, vesa-framebuffer or platform-framebuffer
   legacy devices instead of just platform-framebuffer devs. This allows to
   load vesafb, efifb, .. simultaneously instead of only one driver.
 - vesafb and efifb now use the new platform devices
 - simplefb can now be unloaded via remove_conflicting_framebuffers()
 - efifb EFI quirks now moved to x86 setup
 - refactored x86 setup code to avoid #ifdefs
 - Many small fixes (thanks to Stephen and Andy)
 - Adjusted i915 and radeon to use new drm_kick_out_firmware()
 - fbcon now works with SimpleDRM (fixed the palette handling and def-flags)
 - fbdev unloading fixed (Patch #8)

Open issues:
 - How does static platform-device creation conflict with OF support on x86?
   If we want to support "simple-framebuffer" devices via OF, we currently
   require screen_info...isVGA to be 0 so sysfb.c does nothing. Is that
   guaranteed?
 - Should we try to move the offb.c DT parser to sysfb.c, too, so we can
   convert these devices to simple-framebuffers?
 - How can we integrate vga16fb.c into this? Bind to "platform-framebuffer"?
 - Is there any other generic driver that we might want to check? I haven't
   found more (except uvesafb, which always was separate, anyway).
 - What FB formats are common on x86 that we should add to SIMPLEFB_FORMATS?
   (other than ARGB/XRGB32)
 - Should we move default_vga detection from efifb.c to sysfb_efi.c, too? We
   could make the DMI table __init then.

I tested this (including DRM handover) with vesafb, efifb and simpledrm. It all
worked well without problems. More testing is highly welcome! Also feel free
to pickup individual fixes which don't directly depend on the series (eg. #1,
 #2, #7, #8).

Comments welcome!
Cheers
David

David Herrmann (14):
  fbdev: simplefb: add init through platform_data
  fbdev: simplefb: mark as fw and allocate apertures
  x86: provide platform-devices for boot-framebuffers
  x86: sysfb: move EFI quirks from efifb to sysfb
  fbdev: simplefb: add 32bit RGB formats
  fbdev: vesafb: bind to platform-framebuffer device
  fbdev: efifb: bind to efi-framebuffer
  fbdev: fbcon: select VT_HW_CONSOLE_BINDING
  drm: add SimpleDRM driver
  drm: simpledrm: add fbdev fallback support
  drm: add helpers to kick out firmware drivers
  drm: nouveau: kick out firmware drivers during probe
  drm/i915: use new drm_kick_out_firmware()
  drm/radeon: use new drm_kick_out_firmware()

 MAINTAINERS |   8 +
 arch/x86/Kconfig|  26 ++
 arch/x86/include/asm/sysfb.h|  98 
 arch/x86/kernel/Makefile|   3 +
 arch/x86/kernel/sysfb.c |  74 ++
 arch/x86/kernel/sysfb_efi.c | 214 
 arch/x86/kernel/sysfb_simplefb.c|  95 
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/drm_pci.c   |   1 +
 drivers/gpu/drm/drm_platform.c  |   1 +
 drivers/gpu/drm/drm_stub.c  | 118 +
 drivers/gpu/drm/drm_usb.c   |   1 +
 drivers/gpu/drm/i915/i915_dma.c |   6 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  29 ++-
 drivers/gpu/drm/radeon/radeon_drv.c |  28 ---
 drivers/gpu/drm/radeon/radeon_kms.c |  30 +++
 drivers/gpu/drm/simpledrm/Kconfig   |  29 +++
 drivers/gpu/drm/simpledrm/Makefile