Re: [PATCH v2 02/11] dt-bindings: display: rockchip-lvds: Document PX30 PHY

2020-01-04 Thread Rob Herring
On Tue, 24 Dec 2019 15:38:51 +0100, Miquel Raynal wrote:
> PX30 SoCs use a single PHY shared by two display pipelines: MIPI DSI
> and LVDS. In the case of the LVDS IP, document the possibility to fill
> a PHY handle.
> 
> Signed-off-by: Miquel Raynal 
> ---
>  .../devicetree/bindings/display/rockchip/rockchip-lvds.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 1/3] dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings in yaml format

2020-01-04 Thread Rob Herring
On Mon, Dec 23, 2019 at 04:16:40PM +0100, Yuti Amonkar wrote:
> Document the bindings used for the Cadence MHDP DPI/DP bridge in
> yaml format.
> 
> Signed-off-by: Yuti Amonkar 
> ---
>  .../bindings/display/bridge/cdns,mhdp.yaml | 109 
> +
>  1 file changed, 109 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml 
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> new file mode 100644
> index 000..aed6224
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> @@ -0,0 +1,109 @@
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/bridge/cdns,mhdp.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Cadence MHDP bridge
> +
> +maintainers:
> +  - Swapnil Jakhade 
> +  - Yuti Amonkar 
> +
> +properties:
> +  compatible:
> +enum:
> +  - cdns,mhdp8546
> +  - ti,j721e-mhdp8546
> +
> +  clocks:
> +maxItems: 1
> +description:
> +  DP bridge clock, it's used by the IP to know how to translate a number 
> of
> +  clock cycles into a time (which is used to comply with DP standard 
> timings
> +  and delays).
> +
> +  reg:
> +minItems: 1
> +maxItems: 2
> +items:
> +  - description:
> +  Register block of mhdptx apb registers upto PHY mapped 
> area(AUX_CONFIG_P).
> +  The AUX and PMA registers are mapped to associated phy driver.
> +  - description:
> +  Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7 
> SoCs.
> +
> +  reg-names:
> +minItems: 1
> +maxItems: 2
> +items:
> +  - const: mhdptx
> +  - const: j721e-intg
> +
> +  phys:
> +description: see the 
> Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> +
> +  phy-names:
> +const: dpphy
> +
> +  ports:
> +type: object
> +description:
> +  Ports as described in Documentation/devicetree/bindings/graph.txt
> +properties:
> +   '#address-cells':
> + const: 1
> +   '#size-cells':
> + const: 0
> +   port@0:

type: object

> + description:
> +   input port representing the DP bridge input
> +
> +   port@1:

type: object

> + description:
> +   output port representing the DP bridge output
> +required:
> +  - port@0
> +  - port@1
> +  - '#address-cells'
> +  - '#size-cells'
> +
> +required:
> +  - compatible
> +  - clocks
> +  - reg
> +  - phys
> +  - phy-names
> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +mhdp: dp-bridge@f0fb00 {
> +compatible = "cdns,mhdp8546";
> +reg = <0xf0 0xfb00 0x0 0x100>,
> +  <0xf0 0xfc00 0x0 0x200>;
> +clocks = <_clock>;
> +phys = <_phy>;
> +phy-names = "dpphy";
> +
> +ports {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  port@0 {
> + reg = <0>;
> + dp_bridge_input: endpoint {
> +remote-endpoint = <_dpi_output>;
> + };
> +  };
> +
> +  port@1 {
> + reg = <1>;
> + dp_bridge_output: endpoint {
> + remote-endpoint = 
> <_dp_connector_input>;
> + };
> +  };
> +  };
> +};
> +...
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v1 2/2] drm/panel: add support for rm69299 visionox panel driver

2020-01-04 Thread Sam Ravnborg
Hi Harigovindan.

Thanks for re-submitting this driver.
There is several more or less trivial comments below.
Please fix and send a v3.

Thanks,

Sam

On Fri, Nov 29, 2019 at 12:25:45PM +0530, Harigovindan P wrote:
> Add support for Visionox panel driver.
> 
> Changes in v1:
>   -Split out panel driver patch from dsi config changes(Rob Clark).
> -Remove unrelated code(Stephen Boyd).
> -Remove static arrays to make regulator setup open coded
>in probe(Stephen Boyd).
> -Remove pre-assigning variables(Stephen Boyd).
> -Inline panel_add function into probe(Stephen Boyd).
> -Use mipi_dsi_dcs_write directly(Rob Clark).
>   -Remove qcom_rm69299_1080p_panel_magic_cmds array(Rob Clark).
> 
> Signed-off-by: Harigovindan P 
> ---
>  drivers/gpu/drm/panel/Kconfig  |   9 +
>  drivers/gpu/drm/panel/Makefile |   1 +
>  drivers/gpu/drm/panel/panel-visionox-rm69299.c | 412 
> +
>  3 files changed, 422 insertions(+)
>  create mode 100755 drivers/gpu/drm/panel/panel-visionox-rm69299.c
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index f152bc4..c06c403 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -355,4 +355,13 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
>   help
> Say Y here if you want to enable support for Truly NT35597 WQXGA Dual 
> DSI
> Video Mode panel
> +
> +config DRM_PANEL_VISIONOX_RM69299
> + tristate "Visionox RM69299"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + help
> +   Say Y here if you want to enable support for Visionox
> +   RM69299  DSI Video Mode panel.
Drop redundant space.

> +
>  endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index b6cd39f..6f1e4c6 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -38,3 +38,4 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += 
> panel-tpo-td028ttec1.o
>  obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
>  obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
>  obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
> +obj-$(CONFIG_DRM_PANEL_VISIONOX_RM69299) += panel-visionox-rm69299.o
> diff --git a/drivers/gpu/drm/panel/panel-visionox-rm69299.c 
> b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
> new file mode 100755
> index 000..da86714
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
> @@ -0,0 +1,412 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019, The Linux Foundation. All rights reserved.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 

Please use following structure for include files:
#include 

#include 

#include 

#include ""

And within each block sort the include lines alphabetically.

> +
> +struct rm69299_config {
> + unsigned long width_mm;
> + unsigned long height_mm;
> + const char *panel_name;
> + u32 num_on_cmds;
> + const struct drm_display_mode *dm;
> +};
> +
> +struct visionox_rm69299 {
> + struct device *dev;
> + struct drm_panel panel;
> +
> + struct regulator_bulk_data supplies[2];
> +
> + struct gpio_desc *reset_gpio;
> +
> + struct backlight_device *backlight;
backlight is never assigned - drop it.
Your binding does not mention backligth so
this seems to be correct to drop it.

> +
> + struct mipi_dsi_device *dsi;
> + const struct rm69299_config *config;
> + bool prepared;
> + bool enabled;
> +};
> +
> +static inline struct visionox_rm69299 *panel_to_ctx(struct drm_panel *panel)
> +{
> + return container_of(panel, struct visionox_rm69299, panel);
> +}
> +
> +static int visionox_35597_power_on(struct visionox_rm69299 *ctx)
> +{
> + int ret;
> +
> + ret = regulator_set_load(ctx->supplies[0].consumer, 32000);
> + if (ret)
> + return ret;
> +
> + ret = regulator_set_load(ctx->supplies[1].consumer, 13200);
> + if (ret)
> + return ret;
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> + if (ret < 0)
> + return ret;
> +
> + /*
> +  * Reset sequence of visionox panel requires the panel to be
> +  * out of reset for 10ms, followed by being held in reset
> +  * for 10ms and then out again
> +  */
> + gpiod_set_value(ctx->reset_gpio, 1);
> + usleep_range(1, 2);
> + gpiod_set_value(ctx->reset_gpio, 0);
> + usleep_range(1, 2);
> + gpiod_set_value(ctx->reset_gpio, 1);
> + usleep_range(1, 2);
> +
> + return 0;
> +}
> +
> +static int visionox_rm69299_power_off(struct visionox_rm69299 *ctx)
> +{
> + int ret;
> +
> + gpiod_set_value(ctx->reset_gpio, 0);
> +
> + ret = regulator_set_load(ctx->supplies[0].consumer, 

Re: [PATCH v4 2/3] drm: Add support for the LogiCVC display controller

2020-01-04 Thread Sam Ravnborg
Hi Paul.

Good looking driver. Well structured in a number of relevant files.
A few comments in the following.
Some parts I fail to follow - due to my lack of DRM knowledge.
So all in all - only trivial comments.

With these fixed you can add:
Acked-by: Sam Ravnborg 

Sam

On Tue, Dec 03, 2019 at 04:06:05PM +0100, Paul Kocialkowski wrote:
> Introduces a driver for the LogiCVC display controller, a programmable
> logic controller optimized for use in Xilinx Zynq-7000 SoCs and other
> Xilinx FPGAs. The controller is mostly configured at logic synthesis
> time so only a subset of configuration is left for the driver to
> handle.
> 
> The following features are implemented and tested:
> - LVDS 4-bit interface;
> - RGB565 pixel formats;
> - Multiple layers and hardware composition;
> - Layer-wide alpha mode;
> 
> The following features are implemented but untested:
> - Other RGB pixel formats;
> - Layer framebuffer configuration for version 4;
> - Lowest-layer used as background color;
> - Per-pixel alpha mode.
> 
> The following features are not implemented:
> - YUV pixel formats;
> - DVI, LVDS 3-bit, ITU656 and camera link interfaces;
> - External parallel input for layer;
> - Color-keying;
> - LUT-based alpha modes.
> 
> Additional implementation-specific notes:
> - Panels are only enabled after the first page flip to avoid flashing a
>   white screen.
> - Depth used in context of the LogiCVC driver only counts color components
>   to match the definition of the synthesis parameters.
> 
> Support is implemented for both version 3 and 4 of the controller.
> 
> With version 3, framebuffers are stored in a dedicated contiguous
> memory area, with a base address hardcoded for each layer. This requires
> using a dedicated CMA pool registered at the base address and tweaking a
> few offset-related registers to try to use any buffer allocated from
> the pool. This is done on a best-effort basis to have the hardware cope
> with the DRM framebuffer allocation model and there is no guarantee
> that each buffer allocated by GEM CMA can be used for any layer.
> In particular, buffers allocated below the base address for a layer are
> guaranteed not to be configurable for that layer. See the implementation of
> logicvc_layer_buffer_find_setup for specifics.
> 
> Version 4 allows configuring each buffer address directly, which
> guarantees that any buffer can be configured.
> 
> Signed-off-by: Paul Kocialkowski 
> Reviewed-by: Maxime Ripard 
> ---

MAINTAINERS needs an entry.
Will this driver be supported in drm-misc?
If yes, then yoy need to apply for write access (if you do not have it).

> diff --git a/drivers/gpu/drm/logicvc/Kconfig b/drivers/gpu/drm/logicvc/Kconfig
> new file mode 100644
> index ..34dacabbb49a
> --- /dev/null
> +++ b/drivers/gpu/drm/logicvc/Kconfig
> @@ -0,0 +1,8 @@
> +config DRM_LOGICVC
> +   tristate "LogiCVC DRM"
> +   depends on DRM
> +   select DRM_KMS_HELPER
> +   select DRM_KMS_CMA_HELPER
> +   select DRM_GEM_CMA_HELPER
> +   help
> + DRM display driver for the logiCVC programmable logic block from 
> Xylon
The driver, as far as I can tell, required OF.
So a depends on OF seems missing.

> diff --git a/drivers/gpu/drm/logicvc/logicvc_crtc.c 
> b/drivers/gpu/drm/logicvc/logicvc_crtc.c
> new file mode 100644
> index ..2c07f4594c32
> --- /dev/null
> +++ b/drivers/gpu/drm/logicvc/logicvc_crtc.c
> @@ -0,0 +1,271 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Bootlin
> + * Author: Paul Kocialkowski 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 

Empty line between the include blocks.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "logicvc_crtc.h"
> +#include "logicvc_drm.h"
> +#include "logicvc_interface.h"
> +#include "logicvc_layer.h"
> +#include "logicvc_regs.h"

All sorted within each block - good.

> +
> +#define logicvc_crtc(c) \
> + container_of(c, struct logicvc_crtc, drm_crtc)
> +
> +static int logicvc_crtc_atomic_check(struct drm_crtc *drm_crtc,
> +  struct drm_crtc_state *state)
> +{
> + struct drm_display_mode *mode = >adjusted_mode;
> +
> + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> + return -EINVAL;
> +
> + return 0;
> +}
> +

> +
> +void logicvc_crtc_vblank_handler(struct logicvc_drm *logicvc)
> +{
> + struct logicvc_crtc *crtc = logicvc->crtc;
> + struct drm_device *drm = logicvc->drm;
> + unsigned long flags;
> +
> + if (!crtc)
> + return;
> +
> + drm_crtc_handle_vblank(>drm_crtc);
> +
> + spin_lock_irqsave(>event_lock, flags);
> + if (crtc->event) {
> + drm_crtc_send_vblank_event(>drm_crtc, crtc->event);
> + drm_crtc_vblank_put(>drm_crtc);
> + crtc->event = NULL;
> + }
> + spin_unlock_irqrestore(>event_lock, flags);
In the other cases you have spin_* inside the block.
No nbeed to take 

Re: [PATCH 2/2] drm/panel: Add driver for Novatek NT35510-based panels

2020-01-04 Thread Sam Ravnborg
Hi Linus.

Driver looks good.
Rahter complicated - but that what the controller/panel requires.
Lot's of good code comments - very nice.

A few comments in the following.

Sam

> diff --git a/MAINTAINERS b/MAINTAINERS
> index e6db3889cb19..1372b4139ebd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5244,6 +5244,13 @@ F: drivers/gpu/drm/msm/
>  F:   include/uapi/drm/msm_drm.h
>  F:   Documentation/devicetree/bindings/display/msm/
>  
> +DRM DRIVER FOR NOVATEK NT35510 PANELS
> +M:   Linus Walleij 
> +T:   git git://anongit.freedesktop.org/drm/drm-misc
> +S:   Maintained
> +F:   drivers/gpu/drm/panel/panel-novatek-nt35510*
Unless you expect more files named panel-novatek-nt35510*  then use as
specific filename (no wildcard).

> +F:   Documentation/devicetree/bindings/display/panel/novatek-nt35510.yaml
> +
>  DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS
>  M:   Ben Skeggs 
>  L:   dri-devel@lists.freedesktop.org
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 46e3c931e5d9..620a0fd1e816 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -127,6 +127,17 @@ config DRM_PANEL_NEC_NL8048HL11
> panel (found on the Zoom2/3/3630 SDP boards). To compile this driver
> as a module, choose M here.
>  
> +config DRM_PANEL_NOVATEK_NT35510
> + tristate "Novatek NT35510 RGB panel driver"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE

> + select VIDEOMODE_HELPERS
Is this really needed? From a quick look you can drop it.

> + help
> +   Say Y here if you want to enable support for the panels built
> +   around the Novatek NT35510 display controller, such as some
> +   Hydis panels.
> +
>  config DRM_PANEL_NOVATEK_NT39016
>   tristate "Novatek NT39016 RGB/SPI panel"
>   depends on OF && SPI
> diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c 
> b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> new file mode 100644
> index ..b312a8848c25
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> @@ -0,0 +1,1126 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Novatek NT35510 panel driver
> + * Copyright (C) 2019 Linus Walleij 
> + * Based on code by Robert Teather (C) 2012 Samsung
> + *
> + * This display driver (and I refer to the physical component NT35510,
> + * not this Linux kernel software driver) can handle:
> + * 480x864, 480x854, 480x800, 480x720 and 480x640 pixel displays.
> + * It has 480x840x24bit SRAM embedded for storing a frame.
> + * When powered on the display is by default in 480x800 mode.
> + *
> + * The actual panels using this component have different names, but
> + * the code needed to set up and configure the panel will be similar,
> + * so they should all use the NT35510 driver with appropriate configuration
> + * per-panel, e.g. for physical size.
> + *
> + * This driver is for the DSI interface to panels using the NT35510.
> + *
> + * The NT35510 can also use an RGB (DPI) interface combined with an

> + * I2C or SPI interface for setting up the NT35510. If this is needed I
> + * this panel driver should be refactored to also support that use
An extra "I" sneaked in here.

> + * case.
> + */
You are using nice kernel-doc style comments.
Consider to wire this into Documentation/gpu/ somewhere.

> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +

Please structure includes like this:

#include 

#include 

#include 

#include ""

Within each block sort the include fiels alphabetically.

I think you can drop of_videomode.h and videomode.h.


> +#define MCS_CMD_MAUCCTR  0xF0 /* Manufacturer command enable */
> +#define MCS_CMD_READ_ID1 0xDA
> +#define MCS_CMD_READ_ID2 0xDB
> +#define MCS_CMD_READ_ID3 0xDC
> +#define MCS_CMD_MTP_READ_SETTING 0xF8 /* Uncertain about name */
> +#define MCS_CMD_MTP_READ_PARAM 0xFF /* Uncertain about name */

> + *
> + * Gamma correction arrays are 10bit numbers, two consecutive bytes
> + * makes out one point on the gamma correction curve. The points are
> + * not linearly placed along the X axis, we get points 0, 1, 3, 5
> + * 7, 11, 15, 23, 31, 47, 63, 95, 127, 128, 160, 192, 208, 224, 232,
> + * 240, 244, 248, 250, 252, 254, 255. The voltages tuples form
> + * V0, V1, V3 ... V255, with 0x being the lowest voltage and
> + * 0x03FF being the highest voltage.
> + *
> + * Each value must be strictly lower than the next value forming a
  ^ higher?
> + * rising curve like this:
> + *
> + * ^
> + * |V255
> + * | V254
> + * | 
> + * |V5
> + * |   V3
> + * | V1
> + * | V0
> + * +--->
> + *
> + 

Re: [PATCH 1/2] drm/panel: Add DT bindings for Novatek NT35510-based panels

2020-01-04 Thread Sam Ravnborg
Hi Linus

On Sat, Jan 04, 2020 at 06:27:17PM +0100, Sam Ravnborg wrote:
> Hi Linus.
> 
> On Wed, Dec 25, 2019 at 12:56:09PM +0100, Linus Walleij wrote:
> > This adds device tree bindings for the Novatek NT35510-based
> > family of panels. Since several such panels are in existence
> > we define bindings common for all, and define the compatible
> > string for one certain panel (Hydis HVA40WV1).
Reading this once more make me think that the right way to do this
is to have two compatible's.

enum
- novatek,nt35510
- hydis,hva40wv1

So there shall be a match for both.

Then we have explicit documented that this is the combination of
a specific controller and a specific panel.

Sam

> > 
> > As other panels are discovered and investigated, we can add
> > more compatibles to the binding.
> > 
> > Cc: Stephan Gerhold 
> > Cc: devicet...@vger.kernel.org
> > Signed-off-by: Linus Walleij 
> > ---
> >  .../display/panel/novatek-nt35510.yaml| 53 +++
> >  1 file changed, 53 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/panel/novatek-nt35510.yaml
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/novatek-nt35510.yaml 
> > b/Documentation/devicetree/bindings/display/panel/novatek-nt35510.yaml
> > new file mode 100644
> > index ..a4a6b5adf15b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/novatek-nt35510.yaml
> > @@ -0,0 +1,53 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/novatek-nt35510.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Novatek NT35510-based display panels
> > +
> > +maintainers:
> > +  - Linus Walleij 
> > +
> > +allOf:
> > +  - $ref: panel-common.yaml#
> > +
> > +properties:
> > +  compatible:
> > +const: hydis,hva40wv1
> compatible fail to match filename - which is common practice.
> And hydis is not a known vendor-prefix.
> 
> 
> > +description: This indicates the panel manufacturer of the panel
> > +  that is in turn using the NT35510 panel driver. The compatible
> > +  string determines how the NT35510 panel driver shall be configured
> > +  to work with the indicated panel.
> The description is just a general description of what compatible is used
> for.
> Please drop it as it does not provide anything specific for the panel.
> 
>   Sam
> 
> > +  reg: true
> > +  reset-gpios: true
> > +  vdd-supply:
> > + description: regulator that supplies the vdd voltage
> > +  vddi-supply:
> > + description: regulator that supplies the vddi voltage
> > +  backlight: true
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +#include 
> > +
> > +dsi@a0351000 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +panel {
> > +compatible = "hydis,hva40wv1";
> > +reg = <0>;
> > +vdd-supply = <_ldo_aux4_reg>;
> > +vddi-supply = <_ldo_aux6_reg>;
> > +reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> > +backlight = <_bl>;
> > +};
> > +};
> > +
> > +...
> > -- 
> > 2.21.0
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] drm/panel: Add DT bindings for Novatek NT35510-based panels

2020-01-04 Thread Sam Ravnborg
Hi Linus.

On Wed, Dec 25, 2019 at 12:56:09PM +0100, Linus Walleij wrote:
> This adds device tree bindings for the Novatek NT35510-based
> family of panels. Since several such panels are in existence
> we define bindings common for all, and define the compatible
> string for one certain panel (Hydis HVA40WV1).
> 
> As other panels are discovered and investigated, we can add
> more compatibles to the binding.
> 
> Cc: Stephan Gerhold 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij 
> ---
>  .../display/panel/novatek-nt35510.yaml| 53 +++
>  1 file changed, 53 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/novatek-nt35510.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/novatek-nt35510.yaml 
> b/Documentation/devicetree/bindings/display/panel/novatek-nt35510.yaml
> new file mode 100644
> index ..a4a6b5adf15b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/novatek-nt35510.yaml
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/novatek-nt35510.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Novatek NT35510-based display panels
> +
> +maintainers:
> +  - Linus Walleij 
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +  compatible:
> +const: hydis,hva40wv1
compatible fail to match filename - which is common practice.
And hydis is not a known vendor-prefix.


> +description: This indicates the panel manufacturer of the panel
> +  that is in turn using the NT35510 panel driver. The compatible
> +  string determines how the NT35510 panel driver shall be configured
> +  to work with the indicated panel.
The description is just a general description of what compatible is used
for.
Please drop it as it does not provide anything specific for the panel.

Sam

> +  reg: true
> +  reset-gpios: true
> +  vdd-supply:
> + description: regulator that supplies the vdd voltage
> +  vddi-supply:
> + description: regulator that supplies the vddi voltage
> +  backlight: true
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +
> +dsi@a0351000 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +panel {
> +compatible = "hydis,hva40wv1";
> +reg = <0>;
> +vdd-supply = <_ldo_aux4_reg>;
> +vddi-supply = <_ldo_aux6_reg>;
> +reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> +backlight = <_bl>;
> +};
> +};
> +
> +...
> -- 
> 2.21.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 5/6] drm: atmel-hlcdc: prefer a lower pixel-clock than requested

2020-01-04 Thread Sam Ravnborg
Hi Claudiu

On Thu, Jan 02, 2020 at 10:08:48AM +0100, Sam Ravnborg wrote:
> On Wed, Dec 18, 2019 at 02:28:28PM +0200, Claudiu Beznea wrote:
> > From: Peter Rosin 
> > 
> > The intention was to only select a higher pixel-clock rate than the
> > requested, if a slight overclocking would result in a rate significantly
> > closer to the requested rate than if the conservative lower pixel-clock
> > rate is selected. The fixed patch has the logic the other way around and
> > actually prefers the higher frequency. Fix that.
> > 
> > Fixes: f6f7ad323461 ("drm/atmel-hlcdc: allow selecting a higher pixel-clock 
> > than requested")
> The id is wrong here - the right one is: 
> 9946a3a9dbedaaacef8b7e94f6ac144f1daaf1de
> The wrong id above was used before - so I think it is a copy'n'paste
> thing.
> 
> Hint: try "dim fixes 9946a3a9dbedaaacef8b7e94f6ac144f1daaf1de"
> 
> If I get a quick response from Lee I can fix it up while applying.
> 
>   Sam
> 
> > Reported-by: Claudiu Beznea 
> > Tested-by: Claudiu Beznea 
> > Signed-off-by: Peter Rosin 

One other detail.
The patch has passed through your hands, so you have to add your s-o-b
to document this.
The chain of s-o-b shall document the path the patch has taken towards
the kernel.

In this case:
Peter => Claudiu => Sam => Applied.

Please resend or reply where you say OK that I add your s-o-b.

PS. And happy new year!

Sam


> > ---
> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
> > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> > index 721fa88bf71d..10985134ce0b 100644
> > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> > @@ -121,8 +121,8 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct 
> > drm_crtc *c)
> > int div_low = prate / mode_rate;
> >  
> > if (div_low >= 2 &&
> > -   ((prate / div_low - mode_rate) <
> > -10 * (mode_rate - prate / div)))
> > +   (10 * (prate / div_low - mode_rate) <
> > +(mode_rate - prate / div)))
> > /*
> >  * At least 10 times better when using a higher
> >  * frequency than requested, instead of a lower.
> > -- 
> > 2.7.4
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 3/3] drm/panel: add panel driver for Leadtek LTK500HD1829

2020-01-04 Thread Sam Ravnborg
On Tue, Dec 24, 2019 at 12:26:41PM +0100, Heiko Stuebner wrote:
> From: Heiko Stuebner 
> 
> The LTK500HD1829 is 5.5" DSI display.
> 
> changes in v4:
> - drop error message if backlight not found, no other panel
>   does that and if needed it should live in drm_panel_of_backlight
> changes in v3:
> - drop one more overlooked panel->drm access
> 
> Signed-off-by: Heiko Stuebner 

Applied to drm-misc-next.
Updated to fix a few trivial checkpatch warnings when I applied.

Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 2/3] dt-bindings: display: panel: Add binding document for Leadtek LTK500HD1829

2020-01-04 Thread Sam Ravnborg
On Tue, Dec 24, 2019 at 12:26:40PM +0100, Heiko Stuebner wrote:
> From: Heiko Stuebner 
> 
> The LTK500HD1829 is a 5.0" 720x1280 DSI display.
> 
> changes in v2:
> - fix id (Maxime)
> - drop port (Maxime)
> 
> Signed-off-by: Heiko Stuebner 
> Acked-by: Maxime Ripard 

Applied to drm-misc-next.
Updated example to pass dt_bindings_check while applying.
(Missing #address,size-celss properties)

Sam


> ---
>  .../display/panel/leadtek,ltk500hd1829.yaml   | 47 +++
>  1 file changed, 47 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml 
> b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
> new file mode 100644
> index ..123869533a5e
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
> @@ -0,0 +1,47 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/leadtek,ltk500hd1829.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Leadtek LTK500HD1829 5.0in 720x1280 DSI panel
> +
> +maintainers:
> +  - Heiko Stuebner 
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +  compatible:
> +const: leadtek,ltk500hd1829
> +  reg: true
> +  backlight: true
> +  reset-gpios: true
> +  iovcc-supply:
> + description: regulator that supplies the iovcc voltage
> +  vcc-supply:
> + description: regulator that supplies the vcc voltage
> +
> +required:
> +  - compatible
> +  - reg
> +  - backlight
> +  - iovcc-supply
> +  - vcc-supply
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +dsi@ff45 {
> +panel@0 {
> +compatible = "leadtek,ltk500hd1829";
> +reg = <0>;
> +backlight = <>;
> +iovcc-supply = <_1v8>;
> +vcc-supply = <_2v8>;
> +};
> +};
> +
> +...
> -- 
> 2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 1/3] dt-bindings: Add vendor prefix for Leadtek Technology

2020-01-04 Thread Sam Ravnborg
On Tue, Dec 24, 2019 at 12:26:39PM +0100, Heiko Stuebner wrote:
> From: Heiko Stuebner 
> 
> Shenzhen Leadtek Technology Co., Ltd. produces for example display
> and touch panels.
> 
> Signed-off-by: Heiko Stuebner 

Applied to drm-misc-next.

Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 1/3] dt-bindings: Add vendor prefix for Xinpeng Technology

2020-01-04 Thread Sam Ravnborg
Hi Heiko.

Thanks for your work on this.

On Tue, Dec 24, 2019 at 12:29:05PM +0100, Heiko Stuebner wrote:
> From: Heiko Stuebner 
> 
> Shenzhen Xinpeng Technology Co., Ltd produces for example display panels.
> 
> Signed-off-by: Heiko Stuebner 
> Acked-by: Sam Ravnborg 
> Acked-by: Rob Herring 

This and the following two patches are now applied to drm-misc-next.

Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 14/20] drm/exynos: Rename Exynos to lowercase

2020-01-04 Thread Krzysztof Kozlowski
Fix up inconsistent usage of upper and lowercase letters in "Exynos"
name.

"EXYNOS" is not an abbreviation but a regular trademarked name.
Therefore it should be written with lowercase letters starting with
capital letter.

The lowercase "Exynos" name is promoted by its manufacturer Samsung
Electronics Co., Ltd., in advertisement materials and on website.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/exynos/Kconfig | 6 +++---
 include/uapi/drm/exynos_drm.h  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 6f7d3b3b3628..6417f374b923 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -1,13 +1,13 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config DRM_EXYNOS
-   tristate "DRM Support for Samsung SoC EXYNOS Series"
+   tristate "DRM Support for Samsung SoC Exynos Series"
depends on OF && DRM && (ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS || 
ARCH_MULTIPLATFORM || COMPILE_TEST)
depends on MMU
select DRM_KMS_HELPER
select VIDEOMODE_HELPERS
select SND_SOC_HDMI_CODEC if SND_SOC
help
- Choose this option if you have a Samsung SoC EXYNOS chipset.
+ Choose this option if you have a Samsung SoC Exynos chipset.
  If M is selected the module will be called exynosdrm.
 
 if DRM_EXYNOS
@@ -62,7 +62,7 @@ config DRM_EXYNOS_DSI
  This enables support for Exynos MIPI-DSI device.
 
 config DRM_EXYNOS_DP
-   bool "EXYNOS specific extensions for Analogix DP driver"
+   bool "Exynos specific extensions for Analogix DP driver"
depends on DRM_EXYNOS_FIMD || DRM_EXYNOS7_DECON
select DRM_ANALOGIX_DP
default DRM_EXYNOS
diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
index 45c6582b3df3..a51aa1c618c1 100644
--- a/include/uapi/drm/exynos_drm.h
+++ b/include/uapi/drm/exynos_drm.h
@@ -394,7 +394,7 @@ struct drm_exynos_ioctl_ipp_commit {
 #define DRM_IOCTL_EXYNOS_IPP_COMMITDRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_IPP_COMMIT, struct drm_exynos_ioctl_ipp_commit)
 
-/* EXYNOS specific events */
+/* Exynos specific events */
 #define DRM_EXYNOS_G2D_EVENT   0x8000
 #define DRM_EXYNOS_IPP_EVENT   0x8002
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 15/20] video: exynos: Rename Exynos to lowercase

2020-01-04 Thread Krzysztof Kozlowski
Fix up inconsistent usage of upper and lowercase letters in "Exynos"
name.

"EXYNOS" is not an abbreviation but a regular trademarked name.
Therefore it should be written with lowercase letters starting with
capital letter.

The lowercase "Exynos" name is promoted by its manufacturer Samsung
Electronics Co., Ltd., in advertisement materials and on website.

Signed-off-by: Krzysztof Kozlowski 
---
 include/video/samsung_fimd.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index b6571c3cfa31..c4a93ce1de48 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -10,7 +10,7 @@
  *
  * This is the register set for the fimd and new style framebuffer interface
  * found from the S3C2443 onwards into the S3C2416, S3C2450, the
- * S3C64XX series such as the S3C6400 and S3C6410, and EXYNOS series.
+ * S3C64XX series such as the S3C6400 and S3C6410, and Exynos series.
 */
 
 /* VIDCON0 */
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 00/20] Rename Samsung and Exynos to lowercase

2020-01-04 Thread Krzysztof Kozlowski
Hi all,

Changes since v1:
=
1. Split bindings to separate patch (1/20). Bindings were previously in
media (7/20) and phy (10/20).

Description
===

The "Samsung" and "Exynos" names are written inconsistently in Linux
kernel sources. Sometimes all uppercase (as SAMSUNG), sometimes
lowercase with capital letter (as Samsung).

This patchset tries to unify this towards "Samsung" and "Exynos"
versions because:

1. "SAMSUNG" and "EXYNOS" are not abbreviations but regular trademarked
names.  Therefore they should be written with lowercase letters starting
with capital letter.

2. The lowercase "Exynos" name is promoted by its manufacturer Samsung
   Electronics Co., Ltd., in advertisement materials and on website [1].

3. Although advertisement materials usually use uppercase "SAMSUNG", the
   lowercase version is used in all legal aspects (e.g. on Wikipedia [2]
   and in privacy/legal statements on Samsung site [3]).

Patches are independent of each other so I expect they will go through
each maintainer's tree. Optionally let me know - I'll take it then
through samsung-soc tree.

[1] https://www.samsung.com/semiconductor/minisite/exynos/
[2] https://en.wikipedia.org/wiki/Samsung
[3] https://www.samsung.com/semiconductor/privacy-global/

Best regards,
Krzysztof

Cc: Mauro Carvalho Chehab 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: Kamil Debski 
Cc: Sylwester Nawrocki 
Cc: Kishon Vijay Abraham I 
Cc: Jonathan Corbet 
Cc: Russell King 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: Herbert Xu 
Cc: "David S. Miller" 
Cc: MyungJoo Ham 
Cc: Kyungmin Park 
Cc: Chanwoo Choi 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Lee Jones 
Cc: Byungho An 
Cc: Girish K S 
Cc: Vipul Pandya 
Cc: Jingoo Han 
Cc: Lorenzo Pieralisi 
Cc: Andrew Murray 
Cc: Bjorn Helgaas 
Cc: Maxime Ripard 
Cc: Chen-Yu Tsai 
Cc: Sangbeom Kim 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Zhang Rui 
Cc: Amit Kucheria 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Felipe Balbi 
Cc: Alan Stern 
Cc: Arnd Bergmann 
Cc: linux-me...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-cry...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: net...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-ser...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org

Krzysztof Kozlowski (20):
  dt-bindings: Rename Exynos to lowercase
  arm64: dts: exynos: Rename Samsung and Exynos to lowercase
  ARM: dts: samsung: Rename Samsung and Exynos to lowercase
  ARM: samsung: Rename Samsung and Exynos to lowercase
  soc: samsung: Rename Samsung and Exynos to lowercase
  thermal: exynos: Rename Samsung and Exynos to lowercase
  media: samsung: Rename Samsung and Exynos to lowercase
  usb: exynos: Rename Samsung and Exynos to lowercase
  memory: samsung: Rename Exynos to lowercase
  phy: exynos: Rename Exynos to lowercase
  clocksource/drivers/exynos_mct: Rename Exynos to lowercase
  crypto: exynos-rng - Rename Exynos to lowercase
  devfreq: exynos: Rename Exynos to lowercase
  drm/exynos: Rename Exynos to lowercase
  video: exynos: Rename Exynos to lowercase
  pci: exynos: Rename Exynos to lowercase
  serial: samsung: Rename Exynos to lowercase
  mfd: samsung: Rename Samsung to lowercase
  net: ethernet: sxgbe: Rename Samsung to lowercase
  regulator: samsung: Rename Samsung to lowercase

 .../bindings/media/exynos-jpeg-codec.txt  |  2 +-
 .../devicetree/bindings/media/exynos5-gsc.txt |  2 +-
 .../bindings/media/samsung-fimc.txt   |  2 +-
 .../bindings/media/samsung-mipi-csis.txt  |  2 +-
 .../devicetree/bindings/phy/samsung-phy.txt   |  6 ++--
 .../driver-api/thermal/exynos_thermal.rst |  6 ++--
 Documentation/media/v4l-drivers/fimc.rst  |  6 ++--
 Documentation/media/v4l-drivers/tuners.rst|  2 +-
 arch/arm/boot/dts/exynos5250-arndale.dts  |  2 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts |  4 +--
 arch/arm/boot/dts/exynos5250.dtsi |  8 ++---
 arch/arm/boot/dts/exynos5260-xyref5260.dts|  4 +--
 arch/arm/boot/dts/exynos5260.dtsi |  2 +-
 arch/arm/boot/dts/exynos5410-smdk5410.dts |  4 +--
 arch/arm/boot/dts/exynos5410.dtsi |  6 ++--
 arch/arm/boot/dts/exynos5420-arndale-octa.dts |  2 +-
 arch/arm/boot/dts/exynos5420-cpus.dtsi|  2 +-
 arch/arm/boot/dts/exynos5420-smdk5420.dts |  4 +--
 arch/arm/boot/dts/exynos5420.dtsi |  6 ++--
 arch/arm/boot/dts/exynos5422-cpus.dtsi|  2 +-
 arch/arm/boot/dts/exynos5800.dtsi |  6 ++--
 arch/arm/boot/dts/s3c2416-smdk2416.dts|  2 +-
 arch/arm/boot/dts/s3c6410-smdk6410.dts|  4 +--
 arch/arm/mach-exynos/Kconfig  | 36 +--
 

Re: [PATCH v3 3/3] drm/panel: simple: Add Satoz SAT050AT40H12R2 panel support

2020-01-04 Thread Sam Ravnborg
Hi Miquel.

On Tue, Dec 24, 2019 at 03:19:05PM +0100, Miquel Raynal wrote:
> Add support for the Satoz SAT050AT40H12R2 RGB panel.
> 
> Signed-off-by: Miquel Raynal 
> ---
> 
> Changes since v2:
> * Dropped two uneeded lines which would fail the build.
> 
> Changes since v1:
> * Switched to display_timing's instead of display_mode.
> 
>  drivers/gpu/drm/panel/panel-simple.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index ac6f6b5d200d..cc1595c5633a 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2559,6 +2559,29 @@ static const struct panel_desc samsung_ltn140at29_301 
> = {
>   },
>  };
>  
> +static const struct display_timing satoz_sat050at40h12r2_timing = {
> + .pixelclock = { 3330, 3330, 5000 },
> + .hactive = {800, 800, 800},
> + .hfront_porch = {16, 210, 354},
> + .hback_porch = {46, 46, 46},
> + .hsync_len = {1, 1, 40},
> + .vactive = {480, 480, 480},
> + .vfront_porch = {7, 22, 147},
> + .vback_porch = {23, 23, 23},
> + .vsync_len = {1, 1, 20},
> +};
> +
> +static const struct panel_desc satoz_sat050at40h12r2 = {
> + .timings = _sat050at40h12r2_timing,
> + .num_timings = 1,
> + .bpc = 8,
> + .size = {
> + .width = 108,
> + .height = 65,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> +};
Please add connector_type as well.
This is mandatory for all new panels.

Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 0/6] dt-bindings: display: Update few panel bindings with YAML

2020-01-04 Thread Sam Ravnborg
Hi Jagan.
On Wed, Jan 01, 2020 at 04:54:38PM +0530, Jagan Teki wrote:
> These panel bindings are owned by me, so updated all of them into
> YAML DT schema.
> 
> Any inputs?
Thanks for doing the conversion.

dt_binding_check was not happy:
Documentation/devicetree/bindings/display/panel/rocktech,rk070er9427.example.dt.yaml:
 panel: 'backlight', 'port' do not match any of the regexes: 'pinctrl-[0-9]+'
  DTC 
Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.example.dt.yaml
  CHECK   
Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.example.dt.yaml
Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.example.dt.yaml:
 panel: 'backlight', 'port' do not match any of the regexes: 'pinctrl-[0-9]+'
Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.example.dt.yaml:
 panel: compatible: Additional items are not allowed ('simple-panel' was 
unexpected)
Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.example.dt.yaml:
 panel: compatible: ['friendlyarm,hd702e', 'simple-panel'] is too long
  DTC 
Documentation/devicetree/bindings/display/panel/sitronix,st7701.example.dt.yaml
Error: 
Documentation/devicetree/bindings/display/panel/sitronix,st7701.example.dts:22.42-43
 syntax error
FATAL ERROR: Unable to parse input tree

Please fix and check the bindings using dt_binding_check before
resubmit.

I had to install libyaml-dev (as least I recall this was the name)
before dt_binding_check worked OK for me.

Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 00/19] Rename Samsung and Exynos to lowercase

2020-01-04 Thread Krzysztof Kozlowski
On Fri, Jan 03, 2020 at 02:25:41PM -0700, Rob Herring wrote:
> On Fri, Jan 3, 2020 at 10:11 AM Krzysztof Kozlowski  wrote:
> >
> > Hi all,
> >
> > The "Samsung" and "Exynos" names are written inconsistently in Linux
> > kernel sources. Sometimes all uppercase (as SAMSUNG), sometimes
> > lowercase with capital letter (as Samsung).
> >
> > This patchset tries to unify this towards "Samsung" and "Exynos"
> > versions because:
> >
> > 1. "SAMSUNG" and "EXYNOS" are not abbreviations but regular trademarked
> > names.  Therefore they should be written with lowercase letters starting
> > with capital letter.
> >
> > 2. The lowercase "Exynos" name is promoted by its manufacturer Samsung
> >Electronics Co., Ltd., in advertisement materials and on website [1].
> >
> > 3. Although advertisement materials usually use uppercase "SAMSUNG", the
> >lowercase version is used in all legal aspects (e.g. on Wikipedia [2]
> >and in privacy/legal statements on Samsung site [3]).
> >
> > Patches are independent of each other so I expect they will go through
> > each maintainer's tree. Optionally let me know - I'll take it then
> > through samsung-soc tree.
> >
> > [1] https://www.samsung.com/semiconductor/minisite/exynos/
> > [2] https://en.wikipedia.org/wiki/Samsung
> > [3] https://www.samsung.com/semiconductor/privacy-global/
> >
> > Best regards,
> > Krzysztof
> >
> > Cc: Mauro Carvalho Chehab 
> > Cc: Rob Herring 
> > Cc: Mark Rutland 
> > Cc: Kukjin Kim 
> > Cc: Krzysztof Kozlowski 
> > Cc: Kamil Debski 
> > Cc: Sylwester Nawrocki 
> > Cc: Kishon Vijay Abraham I 
> > Cc: Jonathan Corbet 
> > Cc: Russell King 
> > Cc: Bartlomiej Zolnierkiewicz 
> > Cc: Daniel Lezcano 
> > Cc: Thomas Gleixner 
> > Cc: Herbert Xu 
> > Cc: "David S. Miller" 
> > Cc: MyungJoo Ham 
> > Cc: Kyungmin Park 
> > Cc: Chanwoo Choi 
> > Cc: Inki Dae 
> > Cc: Joonyoung Shim 
> > Cc: Seung-Woo Kim 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: Lee Jones 
> > Cc: Byungho An 
> > Cc: Girish K S 
> > Cc: Vipul Pandya 
> > Cc: Jingoo Han 
> > Cc: Lorenzo Pieralisi 
> > Cc: Andrew Murray 
> > Cc: Bjorn Helgaas 
> > Cc: Maxime Ripard 
> > Cc: Chen-Yu Tsai 
> > Cc: Sangbeom Kim 
> > Cc: Liam Girdwood 
> > Cc: Mark Brown 
> > Cc: Zhang Rui 
> > Cc: Amit Kucheria 
> > Cc: Greg Kroah-Hartman 
> > Cc: Jiri Slaby 
> > Cc: Felipe Balbi 
> > Cc: Alan Stern 
> > Cc: Arnd Bergmann 
> > Cc: linux-me...@vger.kernel.org
> > Cc: devicet...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org
> > Cc: linux-...@vger.kernel.org
> > Cc: linux...@vger.kernel.org
> > Cc: linux-cry...@vger.kernel.org
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: net...@vger.kernel.org
> > Cc: linux-...@vger.kernel.org
> > Cc: linux-ser...@vger.kernel.org
> > Cc: linux-...@vger.kernel.org
> > Cc: linux-fb...@vger.kernel.org
> >
> > Krzysztof Kozlowski (19):
> >   arm64: dts: exynos: Rename Samsung and Exynos to lowercase
> >   ARM: dts: samsung: Rename Samsung and Exynos to lowercase
> >   ARM: samsung: Rename Samsung and Exynos to lowercase
> >   soc: samsung: Rename Samsung and Exynos to lowercase
> >   thermal: exynos: Rename Samsung and Exynos to lowercase
> >   media: samsung: Rename Samsung and Exynos to lowercase
> >   usb: exynos: Rename Samsung and Exynos to lowercase
> >   memory: samsung: Rename Exynos to lowercase
> >   phy: exynos: Rename Exynos to lowercase
> >   clocksource/drivers/exynos_mct: Rename Exynos to lowercase
> >   crypto: exynos-rng - Rename Exynos to lowercase
> >   devfreq: exynos: Rename Exynos to lowercase
> >   drm/exynos: Rename Exynos to lowercase
> >   video: exynos: Rename Exynos to lowercase
> >   pci: exynos: Rename Exynos to lowercase
> >   serial: samsung: Rename Exynos to lowercase
> >   mfd: samsung: Rename Samsung to lowercase
> >   net: ethernet: sxgbe: Rename Samsung to lowercase
> >   regulator: samsung: Rename Samsung to lowercase
> >
> >  .../bindings/media/exynos-jpeg-codec.txt  |  2 +-
> >  .../devicetree/bindings/media/exynos5-gsc.txt |  2 +-
> >  .../bindings/media/samsung-fimc.txt   |  2 +-
> >  .../bindings/media/samsung-mipi-csis.txt  |  2 +-
> >  .../devicetree/bindings/phy/samsung-phy.txt   |  6 ++--
> 
> Please split bindings to a separate patch.

Sure, let me resend.

Best regards,
Krzysztof

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 2/9] drm/sun4i: tcon: Add TCON LCD support for R40

2020-01-04 Thread Maxime Ripard
Hi,

On Thu, Jan 02, 2020 at 10:04:40PM +0530, Jagan Teki wrote:
> On Thu, Jan 2, 2020 at 9:17 PM Maxime Ripard  wrote:
> >
> > On Thu, Jan 02, 2020 at 09:10:31PM +0530, Jagan Teki wrote:
> > > On Thu, Jan 2, 2020 at 4:24 PM Maxime Ripard  wrote:
> > > >
> > > > On Tue, Dec 31, 2019 at 06:35:21PM +0530, Jagan Teki wrote:
> > > > > TCON LCD0, LCD1 in allwinner R40, are used for managing
> > > > > LCD interfaces like RGB, LVDS and DSI.
> > > > >
> > > > > Like TCON TV0, TV1 these LCD0, LCD1 are also managed via
> > > > > tcon top.
> > > > >
> > > > > Add support for it, in tcon driver.
> > > > >
> > > > > Signed-off-by: Jagan Teki 
> > > > > ---
> > > > > Changes for v3:
> > > > > - none
> > > > >
> > > > >  drivers/gpu/drm/sun4i/sun4i_tcon.c | 8 
> > > > >  1 file changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > index fad72799b8df..69611d38c844 100644
> > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > @@ -1470,6 +1470,13 @@ static const struct sun4i_tcon_quirks 
> > > > > sun8i_a83t_tv_quirks = {
> > > > >   .has_channel_1  = true,
> > > > >  };
> > > > >
> > > > > +static const struct sun4i_tcon_quirks sun8i_r40_lcd_quirks = {
> > > > > + .supports_lvds  = true,
> > > > > + .has_channel_0  = true,
> > > > > + /* TODO Need to support TCON output muxing via GPIO pins */
> > > > > + .set_mux= sun8i_r40_tcon_tv_set_mux,
> > > >
> > > > What is this muking about? And why is it a TODO?
> > >
> > > Muxing similar like how TCON TOP handle TV0, TV1 I have reused the
> > > same so-that it would configure de port selection via
> > > sun8i_tcon_top_de_config
> > >
> > > TCON output muxing have gpio with GPIOD and GPIOH bits, which select
> > > which of LCD or TV TCON outputs to the LCD function pins. I have
> > > marked these has TODO for further support as mentioned by Chen-Yu in
> > > v1[1].
> >
> > It should be in the commit log.
>
> Make sense.
>
> > What's the plan to support that when needed? And that means that the
> > LCD and TV outputs are mutually exclusive? We should at the very least
> > check that both aren't enabled at the same time.
>
> Yes, LCD or TV within the outselect seems to be mutually exclusive.
> Like LCD0 or TV0 can output to GPIOD incase of TV0_OUTSEL and LCD1 or
> TV1 can output to GPIOH incase of TV1_OUTSEL. I think checking them
> before configuring TCON_TOP_PORT_SEL_REG would make sense, let me know
> if you have any suggestions?

Making sure in atomic_check that TV and LCD are not used at the same
time, and then in encoders mode_set / enable mux the pins to our
encoders would be my first guess.

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v7] drm/panel: Add driver for Sony ACX424AKP panel

2020-01-04 Thread Sam Ravnborg
Hi Linus.

On Sat, Jan 04, 2020 at 01:10:26AM +0100, Linus Walleij wrote:
> The Sony ACX424AKP is a command/videomode DSI panel for
> mobile devices. It is used on the ST-Ericsson HREF520
> reference design. We support video mode by default, but
> it is possible to switch the panel into command mode
> by using the bool property "dsi-command-mode".
> 
> Cc: Stephan Gerhold 
> Signed-off-by: Linus Walleij 

Driver looks good but there are a few issues yet to address:
It does not build on top of drm-misc-next due to changes to the
drm_panel code.

And then there is a few checkpatch warnings that needs to be looked at:
-:25: WARNING:CONFIG_DESCRIPTION: please write a paragraph that describes the 
config symbol fully
#25: FILE: drivers/gpu/drm/panel/Kconfig:330:
+config DRM_PANEL_SONY_ACX424AKP

-:52: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#52:
new file mode 100644

-:307: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see 
Documentation/timers/timers-howto.rst
#307: FILE: drivers/gpu/drm/panel/panel-sony-acx424akp.c:251:
+   udelay(20);

-:310: WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see 
Documentation/timers/timers-howto.rst
#310: FILE: drivers/gpu/drm/panel/panel-sony-acx424akp.c:254:
+   msleep(11);

-:319: WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see 
Documentation/timers/timers-howto.rst
#319: FILE: drivers/gpu/drm/panel/panel-sony-acx424akp.c:263:
+   msleep(11);

-:543: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#543: FILE: drivers/gpu/drm/panel/panel-sony-acx424akp.c:487:
+   acx->reset_gpio = devm_gpiod_get_optional(dev, "reset",
+GPIOD_OUT_HIGH);


The build errors was easy to fix - but please have a look at the other
warnings.

I did the following changes locally to fix the build.
But I did not try to look into the delay stuff.

Sam

diff --git a/drivers/gpu/drm/panel/panel-sony-acx424akp.c 
b/drivers/gpu/drm/panel/panel-sony-acx424akp.c
index fe33f97cd812..38c83f5b16d5 100644
--- a/drivers/gpu/drm/panel/panel-sony-acx424akp.c
+++ b/drivers/gpu/drm/panel/panel-sony-acx424akp.c
@@ -407,17 +407,17 @@ static int acx424akp_disable(struct drm_panel *panel)
return 0;
 }
 
-static int acx424akp_get_modes(struct drm_panel *panel)
+static int acx424akp_get_modes(struct drm_panel *panel,
+  struct drm_connector *connector)
 {
struct acx424akp *acx = panel_to_acx424akp(panel);
-   struct drm_connector *connector = panel->connector;
struct drm_display_mode *mode;
 
if (acx->video_mode)
-   mode = drm_mode_duplicate(panel->drm,
+   mode = drm_mode_duplicate(connector->dev,
  _acx424akp_vid_mode);
else
-   mode = drm_mode_duplicate(panel->drm,
+   mode = drm_mode_duplicate(connector->dev,
  _acx424akp_cmd_mode);
if (!mode) {
DRM_ERROR("bad mode or failed to add mode\n");
@@ -484,7 +484,7 @@ static int acx424akp_probe(struct mipi_dsi_device *dsi)
 
/* This asserts RESET by default */
acx->reset_gpio = devm_gpiod_get_optional(dev, "reset",
-GPIOD_OUT_HIGH);
+ GPIOD_OUT_HIGH);
if (IS_ERR(acx->reset_gpio)) {
ret = PTR_ERR(acx->reset_gpio);
if (ret != -EPROBE_DEFER)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 0/3] Fixes coccicheck warnings

2020-01-04 Thread Ma Feng



Ma Feng (3):
  drm/i915: use true,false for bool variable in i915_debugfs.c
  drm/i915/dp: use true,false for bool variable in intel_dp.c
  drm/i915: use true,false for bool variable in intel_crt.c

 drivers/gpu/drm/i915/display/intel_crt.c | 6 +++---
 drivers/gpu/drm/i915/display/intel_dp.c  | 4 ++--
 drivers/gpu/drm/i915/i915_debugfs.c  | 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

--
2.6.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 2/2] drm/sun4i: Use CRTC size instead of PRIMARY plane size as mixer frame.

2020-01-04 Thread Roman Stratiienko
чт, 2 янв. 2020 г., 09:42 Jernej Škrabec :
>
> Hi!
>
> Dne sreda, 01. januar 2020 ob 21:47:50 CET je
> roman.stratiie...@globallogic.com napisal(a):
> > From: Roman Stratiienko 
> >
> > According to DRM documentation the only difference between PRIMARY
> > and OVERLAY plane is that each CRTC must have PRIMARY plane and
> > OVERLAY are optional.
> >
> > Allow PRIMARY plane to have dimension different from full-screen.
> >
> > Fixes: 5bb5f5dafa1a ("drm/sun4i: Reorganize UI layer code in DE2")
> > Signed-off-by: Roman Stratiienko 
>
> This looks great now.
>
> Reviewed-by: Jernej Skrabec 
>
> What happened to other patches in the series? It would be nice to have a cover
> letter for such cases, where you can explain reasons for dropped patches.
>
>
>
>

Thanks and sorry for any mistakes in procedure, I'll try to follow the
rules in the future..
Some of commits requires more time to test/deliver than others.  So
splitting it into smaller chunks helps to deliver them earlier.

>
> Best regards,
> Jernej
>
> > ---
> > v2:
> > - Split commit in 2 parts
> > - Add Fixes line to the commit message
> >
> > v3:
> > - Address review comments of v2 + removed 3 local varibles
> > - Change 'Fixes' line
> >
> > Since I've put more changes from my side, please review/sign again.
> > ---
> >  drivers/gpu/drm/sun4i/sun8i_mixer.c| 28 
> >  drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 30 --
> >  2 files changed, 28 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > b/drivers/gpu/drm/sun4i/sun8i_mixer.c index 8b803eb903b8..658cf442c121
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > @@ -257,6 +257,33 @@ const struct de2_fmt_info *sun8i_mixer_format_info(u32
> > format) return NULL;
> >  }
> >
> > +static void sun8i_mode_set(struct sunxi_engine *engine,
> > +struct drm_display_mode *mode)
> > +{
> > + u32 size = SUN8I_MIXER_SIZE(mode->crtc_hdisplay, mode-
> >crtc_vdisplay);
> > + struct sun8i_mixer *mixer = engine_to_sun8i_mixer(engine);
> > + u32 bld_base = sun8i_blender_base(mixer);
> > + u32 val;
> > +
> > + DRM_DEBUG_DRIVER("Mode change, updating global size W: %u H: %u\n",
> > +  mode->crtc_hdisplay, mode->crtc_vdisplay);
> > + regmap_write(mixer->engine.regs, SUN8I_MIXER_GLOBAL_SIZE, size);
> > + regmap_write(mixer->engine.regs,
> > +  SUN8I_MIXER_BLEND_OUTSIZE(bld_base), size);
> > +
> > + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> > + val = SUN8I_MIXER_BLEND_OUTCTL_INTERLACED;
> > + else
> > + val = 0;
> > +
> > + regmap_update_bits(mixer->engine.regs,
> > +SUN8I_MIXER_BLEND_OUTCTL(bld_base),
> > +SUN8I_MIXER_BLEND_OUTCTL_INTERLACED,
> > +val);
> > + DRM_DEBUG_DRIVER("Switching display mixer interlaced mode %s\n",
> > +  val ? "on" : "off");
> > +}
> > +
> >  static void sun8i_mixer_commit(struct sunxi_engine *engine)
> >  {
> >   DRM_DEBUG_DRIVER("Committing changes\n");
> > @@ -310,6 +337,7 @@ static struct drm_plane **sun8i_layers_init(struct
> > drm_device *drm, static const struct sunxi_engine_ops sun8i_engine_ops = {
> >   .commit = sun8i_mixer_commit,
> >   .layers_init= sun8i_layers_init,
> > + .mode_set   = sun8i_mode_set,
> >  };
> >
> >  static struct regmap_config sun8i_mixer_regmap_config = {
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> > b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c index 4343ea9f8cf8..f01ac55191f1
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> > @@ -120,36 +120,6 @@ static int sun8i_ui_layer_update_coord(struct
> > sun8i_mixer *mixer, int channel, insize = SUN8I_MIXER_SIZE(src_w, src_h);
> >   outsize = SUN8I_MIXER_SIZE(dst_w, dst_h);
> >
> > - if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
> > - bool interlaced = false;
> > - u32 val;
> > -
> > - DRM_DEBUG_DRIVER("Primary layer, updating global size
> W: %u H: %u\n",
> > -  dst_w, dst_h);
> > - regmap_write(mixer->engine.regs,
> > -  SUN8I_MIXER_GLOBAL_SIZE,
> > -  outsize);
> > - regmap_write(mixer->engine.regs,
> > -  SUN8I_MIXER_BLEND_OUTSIZE(bld_base),
> outsize);
> > -
> > - if (state->crtc)
> > - interlaced = state->crtc->state-
> >adjusted_mode.flags
> > - & DRM_MODE_FLAG_INTERLACE;
> > -
> > - if (interlaced)
> > - val = SUN8I_MIXER_BLEND_OUTCTL_INTERLACED;
> > - else
> > - val = 0;
> > -
> > - regmap_update_bits(mixer->engine.regs,
> > -
> 

Re: [PATCH v3 2/4] clk: sunxi: a31: Export the MIPI PLL

2020-01-04 Thread Maxime Ripard
On Fri, Jan 03, 2020 at 11:30:12PM +0800, Chen-Yu Tsai wrote:
> On Fri, Jan 3, 2020 at 11:28 PM Maxime Ripard  wrote:
> >
> > The MIPI PLL is used for LVDS. Make sure it's exported in the dt bindings
> > headers.
> >
> > Signed-off-by: Maxime Ripard 
>
> Acked-by: Chen-Yu Tsai 

Applied, thanks!
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RESEND PATCH v6 00/17] add drm support for MT8183

2020-01-04 Thread Yongqiang Niu
This series are based on 5.5-rc1 and provid 17 patch
to support mediatek SOC MT8183

Change since v5
- fix reviewed issue in v5
base https://patchwork.kernel.org/project/linux-mediatek/list/?series=213219

Change since v4
- fix reviewed issue in v4

Change since v3
- fix reviewed issue in v3
- fix type error in v3
- fix conflict with iommu patch

Change since v2
- fix reviewed issue in v2
- add mutex node into dts file

Changes since v1:
- fix reviewed issue in v1
- add dts for mt8183 display nodes
- adjust display clock control flow in patch 22
- add vmap support for mediatek drm in patch 23
- fix page offset issue for mmap function in patch 24
- enable allow_fb_modifiers for mediatek drm in patch 25

Yongqiang Niu (17):
  dt-bindings: mediatek: add rdma_fifo_size description for mt8183
display
  arm64: dts: add display nodes for mt8183
  drm/mediatek: move dsi/dpi select input into mtk_ddp_sel_in
  drm/mediatek: make sout select function format same with select input
  drm/mediatek: add mmsys private data for ddp path config
  drm/mediatek: add private data for rdma1 to dpi0 connection
  drm/mediatek: add private data for rdma1 to dsi0 connection
  drm/mediatek: move rdma sout from mtk_ddp_mout_en into
mtk_ddp_sout_sel
  drm/mediatek: add connection from OVL0 to OVL_2L0
  drm/mediatek: add connection from RDMA0 to COLOR0
  drm/mediatek: add connection from RDMA1 to DSI0
  drm/mediatek: add connection from OVL_2L0 to RDMA0
  drm/mediatek: add connection from OVL_2L1 to RDMA1
  drm/mediatek: add connection from DITHER0 to DSI0
  drm/mediatek: add connection from RDMA0 to DSI0
  drm/mediatek: add fifo_size into rdma private data
  drm/mediatek: add support for mediatek SOC MT8183

 .../bindings/display/mediatek/mediatek,disp.txt|  13 +
 arch/arm64/boot/dts/mediatek/mt8183.dtsi   |  98 +++
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c|  18 ++
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c   |  25 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c|   4 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 288 -
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h |   7 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |  49 
 drivers/gpu/drm/mediatek/mtk_drm_drv.h |   3 +
 9 files changed, 435 insertions(+), 70 deletions(-)

-- 
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/omap: gem: Fix tearing with BO_TILED

2020-01-04 Thread Tony Lindgren
* Matthijs van Duin  [200104 04:53]:
> On Fri, Dec 20, 2019 at 04:57:11PM -0800, Tony Lindgren wrote:
> > On my droid4 I noticed bad constant tearing on the LCD with stellarium in
> > landscape mode with xorg-video-omap rotated with xrandr --rotate right.
> > Every second or so update gets squeezed down in size to only the top half
> > of the LCD panel.
> 
> Odd, there's not really a good reason for rotation to have any effect on
> whether tearing happens or not.
> 
> BTW, with "top half", I assume you mean the top of the screen (i.e.
> right side of the display), not the top of the display (i.e. left side
> of the screen) ?

Correct right side of the display that appears on top after rotate right.

> > This issue does not happen with xrandr --rotate normal, or when HDMI
> > display is also connected.
> 
> E, mirroring onto HDMI fixes the problem?  Strange

Yup just connecting an additional HDMI panel fixes the issue on the LCD :)

> > Looking around what might affect BO_TILED, I noticed Matthijs had this
> > change in his earlier pyra tiler patches. The earlier patch "XXX omapdrm:
> > force tiled buffers to be pinned and page-aligned" has no commit log
> > though, so I'm not sure what other issues this might fix.
> 
> This is just part of a hacky patch series to improve performance for
> userspace access to tiled buffers.  Page alignment has no effect by
> itself, but it's necessary to allow the tiled memory allocated by
> tiled_reserve_2d() to be mapped directly into userspace instead of using
> the really slow "usergart" mechanism.

OK

> You can find the full patch series in github.com/mvduin/linux branch
> 4.15/patch/tiler-fast (based on mainline 4.15-rc6):
> 
> ae664249050b ARM: introduce pgprot_device()
> fc1e8ffd1334 drm: omapdrm: improve choice of memory type for tiled memory
>these improve performance on omap5/dra7 by mapping tiled buffers as
>"device" memory by default instead of the pointlessly slow "strongly
>ordered" which is currently used as a workaround for the
>incompatibility between TILER and the bizarre way the ARM Cortex-A15
>implements loads from normal non-cacheable memory.
> 
> 3d4c98cc47dd XXX omapdrm: factor out _omap_gem_(un)pin
> 70593563f531 XXX omapdrm: force tiled buffers to be pinned and page-aligned
> e061e454afd5 XXX omapdrm: fast userspace mapping of tiled buffers
>these greatly improve performance of userspace access to tiled
>buffers (on all devices that use tiler) at the expense of using more
>tiler virtual memory.  note that tiler virtual memory is a less
>scarce resource on omap5/dra7 where 2d and 1d mappings have separate
>page tables than on omap4 where they share a page table.
> 
> None of this should have any impact on tearing.

OK so the alignment change just happens to fix the issue then.

Regards,

Tony
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 3/4] clk: sunxi: a23/a33: Export the MIPI PLL

2020-01-04 Thread Maxime Ripard
On Fri, Jan 03, 2020 at 11:30:35PM +0800, Chen-Yu Tsai wrote:
> On Fri, Jan 3, 2020 at 11:28 PM Maxime Ripard  wrote:
> >
> > The MIPI PLL is used for LVDS. Make sure it's exported in the dt bindings
> > headers.
> >
> > Signed-off-by: Maxime Ripard 
>
> Acked-by: Chen-Yu Tsai 

Applied, thanks!
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2] dt-bindings: display: Convert Allwinner display pipeline to schemas

2020-01-04 Thread Maxime Ripard
On Thu, Jan 02, 2020 at 10:12:10AM -0700, Rob Herring wrote:
> On Thu, Jan 2, 2020 at 8:26 AM Maxime Ripard  wrote:
> >
> > The Allwinner SoCs have a display engine composed of several controllers
> > assembled differently depending on the SoC, the number and type of output
> > they have, and the additional features they provide. A number of those are
> > supported in Linux, with the matching bindings.
> >
> > Now that we have the DT validation in place, let's split into separate file
> > and convert the device tree bindings for those controllers to schemas.
> >
> > Signed-off-by: Maxime Ripard 
> >
> > ---
> >
> > Changes from v1:
> >   - Declare the ports in the bindings
>
> What about my comment on using minItems rather than maxItems?

I missed it, sorry. I'll address it in the next version

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RESEND PATCH v6 12/17] drm/mediatek: add connection from OVL_2L0 to RDMA0

2020-01-04 Thread Yongqiang Niu
this patch add add connection from OVL_2L0 to RDMA0

Signed-off-by: Yongqiang Niu 
Reviewed-by: CK Hu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 7b7e365..4a926f6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -33,6 +33,12 @@
 #define DISP_REG_CONFIG_DSI_SEL0x050
 #define DISP_REG_CONFIG_DPI_SEL0x064
 
+#define MT8183_DISP_OVL0_2L_MOUT_EN0xf04
+#define MT8183_DISP_PATH0_SEL_IN   0xf24
+
+#define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
+#define DISP_PATH0_SEL_IN_OVL0_2L  0x1
+
 #define MT2701_DISP_MUTEX0_MOD00x2c
 #define MT2701_DISP_MUTEX0_SOF00x30
 
@@ -308,6 +314,10 @@ static unsigned int mtk_ddp_mout_en(const struct 
mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_OVL_2L0) {
*addr = data->ovl0_mout_en;
value = OVL0_MOUT_EN_OVL0_2L;
+   } else if (cur == DDP_COMPONENT_OVL_2L0 &&
+  next == DDP_COMPONENT_RDMA0) {
+   *addr = MT8183_DISP_OVL0_2L_MOUT_EN;
+   value = OVL0_2L_MOUT_EN_DISP_PATH0;
} else {
value = 0;
}
@@ -370,6 +380,10 @@ static unsigned int mtk_ddp_sel_in(const struct 
mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
*addr = DISP_REG_CONFIG_DSI_SEL;
value = DSI_SEL_IN_RDMA;
+   } else if (cur == DDP_COMPONENT_OVL_2L0 &&
+  next == DDP_COMPONENT_RDMA0) {
+   *addr = MT8183_DISP_PATH0_SEL_IN;
+   value = DISP_PATH0_SEL_IN_OVL0_2L;
} else {
value = 0;
}
-- 
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RESEND PATCH v6 08/17] drm/mediatek: move rdma sout from mtk_ddp_mout_en into mtk_ddp_sout_sel

2020-01-04 Thread Yongqiang Niu
This patch move rdma sout from mtk_ddp_mout_en into mtk_ddp_sout_sel
rdma only has single output, but no multi output,
all these rdma->dsi/dpi usecase should move to mtk_ddp_sout_sel

Signed-off-by: Yongqiang Niu 
Reviewed-by: CK Hu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 90 +-
 1 file changed, 45 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 296b157..205c62a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -300,51 +300,6 @@ static unsigned int mtk_ddp_mout_en(const struct 
mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD1_MOUT_EN_RDMA1;
-   } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
-   *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
-   value = RDMA0_SOUT_DPI0;
-   } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI1) {
-   *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
-   value = RDMA0_SOUT_DPI1;
-   } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI1) {
-   *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
-   value = RDMA0_SOUT_DSI1;
-   } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
-   *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
-   value = RDMA0_SOUT_DSI2;
-   } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
-   *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
-   value = RDMA0_SOUT_DSI3;
-   } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
-   *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
-   value = RDMA1_SOUT_DSI1;
-   } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
-   *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
-   value = RDMA1_SOUT_DSI2;
-   } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
-   *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
-   value = RDMA1_SOUT_DSI3;
-   } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
-   *addr = data->rdma1_sout_sel_in;
-   value =data->rdma1_sout_dpi0;
-   } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
-   *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
-   value = RDMA1_SOUT_DPI1;
-   } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
-   *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
-   value = RDMA2_SOUT_DPI0;
-   } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
-   *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
-   value = RDMA2_SOUT_DPI1;
-   } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI1) {
-   *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
-   value = RDMA2_SOUT_DSI1;
-   } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI2) {
-   *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
-   value = RDMA2_SOUT_DSI2;
-   } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI3) {
-   *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
-   value = RDMA2_SOUT_DSI3;
} else {
value = 0;
}
@@ -427,6 +382,51 @@ static unsigned int mtk_ddp_sout_sel(const struct 
mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
*addr = DISP_REG_CONFIG_OUT_SEL;
value = BLS_TO_DPI_RDMA1_TO_DSI;
+   } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
+   *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+   value = RDMA0_SOUT_DPI0;
+   } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI1) {
+   *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+   value = RDMA0_SOUT_DPI1;
+   } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI1) {
+   *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+   value = RDMA0_SOUT_DSI1;
+   } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
+   *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+   value = RDMA0_SOUT_DSI2;
+   } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
+   *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+   value = RDMA0_SOUT_DSI3;
+   } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
+   *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
+   value = RDMA1_SOUT_DSI1;
+   } else if (cur == DDP_COMPONENT_RDMA1 && next 

[RESEND PATCH v6 13/17] drm/mediatek: add connection from OVL_2L1 to RDMA1

2020-01-04 Thread Yongqiang Niu
This patch add connection from OVL_2L1 to RDMA1

Signed-off-by: Yongqiang Niu 
Reviewed-by: CK Hu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 4a926f6..56750ba 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -34,9 +34,11 @@
 #define DISP_REG_CONFIG_DPI_SEL0x064
 
 #define MT8183_DISP_OVL0_2L_MOUT_EN0xf04
+#define MT8183_DISP_OVL1_2L_MOUT_EN0xf08
 #define MT8183_DISP_PATH0_SEL_IN   0xf24
 
 #define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
+#define OVL1_2L_MOUT_EN_RDMA1  BIT(4)
 #define DISP_PATH0_SEL_IN_OVL0_2L  0x1
 
 #define MT2701_DISP_MUTEX0_MOD00x2c
@@ -318,6 +320,10 @@ static unsigned int mtk_ddp_mout_en(const struct 
mtk_mmsys_reg_data *data,
   next == DDP_COMPONENT_RDMA0) {
*addr = MT8183_DISP_OVL0_2L_MOUT_EN;
value = OVL0_2L_MOUT_EN_DISP_PATH0;
+   } else if (cur == DDP_COMPONENT_OVL_2L1 &&
+  next == DDP_COMPONENT_RDMA1) {
+   *addr = MT8183_DISP_OVL1_2L_MOUT_EN;
+   value = OVL1_2L_MOUT_EN_RDMA1;
} else {
value = 0;
}
-- 
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 2/2] drm/sun4i: Use CRTC size instead of PRIMARY plane size as mixer frame.

2020-01-04 Thread Roman Stratiienko
чт, 2 янв. 2020 г., 12:08 Maxime Ripard :
>
> Hi,
>
> On Wed, Jan 01, 2020 at 10:47:50PM +0200, roman.stratiie...@globallogic.com 
> wrote:
> > From: Roman Stratiienko 
> >
> > According to DRM documentation the only difference between PRIMARY
> > and OVERLAY plane is that each CRTC must have PRIMARY plane and
> > OVERLAY are optional.
> >
> > Allow PRIMARY plane to have dimension different from full-screen.
> >
> > Fixes: 5bb5f5dafa1a ("drm/sun4i: Reorganize UI layer code in DE2")
> > Signed-off-by: Roman Stratiienko 
>
> So it applies to all the 4 patches you've sent, but this lacks some
> context.
>
> There's a few questions that should be answered here:
>   - Which situation is it fixing?

Setting primary plane size less than crtc breaks composition. Also
shifting top left corner also breaks it.

>   - What tool / userspace stack is it fixing?

I am using Android userspace and drm_hwcomposer HAL.

@Jernej, you've said that you observed similar issue. Could you share
what userspace have you used?

>   - What happens with your fix? Do you set the plane at coordinates
> 0,0 (meaning you'll crop the top-lef corner), do you center it? If
> the plane is smaller than the CTRC size, what is set on the edges?

You can put primary plane to any part of the screen and make it as
small as 8x8 (according to the datasheet) . Background would be filled
with black color, that is default, but it also could be overridden by
setting corresponding registers.

>
>
> Thanks!
> Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/hisilicon: Enforce 128-byte stride alignment to fix the display problem

2020-01-04 Thread Tian Tao
because the hardware limitation,The initial color depth must set to 32bpp
and must set the FB Offset of the display hardware to 128Byte alignment,
which is used to solve the display problem at 800x600 and 1440x900
resolution under 16bpp.

Signed-off-by: Tian Tao 
Signed-off-by: Gong junjie 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 13 ++---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c |  4 ++--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c   |  2 +-
 3 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index 12b38ac..843d784 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -83,9 +83,6 @@ static int hibmc_plane_atomic_check(struct drm_plane *plane,
return -EINVAL;
}
 
-   if (!crtc_state->enable)
-   return 0;
-
if (state->crtc_x + state->crtc_w >
crtc_state->adjusted_mode.hdisplay ||
state->crtc_y + state->crtc_h >
@@ -94,6 +91,11 @@ static int hibmc_plane_atomic_check(struct drm_plane *plane,
return -EINVAL;
}
 
+   if (state->fb->pitches[0] % 128 != 0) {
+   DRM_DEBUG_ATOMIC("wrong stride with 128-byte aligned\n");
+   return -EINVAL;
+   }
+
return 0;
 }
 
@@ -119,11 +121,8 @@ static void hibmc_plane_atomic_update(struct drm_plane 
*plane,
writel(gpu_addr, priv->mmio + HIBMC_CRT_FB_ADDRESS);
 
reg = state->fb->width * (state->fb->format->cpp[0]);
-   /* now line_pad is 16 */
-   reg = PADDING(16, reg);
 
-   line_l = state->fb->width * state->fb->format->cpp[0];
-   line_l = PADDING(16, line_l);
+   line_l = state->fb->pitches[0];
writel(HIBMC_FIELD(HIBMC_CRT_FB_WIDTH_WIDTH, reg) |
   HIBMC_FIELD(HIBMC_CRT_FB_WIDTH_OFFS, line_l),
   priv->mmio + HIBMC_CRT_FB_WIDTH);
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
index 1d15560..ca42dd7 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
@@ -73,7 +73,7 @@ static int hibmc_drm_fb_create(struct drm_fb_helper *helper,
 
mode_cmd.width = sizes->surface_width;
mode_cmd.height = sizes->surface_height;
-   mode_cmd.pitches[0] = mode_cmd.width * bytes_per_pixel;
+   mode_cmd.pitches[0] = ALIGN(mode_cmd.width * bytes_per_pixel, 128);
mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
  sizes->surface_depth);
 
@@ -186,7 +186,7 @@ int hibmc_fbdev_init(struct hibmc_drm_private *priv)
goto fini;
}
 
-   ret = drm_fb_helper_initial_config(>helper, 16);
+   ret = drm_fb_helper_initial_config(>helper, 32);
if (ret) {
DRM_ERROR("failed to setup initial conn config: %d\n", ret);
goto fini;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
index 19dc525..1cc702f 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
@@ -76,7 +76,7 @@ int hibmc_dumb_create(struct drm_file *file, struct 
drm_device *dev,
u32 handle;
int ret;
 
-   args->pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 16);
+   args->pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 128);
args->size = args->pitch * args->height;
 
ret = hibmc_gem_create(dev, args->size, false,
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RESEND PATCH v6 14/17] drm/mediatek: add connection from DITHER0 to DSI0

2020-01-04 Thread Yongqiang Niu
This patch add connection from DITHER0 to DSI0

Signed-off-by: Yongqiang Niu 
Reviewed-by: CK Hu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 56750ba..81d91f5 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -35,10 +35,12 @@
 
 #define MT8183_DISP_OVL0_2L_MOUT_EN0xf04
 #define MT8183_DISP_OVL1_2L_MOUT_EN0xf08
+#define MT8183_DISP_DITHER0_MOUT_EN0xf0c
 #define MT8183_DISP_PATH0_SEL_IN   0xf24
 
 #define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
 #define OVL1_2L_MOUT_EN_RDMA1  BIT(4)
+#define DITHER0_MOUT_IN_DSI0   BIT(0)
 #define DISP_PATH0_SEL_IN_OVL0_2L  0x1
 
 #define MT2701_DISP_MUTEX0_MOD00x2c
@@ -324,6 +326,9 @@ static unsigned int mtk_ddp_mout_en(const struct 
mtk_mmsys_reg_data *data,
   next == DDP_COMPONENT_RDMA1) {
*addr = MT8183_DISP_OVL1_2L_MOUT_EN;
value = OVL1_2L_MOUT_EN_RDMA1;
+   } else if (cur == DDP_COMPONENT_DITHER && next == DDP_COMPONENT_DSI0) {
+   *addr = MT8183_DISP_DITHER0_MOUT_EN;
+   value = DITHER0_MOUT_IN_DSI0;
} else {
value = 0;
}
-- 
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 1/4] dt-bindings: display: Convert Allwinner display pipeline to schemas

2020-01-04 Thread Maxime Ripard
The Allwinner SoCs have a display engine composed of several controllers
assembled differently depending on the SoC, the number and type of output
they have, and the additional features they provide. A number of those are
supported in Linux, with the matching bindings.

Now that we have the DT validation in place, let's split into separate file
and convert the device tree bindings for those controllers to schemas.

Signed-off-by: Maxime Ripard 

---

Changes from v2:
  - Changed a number of maxItems to minItems to make more sense
  - Fixed a few enum that were improperly declared. This raised a bunch of
warnings that were unnoticed before. Fixed them.
  - Added an if clause to the HDMI PHY binding to check the number of clocks

Changes from v1:
  - Declare the ports in the bindings
---
 .../allwinner,sun4i-a10-display-backend.yaml  | 291 
 .../allwinner,sun4i-a10-display-engine.yaml   | 114 +++
 .../allwinner,sun4i-a10-display-frontend.yaml | 138 
 .../display/allwinner,sun4i-a10-hdmi.yaml | 183 +
 .../display/allwinner,sun4i-a10-tcon.yaml | 676 ++
 .../allwinner,sun4i-a10-tv-encoder.yaml   |  62 ++
 .../display/allwinner,sun6i-a31-drc.yaml  | 138 
 .../allwinner,sun8i-a83t-de2-mixer.yaml   | 118 +++
 .../display/allwinner,sun8i-a83t-dw-hdmi.yaml | 273 +++
 .../allwinner,sun8i-a83t-hdmi-phy.yaml| 117 +++
 .../display/allwinner,sun8i-r40-tcon-top.yaml | 382 ++
 .../display/allwinner,sun9i-a80-deu.yaml  | 133 
 .../bindings/display/sunxi/sun4i-drm.txt  | 637 -
 13 files changed, 2625 insertions(+), 637 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-frontend.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun4i-a10-hdmi.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tv-encoder.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun6i-a31-drc.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun9i-a80-deu.yaml
 delete mode 100644 
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt

diff --git 
a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml
 
b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml
new file mode 100644
index ..86057d541065
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml
@@ -0,0 +1,291 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: 
http://devicetree.org/schemas/display/allwinner,sun4i-a10-display-backend.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A10 Display Engine Backend Device Tree Bindings
+
+maintainers:
+  - Chen-Yu Tsai 
+  - Maxime Ripard 
+
+description: |
+  The display engine backend exposes layers and sprites to the system.
+
+properties:
+  compatible:
+enum:
+  - allwinner,sun4i-a10-display-backend
+  - allwinner,sun5i-a13-display-backend
+  - allwinner,sun6i-a31-display-backend
+  - allwinner,sun7i-a20-display-backend
+  - allwinner,sun8i-a23-display-backend
+  - allwinner,sun8i-a33-display-backend
+  - allwinner,sun9i-a80-display-backend
+
+  reg:
+minItems: 1
+maxItems: 2
+items:
+  - description: Display Backend registers
+  - description: SAT registers
+
+  reg-names:
+minItems: 1
+maxItems: 2
+items:
+  - const: be
+  - const: sat
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+minItems: 3
+maxItems: 4
+items:
+  - description: The backend interface clock
+  - description: The backend module clock
+  - description: The backend DRAM clock
+  - description: The SAT clock
+
+  clock-names:
+minItems: 3
+maxItems: 4
+items:
+  - const: ahb
+  - const: mod
+  - const: ram
+  - const: sat
+
+  resets:
+minItems: 1
+maxItems: 2
+items:
+  - description: The Backend reset line
+  - description: The SAT reset line
+
+  reset-names:
+minItems: 1
+maxItems: 2
+items:
+  - const: be
+  - const: sat
+
+  # FIXME: This should be made required eventually once every 

[PATCH] drm/hisilicon: fixed the wrong resolution configurations

2020-01-04 Thread Tian Tao
The maximum resolution supported by hibmc is 1920 * 1200 instead of
1920 * 1440, this patch fixed this problem

Signed-off-by: Tian Tao 
Signed-off-by: Gong junjie 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 2fd4ca9..dbdeb2b 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -89,7 +89,7 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
priv->dev->mode_config.min_width = 0;
priv->dev->mode_config.min_height = 0;
priv->dev->mode_config.max_width = 1920;
-   priv->dev->mode_config.max_height = 1440;
+   priv->dev->mode_config.max_height = 1200;
 
priv->dev->mode_config.fb_base = priv->fb_base;
priv->dev->mode_config.preferred_depth = 24;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RESEND PATCH v6 17/17] drm/mediatek: add support for mediatek SOC MT8183

2020-01-04 Thread Yongqiang Niu
This patch add support for mediatek SOC MT8183
1.ovl_2l share driver with ovl
2.rdma1 share drive with rdma0, but fifo size is different
3.add mt8183 mutex private data, and mmsys private data
4.add mt8183 main and external path module for crtc create

Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c  | 18 +
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c |  6 +++
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c   | 69 
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h   |  1 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c   | 46 +
 5 files changed, 140 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 4a55bb6..5ee175e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -423,11 +423,29 @@ static int mtk_disp_ovl_remove(struct platform_device 
*pdev)
.fmt_rgb565_is_0 = true,
 };
 
+static const struct mtk_disp_ovl_data mt8183_ovl_driver_data = {
+   .addr = DISP_REG_OVL_ADDR_MT8173,
+   .gmc_bits = 10,
+   .layer_nr = 4,
+   .fmt_rgb565_is_0 = true,
+};
+
+static const struct mtk_disp_ovl_data mt8183_ovl_2l_driver_data = {
+   .addr = DISP_REG_OVL_ADDR_MT8173,
+   .gmc_bits = 10,
+   .layer_nr = 2,
+   .fmt_rgb565_is_0 = true,
+};
+
 static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-ovl",
  .data = _ovl_driver_data},
{ .compatible = "mediatek,mt8173-disp-ovl",
  .data = _ovl_driver_data},
+   { .compatible = "mediatek,mt8183-disp-ovl",
+ .data = _ovl_driver_data},
+   { .compatible = "mediatek,mt8183-disp-ovl-2l",
+ .data = _ovl_2l_driver_data},
{},
 };
 MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 0e0af04a..e2aab69 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -345,11 +345,17 @@ static int mtk_disp_rdma_remove(struct platform_device 
*pdev)
.fifo_size = SZ_8K,
 };
 
+static const struct mtk_disp_rdma_data mt8183_rdma_driver_data = {
+   .fifo_size = 5 * SZ_1K,
+};
+
 static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-rdma",
  .data = _rdma_driver_data},
{ .compatible = "mediatek,mt8173-disp-rdma",
  .data = _rdma_driver_data},
+   { .compatible = "mediatek,mt8183-disp-rdma",
+ .data = _rdma_driver_data},
{},
 };
 MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 3308b60..ee2bb3f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -33,19 +33,31 @@
 #define DISP_REG_CONFIG_DSI_SEL0x050
 #define DISP_REG_CONFIG_DPI_SEL0x064
 
+#define MT8183_DISP_OVL0_MOUT_EN   0xf00
 #define MT8183_DISP_OVL0_2L_MOUT_EN0xf04
 #define MT8183_DISP_OVL1_2L_MOUT_EN0xf08
 #define MT8183_DISP_DITHER0_MOUT_EN0xf0c
 #define MT8183_DISP_PATH0_SEL_IN   0xf24
+#define MT8183_DISP_DSI0_SEL_IN0xf2c
+#define MT8183_DISP_DPI0_SEL_IN0xf30
+#define MT8183_DISP_RDMA0_SOUT_SEL_IN  0xf50
+#define MT8183_DISP_RDMA1_SOUT_SEL_IN  0xf54
 
 #define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
 #define OVL1_2L_MOUT_EN_RDMA1  BIT(4)
 #define DITHER0_MOUT_IN_DSI0   BIT(0)
 #define DISP_PATH0_SEL_IN_OVL0_2L  0x1
 #define DSI0_SEL_IN_RDMA0  0x1
+#define MT8183_DSI0_SEL_IN_RDMA1   0x3
+#define MT8183_DPI0_SEL_IN_RDMA0   0x1
+#define MT8183_DPI0_SEL_IN_RDMA1   0x2
+#define MT8183_RDMA0_SOUT_COLOR0   0x1
+#define MT8183_RDMA1_SOUT_DSI0 0x1
 
 #define MT2701_DISP_MUTEX0_MOD00x2c
 #define MT2701_DISP_MUTEX0_SOF00x30
+#define MT8183_DISP_MUTEX0_MOD00x30
+#define MT8183_DISP_MUTEX0_SOF00x2c
 
 #define DISP_REG_MUTEX_EN(n)   (0x20 + 0x20 * (n))
 #define DISP_REG_MUTEX(n)  (0x24 + 0x20 * (n))
@@ -56,6 +68,18 @@
 
 #define INT_MUTEX  BIT(1)
 
+#define MT8183_MUTEX_MOD_DISP_RDMA00
+#define MT8183_MUTEX_MOD_DISP_RDMA11
+#define MT8183_MUTEX_MOD_DISP_OVL0 9
+#define MT8183_MUTEX_MOD_DISP_OVL0_2L  10
+#define MT8183_MUTEX_MOD_DISP_OVL1_2L  11
+#define MT8183_MUTEX_MOD_DISP_WDMA012
+#define 

[PATCH] drm/mediatek: fix indentation

2020-01-04 Thread Fabien Parent
Fix indentation in the Makefile by replacing spaces with tabs.

Signed-off-by: Fabien Parent 
---
 drivers/gpu/drm/mediatek/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index 8067a4be8311..b2b523913164 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -21,7 +21,7 @@ obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
 mediatek-drm-hdmi-objs := mtk_cec.o \
  mtk_hdmi.o \
  mtk_hdmi_ddc.o \
-  mtk_mt2701_hdmi_phy.o \
+ mtk_mt2701_hdmi_phy.o \
  mtk_mt8173_hdmi_phy.o \
  mtk_hdmi_phy.o
 
-- 
2.25.0.rc0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RESEND PATCH v6 09/17] drm/mediatek: add connection from OVL0 to OVL_2L0

2020-01-04 Thread Yongqiang Niu
This patch add connection from OVL0 to OVL_2L0

Signed-off-by: Yongqiang Niu 
Reviewed-by: CK Hu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 205c62a..3a1aa9a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -137,6 +137,8 @@
 #define DPI_SEL_IN_BLS 0x0
 #define DSI_SEL_IN_RDMA0x1
 
+#define OVL0_MOUT_EN_OVL0_2L   BIT(4)
+
 struct mtk_disp_mutex {
int id;
bool claimed;
@@ -300,6 +302,9 @@ static unsigned int mtk_ddp_mout_en(const struct 
mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD1_MOUT_EN_RDMA1;
+   } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_OVL_2L0) {
+   *addr = data->ovl0_mout_en;
+   value = OVL0_MOUT_EN_OVL0_2L;
} else {
value = 0;
}
-- 
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/amd: use list_for_each_entry for list iteration.

2020-01-04 Thread Wambui Karuga
list_for_each() can be replaced by the more concise
list_for_each_entry() here for iteration over the lists.
This change was reported by coccinelle.

Signed-off-by: Wambui Karuga 
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 19 ---
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
index 64445c4cc4c2..cbcf504f73a5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
@@ -111,17 +111,12 @@ static void init_handler_common_data(struct 
amdgpu_dm_irq_handler_data *hcd,
  */
 static void dm_irq_work_func(struct work_struct *work)
 {
-   struct list_head *entry;
struct irq_list_head *irq_list_head =
container_of(work, struct irq_list_head, work);
struct list_head *handler_list = _list_head->head;
struct amdgpu_dm_irq_handler_data *handler_data;
 
-   list_for_each(entry, handler_list) {
-   handler_data = list_entry(entry,
- struct amdgpu_dm_irq_handler_data,
- list);
-
+   list_for_each_entry(handler_data, handler_list, list) {
DRM_DEBUG_KMS("DM_IRQ: work_func: for dal_src=%d\n",
handler_data->irq_source);
 
@@ -528,19 +523,13 @@ static void amdgpu_dm_irq_immediate_work(struct 
amdgpu_device *adev,
 enum dc_irq_source irq_source)
 {
struct amdgpu_dm_irq_handler_data *handler_data;
-   struct list_head *entry;
unsigned long irq_table_flags;
 
DM_IRQ_TABLE_LOCK(adev, irq_table_flags);
 
-   list_for_each(
-   entry,
-   >dm.irq_handler_list_high_tab[irq_source]) {
-
-   handler_data = list_entry(entry,
- struct amdgpu_dm_irq_handler_data,
- list);
-
+   list_for_each_entry(handler_data,
+   >dm.irq_handler_list_high_tab[irq_source],
+   list) {
/* Call a subcomponent which registered for immediate
 * interrupt notification */
handler_data->handler(handler_data->handler_arg);
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RESEND PATCH v6 04/17] drm/mediatek: make sout select function format same with select input

2020-01-04 Thread Yongqiang Niu
there will be more sout case in the future,
make the sout function format same mtk_ddp_sel_in

Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index d66ce31..ae08fc4 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -386,17 +386,23 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id 
cur,
return value;
 }
 
-static void mtk_ddp_sout_sel(struct regmap *config_regs,
-enum mtk_ddp_comp_id cur,
-enum mtk_ddp_comp_id next)
+static unsigned int mtk_ddp_sout_sel(enum mtk_ddp_comp_id cur,
+enum mtk_ddp_comp_id next,
+unsigned int *addr)
 {
+   unsigned int value;
+
if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
-   regmap_write(config_regs, DISP_REG_CONFIG_OUT_SEL,
-   BLS_TO_DSI_RDMA1_TO_DPI1);
+   *addr = DISP_REG_CONFIG_OUT_SEL;
+   value = BLS_TO_DSI_RDMA1_TO_DPI1;
} else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
-   regmap_write(config_regs, DISP_REG_CONFIG_OUT_SEL,
-   BLS_TO_DPI_RDMA1_TO_DSI);
+   *addr = DISP_REG_CONFIG_OUT_SEL;
+   value = BLS_TO_DPI_RDMA1_TO_DSI;
+   } else {
+   value = 0;
}
+
+   return value;
 }
 
 void mtk_ddp_add_comp_to_path(struct regmap *config_regs,
@@ -409,7 +415,9 @@ void mtk_ddp_add_comp_to_path(struct regmap *config_regs,
if (value)
regmap_update_bits(config_regs, addr, value, value);
 
-   mtk_ddp_sout_sel(config_regs, cur, next);
+   value = mtk_ddp_sout_sel(cur, next, );
+   if (value)
+   regmap_update_bits(config_regs, addr, value, value);
 
value = mtk_ddp_sel_in(cur, next, );
if (value)
-- 
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 3/4] clk: sunxi: a23/a33: Export the MIPI PLL

2020-01-04 Thread Maxime Ripard
The MIPI PLL is used for LVDS. Make sure it's exported in the dt bindings
headers.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu-sun8i-a23-a33.h  | 4 +++-
 include/dt-bindings/clock/sun8i-a23-a33-ccu.h | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a23-a33.h 
b/drivers/clk/sunxi-ng/ccu-sun8i-a23-a33.h
index 72df69291cc6..5bf5c4d13b4c 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a23-a33.h
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a23-a33.h
@@ -24,7 +24,9 @@
 #define CLK_PLL_PERIPH 10
 #define CLK_PLL_PERIPH_2X  11
 #define CLK_PLL_GPU12
-#define CLK_PLL_MIPI   13
+
+/* The PLL MIPI clock is exported */
+
 #define CLK_PLL_HSIC   14
 #define CLK_PLL_DE 15
 #define CLK_PLL_DDR1   16
diff --git a/include/dt-bindings/clock/sun8i-a23-a33-ccu.h 
b/include/dt-bindings/clock/sun8i-a23-a33-ccu.h
index f8222b6b2cc3..eb524d0bbd01 100644
--- a/include/dt-bindings/clock/sun8i-a23-a33-ccu.h
+++ b/include/dt-bindings/clock/sun8i-a23-a33-ccu.h
@@ -43,6 +43,8 @@
 #ifndef _DT_BINDINGS_CLK_SUN8I_A23_A33_H_
 #define _DT_BINDINGS_CLK_SUN8I_A23_A33_H_
 
+#define CLK_PLL_MIPI   13
+
 #define CLK_CPUX   18
 
 #define CLK_BUS_MIPI_DSI   23
-- 
2.24.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2] dt-bindings: display: Convert Allwinner display pipeline to schemas

2020-01-04 Thread Maxime Ripard
The Allwinner SoCs have a display engine composed of several controllers
assembled differently depending on the SoC, the number and type of output
they have, and the additional features they provide. A number of those are
supported in Linux, with the matching bindings.

Now that we have the DT validation in place, let's split into separate file
and convert the device tree bindings for those controllers to schemas.

Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Declare the ports in the bindings
---
 .../allwinner,sun4i-a10-display-backend.yaml  | 291 
 .../allwinner,sun4i-a10-display-engine.yaml   | 114 
 .../allwinner,sun4i-a10-display-frontend.yaml | 138 
 .../display/allwinner,sun4i-a10-hdmi.yaml | 183 +
 .../display/allwinner,sun4i-a10-tcon.yaml | 591 
 .../allwinner,sun4i-a10-tv-encoder.yaml   |  62 ++
 .../display/allwinner,sun6i-a31-drc.yaml  | 138 
 .../allwinner,sun8i-a83t-de2-mixer.yaml   | 118 
 .../display/allwinner,sun8i-a83t-dw-hdmi.yaml | 273 
 .../allwinner,sun8i-a83t-hdmi-phy.yaml|  77 +++
 .../display/allwinner,sun8i-r40-tcon-top.yaml | 382 +++
 .../display/allwinner,sun9i-a80-deu.yaml  | 133 
 .../bindings/display/sunxi/sun4i-drm.txt  | 637 --
 13 files changed, 2500 insertions(+), 637 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-frontend.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun4i-a10-hdmi.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tv-encoder.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun6i-a31-drc.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/allwinner,sun9i-a80-deu.yaml
 delete mode 100644 
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt

diff --git 
a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml
 
b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml
new file mode 100644
index ..b6b1a0babe83
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml
@@ -0,0 +1,291 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: 
http://devicetree.org/schemas/display/allwinner,sun4i-a10-display-backend.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A10 Display Engine Backend Device Tree Bindings
+
+maintainers:
+  - Chen-Yu Tsai 
+  - Maxime Ripard 
+
+description: |
+  The display engine backend exposes layers and sprites to the system.
+
+properties:
+  compatible:
+enum:
+  - allwinner,sun4i-a10-display-backend
+  - allwinner,sun5i-a13-display-backend
+  - allwinner,sun6i-a31-display-backend
+  - allwinner,sun7i-a20-display-backend
+  - allwinner,sun8i-a23-display-backend
+  - allwinner,sun8i-a33-display-backend
+  - allwinner,sun9i-a80-display-backend
+
+  reg:
+minItems: 1
+maxItems: 2
+items:
+  - description: Display Backend registers
+  - description: SAT registers
+
+  reg-names:
+minItems: 1
+maxItems: 2
+items:
+  - const: be
+  - const: sat
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+minItems: 3
+maxItems: 4
+items:
+  - description: The backend interface clock
+  - description: The backend module clock
+  - description: The backend DRAM clock
+  - description: The SAT clock
+
+  clock-names:
+minItems: 3
+maxItems: 4
+items:
+  - const: ahb
+  - const: mod
+  - const: ram
+  - const: sat
+
+  resets:
+minItems: 1
+maxItems: 2
+items:
+  - description: The Backend reset line
+  - description: The SAT reset line
+
+  reset-names:
+minItems: 1
+maxItems: 2
+items:
+  - const: be
+  - const: sat
+
+  # FIXME: This should be made required eventually once every SoC will
+  # have the MBUS declared.
+  interconnects:
+maxItems: 1
+
+  # FIXME: This should be made required eventually once every SoC will
+  # have the MBUS declared.
+  interconnect-names:
+const: dma-mem
+
+  ports:
+type: object
+description: |
+  A ports 

Re: [PATCH v3 2/2] drm/sun4i: Use CRTC size instead of PRIMARY plane size as mixer frame.

2020-01-04 Thread Jernej Škrabec
Hi!

Dne četrtek, 02. januar 2020 ob 17:32:07 CET je Roman Stratiienko napisal(a):
> чт, 2 янв. 2020 г., 12:08 Maxime Ripard :
> > Hi,
> > 
> > On Wed, Jan 01, 2020 at 10:47:50PM +0200, 
roman.stratiie...@globallogic.com wrote:
> > > From: Roman Stratiienko 
> > > 
> > > According to DRM documentation the only difference between PRIMARY
> > > and OVERLAY plane is that each CRTC must have PRIMARY plane and
> > > OVERLAY are optional.
> > > 
> > > Allow PRIMARY plane to have dimension different from full-screen.
> > > 
> > > Fixes: 5bb5f5dafa1a ("drm/sun4i: Reorganize UI layer code in DE2")
> > > Signed-off-by: Roman Stratiienko 
> > 
> > So it applies to all the 4 patches you've sent, but this lacks some
> > context.
> > 
> > There's a few questions that should be answered here:
> >   - Which situation is it fixing?
> 
> Setting primary plane size less than crtc breaks composition. Also
> shifting top left corner also breaks it.

True, HW doesn't have notion of primary plane. It's just one plane which is 
marked as primary, but otherwise it has same capabilities as others, like x,y 
coordinates, size, etc.

> 
> >   - What tool / userspace stack is it fixing?
> 
> I am using Android userspace and drm_hwcomposer HAL.
> 
> @Jernej, you've said that you observed similar issue. Could you share
> what userspace have you used?

I observed it with DE1, but it has exactly the same issue. I noticed this 
problem on Kodi (gbm version). Kodi first searches for plane capable of 
displaying NV12 format (for video) and after that a plane which is capable of 
displaying RGB888 format (for GUI). In DE1 case, first plane is primary and 
also capable of displaying NV12 format. So when video is displayed which 
doesn't cover whole screen, display output is corrupted. However, with such 
fix, video playback is correct. Luc Verhaegen make equivalent fix for DE1, 
where 
he also claims primary plane doesn't have to be same size as CRTC output:
https://github.com/libv/fosdem-video-linux/commit/
ae3215d37ca2a55642bcae6c83c3612e26275711

> 
> >   - What happens with your fix? Do you set the plane at coordinates
> >   
> > 0,0 (meaning you'll crop the top-lef corner), do you center it? If
> > the plane is smaller than the CTRC size, what is set on the edges?
> 
> You can put primary plane to any part of the screen and make it as
> small as 8x8 (according to the datasheet) . Background would be filled
> with black color, that is default, but it also could be overridden by
> setting corresponding registers.

Correct, same logic as for overlay planes applies.

Best regards,
Jernej

> 
> > Thanks!
> > Maxime




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/radeon: remove boolean checks in if statements.

2020-01-04 Thread Wambui Karuga
Remove unnecessary variable comparisions to true/false in if statements
and check the value of the variable directly.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/radeon/cik_sdma.c   |  2 +-
 drivers/gpu/drm/radeon/r100.c   |  2 +-
 drivers/gpu/drm/radeon/r600.c   |  2 +-
 drivers/gpu/drm/radeon/radeon_bios.c| 12 ++--
 drivers/gpu/drm/radeon/radeon_connectors.c  |  4 ++--
 drivers/gpu/drm/radeon/radeon_display.c |  4 ++--
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |  4 ++--
 drivers/gpu/drm/radeon/radeon_pm.c  |  2 +-
 8 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
b/drivers/gpu/drm/radeon/cik_sdma.c
index 35b9dc6ce46a..68403e77756d 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -333,7 +333,7 @@ void cik_sdma_enable(struct radeon_device *rdev, bool 
enable)
u32 me_cntl, reg_offset;
int i;
 
-   if (enable == false) {
+   if (!enable) {
cik_sdma_gfx_stop(rdev);
cik_sdma_rlc_stop(rdev);
}
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 0017aa7a9f17..957994258860 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2815,7 +2815,7 @@ void r100_vga_set_state(struct radeon_device *rdev, bool 
state)
uint32_t temp;
 
temp = RREG32(RADEON_CONFIG_CNTL);
-   if (state == false) {
+   if (!state) {
temp &= ~RADEON_CFG_VGA_RAM_EN;
temp |= RADEON_CFG_VGA_IO_DIS;
} else {
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 0d453aa09352..eb56fb48a6b7 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3191,7 +3191,7 @@ void r600_vga_set_state(struct radeon_device *rdev, bool 
state)
uint32_t temp;
 
temp = RREG32(CONFIG_CNTL);
-   if (state == false) {
+   if (!state) {
temp &= ~(1<<0);
temp |= (1<<1);
} else {
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index c84d965c283e..c42f73fad3e3 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -664,17 +664,17 @@ bool radeon_get_bios(struct radeon_device *rdev)
uint16_t tmp;
 
r = radeon_atrm_get_bios(rdev);
-   if (r == false)
+   if (!r)
r = radeon_acpi_vfct_bios(rdev);
-   if (r == false)
+   if (!r)
r = igp_read_bios_from_vram(rdev);
-   if (r == false)
+   if (!r)
r = radeon_read_bios(rdev);
-   if (r == false)
+   if (!r)
r = radeon_read_disabled_bios(rdev);
-   if (r == false)
+   if (!r)
r = radeon_read_platform_bios(rdev);
-   if (r == false || rdev->bios == NULL) {
+   if (!r || rdev->bios == NULL) {
DRM_ERROR("Unable to locate a BIOS ROM\n");
rdev->bios = NULL;
return false;
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 0851e6817e57..90d2f732affb 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -440,7 +440,7 @@ radeon_connector_analog_encoder_conflict_solve(struct 
drm_connector *connector,
if (radeon_conflict->use_digital)
continue;
 
-   if (priority == true) {
+   if (priority) {
DRM_DEBUG_KMS("1: conflicting encoders 
switching off %s\n",
  conflict->name);
DRM_DEBUG_KMS("in favor of %s\n",
@@ -700,7 +700,7 @@ static int radeon_connector_set_property(struct 
drm_connector *connector, struct
else
ret = 
radeon_legacy_get_tmds_info_from_combios(radeon_encoder, tmds);
}
-   if (val == 1 || ret == false) {
+   if (val == 1 || !ret) {
radeon_legacy_get_tmds_info_from_table(radeon_encoder, 
tmds);
}
radeon_property_change_mode(_encoder->base);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index dfb921899853..e42d9e0a4b8c 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -847,11 +847,11 @@ static bool radeon_setup_enc_conn(struct drm_device *dev)
if (rdev->bios) {
if (rdev->is_atom_bios) {
ret = 
radeon_get_atom_connector_info_from_supported_devices_table(dev);
-   if (ret == false)
+  

[RESEND PATCH v6 07/17] drm/mediatek: add private data for rdma1 to dsi0 connection

2020-01-04 Thread Yongqiang Niu
the register offset and value will be different in future SOC,
add private data for rdma1->dsi0 use case.

Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 0015b35..296b157 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -174,6 +174,8 @@ struct mtk_mmsys_reg_data {
u32 rdma1_sout_dpi0;
u32 dpi0_sel_in;
u32 dpi0_sel_in_rdma1;
+   u32 dsi0_sel_in;
+   u32 dsi0_sel_in_rdma1;
 };
 
 static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
@@ -256,6 +258,8 @@ struct mtk_mmsys_reg_data {
 
 const struct mtk_mmsys_reg_data mt2701_mmsys_reg_data = {
.ovl0_mout_en = DISP_REG_CONFIG_DISP_OVL_MOUT_EN,
+   .dsi0_sel_in = DISP_REG_CONFIG_DSI_SEL,
+   .dsi0_sel_in_rdma1 = DSI_SEL_IN_RDMA,
 };
 
 const struct mtk_mmsys_reg_data mt8173_mmsys_reg_data = {
@@ -264,6 +268,8 @@ struct mtk_mmsys_reg_data {
.rdma1_sout_dpi0 = RDMA1_SOUT_DPI0,
.dpi0_sel_in = DISP_REG_CONFIG_DPI_SEL_IN,
.dpi0_sel_in_rdma1 = DPI0_SEL_IN_RDMA1,
+   .dsi0_sel_in = DISP_REG_CONFIG_DSIE_SEL_IN,
+   .dsi0_sel_in_rdma1 = DSI0_SEL_IN_RDMA1,
 };
 
 static unsigned int mtk_ddp_mout_en(const struct mtk_mmsys_reg_data *data,
@@ -363,8 +369,8 @@ static unsigned int mtk_ddp_sel_in(const struct 
mtk_mmsys_reg_data *data,
*addr = DISP_REG_CONFIG_DPI_SEL_IN;
value = DPI1_SEL_IN_RDMA1;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI0) {
-   *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
-   value = DSI0_SEL_IN_RDMA1;
+   *addr = data->dsi0_sel_in;
+   value = data->dsi0_sel_in_rdma1;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
*addr = DISP_REG_CONFIG_DSIO_SEL_IN;
value = DSI1_SEL_IN_RDMA1;
-- 
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 4/4] ARM: dts: sunxi: Add missing LVDS resets and clocks

2020-01-04 Thread Maxime Ripard
Some old SoCs, while supporting LVDS, don't list the LVDS clocks and reset
lines. Let's add them when relevant.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 23 +++
 arch/arm/boot/dts/sun8i-a23-a33.dtsi | 12 
 arch/arm/boot/dts/sun9i-a80.dtsi |  8 ++--
 3 files changed, 29 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 4d622ec48b24..7762fbd9a133 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -286,14 +286,18 @@ tcon0: lcd-controller@1c0c000 {
reg = <0x01c0c000 0x1000>;
interrupts = ;
dmas = < 11>;
-   resets = < RST_AHB1_LCD0>;
-   reset-names = "lcd";
+   resets = < RST_AHB1_LCD0>,
+< RST_AHB1_LVDS>;
+   reset-names = "lcd",
+ "lvds";
clocks = < CLK_AHB1_LCD0>,
 < CLK_LCD0_CH0>,
-< CLK_LCD0_CH1>;
+< CLK_LCD0_CH1>,
+< 15>;
clock-names = "ahb",
  "tcon-ch0",
- "tcon-ch1";
+ "tcon-ch1",
+ "lvds-alt";
clock-output-names = "tcon0-pixel-clock";
#clock-cells = <0>;
 
@@ -336,14 +340,17 @@ tcon1: lcd-controller@1c0d000 {
reg = <0x01c0d000 0x1000>;
interrupts = ;
dmas = < 12>;
-   resets = < RST_AHB1_LCD1>;
-   reset-names = "lcd";
+   resets = < RST_AHB1_LCD1>,
+< RST_AHB1_LVDS>;
+   reset-names = "lcd", "lvds";
clocks = < CLK_AHB1_LCD1>,
 < CLK_LCD1_CH0>,
-< CLK_LCD1_CH1>;
+< CLK_LCD1_CH1>,
+< 15>;
clock-names = "ahb",
  "tcon-ch0",
- "tcon-ch1";
+ "tcon-ch1",
+ "lvds-alt";
clock-output-names = "tcon1-pixel-clock";
#clock-cells = <0>;
 
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi 
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 70ec3493061b..48487f6d4ab9 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -184,13 +184,17 @@ tcon0: lcd-controller@1c0c000 {
interrupts = ;
dmas = < 12>;
clocks = < CLK_BUS_LCD>,
-< CLK_LCD_CH0>;
+< CLK_LCD_CH0>,
+< 13>;
clock-names = "ahb",
- "tcon-ch0";
+ "tcon-ch0",
+ "lvds-alt";
clock-output-names = "tcon-pixel-clock";
#clock-cells = <0>;
-   resets = < RST_BUS_LCD>;
-   reset-names = "lcd";
+   resets = < RST_BUS_LCD>,
+< RST_BUS_LVDS>;
+   reset-names = "lcd",
+ "lvds";
status = "disabled";
 
ports {
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 3b533e85da43..ce4fa6706d06 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -878,8 +878,12 @@ tcon0: lcd-controller@3c0 {
interrupts = ;
clocks = < CLK_BUS_LCD0>, < CLK_LCD0>;
clock-names = "ahb", "tcon-ch0";
-   resets = < RST_BUS_LCD0>, < RST_BUS_EDP>;
-   reset-names = "lcd", "edp";
+   resets = < RST_BUS_LCD0>,
+< RST_BUS_EDP>,
+< RST_BUS_LVDS>;
+   reset-names = "lcd",
+ "edp",
+ "lvds";
clock-output-names = "tcon0-pixel-clock";
#clock-cells = <0>;
 
-- 
2.24.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RESEND PATCH v6 06/17] drm/mediatek: add private data for rdma1 to dpi0 connection

2020-01-04 Thread Yongqiang Niu
the register offset and value will be different in future SOC,
add private data for rdma1->dpi0 use case.

Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index b279204..0015b35 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -170,6 +170,10 @@ struct mtk_ddp {
 
 struct mtk_mmsys_reg_data {
u32 ovl0_mout_en;
+   u32 rdma1_sout_sel_in;
+   u32 rdma1_sout_dpi0;
+   u32 dpi0_sel_in;
+   u32 dpi0_sel_in_rdma1;
 };
 
 static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
@@ -256,6 +260,10 @@ struct mtk_mmsys_reg_data {
 
 const struct mtk_mmsys_reg_data mt8173_mmsys_reg_data = {
.ovl0_mout_en = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN,
+   .rdma1_sout_sel_in = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN,
+   .rdma1_sout_dpi0 = RDMA1_SOUT_DPI0,
+   .dpi0_sel_in = DISP_REG_CONFIG_DPI_SEL_IN,
+   .dpi0_sel_in_rdma1 = DPI0_SEL_IN_RDMA1,
 };
 
 static unsigned int mtk_ddp_mout_en(const struct mtk_mmsys_reg_data *data,
@@ -311,8 +319,8 @@ static unsigned int mtk_ddp_mout_en(const struct 
mtk_mmsys_reg_data *data,
*addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
value = RDMA1_SOUT_DSI3;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
-   *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
-   value = RDMA1_SOUT_DPI0;
+   *addr = data->rdma1_sout_sel_in;
+   value =data->rdma1_sout_dpi0;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
*addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
value = RDMA1_SOUT_DPI1;
@@ -349,8 +357,8 @@ static unsigned int mtk_ddp_sel_in(const struct 
mtk_mmsys_reg_data *data,
*addr = DISP_REG_CONFIG_DISP_COLOR0_SEL_IN;
value = COLOR0_SEL_IN_OVL0;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
-   *addr = DISP_REG_CONFIG_DPI_SEL_IN;
-   value = DPI0_SEL_IN_RDMA1;
+   *addr = data->dpi0_sel_in;
+   value = data->dpi0_sel_in_rdma1;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
*addr = DISP_REG_CONFIG_DPI_SEL_IN;
value = DPI1_SEL_IN_RDMA1;
-- 
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 2/4] clk: sunxi: a31: Export the MIPI PLL

2020-01-04 Thread Maxime Ripard
The MIPI PLL is used for LVDS. Make sure it's exported in the dt bindings
headers.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu-sun6i-a31.h  | 4 +++-
 include/dt-bindings/clock/sun6i-a31-ccu.h | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.h 
b/drivers/clk/sunxi-ng/ccu-sun6i-a31.h
index a361388b4670..3ed2a59b0dc6 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.h
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.h
@@ -32,7 +32,9 @@
 /* The PLL_VIDEO1_2X clock is exported */
 
 #define CLK_PLL_GPU14
-#define CLK_PLL_MIPI   15
+
+/* The PLL_VIDEO1_2X clock is exported */
+
 #define CLK_PLL9   16
 #define CLK_PLL10  17
 
diff --git a/include/dt-bindings/clock/sun6i-a31-ccu.h 
b/include/dt-bindings/clock/sun6i-a31-ccu.h
index c5d13340184a..39878d9dce9f 100644
--- a/include/dt-bindings/clock/sun6i-a31-ccu.h
+++ b/include/dt-bindings/clock/sun6i-a31-ccu.h
@@ -49,6 +49,8 @@
 
 #define CLK_PLL_VIDEO1_2X  13
 
+#define CLK_PLL_MIPI   15
+
 #define CLK_CPU18
 
 #define CLK_AHB1_MIPIDSI   23
-- 
2.24.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RESEND PATCH v6 01/17] dt-bindings: mediatek: add rdma_fifo_size description for mt8183 display

2020-01-04 Thread Yongqiang Niu
Update device tree binding documention for rdma_fifo_size

Signed-off-by: Yongqiang Niu 
---
 .../devicetree/bindings/display/mediatek/mediatek,disp.txt  | 13 +
 1 file changed, 13 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 681502e..34bef44 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -70,6 +70,10 @@ Required properties (DMA function blocks):
   argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
   for details.
 
+Required properties (DMA function blocks):
+- mediatek,rdma_fifo_size: rdma fifo size may be different even in same SOC, 
add this
+  property to the corresponding rdma
+
 Examples:
 
 mmsys: clock-controller@1400 {
@@ -211,3 +215,12 @@ od@14023000 {
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_OD>;
 };
+
+rdma1: rdma@1400c000 {
+   compatible = "mediatek,mt8183-disp-rdma";
+   reg = <0 0x1400c000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_RDMA1>;
+   mediatek,rdma_fifo_size = <2048>;
+};
\ No newline at end of file
-- 
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RESEND PATCH v6 03/17] drm/mediatek: move dsi/dpi select input into mtk_ddp_sel_in

2020-01-04 Thread Yongqiang Niu
move dsi/dpi select input into mtk_ddp_sel_in
DPI_SEL_IN_BLS is zero, it is same with hardware default setting,
DISP_REG_CONFIG_DPI_SEL no need set when bls connect with
dpi0

Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 39700b9..d66ce31 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -376,6 +376,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
} else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
*addr = DISP_REG_CONFIG_DSI_SEL;
value = DSI_SEL_IN_BLS;
+   } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
+   *addr = DISP_REG_CONFIG_DSI_SEL;
+   value = DSI_SEL_IN_RDMA;
} else {
value = 0;
}
@@ -393,10 +396,6 @@ static void mtk_ddp_sout_sel(struct regmap *config_regs,
} else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
regmap_write(config_regs, DISP_REG_CONFIG_OUT_SEL,
BLS_TO_DPI_RDMA1_TO_DSI);
-   regmap_write(config_regs, DISP_REG_CONFIG_DSI_SEL,
-   DSI_SEL_IN_RDMA);
-   regmap_write(config_regs, DISP_REG_CONFIG_DPI_SEL,
-   DPI_SEL_IN_BLS);
}
 }
 
-- 
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RESEND PATCH v6 16/17] drm/mediatek: add fifo_size into rdma private data

2020-01-04 Thread Yongqiang Niu
the fifo size of rdma in mt8183 is different.
rdma0 fifo size is 5k
rdma1 fifo size is 2k

Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 405afef..0e0af04a 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -62,6 +62,7 @@ struct mtk_disp_rdma {
struct mtk_ddp_comp ddp_comp;
struct drm_crtc *crtc;
const struct mtk_disp_rdma_data *data;
+   u32 fifo_size;
 };
 
 static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
@@ -130,10 +131,16 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, 
unsigned int width,
unsigned int threshold;
unsigned int reg;
struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
+   u32 rdma_fifo_size;
 
rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xfff, width);
rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_1, 0xf, height);
 
+   if (rdma->fifo_size)
+   rdma_fifo_size = rdma->fifo_size;
+   else
+   rdma_fifo_size = RDMA_FIFO_SIZE(rdma);
+
/*
 * Enable FIFO underflow since DSI and DPI can't be blocked.
 * Keep the FIFO pseudo size reset default of 8 KiB. Set the
@@ -142,7 +149,7 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, 
unsigned int width,
 */
threshold = width * height * vrefresh * 4 * 7 / 100;
reg = RDMA_FIFO_UNDERFLOW_EN |
- RDMA_FIFO_PSEUDO_SIZE(RDMA_FIFO_SIZE(rdma)) |
+ RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) |
  RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
writel(reg, comp->regs + DISP_REG_RDMA_FIFO_CON);
 }
@@ -284,6 +291,16 @@ static int mtk_disp_rdma_probe(struct platform_device 
*pdev)
return comp_id;
}
 
+   if (of_find_property(dev->of_node, "mediatek,rdma_fifo_size", )) {
+   ret = of_property_read_u32(dev->of_node,
+  "mediatek,rdma_fifo_size",
+  >fifo_size);
+   if (ret) {
+   dev_err(dev, "Failed to get rdma fifo size\n");
+   return ret;
+   }
+   }
+
ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp, comp_id,
_disp_rdma_funcs);
if (ret) {
-- 
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RESEND PATCH v6 02/17] arm64: dts: add display nodes for mt8183

2020-01-04 Thread Yongqiang Niu
This patch add display nodes for mt8183

Signed-off-by: Yongqiang Niu 
---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 98 
 1 file changed, 98 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 91217e4f..28beb1d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -30,6 +30,11 @@
i2c9 = 
i2c10 = 
i2c11 = 
+   ovl0 = 
+   ovl_2l0 = _2l0;
+   ovl_2l1 = _2l1;
+   rdma0 = 
+   rdma1 = 
};
 
cpus {
@@ -648,9 +653,102 @@
mmsys: syscon@1400 {
compatible = "mediatek,mt8183-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
#clock-cells = <1>;
};
 
+   ovl0: ovl@14008000 {
+   compatible = "mediatek,mt8183-disp-ovl";
+   reg = <0 0x14008000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_OVL0>;
+   };
+
+   ovl_2l0: ovl@14009000 {
+   compatible = "mediatek,mt8183-disp-ovl-2l";
+   reg = <0 0x14009000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_OVL0_2L>;
+   };
+
+   ovl_2l1: ovl@1400a000 {
+   compatible = "mediatek,mt8183-disp-ovl-2l";
+   reg = <0 0x1400a000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_OVL1_2L>;
+   };
+
+   rdma0: rdma@1400b000 {
+   compatible = "mediatek,mt8183-disp-rdma";
+   reg = <0 0x1400b000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_RDMA0>;
+   mediatek,rdma_fifo_size = <5120>;
+   };
+
+   rdma1: rdma@1400c000 {
+   compatible = "mediatek,mt8183-disp-rdma";
+   reg = <0 0x1400c000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_RDMA1>;
+   mediatek,rdma_fifo_size = <2048>;
+   };
+
+   color0: color@1400e000 {
+   compatible = "mediatek,mt8183-disp-color",
+"mediatek,mt8173-disp-color";
+   reg = <0 0x1400e000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_COLOR0>;
+   };
+
+   ccorr0: ccorr@1400f000 {
+   compatible = "mediatek,mt8183-disp-ccorr";
+   reg = <0 0x1400f000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_CCORR0>;
+   };
+
+   aal0: aal@1401 {
+   compatible = "mediatek,mt8183-disp-aal",
+"mediatek,mt8173-disp-aal";
+   reg = <0 0x1401 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_AAL0>;
+   };
+
+   gamma0: gamma@14011000 {
+   compatible = "mediatek,mt8183-disp-gamma",
+"mediatek,mt8173-disp-gamma";
+   reg = <0 0x14011000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_GAMMA0>;
+   };
+
+   dither0: dither@14012000 {
+   compatible = "mediatek,mt8183-disp-dither";
+   reg = <0 0x14012000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_DITHER0>;
+   };
+
+   mutex: mutex@14016000 {
+   compatible = "mediatek,mt8183-disp-mutex";
+   reg = <0 0x14016000 0 0x1000>;
+   interrupts = ;
+   

Re: [PATCH v3 4/4] ARM: dts: sunxi: Add missing LVDS resets and clocks

2020-01-04 Thread Maxime Ripard
On Fri, Jan 03, 2020 at 11:31:05PM +0800, Chen-Yu Tsai wrote:
> On Fri, Jan 3, 2020 at 11:28 PM Maxime Ripard  wrote:
> >
> > Some old SoCs, while supporting LVDS, don't list the LVDS clocks and reset
> > lines. Let's add them when relevant.
> >
> > Signed-off-by: Maxime Ripard 
>
> Acked-by: Chen-Yu Tsai 

Applied, thanks!
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 1/2] drm/sun4i: Add alpha property for sun8i UI layer

2020-01-04 Thread roman . stratiienko
From: Roman Stratiienko 

DE2.0 and DE3.0 UI layers supports plane-global alpha channel.
Add alpha property to the DRM plane and connect it to the
corresponding registers in mixer.

Signed-off-by: Roman Stratiienko 
Reviewed-by: Jernej Skrabec 
---
v2: Initial commit by mistake
v3:
- Picked `reviewed-by` line
---
 drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 29 ++
 drivers/gpu/drm/sun4i/sun8i_ui_layer.h |  5 +
 2 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c 
b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
index c87fd842918e..4343ea9f8cf8 100644
--- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
@@ -72,6 +72,27 @@ static void sun8i_ui_layer_enable(struct sun8i_mixer *mixer, 
int channel,
}
 }
 
+static void sun8i_ui_layer_update_alpha(struct sun8i_mixer *mixer, int channel,
+   int overlay, struct drm_plane *plane)
+{
+   u32 mask, val, ch_base;
+
+   ch_base = sun8i_channel_base(mixer, channel);
+
+   mask = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK |
+   SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK;
+
+   val = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA(plane->state->alpha >> 8);
+
+   val |= (plane->state->alpha == DRM_BLEND_ALPHA_OPAQUE) ?
+   SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_PIXEL :
+   SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_COMBINED;
+
+   regmap_update_bits(mixer->engine.regs,
+  SUN8I_MIXER_CHAN_UI_LAYER_ATTR(ch_base, overlay),
+  mask, val);
+}
+
 static int sun8i_ui_layer_update_coord(struct sun8i_mixer *mixer, int channel,
   int overlay, struct drm_plane *plane,
   unsigned int zpos)
@@ -288,6 +309,8 @@ static void sun8i_ui_layer_atomic_update(struct drm_plane 
*plane,
 
sun8i_ui_layer_update_coord(mixer, layer->channel,
layer->overlay, plane, zpos);
+   sun8i_ui_layer_update_alpha(mixer, layer->channel,
+   layer->overlay, plane);
sun8i_ui_layer_update_formats(mixer, layer->channel,
  layer->overlay, plane);
sun8i_ui_layer_update_buffer(mixer, layer->channel,
@@ -365,6 +388,12 @@ struct sun8i_ui_layer *sun8i_ui_layer_init_one(struct 
drm_device *drm,
 
plane_cnt = mixer->cfg->ui_num + mixer->cfg->vi_num;
 
+   ret = drm_plane_create_alpha_property(>plane);
+   if (ret) {
+   dev_err(drm->dev, "Couldn't add alpha property\n");
+   return ERR_PTR(ret);
+   }
+
ret = drm_plane_create_zpos_property(>plane, channel,
 0, plane_cnt - 1);
if (ret) {
diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.h 
b/drivers/gpu/drm/sun4i/sun8i_ui_layer.h
index f4ab1cf6cded..e3e32ee1178d 100644
--- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.h
@@ -40,6 +40,11 @@
 #define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK  GENMASK(12, 8)
 #define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_OFFSET8
 #define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK  GENMASK(31, 24)
+#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA(x)((x) << 24)
+
+#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_PIXEL((0) << 
1)
+#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_LAYER((1) << 
1)
+#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_COMBINED ((2) << 1)
 
 struct sun8i_mixer;
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/omap: gem: Fix tearing with BO_TILED

2020-01-04 Thread Tony Lindgren
* Matthijs van Duin  [200104 05:10]:
> On Sat, Dec 21, 2019 at 08:41:41AM -0800, Tony Lindgren wrote:
> > Also, I'm wondering if this change makes sense alone without the pinning
> > changes for a fix, or if also the pinning changes are needed.
> 
> Both pinning and page-alignment are done just to support the direct
> userspace mapping.  By themselves they mostly just waste tiler memory
> but otherwise don't really have much impact.

OK thanks, so no specific fix, that's the part I was wondering about :)

> It's not really clear to me why you have such interest in this specific
> patch.  Does my patch series fix the tearing issue you've described?  If
> so maybe without my patches tiled memory is just so slow that the frame
> is being submitted too late, which perhaps causes an async page flip
> (does it? I'm not sure) thus resulting in tearing?

Just changing the alingment fixes the issue. Looks like the minimum
alignment we currently allow is 128, I think 512 was the minimum
that worked for me, so maybe the right fix would be to just change
the minimum to 512 with no specific need to use 4096 for now.

I did not see any issue with frame updates being too slow, I just
picked that alignment change manually without trying the rest of
your series.

Regards,

Tony
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RESEND PATCH v6 05/17] drm/mediatek: add mmsys private data for ddp path config

2020-01-04 Thread Yongqiang Niu
This patch add mmsys private data for ddp path config
all these register offset and value will be different in future SOC
add these define into mmsys private data
u32 ovl0_mout_en;

Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  4 
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 37 -
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |  6 ++
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  3 +++
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  3 +++
 5 files changed, 43 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index e47cf84..9aacbcf 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -44,6 +44,7 @@ struct mtk_drm_crtc {
boolpending_planes;
 
struct regmap   *config_regs;
+   const struct mtk_mmsys_reg_data *mmsys_reg_data;
struct mtk_disp_mutex   *mutex;
unsigned intddp_comp_nr;
struct mtk_ddp_comp **ddp_comp;
@@ -283,6 +284,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
*mtk_crtc)
DRM_DEBUG_DRIVER("mediatek_ddp_ddp_path_setup\n");
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
mtk_ddp_add_comp_to_path(mtk_crtc->config_regs,
+mtk_crtc->mmsys_reg_data,
 mtk_crtc->ddp_comp[i]->id,
 mtk_crtc->ddp_comp[i + 1]->id);
mtk_disp_mutex_add_comp(mtk_crtc->mutex,
@@ -340,6 +342,7 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc 
*mtk_crtc)
mtk_disp_mutex_disable(mtk_crtc->mutex);
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
mtk_ddp_remove_comp_from_path(mtk_crtc->config_regs,
+ mtk_crtc->mmsys_reg_data,
  mtk_crtc->ddp_comp[i]->id,
  mtk_crtc->ddp_comp[i + 1]->id);
mtk_disp_mutex_remove_comp(mtk_crtc->mutex,
@@ -649,6 +652,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
return -ENOMEM;
 
mtk_crtc->config_regs = priv->config_regs;
+   mtk_crtc->mmsys_reg_data = priv->data->reg_data;
mtk_crtc->ddp_comp_nr = path_len;
mtk_crtc->ddp_comp = devm_kmalloc_array(dev, mtk_crtc->ddp_comp_nr,
sizeof(*mtk_crtc->ddp_comp),
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index ae08fc4..b279204 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -168,6 +168,10 @@ struct mtk_ddp {
const struct mtk_ddp_data   *data;
 };
 
+struct mtk_mmsys_reg_data {
+   u32 ovl0_mout_en;
+};
+
 static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_BLS] = MT2701_MUTEX_MOD_DISP_BLS,
[DDP_COMPONENT_COLOR0] = MT2701_MUTEX_MOD_DISP_COLOR,
@@ -246,17 +250,26 @@ struct mtk_ddp {
.mutex_sof_reg = MT2701_DISP_MUTEX0_SOF0,
 };
 
-static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
+const struct mtk_mmsys_reg_data mt2701_mmsys_reg_data = {
+   .ovl0_mout_en = DISP_REG_CONFIG_DISP_OVL_MOUT_EN,
+};
+
+const struct mtk_mmsys_reg_data mt8173_mmsys_reg_data = {
+   .ovl0_mout_en = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN,
+};
+
+static unsigned int mtk_ddp_mout_en(const struct mtk_mmsys_reg_data *data,
+   enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next,
unsigned int *addr)
 {
unsigned int value;
 
if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_COLOR0) {
-   *addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
+   *addr = data->ovl0_mout_en;
value = OVL0_MOUT_EN_COLOR0;
} else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
-   *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
+   *addr = data->ovl0_mout_en;
value = OVL_MOUT_EN_RDMA;
} else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
@@ -325,7 +338,8 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id 
cur,
return value;
 }
 
-static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
+static unsigned int mtk_ddp_sel_in(const struct mtk_mmsys_reg_data *data,
+  enum mtk_ddp_comp_id cur,
   enum mtk_ddp_comp_id next,
   unsigned int *addr)
 {
@@ -386,7 +400,8 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
return value;
 }
 
-static 

Re: [PATCH] panel: simple: Add Ivo M133NWF4 R0

2020-01-04 Thread Bjorn Andersson
On Thu 02 Jan 00:55 PST 2020, Sam Ravnborg wrote:

> Hi Bjorn.
> 
> On Sat, Dec 28, 2019 at 10:06:58PM -0800, Bjorn Andersson wrote:
> > The InfoVision Optoelectronics M133NWF4 R0 panel is a 13.3" 1920x1080
> > eDP panel, add support for it in panel-simple.
> > 
> > Signed-off-by: Bjorn Andersson 
> > ---
> >  drivers/gpu/drm/panel/panel-simple.c | 31 
> >  1 file changed, 31 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index ba3f85f36c2f..d7ae0ede2b6e 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -1806,6 +1806,34 @@ static const struct panel_desc innolux_zj070na_01p = 
> > {
> > },
> >  };
> >  
> > +static const struct drm_display_mode ivo_m133nwf4_r0_mode = {
> > +   .clock = 138778,
> > +   .hdisplay = 1920,
> > +   .hsync_start = 1920 + 24,
> > +   .hsync_end = 1920 + 24 + 48,
> > +   .htotal = 1920 + 24 + 48 + 88,
> > +   .vdisplay = 1080,
> > +   .vsync_start = 1080 + 3,
> > +   .vsync_end = 1080 + 3 + 12,
> > +   .vtotal = 1080 + 3 + 12 + 17,
> > +   .vrefresh = 60,
> > +   .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> > +};
> > +
> > +static const struct panel_desc ivo_m133nwf4_r0 = {
> > +   .modes = _m133nwf4_r0_mode,
> > +   .num_modes = 1,
> > +   .bpc = 8,
> > +   .size = {
> > +   .width = 294,
> > +   .height = 165,
> > +   },
> > +   .delay = {
> > +   .hpd_absent_delay = 200,
> > +   .unprepare = 500,
> > +   },
> > +};
> 
> For new bindings - at least add connector_type.
> And consider bus_format and bus_flags too.
> 

Sure thing, will update the two patches.

> 
> > +
> >  static const struct display_timing koe_tx14d24vm1bpa_timing = {
> > .pixelclock = { 558, 585, 620 },
> > .hactive = { 320, 320, 320 },
> > @@ -3266,6 +3294,9 @@ static const struct of_device_id platform_of_match[] 
> > = {
> > }, {
> > .compatible = "innolux,zj070na-01p",
> > .data = _zj070na_01p,
> > +   }, {
> > +   .compatible = "ivo,m133nwf4-r0",
> Compatible must be documented in a binding file.
> We are discussing a new binding format where it is simple to add
> a new panel. But no final conclusion yet.
> 

Okay, will spin some DT bindings for these as well.

Thanks,
Bjorn

> The comments above (in panel_desc and here) also apply for the
> other patch you sent.
> 
>   Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/3] drm/i915: use true, false for bool variable in intel_crt.c

2020-01-04 Thread Ma Feng
Fixes coccicheck warning:

drivers/gpu/drm/i915/display/intel_crt.c:1066:1-28: WARNING: Assignment of 0/1 
to bool variable
drivers/gpu/drm/i915/display/intel_crt.c:928:2-29: WARNING: Assignment of 0/1 
to bool variable
drivers/gpu/drm/i915/display/intel_crt.c:443:2-29: WARNING: Assignment of 0/1 
to bool variable

Reported-by: Hulk Robot 
Signed-off-by: Ma Feng 
---
 drivers/gpu/drm/i915/display/intel_crt.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crt.c 
b/drivers/gpu/drm/i915/display/intel_crt.c
index b2b1336..8596eef 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -440,7 +440,7 @@ static bool intel_ironlake_crt_detect_hotplug(struct 
drm_connector *connector)
bool turn_off_dac = HAS_PCH_SPLIT(dev_priv);
u32 save_adpa;

-   crt->force_hotplug_required = 0;
+   crt->force_hotplug_required = false;

save_adpa = adpa = I915_READ(crt->adpa_reg);
DRM_DEBUG_KMS("trigger hotplug detect cycle: adpa=0x%x\n", 
adpa);
@@ -925,7 +925,7 @@ void intel_crt_reset(struct drm_encoder *encoder)
POSTING_READ(crt->adpa_reg);

DRM_DEBUG_KMS("crt adpa set to 0x%x\n", adpa);
-   crt->force_hotplug_required = 1;
+   crt->force_hotplug_required = true;
}

 }
@@ -1063,7 +1063,7 @@ void intel_crt_init(struct drm_i915_private *dev_priv)
/*
 * Configure the automatic hotplug detection stuff
 */
-   crt->force_hotplug_required = 0;
+   crt->force_hotplug_required = false;

/*
 * TODO: find a proper way to discover whether we need to set the the
--
2.6.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RESEND PATCH v6 11/17] drm/mediatek: add connection from RDMA1 to DSI0

2020-01-04 Thread Yongqiang Niu
This patch add connection from RDMA1 to DSI0

Signed-off-by: Yongqiang Niu 
Reviewed-by: CK Hu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index b6b86600..7b7e365 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -176,6 +176,7 @@ struct mtk_mmsys_reg_data {
u32 rdma0_sout_color0;
u32 rdma1_sout_sel_in;
u32 rdma1_sout_dpi0;
+   u32 rdma1_sout_dsi0;
u32 dpi0_sel_in;
u32 dpi0_sel_in_rdma1;
u32 dsi0_sel_in;
@@ -437,6 +438,9 @@ static unsigned int mtk_ddp_sout_sel(const struct 
mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_COLOR0) {
*addr = data->rdma0_sout_sel_in;
value = data->rdma0_sout_color0;
+   } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI0) {
+   *addr = data->rdma1_sout_sel_in;
+   value = data->rdma1_sout_dsi0;
} else {
value = 0;
}
-- 
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RESEND PATCH v6 10/17] drm/mediatek: add connection from RDMA0 to COLOR0

2020-01-04 Thread Yongqiang Niu
This patch add connection from RDMA0 to COLOR0

Signed-off-by: Yongqiang Niu 
Reviewed-by: CK Hu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 3a1aa9a..b6b86600 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -172,6 +172,8 @@ struct mtk_ddp {
 
 struct mtk_mmsys_reg_data {
u32 ovl0_mout_en;
+   u32 rdma0_sout_sel_in;
+   u32 rdma0_sout_color0;
u32 rdma1_sout_sel_in;
u32 rdma1_sout_dpi0;
u32 dpi0_sel_in;
@@ -432,6 +434,9 @@ static unsigned int mtk_ddp_sout_sel(const struct 
mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI3) {
*addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
value = RDMA2_SOUT_DSI3;
+   } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_COLOR0) {
+   *addr = data->rdma0_sout_sel_in;
+   value = data->rdma0_sout_color0;
} else {
value = 0;
}
-- 
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/3] drm/i915: use true, false for bool variable in i915_debugfs.c

2020-01-04 Thread Ma Feng
Fixes coccicheck warning:

drivers/gpu/drm/i915/i915_debugfs.c:3078:4-36: WARNING: Assignment of 0/1 to 
bool variable
drivers/gpu/drm/i915/i915_debugfs.c:3078:4-36: WARNING: Assignment of 0/1 to 
bool variable
drivers/gpu/drm/i915/i915_debugfs.c:3080:4-36: WARNING: Assignment of 0/1 to 
bool variable
drivers/gpu/drm/i915/i915_debugfs.c:3080:4-36: WARNING: Assignment of 0/1 to 
bool variable

Reported-by: Hulk Robot 
Signed-off-by: Ma Feng 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d28468e..4ead86a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3075,9 +3075,9 @@ static ssize_t i915_displayport_test_active_write(struct 
file *file,
 * testing code, only accept an actual value of 1 here
 */
if (val == 1)
-   intel_dp->compliance.test_active = 1;
+   intel_dp->compliance.test_active = true;
else
-   intel_dp->compliance.test_active = 0;
+   intel_dp->compliance.test_active = false;
}
}
drm_connector_list_iter_end(_iter);
--
2.6.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/3] drm/i915/dp: use true, false for bool variable in intel_dp.c

2020-01-04 Thread Ma Feng
Fixes coccicheck warning:

drivers/gpu/drm/i915/display/intel_dp.c:4950:1-33: WARNING: Assignment of 0/1 
to bool variable
drivers/gpu/drm/i915/display/intel_dp.c:4906:1-33: WARNING: Assignment of 0/1 
to bool variable

Reported-by: Hulk Robot 
Signed-off-by: Ma Feng 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2f31d22..4fd0fcd 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4903,7 +4903,7 @@ static u8 intel_dp_autotest_video_pattern(struct intel_dp 
*intel_dp)
intel_dp->compliance.test_data.hdisplay = be16_to_cpu(h_width);
intel_dp->compliance.test_data.vdisplay = be16_to_cpu(v_height);
/* Set test active flag here so userspace doesn't interrupt things */
-   intel_dp->compliance.test_active = 1;
+   intel_dp->compliance.test_active = true;

return DP_TEST_ACK;
 }
@@ -4947,7 +4947,7 @@ static u8 intel_dp_autotest_edid(struct intel_dp 
*intel_dp)
}

/* Set test active flag here so userspace doesn't interrupt things */
-   intel_dp->compliance.test_active = 1;
+   intel_dp->compliance.test_active = true;

return test_result;
 }
--
2.6.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/nouveau/bios: fix incorrect kfree in platform_init

2020-01-04 Thread wuxu . wu
Hi, I think there has a incorrect kfree in pcirom_init function. In
pcirom_init function priv porinter could be free only when priv != null
and priv->rom is null.

Signed-off-by: wuxu.wu 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
index 9b91da0..d776e01 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
@@ -70,8 +70,9 @@ pcirom_init(struct nvkm_bios *bios, const char *name)
(priv->rom = pci_map_rom(pdev, >size))) {
priv->pdev = pdev;
return priv;
+   } else {
+   kfree(priv);
}
-   kfree(priv);
}
pci_disable_rom(pdev);
}
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 2/2] drm/sun4i: Add alpha property for sun8i and sun50i VI layer

2020-01-04 Thread roman . stratiienko
From: Roman Stratiienko 

DE3.0 VI layers supports plane-global alpha channel.
DE2.0 FCC block have GLOBAL_ALPHA register that can be used as alpha source
for blender.

Add alpha property to the DRM plane and connect it to the
corresponding registers in the mixer.

Do not add alpha property for systems with DE2.0 and more than 1 VI planes.

Signed-off-by: Roman Stratiienko 
---
v2: Initial version by mistake
v3:
- Skip adding & applying alpha property if VI count > 1
---
 drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 48 +-
 drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 11 ++
 2 files changed, 51 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c 
b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
index 42d445d23773..e61aec7d6d07 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
@@ -65,6 +65,36 @@ static void sun8i_vi_layer_enable(struct sun8i_mixer *mixer, 
int channel,
}
 }
 
+static void sun8i_vi_layer_update_alpha(struct sun8i_mixer *mixer, int channel,
+   int overlay, struct drm_plane *plane)
+{
+   u32 mask, val, ch_base;
+
+   ch_base = sun8i_channel_base(mixer, channel);
+
+   if (mixer->cfg->is_de3) {
+   mask = SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MASK |
+  SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MODE_MASK;
+   val = SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA
+   (plane->state->alpha >> 8);
+
+   val |= (plane->state->alpha == DRM_BLEND_ALPHA_OPAQUE) ?
+   SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MODE_PIXEL :
+   SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MODE_COMBINED;
+
+   regmap_update_bits(mixer->engine.regs,
+  SUN8I_MIXER_CHAN_VI_LAYER_ATTR(ch_base,
+ overlay),
+  mask, val);
+   } else if (mixer->cfg->vi_num == 1) {
+   regmap_update_bits(mixer->engine.regs,
+  SUN8I_MIXER_FCC_GLOBAL_ALPHA_REG,
+  SUN8I_MIXER_FCC_GLOBAL_ALPHA_MASK,
+  SUN8I_MIXER_FCC_GLOBAL_ALPHA
+   (plane->state->alpha >> 8));
+   }
+}
+
 static int sun8i_vi_layer_update_coord(struct sun8i_mixer *mixer, int channel,
   int overlay, struct drm_plane *plane,
   unsigned int zpos)
@@ -248,14 +278,6 @@ static int sun8i_vi_layer_update_formats(struct 
sun8i_mixer *mixer, int channel,
   SUN8I_MIXER_CHAN_VI_LAYER_ATTR(ch_base, overlay),
   SUN8I_MIXER_CHAN_VI_LAYER_ATTR_RGB_MODE, val);
 
-   /* It seems that YUV formats use global alpha setting. */
-   if (mixer->cfg->is_de3)
-   regmap_update_bits(mixer->engine.regs,
-  SUN8I_MIXER_CHAN_VI_LAYER_ATTR(ch_base,
- overlay),
-  SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MASK,
-  SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA(0xff));
-
return 0;
 }
 
@@ -373,6 +395,8 @@ static void sun8i_vi_layer_atomic_update(struct drm_plane 
*plane,
 
sun8i_vi_layer_update_coord(mixer, layer->channel,
layer->overlay, plane, zpos);
+   sun8i_vi_layer_update_alpha(mixer, layer->channel,
+   layer->overlay, plane);
sun8i_vi_layer_update_formats(mixer, layer->channel,
  layer->overlay, plane);
sun8i_vi_layer_update_buffer(mixer, layer->channel,
@@ -464,6 +488,14 @@ struct sun8i_vi_layer *sun8i_vi_layer_init_one(struct 
drm_device *drm,
 
plane_cnt = mixer->cfg->ui_num + mixer->cfg->vi_num;
 
+   if (mixer->cfg->vi_num == 1 || mixer->cfg->is_de3) {
+   ret = drm_plane_create_alpha_property(>plane);
+   if (ret) {
+   dev_err(drm->dev, "Couldn't add alpha property\n");
+   return ERR_PTR(ret);
+   }
+   }
+
ret = drm_plane_create_zpos_property(>plane, index,
 0, plane_cnt - 1);
if (ret) {
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.h 
b/drivers/gpu/drm/sun4i/sun8i_vi_layer.h
index eaa6076f5dbc..48c399e1c86d 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.h
@@ -29,14 +29,25 @@
 #define SUN8I_MIXER_CHAN_VI_VDS_UV(base) \
((base) + 0xfc)
 
+#define SUN8I_MIXER_FCC_GLOBAL_ALPHA_REG \
+   (0xAA000 + 0x90)
+
+#define SUN8I_MIXER_FCC_GLOBAL_ALPHA(x)((x) << 24)
+#define SUN8I_MIXER_FCC_GLOBAL_ALPHA_MASK

Re: [PATCH] drm/omap: gem: Fix tearing with BO_TILED

2020-01-04 Thread Matthijs van Duin
On Sat, Dec 21, 2019 at 08:41:41AM -0800, Tony Lindgren wrote:
> Also, I'm wondering if this change makes sense alone without the pinning
> changes for a fix, or if also the pinning changes are needed.

Both pinning and page-alignment are done just to support the direct
userspace mapping.  By themselves they mostly just waste tiler memory
but otherwise don't really have much impact.

It's not really clear to me why you have such interest in this specific
patch.  Does my patch series fix the tearing issue you've described?  If
so maybe without my patches tiled memory is just so slow that the frame
is being submitted too late, which perhaps causes an async page flip
(does it? I'm not sure) thus resulting in tearing?

Matthijs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC v2 1/1] drm/lima: Add optional devfreq support

2020-01-04 Thread Martin Blumenstingl
Hi Robin,

On Wed, Jan 1, 2020 at 1:55 PM Robin Murphy  wrote:
>
> On 2019-12-31 4:47 pm, Martin Blumenstingl wrote:
> > Hi Robin,
> >
> > On Tue, Dec 31, 2019 at 5:40 PM Robin Murphy  wrote:
> >>
> >> On 2019-12-31 2:17 pm, Martin Blumenstingl wrote:
> >>> Hi Robin,
> >>>
> >>> On Mon, Dec 30, 2019 at 1:47 AM Robin Murphy  wrote:
> 
>  On 2019-12-29 11:19 pm, Martin Blumenstingl wrote:
> > Hi Robin,
> >
> > On Sun, Dec 29, 2019 at 11:58 PM Robin Murphy  
> > wrote:
> >>
> >> Hi Martin,
> >>
> >> On 2019-12-27 5:37 pm, Martin Blumenstingl wrote:
> >>> Most platforms with a Mali-400 or Mali-450 GPU also have support for
> >>> changing the GPU clock frequency. Add devfreq support so the GPU clock
> >>> rate is updated based on the actual GPU usage when the
> >>> "operating-points-v2" property is present in the board.dts.
> >>>
> >>> The actual devfreq code is taken from panfrost_devfreq.c and modified 
> >>> so
> >>> it matches what the lima hardware needs:
> >>> - a call to dev_pm_opp_set_clkname() during initialization because 
> >>> there
> >>>   are two clocks on Mali-4x0 IPs. "core" is the one that actually 
> >>> clocks
> >>>   the GPU so we need to control it using devfreq.
> >>> - locking when reading or writing the devfreq statistics because 
> >>> (unlike
> >>>   than panfrost) we have multiple PP and GP IRQs which may finish 
> >>> jobs
> >>>   concurrently.
> >>
> >> I gave this a quick try on my RK3328, and the clock scaling indeed 
> >> kicks
> >> in nicely on the glmark2 scenes that struggle, however something 
> >> appears
> >> to be missing in terms of regulator association, as the appropriate OPP
> >> voltages aren't reflected in the GPU supply (fortunately the initial
> >> voltage seems close enough to that of the highest OPP not to cause 
> >> major
> >> problems, on my box at least). With panfrost on RK3399 I do see the
> >> supply voltage scaling accordingly, but I don't know my way around
> >> devfreq well enough to know what matters in the difference :/
> > first of all: thank you for trying this out! :-)
> >
> > does your kernel include commit 221bc77914cbcc ("drm/panfrost: Use
> > generic code for devfreq") for your panfrost test?
> > if I understand the devfreq API correct then I suspect with that
> > commit panfrost also won't change the voltage anymore.
> 
>  Oh, you're quite right - I was already considering that change as
>  ancient history, but indeed it's only in 5.5-rc, while that board is
>  still on 5.4.y release kernels. No wonder I couldn't make sense of how
>  the (current) code could possibly be working :)
> 
>  I'll try the latest -rc kernel tomorrow to confirm (now that PCIe is
>  hopefully fixed), but I'm already fairly confident you've called it
>  correctly.
> >>> I just tested it with the lima driver (by undervolting the GPU by
> >>> 0.05V) and it seems that dev_pm_opp_set_regulators is really needed.
> >>> I'll fix this in the next version of this patch and also submit a fix
> >>> for panfrost (I won't be able to test that though, so help is
> >>> appreciated in terms of testing :))
> >>
> >> Yeah, I started hacking something up for panfrost yesterday, but at the
> >> point of realising the core OPP code wants refactoring to actually
> >> handle optional regulators without spewing errors, decided that was
> >> crossing the line into "work" and thus could wait until next week :D
> > I'm not sure what you mean, dev_pm_opp_set_regulators uses
> > regulator_get_optional.
> > doesn't that mean that it is optional already?
>
> Indeed it does call regulator_get_optional(), but it then goes on to
> treat the absence of a supposedly-optional regulator as a hard failure.
> It doesn't seem very useful having a nice abstracted interface if users
> still end up have to dance around and duplicate half the parsing in
> order to work out whether it's worth calling or not - far better IMO if
> it could just successfully set/put zero regulators in the cases where
> the OPPs are behind a firmware/mailbox DVFS interface rather than
> explicit in-kernel clock/regulator control.
thank you for the explanation
I'll experience this case on newer Amlogic SoCs where regulators are
hidden behind SCPI firmware. so far I have only tested the case
without OPP-table on those SoCs.

> That said, given that I think the current lima/panfrost users should all
> be relatively simple with either 0 or 1 regulator, you could probably
> just special-case -ENODEV and accept a spurious error message sometimes
> for the sake of an immediate fix, then we can make general improvements
> to the interface separately afterwards.
OK, I'll be working on this next week again
if you get to fix panfrost earlier then please Cc me so we don't duplicate work


Martin

[RESEND PATCH v6 15/17] drm/mediatek: add connection from RDMA0 to DSI0

2020-01-04 Thread Yongqiang Niu
This patch add connection from RDMA0 to DSI0

Signed-off-by: Yongqiang Niu 
Reviewed-by: CK Hu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 81d91f5..3308b60 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -42,6 +42,7 @@
 #define OVL1_2L_MOUT_EN_RDMA1  BIT(4)
 #define DITHER0_MOUT_IN_DSI0   BIT(0)
 #define DISP_PATH0_SEL_IN_OVL0_2L  0x1
+#define DSI0_SEL_IN_RDMA0  0x1
 
 #define MT2701_DISP_MUTEX0_MOD00x2c
 #define MT2701_DISP_MUTEX0_SOF00x30
@@ -395,6 +396,9 @@ static unsigned int mtk_ddp_sel_in(const struct 
mtk_mmsys_reg_data *data,
   next == DDP_COMPONENT_RDMA0) {
*addr = MT8183_DISP_PATH0_SEL_IN;
value = DISP_PATH0_SEL_IN_OVL0_2L;
+   } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI0) {
+   *addr = data->dsi0_sel_in;
+   value = DSI0_SEL_IN_RDMA0;
} else {
value = 0;
}
-- 
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/omap: gem: Fix tearing with BO_TILED

2020-01-04 Thread Matthijs van Duin
On Fri, Dec 20, 2019 at 04:57:11PM -0800, Tony Lindgren wrote:
> On my droid4 I noticed bad constant tearing on the LCD with stellarium in
> landscape mode with xorg-video-omap rotated with xrandr --rotate right.
> Every second or so update gets squeezed down in size to only the top half
> of the LCD panel.

Odd, there's not really a good reason for rotation to have any effect on
whether tearing happens or not.

BTW, with "top half", I assume you mean the top of the screen (i.e.
right side of the display), not the top of the display (i.e. left side
of the screen) ?


> This issue does not happen with xrandr --rotate normal, or when HDMI
> display is also connected.

E, mirroring onto HDMI fixes the problem?  Strange


> Looking around what might affect BO_TILED, I noticed Matthijs had this
> change in his earlier pyra tiler patches. The earlier patch "XXX omapdrm:
> force tiled buffers to be pinned and page-aligned" has no commit log
> though, so I'm not sure what other issues this might fix.

This is just part of a hacky patch series to improve performance for
userspace access to tiled buffers.  Page alignment has no effect by
itself, but it's necessary to allow the tiled memory allocated by
tiled_reserve_2d() to be mapped directly into userspace instead of using
the really slow "usergart" mechanism.

You can find the full patch series in github.com/mvduin/linux branch
4.15/patch/tiler-fast (based on mainline 4.15-rc6):

ae664249050b ARM: introduce pgprot_device()
fc1e8ffd1334 drm: omapdrm: improve choice of memory type for tiled memory
   these improve performance on omap5/dra7 by mapping tiled buffers as
   "device" memory by default instead of the pointlessly slow "strongly
   ordered" which is currently used as a workaround for the
   incompatibility between TILER and the bizarre way the ARM Cortex-A15
   implements loads from normal non-cacheable memory.

3d4c98cc47dd XXX omapdrm: factor out _omap_gem_(un)pin
70593563f531 XXX omapdrm: force tiled buffers to be pinned and page-aligned
e061e454afd5 XXX omapdrm: fast userspace mapping of tiled buffers
   these greatly improve performance of userspace access to tiled
   buffers (on all devices that use tiler) at the expense of using more
   tiler virtual memory.  note that tiler virtual memory is a less
   scarce resource on omap5/dra7 where 2d and 1d mappings have separate
   page tables than on omap4 where they share a page table.

None of this should have any impact on tearing.


Matthijs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/radeon: remove unnecessary braces around conditionals.

2020-01-04 Thread Wambui Karuga
As single statement conditionals do not need to be wrapped around
braces, the unnecessary braces can be removed.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/radeon/atombios_crtc.c |  3 +--
 drivers/gpu/drm/radeon/atombios_dp.c   |  3 +--
 drivers/gpu/drm/radeon/atombios_encoders.c |  9 -
 drivers/gpu/drm/radeon/radeon_connectors.c |  4 ++--
 drivers/gpu/drm/radeon/radeon_vce.c|  4 ++--
 drivers/gpu/drm/radeon/radeon_vm.c | 16 
 6 files changed, 18 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index da2c9e295408..be583695427a 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -244,9 +244,8 @@ static void atombios_blank_crtc(struct drm_crtc *crtc, int 
state)
 
atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t 
*));
 
-   if (ASIC_IS_DCE8(rdev)) {
+   if (ASIC_IS_DCE8(rdev))
WREG32(vga_control_regs[radeon_crtc->crtc_id], vga_control);
-   }
 }
 
 static void atombios_powergate_crtc(struct drm_crtc *crtc, int state)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 6f38375c77c8..39b342b5c495 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -816,9 +816,8 @@ void radeon_dp_link_train(struct drm_encoder *encoder,
dp_info.use_dpencoder = true;
index = GetIndexIntoMasterTable(COMMAND, DPEncoderService);
if (atom_parse_cmd_header(rdev->mode_info.atom_context, index, , 
)) {
-   if (crev > 1) {
+   if (crev > 1)
dp_info.use_dpencoder = false;
-   }
}
 
dp_info.enc_id = 0;
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 2a7be5d5e7e6..cc5ee1b3af84 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1885,11 +1885,10 @@ atombios_set_encoder_crtc_source(struct drm_encoder 
*encoder)
if (ASIC_IS_AVIVO(rdev))
args.v1.ucCRTC = radeon_crtc->crtc_id;
else {
-   if (radeon_encoder->encoder_id == 
ENCODER_OBJECT_ID_INTERNAL_DAC1) {
+   if (radeon_encoder->encoder_id == 
ENCODER_OBJECT_ID_INTERNAL_DAC1)
args.v1.ucCRTC = radeon_crtc->crtc_id;
-   } else {
+   else
args.v1.ucCRTC = radeon_crtc->crtc_id 
<< 2;
-   }
}
switch (radeon_encoder->encoder_id) {
case ENCODER_OBJECT_ID_INTERNAL_TMDS1:
@@ -2234,9 +2233,9 @@ int radeon_atom_pick_dig_encoder(struct drm_encoder 
*encoder, int fe_idx)
DRM_ERROR("Got encoder index incorrect - returning 0\n");
return 0;
}
-   if (rdev->mode_info.active_encoders & (1 << enc_idx)) {
+   if (rdev->mode_info.active_encoders & (1 << enc_idx))
DRM_ERROR("chosen encoder in use %d\n", enc_idx);
-   }
+
rdev->mode_info.active_encoders |= (1 << enc_idx);
return enc_idx;
 }
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 90d2f732affb..fe12d9d91d7a 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -700,9 +700,9 @@ static int radeon_connector_set_property(struct 
drm_connector *connector, struct
else
ret = 
radeon_legacy_get_tmds_info_from_combios(radeon_encoder, tmds);
}
-   if (val == 1 || !ret) {
+   if (val == 1 || !ret)
radeon_legacy_get_tmds_info_from_table(radeon_encoder, 
tmds);
-   }
+
radeon_property_change_mode(_encoder->base);
}
 
diff --git a/drivers/gpu/drm/radeon/radeon_vce.c 
b/drivers/gpu/drm/radeon/radeon_vce.c
index 59db54ace428..5e8006444704 100644
--- a/drivers/gpu/drm/radeon/radeon_vce.c
+++ b/drivers/gpu/drm/radeon/radeon_vce.c
@@ -388,9 +388,9 @@ int radeon_vce_get_create_msg(struct radeon_device *rdev, 
int ring,
ib.ptr[i] = cpu_to_le32(0x0);
 
r = radeon_ib_schedule(rdev, , NULL, false);
-   if (r) {
+   if (r)
DRM_ERROR("radeon: failed to schedule ib (%d).\n", r);
-   }
+
 
if (fence)
*fence = radeon_fence_ref(ib.fence);
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index e0ad547786e8..f60fae0aed11 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -296,9 +296,9 @@ struct 

[PATCH v2] drm/nouveau: declare constants as unsigned long long.

2020-01-04 Thread Wambui Karuga
Explicitly declare constants as unsigned long long to address the
following sparse warnings:
warning: constant is so big it is long

v2: convert to unsigned long long for compatibility with 32-bit
architectures.

Signed-off-by: Wambui Karuga 
Suggested by: lia Mirkin 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c | 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c | 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c | 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c | 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c | 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
index ac87a3b6b7c9..ba43fe158b22 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
@@ -655,7 +655,7 @@ gf100_ram_new_(const struct nvkm_ram_func *func,
 
 static const struct nvkm_ram_func
 gf100_ram = {
-   .upper = 0x02,
+   .upper = 0x02ULL,
.probe_fbp = gf100_ram_probe_fbp,
.probe_fbp_amount = gf100_ram_probe_fbp_amount,
.probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c
index 70a06e3cd55a..d97fa43efb91 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c
@@ -43,7 +43,7 @@ gf108_ram_probe_fbp_amount(const struct nvkm_ram_func *func, 
u32 fbpao,
 
 static const struct nvkm_ram_func
 gf108_ram = {
-   .upper = 0x02,
+   .upper = 0x02ULL,
.probe_fbp = gf100_ram_probe_fbp,
.probe_fbp_amount = gf108_ram_probe_fbp_amount,
.probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
index 456aed1f2a02..d350d92852d2 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
@@ -1698,7 +1698,7 @@ gk104_ram_new_(const struct nvkm_ram_func *func, struct 
nvkm_fb *fb,
 
 static const struct nvkm_ram_func
 gk104_ram = {
-   .upper = 0x02,
+   .upper = 0x02ULL,
.probe_fbp = gf100_ram_probe_fbp,
.probe_fbp_amount = gf108_ram_probe_fbp_amount,
.probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c
index 27c68e3f9772..be91da854dca 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c
@@ -33,7 +33,7 @@ gm107_ram_probe_fbp(const struct nvkm_ram_func *func,
 
 static const struct nvkm_ram_func
 gm107_ram = {
-   .upper = 0x10,
+   .upper = 0x10ULL,
.probe_fbp = gm107_ram_probe_fbp,
.probe_fbp_amount = gf108_ram_probe_fbp_amount,
.probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c
index 6b0cac1fe7b4..8f91ea91ee25 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c
@@ -48,7 +48,7 @@ gm200_ram_probe_fbp_amount(const struct nvkm_ram_func *func, 
u32 fbpao,
 
 static const struct nvkm_ram_func
 gm200_ram = {
-   .upper = 0x10,
+   .upper = 0x10ULL,
.probe_fbp = gm107_ram_probe_fbp,
.probe_fbp_amount = gm200_ram_probe_fbp_amount,
.probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c
index adb62a6beb63..378f6fb70990 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c
@@ -79,7 +79,7 @@ gp100_ram_probe_fbpa(struct nvkm_device *device, int fbpa)
 
 static const struct nvkm_ram_func
 gp100_ram = {
-   .upper = 0x10,
+   .upper = 0x10ULL,
.probe_fbp = gm107_ram_probe_fbp,
.probe_fbp_amount = gm200_ram_probe_fbp_amount,
.probe_fbpa_amount = gp100_ram_probe_fbpa,
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 204849] amdgpu (RX560X) traceboot in dmesg boot output, system instability

2020-01-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=204849

--- Comment #3 from Justin Clift (jus...@postgresql.org) ---
As an extra data point with this, the error in my case only happens when I have
an external monitor plugged in via the HDMI port.

This is on a laptop, with the error not showing up if only the in-built display
is in use.  eg the HDMI not even plugged in.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/2] drm/nouveau: Add HD-audio component notifier support

2020-01-04 Thread Takashi Iwai
On Sat, 04 Jan 2020 00:01:14 +0100,
Lyude Paul wrote:
> 
> Got shown this patch at work and realized it still needed review, so I went
> ahead and did that :)
> 
> Reviewed-by: Lyude Paul 

Thanks!

Let me know if the submission of the patch is needed.


Takashi

> 
> On Mon, 2019-07-22 at 16:38 +0200, Takashi Iwai wrote:
> > This patch adds the support for the notification of HD-audio hotplug
> > via the already existing drm_audio_component framework.  This allows
> > us more reliable hotplug notification and ELD transfer without
> > accessing HD-audio bus; it's more efficient, and more importantly, it
> > works without waking up the runtime PM.
> > 
> > The implementation is rather simplistic: nouveau driver provides the
> > get_eld ops for HD-audio, and it notifies the audio hotplug via
> > pin_eld_notify callback upon each nv50_audio_enable() and _disable()
> > call.  As the HD-audio pin assignment seems corresponding to the CRTC,
> > the crtc->index number is passed directly as the zero-based port
> > number.
> > 
> > The bind and unbind callbacks handle the device-link so that it
> > assures the PM call order.
> > 
> > Signed-off-by: Takashi Iwai 
> > ---
> >  drivers/gpu/drm/nouveau/Kconfig |   1 +
> >  drivers/gpu/drm/nouveau/dispnv50/disp.c | 111
> > 
> >  drivers/gpu/drm/nouveau/nouveau_drv.h   |   7 ++
> >  3 files changed, 119 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/nouveau/Kconfig
> > b/drivers/gpu/drm/nouveau/Kconfig
> > index 96b9814e6d06..33ccf11bd70d 100644
> > --- a/drivers/gpu/drm/nouveau/Kconfig
> > +++ b/drivers/gpu/drm/nouveau/Kconfig
> > @@ -16,6 +16,7 @@ config DRM_NOUVEAU
> > select INPUT if ACPI && X86
> > select THERMAL if ACPI && X86
> > select ACPI_VIDEO if ACPI && X86
> > +   select SND_HDA_COMPONENT if SND_HDA_CORE
> > help
> >   Choose this option for open-source NVIDIA support.
> >  
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > index 8497768f1b41..919f3d3db161 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > @@ -29,6 +29,7 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -466,12 +467,113 @@ nv50_dac_create(struct drm_connector *connector,
> > struct dcb_output *dcbe)
> > return 0;
> >  }
> >  
> > +/*
> > + * audio component binding for ELD notification
> > + */
> > +static void
> > +nv50_audio_component_eld_notify(struct drm_audio_component *acomp, int
> > port)
> > +{
> > +   if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
> > +   acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
> > +port, -1);
> > +}
> > +
> > +static int
> > +nv50_audio_component_get_eld(struct device *kdev, int port, int pipe,
> > +bool *enabled, unsigned char *buf, int max_bytes)
> > +{
> > +   struct drm_device *drm_dev = dev_get_drvdata(kdev);
> > +   struct nouveau_drm *drm = nouveau_drm(drm_dev);
> > +   struct drm_encoder *encoder;
> > +   struct nouveau_encoder *nv_encoder;
> > +   struct nouveau_connector *nv_connector;
> > +   struct nouveau_crtc *nv_crtc;
> > +   int ret = 0;
> > +
> > +   *enabled = false;
> > +   drm_for_each_encoder(encoder, drm->dev) {
> > +   nv_encoder = nouveau_encoder(encoder);
> > +   nv_connector = nouveau_encoder_connector_get(nv_encoder);
> > +   nv_crtc = nouveau_crtc(encoder->crtc);
> > +   if (!nv_connector || !nv_crtc || nv_crtc->index != port)
> > +   continue;
> > +   *enabled = drm_detect_monitor_audio(nv_connector->edid);
> > +   if (*enabled) {
> > +   ret = drm_eld_size(nv_connector->base.eld);
> > +   memcpy(buf, nv_connector->base.eld,
> > +  min(max_bytes, ret));
> > +   }
> > +   break;
> > +   }
> > +   return ret;
> > +}
> > +
> > +static const struct drm_audio_component_ops nv50_audio_component_ops = {
> > +   .get_eld = nv50_audio_component_get_eld,
> > +};
> > +
> > +static int
> > +nv50_audio_component_bind(struct device *kdev, struct device *hda_kdev,
> > + void *data)
> > +{
> > +   struct drm_device *drm_dev = dev_get_drvdata(kdev);
> > +   struct nouveau_drm *drm = nouveau_drm(drm_dev);
> > +   struct drm_audio_component *acomp = data;
> > +
> > +   if (WARN_ON(!device_link_add(hda_kdev, kdev, DL_FLAG_STATELESS)))
> > +   return -ENOMEM;
> > +
> > +   drm_modeset_lock_all(drm_dev);
> > +   acomp->ops = _audio_component_ops;
> > +   acomp->dev = kdev;
> > +   drm->audio.component = acomp;
> > +   drm_modeset_unlock_all(drm_dev);
> > +   return 0;
> > +}
> > +
> > +static void
> > +nv50_audio_component_unbind(struct device *kdev, struct device *hda_kdev,
> > +   void *data)
> > +{
> > +   struct drm_device