[0/3] RFT: PL111 DRM conversion of nspire

So this is a cold-coded attempt to move the TI nspire over to
using DRM. It is more or less the last user of the old fbdev
driver so it is a noble cause and interesting usecase.

This can be applied on top of a vanilla Torvalds v5.3-rc1
kernel out since sunday.

I do not expect these patches to "just work", I expect them to
need some hacking, so someone who is actually working on the
hardware will need to step in and fix it up.

It does outline the overall idea of how to do this.

I found no defconfig for nspire in the kernel so I used
ARMv4t multi.

Configuring the driver for nspire:

- Disable CONFIG_FB_ARMCLCD
- Enable CONFIG_DRM_PL111, CONFIG_DRM_PANEL_SIMPLE

Hacker notes for nspire:

- I don't know which PrimeCell ID this hardware has, I hope
  the amba_id mask in drivers/gpu/drm/pl111/pl111_drv.c for
  PL111 and PL110 will match it. Please confirm that you get
  a clean probe call, else report what ID this has.

- The 24bit RGB frame buffer may be a bit much for the PL111
  in the TI nspire to handle. Try editing the .fb_bpp in
  drivers/gpu/drm/pl111/pl111_drv.c down to 16 if this is
  the PL111 variant. If it is the PL110 variant, we will get
  16 buts framebuffer anyway.

- I have hard-coded the panels to 1MHz, based on the fact
  that the AHB clock into the CLCD appears to be 48 MHz
  and the hard-coded TIM2 value for the classic means
  "divide by 48" and this seems to want the clock freq
  divided down to 1MHz. Verify this by adding prints
  inside drivers/gpu/drm/pl111/pl111_display.c in the
  function pl111_clk_div_set_rate() to verify that the
  divider gets set to 48 in TIM2_PCD_HI and
  TIM2_PCD_LO. TIM2_PCD_LO bits 0..4 = 10000 and
  TIM2_PCD_HI bits 27..31 = 00001 in that register.

Please test and fix, if you can.

Linus Walleij (3):
  RFT: drm/pl111: Support grayscale
  RTF: drm/panel: simple: Add TI nspire panels
  RFT: ARM: nspire: Move CLCD set-up to device tree

 arch/arm/boot/dts/nspire-classic.dtsi |  19 ++++-
 arch/arm/boot/dts/nspire-cx.dts       |  18 +++-
 arch/arm/boot/dts/nspire.dtsi         |  10 ++-
 arch/arm/mach-nspire/Makefile         |   1 -
 arch/arm/mach-nspire/clcd.c           | 114 --------------------------
 arch/arm/mach-nspire/clcd.h           |  10 ---
 arch/arm/mach-nspire/nspire.c         |  25 ------
 drivers/gpu/drm/panel/panel-simple.c  |  63 ++++++++++++++
 drivers/gpu/drm/pl111/pl111_display.c |  28 ++++++-
 include/linux/amba/clcd-regs.h        |   1 +
 10 files changed, 133 insertions(+), 156 deletions(-)
 delete mode 100644 arch/arm/mach-nspire/clcd.c
 delete mode 100644 arch/arm/mach-nspire/clcd.h

Hi Linus.

On Tue, Jul 23, 2019 at 03:37:52PM +0200, Linus Walleij wrote:
> So this is a cold-coded attempt to move the TI nspire over to
> using DRM. It is more or less the last user of the old fbdev
> driver so it is a noble cause and interesting usecase.

Do we need to support arm,pl11x,tft-r0g0b0-pads before
we can obsolete fbdev stuff?
Just checked and cannot see it in use today.

Looked through the patches.
1 and 3 are:
Acked-by: Sam Ravnborg <sam@ravnborg.org>

As in - the patches looked fine to me - but I do not know the code in detail.
But obviously need some testing feedback before they are applied.

Posted some comments on patch 2.

	Sam

On Tue, Jul 23, 2019 at 8:10 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> On Tue, Jul 23, 2019 at 03:37:52PM +0200, Linus Walleij wrote:
> > So this is a cold-coded attempt to move the TI nspire over to
> > using DRM. It is more or less the last user of the old fbdev
> > driver so it is a noble cause and interesting usecase.
>
> Do we need to support arm,pl11x,tft-r0g0b0-pads before
> we can obsolete fbdev stuff?

No I don't think so, the only in-tree platform that was using it was
the Nomadik and all it did was to switch RGB to BGR and
I already handle that in the driver using the hardware
feature to switch RGB and BGR around instead.

Right now I just check that the pads are there, I might just
remove the check.

However Pawel added this binding and might be able to tell
something about if there are platforms out there that really
needs this. Possibly Liviu knows more.

> Looked through the patches.
> 1 and 3 are:
> Acked-by: Sam Ravnborg <sam@ravnborg.org>

Thanks!

Yours,
Linus Walleij

On Wed, 2019-07-24 at 13:28 +0100, Linus Walleij wrote:
> On Tue, Jul 23, 2019 at 8:10 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> > On Tue, Jul 23, 2019 at 03:37:52PM +0200, Linus Walleij wrote:
> > Do we need to support arm,pl11x,tft-r0g0b0-pads before
> > we can obsolete fbdev stuff?
> 
> No I don't think so, the only in-tree platform that was using it was
> the Nomadik and all it did was to switch RGB to BGR and
> I already handle that in the driver using the hardware
> feature to switch RGB and BGR around instead.
> 
> Right now I just check that the pads are there, I might just
> remove the check.
> 
> However Pawel added this binding and might be able to tell
> something about if there are platforms out there that really
> needs this. Possibly Liviu knows more.

It was only there so the fbdev driver could figure out the output mode.
I take that DRM "pipeline" now takes care of it, so I'd say that the
moment the fbdev driver dies, the binding can go along :-)

Cheers!

Pawel

On Wed, Jul 24, 2019 at 2:47 PM Pawel Moll <pawel.moll@arm.com> wrote:
> On Wed, 2019-07-24 at 13:28 +0100, Linus Walleij wrote:
> > On Tue, Jul 23, 2019 at 8:10 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> > > On Tue, Jul 23, 2019 at 03:37:52PM +0200, Linus Walleij wrote:
> > > Do we need to support arm,pl11x,tft-r0g0b0-pads before
> > > we can obsolete fbdev stuff?
> >
> > No I don't think so, the only in-tree platform that was using it was
> > the Nomadik and all it did was to switch RGB to BGR and
> > I already handle that in the driver using the hardware
> > feature to switch RGB and BGR around instead.
> >
> > Right now I just check that the pads are there, I might just
> > remove the check.
> >
> > However Pawel added this binding and might be able to tell
> > something about if there are platforms out there that really
> > needs this. Possibly Liviu knows more.
>
> It was only there so the fbdev driver could figure out the output mode.
> I take that DRM "pipeline" now takes care of it, so I'd say that the
> moment the fbdev driver dies, the binding can go along :-)

OK I'll get rid of it. :)

Yours,
Linus Walleij