kernel/drivers/gpu/drm/pl111, branch linux-4.17.y

drm/pl111: Use max memory bandwidth for resolution

2018-03-07T22:14:24Z

We were previously selecting 1024x768 and 32BPP as the default set-up for the PL111 consumers. This does not work on elder systems: the device tree bindings support a property "max-memory-bandwidth" in bytes/second that states that if you exceed this the memory bus will saturate. The result is flickering and unstable images. Parse the "max-memory-bandwidth" and respect it when intializing the driver. On the RealView PB11MP, Versatile and Integrator/CP we get a nice console as default with this code. Reviewed-by: Eric Anholt Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20180307215819.15814-1-linus.walleij@linaro.org

drm/pl111: Handle the RealView variant separately

2018-03-07T21:48:08Z

We want to cut down the default bpp to 16 on the RealView so we can have a 1024x768 framebuffer console by default. The memory bandwidth limitations makes this not work with the PL111 default of 32bpp. This builds on top of the earlier patches making the framebuffer default bpp a per-variant variable. Reviewed-by: Eric Anholt Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20180302090948.6399-4-linus.walleij@linaro.org

drm/pl111: Make the default BPP a per-variant variable

2018-03-07T21:46:46Z

The PL110, Integrator and Versatile boards strongly prefer to use 16 BPP even if other modes are supported, both to keep down memory consumption and also to easier find a good match to supported resolutions with consideration taken to the memory bandwidth of the platforms. Reviewed-by: Eric Anholt Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20180302090948.6399-2-linus.walleij@linaro.org Link: https://patchwork.freedesktop.org/patch/msgid/20180307084316.23623-1-linus.walleij@linaro.org Link: https://patchwork.freedesktop.org/patch/msgid/20180307084316.23623-1-linus.walleij@linaro.org

drm/pl111: Remove reverse dependency on DRM_DUMB_VGA_DAC

2018-02-26T05:34:51Z

DRM_DUMB_VGA_DAC is a user-visible symbol. Selecting it can cause unmet direct dependencies such as this (on i386, randconfig): warning: (DRM_PL111) selects DRM_DUMB_VGA_DAC which has unmet direct dependencies (HAS_IOMEM && DRM && DRM_BRIDGE && OF) This is because DRM_DUMB_VGA_DAC depends on OF while DRM_PL111 does not. It does indirectly depend on OF via the ARM and ARM64 dependencies, but since it can also be enabled under COMPILE_TEST, randconfig can find a case where DRM_PL111 is selected without pulling in OF and not meeting the dependency for DRM_DUMB_VGA_DAC. Since select is "heavy handed", DRM_DUMB_VGA_DAC is going to be enabled regardless of the above warning and causes the following build error: ../drivers/gpu/drm/bridge/dumb-vga-dac.c: In function 'dumb_vga_probe': ../drivers/gpu/drm/bridge/dumb-vga-dac.c:207:13: error: 'struct drm_bridge' has no member named 'of_node' vga->bridge.of_node = pdev->dev.of_node; See Documentation/kbuild/kconfig-language.txt, "reverse dependencies". Fixes: 49f81d80ab84 ("drm/pl111: Support handling bridge timings") Reported-by: Randy Dunlap Reviewed-by: Eric Anholt Cc: Laurent Pinchart Cc: Archit Taneja Cc: Eric Anholt Signed-off-by: Thierry Reding Signed-off-by: Archit Taneja Link: https://patchwork.freedesktop.org/patch/msgid/20180220102903.27787-1-thierry.reding@gmail.com

drm/pl111: Do not use deprecated drm_driver.{enable|disable)_vblank

2018-02-22T16:58:59Z

Do not use deprecated drm_driver.{enable|disable)_vblank callbacks, but use drm_simple_kms_helpe's pipe callbacks instead. Signed-off-by: Oleksandr Andrushchenko Cc: Eric Anholt Reviewed-by: Eric Anholt Tested-by: Eric Anholt Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/1518425574-32671-5-git-send-email-andr2000@gmail.com

drm/pl111: Support multiple endpoints on the CLCD

2018-02-07T08:08:51Z

The Versatile PL110 implementations use multiple endpoints: from the PL111 port, the lines are routed through a PLD, and from there forked so the same lines go to a VGA DAC and an external TFT panel connector. This is discrete wireing so there is no way to turn of one output, i.e. this is really two endpoints, not two ports. We model this with multiple endpoints, so we need to loop over the available endpoints, check for panel or bridge on each and accumulate the result before continuing. The code already will give the panel preference over the bridge, if present, so the output will be sent to the panel if both a panel and a bridge is present on two endpoints of the same port. If they all return -EPROBE_DEFER we return -EPROBE_DEFER as well. If just one endpoint is present on the port, the behaviour is the same as before. Reviewed-by: Eric Anholt Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20180206093540.8147-5-linus.walleij@linaro.org

drm/pl111: Support variants with broken VBLANK

2018-02-07T08:08:46Z

The early Integrator CLCD synthesized in the Integrator CP and IM-PD1 FPGAs are broken: their vertical and next base interrupts are not functional. Support these variants by simply disabling the use of the vblank interrupt on these variants. Reviewed-by: Eric Anholt Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20180206093540.8147-4-linus.walleij@linaro.org

drm/pl111: Support variants with broken clock divider

2018-02-07T08:08:40Z

The early Integrator CLCD synthesized in the Integrator CP and IM-PD1 FPGAs are broken: their clock dividers do not work properly. Support disabling the clock divider and drive the clock directly from the parent under these circumstances. Reviewed-by: Eric Anholt Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20180206093540.8147-3-linus.walleij@linaro.org

drm/pl111: Handle the Versatile RGB/BGR565 mode

2018-02-07T08:08:34Z

The ARM Versatile series can do RGB/BGR565 with an external "PLD" (Programmable Logical Device). However the CLCD does not have control bits for this, so it needs to be set into the ordinary 16BPP mode, then the RGB/BGR565 handling of the pixel data is handled by configuring the PLD through the external register. Reviewed-by: Eric Anholt Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20180206093540.8147-2-linus.walleij@linaro.org

drm/pl111: Properly detect the ARM PL110 variants

2018-02-07T08:08:23Z

With a bit of refactoring we can contain the variant data for the strange PL110 versions that is feature-incomplete PL110 for the ARM Integrator/CP and somewhere inbetween PL110 and PL111 for the ARM Versatile AB and Versatile PB. We also accomodate for the custom duct-taped RGB565/BGR565 support in the Versatile variant. Reviewed-by: Eric Anholt Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20180206093540.8147-1-linus.walleij@linaro.org