Re: [PATCH] drm: panel: Fix bpc for OrtusTech COM43H4M85ULC panel
On Mon, Aug 24, 2020 at 03:32:54AM +0300, Laurent Pinchart wrote:
> The OrtusTech COM43H4M85ULC panel is a 18-bit RGB panel. Commit
> f098f168e91c ("drm: panel: Fix bus format for OrtusTech COM43H4M85ULC
> panel") has fixed the bus formats, but forgot to address the bpc value.
> Set it to 6.
>
> Fixes: f098f168e91c ("drm: panel: Fix bus format for OrtusTech COM43H4M85ULC
> panel")
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 4eabfdd3be2d..723e9c879dfc 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -3024,7 +3024,7 @@ static const struct drm_display_mode
> ortustech_com43h4m85ulc_mode = {
> static const struct panel_desc ortustech_com43h4m85ulc = {
> .modes = _com43h4m85ulc_mode,
> .num_modes = 1,
> - .bpc = 8,
> + .bpc = 6,
> .size = {
> .width = 56,
> .height = 93,
Thanks, applied to drm-misc-next.
Did not see this was material for any -fixes branch.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/2] drm: panel: Add novatek nt36672a panel driver
Hi Sumit. On Wed, Aug 26, 2020 at 09:33:08PM +0530, Sumit Semwal wrote: > Novatek NT36672a is a generic DSI IC that drives command and video mode > panels. Add the driver for it. > > Right now adding support for some Poco F1 phones that have an LCD panel > from Tianma connected with this IC, with a resolution of 1080x2246 that > operates in DSI video mode. > > During testing, Benni Steini helped us fix > the reset sequence timing (from 10ms to 20ms), to get the bootanimation > to work on Android. > > With current AOSP, we need to increase it to 200ms - this seems to be a > safe high value to avoid a white screen occasionally. > > Signed-off-by: Sumit Semwal > Cc: Benni Steini > > --- > v2: increase reset sequence timing to a safe 200ms > v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate > vrefresh on demand. Update for it. > v5: Fixed review comments from Sam: > - rebased on top of drm-misc-next >remove return of drm_panel_add() >remove drm_panel_detach() > - renamed the panel driver file to reflect that this is a novatek >nt36672a display driver and not only for tianma panels. >Adjusted some internal names also to reflect the same. > - corrected changelog to add info about the generic Novatek DSI IC > - corrected compatible string accordingly > - removed pinctrl > - used drm_panel* API for prepare/unprepare/disable/remove Thanks for the detailed follow-up - very nice. A few things slipped thought last review and we have gained support for dv_err_probe() now. Also dev_err() and friends are now the right choice for panel drivers. Sam > --- > MAINTAINERS | 7 + > drivers/gpu/drm/panel/Kconfig | 10 + > drivers/gpu/drm/panel/Makefile| 1 + > .../gpu/drm/panel/panel-novatek-nt36672a.c| 767 ++ > 4 files changed, 785 insertions(+) > create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672a.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 01fb9ee6b951..aeecade2d65f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5619,6 +5619,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc > F: Documentation/devicetree/bindings/display/ste,mcde.txt > F: drivers/gpu/drm/mcde/ > > +DRM DRIVER FOR TIANMA NT36672A PANELS > +M: Sumit Semwal > +S: Maintained > +T: git git://anongit.freedesktop.org/drm/drm-misc > +F: > Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml > +F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c > + > DRM DRIVER FOR TDFX VIDEO CARDS > S: Orphan / Obsolete > F: drivers/gpu/drm/tdfx/ > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > index 8d97d07c5871..02600f12a063 100644 > --- a/drivers/gpu/drm/panel/Kconfig > +++ b/drivers/gpu/drm/panel/Kconfig > @@ -208,6 +208,16 @@ config DRM_PANEL_NOVATEK_NT35510 > around the Novatek NT35510 display controller, such as some > Hydis panels. > > +config DRM_PANEL_NOVATEK_NT36672A > + tristate "Novatek NT36672A DSI panel" > + depends on OF > + depends on DRM_MIPI_DSI > + depends on BACKLIGHT_CLASS_DEVICE > + help > + Say Y here if you want to enable support for the panels built > + around the Novatek NT36672A display controller, such as some > + Tianma panels used in a few Xiaomi Poco F1 mobile phone. > + > config DRM_PANEL_NOVATEK_NT39016 > tristate "Novatek NT39016 RGB/SPI panel" > depends on OF && SPI > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile > index 15a4e7752951..4a36eb45f670 100644 > --- a/drivers/gpu/drm/panel/Makefile > +++ b/drivers/gpu/drm/panel/Makefile > @@ -19,6 +19,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o > obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o > obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o > obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o > +obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672A) += panel-novatek-nt36672a.o > obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o > obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o > obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o > diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c > b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c > new file mode 100644 > index ..3f0c18e46818 > --- /dev/null > +++ b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c > @@ -0,0 +1,767 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright (C) 2020 Linaro Ltd > + * Author: Sumit Semwal > + * > + * This driver is for the DSI interface to panels using the NT36672A display > driver IC > + * from Novatek. > + * Currently supported are the Tianma FHD+ panels found in some Xiaomi > phones, including > + * some variants of the Poco F1 phone. > + *
Re: [PATCH v5 1/2] dt-bindings: display: panel: Add bindings for Novatek nt36672a
Hi Sumit.
On Wed, Aug 26, 2020 at 09:33:07PM +0530, Sumit Semwal wrote:
> Novatek nt36672a is a display driver IC that can drive DSI panel. It
> is also present in the Tianma video mode panel, which is a FHD+ panel
> with a resolution of 1080x2246 and 6.18 inches size. It is found in
> some of the Poco F1 phones.
>
> This patch adds the display driver for the IC, with support added for
> this tianma fhd video mode panel.
>
> Signed-off-by: Sumit Semwal
> Reviewed-by: Rob Herring
Looks fine, just a few comments in the following.
Should be easy to fix.
Sam
>
> ---
> v2: remove ports node, making port@0 directly under panel@0 node.
> v3: updated to replace port@0 to just 'port'.
> v5: renamed to novatek,nt36672a, since the binding is for the IC and not
> the panel.
> ---
> .../display/panel/novatek,nt36672a.yaml | 81 +++
> 1 file changed, 81 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> new file mode 100644
> index ..7f8d1097bee0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> @@ -0,0 +1,81 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/novatek,nt36672a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Novatek NT36672A based DSI display Panels
> +
> +maintainers:
> + - Sumit Semwal
> +
> +description: |
> + The nt36672a IC from Novatek is a generic DSI Panel IC used to drive dsi
> + panels.
> + Right now, support is added only for a Tianma FHD+ LCD display panel with a
> + resolution of 1080x2246. It is a video mode DSI panel.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +items:
> + - const: tianma,fhd-video
> + - const: novatek,nt36672a
Similar bindings uses following pattaern:
properties:
compatible:
items:
- enum:
- dlink,dir-685-panel
- const: ilitek,ili9322
See ow an "- enum" is used for the part where we expect to add more
compatible in the future. And const for the fixed part.
Notice the indent - this is right.
> +description: This indicates the panel manufacturer of the panel that is
> + in turn using the NT36672A panel driver. This compatible string
> + determines how the NT36672A panel driver is configured for the
> indicated
> + panel. The novatek,nt36672a compatible shall always be provided as a
> fallback.
> +
> + reg: true
> + reset-gpios:
> +description: phandle of gpio for reset line - This should be 8mA, gpio
> + can be configured using mux, pinctrl, pinctrl-names (active high)
add empty line, or rely on the generic description in panel-common.
> + vddio-supply:
> +description: phandle of the regulator that provides the supply voltage
> + Power IC supply
add empty line
> + vddpos-supply:
> +description: phandle of the positive boost supply regulator
add empty line
> + vddneg-supply:
> +description: phandle of the negative boost supply regulator
add empty line
> + port: true
Maybe group all the ": true" properties.
> +
> +required:
> + - compatible
> + - reg
> + - vddi0-supply
> + - vddpos-supply
> + - vddneg-supply
> + - reset-gpios
> + - port
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |+
> +#include
empty line
> +dsi0 {
My personal preference is indent examples with 4 spaces - it increased
readability.
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + panel@0 {
> +compatible = "tianma,fhd-video", "novatek,nt36672a";
> +reg = <0>;
> +vddi0-supply = <_l14a_1p88>;
> +vddpos-supply = <>;
> +vddneg-supply = <>;
> +
> +reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
> +
> +#address-cells = <1>;
> +#size-cells = <0>;
> +port {
> + tianma_nt36672a_in_0: endpoint {
> +remote-endpoint = <_out>;
> + };
> +};
> + };
> +};
> +
> +...
> --
> 2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/ingenic: Fix driver not probing when IPU port is missing
On Thu, Aug 27, 2020 at 01:44:04PM +0200, Paul Cercueil wrote:
> Even if support for the IPU was compiled in, we may run on a device
> (e.g. the Qi LB60) where the IPU is not available, or simply with an old
> devicetree without the IPU node. In that case the ingenic-drm refused to
> probe.
>
> Fix the driver so that it will probe even if the IPU node is not present
> in devicetree (but then IPU support is disabled of course).
>
> v2: Take a different approach
>
> Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
> Signed-off-by: Paul Cercueil
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index c1bcb93aed2d..b7074161ccf0 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -673,7 +673,7 @@ static void ingenic_drm_unbind_all(void *d)
> component_unbind_all(priv->dev, >drm);
> }
>
> -static int ingenic_drm_bind(struct device *dev)
> +static int ingenic_drm_bind(struct device *dev, bool has_components)
> {
> struct platform_device *pdev = to_platform_device(dev);
> const struct jz_soc_info *soc_info;
> @@ -808,7 +808,7 @@ static int ingenic_drm_bind(struct device *dev)
> return ret;
> }
>
> - if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU)) {
> + if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU) && has_components) {
> ret = component_bind_all(dev, drm);
> if (ret) {
> if (ret != -EPROBE_DEFER)
> @@ -939,6 +939,11 @@ static int ingenic_drm_bind(struct device *dev)
> return ret;
> }
>
> +static int ingenic_drm_bind_with_components(struct device *dev)
> +{
> + return ingenic_drm_bind(dev, true);
> +}
> +
> static int compare_of(struct device *dev, void *data)
> {
> return dev->of_node == data;
> @@ -957,7 +962,7 @@ static void ingenic_drm_unbind(struct device *dev)
> }
>
> static const struct component_master_ops ingenic_master_ops = {
> - .bind = ingenic_drm_bind,
> + .bind = ingenic_drm_bind_with_components,
> .unbind = ingenic_drm_unbind,
> };
>
> @@ -968,14 +973,12 @@ static int ingenic_drm_probe(struct platform_device
> *pdev)
> struct device_node *np;
>
> if (!IS_ENABLED(CONFIG_DRM_INGENIC_IPU))
> - return ingenic_drm_bind(dev);
> + return ingenic_drm_bind(dev, false);
>
> /* IPU is at port address 8 */
> np = of_graph_get_remote_node(dev->of_node, 8, 0);
> - if (!np) {
> - dev_err(dev, "Unable to get IPU node\n");
> - return -EINVAL;
> - }
> + if (!np)
> + return ingenic_drm_bind(dev, false);
>
> drm_of_component_match_add(dev, , compare_of, np);
> of_node_put(np);
> --
> 2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/ingenic: Fix leak of device_node pointer
On Thu, Aug 27, 2020 at 01:44:03PM +0200, Paul Cercueil wrote:
> of_graph_get_remote_node() requires of_node_put() to be called on the
> device_node pointer when it's no more in use.
>
> Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
> Signed-off-by: Paul Cercueil
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index ada990a7f911..c1bcb93aed2d 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -978,6 +978,7 @@ static int ingenic_drm_probe(struct platform_device *pdev)
> }
>
> drm_of_component_match_add(dev, , compare_of, np);
> + of_node_put(np);
>
> return component_master_add_with_match(dev, _master_ops, match);
> }
> --
> 2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] dt-bindings: display: samsung,amoled-mipi-dsi: Do not require enable-gpios on samsung,s6e63j0x03
On Sat, Aug 29, 2020 at 07:25:29PM +0200, Krzysztof Kozlowski wrote: > The samsung,s6e63j0x03 does not have enable GPIO, so do not require it. > This fixes dtbs_check warning: > > arch/arm/boot/dts/exynos3250-rinato.dt.yaml: panel@0: 'enable-gpios' is a > required property > > Signed-off-by: Krzysztof Kozlowski Acked-by: Sam Ravnborg I expect this patch is picked up with the dts fixes. Sam > --- > .../display/panel/samsung,amoled-mipi-dsi.yaml | 12 +++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml > > b/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml > index 96bdde9298e0..ccc482570d6a 100644 > --- > a/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml > +++ > b/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml > @@ -12,6 +12,17 @@ maintainers: > allOf: >- $ref: panel-common.yaml# > > + - if: > + properties: > +compatible: > + contains: > +enum: > + - samsung,s6e3ha2 > + - samsung,s6e3hf2 > +then: > + required: > +- enable-gpios > + > properties: >compatible: > enum: > @@ -39,7 +50,6 @@ required: >- vdd3-supply >- vci-supply >- reset-gpios > - - enable-gpios > > additionalProperties: false > > -- > 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: display: simple: Add AM-1280800N3TZQW-T00H
Hi Jagan. On Sat, Aug 29, 2020 at 10:03:27PM +0530, Jagan Teki wrote: > Add dt-bindings for 10.1" TFT LCD module from Ampire Co. Ltd. > as part of panel-simple. > > Signed-off-by: Jagan Teki Thanks for the quick update. Applied both patches to drm-misc-next. Sam > --- > Changes for v2: > - none > > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index d6cca1479633..f629d04f7737 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -29,6 +29,8 @@ properties: > # compatible must be listed in alphabetical order, ordered by compatible. > # The description in the comment is mandatory for each compatible. > > +# Ampire AM-1280800N3TZQW-T00H 10.1" WQVGA TFT LCD panel > + - ampire,am-1280800n3tzqw-t00h > # Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel >- ampire,am-480272h3tmqw-t01h > # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel > -- > 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: Fix the dsi remote end-points
On Fri, Aug 28, 2020 at 01:12:50PM +0530, Vinod Koul wrote:
> DSI end-points are supposed to be at node 0 and node 1 as per binding.
> So fix this and use node 0 and node 1 for dsi.
>
> Reported-by: Dmitry Baryshkov
> Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
> Signed-off-by: Vinod Koul
Thanks, applied to drm-misc-next.
Sam
> ---
> drivers/gpu/drm/bridge/lontium-lt9611.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
> b/drivers/gpu/drm/bridge/lontium-lt9611.c
> index 1009fc4ed4ed..d734d9402c35 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9611.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
> @@ -960,13 +960,13 @@ static const struct drm_bridge_funcs
> lt9611_bridge_funcs = {
> static int lt9611_parse_dt(struct device *dev,
> struct lt9611 *lt9611)
> {
> - lt9611->dsi0_node = of_graph_get_remote_node(dev->of_node, 1, -1);
> + lt9611->dsi0_node = of_graph_get_remote_node(dev->of_node, 0, -1);
> if (!lt9611->dsi0_node) {
> dev_err(lt9611->dev, "failed to get remote node for primary
> dsi\n");
> return -ENODEV;
> }
>
> - lt9611->dsi1_node = of_graph_get_remote_node(dev->of_node, 2, -1);
> + lt9611->dsi1_node = of_graph_get_remote_node(dev->of_node, 1, -1);
>
> lt9611->ac_mode = of_property_read_bool(dev->of_node, "lt,ac-mode");
>
> --
> 2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: rm67191: Remove CLOCK_NON_CONTINUOUS flag
On Fri, Aug 28, 2020 at 05:58:33PM +0300, Robert Chiras (OSS) wrote:
> From: Robert Chiras
>
> The flag MIPI_DSI_CLOCK_NON_CONTINUOUS was wrong used in the DSI driver,
> so it was added to this panel, but not necessary.
> So, remove this flag since it is not needed.
>
> Signed-off-by: Robert Chiras
Thanks, applied to drm-misc-next.
Sam
> ---
> drivers/gpu/drm/panel/panel-raydium-rm67191.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> index 23b6208..572547d 100644
> --- a/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> @@ -552,8 +552,7 @@ static int rad_panel_probe(struct mipi_dsi_device *dsi)
> panel->dsi = dsi;
>
> dsi->format = MIPI_DSI_FMT_RGB888;
> - dsi->mode_flags = MIPI_DSI_MODE_VIDEO_HSE | MIPI_DSI_MODE_VIDEO |
> -MIPI_DSI_CLOCK_NON_CONTINUOUS;
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO_HSE | MIPI_DSI_MODE_VIDEO;
>
> ret = of_property_read_u32(np, "video-mode", _mode);
> if (!ret) {
> --
> 2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209071] Nouveau dual monitor setup: After unlock xscreensaver, VGA-1 remains black
https://bugzilla.kernel.org/show_bug.cgi?id=209071 --- Comment #2 from Oscar Megía (megia.os...@gmail.com) --- I'm not an expert, so I thought that the error by the time could be a issue in video driver. The last kernel was 5.8.1.arch1-1. It was upgraded last sunday. I left mypc 2 hours unattended and when I typed the password in the monitor that before remained black (I can see the password input window), now has the same issue. I searched on journalctl and I didn't see the same error. If fact I don't see anyhing important. I tried executing: xrandr --auto --output VGA-1 --mode 1280x1024 --right-of DVI-D-1 and the desktop swap monitors, but the monitor black still remains black. It could be a hardware error. How can I know if is a hardware error? Regards Oscar -- 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
[Bug 209071] Nouveau dual monitor setup: After unlock xscreensaver, VGA-1 remains black
https://bugzilla.kernel.org/show_bug.cgi?id=209071 Ilia Mirkin (imir...@alum.mit.edu) changed: What|Removed |Added CC||imir...@alum.mit.edu --- Comment #1 from Ilia Mirkin (imir...@alum.mit.edu) --- It appears that the error you pasted is some sort of hang which has nothing to do with nouveau. What indication do you have that nouveau is involved in any way with this issue? What was the previous kernel version that worked fine? -- 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
[RFT 3/4] ARM: dts: exynos: Move CMU assigned ISP clocks to buses in Exynos3250
Commit 52005dece527 ("ARM: dts: Add assigned clock parents to CMU node
for exynos3250") added assigned clocks under Clock Management Unit to
fix hangs when accessing ISP registers.
This is not the place for it as CMU does not have a required "clocks"
property:
arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml: clock-controller@1003:
'clocks' is a dependency of 'assigned-clocks'
Signed-off-by: Krzysztof Kozlowski
---
Not tested and I wonder whether actually correct. For example, what will
happen if devfreq (exynos-bus) is not built in?
Could someone verify it?
---
arch/arm/boot/dts/exynos3250.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index c67c70e46794..6d467022d929 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -214,10 +214,6 @@
compatible = "samsung,exynos3250-cmu";
reg = <0x1003 0x2>;
#clock-cells = <1>;
- assigned-clocks = < CLK_MOUT_ACLK_400_MCUISP_SUB>,
- < CLK_MOUT_ACLK_266_SUB>;
- assigned-clock-parents = < CLK_FIN_PLL>,
-< CLK_FIN_PLL>;
};
cmu_dmc: clock-controller@105c {
@@ -835,6 +831,8 @@
compatible = "samsung,exynos-bus";
clocks = < CLK_DIV_ACLK_400_MCUISP>;
clock-names = "bus";
+ assigned-clocks = < CLK_MOUT_ACLK_400_MCUISP_SUB>;
+ assigned-clock-parents = < CLK_FIN_PLL>;
operating-points-v2 = <_mcuisp_opp_table>;
status = "disabled";
};
@@ -843,6 +841,8 @@
compatible = "samsung,exynos-bus";
clocks = < CLK_DIV_ACLK_266>;
clock-names = "bus";
+ assigned-clocks = < CLK_MOUT_ACLK_266_SUB>;
+ assigned-clock-parents = < CLK_FIN_PLL>;
operating-points-v2 = <_isp_opp_table>;
status = "disabled";
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] dt-bindings: display: samsung, amoled-mipi-dsi: Do not require enable-gpios on samsung, s6e63j0x03
The samsung,s6e63j0x03 does not have enable GPIO, so do not require it. This fixes dtbs_check warning: arch/arm/boot/dts/exynos3250-rinato.dt.yaml: panel@0: 'enable-gpios' is a required property Signed-off-by: Krzysztof Kozlowski --- .../display/panel/samsung,amoled-mipi-dsi.yaml | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml index 96bdde9298e0..ccc482570d6a 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml @@ -12,6 +12,17 @@ maintainers: allOf: - $ref: panel-common.yaml# + - if: + properties: +compatible: + contains: +enum: + - samsung,s6e3ha2 + - samsung,s6e3hf2 +then: + required: +- enable-gpios + properties: compatible: enum: @@ -39,7 +50,6 @@ required: - vdd3-supply - vci-supply - reset-gpios - - enable-gpios additionalProperties: false -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] ARM: dts: exynos: Remove snps, dwc2 compatible in Exynos3250
The binding for DesignWare HS OTG USB 2.0 in Samsung SoCs take only one
compatible. This fixes dtbs_check warnings like:
arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml: hsotg@1248:
compatible: ['samsung,s3c6400-hsotg', 'snps,dwc2'] is not valid under any
of the given schemas (Possible causes of the failure):
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos3250.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 6d467022d929..78734c132822 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -350,7 +350,7 @@
};
hsotg: hsotg@1248 {
- compatible = "samsung,s3c6400-hsotg", "snps,dwc2";
+ compatible = "samsung,s3c6400-hsotg";
reg = <0x1248 0x2>;
interrupts = ;
clocks = < CLK_USBOTG>;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFT 2/4] ARM: dts: exynos: Move fixed clocks under root node in Exynos3250
The fixed clocks are kept under dedicated node fixed-rate-clocks, thus a
fake "reg" was added. This is not correct with dtschema as fixed-clock
binding does not have a "reg" property:
arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml: clock@0: 'reg' does not
match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos3250.dtsi | 42 +--
1 file changed, 17 insertions(+), 25 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index d3fb45a56527..c67c70e46794 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -97,33 +97,25 @@
};
};
- fixed-rate-clocks {
- #address-cells = <1>;
- #size-cells = <0>;
-
- xusbxti: clock@0 {
- compatible = "fixed-clock";
- reg = <0>;
- clock-frequency = <0>;
- #clock-cells = <0>;
- clock-output-names = "xusbxti";
- };
+ xusbxti: clock-0 {
+ compatible = "fixed-clock";
+ clock-frequency = <0>;
+ #clock-cells = <0>;
+ clock-output-names = "xusbxti";
+ };
- xxti: clock@1 {
- compatible = "fixed-clock";
- reg = <1>;
- clock-frequency = <0>;
- #clock-cells = <0>;
- clock-output-names = "xxti";
- };
+ xxti: clock-1 {
+ compatible = "fixed-clock";
+ clock-frequency = <0>;
+ #clock-cells = <0>;
+ clock-output-names = "xxti";
+ };
- xtcxo: clock@2 {
- compatible = "fixed-clock";
- reg = <2>;
- clock-frequency = <0>;
- #clock-cells = <0>;
- clock-output-names = "xtcxo";
- };
+ xtcxo: clock-2 {
+ compatible = "fixed-clock";
+ clock-frequency = <0>;
+ #clock-cells = <0>;
+ clock-output-names = "xtcxo";
};
pmu {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] dt-bindings: display: simple: Add AM-1280800N3TZQW-T00H
Add dt-bindings for 10.1" TFT LCD module from Ampire Co. Ltd. as part of panel-simple. Signed-off-by: Jagan Teki --- Changes for v2: - none .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index d6cca1479633..f629d04f7737 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -29,6 +29,8 @@ properties: # compatible must be listed in alphabetical order, ordered by compatible. # The description in the comment is mandatory for each compatible. +# Ampire AM-1280800N3TZQW-T00H 10.1" WQVGA TFT LCD panel + - ampire,am-1280800n3tzqw-t00h # Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel - ampire,am-480272h3tmqw-t01h # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/panel: simple: Add AM-1280800N3TZQW-T00H
Add Ampire, AM-1280800N3TZQW-T00H 10.1" TFT LCD panel timings.
Signed-off-by: Jagan Teki
---
Changes for v2:
- dropped vrefresh
- add bus_flags, connector_type
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index b6ecd1552132..b106142b11ca 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -592,6 +592,32 @@ static void panel_simple_shutdown(struct device *dev)
drm_panel_unprepare(>base);
}
+static const struct drm_display_mode ampire_am_1280800n3tzqw_t00h_mode = {
+ .clock = 71100,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 40,
+ .hsync_end = 1280 + 40 + 80,
+ .htotal = 1280 + 40 + 80 + 40,
+ .vdisplay = 800,
+ .vsync_start = 800 + 3,
+ .vsync_end = 800 + 3 + 10,
+ .vtotal = 800 + 3 + 10 + 10,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc ampire_am_1280800n3tzqw_t00h = {
+ .modes = _am_1280800n3tzqw_t00h_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct drm_display_mode ampire_am_480272h3tmqw_t01h_mode = {
.clock = 9000,
.hdisplay = 480,
@@ -3637,6 +3663,9 @@ static const struct panel_desc arm_rtsm = {
static const struct of_device_id platform_of_match[] = {
{
+ .compatible = "ampire,am-1280800n3tzqw-t00h",
+ .data = _am_1280800n3tzqw_t00h,
+ }, {
.compatible = "ampire,am-480272h3tmqw-t01h",
.data = _am_480272h3tmqw_t01h,
}, {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next 473/599] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:408:9: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: b8bccd965ee3a8e17af971e55ec8df9e425dec5c
commit: e098bc9612c2b60f94920461d71c92962a916e73 [473/599] drm/amd/pm: optimize
the power related source code layout
config: arm-randconfig-s031-20200829 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-191-g10164920-dirty
git checkout e098bc9612c2b60f94920461d71c92962a916e73
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:65:25:
sparse: sparse: cast to restricted __be32
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:65:25:
sparse: sparse: cast to restricted __be32
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:65:25:
sparse: sparse: cast to restricted __be32
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:65:25:
sparse: sparse: cast to restricted __be32
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:65:25:
sparse: sparse: cast to restricted __be32
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:65:25:
sparse: sparse: cast to restricted __be32
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:74:26:
sparse: sparse: cast to restricted __be32
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:74:26:
sparse: sparse: cast to restricted __be32
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:74:26:
sparse: sparse: cast to restricted __be32
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:74:26:
sparse: sparse: cast to restricted __be32
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:74:26:
sparse: sparse: cast to restricted __be32
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:74:26:
sparse: sparse: cast to restricted __be32
>> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:408:9:
>> sparse: sparse: incorrect type in argument 1 (different address spaces) @@
>> expected void volatile [noderef] __iomem *to @@ got void *kaddr @@
>> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:408:9:
>> sparse: expected void volatile [noderef] __iomem *to
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:408:9:
sparse: got void *kaddr
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex drm-next
git checkout e098bc9612c2b60f94920461d71c92962a916e73
vim +408 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c
1ff55f465103782 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2016-08-19 321
d3f8c0abf45866d drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2017-09-20 322 int smu7_request_smu_load_fw(struct pp_hwmgr *hwmgr)
1ff55f465103782 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2016-08-19 323 {
b3b030520df05fc drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2017-09-26 324struct smu7_smumgr *smu_data = (struct smu7_smumgr
*)(hwmgr->smu_backend);
1ff55f465103782 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2016-08-19 325uint32_t fw_to_load;
d92867122cd9524 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Alex Deucher
2018-07-12 326int r = 0;
1ff55f465103782 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2016-08-19 327
744a522794bdc64 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2018-09-29 328amdgpu_ucode_init_bo(hwmgr->adev);
744a522794bdc64 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2018-09-29 329
1ff55f465103782 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2016-08-19 330if (smu_data->soft_regs_start)
d3f8c0abf45866d drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2017-09-20 331cgs_write_ind_register(hwmgr->device,
CGS_IND_REG__SMC,
d3f8c0abf45866d drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2017-09-20 332
smu_data->soft_regs_start + smum_get_offsetof(hwmgr,
1ff55f465103782 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2016-08-19 333SMU_SoftRegisters,
UcodeLoadStatus),
1ff55f465103782 drivers/gpu/drm/amd/powerplay/
[Bug 209071] New: Nouveau dual monitor setup: After unlock xscreensaver, VGA-1 remains black
https://bugzilla.kernel.org/show_bug.cgi?id=209071 Bug ID: 209071 Summary: Nouveau dual monitor setup: After unlock xscreensaver, VGA-1 remains black Product: Drivers Version: 2.5 Kernel Version: 5.8.3-arch1-1 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: megia.os...@gmail.com Regression: No Created attachment 292209 --> https://bugzilla.kernel.org/attachment.cgi?id=292209=edit output from lshw I have archlinux upgraded system last sunday. Today after unlock xscreensaver on OpenBox, the screen connected to VGA-1 port remained black. I need to switch off and switch on mypc to make work it. The is the log from journalctl: ago 29 15:13:17 mypc kernel: [ cut here ] ago 29 15:13:17 mypc kernel: NETDEV WATCHDOG: enp3s0 (r8169): transmit queue 0 timed out ago 29 15:13:17 mypc kernel: WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:442 dev_watchdog+0x26d/0x280 ago 29 15:13:17 mypc kernel: Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_seq_device fuse rfkill squashfs loop nouveau snd_hda_codec_analog snd_hda_codec_generic pktcdvd ledtrig_audio iTCO_wdt snd_hda_codec_hdmi mxm_wmi intel_pmc_bxt ppdev mousedev wmi i2c_algo_bit gpio_ich iTCO_vendor_support snd_hda_intel ttm snd_intel_dspcfg snd_hda_codec drm_kms_helper snd_hda_core input_leds cec r8169 snd_hwdep snd_pcm rc_core snd_timer syscopyarea snd sysfillrect sysimgblt fb_sys_fops realtek soundcore evdev libphy parport_pc mac_hid parport asus_atk0110 intel_agp lpc_ich i2c_i801 intel_gtt i2c_smbus acpi_cpufreq drm sg agpgart crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 uas usb_storage hid_generic usbhid hid sr_mod cdrom ata_generic pata_acpi dm_mod serio_raw atkbd libps2 uhci_hcd pata_jmicron ehci_pci ehci_hcd i8042 serio ago 29 15:13:17 mypc kernel: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.8.3-arch1-1 #1 ago 29 15:13:17 mypc kernel: Hardware name: System manufacturer System Product Name/P5B, BIOS 210403/09/2009 ago 29 15:13:17 mypc kernel: RIP: 0010:dev_watchdog+0x26d/0x280 ago 29 15:13:17 mypc kernel: Code: d8 9b 75 ff eb 85 4c 89 f7 c6 05 b3 df 08 01 01 e8 e8 c7 fa ff 44 89 e9 4c 89 f6 48 c7 c7 70 4a a1 89 48 89 c2 e8 39 76 7e ff <0f> 0b e9 63 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 ago 29 15:13:17 mypc kernel: RSP: 0018:b332400ece90 EFLAGS: 00010286 ago 29 15:13:17 mypc kernel: RAX: RBX: 9e51f485ac00 RCX: ago 29 15:13:17 mypc kernel: RDX: 0103 RSI: 8996a47f RDI: ago 29 15:13:17 mypc kernel: RBP: 9e51f51d23dc R08: 0433 R09: 0003 ago 29 15:13:17 mypc kernel: R10: R11: 0001 R12: 9e51f51d2480 ago 29 15:13:17 mypc kernel: R13: R14: 9e51f51d2000 R15: 9e51f485ac80 ago 29 15:13:17 mypc kernel: FS: () GS:9e51f7c8() knlGS: ago 29 15:13:17 mypc kernel: CS: 0010 DS: ES: CR0: 80050033 ago 29 15:13:17 mypc kernel: CR2: 7f2a199ab28c CR3: 0001b2a2a000 CR4: 06e0 ago 29 15:13:17 mypc kernel: Call Trace: ago 29 15:13:17 mypc kernel: ago 29 15:13:17 mypc kernel: ? pfifo_fast_init+0x110/0x110 ago 29 15:13:17 mypc kernel: ? pfifo_fast_init+0x110/0x110 ago 29 15:13:17 mypc kernel: call_timer_fn+0x2d/0x160 ago 29 15:13:17 mypc kernel: ? pfifo_fast_init+0x110/0x110 ago 29 15:13:17 mypc kernel: __run_timers+0x193/0x290 ago 29 15:13:17 mypc kernel: run_timer_softirq+0x2b/0x50 ago 29 15:13:17 mypc kernel: __do_softirq+0xff/0x340 ago 29 15:13:17 mypc kernel: asm_call_on_stack+0x12/0x20 ago 29 15:13:17 mypc kernel: ago 29 15:13:17 mypc kernel: do_softirq_own_stack+0x5f/0x80 ago 29 15:13:17 mypc kernel: irq_exit_rcu+0xcb/0x120 ago 29 15:13:17 mypc kernel: sysvec_apic_timer_interrupt+0x46/0xe0 ago 29 15:13:17 mypc kernel: asm_sysvec_apic_timer_interrupt+0x12/0x20 ago 29 15:13:17 mypc kernel: RIP: 0010:native_safe_halt+0xe/0x10 ago 29 15:13:17 mypc kernel: Code: f0 80 48 02 20 48 8b 00 a8 08 75 c3 e9 7a ff ff ff cc cc cc cc cc cc cc cc cc cc cc e9 07 00 00 00 0f 00 2d 86 da 5f 00 fb f4 90 e9 07 00 00 00 0f 00 2d 76 da 5f 00 f4 c3 cc cc 0f 1f 44 00 ago 29 15:13:17 mypc kernel: RSP: 0018:b33240097e20 EFLAGS: 0246 ago 29 15:13:17 mypc kernel: RAX: 4000 RBX: 0001 RCX: 001f ago 29 15:13:17 mypc kernel: RDX: 4ec4ec4ec4ec4ec5 RSI: 89a04c55 RDI: 8999c80e ago 29 15:13:17 mypc kernel: RBP: 9e51f65b1c00 R08: 1aee947ef30b R09: 0008 ago 29 15:13:17 mypc kernel: R10: 2a48 R11: 0009 R12: 9e51f65b1c64 ago 29 15:13:17 mypc kernel: R13:
[Bug 201497] [amdgpu]: '*ERROR* No EDID read' is back in 4.19
https://bugzilla.kernel.org/show_bug.cgi?id=201497 Mike Starr (starrten...@gmail.com) changed: What|Removed |Added CC||starrten...@gmail.com --- Comment #16 from Mike Starr (starrten...@gmail.com) --- I have traced my personal version of this bug down to my Acer monitor and Logitech gamepad. Both are detected, but only the monitor works. The error spits out toward the end of dmesg about ten times in a row, twice. Thank you. -- 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
[PATCH 08/10] arm64: dts: exynos: Add compatibles to sysreg nodes
System register nodes, implementing syscon binding, should use
appropriate compatible. This fixes dtbs_check warnings:
arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: syscon@13b8:
compatible: ['syscon'] is not valid under any of the given schemas
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 74ac4ac75865..b2eebdd88c3c 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -1015,17 +1015,17 @@
};
syscon_disp: syscon@13b8 {
- compatible = "syscon";
+ compatible = "samsung,exynos5433-sysreg", "syscon";
reg = <0x13b8 0x1010>;
};
syscon_cam0: syscon@120f {
- compatible = "syscon";
+ compatible = "samsung,exynos5433-sysreg", "syscon";
reg = <0x120f 0x1020>;
};
syscon_cam1: syscon@145f {
- compatible = "syscon";
+ compatible = "samsung,exynos5433-sysreg", "syscon";
reg = <0x145f 0x1038>;
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/10] dt-bindings: sound: samsung-i2s: Use unevaluatedProperties
Additional properties actually might appear (e.g. power-domains) so use
unevaluatedProperties to fix dtbs_check warnings like:
arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: i2s@1144:
Additional properties are not allowed ('power-domains', '#address-cells',
'interrupts', '#size-cells' were unexpected)
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/sound/samsung-i2s.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.yaml
b/Documentation/devicetree/bindings/sound/samsung-i2s.yaml
index b2ad093d94df..16dc81288115 100644
--- a/Documentation/devicetree/bindings/sound/samsung-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/samsung-i2s.yaml
@@ -115,7 +115,7 @@ required:
- clocks
- clock-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/10] dt-bindings: connector: Convert Samsung 11-pin USB bindings to dtschema
Add Samsung 11-pin USB-C connector into standard dtschema bindings file.
Signed-off-by: Krzysztof Kozlowski
---
.../connector/samsung,usb-connector-11pin.txt | 49 ---
.../bindings/connector/usb-connector.yaml | 44 +
2 files changed, 44 insertions(+), 49 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
diff --git
a/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
b/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
deleted file mode 100644
index 3dd8961154ab..
---
a/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-Samsung micro-USB 11-pin connector
-==
-
-Samsung micro-USB 11-pin connector is an extension of micro-USB connector.
-It is present in multiple Samsung mobile devices.
-It has additional pins to route MHL traffic simultanously with USB.
-
-The bindings are superset of usb-connector bindings for micro-USB connector[1].
-
-Required properties:
-- compatible: must be: "samsung,usb-connector-11pin", "usb-b-connector",
-- type: must be "micro".
-
-Required nodes:
-- any data bus to the connector should be modeled using the OF graph bindings
- specified in bindings/graph.txt, unless the bus is between parent node and
- the connector. Since single connector can have multpile data buses every bus
- has assigned OF graph port number as follows:
-0: High Speed (HS),
-3: Mobile High-Definition Link (MHL), specific to 11-pin Samsung micro-USB.
-
-[1]: bindings/connector/usb-connector.yaml
-
-Example
-
-Micro-USB connector with HS lines routed via controller (MUIC) and MHL lines
-connected to HDMI-MHL bridge (sii8620):
-
-muic-max77843@66 {
- ...
- usb_con: connector {
- compatible = "samsung,usb-connector-11pin", "usb-b-connector";
- label = "micro-USB";
- type = "micro";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@3 {
- reg = <3>;
- usb_con_mhl: endpoint {
- remote-endpoint = <_mhl>;
- };
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml
b/Documentation/devicetree/bindings/connector/usb-connector.yaml
index 9bd52e63c935..dc6ff64422d4 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
+++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
@@ -25,6 +25,10 @@ properties:
- const: gpio-usb-b-connector
- const: usb-b-connector
+ - items:
+ - const: samsung,usb-connector-11pin
+ - const: usb-b-connector
+
label:
description: Symbolic name for the connector.
@@ -158,6 +162,16 @@ allOf:
- required:
- id-gpios
+ - if:
+ properties:
+compatible:
+ contains:
+const: samsung,usb-connector-11pin
+then:
+ properties:
+type:
+ const: micro
+
examples:
# Micro-USB connector with HS lines routed via controller (MUIC).
- |
@@ -233,3 +247,33 @@ examples:
vbus-supply = <_p0_vbus>;
};
};
+
+ # Micro-USB connector with HS lines routed via controller (MUIC) and MHL
+ # lines connected to HDMI-MHL bridge (sii8620) on Samsung Exynos5433-based
+ # mobile phone
+ - |
+muic-max77843 {
+ usb_con4: connector {
+compatible = "samsung,usb-connector-11pin", "usb-b-connector";
+label = "micro-USB";
+type = "micro";
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+muic_to_usb: endpoint {
+ remote-endpoint = <_to_muic>;
+};
+ };
+ port@3 {
+reg = <3>;
+usb_con_mhl: endpoint {
+ remote-endpoint = <_mhl>;
+};
+ };
+};
+ };
+};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFT 09/10] arm64: dts: exynos: Correct port of USB-C connector node on Exynos5433 TM2
The USB-C connector bindings require port@0. Such port was already
described in DTS but outside of the connector itself. Put it into
proper place to fix dtbs_check warnings like:
arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: musb_connector: ports:
'port@0' is a required property
Signed-off-by: Krzysztof Kozlowski
---
Not tested on HQ. Please kindly review and test.
Best regards,
Krzysztof
---
.../boot/dts/exynos/exynos5433-tm2-common.dtsi| 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 6246cce2a15e..bab6c1addd5f 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -871,6 +871,13 @@
#address-cells = <1>;
#size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ muic_to_usb: endpoint {
+ remote-endpoint =
<_to_muic>;
+ };
+ };
+
port@3 {
reg = <3>;
musb_con_to_mhl: endpoint {
@@ -879,14 +886,6 @@
};
};
};
-
- ports {
- port {
- muic_to_usb: endpoint {
- remote-endpoint =
<_to_muic>;
- };
- };
- };
};
regulators {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/10] arm64: dts: exynos: Replace deprecated "gpios" i2c-gpio property in Exynos5433
"gpios" property is deprecated. Update the Exynos5433 DTS to fix
dtbs_checks warnings like:
arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: i2c-gpio-0: 'sda-gpios' is
a required property
arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: i2c-gpio-0: 'scl-gpios' is
a required property
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 250fc01de78d..6246cce2a15e 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -87,8 +87,8 @@
i2c_max98504: i2c-gpio-0 {
compatible = "i2c-gpio";
- gpios = < 1 GPIO_ACTIVE_HIGH /* SPK_AMP_SDA */
- 0 GPIO_ACTIVE_HIGH /* SPK_AMP_SCL */ >;
+ sda-gpios = < 1 GPIO_ACTIVE_HIGH>;
+ scl-gpios = < 0 GPIO_ACTIVE_HIGH>;
i2c-gpio,delay-us = <2>;
#address-cells = <1>;
#size-cells = <0>;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFT 10/10] arm64: dts: exynos: Enable Arizona interrupt controller in Exynos5433 TM2
The Wolfson Arizona codec is interrupt controller which is required by bindings. This fixes dtbs_check warnings like: arch/arm64/boot/dts/exynos/exynos5433-tm2e.dt.yaml: wm5110-codec@0: 'interrupt-controller' is a required property arch/arm64/boot/dts/exynos/exynos5433-tm2e.dt.yaml: wm5110-codec@0: '#interrupt-cells' is a required property Signed-off-by: Krzysztof Kozlowski --- Not tested on HQ. Please kindly review and test. Best regards, Krzysztof --- arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi index bab6c1addd5f..49cd55d6891c 100644 --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi @@ -1242,6 +1242,8 @@ gpio-controller; #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; wlf,micd-detect-debounce = <300>; wlf,micd-bias-start-time = <0x1>; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/10] dt-bindings: gpu: arm, mali-midgard: Use unevaluatedProperties
Additional properties or nodes actually might appear (e.g. operating points table) so use unevaluatedProperties to fix dtbs_check warnings like: arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: gpu@14ac: 'opp_table' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml index 80d519a76db2..c60300ffd764 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml @@ -96,7 +96,7 @@ required: - interrupt-names - clocks -additionalProperties: false +unevaluatedProperties: false allOf: - if: -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/10] dt-bindings: timer: exynos4210-mct: Use unevaluatedProperties
Additional properties actually might appear (e.g. clocks) so use unevaluatedProperties to fix dtbs_check warnings like: arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: timer@101c: 'clock-names', 'clocks' do not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/timer/samsung,exynos4210-mct.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml index 37bd01a62c52..f46373fca95a 100644 --- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml +++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml @@ -52,7 +52,7 @@ required: - interrupts - reg -additionalProperties: false +unevaluatedProperties: false examples: - | -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/10] dt-bindings: arm: samsung: pmu: Use unevaluatedProperties
Additional properties actually might appear (e.g. assigned-clocks) so use unevaluatedProperties to fix dtbs_check warnings like: arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: system-controller@105c: 'assigned-clock-parents', 'assigned-clocks' do not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/arm/samsung/pmu.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.yaml b/Documentation/devicetree/bindings/arm/samsung/pmu.yaml index 686c13c14e32..30ff2da81416 100644 --- a/Documentation/devicetree/bindings/arm/samsung/pmu.yaml +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.yaml @@ -86,7 +86,7 @@ required: - compatible - reg -additionalProperties: false +unevaluatedProperties: false allOf: - if: -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/10] dt-bindings: mfd: syscon: Document Samsung Exynos compatibles
Samsung Exynos SoCs use syscon for system registers so document its compatibles. Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/mfd/syscon.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index 049ec2ffc7f9..0f21943dea28 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -40,6 +40,10 @@ properties: - allwinner,sun50i-a64-system-controller - microchip,sparx5-cpu-syscon - mstar,msc313-pmsleep + - samsung,exynos3-sysreg + - samsung,exynos4-sysreg + - samsung,exynos5-sysreg + - samsung,exynos5433-sysreg - const: syscon -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vkms: add support for gamma_set interface
Currently vkms module doesn't support gamma function for userspace. so igt
subtests in kms_plane(pixel-format-pipe-A-plan) failed for calling
drmModeCrtcSetGamma(). This patch set gamma_set interface in vkms_crtc_funcs for
support gamma function. With initializing crtc, added calls for setting gamma
size. it pass the test after this patch.
Cc: Daniel Vetter
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Signed-off-by: Sidong Yang
---
drivers/gpu/drm/vkms/vkms_crtc.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index ac85e17428f8..643435fb2ee6 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -160,6 +160,7 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
.get_crc_sources= vkms_get_crc_sources,
.set_crc_source = vkms_set_crc_source,
.verify_crc_source = vkms_verify_crc_source,
+ .gamma_set = drm_atomic_helper_legacy_gamma_set,
};
static int vkms_crtc_atomic_check(struct drm_crtc *crtc,
@@ -275,6 +276,13 @@ int vkms_crtc_init(struct drm_device *dev, struct drm_crtc
*crtc,
return ret;
}
+ ret = drm_mode_crtc_set_gamma_size(crtc, 256);
+ if (ret) {
+ DRM_ERROR("Failed to set gamma size\n");
+ return ret;
+ }
+ drm_crtc_enable_color_mgmt(crtc, 0, false, 256);
+
drm_crtc_helper_add(crtc, _crtc_helper_funcs);
spin_lock_init(_out->lock);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: rm67191: Remove CLOCK_NON_CONTINUOUS flag
From: Robert Chiras
The flag MIPI_DSI_CLOCK_NON_CONTINUOUS was wrong used in the DSI driver,
so it was added to this panel, but not necessary.
So, remove this flag since it is not needed.
Signed-off-by: Robert Chiras
---
drivers/gpu/drm/panel/panel-raydium-rm67191.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm67191.c
b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
index 23b6208..572547d 100644
--- a/drivers/gpu/drm/panel/panel-raydium-rm67191.c
+++ b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
@@ -552,8 +552,7 @@ static int rad_panel_probe(struct mipi_dsi_device *dsi)
panel->dsi = dsi;
dsi->format = MIPI_DSI_FMT_RGB888;
- dsi->mode_flags = MIPI_DSI_MODE_VIDEO_HSE | MIPI_DSI_MODE_VIDEO |
- MIPI_DSI_CLOCK_NON_CONTINUOUS;
+ dsi->mode_flags = MIPI_DSI_MODE_VIDEO_HSE | MIPI_DSI_MODE_VIDEO;
ret = of_property_read_u32(np, "video-mode", _mode);
if (!ret) {
--
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: bridge: add support for lontium LT9611UXC bridge
On 28/08/2020 17:18, Vinod Koul wrote:
On 28-08-20, 15:04, Dmitry Baryshkov wrote:
+static int lt9611uxc_bridge_attach(struct drm_bridge *bridge,
+ enum drm_bridge_attach_flags flags)
+{
+ struct lt9611uxc *lt9611uxc = bridge_to_lt9611uxc(bridge);
+ int ret;
+
+ if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
+ dev_err(lt9611uxc->dev, "Fix bridge driver to make connector
optional!");
Can we support both modes as I have done in lt9611, that way once the
conversion is done we can drop the init part and support conversion.
I have patch for msm driver to set DRM_BRIDGE_ATTACH_NO_CONNECTOR, you
can use that to test
Probably the message text is misleading. The driver as is does not work
w/o DRM_BRIDGE_ATTACH_NO_CONNECTOR. Do you plan to push that patch into
upstream tree?
+static int lt9611uxc_hdmi_hw_params(struct device *dev, void *data,
+struct hdmi_codec_daifmt *fmt,
+struct hdmi_codec_params *hparms)
+{
+ /*
+* LT9611UXC will automatically detect rate and sample size, so no need
+* to setup anything here.
+*/
+ return 0;
+}
Do we need dummy function?
Yes, this callback is mandatory (and audio_shutdown).
--
With best wishes
Dmitry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH] drm/sun4i: Fix dsi dcs long write function
On Fri, Aug 28, 2020 at 02:35:26PM +0200, Jernej Škrabec wrote:
> Dne petek, 28. avgust 2020 ob 13:24:44 CEST je Ondrej Jirman napisal(a):
> > It's writing too much data. regmap_bulk_write expects number of
> > register sized chunks to write, not a byte sized length of the
> > bounce buffer. Bounce buffer needs to be padded too, so that
> > regmap_bulk_write will not read past the end of the buffer.
> >
> > Signed-off-by: Ondrej Jirman
>
> Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller
> support")
It doesn't really fix anything user visible though, and will not help
the stable branch in any way. It just makes the code more correct.
Though now that you came up with the tag, copypasting it is not that much
work. ;) So I added it.
> should be added. Fix will be then automatically picked into stable releases.
>
> Small nit below.
>
> > ---
> > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 7f13f4d715bf..840fad1b68dd
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > @@ -889,7 +889,7 @@ static int sun6i_dsi_dcs_write_long(struct sun6i_dsi
> > *dsi, regmap_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(0),
> > sun6i_dsi_dcs_build_pkt_hdr(dsi, msg));
> >
> > - bounce = kzalloc(msg->tx_len + sizeof(crc), GFP_KERNEL);
> > + bounce = kzalloc(msg->tx_len + sizeof(crc) + 3, GFP_KERNEL);
>
> It would be nicer to use ALIGN() macro, but I'm fine either way.
Nice idea.
> Reviewed-by: Jernej Skrabec
Thanks. :)
regards,
o.
> Best regards,
> Jernej
>
> > if (!bounce)
> > return -ENOMEM;
> >
> > @@ -900,7 +900,7 @@ static int sun6i_dsi_dcs_write_long(struct sun6i_dsi
> > *dsi, memcpy((u8 *)bounce + msg->tx_len, , sizeof(crc));
> > len += sizeof(crc);
> >
> > - regmap_bulk_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(1), bounce,
> len);
> > + regmap_bulk_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(1), bounce,
> > DIV_ROUND_UP(len, 4)); regmap_write(dsi->regs, SUN6I_DSI_CMD_CTL_REG, len +
> > 4 - 1);
> > kfree(bounce);
>
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Call traces triggered by starting X on 5.8.x kernels - Radeon RX580
Hi All, I hope this is useful. Let me know if you would like me to test anything. Cheers, Adam [2.] Full description of the problem/report: X works but, 6 warnings triggered, in; drivers/gpu/drm/drm_modeset_lock.c:185 drivers/gpu/drm/drm_crtc_helper.c:148 drivers/gpu/drm/drm_crtc_helper.c:108 First one here, refer to dmesg-out.txt in tarball for the rest; [ 28.223717] [ cut here ] [ 28.223722] WARNING: CPU: 15 PID: 844 at drivers/gpu/drm/drm_modeset_lock.c:185 drm_warn_on_modeset_not_all_locked.part.0+0x67/0x70 [ 28.223723] Modules linked in: igb uvcvideo snd_usb_audio videobuf2_vmalloc videobuf2_memops snd_usbmidi_lib videobuf2_v4l2 snd_rawmidi videobuf2_common snd_seq_device snd_hda_codec_realtek kvm_amd snd_hda_codec_generic kvm irqbypass snd_hda_codec_hdmi aesni_intel glue_helper crypto_simd snd_hda_intel cryptd snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer pinctrl_amd sch_fq_codel efivarfs [ 28.223734] CPU: 15 PID: 844 Comm: X Tainted: G T 5.8.4-gentoo #1 [ 28.223735] Hardware name: Micro-Star International Co., Ltd. MS-7C37/X570-A PRO (MS-7C37), BIOS H.70 01/09/2020 [ 28.223736] RIP: 0010:drm_warn_on_modeset_not_all_locked.part.0+0x67/0x70 [ 28.223737] Code: 01 00 00 e8 0b c5 9d ff 84 c0 74 1a 49 8d bc 24 98 01 00 00 e8 fa c4 9d ff 84 c0 74 0d 5b 5d 41 5c c3 0f 0b eb c8 0f 0b eb e2 <0f> 0b 5b 5d 41 5c c3 66 90 8b 05 f2 c2 ad 01 85 c0 75 02 eb 84 c3 [ 28.223738] RSP: 0018:ae22c1217a50 EFLAGS: 00010246 [ 28.223739] RAX: RBX: 92f1f2370af8 RCX: [ 28.223739] RDX: RSI: 92f1f1dce8a0 RDI: 92f1f2370998 [ 28.223740] RBP: 92f1f2370b08 R08: 92f1f16c9d48 R09: 92f1f1f85848 [ 28.223740] R10: R11: R12: 92f1f2370800 [ 28.223741] R13: 0002 R14: 92f1f2370800 R15: 92f1f1dce800 [ 28.223742] FS: 77e6a3f76dc0() GS:92f1febc() knlGS: [ 28.223742] CS: 0010 DS: ES: CR0: 80050033 [ 28.223743] CR2: 644699c64018 CR3: 0007dcb9e000 CR4: 00340ee0 [ 28.223743] Call Trace: [ 28.223745] drm_crtc_helper_set_mode+0x73/0x4b0 [ 28.223748] ? __blk_mq_try_issue_directly+0xfd/0x250 [ 28.223750] ? update_load_avg+0x71/0x5a0 [ 28.223751] ? newidle_balance.constprop.0+0x1eb/0x340 [ 28.223752] ? psi_group_change+0x3a/0x1d0 [ 28.223754] ? kernel_init_free_pages+0x40/0x50 [ 28.223754] ? prep_new_page+0xa3/0xb0 [ 28.223755] ? get_page_from_freelist+0x1125/0x1a60 [ 28.223757] amdgpu_connector_set_property+0x2a8/0x630 [ 28.223758] drm_connector_set_obj_prop+0x39/0x80 [ 28.223759] drm_mode_obj_set_property_ioctl+0x291/0x320 [ 28.223760] ? drm_connector_set_obj_prop+0x80/0x80 [ 28.223761] drm_connector_property_set_ioctl+0x34/0x50 [ 28.223763] drm_ioctl_kernel+0xa3/0xf0 [ 28.223764] drm_ioctl+0x1f9/0x36f [ 28.223764] ? drm_connector_set_obj_prop+0x80/0x80 [ 28.223766] ? handle_mm_fault+0xd65/0x1680 [ 28.223767] amdgpu_drm_ioctl+0x41/0x70 [ 28.223769] ksys_ioctl+0x88/0xc0 [ 28.223769] __x64_sys_ioctl+0x11/0x20 [ 28.223771] do_syscall_64+0x3e/0x70 [ 28.223772] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 28.223773] RIP: 0033:0x77e6a446d747 [ 28.223774] Code: 1f 40 00 48 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b1 e8 0c ff ff ff 85 c0 78 b6 5b 4c 89 e0 5d 41 5c c3 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 76 0c 00 f7 d8 64 89 01 48 [ 28.223775] RSP: 002b:7ffe15738858 EFLAGS: 0246 ORIG_RAX: 0010 [ 28.223776] RAX: ffda RBX: 7ffe15738890 RCX: 77e6a446d747 [ 28.223776] RDX: 7ffe15738890 RSI: c01064ab RDI: 000b [ 28.223777] RBP: c01064ab R08: 644699c61e90 R09: 0001 [ 28.223777] R10: 77e6a4535a60 R11: 0246 R12: 6446996915b0 [ 28.223778] R13: 000b R14: 644699c63c10 R15: 0002 [ 28.223778] ---[ end trace b571c596e5f7bd31 ]--- [3.] Keywords (i.e., modules, networking, kernel): [4.] Kernel information [4.1.] Kernel version (from /proc/version): Linux version 5.8.4-gentoo (root@zen) (gcc (Gentoo 10.2.0-r1 p2) 10.2.0, GNU ld (Gentoo 2.34 p6) 2.34.0) #1 SMP Thu Aug 27 11:20:43 AEST 2020 Pretty sure it started in 5.8.0. [4.2.] Kernel .config file: In tarball [5.] Most recent kernel version which did not have the bug: Likely 5.7.x, however, it is possible that I missed it in other versions since X still runs. [6.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/admin-guide/bug-hunting.rst) full dmesg included in tarball [7.] A small shell script or example program which triggers the startx triggers it [8.] Environment [8.1.] Software (add the output of the ver_linux script here) Linux zen 5.8.4-gentoo #1 SMP Thu Aug 27 11:20:43 AEST 2020
[PATCH v2 3/3] drm: bridge: lt9611uxc: support working without DRM_BRIDGE_ATTACH_NO_CONNECTOR
As the MSM driver does not specify DRM_BRIDGE_ATTACH_NO_CONNECTOR to
bridges, support working without this flag for now.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 80 +-
1 file changed, 78 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index 77c5aa5c6ad7..47a48e440bb3 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -31,6 +31,7 @@
struct lt9611uxc {
struct device *dev;
struct drm_bridge bridge;
+ struct drm_connector connector;
struct regmap *regmap;
/* Protects all accesses to registers by stopping the on-chip MCU */
@@ -105,6 +106,11 @@ static struct lt9611uxc *bridge_to_lt9611uxc(struct
drm_bridge *bridge)
return container_of(bridge, struct lt9611uxc, bridge);
}
+static struct lt9611uxc *connector_to_lt9611uxc(struct drm_connector
*connector)
+{
+ return container_of(connector, struct lt9611uxc, connector);
+}
+
static void lt9611uxc_lock(struct lt9611uxc *lt9611uxc)
{
mutex_lock(>ocm_lock);
@@ -246,6 +252,75 @@ static struct mipi_dsi_device *lt9611uxc_attach_dsi(struct
lt9611uxc *lt9611uxc,
return dsi;
}
+static int lt9611uxc_connector_get_modes(struct drm_connector *connector)
+{
+ struct lt9611uxc *lt9611uxc = connector_to_lt9611uxc(connector);
+ unsigned int count;
+ struct edid *edid;
+
+ if (lt9611uxc->bridge.ops & DRM_BRIDGE_OP_MODES)
+ return lt9611uxc->bridge.funcs->get_modes(>bridge,
connector);
+
+ edid = lt9611uxc->bridge.funcs->get_edid(>bridge, connector);
+ drm_connector_update_edid_property(connector, edid);
+ count = drm_add_edid_modes(connector, edid);
+ kfree(edid);
+
+ return count;
+}
+
+static enum drm_connector_status lt9611uxc_connector_detect(struct
drm_connector *connector,
+ bool force)
+{
+ struct lt9611uxc *lt9611uxc = connector_to_lt9611uxc(connector);
+
+ return lt9611uxc->bridge.funcs->detect(>bridge);
+}
+
+static enum drm_mode_status lt9611uxc_connector_mode_valid(struct
drm_connector *connector,
+ struct
drm_display_mode *mode)
+{
+ struct lt9611uxc_mode *lt9611uxc_mode = lt9611uxc_find_mode(mode);
+
+ return lt9611uxc_mode ? MODE_OK : MODE_BAD;
+}
+
+static const struct drm_connector_helper_funcs
lt9611uxc_bridge_connector_helper_funcs = {
+ .get_modes = lt9611uxc_connector_get_modes,
+ .mode_valid = lt9611uxc_connector_mode_valid,
+};
+
+static const struct drm_connector_funcs lt9611uxc_bridge_connector_funcs = {
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .detect = lt9611uxc_connector_detect,
+ .destroy = drm_connector_cleanup,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int lt9611uxc_connector_init(struct drm_bridge *bridge, struct
lt9611uxc *lt9611uxc)
+{
+ int ret;
+
+ if (!bridge->encoder) {
+ DRM_ERROR("Parent encoder object not found");
+ return -ENODEV;
+ }
+
+ drm_connector_helper_add(>connector,
+_bridge_connector_helper_funcs);
+ ret = drm_connector_init(bridge->dev, >connector,
+_bridge_connector_funcs,
+DRM_MODE_CONNECTOR_HDMIA);
+ if (ret) {
+ DRM_ERROR("Failed to initialize connector with drm\n");
+ return ret;
+ }
+
+ return drm_connector_attach_encoder(>connector,
bridge->encoder);
+}
+
static void lt9611uxc_bridge_detach(struct drm_bridge *bridge)
{
struct lt9611uxc *lt9611uxc = bridge_to_lt9611uxc(bridge);
@@ -266,8 +341,9 @@ static int lt9611uxc_bridge_attach(struct drm_bridge
*bridge,
int ret;
if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
- dev_err(lt9611uxc->dev, "This bridge driver does not support
providing connector!");
- return -EINVAL;
+ ret = lt9611uxc_connector_init(bridge, lt9611uxc);
+ if (ret < 0)
+ return ret;
}
/* Attach primary DSI */
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH] drm/sun4i: Fix dsi dcs long write function
Dne petek, 28. avgust 2020 ob 13:24:44 CEST je Ondrej Jirman napisal(a):
> It's writing too much data. regmap_bulk_write expects number of
> register sized chunks to write, not a byte sized length of the
> bounce buffer. Bounce buffer needs to be padded too, so that
> regmap_bulk_write will not read past the end of the buffer.
>
> Signed-off-by: Ondrej Jirman
Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller
support")
should be added. Fix will be then automatically picked into stable releases.
Small nit below.
> ---
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 7f13f4d715bf..840fad1b68dd
> 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -889,7 +889,7 @@ static int sun6i_dsi_dcs_write_long(struct sun6i_dsi
> *dsi, regmap_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(0),
>sun6i_dsi_dcs_build_pkt_hdr(dsi, msg));
>
> - bounce = kzalloc(msg->tx_len + sizeof(crc), GFP_KERNEL);
> + bounce = kzalloc(msg->tx_len + sizeof(crc) + 3, GFP_KERNEL);
It would be nicer to use ALIGN() macro, but I'm fine either way.
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> if (!bounce)
> return -ENOMEM;
>
> @@ -900,7 +900,7 @@ static int sun6i_dsi_dcs_write_long(struct sun6i_dsi
> *dsi, memcpy((u8 *)bounce + msg->tx_len, , sizeof(crc));
> len += sizeof(crc);
>
> - regmap_bulk_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(1), bounce,
len);
> + regmap_bulk_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(1), bounce,
> DIV_ROUND_UP(len, 4)); regmap_write(dsi->regs, SUN6I_DSI_CMD_CTL_REG, len +
> 4 - 1);
> kfree(bounce);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Fwd: Call traces triggered by starting X on 5.8.x kernels - Radeon RX580
Hi All, I hope this is useful. Let me know if you would like me to test anything. Cheers, Adam [2.] Full description of the problem/report: X works but, 6 warnings triggered, in; drivers/gpu/drm/drm_modeset_lock.c:185 drivers/gpu/drm/drm_crtc_helper.c:148 drivers/gpu/drm/drm_crtc_helper.c:108 First one here, refer to dmesg-out.txt in tarball for the rest; [ 28.223717] [ cut here ] [ 28.223722] WARNING: CPU: 15 PID: 844 at drivers/gpu/drm/drm_modeset_lock.c:185 drm_warn_on_modeset_not_all_locked.part.0+0x67/0x70 [ 28.223723] Modules linked in: igb uvcvideo snd_usb_audio videobuf2_vmalloc videobuf2_memops snd_usbmidi_lib videobuf2_v4l2 snd_rawmidi videobuf2_common snd_seq_device snd_hda_codec_realtek kvm_amd snd_hda_codec_generic kvm irqbypass snd_hda_codec_hdmi aesni_intel glue_helper crypto_simd snd_hda_intel cryptd snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer pinctrl_amd sch_fq_codel efivarfs [ 28.223734] CPU: 15 PID: 844 Comm: X Tainted: G T 5.8.4-gentoo #1 [ 28.223735] Hardware name: Micro-Star International Co., Ltd. MS-7C37/X570-A PRO (MS-7C37), BIOS H.70 01/09/2020 [ 28.223736] RIP: 0010:drm_warn_on_modeset_not_all_locked.part.0+0x67/0x70 [ 28.223737] Code: 01 00 00 e8 0b c5 9d ff 84 c0 74 1a 49 8d bc 24 98 01 00 00 e8 fa c4 9d ff 84 c0 74 0d 5b 5d 41 5c c3 0f 0b eb c8 0f 0b eb e2 <0f> 0b 5b 5d 41 5c c3 66 90 8b 05 f2 c2 ad 01 85 c0 75 02 eb 84 c3 [ 28.223738] RSP: 0018:ae22c1217a50 EFLAGS: 00010246 [ 28.223739] RAX: RBX: 92f1f2370af8 RCX: [ 28.223739] RDX: RSI: 92f1f1dce8a0 RDI: 92f1f2370998 [ 28.223740] RBP: 92f1f2370b08 R08: 92f1f16c9d48 R09: 92f1f1f85848 [ 28.223740] R10: R11: R12: 92f1f2370800 [ 28.223741] R13: 0002 R14: 92f1f2370800 R15: 92f1f1dce800 [ 28.223742] FS: 77e6a3f76dc0() GS:92f1febc() knlGS: [ 28.223742] CS: 0010 DS: ES: CR0: 80050033 [ 28.223743] CR2: 644699c64018 CR3: 0007dcb9e000 CR4: 00340ee0 [ 28.223743] Call Trace: [ 28.223745] drm_crtc_helper_set_mode+0x73/0x4b0 [ 28.223748] ? __blk_mq_try_issue_directly+0xfd/0x250 [ 28.223750] ? update_load_avg+0x71/0x5a0 [ 28.223751] ? newidle_balance.constprop.0+0x1eb/0x340 [ 28.223752] ? psi_group_change+0x3a/0x1d0 [ 28.223754] ? kernel_init_free_pages+0x40/0x50 [ 28.223754] ? prep_new_page+0xa3/0xb0 [ 28.223755] ? get_page_from_freelist+0x1125/0x1a60 [ 28.223757] amdgpu_connector_set_property+0x2a8/0x630 [ 28.223758] drm_connector_set_obj_prop+0x39/0x80 [ 28.223759] drm_mode_obj_set_property_ioctl+0x291/0x320 [ 28.223760] ? drm_connector_set_obj_prop+0x80/0x80 [ 28.223761] drm_connector_property_set_ioctl+0x34/0x50 [ 28.223763] drm_ioctl_kernel+0xa3/0xf0 [ 28.223764] drm_ioctl+0x1f9/0x36f [ 28.223764] ? drm_connector_set_obj_prop+0x80/0x80 [ 28.223766] ? handle_mm_fault+0xd65/0x1680 [ 28.223767] amdgpu_drm_ioctl+0x41/0x70 [ 28.223769] ksys_ioctl+0x88/0xc0 [ 28.223769] __x64_sys_ioctl+0x11/0x20 [ 28.223771] do_syscall_64+0x3e/0x70 [ 28.223772] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 28.223773] RIP: 0033:0x77e6a446d747 [ 28.223774] Code: 1f 40 00 48 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b1 e8 0c ff ff ff 85 c0 78 b6 5b 4c 89 e0 5d 41 5c c3 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 76 0c 00 f7 d8 64 89 01 48 [ 28.223775] RSP: 002b:7ffe15738858 EFLAGS: 0246 ORIG_RAX: 0010 [ 28.223776] RAX: ffda RBX: 7ffe15738890 RCX: 77e6a446d747 [ 28.223776] RDX: 7ffe15738890 RSI: c01064ab RDI: 000b [ 28.223777] RBP: c01064ab R08: 644699c61e90 R09: 0001 [ 28.223777] R10: 77e6a4535a60 R11: 0246 R12: 6446996915b0 [ 28.223778] R13: 000b R14: 644699c63c10 R15: 0002 [ 28.223778] ---[ end trace b571c596e5f7bd31 ]--- [3.] Keywords (i.e., modules, networking, kernel): [4.] Kernel information [4.1.] Kernel version (from /proc/version): Linux version 5.8.4-gentoo (root@zen) (gcc (Gentoo 10.2.0-r1 p2) 10.2.0, GNU ld (Gentoo 2.34 p6) 2.34.0) #1 SMP Thu Aug 27 11:20:43 AEST 2020 Pretty sure it started in 5.8.0. [4.2.] Kernel .config file: In tarball [5.] Most recent kernel version which did not have the bug: Likely 5.7.x, however, it is possible that I missed it in other versions since X still runs. [6.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/admin-guide/bug-hunting.rst) full dmesg included in tarball [7.] A small shell script or example program which triggers the startx triggers it [8.] Environment [8.1.] Software (add the output of the ver_linux script here) Linux zen 5.8.4-gentoo #1 SMP Thu Aug 27 11:20:43 AEST 2020
[PATCH v1 2/2] drm: bridge: add support for lontium LT9611UXC bridge
Add support for Lontium LT9611UXC HDMI bridge. Lontium LT9611UXC is a
DSI to HDMI bridge which supports two DSI ports and I2S port as an input
and HDMI port as output. Despite name being similar to LT9611, these
devices are different enough to warrant separate driver.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/Kconfig | 13 +
drivers/gpu/drm/bridge/Makefile| 1 +
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 777 +
3 files changed, 791 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/lontium-lt9611uxc.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3e11af4e9f63..8343fb054652 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -61,6 +61,19 @@ config DRM_LONTIUM_LT9611
HDMI signals
Please say Y if you have such hardware.
+config DRM_LONTIUM_LT9611UXC
+ tristate "Lontium LT9611UXC DSI/HDMI bridge"
+ select SND_SOC_HDMI_CODEC if SND_SOC
+ depends on OF
+ select DRM_PANEL_BRIDGE
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ Driver for Lontium LT9611UXC DSI to HDMI bridge
+ chip driver that converts dual DSI and I2S to
+ HDMI signals
+ Please say Y if you have such hardware.
+
config DRM_LVDS_CODEC
tristate "Transparent LVDS encoders and decoders support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index c589a6a7cbe1..306850a5899b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
+obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
new file mode 100644
index ..fc363b65590d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -0,0 +1,777 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019-2020. Linaro Limited.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define EDID_BLOCK_SIZE128
+#define EDID_NUM_BLOCKS 2
+
+struct lt9611uxc {
+ struct device *dev;
+ struct drm_bridge bridge;
+
+ struct regmap *regmap;
+ /* Protects all accesses to registers by stopping the on-chip MCU */
+ struct mutex ocm_lock;
+
+ struct device_node *dsi0_node;
+ struct device_node *dsi1_node;
+ struct mipi_dsi_device *dsi0;
+ struct mipi_dsi_device *dsi1;
+ struct platform_device *audio_pdev;
+
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *enable_gpio;
+
+ bool sleep;
+
+ struct regulator_bulk_data supplies[2];
+
+ struct i2c_client *client;
+
+ bool hpd_supported;
+ struct display_timings *timings;
+ u8 edid_buf[EDID_BLOCK_SIZE * EDID_NUM_BLOCKS];
+};
+
+#define LT9611_PAGE_CONTROL0xff
+
+static const struct regmap_range_cfg lt9611uxc_ranges[] = {
+ {
+ .name = "register_range",
+ .range_min = 0,
+ .range_max = 0xd0ff,
+ .selector_reg = LT9611_PAGE_CONTROL,
+ .selector_mask = 0xff,
+ .selector_shift = 0,
+ .window_start = 0,
+ .window_len = 0x100,
+ },
+};
+
+static const struct regmap_config lt9611uxc_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0x,
+ .ranges = lt9611uxc_ranges,
+ .num_ranges = ARRAY_SIZE(lt9611uxc_ranges),
+};
+
+struct lt9611uxc_mode {
+ u16 hdisplay;
+ u16 vdisplay;
+ u8 vrefresh;
+ u8 lanes;
+ u8 intfs;
+};
+
+static struct lt9611uxc_mode lt9611uxc_modes[] = {
+ { 3840, 2160, 60, 4, 2 }, /* 3840x2160 24bit 60Hz 4Lane 2ports */
+ { 3840, 2160, 30, 4, 2 }, /* 3840x2160 24bit 30Hz 4Lane 2ports */
+ { 1920, 1080, 60, 4, 1 }, /* 1080P 24bit 60Hz 4lane 1port */
+ { 1920, 1080, 30, 3, 1 }, /* 1080P 24bit 30Hz 3lane 1port */
+ { 1920, 1080, 24, 3, 1 },
+ { 1024, 768, 60, 4, 1},
+ { 800, 600, 60, 4, 1},
+ { 720, 480, 60, 4, 1 },
+ { 720, 576, 50, 2, 1 },
+ { 640, 480, 60, 2, 1 },
+};
+
+static struct lt9611uxc *bridge_to_lt9611uxc(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct lt9611uxc, bridge);
+}
+
Re: [PATCH] coccinelle: api: fix kobj_to_dev.cocci warnings
> It seems that 0-day picks up new semantic patches that are added to trees > in kernel.org, but that it's strategy for generating the patch is not > ideal. I'll just drop these Fixes lines. * How do you think about to adjust also the prefix for subjects of generated patches? Another example: https://lore.kernel.org/linux-nvme/alpine.DEB.2.22.394.2008272211260.2482@hadrien/ https://lore.kernel.org/patchwork/patch/1296616/ https://lkml.org/lkml/2020/8/27/1377 * Do any scripts (from the continuous integration system) need further improvements for the safe and clear application of patch results? Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 13/36] PM / devfreq: tegra30: Use MC timings for building OPP table
28.08.2020 04:47, Chanwoo Choi пишет: > Hi, ... >> Hence the NULL-checking is unnecessary. >> >> When I first encountered the of_device_get_match_data(), I was also >> thinking that adding the NULL-checks is a good idea, but later on >> somebody pointed out to me (maybe Thierry) that it's unnecessary to do. > > OK. Thanks. > >> + + mc = tegra_get_memory_controller(soc_data->mc_compatible); + if (IS_ERR(mc)) + return PTR_ERR(mc); >>> >>> You better to add error log. >> >> In practice we should get only -EPROBE_DEFER here ever. I'll consider >> adding the message in the next revision, at least just for consistency. > > In order to handle -EPROBE_DEFER, recommend the using of dev_err_probe(). Hello, Chanwoo! Thank you for the suggestion! I wasn't aware about the dev_err_probe() until recently and will use this new helper in the v6! Thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/bridge: nwl-dsi: Add support for video_pll
From: Robert Chiras
This patch adds support for a new clock 'video_pll' in order to better
set the video_pll clock to a clock-rate that satisfies a mode's clock.
The video PLL, on i.MX8MQ, can drive both DC pixel-clock and DSI phy_ref
clock. When used with a bridge that can drive multiple modes, like a DSI
to HDMI bridge, the DSI can't be statically configured for a specific
mode in the DTS file.
So, this patch adds access to the video PLL inside the DSI driver, so
that modes can be filtered-out if the required combination of phy_ref
and pixel-clock can't be achieved using the video PLL.
Signed-off-by: Robert Chiras
---
drivers/gpu/drm/bridge/nwl-dsi.c | 318 ++-
1 file changed, 313 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index ce94f79..1228466 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -39,6 +39,20 @@
#define NWL_DSI_MIPI_FIFO_TIMEOUT msecs_to_jiffies(500)
+/* Maximum Video PLL frequency: 1.2GHz */
+#define MAX_PLL_FREQ 12
+
+#define MBPS(x) ((x) * 100)
+#define MIN_PHY_RATE MBPS(24)
+#define MAX_PHY_RATE MBPS(30)
+
+/* Possible valid PHY reference clock rates*/
+static u32 phyref_rates[] = {
+ 2700,
+ 2500,
+ 2400,
+};
+
enum transfer_direction {
DSI_PACKET_SEND,
DSI_PACKET_RECEIVE,
@@ -67,6 +81,17 @@ struct nwl_dsi_transfer {
size_t rx_len; /* in bytes */
};
+struct mode_config {
+ int clock;
+ int crtc_clock;
+ unsigned intlanes;
+ unsigned long bitclock;
+ unsigned long phy_rates[3];
+ unsigned long pll_rates[3];
+ int phy_rate_idx;
+ struct list_headlist;
+};
+
struct nwl_dsi {
struct drm_bridge bridge;
struct mipi_dsi_host dsi_host;
@@ -101,6 +126,7 @@ struct nwl_dsi {
struct clk *rx_esc_clk;
struct clk *tx_esc_clk;
struct clk *core_clk;
+ struct clk *pll_clk;
/*
* hardware bug: the i.MX8MQ needs this clock on during reset
* even when not using LCDIF.
@@ -115,6 +141,7 @@ struct nwl_dsi {
int error;
struct nwl_dsi_transfer *xfer;
+ struct list_head valid_modes;
};
static const struct regmap_config nwl_dsi_regmap_config = {
@@ -778,6 +805,207 @@ static void nwl_dsi_bridge_disable(struct drm_bridge
*bridge)
pm_runtime_put(dsi->dev);
}
+static unsigned long nwl_dsi_get_bit_clock(struct nwl_dsi *dsi,
+ unsigned long pixclock, u32 lanes)
+{
+ int bpp;
+
+ if (lanes < 1 || lanes > 4)
+ return 0;
+
+ bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
+
+ return (pixclock * bpp) / lanes;
+}
+
+/*
+ * Utility function to calculate least commom multiple, using an improved
+ * version of the Euclidean algorithm for greatest common factor.
+ */
+static unsigned long nwl_dsi_get_lcm(unsigned long a, unsigned long b)
+{
+ u32 gcf = 0; /* greatest common factor */
+ unsigned long tmp_a = a;
+ unsigned long tmp_b = b;
+
+ if (!a || !b)
+ return 0;
+
+ while (tmp_a % tmp_b) {
+ gcf = tmp_a % tmp_b;
+ tmp_a = tmp_b;
+ tmp_b = gcf;
+ }
+
+ if (!gcf)
+ return a;
+
+ return ((unsigned long long)a * b) / gcf;
+}
+
+/*
+ * This function tries to adjust the crtc_clock for a DSI device in such a way
+ * that the video pll will be able to satisfy both Display Controller pixel
+ * clock (feeding out DPI interface) and our input phy_ref clock.
+ */
+static void nwl_dsi_setup_pll_config(struct mode_config *config)
+{
+ unsigned long pll_rate;
+ int div;
+ size_t i, num_rates = ARRAY_SIZE(config->phy_rates);
+
+ config->crtc_clock = 0;
+
+ for (i = 0; i < num_rates; i++) {
+ int crtc_clock;
+
+ if (!config->phy_rates[i])
+ break;
+ /*
+* First, we need to check if phy_ref can actually be obtained
+* from pixel clock. To do this, we check their lowest common
+* multiple, which has to be in PLL range.
+*/
+ pll_rate = nwl_dsi_get_lcm(config->clock, config->phy_rates[i]);
+ if (pll_rate > MAX_PLL_FREQ) {
+ /* Drop pll_rate to a realistic value */
+ while (pll_rate > MAX_PLL_FREQ)
+ pll_rate >>= 1;
+ /* Make sure pll_rate can provide phy_ref rate */
+ div = DIV_ROUND_UP(pll_rate, config->phy_rates[i]);
+ pll_rate = config->phy_rates[i] * div;
+ } else {
+
Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
Hi,
On Fri, Aug 28, 2020 at 02:45:49PM +0200, Stefan Wahren wrote:
> Am 28.08.20 um 08:30 schrieb Hoegeun Kwon:
> > On 8/27/20 6:49 PM, Stefan Wahren wrote:
> >> Am 27.08.20 um 06:35 schrieb Hoegeun Kwon:
> >>> Hi Stefan,
> >>>
> >>> Thank you for your review.
> >>>
> >>>
> >>> On 8/26/20 7:04 PM, Stefan Wahren wrote:
> Hi Hoeguen,
>
> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
> > There is a problem that the output does not work at a resolution
> > exceeding FHD. To solve this, we need to adjust the bvb clock at a
> > resolution exceeding FHD.
> this patch introduces a mandatory clock, please update
> brcm,bcm2835-hdmi.yaml first.
>
> Is this clock physically available on BCM283x or only on BCM2711?
> >>> As far as I know, BCM2711 raspberry pi 4 supports 4k,
> >>>
> >>> don't supported on pi 3 and pi 3+.
> >>>
> >>> Since 4k is not supported in versions prior to Raspberry Pi 4,
> >>>
> >>> I don't think we need to modify the bvb clock.
> >>>
> >>>
> >>> So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
> >>>
> >>> instead of 'brcm,bcm2835-hdmi.yaml'.
> >> You are correct please update only brcm,bcm2711-hdmi.yaml.
> >>
> >> My concern was that the function vc4_hdmi_encoder_pre_crtc_configure()
> >> is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older
> >> DTB. So making the BVB clock optional might be better?
> > You are right, if use old dtb, we have a problem with the hdmi driver.
> >
> > So how about modifying it like this?
> >
> > @@ -1614,8 +1614,8 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
> > *vc4_hdmi)
> >
> > vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
> > if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
> > - DRM_ERROR("Failed to get pixel bvb clock\n");
> > - return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
> > + DRM_WARN("Failed to get pixel bvb clock\n");
> > + vc4_hdmi->pixel_bvb_clock = NULL;
> > }
>
> i think the better solution would be devm_clk_get_optional(), which
> return NULL in case the clock doesn't exist.
It's not really optional though. BCM2711 will require it in order to run
properly (as Hoegeun experienced), and the previous SoCs won't.
If we use clk_get_optional and that the DT is missing the clock on the
BCM2711, we will silently ignore it which doesn't sound great.
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 1/2] i2c: i2c-qcom-geni: Store DMA mapping data in geni_i2c_dev struct
On 2020-08-21 05:48, Stephen Boyd wrote: Quoting Roja Rani Yarubandi (2020-08-20 03:35:21) Store DMA mapping data in geni_i2c_dev struct to enhance DMA mapping data scope. For example during shutdown callback to unmap DMA mapping, this stored DMA mapping data can be used to call geni_se_tx_dma_unprep and geni_se_rx_dma_unprep functions. Signed-off-by: Roja Rani Yarubandi --- Can this be squashed with the next patch? I don't see how this stands on its own. Okay. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: virtio: fix kconfig dependency warning
From: Randy Dunlap Fix kconfig dependency warning by using a different Kconfig symbol. WARNING: unmet direct dependencies detected for VIRTIO_DMA_SHARED_BUFFER Depends on [n]: VIRTIO_MENU [=n] && DMA_SHARED_BUFFER [=y] Selected by [y]: - DRM_VIRTIO_GPU [=y] && HAS_IOMEM [=y] && DRM [=y] && VIRTIO [=y] && MMU [=y] Signed-off-by: Randy Dunlap Cc: David Airlie Cc: Gerd Hoffmann Cc: dri-devel@lists.freedesktop.org Cc: virtualizat...@lists.linux-foundation.org --- v2: depends on VIRTIO + VIRTIO_MENU (Gerd) Found in linux-next but applies to mainline. drivers/gpu/drm/virtio/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200828.orig/drivers/gpu/drm/virtio/Kconfig +++ linux-next-20200828/drivers/gpu/drm/virtio/Kconfig @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_VIRTIO_GPU tristate "Virtio GPU driver" - depends on DRM && VIRTIO && MMU + depends on DRM && VIRTIO && VIRTIO_MENU && MMU select DRM_KMS_HELPER select DRM_GEM_SHMEM_HELPER select VIRTIO_DMA_SHARED_BUFFER ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] dt-bindings: display: bridge: Add documentation for LT9611UXC
Lontium LT9611UXC is a DSI to HDMI bridge which supports 2 DSI ports and I2S port as input and one HDMI port as output. The LT9611UXC chip is handled by a separate driver, but the bindings used are fully compatible with the LT9611 chip, so let's reuse the lt9611.yaml schema. Signed-off-by: Dmitry Baryshkov Acked-by: Vinod Koul --- .../devicetree/bindings/display/bridge/lontium,lt9611.yaml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml index d60208359234..7a1c89b995e2 100644 --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml @@ -4,18 +4,19 @@ $id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Lontium LT9611 2 Port MIPI to HDMI Bridge +title: Lontium LT9611(UXC) 2 Port MIPI to HDMI Bridge maintainers: - Vinod Koul description: | - The LT9611 is a bridge device which converts DSI to HDMI + The LT9611 and LT9611UXC are bridge devices which convert DSI to HDMI properties: compatible: enum: - lontium,lt9611 + - lontium,lt9611uxc reg: maxItems: 1 -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 23/24] drm/omap: display: Backlight update
Hi,
On Sun, Aug 23, 2020 at 12:45:31PM +0200, Sam Ravnborg wrote:
> - Introduce backlight_{enable/disable)
> - Use get/set methods for backlight_properties
> - Drop redundant get_brightness() implementation
> The default implementation return the current brightness value
> - Use macro for backlight initialization
>
> v2:
> - Drop backlight_update() call as it is redundant (Sebastian)
>
> Signed-off-by: Sam Ravnborg
> Cc: Tomi Valkeinen
> Cc: Sebastian Reichel
> Cc: Laurent Pinchart
> Cc: Zheng Bin
> Cc: Sam Ravnborg
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> .../gpu/drm/omapdrm/displays/panel-dsi-cm.c | 37 +++
> 1 file changed, 6 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> index 3484b5d4a91c..39b3a7affbc8 100644
> --- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> @@ -110,17 +110,10 @@ static void dsicm_bl_power(struct panel_drv_data
> *ddata, bool enable)
> else
> return;
>
> - if (enable) {
> - backlight->props.fb_blank = FB_BLANK_UNBLANK;
> - backlight->props.state = ~(BL_CORE_FBBLANK | BL_CORE_SUSPENDED);
> - backlight->props.power = FB_BLANK_UNBLANK;
> - } else {
> - backlight->props.fb_blank = FB_BLANK_NORMAL;
> - backlight->props.power = FB_BLANK_POWERDOWN;
> - backlight->props.state |= BL_CORE_FBBLANK | BL_CORE_SUSPENDED;
> - }
> -
> - backlight_update_status(backlight);
> + if (enable)
> + backlight_enable(backlight);
> + else
> + backlight_disable(backlight);
> }
>
> static void hw_guard_start(struct panel_drv_data *ddata, int guard_msec)
> @@ -363,13 +356,7 @@ static int dsicm_bl_update_status(struct
> backlight_device *dev)
> struct panel_drv_data *ddata = dev_get_drvdata(>dev);
> struct omap_dss_device *src = ddata->src;
> int r = 0;
> - int level;
> -
> - if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
> - dev->props.power == FB_BLANK_UNBLANK)
> - level = dev->props.brightness;
> - else
> - level = 0;
> + int level = backlight_get_brightness(dev);
>
> dev_dbg(>pdev->dev, "update brightness to %d\n", level);
>
> @@ -390,17 +377,7 @@ static int dsicm_bl_update_status(struct
> backlight_device *dev)
> return r;
> }
>
> -static int dsicm_bl_get_intensity(struct backlight_device *dev)
> -{
> - if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
> - dev->props.power == FB_BLANK_UNBLANK)
> - return dev->props.brightness;
> -
> - return 0;
> -}
> -
> static const struct backlight_ops dsicm_bl_ops = {
> - .get_brightness = dsicm_bl_get_intensity,
> .update_status = dsicm_bl_update_status,
> };
>
> @@ -1305,9 +1282,7 @@ static int dsicm_probe(struct platform_device *pdev)
> dsicm_hw_reset(ddata);
>
> if (ddata->use_dsi_backlight) {
> - struct backlight_properties props = { 0 };
> - props.max_brightness = 255;
> - props.type = BACKLIGHT_RAW;
> + DECLARE_BACKLIGHT_INIT_RAW(props, 0, 255);
>
> bldev = devm_backlight_device_register(dev, dev_name(dev),
> dev, ddata, _bl_ops, );
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm: bridge: add support for lontium LT9611UXC bridge
Add support for Lontium LT9611UXC HDMI bridge. Lontium LT9611UXC is a
DSI to HDMI bridge which supports two DSI ports and I2S port as an input
and HDMI port as output. Despite name being similar to LT9611, these
devices are different enough to warrant separate driver.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/Kconfig | 13 +
drivers/gpu/drm/bridge/Makefile| 1 +
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 774 +
3 files changed, 788 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/lontium-lt9611uxc.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3e11af4e9f63..8343fb054652 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -61,6 +61,19 @@ config DRM_LONTIUM_LT9611
HDMI signals
Please say Y if you have such hardware.
+config DRM_LONTIUM_LT9611UXC
+ tristate "Lontium LT9611UXC DSI/HDMI bridge"
+ select SND_SOC_HDMI_CODEC if SND_SOC
+ depends on OF
+ select DRM_PANEL_BRIDGE
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ Driver for Lontium LT9611UXC DSI to HDMI bridge
+ chip driver that converts dual DSI and I2S to
+ HDMI signals
+ Please say Y if you have such hardware.
+
config DRM_LVDS_CODEC
tristate "Transparent LVDS encoders and decoders support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index c589a6a7cbe1..306850a5899b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
+obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
new file mode 100644
index ..77c5aa5c6ad7
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -0,0 +1,774 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019-2020. Linaro Limited.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define EDID_BLOCK_SIZE128
+#define EDID_NUM_BLOCKS2
+
+struct lt9611uxc {
+ struct device *dev;
+ struct drm_bridge bridge;
+
+ struct regmap *regmap;
+ /* Protects all accesses to registers by stopping the on-chip MCU */
+ struct mutex ocm_lock;
+
+ struct device_node *dsi0_node;
+ struct device_node *dsi1_node;
+ struct mipi_dsi_device *dsi0;
+ struct mipi_dsi_device *dsi1;
+ struct platform_device *audio_pdev;
+
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *enable_gpio;
+
+ bool sleep;
+
+ struct regulator_bulk_data supplies[2];
+
+ struct i2c_client *client;
+
+ bool hpd_supported;
+ struct display_timings *timings;
+ u8 edid_buf[EDID_BLOCK_SIZE * EDID_NUM_BLOCKS];
+};
+
+#define LT9611_PAGE_CONTROL0xff
+
+static const struct regmap_range_cfg lt9611uxc_ranges[] = {
+ {
+ .name = "register_range",
+ .range_min = 0,
+ .range_max = 0xd0ff,
+ .selector_reg = LT9611_PAGE_CONTROL,
+ .selector_mask = 0xff,
+ .selector_shift = 0,
+ .window_start = 0,
+ .window_len = 0x100,
+ },
+};
+
+static const struct regmap_config lt9611uxc_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0x,
+ .ranges = lt9611uxc_ranges,
+ .num_ranges = ARRAY_SIZE(lt9611uxc_ranges),
+};
+
+struct lt9611uxc_mode {
+ u16 hdisplay;
+ u16 vdisplay;
+ u8 vrefresh;
+ u8 lanes;
+ u8 intfs;
+};
+
+static struct lt9611uxc_mode lt9611uxc_modes[] = {
+ { 3840, 2160, 60, 4, 2 }, /* 3840x2160 24bit 60Hz 4Lane 2ports */
+ { 3840, 2160, 30, 4, 2 }, /* 3840x2160 24bit 30Hz 4Lane 2ports */
+ { 1920, 1080, 60, 4, 1 }, /* 1080P 24bit 60Hz 4lane 1port */
+ { 1920, 1080, 30, 3, 1 }, /* 1080P 24bit 30Hz 3lane 1port */
+ { 1920, 1080, 24, 3, 1 },
+ { 1024, 768, 60, 4, 1},
+ { 800, 600, 60, 4, 1},
+ { 720, 480, 60, 4, 1 },
+ { 720, 576, 50, 2, 1 },
+ { 640, 480, 60, 2, 1 },
+};
+
+static struct lt9611uxc *bridge_to_lt9611uxc(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct lt9611uxc,
[PATCH 4/5] dt-bindings: display/bridge: nwl-dsi: Document fsl, clock-drop-level property
From: Robert Chiras Add documentation for a new property: 'fsl,clock-drop-level'. Signed-off-by: Robert Chiras --- Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml index 8b5741b..b415f4e 100644 --- a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml @@ -143,6 +143,10 @@ properties: additionalProperties: false + clock-drop-level: +description: + Specifies the level at wich the crtc_clock should be dropped + patternProperties: "^panel@[0-9]+$": type: object -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v6 4/6] drm/sprd: add Unisoc's drm display controller driver
Sam Ravnborg 于2020年7月29日周三 上午5:14写道：
>
> Hi Kevin.
>
> Some feedback in the following.
> I lost track of thing for the atomic modesettting stuff and I hope other
> will review that.
>
> Sam
>
> On Tue, Jul 28, 2020 at 06:07:57PM +0800, Kevin Tang wrote:
> > From: Kevin Tang
> >
> > Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem.
> > It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
> >
> > RFC v6:
> > - Access registers via readl/writel
> > - Checking for unsupported KMS properties (format, rotation, blend_mode,
> > etc) on plane_check ops
> > - Remove always true checks for dpu core ops
> >
> > Cc: Orson Zhai
> > Cc: Chunyan Zhang
> > Signed-off-by: Kevin Tang
> > ---
> > drivers/gpu/drm/sprd/Makefile | 5 +-
> > drivers/gpu/drm/sprd/dpu/Makefile | 3 +
> > drivers/gpu/drm/sprd/dpu/dpu_r2p0.c | 503
> > drivers/gpu/drm/sprd/sprd_dpu.c | 646
> >
> > drivers/gpu/drm/sprd/sprd_dpu.h | 187 +++
> > drivers/gpu/drm/sprd/sprd_drm.c | 1 +
> > drivers/gpu/drm/sprd/sprd_drm.h | 2 +
> > 7 files changed, 1346 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/gpu/drm/sprd/dpu/Makefile
> > create mode 100644 drivers/gpu/drm/sprd/dpu/dpu_r2p0.c
> > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c
> > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h
> >
> > diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
> > index 86d95d9..88ab32a 100644
> > --- a/drivers/gpu/drm/sprd/Makefile
> > +++ b/drivers/gpu/drm/sprd/Makefile
> > @@ -2,4 +2,7 @@
> >
> > subdir-ccflags-y += -I$(srctree)/$(src)
> Not needed - drop.
>
> >
> > -obj-y := sprd_drm.o
> > +obj-y := sprd_drm.o \
> > + sprd_dpu.o
> > +
> > +obj-y += dpu/
>
> Until there are several DPU's there is no need for a separate directory.
> Make it simpler by keeping it all in drm/sprd/*
Ok I will move DPU IP code to drm/sprd
>
> > diff --git a/drivers/gpu/drm/sprd/dpu/Makefile
> > b/drivers/gpu/drm/sprd/dpu/Makefile
> > new file mode 100644
> > index 000..40278b6
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/dpu/Makefile
> > @@ -0,0 +1,3 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +obj-y += dpu_r2p0.o
> > diff --git a/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c
> > b/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c
> > new file mode 100644
> > index 000..4b9521d
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c
> > @@ -0,0 +1,503 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2020 Unisoc Inc.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "sprd_dpu.h"
> > +
> > +/* DPU registers size, 4 Bytes(32 Bits) */
> > +#define DPU_REG_SIZE 0x04
> > +
> > +/* Layer registers offset */
> > +#define DPU_LAY_REG_OFFSET 0x0C
> > +
> > +#define DPU_LAY_REG(reg, index) \
> > + (reg + index * DPU_LAY_REG_OFFSET * DPU_REG_SIZE)
> Use a static inline to get better typecheck.
>
> > +#define DPU_REG_RD(reg) readl_relaxed(reg)
> > +
> > +#define DPU_REG_WR(reg, mask) writel_relaxed(mask, reg)
> > +
> > +#define DPU_REG_SET(reg, mask) \
> > + writel_relaxed(readl_relaxed(reg) | mask, reg)
> > +
> > +#define DPU_REG_CLR(reg, mask) \
> > + writel_relaxed(readl_relaxed(reg) & ~mask, reg)
> I am no fan of macros used like this.
>
> Maybe use static inlines and add struct dpu_context * as first argument.
> Then adding base can be hidden away.
Maybe a good idea, i will try it, like this:
static inline void DPU_REG_CLR(dpu_context *ctx, u32 reg, u32 mask) {
writel_relaxed(readl_relaxed(ctx->base + reg) & ~mask, ctx->base + reg);
}
>
>
> I had a hard time convincing myself that _relaxed was the right
> variants. If I get it correct we may see writes re-ordered with the
> _relaxed variants wich would be no good when dealign with interrupts.
> But I may miss somethign here.
>
> > +
> > +/* Global control registers */
> > +#define REG_DPU_CTRL 0x04
> > +#define REG_DPU_CFG0 0x08
> > +#define REG_DPU_CFG1 0x0C
> > +#define REG_DPU_CFG2 0x10
> > +#define REG_PANEL_SIZE 0x20
> > +#define REG_BLEND_SIZE 0x24
> > +#define REG_BG_COLOR 0x2C
> > +
> > +/* Layer0 control registers */
> > +#define REG_LAY_BASE_ADDR0 0x30
> > +#define REG_LAY_BASE_ADDR1 0x34
> > +#define REG_LAY_BASE_ADDR2 0x38
> > +#define REG_LAY_CTRL 0x40
> > +#define REG_LAY_SIZE 0x44
> > +#define REG_LAY_PITCH0x48
> > +#define REG_LAY_POS 0x4C
> > +#define REG_LAY_ALPHA0x50
> > +#define REG_LAY_PALLETE 0x58
> > +#define REG_LAY_CROP_START 0x5C
> > +
> > +/* Interrupt control registers */
> > +#define REG_DPU_INT_EN 0x1E0
> > +#define REG_DPU_INT_CLR 0x1E4
> > +#define REG_DPU_INT_STS 0x1E8
> > +
> > +/* DPI control registers */
> > +#define REG_DPI_CTRL 0x1F0
> > +#define
[PATCH v1 1/2] dt-bindings: display: bridge: Add documentation for LT9611UXC
Lontium LT9611UXC is a DSI to HDMI bridge which supports 2 DSI ports and I2S port as input and one HDMI port as output. The LT9611UXC chip is handled by a separate driver, but the bindings used are fully compatible with the LT9611 chip, so let's reuse the lt9611.yaml schema. Signed-off-by: Dmitry Baryshkov --- .../devicetree/bindings/display/bridge/lontium,lt9611.yaml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml index d60208359234..7a1c89b995e2 100644 --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml @@ -4,18 +4,19 @@ $id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Lontium LT9611 2 Port MIPI to HDMI Bridge +title: Lontium LT9611(UXC) 2 Port MIPI to HDMI Bridge maintainers: - Vinod Koul description: | - The LT9611 is a bridge device which converts DSI to HDMI + The LT9611 and LT9611UXC are bridge devices which convert DSI to HDMI properties: compatible: enum: - lontium,lt9611 + - lontium,lt9611uxc reg: maxItems: 1 -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/vc4: Support HDMI QHD or higher output
Hi! On Fri, Aug 21, 2020 at 04:10:42PM +0900, Hoegeun Kwon wrote: > Hi everyone, > > There is a problem that the output does not work at a resolution > exceeding FHD. To solve this, we need to adjust the bvb clock at a > resolution exceeding FHD. > > Rebased on top of next-20200708 and [1]. > > [1] : [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline (Maxime's > patchset) Thanks a lot for figuring it out I have to send a new (and hopefully final) version next week to address some changes suggested by Dave, so I'll squash your patches into the series Thanks again! Maxime ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu/ipu-v3:reduce protected code area in ipu idmac get/put
This change will speed-up a bit these ipu_idmac_get &
ipu_idmac_put processing and there is no need to protect
kzalloc & kfree.
Signed-off-by: Bernard Zhao
---
drivers/gpu/ipu-v3/ipu-common.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index b3dae9ec1a38..8b3a57864c2e 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -267,29 +267,30 @@ EXPORT_SYMBOL_GPL(ipu_rot_mode_to_degrees);
struct ipuv3_channel *ipu_idmac_get(struct ipu_soc *ipu, unsigned num)
{
struct ipuv3_channel *channel;
+ struct ipuv3_channel *entry;
dev_dbg(ipu->dev, "%s %d\n", __func__, num);
if (num > 63)
return ERR_PTR(-ENODEV);
+ channel = kzalloc(sizeof(*channel), GFP_KERNEL);
+ if (!channel)
+ return ERR_PTR(-ENOMEM);
+
+ channel->num = num;
+ channel->ipu = ipu;
+
mutex_lock(>channel_lock);
- list_for_each_entry(channel, >channels, list) {
- if (channel->num == num) {
+ list_for_each_entry(entry, >channels, list) {
+ if (entry->num == num) {
+ kfree(channel);
channel = ERR_PTR(-EBUSY);
goto out;
}
}
- channel = kzalloc(sizeof(*channel), GFP_KERNEL);
- if (!channel) {
- channel = ERR_PTR(-ENOMEM);
- goto out;
- }
-
- channel->num = num;
- channel->ipu = ipu;
list_add(>list, >channels);
out:
@@ -308,9 +309,10 @@ void ipu_idmac_put(struct ipuv3_channel *channel)
mutex_lock(>channel_lock);
list_del(>list);
- kfree(channel);
mutex_unlock(>channel_lock);
+
+ kfree(channel);
}
EXPORT_SYMBOL_GPL(ipu_idmac_put);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
Hi Stefan, On Thu, Aug 27, 2020 at 11:49:34AM +0200, Stefan Wahren wrote: > Am 27.08.20 um 06:35 schrieb Hoegeun Kwon: > > Hi Stefan, > > > > Thank you for your review. > > > > > > On 8/26/20 7:04 PM, Stefan Wahren wrote: > >> Hi Hoeguen, > >> > >> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon: > >>> There is a problem that the output does not work at a resolution > >>> exceeding FHD. To solve this, we need to adjust the bvb clock at a > >>> resolution exceeding FHD. > >> this patch introduces a mandatory clock, please update > >> brcm,bcm2835-hdmi.yaml first. > >> > >> Is this clock physically available on BCM283x or only on BCM2711? > > As far as I know, BCM2711 raspberry pi 4 supports 4k, > > > > don't supported on pi 3 and pi 3+. > > > > Since 4k is not supported in versions prior to Raspberry Pi 4, > > > > I don't think we need to modify the bvb clock. > > > > > > So I think it is better to update 'brcm,bcm2711-hdmi.yaml' > > > > instead of 'brcm,bcm2835-hdmi.yaml'. > > You are correct please update only brcm,bcm2711-hdmi.yaml. > > My concern was that the function vc4_hdmi_encoder_pre_crtc_configure() > is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older > DTB. So making the BVB clock optional might be better? It won't cause any issue on a non-RPi4 platform since the clock pointer will be NULL and clk_set_rate can deal with NULL pointers just fine: https://elixir.bootlin.com/linux/latest/source/drivers/clk/clk.c#L2221 For the older DTBs, it shouldn't be an issue either. We haven't merged the binding yet, so we don't have an upstream DTB using it Maxime ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] Add LT9611UXC DSI to HDMI bridge support
Hi, This series adds support for Lontium LT9611UXC bridge chip which takes MIPI DSI as input and provides HDMI signal as output. The chip can be found in Qualcomm RB5 platform [1], [2]. [1] https://www.qualcomm.com/products/qualcomm-robotics-rb5-platform [2] https://www.thundercomm.com/app_en/product/1590131656070623 Changes since v1: - Fix whitespaces/indentation - Support working without DRM_BRIDGE_ATTACH_NO_CONNECTOR ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v2 13/14] [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table
Dne petek, 28. avgust 2020 ob 14:21:19 CEST je Ondřej Jirman napisal(a): > On Fri, Aug 28, 2020 at 02:16:36PM +0200, Clément Péron wrote: > > Hi Maxime, > > > > On Tue, 25 Aug 2020 at 15:35, Maxime Ripard wrote: > > > Hi Clement, > > > > > > On Mon, Aug 03, 2020 at 09:54:05AM +0200, Clément Péron wrote: > > > > Hi Maxime and All, > > > > > > > > On Sat, 4 Jul 2020 at 16:56, Clément Péron wrote: > > > > > Hi Maxime, > > > > > > > > > > On Sat, 4 Jul 2020 at 14:13, Maxime Ripard wrote: > > > > > > Hi, > > > > > > > > > > > > On Sat, Jul 04, 2020 at 12:25:34PM +0200, Clément Péron wrote: > > > > > > > Add an Operating Performance Points table for the GPU to > > > > > > > enable Dynamic Voltage & Frequency Scaling on the H6. > > > > > > > > > > > > > > The voltage range is set with minival voltage set to the target > > > > > > > and the maximal voltage set to 1.2V. This allow DVFS framework > > > > > > > to > > > > > > > work properly on board with fixed regulator. > > > > > > > > > > > > > > Signed-off-by: Clément Péron > > > > > > > > > > > > That patch seems reasonable, why shouldn't we merge it? > > > > > > > > > > I didn't test it a lot and last time I did, some frequencies looked > > > > > unstable. https://lore.kernel.org/patchwork/cover/1239739/ > > > > > > > > > > This series adds regulator support to Panfrost devfreq, I will send > > > > > a > > > > > new one if DVFS on the H6 GPU is stable. > > > > > > > > > > I got this running glmark2 last time > > > > > # glmark2-es2-drm > > > > > === > > > > > > > > > > glmark2 2017.07 > > > > > > > > > > === > > > > > > > > > > OpenGL Information > > > > > GL_VENDOR: Panfrost > > > > > GL_RENDERER: Mali T720 (Panfrost) > > > > > GL_VERSION:OpenGL ES 2.0 Mesa 20.0.5 > > > > > > > > > > === > > > > > > > > > > [ 93.550063] panfrost 180.gpu: GPU Fault 0x0088 (UNKNOWN) > > > > > at > > > > > 0x80117100 > > > > > [ 94.045401] panfrost 180.gpu: gpu sched timeout, js=0, > > > > > config=0x3700, status=0x8, head=0x21d6c00, tail=0x21d6c00, > > > > > sched_job=e3c2132f > > > > > > > > > > [ 328.871070] panfrost 180.gpu: Unhandled Page fault in AS0 at > > > > > VA > > > > > 0x > > > > > [ 328.871070] Reason: TODO > > > > > [ 328.871070] raw fault status: 0xAA0003C2 > > > > > [ 328.871070] decoded fault status: SLAVE FAULT > > > > > [ 328.871070] exception type 0xC2: TRANSLATION_FAULT_LEVEL2 > > > > > [ 328.871070] access type 0x3: WRITE > > > > > [ 328.871070] source id 0xAA00 > > > > > [ 329.373327] panfrost 180.gpu: gpu sched timeout, js=1, > > > > > config=0x3700, status=0x8, head=0xa1a4900, tail=0xa1a4900, > > > > > sched_job=7ac31097 > > > > > [ 329.386527] panfrost 180.gpu: js fault, js=0, > > > > > status=DATA_INVALID_FAULT, head=0xa1a4c00, tail=0xa1a4c00 > > > > > [ 329.396293] panfrost 180.gpu: gpu sched timeout, js=0, > > > > > config=0x3700, status=0x58, head=0xa1a4c00, tail=0xa1a4c00, > > > > > sched_job=04c90381 > > > > > [ 329.411521] panfrost 180.gpu: Unhandled Page fault in AS0 at > > > > > VA > > > > > 0x > > > > > [ 329.411521] Reason: TODO > > > > > [ 329.411521] raw fault status: 0xAA0003C2 > > > > > [ 329.411521] decoded fault status: SLAVE FAULT > > > > > [ 329.411521] exception type 0xC2: TRANSLATION_FAULT_LEVEL2 > > > > > [ 329.411521] access type 0x3: WRITE > > > > > [ 329.411521] source id 0xAA00 > > > > > > > > Just to keep a track of this issue. > > > > > > > > Piotr Oniszczuk give more test and seems to be software related: > > > > https://www.spinics.net/lists/dri-devel/msg264279.html > > > > > > > > Ondrej gave a great explanation about a possible origin of this issue: > > > > https://freenode.irclog.whitequark.org/linux-sunxi/2020-07-11 > > > > > > > > 20:12 looks like gpu pll on H6 is NKMP clock, and those are > > > > implemented in such a way in mainline that they are prone to > > > > overshooting the frequency during output divider reduction > > > > 20:13 so disabling P divider may help > > > > 20:13 or fixing the dividers > > > > 20:14 and just allowing N to change > > > > 20:22 hmm, I haven't looked at this for quite some time, but H6 > > > > BSP way of setting PLL factors actually makes the most sense out of > > > > everything I've seen/tested so far > > > > 20:23 it waits for lock not after setting NK factors, but after > > > > reducing the M factor (pre-divider) > > > > 20:24 I might as well re-run my CPU PLL tester with this > > > > algorithm, to see if it fixes the lockups > > > > 20:26 it makes sense to wait for PLL to stabilize "after" > > > > changing all the factors that actually affect the VCO, and not just > > > > some of them > > > > 20:27 warpme_: ^ > > > > 20:28 it may be the same thing
[PATCH 2/5] dt-bindings: display/bridge: nwl-dsi: Document video_pll clock
From: Robert Chiras Add documentation for a new clock 'video_pll'. Signed-off-by: Robert Chiras --- Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml index 04099f5..8b5741b 100644 --- a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml @@ -37,6 +37,8 @@ properties: - description: TX_ESC clock (used in escape mode) - description: PHY_REF clock - description: LCDIF clock + - description: VIDEO_PLL clock (used to set the the PLL clock feeding both + phy_ref and DC pixel clock to a convenient rate) clock-names: items: @@ -45,6 +47,7 @@ properties: - const: tx_esc - const: phy_ref - const: lcdif + - const: video_pll mux-controls: description: -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] Add new features to nwl-dsi driver
From: Robert Chiras This patch-set adds the new following features to the nwl-dsi bridge driver: 1. Control Video PLL from nwl-dsi driver Add support for the Video PLL into the nwl-dsi driver, in order to better control it's rate, depending on the requested video mode. Controlling the Video PLL from nwl-dsi is usefull, since it both drives the DC pixel-clock and DPHY phy_ref clock. On i.MX8MQ, the DC can be either DCSS or LCDIF. 2. Add new property to nwl-dsi: clock-drop-level This new property is usefull in order to use DSI panels with the nwl-dsi driver which require a higher overhead to the pixel-clock. For example, the Raydium RM67191 DSI Panel works with 132M pixel-clock, but it needs an overhead in order to work properly. So, the actual pixel-clock fed into the DSI DPI interface needs to be lower than the one used ad DSI output. This new property addresses this matter. 3. Add support to handle both inputs for nwl-dsi: DCSS and LCDIF Laurentiu Palcu (1): drm/bridge: nwl-dsi: add support for DCSS Robert Chiras (4): drm/bridge: nwl-dsi: Add support for video_pll dt-bindings: display/bridge: nwl-dsi: Document video_pll clock drm/bridge: nwl-dsi: Add support for clock-drop-level dt-bindings: display/bridge: nwl-dsi: Document fsl,clock-drop-level property .../bindings/display/bridge/nwl-dsi.yaml | 7 + drivers/gpu/drm/bridge/nwl-dsi.c | 338 - 2 files changed, 336 insertions(+), 9 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: virtio: fix kconfig dependency warning
On 8/28/20 4:25 AM, Gerd Hoffmann wrote: > Hi, > >> config DRM_VIRTIO_GPU >> tristate "Virtio GPU driver" >> -depends on DRM && VIRTIO && MMU >> +depends on DRM && VIRTIO_MENU && MMU > > Shouldn't this depend on both VIRTIO and VIRTIO_MENU, simliar to the > other virtio drivers? OK, I'll send a v2. thanks. -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/bridge: nwl-dsi: add support for DCSS
From: Laurentiu Palcu
DCSS needs active low VSYNC and HSYNC. Also, move the input selection in
the probe function, as this will not change at runtime.
Signed-off-by: Laurentiu Palcu
Signed-off-by: Robert Chiras
---
drivers/gpu/drm/bridge/nwl-dsi.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index ac4aa0a..c30f7a8 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -143,6 +143,7 @@ struct nwl_dsi {
struct nwl_dsi_transfer *xfer;
struct list_head valid_modes;
u32 clk_drop_lvl;
+ bool use_dcss;
};
static const struct regmap_config nwl_dsi_regmap_config = {
@@ -1036,16 +1037,16 @@ static int nwl_dsi_get_dphy_params(struct nwl_dsi *dsi,
static bool nwl_dsi_bridge_mode_fixup(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+ struct drm_display_mode *adjusted)
{
struct nwl_dsi *dsi = bridge_to_dsi(bridge);
struct mode_config *config;
unsigned long pll_rate;
DRM_DEV_DEBUG_DRIVER(dsi->dev, "Fixup mode:\n");
- drm_mode_debug_printmodeline(adjusted_mode);
+ drm_mode_debug_printmodeline(adjusted);
- config = nwl_dsi_mode_probe(dsi, adjusted_mode);
+ config = nwl_dsi_mode_probe(dsi, adjusted);
if (!config)
return false;
@@ -1067,12 +1068,16 @@ static bool nwl_dsi_bridge_mode_fixup(struct drm_bridge
*bridge,
}
/* Update the crtc_clock to be used by display controller */
if (config->crtc_clock)
- adjusted_mode->crtc_clock = config->crtc_clock / 1000;
+ adjusted->crtc_clock = config->crtc_clock / 1000;
-
- /* At least LCDIF + NWL needs active high sync */
- adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
- adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
+ if (!dsi->use_dcss) {
+ /* At least LCDIF + NWL needs active high sync */
+ adjusted->flags |= (DRM_MODE_FLAG_PHSYNC |
DRM_MODE_FLAG_PVSYNC);
+ adjusted->flags &= ~(DRM_MODE_FLAG_NHSYNC |
DRM_MODE_FLAG_NVSYNC);
+ } else {
+ adjusted->flags &= ~(DRM_MODE_FLAG_PHSYNC |
DRM_MODE_FLAG_PVSYNC);
+ adjusted->flags |= (DRM_MODE_FLAG_NHSYNC |
DRM_MODE_FLAG_NVSYNC);
+ }
return true;
}
@@ -1400,6 +1405,9 @@ static int nwl_dsi_select_input(struct nwl_dsi *dsi)
DRM_DEV_ERROR(dsi->dev, "Failed to select input: %d\n", ret);
of_node_put(remote);
+
+ dsi->use_dcss = use_dcss;
+
return ret;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1] iommu/vt-d: Move intel_iommu_gfx_mapped to Intel IOMMU header
Static analyzer is not happy about intel_iommu_gfx_mapped declaration:
.../drivers/iommu/intel/iommu.c:364:5: warning: symbol 'intel_iommu_gfx_mapped'
was not declared. Should it be static?
Move its declaration to Intel IOMMU header file.
Signed-off-by: Andy Shevchenko
---
include/drm/intel-gtt.h | 5 +
include/linux/intel-iommu.h | 1 +
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/drm/intel-gtt.h b/include/drm/intel-gtt.h
index 71d81923e6b0..abfefaaf897a 100644
--- a/include/drm/intel-gtt.h
+++ b/include/drm/intel-gtt.h
@@ -5,6 +5,7 @@
#define_DRM_INTEL_GTT_H
#include
+#include
#include
void intel_gtt_get(u64 *gtt_total,
@@ -33,8 +34,4 @@ void intel_gtt_clear_range(unsigned int first_entry, unsigned
int num_entries);
/* flag for GFDT type */
#define AGP_USER_CACHED_MEMORY_GFDT (1 << 3)
-#ifdef CONFIG_INTEL_IOMMU
-extern int intel_iommu_gfx_mapped;
-#endif
-
#endif
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 64fa5c56c825..fbd3bb64649b 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -794,6 +794,7 @@ extern int iommu_calculate_max_sagaw(struct intel_iommu
*iommu);
extern int dmar_disabled;
extern int intel_iommu_enabled;
extern int intel_iommu_tboot_noforce;
+extern int intel_iommu_gfx_mapped;
#else
static inline int iommu_calculate_agaw(struct intel_iommu *iommu)
{
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/2] Add LT9611UXC DSI to HDMI bridge support
Hi, This series adds support for Lontium LT9611UXC bridge chip which takes MIPI DSI as input and provides HDMI signal as output. The chip can be found in Qualcomm RB5 platform [1], [2]. [1] https://www.qualcomm.com/products/qualcomm-robotics-rb5-platform [2] https://www.thundercomm.com/app_en/product/1590131656070623 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/sun4i: Fix dsi dcs long write function
It's writing too much data. regmap_bulk_write expects number of register sized chunks to write, not a byte sized length of the bounce buffer. Bounce buffer needs to be padded too, so that regmap_bulk_write will not read past the end of the buffer. Signed-off-by: Ondrej Jirman --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 7f13f4d715bf..840fad1b68dd 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -889,7 +889,7 @@ static int sun6i_dsi_dcs_write_long(struct sun6i_dsi *dsi, regmap_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(0), sun6i_dsi_dcs_build_pkt_hdr(dsi, msg)); - bounce = kzalloc(msg->tx_len + sizeof(crc), GFP_KERNEL); + bounce = kzalloc(msg->tx_len + sizeof(crc) + 3, GFP_KERNEL); if (!bounce) return -ENOMEM; @@ -900,7 +900,7 @@ static int sun6i_dsi_dcs_write_long(struct sun6i_dsi *dsi, memcpy((u8 *)bounce + msg->tx_len, , sizeof(crc)); len += sizeof(crc); - regmap_bulk_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(1), bounce, len); + regmap_bulk_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(1), bounce, DIV_ROUND_UP(len, 4)); regmap_write(dsi->regs, SUN6I_DSI_CMD_CTL_REG, len + 4 - 1); kfree(bounce); -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/bridge: nwl-dsi: Add support for clock-drop-level
From: Robert Chiras
The clock-drop-level is needed in order to add more blanking space needed
by DSI panels when sending DSI commands. One level is the equivalent of
phy_ref rate from the PLL rate. Since the PLL rate is targeted as highest
possible, each level should not get the crtc_clock too low, compared to
the actual clock.
Example for a clock of 132M, with "clock-drop-level = <1>" in dts file
will result in a crtc_clock of 129M, using the following logic:
- video_pll rate to provide both phy_ref rate of 24M and pixel-clock
of 132M is 1056M (divisor /43 for phy_ref and /8 for pixel-clock)
- from this rate, we subtract the equivalent of phy_ref (24M) but
keep the same divisor. This way, the video_pll rate will be 1056 - 24
= 1032M.
- new pixel-clock will be: 1032 / 8 = 129M
For a "clock-drop-level = <2>", new pixel-clock will be:
(1056 - (24 * 2)) / 8 = 1008 / 8 = 126M
Signed-off-by: Robert Chiras
---
drivers/gpu/drm/bridge/nwl-dsi.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index 1228466..ac4aa0a 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -142,6 +142,7 @@ struct nwl_dsi {
struct nwl_dsi_transfer *xfer;
struct list_head valid_modes;
+ u32 clk_drop_lvl;
};
static const struct regmap_config nwl_dsi_regmap_config = {
@@ -842,13 +843,14 @@ static unsigned long nwl_dsi_get_lcm(unsigned long a,
unsigned long b)
return ((unsigned long long)a * b) / gcf;
}
-
/*
* This function tries to adjust the crtc_clock for a DSI device in such a way
* that the video pll will be able to satisfy both Display Controller pixel
* clock (feeding out DPI interface) and our input phy_ref clock.
+ * Also, the DC pixel clock must be lower than the actual clock in order to
+ * have enough blanking space to send DSI commands, if the device is a panel.
*/
-static void nwl_dsi_setup_pll_config(struct mode_config *config)
+static void nwl_dsi_setup_pll_config(struct mode_config *config, u32 lvl)
{
unsigned long pll_rate;
int div;
@@ -908,7 +910,6 @@ static void nwl_dsi_setup_pll_config(struct mode_config
*config)
}
}
-
/*
* This function will try the required phy speed for current mode
* If the phy speed can be achieved, the phy will save the speed
@@ -1103,7 +1104,7 @@ nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge,
pll_rate = config->pll_rates[config->phy_rate_idx];
if (dsi->pll_clk && !pll_rate)
- nwl_dsi_setup_pll_config(config);
+ nwl_dsi_setup_pll_config(config, dsi->clk_drop_lvl);
return MODE_OK;
}
@@ -1248,6 +1249,7 @@ static const struct drm_bridge_funcs nwl_dsi_bridge_funcs
= {
static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
{
struct platform_device *pdev = to_platform_device(dsi->dev);
+ struct device_node *np = dsi->dev->of_node;
struct clk *clk;
void __iomem *base;
int ret;
@@ -1364,6 +1366,8 @@ static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
return PTR_ERR(dsi->rst_dpi);
}
+ of_property_read_u32(np, "fsl,clock-drop-level", >clk_drop_lvl);
+
INIT_LIST_HEAD(>valid_modes);
return 0;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v6 2/6] drm/sprd: add Unisoc's drm kms master
Sam Ravnborg 于2020年7月29日周三 上午4:45写道：
>
> Hi Kevin.
>
> Nice split of the driver.
> Some feedback in the following.
> Most to bring the driver up-to-date with what have happened since
> we saw it last time.
> Keeping up with the changes in drm is not always easy.
>
> Sam
>
Hi Sam,
Thanks for your feedback,
I am really busy sometimes, but will try my best to keep up with others.
>
> On Tue, Jul 28, 2020 at 06:07:55PM +0800, Kevin Tang wrote:
> > From: Kevin Tang
> >
> > Adds drm support for the Unisoc's display subsystem.
> >
> > This is drm kms driver, this driver provides support for the
> > application framework in Android, Yocto and more.
> >
> > Application framework can access Unisoc's display internel
> > peripherals through libdrm or libkms, it's test ok by modetest
> > (DRM/KMS test tool) and Android HWComposer.
> >
> > Cc: Orson Zhai
> > Cc: Chunyan Zhang
> > Signed-off-by: Kevin Tang
> > ---
> > drivers/gpu/drm/Kconfig | 2 +
> > drivers/gpu/drm/Makefile| 1 +
> > drivers/gpu/drm/sprd/Kconfig| 12 +++
> > drivers/gpu/drm/sprd/Makefile | 5 +
> > drivers/gpu/drm/sprd/sprd_drm.c | 226
> >
> > drivers/gpu/drm/sprd/sprd_drm.h | 16 +++
> > 6 files changed, 262 insertions(+)
> > create mode 100644 drivers/gpu/drm/sprd/Kconfig
> > create mode 100644 drivers/gpu/drm/sprd/Makefile
> > create mode 100644 drivers/gpu/drm/sprd/sprd_drm.c
> > create mode 100644 drivers/gpu/drm/sprd/sprd_drm.h
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index c4fd57d..7fe7ab91 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -386,6 +386,8 @@ source "drivers/gpu/drm/mcde/Kconfig"
> >
> > source "drivers/gpu/drm/tidss/Kconfig"
> >
> > +source "drivers/gpu/drm/sprd/Kconfig"
> > +
> > # Keep legacy drivers last
> >
> > menuconfig DRM_LEGACY
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 2c0e5a7..ee2ccd9 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -123,3 +123,4 @@ obj-$(CONFIG_DRM_PANFROST) += panfrost/
> > obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
> > obj-$(CONFIG_DRM_MCDE) += mcde/
> > obj-$(CONFIG_DRM_TIDSS) += tidss/
> > +obj-$(CONFIG_DRM_SPRD) += sprd/
> > diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
> > new file mode 100644
> > index 000..b189a54
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/Kconfig
> > @@ -0,0 +1,12 @@
> > +config DRM_SPRD
> > + tristate "DRM Support for Unisoc SoCs Platform"
> > + depends on ARCH_SPRD || COMPILE_TEST
> > + depends on DRM && OF
> > + select DRM_KMS_HELPER
> > + select DRM_GEM_CMA_HELPER
> > + select DRM_KMS_CMA_HELPER
> > + select DRM_MIPI_DSI
> > + help
> > + Choose this option if you have a Unisoc chipsets.
> > + If M is selected the module will be called sprd-drm.
> > +
> > diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
> > new file mode 100644
> > index 000..86d95d9
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/Makefile
> > @@ -0,0 +1,5 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +subdir-ccflags-y += -I$(srctree)/$(src)
> subdir-ccflags-y is not needed - drop it.
>
> > +
> > +obj-y := sprd_drm.o
> > diff --git a/drivers/gpu/drm/sprd/sprd_drm.c
> > b/drivers/gpu/drm/sprd/sprd_drm.c
> > new file mode 100644
> > index 000..4706185
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/sprd_drm.c
> > @@ -0,0 +1,226 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2020 Unisoc Inc.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "sprd_drm.h"
> > +
> > +#define DRIVER_NAME "sprd"
> > +#define DRIVER_DESC "Spreadtrum SoCs' DRM Driver"
> > +#define DRIVER_DATE "20200201"
> > +#define DRIVER_MAJOR 1
> > +#define DRIVER_MINOR 0
> > +
> > +static const struct drm_mode_config_helper_funcs
> > sprd_drm_mode_config_helper = {
> > + .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
> > +};
> > +
> > +static const struct drm_mode_config_funcs sprd_drm_mode_config_funcs = {
> > + .fb_create = drm_gem_fb_create,
> > + .atomic_check = drm_atomic_helper_check,
> > + .atomic_commit = drm_atomic_helper_commit,
> > +};
> > +
> > +static void sprd_drm_mode_config_init(struct drm_device *drm)
> > +{
> > + drm_mode_config_init(drm);
> The documentation of this functions says:
>
> FIXME: This function is deprecated and drivers should be converted over to
> drmm_mode_config_init().
>
>
> > +
> > + drm->mode_config.min_width = 0;
> > + drm->mode_config.min_height = 0;
> > + drm->mode_config.max_width = 8192;
> > + drm->mode_config.max_height = 8192;
> > + drm->mode_config.allow_fb_modifiers =
[PATCH v2] drm/sun4i: Fix dsi dcs long write function
It's writing too much data. regmap_bulk_write expects number of
register sized chunks to write, not a byte sized length of the
bounce buffer. Bounce buffer needs to be padded too, so that
regmap_bulk_write will not read past the end of the buffer.
Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller support")
Signed-off-by: Ondrej Jirman
Reviewed-by: Jernej Skrabec
---
v2:
- use ALIGN
- add tags
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 7f13f4d715bf..840fad1b68dd 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -889,7 +889,7 @@ static int sun6i_dsi_dcs_write_long(struct sun6i_dsi *dsi,
regmap_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(0),
sun6i_dsi_dcs_build_pkt_hdr(dsi, msg));
- bounce = kzalloc(msg->tx_len + sizeof(crc), GFP_KERNEL);
+ bounce = kzalloc(ALIGN(msg->tx_len + sizeof(crc), 4), GFP_KERNEL);
if (!bounce)
return -ENOMEM;
@@ -900,7 +900,7 @@ static int sun6i_dsi_dcs_write_long(struct sun6i_dsi *dsi,
memcpy((u8 *)bounce + msg->tx_len, , sizeof(crc));
len += sizeof(crc);
- regmap_bulk_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(1), bounce, len);
+ regmap_bulk_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(1), bounce,
DIV_ROUND_UP(len, 4));
regmap_write(dsi->regs, SUN6I_DSI_CMD_CTL_REG, len + 4 - 1);
kfree(bounce);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] i2c: i2c-qcom-geni: Add shutdown callback for i2c
On 2020-08-21 05:52, Stephen Boyd wrote:
Quoting Roja Rani Yarubandi (2020-08-20 03:35:22)
If the hardware is still accessing memory after SMMU translation
is disabled (as part of smmu shutdown callback), then the
IOVAs (I/O virtual address) which it was using will go on the bus
as the physical addresses which will result in unknown crashes
like NoC/interconnect errors.
So, implement shutdown callback to i2c driver to unmap DMA mappings
during system "reboot" or "shutdown".
Signed-off-by: Roja Rani Yarubandi
---
I'd still put a Fixes tag because it's fixing the driver when someone
runs shutdown.
Okay, will add fixes tag.
Changes in V2:
- As per Stephen's comments added seperate function for stop
transfer,
fixed minor nitpicks.
drivers/i2c/busses/i2c-qcom-geni.c | 43
++
include/linux/qcom-geni-se.h | 5
2 files changed, 48 insertions(+)
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b/drivers/i2c/busses/i2c-qcom-geni.c
index 1fda5c7c2cfc..d07f2f33bb75 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -486,6 +486,28 @@ static int geni_i2c_xfer(struct i2c_adapter
*adap,
return ret;
}
+static void geni_i2c_stop_xfer(struct geni_i2c_dev *gi2c)
+{
+ u32 val;
+ struct geni_se *se = >se;
+
+ val = readl_relaxed(gi2c->se.base + SE_DMA_DEBUG_REG0);
+ if (val & DMA_TX_ACTIVE) {
+ geni_i2c_abort_xfer(gi2c);
+ gi2c->cur_wr = 0;
+ if (gi2c->err)
+ geni_i2c_tx_fsm_rst(gi2c);
+ geni_se_tx_dma_unprep(se, gi2c->tx_dma,
gi2c->xfer_len);
+ }
+ if (val & DMA_RX_ACTIVE) {
+ geni_i2c_abort_xfer(gi2c);
+ gi2c->cur_rd = 0;
+ if (gi2c->err)
+ geni_i2c_rx_fsm_rst(gi2c);
+ geni_se_rx_dma_unprep(se, gi2c->rx_dma,
gi2c->xfer_len);
+ }
+}
+
static u32 geni_i2c_func(struct i2c_adapter *adap)
{
return I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL &
~I2C_FUNC_SMBUS_QUICK);
@@ -617,6 +639,26 @@ static int geni_i2c_remove(struct platform_device
*pdev)
return 0;
}
+static void geni_i2c_shutdown(struct platform_device *pdev)
+{
+ int ret;
+ u32 dma;
+ struct geni_i2c_dev *gi2c = platform_get_drvdata(pdev);
+ struct geni_se *se = >se;
+
+ ret = pm_runtime_get_sync(gi2c->se.dev);
+ if (ret < 0) {
+ dev_err(gi2c->se.dev, "Failed to resume device: %d\n",
ret);
+ return;
+ }
+
+ dma = readl_relaxed(se->base + SE_GENI_DMA_MODE_EN);
+ if (dma)
+ geni_i2c_stop_xfer(gi2c);
Any reason the if (dma) check isn't inside geni_i2c_stop_xfer()?
Checking for dma and then bailing out early should work and keep the
logic in one function. Then the pm_runtime_sync() call could go in
there
too and if (!dma) goto out. This assumes that we're going to call
geni_i2c_stop_xfer() from somewhere else, like if a transfer times out
or something?
Okay, will do the changes.
+
+ pm_runtime_put_sync_suspend(gi2c->se.dev);
+}
+
static int __maybe_unused geni_i2c_runtime_suspend(struct device
*dev)
{
int ret;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/14] [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table
Hi Maxime, On Tue, 25 Aug 2020 at 15:35, Maxime Ripard wrote: > > Hi Clement, > > On Mon, Aug 03, 2020 at 09:54:05AM +0200, Clément Péron wrote: > > Hi Maxime and All, > > > > On Sat, 4 Jul 2020 at 16:56, Clément Péron wrote: > > > > > > Hi Maxime, > > > > > > On Sat, 4 Jul 2020 at 14:13, Maxime Ripard wrote: > > > > > > > > Hi, > > > > > > > > On Sat, Jul 04, 2020 at 12:25:34PM +0200, Clément Péron wrote: > > > > > Add an Operating Performance Points table for the GPU to > > > > > enable Dynamic Voltage & Frequency Scaling on the H6. > > > > > > > > > > The voltage range is set with minival voltage set to the target > > > > > and the maximal voltage set to 1.2V. This allow DVFS framework to > > > > > work properly on board with fixed regulator. > > > > > > > > > > Signed-off-by: Clément Péron > > > > > > > > That patch seems reasonable, why shouldn't we merge it? > > > > > > I didn't test it a lot and last time I did, some frequencies looked > > > unstable. > > > https://lore.kernel.org/patchwork/cover/1239739/ > > > > > > This series adds regulator support to Panfrost devfreq, I will send a > > > new one if DVFS on the H6 GPU is stable. > > > > > > I got this running glmark2 last time > > > # glmark2-es2-drm > > > === > > > glmark2 2017.07 > > > === > > > OpenGL Information > > > GL_VENDOR: Panfrost > > > GL_RENDERER: Mali T720 (Panfrost) > > > GL_VERSION:OpenGL ES 2.0 Mesa 20.0.5 > > > === > > > > > > [ 93.550063] panfrost 180.gpu: GPU Fault 0x0088 (UNKNOWN) at > > > 0x80117100 > > > [ 94.045401] panfrost 180.gpu: gpu sched timeout, js=0, > > > config=0x3700, status=0x8, head=0x21d6c00, tail=0x21d6c00, > > > sched_job=e3c2132f > > > > > > [ 328.871070] panfrost 180.gpu: Unhandled Page fault in AS0 at VA > > > 0x > > > [ 328.871070] Reason: TODO > > > [ 328.871070] raw fault status: 0xAA0003C2 > > > [ 328.871070] decoded fault status: SLAVE FAULT > > > [ 328.871070] exception type 0xC2: TRANSLATION_FAULT_LEVEL2 > > > [ 328.871070] access type 0x3: WRITE > > > [ 328.871070] source id 0xAA00 > > > [ 329.373327] panfrost 180.gpu: gpu sched timeout, js=1, > > > config=0x3700, status=0x8, head=0xa1a4900, tail=0xa1a4900, > > > sched_job=7ac31097 > > > [ 329.386527] panfrost 180.gpu: js fault, js=0, > > > status=DATA_INVALID_FAULT, head=0xa1a4c00, tail=0xa1a4c00 > > > [ 329.396293] panfrost 180.gpu: gpu sched timeout, js=0, > > > config=0x3700, status=0x58, head=0xa1a4c00, tail=0xa1a4c00, > > > sched_job=04c90381 > > > [ 329.411521] panfrost 180.gpu: Unhandled Page fault in AS0 at VA > > > 0x > > > [ 329.411521] Reason: TODO > > > [ 329.411521] raw fault status: 0xAA0003C2 > > > [ 329.411521] decoded fault status: SLAVE FAULT > > > [ 329.411521] exception type 0xC2: TRANSLATION_FAULT_LEVEL2 > > > [ 329.411521] access type 0x3: WRITE > > > [ 329.411521] source id 0xAA00 > > > > Just to keep a track of this issue. > > > > Piotr Oniszczuk give more test and seems to be software related: > > https://www.spinics.net/lists/dri-devel/msg264279.html > > > > Ondrej gave a great explanation about a possible origin of this issue: > > https://freenode.irclog.whitequark.org/linux-sunxi/2020-07-11 > > > > 20:12 looks like gpu pll on H6 is NKMP clock, and those are > > implemented in such a way in mainline that they are prone to > > overshooting the frequency during output divider reduction > > 20:13 so disabling P divider may help > > 20:13 or fixing the dividers > > 20:14 and just allowing N to change > > 20:22 hmm, I haven't looked at this for quite some time, but H6 > > BSP way of setting PLL factors actually makes the most sense out of > > everything I've seen/tested so far > > 20:23 it waits for lock not after setting NK factors, but after > > reducing the M factor (pre-divider) > > 20:24 I might as well re-run my CPU PLL tester with this > > algorithm, to see if it fixes the lockups > > 20:26 it makes sense to wait for PLL to stabilize "after" > > changing all the factors that actually affect the VCO, and not just > > some of them > > 20:27 warpme_: ^ > > 20:28 it may be the same thing that plagues the CPU PLL rate > > changes at runtime > > I guess it's one of the bugs we never heard of... > > It would be a good idea to test it on another platform (like Rockchip?) > to rule out any driver issue? > > What do you think? I can't exclude a bug in the driver, but if it was the case LE community or Panfrost maintainer would have heard of that. Megi's explanations match what I observed. NKMP drivers seem the perfect guilty here or maybe it's a combination of both... Jernej sent me this patch to test: https://github.com/clementperon/linux/commit/56bde359beaf8e827ce53ede1fe4a0ad233cb79b But it didn't fix the
Re: [PATCH v2 13/14] [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table
On Fri, Aug 28, 2020 at 02:16:36PM +0200, Clément Péron wrote: > Hi Maxime, > > On Tue, 25 Aug 2020 at 15:35, Maxime Ripard wrote: > > > > Hi Clement, > > > > On Mon, Aug 03, 2020 at 09:54:05AM +0200, Clément Péron wrote: > > > Hi Maxime and All, > > > > > > On Sat, 4 Jul 2020 at 16:56, Clément Péron wrote: > > > > > > > > Hi Maxime, > > > > > > > > On Sat, 4 Jul 2020 at 14:13, Maxime Ripard wrote: > > > > > > > > > > Hi, > > > > > > > > > > On Sat, Jul 04, 2020 at 12:25:34PM +0200, Clément Péron wrote: > > > > > > Add an Operating Performance Points table for the GPU to > > > > > > enable Dynamic Voltage & Frequency Scaling on the H6. > > > > > > > > > > > > The voltage range is set with minival voltage set to the target > > > > > > and the maximal voltage set to 1.2V. This allow DVFS framework to > > > > > > work properly on board with fixed regulator. > > > > > > > > > > > > Signed-off-by: Clément Péron > > > > > > > > > > That patch seems reasonable, why shouldn't we merge it? > > > > > > > > I didn't test it a lot and last time I did, some frequencies looked > > > > unstable. > > > > https://lore.kernel.org/patchwork/cover/1239739/ > > > > > > > > This series adds regulator support to Panfrost devfreq, I will send a > > > > new one if DVFS on the H6 GPU is stable. > > > > > > > > I got this running glmark2 last time > > > > # glmark2-es2-drm > > > > === > > > > glmark2 2017.07 > > > > === > > > > OpenGL Information > > > > GL_VENDOR: Panfrost > > > > GL_RENDERER: Mali T720 (Panfrost) > > > > GL_VERSION:OpenGL ES 2.0 Mesa 20.0.5 > > > > === > > > > > > > > [ 93.550063] panfrost 180.gpu: GPU Fault 0x0088 (UNKNOWN) at > > > > 0x80117100 > > > > [ 94.045401] panfrost 180.gpu: gpu sched timeout, js=0, > > > > config=0x3700, status=0x8, head=0x21d6c00, tail=0x21d6c00, > > > > sched_job=e3c2132f > > > > > > > > [ 328.871070] panfrost 180.gpu: Unhandled Page fault in AS0 at VA > > > > 0x > > > > [ 328.871070] Reason: TODO > > > > [ 328.871070] raw fault status: 0xAA0003C2 > > > > [ 328.871070] decoded fault status: SLAVE FAULT > > > > [ 328.871070] exception type 0xC2: TRANSLATION_FAULT_LEVEL2 > > > > [ 328.871070] access type 0x3: WRITE > > > > [ 328.871070] source id 0xAA00 > > > > [ 329.373327] panfrost 180.gpu: gpu sched timeout, js=1, > > > > config=0x3700, status=0x8, head=0xa1a4900, tail=0xa1a4900, > > > > sched_job=7ac31097 > > > > [ 329.386527] panfrost 180.gpu: js fault, js=0, > > > > status=DATA_INVALID_FAULT, head=0xa1a4c00, tail=0xa1a4c00 > > > > [ 329.396293] panfrost 180.gpu: gpu sched timeout, js=0, > > > > config=0x3700, status=0x58, head=0xa1a4c00, tail=0xa1a4c00, > > > > sched_job=04c90381 > > > > [ 329.411521] panfrost 180.gpu: Unhandled Page fault in AS0 at VA > > > > 0x > > > > [ 329.411521] Reason: TODO > > > > [ 329.411521] raw fault status: 0xAA0003C2 > > > > [ 329.411521] decoded fault status: SLAVE FAULT > > > > [ 329.411521] exception type 0xC2: TRANSLATION_FAULT_LEVEL2 > > > > [ 329.411521] access type 0x3: WRITE > > > > [ 329.411521] source id 0xAA00 > > > > > > Just to keep a track of this issue. > > > > > > Piotr Oniszczuk give more test and seems to be software related: > > > https://www.spinics.net/lists/dri-devel/msg264279.html > > > > > > Ondrej gave a great explanation about a possible origin of this issue: > > > https://freenode.irclog.whitequark.org/linux-sunxi/2020-07-11 > > > > > > 20:12 looks like gpu pll on H6 is NKMP clock, and those are > > > implemented in such a way in mainline that they are prone to > > > overshooting the frequency during output divider reduction > > > 20:13 so disabling P divider may help > > > 20:13 or fixing the dividers > > > 20:14 and just allowing N to change > > > 20:22 hmm, I haven't looked at this for quite some time, but H6 > > > BSP way of setting PLL factors actually makes the most sense out of > > > everything I've seen/tested so far > > > 20:23 it waits for lock not after setting NK factors, but after > > > reducing the M factor (pre-divider) > > > 20:24 I might as well re-run my CPU PLL tester with this > > > algorithm, to see if it fixes the lockups > > > 20:26 it makes sense to wait for PLL to stabilize "after" > > > changing all the factors that actually affect the VCO, and not just > > > some of them > > > 20:27 warpme_: ^ > > > 20:28 it may be the same thing that plagues the CPU PLL rate > > > changes at runtime > > > > I guess it's one of the bugs we never heard of... > > > > It would be a good idea to test it on another platform (like Rockchip?) > > to rule out any driver issue? > > > > What do you think? > > I can't exclude a bug in the driver, but if it was the case LE > community or Panfrost maintainer
Re: [PATCH v9 0/5] Add support for iMX8MQ Display Controller Subsystem
Hi Laurentiu. > As to who is going to do the actual merge, I know we had a brief > discussion about it some time ago and I was supposed to apply for > drm-misc rights, however it feels a little awkward to merge my own > code... :) You are encouraged to commit your own code, it is anyway you who knows the state of the code best. The golden rule is that the code must have been seen by somone else before you merge, are translated there must be an acked-by or reviewed-by on each of the patches. If you look at ths page: https://people.freedesktop.org/~seanpaul/whomisc.html You can see that a lot of people commit their own code in drm-misc. Example: Daniel Vetter , (authored=159 committed=249 self_committed=153) There is only a few patches written by Daniel that is committed by someone else. And all patches committed by Daniel carries an a-b or -rb by someone else. > Though, I might not even qualify for drm-misc rights anyway, > considering I haven't been very active in this area... :/ > > On that note, I will probably need help with the merging, provided it's > still happenning. Will you be able to help me out with this? If the challenge is only to push the patches to drm-misc-next there is a lot of people that can help you. I would be happy to do so, but would need a resend as I have deleted the patches from my inbox. I could dig the pathces out somewhere else, but a fresh rebase would be preferred. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/sun4i: backend: Disable alpha on the lowest plane on the A20
On Tue, Jul 28, 2020 at 9:48 PM Maxime Ripard wrote:
>
> Unlike we previously thought, the per-pixel alpha is just as broken on the
> A20 as it is on the A10. Remove the quirk that says we can use it.
>
> Cc: Paul Kocialkowski
> Fixes: dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for lowest plane
> alpha support")
> Signed-off-by: Maxime Ripard
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/sun4i: backend: Support alpha property on lowest plane
On Tue, Jul 28, 2020 at 9:48 PM Maxime Ripard wrote:
>
> Unlike what we previously thought, only the per-pixel alpha is broken on
> the lowest plane and the per-plane alpha isn't. Remove the check on the
> alpha property being set on the lowest plane to reject a mode.
>
> Cc: Paul Kocialkowski
> Fixes: dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for lowest plane
> alpha support")
> Signed-off-by: Maxime Ripard
Reviewed-by: Chen-Yu Tsai
once the build break is fixed.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/sun4i: tcon: Support the LVDS Dual-Link on the A20
On Thu, Jul 30, 2020 at 5:35 PM Maxime Ripard wrote:
>
> The A20 can use its second TCON as the secondary LVDS link in a dual-link
> setup, with the TCON0 being the main link. Extend a bit the parsing code to
> leverage the DRM dual-link code, register only the LVDS output on the
> primary TCON, and add the needed bits to setup the TCON properly.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 36 +++-
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 +++-
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index d03ad75f9900..ed2abf6eb18b 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -487,6 +487,9 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon
> *tcon,
> else
> reg |= SUN4I_TCON0_LVDS_IF_DATA_POL_NORMAL;
>
> + if (tcon->lvds_dual_link)
> + reg |= SUN4I_TCON0_LVDS_IF_DUAL_LINK;
> +
> if (sun4i_tcon_get_pixel_depth(encoder) == 24)
> reg |= SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS;
> else
> @@ -896,6 +899,16 @@ static int sun4i_tcon_register_panel(struct drm_device
> *drm,
> return sun4i_rgb_init(drm, tcon);
>
> /*
> +* Only the TCON0 will be relevant for the LVDS output, so if
> +* our ID is something else, let's prevent our TCON from
> +* registering its own LVDS output
> +*/
> + if (tcon->id) {
> + dev_info(dev, "Secondary TCON, disabling panel output");
Nit: "disabling" is a bit misleading.
Just stating that it is used as a secondary link
> + return 0;
> + }
> +
> + /*
> * This can only be made optional since we've had DT
> * nodes without the LVDS reset properties.
> *
> @@ -941,6 +954,28 @@ static int sun4i_tcon_register_panel(struct drm_device
> *drm,
> return -ENODEV;
> }
>
> + /*
> +* If we don't have a second TCON, we will never be able to do
> +* dual-link LVDS, so we don't have much more to do.
> +*/
> + companion = of_parse_phandle(dev->of_node,
> "allwinner,lvds-companion", 0);
> + if (!companion)
> + return 0;
I assume you want
return sun4i_lvds_init(drm, tcon);
otherwise single-link LVDS would not work anymore?
ChenYu
> +
> + /*
> +* Let's do a sanity check on the dual-link setup to make sure
> +* everything is properly described.
> +*/
> + ret = drm_of_lvds_get_dual_link_pixel_order(dev->of_node, 1, 0,
> + companion, 1, 0);
> + if (ret < 0) {
> + dev_err(dev, "Invalid Dual-Link Configuration.\n");
> + return ret;
> + }
> +
> + dev_info(dev, "Primary TCON, enabling LVDS Dual-Link");
> + tcon->lvds_dual_link = true;
> +
> return sun4i_lvds_init(drm, tcon);
> }
>
> @@ -1500,6 +1535,7 @@ static const struct sun4i_tcon_quirks
> sun7i_a20_tcon0_quirks = {
> };
>
> static const struct sun4i_tcon_quirks sun7i_a20_quirks = {
> + .supports_lvds = true,
> .has_channel_0 = true,
> .has_channel_1 = true,
> .dclk_min_div = 4,
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> index cfbf4e6c1679..51c4e09cdd13 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@ -98,6 +98,7 @@
>
> #define SUN4I_TCON0_LVDS_IF_REG0x84
> #define SUN4I_TCON0_LVDS_IF_EN BIT(31)
> +#define SUN4I_TCON0_LVDS_IF_DUAL_LINK BIT(30)
> #define SUN4I_TCON0_LVDS_IF_BITWIDTH_MASK BIT(26)
> #define SUN4I_TCON0_LVDS_IF_BITWIDTH_18BITS(1 << 26)
> #define SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS(0 << 26)
> @@ -274,6 +275,9 @@ struct sun4i_tcon {
> /* Associated crtc */
> struct sun4i_crtc *crtc;
>
> + /* Is the LVDS link a dual-channel link? */
> + boollvds_dual_link;
> +
> int id;
>
> /* TCON list management */
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/sun4i: tcon: Refactor the LVDS and panel probing
On Thu, Jul 30, 2020 at 5:35 PM Maxime Ripard wrote:
>
> The current code to parse the DT, deal with the older device trees, and
> register either the RGB or LVDS output has so far grown organically into
> the bind function and has become quite hard to extend properly.
>
> Let's move it into a single function that grabs all the resources it needs
> and registers the proper panel output.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Chen-Yu Tsai
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 139 +++---
> 1 file changed, 70 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 2a5a9903c4c6..d03ad75f9900 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -875,6 +875,75 @@ static int sun4i_tcon_init_regmap(struct device *dev,
> return 0;
> }
>
> +static int sun4i_tcon_register_panel(struct drm_device *drm,
> +struct sun4i_tcon *tcon)
> +{
> + struct device_node *companion;
> + struct device_node *remote;
> + struct device *dev = tcon->dev;
> + bool has_lvds_alt;
> + bool has_lvds_rst;
> + int ret;
> +
> + /*
> +* If we have an LVDS panel connected to the TCON, we should
> +* just probe the LVDS connector. Otherwise, let's just register
> +* an RGB panel.
> +*/
> + remote = of_graph_get_remote_node(dev->of_node, 1, 0);
> + if (!tcon->quirks->supports_lvds ||
> + !of_device_is_compatible(remote, "panel-lvds"))
> + return sun4i_rgb_init(drm, tcon);
Slightly related: IIRC there are a few LVDS panels supported in panel-simple
so they don't use the panel-lvds compatible. Any idea how to deal with those?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
