Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

2022-05-26 Thread Benjamin Herrenschmidt
On Wed, 2022-05-25 at 18:45 +0200, Thomas Zimmermann wrote: > I don't mind adding DRM support for BootX displays, but getting the > necessary test HW with a suitable Linux seems to be laborious. Would > a G4 Powerbook work? Probably not unfortunately... it's going to be tricky. I might sitll

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

2022-05-26 Thread Benjamin Herrenschmidt
On Wed, 2022-05-25 at 18:45 +0200, Thomas Zimmermann wrote: > > > The palette handling is useful when using a real Open Firmware > > implementation which tends to boot in 8-bit mode, so without palette > > things will look ... bad. > > > > It's not necessary when using 16/32 bpp framebuffers

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

2022-05-25 Thread Thomas Zimmermann
Hi Am 21.05.22 um 04:49 schrieb Benjamin Herrenschmidt: On Thu, 2022-05-19 at 09:27 +0200, Thomas Zimmermann wrote: to build without PCI to see what happens. If you bring any of the "heuristic" and palette support code in, you need PCI. I don't see any reason to take it out. Those old

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

2022-05-24 Thread Benjamin Herrenschmidt
On Sun, 2022-05-22 at 21:35 +0200, Thomas Zimmermann wrote: > > Interesting. Did you find some formats that were not supported ? > > We still don't support XRGB1555. If the native buffer uses this format, > we'd have no conversion helper. In this case, we rely on userspace/fbcon > to use the

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

2022-05-22 Thread Thomas Zimmermann
Hi Javier Am 20.05.22 um 08:19 schrieb Javier Martinez Canillas: Hello Thomas, On 5/18/22 20:30, Thomas Zimmermann wrote: +config DRM_OFDRM + tristate "Open Firmware display driver" + depends on DRM && MMU && PPC Shouldn't depend on OF? I mean, is a DRM driver for Open

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

2022-05-20 Thread Benjamin Herrenschmidt
On Thu, 2022-05-19 at 09:27 +0200, Thomas Zimmermann wrote: > to build without PCI to see what happens. If you bring any of the "heuristic" and palette support code in, you need PCI. I don't see any reason to take it out. > Those old Macs use BootX, right? BootX is not supported ATM, as I don't

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

2022-05-20 Thread Benjamin Herrenschmidt
On Thu, 2022-05-19 at 09:11 +0200, Geert Uytterhoeven wrote: > Hi Michal, > > > > On Wed, May 18, 2022 at 8:54 PM Michal Suchánek > wrote: > > > On Wed, May 18, 2022 at 08:30:06PM +0200, Thomas Zimmermann wrote: > > > --- a/drivers/gpu/drm/tiny/Kconfig > > > +++ b/drivers/gpu/drm/tiny/Kconfig

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

2022-05-20 Thread Javier Martinez Canillas
Hello Thomas, On 5/18/22 20:30, Thomas Zimmermann wrote: > > +config DRM_OFDRM > + tristate "Open Firmware display driver" > + depends on DRM && MMU && PPC Shouldn't depend on OF? I mean, is a DRM driver for Open Firmware after all :) I know that the old drivers/video/fbdev/offb.c

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

2022-05-19 Thread Thomas Zimmermann
Hi Am 18.05.22 um 23:11 schrieb Mark Cave-Ayland: On 18/05/2022 19:30, Thomas Zimmermann wrote: Open Firmware provides basic display output via the 'display' node. DT platform code already provides a device that represents the node's framebuffer. Add a DRM driver for the device. The display

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

2022-05-19 Thread Mark Cave-Ayland
On 18/05/2022 19:30, Thomas Zimmermann wrote: Open Firmware provides basic display output via the 'display' node. DT platform code already provides a device that represents the node's framebuffer. Add a DRM driver for the device. The display mode and color format is pre-initialized by the

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

2022-05-19 Thread Thomas Zimmermann
Hi Am 19.05.22 um 09:11 schrieb Geert Uytterhoeven: Hi Michal, On Wed, May 18, 2022 at 8:54 PM Michal Suchánek wrote: On Wed, May 18, 2022 at 08:30:06PM +0200, Thomas Zimmermann wrote: --- a/drivers/gpu/drm/tiny/Kconfig +++ b/drivers/gpu/drm/tiny/Kconfig @@ -51,6 +51,18 @@ config

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

2022-05-19 Thread Geert Uytterhoeven
Hi Michal, On Wed, May 18, 2022 at 8:54 PM Michal Suchánek wrote: > On Wed, May 18, 2022 at 08:30:06PM +0200, Thomas Zimmermann wrote: > > --- a/drivers/gpu/drm/tiny/Kconfig > > +++ b/drivers/gpu/drm/tiny/Kconfig > > @@ -51,6 +51,18 @@ config DRM_GM12U320 > >This is a KMS driver for

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

2022-05-19 Thread Michal Suchánek
On Wed, May 18, 2022 at 10:11:03PM +0100, Mark Cave-Ayland wrote: > On 18/05/2022 19:30, Thomas Zimmermann wrote: > > > Open Firmware provides basic display output via the 'display' node. > > DT platform code already provides a device that represents the node's > > framebuffer. Add a DRM driver

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

2022-05-18 Thread Michal Suchánek
Hello, On Wed, May 18, 2022 at 08:30:06PM +0200, Thomas Zimmermann wrote: > Open Firmware provides basic display output via the 'display' node. > DT platform code already provides a device that represents the node's > framebuffer. Add a DRM driver for the device. The display mode and > color

[PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

2022-05-18 Thread Thomas Zimmermann
Open Firmware provides basic display output via the 'display' node. DT platform code already provides a device that represents the node's framebuffer. Add a DRM driver for the device. The display mode and color format is pre-initialized by the system's firmware. Runtime modesetting via DRM is not