- Apr 12, 2019
-
-
Helen Koike authored
Add atomic_async_{check,update} hooks in drm_plane_helper_funcs. These hooks are called when userspace requests asyncronous page flip in the atomic api through the flag DRM_MODE_PAGE_FLIP_ASYNC. Update those hooks in the drivers that implement async functions, except for amdgpu who handles the flag in the normal path, and rockchip who doesn't support async page flip. Signed-off-by:
Helen Koike <helen.koike@collabora.com> Series-changes: 4 - Fix drm_atomic_helper_async_amend_check to return -EOPNOTSUPP then hooks are not provided Commit-notes: Hi, This patch is an attempt to expose the implementation that already exist for true async page flips updates through atomic api when the DRM_MODE_PAGE_FLIP_ASYNC is used. In this commit I'm re-introducing the atomic_async_{check,update} hooks. I know it is a bit weird to remove them first and them re-add them, but I did this in the last commit to avoid any state of inconsistency between commits, as rockchip doesn't support async page flip and they were being used as amend. So I reverted to amend first and then re-introced async again tied to the DRM_MODE_PAGE_FLIP_ASYNC flag (I also think this is easier to read). To use async, it is required to have dev->mode_config.async_page_flip = true; but I see that only amdgpu and vc4 have this, so this patch won't take effect on mdp5. Nouveau and radeon also have this flag, but they don't implement the async hooks yet. Please let me know what you think. Thanks Helen END
-
Helen Koike authored
This flag tells core to jump ahead the queued update if the conditions in drm_atomic_amend_check() are met. That means we are only able to do an amend update if no modeset is pending and update for the same plane is not queued. It uses the already in place infrastructure for amend updates. It is useful for cursor updates over the atomic ioctl. Otherwise in some cases updates may be delayed to the point the user will notice it. Note that for now it's only enabled for cursor planes. DRM_MODE_ATOMIC_AMEND should be passed to the Atomic IOCTL to use this feature. Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> [updated for upstream] Signed-off-by:
Helen Koike <helen.koike@collabora.com> Series-to: David Airlie <airlied@linux.ie> Series-cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, kernel@collabora.com, Gustavo Padovan <gustavo.padovan@collabora.com>, Stéphane Marchesin <marcheu@google.com>, tomasz Figa <tfiga@chromium.org>, Sean Paul <seanpaul@google.com>, alexandros.frantzis@collabora.com, dnicoara@chromium.org, daniels@collabora.com Series-version: 3 Series-changes: 3 - rebase tree - rebase on top of renaming async_update to amend_update - improve documentation - don't fall back to a normal commit if amend is not possible when requested through the atomic api Series-changes: 2 - rebase tree - do not fall back to a non-async update if if there isn't any pending commit to amend Series-changes: 1 - https://patchwork.freedesktop.org/patch/243088/ - Only enable it if userspace requests it. - Only allow async update for cursor type planes. - Rename ASYNC_UPDATE for ATOMIC_AMEND. Cover-letter: async vs amend - UAPI Hi, This patch series is an attempt to clarify some concepts and how things are hooked inside drm. There are two main concepts that are similar but different and are causing some confusion: - Asynchronous update: is the ability change the hw state at any time, not only during vblank. - Amend update: is the ability to perform 1000 commits to be applied as soon as possible without waiting for 1000 vblanks. async updates can be seen as amend, but the opposite is not true. Please see documentation on the commit "drm/atomic: rename async_{update,check} to amend_{update,check}" for a more detailed explanation. To perform an async update, we already have the DRM_MODE_PAGE_FLIP_ASYNC flag in the atomic API and it is already being used by amdgpu in the atomic path. The first two commits clarifies these differences. The last two are RFCs that exposes new async and amend features to userspace. We introduce in this series the flag DRM_MODE_ATOMIC_AMEND to expose the amend feature to userspace. The main reasons to expose this through atomic api is to avoid mixing legacy with modern/atomic API (since their interactions are not well defined) and to be able to explicitly manage the cursor plane. And the last commit hooks the current async implementations with the DRM_MODE_PAGE_FLIP_ASYNC flag. Please, see the message in each commit and the documentation that was added for more details and let me know what you think. Thanks Helen END Commit-notes: Hi, This is the third attempt to introduce the new ATOMIC_AMEND flag for atomic operations, see the commit message for a more detailed description. I am sending this patch in the series as an RFC as I still have things to define/discuss. The main reasons to expose this through atomic api is to avoid mixing legacy with modern/atomic API (since their interactions are not well defined) and to be able to explicitly manage the cursor plane. The way I envision it working is: 1) userspace just use DRM_MODE_PAGE_FLIP_ASYNC if true async is desired. 2) if it fails, then userspace can try DRM_MODE_ATOMIC_AMEND if true async is not required, but a legacy cursor behavior is required 3) if amend is not possible, we can or: A) fallback to a non amend update B) fail C) add another flag to define what it should do. Right now the code does A for legacy cursor and B for atomic api using the DRM_MODE_ATOMIC_AMEND flag. Discussing with some people it seems that failing is better for Xorg, but Ozone (chrome compositor) doesn't expect the amend to fail, but I think it could just retry the same atomic commit without the AMEND flag if it wants to fallback. Alexandros also did a proof-of-concept to use this flag and draw cursors using atomic if possible on ozone (Chrome compositor) [1]. I'm sending this as an RFC for now as I still need to verify the requirements from other compositors and make some tests (and also to justify the s/async/amend renaming). Please, let me know if you detect issues with this. If not, I'll start implementing tests in igt and push the adoption in other compositors. Thanks Helen [1] https://chromium-review.googlesource.com/c/chromium/src/+/1092711 [2] https://gitlab.collabora.com/eballetbo/drm-cursor/commits/async-capability END
-
Helen Koike authored
Asynchronous update is the ability change the hw state at any time, not only during vblank. Amend mode is the ability to perform 1000 commits to be applied as soon as possible without waiting for 1000 vblanks. async updates can be seen as amend, but the opposite is not true. &drm_plane_helper_funcs.atomic_async_{update,check}() was being used by drivers to implement amend and not async. So rename them to amend. Also improve docs explaining the difference. If asynchronous is required, normal page flip can be performed using DRM_MODE_PAGE_FLIP_ASYNC flag. Signed-off-by:
Helen Koike <helen.koike@collabora.com> Series-to: dri-devel@lists.freedesktop.org Series-cc: David Airlie <airlied@linux.ie>, linux-kernel@vger.kernel.org, kernel@collabora.com, Stéphane Marchesin <marcheu@google.com>, Tomasz Figa <tfiga@chromium.org> Series-cc: nicholas.kazlauskas@amd.com, Sean Paul <seanpaul@google.com>, daniel.vetter@ffwll.ch, boris.brezillon@collabora.com, tina.zhang@intel.com Commit-notes: Hello, I would like to officially clarify what async update means by adding it in the docs. Please correct me if I am wrong, but the current async_{update,check} callbacks are being used to do amend (the legacy cursor behavior), i.e. to allow 1000 updates without waiting for 1000 vblanks. So I would like to clarify this in the docs and rename the current callbacks to reflect this behaviour. I also see that for real async updates, the flag DRM_MODE_PAGE_FLIP_ASYNC can be used in a normal sync update (it is already being used by some drivers actually, in the atomic path, not only in the legacy page flip, at least is what I understood from amdgpu_dm_atomic_commit_tail() implementation). Please, let me know if I misunderstood anything. Otherwise renaming and improving the docs would put us all in sync. Thanks! Helen END
-
- Apr 10, 2019
-
-
Helen Koike authored
add a brief description of the flags used in an atomic commit Signed-off-by:
Helen Koike <helen.koike@collabora.com>
-
- Apr 09, 2019
-
-
Qiang Yu authored
To prevent build fail on some platform which does not have it in the include file chain. Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Suggested-by:
Randy Dunlap <rdunlap@infradead.org> Fixes: a1d2a633 ("drm/lima: driver for ARM Mali4xx GPUs") Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190409003617.4470-2-yuq825@gmail.com
-
Qiang Yu authored
Current implementation does not support MMU-less plarforms. Suggested-by:
Randy Dunlap <rdunlap@infradead.org> Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Fixes: a1d2a633 ("drm/lima: driver for ARM Mali4xx GPUs") Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190409003617.4470-1-yuq825@gmail.com
-
Neil Armstrong authored
The Amlogic G12A embeds the same Synopsys DW-HDMI Controller, but with : - a "backport" of the HDR signaling registers from more recent DW-HDMI controllers, this will need a tweak since it's not normally present on this version of the DW-HDMI controller - A direct mapping of TOP and DW-HDMI registers instead of an internal bus accessed using read/write registers - Support for RX-SENSE, but not yet implemented - Support for HDMI 2.1 Dynamic HDR, but not yet implemented - Different registers mapping for the HDMI PHY setup This patchs adds support for these changes while providing exact same support as the previous GXBB, GXL & GXM SoCs. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Tested-by:
Jerome Brunet <jbrunet@baylibre.com> Reviewed-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-12-narmstrong@baylibre.com
-
Neil Armstrong authored
Finally add the Amlogic G12A SoC compatible for the VPU driver. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Tested-by:
Jerome Brunet <jbrunet@baylibre.com> Reviewed-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-11-narmstrong@baylibre.com
-
Neil Armstrong authored
While switching to the Common Clock Framework is still Work In Progress, this patch adds the corresponding G12A HDMI PLL setup to be on-par with the other SoCs support. The G12A has only a single tweak about the high frequency setup, where the HDMI PLL needs a specific setup to handle correctly the 5.94GHz DCO frequency. Apart that, it handls ecorrectly all the other HDMI frequencies and can achieve even better DMT clock frequency precision with the larger fractional dividier width. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Tested-by:
Jerome Brunet <jbrunet@baylibre.com> Reviewed-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-10-narmstrong@baylibre.com
-
Neil Armstrong authored
The Meson G12A SoCs uses the exact same CVBS encoder except a simple CVBS DAC register offset and settings delta. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> [narmstrong: fixed subject typo] Tested-by:
Jerome Brunet <jbrunet@baylibre.com> Reviewed-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-9-narmstrong@baylibre.com
-
Neil Armstrong authored
This patch adds support for the new OSD+VD Plane blending module in the CRTC code by adding the G12A code to manage the blending module and setting the right OSD1 & VD1 plane registers. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Tested-by:
Jerome Brunet <jbrunet@baylibre.com> Reviewed-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-8-narmstrong@baylibre.com
-
Neil Armstrong authored
Amlogic G12A SoC supports the same set of Video Planes, but now are handled by the new OSD plane blender module. This patch uses the same VD1 plane for G12A, using the exact same scaler and VD1 setup registers, except using the new blender register to disable the plane. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> [narmstrong: fix typo in commit log] Tested-by:
Jerome Brunet <jbrunet@baylibre.com> Reviewed-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-7-narmstrong@baylibre.com
-
Neil Armstrong authored
Amlogic G12A SoC supports now up to 3 OSD planes (1 more than the previous SoCs) and a brand new OSD plane blender module. This patch uses the same OSD1 plane for G12A, using the exact same scaler and OSD1 setup registers, except using the new blender register to disable the plane. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> [narmstrong: fixed typo in commit log] Tested-by:
Jerome Brunet <jbrunet@baylibre.com> Reviewed-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-6-narmstrong@baylibre.com
-
Neil Armstrong authored
Amlogic G12A SoC needs a different VIU setup code, handle it. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Tested-by:
Jerome Brunet <jbrunet@baylibre.com> Reviewed-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-5-narmstrong@baylibre.com
-
Neil Armstrong authored
Amlogic G12A needs a different VPP setup code, handle it here. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Tested-by:
Jerome Brunet <jbrunet@baylibre.com> Reviewed-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-4-narmstrong@baylibre.com
-
Neil Armstrong authored
This patch adds the new VPU registers added since the Amlogic GXM SoCs. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Tested-by:
Jerome Brunet <jbrunet@baylibre.com> Reviewed-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-3-narmstrong@baylibre.com
-
Neil Armstrong authored
On Amlogic G12A SoC, the 2,97GHz PLL frequency is not stable enough to provide a correct 297MHz pixel clock, so switch the PLL base frequency with a /2 OD when the 297MHz pixel clock is requested. This solves the issue on G12A and also works fine on GXBB, GXL & GXM. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Tested-by:
Jerome Brunet <jbrunet@baylibre.com> Reviewed-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190325141824.21259-2-narmstrong@baylibre.com
-
Neil Armstrong authored
The Amlogic G12A SoC has a slighly modified DW-HDMI Glue with support for HDMI 2.1 and a different DW-HDMI register access. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190313141030.5958-3-narmstrong@baylibre.com
-
Neil Armstrong authored
The Amlogic G12A VPU is very similar to the Amlogic GXM VPU but with : - an enhanced plane blender, with up to 3 OSD planes - support for AFBC 1.2 decoder (for Bifrost GPU) - support display mode up to 4k60@75Hz Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190313141030.5958-2-narmstrong@baylibre.com
-
Neil Armstrong authored
Add the bindings for the Bifrost family of ARM Mali GPUs. The Bifrost GPU architecture is similar to the Midgard family, but with a different Shader Core & Execution Engine structures. Bindings are based on the Midgard family bindings, but the inner architectural changes makes it a separate family needing separate bindings. The Bifrost GPUs are present in a number of recent SoCs, like the Amlogic G12A Family, and many other vendors. The Amlogic vendor specific compatible is added to handle the specific IP integration differences and dependencies. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Rob Herring <robh@kernel.org> [narmstrong: fixed small typo in compatible description] Link: https://patchwork.freedesktop.org/patch/msgid/20190401080949.14550-1-narmstrong@baylibre.com
-
- Apr 08, 2019
-
-
Randy Dunlap authored
Note that the lima mailing list is moderated. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Qiang Yu <yuq825@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: lima@lists.freedesktop.org Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/9138d8e8-5390-0650-9bc3-050b869e978c@infradead.org Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com>
-
Gerd Hoffmann authored
Time to kill some bad sample code people are copying from ;) This is a complete rewrite of the cirrus driver. The cirrus_mode_set() function is pretty much the only function which is carried over largely unmodified. Everything else is upside down. It is a single monster patch. But given that it does some pretty fundamental changes to the drivers workflow and also reduces the code size by roughly 70% I think it'll still be alot easier to review than a longish baby-step patch series. Changes summary: - Given the small amout of video memory (4 MB) the cirrus device has the rewritten driver doesn't try to manage buffers there. Instead it will blit (memcpy) the active framebuffer to video memory. - All gem objects are stored in main memory and are manged using the new shmem helpers. ttm is out. - It supports RG16, RG24 and XR24 formats. XR24 gets converted to RG24 or RG16 at blit time if needed, to avoid the pitch becoming larger than what the cirrus hardware can handle. - The simple display pipeline is used. - The generic fbdev emulation is used. - It's a atomic driver now. - It runs wayland. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190405095219.9231-6-kraxel@redhat.com
-
Gerd Hoffmann authored
Simliar to drm_fb_xrgb8888_to_rgb565_dstclip() but converts to rgb888 instead of rgb565. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190405095219.9231-5-kraxel@redhat.com
-
Gerd Hoffmann authored
It is a drm_fb_xrgb8888_to_rgb565() variant which checks the clip rectangle for the destination too. Common code between drm_fb_xrgb8888_to_rgb565() and drm_fb_xrgb8888_to_rgb565_dstclip() was factored out into the drm_fb_xrgb8888_to_rgb565_lines() helper function. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190405095219.9231-4-kraxel@redhat.com
-
Gerd Hoffmann authored
It is a drm_fb_memcpy() variant which checks the clip rectangle for the destination too. Common code between drm_fb_memcpy() and drm_fb_memcpy_dstclip() was factored out into the drm_fb_memcpy_lines() helper function. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190405095219.9231-3-kraxel@redhat.com
-
Gerd Hoffmann authored
Also rename them from tinydrm_* to drm_fb_* Pure code motion, no functional change. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190405095219.9231-2-kraxel@redhat.com
-
- Apr 05, 2019
-
-
Sean Paul authored
The file was removed in the below patch and is causing this error: WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno -function Canvas ../drivers/gpu/drm/meson/meson_canvas.c' failed with return code Fixes: 2bf6b5b0 ("drm/meson: exclusively use the canvas provider module") Cc: Maxime Jourdan <mjourdan@baylibre.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190403205652.183496-1-sean@poorly.run
-
- Apr 04, 2019
-
-
Wen Yang authored
The call to of_find_matching_node_and_match returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/gpu/drm/pl111/pl111_versatile.c:333:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function. drivers/gpu/drm/pl111/pl111_versatile.c:340:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function. drivers/gpu/drm/pl111/pl111_versatile.c:346:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function. drivers/gpu/drm/pl111/pl111_versatile.c:354:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function. drivers/gpu/drm/pl111/pl111_versatile.c:395:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function. drivers/gpu/drm/pl111/pl111_versatile.c:402:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 317, but without a corresponding object release within this function. Signed-off-by:
Wen Yang <wen.yang99@zte.com.cn> Cc: Eric Anholt <eric@anholt.net> (supporter:DRM DRIVER FOR ARM PL111 CLCD) Cc: David Airlie <airlied@linux.ie> (maintainer:DRM DRIVERS) Cc: Daniel Vetter <daniel@ffwll.ch> (maintainer:DRM DRIVERS) Cc: dri-devel@lists.freedesktop.org (open list:DRM DRIVERS) Cc: linux-kernel@vger.kernel.org (open list) Signed-off-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1554307455-40361-6-git-send-email-wen.yang99@zte.com.cn
-
kbuild test robot authored
Fixes: c9be804c ("drm/vc4: Use common helpers for debugfs setup by the driver components.") Signed-off-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190403213629.GA31570@lkp-ib03
-
Joe Perches authored
These were missing '\n' terminations, add them. Signed-off-by:
Joe Perches <joe@perches.com> Reviewed-by:
Guido Günther <agx@sigxcpu.org> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/da6f2344396555034cf2476c8338b0ce1c56e0a7.camel@perches.com
-
Joel Stanley authored
This hardware is found inside ASPEED Baseboard Management Controller (BMC) system on chips. It is called the 'SOC Display Controller' or 'GFX'. Signed-off-by:
Joel Stanley <joel@jms.id.au> Acked-by:
Andrew Jeffery <andrew@aj.id.au> Link: https://patchwork.freedesktop.org/patch/msgid/20190403001909.31637-4-joel@jms.id.au
-
Joel Stanley authored
This driver is for the ASPEED BMC SoC's GFX display hardware. This driver runs on the ARM based BMC systems, unlike the ast driver which runs on a host CPU and is is for a PCI graphics device. Signed-off-by:
Joel Stanley <joel@jms.id.au> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190403001909.31637-3-joel@jms.id.au
-
Joel Stanley authored
This describes the ASPEED BMC SoC's display controller. Signed-off-by:
Joel Stanley <joel@jms.id.au> Reviewed-by:
Andrew Jeffery <andrew@aj.id.au> Link: https://patchwork.freedesktop.org/patch/msgid/20190403001909.31637-2-joel@jms.id.au
-
- Apr 03, 2019
-
-
Eric Anholt authored
One might want to use the VC4 display stack without using Mesa. Similar to the debugfs fixes for not having all of the possible display bits enabled, make sure you can't oops in vc4 if v3d isn't enabled. v2: Fix matching against other v3d variants (review by Paul), don't forget to set irq_enabled so that the vblank uapi works v3: Use -ENODEV instead of -EINVAL on Paul's suggestion. Signed-off-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190401183559.3823-2-eric@anholt.net Reviewed-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
Eric Anholt authored
The global list of all debugfs entries for the driver was painful: the list couldn't see into the components' structs, so each component had its own debugs show function to find the component, then find the regset and dump it. The components also had to be careful to check that they were actually registered in vc4 before dereferencing themselves, in case they weren't probed on a particular platform. They routinely failed at that. Instead, we can have the components add their debugfs callbacks to a little list in vc4 to be registered at drm_dev_register() time, which gets vc4_debugfs.c out of the business of knowing the whole list of components. Thanks to this change, dsi0 (if it existed) would register its node. v2: Rebase on hvs_underrun addition. v3: whitespace fixup Signed-off-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190401183559.3823-1-eric@anholt.net Reviewed-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com>
-
Yannick Fertré authored
The panel does not support clock frequency over 30.74 MHz. The clock rate has been reduced to 29.70 MHz & new timings have been computed to get a framerate of 50 fps. Signed-off-by:
Yannick Fertré <yannick.fertre@st.com> Reviewed-by:
Philippe Cornu <philippe.cornu@st.com> Tested-by:
Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/1553155646-13636-1-git-send-email-yannick.fertre@st.com
-
Yannick Fertré authored
Do not print an error message if the regulator framework returns EPROBE_DEFER. Signed-off-by:
Yannick Fertré <yannick.fertre@st.com> Reviewed-by:
Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/1553155535-13555-1-git-send-email-yannick.fertre@st.com
-
Yannick Fertré authored
Do not print an error message if the regulator framework returns EPROBE_DEFER. Signed-off-by:
Yannick Fertré <yannick.fertre@st.com> Reviewed-by:
Philippe Cornu <philippe.cornu@st.com> Tested-by:
Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/1553155484-13460-1-git-send-email-yannick.fertre@st.com
-
Yannick Fertré authored
At the end of initialization, a delay is required by the panel. Without this delay, the panel could received a frame early & generate a crash of panel (black screen). Signed-off-by:
Yannick Fertré <yannick.fertre@st.com> Reviewed-by:
Philippe Cornu <philippe.cornu@st.com> Tested-by:
Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/1553155445-13407-1-git-send-email-yannick.fertre@st.com
-
Guido Günther authored
Support Rocktech jh057n00900 5.5" 720x1440 TFT LCD panel. It is a MIPI DSI video mode panel. The panel seems to use a Sitronix ST7703 look alike (most of the commands look similar to the ST7703's data sheet but use a different number of parameters). The initial version of the DSI init sequence (including sleeps) were provided by the vendor. Sleeps were reduced considerably though to speed up initialization. Signed-off-by:
Guido Günther <agx@sigxcpu.org> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/1a9ce687be283c66dfb26d1dfb52a7bf695090fa.1554114302.git.agx@sigxcpu.org
-