Skip to content

K
Kernel

openeuler / Kernel
大约 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 10月, 2021 2 次提交
    • N
      drm/panel-simple: Add Vivax TPC-9150 panel v6 · 1a84a308
      由 Nikola Pavlica 提交于 
      The model and make of the LCD panel of the Vivax TPC-9150 is unknown,
hence the panel settings that were retrieved with a FEX dump are named
after the device NOT the actual panel.

The LCD in question is a 50 pin MISO TFT LCD panel of the resolution
1024x600 used by the aforementioned device.

Version 2, as Thierry kindly suggested that I fix the order in which the
panel was ordered compared to others.

Version 3, filling in the required info suggested by Sam. Plus some
factual issues that I've corrected myself (tested working)

Version 4, rearranged the display parameters and fix invalid bit format
issue. (Thanks Sam)

Version 5, referred to FEX file instead of manual debugging for
information.

Version 6, same as above. This time, it'll be documented.

A bit of context first: I experimented with this a long time ago whilst
I was first learning how to get Linux running on Allwinner boards, I
didn't have many resources at hand so this was quite slow. Anyways, I
stumbled upon this guide (https://linux-sunxi.org/LCD) and was reading
about how to setup the LCD for my tablet. Since I was able to make a
proper FEX dump, I was also able to read the correct parameters for
myself without relying on leaked documents or part numbers and whatnot.

In the FEX dump the value lcd_frm IS SET to 1, which means, at least
according to the document, that this display is INDEED an 18 bit per
pixel panel. Compiling U-Boot and seeing the tux in proper colors
confirmed this. As per Sam Ravnborg's suggestion, I've changed the panel
to his format "MEDIA_BUS_FMT_RGB666_1X7X3_SPWG", however this does not
lead to any actual change in regards to the functionality since the sunxi
panel driver just ignores this value. However, hopefully this clears up
any errors down the road as either the driver becomes advanced enough to
not ignore this value or that some other piece of software relies on
this value being known. PS: Apologies to the maintainers that have to
endure my misjudgement about how these things work.

As for the concerns about a single patch series, I wasn't sure where to
send the patches as they clearly aren't dt-bindings related and my
previous patches have ended up in drm-misc-fixes anyway. So I'm guessing
I'll be fine if I just post them in the list from last time???
Signed-off-by: NNikola Pavlica <pavlica.nikola@gmail.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211011212731.77763-1-pavlica.nikola@gmail.com
      1a84a308
    • O
      drm: panel-simple: Add support for the Innolux G070Y2-T02 panel · 57a06e90
      由 Oleksij Rempel 提交于 
      Add compatible and timings for the Innolux G070Y2-T02 panel. It is 7"
WVGA (800x480) TFT LCD panel with TTL interface and a backlight unit.
Co-Developed-by: NRobin van der Gracht <robin@protonic.nl>
Signed-off-by: NRobin van der Gracht <robin@protonic.nl>
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211014095202.16716-2-o.rempel@pengutronix.de
      57a06e90
  3. 09 10月, 2021 1 次提交
  5. 21 9月, 2021 3 次提交
  7. 10 9月, 2021 1 次提交
  9. 06 8月, 2021 2 次提交
  11. 05 8月, 2021 1 次提交
  13. 01 8月, 2021 3 次提交
  15. 27 7月, 2021 2 次提交
  17. 26 7月, 2021 1 次提交
  19. 15 7月, 2021 1 次提交
  21. 10 7月, 2021 2 次提交
  23. 09 7月, 2021 4 次提交
  25. 22 6月, 2021 3 次提交
  27. 12 6月, 2021 2 次提交
  29. 25 5月, 2021 1 次提交
  31. 04 5月, 2021 4 次提交
  33. 01 5月, 2021 1 次提交
  35. 21 4月, 2021 1 次提交
    • D
      drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare · 3235b0f2
      由 Douglas Anderson 提交于 
      Unpreparing and re-preparing a panel can be a really heavy
operation. Panels datasheets often specify something on the order of
500ms as the delay you should insert after turning off the panel
before turning it on again. In addition, turning on a panel can have
delays on the order of 100ms - 200ms before the panel will assert HPD
(AKA "panel ready"). The above means that we should avoid turning a
panel off if we're going to turn it on again shortly.

The above becomes a problem when we want to read the EDID of a
panel. The way that ordering works is that userspace wants to read the
EDID of the panel _before_ fully enabling it so that it can set the
initial mode correctly. However, we can't read the EDID until we power
it up. This leads to code that does this dance (like
ps8640_bridge_get_edid()):

1. When userspace requests EDID / the panel modes (through an ioctl),
   we power on the panel just enough to read the EDID and then power
   it off.
2. Userspace then turns the panel on.

There's likely not much time between step #1 and #2 and so we want to
avoid powering the panel off and on again between those two steps.

Let's use Runtime PM to help us. We'll move the existing prepare() and
unprepare() to be runtime resume() and runtime suspend(). Now when we
want to prepare() or unprepare() we just increment or decrement the
refcount. We'll default to a 1 second autosuspend delay which seems
sane given the typical delays we see for panels.

A few notes:
- It seems the existing unprepare() and prepare() are defined to be
  no-ops if called extra times. We'll preserve that behavior but may
  try to remove it in a future patch.
- This is a slight change in the ABI of simple panel. If something was
  absolutely relying on the unprepare() to happen instantly that
  simply won't be the case anymore. I'm not aware of anyone relying on
  that behavior, but if there is someone then we'll need to figure out
  how to enable (or disable) this new delayed behavior selectively.
- In order for this to work we now have a hard dependency on
  "PM". From memory this is a legit thing to assume these days and we
  don't have to find some fallback to keep working if someone wants to
  build their system without "PM".
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416153909.v4.7.I9e8bd33b49c496745bfac58ea9ab418bd3b6f5ce@changeid
      3235b0f2
  37. 12 3月, 2021 5 次提交