summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/panel/panel-simple.c
AgeCommit message (Collapse)AuthorFilesLines
2021-05-03drm/panel: panel-simple: Cache the EDID as long as we retain powerDouglas Anderson1-7/+10
It doesn't make sense to go out to the bus and read the EDID over and over again. Let's cache it and throw away the cache when we turn power off from the panel. Autosuspend means that even if there are several calls to read the EDID before we officially turn the power on then we should get good use out of this cache. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.18.If050957eaa85cf45b10bcf61e6f7fa61c9750ebf@changeid
2021-05-03drm/panel: panel-simple: Power the panel when reading the EDIDDouglas Anderson1-1/+7
I don't believe that it ever makes sense to read the EDID when a panel is not powered and the powering on of the panel is the job of prepare(). Let's make sure that this happens before we try to read the EDID. We use the pm_runtime functions directly rather than directly calling the normal prepare() function because the pm_runtime functions are definitely refcounted whereas it's less clear if the prepare() one is. NOTE: I'm not 100% sure how EDID reading was working for folks in the past, but I can only assume that it was failing on the initial attempt and then working only later. This patch, presumably, will fix that. If some panel out there really can read the EDID without powering up and it's a big advantage to preserve the old behavior we can add a per-panel flag. It appears that providing the DDC bus to the panel in the past was somewhat uncommon in any case. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.17.Ibd31b8f7c73255d68c5c9f5b611b4bfaa036f727@changeid
2021-05-03drm/panel: panel-simple: Remove extra call: drm_connector_update_edid_property()Douglas Anderson1-1/+0
As of commit 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector") the drm_get_edid() function calls drm_connector_update_edid_property() for us. There's no reason for us to call it again. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.16.Icb581b0273d95cc33ca38676c61ae6d7d2e75357@changeid
2021-05-03drm/panel: panel-simple: Get rid of hacky HPD chicken-and-egg codeDouglas Anderson1-19/+5
When I added support for the hpd-gpio to simple-panel in commit 48834e6084f1 ("drm/panel-simple: Support hpd-gpios for delaying prepare()"), I added a special case to handle a circular dependency I was running into on the ti-sn65dsi86 bridge chip. On my board the hpd-gpio is actually provided by the bridge chip. That was causing some circular dependency problems that I had to work around by getting the hpd-gpio late. I've now reorganized the ti-sn65dsi86 bridge chip driver to be a collection of sub-drivers. Now the GPIO part can probe separately and that breaks the chain. Let's get rid of the old code to clean things up. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.10.I40eeedc23459d1e3fc96fa6cdad775d88c6e706c@changeid
2021-04-30drm/panel: panel-simple: Add missing pm_runtime_disable() callsDouglas Anderson1-1/+4
In commit 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare") we started using pm_runtime, but my patch neglected to add the proper pm_runtime_disable(). Doh! Add them now. Fixes: 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare") Reported-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.1.I9e6af2529d6c61e5daf86a15a1211121c5223b9a@changeid
2021-04-20drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepareDouglas Anderson1-21/+72
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: Douglas Anderson <dianders@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210416153909.v4.7.I9e8bd33b49c496745bfac58ea9ab418bd3b6f5ce@changeid
2021-03-11drm: panel: simple: Set enable delay for BOE NV110WTM-N61Douglas Anderson1-0/+1
Panel power sequence says timing T8 (time from link idle to turn on the backlight) should be at least 50 ms. This is what the .enable delay in simple-panel is for, so set it. NOTE: this overlaps with the 80 ms .prepare_to_enable delay on purpose. The data sheet says that at least 80 ms needs to pass between HPD going high and turning on the backlight and that at least 50 ms needs to pass between the link idle and the backlight going on. Thus it works like this on the system in front of me: * In bridge chip pre_enable call drm_panel_prepare() * drm_panel_prepare() -> panel_simple_prepare() * Wait for HPD GPIO to go high. * Start counting for 80 ms (store in prepared_time) * In bridge chip enable, train link then call drm_panel_enable() * drm_panel_enable() -> panel_simple_enable() * panel_simple_enable() does hardcoded 50 ms delay then enforces 80 ms from HPD going high (in case the bridge took less than 30 ms to enable / link train). * drm_panel_enable() -> backlight_enable(). Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210222081716.1.I1a45aece5d2ac6a2e73bbec50da2086e43e0862b@changeid
2021-03-11drm/panel-simple: Add N116BCA-EA1Douglas Anderson1-0/+33
This panel is quite similar to the similarly named N116BGE panel (the nominal timings are, in fact identical). However, let's add a new entry because the full range of clocks listed for N116BGE aren't supported for N116BCA-EA1, at least according to the datasheet. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210115144345.v2.5.I3c01f3aab8335cb509da7009d8938c1a27a266dc@changeid
2021-03-11drm/panel-simple: Retry if we timeout waiting for HPDDouglas Anderson1-3/+29
On an Innolux N116BCA panel that I have in front of me, sometimes HPD simply doesn't assert no matter how long you wait for it. As per the very wise advice of The IT Crowd ("Have you tried turning it off and on again?") it appears that power cycling is enough to kick this panel back into a sane state. >From tests on this panel, it appears that leaving it powered off for a while stimulates the problem. Adding a 6 second sleep at the start of panel_simple_prepare_once() makes it happen fairly reliably and, with this delay, I saw up to 3 retries needed sometimes. Without the 6 second sleep, however, the panel came up much more reliably the first time or after only 1 retry. While it's unknown what the problems are with this panel (and probably the hardware should be debugged), adding a few retries to the power on routine doesn't seem insane. Even if this panel's problems are attributed to the fact that it's pre-production and/or can be fixed, retries clearly can help in some cases and really don't hurt. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210115144345.v2.3.I6916959daa7c5c915e889442268d23338de17923@changeid
2021-03-11drm/panel-simple: Don't wait longer for HPD than hpd_absent_delayDouglas Anderson1-1/+7
If a panel has an hpd_absent_delay specified then we know exactly how long the maximum time is before HPD must be asserted. That means we can use it as a timeout for polling the HPD pin instead of using an arbitrary timeout. This is especially useful for dealing with panels that periodically fail to power on and need to be retried. We can detect the problem sooner. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210115144345.v2.2.I183b1817610d7a82fdd3bc852e96d2985df9623f@changeid
2021-03-11drm/panel-simple: Undo enable if HPD never assertsDouglas Anderson1-2/+9
If the HPD signal never asserts in panel_simple_prepare() and we return an error, we should unset the enable GPIO and disable the regulator to make it consistent for the caller. At the moment I have some hardware where HPD sometimes doesn't assert. Obviously that needs to be debugged, but this patch makes it so that if I add a retry that I can make things work. Fixes: 48834e6084f1 ("drm/panel-simple: Support hpd-gpios for delaying prepare()") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210115144345.v2.1.I33fcbd64ab409cfe4f9491bf449f51925a4d3281@changeid
2021-02-10drm: use getter/setter functionsJulia Lawall1-1/+1
Use getter and setter functions, for platform_device structures and a mipi_dsi_device structure. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210209211304.1261740-1-Julia.Lawall@inria.fr
2021-01-18drm/panel: panel-simple: add bus-format and connector-type to Innolux n116bgeHeiko Stuebner1-0/+2
The Innolux n116bge panel has an eDP connector and 3*6 bits bus format. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210109130951.3448435-1-heiko@sntech.de
2020-12-05drm: panel: add flags to BOE NV110WTM-N61Douglas Anderson1-0/+2
I forgot to add these when posting up the support for BOE NV110WTM-N61. Add them now. Fixes: a96ee0f6b58d ("drm: panel: simple: Add BOE NV110WTM-N61") Signed-off-by: Douglas Anderson <dianders@chromium.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201201125554.v2.1.I8a7bfc0966e803ab91001c9e6d01a736950c4981@changeid
2020-12-05drm: panel: Fully transition panel_desc kerneldoc to inline styleDouglas Anderson1-16/+27
In commit 131f909ad55f ("drm: panel: simple: Fixup the struct panel_desc kernel doc") I transitioned the more deeply nested kerneldoc comments into the inline style. Apparently it is desirable to continue the job and move _everything_ in this struct to inline. Let's do it. While doing this, we also add a short summary for the whole struct to fix a warning when we run with extra warnings, AKA: scripts/kernel-doc -v -rst drivers/gpu/drm/panel/panel-simple.c The warning was: drivers/gpu/drm/panel/panel-simple.c:42: warning: missing initial short description on line: * struct panel_desc Suggested-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201201125822.1.I3c4191336014bd57364309439e56f600c94bb12b@changeid
2020-11-30drm: panel: simple: Add BOE NV110WTM-N61Douglas Anderson1-0/+46
Add support for the BOE NV110WTM-N61 panel. The EDID lists two modes (one for 60 Hz refresh rate and one for 40 Hz), so we'll list both of them here. Note that the panel datasheet requires 80 ms between HPD asserting and the backlight power being turned on. We'll use the new timing constraints structure to do this cleanly. This assumes that the backlight will be enabled _after_ the panel enable finishes. This is how it works today and seems a sane assumption. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201109170018.v4.4.I71b2118dfc00fd7b43b02d28e7b890081c2acfa2@changeid
2020-11-30drm: panel: simple: Allow specifying the delay from prepare to enableDouglas Anderson1-6/+38
On the panel I'm looking at, there's an 80 ms minimum time between HPD being asserted by the panel and setting the backlight enable GPIO. While we could just add an 80 ms "enable" delay, this is not ideal. Link training is allowed to happen in parallel with this delay so the fixed 80 ms delay over-delays. We'll support this by logging the time at the end of prepare and then delaying in enable if enough time hasn't passed. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201109170018.v4.3.Ib9ce3c6482f464bf594161581521ced46bbd54ed@changeid
2020-11-30drm: panel: simple: Defer unprepare delay till next prepare to shorten itDouglas Anderson1-3/+24
It is believed that all of the current users of the "unprepare" delay don't actually need to wait the amount of time specified directly in the unprepare phase. The purpose of the delay that's specified is to allow the panel to fully power off so that we don't try to power it back on before it's managed to full power down. Let's use this observation to avoid the fixed delay that we currently have. Instead of delaying, we'll note the current time when the unprepare happens. If someone then tries to prepare the panel later and not enough time has passed, we'll do the delay before starting the prepare phase. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201109170018.v4.2.I06a95d83e7fa1bd919c8edd63dacacb5436e495a@changeid
2020-11-30drm: panel: simple: Fixup the struct panel_desc kernel docDouglas Anderson1-17/+42
When I run: scripts/kernel-doc -rst drivers/gpu/drm/panel/panel-simple.c I see that several of the kernel-doc entries aren't showing up because they don't specify the full path down the hierarchy. Let's fix that and also move to inline kernel docs. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201109170018.v4.1.Icaa86f0a4ca45a9a7184da4bc63386b29792d613@changeid
2020-11-24panel-simple: add Innolux N125HCE-GN1Lukas F. Hartmann1-0/+28
The Innolux N125HCE-GN1 display is used in the MNT Reform 2.0 laptop, attached via eDP to a SN65DSI86 MIPI-DSI to eDP bridge. Signed-off-by: Lukas F. Hartmann <lukas@mntre.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201124172604.981746-1-lukas@mntre.com
2020-11-09drm/panel: simple: Add flags to boe_nv133fhm_n61Stephen Boyd1-0/+1
Reading the EDID of this panel shows that these flags should be set. Set them so that we match what is in the EDID. Cc: Douglas Anderson <dianders@chromium.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Fixes: b0c664cc80e8 ("panel: simple: Add BOE NV133FHM-N61") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201106182333.3080124-1-swboyd@chromium.org
2020-11-08drm/panel: panel-simple: Add connector_type for EDT ETM0700G0DH6 panelBiju Das1-0/+1
Fix the warning message "missing connector type" by adding connector_type for EDT ETM0700G0DH6 panel. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201020094910.4756-1-biju.das.jz@bp.renesas.com
2020-11-08drm: panel: simple: add missing platform_driver_unregister() in ↵Qinglang Miao1-1/+3
panel_simple_init Add the missing platform_driver_unregister() before return from panel_simple_init in the error handling case when failed to register panel_simple_dsi_driver with CONFIG_DRM_MIPI_DSI enabled. Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201031011856.137307-1-miaoqinglang@huawei.com
2020-11-06drm/panel: panel-simple: Fix 'struct panel_desc's headerLee Jones1-0/+2
Struct headers should start with 'struct <name>' Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/panel/panel-simple.c:42: warning: Cannot understand * @modes: Pointer to array of fixed modes appropriate for this panel. If Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201105144517.1826692-12-lee.jones@linaro.org
2020-10-17drm/panel: simple: Add YTC700TLAG-05-201CJagan Teki1-0/+29
Add panel timings for YTC700TLAG-05-201C 7" TFT LCD panel from Yes Optoelectronics Co.,Ltd. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200904180821.302194-3-jagan@amarulasolutions.com
2020-08-30drm: panel: Fix bpc for OrtusTech COM43H4M85ULC panelLaurent Pinchart1-1/+1
The OrtusTech COM43H4M85ULC panel is a 18-bit RGB panel. Commit f098f168e91c ("drm: panel: Fix bus format for OrtusTech COM43H4M85ULC panel") has fixed the bus formats, but forgot to address the bpc value. Set it to 6. Fixes: f098f168e91c ("drm: panel: Fix bus format for OrtusTech COM43H4M85ULC panel") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200824003254.21904-1-laurent.pinchart@ideasonboard.com
2020-08-30drm/panel: simple: Add AM-1280800N3TZQW-T00HJagan Teki1-0/+29
Add Ampire, AM-1280800N3TZQW-T00H 10.1" TFT LCD panel timings. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200829163328.249211-2-jagan@amarulasolutions.com
2020-08-21drm: panel: simple: Add KD116N21-30NV-A010Douglas Anderson1-0/+31
Values come from the vendor and have been tested on hardware. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200821083454.2.Idf25356dff4b36c62704188c3e3d39a2010d6f6a@changeid
2020-08-16drm/panel-simple: Read panel orientationDmitry Osipenko1-0/+11
The panel orientation needs to parsed from a device-tree and assigned to the panel's connector in order to make orientation property available to userspace. That's what this patch does for the panel-simple driver. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200813215609.28643-5-digetx@gmail.com
2020-08-15drm/panel: simple: Add 50Hz mode for sharp,ls020b1dd01dPaul Cercueil1-0/+12
Add a perfect 50.00 Hz frame rate mode to the list of available modes for the Sharp LS020B1DD01D panel. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200811002240.55194-6-paul@crapouillou.net
2020-08-15drm/panel: simple: Tweak timings of sharp,ls020b1dd01d for perfect 60HzPaul Cercueil1-7/+7
Modify the video mode in order to obtain a perfect 60.00 Hz frame rate using a 3 MHz pixel clock. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200811002240.55194-5-paul@crapouillou.net
2020-08-15drm/panel: simple: Convert sharp,ls020b1dd01d from timings to videomodePaul Cercueil1-13/+15
Convert the Sharp LS020B1DD01D panel entry from using a struct display_timing to using a struct drm_display_mode, as display_timing seems to be the old and legacy format. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200811002240.55194-4-paul@crapouillou.net
2020-08-13drm: panel: Fix bus format for OrtusTech COM43H4M85ULC panelLaurent Pinchart1-1/+1
The OrtusTech COM43H4M85ULC panel is a 18-bit RGB panel, set the bus format to MEDIA_BUS_FMT_RGB666_1X18. Fixes: 725c9d40f3fe ("drm/panel: Add support for OrtusTech COM43H4M85ULC panel") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam.ravnborg@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200812220244.24500-1-laurent.pinchart@ideasonboard.com
2020-08-12Merge drm/drm-next into drm-misc-nextThomas Zimmermann1-1/+17
Backmerging drm-next into drm-misc-next for nouveau and panel updates. Resolves a conflict between ttm and nouveau, where struct ttm_mem_res got renamed to struct ttm_resource. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2020-08-11Merge tag 'v5.8' into drm-nextDave Airlie1-1/+15
I need to backmerge 5.8 as I've got a bunch of fixes sitting on an rc7 base that I want to land. Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-08-02drm/panel: simple: Add Chefree CH101OLHLWH-002 panelMarek Vasut1-0/+33
Add support for the Chefree CH101OLHLWH-002 10.1" (1280x800) color TFT LCD panel, connected over LVDS. Timings are taken from the datasheet version P0.5. Signed-off-by: Marek Vasut <marex@denx.de> Cc: dri-devel@lists.freedesktop.org Cc: Rob Herring <robh+dt@kernel.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: devicetree@vger.kernel.org Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200728201242.4336-3-marex@denx.de
2020-08-02drm/panel: remove return value of function drm_panel_addBernard Zhao1-3/+1
The function "int drm_panel_add(struct drm_panel *panel)" always returns 0, this return value is meaningless. Also, there is no need to check return value which calls "drm_panel_add and", error branch code will never run. Signed-off-by: Bernard Zhao <bernard@vivo.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200801120216.8488-1-bernard@vivo.com
2020-07-28drm/panel: simple: Add Powertip PH800480T013 panelMarek Vasut1-0/+28
Add support for Powertip PH800480T013 800x480 parallel LCD, this one is used in the Raspberry Pi 7" touchscreen display unit. Signed-off-by: Marek Vasut <marex@denx.de> To: dri-devel@lists.freedesktop.org Cc: Eric Anholt <eric@anholt.net> Cc: Rob Herring <robh+dt@kernel.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: devicetree@vger.kernel.org Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200728121246.23304-3-marex@denx.de
2020-07-27drm/panel: panel-simple: add default connector_typeSam Ravnborg1-3/+6
All panels shall report a connector type. panel-simple has a lot of panels with no connector_type, and for these fall back to DPI as the default. v2: - Rebased on top of validation of panel description Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200726203324.3722593-3-sam@ravnborg.org
2020-07-27drm/panel: panel-simple: validate panel descriptionSam Ravnborg1-2/+39
Warn if we detect a panel with incomplete/wrong description. This is inspired by a similar patch by Laurent that introduced checks for LVDS panels - this extends the checks to the remaining type of connectors. This is known to warn for some of the existing panels but added despite this as we need help from people using the panels to add the missing info. The checks are not complete but will catch the most common mistakes. The checks at the same time serve as documentation for the minimum required description for a panel. The checks uses dev_warn() as we know this will hit. WARN() was too noisy at the moment for anything else than LVDS. v3: - %d => %u for bpc (Laurent) v2: - Use dev_warn (Laurent) - Check for empty bus_flags Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200726203324.3722593-2-sam@ravnborg.org
2020-07-26drm/panel: add connector type to boe,hv070wsa-100 panelSam Ravnborg1-0/+4
The boe,hv070wsa-100 panel is a LVDS panel. Fix connector type to reflect this. With this change users of this panel do not have to specify the connector type. v4: - Add .bpc = 4 (Laurent) v3: - Drop PIXDATA bus_flag, not relevant v2: - Add .bus_format (Laurent) - Add .bus_flags Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200703192417.372164-2-sam@ravnborg.org
2020-07-26drm: panel: simple: Delay HPD checking on boe_nv133fhm_n61 for 15 msDouglas Anderson1-1/+15
On boe_nv133fhm_n62 (and presumably on boe_nv133fhm_n61) a scope shows a small spike on the HPD line right when you power the panel on. The picture looks something like this: +-------------------------------------- | | | Power ---+ +--- | ++ | +----+| | HPD -----+ +---------------------------+ So right when power is applied there's a little bump in HPD and then there's small spike right before it goes low. The total time of the little bump plus the spike was measured on one panel as being 8 ms long. The total time for the HPD to go high on the same panel was 51.2 ms, though the datasheet only promises it is < 200 ms. When asked about this glitch, BOE indicated that it was expected and persisted until the TCON has been initialized. If this was a real hotpluggable DP panel then this wouldn't matter a whole lot. We'd debounce the HPD signal for a really long time and so the little blip wouldn't hurt. However, this is not a hotpluggable DP panel and the the debouncing logic isn't needed and just shows down the time needed to get the display working. This is why the code in panel_simple_prepare() doesn't do debouncing and just waits for HPD to go high once. Unfortunately if we get unlucky and happen to poll the HPD line right at the spike we can try talking to the panel before it's ready. Let's handle this situation by putting in a 15 ms prepare delay and decreasing the "hpd absent delay" by 15 ms. That means: * If you don't have HPD hooked up at all you've still got the hardcoded 200 ms delay. * If you've got HPD hooked up you will always wait at least 15 ms before checking HPD. The only case where this could be bad is if the panel is sharing a voltage rail with something else in the system and was already turned on long before the panel came up. In such a case we'll be delaying 15 ms for no reason, but it's not a huge delay and I don't see any other good solution to handle that case. Even though the delay was measured as 8 ms, 15 ms was chosen to give a bit of margin. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200716132120.1.I01e738cd469b61fc9b28b3ef1c6541a4f48b11bf@changeid
2020-07-24Merge v5.8-rc6 into drm-nextDave Airlie1-0/+2
I've got a silent conflict + two trees based on fixes to merge. Fixes a silent merge with amdgpu Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-07-16drm/panel-simple: Add 50 Hz mode to the Frida FRD350H54004 panelPaul Cercueil1-13/+27
By changing the pixel clock and the length of the back porch, it is possible to obtain a perfect 50 Hz refresh rate. v2: Rebase on drm-misc-next Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200716125647.10964-2-paul@crapouillou.net
2020-07-16drm/panel-simple: Fix inverted V/H SYNC for Frida FRD350H54004 panelPaul Cercueil1-1/+1
The FRD350H54004 panel was marked as having active-high VSYNC and HSYNC signals, which sorts-of worked, but resulted in the picture fading out under certain circumstances. Fix this issue by marking VSYNC and HSYNC signals active-low. v2: Rebase on drm-misc-next Fixes: 7b6bd8433609 ("drm/panel: simple: Add support for the Frida FRD350H54004 panel") Cc: stable@vger.kernel.org # v5.5 Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200716125647.10964-1-paul@crapouillou.net
2020-07-12drm: panel: simple: Fix bpc for LG LB070WV8 panelLaurent Pinchart1-1/+1
The LG LB070WV8 panel incorrectly reports a 16 bits per component value, while the panel uses 8 bits per component. Fix it. Fixes: dd0150026901 ("drm/panel: simple: Add support for LG LB070WV8 800x480 7" panel") Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200711225317.28476-1-laurent.pinchart+renesas@ideasonboard.com
2020-07-11drm/panel: auo,b116xw03: fix flash backlight when power onJitao Shi1-0/+7
Delay the backlight on to make sure the video stable. Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200705094514.34526-1-jitao.shi@mediatek.com
2020-07-01drm/panel: panel-simple: drop use of legacy drm_bus_flagsSam Ravnborg1-14/+14
Replace all uses of the legacy drm_bus_flags with their relevant _SAMPLE_ variant. This is a 1:1 replacement, no effort was made to validate the actual bus flags for the panels. Note: DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE = DRM_BUS_FLAG_PIXDATA_NEGEDGE DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE = DRM_BUS_FLAG_PIXDATA_POSEDGE Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200630180545.1132217-6-sam@ravnborg.org
2020-06-30drm: panel: simple: Warn in case of incorrect bus format for LVDS panelsLaurent Pinchart1-1/+10
Only the MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, MEDIA_BUS_FMT_RGB888_1X7X4_SPWG and MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA bus formats are valid for LVDS panels. Warn at probe time to catch the common mistake of using an incorrect format, as well as discrepancies between the bus format and the reported bpc. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200629233320.8774-5-laurent.pinchart+renesas@ideasonboard.com
2020-06-30drm: panel: simple: Drop drive/sample bus flags for LVDS panelsLaurent Pinchart1-11/+17
The DRM bus flags reporting on which clock edge the pixel data and sync signals are sampled or driven don't make sense for LVDS panels, as the bus then uses sub-clock timings to send data. Drop those flags and add a warning in the probe function to make sure the mistake won't be repeated. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200629233320.8774-4-laurent.pinchart+renesas@ideasonboard.com
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-01 23:32:13 +0300