Re: [PATCH v2 2/2] drm/format_helper: Dual licence the file in GPL 2 and MIT

[Gerd Hoffmann]

On Sat, Feb 15, 2020 at 07:09:11PM +0100, Emmanuel Vadot wrote:
> From: Emmanuel Vadot 
> 
> Contributors for this file are :
> Gerd Hoffmann 
> Maxime Ripard 
> Noralf Trønnes 
> 
> Signed-off-by: Emmanuel Vadot 
> ---
>  drivers/gpu/drm/drm_format_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_format_helper.c 
> b/drivers/gpu/drm/drm_format_helper.c
> index 0897cb9aeaff..3b818f2b2392 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -1,4 +1,4 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> +// SPDX-License-Identifier: GPL-2.0 or MIT
>  /*
>   * Copyright (C) 2016 Noralf Trønnes
>   *

Acked-by: Gerd Hoffmann 

> -- 
> 2.25.0
> 

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

Re: [PATCHv4,04/36] drm/gem-fb-helper: Add special version of drm_gem_fb_size_check

[james qian wang (Arm Technology China)]

Hi Andrzej:

Really a good idea for introducing this custom size check, it's very
useful for some Komeda/malidp format, espcially pitch_multiplier, maybe
in future we can add it into into the drm_format_info.

On Fri, Dec 13, 2019 at 04:58:35PM +0100, Andrzej Pietrasiewicz wrote:
> The new version accepts a struct describing deviations from standard way of
> doing the size checks. The caller must provide the respective values.
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
>  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 47 
>  include/drm/drm_gem_framebuffer_helper.h | 16 +++
>  2 files changed, 55 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index 787edb9a916b..4201dc1f32a5 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -201,8 +201,9 @@ int drm_gem_fb_lookup(struct drm_device *dev,
>  EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
>  
>  /**
> - * drm_gem_fb_size_check() - Helper function for use in
> - *&drm_mode_config_funcs.fb_create implementations
> + * drm_gem_fb_size_check_special() - Helper function for use in
> + *&drm_mode_config_funcs.fb_create
> + *implementations
>   * @dev: DRM device
>   * @mode_cmd: Metadata from the userspace framebuffer creation request
>   *
> @@ -212,9 +213,10 @@ EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
>   * Returns:
>   * Zero on success or a negative error code on failure.
>   */
> -int drm_gem_fb_size_check(struct drm_device *dev,
> -   const struct drm_mode_fb_cmd2 *mode_cmd,
> -   struct drm_gem_object **objs)
> +int drm_gem_fb_size_check_special(struct drm_device *dev,

How about name it to drm_gem_fb_custom_size_check()

> +   const struct drm_mode_fb_cmd2 *mode_cmd,
> +   const struct drm_size_check *check,
> +   struct drm_gem_object **objs)
>  {
>   const struct drm_format_info *info;
>   int i;
> @@ -227,10 +229,19 @@ int drm_gem_fb_size_check(struct drm_device *dev,
>   unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
>   unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
>   unsigned int min_size;
> + u32 pitch = mode_cmd->pitches[i];
> +
> + if (check && check->use_pitch_multiplier)
> + if ((pitch * check->pitch_multiplier[i]) %
> + check->pitch_modulo)
> + return -EINVAL;
>  
> - min_size = (height - 1) * mode_cmd->pitches[i]
> -  + drm_format_info_min_pitch(info, i, width)
> -  + mode_cmd->offsets[i];
> + if (check && check->use_min_size)
> + min_size = check->min_size[i];
> + else
> + min_size = (height - 1) * pitch
> +  + drm_format_info_min_pitch(info, i, width)
> +  + mode_cmd->offsets[i];
>  
>   if (objs[i]->size < min_size)
>   return -EINVAL;
> @@ -239,6 +250,26 @@ int drm_gem_fb_size_check(struct drm_device *dev,
>   return 0;
>  
>  }
> +EXPORT_SYMBOL_GPL(drm_gem_fb_size_check_special);
> +
> +/**
> + * drm_gem_fb_size_check() - Helper function for use in
> + *&drm_mode_config_funcs.fb_create implementations
> + * @dev: DRM device
> + * @mode_cmd: Metadata from the userspace framebuffer creation request
> + *
> + * This function can be used to verify buffer sizes for all planes.
> + * It is caller's responsibility to put the objects on failure.
> + *
> + * Returns:
> + * Zero on success or a negative error code on failure.
> + */
> +int drm_gem_fb_size_check(struct drm_device *dev,
> +   const struct drm_mode_fb_cmd2 *mode_cmd,
> +   struct drm_gem_object **objs)
> +{
> + return drm_gem_fb_size_check_special(dev, mode_cmd, NULL, objs);
> +}
>  EXPORT_SYMBOL_GPL(drm_gem_fb_size_check);
>  
>  /**
> diff --git a/include/drm/drm_gem_framebuffer_helper.h 
> b/include/drm/drm_gem_framebuffer_helper.h
> index c85d4b152e91..74304a268694 100644
> --- a/include/drm/drm_gem_framebuffer_helper.h
> +++ b/include/drm/drm_gem_framebuffer_helper.h
> @@ -11,6 +11,18 @@ struct drm_mode_fb_cmd2;
>  struct drm_plane;
>  struct drm_plane_state;
>  struct drm_simple_display_pipe;
> +struct drm_size_check;
> +
> +/**
> + * struct drm_size_check - Description of special requirements for size 
> checks.
> + */
> +struct drm_size_check {
> + unsigned int min_size[4];
> + bool use_min_size;
> + u32 pitch_multiplier[4];
> + u32 pitch_modulo;
> + bool use_pitch_multiplier;
> +};
>  
>  struct drm_gem_object *drm_gem_fb_

[PATCH v2 12/12] MIPS: DTS: CI20: fix interrupt for pcf8563 RTC

[H. Nikolaus Schaller]

Interrupts should not be specified by interrupt line but by
gpio parent and reference.

Fixes: 73f2b940474d ("MIPS: CI20: DTS: Add I2C nodes")
Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/boot/dts/ingenic/ci20.dts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
b/arch/mips/boot/dts/ingenic/ci20.dts
index 8f9d182566db..4bacefa2cfce 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -298,7 +298,9 @@ Optional input supply properties:
rtc@51 {
compatible = "nxp,pcf8563";
reg = <0x51>;
-   interrupts = <110>;
+
+   interrupt-parent = <&gpf>;
+   interrupts = <30 IRQ_TYPE_LEVEL_LOW>;
};
 };
 
-- 
2.23.0

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

Re: [PATCH] drm/sun4i: tcon: Support LVDS on the A33

[Maxime Ripard]

On Fri, Feb 14, 2020 at 01:24:27PM +0100, Maxime Ripard wrote:
> The A33 TCON supports LVDS, so we can toggle the support switch.
>
> Signed-off-by: Maxime Ripard 

Sorry, that one was a spurious send-email run ...

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] drm/client: Dual licence the file in GPL-2 and MIT

[Denis Efremov]

15.02.2020 21:09, Emmanuel Vadot пишет:
> From: Emmanuel Vadot 
> 
> Contributors for this file are :
> Chris Wilson 
> Denis Efremov 
> Jani Nikula 
> Maxime Ripard 
> Noralf Trønnes 
> Sam Ravnborg 
> Thomas Zimmermann 
> 
> Signed-off-by: Emmanuel Vadot 

Acked-by: Denis Efremov 

for my one-line patch.

Thanks,
Denis

> ---
>  drivers/gpu/drm/drm_client.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index b031b45aa8ef..6b0c6ef8b9b3 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0 or MIT
>  /*
>   * Copyright 2018 Noralf Trønnes
>   */
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 10/12] MIPS: DTS: CI20: add DT node for SW1 as Enter button

[H. Nikolaus Schaller]

The SW1 button can be used as a simple one-button keyboard
and is connected to PD17.

Note: SW1 has a second meaning to change the boot sequence
when pressed while powering on.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/boot/dts/ingenic/ci20.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
b/arch/mips/boot/dts/ingenic/ci20.dts
index b4a820313992..8f9d182566db 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -4,6 +4,7 @@
 #include "jz4780.dtsi"
 #include 
 #include 
+#include 
 
 / {
compatible = "img,ci20", "ingenic,jz4780";
@@ -25,6 +26,17 @@
   0x3000 0x3000>;
};
 
+   gpio-keys {
+   compatible = "gpio-keys";
+
+   sw1 {
+   label = "ci20:sw1";
+   linux,code = ;
+   gpios = <&gpd 17 GPIO_ACTIVE_HIGH>;
+   wakeup-source;
+   };
+   };
+
leds {
compatible = "gpio-leds";
 
-- 
2.23.0

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

Re: [PATCH v7 01/13] dt-bindings: arm: move mmsys description to display

[Enric Balletbo i Serra]

Hi CK,

On 14/2/20 11:01, Matthias Brugger wrote:
> 
> 
> On 14/02/2020 07:42, CK Hu wrote:
>> Hi, Matthias:
>>
>> On Thu, 2020-02-13 at 21:19 +0100, matthias@kernel.org wrote:
>>> From: Matthias Brugger 
>>>
>>> The mmsys block provides registers and clocks for the display
>>> subsystem. The binding description should therefore live together with
>>> the rest of the display descriptions. Move it to display/mediatek.
>>>
>>
>> Yes, for the upstreamed driver, only display (DRM) use mmsys clock. For
>> some MDP patches [1] in progress, MDP also use mmsys clock. So we just
>> consider what's upstreamed now?
> 

Let me jump into the discussion, and sorry if my question is silly because I'm
just starting to look at this code.

IMO we should consider all the cases to find a proper fix on all this, and if
MDP uses also mmsys clocks this approach will not work. I think the main problem
here and the big question is what exactly is the MMSYS block, is an independent
clock controller that provides clocks to DRM and other blocks? or is hardly tied
to the DRM block in some way?

Could you give us a block schema on how the things are interconnected?

If is an independent clock controller I think there was a mistake when the first
drm driver was pushed by using the compatible = "mediatek,mt8173-mmsys" as id
for that driver.

Thanks,
 Enric


> I'm not sure if I understand you correctly. Are you proposing to keep the
> binding description in arm/mediatek?
> 
> Regards,
> Matthias
> 
>>
>> [1] https://patchwork.kernel.org/patch/11140747/
>>
>> Regards,
>> CK
>>
>>> Signed-off-by: Matthias Brugger 
>>>
>>> ---
>>>
>>> Changes in v7:
>>> - move the binding description
>>>
>>> Changes in v6: None
>>> Changes in v5: None
>>> Changes in v4: None
>>> Changes in v3: None
>>> Changes in v2: None
>>>
>>>  .../bindings/{arm => display}/mediatek/mediatek,mmsys.txt | 0
>>>  1 file changed, 0 insertions(+), 0 deletions(-)
>>>  rename Documentation/devicetree/bindings/{arm => 
>>> display}/mediatek/mediatek,mmsys.txt (100%)
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt 
>>> b/Documentation/devicetree/bindings/display/mediatek/mediatek,mmsys.txt
>>> similarity index 100%
>>> rename from 
>>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
>>> rename to 
>>> Documentation/devicetree/bindings/display/mediatek/mediatek,mmsys.txt
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 12/12] MIPS: DTS: CI20: fix interrupt for pcf8563 RTC

[Paul Cercueil]

Hi Nikolaus,


Le ven., févr. 14, 2020 at 17:10, H. Nikolaus Schaller 
 a écrit :

Interrupts should not be specified by interrupt line but by
gpio parent and reference.

Fixes: 73f2b940474d ("MIPS: CI20: DTS: Add I2C nodes")


If you add a Fixes tag, you should also add:
Cc: sta...@vger.kernel.org

if you're fixing something older than -rc1, which is the case here 
(alternatively Cc them manually, but just for these patches).


Same remark for your patch 05/12.

Cheers,
-Paul


Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/boot/dts/ingenic/ci20.dts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
b/arch/mips/boot/dts/ingenic/ci20.dts

index 8f9d182566db..4bacefa2cfce 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -298,7 +298,9 @@ Optional input supply properties:
rtc@51 {
compatible = "nxp,pcf8563";
reg = <0x51>;
-   interrupts = <110>;
+
+   interrupt-parent = <&gpf>;
+   interrupts = <30 IRQ_TYPE_LEVEL_LOW>;
};
 };

--
2.23.0




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

Re: [PATCH 1/1] Support LVDS output on Allwinner A20

[Maxime Ripard]

On Thu, Feb 13, 2020 at 08:11:10PM +0200, Andrey Lebedev wrote:
> On Thu, Feb 13, 2020 at 10:24:33AM +0100, Maxime Ripard wrote:
> > > > do you have a board when you have been able to test it?
> > >
> > > Yes, I have the hardware (Cubieboard 2) at hand, but I cannot change the
> > > any physical connections on it. FWIW, it is https://openvario.org, the
> > > device we are (painfully) trying to upgrade from old kernel-3.4 with
> > > proprietary mali drivers to contemporary software.
> >
> > What painpoints do you have?
>
> So, even though proprietary mali drivers worked well for us, they seem
> to hold us back to old kernel-3.4, and it started to get harder to avoid
> various compatibility issues with newer software. Since there seemed to
> be a good progress with OSS lima driver lately, we decided to try to
> replace mali with lima. And that naturally pulled to switch to DRM/KMS.

You can use the proprietary mali drivers with mainline too, but yeah
it's in maintainance mode these days and you should go for lima if
you're (re)starting from scratch.

> The first painpoint is this LVDS support problem: after a week of trial
> and error, I discovered that support was simply not there. But it seemed
> that not that much was actually missing and after couple of evenings
> deep into debugging, here we are.
>
> Another one is the screen rotation: the device is installed into the
> glider' instrument panel, and some pilots prefer it in portrait
> orientation.  Under old mali setup, all that (seemingly) was required
> was setting "fbcon=rotate:n" boot arg, and both linux console and
> graphical app (https://xcsoar.org/) rotated "automagically". With new
> DRM/KMS setup, only console is rotated, all graphical apps seem to see
> the screen in its "natural" landscape orientation. Do you know if there
> is any way to leverage DMS/KMS infrastructure to make screen appear
> rotated for userspace apps (writing to /sys/class/graphics/fb0/rotate
> didn't work)?  There's of course a plan B to teach the app to rotate its
> output, but that leads to problem number 3.

There's a rotation property that can be set by whatever you're using
on top of KMS, DRM_MODE_ROTATE_*, but I'm not sure the driver supports
it at the moment.

> And the 3rd outstanding problem is that app doesn't really work under
> lima module and lima mesa driver. It starts, but renders a black window.
> I haven't dug deeply into this yet, but it is possible that some opengl
> API isn't supported in OSS drivers yet (even though app only renders 2d
> graphics).

I have no idea on this one though, sorry :/

Maxime


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/2] drm/format_helper: Dual licence the file in GPL 2 and MIT

[Emmanuel Vadot]

From: Emmanuel Vadot 

Contributors for this file are :
Gerd Hoffmann 
Maxime Ripard 
Noralf Trønnes 

Signed-off-by: Emmanuel Vadot 
---
 drivers/gpu/drm/drm_format_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_format_helper.c 
b/drivers/gpu/drm/drm_format_helper.c
index 0897cb9aeaff..3b818f2b2392 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: GPL-2.0 */
+// SPDX-License-Identifier: GPL-2.0 or MIT
 /*
  * Copyright (C) 2016 Noralf Trønnes
  *
-- 
2.25.0

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

[PATCH v2 05/12] MIPS: DTS: CI20: fix PMU definitions for ACT8600

[H. Nikolaus Schaller]

There is a ACT8600 on the CI20 board and the bindings of the
ACT8865 driver have changed without updating the CI20 device
tree. Therefore the PMU can not be probed successfully and
is running in power-on reset state.

Fix DT to match the latest act8865-regulator bindings.

Fixes: 73f2b940474d ("MIPS: CI20: DTS: Add I2C nodes")
Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/boot/dts/ingenic/ci20.dts | 48 -
 1 file changed, 33 insertions(+), 15 deletions(-)

diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
b/arch/mips/boot/dts/ingenic/ci20.dts
index 37b93166bf22..e02a19db7ef1 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -148,6 +148,8 @@
pinctrl-0 = <&pins_uart4>;
 };
 
+#include 
+
 &i2c0 {
status = "okay";
 
@@ -161,65 +163,81 @@
reg = <0x5a>;
status = "okay";
 
+/*
+Optional input supply properties:
+- for act8600:
+  - vp1-supply: The input supply for DCDC_REG1
+  - vp2-supply: The input supply for DCDC_REG2
+  - vp3-supply: The input supply for DCDC_REG3
+  - inl-supply: The input supply for LDO_REG5, LDO_REG6, LDO_REG7 and LDO_REG8
+  SUDCDC_REG4, LDO_REG9 and LDO_REG10 do not have separate supplies.
+*/
+
regulators {
vddcore: SUDCDC1 {
-   regulator-name = "VDDCORE";
+   regulator-name = "DCDC_REG1";
regulator-min-microvolt = <110>;
regulator-max-microvolt = <110>;
regulator-always-on;
};
vddmem: SUDCDC2 {
-   regulator-name = "VDDMEM";
+   regulator-name = "DCDC_REG2";
regulator-min-microvolt = <150>;
regulator-max-microvolt = <150>;
regulator-always-on;
};
vcc_33: SUDCDC3 {
-   regulator-name = "VCC33";
+   regulator-name = "DCDC_REG3";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-always-on;
};
vcc_50: SUDCDC4 {
-   regulator-name = "VCC50";
+   regulator-name = "SUDCDC_REG4";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
regulator-always-on;
};
vcc_25: LDO_REG5 {
-   regulator-name = "VCC25";
+   regulator-name = "LDO_REG5";
regulator-min-microvolt = <250>;
regulator-max-microvolt = <250>;
regulator-always-on;
};
wifi_io: LDO_REG6 {
-   regulator-name = "WIFIIO";
+   regulator-name = "LDO_REG6";
regulator-min-microvolt = <250>;
regulator-max-microvolt = <250>;
regulator-always-on;
};
vcc_28: LDO_REG7 {
-   regulator-name = "VCC28";
+   regulator-name = "LDO_REG7";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
regulator-always-on;
};
vcc_15: LDO_REG8 {
-   regulator-name = "VCC15";
+   regulator-name = "LDO_REG8";
regulator-min-microvolt = <150>;
regulator-max-microvolt = <150>;
regulator-always-on;
};
-   vcc_18: LDO_REG9 {
-   regulator-name = "VCC18";
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <180>;
+   vrtc_18: LDO_REG9 {
+   regulator-name = "LDO_REG9";
+   /* Despite the datasheet stating 3.3V for REG9 
and
+  driver expecting that, REG9 outputs 1.8V.
+  Likely the CI20 uses a chip variant.
+  Since it is a simple on/off LDO the exact 
values
+ 

[PATCH 2/4] dt-bindings: panel: lvds: Add properties for clock and data polarities

[Maxime Ripard]

Some LVDS encoders can support multiple polarities on the data and
clock lanes, and similarly some panels require a given polarity on
their inputs. Add a property on the panel to configure the encoder
properly.

Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/panel/lvds.yaml | 10 -
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml 
b/Documentation/devicetree/bindings/display/panel/lvds.yaml
index d0083301acbe..4aa1ab38 100644
--- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
@@ -90,6 +90,16 @@ properties:
   CTL2: Data Enable
   CTL3: 0
 
+  clock-active-low:
+type: boolean
+description: >
+  If set, reverse the clock polarity on the clock lane.
+
+  data-active-low:
+type: boolean
+description: >
+  If set, reverse the bit polarity on all data lanes.
+
   data-mirror:
 type: boolean
 description:
-- 
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/2] ARM: sun7i: dts: Add LVDS panel support on A20

[Andrey Lebedev]

On Fri, Feb 14, 2020 at 09:53:51AM +0100, Maxime Ripard wrote:
> On Fri, Feb 14, 2020 at 10:43:58AM +0200, Andrey Lebedev wrote:
> > On Fri, Feb 14, 2020 at 08:52:18AM +0100, Maxime Ripard wrote:
> > > > > This will create a spurious warning message for TCON1, since we
> > > > > adjusted the driver to tell it supports LVDS, but there's no LVDS
> > > > > reset line, so we need to make it finer grained.
> > > >
> > > > Yes, I can attribute two of the messages in my dmesg log [1] to this
> > > > ("Missing LVDS properties" and "LVDS output disabled". "sun4i-tcon
> > > > 1c0d000.lcd-controller" is indeed tcon1). And yes, I can see how they
> > > > can be confusing to someone.
> > > >
> > > > I'd need some pointers on how to deal with that though (if we want to do
> > > > it in this scope).
> > >
> > > Like I was mentionning, you could introduce a new compatible for each
> > > TCON (tcon0 and tcon1) and only set the support_lvds flag for tcon0
> >
> > Can you give me an idea how that compatible might look like?
> >
> > tcon0: lcd-controller@1c0c000 {
> > compatible = "allwinner,sun7i-a20-tcon", 
> > "allwinner,lvds";
> >
> > or
> >
> > tcon0: lcd-controller@1c0c000 {
> > compatible = "allwinner,sun7i-a20-tcon", 
> > "allwinner,tcon0";
> >
> > ? Or something completely different?
> 
> Something like
> 
> &tcon0 {
> compatible = "allwinner,sun7i-a20-tcon0", "allwinner,sun7i-a20-tcon";
> };
> 
> &tcon1 {
> compatible = "allwinner,sun7i-a20-tcon1", "allwinner,sun7i-a20-tcon";
> };
> 

Hi Maxime, here is what I came up with, please take a look. If the
approach is right, I'll split it up and include into the patch set.

>From f3e45c958a9551a52ac26435785bdb572e54d8db Mon Sep 17 00:00:00 2001
From: Andrey Lebedev 
Date: Fri, 14 Feb 2020 23:21:59 +0200
Subject: [PATCH] Mark tcon0 to be the only tcon capable of LVDS on sun7i-a20

This allows to avoid warnings about reset line not provided for tcon1.

Signed-off-by: Andrey Lebedev 
---
 arch/arm/boot/dts/sun7i-a20.dtsi   |  2 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  2 ++
 3 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 3b3c366a2bee..bab59fc4d9b1 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -405,7 +405,7 @@
};
 
tcon0: lcd-controller@1c0c000 {
-   compatible = "allwinner,sun7i-a20-tcon";
+   compatible = "allwinner,sun7i-a20-tcon0", 
"allwinner,sun7i-a20-tcon";
reg = <0x01c0c000 0x1000>;
interrupts = ;
resets = <&ccu RST_TCON0>, <&ccu RST_LVDS>;
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 800a9bd86112..cb2040aec436 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1107,6 +1107,25 @@ static struct sunxi_engine 
*sun4i_tcon_find_engine(struct sun4i_drv *drv,
return sun4i_tcon_find_engine_traverse(drv, node, 0);
 }
 
+/*
+ * Check if given tcon supports LVDS
+ *
+ * Some of the sunxi SoC variants contain several timing controllers, but only
+ * one of them can be used to drive LVDS screen. In this case such tcon is
+ * identified in respective quirks struct: lvds_compatible_tcon property will
+ * hold "compatible" string of the tcon, that supports LVDS.
+ *
+ * If lvds_compatible_tcon is not set, all tcons are considered capable of
+ * driving LVDS.
+ */
+static bool sun4i_tcon_lvds_compat(struct device *dev, struct sun4i_tcon *tcon)
+{
+   if (tcon->quirks->lvds_compatible_tcon == NULL)
+   return true;
+   return of_device_is_compatible(dev->of_node,
+  tcon->quirks->lvds_compatible_tcon);
+}
+
 static int sun4i_tcon_bind(struct device *dev, struct device *master,
   void *data)
 {
@@ -1161,7 +1180,7 @@ static int sun4i_tcon_bind(struct device *dev, struct 
device *master,
return ret;
}
 
-   if (tcon->quirks->supports_lvds) {
+   if (tcon->quirks->supports_lvds && sun4i_tcon_lvds_compat(dev, tcon)) {
/*
 * This can only be made optional since we've had DT
 * nodes without the LVDS reset properties.
@@ -1481,6 +1500,7 @@ static const struct sun4i_tcon_quirks sun6i_a31s_quirks = 
{
 
 static const struct sun4i_tcon_quirks sun7i_a20_quirks = {
.supports_lvds  = true,
+   .lvds_compatible_tcon   = "allwinner,sun7i-a20-tcon0",
.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..bc87d28ee341 100644
--- a/drivers/gpu/drm/sun4i/sun4i_

Re: [PATCH v2 2/2] ARM: sun7i: dts: Add LVDS panel support on A20

[Maxime Ripard]

On Fri, Feb 14, 2020 at 10:43:58AM +0200, Andrey Lebedev wrote:
> On Fri, Feb 14, 2020 at 08:52:18AM +0100, Maxime Ripard wrote:
> > > > This will create a spurious warning message for TCON1, since we
> > > > adjusted the driver to tell it supports LVDS, but there's no LVDS
> > > > reset line, so we need to make it finer grained.
> > >
> > > Yes, I can attribute two of the messages in my dmesg log [1] to this
> > > ("Missing LVDS properties" and "LVDS output disabled". "sun4i-tcon
> > > 1c0d000.lcd-controller" is indeed tcon1). And yes, I can see how they
> > > can be confusing to someone.
> > >
> > > I'd need some pointers on how to deal with that though (if we want to do
> > > it in this scope).
> >
> > Like I was mentionning, you could introduce a new compatible for each
> > TCON (tcon0 and tcon1) and only set the support_lvds flag for tcon0
>
> Can you give me an idea how that compatible might look like?
>
>   tcon0: lcd-controller@1c0c000 {
>   compatible = "allwinner,sun7i-a20-tcon", 
> "allwinner,lvds";
>
> or
>
>   tcon0: lcd-controller@1c0c000 {
>   compatible = "allwinner,sun7i-a20-tcon", 
> "allwinner,tcon0";
>
> ? Or something completely different?

Something like

&tcon0 {
compatible = "allwinner,sun7i-a20-tcon0", "allwinner,sun7i-a20-tcon";
};

&tcon1 {
compatible = "allwinner,sun7i-a20-tcon1", "allwinner,sun7i-a20-tcon";
};

Maxime


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

[PATCH 2/3] gpu/drm: ingenic: Switch emulated fbdev to 16bpp

[Paul Cercueil]

The fbdev emulation is only ever used on Ingenic SoCs to run old SDL1
based games at 16bpp (rgb565). Recent applications generally talk to
DRM directly, and can request their favourite pixel format; so we can
make everybody happy by switching the emulated fbdev to 16bpp.

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 034961a40e98..9aa88fabbd2a 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -808,7 +808,7 @@ static int ingenic_drm_probe(struct platform_device *pdev)
goto err_devclk_disable;
}
 
-   ret = drm_fbdev_generic_setup(drm, 32);
+   ret = drm_fbdev_generic_setup(drm, 16);
if (ret)
dev_warn(dev, "Unable to start fbdev emulation: %i", ret);
 
-- 
2.25.0

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

Re: [PATCH v3 3/3] ARM: dts: sun7i: Add LVDS panel support on A20

[Maxime Ripard]

On Thu, Feb 13, 2020 at 10:18:57PM +0200, Andrey Lebedev wrote:
> From: Andrey Lebedev 
>
> Define pins for LVDS channels 0 and 1, configure reset line for tcon0 and
> provide sample LVDS panel, connected to tcon0.
>
> Signed-off-by: Andrey Lebedev 
> ---
>  arch/arm/boot/dts/sun7i-a20.dtsi | 28 ++--
>  1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi 
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 92b5be97085d..3b3c366a2bee 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -47,6 +47,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  / {
>   interrupt-parent = <&gic>;
> @@ -407,8 +408,8 @@
>   compatible = "allwinner,sun7i-a20-tcon";
>   reg = <0x01c0c000 0x1000>;
>   interrupts = ;
> - resets = <&ccu RST_TCON0>;
> - reset-names = "lcd";
> + resets = <&ccu RST_TCON0>, <&ccu RST_LVDS>;
> + reset-names = "lcd", "lvds";
>   clocks = <&ccu CLK_AHB_LCD0>,
><&ccu CLK_TCON0_CH0>,
><&ccu CLK_TCON0_CH1>;
> @@ -444,6 +445,11 @@
>   #size-cells = <0>;
>   reg = <1>;
>
> + tcon0_out_lvds: endpoint@0 {
> + reg = <0>;
> + allwinner,tcon-channel = <0>;
> + };
> +
>   tcon0_out_hdmi: endpoint@1 {
>   reg = <1>;
>   remote-endpoint = 
> <&hdmi_in_tcon0>;
> @@ -1162,6 +1168,24 @@
>   pins = "PI20", "PI21";
>   function = "uart7";
>   };
> +
> + /omit-if-no-ref/
> + lcd_lvds0_pins: lcd-lvds0-pins {

The nodes here should be ordered by alphabetical order

> + pins =

I'm not sure why you need a new line here

> + "PD0", "PD1", "PD2", "PD3", "PD4",
> + "PD5", "PD6", "PD7", "PD8", "PD9";
> + function = "lvds0";
> + allwinner,drive = ;

And allwinner,drive is also deprecated and at its default value anyway

Maxime


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

[PATCH] drm/sun4i: dsi: Avoid hotplug race with DRM driver bind

[Samuel Holland]

We need to make sure that the DRM driver is fully registered before
allowing the panel to be attached. Otherwise, we may trigger a hotplug
event before sun4i_framebuffer_init() sets up drm->mode_config.funcs,
causing a NULL pointer dereference.

Fixes: 1a2703bd7356 ("drm/sun4i: dsi: Allow binding the host without a panel")
Signed-off-by: Samuel Holland 
---

This fixes a bug in my previous patch series, that I didn't catch until
it was already merged.

---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 9aa78c73873c..9cc1bb69fcda 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -970,7 +970,7 @@ static int sun6i_dsi_attach(struct mipi_dsi_host *host,
 
if (IS_ERR(panel))
return PTR_ERR(panel);
-   if (!dsi->drm)
+   if (!dsi->drm || !dsi->drm->registered)
return -EPROBE_DEFER;
 
dsi->panel = panel;
-- 
2.24.1

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

[PATCH v2 08/12] MIPS: DTS: CI20: add DT node for IR sensor

[H. Nikolaus Schaller]

From: Alex Smith 

The infrared sensor on the CI20 board is connected to a GPIO and can
be operated by using the gpio-ir-recv driver. Add a DT node for the
sensor to allow that driver to be used.

Signed-off-by: Alex Smith 
Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/boot/dts/ingenic/ci20.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
b/arch/mips/boot/dts/ingenic/ci20.dts
index e1364f941c7d..b4a820313992 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -62,6 +62,11 @@
enable-active-high;
};
 
+   ir: ir-receiver {
+   compatible = "gpio-ir-receiver";
+   gpios = <&gpe 3 GPIO_ACTIVE_LOW>;
+   };
+
wlan0_power: fixedregulator@1 {
compatible = "regulator-fixed";
regulator-name = "wlan0_power";
-- 
2.23.0

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

[PATCH 1/4] drm/connector: Add data polarity flags

[Maxime Ripard]

Some LVDS encoders can change the polarity of the data signals being
sent. Add a DRM bus flag to reflect this.

Signed-off-by: Maxime Ripard 
---
 include/drm/drm_connector.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 221910948b37..9a08fe6ab7c2 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -330,6 +330,8 @@ enum drm_panel_orientation {
  * edge of the pixel clock
  * @DRM_BUS_FLAG_SHARP_SIGNALS:Set if the Sharp-specific 
signals
  * (SPL, CLS, PS, REV) must be used
+ * @DRM_BUS_FLAG_DATA_LOW: The Data signals are active low
+ * @DRM_BUS_FLAG_DATA_HIGH:The Data signals are active high
  */
 enum drm_bus_flags {
DRM_BUS_FLAG_DE_LOW = BIT(0),
@@ -349,6 +351,8 @@ enum drm_bus_flags {
DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE = DRM_BUS_FLAG_SYNC_NEGEDGE,
DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE = DRM_BUS_FLAG_SYNC_POSEDGE,
DRM_BUS_FLAG_SHARP_SIGNALS = BIT(8),
+   DRM_BUS_FLAG_DATA_LOW = BIT(9),
+   DRM_BUS_FLAG_DATA_HIGH = BIT(10),
 };
 
 /**
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/sun4i: tcon: Support LVDS on the A33

[Maxime Ripard]

The A33 TCON supports LVDS, so we can toggle the support switch.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index fdf143042f83..14026b4fa7c7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1475,6 +1475,7 @@ static const struct sun4i_tcon_quirks sun8i_a33_quirks = {
.has_channel_0  = true,
.has_lvds_alt   = true,
.dclk_min_div   = 1,
+   .supports_lvds  = true,
 };
 
 static const struct sun4i_tcon_quirks sun8i_a83t_lcd_quirks = {
-- 
2.24.1

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

[PATCH 1/2] dt-bindings: display: sun4i-tcon: Add LVDS Dual Link property

[Maxime Ripard]

SoCs that have multiple TCONs can use the two set of pins on the first TCON
to drive a dual-link display. Add a property to enable the dual link.

Signed-off-by: Maxime Ripard 
---
 .../bindings/display/allwinner,sun4i-a10-tcon.yaml | 7 +++
 1 file changed, 7 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml 
b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
index 86ad617d2327..aa6dd8409dbc 100644
--- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
+++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
@@ -105,6 +105,13 @@ properties:
 - const: edp
 - const: lvds
 
+  allwinner,lvds-dual-link:
+type: boolean
+description: |
+  On a SoC with two TCON with LVDS support, the first TCON can
+  operate over both pins sets to output in a dual-link setup. This
+  will be triggered by setting this property.
+
   ports:
 type: object
 description: |
-- 
2.24.1

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

[PATCH] Correct typos in comments

[Maya Rashish]

Signed-off-by: Maya Rashish 
Co-authored-by: Thomas Klausner 
---
 drivers/gpu/drm/amd/include/atombios.h | 20 ++--
 drivers/gpu/drm/amd/include/atomfirmware.h |  4 ++--
 drivers/gpu/drm/radeon/atombios.h  |  8 
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|  2 +-
 4 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/amd/include/atombios.h 
b/drivers/gpu/drm/amd/include/atombios.h
index 8ba21747b40a..2f124c1a9c8e 100644
--- a/drivers/gpu/drm/amd/include/atombios.h
+++ b/drivers/gpu/drm/amd/include/atombios.h
@@ -1987,9 +1987,9 @@ typedef struct _PIXEL_CLOCK_PARAMETERS_V6
 #define PIXEL_CLOCK_V6_MISC_HDMI_BPP_MASK   0x0c
 #define PIXEL_CLOCK_V6_MISC_HDMI_24BPP  0x00
 #define PIXEL_CLOCK_V6_MISC_HDMI_36BPP  0x04
-#define PIXEL_CLOCK_V6_MISC_HDMI_36BPP_V6   0x08//for V6, the 
correct defintion for 36bpp should be 2 for 36bpp(2:1)
+#define PIXEL_CLOCK_V6_MISC_HDMI_36BPP_V6   0x08//for V6, the 
correct definition for 36bpp should be 2 for 36bpp(2:1)
 #define PIXEL_CLOCK_V6_MISC_HDMI_30BPP  0x08
-#define PIXEL_CLOCK_V6_MISC_HDMI_30BPP_V6   0x04//for V6, the 
correct defintion for 30bpp should be 1 for 36bpp(5:4)
+#define PIXEL_CLOCK_V6_MISC_HDMI_30BPP_V6   0x04//for V6, the 
correct definition for 30bpp should be 1 for 36bpp(5:4)
 #define PIXEL_CLOCK_V6_MISC_HDMI_48BPP  0x0c
 #define PIXEL_CLOCK_V6_MISC_REF_DIV_SRC 0x10
 #define PIXEL_CLOCK_V6_MISC_GEN_DPREFCLK0x40
@@ -2420,7 +2420,7 @@ typedef struct _LVDS_ENCODER_CONTROL_PARAMETERS
 typedef struct _LVDS_ENCODER_CONTROL_PARAMETERS_V2
 {
   USHORT usPixelClock;  // in 10KHz; for bios convenient
-  UCHAR  ucMisc;// see PANEL_ENCODER_MISC_xx defintions below
+  UCHAR  ucMisc;// see PANEL_ENCODER_MISC_xx definitions below
   UCHAR  ucAction;  // 0: turn off encoder
 // 1: setup and turn on encoder
   UCHAR  ucTruncate;// bit0=0: Disable truncate
@@ -2873,7 +2873,7 @@ typedef struct _ATOM_MULTIMEDIA_CONFIG_INFO
 // Structures used in FirmwareInfoTable
 //
 
-// usBIOSCapability Defintion:
+// usBIOSCapability Definition:
 // Bit 0 = 0: Bios image is not Posted, =1:Bios image is Posted;
 // Bit 1 = 0: Dual CRTC is not supported, =1: Dual CRTC is supported;
 // Bit 2 = 0: Extended Desktop is not supported, =1: Extended Desktop is 
supported;
@@ -4213,7 +4213,7 @@ typedef struct _ATOM_DPCD_INFO
 #define ATOM_DPCD_MAX_LANE_MASK0x1F
 
 /**/
-// VRAM usage and their defintions
+// VRAM usage and their definitions
 
 // One chunk of VRAM used by Bios are for HWICON surfaces,EDID data.
 // Current Mode timing and Dail Timing and/or STD timing data EACH device. 
They can be broken down as below.
@@ -6753,7 +6753,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
 #define ATOM_S0_SYSTEM_POWER_STATE_VALUE_LITEAC 3
 #define ATOM_S0_SYSTEM_POWER_STATE_VALUE_LIT2AC 4
 
-//Byte aligned defintion for BIOS usage
+//Byte aligned definition for BIOS usage
 #define ATOM_S0_CRT1_MONOb0 0x01
 #define ATOM_S0_CRT1_COLORb00x02
 #define ATOM_S0_CRT1_MASKb0 
(ATOM_S0_CRT1_MONOb0+ATOM_S0_CRT1_COLORb0)
@@ -6819,7 +6819,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
 #define ATOM_S2_DISPLAY_ROTATION_ANGLE_MASK   0xC000L
 
 
-//Byte aligned defintion for BIOS usage
+//Byte aligned definition for BIOS usage
 #define ATOM_S2_TV1_STANDARD_MASKb0 0x0F
 #define ATOM_S2_CURRENT_BL_LEVEL_MASKb1 0xFF
 #define ATOM_S2_DEVICE_DPMS_STATEb2 0x01
@@ -6871,7 +6871,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
 
 
 
-//Byte aligned defintion for BIOS usage
+//Byte aligned definition for BIOS usage
 #define ATOM_S3_CRT1_ACTIVEb0   0x01
 #define ATOM_S3_LCD1_ACTIVEb0   0x02
 #define ATOM_S3_TV1_ACTIVEb00x04
@@ -6910,7 +6910,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
 #define ATOM_S4_LCD1_REFRESH_MASK   0xFF00L
 #define ATOM_S4_LCD1_REFRESH_SHIFT  8
 
-//Byte aligned defintion for BIOS usage
+//Byte aligned definition for BIOS usage
 #define ATOM_S4_LCD1_PANEL_ID_MASKb00x0FF
 #define ATOM_S4_LCD1_REFRESH_MASKb1 ATOM_S4_LCD1_PANEL_ID_MASKb0
 #define ATOM_S4_VRAM_INFO_MASKb2ATOM_S4_LCD1_PANEL_ID_MASKb0
@@ -6989,7 +6989,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
 #define ATOM_S6_VRI_BRIGHTNESS_CHANGE   0x4000L
 #define ATOM_S6_CONFIG_DISPLAY_CHANGE_MASK  0x8000L
 
-//Byte aligned defintion for BIOS usage
+//Byte aligned definition for BIOS usage
 #define ATOM_S6_DEVICE_CHANGEb0 0x01
 #define ATOM_S6_SCALER_CHANGEb0 0x02
 #define ATOM_S6_LID_CHANGEb00x04
diff --git a/drivers/gpu/drm/amd/include/atomfirmware.h 
b/drivers/gpu/drm/amd/include/atomfirmware.h
index 7014651

[PATCH 4/4] drm/sun4i: lvds: Support data and clock polarity flags

[Maxime Ripard]

Our LVDS encoder can change the polarity of data and clock signals on
the LVDS link. Make sure we don't ignore the matching bus flags.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c81cdce6ed55..fdf143042f83 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -404,6 +404,8 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon 
*tcon,
  const struct drm_encoder *encoder,
  const struct drm_display_mode *mode)
 {
+   struct drm_connector *connector = sun4i_tcon_get_connector(encoder);
+   const struct drm_display_info *info = &connector->display_info;
unsigned int bp;
u8 clk_delay;
u32 reg, val = 0;
@@ -449,9 +451,17 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon 
*tcon,
 SUN4I_TCON0_BASIC2_V_TOTAL(mode->crtc_vtotal * 2) |
 SUN4I_TCON0_BASIC2_V_BACKPORCH(bp));
 
-   reg = SUN4I_TCON0_LVDS_IF_CLK_SEL_TCON0 |
-   SUN4I_TCON0_LVDS_IF_DATA_POL_NORMAL |
-   SUN4I_TCON0_LVDS_IF_CLK_POL_NORMAL;
+   reg = SUN4I_TCON0_LVDS_IF_CLK_SEL_TCON0;
+   if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
+   reg |= SUN4I_TCON0_LVDS_IF_CLK_POL_INV;
+   else
+   reg |= SUN4I_TCON0_LVDS_IF_CLK_POL_NORMAL;
+
+   if (info->bus_flags & DRM_BUS_FLAG_DATA_LOW)
+   reg |= SUN4I_TCON0_LVDS_IF_DATA_POL_INV;
+   else
+   reg |= SUN4I_TCON0_LVDS_IF_DATA_POL_NORMAL;
+
if (sun4i_tcon_get_pixel_depth(encoder) == 24)
reg |= SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS;
else
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 03/12] MIPS: CI20: defconfig: configure for supporting modules

[H. Nikolaus Schaller]

Not all drivers need to be compiled into the kernel.
Support building and loading of kernel modules.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/configs/ci20_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index be41df2a81fb..e0d3c9d4c2ae 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -1,4 +1,5 @@
 # CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_MODULES=y
 CONFIG_KERNEL_XZ=y
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
-- 
2.23.0

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

Re: [PATCH 3/4] drm/sun4i: dsi: Allow binding the host without a panel

[Samuel Holland]

Maxime,

On 2/11/20 1:28 AM, Samuel Holland wrote:
> Currently, the DSI host blocks binding the display pipeline until the
> panel is available. This unnecessarily prevents other display outpus
> from working, and adds logspam to dmesg when the panel driver is built
> as a module (the component master is unsuccessfully brought up several
> times during boot).
> 
> Flip the dependency, instead requiring the host to be bound before the
> panel is attached. The panel driver provides no functionality outside of
> the display pipeline anyway.
> 
> Since the panel is now probed after the DRM connector, we need a hotplug
> event to turn on the connector after the panel is attached.
> 
> This has the added benefit of fixing panel module removal/insertion.
> Previously, the panel would be turned off when its module was removed.
> But because the connector state was hardcoded, nothing knew to turn the
> panel back on when it was re-attached. Now, with hotplug events
> available, the connector state will follow the panel module state, and
> the panel will be re-enabled properly.
> 
> Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller 
> support")
> Signed-off-by: Samuel Holland 
> ---
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 22 --
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |  1 +
>  2 files changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 019fdf4ec274..ef35ce5a9bb0 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -804,7 +804,10 @@ static struct drm_connector_helper_funcs 
> sun6i_dsi_connector_helper_funcs = {
>  static enum drm_connector_status
>  sun6i_dsi_connector_detect(struct drm_connector *connector, bool force)
>  {
> - return connector_status_connected;
> + struct sun6i_dsi *dsi = connector_to_sun6i_dsi(connector);
> +
> + return dsi->panel ? connector_status_connected :
> + connector_status_disconnected;
>  }
>  
>  static const struct drm_connector_funcs sun6i_dsi_connector_funcs = {
> @@ -945,10 +948,15 @@ static int sun6i_dsi_attach(struct mipi_dsi_host *host,
>  
>   if (IS_ERR(panel))
>   return PTR_ERR(panel);
> + if (!dsi->drm)
> + return -EPROBE_DEFER;

There's actually a bug here. If the panel and DSI drivers are loaded in
parallel, sun6i_dsi_attach() can be called after sun6i_dsi_bind() but before
sun4i_framebuffer_init() initializes drm->mode_config.funcs, causing the hotplug
call to crash. This check also needs to consider dsi->drm->registered before
allowing the panel to be added.

I can send a v2 or a follow-up, whichever you prefer.

Thanks,
Samuel

>   dsi->panel = panel;
>   dsi->device = device;
>  
> + drm_panel_attach(dsi->panel, &dsi->connector);
> + drm_kms_helper_hotplug_event(dsi->drm);
> +
>   dev_info(host->dev, "Attached device %s\n", device->name);
>  
>   return 0;
> @@ -958,10 +966,14 @@ static int sun6i_dsi_detach(struct mipi_dsi_host *host,
>   struct mipi_dsi_device *device)
>  {
>   struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
> + struct drm_panel *panel = dsi->panel;
>  
>   dsi->panel = NULL;
>   dsi->device = NULL;
>  
> + drm_panel_detach(panel);
> + drm_kms_helper_hotplug_event(dsi->drm);
> +
>   return 0;
>  }
>  
> @@ -1026,9 +1038,6 @@ static int sun6i_dsi_bind(struct device *dev, struct 
> device *master,
>   struct sun6i_dsi *dsi = dev_get_drvdata(dev);
>   int ret;
>  
> - if (!dsi->panel)
> - return -EPROBE_DEFER;
> -
>   drm_encoder_helper_add(&dsi->encoder,
>  &sun6i_dsi_enc_helper_funcs);
>   ret = drm_encoder_init(drm,
> @@ -1054,7 +1063,8 @@ static int sun6i_dsi_bind(struct device *dev, struct 
> device *master,
>   }
>  
>   drm_connector_attach_encoder(&dsi->connector, &dsi->encoder);
> - drm_panel_attach(dsi->panel, &dsi->connector);
> +
> + dsi->drm = drm;
>  
>   return 0;
>  
> @@ -1068,7 +1078,7 @@ static void sun6i_dsi_unbind(struct device *dev, struct 
> device *master,
>  {
>   struct sun6i_dsi *dsi = dev_get_drvdata(dev);
>  
> - drm_panel_detach(dsi->panel);
> + dsi->drm = NULL;
>  }
>  
>  static const struct component_ops sun6i_dsi_ops = {
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h 
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> index 61e88ea6044d..c863900ae3b4 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> @@ -29,6 +29,7 @@ struct sun6i_dsi {
>  
>   struct device   *dev;
>   struct mipi_dsi_device  *device;
> + struct drm_device   *drm;
>   struct drm_panel*panel;
>  };
>  
> 

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

[PATCH 2/2] drm/sun4i: tcon: Support LVDS dual-link

[Maxime Ripard]

Some LVDS encoders in the Allwinner SoCs can output on a dual-link. Let's
add a DT property to toggle it.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++
 drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index e616cc901b4e..ed1f09e52ef3 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -488,6 +488,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
@@ -1219,6 +1222,9 @@ static int sun4i_tcon_bind(struct device *dev, struct 
device *master,
} else {
can_lvds = true;
}
+
+   tcon->lvds_dual_link = of_property_read_bool(dev->of_node,
+
"allwinner,lvds-dual-link");
} else {
can_lvds = false;
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index d36c304b1607..2a57d24e2772 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)
@@ -263,6 +264,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 */
-- 
2.24.1

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

[PATCH 3/4] drm/panel: lvds: Support data and clock polarity flags

[Maxime Ripard]

Add device tree properties to the panel-lvds driver to set the bus
flags properly.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/panel/panel-lvds.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-lvds.c 
b/drivers/gpu/drm/panel/panel-lvds.c
index 5ce3f4a2b7a1..c0d6dcd9e9fc 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -31,6 +31,8 @@ struct panel_lvds {
unsigned int height;
struct videomode video_mode;
unsigned int bus_format;
+   bool clk_active_low;
+   bool data_active_low;
bool data_mirror;
 
struct regulator *supply;
@@ -83,6 +85,7 @@ static int panel_lvds_get_modes(struct drm_panel *panel,
 {
struct panel_lvds *lvds = to_panel_lvds(panel);
struct drm_display_mode *mode;
+   unsigned int flags = 0;
 
mode = drm_mode_create(connector->dev);
if (!mode)
@@ -96,9 +99,23 @@ static int panel_lvds_get_modes(struct drm_panel *panel,
connector->display_info.height_mm = lvds->height;
drm_display_info_set_bus_formats(&connector->display_info,
 &lvds->bus_format, 1);
-   connector->display_info.bus_flags = lvds->data_mirror
- ? DRM_BUS_FLAG_DATA_LSB_TO_MSB
- : DRM_BUS_FLAG_DATA_MSB_TO_LSB;
+
+   if (lvds->data_mirror)
+   flags |= DRM_BUS_FLAG_DATA_LSB_TO_MSB;
+   else
+   flags |= DRM_BUS_FLAG_DATA_MSB_TO_LSB;
+
+   if (lvds->clk_active_low)
+   flags |= DRM_BUS_FLAG_PIXDATA_NEGEDGE;
+   else
+   flags |= DRM_BUS_FLAG_PIXDATA_POSEDGE;
+
+   if (lvds->data_active_low)
+   flags |= DRM_BUS_FLAG_DATA_LOW;
+   else
+   flags |= DRM_BUS_FLAG_DATA_HIGH;
+
+   connector->display_info.bus_flags = flags;
 
return 1;
 }
@@ -159,6 +176,8 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
return -EINVAL;
}
 
+   lvds->clk_active_low = of_property_read_bool(np, "clock-active-low");
+   lvds->data_active_low = of_property_read_bool(np, "data-active-low");
lvds->data_mirror = of_property_read_bool(np, "data-mirror");
 
return 0;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 17/30] drm/vkms: Add missing annotation for vkms_crtc_atomic_flush()

[Jules Irenge]

Sparse reports a warning at vkms_crtc_atomic_flush()

warning: context imbalance in vkms_crtc_atomic_flush()
 - unexpected unlock

The root cause is the missing annotation at vkms_crtc_atomic_flush()
Add the missing __releases(&vkms_output->lock) annotation

Signed-off-by: Jules Irenge 
---
 drivers/gpu/drm/vkms/vkms_crtc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 7513be6444ae..bc0ac2641220 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -231,6 +231,7 @@ static void vkms_crtc_atomic_begin(struct drm_crtc *crtc,
 
 static void vkms_crtc_atomic_flush(struct drm_crtc *crtc,
   struct drm_crtc_state *old_crtc_state)
+   __releases(&vkms_output->lock)
 {
struct vkms_output *vkms_output = drm_crtc_to_vkms_output(crtc);
 
-- 
2.24.1

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

Re: [PATCH v2 01/12] drm: ingenic-drm: add MODULE_DEVICE_TABLE

[H. Nikolaus Schaller]

> Am 14.02.2020 um 20:06 schrieb Paul Cercueil :
> 
> Hi Nikolaus,
> 
> Please rebase this patch on top of drm-misc-next and send it apart - it 
> should go through the DRM tree.
> 
> 
> Le ven., févr. 14, 2020 at 17:10, H. Nikolaus Schaller  a 
> écrit :
>> Add MODULE_DEVICE_TABLE so that the driver can load by
>> matching the device tree if compiled as module.
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
>> drivers/gpu/drm/ingenic/ingenic-drm.c | 2 ++
>> 1 file changed, 2 insertions(+)
>> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
>> b/drivers/gpu/drm/ingenic/ingenic-drm.c
>> index 6d47ef7b148c..d8617096dd8e 100644
>> --- a/drivers/gpu/drm/ingenic/ingenic-drm.c
>> +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
>> @@ -844,6 +844,8 @@ static const struct of_device_id ingenic_drm_of_match[] 
>> = {
>>  { /* sentinel */ },
>> };
>> +MODULE_DEVICE_TABLE(of, ingenic_drm_of_match);
> 
> Also please remove the blank line above MODULE_DEVICE_TABLE.
> 
> Cheers,
> -Paul

Ok.

BR and thanks,
Nikolaus

> 
>> +
>> static struct platform_driver ingenic_drm_driver = {
>>  .driver = {
>>  .name = "ingenic-drm",
>> --
>> 2.23.0
> 
> 

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

[PATCH 1/3] gpu/drm: ingenic: Add trick to support 16bpp on 24-bit panels

[Paul Cercueil]

If the panel interface is 24-bit but our primary plane is 16bpp,
configure as if the panel was 18-bit. This tricks permits the display
of 16bpp data on a 24-bit panel by wiring each color component to the
MSBs of the 24-bit interface.

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 6d47ef7b148c..034961a40e98 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -400,6 +400,8 @@ static void ingenic_drm_encoder_atomic_mode_set(struct 
drm_encoder *encoder,
struct drm_display_mode *mode = &crtc_state->adjusted_mode;
struct drm_connector *conn = conn_state->connector;
struct drm_display_info *info = &conn->display_info;
+   struct drm_plane_state *plane_state = crtc_state->crtc->primary->state;
+   const struct drm_format_info *finfo = NULL;
unsigned int cfg;
 
priv->panel_is_sharp = info->bus_flags & DRM_BUS_FLAG_SHARP_SIGNALS;
@@ -435,7 +437,22 @@ static void ingenic_drm_encoder_atomic_mode_set(struct 
drm_encoder *encoder,
cfg |= JZ_LCD_CFG_MODE_GENERIC_18BIT;
break;
case MEDIA_BUS_FMT_RGB888_1X24:
-   cfg |= JZ_LCD_CFG_MODE_GENERIC_24BIT;
+   if (plane_state && plane_state->fb)
+   finfo = plane_state->fb->format;
+
+   /*
+* If the panel interface is 24-bit but our
+* primary plane is 16bpp, configure as if the
+* panel was 18-bit. This tricks permits the
+* display of 16bpp data on a 24-bit panel by
+* wiring each color component to the MSBs of
+* the 24-bit interface.
+*/
+   if (finfo &&
+   finfo->format != DRM_FORMAT_XRGB)
+   cfg |= JZ_LCD_CFG_MODE_GENERIC_18BIT;
+   else
+   cfg |= JZ_LCD_CFG_MODE_GENERIC_24BIT;
break;
case MEDIA_BUS_FMT_RGB888_3X8:
cfg |= JZ_LCD_CFG_MODE_8BIT_SERIAL;
-- 
2.25.0

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

Re: [PATCH v2 03/12] MIPS: CI20: defconfig: configure for supporting modules

[Paul Cercueil]

Le ven., févr. 14, 2020 at 20:30, H. Nikolaus Schaller 
 a écrit :

Hi Paul,


 Am 14.02.2020 um 20:10 schrieb Paul Cercueil :

 Hi Nikolaus,

 Patches 03-12 only touch the same two files - ci20.dts and 
ci20_defconfig.


 Unless someone strongly disagrees, I'd suggest to squash all 
patches that touch each file together (except the ones with a Fixes 
tag), I don't think we really need that much granularity here.


It comes more from having developed these things quite independently 
and only collected for submission...


One patch I don't know how to handle: "MIPS: DTS: CI20: add DT node 
for IR sensor".
It is from 2015 and has a different author (some Alex Smith but the 
mail address seems to be broken).

This information and attribution will be lost if we squash them.


Ah, alright. Then I guess keep this one separate.

-Paul



But I can do for V3 and will also fix the fixes tags by adding cc: 
stable :)


BR and thanks,
Nikolaus




 -Paul


 Le ven., févr. 14, 2020 at 17:10, H. Nikolaus Schaller 
 a écrit :

 Not all drivers need to be compiled into the kernel.
 Support building and loading of kernel modules.
 Signed-off-by: H. Nikolaus Schaller 
 ---
 arch/mips/configs/ci20_defconfig | 1 +
 1 file changed, 1 insertion(+)
 diff --git a/arch/mips/configs/ci20_defconfig 
b/arch/mips/configs/ci20_defconfig

 index be41df2a81fb..e0d3c9d4c2ae 100644
 --- a/arch/mips/configs/ci20_defconfig
 +++ b/arch/mips/configs/ci20_defconfig
 @@ -1,4 +1,5 @@
 # CONFIG_LOCALVERSION_AUTO is not set
 +CONFIG_MODULES=y
 CONFIG_KERNEL_XZ=y
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
 --
 2.23.0








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

Re: [PATCH v2 01/12] drm: ingenic-drm: add MODULE_DEVICE_TABLE

[Paul Cercueil]

Hi Nikolaus,

Please rebase this patch on top of drm-misc-next and send it apart - it 
should go through the DRM tree.



Le ven., févr. 14, 2020 at 17:10, H. Nikolaus Schaller 
 a écrit :

Add MODULE_DEVICE_TABLE so that the driver can load by
matching the device tree if compiled as module.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c

index 6d47ef7b148c..d8617096dd8e 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -844,6 +844,8 @@ static const struct of_device_id 
ingenic_drm_of_match[] = {

{ /* sentinel */ },
 };

+MODULE_DEVICE_TABLE(of, ingenic_drm_of_match);


Also please remove the blank line above MODULE_DEVICE_TABLE.

Cheers,
-Paul


+
 static struct platform_driver ingenic_drm_driver = {
.driver = {
.name = "ingenic-drm",
--
2.23.0




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

[PATCH RESEND] drm/mcde: Fix Sphinx formatting

[Jonathan Neuschäfer]

- Format the pipe diagram as a monospace block.
- Fix formatting of the list. Without the empty line, the first dash is
  not parsed as a bullet point.

Signed-off-by: Jonathan Neuschäfer 
---
Previous copy: 
https://lore.kernel.org/lkml/20191002153827.23026-2-j.neuschae...@gmx.net/

It seems that this patch got lost, somehow.
---
 drivers/gpu/drm/mcde/mcde_drv.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
index 9a09eba53182..c535abed4765 100644
--- a/drivers/gpu/drm/mcde/mcde_drv.c
+++ b/drivers/gpu/drm/mcde/mcde_drv.c
@@ -20,11 +20,11 @@
  * input formats including most variants of RGB and YUV.
  *
  * The hardware has four display pipes, and the layout is a little
- * bit like this:
+ * bit like this::
  *
- * Memory -> Overlay -> Channel -> FIFO -> 5 formatters -> DSI/DPI
- * External  0..5   0..3   A,B,3 x DSI bridge
- * source 0..9 C0,C1   2 x DPI
+ *   Memory -> Overlay -> Channel -> FIFO -> 5 formatters -> DSI/DPI
+ *   External  0..5   0..3   A,B,3 x DSI bridge
+ *   source 0..9 C0,C1   2 x DPI
  *
  * FIFOs A and B are for LCD and HDMI while FIFO CO/C1 are for
  * panels with embedded buffer.
@@ -43,6 +43,7 @@
  * to change as we exploit more of the hardware capabilities.
  *
  * TODO:
+ *
  * - Enabled damaged rectangles using drm_plane_enable_fb_damage_clips()
  *   so we can selectively just transmit the damaged area to a
  *   command-only display.
--
2.20.1

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

[PATCH v2 11/12] MIPS: CI20: defconfig: configure for CONFIG_KEYBOARD_GPIO=m

[H. Nikolaus Schaller]

The SW1 button is hooked up to send input events.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/configs/ci20_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index 0458ea4d54e8..0db0088bbc1c 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -89,6 +89,7 @@ CONFIG_I2C_JZ4780=y
 CONFIG_SPI=y
 CONFIG_SPI_GPIO=y
 CONFIG_GPIO_SYSFS=y
+CONFIG_KEYBOARD_GPIO=m
 # CONFIG_HWMON is not set
 CONFIG_WATCHDOG=y
 CONFIG_JZ4740_WDT=y
-- 
2.23.0

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

[PATCH v2 00/12] MIPS: Fixes and improvements for CI20 board (JZ4780)

[H. Nikolaus Schaller]

V2:
* dropped "net: davicom: dm9000: allow to pass MAC address through mac_addr 
module parameter"
  from this series because it goes through the netdev tree
  (suggested by Andrew Lunn )
* added a "fixes:" for "MIPS: DTS: CI20: fix PMU definitions for ACT8600"
  and "MIPS: DTS: CI20: fix interrupt for pcf8563 RTC"
  (suggested by Andreas Kemnade )
* "i2c: jz4780: silence log flood on txabrt" dropped because it is
  replaced by a new version in v5.6 by Wolfram Sang 

PATCH V1 2020-02-11 22:41:43:
This patch set provides several improvements for the CI20 board:

* suppress warnings from i2c if device is not responding
* make ingenic-drm found through DT
* allow davicom dm9000 ethernet controller to use MAC address provided by U-Boot
* fix #include in jz4780.dtsi
* configure for loadable kernel modules
* add DTS for IR sensor and SW1 button
* configure so that LEDs, IR sensor, SW1 button have drivers
* fix DTS for ACT8600 PMU and configure driver
* fix interrupt of nxp,pcf8563

There is another patch set in our queue to add HDMI support on top of this work.

Signed-off-by: Paul Boddie 
Signed-off-by: H. Nikolaus Schaller 


Alex Smith (1):
  MIPS: DTS: CI20: add DT node for IR sensor

H. Nikolaus Schaller (11):
  drm: ingenic-drm: add MODULE_DEVICE_TABLE
  MIPS: DTS: jz4780: add #includes for irq.h and gpio.h
  MIPS: CI20: defconfig: configure for supporting modules
  MIPS: CI20: defconfig: compile leds-gpio driver into the kernel and
configure for LED triggers
  MIPS: DTS: CI20: fix PMU definitions for ACT8600
  MIPS: CI20: defconfig: configure CONFIG_REGULATOR_ACT8865 for PMU
  MIPS: DTS: CI20: give eth0_power a defined voltage.
  MIPS: CI20: defconfig: compile gpio-ir driver
  MIPS: DTS: CI20: add DT node for SW1 as Enter button
  MIPS: CI20: defconfig: configure for CONFIG_KEYBOARD_GPIO=m
  MIPS: DTS: CI20: fix interrupt for pcf8563 RTC

 arch/mips/boot/dts/ingenic/ci20.dts| 71 --
 arch/mips/boot/dts/ingenic/jz4780.dtsi |  2 +
 arch/mips/configs/ci20_defconfig   | 21 
 drivers/gpu/drm/ingenic/ingenic-drm.c  |  2 +
 4 files changed, 80 insertions(+), 16 deletions(-)

-- 
2.23.0

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

[PATCH v2 07/12] MIPS: DTS: CI20: give eth0_power a defined voltage.

[H. Nikolaus Schaller]

This is a 3.3V power switch (DVNET3.3V ).

Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/boot/dts/ingenic/ci20.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
b/arch/mips/boot/dts/ingenic/ci20.dts
index e02a19db7ef1..e1364f941c7d 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -56,6 +56,8 @@
eth0_power: fixedregulator@0 {
compatible = "regulator-fixed";
regulator-name = "eth0_power";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
gpio = <&gpb 25 GPIO_ACTIVE_LOW>;
enable-active-high;
};
-- 
2.23.0

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

[PATCH] drm/sun4i: tcon: Support LVDS on the A33

[Maxime Ripard]

The A33 TCON supports LVDS, so we can toggle the support switch.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index fdf143042f83..14026b4fa7c7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1475,6 +1475,7 @@ static const struct sun4i_tcon_quirks sun8i_a33_quirks = {
.has_channel_0  = true,
.has_lvds_alt   = true,
.dclk_min_div   = 1,
+   .supports_lvds  = true,
 };
 
 static const struct sun4i_tcon_quirks sun8i_a83t_lcd_quirks = {
-- 
2.24.1

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

[PATCH v2 04/12] MIPS: CI20: defconfig: compile leds-gpio driver into the kernel and configure for LED triggers

[H. Nikolaus Schaller]

DTS has been augmented to add some gpio-leds. We need the leds-gpio driver
and enable the triggers.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/configs/ci20_defconfig | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index e0d3c9d4c2ae..30a47a7a2994 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -167,3 +167,16 @@ CONFIG_STACKTRACE=y
 # CONFIG_FTRACE is not set
 CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="earlycon console=ttyS4,115200 clk_ignore_unused"
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_MTD=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_ONESHOT=y
+CONFIG_LEDS_TRIGGER_ONESHOT=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_BACKLIGHT=m
+CONFIG_LEDS_TRIGGER_CPU=y
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_LEDS_TRIGGER_TRANSIENT=y
+CONFIG_LEDS_TRIGGER_CAMERA=m
-- 
2.23.0

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

Re: [PATCH v2 03/12] MIPS: CI20: defconfig: configure for supporting modules

[H. Nikolaus Schaller]

Hi Paul,

> Am 14.02.2020 um 20:10 schrieb Paul Cercueil :
> 
> Hi Nikolaus,
> 
> Patches 03-12 only touch the same two files - ci20.dts and ci20_defconfig.
> 
> Unless someone strongly disagrees, I'd suggest to squash all patches that 
> touch each file together (except the ones with a Fixes tag), I don't think we 
> really need that much granularity here.

It comes more from having developed these things quite independently and only 
collected for submission...

One patch I don't know how to handle: "MIPS: DTS: CI20: add DT node for IR 
sensor".
It is from 2015 and has a different author (some Alex Smith but the mail 
address seems to be broken).
This information and attribution will be lost if we squash them.

But I can do for V3 and will also fix the fixes tags by adding cc: stable :)

BR and thanks,
Nikolaus


> 
> -Paul
> 
> 
> Le ven., févr. 14, 2020 at 17:10, H. Nikolaus Schaller  a 
> écrit :
>> Not all drivers need to be compiled into the kernel.
>> Support building and loading of kernel modules.
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
>> arch/mips/configs/ci20_defconfig | 1 +
>> 1 file changed, 1 insertion(+)
>> diff --git a/arch/mips/configs/ci20_defconfig 
>> b/arch/mips/configs/ci20_defconfig
>> index be41df2a81fb..e0d3c9d4c2ae 100644
>> --- a/arch/mips/configs/ci20_defconfig
>> +++ b/arch/mips/configs/ci20_defconfig
>> @@ -1,4 +1,5 @@
>> # CONFIG_LOCALVERSION_AUTO is not set
>> +CONFIG_MODULES=y
>> CONFIG_KERNEL_XZ=y
>> CONFIG_SYSVIPC=y
>> CONFIG_POSIX_MQUEUE=y
>> --
>> 2.23.0
> 
> 

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

Re: [PATCH resend 0/2] dts: keystone-k2g-evm: Display support

[santosh . shilimkar]

On 2/14/20 1:22 AM, Jyri Sarha wrote:

Resend because the earlier recipient list was wrong.

Now that drm/tidss is queued for mainline, lets add display support for
k2g-evm. There is no hurry since tidss is out only in v5.7, but it
should not harm to have the dts changes in place before that.

Jyri Sarha (2):
   ARM: dts: keystone-k2g: Add DSS node
   ARM: dts: keystone-k2g-evm: add HDMI video support

  arch/arm/boot/dts/keystone-k2g-evm.dts | 101 +
  arch/arm/boot/dts/keystone-k2g.dtsi|  22 ++
  2 files changed, 123 insertions(+)


Ok. Will add this to the next queue.

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

Re: [PATCH 1/2] dt-bindings: display: sun4i-tcon: Add LVDS Dual Link property

[Maxime Ripard]

Hi Laurent,

On Fri, Feb 14, 2020 at 03:10:25PM +0200, Laurent Pinchart wrote:
> Hi Maxime,
>
> Thank you for the patch.
>
> On Fri, Feb 14, 2020 at 01:32:43PM +0100, Maxime Ripard wrote:
> > SoCs that have multiple TCONs can use the two set of pins on the first TCON
> > to drive a dual-link display. Add a property to enable the dual link.
> >
> > Signed-off-by: Maxime Ripard 
> > ---
> >  .../bindings/display/allwinner,sun4i-a10-tcon.yaml | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml 
> > b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
> > index 86ad617d2327..aa6dd8409dbc 100644
> > --- 
> > a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
> > +++ 
> > b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
> > @@ -105,6 +105,13 @@ properties:
> >  - const: edp
> >  - const: lvds
> >
> > +  allwinner,lvds-dual-link:
> > +type: boolean
> > +description: |
> > +  On a SoC with two TCON with LVDS support, the first TCON can
> > +  operate over both pins sets to output in a dual-link setup. This
> > +  will be triggered by setting this property.
>
> Could you maybe provide an example of how this property is supposed to
> be used ? I'm especially wondering what ports are used in that case and
> how they're connected.

It's pretty trivial to support, it's only a property to set on the
encoder node itself.

I'm not really sure what you meant by your question with the ports
though :/

Maxime


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

[PATCH v4] drm/i915: Init lspcon after HPD in intel_dp_detect()

[Kai-Heng Feng]

On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
becomes useless and never responds to cable hotplugging:
[3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D

Seems like the lspcon chip on the system in question only gets powered
after the cable is plugged.

So let's call lspcon_init() dynamically to properly initialize the
lspcon chip and make HDMI port work.

Signed-off-by: Kai-Heng Feng 
---
v4:
 - Trust VBT in intel_infoframe_init().
 - Init lspcon in intel_dp_detect().

v3:
 - Make sure it's handled under long HPD case.

v2: 
 - Move lspcon_init() inside of intel_dp_hpd_pulse().

 drivers/gpu/drm/i915/display/intel_ddi.c  | 17 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 13 -
 drivers/gpu/drm/i915/display/intel_hdmi.c |  2 +-
 3 files changed, 14 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 33f1dc3d7c1a..ca717434b406 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4741,7 +4741,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
&dev_priv->vbt.ddi_port_info[port];
struct intel_digital_port *intel_dig_port;
struct intel_encoder *encoder;
-   bool init_hdmi, init_dp, init_lspcon = false;
+   bool init_hdmi, init_dp;
enum phy phy = intel_port_to_phy(dev_priv, port);
 
init_hdmi = port_info->supports_dvi || port_info->supports_hdmi;
@@ -4754,7 +4754,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
 * is initialized before lspcon.
 */
init_dp = true;
-   init_lspcon = true;
init_hdmi = false;
DRM_DEBUG_KMS("VBT says port %c has lspcon\n", port_name(port));
}
@@ -4833,20 +4832,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
goto err;
}
 
-   if (init_lspcon) {
-   if (lspcon_init(intel_dig_port))
-   /* TODO: handle hdmi info frame part */
-   DRM_DEBUG_KMS("LSPCON init success on port %c\n",
-   port_name(port));
-   else
-   /*
-* LSPCON init faied, but DP init was success, so
-* lets try to drive as DP++ port.
-*/
-   DRM_ERROR("LSPCON init failed on port %c\n",
-   port_name(port));
-   }
-
intel_infoframe_init(intel_dig_port);
 
return;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index c7424e2a04a3..43117aa86292 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5663,8 +5663,19 @@ intel_dp_detect(struct drm_connector *connector,
/* Can't disconnect eDP */
if (intel_dp_is_edp(intel_dp))
status = edp_detect(intel_dp);
-   else if (intel_digital_port_connected(encoder))
+   else if (intel_digital_port_connected(encoder)) {
+   if (intel_bios_is_lspcon_present(dev_priv, dig_port->base.port) 
&&
+   !dig_port->lspcon.active) {
+   if (lspcon_init(dig_port))
+   DRM_DEBUG_KMS("LSPCON init success on port 
%c\n",
+ port_name(dig_port->base.port));
+   else
+   DRM_DEBUG_KMS("LSPCON init failed on port %c\n",
+ port_name(dig_port->base.port));
+   }
+
status = intel_dp_detect_dpcd(intel_dp);
+   }
else
status = connector_status_disconnected;
 
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 93ac0f296852..27a5aa8cefc9 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3100,7 +3100,7 @@ void intel_infoframe_init(struct intel_digital_port 
*intel_dig_port)
intel_dig_port->set_infoframes = g4x_set_infoframes;
intel_dig_port->infoframes_enabled = g4x_infoframes_enabled;
} else if (HAS_DDI(dev_priv)) {
-   if (intel_dig_port->lspcon.active) {
+   if (intel_bios_is_lspcon_present(dev_priv, 
intel_dig_port->base.port)) {
intel_dig_port->write_infoframe = 
lspcon_write_infoframe;
intel_dig_port->read_infoframe = lspcon_read_infoframe;
intel_dig_port->set_infoframes = lspcon_set_infoframes;
-- 
2.17.1

___
dri-devel ma

Re: [PATCH 4/4] drm/sun4i: dsi: Remove incorrect use of runtime PM

[Maxime Ripard]

On Tue, Feb 11, 2020 at 01:28:58AM -0600, Samuel Holland wrote:
> The driver currently uses runtime PM to perform some of the module
> initialization and cleanup. This has three problems:
>
> 1) There is no Kconfig dependency on CONFIG_PM, so if runtime PM is
>disabled, the driver will not work at all, since the module will
>never be initialized.
>
> 2) The driver does not ensure that the device is suspended when
>sun6i_dsi_probe() fails or when sun6i_dsi_remove() is called. It
>simply disables runtime PM. From the docs of pm_runtime_disable():
>
>   The device can be either active or suspended after its runtime PM
>   has been disabled.
>
>And indeed, the device will likely still be active if sun6i_dsi_probe
>fails. For example, if the panel driver is not yet loaded, we have
>the following sequence:
>
>sun6i_dsi_probe()
>   pm_runtime_enable()
>   mipi_dsi_host_register()
>  of_mipi_dsi_device_add(child)
> ...device_add()...
>__device_attach()
>  pm_runtime_get_sync(dev->parent) -> Causes resume
>  bus_for_each_drv()
> __device_attach_driver() -> No match for panel
>  pm_runtime_put(dev->parent) -> Async idle request
>   component_add()
>  __component_add()
> try_to_bring_up_masters()
>try_to_bring_up_master()
>   sun4i_drv_bind()
>  component_bind_all()
> component_bind()
>sun6i_dsi_bind() -> Fails with -EPROBE_DEFER
>   mipi_dsi_host_unregister()
>   pm_runtime_disable()
>  __pm_runtime_disable()
> __pm_runtime_barrier() -> Idle request is still pending
>cancel_work_sync()  -> DSI host is *not* suspended!
>
>Since the device is not suspended, the clock and regulator are never
>disabled. The imbalance causes a WARN at devres free time.
>
> 3) The driver relies on being suspended when sun6i_dsi_encoder_enable()
>is called. The resume callback has a comment that says:
>
>   Some part of it can only be done once we get a number of
>   lanes, see sun6i_dsi_inst_init
>
>And then part of the resume callback only runs if dsi->device is not
>NULL (that is, if sun6i_dsi_attach() has been called). However, as
>the above call graph shows, the resume callback is guaranteed to be
>called before sun6i_dsi_attach(); it is called before child devices
>get their drivers attached.
>
>Therefore, part of the controller initialization will only run if the
>device is suspended between the calls to mipi_dsi_host_register() and
>component_add() (which ends up calling sun6i_dsi_encoder_enable()).
>Again, as shown by the above call graph, this is not the case. It
>appears that the controller happens to work because it is still
>initialized by the bootloader.
>
>Because the connector is hardcoded to always be connected, the
>device's runtime PM reference is not dropped until system suspend,
>when sun4i_drv_drm_sys_suspend() ends up calling
>sun6i_dsi_encoder_disable(). However, that is done as a system sleep
>PM hook, and at that point the system PM core has already taken
>another runtime PM reference, so sun6i_dsi_runtime_suspend() is
>not called. Likewise, by the time the PM core releases its reference,
>sun4i_drv_drm_sys_resume() has already re-enabled the encoder.
>
>So after system suspend and resume, we have *still never called*
>sun6i_dsi_inst_init(), and now that the rest of the display pipeline
>has been reset, the DSI host is unable to communicate with the panel,
>causing VBLANK timeouts.
>
> Fix all of these issues by inlining the runtime PM hooks into the
> encoder enable/disable functions, which are guaranteed to run after a
> panel is attached. This allows sun6i_dsi_inst_init() to be called
> unconditionally. Furthermore, this causes the hardware to be turned off
> during system suspend and reinitialized on resume, which was not
> happening before.
>
> Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller 
> support")
> Signed-off-by: Samuel Holland 

Applied all 4 patches.

This one failed to apply for some reason (even though the context
looks similar) so I fixed the conflict by hand, you might want to
double check.

Thanks!
Maxime


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

[PATCH v2 0/2] Dual licence some files in GPL-2.0 and MIT

[Emmanuel Vadot]

Hello all,

We had a discussion a while back with Noralf where he said that he wouldn't
mind dual licence his work under GPL-2 and MIT.
Those files are a problem with BSDs as we cannot include them.
For drm_client.c the main contributors are Noralf Trønnes and Thomas
Zimmermann, the other commits are just catch ups from changes elsewhere
(return values, struct member names, function renames etc ...).
For drm_format_helper the main contributors are Noralf Trønnes and
Gerd Hoffmann. Same comment as for drm_client.c for the other commits.

Emmanuel Vadot (2):
  drm/client: Dual licence the file in GPL-2 and MIT
  drm/format_helper: Dual licence the file in GPL 2 and MIT

 drivers/gpu/drm/drm_client.c| 2 +-
 drivers/gpu/drm/drm_format_helper.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.25.0

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

Re: [PATCH 4/4] drm/sun4i: dsi: Remove incorrect use of runtime PM

[Samuel Holland]

Maxime,

First, sorry for the tone in my previous message. I wrote it too hastily.

> On 2/11/20 2:26 AM, Maxime Ripard wrote:
>> On Tue, Feb 11, 2020 at 01:28:58AM -0600, Samuel Holland wrote:
>>> 3) The driver relies on being suspended when sun6i_dsi_encoder_enable()
>>>is called. The resume callback has a comment that says:
>>>
>>>   Some part of it can only be done once we get a number of
>>>   lanes, see sun6i_dsi_inst_init
>>>
>>>And then part of the resume callback only runs if dsi->device is not
>>>NULL (that is, if sun6i_dsi_attach() has been called). However, as
>>>the above call graph shows, the resume callback is guaranteed to be
>>>called before sun6i_dsi_attach(); it is called before child devices
>>>get their drivers attached.
>>
>> Isn't it something that has been changed by your previous patch though?
> 
> No. Before the previous patch, sun6i_dsi_bind() requires sun6i_dsi_attach() to
> have been called first. So either the panel driver is not loaded, and issue #2
> happens, or the panel driver is loaded, and you get the following modification
> to the above call graph:
> 
>mipi_dsi_host_register()
>   ...
>  __device_attach()
> pm_runtime_get_sync(dev->parent) -> Causes resume
> bus_for_each_drv()
>__device_attach_driver()
>   [panel probe function]
>  mipi_dsi_attach()
> sun6i_dsi_attach()
> pm_runtime_put(dev->parent) -> Async idle request
>component_add()
>   ...
>  sun6i_dsi_bind()
>   ...
>  sun6i_dsi_encoder_enable()
> pm_runtime_get_sync() -> Cancels idle request
> 
> And because `dev->power.runtime_status == RPM_ACTIVE` still, the callback is
> *not* run. Either way you have the same problem.

While the scenario I described is possible (since an unbounded amount of other
work could be queued to pm_wq), I did more testing without these patches, and I
could never trigger it. No matter what combination of module/built-in drivers I
used, there was always enough time between mipi_dsi_host_register() and
sun6i_dsi_encoder_enable() for the device to be suspended. So in practice
sun6i_dsi_inst_init() was always called during boot.

>>>Therefore, part of the controller initialization will only run if the
>>>device is suspended between the calls to mipi_dsi_host_register() and
>>>component_add() (which ends up calling sun6i_dsi_encoder_enable()).
>>>Again, as shown by the above call graph, this is not the case. It
>>>appears that the controller happens to work because it is still
>>>initialized by the bootloader.
>>
>> We don't have any bootloader support for MIPI-DSI, so no, that's not it.

You are correct here. sun6i_dsi_inst_init() was indeed being called at boot. So
my commit log is wrong.

>>>Because the connector is hardcoded to always be connected, the
>>>device's runtime PM reference is not dropped until system suspend,
>>>when sun4i_drv_drm_sys_suspend() ends up calling
>>>sun6i_dsi_encoder_disable(). However, that is done as a system sleep
>>>PM hook, and at that point the system PM core has already taken
>>>another runtime PM reference, so sun6i_dsi_runtime_suspend() is
>>>not called. Likewise, by the time the PM core releases its reference,
>>>sun4i_drv_drm_sys_resume() has already re-enabled the encoder.
>>>
>>>So after system suspend and resume, we have *still never called*
>>>sun6i_dsi_inst_init(), and now that the rest of the display pipeline
>>>has been reset, the DSI host is unable to communicate with the panel,
>>>causing VBLANK timeouts.
>>
>> Either way, I guess just moving the pm_runtime_enable call to
>> sun6i_dsi_attach will fix this, right? We don't really need to have
>> the DSI controller powered up before that time anyway.
> 
> No. It would solve issue #2 (only if the previous patch is
> applied), but not issue #3.
> 
> Regardless of when runtime PM is enabled, sun6i_dsi_runtime_suspend() will not
> be called until the device's usage count drops to 0. And as long as a panel is
> bound, the controller's usage count will be >0, *even during system suspend*
> while the encoder is turned off.
> 
> Before the previous patch, the usage count would never drop to 0 under *any*
> circumstance.

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

Re: [PATCH v2 03/12] MIPS: CI20: defconfig: configure for supporting modules

[Paul Cercueil]

Hi Nikolaus,

Patches 03-12 only touch the same two files - ci20.dts and 
ci20_defconfig.


Unless someone strongly disagrees, I'd suggest to squash all patches 
that touch each file together (except the ones with a Fixes tag), I 
don't think we really need that much granularity here.


-Paul


Le ven., févr. 14, 2020 at 17:10, H. Nikolaus Schaller 
 a écrit :

Not all drivers need to be compiled into the kernel.
Support building and loading of kernel modules.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/configs/ci20_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/configs/ci20_defconfig 
b/arch/mips/configs/ci20_defconfig

index be41df2a81fb..e0d3c9d4c2ae 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -1,4 +1,5 @@
 # CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_MODULES=y
 CONFIG_KERNEL_XZ=y
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
--
2.23.0




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

[PATCH v2 06/12] MIPS: CI20: defconfig: configure CONFIG_REGULATOR_ACT8865 for PMU

[H. Nikolaus Schaller]

The PMU on the CI20 board is an ACT8600 using the ACT8865 driver.
Since it is not compiled, the PMU and the CI20 board is running in
power-on reset state of the PMU.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/configs/ci20_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index 30a47a7a2994..74e5775b8a05 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -95,6 +95,7 @@ CONFIG_JZ4740_WDT=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_DEBUG=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_ACT8865=y
 # CONFIG_VGA_CONSOLE is not set
 # CONFIG_HID is not set
 # CONFIG_USB_SUPPORT is not set
-- 
2.23.0

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

Re: [PATCH v2 0/2] Dual licence some files in GPL-2.0 and MIT

[Maxime Ripard]

On Sat, Feb 15, 2020 at 07:09:09PM +0100, Emmanuel Vadot wrote:
> Hello all,
>
> We had a discussion a while back with Noralf where he said that he wouldn't
> mind dual licence his work under GPL-2 and MIT.
> Those files are a problem with BSDs as we cannot include them.
> For drm_client.c the main contributors are Noralf Trønnes and Thomas
> Zimmermann, the other commits are just catch ups from changes elsewhere
> (return values, struct member names, function renames etc ...).
> For drm_format_helper the main contributors are Noralf Trønnes and
> Gerd Hoffmann. Same comment as for drm_client.c for the other commits.
>
> Emmanuel Vadot (2):
>   drm/client: Dual licence the file in GPL-2 and MIT
>   drm/format_helper: Dual licence the file in GPL 2 and MIT

Acked-by: Maxime Ripard 

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

[PATCH v2 02/12] MIPS: DTS: jz4780: add #includes for irq.h and gpio.h

[H. Nikolaus Schaller]

The constants from irq.h and gpio.h can be used in the
jz4780.dtsi and derived DTS like ci20.dts.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/boot/dts/ingenic/jz4780.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi 
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index f928329b034b..112a24deff71 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -1,6 +1,8 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
 #include 
+#include 
+#include 
 
 / {
#address-cells = <1>;
-- 
2.23.0

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

Re: [PATCH] drm/i915: Cast remain to unsigned long in eb_relocate_vma

[Nathan Chancellor]

On Fri, Feb 14, 2020 at 08:32:19AM +, Chris Wilson wrote:
> Quoting Jani Nikula (2020-02-14 06:36:15)
> > On Thu, 13 Feb 2020, Nathan Chancellor  wrote:
> > > A recent commit in clang added -Wtautological-compare to -Wall, which is
> > > enabled for i915 after -Wtautological-compare is disabled for the rest
> > > of the kernel so we see the following warning on x86_64:
> > >
> > >  ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1433:22: warning:
> > >  result of comparison of constant 576460752303423487 with expression of
> > >  type 'unsigned int' is always false
> > >  [-Wtautological-constant-out-of-range-compare]
> > >  if (unlikely(remain > N_RELOC(ULONG_MAX)))
> > > ^
> > >  ../include/linux/compiler.h:78:42: note: expanded from macro 'unlikely'
> > >  # define unlikely(x)__builtin_expect(!!(x), 0)
> > > ^
> > >  1 warning generated.
> > >
> > > It is not wrong in the case where ULONG_MAX > UINT_MAX but it does not
> > > account for the case where this file is built for 32-bit x86, where
> > > ULONG_MAX == UINT_MAX and this check is still relevant.
> > >
> > > Cast remain to unsigned long, which keeps the generated code the same
> > > (verified with clang-11 on x86_64 and GCC 9.2.0 on x86 and x86_64) and
> > > the warning is silenced so we can catch more potential issues in the
> > > future.
> > >
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/778
> > > Suggested-by: Michel Dänzer 
> > > Signed-off-by: Nathan Chancellor 
> > 
> > Works for me as a workaround,
> 
> But the whole point was that the compiler could see that it was
> impossible and not emit the code. Doesn't this break that?
> -Chris

As noted in the commit message, I ran diff <(objdump -Dr) <(objdump -Dr)
on objects files compiled with and without the patch with clang and gcc
for x86_64 and gcc for i386 (i386 does not build with clang) and there
was zero difference aside from the file names.

At the end of the day, I do not really care how the warning get fixed,
just that it does since it is the only one on x86_64 defconfig.

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

[PATCH 3/3] gpu/drm: ingenic: Add option to mmap GEM buffers cached

[Paul Cercueil]

Ingenic SoCs are most notably used in cheap chinese handheld gaming
consoles. There, the games and applications generally render in software
directly in the emulated framebuffer using SDL1.

Since the emulated framebuffer is mapped as write-combine by default,
these applications start to run really slow as soon as alpha-blending is
used.

Add a 'cached_gem_buffers' option to the ingenic-drm driver to mmap the
GEM buffers as fully cached to address this issue.

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 41 +--
 1 file changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 9aa88fabbd2a..31f0346b55f0 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -30,6 +31,11 @@
 #include 
 #include 
 
+static bool ingenic_drm_cached_gem_buf;
+module_param_named(cached_gem_buffers, ingenic_drm_cached_gem_buf, bool, 0400);
+MODULE_PARM_DESC(cached_gem_buffers,
+"Enable fully cached GEM buffers [default=false]");
+
 #define JZ_REG_LCD_CFG 0x00
 #define JZ_REG_LCD_VSYNC   0x04
 #define JZ_REG_LCD_HSYNC   0x08
@@ -378,16 +384,25 @@ static void ingenic_drm_plane_atomic_update(struct 
drm_plane *plane,
struct ingenic_drm *priv = drm_plane_get_priv(plane);
struct drm_plane_state *state = plane->state;
unsigned int width, height, cpp;
+   unsigned long virt_addr;
dma_addr_t addr;
+   uint32_t len;
 
if (state && state->fb) {
addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
+
width = state->src_w >> 16;
height = state->src_h >> 16;
cpp = state->fb->format->cpp[plane->index];
+   len = width * height * cpp;
+
+   if (ingenic_drm_cached_gem_buf) {
+   virt_addr = (unsigned long)phys_to_virt(addr);
+   dma_cache_wback_inv(virt_addr, len);
+   }
 
priv->dma_hwdesc->addr = addr;
-   priv->dma_hwdesc->cmd = width * height * cpp / 4;
+   priv->dma_hwdesc->cmd = len / 4;
priv->dma_hwdesc->cmd |= JZ_LCD_CMD_EOF_IRQ;
}
 }
@@ -533,6 +548,28 @@ static void ingenic_drm_disable_vblank(struct drm_crtc 
*crtc)
 
 DEFINE_DRM_GEM_CMA_FOPS(ingenic_drm_fops);
 
+static int ingenic_drm_gem_mmap(struct drm_gem_object *obj,
+   struct vm_area_struct *vma)
+{
+   unsigned long start, off;
+
+   if (!ingenic_drm_cached_gem_buf)
+   return drm_gem_cma_prime_mmap(obj, vma);
+
+   off = vma->vm_pgoff << PAGE_SHIFT;
+   start = to_drm_gem_cma_obj(obj)->paddr;
+
+   off += start;
+
+   vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+   pgprot_val(vma->vm_page_prot) &= ~_CACHE_MASK;
+   pgprot_val(vma->vm_page_prot) |= _CACHE_CACHABLE_NONCOHERENT;
+
+   return io_remap_pfn_range(vma, vma->vm_start, off >> PAGE_SHIFT,
+ vma->vm_end - vma->vm_start,
+ vma->vm_page_prot);
+}
+
 static struct drm_driver ingenic_drm_driver_data = {
.driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
.name   = "ingenic-drm",
@@ -554,7 +591,7 @@ static struct drm_driver ingenic_drm_driver_data = {
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
.gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
+   .gem_prime_mmap = ingenic_drm_gem_mmap,
 
.irq_handler= ingenic_drm_irq_handler,
.release= ingenic_drm_release,
-- 
2.25.0

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

[PATCH v2 01/12] drm: ingenic-drm: add MODULE_DEVICE_TABLE

[H. Nikolaus Schaller]

Add MODULE_DEVICE_TABLE so that the driver can load by
matching the device tree if compiled as module.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 6d47ef7b148c..d8617096dd8e 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -844,6 +844,8 @@ static const struct of_device_id ingenic_drm_of_match[] = {
{ /* sentinel */ },
 };
 
+MODULE_DEVICE_TABLE(of, ingenic_drm_of_match);
+
 static struct platform_driver ingenic_drm_driver = {
.driver = {
.name = "ingenic-drm",
-- 
2.23.0

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

[PATCH 16/30] drm/vkms: Add missing annotation for vkms_crtc_atomic_begin()

[Jules Irenge]

Sparse reports a warning at vkms_crtc_atomic_begin()

warning: context imbalance in vkms_crtc_atomic_begin()
 - wrong count at exit

The root cause is the missing annotation at vkms_crtc_atomic_begin()
Add the missing __acquires(&vkms_output->lock) annotation

Signed-off-by: Jules Irenge 
---
 drivers/gpu/drm/vkms/vkms_crtc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 74f703b8d22a..7513be6444ae 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -219,6 +219,7 @@ static void vkms_crtc_atomic_disable(struct drm_crtc *crtc,
 
 static void vkms_crtc_atomic_begin(struct drm_crtc *crtc,
   struct drm_crtc_state *old_crtc_state)
+   __acquires(&vkms_output->lock)
 {
struct vkms_output *vkms_output = drm_crtc_to_vkms_output(crtc);
 
-- 
2.24.1

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

[PATCH v2 1/2] drm/client: Dual licence the file in GPL-2 and MIT

[Emmanuel Vadot]

From: Emmanuel Vadot 

Contributors for this file are :
Chris Wilson 
Denis Efremov 
Jani Nikula 
Maxime Ripard 
Noralf Trønnes 
Sam Ravnborg 
Thomas Zimmermann 

Signed-off-by: Emmanuel Vadot 
---
 drivers/gpu/drm/drm_client.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index b031b45aa8ef..6b0c6ef8b9b3 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0
+// SPDX-License-Identifier: GPL-2.0 or MIT
 /*
  * Copyright 2018 Noralf Trønnes
  */
-- 
2.25.0

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

Re: [PATCH v2 2/2] ARM: sun7i: dts: Add LVDS panel support on A20

[Andrey Lebedev]

On Fri, Feb 14, 2020 at 08:52:18AM +0100, Maxime Ripard wrote:
> > > This will create a spurious warning message for TCON1, since we
> > > adjusted the driver to tell it supports LVDS, but there's no LVDS
> > > reset line, so we need to make it finer grained.
> >
> > Yes, I can attribute two of the messages in my dmesg log [1] to this
> > ("Missing LVDS properties" and "LVDS output disabled". "sun4i-tcon
> > 1c0d000.lcd-controller" is indeed tcon1). And yes, I can see how they
> > can be confusing to someone.
> >
> > I'd need some pointers on how to deal with that though (if we want to do
> > it in this scope).
> 
> Like I was mentionning, you could introduce a new compatible for each
> TCON (tcon0 and tcon1) and only set the support_lvds flag for tcon0

Can you give me an idea how that compatible might look like?

tcon0: lcd-controller@1c0c000 {
compatible = "allwinner,sun7i-a20-tcon", 
"allwinner,lvds";

or

tcon0: lcd-controller@1c0c000 {
compatible = "allwinner,sun7i-a20-tcon", 
"allwinner,tcon0";

? Or something completely different?


-- 
Andrey Lebedev aka -.- . -.. -.. . .-.
Software engineer
Homepage: http://lebedev.lt/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dma-buf: Fix a typo in Kconfig

[Christophe JAILLET]

A 'h' ismissing in' syncronization'

Signed-off-by: Christophe JAILLET 
---
 drivers/dma-buf/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index 0613bb7770f5..e7d820ce0724 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -6,7 +6,7 @@ config SYNC_FILE
default n
select DMA_SHARED_BUFFER
---help---
- The Sync File Framework adds explicit syncronization via
+ The Sync File Framework adds explicit synchronization via
  userspace. It enables send/receive 'struct dma_fence' objects to/from
  userspace via Sync File fds for synchronization between drivers via
  userspace components. It has been ported from Android.
-- 
2.20.1

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

Re: [PATCH v4 02/11] drm/bridge: dw-hdmi: add max bpc connector property

[Jernej Škrabec]

Hi!

Dne četrtek, 06. februar 2020 ob 20:18:25 CET je Neil Armstrong napisal(a):
> From: Jonas Karlman 
> 
> Add the max_bpc property to the dw-hdmi connector to prepare support
> for 10, 12 & 16bit output support.
> 
> Signed-off-by: Jonas Karlman 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> 9e0927d22db6..051001f77dd4 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2406,6 +2406,10 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
> *bridge) DRM_MODE_CONNECTOR_HDMIA,
>   hdmi->ddc);
> 
> + drm_atomic_helper_connector_reset(connector);

Why is this reset needed?

Best regards,
Jernej

> +
> + drm_connector_attach_max_bpc_property(connector, 8, 16);
> +
>   if (hdmi->version >= 0x200a && hdmi->plat_data->use_drm_infoframe)
>   drm_object_attach_property(&connector->base,
>   connector->dev-
>mode_config.hdr_output_metadata_property, 0);




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

[PATCH v2 09/12] MIPS: CI20: defconfig: compile gpio-ir driver

[H. Nikolaus Schaller]

The CI20 board has a gpio based IR receiver.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/configs/ci20_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index 74e5775b8a05..0458ea4d54e8 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -181,3 +181,8 @@ CONFIG_LEDS_TRIGGER_CPU=y
 CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
 CONFIG_LEDS_TRIGGER_TRANSIENT=y
 CONFIG_LEDS_TRIGGER_CAMERA=m
+CONFIG_LIRC=y
+CONFIG_MEDIA_SUPPORT=m
+CONFIG_RC_DEVICES=y
+CONFIG_IR_GPIO_CIR=m
+CONFIG_IR_GPIO_TX=m
-- 
2.23.0

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

[PATCH 0/4] drm/sun4i: Support clock and data polarities on LVDS output

[Maxime Ripard]

Hi,

The Allwinner LVDS encoder allows to change the polarity of clocks and
data lanes, so let's add the needed bus flags to DRM, panel-lvds and
our encoder driver.

Let me know what you think,
Maxime

Maxime Ripard (4):
  drm/connector: Add data polarity flags
  dt-bindings: panel: lvds: Add properties for clock and data polarities
  drm/panel: lvds: Support data and clock polarity flags
  drm/sun4i: lvds: Support data and clock polarity flags

 Documentation/devicetree/bindings/display/panel/lvds.yaml | 10 +++-
 drivers/gpu/drm/panel/panel-lvds.c| 25 +++-
 drivers/gpu/drm/sun4i/sun4i_tcon.c| 16 -
 include/drm/drm_connector.h   |  4 +-
 4 files changed, 49 insertions(+), 6 deletions(-)

base-commit: bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9
-- 
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 0/2] Dual licence some files in GPL-2.0 and MIT

[Thomas Zimmermann]

Hi

Am 15.02.20 um 19:09 schrieb Emmanuel Vadot:
> Hello all,
> 
> We had a discussion a while back with Noralf where he said that he wouldn't
> mind dual licence his work under GPL-2 and MIT.
> Those files are a problem with BSDs as we cannot include them.
> For drm_client.c the main contributors are Noralf Trønnes and Thomas
> Zimmermann, the other commits are just catch ups from changes elsewhere
> (return values, struct member names, function renames etc ...).
> For drm_format_helper the main contributors are Noralf Trønnes and
> Gerd Hoffmann. Same comment as for drm_client.c for the other commits.
> 
> Emmanuel Vadot (2):
>   drm/client: Dual licence the file in GPL-2 and MIT
>   drm/format_helper: Dual licence the file in GPL 2 and MIT
> 
>  drivers/gpu/drm/drm_client.c| 2 +-
>  drivers/gpu/drm/drm_format_helper.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 

For the patches I contributed:

  Acked-by: Thomas Zimmermann 

Best regards
Thomas

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



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

[PATCH v1 3/3] drm/mediatek: move gce event property to mutex device node

[Bibby Hsieh]

According mtk hardware design, stream_done0 and stream_done1 are
generated by mutex, so we move gce event property to mutex device mode.

Signed-off-by: Bibby Hsieh 
Reviewed-by: CK Hu 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index e35b66c5ba0f..e1cc7703a312 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -820,7 +820,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
drm_crtc_index(&mtk_crtc->base));
mtk_crtc->cmdq_client = NULL;
}
-   ret = of_property_read_u32_index(dev->of_node, "mediatek,gce-events",
+   ret = of_property_read_u32_index(priv->mutex_node, 
"mediatek,gce-events",
 drm_crtc_index(&mtk_crtc->base),
 &mtk_crtc->cmdq_event);
if (ret)
-- 
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 1/3] arm64: dts: mt8183: Add gce setting in display node

[Bibby Hsieh]

In order to use GCE function, we need add some information
into display node (mboxes, mediatek,gce-client-reg, mediatek,gce-events).

Signed-off-by: Bibby Hsieh 
Signed-off-by: Yongqiang Niu 

---
This patch depends on ptach:
[RESEND,v6,02/17] arm64: dts: add display nodes for mt8183
https://patchwork.kernel.org/patch/11316277/
---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index be4428c92f35..8b522b039a37 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "mt8183-pinfunc.h"
 
 / {
@@ -664,6 +665,9 @@
reg = <0 0x1400 0 0x1000>;
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
#clock-cells = <1>;
+   mboxes = <&gce 0 CMDQ_THR_PRIO_HIGHEST>,
+<&gce 1 CMDQ_THR_PRIO_HIGHEST>;
+   mediatek,gce-client-reg = <&gce SUBSYS_1400 0 
0x1000>;
};
 
ovl0: ovl@14008000 {
@@ -672,6 +676,7 @@
interrupts = ;
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_OVL0>;
+   mediatek,gce-client-reg = <&gce SUBSYS_1400 0x8000 
0x1000>;
};
 
ovl_2l0: ovl@14009000 {
@@ -680,6 +685,7 @@
interrupts = ;
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_OVL0_2L>;
+   mediatek,gce-client-reg = <&gce SUBSYS_1400 0x9000 
0x1000>;
};
 
ovl_2l1: ovl@1400a000 {
@@ -688,6 +694,7 @@
interrupts = ;
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_OVL1_2L>;
+   mediatek,gce-client-reg = <&gce SUBSYS_1400 0xa000 
0x1000>;
};
 
rdma0: rdma@1400b000 {
@@ -697,6 +704,7 @@
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_RDMA0>;
mediatek,rdma_fifo_size = <5120>;
+   mediatek,gce-client-reg = <&gce SUBSYS_1400 0xb000 
0x1000>;
};
 
rdma1: rdma@1400c000 {
@@ -706,6 +714,7 @@
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_RDMA1>;
mediatek,rdma_fifo_size = <2048>;
+   mediatek,gce-client-reg = <&gce SUBSYS_1400 0xc000 
0x1000>;
};
 
color0: color@1400e000 {
@@ -715,6 +724,7 @@
interrupts = ;
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_COLOR0>;
+   mediatek,gce-client-reg = <&gce SUBSYS_1400 0xe000 
0x1000>;
};
 
ccorr0: ccorr@1400f000 {
@@ -723,6 +733,7 @@
interrupts = ;
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_CCORR0>;
+   mediatek,gce-client-reg = <&gce SUBSYS_1400 0xf000 
0x1000>;
};
 
aal0: aal@1401 {
@@ -732,6 +743,7 @@
interrupts = ;
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_AAL0>;
+   mediatek,gce-client-reg = <&gce SUBSYS_1401 0 
0x1000>;
};
 
gamma0: gamma@14011000 {
@@ -741,6 +753,7 @@
interrupts = ;
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_GAMMA0>;
+   mediatek,gce-client-reg = <&gce SUBSYS_1401 0x1000 
0x1000>;
};
 
dither0: dither@14012000 {
@@ -749,6 +762,7 @@
interrupts = ;
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_DITHER0>;
+   mediatek,gce-client-reg = <&gce SUBSYS_1401 0x2000 
0x1000>;
};
 
mutex: mutex@14016000 {
@@ -756,6 +770,8 @@
reg = <0 0x14016000 0 0x1000>;
interrupts = ;
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+   mediatek,gce-events = ,
+   

[PATCH v1 2/3] drm/mediatek: make sure previous message done or be aborted before send

[Bibby Hsieh]

Mediatek CMDQ driver removed atomic parameter and implementation
related to atomic. DRM driver need to make sure previous message
done or be aborted before we send next message.

If previous message is still waiting for event, it means the
setting hasn't been updated into display hardware register,
we can abort the message and send next message to update the
newest setting into display hardware.
If previous message already started, we have to wait it until
transmission has been completed.

So we flush mbox client before we send new message to controller
driver.

This patch depends on ptach:
[0/3] Remove atomic_exec
https://patchwork.kernel.org/cover/11381677/

Signed-off-by: Bibby Hsieh 
Reviewed-by: CK Hu 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 3c53ea22208c..e35b66c5ba0f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -491,6 +491,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc 
*mtk_crtc)
}
 #if IS_ENABLED(CONFIG_MTK_CMDQ)
if (mtk_crtc->cmdq_client) {
+   mbox_flush(mtk_crtc->cmdq_client->chan, 2000);
cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
-- 
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Correct typos in comments

[Daniel Vetter]

On Fri, Feb 14, 2020 at 11:29:38AM +, Maya Rashish wrote:
> Signed-off-by: Maya Rashish 
> Co-authored-by: Thomas Klausner 
> ---
>  drivers/gpu/drm/amd/include/atombios.h | 20 ++--
>  drivers/gpu/drm/amd/include/atomfirmware.h |  4 ++--
>  drivers/gpu/drm/radeon/atombios.h  |  8 
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|  2 +-

Can you please split this up per-driver, and prefix the commit message
with the usual driver prefix? git log drivers/gpu/drm/$driver will tell
you what it usually is.

Thanks, Daniel

>  4 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/include/atombios.h 
> b/drivers/gpu/drm/amd/include/atombios.h
> index 8ba21747b40a..2f124c1a9c8e 100644
> --- a/drivers/gpu/drm/amd/include/atombios.h
> +++ b/drivers/gpu/drm/amd/include/atombios.h
> @@ -1987,9 +1987,9 @@ typedef struct _PIXEL_CLOCK_PARAMETERS_V6
>  #define PIXEL_CLOCK_V6_MISC_HDMI_BPP_MASK   0x0c
>  #define PIXEL_CLOCK_V6_MISC_HDMI_24BPP  0x00
>  #define PIXEL_CLOCK_V6_MISC_HDMI_36BPP  0x04
> -#define PIXEL_CLOCK_V6_MISC_HDMI_36BPP_V6   0x08//for V6, the 
> correct defintion for 36bpp should be 2 for 36bpp(2:1)
> +#define PIXEL_CLOCK_V6_MISC_HDMI_36BPP_V6   0x08//for V6, the 
> correct definition for 36bpp should be 2 for 36bpp(2:1)
>  #define PIXEL_CLOCK_V6_MISC_HDMI_30BPP  0x08
> -#define PIXEL_CLOCK_V6_MISC_HDMI_30BPP_V6   0x04//for V6, the 
> correct defintion for 30bpp should be 1 for 36bpp(5:4)
> +#define PIXEL_CLOCK_V6_MISC_HDMI_30BPP_V6   0x04//for V6, the 
> correct definition for 30bpp should be 1 for 36bpp(5:4)
>  #define PIXEL_CLOCK_V6_MISC_HDMI_48BPP  0x0c
>  #define PIXEL_CLOCK_V6_MISC_REF_DIV_SRC 0x10
>  #define PIXEL_CLOCK_V6_MISC_GEN_DPREFCLK0x40
> @@ -2420,7 +2420,7 @@ typedef struct _LVDS_ENCODER_CONTROL_PARAMETERS
>  typedef struct _LVDS_ENCODER_CONTROL_PARAMETERS_V2
>  {
>USHORT usPixelClock;  // in 10KHz; for bios convenient
> -  UCHAR  ucMisc;// see PANEL_ENCODER_MISC_xx defintions below
> +  UCHAR  ucMisc;// see PANEL_ENCODER_MISC_xx definitions below
>UCHAR  ucAction;  // 0: turn off encoder
>  // 1: setup and turn on encoder
>UCHAR  ucTruncate;// bit0=0: Disable truncate
> @@ -2873,7 +2873,7 @@ typedef struct _ATOM_MULTIMEDIA_CONFIG_INFO
>  // Structures used in FirmwareInfoTable
>  
> //
>  
> -// usBIOSCapability Defintion:
> +// usBIOSCapability Definition:
>  // Bit 0 = 0: Bios image is not Posted, =1:Bios image is Posted;
>  // Bit 1 = 0: Dual CRTC is not supported, =1: Dual CRTC is supported;
>  // Bit 2 = 0: Extended Desktop is not supported, =1: Extended Desktop is 
> supported;
> @@ -4213,7 +4213,7 @@ typedef struct _ATOM_DPCD_INFO
>  #define ATOM_DPCD_MAX_LANE_MASK0x1F
>  
>  /**/
> -// VRAM usage and their defintions
> +// VRAM usage and their definitions
>  
>  // One chunk of VRAM used by Bios are for HWICON surfaces,EDID data.
>  // Current Mode timing and Dail Timing and/or STD timing data EACH device. 
> They can be broken down as below.
> @@ -6753,7 +6753,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
>  #define ATOM_S0_SYSTEM_POWER_STATE_VALUE_LITEAC 3
>  #define ATOM_S0_SYSTEM_POWER_STATE_VALUE_LIT2AC 4
>  
> -//Byte aligned defintion for BIOS usage
> +//Byte aligned definition for BIOS usage
>  #define ATOM_S0_CRT1_MONOb0 0x01
>  #define ATOM_S0_CRT1_COLORb00x02
>  #define ATOM_S0_CRT1_MASKb0 
> (ATOM_S0_CRT1_MONOb0+ATOM_S0_CRT1_COLORb0)
> @@ -6819,7 +6819,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
>  #define ATOM_S2_DISPLAY_ROTATION_ANGLE_MASK   0xC000L
>  
>  
> -//Byte aligned defintion for BIOS usage
> +//Byte aligned definition for BIOS usage
>  #define ATOM_S2_TV1_STANDARD_MASKb0 0x0F
>  #define ATOM_S2_CURRENT_BL_LEVEL_MASKb1 0xFF
>  #define ATOM_S2_DEVICE_DPMS_STATEb2 0x01
> @@ -6871,7 +6871,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
>  
>  
>  
> -//Byte aligned defintion for BIOS usage
> +//Byte aligned definition for BIOS usage
>  #define ATOM_S3_CRT1_ACTIVEb0   0x01
>  #define ATOM_S3_LCD1_ACTIVEb0   0x02
>  #define ATOM_S3_TV1_ACTIVEb00x04
> @@ -6910,7 +6910,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
>  #define ATOM_S4_LCD1_REFRESH_MASK   0xFF00L
>  #define ATOM_S4_LCD1_REFRESH_SHIFT  8
>  
> -//Byte aligned defintion for BIOS usage
> +//Byte aligned definition for BIOS usage
>  #define ATOM_S4_LCD1_PANEL_ID_MASKb00x0FF
>  #define ATOM_S4_LCD1_REFRESH_MASKb1 ATOM_S4_LCD1_PANEL_ID_MASKb0
>  #define ATOM_S4_VRAM_INFO_MASKb2ATOM_S4_LCD1_PANEL_ID_MASKb0
> @@ -6989,7 +6989,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
>  #defi

Re: [PATCH] Correct typos in comments

[Daniel Vetter]

On Fri, Feb 14, 2020 at 11:29:38AM +, Maya Rashish wrote:
> Signed-off-by: Maya Rashish 
> Co-authored-by: Thomas Klausner 

Also, we need a s-o-b from every co-author, because of the dco:

https://developercertificate.org/

Thanks, Daniel

> ---
>  drivers/gpu/drm/amd/include/atombios.h | 20 ++--
>  drivers/gpu/drm/amd/include/atomfirmware.h |  4 ++--
>  drivers/gpu/drm/radeon/atombios.h  |  8 
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|  2 +-
>  4 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/include/atombios.h 
> b/drivers/gpu/drm/amd/include/atombios.h
> index 8ba21747b40a..2f124c1a9c8e 100644
> --- a/drivers/gpu/drm/amd/include/atombios.h
> +++ b/drivers/gpu/drm/amd/include/atombios.h
> @@ -1987,9 +1987,9 @@ typedef struct _PIXEL_CLOCK_PARAMETERS_V6
>  #define PIXEL_CLOCK_V6_MISC_HDMI_BPP_MASK   0x0c
>  #define PIXEL_CLOCK_V6_MISC_HDMI_24BPP  0x00
>  #define PIXEL_CLOCK_V6_MISC_HDMI_36BPP  0x04
> -#define PIXEL_CLOCK_V6_MISC_HDMI_36BPP_V6   0x08//for V6, the 
> correct defintion for 36bpp should be 2 for 36bpp(2:1)
> +#define PIXEL_CLOCK_V6_MISC_HDMI_36BPP_V6   0x08//for V6, the 
> correct definition for 36bpp should be 2 for 36bpp(2:1)
>  #define PIXEL_CLOCK_V6_MISC_HDMI_30BPP  0x08
> -#define PIXEL_CLOCK_V6_MISC_HDMI_30BPP_V6   0x04//for V6, the 
> correct defintion for 30bpp should be 1 for 36bpp(5:4)
> +#define PIXEL_CLOCK_V6_MISC_HDMI_30BPP_V6   0x04//for V6, the 
> correct definition for 30bpp should be 1 for 36bpp(5:4)
>  #define PIXEL_CLOCK_V6_MISC_HDMI_48BPP  0x0c
>  #define PIXEL_CLOCK_V6_MISC_REF_DIV_SRC 0x10
>  #define PIXEL_CLOCK_V6_MISC_GEN_DPREFCLK0x40
> @@ -2420,7 +2420,7 @@ typedef struct _LVDS_ENCODER_CONTROL_PARAMETERS
>  typedef struct _LVDS_ENCODER_CONTROL_PARAMETERS_V2
>  {
>USHORT usPixelClock;  // in 10KHz; for bios convenient
> -  UCHAR  ucMisc;// see PANEL_ENCODER_MISC_xx defintions below
> +  UCHAR  ucMisc;// see PANEL_ENCODER_MISC_xx definitions below
>UCHAR  ucAction;  // 0: turn off encoder
>  // 1: setup and turn on encoder
>UCHAR  ucTruncate;// bit0=0: Disable truncate
> @@ -2873,7 +2873,7 @@ typedef struct _ATOM_MULTIMEDIA_CONFIG_INFO
>  // Structures used in FirmwareInfoTable
>  
> //
>  
> -// usBIOSCapability Defintion:
> +// usBIOSCapability Definition:
>  // Bit 0 = 0: Bios image is not Posted, =1:Bios image is Posted;
>  // Bit 1 = 0: Dual CRTC is not supported, =1: Dual CRTC is supported;
>  // Bit 2 = 0: Extended Desktop is not supported, =1: Extended Desktop is 
> supported;
> @@ -4213,7 +4213,7 @@ typedef struct _ATOM_DPCD_INFO
>  #define ATOM_DPCD_MAX_LANE_MASK0x1F
>  
>  /**/
> -// VRAM usage and their defintions
> +// VRAM usage and their definitions
>  
>  // One chunk of VRAM used by Bios are for HWICON surfaces,EDID data.
>  // Current Mode timing and Dail Timing and/or STD timing data EACH device. 
> They can be broken down as below.
> @@ -6753,7 +6753,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
>  #define ATOM_S0_SYSTEM_POWER_STATE_VALUE_LITEAC 3
>  #define ATOM_S0_SYSTEM_POWER_STATE_VALUE_LIT2AC 4
>  
> -//Byte aligned defintion for BIOS usage
> +//Byte aligned definition for BIOS usage
>  #define ATOM_S0_CRT1_MONOb0 0x01
>  #define ATOM_S0_CRT1_COLORb00x02
>  #define ATOM_S0_CRT1_MASKb0 
> (ATOM_S0_CRT1_MONOb0+ATOM_S0_CRT1_COLORb0)
> @@ -6819,7 +6819,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
>  #define ATOM_S2_DISPLAY_ROTATION_ANGLE_MASK   0xC000L
>  
>  
> -//Byte aligned defintion for BIOS usage
> +//Byte aligned definition for BIOS usage
>  #define ATOM_S2_TV1_STANDARD_MASKb0 0x0F
>  #define ATOM_S2_CURRENT_BL_LEVEL_MASKb1 0xFF
>  #define ATOM_S2_DEVICE_DPMS_STATEb2 0x01
> @@ -6871,7 +6871,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
>  
>  
>  
> -//Byte aligned defintion for BIOS usage
> +//Byte aligned definition for BIOS usage
>  #define ATOM_S3_CRT1_ACTIVEb0   0x01
>  #define ATOM_S3_LCD1_ACTIVEb0   0x02
>  #define ATOM_S3_TV1_ACTIVEb00x04
> @@ -6910,7 +6910,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
>  #define ATOM_S4_LCD1_REFRESH_MASK   0xFF00L
>  #define ATOM_S4_LCD1_REFRESH_SHIFT  8
>  
> -//Byte aligned defintion for BIOS usage
> +//Byte aligned definition for BIOS usage
>  #define ATOM_S4_LCD1_PANEL_ID_MASKb00x0FF
>  #define ATOM_S4_LCD1_REFRESH_MASKb1 ATOM_S4_LCD1_PANEL_ID_MASKb0
>  #define ATOM_S4_VRAM_INFO_MASKb2ATOM_S4_LCD1_PANEL_ID_MASKb0
> @@ -6989,7 +6989,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
>  #define ATOM_S6_VRI_BRIGHTNESS_CHANGE   0x4000L
>  #define ATOM_S

Re: [PATCH v2 2/2] drm/format_helper: Dual licence the file in GPL 2 and MIT

[Daniel Vetter]

On Sat, Feb 15, 2020 at 07:09:11PM +0100, Emmanuel Vadot wrote:
> From: Emmanuel Vadot 
> 
> Contributors for this file are :
> Gerd Hoffmann 
> Maxime Ripard 
> Noralf Trønnes 
> 
> Signed-off-by: Emmanuel Vadot 

Patch applied since we have all the acks we need. I think for the first
one we still need a few more.
-Daniel

> ---
>  drivers/gpu/drm/drm_format_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_format_helper.c 
> b/drivers/gpu/drm/drm_format_helper.c
> index 0897cb9aeaff..3b818f2b2392 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -1,4 +1,4 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> +// SPDX-License-Identifier: GPL-2.0 or MIT
>  /*
>   * Copyright (C) 2016 Noralf Trønnes
>   *
> -- 
> 2.25.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf: Fix a typo in Kconfig

[Daniel Vetter]

On Sun, Feb 16, 2020 at 12:47:08PM +0100, Christophe JAILLET wrote:
> A 'h' ismissing in' syncronization'
> 
> Signed-off-by: Christophe JAILLET 

Applied, thanks for your patch.
-Daniel

> ---
>  drivers/dma-buf/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> index 0613bb7770f5..e7d820ce0724 100644
> --- a/drivers/dma-buf/Kconfig
> +++ b/drivers/dma-buf/Kconfig
> @@ -6,7 +6,7 @@ config SYNC_FILE
>   default n
>   select DMA_SHARED_BUFFER
>   ---help---
> -   The Sync File Framework adds explicit syncronization via
> +   The Sync File Framework adds explicit synchronization via
> userspace. It enables send/receive 'struct dma_fence' objects to/from
> userspace via Sync File fds for synchronization between drivers via
> userspace components. It has been ported from Android.
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] gpu/drm: ingenic: Switch emulated fbdev to 16bpp

[Daniel Vetter]

On Sun, Feb 16, 2020 at 12:58:10PM -0300, Paul Cercueil wrote:
> The fbdev emulation is only ever used on Ingenic SoCs to run old SDL1
> based games at 16bpp (rgb565). Recent applications generally talk to
> DRM directly, and can request their favourite pixel format; so we can
> make everybody happy by switching the emulated fbdev to 16bpp.
> 
> Signed-off-by: Paul Cercueil 
> ---
>  drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
> b/drivers/gpu/drm/ingenic/ingenic-drm.c
> index 034961a40e98..9aa88fabbd2a 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
> @@ -808,7 +808,7 @@ static int ingenic_drm_probe(struct platform_device *pdev)
>   goto err_devclk_disable;
>   }
>  
> - ret = drm_fbdev_generic_setup(drm, 32);
> + ret = drm_fbdev_generic_setup(drm, 16);

If you're really bored, could we make everyone even more happy by exposing
format switching in the drm fbdev emulation? Only for the drivers which
have a full format list on the primary plane (gets too tricky otherwise).
And obviously only formats that have lower bpp than the one we booted with
(can't reallocate the framebuffer because fbdev).

Just as an idea, this shouldn't be too horrible amounts of work to wire
up. But ofc more than this oneliner :-)

Cheers, Daniel

>   if (ret)
>   dev_warn(dev, "Unable to start fbdev emulation: %i", ret);
>  
> -- 
> 2.25.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 8/9] drm/client: Add drm_client_init_from_id() and drm_client_modeset_set()

[Daniel Vetter]

On Sun, Feb 16, 2020 at 06:21:16PM +0100, Noralf Trønnes wrote:
> drm_client_init_from_id() provides a way for clients to add a client based
> on the minor. drm_client_modeset_set() provides a way to set the modeset
> for clients that handles connectors and display mode on their own.
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/drm_client.c | 37 
>  drivers/gpu/drm/drm_client_modeset.c | 52 
>  include/drm/drm_client.h |  4 +++
>  3 files changed, 93 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index d9a2e3695525..dbd73fe8d987 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -112,6 +112,43 @@ int drm_client_init(struct drm_device *dev, struct 
> drm_client_dev *client,
>  }
>  EXPORT_SYMBOL(drm_client_init);
>  
> +/**
> + * drm_client_init_from_id - Initialise a DRM client
> + * @minor_id: DRM minor id
> + * @client: DRM client
> + * @name: Client name
> + * @funcs: DRM client functions (optional)
> + *
> + * This function looks up the drm_device using the minor id and initializes 
> the client.
> + * It also registeres the client to avoid a possible race with DRM device 
> unregister.

I think another sentence here would be good, explaining that this is for
drivers outside of drm to expose a specific drm driver in some fashion,
and just outright mention your use-case as an example.

I'm also not sure whether lookup-by-minor is the greatest thing for
kernel-internal lookups like this, maybe Greg has some idea?

> + *
> + * See drm_client_init() and drm_client_register().
> + *
> + * Returns:
> + * Zero on success or negative error code on failure.
> + */
> +int drm_client_init_from_id(unsigned int minor_id, struct drm_client_dev 
> *client,
> + const char *name, const struct drm_client_funcs 
> *funcs)
> +{
> + struct drm_minor *minor;
> + int ret;
> +
> + minor = drm_minor_acquire(minor_id);
> + if (IS_ERR(minor))
> + return PTR_ERR(minor);
> +
> + mutex_lock(&minor->dev->clientlist_mutex);
> + ret = drm_client_init(minor->dev, client, name, funcs);
> + if (!ret)
> + list_add(&client->list, &minor->dev->clientlist);
> + mutex_unlock(&minor->dev->clientlist_mutex);
> +
> + drm_minor_release(minor);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_client_init_from_id);
> +
>  /**
>   * drm_client_register - Register client
>   * @client: DRM client
> diff --git a/drivers/gpu/drm/drm_client_modeset.c 
> b/drivers/gpu/drm/drm_client_modeset.c
> index 895b73f23079..9396267e646c 100644
> --- a/drivers/gpu/drm/drm_client_modeset.c
> +++ b/drivers/gpu/drm/drm_client_modeset.c
> @@ -807,6 +807,58 @@ int drm_client_modeset_probe(struct drm_client_dev 
> *client, unsigned int width,
>  }
>  EXPORT_SYMBOL(drm_client_modeset_probe);
>  
> +/**
> + * drm_client_modeset_set() - Set modeset
> + * @client: DRM client
> + * @connector: Connector
> + * @mode: Display mode
> + * @fb: Framebuffer
> + *
> + * This function releases any current modeset info and sets the new modeset 
> in
> + * the client's modeset array.
> + *
> + * Returns:
> + * Zero on success or negative error code on failure.
> + */
> +int drm_client_modeset_set(struct drm_client_dev *client, struct 
> drm_connector *connector,
> +struct drm_display_mode *mode, struct 
> drm_framebuffer *fb)

Hm, since you need the functionality would be kinda neat to wire this up
for the fbdev emulation too. Ofc without reallocating the framebuffer
(fbdev can't do that), so would be limited to lower resolutions than we
booted with.
-Daniel

> +{
> + struct drm_mode_set *modeset;
> + int ret = -ENOENT;
> +
> + mutex_lock(&client->modeset_mutex);
> +
> + drm_client_modeset_release(client);
> +
> + if (!connector || !mode || !fb) {
> + ret = 0;
> + goto unlock;
> + }
> +
> + drm_client_for_each_modeset(modeset, client) {
> + if (!connector_has_possible_crtc(connector, modeset->crtc))
> + continue;
> +
> + modeset->mode = drm_mode_duplicate(client->dev, mode);
> + if (!modeset->mode) {
> + ret = -ENOMEM;
> + break;
> + }
> +
> + drm_connector_get(connector);
> + modeset->connectors[modeset->num_connectors++] = connector;
> +
> + modeset->fb = fb;
> + ret = 0;
> + break;
> + }
> +unlock:
> + mutex_unlock(&client->modeset_mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_client_modeset_set);
> +
>  /**
>   * drm_client_rotation() - Check the initial rotation value
>   * @modeset: DRM modeset
> diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
> index 5cf2c5dd8b1e..97e4157d07c5 100644
> --- a/include/drm/drm_client.h
> +++ b/include/drm/drm_client.h
> @@ -10

Re: [RFC 0/9] Regmap over USB for Multifunction USB Device (gpio, display, ...)

[Daniel Vetter]

On Sun, Feb 16, 2020 at 06:21:08PM +0100, Noralf Trønnes wrote:
> Hi,
> 
> A while back I had the idea to turn a Raspberry Pi Zero into a $5
> USB to HDMI/SDTV/DSI/DPI display adapter.
> 
> Thinking about how to represent the display to the driver I realised
> that hardware use registers as API. And Linux does have a generic
> register abstraction: regmap. Furthermore this means that if I can do a
> regmap over USB implementation, it will be easy to do other functions
> like gpio, adc and others. After a few iterations trying to understand
> the USB subsystem and satisfying driver requirements, I now have
> something that looks promising.
> 
> I'm sending out an early version hoping to get feedback especially on
> the core parts that handles regmap and interrupts.
> 
> Overview:
> 
>   USB Host  : USB Device
> :
> --  :  --
> --  | mfd: mud   |  :  | f_mud  |  --
> | Driver |  --  :  ||  | Driver |
> --  | regmap-usb |  :  | (mud_regmap)   |  --
> --  :  --
> 
> 
> I've attached 2 drivers:
> - gpio/pinctrl: is more or less finished
> - display: needs a lot more work
> 
> 
> USB3 device
> I've only tested this with usb2 devices (Pi, BBB) so I should get myself
> a usb3 gadget capable board. My searching didn't turn up much, so this
> seems to be quite rare. ROCK960 has USB 3.0 type C OTG but the price is
> $139 which is a bit expensive for this hobby project. Does anyone know
> of a cheap board?
> 
> Noralf.

Pretty cool idea, and the drm side looks really tiny (after all your
drm_client work that is). I think the important feedback here is for the
usb and regmap stuff, that's totally out of my area. I've commented on the
drm_client patch, but that's just minor stuff, imo looks good.

Cheers, Daniel

> 
> 
> Noralf Trønnes (9):
>   regmap: Add USB support
>   mfd: Add driver for Multifunction USB Device
>   usb: gadget: function: Add Multifunction USB Device support
>   pinctrl: Add Multifunction USB Device pinctrl driver
>   usb: gadget: function: mud: Add gpio support
>   regmap: Speed up _regmap_raw_write_impl() for large buffers
>   drm: Add Multifunction USB Device display driver
>   drm/client: Add drm_client_init_from_id() and drm_client_modeset_set()
>   usb: gadget: function: mud: Add display support
> 
>  drivers/base/regmap/Kconfig  |8 +-
>  drivers/base/regmap/Makefile |1 +
>  drivers/base/regmap/regmap-usb.c | 1026 ++
>  drivers/base/regmap/regmap.c |   10 +-
>  drivers/gpu/drm/Kconfig  |2 +
>  drivers/gpu/drm/Makefile |1 +
>  drivers/gpu/drm/drm_client.c |   37 +
>  drivers/gpu/drm/drm_client_modeset.c |   52 +
>  drivers/gpu/drm/mud/Kconfig  |   18 +
>  drivers/gpu/drm/mud/Makefile |4 +
>  drivers/gpu/drm/mud/mud_drm.c| 1198 ++
>  drivers/gpu/drm/mud/mud_drm.h|  137 +++
>  drivers/gpu/drm/mud/mud_drm_gadget.c |  889 
>  drivers/mfd/Kconfig  |8 +
>  drivers/mfd/Makefile |1 +
>  drivers/mfd/mud.c|  580 +++
>  drivers/pinctrl/Kconfig  |9 +
>  drivers/pinctrl/Makefile |1 +
>  drivers/pinctrl/pinctrl-mud.c|  657 
>  drivers/pinctrl/pinctrl-mud.h|   89 ++
>  drivers/usb/gadget/Kconfig   |   36 +
>  drivers/usb/gadget/function/Makefile |6 +
>  drivers/usb/gadget/function/f_mud.c  |  913 +
>  drivers/usb/gadget/function/f_mud.h  |  210 
>  drivers/usb/gadget/function/f_mud_drm.c  |  181 
>  drivers/usb/gadget/function/f_mud_pins.c |  962 +
>  drivers/usb/gadget/function/mud_regmap.c |  936 +
>  include/drm/drm_client.h |4 +
>  include/linux/mfd/mud.h  |   16 +
>  include/linux/regmap.h   |   23 +
>  include/linux/regmap_usb.h   |   97 ++
>  31 files changed, 8107 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/base/regmap/regmap-usb.c
>  create mode 100644 drivers/gpu/drm/mud/Kconfig
>  create mode 100644 drivers/gpu/drm/mud/Makefile
>  create mode 100644 drivers/gpu/drm/mud/mud_drm.c
>  create mode 100644 drivers/gpu/drm/mud/mud_drm.h
>  create mode 100644 drivers/gpu/drm/mud/mud_drm_gadget.c
>  create mode 100644 drivers/mfd/mud.c
>  create mode 100644 drivers/pinctrl/pinctrl-mud.c
>  create mode 100644 drivers/pinctrl/pinctrl-mud.h
>  create mode 100644 drivers/usb/gadget/function/f_mud.c
>  create mode 100644 drivers/usb/gadget/function/f_mud.h
>  create mode 100644 drivers/usb/gadget/function/f_mud_drm.c
>  create mode 100644 drivers/usb/gadget/function/f_mud_pins.c
>  create m

Re: [PATCH v6 02/51] drm/connector: Add helper to get a connector type name

[Daniel Vetter]

On Sun, Feb 16, 2020 at 11:02:19PM +0200, Laurent Pinchart wrote:
> drm_connector.c contains a map of connector types (DRM_MODE_CONNECTOR_*)
> to name strings, but doesn't expose it. This leads to drivers having to
> store a similar map.

Maybe also a todo if there's many of these?
-Daniel

> 
> Add a new drm_get_connector_type_name() helper function that return a
> name string for a connector type.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Boris Brezillon 
> Reviewed-by: Sam Ravnborg 
> ---
>  drivers/gpu/drm/drm_connector.c | 15 +++
>  include/drm/drm_connector.h |  1 +
>  2 files changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index f632ca05960e..644f0ad10671 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -111,6 +111,21 @@ void drm_connector_ida_destroy(void)
>   ida_destroy(&drm_connector_enum_list[i].ida);
>  }
>  
> +/**
> + * drm_get_connector_type_name - return a string for connector type
> + * @type: The connector type (DRM_MODE_CONNECTOR_*)
> + *
> + * Returns: the name of the connector type, or NULL if the type is not valid.
> + */
> +const char *drm_get_connector_type_name(unsigned int type)
> +{
> + if (type < ARRAY_SIZE(drm_connector_enum_list))
> + return drm_connector_enum_list[type].name;
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL(drm_get_connector_type_name);
> +
>  /**
>   * drm_connector_get_cmdline_mode - reads the user's cmdline mode
>   * @connector: connector to quwery
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index b3815371c271..c3bd5262db9c 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1518,6 +1518,7 @@ drm_connector_is_unregistered(struct drm_connector 
> *connector)
>   DRM_CONNECTOR_UNREGISTERED;
>  }
>  
> +const char *drm_get_connector_type_name(unsigned int connector_type);
>  const char *drm_get_connector_status_name(enum drm_connector_status status);
>  const char *drm_get_subpixel_order_name(enum subpixel_order order);
>  const char *drm_get_dpms_name(int val);
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/edid: temporary workaround to pass HDMI 2.0 compliance HF1-13

[Lee Shawn C]

Test case HF1-13 for HDMI 2.0 compliance would ask DUT to downgrade
output resolution to 720x480 or 720x576 (lower than 3.4Gbps).
And check scrambling feature was disabled as well.

But QD980 report it can support low rate scrambling. The vendor
specific data block byte[6] was 0x88. If driver enabled scrambling
rely on this info. Then HF1-13 would not get pass because DUT have
to disable scrambling to run this case.

Cc: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Clint Taylor 
Cc: Cooper Chiou 
Signed-off-by: Lee Shawn C 
---
 drivers/gpu/drm/drm_edid.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 99769d6c9f84..0b4badc20c35 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -85,6 +85,8 @@
 #define EDID_QUIRK_FORCE_10BPC (1 << 11)
 /* Non desktop display (i.e. HMD) */
 #define EDID_QUIRK_NON_DESKTOP (1 << 12)
+/* Do not enable low rates scrambling */
+#define EDID_QUIRK_DISABLE_LOW_RATE_SCRAMBLING (1 << 13)
 
 struct detailed_mode_closure {
struct drm_connector *connector;
@@ -214,6 +216,9 @@ static const struct edid_quirk {
 
/* OSVR HDK and HDK2 VR Headsets */
{ "SVR", 0x1019, EDID_QUIRK_NON_DESKTOP },
+
+   /* Quantumdata 980 test platform */
+   { "QDI", 0x03D4, EDID_QUIRK_DISABLE_LOW_RATE_SCRAMBLING },
 };
 
 /*
@@ -4710,10 +4715,11 @@ static void drm_parse_ycbcr420_deep_color_info(struct 
drm_connector *connector,
 }
 
 static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
-const u8 *hf_vsdb)
+const u8 *hf_vsdb, const struct edid *edid)
 {
struct drm_display_info *display = &connector->display_info;
struct drm_hdmi_info *hdmi = &display->hdmi;
+   u32 quirks = edid_get_quirks(edid);
 
display->has_hdmi_infoframe = true;
 
@@ -4747,7 +4753,8 @@ static void drm_parse_hdmi_forum_vsdb(struct 
drm_connector *connector,
scdc->scrambling.supported = true;
 
/* Few sinks support scrambling for clocks < 340M */
-   if ((hf_vsdb[6] & 0x8))
+   if ((hf_vsdb[6] & 0x8) &&
+   !(quirks & EDID_QUIRK_DISABLE_LOW_RATE_SCRAMBLING))
scdc->scrambling.low_rates = true;
}
}
@@ -4870,7 +4877,7 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
if (cea_db_is_hdmi_vsdb(db))
drm_parse_hdmi_vsdb_video(connector, db);
if (cea_db_is_hdmi_forum_vsdb(db))
-   drm_parse_hdmi_forum_vsdb(connector, db);
+   drm_parse_hdmi_forum_vsdb(connector, db, edid);
if (cea_db_is_y420cmdb(db))
drm_parse_y420cmdb_bitmap(connector, db);
if (cea_db_is_vcdb(db))
-- 
2.17.1

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

Re: [PATCH v6 04/51] drm/bridge: Add connector-related bridge operations and data

[Daniel Vetter]

On Sun, Feb 16, 2020 at 11:02:21PM +0200, Laurent Pinchart wrote:
> To support implementation of DRM connectors on top of DRM bridges
> instead of by bridges, the drm_bridge needs to expose new operations and
> data:
> 
> - Output detection, hot-plug notification, mode retrieval and EDID
>   retrieval operations
> - Bitmask of supported operations
> - Bridge output type
> - I2C adapter for DDC access
> 
> Add and document these.
> 
> Three new bridge helper functions are also added to handle hot plug
> notification in a way that is as transparent as possible for the
> bridges.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Boris Brezillon 
> Reviewed-by: Sam Ravnborg 
> ---
> Changes since v3:
> 
> - Fix typos
> 
> Changes since v2:
> 
> - Add wrappers around the .detect(), .get_modes() and .get_edid()
>   operations
> - Warn bridge drivers about valid usage of the connector argument to
>   .get_modes() and .get_edid()
> 
> Changes since v1:
> 
> - Make .hpd_enable() and .hpd_disable() optional
> - Rename .lost_hotplug() to .hpd_notify()
> - Add ddc field to drm_bridge
> ---
>  drivers/gpu/drm/drm_bridge.c | 162 +
>  include/drm/drm_bridge.h | 192 ++-
>  2 files changed, 353 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 68ab933ee430..78d26a9a3ee6 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -71,6 +71,8 @@ static LIST_HEAD(bridge_list);
>   */
>  void drm_bridge_add(struct drm_bridge *bridge)
>  {
> + mutex_init(&bridge->hpd_mutex);
> +
>   mutex_lock(&bridge_lock);
>   list_add_tail(&bridge->list, &bridge_list);
>   mutex_unlock(&bridge_lock);
> @@ -87,6 +89,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
>   mutex_lock(&bridge_lock);
>   list_del_init(&bridge->list);
>   mutex_unlock(&bridge_lock);
> +
> + mutex_destroy(&bridge->hpd_mutex);
>  }
>  EXPORT_SYMBOL(drm_bridge_remove);
>  
> @@ -919,6 +923,164 @@ int drm_atomic_bridge_chain_check(struct drm_bridge 
> *bridge,
>  }
>  EXPORT_SYMBOL(drm_atomic_bridge_chain_check);
>  
> +/**
> + * drm_bridge_detect - check if anything is attached to the bridge output
> + * @bridge: bridge control structure
> + *
> + * If the bridge supports output detection, as reported by the
> + * DRM_BRIDGE_OP_DETECT bridge ops flag, call &drm_bridge_funcs.detect for 
> the
> + * bridge and return the connection status. Otherwise return
> + * connector_status_unknown.
> + *
> + * RETURNS:
> + * The detection status on success, or connector_status_unknown if the bridge
> + * doesn't support output detection.
> + */
> +enum drm_connector_status drm_bridge_detect(struct drm_bridge *bridge)
> +{
> + if (!(bridge->ops & DRM_BRIDGE_OP_DETECT))
> + return connector_status_unknown;
> +
> + return bridge->funcs->detect(bridge);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_detect);
> +
> +/**
> + * drm_bridge_get_modes - fill all modes currently valid for the sink into 
> the
> + * @connector
> + * @bridge: bridge control structure
> + * @connector: the connector to fill with modes
> + *
> + * If the bridge supports output modes retrieval, as reported by the
> + * DRM_BRIDGE_OP_MODES bridge ops flag, call &drm_bridge_funcs.get_modes to
> + * fill the connector with all valid modes and return the number of modes
> + * added. Otherwise return 0.
> + *
> + * RETURNS:
> + * The number of modes added to the connector.
> + */
> +int drm_bridge_get_modes(struct drm_bridge *bridge,
> +  struct drm_connector *connector)
> +{
> + if (!(bridge->ops & DRM_BRIDGE_OP_MODES))
> + return 0;
> +
> + return bridge->funcs->get_modes(bridge, connector);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_get_modes);
> +
> +/**
> + * drm_bridge_get_edid - get the EDID data of the connected display
> + * @bridge: bridge control structure
> + * @connector: the connector to read EDID for
> + *
> + * If the bridge supports output EDID retrieval, as reported by the
> + * DRM_BRIDGE_OP_EDID bridge ops flag, call &drm_bridge_funcs.get_edid to
> + * get the EDID and return it. Otherwise return ERR_PTR(-ENOTSUPP).
> + *
> + * RETURNS:
> + * The retrieved EDID on success, or an error pointer otherwise.
> + */
> +struct edid *drm_bridge_get_edid(struct drm_bridge *bridge,
> +  struct drm_connector *connector)
> +{
> + if (!(bridge->ops & DRM_BRIDGE_OP_EDID))
> + return ERR_PTR(-ENOTSUPP);
> +
> + return bridge->funcs->get_edid(bridge, connector);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_get_edid);
> +
> +/**
> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> + * @bridge: bridge control structure
> + * @cb: hot-plug detection callback
> + * @data: data to be passed to the hot-plug detection callback
> + *
> + * Call &drm_bridge_funcs.hpd_enable if implemented and register the given 
> @cb
> + * and @d

Re: [RFC 0/9] Regmap over USB for Multifunction USB Device (gpio, display, ...)

[Neil Armstrong]

Hi,

On 16/02/2020 18:21, Noralf Trønnes wrote:
> Hi,
> 
> A while back I had the idea to turn a Raspberry Pi Zero into a $5
> USB to HDMI/SDTV/DSI/DPI display adapter.
> 
> Thinking about how to represent the display to the driver I realised
> that hardware use registers as API. And Linux does have a generic
> register abstraction: regmap. Furthermore this means that if I can do a
> regmap over USB implementation, it will be easy to do other functions
> like gpio, adc and others. After a few iterations trying to understand
> the USB subsystem and satisfying driver requirements, I now have
> something that looks promising.
> 
> I'm sending out an early version hoping to get feedback especially on
> the core parts that handles regmap and interrupts.
> 
> Overview:
> 
>   USB Host  : USB Device
> :
> --  :  --
> --  | mfd: mud   |  :  | f_mud  |  --
> | Driver |  --  :  ||  | Driver |
> --  | regmap-usb |  :  | (mud_regmap)   |  --
> --  :  --
> 

The idea is really like ARA's greybus, but much simpler !
Anyway nice idea, do you have good performance over USB2 and
RPi's awful DWC2 gagdet controller ?

Neil
> 
> I've attached 2 drivers:
> - gpio/pinctrl: is more or less finished
> - display: needs a lot more work
> 
> 
> USB3 device
> I've only tested this with usb2 devices (Pi, BBB) so I should get myself
> a usb3 gadget capable board. My searching didn't turn up much, so this
> seems to be quite rare. ROCK960 has USB 3.0 type C OTG but the price is
> $139 which is a bit expensive for this hobby project. Does anyone know
> of a cheap board?
> 
> Noralf.
> 
> 
> Noralf Trønnes (9):
>   regmap: Add USB support
>   mfd: Add driver for Multifunction USB Device
>   usb: gadget: function: Add Multifunction USB Device support
>   pinctrl: Add Multifunction USB Device pinctrl driver
>   usb: gadget: function: mud: Add gpio support
>   regmap: Speed up _regmap_raw_write_impl() for large buffers
>   drm: Add Multifunction USB Device display driver
>   drm/client: Add drm_client_init_from_id() and drm_client_modeset_set()
>   usb: gadget: function: mud: Add display support
> 
>  drivers/base/regmap/Kconfig  |8 +-
>  drivers/base/regmap/Makefile |1 +
>  drivers/base/regmap/regmap-usb.c | 1026 ++
>  drivers/base/regmap/regmap.c |   10 +-
>  drivers/gpu/drm/Kconfig  |2 +
>  drivers/gpu/drm/Makefile |1 +
>  drivers/gpu/drm/drm_client.c |   37 +
>  drivers/gpu/drm/drm_client_modeset.c |   52 +
>  drivers/gpu/drm/mud/Kconfig  |   18 +
>  drivers/gpu/drm/mud/Makefile |4 +
>  drivers/gpu/drm/mud/mud_drm.c| 1198 ++
>  drivers/gpu/drm/mud/mud_drm.h|  137 +++
>  drivers/gpu/drm/mud/mud_drm_gadget.c |  889 
>  drivers/mfd/Kconfig  |8 +
>  drivers/mfd/Makefile |1 +
>  drivers/mfd/mud.c|  580 +++
>  drivers/pinctrl/Kconfig  |9 +
>  drivers/pinctrl/Makefile |1 +
>  drivers/pinctrl/pinctrl-mud.c|  657 
>  drivers/pinctrl/pinctrl-mud.h|   89 ++
>  drivers/usb/gadget/Kconfig   |   36 +
>  drivers/usb/gadget/function/Makefile |6 +
>  drivers/usb/gadget/function/f_mud.c  |  913 +
>  drivers/usb/gadget/function/f_mud.h  |  210 
>  drivers/usb/gadget/function/f_mud_drm.c  |  181 
>  drivers/usb/gadget/function/f_mud_pins.c |  962 +
>  drivers/usb/gadget/function/mud_regmap.c |  936 +
>  include/drm/drm_client.h |4 +
>  include/linux/mfd/mud.h  |   16 +
>  include/linux/regmap.h   |   23 +
>  include/linux/regmap_usb.h   |   97 ++
>  31 files changed, 8107 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/base/regmap/regmap-usb.c
>  create mode 100644 drivers/gpu/drm/mud/Kconfig
>  create mode 100644 drivers/gpu/drm/mud/Makefile
>  create mode 100644 drivers/gpu/drm/mud/mud_drm.c
>  create mode 100644 drivers/gpu/drm/mud/mud_drm.h
>  create mode 100644 drivers/gpu/drm/mud/mud_drm_gadget.c
>  create mode 100644 drivers/mfd/mud.c
>  create mode 100644 drivers/pinctrl/pinctrl-mud.c
>  create mode 100644 drivers/pinctrl/pinctrl-mud.h
>  create mode 100644 drivers/usb/gadget/function/f_mud.c
>  create mode 100644 drivers/usb/gadget/function/f_mud.h
>  create mode 100644 drivers/usb/gadget/function/f_mud_drm.c
>  create mode 100644 drivers/usb/gadget/function/f_mud_pins.c
>  create mode 100644 drivers/usb/gadget/function/mud_regmap.c
>  create mode 100644 include/linux/mfd/mud.h
>  create mode 100644 include/linux/regmap_usb.h
> 

Re: [PATCHv4,04/36] drm/gem-fb-helper: Add special version of drm_gem_fb_size_check

[Andrzej Pietrasiewicz]

Hi James,

Thank you for the review.

Did you intentionally review patches from the v4 series or you simply
didn't notice the v5? There are some differences, the most notable one
is using proper way of subclassing a drm_framebuffer.
The v5 series was sent on 17th December 2019.

Andrzej

W dniu 17.02.2020 o 09:16, james qian wang (Arm Technology China) pisze:

Hi Andrzej:

Really a good idea for introducing this custom size check, it's very
useful for some Komeda/malidp format, espcially pitch_multiplier, maybe
in future we can add it into into the drm_format_info.

On Fri, Dec 13, 2019 at 04:58:35PM +0100, Andrzej Pietrasiewicz wrote:

The new version accepts a struct describing deviations from standard way of
doing the size checks. The caller must provide the respective values.

Signed-off-by: Andrzej Pietrasiewicz 
---
  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 47 
  include/drm/drm_gem_framebuffer_helper.h | 16 +++
  2 files changed, 55 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index 787edb9a916b..4201dc1f32a5 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -201,8 +201,9 @@ int drm_gem_fb_lookup(struct drm_device *dev,
  EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
  
  /**

- * drm_gem_fb_size_check() - Helper function for use in
- *  &drm_mode_config_funcs.fb_create implementations
+ * drm_gem_fb_size_check_special() - Helper function for use in
+ *  &drm_mode_config_funcs.fb_create
+ *  implementations
   * @dev: DRM device
   * @mode_cmd: Metadata from the userspace framebuffer creation request
   *
@@ -212,9 +213,10 @@ EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
   * Returns:
   * Zero on success or a negative error code on failure.
   */
-int drm_gem_fb_size_check(struct drm_device *dev,
- const struct drm_mode_fb_cmd2 *mode_cmd,
- struct drm_gem_object **objs)
+int drm_gem_fb_size_check_special(struct drm_device *dev,


How about name it to drm_gem_fb_custom_size_check()


+ const struct drm_mode_fb_cmd2 *mode_cmd,
+ const struct drm_size_check *check,
+ struct drm_gem_object **objs)
  {
const struct drm_format_info *info;
int i;
@@ -227,10 +229,19 @@ int drm_gem_fb_size_check(struct drm_device *dev,
unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
unsigned int min_size;
+   u32 pitch = mode_cmd->pitches[i];
+
+   if (check && check->use_pitch_multiplier)
+   if ((pitch * check->pitch_multiplier[i]) %
+   check->pitch_modulo)
+   return -EINVAL;
  
-		min_size = (height - 1) * mode_cmd->pitches[i]

-+ drm_format_info_min_pitch(info, i, width)
-+ mode_cmd->offsets[i];
+   if (check && check->use_min_size)
+   min_size = check->min_size[i];
+   else
+   min_size = (height - 1) * pitch
++ drm_format_info_min_pitch(info, i, width)
++ mode_cmd->offsets[i];
  
  		if (objs[i]->size < min_size)

return -EINVAL;
@@ -239,6 +250,26 @@ int drm_gem_fb_size_check(struct drm_device *dev,
return 0;
  
  }

+EXPORT_SYMBOL_GPL(drm_gem_fb_size_check_special);
+
+/**
+ * drm_gem_fb_size_check() - Helper function for use in
+ *  &drm_mode_config_funcs.fb_create implementations
+ * @dev: DRM device
+ * @mode_cmd: Metadata from the userspace framebuffer creation request
+ *
+ * This function can be used to verify buffer sizes for all planes.
+ * It is caller's responsibility to put the objects on failure.
+ *
+ * Returns:
+ * Zero on success or a negative error code on failure.
+ */
+int drm_gem_fb_size_check(struct drm_device *dev,
+ const struct drm_mode_fb_cmd2 *mode_cmd,
+ struct drm_gem_object **objs)
+{
+   return drm_gem_fb_size_check_special(dev, mode_cmd, NULL, objs);
+}
  EXPORT_SYMBOL_GPL(drm_gem_fb_size_check);
  
  /**

diff --git a/include/drm/drm_gem_framebuffer_helper.h 
b/include/drm/drm_gem_framebuffer_helper.h
index c85d4b152e91..74304a268694 100644
--- a/include/drm/drm_gem_framebuffer_helper.h
+++ b/include/drm/drm_gem_framebuffer_helper.h
@@ -11,6 +11,18 @@ struct drm_mode_fb_cmd2;
  struct drm_plane;
  struct drm_plane_state;
  struct drm_simple_display_pipe;
+struct drm_size_check;
+
+/**
+ * struct drm_size_check - Description of special requirements for size checks.
+ */
+struc

Re: [PATCHv4,05/36] drm/gem-fb-helper: Add generic afbc size checks

[james qian wang (Arm Technology China)]

Hi Andrzej:

On Fri, Dec 13, 2019 at 04:58:36PM +0100, Andrzej Pietrasiewicz wrote:
> Extend the size-checking special function to handle afbc.
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
>  drivers/gpu/drm/drm_fourcc.c | 10 +++-
>  drivers/gpu/drm/drm_framebuffer.c|  3 +
>  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 60 ++--
>  include/drm/drm_gem_framebuffer_helper.h | 16 ++
>  4 files changed, 82 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index d14dd7c86020..9ac2175c5bee 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -323,8 +323,14 @@ drm_get_format_info(struct drm_device *dev,
>  {
>   const struct drm_format_info *info = NULL;
>  
> - if (dev->mode_config.funcs->get_format_info)
> - info = dev->mode_config.funcs->get_format_info(mode_cmd);
> + /* bypass driver callback if afbc */
> + if (!drm_is_afbc(mode_cmd->modifier[0]))
> + if (dev->mode_config.funcs->get_format_info) {
> + const struct drm_mode_config_funcs *funcs;
> +
> + funcs = dev->mode_config.funcs;
> + info = funcs->get_format_info(mode_cmd);
> + }
>  
>   if (!info)
>   info = drm_format_info(mode_cmd->pixel_format);
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index 57564318ceea..33b741cc73e8 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -204,6 +204,9 @@ static int framebuffer_check(struct drm_device *dev,
>   unsigned int block_size = info->char_per_block[i];
>   u64 min_pitch = drm_format_info_min_pitch(info, i, width);
>  
> + if (drm_is_afbc(r->modifier[i]))
> + block_size = 0;
> +
>   if (!block_size && (r->modifier[i] == DRM_FORMAT_MOD_LINEAR)) {
>   DRM_DEBUG_KMS("Format requires non-linear modifier for 
> plane %d\n", i);
>   return -EINVAL;
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index 4201dc1f32a5..e20f4d00b0a5 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -21,6 +21,11 @@
>  #include 
>  #include 
>  
> +#define AFBC_HEADER_SIZE 16
> +#define AFBC_TH_LAYOUT_ALIGNMENT 8
> +#define AFBC_SUPERBLOCK_PIXELS   256
> +#define AFBC_SUPERBLOCK_ALIGNMENT128
> +
>  /**
>   * DOC: overview
>   *
> @@ -200,6 +205,40 @@ int drm_gem_fb_lookup(struct drm_device *dev,
>  }
>  EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
>  
> +static int drm_gem_afbc_min_size(struct drm_device *dev,
> +  const struct drm_mode_fb_cmd2 *mode_cmd,
> +  struct drm_afbc *afbc)
> +{
> + u32 n_blocks;
> +
> + if (!drm_afbc_get_superblock_wh(mode_cmd->modifier[0],
> + &afbc->block_width,
> + &afbc->block_height)) {
> + return -EINVAL;
> + }
> +
> + /* tiled header afbc */
> + if (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_TILED) {
> + afbc->block_width *= AFBC_TH_LAYOUT_ALIGNMENT;
> + afbc->block_height *= AFBC_TH_LAYOUT_ALIGNMENT;
> + }
> +
> + afbc->aligned_width = ALIGN(mode_cmd->width, afbc->block_width);
> + afbc->aligned_height = ALIGN(mode_cmd->height, afbc->block_height);
> + afbc->offset = mode_cmd->offsets[0];
> +
> + n_blocks = (afbc->aligned_width * afbc->aligned_height)
> +  / AFBC_SUPERBLOCK_PIXELS;
> + afbc->offset_payload = ALIGN(n_blocks * AFBC_HEADER_SIZE,
> +  afbc->alignment_header);

After check the references in malidp, rockchip and komeda, seems this
afbc->alignment_header is dedicated for komeda only.

This is not true. Per afbc HW spec alignment is essential for
all afbc usage. according to the spec the requiremnt are:

  AFBC1.0/1.1: 64 byte alignment both for header and body buffer.
  AFBC1.2 (tiled header enabled): 4096 alignment.

So this alignement is not a vendor specific value, but afbc feature
requirement, can be determined by afbc modifier.
(malidp and komeda obeys this spec, not sure about Rockchip, but I
think it should be)

But you may see, komeda uses 1024 (not 64) for none-tiled-header afbc,
that's because GPU(MALI) changed this value to 1024 for bus
performance (sorry I don't know the detail), and komeda changed to
1024 to follow.

Back to display alignment, I think we can just follow the spec, use 64
for none-tiled-header, 4096 for tiled-header, but no need to caller to
pass a value.

> +
> + afbc->afbc_size = afbc->offset_payload + n_blocks *
> +   ALIGN(afbc->bpp * AFBC_SUPERBLOCK_PIXELS / 8,
> +   

Re: [PATCH 1/7] drm/amdgpu: move ttm bo->offset to amdgpu_bo

[Christian König]

Am 17.02.20 um 11:18 schrieb Nirmoy Das:

GPU address should belong to driver not in memory management.
This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.

Signed-off-by: Nirmoy Das 
Acked-by: Huang Rui 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 ++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 29 --
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|  1 +
  4 files changed, 44 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e3f16b49e970..04e78f783638 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -917,7 +917,7 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32 
domain,
bo->pin_count++;
  
  		if (max_offset != 0) {

-   u64 domain_start = 
bo->tbo.bdev->man[mem_type].gpu_offset;
+   u64 domain_start = amdgpu_ttm_domain_start(adev, 
mem_type);
WARN_ON_ONCE(max_offset <
 (amdgpu_bo_gpu_offset(bo) - domain_start));
}
@@ -1445,7 +1445,25 @@ u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo)
WARN_ON_ONCE(bo->tbo.mem.mem_type == TTM_PL_VRAM &&
 !(bo->flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS));
  
-	return amdgpu_gmc_sign_extend(bo->tbo.offset);

+   return amdgpu_bo_gpu_offset_no_check(bo);
+}
+
+/**
+ * amdgpu_bo_gpu_offset_no_check - return GPU offset of bo
+ * @bo:amdgpu object for which we query the offset
+ *
+ * Returns:
+ * current GPU offset of the object without raising warnings.
+ */
+u64 amdgpu_bo_gpu_offset_no_check(struct amdgpu_bo *bo)
+{
+   struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+   uint64_t offset;
+
+offset = (bo->tbo.mem.start << PAGE_SHIFT) +
+amdgpu_ttm_domain_start(adev, bo->tbo.mem.mem_type);
+
+   return amdgpu_gmc_sign_extend(offset);
  }
  
  /**

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 36dec51d1ef1..1d86b4c7a1f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -279,6 +279,7 @@ void amdgpu_bo_fence(struct amdgpu_bo *bo, struct dma_fence 
*fence,
 bool shared);
  int amdgpu_bo_sync_wait(struct amdgpu_bo *bo, void *owner, bool intr);
  u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo);
+u64 amdgpu_bo_gpu_offset_no_check(struct amdgpu_bo *bo);
  int amdgpu_bo_validate(struct amdgpu_bo *bo);
  int amdgpu_bo_restore_shadow(struct amdgpu_bo *shadow,
 struct dma_fence **fence);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 3ab46d4647e4..e329a108e760 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -97,7 +97,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
case TTM_PL_TT:
/* GTT memory  */
man->func = &amdgpu_gtt_mgr_func;
-   man->gpu_offset = adev->gmc.gart_start;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
@@ -105,7 +104,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = &amdgpu_vram_mgr_func;
-   man->gpu_offset = adev->gmc.vram_start;
man->flags = TTM_MEMTYPE_FLAG_FIXED |
 TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
@@ -116,7 +114,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
case AMDGPU_PL_OA:
/* On-chip GDS memory*/
man->func = &ttm_bo_manager_func;
-   man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_CMA;
man->available_caching = TTM_PL_FLAG_UNCACHED;
man->default_caching = TTM_PL_FLAG_UNCACHED;
@@ -264,7 +261,7 @@ static uint64_t amdgpu_mm_node_addr(struct 
ttm_buffer_object *bo,
  
  	if (mm_node->start != AMDGPU_BO_INVALID_OFFSET) {

addr = mm_node->start << PAGE_SHIFT;
-   addr += bo->bdev->man[mem->mem_type].gpu_offset;
+   addr += amdgpu_ttm_domain_start(amdgpu_ttm_adev(bo->bdev), 
mem->mem_type);
}
return addr;
  }
@@ -751,6 +748,27 @@ static unsigned long amdgpu_ttm_io_mem_pfn(struct 
ttm_buffer_object *bo,
(offset >> PAGE_SHIFT);
  }
  
+/**

+ * amdgpu_ttm_domain_star

Re: [PATCH 3/7] drm/vmwgfx: don't use ttm bo->offset

[Christian König]

Am 17.02.20 um 11:18 schrieb Nirmoy Das:

Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c   | 2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 --
  4 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 8b71bf6b58ef..a714582bb61c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -258,7 +258,7 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private 
*dev_priv,
ret = ttm_bo_validate(bo, &placement, &ctx);
  
  	/* For some reason we didn't end up at the start of vram */

-   WARN_ON(ret == 0 && bo->offset != 0);
+   WARN_ON(ret == 0 && (bo->mem.start << PAGE_SHIFT) != 0);


You could drop the (<< PAGE_SHIFT) part here.

Apart from that feel free to stick an Acked-by: Christian König 
 on the patch.


Christian.


if (!ret)
vmw_bo_pin_reserved(buf, true);
  
@@ -317,7 +317,7 @@ void vmw_bo_get_guest_ptr(const struct ttm_buffer_object *bo,

  {
if (bo->mem.mem_type == TTM_PL_VRAM) {
ptr->gmrId = SVGA_GMR_FRAMEBUFFER;
-   ptr->offset = bo->offset;
+   ptr->offset = bo->mem.start << PAGE_SHIFT;
} else {
ptr->gmrId = bo->mem.start;
ptr->offset = 0;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 73489a45decb..72c2cf4053df 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -3313,7 +3313,7 @@ static void vmw_apply_relocations(struct vmw_sw_context 
*sw_context)
bo = &reloc->vbo->base;
switch (bo->mem.mem_type) {
case TTM_PL_VRAM:
-   reloc->location->offset += bo->offset;
+   reloc->location->offset += bo->mem.start << PAGE_SHIFT;
reloc->location->gmrId = SVGA_GMR_FRAMEBUFFER;
break;
case VMW_PL_GMR:
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index e5252ef3812f..1cdc445b24c3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -612,7 +612,7 @@ static int vmw_fifo_emit_dummy_legacy_query(struct 
vmw_private *dev_priv,
  
  	if (bo->mem.mem_type == TTM_PL_VRAM) {

cmd->body.guestResult.gmrId = SVGA_GMR_FRAMEBUFFER;
-   cmd->body.guestResult.offset = bo->offset;
+   cmd->body.guestResult.offset = bo->mem.start << PAGE_SHIFT;
} else {
cmd->body.guestResult.gmrId = bo->mem.start;
cmd->body.guestResult.offset = 0;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 3f3b2c7a208a..e7134aebeb81 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -750,7 +750,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = &ttm_bo_manager_func;
-   man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
man->default_caching = TTM_PL_FLAG_CACHED;
@@ -763,7 +762,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
 *  slots as well as the bo size.
 */
man->func = &vmw_gmrid_manager_func;
-   man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_CMA | TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
man->default_caching = TTM_PL_FLAG_CACHED;


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

Re: [PATCH 3/7] drm/vmwgfx: don't use ttm bo->offset

[Nirmoy]

On 2/17/20 12:09 PM, Christian König wrote:

Am 17.02.20 um 11:18 schrieb Nirmoy Das:

Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c    | 2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c   | 2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 --
  4 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c

index 8b71bf6b58ef..a714582bb61c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -258,7 +258,7 @@ int vmw_bo_pin_in_start_of_vram(struct 
vmw_private *dev_priv,

  ret = ttm_bo_validate(bo, &placement, &ctx);
    /* For some reason we didn't end up at the start of vram */
-    WARN_ON(ret == 0 && bo->offset != 0);
+    WARN_ON(ret == 0 && (bo->mem.start << PAGE_SHIFT) != 0);


You could drop the (<< PAGE_SHIFT) part here.


Thanks Christian! I will drop that in next version.
Apart from that feel free to stick an Acked-by: Christian König 
 on the patch.


Christian.



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

Re: [PATCHv4,04/36] drm/gem-fb-helper: Add special version of drm_gem_fb_size_check

[james qian wang (Arm Technology China)]

On Mon, Feb 17, 2020 at 11:55:50AM +0100, Andrzej Pietrasiewicz wrote:
> Hi James,
> 
> Thank you for the review.
> 
> Did you intentionally review patches from the v4 series or you simply
> didn't notice the v5? There are some differences, the most notable one
> is using proper way of subclassing a drm_framebuffer.
> The v5 series was sent on 17th December 2019.

Hi Andrzej:
Sorry, I did the review based pathwork:
https://patchwork.freedesktop.org/series/70889/#rev35
seems it has problem which only have V4.

I will re-do the review for V5 ASAP.

Sorry again.

James.

> Andrzej
> 
> W dniu 17.02.2020 o�09:16, james qian wang (Arm Technology China) pisze:
> > Hi Andrzej:
> > 
> > Really a good idea for introducing this custom size check, it's very
> > useful for some Komeda/malidp format, espcially pitch_multiplier, maybe
> > in future we can add it into into the drm_format_info.
> > 
> > On Fri, Dec 13, 2019 at 04:58:35PM +0100, Andrzej Pietrasiewicz wrote:
> > > The new version accepts a struct describing deviations from standard way 
> > > of
> > > doing the size checks. The caller must provide the respective values.
> > > 
> > > Signed-off-by: Andrzej Pietrasiewicz 
> > > ---
> > >   drivers/gpu/drm/drm_gem_framebuffer_helper.c | 47 
> > >   include/drm/drm_gem_framebuffer_helper.h | 16 +++
> > >   2 files changed, 55 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
> > > b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > > index 787edb9a916b..4201dc1f32a5 100644
> > > --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > > +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > > @@ -201,8 +201,9 @@ int drm_gem_fb_lookup(struct drm_device *dev,
> > >   EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
> > >   /**
> > > - * drm_gem_fb_size_check() - Helper function for use in
> > > - *&drm_mode_config_funcs.fb_create 
> > > implementations
> > > + * drm_gem_fb_size_check_special() - Helper function for use in
> > > + *&drm_mode_config_funcs.fb_create
> > > + *implementations
> > >* @dev: DRM device
> > >* @mode_cmd: Metadata from the userspace framebuffer creation request
> > >*
> > > @@ -212,9 +213,10 @@ EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
> > >* Returns:
> > >* Zero on success or a negative error code on failure.
> > >*/
> > > -int drm_gem_fb_size_check(struct drm_device *dev,
> > > -   const struct drm_mode_fb_cmd2 *mode_cmd,
> > > -   struct drm_gem_object **objs)
> > > +int drm_gem_fb_size_check_special(struct drm_device *dev,
> > 
> > How about name it to drm_gem_fb_custom_size_check()
> > 
> > > +   const struct drm_mode_fb_cmd2 *mode_cmd,
> > > +   const struct drm_size_check *check,
> > > +   struct drm_gem_object **objs)
> > >   {
> > >   const struct drm_format_info *info;
> > >   int i;
> > > @@ -227,10 +229,19 @@ int drm_gem_fb_size_check(struct drm_device *dev,
> > >   unsigned int width = mode_cmd->width / (i ? info->hsub 
> > > : 1);
> > >   unsigned int height = mode_cmd->height / (i ? 
> > > info->vsub : 1);
> > >   unsigned int min_size;
> > > + u32 pitch = mode_cmd->pitches[i];
> > > +
> > > + if (check && check->use_pitch_multiplier)
> > > + if ((pitch * check->pitch_multiplier[i]) %
> > > + check->pitch_modulo)
> > > + return -EINVAL;
> > > - min_size = (height - 1) * mode_cmd->pitches[i]
> > > -  + drm_format_info_min_pitch(info, i, width)
> > > -  + mode_cmd->offsets[i];
> > > + if (check && check->use_min_size)
> > > + min_size = check->min_size[i];
> > > + else
> > > + min_size = (height - 1) * pitch
> > > +  + drm_format_info_min_pitch(info, i, width)
> > > +  + mode_cmd->offsets[i];
> > >   if (objs[i]->size < min_size)
> > >   return -EINVAL;
> > > @@ -239,6 +250,26 @@ int drm_gem_fb_size_check(struct drm_device *dev,
> > >   return 0;
> > >   }
> > > +EXPORT_SYMBOL_GPL(drm_gem_fb_size_check_special);
> > > +
> > > +/**
> > > + * drm_gem_fb_size_check() - Helper function for use in
> > > + *&drm_mode_config_funcs.fb_create 
> > > implementations
> > > + * @dev: DRM device
> > > + * @mode_cmd: Metadata from the userspace framebuffer creation request
> > > + *
> > > + * This function can be used to verify buffer sizes for all planes.
> > > + * It is caller's responsibility to put the objects on failure.
> > > + *
> > > + * Returns:
> > > + * Zero on success or a negative error code on failure.
> > > + */
> > > +int drm_gem_fb_size_check

Re: [RFC 1/9] regmap: Add USB support

[Mark Brown]

On Sun, Feb 16, 2020 at 06:21:09PM +0100, Noralf Trønnes wrote:

> Add support for regmap over USB for use with the Multifunction USB Device.
> Two endpoints IN/OUT are used. Up to 255 regmaps are supported on one USB
> interface. The register index width is always 32-bit, but the register
> value can be 8, 16 or 32 bits wide. LZ4 compression is supported on bulk
> transfers.

This looks like a custom thing for some particular devices rather than a
thing that will work for any USB device?  If that is the case then this
should have a more specific name.

> +++ b/drivers/base/regmap/regmap-usb.c
> @@ -0,0 +1,1026 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Register map access API - USB support

Why is this GPL-2.0-or-later?  The rest of the code is just plain old
GPL-2.0.

Please also make the entire comment a C++ one so things look more
intentional.

> +
> + ktime_t start; /* FIXME: Temporary debug/perf aid */

Add tracepoints, most of your debugging stuff looks like you want to use
tracepoints - you can easily work out time differences with them by
postprocessing the log, they get very fine grained timestamps.

> + mutex_lock(®map_usb_interfaces_lock);
> + list_for_each_entry(entry, ®map_usb_interfaces, link)
> + if (entry->interface == interface) {
> + ruif = entry;
> + ruif->refcount++;
> + goto out_unlock;
> + }
> +

You're missing some { } here.

> +static long mud_drm_throughput(ktime_t begin, ktime_t end, size_t len)
> +{
> + long throughput;
> +
> + throughput = ktime_us_delta(end, begin);
> + throughput = throughput ? (len * 1000) / throughput : 0;
> + throughput = throughput * 1000 / 1024;

Please write normal conditional statements to improve legibility.

> +static int regmap_usb_gather_write(void *context,
> +const void *reg, size_t reg_len,
> +const void *val, size_t val_len)
> +{
> + return regmap_usb_transfer(context, false, reg, (void *)val, val_len);
> +}

Why are we casting away a const here?  If we really need to modify the
raw data that's being transmitted take a copy.

> +static int regmap_usb_write(void *context, const void *data, size_t count)
> +{
> + struct regmap_usb_context *ctx = context;
> + size_t val_len = count - sizeof(u32);
> + void *val;
> + int ret;
> +
> + /* buffer needs to be properly aligned for DMA use */
> + val = kmemdup(data + sizeof(u32), val_len, GFP_KERNEL);
> + if (!val)
> + return -ENOMEM;
> +
> + ret = regmap_usb_gather_write(ctx, data, sizeof(u32), val, val_len);
> + kfree(val);
> +
> + return ret;
> +}

This looks like you just don't support a straight write operation, if
you need to do this emulation push it up the stack.

> + regmap_usb_debugfs_init(map);
> +
> + return map;
> +}
> +EXPORT_SYMBOL(__devm_regmap_init_usb);

No, this needs to be EXPORT_SYMBOL_GPL - the regmap core is and this
isn't going to be useful without those bits of the code anyway.


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

Re: [PATCH 4/7] drm/nouveau: don't use ttm bo->offset

[Christian König]

Am 17.02.20 um 11:18 schrieb Nirmoy Das:

Store ttm bo->offset in struct nouveau_bo instead.

Signed-off-by: Nirmoy Das 


Acked-by: Christian König  for this one and 
patch #5 and #6 in this series.



---
  drivers/gpu/drm/nouveau/dispnv04/crtc.c |  6 +++---
  drivers/gpu/drm/nouveau/dispnv04/disp.c |  2 +-
  drivers/gpu/drm/nouveau/dispnv04/overlay.c  |  6 +++---
  drivers/gpu/drm/nouveau/dispnv50/base507c.c |  2 +-
  drivers/gpu/drm/nouveau/dispnv50/core507d.c |  2 +-
  drivers/gpu/drm/nouveau/dispnv50/ovly507e.c |  2 +-
  drivers/gpu/drm/nouveau/dispnv50/wndw.c |  2 +-
  drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c |  2 +-
  drivers/gpu/drm/nouveau/nouveau_abi16.c |  8 
  drivers/gpu/drm/nouveau/nouveau_bo.c|  1 +
  drivers/gpu/drm/nouveau/nouveau_bo.h|  3 +++
  drivers/gpu/drm/nouveau/nouveau_chan.c  |  2 +-
  drivers/gpu/drm/nouveau/nouveau_dmem.c  |  2 +-
  drivers/gpu/drm/nouveau/nouveau_fbcon.c |  2 +-
  drivers/gpu/drm/nouveau/nouveau_gem.c   | 10 +-
  15 files changed, 28 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 1f08de4241e0..d06a93f2b38a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -845,7 +845,7 @@ nv04_crtc_do_mode_set_base(struct drm_crtc *crtc,
fb = nouveau_framebuffer(crtc->primary->fb);
}
  
-	nv_crtc->fb.offset = fb->nvbo->bo.offset;

+   nv_crtc->fb.offset = fb->nvbo->offset;
  
  	if (nv_crtc->lut.depth != drm_fb->format->depth) {

nv_crtc->lut.depth = drm_fb->format->depth;
@@ -1013,7 +1013,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct 
drm_file *file_priv,
nv04_cursor_upload(dev, cursor, nv_crtc->cursor.nvbo);
  
  	nouveau_bo_unmap(cursor);

-   nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->bo.offset;
+   nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->offset;
nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset);
nv_crtc->cursor.show(nv_crtc, true);
  out:
@@ -1191,7 +1191,7 @@ nv04_crtc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
/* Initialize a page flip struct */
*s = (struct nv04_page_flip_state)
{ { }, event, crtc, fb->format->cpp[0] * 8, fb->pitches[0],
- new_bo->bo.offset };
+ new_bo->offset };
  
  	/* Keep vblanks on during flip, for the target crtc of this flip */

drm_crtc_vblank_get(crtc);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c 
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 44ee82d0c9b6..89a4ddfcc55f 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -151,7 +151,7 @@ nv04_display_init(struct drm_device *dev, bool resume, bool 
runtime)
continue;
  
  		if (nv_crtc->cursor.set_offset)

-   nv_crtc->cursor.set_offset(nv_crtc, 
nv_crtc->cursor.nvbo->bo.offset);
+   nv_crtc->cursor.set_offset(nv_crtc, 
nv_crtc->cursor.nvbo->offset);
nv_crtc->cursor.set_pos(nv_crtc, nv_crtc->cursor_saved_x,
 nv_crtc->cursor_saved_y);
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c 
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index a3a0a73ae8ab..9529bd9053e7 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@ -150,7 +150,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
nvif_mask(dev, NV_PCRTC_ENGINE_CTRL + soff2, NV_CRTC_FSEL_OVERLAY, 0);
  
  	nvif_wr32(dev, NV_PVIDEO_BASE(flip), 0);

-   nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->bo.offset);
+   nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->offset);
nvif_wr32(dev, NV_PVIDEO_SIZE_IN(flip), src_h << 16 | src_w);
nvif_wr32(dev, NV_PVIDEO_POINT_IN(flip), src_y << 16 | src_x);
nvif_wr32(dev, NV_PVIDEO_DS_DX(flip), (src_w << 20) / crtc_w);
@@ -172,7 +172,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
if (format & NV_PVIDEO_FORMAT_PLANAR) {
nvif_wr32(dev, NV_PVIDEO_UVPLANE_BASE(flip), 0);
nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
-   nv_fb->nvbo->bo.offset + fb->offsets[1]);
+   nv_fb->nvbo->offset + fb->offsets[1]);
}
nvif_wr32(dev, NV_PVIDEO_FORMAT(flip), format | fb->pitches[0]);
nvif_wr32(dev, NV_PVIDEO_STOP, 0);
@@ -396,7 +396,7 @@ nv04_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
  
  	for (i = 0; i < 2; i++) {

nvif_wr32(dev, NV_PVIDEO_BUFF0_START_ADDRESS + 4 * i,
- nv_fb->nvbo->bo.offset);
+ nv_fb->nvbo->offset);
nvif_wr32(dev, NV_PVIDEO_BUFF0_PITCH_LENGTH + 4 

Re: [RFC 6/9] regmap: Speed up _regmap_raw_write_impl() for large buffers

[Mark Brown]

On Sun, Feb 16, 2020 at 06:21:14PM +0100, Noralf Trønnes wrote:

> When writing a 3MB buffer the unwritable check in _regmap_raw_write_impl()
> adds a ~20ms overhead on a Raspberry Pi 4.
> Amend this by avoiding the check if it's not necessary.

This is a generic optimization, why is it mixed in with the rest of this
series?  There is no dependency either way :(

>   /* Check for unwritable registers before we start */
> - for (i = 0; i < val_len / map->format.val_bytes; i++)
> - if (!regmap_writeable(map,
> -  reg + regmap_get_offset(map, i)))
> - return -EINVAL;
> + if (map->max_register || map->writeable_reg || map->wr_table) {
> + for (i = 0; i < val_len / map->format.val_bytes; i++)
> + if (!regmap_writeable(map,
> +   reg + regmap_get_offset(map, i)))
> + return -EINVAL;
> + }

This is going to break if there is any change to the implementation of
regmap_writeable().  The code should at least be next to that if not
actually shared so that this doesn't happen.  I'd suggest implementing a
function regmap_writeable_range() and then making regmap_writeable()
call that.


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

Re: [PATCH 5/7] drm/qxl: don't use ttm bo->offset

[Gerd Hoffmann]

On Mon, Feb 17, 2020 at 11:18:39AM +0100, Nirmoy Das wrote:
> This patch also removes slot->gpu_offset which is not required as
> VRAM and PRIV slot are in separate PCI bar

Well, gpu_offset is still in struct qxlslot ...

Other than that the patch looks fine, and this is minor enough
that I'll happily

Acked-by: Gerd Hoffmann 

cheers,
  Gerd

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

Re: [PATCH 6/7] drm/bochs: don't use ttm bo->offset

[Gerd Hoffmann]

On Mon, Feb 17, 2020 at 11:18:40AM +0100, Nirmoy Das wrote:
> Calculate GPU offset within bochs driver itself without depending on
> bo->offset
> 
> Signed-off-by: Nirmoy Das 
> ---
>  drivers/gpu/drm/bochs/bochs_kms.c | 3 ++-
>  drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 8066d7d370d5..852ec7910d84 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -38,7 +38,8 @@ static void bochs_plane_update(struct bochs_device *bochs,
>state->crtc_x,
>state->crtc_y,
>state->fb->pitches[0],
> -  state->fb->offsets[0] + gbo->bo.offset);
> +  state->fb->offsets[0] +
> +  (gbo->bo.mem.start << PAGE_SHIFT));

I'd suggest to use drm_gem_vram_offset() here ...

> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index 92a11bb42365..e7ef4cd8116d 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -214,7 +214,7 @@ s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo)
>  {
>   if (WARN_ON_ONCE(!gbo->pin_count))
>   return (s64)-ENODEV;
> - return gbo->bo.offset;
> + return gbo->bo.mem.start << PAGE_SHIFT;

... and move this to a separate patch.  The vram helpers are used by
more drivers than just bochs.

cheers,
  Gerd

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

Re: [PATCH 6/7] drm/bochs: don't use ttm bo->offset

[Nirmoy]

On 2/17/20 1:41 PM, Gerd Hoffmann wrote:

On Mon, Feb 17, 2020 at 11:18:40AM +0100, Nirmoy Das wrote:

Calculate GPU offset within bochs driver itself without depending on
bo->offset

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/bochs/bochs_kms.c | 3 ++-
  drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
  2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 8066d7d370d5..852ec7910d84 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -38,7 +38,8 @@ static void bochs_plane_update(struct bochs_device *bochs,
 state->crtc_x,
 state->crtc_y,
 state->fb->pitches[0],
-state->fb->offsets[0] + gbo->bo.offset);
+state->fb->offsets[0] +
+(gbo->bo.mem.start << PAGE_SHIFT));

I'd suggest to use drm_gem_vram_offset() here ...


diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 92a11bb42365..e7ef4cd8116d 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -214,7 +214,7 @@ s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo)
  {
if (WARN_ON_ONCE(!gbo->pin_count))
return (s64)-ENODEV;
-   return gbo->bo.offset;
+   return gbo->bo.mem.start << PAGE_SHIFT;

... and move this to a separate patch.  The vram helpers are used by
more drivers than just bochs.


Thanks for reviewing Gerd, will send next version with your suggestions 
applied.



Regards,

Nirmoy



cheers,
   Gerd


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

[Bug 206475] amdgpu under load drop signal to monitor until hard reset

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=206475

Marco (rodomar...@protonmail.com) changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|OBSOLETE|---

--- Comment #6 from Marco (rodomar...@protonmail.com) ---
(In reply to Marco from comment #5)
> It seems that the problem was insufficient cooling, since the same happened
> on a Windows VM.

Instead I was wrong, tested Furmark on two different driver sets on W10 bare
metal, no crashes for an hour (furmark on VM lasted for 30 seconds).

This is a firmware/software problem. Please fix it.

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

Re: [RFC 0/9] Regmap over USB for Multifunction USB Device (gpio, display, ...)

[Noralf Trønnes]

Den 17.02.2020 11.32, skrev Neil Armstrong:
> Hi,
> 
> On 16/02/2020 18:21, Noralf Trønnes wrote:
>> Hi,
>>
>> A while back I had the idea to turn a Raspberry Pi Zero into a $5
>> USB to HDMI/SDTV/DSI/DPI display adapter.
>>
>> Thinking about how to represent the display to the driver I realised
>> that hardware use registers as API. And Linux does have a generic
>> register abstraction: regmap. Furthermore this means that if I can do a
>> regmap over USB implementation, it will be easy to do other functions
>> like gpio, adc and others. After a few iterations trying to understand
>> the USB subsystem and satisfying driver requirements, I now have
>> something that looks promising.
>>
>> I'm sending out an early version hoping to get feedback especially on
>> the core parts that handles regmap and interrupts.
>>
>> Overview:
>>
>>   USB Host  : USB Device
>> :
>> --  :  --
>> --  | mfd: mud   |  :  | f_mud  |  --
>> | Driver |  --  :  ||  | Driver |
>> --  | regmap-usb |  :  | (mud_regmap)   |  --
>> --  :  --
>>
> 
> The idea is really like ARA's greybus, but much simpler !
> Anyway nice idea, do you have good performance over USB2 and
> RPi's awful DWC2 gagdet controller ?
> 

Not as good as I was hoping for. If I disable compression I'm getting 5
fps for a 1.5MB framebuffer (7800 kB/s):

$ modetest -M mud_drm -s 35:1024x768@RG16 -v
setting mode 1024x768-60.00Hz@RG16 on connectors 35, crtc 33
freq: 5.07Hz

When I tried reading I discovered that it was almost 3 times faster than
writing.

The zero gadget (loop testing) confirmed my findings:

Device:
$ sudo modprobe g_zero
[   44.221890] zero gadget: Gadget Zero, version: Cinco de Mayo 2008
[   44.221906] zero gadget: zero ready
[   60.751451] zero gadget: high-speed config #3: source/sink

Host:

$ sudo ~/testusb -a -t  -g 64 -s 16384
/dev/bus/usb/001/010 test 27,  107.230669 secs  -> 1000 / 107 =  9MB/s
/dev/bus/usb/001/010 test 28,   37.791292 secs  -> 1000 / 37  = 27MB/s
[73983.796552] usbtest 1-1.3:3.0: TEST 27: bulk write 1000Mbytes
[74205.060204] usbtest 1-1.3:3.0: TEST 28: bulk read 1000Mbytes

$ sudo ~/testusb -a -t  -g 64 -s 16384
/dev/bus/usb/001/010 test 5,  107.421535 secs
/dev/bus/usb/001/010 test 6,   38.189712 secs
[74893.204170] usbtest 1-1.3:3.0: TEST 5:  write 1000 sglists 64 entries
of 16384 bytes
[75012.59] usbtest 1-1.3:3.0: TEST 6:  read 1000 sglists 64 entries
of 16384 bytes


I have tried Raspberry Pi1 and Pi4 as host (2 different controllers)
and Pi Zero and Beaglebone Black as device, getting similar result.

I found this post having the same issue:

Re: Asymmetric speed results with testusb/usbtest/g_zero
https://www.spinics.net/lists/linux-usb/msg100588.html

I haven't got a usb analyzer, but adding printk to
dwc2_assign_and_init_hc() showed that IN interrupts were 2-3 ms apart
but OUT interrupts were ~8 ms apart.

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

Re: [PATCH] drm/edid: temporary workaround to pass HDMI 2.0 compliance HF1-13

[Ville Syrjälä]

On Tue, Feb 18, 2020 at 01:41:39AM +0800, Lee Shawn C wrote:
> Test case HF1-13 for HDMI 2.0 compliance would ask DUT to downgrade
> output resolution to 720x480 or 720x576 (lower than 3.4Gbps).
> And check scrambling feature was disabled as well.
> 
> But QD980 report it can support low rate scrambling. The vendor
> specific data block byte[6] was 0x88. If driver enabled scrambling
> rely on this info. Then HF1-13 would not get pass because DUT have
> to disable scrambling to run this case.

Sounds like a broken test to me.

> 
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Cc: Clint Taylor 
> Cc: Cooper Chiou 
> Signed-off-by: Lee Shawn C 
> ---
>  drivers/gpu/drm/drm_edid.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 99769d6c9f84..0b4badc20c35 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -85,6 +85,8 @@
>  #define EDID_QUIRK_FORCE_10BPC   (1 << 11)
>  /* Non desktop display (i.e. HMD) */
>  #define EDID_QUIRK_NON_DESKTOP   (1 << 12)
> +/* Do not enable low rates scrambling */
> +#define EDID_QUIRK_DISABLE_LOW_RATE_SCRAMBLING   (1 << 13)
>  
>  struct detailed_mode_closure {
>   struct drm_connector *connector;
> @@ -214,6 +216,9 @@ static const struct edid_quirk {
>  
>   /* OSVR HDK and HDK2 VR Headsets */
>   { "SVR", 0x1019, EDID_QUIRK_NON_DESKTOP },
> +
> + /* Quantumdata 980 test platform */
> + { "QDI", 0x03D4, EDID_QUIRK_DISABLE_LOW_RATE_SCRAMBLING },
>  };
>  
>  /*
> @@ -4710,10 +4715,11 @@ static void drm_parse_ycbcr420_deep_color_info(struct 
> drm_connector *connector,
>  }
>  
>  static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
> -  const u8 *hf_vsdb)
> +  const u8 *hf_vsdb, const struct edid *edid)
>  {
>   struct drm_display_info *display = &connector->display_info;
>   struct drm_hdmi_info *hdmi = &display->hdmi;
> + u32 quirks = edid_get_quirks(edid);
>  
>   display->has_hdmi_infoframe = true;
>  
> @@ -4747,7 +4753,8 @@ static void drm_parse_hdmi_forum_vsdb(struct 
> drm_connector *connector,
>   scdc->scrambling.supported = true;
>  
>   /* Few sinks support scrambling for clocks < 340M */
> - if ((hf_vsdb[6] & 0x8))
> + if ((hf_vsdb[6] & 0x8) &&
> + !(quirks & EDID_QUIRK_DISABLE_LOW_RATE_SCRAMBLING))
>   scdc->scrambling.low_rates = true;
>   }
>   }
> @@ -4870,7 +4877,7 @@ static void drm_parse_cea_ext(struct drm_connector 
> *connector,
>   if (cea_db_is_hdmi_vsdb(db))
>   drm_parse_hdmi_vsdb_video(connector, db);
>   if (cea_db_is_hdmi_forum_vsdb(db))
> - drm_parse_hdmi_forum_vsdb(connector, db);
> + drm_parse_hdmi_forum_vsdb(connector, db, edid);
>   if (cea_db_is_y420cmdb(db))
>   drm_parse_y420cmdb_bitmap(connector, db);
>   if (cea_db_is_vcdb(db))
> -- 
> 2.17.1

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/8] drm/bochs: use drm_gem_vram_offset to get bo offset

[Christian König]

Am 17.02.20 um 16:04 schrieb Nirmoy Das:

Switch over to GEM VRAM's implementation to retrieve bo->offset

Signed-off-by: Nirmoy Das 


Acked-by: Christian König 


---
  drivers/gpu/drm/bochs/bochs_kms.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 8066d7d370d5..b8e1079f077e 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -38,7 +38,7 @@ static void bochs_plane_update(struct bochs_device *bochs,
 state->crtc_x,
 state->crtc_y,
 state->fb->pitches[0],
-state->fb->offsets[0] + gbo->bo.offset);
+state->fb->offsets[0] + drm_gem_vram_offset(gbo));
bochs_hw_setformat(bochs, state->fb->format);
  }
  


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

RFC: Unpinned DMA-buf handling

[Christian König]

Hi everyone,

hopefully the last iteration of those patches.

For now I've addressed the issue of unmapping imported BOs from the amdgpu page 
tables immediately by locking the page tables in place.

For HMM handling we are getting the ability to invalidate BOs without locking 
the VM anyway, so this last TODO will probably go away rather soon.

Place comment,
Christian.


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

[PATCH 1/5] dma-buf: add dynamic DMA-buf handling v14

[Christian König]

On the exporter side we add optional explicit pinning callbacks. Which are
called when the importer doesn't implement dynamic handling, move notification
or need the DMA-buf locked in place for its use case.

On the importer side we add an optional move_notify callback. This callback is
used by the exporter to inform the importers that their mappings should be
destroyed as soon as possible.

This allows the exporter to provide the mappings without the need to pin
the backing store.

v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
use new attach_info structure to set the callback
v4: use importer_priv field instead of mangling exporter priv.
v5: drop invalidation_supported flag
v6: squash together with pin/unpin changes
v7: pin/unpin takes an attachment now
v8: nuke dma_buf_attachment_(map|unmap)_locked,
everything is now handled backward compatible
v9: always cache when export/importer don't agree on dynamic handling
v10: minimal style cleanup
v11: drop automatically re-entry avoidance
v12: rename callback to move_notify
v13: add might_lock in appropriate places
v14: rebase on separated locking change

Signed-off-by: Christian König 
---
 drivers/dma-buf/dma-buf.c   | 106 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c |   6 +-
 include/linux/dma-buf.h |  78 --
 3 files changed, 170 insertions(+), 20 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d377b4ca66bf..ce293cee76ed 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -529,6 +529,10 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
exp_info->ops->dynamic_mapping))
return ERR_PTR(-EINVAL);
 
+   if (WARN_ON(!exp_info->ops->dynamic_mapping &&
+   (exp_info->ops->pin || exp_info->ops->unpin)))
+   return ERR_PTR(-EINVAL);
+
if (!try_module_get(exp_info->owner))
return ERR_PTR(-ENOENT);
 
@@ -653,7 +657,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
  * calls attach() of dma_buf_ops to allow device-specific attach functionality
  * @dmabuf:[in]buffer to attach device to.
  * @dev:   [in]device to be attached.
- * @dynamic_mapping:   [in]calling convention for map/unmap
+ * @importer_ops   [in]importer operations for the attachment
+ * @importer_priv  [in]importer private pointer for the attachment
  *
  * Returns struct dma_buf_attachment pointer for this attachment. Attachments
  * must be cleaned up by calling dma_buf_detach().
@@ -669,7 +674,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
  */
 struct dma_buf_attachment *
 dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
-  bool dynamic_mapping)
+  const struct dma_buf_attach_ops *importer_ops,
+  void *importer_priv)
 {
struct dma_buf_attachment *attach;
int ret;
@@ -683,7 +689,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,
 
attach->dev = dev;
attach->dmabuf = dmabuf;
-   attach->dynamic_mapping = dynamic_mapping;
+   attach->importer_ops = importer_ops;
+   attach->importer_priv = importer_priv;
 
if (dmabuf->ops->attach) {
ret = dmabuf->ops->attach(dmabuf, attach);
@@ -702,15 +709,19 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,
dma_buf_is_dynamic(dmabuf)) {
struct sg_table *sgt;
 
-   if (dma_buf_is_dynamic(attach->dmabuf))
+   if (dma_buf_is_dynamic(attach->dmabuf)) {
dma_resv_lock(attach->dmabuf->resv, NULL);
+   ret = dma_buf_pin(attach);
+   if (ret)
+   goto err_unlock;
+   }
 
sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
if (!sgt)
sgt = ERR_PTR(-ENOMEM);
if (IS_ERR(sgt)) {
ret = PTR_ERR(sgt);
-   goto err_unlock;
+   goto err_unpin;
}
if (dma_buf_is_dynamic(attach->dmabuf))
dma_resv_unlock(attach->dmabuf->resv);
@@ -724,6 +735,10 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,
kfree(attach);
return ERR_PTR(ret);
 
+err_unpin:
+   if (dma_buf_is_dynamic(attach->dmabuf))
+   dma_buf_unpin(attach);
+
 err_unlock:
if (dma_buf_is_dynamic(attach->dmabuf))
dma_resv_unlock(attach->dmabuf->resv);
@@ -744,7 +759,7 @@ EXPORT_SYMBOL_GPL(dma_buf_dynamic_attach);
 struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,

[PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2

[Christian König]

Implement the importer side of unpinned DMA-buf handling.

v2: update page tables immediately

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |  6 ++
 2 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 770baba621b3..48de7624d49c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -453,7 +453,71 @@ amdgpu_dma_buf_create_obj(struct drm_device *dev, struct 
dma_buf *dma_buf)
return ERR_PTR(ret);
 }
 
+/**
+ * amdgpu_dma_buf_move_notify - &attach.move_notify implementation
+ *
+ * @attach: the DMA-buf attachment
+ *
+ * Invalidate the DMA-buf attachment, making sure that the we re-create the
+ * mapping before the next use.
+ */
+static void
+amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
+{
+   struct drm_gem_object *obj = attach->importer_priv;
+   struct ww_acquire_ctx *ticket = dma_resv_locking_ctx(obj->resv);
+   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+   struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+   struct ttm_operation_ctx ctx = { false, false };
+   struct ttm_placement placement = {};
+   struct amdgpu_vm_bo_base *bo_base;
+   int r;
+
+   if (bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
+   return;
+
+   r = ttm_bo_validate(&bo->tbo, &placement, &ctx);
+   if (r) {
+   DRM_ERROR("Failed to invalidate DMA-buf import (%d))\n", r);
+   return;
+   }
+
+   for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
+   struct amdgpu_vm *vm = bo_base->vm;
+   struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
+
+   if (ticket) {
+   /* When we get an error here it means that somebody
+* else is holding the VM lock and updating page tables
+* So we can just continue here.
+*/
+   r = dma_resv_lock(resv, ticket);
+   if (r)
+   continue;
+
+   } else {
+   /* TODO: This is more problematic and we actually need
+* to allow page tables updates without holding the
+* lock.
+*/
+   if (!dma_resv_trylock(resv))
+   continue;
+   }
+
+   r = amdgpu_vm_clear_freed(adev, vm, NULL);
+   if (!r)
+   r = amdgpu_vm_handle_moved(adev, vm);
+
+   if (r && r != -EBUSY)
+   DRM_ERROR("Failed to invalidate VM page tables (%d))\n",
+ r);
+
+   dma_resv_unlock(resv);
+   }
+}
+
 static const struct dma_buf_attach_ops amdgpu_dma_buf_attach_ops = {
+   .move_notify = amdgpu_dma_buf_move_notify
 };
 
 /**
@@ -489,7 +553,7 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct 
drm_device *dev,
return obj;
 
attach = dma_buf_dynamic_attach(dma_buf, dev->dev,
-   &amdgpu_dma_buf_attach_ops, NULL);
+   &amdgpu_dma_buf_attach_ops, obj);
if (IS_ERR(attach)) {
drm_gem_object_put(obj);
return ERR_CAST(attach);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 8ae260822908..8c480c898b0d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -926,6 +926,9 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32 
domain,
return 0;
}
 
+   if (bo->tbo.base.import_attach)
+   dma_buf_pin(bo->tbo.base.import_attach);
+
bo->flags |= AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS;
/* force to pin into visible video ram */
if (!(bo->flags & AMDGPU_GEM_CREATE_NO_CPU_ACCESS))
@@ -1009,6 +1012,9 @@ int amdgpu_bo_unpin(struct amdgpu_bo *bo)
 
amdgpu_bo_subtract_pin_size(bo);
 
+   if (bo->tbo.base.import_attach)
+   dma_buf_unpin(bo->tbo.base.import_attach);
+
for (i = 0; i < bo->placement.num_placement; i++) {
bo->placements[i].lpfn = 0;
bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT;
-- 
2.17.1

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

[PATCH 2/5] drm/ttm: remove the backing store if no placement is given

[Christian König]

Pipeline removal of the BOs backing store when no placement is given
during validation.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 229205e499db..a56cb2a2b4ad 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1225,6 +1225,18 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
uint32_t new_flags;
 
dma_resv_assert_held(bo->base.resv);
+
+   /*
+* Remove the backing store if no placement is given.
+*/
+   if (!placement->num_placement && !placement->num_busy_placement) {
+   ret = ttm_bo_pipeline_gutting(bo);
+   if (ret)
+   return ret;
+
+   return ttm_tt_create(bo, false);
+   }
+
/*
 * Check whether we need to move buffer.
 */
-- 
2.17.1

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

[PATCH 3/5] drm/amdgpu: use allowed_domains for exported DMA-bufs

[Christian König]

Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 80ba6dfc54e2..d938d458e22d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -417,7 +418,9 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
/* Don't move this buffer if we have depleted our allowance
 * to move it. Don't move anything if the threshold is zero.
 */
-   if (p->bytes_moved < p->bytes_moved_threshold) {
+   if (p->bytes_moved < p->bytes_moved_threshold &&
+   (!bo->tbo.base.dma_buf ||
+   list_empty(&bo->tbo.base.dma_buf->attachments))) {
if (!amdgpu_gmc_vram_full_visible(&adev->gmc) &&
(bo->flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)) {
/* And don't move a CPU_ACCESS_REQUIRED BO to limited
-- 
2.17.1

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

[PATCH 4/5] drm/amdgpu: add amdgpu_dma_buf_pin/unpin v2

[Christian König]

This implements the exporter side of unpinned DMA-buf handling.

v2: fix minor coding style issues

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 53 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |  5 ++
 2 files changed, 51 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index b2ca78b6abce..770baba621b3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -222,6 +222,37 @@ static void amdgpu_dma_buf_detach(struct dma_buf *dmabuf,
bo->prime_shared_count--;
 }
 
+/**
+ * amdgpu_dma_buf_pin - &dma_buf_ops.pin implementation
+ *
+ * @attach: attachment to pin down
+ *
+ * Pin the BO which is backing the DMA-buf so that it can't move any more.
+ */
+static int amdgpu_dma_buf_pin(struct dma_buf_attachment *attach)
+{
+   struct drm_gem_object *obj = attach->dmabuf->priv;
+   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+   /* pin buffer into GTT */
+   return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
+}
+
+/**
+ * amdgpu_dma_buf_unpin - &dma_buf_ops.unpin implementation
+ *
+ * @attach: attachment to unpin
+ *
+ * Unpin a previously pinned BO to make it movable again.
+ */
+static void amdgpu_dma_buf_unpin(struct dma_buf_attachment *attach)
+{
+   struct drm_gem_object *obj = attach->dmabuf->priv;
+   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+   amdgpu_bo_unpin(bo);
+}
+
 /**
  * amdgpu_dma_buf_map - &dma_buf_ops.map_dma_buf implementation
  * @attach: DMA-buf attachment
@@ -244,9 +275,19 @@ static struct sg_table *amdgpu_dma_buf_map(struct 
dma_buf_attachment *attach,
struct sg_table *sgt;
long r;
 
-   r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
-   if (r)
-   return ERR_PTR(r);
+   if (!bo->pin_count) {
+   /* move buffer into GTT */
+   struct ttm_operation_ctx ctx = { false, false };
+
+   amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
+   r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
+   if (r)
+   return ERR_PTR(r);
+
+   } else if (!(amdgpu_mem_type_to_domain(bo->tbo.mem.mem_type) &
+AMDGPU_GEM_DOMAIN_GTT)) {
+   return ERR_PTR(-EBUSY);
+   }
 
sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages, bo->tbo.num_pages);
if (IS_ERR(sgt))
@@ -277,13 +318,9 @@ static void amdgpu_dma_buf_unmap(struct dma_buf_attachment 
*attach,
 struct sg_table *sgt,
 enum dma_data_direction dir)
 {
-   struct drm_gem_object *obj = attach->dmabuf->priv;
-   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
-
dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
sg_free_table(sgt);
kfree(sgt);
-   amdgpu_bo_unpin(bo);
 }
 
 /**
@@ -330,6 +367,8 @@ const struct dma_buf_ops amdgpu_dmabuf_ops = {
.dynamic_mapping = true,
.attach = amdgpu_dma_buf_attach,
.detach = amdgpu_dma_buf_detach,
+   .pin = amdgpu_dma_buf_pin,
+   .unpin = amdgpu_dma_buf_unpin,
.map_dma_buf = amdgpu_dma_buf_map,
.unmap_dma_buf = amdgpu_dma_buf_unmap,
.release = drm_gem_dmabuf_release,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 6f60a581e3ba..8ae260822908 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -31,6 +31,7 @@
  */
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1274,6 +1275,10 @@ void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
 
amdgpu_bo_kunmap(abo);
 
+   if (abo->tbo.base.dma_buf && !abo->tbo.base.import_attach &&
+   bo->mem.mem_type != TTM_PL_SYSTEM)
+   dma_buf_move_notify(abo->tbo.base.dma_buf);
+
/* remember the eviction */
if (evict)
atomic64_inc(&adev->num_evictions);
-- 
2.17.1

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

Re: [PATCH 1/5] dma-buf: add dynamic DMA-buf handling v14

[Christian König]

Please ignore this one, I've send out the wrong version without Daniels 
latest comment nit picks fixed.


The interesting one in this series is the last patch.

Regards,
Christian.

Am 17.02.20 um 16:45 schrieb Christian König:

On the exporter side we add optional explicit pinning callbacks. Which are
called when the importer doesn't implement dynamic handling, move notification
or need the DMA-buf locked in place for its use case.

On the importer side we add an optional move_notify callback. This callback is
used by the exporter to inform the importers that their mappings should be
destroyed as soon as possible.

This allows the exporter to provide the mappings without the need to pin
the backing store.

v2: don't try to invalidate mappings when the callback is NULL,
 lock the reservation obj while using the attachments,
 add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
 use new attach_info structure to set the callback
v4: use importer_priv field instead of mangling exporter priv.
v5: drop invalidation_supported flag
v6: squash together with pin/unpin changes
v7: pin/unpin takes an attachment now
v8: nuke dma_buf_attachment_(map|unmap)_locked,
 everything is now handled backward compatible
v9: always cache when export/importer don't agree on dynamic handling
v10: minimal style cleanup
v11: drop automatically re-entry avoidance
v12: rename callback to move_notify
v13: add might_lock in appropriate places
v14: rebase on separated locking change

Signed-off-by: Christian König 
---
  drivers/dma-buf/dma-buf.c   | 106 ++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c |   6 +-
  include/linux/dma-buf.h |  78 --
  3 files changed, 170 insertions(+), 20 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d377b4ca66bf..ce293cee76ed 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -529,6 +529,10 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
exp_info->ops->dynamic_mapping))
return ERR_PTR(-EINVAL);
  
+	if (WARN_ON(!exp_info->ops->dynamic_mapping &&

+   (exp_info->ops->pin || exp_info->ops->unpin)))
+   return ERR_PTR(-EINVAL);
+
if (!try_module_get(exp_info->owner))
return ERR_PTR(-ENOENT);
  
@@ -653,7 +657,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);

   * calls attach() of dma_buf_ops to allow device-specific attach functionality
   * @dmabuf:   [in]buffer to attach device to.
   * @dev:  [in]device to be attached.
- * @dynamic_mapping:   [in]calling convention for map/unmap
+ * @importer_ops   [in]importer operations for the attachment
+ * @importer_priv  [in]importer private pointer for the attachment
   *
   * Returns struct dma_buf_attachment pointer for this attachment. Attachments
   * must be cleaned up by calling dma_buf_detach().
@@ -669,7 +674,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
   */
  struct dma_buf_attachment *
  dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
-  bool dynamic_mapping)
+  const struct dma_buf_attach_ops *importer_ops,
+  void *importer_priv)
  {
struct dma_buf_attachment *attach;
int ret;
@@ -683,7 +689,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,
  
  	attach->dev = dev;

attach->dmabuf = dmabuf;
-   attach->dynamic_mapping = dynamic_mapping;
+   attach->importer_ops = importer_ops;
+   attach->importer_priv = importer_priv;
  
  	if (dmabuf->ops->attach) {

ret = dmabuf->ops->attach(dmabuf, attach);
@@ -702,15 +709,19 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,
dma_buf_is_dynamic(dmabuf)) {
struct sg_table *sgt;
  
-		if (dma_buf_is_dynamic(attach->dmabuf))

+   if (dma_buf_is_dynamic(attach->dmabuf)) {
dma_resv_lock(attach->dmabuf->resv, NULL);
+   ret = dma_buf_pin(attach);
+   if (ret)
+   goto err_unlock;
+   }
  
  		sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);

if (!sgt)
sgt = ERR_PTR(-ENOMEM);
if (IS_ERR(sgt)) {
ret = PTR_ERR(sgt);
-   goto err_unlock;
+   goto err_unpin;
}
if (dma_buf_is_dynamic(attach->dmabuf))
dma_resv_unlock(attach->dmabuf->resv);
@@ -724,6 +735,10 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,
kfree(attach);
return ERR_PTR(ret);
  
+err_unpin:

+   if (dma_buf_is_dynamic(attach->dmabuf))
+   dma_buf_unpin(attach);
+
  err_unlock:
if (dma_b

Re: [PATCH 4/8] drm/nouveau: don't use ttm bo->offset

[Alex Deucher]

On Mon, Feb 17, 2020 at 10:02 AM Nirmoy Das  wrote:
>
> Store ttm bo->offset in struct nouveau_bo instead.
>
> Signed-off-by: Nirmoy Das 
> Christian König 

Missing Acked or Reviewed prefix for Christian.

Alex

> ---
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c |  6 +++---
>  drivers/gpu/drm/nouveau/dispnv04/disp.c |  2 +-
>  drivers/gpu/drm/nouveau/dispnv04/overlay.c  |  6 +++---
>  drivers/gpu/drm/nouveau/dispnv50/base507c.c |  2 +-
>  drivers/gpu/drm/nouveau/dispnv50/core507d.c |  2 +-
>  drivers/gpu/drm/nouveau/dispnv50/ovly507e.c |  2 +-
>  drivers/gpu/drm/nouveau/dispnv50/wndw.c |  2 +-
>  drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_abi16.c |  8 
>  drivers/gpu/drm/nouveau/nouveau_bo.c|  1 +
>  drivers/gpu/drm/nouveau/nouveau_bo.h|  3 +++
>  drivers/gpu/drm/nouveau/nouveau_chan.c  |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_dmem.c  |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_gem.c   | 10 +-
>  15 files changed, 28 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index 1f08de4241e0..d06a93f2b38a 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -845,7 +845,7 @@ nv04_crtc_do_mode_set_base(struct drm_crtc *crtc,
> fb = nouveau_framebuffer(crtc->primary->fb);
> }
>
> -   nv_crtc->fb.offset = fb->nvbo->bo.offset;
> +   nv_crtc->fb.offset = fb->nvbo->offset;
>
> if (nv_crtc->lut.depth != drm_fb->format->depth) {
> nv_crtc->lut.depth = drm_fb->format->depth;
> @@ -1013,7 +1013,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct 
> drm_file *file_priv,
> nv04_cursor_upload(dev, cursor, nv_crtc->cursor.nvbo);
>
> nouveau_bo_unmap(cursor);
> -   nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->bo.offset;
> +   nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->offset;
> nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset);
> nv_crtc->cursor.show(nv_crtc, true);
>  out:
> @@ -1191,7 +1191,7 @@ nv04_crtc_page_flip(struct drm_crtc *crtc, struct 
> drm_framebuffer *fb,
> /* Initialize a page flip struct */
> *s = (struct nv04_page_flip_state)
> { { }, event, crtc, fb->format->cpp[0] * 8, fb->pitches[0],
> - new_bo->bo.offset };
> + new_bo->offset };
>
> /* Keep vblanks on during flip, for the target crtc of this flip */
> drm_crtc_vblank_get(crtc);
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> index 44ee82d0c9b6..89a4ddfcc55f 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> @@ -151,7 +151,7 @@ nv04_display_init(struct drm_device *dev, bool resume, 
> bool runtime)
> continue;
>
> if (nv_crtc->cursor.set_offset)
> -   nv_crtc->cursor.set_offset(nv_crtc, 
> nv_crtc->cursor.nvbo->bo.offset);
> +   nv_crtc->cursor.set_offset(nv_crtc, 
> nv_crtc->cursor.nvbo->offset);
> nv_crtc->cursor.set_pos(nv_crtc, nv_crtc->cursor_saved_x,
>  nv_crtc->cursor_saved_y);
> }
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c 
> b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> index a3a0a73ae8ab..9529bd9053e7 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> @@ -150,7 +150,7 @@ nv10_update_plane(struct drm_plane *plane, struct 
> drm_crtc *crtc,
> nvif_mask(dev, NV_PCRTC_ENGINE_CTRL + soff2, NV_CRTC_FSEL_OVERLAY, 0);
>
> nvif_wr32(dev, NV_PVIDEO_BASE(flip), 0);
> -   nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->bo.offset);
> +   nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->offset);
> nvif_wr32(dev, NV_PVIDEO_SIZE_IN(flip), src_h << 16 | src_w);
> nvif_wr32(dev, NV_PVIDEO_POINT_IN(flip), src_y << 16 | src_x);
> nvif_wr32(dev, NV_PVIDEO_DS_DX(flip), (src_w << 20) / crtc_w);
> @@ -172,7 +172,7 @@ nv10_update_plane(struct drm_plane *plane, struct 
> drm_crtc *crtc,
> if (format & NV_PVIDEO_FORMAT_PLANAR) {
> nvif_wr32(dev, NV_PVIDEO_UVPLANE_BASE(flip), 0);
> nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
> -   nv_fb->nvbo->bo.offset + fb->offsets[1]);
> +   nv_fb->nvbo->offset + fb->offsets[1]);
> }
> nvif_wr32(dev, NV_PVIDEO_FORMAT(flip), format | fb->pitches[0]);
> nvif_wr32(dev, NV_PVIDEO_STOP, 0);
> @@ -396,7 +396,7 @@ nv04_update_plane(struct drm_plane *plane, struct 
> drm_crtc *crtc,
>
> for (i = 0; i < 2; i++) {
> nvif_wr32(dev

Re: [PATCH 4/8] drm/nouveau: don't use ttm bo->offset

[Nirmoy]

On 2/17/20 4:57 PM, Alex Deucher wrote:

On Mon, Feb 17, 2020 at 10:02 AM Nirmoy Das  wrote:

Store ttm bo->offset in struct nouveau_bo instead.

Signed-off-by: Nirmoy Das 
Christian König 

Missing Acked or Reviewed prefix for Christian.


:facepalm: Thanks Alex.

Nirmoy



Alex


---
  drivers/gpu/drm/nouveau/dispnv04/crtc.c |  6 +++---
  drivers/gpu/drm/nouveau/dispnv04/disp.c |  2 +-
  drivers/gpu/drm/nouveau/dispnv04/overlay.c  |  6 +++---
  drivers/gpu/drm/nouveau/dispnv50/base507c.c |  2 +-
  drivers/gpu/drm/nouveau/dispnv50/core507d.c |  2 +-
  drivers/gpu/drm/nouveau/dispnv50/ovly507e.c |  2 +-
  drivers/gpu/drm/nouveau/dispnv50/wndw.c |  2 +-
  drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c |  2 +-
  drivers/gpu/drm/nouveau/nouveau_abi16.c |  8 
  drivers/gpu/drm/nouveau/nouveau_bo.c|  1 +
  drivers/gpu/drm/nouveau/nouveau_bo.h|  3 +++
  drivers/gpu/drm/nouveau/nouveau_chan.c  |  2 +-
  drivers/gpu/drm/nouveau/nouveau_dmem.c  |  2 +-
  drivers/gpu/drm/nouveau/nouveau_fbcon.c |  2 +-
  drivers/gpu/drm/nouveau/nouveau_gem.c   | 10 +-
  15 files changed, 28 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 1f08de4241e0..d06a93f2b38a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -845,7 +845,7 @@ nv04_crtc_do_mode_set_base(struct drm_crtc *crtc,
 fb = nouveau_framebuffer(crtc->primary->fb);
 }

-   nv_crtc->fb.offset = fb->nvbo->bo.offset;
+   nv_crtc->fb.offset = fb->nvbo->offset;

 if (nv_crtc->lut.depth != drm_fb->format->depth) {
 nv_crtc->lut.depth = drm_fb->format->depth;
@@ -1013,7 +1013,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct 
drm_file *file_priv,
 nv04_cursor_upload(dev, cursor, nv_crtc->cursor.nvbo);

 nouveau_bo_unmap(cursor);
-   nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->bo.offset;
+   nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->offset;
 nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset);
 nv_crtc->cursor.show(nv_crtc, true);
  out:
@@ -1191,7 +1191,7 @@ nv04_crtc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
 /* Initialize a page flip struct */
 *s = (struct nv04_page_flip_state)
 { { }, event, crtc, fb->format->cpp[0] * 8, fb->pitches[0],
- new_bo->bo.offset };
+ new_bo->offset };

 /* Keep vblanks on during flip, for the target crtc of this flip */
 drm_crtc_vblank_get(crtc);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c 
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 44ee82d0c9b6..89a4ddfcc55f 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -151,7 +151,7 @@ nv04_display_init(struct drm_device *dev, bool resume, bool 
runtime)
 continue;

 if (nv_crtc->cursor.set_offset)
-   nv_crtc->cursor.set_offset(nv_crtc, 
nv_crtc->cursor.nvbo->bo.offset);
+   nv_crtc->cursor.set_offset(nv_crtc, 
nv_crtc->cursor.nvbo->offset);
 nv_crtc->cursor.set_pos(nv_crtc, nv_crtc->cursor_saved_x,
  nv_crtc->cursor_saved_y);
 }
diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c 
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index a3a0a73ae8ab..9529bd9053e7 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@ -150,7 +150,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
 nvif_mask(dev, NV_PCRTC_ENGINE_CTRL + soff2, NV_CRTC_FSEL_OVERLAY, 0);

 nvif_wr32(dev, NV_PVIDEO_BASE(flip), 0);
-   nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->bo.offset);
+   nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->offset);
 nvif_wr32(dev, NV_PVIDEO_SIZE_IN(flip), src_h << 16 | src_w);
 nvif_wr32(dev, NV_PVIDEO_POINT_IN(flip), src_y << 16 | src_x);
 nvif_wr32(dev, NV_PVIDEO_DS_DX(flip), (src_w << 20) / crtc_w);
@@ -172,7 +172,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
 if (format & NV_PVIDEO_FORMAT_PLANAR) {
 nvif_wr32(dev, NV_PVIDEO_UVPLANE_BASE(flip), 0);
 nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
-   nv_fb->nvbo->bo.offset + fb->offsets[1]);
+   nv_fb->nvbo->offset + fb->offsets[1]);
 }
 nvif_wr32(dev, NV_PVIDEO_FORMAT(flip), format | fb->pitches[0]);
 nvif_wr32(dev, NV_PVIDEO_STOP, 0);
@@ -396,7 +396,7 @@ nv04_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,

 for (i = 0; i < 2; i++) {
 nvif_wr32(dev, NV_PVIDEO_BUFF0_START_ADDRESS + 4 * i,
- nv_

[Bug 206575] New: [amdgpu] [drm] No video signal on resume from suspend, R9 380

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=206575

Bug ID: 206575
   Summary: [amdgpu] [drm] No video signal on resume from suspend,
R9 380
   Product: Drivers
   Version: 2.5
Kernel Version: 5.5
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: low
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: veox+ker...@veox.pw
Regression: No

Created attachment 287441
  --> https://bugzilla.kernel.org/attachment.cgi?id=287441&action=edit
dmesg output for resume-from-suspend, linux 5.5.4

OS: Arch Linux
GPU: (MSI) Radeon R9 380

On `systemctl suspend` and subsequent resume, the monitors display "no signal".
The machine is responsive, commands can be typed on the keyboard, SSH'ing is
also possible.

Somewhat unexpectedly, resume from hibernation works fine (i.e. there is
signal).

This started happening a few weeks ago, seemingly when `linux` v5.5.2 was
installed. Was also present on v5.5.3 and v5.5.4 (current).

`linux-lts` v5.4.20 does not exhibit this behaviour; it's a regression.

-- 
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