linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Noralf Trønnes" <noralf@tronnes.org>
To: Eric Anholt <eric@anholt.net>,
	dri-devel@lists.freedesktop.org, Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH 0/3] drm: tinydrm driver for adafruit PiTFT 3.5" touchscreen
Date: Thu, 25 Oct 2018 23:52:35 +0200	[thread overview]
Message-ID: <2e548bd7-81f3-5952-b5de-96c26c9f6b19@tronnes.org> (raw)
In-Reply-To: <87h8harnv4.fsf@anholt.net>


Den 25.10.2018 18.29, skrev Eric Anholt:
> Eric Anholt <eric@anholt.net> writes:
>
>> I was going to start working on making the vc4 driver work with
>> tinydrm panels, but it turned out tinydrm didn't have the panel I had
>> previously bought.  So, last night I ported the fbtft staging
>> driver over to DRM.
>>
>> It seems to work (with DT at
>> https://github.com/anholt/linux/commits/drm-misc-next-hx8357d) --
>> fbdev works great including rotated, and so does modetest.  However,
>> when X11 comes up at 16bpp, I get:
>>
>> https://photos.app.goo.gl/8tuhzPFFoDGamEfk8
>>
>> If I have tinydrm set a preferred bpp of 24, X looks great.  Noralf,
>> any ideas?
> Also, with these patches and the format modifier patch I just sent, mesa
> with vc4 is now working with this driver on this branch:
>
> https://gitlab.freedesktop.org/anholt/mesa/commits/kmsro

Ah, nice to see this happening!
Getting hw rendering was one of the advantages I saw DRM could provide
over fbdev on these displays. Little did I know how complicated graphics
was outside fbdev, so I was unable to realise this myself.

The current solution to get hw rendering is to have a userspace process
that continously copies the framebuffer:
https://github.com/tasanakorn/rpi-fbcp

It's used by some of the small DIY handheld game consoles that run
emulators which requires hw rendering.

> Now I wonder how we can improve performance of the SPI updates.

At what SPI speed are you running? The datasheet for most of these
display controllers list the max speed as 10MHz, but almost all of them
can go faster. Some are reported going as high as 70-80MHz. That's for
the pixel data transfer, not the commands. tinydrm/mipi-dbi.c sends
commands at 10MHz and pixels at full speed (mipi_dbi_spi_cmd_max_speed()).
Most panels I have run at 32MHz or 48MHz.

Almost all the time is spent in the SPI transfer, so every hz counts. On
the Pi there's byte swapping because the DMA capable SPI controller can't
do 16-bit (tinydrm_swab16()). If I remember correctly this has negligible
impact on performance.

The SPI controller/driver on the Pi has some restrictions on the speeds
to choose from because the divisor has to be a multiple of two
(bcm2835_spi_transfer_one()).

A full update on a 320x480 RGB565 panel is 262.5kB, so it's a lot to push
over SPI. A 2.8" 320x240 panel is more suitable for video fps, because of
the lower resolution.

I'll look at the patches during the weekend.

Noralf.



  reply	other threads:[~2018-10-25 21:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-24 18:43 Eric Anholt
2018-10-24 18:43 ` [PATCH 1/3] dt-bindings: new binding for Himax HX8357D display panels Eric Anholt
2018-10-25 21:42   ` Rob Herring
2018-10-27 16:10   ` Noralf Trønnes
2018-10-24 18:43 ` [PATCH 2/3] drm: Add an hx8367d tinydrm driver Eric Anholt
2018-10-27 16:12   ` Noralf Trønnes
2018-10-30 22:46     ` Eric Anholt
2018-10-24 18:43 ` [PATCH 3/3] drm/tinydrm: Fix setting of the column/page end addresses Eric Anholt
2018-10-27 16:13   ` Noralf Trønnes
2018-10-25 16:29 ` [PATCH 0/3] drm: tinydrm driver for adafruit PiTFT 3.5" touchscreen Eric Anholt
2018-10-25 21:52   ` Noralf Trønnes [this message]
2018-10-26  2:30     ` Eric Anholt
2018-10-26 19:16       ` Noralf Trønnes
2018-10-26 20:57         ` Noralf Trønnes
2018-10-31 16:27   ` Noralf Trønnes

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=2e548bd7-81f3-5952-b5de-96c26c9f6b19@tronnes.org \
    --to=noralf@tronnes.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eric@anholt.net \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --subject='Re: [PATCH 0/3] drm: tinydrm driver for adafruit PiTFT 3.5" touchscreen' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).