- 19 Oct, 2017 1 commit
-
-
Lucas Stach authored
Only exposes a single mode and not a complete display timing, as the datasheet is rather vague about the minimum/maximum values. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171018172240.8772-1-l.stach@pengutronix.de
-
- 18 Oct, 2017 9 commits
-
-
Frank Binns authored
Signed-off-by:
Frank Binns <frank.binns@imgtec.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1508333423-5394-1-git-send-email-frank.binns@imgtec.com
-
Philipp Zabel authored
The delays between video data and backlight enable and between backlight disable and end of video data are given as >= 160 ms in the datasheet. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Tested-by:
Marco Franchi <marco.franchi@nxp.com> Signed-off-by:
-
Philipp Zabel authored
For LCD interface controllers that support configuring polarity of pixel clock and data enable signal, specify bus flags in the panel descriptor. Signed-off-by:
-
Philipp Zabel authored
The vsync length should be 10 lines, as specified in the data sheet. This gets the actual refresh rate closer to nominal 60 Hz given the 9 MHz pixel clock. Signed-off-by:
-
Daniel Vetter authored
At least when they have vblank support they need to call this, or the vblank core will happily call into their crtc->enable_vblank callback even when the crtc is off. Which leads to a boom when the clocks are off on most hardware (besides the inevitable confusion in the book-keeping). The consistency checks in drm_vblank.c will then make sure that vblank_off/on calls are balanced, and if drivers forget to re-enable it all the commits will stall, so I think we're covered. It'd be nice to be able to place this check outside of commit helpers, but tha's not really possible (due to nonblocking commits and all that). Placing it into atomic helpers should at least cover most drivers. Also note that vblank support is still optional (for virtual drivers, which tend to not have this), check for that. v2: Fixup the handling for vblank_put (Rob). Cc: Rob Clark <robdclark@gmail.com> Tested-by:
Rob Clark <robdclark@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171017152714.6849-1-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Inspired by discussions with Keith and Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Keith Packard <keithp@keithp.com> Acked-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
Bjorn Helgaas authored
The default VGA device is normally set in vga_arbiter_add_pci_device() when we call it for the first enabled device that can be accessed with the legacy VGA resources ([mem 0xa0000-0xbffff], etc.) That default device can be overridden by an EFI device that owns the boot framebuffer. As a fallback, we can also select a VGA device that can't be accessed via legacy VGA resources, or a VGA device that isn't even enabled. Factor out this EFI and fallback selection from vga_arb_device_init() into a separate vga_arb_select_default_device() function. This doesn't change any behavior, but it untangles the "bridge control possible" checking and messages from the default device selection. Tested-by: Zhou Wang <wangzhou1@hisilicon.com> # D05 Hisi Hip07, Hip08 Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by:
Daniel Axtens <dja@axtens.net> Signed-off-by:
-
Bjorn Helgaas authored
Daniel Axtens reported that on the HiSilicon D05 board, the VGA device is behind a bridge that doesn't support PCI_BRIDGE_CTL_VGA, so the VGA arbiter never selects it as the default, which means Xorg auto-detection doesn't work. VGA is a legacy PCI feature: a VGA device can respond to addresses, e.g., [mem 0xa0000-0xbffff], [io 0x3b0-0x3bb], [io 0x3c0-0x3df], etc., that are not configurable by BARs. Consequently, multiple VGA devices can conflict with each other. The VGA arbiter avoids conflicts by ensuring that those legacy resources are only routed to one VGA device at a time. The arbiter identifies the "default VGA" device, i.e., a legacy VGA device that was used by boot firmware. It selects the first device that: - is of PCI_CLASS_DISPLAY_VGA, - has both PCI_COMMAND_IO and PCI_COMMAND_MEMORY enabled, and - has PCI_BRIDGE_CTL_VGA set in all upstream bridges. Some systems don't have such a device. For example, if a host bridge doesn't support I/O space, PCI_COMMAND_IO probably won't be enabled for any devices below it. Or, as on the HiSilicon D05, the VGA device may be behind a bridge that doesn't support PCI_BRIDGE_CTL_VGA, so accesses to the legacy VGA resources will never reach the device. This patch extends the arbiter so that if it doesn't find a device that meets all the above criteria, it selects the first device that: - is of PCI_CLASS_DISPLAY_VGA and - has PCI_COMMAND_IO or PCI_COMMAND_MEMORY enabled If it doesn't find even that, it selects the first device that: - is of class PCI_CLASS_DISPLAY_VGA. Such a device may not be able to use the legacy VGA resources, but most drivers can operate the device without those. Setting it as the default device means its "boot_vga" sysfs file will contain "1", which Xorg (via libpciaccess) uses to help select its default output device. This fixes Xorg auto-detection on some arm64 systems (HiSilicon D05 in particular; see the link below). It also replaces the powerpc fixup_vga() quirk, albeit with slightly different semantics: the quirk selected the first VGA device we found, and overrode that selection with any enabled VGA device we found. If there were several enabled VGA devices, the *last* one we found would become the default. The code here instead selects the *first* enabled VGA device we find, and if none are enabled, the first VGA device we find. Link: http://lkml.kernel.org/r/20170901072744.2409-1-dja@axtens.net Tested-by: Daniel Axtens <dja@axtens.net> # arm64, ppc64-qemu-tcg Tested-by: Zhou Wang <wangzhou1@hisilicon.com> # D05 Hisi Hip07, Hip08 Signed-off-by:
-
Dan Carpenter authored
We free "edid", then use it again on the next line. Fixes: 3b1b9750 ("drm: adv7511/33: add HDMI CEC support") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/20171017204343.zctliubjkq7imudi@mwanda
-
- 17 Oct, 2017 15 commits
-
-
Jonathan Liu authored
The A20 display pipeline has 2 frontends, 2 backends, and 2 TCONs. This patch adds support (or a compatible string in the frontend's case) for these components. The TCONs support directly outputting to CPU/RGB/LVDS LCD panels, or it can output to HDMI via an on-chip HDMI controller, or CVBS/YPbPr/VGA signals via on-chip TV encoders. These additional encoders are not covered in this patch. Signed-off-by:
Jonathan Liu <net147@gmail.com> [wens@csie.org: Expand commit message] Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171017121807.2994-6-wens@csie.org
-
Chen-Yu Tsai authored
The A10 display pipeline has 2 frontends, 2 backends, and 2 TCONs. This patch adds support (or a compatible string in the frontend's case) for these components. The TCONs support directly outputting to CPU/RGB/LVDS LCD panels, or it can output to HDMI via an on-chip HDMI controller, or CVBS/YPbPr/VGA signals via on-chip TV encoders. These additional encoders are not covered in this patch. Signed-off-by:
-
Chen-Yu Tsai authored
The HDMI controller in the A10 SoC is the same as the one currently supported in the A10s. It has slightly different setup parameters. Since these parameters are not thoroughly understood, we add support for this variant by copying these parameters verbatim. Signed-off-by:
-
Jonathan Liu authored
The A10 has two TCONs that are similar to the ones found on other SoCs. Like the A31, TCON0 has a register used to mux the TCON outputs to the downstream encoders. The bit fields are slightly different. Signed-off-by:
-
Chen-Yu Tsai authored
The backend has a mux to select the destination of the data to output to. It can select the TCON or the frontends. On the A20, it includes an option to output to the second TCON. This is not documented in the user manual, but the vendor kernel uses it nevertheless, so the second backend outputs to the second TCON. Although the muxing can be changed on the fly, DRM needs to be able to group a bunch of layers such that they get switched to another crtc together. This is because the display backend does the layer compositing, while the TCON generates the display timings. This constraint is not supported by DRM. Here we simply pair up backends and TCONs with the same ID. Signed-off-by:
-
Maxime Ripard authored
Some channel0 setup has to be done, no matter what the output interface is (RGB, CPU, LVDS). Move that code into a common function in order to avoid duplication. Reviewed-by:
-
Maxime Ripard authored
Just like we did for the TCON enable and disable, for historical reasons we used to rely on the encoders calling the TCON mode_set function, while the CRTC has a callback for that. Let's implement it in order to reduce the boilerplate code. Reviewed-by:
-
Maxime Ripard authored
So far, we've required all the TCON-connected encoders to call the TCON enable and disable functions. This was made this way because in the RGB/LVDS case, the TCON is the CRTC and the encoder. However, in all the other cases (HDMI, TV, DSI, etc.), we have another encoder down the road that needs to be programmed. We also needed to know which channel the encoder is connected to, which is encoder-specific. The CRTC's enable and disable callbacks can work just fine for our use case, and we can get the channel to use just by looking at the type of encoder, since that is fixed. Implement those callbacks, which will remove some of the encoder boilerplate. Reviewed-by:
-
Maxime Ripard authored
The drm_display_mode pointer can be mark const, so let's do it. Reviewed-by:
-
Maxime Ripard authored
The drm_display_mode pointer can be mark const, so let's do it. Reviewed-by:
-
Maxime Ripard authored
Some options were not padded as they should, and the order in the Makefile was chaotic. Fix that. Reviewed-by:
-
Maxime Ripard authored
The commit da82b878 ("drm/sun4i: add components in breadth first traversal order") implemented a breadth first traversal of our device tree nodes graph. However, it was relying on the kernel linked lists, and those are not really safe for addition. Indeed, in a single pipeline stage, your first stage (ie, the mixer or fronted) will be queued, and it will be the final iteration of that list as far as list_for_each_entry_safe is concerned. Then, during that final iteration, we'll queue another element (the TCON or the backend) that list_for_each_entry_safe will not account for, and we will leave the loop without having iterated over all the elements. And since we won't have built our components list properly, the DRM driver will be left non-functional. We can instead use a kfifo to queue and enqueue components in-order, as was the original intention. This also has the benefit of removing any dynamic allocation, making the error handling path simpler too. The only thing we're losing is the ability to tell whether an element has already been queued, but that was only needed to remove spurious logs, and therefore purely cosmetic. This means that this commit effectively reverses e8afb7b6 ("drm/sun4i: don't add components that are already in the queue"). Fixes: da82b878 ("drm/sun4i: add components in breadth first traversal order") Reviewed-by:
-
Chen-Yu Tsai authored
The display backend, as well as other peripherals that have a DRAM clock gate and access DRAM directly, bypassing the system bus, address the DRAM starting from 0x0, while physical addresses the system uses starts from 0x40000000 (or 0x20000000 in A80's case). This issue was witnessed on the Cubietruck, which has 2GB of RAM. Devices with less RAM function normally due to the DRAM address wrapping around. CMA seems to always allocate its buffer at a very high address, close to the end of DRAM. On a 1GB RAM device, the physical address would be something like 0x78000000. The DRAM address 0x78000000 would access the same DRAM region as 0x38000000 on a system, as the DRAM address would only span 0x0 ~ 0x3fffffff. The bit 0x40000000 is non-functional in this case. However on the Cubietruck, the DRAM is 2GB. The physical address is 0x40000000 ~ 0xbfffffff. The buffer would be something like 0xb8000000. But the DRAM address span 0x0 ~ 0x7fffffff, meaning the buffer address wraps around to 0x38000000, which is wrong. The correct DRAM address for it should be 0x78000000. Correct the address configured into the backend layer registers by PHYS_OFFSET to account for this. Fixes: 9026e0d1 ("drm: Add Allwinner A10 Display Engine support") Signed-off-by:
-
Maarten Lankhorst authored
We still want to fail with -EBUSY if a plane or connector is part of a commit, even if it will be assigned to a new commit. This closes a small hole left open where we should return -EBUSY. It's not severe, because wait_for_dependencies and swap_state helpers still block. But it should return -EBUSY and not stall. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 21a01abb ("drm/atomic: Fix freeing connector/plane state too early by tracking commits, v3.") Link: https://patchwork.freedesktop.org/patch/msgid/20171016132928.6498-2-maarten.lankhorst@linux.intel.comReviewed-by:
-
Maarten Lankhorst authored
Commit 669c9215 ("drm/atomic: Make async plane update checks work as intended, v2.") forced planes to always be tracked, but forgot to explicitly get the crtc commit from the new crtc when available. This broke plane commit tracking, and caused kms_atomic_transitions to randomly fail with -EBUSY. Changes since v1: - Prefer new_crtc_state->crtc above old_crtc_state->crtc. Signed-off-by:
-
- 16 Oct, 2017 13 commits
-
-
Robert Tarasov authored
Now DRM/UDL driver retreives all edid data blocks instead of only base one. Previous approch could lead to improper initialization of video mode with certain monitors. Signed-off-by:
Robert Tarasov <tutankhamen@chromium.org> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Robert Tarasov authored
Fixed problem with DisplayLink and DisplayLink certified adapers in drm/udl driver when adapter doesn't want to work if it was initialized with disconnected DVI cable by enabling drm connectot polling and updating current connector's state. Signed-off-by:
-
Haneen Mohammed authored
This patch replace instances of drm_framebuffer_reference/unreference with *_get/put() suffixes, because get/put is shorter and consistent with the kernel use of *_get/put suffixes. This was done with the following Coccinelle script: @r1@ expression e; @@ ( -drm_framebuffer_reference(e); +drm_framebuffer_get(e); | -drm_framebuffer_unreference(e); +drm_framebuffer_put(e); ) Signed-off-by:
Haneen Mohammed <hamohammed.sa@gmail.com> Signed-off-by:
-
Haneen Mohammed authored
This patch replace instances of drm_gem_object_reference/unreference with *_get/put() suffixes, because get/put is shorter and consistent with the kernel use of *_get/put() suffixes. This was done with the following Coccinelle script: @r1@ expression e; @@ ( -drm_gem_object_reference(e); +drm_gem_object_get(e); | -drm_gem_object_unreference(e); +drm_gem_object_put(e); | -drm_gem_object_unreference_unlocked(e); +drm_gem_object_put_unlocked(e); ) Signed-off-by:
-
Boris BREZILLON authored
drm_gem_cma_create() prints an error message when dma_alloc_wc() fails to allocate the amount of memory we requested. This can lead to annoying error messages when CMA is only one possible source of memory for the BO allocation. Turn this error message into a debug one. Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by:
Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20171005112917.15949-1-boris.brezillon@free-electrons.com
-
Jérémy Lefaure authored
Using the ARRAY_SIZE macro improves the readability of the code. Found with Coccinelle with the following semantic patch: @r depends on (org || report)@ type T; T[] E; position p; @@ ( (sizeof(E)@p /sizeof(*E)) | (sizeof(E)@p /sizeof(E[...])) | (sizeof(E)@p /sizeof(T)) ) Reviewed-by:
Jérémy Lefaure <jeremy.lefaure@lse.epita.fr> Signed-off-by:
-
Jérémy Lefaure authored
Using the ARRAY_SIZE macro improves the readability of the code. Also, it is useless to re-invent it. Found with Coccinelle with the following semantic patch: @r depends on (org || report)@ type T; T[] E; position p; @@ ( (sizeof(E)@p /sizeof(*E)) | (sizeof(E)@p /sizeof(E[...])) | (sizeof(E)@p /sizeof(T)) ) Reviewed-by:
-
Chen-Yu Tsai authored
Initially we configured the PAD_CTRL1 register at probe/bind time. However it seems the HDMI controller will modify some of the bits in this register by itself. On the A10 it is particularly annoying as it toggles the output invert bits, which inverts the colors on the display output. The U-boot driver this driver is based on sets this register twice, though it seems it's only needed for actual display output. Hence we move it to the mode_set function. Signed-off-by:
-
Chen-Yu Tsai authored
While debugging inverted color from the HDMI output on the A10, I found that the lowest 3 bits were set. These were cleared on A20 boards that had normal display output. By manually toggling these bits the mapping of the color components to these bits was found. While these are not used anywhere, it would be nice to document them somewhere. Signed-off-by:
-
Chen-Yu Tsai authored
Many of the backend's layer configuration registers have undefined default values. This poses a risk as we use regmap_update_bits in some places, and don't overwrite the whole register. At probe/bind time we explicitly clear all the control registers by writing 0 to them. This patch adds a more detailed explanation on why we're doing this. Signed-off-by:
-
Chen-Yu Tsai authored
Commit 4636ce93 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()") adds a new helper, which covers fetching a drm_framebuffer's GEM object and calculating the buffer address for a given plane. This patch uses this helper to replace our own open coded version of the same function. Signed-off-by:
-
Chen-Yu Tsai authored
The backend has various clocks and reset controls that need to be enabled and deasserted before register access is possible. Move the creation of the regmap to after the clocks and reset controls have been configured where it makes more sense. Signed-off-by:
-
Chen-Yu Tsai authored
Even though the components framework can handle duplicate entries, the extra entries cause a lot more debug messages to be generated, which would be confusing to developers not familiar with our driver and the framework in general. Instead, we can scan the relatively small queue and check if the component to be added is already queued up. Since the display pipelines are symmetrical (not considering the third display pipeline on the A80), and we add components level by level, when we get to the second instance at the same level, any shared downstream components would already be in the queue. Signed-off-by:
-
- 13 Oct, 2017 2 commits
-
-
Eric Anholt authored
The documentation said to use src_w here, and I didn't consider that we actually needed to be using pitch somewhere in our setup. Fixes scanout on my DSI panel when X11 does initial setup with 1920x1080 HDMI and 800x480 DSI both at 0,0 of the same framebuffer. v2: Add some comments requested by Boris Signed-off-by:
-
Eric Anholt authored
We want the adjusted_mode->clock to be the actual clock we're expecting to program, so that consumers see the right values for clock and vrefresh. Signed-off-by:
-
