date:20200428

Hi,
On 25/04/2020 22:39, Martin Blumenstingl wrote:
> The burst length is configured in VIU_OSD1_FIFO_CTRL_STAT[31] and
> VIU_OSD1_FIFO_CTRL_STAT[11:10]. The public S905D3 datasheet describes
> this as:
> - 0x0 = up to 24 per burst
> - 0x1 = up to 32 per burst
> - 0x2 = up to 48 per burst
> - 0x3 = up to 64 per burst
> - 0x4 = up to 96 per burst
> - 0x5 = up to 128 per burst
> 
> The lower two bits map to VIU_OSD1_FIFO_CTRL_STAT[11:10] while the upper
> bit maps to VIU_OSD1_FIFO_CTRL_STAT[31].
> 
> Replace meson_viu_osd_burst_length_reg() with pre-defined macros which
> set these values. meson_viu_osd_burst_length_reg() always returned 0
> (for the two used values: 32 and 64 at least) and thus incorrectly set
> the burst size to 24.
> 
> Fixes: 147ae1cbaa1842 ("drm: meson: viu: use proper macros instead of magic 
> constants")
> Signed-off-by: Martin Blumenstingl 
> ---
>  drivers/gpu/drm/meson/meson_registers.h |  6 ++
>  drivers/gpu/drm/meson/meson_viu.c   | 11 ++-
>  2 files changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_registers.h 
> b/drivers/gpu/drm/meson/meson_registers.h
> index 8ea00546cd4e..049c4bfe2a3a 100644
> --- a/drivers/gpu/drm/meson/meson_registers.h
> +++ b/drivers/gpu/drm/meson/meson_registers.h
> @@ -261,6 +261,12 @@
>  #define VIU_OSD_FIFO_DEPTH_VAL(val)  ((val & 0x7f) << 12)
>  #define VIU_OSD_WORDS_PER_BURST(words)   (((words & 0x4) >> 1) << 22)
>  #define VIU_OSD_FIFO_LIMITS(size)((size & 0xf) << 24)
> +#define VIU_OSD_BURST_LENGTH_24  (0x0 << 31 | 0x0 << 10)
> +#define VIU_OSD_BURST_LENGTH_32  (0x0 << 31 | 0x1 << 10)
> +#define VIU_OSD_BURST_LENGTH_48  (0x0 << 31 | 0x2 << 10)
> +#define VIU_OSD_BURST_LENGTH_64  (0x0 << 31 | 0x3 << 10)
> +#define VIU_OSD_BURST_LENGTH_96  (0x1 << 31 | 0x0 << 10)
> +#define VIU_OSD_BURST_LENGTH_128 (0x1 << 31 | 0x1 << 10)
>  
>  #define VD1_IF0_GEN_REG 0x1a50
>  #define VD1_IF0_CANVAS0 0x1a51
> diff --git a/drivers/gpu/drm/meson/meson_viu.c 
> b/drivers/gpu/drm/meson/meson_viu.c
> index 304f8ff1339c..aede0c67a57f 100644
> --- a/drivers/gpu/drm/meson/meson_viu.c
> +++ b/drivers/gpu/drm/meson/meson_viu.c
> @@ -411,13 +411,6 @@ void meson_viu_gxm_disable_osd1_afbc(struct meson_drm 
> *priv)
>   priv->io_base + _REG(VIU_MISC_CTRL1));
>  }
>  
> -static inline uint32_t meson_viu_osd_burst_length_reg(uint32_t length)
> -{
> - uint32_t val = (((length & 0x80) % 24) / 12);
> -
> - return (((val & 0x3) << 10) | (((val & 0x4) >> 2) << 31));
> -}
> -
>  void meson_viu_init(struct meson_drm *priv)
>  {
>   uint32_t reg;
> @@ -444,9 +437,9 @@ void meson_viu_init(struct meson_drm *priv)
>   VIU_OSD_FIFO_LIMITS(2);  /* fifo_lim: 2*16=32 */
>  
>   if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A))
> - reg |= meson_viu_osd_burst_length_reg(32);
> + reg |= VIU_OSD_BURST_LENGTH_32;
>   else
> - reg |= meson_viu_osd_burst_length_reg(64);
> + reg |= VIU_OSD_BURST_LENGTH_64;
>  
>   writel_relaxed(reg, priv->io_base + _REG(VIU_OSD1_FIFO_CTRL_STAT));
>   writel_relaxed(reg, priv->io_base + _REG(VIU_OSD2_FIFO_CTRL_STAT));
> 

Thanks,
Will run some tests !

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

Re: Linux GOP initialization is wrong

2020-04-28 Thread Hans de Goede


Hi David,

On 4/28/20 1:58 AM, David Santamaría Rogado wrote:

This is related to the issues at least on some devices for panel
orientation quirks where added.


Thank you for looking into this.


My tests have been done over a Lenovo ideapad D330.

This devices like the other ones that need panel orientation quirks,
shows the initramfs with wrong stride and x and y swapped. By applying
the panel orientation quirks this gets solved but many parts of the
systems components needs to be patched. Hans has done a great job with
plymouth, mutter... but always appears a new problem derived as for
example vnc desktop sharing with this devices doesn't work and the
output is send messed up.


When I first started adding support for devices which have their
screen mounted 90 degrees rotated my first attempts where aimed
at solving this transparently in the kernel.

Unfortunately this is not possible. On most affected devices
the hardware does not support 90 degrees rotation for the
primary display layer; or if it does this requires the framebuffer
being in a hardware-specific tiled format rather then being a
linear framebuffer. Using these tiled formats requires userspace
to be aware of this, which rules out transparently handling this
in the kernel.

Other layers (cursor layer, video overlay layers) have similar
issues which require userspace to be aware of what is happening,
so unfortunately there is no other way to deal with this then
fixing involved userspace components.

I'm a bit surprised that you sat that vnc desktop sharing does
not work, I guess that also depends on how the desktop sharing
works. If it pokes directly at the framebuffer somehow, then yes
it will be messed up. But if it goes through the display server
then things might work. I guess that it is possible that the
code doing this cannot deal with Xrandr output rotation ...


The strange thing is that bootloaders like GRUB or rEFInd seems to be
able to handle this and they paint themselves right, despite when
booting Windows directly Windows paints itself right and booted with
GRUB or rEFInd the first second also paint itself wrong. Haven't
tested this too much but the interesting thing is in the next
paragraph.


My experience with bootloaders showing themselves the right way
up is mixed. It seems that the firmware is doing some hacks for
this on some devices, at least for the EFI text console.

Funnily enough (for some definition of fun) on at least one of
the devices where the firmware is playing tricks (Asus T100HA IIRC)
the position of the carret for text-editing is off by one, which
is very annoying when editing the kernel commandline and which
clearly shows that things are being emulated in software here.


I decided to get the UEFI GOP video modes and found that the D330 have
these ones:
Mode 0: 1200x1920
Mode 1: 640x480
Mode 2: 800x600
Mode 3: 1024x768
Mode 4: 1920x1200 (this is the default one started by the firmware)
Mode 5: 480x640
Mode 6: 600x800
Mode 7: 768x1024

So I thought that Linux is taking the first mode despite is not the
active one and that's why the display is messed up.


Nope, Linux does not touch the mode at all (nor does grub by default).
Doing a EFI/GOP modeset has the risk of triggering all sort of firmware
bugs. So we stick with what we get. This has interesting side effects
where on some systems you get a different mode when turning on the
machine and letting it boot, vs turning it on, pressing e.g. F12 to get
the boot menu and then boot Linux.


Playing a little I could modify the GOP video mode before booting with
the UEFI Shell by simple using the mode 150 101. This causes GOP video
mode 5 to be switched to video mode 0, the first one. Booting now
makes initramfs messages to be correctly rendered but in the wrong
orientation.


Right, the rendering on the side thing is expected. As said the hardware
cannot do 90 degrees rotation with a linear framebuffer and the GOP
provided efifb is a linear framebuffer. So without telling the kernel
to software rotate its text console the text will always be on its side.

What your little EFI shell hack is doing is working around what seems to
be a bug on these Lenovo devices gives us the wrong stride and dimensions
for the EFI framebuffer.

Note that this very much is a Lenovo bug, all the other devices
with 90 degree rotated screens let us render the text console
on its side just fine. They correctly tells us the real size
and stride of the screen (so its portrait dimensions since it
is a portrait screen).

Even though this is a Lenovo bug we should probably still try to
find a way to deal with this though, so that the efifb works
correctly on these devices...


A look at drivers/firmware/efi/libstub/gop.c seems to be what is
happening, the first available video mode is used despite it could not
be the active one in GOP and the active mode is not switched to the
discovered one by Linux. Both GRUB and rEFInd are able to respect the
video mode that GOP has active so it's poss

[PATCH][next] drm/i915/gt: fix spelling mistake "evalution" -> "evaluation"

2020-04-28 Thread Colin King

From: Colin Ian King 

There is a spelling mistaking in a pr_notice message. Fix it.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/gt/selftest_rps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_rps.c 
b/drivers/gpu/drm/i915/gt/selftest_rps.c
index 181b29fa5b58..6ce7003bf92f 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rps.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rps.c
@@ -282,7 +282,7 @@ int live_rps_clock_interval(void *arg)
  GEN6_RP_CUR_UP_EI),
 10)) {
/* Just skip the test; assume lack of HW support */
-   pr_notice("%s: rps evalution interval not ticking\n",
+   pr_notice("%s: rps evaluation interval not ticking\n",
  engine->name);
err = -ENODEV;
} else {
-- 
2.25.1

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

Re: [PATCH] drm/meson: add mode selection limits against specific SoC revisions

Hi,

On 22/04/2020 23:12, Martin Blumenstingl wrote:
> Hi Neil,
> 
> On Tue, Apr 21, 2020 at 3:44 PM Neil Armstrong  
> wrote:
> [...]
>> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
>> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
>> index e8c94915a4fc..dc3d5122475a 100644
>> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
>> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
>> @@ -695,6 +695,13 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
>> dev_dbg(connector->dev->dev, "%s: vclk:%d phy=%d venc=%d hdmi=%d\n",
>> __func__, phy_freq, vclk_freq, venc_freq, hdmi_freq);
>>
>> +   /* Check against soc revision/package limits */
>> +   if (priv->limits) {
>> +   if (priv->limits->max_hdmi_phy_freq &&
>> +   phy_freq > priv->limits->max_hdmi_phy_freq)
>> +   return MODE_CLOCK_HIGH;
>> +   }
> I think that this will also be useful for the 32-bit SoCs as well.
> is there a chance you can move it to meson_vclk_vic_supported_freq
> (called right below), where all the existing frequency limit checks
> are already?

It would need to add priv to meson_vclk_vic_supported_freq(), but indeed,
would be cleaner.

And the meson_vclk_dmt_supported_freq() would also need this test aswell.

I'll resend with these fixed.

Neil

> 
> 
> Thank you!
> Martin
> 

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

Re: [PATCH] drm/meson: Remove unneeded semicolon

On 24/04/2020 09:49, Zheng Bin wrote:
> Fixes coccicheck warning:
> 
> drivers/gpu/drm/meson/meson_plane.c:226:3-4: Unneeded semicolon
> 
> Reported-by: Hulk Robot 
> Signed-off-by: Zheng Bin 
> ---
>  drivers/gpu/drm/meson/meson_plane.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_plane.c 
> b/drivers/gpu/drm/meson/meson_plane.c
> index d5cbc47835bf..35338ed18209 100644
> --- a/drivers/gpu/drm/meson/meson_plane.c
> +++ b/drivers/gpu/drm/meson/meson_plane.c
> @@ -223,7 +223,7 @@ static void meson_plane_atomic_update(struct drm_plane 
> *plane,
>   priv->viu.osd1_blk0_cfg[0] |= OSD_BLK_MODE_16 |
>   OSD_COLOR_MATRIX_16_RGB565;
>   break;
> - };
> + }
>   }
> 
>   switch (fb->format->format) {
> --
> 2.26.0.106.g9fadedd
> 

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

Re: [PATCH] drm/meson: Remove unneeded semicolon

On 24/04/2020 09:49, Zheng Bin wrote:
> Fixes coccicheck warning:
> 
> drivers/gpu/drm/meson/meson_plane.c:226:3-4: Unneeded semicolon
> 
> Reported-by: Hulk Robot 
> Signed-off-by: Zheng Bin 
> ---
>  drivers/gpu/drm/meson/meson_plane.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_plane.c 
> b/drivers/gpu/drm/meson/meson_plane.c
> index d5cbc47835bf..35338ed18209 100644
> --- a/drivers/gpu/drm/meson/meson_plane.c
> +++ b/drivers/gpu/drm/meson/meson_plane.c
> @@ -223,7 +223,7 @@ static void meson_plane_atomic_update(struct drm_plane 
> *plane,
>   priv->viu.osd1_blk0_cfg[0] |= OSD_BLK_MODE_16 |
>   OSD_COLOR_MATRIX_16_RGB565;
>   break;
> - };
> + }
>   }
> 
>   switch (fb->format->format) {
> --
> 2.26.0.106.g9fadedd
> 

Applied to drm-misc-next
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH] dt-bindings: display: ti,tfp410.txt: convert to yaml

2020-04-28 Thread Ricardo Cañuelo

Convert the DT binding documentation for the TI TFP410 DPI-to-DVI
encoder to json-schema.

Signed-off-by: Ricardo Cañuelo 
---
Hi all,

I found some issues while converting this binding and I'd like to know
your opinions on how to tackle them.

1) dtbs_check fails for arch/arm/boot/dts/dove-sbc-a510.dts

  This board uses the TFP410 encoder but it doesn't define any ports for
  it. I can't find any suitable remote endpoints in its description
  either. Maybe this board description should be reworked? The current
  driver won't handle the device if it doesn't define any ports or
  endpoints anyway.

  It also uses the 'powerdown-gpio' property instead of
  'powerdown-gpios'. AFAICT this shouldn't be a problem from the driver
  point of view, but the general standard in DT bindings is to use the
  plural. This is trivial to fix.

2) The definition of ti,deskew in the original binding seems to be
tailored to the current driver and the way it's defined may not be very
DT-friendly.

  This parameter maps to a 3-bit field in a hardware register that takes
  a value from 0 to 7, so the [-4, 3] range described for this would map
  to [000, 111]: -4 -> 000, -3 -> 001, -2 -> 010, ... 3 -> 111.

  Then, the driver parses the parameter (unsigned) and casts it to a
  signed integer to get a number in the [-4, 3] range.

  A vendor-specific property must have a type definition in json-schema,
  so if I translate the original bindings semantics directly, I should
  define ti,deskew as an int32, but this makes dt_binding_check fail if
  the property has a negative value in the example because of the
  internal representation of cells as unsigned integers:

 ti,deskew:0:0: 4294967293 is greater than the maximum of 2147483647

  So I can think of two solutions to this:

  a) Keep the ti,deskew property as an uint32 and document the valid
  range ([-4, 3]) in the property description (this is what this patch
  does currently).

  b) Redefine this property to be closer to the datasheet description
  (ie. unsigned integers from 0 to 7) and adapt the driver accordingly.
  This would also let us define its range properly using minimum and
  maximum properties for it.

  I think (b) is the right thing to do but I want to know your
  opinion. Besides, I don't have this hardware at hand and if I updated
  the driver I wouldn't be able to test it.

Thanks.

Patch tested with:

make dt_binding_check ARCH=arm DT_SCHEMA_FILES=<.../ti,tfp410.yaml>
make dtbs_check ARCH=arm DT_SCHEMA_FILES=<.../ti,tfp410.yaml>

 .../bindings/display/bridge/ti,tfp410.txt |  66 --
 .../bindings/display/bridge/ti,tfp410.yaml| 121 ++
 2 files changed, 121 insertions(+), 66 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt 
b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
deleted file mode 100644
index 5ff4f64ef8e8..
--- a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-TFP410 DPI to DVI encoder
-=
-
-Required properties:
-- compatible: "ti,tfp410"
-
-Optional properties:
-- powerdown-gpios: power-down gpio
-- reg: I2C address. If and only if present the device node should be placed
-  into the I2C controller node where the TFP410 I2C is connected to.
-- ti,deskew: data de-skew in 350ps increments, from -4 to +3, as configured
-  through th DK[3:1] pins. This property shall be present only if the TFP410
-  is not connected through I2C.
-
-Required nodes:
-
-This device has two video ports. Their connections are modeled using the OF
-graph bindings specified in [1]. Each port node shall have a single endpoint.
-
-- Port 0 is the DPI input port. Its endpoint subnode shall contain a
-  pclk-sample and bus-width property and a remote-endpoint property as 
specified
-  in [1].
-  - If pclk-sample is not defined, pclk-sample = 0 should be assumed for
-backward compatibility.
-  - If bus-width is not defined then bus-width = 24 should be assumed for
-backward compatibility.
-bus-width = 24: 24 data lines are connected and single-edge mode
-bus-width = 12: 12 data lines are connected and dual-edge mode
-
-- Port 1 is the DVI output port. Its endpoint subnode shall contain a
-  remote-endpoint property is specified in [1].
-
-[1] Documentation/devicetree/bindings/media/video-interfaces.txt
-
-
-Example

-
-tfp410: encoder@0 {
-   compatible = "ti,tfp410";
-   powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
-   ti,deskew = <4>;
-
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@0 {
-   reg = <0>;
-
-   tfp410_in: endpoint@0 {
-   pclk-sample = <1>;
-

[PATCH v2] drm/meson: add mode selection limits against specific SoC revisions

The Amlogic S805X/Y uses the same die as the S905X, but with more
limited graphics capabilities.

This adds a soc version detection adding specific limitations on the HDMI
mode selections.

Here, we limit to HDMI 1.3a max HDMI PHY clock frequency.

Changes sinces v1:
- Moved frequency check in the vclk code, and also checks DMT modes

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_drv.c | 29 ++-
 drivers/gpu/drm/meson/meson_drv.h |  6 ++
 drivers/gpu/drm/meson/meson_dw_hdmi.c |  2 +-
 drivers/gpu/drm/meson/meson_vclk.c| 16 ++-
 drivers/gpu/drm/meson/meson_vclk.h|  3 ++-
 5 files changed, 52 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_drv.c 
b/drivers/gpu/drm/meson/meson_drv.c
index 6f29fab79952..621f6de0f076 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -183,6 +184,24 @@ static void meson_remove_framebuffers(void)
kfree(ap);
 }
 
+struct meson_drm_soc_attr {
+   struct meson_drm_soc_limits limits;
+   const struct soc_device_attribute *attrs;
+};
+
+static const struct meson_drm_soc_attr meson_drm_soc_attrs[] = {
+   /* S805X/S805Y HDMI PLL won't lock for HDMI PHY freq > 1,65GHz */
+   {
+   .limits = {
+   .max_hdmi_phy_freq = 165,
+   },
+   .attrs = (const struct soc_device_attribute []) {
+   { .soc_id = "GXL (S805*)", },
+   { /* sentinel */ },
+   }
+   },
+};
+
 static int meson_drv_bind_master(struct device *dev, bool has_components)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -191,7 +210,7 @@ static int meson_drv_bind_master(struct device *dev, bool 
has_components)
struct drm_device *drm;
struct resource *res;
void __iomem *regs;
-   int ret;
+   int ret, i;
 
/* Checks if an output connector is available */
if (!meson_vpu_has_available_connectors(dev)) {
@@ -281,6 +300,14 @@ static int meson_drv_bind_master(struct device *dev, bool 
has_components)
if (ret)
goto free_drm;
 
+   /* Assign limits per soc revision/package */
+   for (i = 0 ; i < ARRAY_SIZE(meson_drm_soc_attrs) ; ++i) {
+   if (soc_device_match(meson_drm_soc_attrs[i].attrs)) {
+   priv->limits = &meson_drm_soc_attrs[i].limits;
+   break;
+   }
+   }
+
/* Remove early framebuffers (ie. simplefb) */
meson_remove_framebuffers();
 
diff --git a/drivers/gpu/drm/meson/meson_drv.h 
b/drivers/gpu/drm/meson/meson_drv.h
index 04fdf3826643..5b23704a80d6 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -30,6 +30,10 @@ struct meson_drm_match_data {
struct meson_afbcd_ops *afbcd_ops;
 };
 
+struct meson_drm_soc_limits {
+   unsigned int max_hdmi_phy_freq;
+};
+
 struct meson_drm {
struct device *dev;
enum vpu_compatible compat;
@@ -48,6 +52,8 @@ struct meson_drm {
struct drm_plane *primary_plane;
struct drm_plane *overlay_plane;
 
+   const struct meson_drm_soc_limits *limits;
+
/* Components Data */
struct {
bool osd1_enabled;
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index e8c94915a4fc..5be963e9db05 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -695,7 +695,7 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
dev_dbg(connector->dev->dev, "%s: vclk:%d phy=%d venc=%d hdmi=%d\n",
__func__, phy_freq, vclk_freq, venc_freq, hdmi_freq);
 
-   return meson_vclk_vic_supported_freq(phy_freq, vclk_freq);
+   return meson_vclk_vic_supported_freq(priv, phy_freq, vclk_freq);
 }
 
 /* Encoder */
diff --git a/drivers/gpu/drm/meson/meson_vclk.c 
b/drivers/gpu/drm/meson/meson_vclk.c
index fdf26dac9fa8..0eb86943a358 100644
--- a/drivers/gpu/drm/meson/meson_vclk.c
+++ b/drivers/gpu/drm/meson/meson_vclk.c
@@ -725,6 +725,13 @@ meson_vclk_dmt_supported_freq(struct meson_drm *priv, 
unsigned int freq)
/* In DMT mode, path after PLL is always /10 */
freq *= 10;
 
+   /* Check against soc revision/package limits */
+   if (priv->limits) {
+   if (priv->limits->max_hdmi_phy_freq &&
+   freq > priv->limits->max_hdmi_phy_freq)
+   return MODE_CLOCK_HIGH;
+   }
+
if (meson_hdmi_pll_find_params(priv, freq, &m, &frac, &od))
return MODE_OK;
 
@@ -762,7 +769,7 @@ static void meson_hdmi_pll_generic_set(struct meson_drm 
*priv,
 }
 
 enum drm_mode_status
-meson_vclk_vic_supported_freq(unsigned int phy_freq,
+meson_vclk_vic_supported_freq(struct meson_drm *priv, unsigned int phy_

Re: [PATCH] drm/virtio: only destroy created contexts

2020-04-28 Thread Gerd Hoffmann

On Wed, Apr 08, 2020 at 04:29:38PM -0700, Gurchetan Singh wrote:
> This can happen if userspace doesn't issue any 3D ioctls before
> closing the DRM fd.
> 
> Fixes: 72b48ae800da ("drm/virtio: enqueue virtio_gpu_create_context
> after the first 3D ioctl")
> Signed-off-by: Gurchetan Singh 

Pushed to drm-misc-fixes.

thanks,
  Gerd

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

Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver

On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote:
> On Fri, Apr 24, 2020 at 2:51 PM Xin Ji  wrote:
> >
> > On Thu, Apr 23, 2020 at 07:55:15PM +0800, Nicolas Boichat wrote:
> > > Hi,
> > >
> > > Just commenting on the mode_fixup function that was added in v7.
> > >
> > [snip]
> > > > +   /*
> > > > +* once illegal timing detected, use default HFP, HSYNC, HBP
> > > > +*/
> > > > +   if (hblanking < HBLANKING_MIN || (hfp < HP_MIN && hbp < 
> > > > HP_MIN)) {
> > >
> > > should this be adj_hblanking/adj_hfp/adj_hbp?
> > NO, need check original HFP and HBP, if they are not legal, driver need
> > set default value to adj_hsync, adj_hfp, adj_hbp.
> > >
> > > > +   adj_hsync = SYNC_LEN_DEF;
> > > > +   adj_hfp = HFP_HBP_DEF;
> > > > +   adj_hbp = HFP_HBP_DEF;
> > > > +   vref = adj->clock * 1000 / (adj->htotal * adj->vtotal);
> > > > +   if (hblanking < HBLANKING_MIN) {
> > > > +   delta_adj = HBLANKING_MIN - hblanking;
> > > > +   adj_clock = vref * delta_adj * adj->vtotal;
> > > > +   adj->clock += DIV_ROUND_UP(adj_clock, 1000);
> > > > +   } else {
> > > > +   delta_adj = hblanking - HBLANKING_MIN;
> > > > +   adj_clock = vref * delta_adj * adj->vtotal;
> > > > +   adj->clock -= DIV_ROUND_UP(adj_clock, 1000);
> > > > +   }
> > > > +
> > > > +   DRM_WARN("illegal hblanking timing, use default.\n");
> > > > +   DRM_WARN("hfp(%d),hbp(%d),hsync(%d).\n", hfp, hbp, 
> > > > hsync);
> > >
> > > How likely is it that this mode is going to work? Can you just return
> > > false here to reject the mode?
> > We want to set the default minimal Hblancking value, then it may display,
> > otherwise. If we just return false, there is no display for sure.
> 
> Right, understand your argument. I'm pondering if it's not just better
> to reject the mode rather than trying a timing that is definitely
> quite different from what the monitor was asking for. No super strong
> opinion, I'll let other people on the list weigh in.

Yeah mode_fixup is supposed to be used to adjust the mode in intermediate
stages (e.g. if you go from progressive to interlaced only at the end of
your pipeline or something like that). It's not meant for adjusting the
mode yout actually put out through a hdmi or dp connector. For fixed
panels adjusting modes to fit the panel is also fairly common, but not for
external outputs.

Since this is a DP bridge I'd say no adjusting, just reject what doesn't
fit.
-Daniel
-- 
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 PATCH] dt-bindings: display: ti,tfp410.txt: convert to yaml

2020-04-28 Thread Tomi Valkeinen

On 28/04/2020 12:20, Ricardo Cañuelo wrote:

2) The definition of ti,deskew in the original binding seems to be
tailored to the current driver and the way it's defined may not be very
DT-friendly.

This parameter maps to a 3-bit field in a hardware register that takes
a value from 0 to 7, so the [-4, 3] range described for this would map
to [000, 111]: -4 -> 000, -3 -> 001, -2 -> 010, ... 3 -> 111.

Then, the driver parses the parameter (unsigned) and casts it to a
signed integer to get a number in the [-4, 3] range.

Interestingly the current example has ti,deskew = <4>...

A vendor-specific property must have a type definition in json-schema,
so if I translate the original bindings semantics directly, I should
define ti,deskew as an int32, but this makes dt_binding_check fail if
the property has a negative value in the example because of the
internal representation of cells as unsigned integers:

ti,deskew:0:0: 4294967293 is greater than the maximum of 2147483647

I don't quite understand this. We cannot have negative numbers in dts files? Or we can, but
dt_binding_check doesn't handle them correctly? Or that int32 is not supported in yaml bindings?

So I can think of two solutions to this:

a) Keep the ti,deskew property as an uint32 and document the valid
range ([-4, 3]) in the property description (this is what this patch
does currently).

b) Redefine this property to be closer to the datasheet description
(ie. unsigned integers from 0 to 7) and adapt the driver accordingly.
This would also let us define its range properly using minimum and
maximum properties for it.

I think (b) is the right thing to do but I want to know your
opinion. Besides, I don't have this hardware at hand and if I updated
the driver I wouldn't be able to test it.

I don't think anyone has used deskew property, so I guess changing it is not
out of the question.

Laurent, did you have a board that needs deskew when you added it to tfp410?

Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/qxl: qxl_release leak in qxl_hw_surface_alloc()

2020-04-28 Thread Gerd Hoffmann

On Mon, Apr 27, 2020 at 08:32:51AM +0300, Vasily Averin wrote:
> Cc: sta...@vger.kernel.org
> Fixes: 8002db6336dd ("qxl: convert qxl driver to proper use for reservations")
> Signed-off-by: Vasily Averin 

Both patches pushed to drm-misc-fixes.

thanks,
  Gerd

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

Re: [PATCH] drm/qxl: lost qxl_bo_kunmap_atomic_page in qxl_image_init_helper()

2020-04-28 Thread Gerd Hoffmann

On Mon, Apr 27, 2020 at 10:55:27AM +0300, Vasily Averin wrote:
> Signed-off-by: Vasily Averin 
> ---
>  drivers/gpu/drm/qxl/qxl_image.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/qxl/qxl_image.c b/drivers/gpu/drm/qxl/qxl_image.c
> index 43688ecdd8a0..7270da62fc29 100644
> --- a/drivers/gpu/drm/qxl/qxl_image.c
> +++ b/drivers/gpu/drm/qxl/qxl_image.c
> @@ -212,6 +212,7 @@ qxl_image_init_helper(struct qxl_device *qdev,
>   break;
>   default:
>   DRM_ERROR("unsupported image bit depth\n");
> + qxl_bo_kunmap_atomic_page(qdev, image_bo, ptr);
>   return -EINVAL; /* TODO: cleanup */

I guess you can ditch the TODO comment now, it's done ;)

take care,
  Gerd

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

Re: [PATCH v4 3/3] drm/bridge: chrontel-ch7033: Add a new driver

On Thu, Apr 23, 2020 at 11:18:45PM +0200, Lubomir Rintel wrote:
> On Tue, Apr 21, 2020 at 02:54:12PM +0200, Daniel Vetter wrote:
> > On Tue, Mar 24, 2020 at 04:19:31PM +0100, Lubomir Rintel wrote:
> > > This is a driver for video encoder with VGA and DVI/HDMI outputs.
> > > 
> > > There is no documentation for the chip -- the operation was guessed from
> > > what was sniffed on a Dell Wyse 3020 ThinOS terminal, the register names
> > > come from the ch7035 driver in Mediatek's GPL code dump.
> > > 
> > > Only bare minimum is implemented -- no fancy stuff, such as scaling. That
> > > would only worsen our misery. We don't load the firmware and we don't need
> > > to even bother enabling the MCU.  There are probably no distributable
> > > firmware images anyway.
> > > 
> > > Just like the tda998x driver, this one uses the component framework and
> > > adds an encoder on component bind, so that it works with the Armada DRM
> > > driver.
> 
> Thank you for your response.
> 
> > Uh, can we instead pls land the patches for armada to switch over to of
> > bridge helpers.
> 
> I honestly don't know -- it's not something I can do anything about.
> 
> I didn't have any luck getting responses to my other patches for the
> Armada driver.

If it's just a case of unresponsive maintainer, we can take over with the
drm-misc group maintained fallback in drm. Still need someone to
review/ack patches ofc, but usually there's room for that in the drm-misc
group.

> > Iirc the big hold-up was that with direct bridge usage
> > instead of component framework, the drm driver wouldn't unload. But core
> > pm maintainers fixed device links to include driver unloading, and there
> > was a drm_bridge patch including armada patches to do all that.
> > 
> > But somehow it didn't land. Iirc because Russell couldn't test them on
> > upstream somehow.
> 
> This is what I've found [1]. It seems to include the device links work and
> switches over the komeda driver, not armada, from components to drm_bridge:
> 
> [1] https://patchwork.kernel.org/cover/11262351/
> 
> I'm wondering if this is the patch set you're referring to?

Yup that was one part. Maybe ping on that thread, if Mihail still is
interested in this you could cross-review each another's stuff and then
land it in drm-misc.

> > Adding more special cases and bridge drivers that we have to convert isn't
> > going to make this any easier.
> 
> No conversion would be necessary -- merely stripping the
> component/encoder parts once they're no longer necessary. The driver
> would still work just fine with drivers that don't utilize the component
> framework, juts as tda998x does.

Hm I was pretty sure it (series to convert to armada) existed by someone,
but I can't find it anymore. Anyway if all we need is to remove a bunch
of stuff, then even better.
-Daniel

> > This entire discussion happened in
> > 
> > https://www.spinics.net/lists/dri-devel/msg201927.html
> > 
> > Can't find the armada patches real quick, nor the drm_bridge patch. But
> > the core infrastructure hides behind. The core pm change has been added in
> > 
> > commit e7dd40105aac9ba051e44ad711123bc53a5e4c71
> > Author: Rafael J. Wysocki 
> > Date:   Fri Feb 1 01:59:42 2019 +0100
> > 
> > driver core: Add device link flag DL_FLAG_AUTOPROBE_CONSUMER
> 
> Thank you
> Lubo
> 
> > 
> > Thanks, Daniel
> > > 
> > > Tested with a handful of monitors ranging from 1024x768@75 to 
> > > 1400x1050@60,
> > > with VGA as well as DVI.
> > > 
> > > Signed-off-by: Lubomir Rintel 
> > > 
> > > ---
> > > Changes since v3:
> > > - Cosmetic changes; drop ch7033_encoder_destroy() and use
> > >   drm_encoder_cleanup() for drm_encoder_funcs.destroy callback
> > >   directly.
> > > 
> > > Changes since v1:
> > > - Sort the includes
> > > - Drop a useless model id read
> > > - Chain to the bridge-connector instead of dealing with the HPD/EDID
> > >   readout machinery ourselves
> > > - Utilize regmap to access the registers
> > > 
> > >  drivers/gpu/drm/bridge/Kconfig   |  10 +
> > >  drivers/gpu/drm/bridge/Makefile  |   1 +
> > >  drivers/gpu/drm/bridge/chrontel-ch7033.c | 669 +++
> > >  3 files changed, 680 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/bridge/chrontel-ch7033.c
> > > 
> > > diff --git a/drivers/gpu/drm/bridge/Kconfig 
> > > b/drivers/gpu/drm/bridge/Kconfig
> > > index aaed2347ace9d..0ebc72d62a5b2 100644
> > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > @@ -27,6 +27,16 @@ config DRM_CDNS_DSI
> > > Support Cadence DPI to DSI bridge. This is an internal
> > > bridge and is meant to be directly embedded in a SoC.
> > >  
> > > +config DRM_CHRONTEL_CH7033
> > > + tristate "Chrontel CH7033 Video Encoder"
> > > + depends on OF
> > > + select DRM_KMS_HELPER
> > > + help
> > > +   Enable support for the Chrontel CH7033 VGA/DVI/HDMI Encoder, as
> > > +   found in the Dell Wyse 3020 thin client.
> > > +
> > > +   If in doubt, say "N".
> >

Re: How to handle disconnection of eDP panels due to dynamic display mux switches

On Wed, Apr 22, 2020 at 05:04:54PM -0500, Daniel Dadap wrote:
> On 4/3/20 2:59 PM, Daniel Vetter wrote:
> > On Fri, Apr 3, 2020 at 8:06 PM Daniel Dadap  wrote:
> > > 
> > > On 4/3/20 2:16 AM, Daniel Vetter wrote:
> > > > On Fri, Apr 3, 2020 at 8:54 AM Daniel Dadap  wrote:
> > > > > On 4/2/20 6:39 AM, Lukas Wunner wrote:
> > > > > 
> > > > > 
> > > > > On Fri, Mar 27, 2020 at 04:25:19PM -0500, Daniel Dadap wrote:
> > > > > > > A number of hybrid GPU notebook computer designs with dual 
> > > > > > > (integrated plus
> > > > > > > discrete) GPUs are equipped with multiplexers (muxes) that allow 
> > > > > > > display
> > > > > > > panels to be driven by either the integrated GPU or the discrete 
> > > > > > > GPU.
> > > > > > > Typically, this is a selection that can be made at boot time as a 
> > > > > > > menu
> > > > > > > option in the system firmware's setup screen, and the mux 
> > > > > > > selection stays
> > > > > > > fixed for as long as the system is running and persists across 
> > > > > > > reboots until
> > > > > > > it is explicitly changed. However, some muxed hybrid GPU systems 
> > > > > > > have
> > > > > > > dynamically switchable muxes which can be switched while the 
> > > > > > > system is
> > > > > > > running.
> > > > > > As you may be aware, there's drivers/gpu/vga/vga_switcheroo.c (of 
> > > > > > which
> > > > > > I'm listed as a reviewer in MAINTAINERS) to support such hardware.
> > > > > > 
> > > > > > It also supports muxed configurations, including those that support
> > > > > > switching at runtime (and not only at boot) such as the MacBook Pro,
> > > > > > which uses drivers/platform/x86/apple-gmux.c to interface between
> > > > > > vga_switcheroo and the hardware mux.
> > > > > > 
> > > > > > However, so far switching only actually works on LVDS-based MacBook 
> > > > > > Pros,
> > > > > > i.e. all pre-retina machines introduced between Late 2008 and Mid 
> > > > > > 2012,
> > > > > > because that hardware is capable of switching the DDC pins 
> > > > > > separately
> > > > > > from the display, so we lock and switch them when probing the EDID.
> > > > > I have observed that on at least some systems, the EDID for the 
> > > > > internal
> > > > > panel can be read via the ACPI _DDC method regardless of whether it's
> > > > > actively muxed in. I don't know whether that's true for all systems
> > > > > where the DDC line can't be switched independently, but maybe
> > > > > vga_switcheroo could also export an interface for GPU drivers to cache
> > > > > EDIDs so that a muxed-away GPU can read an EDID that was previously 
> > > > > read
> > > > > by another GPU? I guess the utility of that would depend on how
> > > > > prevalent the combination of no DDC muxing + no ACPI EDID reads turns
> > > > > out to be.
> > > > > 
> > > > > 
> > > > > > The retina machines introduced from Mid 2012 onward use eDP and run
> > > > > > into the issues you're describing:  The AUX channel cannot be 
> > > > > > switched
> > > > > > separately from the display, so link training fails unless the 
> > > > > > entire
> > > > > > display is switched.  Nevertheless macOS can switch the panel 
> > > > > > seamlessly.
> > > > > > So how are they doing it?
> > > > > > 
> > > > > > Well, I don't own a retina MacBook Pro, hence never got very far 
> > > > > > with
> > > > > > supporting them, but I did some research and experiments in the 
> > > > > > 2015/2016
> > > > > > time frame which a colleague, Bruno Bierbaumer, tested on his 
> > > > > > machine:
> > > > > > 
> > > > > > First of all, there's DPCD byte 3 bit 6 
> > > > > > (NO_AUX_HANDSHAKE_LINK_TRAINING)
> > > > > > which is documented as follows:
> > > > > > 
> > > > > >Does not require AUX CH handshake when the link 
> > > > > > configuration is
> > > > > >already known. [...] The known-good drive current and 
> > > > > > pre-emphasis
> > > > > >level (or those used in the last "full" link training with 
> > > > > > AUX CH
> > > > > >handshake) must be used when the link training is performed 
> > > > > > without
> > > > > >AUX CH handshake.
> > > > > > 
> > > > > > That bit is set on the MacBook Pros in question.
> > > > > I'll check one of the eDP-based systems I've been experimenting on to
> > > > > see if setting the VGA_SWITCHER_NEEDS_EDP_CONFIG capability in the
> > > > > handler is sufficient to make i915 avoid poking the AUX channel when
> > > > > it's mux-switched away. (This would be in addition to hacking the
> > > > > can_switch() callback in the GPU drivers to allow switching while 
> > > > > there
> > > > > are still active KMS clients for the purposes of this experiment, 
> > > > > unless
> > > > > somebody can point me to a tree with the WIP per-output switching 
> > > > > Daniel
> > > > > Vetter mentioned.
> > > > Two things: I thought (but not sure) that for the output switching
> > > > muxes we'd run vgaswitcheroo in a different mode, where it doesn't
> > > > check whether whether the

Re: [PATCH V6 1/4] backlight: qcom-wled: convert the wled bindings to .yaml format

2020-04-28 Thread Lee Jones

On Thu, 23 Apr 2020, Kiran Gunda wrote:

> Convert the qcom-wled bindings from .txt to .yaml format.
> Also replace PM8941 to WLED3 and PMI8998 to WLED4.
> 
> Signed-off-by: Kiran Gunda 
> Signed-off-by: Subbaraman Narayanamurthy 
> Acked-by: Daniel Thompson 
> ---
>  .../bindings/leds/backlight/qcom-wled.txt  | 154 ---
>  .../bindings/leds/backlight/qcom-wled.yaml | 208 
> +
>  2 files changed, 208 insertions(+), 154 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
>  create mode 100644 
> Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml

Needs a DT Ack.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V6 3/4] backlight: qcom-wled: Add WLED5 bindings

2020-04-28 Thread Lee Jones

On Thu, 23 Apr 2020, Kiran Gunda wrote:

> Add WLED5 specific bindings.
> 
> Signed-off-by: Kiran Gunda 
> Signed-off-by: Subbaraman Narayanamurthy 
> Acked-by: Daniel Thompson 
> ---
>  .../bindings/leds/backlight/qcom-wled.yaml | 59 
> --
>  1 file changed, 56 insertions(+), 3 deletions(-)

Needs a DT Ack.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/2] DRM: ARC: add HDMI 2.0 TX encoder support

On Tue, Apr 21, 2020 at 05:55:38PM +0200, Neil Armstrong wrote:
> On 15/04/2020 19:33, Daniel Vetter wrote:
> > On Wed, Apr 15, 2020 at 02:29:28AM +0300, Eugeniy Paltsev wrote:
> >> The Synopsys ARC SoCs (like HSDK4xD) include on-chip DesignWare HDMI
> >> encoders. Support them with a platform driver to provide platform glue
> >> data to the dw-hdmi driver.
> >>
> >> Acked-by: Sam Ravnborg 
> >> Signed-off-by: Eugeniy Paltsev 
> >> ---
> >>  MAINTAINERS   |   6 ++
> >>  drivers/gpu/drm/Makefile  |   2 +-
> >>  drivers/gpu/drm/arc/Kconfig   |   7 ++
> >>  drivers/gpu/drm/arc/Makefile  |   1 +
> >>  drivers/gpu/drm/arc/arc-dw-hdmi.c | 116 ++
> >>  5 files changed, 131 insertions(+), 1 deletion(-)
> >>  create mode 100644 drivers/gpu/drm/arc/arc-dw-hdmi.c
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index a6fbdf354d34..2aaed1190370 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -1258,6 +1258,12 @@ S:  Supported
> >>  F:drivers/gpu/drm/arc/
> >>  F:Documentation/devicetree/bindings/display/snps,arcpgu.txt
> >>  
> >> +ARC DW HDMI DRIVER
> >> +M:Eugeniy Paltsev 
> >> +S:Supported
> >> +F:drivers/gpu/drm/arc/arc-dw-hdmi.c
> >> +F:
> >> Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> >> +
> >>  ARCNET NETWORK LAYER
> >>  M:Michael Grzeschik 
> >>  L:net...@vger.kernel.org
> >> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> >> index 6493088a0fdd..5b0bcf7f45cd 100644
> >> --- a/drivers/gpu/drm/Makefile
> >> +++ b/drivers/gpu/drm/Makefile
> >> @@ -109,7 +109,7 @@ obj-y  += panel/
> >>  obj-y += bridge/
> >>  obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
> >>  obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
> >> -obj-$(CONFIG_DRM_ARCPGU)+= arc/
> >> +obj-y += arc/
> >>  obj-y += hisilicon/
> >>  obj-$(CONFIG_DRM_ZTE) += zte/
> >>  obj-$(CONFIG_DRM_MXSFB)   += mxsfb/
> >> diff --git a/drivers/gpu/drm/arc/Kconfig b/drivers/gpu/drm/arc/Kconfig
> >> index e8f3d63e0b91..baec9d2a4fba 100644
> >> --- a/drivers/gpu/drm/arc/Kconfig
> >> +++ b/drivers/gpu/drm/arc/Kconfig
> >> @@ -8,3 +8,10 @@ config DRM_ARCPGU
> >>  Choose this option if you have an ARC PGU controller.
> >>  
> >>  If M is selected the module will be called arcpgu.
> >> +
> >> +config DRM_ARC_DW_HDMI
> >> +  tristate "ARC DW HDMI"
> >> +  depends on DRM && OF
> >> +  select DRM_DW_HDMI
> >> +  help
> >> +Synopsys DW HDMI driver for various ARC development boards
> >> diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
> >> index c7028b7427b3..7a156d8c2c3c 100644
> >> --- a/drivers/gpu/drm/arc/Makefile
> >> +++ b/drivers/gpu/drm/arc/Makefile
> >> @@ -1,3 +1,4 @@
> >>  # SPDX-License-Identifier: GPL-2.0-only
> >>  arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_sim.o arcpgu_drv.o
> >>  obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
> >> +obj-$(CONFIG_DRM_ARC_DW_HDMI) += arc-dw-hdmi.o
> >> diff --git a/drivers/gpu/drm/arc/arc-dw-hdmi.c 
> >> b/drivers/gpu/drm/arc/arc-dw-hdmi.c
> >> new file mode 100644
> >> index ..46a6ee09b302
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/arc/arc-dw-hdmi.c
> >> @@ -0,0 +1,116 @@
> >> +// SPDX-License-Identifier: GPL-2.0+
> >> +//
> >> +// Synopsys DW HDMI driver for various ARC development boards
> >> +//
> >> +// Copyright (C) 2020 Synopsys
> >> +// Author: Eugeniy Paltsev 
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +static const struct dw_hdmi_mpll_config snps_hdmi_mpll_cfg[] = {
> >> +  {
> >> +  2700, {
> >> +  { 0x00B3, 0x },
> >> +  { 0x00B3, 0x },
> >> +  { 0x00B3, 0x }
> >> +  },
> >> +  }, {
> >> +  7425, {
> >> +  { 0x0072, 0x0001},
> >> +  { 0x0072, 0x0001},
> >> +  { 0x0072, 0x0001}
> >> +  },
> >> +  }, {
> >> +  14850, {
> >> +  { 0x0051, 0x0002},
> >> +  { 0x0051, 0x0002},
> >> +  { 0x0051, 0x0002}
> >> +  },
> >> +  }, {
> >> +  ~0UL, {
> >> +  { 0x00B3, 0x },
> >> +  { 0x00B3, 0x },
> >> +  { 0x00B3, 0x },
> >> +  },
> >> +  }
> >> +};
> >> +
> >> +static const struct dw_hdmi_curr_ctrl snps_hdmi_cur_ctr[] = {
> >> +  /* pixelclkbpp8bpp10   bpp12 */
> >> +  { 2700,  { 0x, 0x, 0x }, },
> >> +  { 7425,  { 0x0008, 0x0008, 0x0008 }, },
> >> +  { 14850, { 0x001b, 0x001b, 0x001b }, },
> >> +  { ~0UL,  { 0x, 0x, 0x }, }
> >> +};
> >> +
> >> +
> >> +static const struct dw_hdmi_phy_config snps_hdmi_phy_config[] = {
> >> +  /* pixelclk   symbol  termvlev */
> >> +  { 2700,   0x8009, 0x0004, 0x

Re: [PATCH] dma-buf: Fix SET_NAME ioctl uapi

2020-04-28 Thread Sumit Semwal

Thanks Daniel, Martin,

On Thu, 23 Apr 2020 at 20:21, Martin Liu  wrote:
>
> On Thu, Apr 09, 2020 at 09:28:16AM +0530, Sumit Semwal wrote:
> > Thanks for the patch, Daniel!
> >
> >
> > On Tue, 7 Apr 2020 at 19:00, Daniel Vetter  wrote:
> > >
> > > The uapi is the same on 32 and 64 bit, but the number isnt. Everyone
> > > who botched this please re-read:
> > >
> > > https://www.kernel.org/doc/html/v5.4-preprc-cpu/ioctl/botching-up-ioctls.html
> > >
> > > Also, the type argument for the ioctl macros is for the type the void
> > > __user *arg pointer points at, which in this case would be the
> > > variable-sized char[] of a 0 terminated string. So this was botched in
> > > more than just the usual ways.
> >
> > Yes, it shouldn't have passed through the cracks; my apologies!
> >
> > >
> > > Cc: Sumit Semwal 
> > > Cc: Chenbo Feng 
> > > Cc: Greg Hackmann 
> > > Cc: Daniel Vetter 
> > > Cc: linux-me...@vger.kernel.org
> > > Cc: linaro-mm-...@lists.linaro.org
> > > Cc: minc...@kernel.org
> > > Cc: sur...@google.com
> > > Cc: jenhaoc...@google.com
> > > Cc: Martin Liu 
> >
> > Martin,
> > Could I request you to test this one with the 4 combinations of 32-bit
> > / 64-bit userspace and kernel, and let us know that all 4 are working
> > alright? If yes, please consider giving your tested-by here.
> >
> Hi Sumit, Daniel,
> Sorry for being late to the tests. I finished the tests on 32/64 apps
> with 64 bit kernel and they were fine. Unfortunately, I couldn't have a 32
> bit kernel to run the tests somehow. However, this should work from the
> code logic. Hope this is okay to you and thanks for Todd's help.
>
> Tested-by: Martin Liu 
> Reviewed-by: Martin Liu 

Applied to drm-misc-fixes.
>
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/dma-buf/dma-buf.c| 3 ++-
> > >  include/uapi/linux/dma-buf.h | 4 
> > >  2 files changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > > index 570c923023e6..1d923b8e4c59 100644
> > > --- a/drivers/dma-buf/dma-buf.c
> > > +++ b/drivers/dma-buf/dma-buf.c
> > > @@ -388,7 +388,8 @@ static long dma_buf_ioctl(struct file *file,
> > >
> > > return ret;
> > >
> > > -   case DMA_BUF_SET_NAME:
> > > +   case DMA_BUF_SET_NAME_A:
> > > +   case DMA_BUF_SET_NAME_B:
> > > return dma_buf_set_name(dmabuf, (const char __user *)arg);
> > >
> > > default:
> > > diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
> > > index dbc7092e04b5..21dfac815dc0 100644
> > > --- a/include/uapi/linux/dma-buf.h
> > > +++ b/include/uapi/linux/dma-buf.h
> > > @@ -39,6 +39,10 @@ struct dma_buf_sync {
> > >
> > >  #define DMA_BUF_BASE   'b'
> > >  #define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync)
> > > +/* 32/64bitness of this uapi was botched in android, there's no 
> > > difference
> > > + * between them in actual uapi, they're just different numbers. */
> > >  #define DMA_BUF_SET_NAME   _IOW(DMA_BUF_BASE, 1, const char *)
> > > +#define DMA_BUF_SET_NAME_A _IOW(DMA_BUF_BASE, 1, u32)
> > > +#define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, u64)
> > >
> > >  #endif
> > > --
> > > 2.25.1
> > >
> > Best,
> > Sumit.
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dt-bindings: arm-smmu: Add a new compatible string and a clock

2020-04-28 Thread Sharat Masetty

This patch adds a new compatible string for sc7180 and also an
additional clock listing needed to power the TBUs and the TCU.

Signed-off-by: Sharat Masetty 
---
 Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml 
b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 6515dbe..15946ac 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -28,6 +28,7 @@ properties:
   - enum:
   - qcom,msm8996-smmu-v2
   - qcom,msm8998-smmu-v2
+  - qcom,sc7180-smmu-v2
   - qcom,sdm845-smmu-v2
   - const: qcom,smmu-v2
 
@@ -113,16 +114,22 @@ properties:
   present in such cases.
 
   clock-names:
+minItems: 2
+maxItems: 3
 items:
   - const: bus
   - const: iface
+  - const: mem_iface_clk
 
   clocks:
+minItems: 2
+maxItems: 3
 items:
   - description: bus clock required for downstream bus access and for the
   smmu ptw
   - description: interface clock required to access smmu's registers
   through the TCU's programming interface.
+  - description: clock required for the SMMU TBUs and the TCU
 
   power-domains:
 maxItems: 1
-- 
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported

2020-04-28 Thread Liviu Dudau

On Mon, Apr 27, 2020 at 07:22:02PM -0700, Peter Collingbourne wrote:
> On Mon, Apr 27, 2020 at 1:47 PM Eric Anholt  wrote:
> >
> > On Mon, Apr 27, 2020 at 1:05 PM Peter Collingbourne  wrote:
> > >
> > > Render nodes are not just useful for devices supporting GPU hardware
> > > acceleration. Even on devices that only support dumb frame buffers,
> > > they are useful in situations where composition (using software
> > > rasterization) and KMS are done in different processes with buffer
> > > sharing being used to send frame buffers between them. This is the
> > > situation on Android, where surfaceflinger is the compositor and the
> > > composer HAL uses KMS to display the buffers. Thus it is beneficial
> > > to expose render nodes on all devices that support buffer sharing.
> > >
> > > Because all drivers that currently support render nodes also support
> > > buffer sharing, the DRIVER_RENDER flag is no longer necessary to mark
> > > devices as supporting render nodes, so remove it and just rely on
> > > the presence of a prime_handle_to_fd function pointer to determine
> > > whether buffer sharing is supported.
> >
> > I'm definitely interested in seeing a patch like this land, as I think
> > the current state is an ugly historical artifact.  We just have to be
> > careful.
> >
> > Were there any instances of drivers with render engines exposing PRIME
> > but not RENDER?  We should be careful to make sure that we're not
> > exposing new privileges for those through adding render nodes.
> 
> These are the drivers that we'd be adding render nodes for with this change:
> 
> $ git grep -l prime_handle_to_fd (git grep -L DRIVER_RENDER (git grep
> -l '\.driver_features'))
> drivers/gpu/drm/arc/arcpgu_drv.c
> drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> drivers/gpu/drm/arm/hdlcd_drv.c
> drivers/gpu/drm/arm/malidp_drv.c
> drivers/gpu/drm/armada/armada_drv.c
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> drivers/gpu/drm/imx/imx-drm-core.c
> drivers/gpu/drm/ingenic/ingenic-drm.c
> drivers/gpu/drm/mcde/mcde_drv.c
> drivers/gpu/drm/mediatek/mtk_drm_drv.c
> drivers/gpu/drm/meson/meson_drv.c
> drivers/gpu/drm/mxsfb/mxsfb_drv.c
> drivers/gpu/drm/pl111/pl111_drv.c
> drivers/gpu/drm/qxl/qxl_drv.c
> drivers/gpu/drm/rcar-du/rcar_du_drv.c
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> drivers/gpu/drm/shmobile/shmob_drm_drv.c
> drivers/gpu/drm/sti/sti_drv.c
> drivers/gpu/drm/stm/drv.c
> drivers/gpu/drm/tilcdc/tilcdc_drv.c
> drivers/gpu/drm/tve200/tve200_drv.c
> drivers/gpu/drm/xen/xen_drm_front.c
> drivers/gpu/drm/zte/zx_drm_drv.c
> 
> Some of the drivers provide custom ioctls but they are already
> protected from render nodes by not setting DRM_RENDER_ALLOW. Another
> thing to check for is drivers providing custom fops that might expose
> something undesirable in the render node:
> 
> $ git grep -L 'DEFINE_DRM_GEM_CMA_FOPS\|DEFINE_DRM_GEM_FOPS' (git grep
> -l prime_handle_to_fd (git grep -L DRIVER_RENDER (git grep -l
> '\.driver_features')))
> drivers/gpu/drm/mediatek/mtk_drm_drv.c
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> drivers/gpu/drm/xen/xen_drm_front.c
> 
> But looking at those drivers in detail, I see that each of them is
> using the standard DRM fops handlers (which presumably already handle
> render nodes correctly) with the exception of mmap, which they provide
> wrappers for that mostly just wrap drm_gem_mmap.
> 
> So unless I'm missing something significant (which seems likely -- I'm
> not a DRM expert), I don't see a problem so far.
> 
> > There's a UAPI risk I see here.  Right now, on a system with a single
> > renderer GPU, we can just open /dev/dri/renderD128 and get the GPU for
> > rendering, and various things are relying on that (such as libwaffle,
> > used in piglit among other things)   Adding render nodes for kms-only
> > drivers could displace the actual GPU to 129, and the question is
> > whether this will be disruptive.  For Mesa, I think this works out,
> > because kmsro should load on the kms device's node and then share
> > buffers over to the real GPU that it digs around to find at init time.
> > Just saying, I'm not sure I know all of the userspace well enough to
> > say "this should be safe despite that"
> >
> > (And, maybe, if we decide that it's not safe enough, we could punt
> > kms-only drivers to a higher starting number?)
> 
> Android (minigbm) similarly tries to open /dev/dri/renderD$N in a loop
> with 128 <= N < 192 and assumes that the first non-blacklisted (i.e.
> not vgem) one that it can open corresponds to the real GPU [1]. I
> think that the risk of breaking something on Android is low since
> Android's architecture basically already depends on there being a
> render node, and it seems unlikely for a device to have more than one
> GPU, one of which would be non-functional.

Would Juno suffer from this issue? It has 2 HDLCD drivers (bo

Re: [PATCH v3 2/6] dt-bindings: display: Add hpd-gpios to panel-common bindings

On Thu, Apr 23, 2020 at 6:26 PM Douglas Anderson  wrote:

> In the cases where there is no connector in a system there's no great
> place to put "hpd-gpios".  As per discussion [1] the best place to put
> it is in the panel.  Add this to the device tree bindings.
>
> [1] https://lore.kernel.org/r/20200417180819.ge5...@pendragon.ideasonboard.com
>
> Signed-off-by: Douglas Anderson 
> Reviewed-by: Stephen Boyd 

Reviewed-by: Linus Walleij 

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

Re: [PATCH v3 3/6] drm/panel-simple: Support hpd-gpios for delaying prepare()

On Thu, Apr 23, 2020 at 6:26 PM Douglas Anderson  wrote:

> People use panel-simple when they have panels that are builtin to
> their device.  In these cases the HPD (Hot Plug Detect) signal isn't
> really used for hotplugging devices but instead is used for power
> sequencing.  Panel timing diagrams (especially for eDP panels) usually
> have the HPD signal in them and it acts as an indicator that the panel
> is ready for us to talk to it.
>
> Sometimes the HPD signal is hooked up to a normal GPIO on a system.
> In this case we need to poll it in the correct place to know that the
> panel is ready for us.  In some system designs the right place for
> this is panel-simple.
>
> When adding this support, we'll account for the case that there might
> be a circular dependency between panel-simple and the provider of the
> GPIO.  The case this was designed for was for the "ti-sn65dsi86"
> bridge chip.  If HPD is hooked up to one of the GPIOs provided by the
> bridge chip then in our probe function we'll always get back
> -EPROBE_DEFER.  Let's handle this by allowing this GPIO to show up
> late if we saw -EPROBE_DEFER during probe.  NOTE: since the
> gpio_get_optional() is used, if the "hpd-gpios" isn't there our
> variable will just be NULL and we won't do anything in prepare().
>
> Signed-off-by: Douglas Anderson 
> Reviewed-by: Stephen Boyd 
> ---
>
> Changes in v3:
> - Remind how gpio_get_optional() works in the commit message.

Reviewed-by: Linus Walleij 

I have a small inkling to protest against calling this driver "panel-simple"
as we tend to stockpile things like this.

I suppose panel-panacea.c is a better name at this point :/

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

Re: [PATCH v3 5/6] dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd

On Thu, Apr 23, 2020 at 6:26 PM Douglas Anderson  wrote:

> The ti-sn65dsi86 MIPI DSI to eDP bridge chip has a dedicated hardware
> HPD (Hot Plug Detect) pin on it, but it's mostly useless for eDP
> because of excessive debouncing in hardware.  Specifically there is no
> way to disable the debouncing and for eDP debouncing hurts you because
> HPD is just used for knowing when the panel is ready, not for
> detecting physical plug events.
>
> Currently the driver in Linux just assumes that nobody has HPD hooked
> up.  It relies on folks setting the "no-hpd" property in the panel
> node to specify that HPD isn't hooked up and then the panel driver
> using this to add some worst case delays when turning on the panel.
>
> Apparently it's also useful to specify "no-hpd" in the bridge node so
> that the bridge driver can make sure it's doing the right thing
> without peeking into the panel [1].  This would be used if anyone ever
> found it useful to implement support for the HW HPD pin on the bridge.
> Let's add this property to the bindings.
>
> NOTES:
> - This is somewhat of a backward-incompatible change.  All current
>   known users of ti-sn65dsi86 didn't have "no-hpd" specified in the
>   bridge node yet none of them had HPD hooked up.  This worked because
>   the current Linux driver just assumed that HPD was never hooked up.
>   We could make it less incompatible by saying that for this bridge
>   it's assumed HPD isn't hooked up _unless_ a property is defined, but
>   "no-hpd" is much more standard and it's unlikely to matter unless
>   someone quickly goes and implements HPD in the driver.
> - It is sensible to specify "no-hpd" at the bridge chip level and
>   specify "hpd-gpios" at the panel level.  That would mean HPD is
>   hooked up to some other GPIO in the system, just not the hardware
>   HPD pin on the bridge chip.
>
> [1] https://lore.kernel.org/r/20200417180819.ge5...@pendragon.ideasonboard.com
>
> Signed-off-by: Douglas Anderson 
> Reviewed-by: Stephen Boyd 

Makes sense to me so:
Reviewed-by: Linus Walleij 

> +  no-hpd:
> +type: boolean
> +description: Set if the HPD line on the bridge isn't hooked up to 
> anything.

I would perhaps tag on:
... or is otherwise unusable?

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

Re: [PATCH v3 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux

On Thu, Apr 23, 2020 at 6:26 PM Douglas Anderson  wrote:

> The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can
> be used as GPIOs in a system.  Each pin can be configured as input,
> output, or a special function for the bridge chip.  These are:
> - GPIO1: SUSPEND Input
> - GPIO2: DSIA VSYNC
> - GPIO3: DSIA HSYNC or VSYNC
> - GPIO4: PWM
>
> Let's expose these pins as GPIOs.  A few notes:
> - Access to ti-sn65dsi86 is via i2c so we set "can_sleep".
> - These pins can't be configured for IRQ.
> - There are no programmable pulls or other fancy features.
> - Keeping the bridge chip powered might be expensive.  The driver is
>   setup such that if all used GPIOs are only inputs we'll power the
>   bridge chip on just long enough to read the GPIO and then power it
>   off again.  Setting a GPIO as output will keep the bridge powered.
> - If someone releases a GPIO we'll implicitly switch it to an input so
>   we no longer need to keep the bridge powered for it.
>
> Because of all of the above limitations we just need to implement a
> bare-bones GPIO driver.  The device tree bindings already account for
> this device being a GPIO controller so we only need the driver changes
> for it.
>
> NOTE: Despite the fact that these pins are nominally muxable I don't
> believe it makes sense to expose them through the pinctrl interface as
> well as the GPIO interface.  The special functions are things that the
> bridge chip driver itself would care about and it can just configure
> the pins as needed.
>
> Signed-off-by: Douglas Anderson 
> Cc: Linus Walleij 
> Cc: Bartosz Golaszewski 

Pretty cool.

I wonder if this chip could use the generic regmap GPIO helpers
that we are working on when they come around?
https://lore.kernel.org/linux-gpio/20200423174543.17161-11-mich...@walle.cc/

> +#include 
> +#include 

Only  should be needed else you are doing
something wrong.

> + * @gchip:If we expose our GPIOs, this is used.
> + * @gchip_output: A cache of whether we've set GPIOs to output.  This
> + *serves double-duty of keeping track of the direction and
> + *also keeping track of whether we've incremented the
> + *pm_runtime reference count for this pin, which we do
> + *whenever a pin is configured as an output.

That sounds a bit hairy but I guess it's fine.

> + */
>  struct ti_sn_bridge {
> struct device   *dev;
> struct regmap   *regmap;
> @@ -102,6 +136,9 @@ struct ti_sn_bridge {
> struct gpio_desc*enable_gpio;
> struct regulator_bulk_data  supplies[SN_REGULATOR_SUPPLY_NUM];
> int dp_lanes;
> +
> +   struct gpio_chipgchip;
> +   DECLARE_BITMAP(gchip_output, SN_NUM_GPIOS);

Do you really need a bitmap for 4 bits? Can't you just have something
like an u8 and check bit 0,1,2,3 ... well I suppose it has some elegance to
it as well but... hm.

> +static struct ti_sn_bridge *gchip_to_pdata(struct gpio_chip *chip)
> +{
> +   return container_of(chip, struct ti_sn_bridge, gchip);
> +}
> +
> +static int ti_sn_bridge_gpio_get_direction(struct gpio_chip *chip,
> +  unsigned int offset)
> +{
> +   struct ti_sn_bridge *pdata = gchip_to_pdata(chip);

Is there some specific reason why you don't just use
gpiochip_get_data()?

> +   /*
> +* We already have to keep track of the direction because we use
> +* that to figure out whether we've powered the device.  We can
> +* just return that rather than (maybe) powering up the device
> +* to ask its direction.
> +*/
> +   return test_bit(offset, pdata->gchip_output) ?
> +   GPIOF_DIR_OUT : GPIOF_DIR_IN;
> +}

Don't use these legacy defines, they are for consumers.
Use GPIO_LINE_DIRECTION_IN  and GPIO_LINE_DIRECTION_OUT.
from 

> +   ret = regmap_read(pdata->regmap, SN_GPIO_IO_REG, &val);
> +   pm_runtime_put(pdata->dev);
> +
> +   if (ret)
> +   return ret;
> +
> +   return (val >> (SN_GPIO_INPUT_SHIFT + offset)) & 1;

My preferred way to do this is:

#include 

return !!(val & BIT(SN_GPIO_INPUT_SHIFT + offset));

> +static void ti_sn_bridge_gpio_set(struct gpio_chip *chip, unsigned int 
> offset,
> + int val)
> +{
> +   struct ti_sn_bridge *pdata = gchip_to_pdata(chip);
> +   int ret;
> +
> +   if (!test_bit(offset, pdata->gchip_output)) {
> +   dev_err(pdata->dev, "Ignoring GPIO set while input\n");
> +   return;
> +   }
> +
> +   val &= 1;
> +   ret = regmap_update_bits(pdata->regmap, SN_GPIO_IO_REG,
> +BIT(SN_GPIO_OUTPUT_SHIFT + offset),
> +val << (SN_GPIO_OUTPUT_SHIFT + offset));

Looks like a job for the generic helper library.

> +static int ti_sn_bridge_gpio_direction_input(st

Re: [PATCH v8 01/10] drm: bridge: dw_mipi_dsi: add initial regmap infrastructure

2020-04-28 Thread Enric Balletbo i Serra

Hi Adrian,

Thank you for your patch and to apply the changes I requested

On 27/4/20 10:19, Adrian Ratiu wrote:
> In order to support multiple versions of the Synopsis MIPI DSI host
> controller, which have different register layouts but almost identical
> HW protocols, we add a regmap infrastructure which can abstract away
> register accesses for platform drivers using the bridge.
> 
> The controller HW revision is detected during bridge probe which will
> be used in future commits to load the relevant register layout which
> the bridge will use transparently to the platform drivers.
> 
> Cc: Enric Balletbo Serra 
> Suggested-by: Ezequiel Garcia 
> Tested-by: Adrian Pop 
> Tested-by: Arnaud Ferraris 
> Signed-off-by: Adrian Ratiu 

Reviewed-by: Enric Balletbo i Serra 

> ---
> Chnages since v7:
>   - Minor checkpatch line fix
> 
> Changes since v6:
>   - Select REGMAP_MMIO in Kconfig (Enric)
>   - Drop unnecessary stack variable inits (Enric)
>   - Make bridge error ASAP after a bad revision read (Enric)
>   - Drop redundant read of hw_version in dphy_timing_config (Enric)
> 
> New in v5.
> ---
>  drivers/gpu/drm/bridge/synopsys/Kconfig   |   1 +
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 210 ++
>  2 files changed, 121 insertions(+), 90 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
> b/drivers/gpu/drm/bridge/synopsys/Kconfig
> index 21a1be3ced0f3..080146093b68e 100644
> --- a/drivers/gpu/drm/bridge/synopsys/Kconfig
> +++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
> @@ -39,3 +39,4 @@ config DRM_DW_MIPI_DSI
>   select DRM_KMS_HELPER
>   select DRM_MIPI_DSI
>   select DRM_PANEL_BRIDGE
> + select REGMAP_MMIO
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 5ef0f154aa7bd..34b8668ae24ea 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -227,6 +228,7 @@ struct dw_mipi_dsi {
>   struct drm_bridge *panel_bridge;
>   struct device *dev;
>   void __iomem *base;
> + struct regmap *regs;
>  
>   struct clk *pclk;
>  
> @@ -235,6 +237,7 @@ struct dw_mipi_dsi {
>   u32 lanes;
>   u32 format;
>   unsigned long mode_flags;
> + u32 hw_version;
>  
>  #ifdef CONFIG_DEBUG_FS
>   struct dentry *debugfs;
> @@ -249,6 +252,13 @@ struct dw_mipi_dsi {
>   const struct dw_mipi_dsi_plat_data *plat_data;
>  };
>  
> +static const struct regmap_config dw_mipi_dsi_regmap_cfg = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .name = "dw-mipi-dsi",
> +};
> +
>  /*
>   * Check if either a link to a master or slave is present
>   */
> @@ -280,16 +290,6 @@ static inline struct dw_mipi_dsi *bridge_to_dsi(struct 
> drm_bridge *bridge)
>   return container_of(bridge, struct dw_mipi_dsi, bridge);
>  }
>  
> -static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg, u32 val)
> -{
> - writel(val, dsi->base + reg);
> -}
> -
> -static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg)
> -{
> - return readl(dsi->base + reg);
> -}
> -
>  static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
>  struct mipi_dsi_device *device)
>  {
> @@ -366,8 +366,8 @@ static void dw_mipi_message_config(struct dw_mipi_dsi 
> *dsi,
>   if (lpm)
>   val |= CMD_MODE_ALL_LP;
>  
> - dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
> - dsi_write(dsi, DSI_CMD_MODE_CFG, val);
> + regmap_write(dsi->regs, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
> + regmap_write(dsi->regs, DSI_CMD_MODE_CFG, val);
>  }
>  
>  static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 
> hdr_val)
> @@ -375,20 +375,20 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct 
> dw_mipi_dsi *dsi, u32 hdr_val)
>   int ret;
>   u32 val, mask;
>  
> - ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
> -  val, !(val & GEN_CMD_FULL), 1000,
> -  CMD_PKT_STATUS_TIMEOUT_US);
> + ret = regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS,
> +val, !(val & GEN_CMD_FULL), 1000,
> +CMD_PKT_STATUS_TIMEOUT_US);
>   if (ret) {
>   dev_err(dsi->dev, "failed to get available command FIFO\n");
>   return ret;
>   }
>  
> - dsi_write(dsi, DSI_GEN_HDR, hdr_val);
> + regmap_write(dsi->regs, DSI_GEN_HDR, hdr_val);
>  
>   mask = GEN_CMD_EMPTY | GEN_PLD_W_EMPTY;
> - ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
> -  val, (val & mask) == mask,
> -  1000, CMD_PKT_STATUS_TIMEOUT_US);
> + ret = regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS,
> +

Re: [PATCH v1] staging: fbtft: fb_st7789v: Initialize the Display

On 09/04/20, Dan Carpenter wrote:
> On Thu, Apr 09, 2020 at 11:25:32AM +0200, Oliver Graute wrote:
> > From: Oliver Graute 
> > 
> > Set Gamma Values and Register Values for the HSD20_IPS
> > 
> > Signed-off-by: Oliver Graute 
> > ---
> >  drivers/staging/fbtft/fb_st7789v.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/staging/fbtft/fb_st7789v.c 
> > b/drivers/staging/fbtft/fb_st7789v.c
> > index 84c5af2dc9a0..b0aa96b703a8 100644
> > --- a/drivers/staging/fbtft/fb_st7789v.c
> > +++ b/drivers/staging/fbtft/fb_st7789v.c
> > @@ -17,8 +17,8 @@
> >  #define DRVNAME "fb_st7789v"
> >  
> >  #define DEFAULT_GAMMA \
> > -   "70 2C 2E 15 10 09 48 33 53 0B 19 18 20 25\n" \
> > -   "70 2C 2E 15 10 09 48 33 53 0B 19 18 20 25"
> > +   "D0 05 0A 09 08 05 2E 44 45 0F 17 16 2B 33\n" \
> > +   "D0 05 0A 09 08 05 2E 43 45 0F 16 16 2B 33"
> 
> How do you know this won't break someone else's setup?

Should I declare an extra define for my values?

+#define HSD20_IPS_GAMMA \
+   "D0 05 0A 09 08 05 2E 44 45 0F 17 16 2B 33\n" \
+   "D0 05 0A 09 08 05 2E 43 45 0F 16 16 2B 33"

> 
> Without knowing anything at all about this driver, it feels like this
> should be:
> 
>   if (new_hardware)
>   write_reg(par, PORCTRL, 0x05, 0x05, 0x00, 0x33, 0x33);
>   else
>   write_reg(par, PORCTRL, 0x08, 0x08, 0x00, 0x22, 0x22);

ok, I'll update this.

Best regards,

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

RE: [PATCH 0/3]

Hi All,

I noticed some API changes that were not present when I first wrote this 
driver. 
This will need correcting so I will send out a second version and respond 
to Sam Ravnborg's feedback at the same time. I recommend waiting for that
version before reviewing as this will not function on Linux-next otherwise.

Gareth

On Mon, Apr 27, 2020 at 09:21:49AM +0100, Gareth Williams wrote:
> 
> This series adds DRM support for the Digital Blocks db9000 LCD controller with
> RZ/N1 specific changes and updates simple-panel to include the associated
> panel. As this has not previously been documented, also include a yaml file to
> provide this.
> 
> Gareth Williams (3):
>   drm/db9000: Add Digital Blocks DB9000 LCD Controller
>   drm/db9000: Add bindings documentation for LCD controller
>   drm/panel: simple: Add Newhaven ATXL#-CTP panel
> 
>  .../devicetree/bindings/display/db9000,du.yaml |  87 ++
>  .../devicetree/bindings/vendor-prefixes.yaml   |   2 +
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/digital-blocks/Kconfig |  13 +
>  drivers/gpu/drm/digital-blocks/Makefile|   3 +
>  drivers/gpu/drm/digital-blocks/db9000-du.c | 953
> +
>  drivers/gpu/drm/digital-blocks/db9000-du.h | 192 +
>  drivers/gpu/drm/panel/panel-simple.c   |  27 +
>  9 files changed, 1280 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/display/db9000,du.yaml
>  create mode 100644 drivers/gpu/drm/digital-blocks/Kconfig
>  create mode 100644 drivers/gpu/drm/digital-blocks/Makefile
>  create mode 100644 drivers/gpu/drm/digital-blocks/db9000-du.c
>  create mode 100644 drivers/gpu/drm/digital-blocks/db9000-du.h
> 
> --
> 2.7.4

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

[PATCH net-next] dpaa2-eth: fix error return code in setup_dpni()

2020-04-28 Thread Wei Yongjun

Fix to return negative error code -ENOMEM from the error handling
case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun 
---
 drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c 
b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
index 8ec435ba7d27..11accab81ea1 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
@@ -2702,8 +2702,10 @@ static int setup_dpni(struct fsl_mc_device *ls_dev)
 
priv->cls_rules = devm_kzalloc(dev, sizeof(struct dpaa2_eth_cls_rule) *
   dpaa2_eth_fs_count(priv), GFP_KERNEL);
-   if (!priv->cls_rules)
+   if (!priv->cls_rules) {
+   err = -ENOMEM;
goto close;
+   }
 
return 0;



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

[PATCH net-next] ath11k: use GFP_ATOMIC under spin lock

2020-04-28 Thread Wei Yongjun

A spin lock is taken here so we should use GFP_ATOMIC.

Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Wei Yongjun 
---
 drivers/net/wireless/ath/ath11k/dp_rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c 
b/drivers/net/wireless/ath/ath11k/dp_rx.c
index f74a0e74bf3e..34b1e8e6a7fb 100644
--- a/drivers/net/wireless/ath/ath11k/dp_rx.c
+++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
@@ -892,7 +892,7 @@ int ath11k_peer_rx_tid_setup(struct ath11k *ar, const u8 
*peer_mac, int vdev_id,
else
hw_desc_sz = ath11k_hal_reo_qdesc_size(DP_BA_WIN_SZ_MAX, tid);
 
-   vaddr = kzalloc(hw_desc_sz + HAL_LINK_DESC_ALIGN - 1, GFP_KERNEL);
+   vaddr = kzalloc(hw_desc_sz + HAL_LINK_DESC_ALIGN - 1, GFP_ATOMIC);
if (!vaddr) {
spin_unlock_bh(&ab->base_lock);
return -ENOMEM;



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

[PATCH 3/3] drm/panel: simple: Add Newhaven ATXL#-CTP panel

This commit adds support for the Newhaven ATXL#-CTP panel used by the
Renesas RZ/N1 Demo Board.

Signed-off-by: Gareth Williams 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 5a93c4e..0b57b0e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2021,6 +2021,30 @@ static const struct panel_desc 
newhaven_nhd_43_480272ef_atxl = {
 DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE,
 };
 
+static const struct display_timing newhaven_nhd_50_800480tf_atxl_timing = {
+   .pixelclock = { 3330, 3340, 3350 },
+   .hactive = { 800, 800, 800 },
+   .hfront_porch = { 40, 40, 40 },
+   .hback_porch = { 88, 88, 88 },
+   .hsync_len = { 1, 1, 1 },
+   .vactive = { 480, 480, 480 },
+   .vfront_porch = { 13, 13, 13 },
+   .vback_porch = { 32, 32, 32 },
+   .vsync_len = { 3, 3, 3 },
+   .flags = DISPLAY_FLAGS_HSYNC_HIGH | DISPLAY_FLAGS_VSYNC_HIGH,
+};
+
+static const struct panel_desc newhaven_nhd_50_800480tf_atxl = {
+   .timings = &newhaven_nhd_50_800480tf_atxl_timing,
+   .num_timings = 1,
+   .bpc = 8,
+   .size = {
+   .width = 400,
+   .height = 300,
+   },
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+};
+
 static const struct display_timing nlt_nl192108ac18_02d_timing = {
.pixelclock = { 13000, 14835, 16300 },
.hactive = { 1920, 1920, 1920 },
@@ -2964,6 +2988,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "newhaven,nhd-4.3-480272ef-atxl",
.data = &newhaven_nhd_43_480272ef_atxl,
}, {
+   .compatible = "newhaven,nhd-5.0-800480tf-atxl",
+   .data = &newhaven_nhd_50_800480tf_atxl,
+   }, {
.compatible = "nlt,nl192108ac18-02d",
.data = &nlt_nl192108ac18_02d,
}, {
-- 
2.7.4

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

[PATCH] drm/mediatek: cleanup coding style in mediatek a bit

2020-04-28 Thread Bernard Zhao

This code change is to make code bit more readable.
Optimise array size align to HDMI macro define.
Add check if len is overange.

Signed-off-by: Bernard Zhao 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index ff43a3d80410..40fb5154ed5d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -311,15 +311,15 @@ static void mtk_hdmi_hw_send_info_frame(struct mtk_hdmi 
*hdmi, u8 *buffer,
u8 checksum;
int ctrl_frame_en = 0;
 
-   frame_type = *buffer;
-   buffer += 1;
-   frame_ver = *buffer;
-   buffer += 1;
-   frame_len = *buffer;
-   buffer += 1;
-   checksum = *buffer;
-   buffer += 1;
+   frame_type = *buffer++;
+   frame_ver = *buffer++;
+   frame_len = *buffer++;
+   checksum = *buffer++;
frame_data = buffer;
+   if ((frame_len + HDMI_INFOFRAME_HEADER_SIZE) > len) {
+   dev_err(hdmi->dev, "Wrong frame len: %d\n", frame_len;
+   return;
+   }
 
dev_dbg(hdmi->dev,
"frame_type:0x%x,frame_ver:0x%x,frame_len:0x%x,checksum:0x%x\n",
@@ -982,7 +982,7 @@ static int mtk_hdmi_setup_avi_infoframe(struct mtk_hdmi 
*hdmi,
struct drm_display_mode *mode)
 {
struct hdmi_avi_infoframe frame;
-   u8 buffer[17];
+   u8 buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_AVI_INFOFRAME_SIZE];
ssize_t err;
 
err = drm_hdmi_avi_infoframe_from_display_mode(&frame,
@@ -1008,7 +1008,7 @@ static int mtk_hdmi_setup_spd_infoframe(struct mtk_hdmi 
*hdmi,
const char *product)
 {
struct hdmi_spd_infoframe frame;
-   u8 buffer[29];
+   u8 buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_SPD_INFOFRAME_SIZE];
ssize_t err;
 
err = hdmi_spd_infoframe_init(&frame, vendor, product);
@@ -1031,7 +1031,7 @@ static int mtk_hdmi_setup_spd_infoframe(struct mtk_hdmi 
*hdmi,
 static int mtk_hdmi_setup_audio_infoframe(struct mtk_hdmi *hdmi)
 {
struct hdmi_audio_infoframe frame;
-   u8 buffer[14];
+   u8 buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_AUDIO_INFOFRAME_SIZE];
ssize_t err;
 
err = hdmi_audio_infoframe_init(&frame);
-- 
2.26.2

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

[PATCH v3 2/4] drm: ipk: Add DRM driver for DesignWare IPK DSI

Add support for Synopsys DesignWare VPG (Video Pattern Generator)
and DRM driver for Synopsys DesignWare DSI Host IPK solution.

This patch has to be applied on top of Daniel Vetter's implementation -
devm_drm_dev_alloc https://patchwork.freedesktop.org/patch/359897/ .

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sam Ravnborg 
Cc: Gustavo Pimentel 
Cc: Joao Pinto 
Signed-off-by: Angelo Ribeiro 
---
Changes since v3:
  - Changed Makefile to use '+=' instead of '\'.
  - Rearranged headers.
  - Replaced drm_mode_config_init by drmm_mode_config_init.
  - Droped DRM legacy functions.
  - Replaced DRM_xxx by drm_xxx.
  - Changed load function to devm_drm_dev_alloc.
  - Implemented pipeline as a drm_simple_display_pipe.
---
 drivers/gpu/drm/Kconfig  |   2 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/ipk/Kconfig  |  13 ++
 drivers/gpu/drm/ipk/Makefile |   4 +
 drivers/gpu/drm/ipk/dw-drv.c | 169 ++
 drivers/gpu/drm/ipk/dw-ipk.h |  26 +++
 drivers/gpu/drm/ipk/dw-vpg.c | 412 +++
 drivers/gpu/drm/ipk/dw-vpg.h |  48 +
 8 files changed, 675 insertions(+)
 create mode 100644 drivers/gpu/drm/ipk/Kconfig
 create mode 100644 drivers/gpu/drm/ipk/Makefile
 create mode 100644 drivers/gpu/drm/ipk/dw-drv.c
 create mode 100644 drivers/gpu/drm/ipk/dw-ipk.h
 create mode 100644 drivers/gpu/drm/ipk/dw-vpg.c
 create mode 100644 drivers/gpu/drm/ipk/dw-vpg.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 4359497..29ea1d1 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -388,6 +388,8 @@ source "drivers/gpu/drm/mcde/Kconfig"
 
 source "drivers/gpu/drm/tidss/Kconfig"
 
+source "drivers/gpu/drm/ipk/Kconfig"
+
 # Keep legacy drivers last
 
 menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f34d08c..b15f2ea 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -124,3 +124,4 @@ obj-$(CONFIG_DRM_PANFROST) += panfrost/
 obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
 obj-$(CONFIG_DRM_MCDE) += mcde/
 obj-$(CONFIG_DRM_TIDSS) += tidss/
+obj-$(CONFIG_DRM_IPK) += ipk/
diff --git a/drivers/gpu/drm/ipk/Kconfig b/drivers/gpu/drm/ipk/Kconfig
new file mode 100644
index 000..1f87444
--- /dev/null
+++ b/drivers/gpu/drm/ipk/Kconfig
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config DRM_IPK
+   tristate "DRM Support for Synopsys DesignWare IPK DSI"
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_PANEL_BRIDGE
+   select VIDEOMODE_HELPERS
+   help
+ Enable support for the Synopsys DesignWare DRM DSI.
+ To compile this driver as a module, choose M here: the module
+ will be called ipk-drm.
diff --git a/drivers/gpu/drm/ipk/Makefile b/drivers/gpu/drm/ipk/Makefile
new file mode 100644
index 000..6a1a911
--- /dev/null
+++ b/drivers/gpu/drm/ipk/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+ipk-drm-y := dw-drv.o dw-vpg.o
+
+obj-$(CONFIG_DRM_IPK) += ipk-drm.o
diff --git a/drivers/gpu/drm/ipk/dw-drv.c b/drivers/gpu/drm/ipk/dw-drv.c
new file mode 100644
index 000..5ff6cbf
--- /dev/null
+++ b/drivers/gpu/drm/ipk/dw-drv.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019-2020 Synopsys, Inc. and/or its affiliates.
+ * Synopsys DesignWare MIPI DSI DRM driver
+ *
+ * Author: Angelo Ribeiro 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dw-ipk.h"
+#include "dw-vpg.h"
+
+static const struct drm_mode_config_funcs dw_ipk_drm_modecfg_funcs = {
+   .fb_create = drm_gem_fb_create_with_dirty,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
+};
+
+static int dw_ipk_load(struct drm_device *drm)
+{
+   int ret;
+
+   ret = drmm_mode_config_init(drm);
+   if (ret)
+   return ret;
+
+   drm->mode_config.min_width = 0;
+   drm->mode_config.min_height = 0;
+
+   /* To handle orientation */
+   drm->mode_config.max_width = 2048;
+   drm->mode_config.max_height = 2048;
+
+   drm->mode_config.funcs = &dw_ipk_drm_modecfg_funcs;
+
+   /* TODO
+* Optional framebuffer memory resources allocation
+*/
+
+   ret = vpg_load(drm);
+   if (ret)
+   return ret;
+
+   /* Calls all the crtc's, encoder's and connector's reset */
+   drm_mode_config_reset(drm);
+
+   return ret;
+}
+
+static void dw_ipk_unload(struct drm_device *drm)
+{
+   drm_dbg(drm, "\n");
+   vpg_unload(drm);
+}
+
+DEFINE_DRM_GEM_CMA_FOPS(ipk_drm_driver_fops);
+
+static int dw_ipk_gem_cma_dumb_create(struct drm_file *file,
+ struct drm_device *dev,
+ struct drm_mode_create_dumb *args)
+{
+   u

[PATCH] drivers/video: cleanup coding style in video a bit

2020-04-28 Thread Bernard Zhao

Eliminate the magic numbers, add vender infoframe size macro
like other hdmi modules.

Signed-off-by: Bernard Zhao 
---
 drivers/video/hdmi.c | 2 +-
 include/linux/hdmi.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 856a8c4e84a2..f693076f2e5f 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -495,7 +495,7 @@ int hdmi_vendor_infoframe_init(struct hdmi_vendor_infoframe 
*frame)
 * value
 */
frame->s3d_struct = HDMI_3D_STRUCTURE_INVALID;
-   frame->length = 4;
+   frame->length = HDMI_VENDOR_INFOFRAME_SIZE;
 
return 0;
 }
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 9613d796cfb1..ff25aeb95ee4 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -57,6 +57,7 @@ enum hdmi_infoframe_type {
 #define HDMI_SPD_INFOFRAME_SIZE25
 #define HDMI_AUDIO_INFOFRAME_SIZE  10
 #define HDMI_DRM_INFOFRAME_SIZE26
+#define HDMI_VENDOR_INFOFRAME_SIZE  4
 
 #define HDMI_INFOFRAME_SIZE(type)  \
(HDMI_INFOFRAME_HEADER_SIZE + HDMI_ ## type ## _INFOFRAME_SIZE)
-- 
2.26.2

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

[PATCH] Remove drm_display_mode.hsync

2020-04-28 Thread Michal Orzel

As suggested by the TODO list of DRM subsystem:
-remove the member hsync of drm_display_mode
-convert code using hsync member to use drm_mode_hsync()

Signed-off-by: Michal Orzel 
---
 drivers/gpu/drm/drm_modes.c  |  6 +-
 drivers/gpu/drm/i915/display/intel_display.c |  1 -
 include/drm/drm_modes.h  | 10 --
 3 files changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index d4d6451..0340079 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -752,16 +752,12 @@ EXPORT_SYMBOL(drm_mode_set_name);
  * @mode: mode
  *
  * Returns:
- * @modes's hsync rate in kHz, rounded to the nearest integer. Calculates the
- * value first if it is not yet set.
+ * @modes's hsync rate in kHz, rounded to the nearest integer.
  */
 int drm_mode_hsync(const struct drm_display_mode *mode)
 {
unsigned int calc_val;
 
-   if (mode->hsync)
-   return mode->hsync;
-
if (mode->htotal <= 0)
return 0;
 
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 3468466..ec7e943 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8891,7 +8891,6 @@ void intel_mode_from_pipe_config(struct drm_display_mode 
*mode,
 
mode->clock = pipe_config->hw.adjusted_mode.crtc_clock;
 
-   mode->hsync = drm_mode_hsync(mode);
mode->vrefresh = drm_mode_vrefresh(mode);
drm_mode_set_name(mode);
 }
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 99134d4..7dab7f1 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -391,16 +391,6 @@ struct drm_display_mode {
int vrefresh;
 
/**
-* @hsync:
-*
-* Horizontal refresh rate, for debug output in human readable form. Not
-* used in a functional way.
-*
-* This value is in kHz.
-*/
-   int hsync;
-
-   /**
 * @picture_aspect_ratio:
 *
 * Field for setting the HDMI picture aspect ratio of a mode.
-- 
2.7.4

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

[PATCH v2 -next] soc: mediatek: Fix Kconfig warning

2020-04-28 Thread YueHaibing

WARNING: unmet direct dependencies detected for MTK_MMSYS
  Depends on [n]: (ARCH_MEDIATEK [=y] || COMPILE_TEST [=n]) && 
COMMON_CLK_MT8173_MMSYS [=n]
  Selected by [y]:
  - DRM_MEDIATEK [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARCH_MEDIATEK [=y] || 
ARM && COMPILE_TEST [=n]) && COMMON_CLK [=y] && HAVE_ARM_SMCCC [=y] && OF [=y]

Make MTK_MMSYS select COMMON_CLK_MT8173_MMSYS to fix this.

Fixes: 2c758e301ed9 ("soc / drm: mediatek: Move routing control to mmsys 
device")
Signed-off-by: YueHaibing 
---
v2: select COMMON_CLK_MT8173_MMSYS instead of adding DRM_MEDIATEK dependency  
---
 drivers/soc/mediatek/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index e84513318725..7f9da11e1a50 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -46,8 +46,7 @@ config MTK_SCPSYS
 
 config MTK_MMSYS
bool "MediaTek MMSYS Support"
-   depends on COMMON_CLK_MT8173_MMSYS
-   default COMMON_CLK_MT8173_MMSYS
+   select COMMON_CLK_MT8173_MMSYS
help
  Say yes here to add support for the MediaTek Multimedia
  Subsystem (MMSYS).
-- 
2.17.1


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

Re: [RESEND PATCH v3 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

2020-04-28 Thread Rasmus Villemoes

On 27/04/2020 16.53, Sakari Ailus wrote:
> Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> pixel formats denoted by fourccs. The fourcc encoding is the same for both
> so the same implementation can be used.
> 
> Suggested-by: Mauro Carvalho Chehab 
> Signed-off-by: Sakari Ailus 
> ---
> since v2:
> 
> - Add comments to explain why things are being done
> 
> - Print characters under 32 (space) as hexadecimals in parenthesis.
> 
> - Do not print spaces in the fourcc codes.
> 
> - Make use of a loop over the fourcc characters instead of
>   put_unaligned_le32(). This is necessary to omit spaces in the output.
> 
> - Use DRM style format instead of V4L2. This provides the precise code as
>   a numerical value as well as explicit endianness information.
> 
> - Added WARN_ON_ONCE() sanity checks. Comments on these are welcome; I'd
>   expect them mostly be covered by the tests.
> 
> - Added tests for %p4cc in lib/test_printf.c
> 
>  Documentation/core-api/printk-formats.rst | 12 
>  lib/test_printf.c | 17 +
>  lib/vsprintf.c| 86 +++
>  3 files changed, 115 insertions(+)
> 
> diff --git a/Documentation/core-api/printk-formats.rst 
> b/Documentation/core-api/printk-formats.rst
> index 8ebe46b1af39..7aa0451e06fb 100644
> --- a/Documentation/core-api/printk-formats.rst
> +++ b/Documentation/core-api/printk-formats.rst
> @@ -545,6 +545,18 @@ For printing netdev_features_t.
>  
>  Passed by reference.
>  
> +V4L2 and DRM FourCC code (pixel format)
> +---
> +
> +::
> +
> + %p4cc
> +
> +Print a FourCC code used by V4L2 or DRM, including format endianness and
> +its numerical value as hexadecimal.
> +
> +Passed by reference.
> +
>  Thanks
>  ==
>  
> diff --git a/lib/test_printf.c b/lib/test_printf.c
> index 2d9f520d2f27..a14754086707 100644
> --- a/lib/test_printf.c
> +++ b/lib/test_printf.c
> @@ -624,6 +624,22 @@ static void __init fwnode_pointer(void)
>   software_node_unregister_nodes(softnodes);
>  }
>  
> +static void __init fourcc_pointer(void)
> +{
> + struct {
> + u32 code;
> + char *str;
> + } const try[] = {
> + { 0x20104646, "FF(10) little-endian (0x20104646)", },
> + { 0xa0104646, "FF(10) big-endian (0xa0104646)", },
> + { 0x10111213, "(13)(12)(11)(10) little-endian (0x10111213)", },
> + };
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(try); i++)
> + test(try[i].str, "%p4cc", &try[i].code);
> +}
> +
>  static void __init
>  errptr(void)
>  {
> @@ -668,6 +684,7 @@ test_pointer(void)
>   flags();
>   errptr();
>   fwnode_pointer();
> + fourcc_pointer();
>  }
>  
>  static void __init selftest(void)
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 7c488a1ce318..02e7906619c0 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1721,6 +1721,89 @@ char *netdev_bits(char *buf, char *end, const void 
> *addr,
>   return special_hex_number(buf, end, num, size);
>  }
>  
> +static noinline_for_stack
> +char *fourcc_string(char *buf, char *end, const u32 *__fourcc,
> + struct printf_spec spec, const char *fmt)
> +{
> +#define FOURCC_HEX_CHAR_STR  "(xx)"
> +#define FOURCC_BIG_ENDIAN_STR" big-endian"
> +#define FOURCC_LITTLE_ENDIAN_STR " little-endian"
> +#define FOURCC_HEX_NUMBER" (0x01234567)"
> +#define FOURCC_STRING_MAX\
> + FOURCC_HEX_CHAR_STR FOURCC_HEX_CHAR_STR FOURCC_HEX_CHAR_STR \
> + FOURCC_HEX_CHAR_STR FOURCC_LITTLE_ENDIAN_STR FOURCC_HEX_NUMBER
> + struct printf_spec my_spec = {
> + .type = FORMAT_TYPE_UINT,
> + .field_width = 2,
> + .flags = SMALL,
> + .base = 16,
> + .precision = -1,
> + };
> + char __s[sizeof(FOURCC_STRING_MAX)];
> + char *s = __s;
> + unsigned int i;
> + /*
> +  * The 31st bit defines the endianness of the data, so save its printing
> +  * for later.
> +  */
> + u32 fourcc = *__fourcc & ~BIT(31);
> + int ret;

Dereference __fourcc ...

> + if (check_pointer(&buf, end, __fourcc, spec))
> + return buf;

.. and then sanity check it?

> + if (fmt[1] != 'c' || fmt[2] != 'c')
> + return error_string(buf, end, "(%p4?)", spec);

Doesn't that want to come before everything else, including the
check_pointer()?

> + for (i = 0; i < sizeof(fourcc); i++, fourcc >>= 8) {
> + unsigned char c = fourcc;
> +
> + /* Weed out spaces */
> + if (c == ' ')
> + continue;
> +
> + /* Print non-control characters as-is */
> + if (c > ' ') {
> + *s = c;
> + s++;
> + continue;
> + }

Are you sure you want to pass non-ascii characters thro

[PATCH] drm/vkms: Hold gem object while still in-use

2020-04-28 Thread Ezequiel Garcia

We need to keep the reference to the drm_gem_object
until the last access by vkms_dumb_create.

Therefore, the put the object after it is used.

This fixes a use-after-free issue reported by syzbot.

While here, change vkms_gem_create() symbol to static.

Reported-and-tested-by: syzbot+e3372a2afe1e7ef04...@syzkaller.appspotmail.com
Signed-off-by: Ezequiel Garcia 
---
 drivers/gpu/drm/vkms/vkms_drv.h |  5 -
 drivers/gpu/drm/vkms/vkms_gem.c | 11 ++-
 2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index eda04ffba7b1..f4036bb0b9a8 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -117,11 +117,6 @@ struct drm_plane *vkms_plane_init(struct vkms_device 
*vkmsdev,
  enum drm_plane_type type, int index);
 
 /* Gem stuff */
-struct drm_gem_object *vkms_gem_create(struct drm_device *dev,
-  struct drm_file *file,
-  u32 *handle,
-  u64 size);
-
 vm_fault_t vkms_gem_fault(struct vm_fault *vmf);
 
 int vkms_dumb_create(struct drm_file *file, struct drm_device *dev,
diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
index 2e01186fb943..c541fec57566 100644
--- a/drivers/gpu/drm/vkms/vkms_gem.c
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -97,10 +97,10 @@ vm_fault_t vkms_gem_fault(struct vm_fault *vmf)
return ret;
 }
 
-struct drm_gem_object *vkms_gem_create(struct drm_device *dev,
-  struct drm_file *file,
-  u32 *handle,
-  u64 size)
+static struct drm_gem_object *vkms_gem_create(struct drm_device *dev,
+ struct drm_file *file,
+ u32 *handle,
+ u64 size)
 {
struct vkms_gem_object *obj;
int ret;
@@ -113,7 +113,6 @@ struct drm_gem_object *vkms_gem_create(struct drm_device 
*dev,
return ERR_CAST(obj);
 
ret = drm_gem_handle_create(file, &obj->gem, handle);
-   drm_gem_object_put_unlocked(&obj->gem);
if (ret)
return ERR_PTR(ret);
 
@@ -142,6 +141,8 @@ int vkms_dumb_create(struct drm_file *file, struct 
drm_device *dev,
args->size = gem_obj->size;
args->pitch = pitch;
 
+   drm_gem_object_put_unlocked(gem_obj);
+
DRM_DEBUG_DRIVER("Created object of size %lld\n", size);
 
return 0;
-- 
2.26.0.rc2

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

Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin

2020-04-28 Thread Jian-Hong Pan

Hi Maxime,

Thanks for your V2 patch series!  I'm testing it.

This patch series is applied upon mainline kernel 5.7-rc2 cleanly and built.
System can boot into console text mode, but no graphic UI.

Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]:

[5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46
[5.587700] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi' 
already present!
[5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi mapping 
ok
[5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name!
[5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops)
[5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46
[5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already present!
[5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi mapping 
ok
[5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name!
[5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops)
[5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops)
[5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops)
[5.588934] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops)
[5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops)
[5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops)
[5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops)
[5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops)
[5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops)
[5.589294] checking generic (3e513000 6d8c00) vs hw (0 )
[5.589297] fb0: switching to vc4drmfb from simple
[5.589433] Console: switching to colour dummy device 80x25
[5.589481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[5.601079] [ cut here ]
[5.601095] WARNING: CPU: 2 PID: 127 at 
drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078
[5.601097] Modules linked in:
[5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted 
5.7.0-rc2-00091-ga181df59a930 #7
[5.601105] Hardware name: Raspberry Pi 4 Model B (DT)
[5.601112] Workqueue: events deferred_probe_work_func
[5.601116] pstate: 2005 (nzCv daif -PAN -UAO)
[5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078
[5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0
[5.601124] sp : 80001217b410
[5.601126] x29: 80001217b410 x28: ec6370f0 
[5.601129] x27: f650d400 x26: 8a50 
[5.601132] x25: 8000113b4ac0 x24: 2060 
[5.601135] x23: 0a50 x22: 0300 
[5.601137] x21: 08d9ee20 x20: ec535080 
[5.601140] x19: 00010989e7c0 x18:  
[5.601142] x17: 0001 x16: 5207 
[5.601145] x15: 4932ad293c92 x14: 0137 
[5.601147] x13: 800010015000 x12: 0001 
[5.601150] x11: 0001 x10:  
[5.601152] x9 :  x8 : 800010015038 
[5.601154] x7 : 0001 x6 : 80001217b368 
[5.601157] x5 :  x4 : 004c 
[5.601159] x3 :  x2 : 8000113b4ac0 
[5.601162] x1 : 8000120c5f44 x0 : dc8984ff 
[5.601164] Call trace:
[5.601169]  vc5_hdmi_phy_init+0x7ac/0x2078
[5.601172]  vc4_hdmi_encoder_enable+0x1b8/0x1ac0
[5.601176]  drm_atomic_helper_commit_modeset_enables+0x224/0x248
[5.601179]  vc4_atomic_complete_commit+0x400/0x558
[5.601182]  vc4_atomic_commit+0x1e0/0x200
[5.601185]  drm_atomic_commit+0x4c/0x60
[5.601190]  drm_client_modeset_commit_atomic.isra.0+0x17c/0x238
[5.601192]  drm_client_modeset_commit_locked+0x5c/0x198
[5.601195]  drm_client_modeset_commit+0x30/0x58
[5.601201]  drm_fb_helper_restore_fbdev_mode_unlocked+0x78/0xe0
[5.601204]  drm_fb_helper_set_par+0x30/0x68
[5.601208]  fbcon_init+0x3d4/0x598
[5.601212]  visual_init+0xb0/0x108
[5.601214]  do_bind_con_driver+0x1d0/0x3a8
[5.601217]  do_take_over_console+0x144/0x208
[5.601219]  do_fbcon_takeover+0x68/0xd8
[5.601222]  fbcon_fb_registered+0x100/0x118
[5.601226]  register_framebuffer+0x1f4/0x338
[5.601229]  __drm_fb_helper_initial_config_and_unlock+0x2f8/0x4a0
[5.601232]  drm_fbdev_client_hotplug+0xd4/0x1b0
[5.601235]  drm_fbdev_generic_setup+0xb0/0x130
[5.601238]  vc4_drm_bind+0x184/0x1a0
[5.601241]  try_to_bring_up_master+0x168/0x1c8
[5.601244]  __component_add+0xa4/0x170
[5.601246]  component_add+0x14/0x20
[5.601248]  vc4_vec_dev_probe+0x20/0x30
[5.601252]  platform_drv_probe+0x54/0xa8
[5.601254]  really_probe+0xd8/0x320
[5.601256]  driver_probe_device+0x58/0xf0
[5.601258]  __device_attach_driver+0x84/0xc8
[5.601263]  bus_for_each_drv+0x78/0xc8
[5.601265]  __device_attach

Re: [PATCH v1] staging: fbtft: fb_st7789v: enabled inversion

On 09/04/20, Dan Carpenter wrote:
> On Thu, Apr 09, 2020 at 11:24:05AM +0200, Oliver Graute wrote:
> > From: Oliver Graute 
> > 
> > Enable inversion mode
> 
> What the heck is an inversion mode and why would you want it?


Should I name it:

Enable MIPI_DCS_ENTER_INVERT_MODE

Best Regards,

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

[PATCH 0/3]

This series adds DRM support for the Digital Blocks db9000
LCD controller with RZ/N1 specific changes and updates simple-panel to
include the associated panel. As this has not previously been
documented, also include a yaml file to provide this.

Gareth Williams (3):
  drm/db9000: Add Digital Blocks DB9000 LCD Controller
  drm/db9000: Add bindings documentation for LCD controller
  drm/panel: simple: Add Newhaven ATXL#-CTP panel

 .../devicetree/bindings/display/db9000,du.yaml |  87 ++
 .../devicetree/bindings/vendor-prefixes.yaml   |   2 +
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/digital-blocks/Kconfig |  13 +
 drivers/gpu/drm/digital-blocks/Makefile|   3 +
 drivers/gpu/drm/digital-blocks/db9000-du.c | 953 +
 drivers/gpu/drm/digital-blocks/db9000-du.h | 192 +
 drivers/gpu/drm/panel/panel-simple.c   |  27 +
 9 files changed, 1280 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/db9000,du.yaml
 create mode 100644 drivers/gpu/drm/digital-blocks/Kconfig
 create mode 100644 drivers/gpu/drm/digital-blocks/Makefile
 create mode 100644 drivers/gpu/drm/digital-blocks/db9000-du.c
 create mode 100644 drivers/gpu/drm/digital-blocks/db9000-du.h

-- 
2.7.4

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

Linux GOP initialization is wrong

2020-04-28 Thread David Santamaría Rogado

This is related to the issues at least on some devices for panel
orientation quirks where added.

My tests have been done over a Lenovo ideapad D330.

This devices like the other ones that need panel orientation quirks,
shows the initramfs with wrong stride and x and y swapped. By applying
the panel orientation quirks this gets solved but many parts of the
systems components needs to be patched. Hans has done a great job with
plymouth, mutter... but always appears a new problem derived as for
example vnc desktop sharing with this devices doesn't work and the
output is send messed up.

The strange thing is that bootloaders like GRUB or rEFInd seems to be
able to handle this and they paint themselves right, despite when
booting Windows directly Windows paints itself right and booted with
GRUB or rEFInd the first second also paint itself wrong. Haven't
tested this too much but the interesting thing is in the next
paragraph.

I decided to get the UEFI GOP video modes and found that the D330 have
these ones:
Mode 0: 1200x1920
Mode 1: 640x480
Mode 2: 800x600
Mode 3: 1024x768
Mode 4: 1920x1200 (this is the default one started by the firmware)
Mode 5: 480x640
Mode 6: 600x800
Mode 7: 768x1024

So I thought that Linux is taking the first mode despite is not the
active one and that's why the display is messed up.

Playing a little I could modify the GOP video mode before booting with
the UEFI Shell by simple using the mode 150 101. This causes GOP video
mode 5 to be switched to video mode 0, the first one. Booting now
makes initramfs messages to be correctly rendered but in the wrong
orientation.

A look at drivers/firmware/efi/libstub/gop.c seems to be what is
happening, the first available video mode is used despite it could not
be the active one in GOP and the active mode is not switched to the
discovered one by Linux. Both GRUB and rEFInd are able to respect the
video mode that GOP has active so it's possible to boot them landscape
and portrait while being correctly rendered.

I think the video mode should not be the first discovered one but the
active one, or at least, the highest resolution video mode that
respects the orientation.

I still have to test what Windows do if I try to boot it with the
video mode 0 active instead the default firmware mode 5, but I guess
it just select the highest resolution available where the x > y, and I
don't think this is the perfect approach, if some manufacturer wants
to make a portrait booting device it only will be possible by
respecting when the resolution is portrait or landscape while
searching the highest of them.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/db9000: Add bindings documentation for LCD controller

Add the DT bindings information for the Digital Blocks DB9000 LCD
controller. Also include documentation for the Renesas RZN1 specific
compatible string.

Signed-off-by: Gareth Williams 
---
 .../devicetree/bindings/display/db9000,du.yaml | 87 ++
 .../devicetree/bindings/vendor-prefixes.yaml   |  2 +
 2 files changed, 89 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/db9000,du.yaml

diff --git a/Documentation/devicetree/bindings/display/db9000,du.yaml 
b/Documentation/devicetree/bindings/display/db9000,du.yaml
new file mode 100644
index 000..73a9311
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/db9000,du.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/db9000,du.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DB9000 LCD Controller
+
+maintainers:
+- Gareth Williams 
+
+description: |
+  This is an LCD controller by Digital Blocks available for SoCs. The DB9000
+  controller reads from the framebuffer to display on a single RGB interface.
+  Output may be formatted in RGB or BGR. The driver also supports the PWM
+  logic that is included with the controller.
+
+properties:
+
+  compatible:
+oneOf:
+  - const: digital-blocks,drm-db9000
+  - const: digital-blocks,drm-rzn1
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: |
+  A phandle and clock-specifier pair to be used as a pixel clock.
+
+  clock-names:
+   items:
+  - const: lcd_eclk
+
+  port:
+type: object
+description: The panel endpoint connection.
+
+  bits-per-pixel:
+description: |
+Default is 24. This selects the number of bits used to represent
+a single pixel within the controller.
+$ref: "/schemas/types.yaml#/definitions/uint32"
+enum: [8, 16, 24, 32]
+
+  bus-width:
+description: |
+   The width of the interface to the LCD panel. This is needed
+   if the bits-per-pixel property is set to 16 or less, but the board
+   connects to a 24-bit panel. In which case, the controller will shift the
+   16-bit data to the most significant bits of the device. Default is 24.
+
+  "#pwm-cells":
+const: 2
+
+required:
+  - compatible
+  - "#pwm-cells"
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - port
+
+examples:
+  - |+
+drm@53004000 {
+  compatible = "digital-blocks,drm-db9000";
+  reg = <0x53004000 0x1000>;
+  interrupts = <10 97 120>;
+  clocks = <&sysctrl 26>;
+  clock-names = "clk_slcd";
+  bus-width = <24>;
+  pinctrl-0 = <&pins_lcd>;
+  #pwm-cells = <2>;
+
+  port {
+drm_point: endpoint@0 {
+  remote-endpoint = <&display_in>;
+};
+  };
+};
+...
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 6992bbb..138f76e 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -235,6 +235,8 @@ patternProperties:
 description: Shenzhen Yagu Electronic Technology Co., Ltd.
   "^digi,.*":
 description: Digi International Inc.
+  "^digital-blocks,.*":
+description: Digital Blocks, Inc.
   "^digilent,.*":
 description: Diglent, Inc.
   "^dioo,.*":
-- 
2.7.4

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

Re: [PATCH v1] staging: fbtft: fb_st7789v: Initialize the Display

On 27/04/20, Dan Carpenter wrote:
> On Mon, Apr 27, 2020 at 10:36:42AM +0200, Oliver Graute wrote:
> > On 09/04/20, Dan Carpenter wrote:
> > > On Thu, Apr 09, 2020 at 11:25:32AM +0200, Oliver Graute wrote:
> > > > From: Oliver Graute 
> > > > 
> > > > Set Gamma Values and Register Values for the HSD20_IPS
> > > > 
> > > > Signed-off-by: Oliver Graute 
> > > > ---
> > > >  drivers/staging/fbtft/fb_st7789v.c | 12 ++--
> > > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/drivers/staging/fbtft/fb_st7789v.c 
> > > > b/drivers/staging/fbtft/fb_st7789v.c
> > > > index 84c5af2dc9a0..b0aa96b703a8 100644
> > > > --- a/drivers/staging/fbtft/fb_st7789v.c
> > > > +++ b/drivers/staging/fbtft/fb_st7789v.c
> > > > @@ -17,8 +17,8 @@
> > > >  #define DRVNAME "fb_st7789v"
> > > >  
> > > >  #define DEFAULT_GAMMA \
> > > > -   "70 2C 2E 15 10 09 48 33 53 0B 19 18 20 25\n" \
> > > > -   "70 2C 2E 15 10 09 48 33 53 0B 19 18 20 25"
> > > > +   "D0 05 0A 09 08 05 2E 44 45 0F 17 16 2B 33\n" \
> > > > +   "D0 05 0A 09 08 05 2E 43 45 0F 16 16 2B 33"
> > > 
> > > How do you know this won't break someone else's setup?
> > 
> > Should I declare an extra define for my values?
> > 
> > +#define HSD20_IPS_GAMMA \
> > +   "D0 05 0A 09 08 05 2E 44 45 0F 17 16 2B 33\n" \
> > +   "D0 05 0A 09 08 05 2E 43 45 0F 16 16 2B 33"
> > 
> 
> That's fine, but it can't be a compile time thing.  Both types of
> hardware have to be working/available at run time.

ok, what is the proper way to handover the gamma values during run time?

Best Regards,

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

[PATCH v9 3/3] drm/bridge: add it6505 driver

2020-04-28 Thread allen

From: Allen Chen 

This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.

Signed-off-by: Jitao Shi 
Signed-off-by: Yilun Lin 
Signed-off-by: Allen Chen 
Signed-off-by: Pi-Hsun Shih 
---
 drivers/gpu/drm/bridge/Kconfig  |7 +
 drivers/gpu/drm/bridge/Makefile |1 +
 drivers/gpu/drm/bridge/ite-it6505.c | 3136 +++
 3 files changed, 3144 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 6ec945f..9897162 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -47,6 +47,13 @@ config DRM_LVDS_CODEC
  Support for transparent LVDS encoders and decoders that don't
  require any configuration.
 
+config DRM_ITE_IT6505
+   tristate "ITE IT6505 DP bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ ITE IT6505 DP bridge chip driver.
+
 config DRM_MEGACHIPS_STDP_GE_B850V3_FW
tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b04ac2d..ed14813 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
 obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
 obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
+obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
b/drivers/gpu/drm/bridge/ite-it6505.c
new file mode 100644
index ..4cf4401
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -0,0 +1,3136 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* Vendor option */
+#define AUDIO_SELECT I2S
+#define AUDIO_TYPE LPCM
+#define AUDIO_SAMPLE_RATE SAMPLE_RATE_48K
+#define AUDIO_CHANNEL_COUNT 2
+
+/*
+ * 0: Standard I2S
+ * 1: 32bit I2S
+ */
+#define I2S_INPUT_FORMAT 1
+
+/*
+ * 0: Left-justified
+ * 1: Right-justified
+ */
+#define I2S_JUSTIFIED 0
+
+/*
+ * 0: Data delay 1T correspond to WS
+ * 1: No data delay correspond to WS
+ */
+#define I2S_DATA_DELAY 0
+
+/*
+ * 0: Left channel
+ * 1: Right channel
+ */
+#define I2S_WS_CHANNEL 0
+
+/*
+ * 0: MSB shift first
+ * 1: LSB shift first
+ */
+#define I2S_DATA_SEQUENCE 0
+
+/*
+ * IT6505 maximum link rate
+ * RBR : 1.62 Gbps/lane
+ * HBR : 2.7  Gbps/lane
+ * HBR2: 5.4  Gbps/lane
+ * HBR3: 8.1  Gbps/lane
+ */
+#define MAX_LINK_RATE HBR
+
+/* IT6505 maximum lane count */
+#define MAX_LANE_COUNT 4
+
+#define TRAINING_LINK_RATE HBR
+#define TRAINING_LANE_COUNT 4
+#define ENABLE_DP_LANE_SWAP 0
+#define AUX_WAIT_TIMEOUT_MS 15
+#define PIXEL_CLK_DELAY 1
+#define PIXEL_CLK_INVERSE 0
+#define ADJUST_PHASE_THRESHOLD 8
+#define MAX_PIXEL_CLK 95000
+#define DEFAULT_DRV_HOLD 0
+#define DEFAULT_PWR_ON 0
+#define AUX_FIFO_MAX_SIZE 0x10
+
+/*
+ * Vendor option afe settings for different platforms
+ * 0: for bitland 10e, quanta zde
+ * 1: for google kukui p1/p2, huaqin krane
+ */
+
+static u8 afe_setting_table[2][3] = {
+   {0, 0, 0},
+   {0x93, 0x2A, 0x85}
+};
+
+enum it6505_sys_state {
+   SYS_UNPLUG = 0,
+   SYS_HPD,
+   SYS_TRAIN,
+   SYS_WAIT,
+   SYS_TRAINFAIL,
+   SYS_HDCP,
+   SYS_NOROP,
+   SYS_UNKNOWN,
+};
+
+enum it6505_audio_select {
+   I2S = 0,
+   SPDIF,
+};
+
+enum it6505_audio_sample_rate {
+   SAMPLE_RATE_24K = 0x6,
+   SAMPLE_RATE_32K = 0x3,
+   SAMPLE_RATE_48K = 0x2,
+   SAMPLE_RATE_96K = 0xA,
+   SAMPLE_RATE_192K = 0xE,
+   SAMPLE_RATE_44_1K = 0x0,
+   SAMPLE_RATE_88_2K = 0x8,
+   SAMPLE_RATE_176_4K = 0xC,
+};
+
+enum it6505_audio_type {
+   LPCM = 0,
+   NLPCM,
+   DSS,
+};
+
+enum it6505_audio_word_length {
+   WORD_LENGTH_16BIT = 0,
+   WORD_LENGTH_18BIT,
+   WORD_LENGTH_20BIT,
+   WORD_LENGTH_24BIT,
+};
+
+/*
+ * Audio Sample Word Length
+ * WORD_LENGTH_16BIT
+ * WORD_LENGTH_18BIT
+ * WORD_LENGTH_20BIT
+ * WORD_LENGTH_24BIT
+ */
+#define AUDIO_WORD_LENGTH WORD_LENGTH_24BIT
+
+enum it6505_link_rate {
+   RBR,
+   HBR,
+   HBR2,
+   HBR3,
+};
+
+struct it6505_audio_sample_rate_map {
+   enum it6505_audio_sample_rate rate;
+   int sample_rate_value;
+};
+
+struct it6505_platform_data {
+   struct regulator *pwr18;
+   struct regulator *

Re: KASAN: use-after-free Read in vkms_dumb_create

2020-04-28 Thread syzbot

Hello,

syzbot tried to test the proposed patch but build/boot failed:

failed to apply patch:
checking file drivers/gpu/drm/vkms/vkms_gem.c
patch:  unexpected end of file in patch



Tested on:

commit: c578ddb3 Merge tag 'linux-kselftest-5.7-rc3' of git://git...
git tree:   
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
dashboard link: https://syzkaller.appspot.com/bug?extid=e3372a2afe1e7ef04bc7
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
patch:  https://syzkaller.appspot.com/x/patch.diff?x=165806efe0

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

Re: Re: KASAN: use-after-free Read in vkms_dumb_create

2020-04-28 Thread syzbot

> On Mon, 27 Apr 2020 at 00:48, syzbot
>  wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:c578ddb3 Merge tag 'linux-kselftest-5.7-rc3' of git://git...
>> git tree:   upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=10fbf0d810
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=b7a70e992f2f9b68
>> dashboard link: https://syzkaller.appspot.com/bug?extid=e3372a2afe1e7ef04bc7
>> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
>> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1543833010
>>
>> Bisection is inconclusive: the first bad commit could be any of:
>>
>> 85b5bafb drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()
>> dff1c703 drm/tinydrm: Use drm_fbdev_generic_setup()
>> 23167fa9 drm/panel: simple: Add support for Rocktech RK070ER9427 LCD panel
>> 9060d7f4 drm/fb-helper: Finish the generic fbdev emulation
>> 2230ca12 dt-bindings: display: Document the EDT et* displays in one file.
>> e896c132 drm/debugfs: Add internal client debugfs file
>> 894a677f drm/cma-helper: Use the generic fbdev emulation
>> aa7e6455 drm/panel: Add support for the EDT ETM0700G0BDH6
>> 244007ec drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
>> aad34de2 drm/panel: Add support for the EDT ETM0700G0EDH6
>> 7a6aca49 dt-bindings: Add vendor prefix for DLC Display Co., Ltd.
>> d536540f drm/fb-helper: Add generic fbdev emulation .fb_probe function
>> 0ca0c827 drm/panel: simple: Add DLC DLC0700YZG-1 panel
>> c76f0f7c drm: Begin an API for in-kernel clients
>> 5ba57bab drm: vkms: select DRM_KMS_HELPER
>> 5fa8e4a2 drm/panel: Make of_drm_find_panel() return an ERR_PTR() instead of 
>> NULL
>> 008095e0 drm/vc4: Add support for the transposer block
>> c59eb3cf drm/panel: Let of_drm_find_panel() return -ENODEV when the panel is 
>> disabled
>> 1ebe99a7 drm/vc4: Call drm_atomic_helper_fake_vblank() in the commit path
>> 2e64a174 drm/of: Make drm_of_find_panel_or_bridge() fail when the device is 
>> disabled
>> 1b9883ea drm/vc4: Support the case where the DSI device is disabled
>> 6fb42b66 drm/atomic: Call fake_vblank() from the generic commit_tail() 
>> helpers
>> b0b7aa40 dt-bindings: display: Add DT bindings for BOE HV070WSA-100 panel
>> b25c60af drm/crtc: Add a generic infrastructure to fake VBLANK events
>> 184d3cf4 drm/vc4: Use wait_for_flip_done() instead of wait_for_vblanks()
>> ae8cf41b drm/panel: simple: Add support for BOE HV070WSA-100 panel to 
>> simple-panel
>> 814bde99 drm/connector: Make ->atomic_commit() optional
>> 955f60db drm: Add support for extracting sync signal drive edge from 
>> videomode
>> 3b39ad7a drm/panel: simple: Add newhaven, nhd-4.3-480272ef-atxl LCD
>> 425132fd drm/connector: Pass a drm_connector_state to ->atomic_commit()
>> a5d2ade6 drm/panel: simple: Add support for Innolux G070Y2-L01
>> b82c1f8f drm/atomic: Avoid connector to writeback_connector casts
>> 03fa9aa3 dt-bindings: Add DataImage, Inc. vendor prefix
>> 73915b2b drm/writeback: Fix the "overview" section of the doc
>> 97ceb1fb drm/panel: simple: Add support for DataImage SCF0700C48GGU18
>> e22e9531 Merge drm-upstream/drm-next into drm-misc-next
>> 3d5664f9 drm/panel: ili9881c: Fix missing assignment to error return ret
>> a0120245 drm/crc: Only report a single overflow when a CRC fd is opened
>> 7ad4e463 drm/panel: p079zca: Refactor panel driver to support multiple panels
>> 8adbbb2e drm/stm: ltdc: rework reset sequence
>> 48bd379a drm/panel: p079zca: Add variable unprepare_delay properties
>> 7868e507 drm/stm: ltdc: filter mode pixel clock vs pad constraint
>> 731edd4c dt-bindings: Add Innolux P097PFG panel bindings
>> f8878bb2 drm: print plane state normalized zpos value
>> ca52bea9 drm/atomic-helper: Use bitwise or for filling a bitmask
>> de04a462 drm/panel: p079zca: Support Innolux P097PFG panel
>> 2bb7a39c dt-bindings: Add vendor prefix for kingdisplay
>> a65020d0 drm/v3d: Fix a grammar nit in the scheduler docs.
>> 2dd4f211 drm/v3d: Add missing v3d documentation structure.
>> ebc950fd dt-bindings: Add KINGDISPLAY KD097D04 panel bindings
>> cd0e0ca6 drm/panel: type promotion bug in s6e8aa0_read_mtp_id()
>> e0d01811 drm/v3d: Remove unnecessary dma_fence_ops.
>> 624bb0c0 drm/v3d: Delay the scheduler timeout if we're still making progress.
>> b6d83fcc drm/panel: p079zca: Use of_device_get_match_data()
>> 408633d2 drm/v3d: use new return type vm_fault_t in v3d_gem_fault
>> decac6b0 dt-bindings: display: sun4i-drm: Add R40 display engine compatible
>> 0b7510d1 drm/tilcdc: Use drm_connector_has_possible_encoder()
>> d978a94b drm/sun4i: Add R40 display engine compatible
>> af11942e drm/sun4i: tcon-top: Cleanup clock handling
>> f8222409 drm/msm: Use drm_connector_has_possible_encoder()
>> 38cb8d96 drm: Add drm_connector_has_possible_encoder()
>> da82107e drm/sun4i: tcon: Release node when traversing of graph
>> 7a667775 dt-bindings: display: sun4i-drm: Add R40 TV TCON description
>> 7b71ca24 drm/radeon: Use drm_connector_for_each_possible_enc

[PATCH 1/3] drm/db9000: Add Digital Blocks DB9000 LCD Controller

Add DRM support for the Digital Blocks DB9000 LCD Controller
with the Renesas RZ/N1 specific changes.

Signed-off-by: Gareth Williams 
---
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/digital-blocks/Kconfig |  13 +
 drivers/gpu/drm/digital-blocks/Makefile|   3 +
 drivers/gpu/drm/digital-blocks/db9000-du.c | 953 +
 drivers/gpu/drm/digital-blocks/db9000-du.h | 192 ++
 6 files changed, 1164 insertions(+)
 create mode 100644 drivers/gpu/drm/digital-blocks/Kconfig
 create mode 100644 drivers/gpu/drm/digital-blocks/Makefile
 create mode 100644 drivers/gpu/drm/digital-blocks/db9000-du.c
 create mode 100644 drivers/gpu/drm/digital-blocks/db9000-du.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 3c88420..159832d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -280,6 +280,8 @@ source "drivers/gpu/drm/mgag200/Kconfig"
 
 source "drivers/gpu/drm/cirrus/Kconfig"
 
+source "drivers/gpu/drm/digital-blocks/Kconfig"
+
 source "drivers/gpu/drm/armada/Kconfig"
 
 source "drivers/gpu/drm/atmel-hlcdc/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9f0d2ee..f525807 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_DRM_MGAG200) += mgag200/
 obj-$(CONFIG_DRM_V3D)  += v3d/
 obj-$(CONFIG_DRM_VC4)  += vc4/
 obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
+obj-$(CONFIG_DRM_DB9000) += digital-blocks/
 obj-$(CONFIG_DRM_SIS)   += sis/
 obj-$(CONFIG_DRM_SAVAGE)+= savage/
 obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
diff --git a/drivers/gpu/drm/digital-blocks/Kconfig 
b/drivers/gpu/drm/digital-blocks/Kconfig
new file mode 100644
index 000..436a7c0
--- /dev/null
+++ b/drivers/gpu/drm/digital-blocks/Kconfig
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: GPL-2.0
+config DRM_DB9000
+   bool "DRM Support for DB9000 LCD Controller"
+   depends on DRM && (ARCH_MULTIPLATFORM || COMPILE_TEST)
+   select DRM_KMS_HELPER
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_PANEL_BRIDGE
+   select VIDEOMODE_HELPERS
+   select FB_PROVIDE_GET_FB_UNMAPPED_AREA if FB
+
+   help
+ Enable DRM support for the DB9000 LCD controller.
diff --git a/drivers/gpu/drm/digital-blocks/Makefile 
b/drivers/gpu/drm/digital-blocks/Makefile
new file mode 100644
index 000..9f78492
--- /dev/null
+++ b/drivers/gpu/drm/digital-blocks/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_DRM_DB9000) += db9000-du.o
diff --git a/drivers/gpu/drm/digital-blocks/db9000-du.c 
b/drivers/gpu/drm/digital-blocks/db9000-du.c
new file mode 100644
index 000..d84d446
--- /dev/null
+++ b/drivers/gpu/drm/digital-blocks/db9000-du.c
@@ -0,0 +1,953 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2019 Renesas Electronics Europe Ltd.
+ *
+ * Author: Gareth Williams 
+ *
+ * Based on ltdc.c
+ * Copyright (C) STMicroelectronics SA 2017
+ *
+ * Authors: Philippe Cornu 
+ *  Yannick Fertre 
+ *  Fabien Dessenne 
+ *  Mickael Reulier 
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "db9000-du.h"
+
+#define NR_CRTC1
+#define DB9000_FB_MAX_WIDTH4095
+#define DB9000_FB_MAX_HEIGHT   4095
+#define RZN1_REGS  ((void *) 1)
+
+static const u32 db9000_fmts[] = {
+   DRM_FORMAT_RGB888,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB1555,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_BGR888,
+   DRM_FORMAT_BGR565,
+   DRM_FORMAT_XBGR1555,
+   DRM_FORMAT_XBGR
+};
+
+static u32 reg_read(void __iomem *base, u32 reg)
+{
+   return readl(base + reg);
+}
+
+static void reg_write(void __iomem *base, u32 reg, u32 val)
+{
+   writel(val, base + reg);
+}
+
+static struct db9000_device *crtc_to_db9000(struct drm_crtc *crtc)
+{
+   return container_of(crtc->dev, struct db9000_device, drm);
+}
+
+static struct db9000_device *plane_to_db9000(struct drm_plane *plane)
+{
+   return container_of(plane->dev, struct db9000_device, drm);
+}
+
+static struct db9000_device *pwm_chip_to_db9000(struct pwm_chip *chip)
+{
+   return container_of(chip, struct db9000_device, pwm);
+}
+
+void db9000_bpp_setup(struct db9000_device *db9000_dev, int bpp, int bus_width,
+ bool pixelSelect)
+{
+   u32 format;
+   u32 reg_cr1 = reg_read(db9000_dev->regs, DB9000_CR1);
+
+   /* reset the BPP bits */
+   reg_cr1 &= ~DB9000_CR1_BPP(7);
+   reg_cr1 &= ~DB9000_CR1_OPS(5);
+   reg_cr1 &= ~DB9000_CR1_OPS(1);
+   db9000_dev->bpp = bpp;
+
+   switch (bpp) {
+   case 16:
+   if (pixelSelect) {
+

Re: [PATCH net-next] ath11k: use GFP_ATOMIC under spin lock

2020-04-28 Thread Kalle Valo

Wei Yongjun  wrote:

> A spin lock is taken here so we should use GFP_ATOMIC.
> 
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
> Signed-off-by: Wei Yongjun 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

69c93f9674c9 ath11k: use GFP_ATOMIC under spin lock

-- 
https://patchwork.kernel.org/patch/11511711/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 3/4] drm: ipk: Add extensions for DW MIPI DSI Host driver

Add Synopsys DesignWare IPK specific extensions for Synopsys DesignWare
MIPI DSI Host driver.

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sam Ravnborg 
Cc: Gustavo Pimentel 
Cc: Joao Pinto 
Signed-off-by: Angelo Ribeiro 
---
Changes since v3:
  - Rearranged headers.
---
 drivers/gpu/drm/ipk/Kconfig   |   9 +
 drivers/gpu/drm/ipk/Makefile  |   2 +
 drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c | 557 ++
 3 files changed, 568 insertions(+)
 create mode 100644 drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c

diff --git a/drivers/gpu/drm/ipk/Kconfig b/drivers/gpu/drm/ipk/Kconfig
index 1f87444..49819e5 100644
--- a/drivers/gpu/drm/ipk/Kconfig
+++ b/drivers/gpu/drm/ipk/Kconfig
@@ -11,3 +11,12 @@ config DRM_IPK
  Enable support for the Synopsys DesignWare DRM DSI.
  To compile this driver as a module, choose M here: the module
  will be called ipk-drm.
+
+config DRM_IPK_DSI
+   tristate "Synopsys DesignWare IPK specific extensions for MIPI DSI"
+   depends on DRM_IPK
+   select DRM_DW_MIPI_DSI
+   help
+ Choose this option for Synopsys DesignWare IPK MIPI DSI support.
+ To compile this driver as a module, choose M here: the module
+ will be called dw-mipi-dsi-ipk.
diff --git a/drivers/gpu/drm/ipk/Makefile b/drivers/gpu/drm/ipk/Makefile
index 6a1a911..f22d590 100644
--- a/drivers/gpu/drm/ipk/Makefile
+++ b/drivers/gpu/drm/ipk/Makefile
@@ -2,3 +2,5 @@
 ipk-drm-y := dw-drv.o dw-vpg.o
 
 obj-$(CONFIG_DRM_IPK) += ipk-drm.o
+
+obj-$(CONFIG_DRM_IPK_DSI) += dw-mipi-dsi-ipk.o
diff --git a/drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c 
b/drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c
new file mode 100644
index 000..f8ac4ca
--- /dev/null
+++ b/drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c
@@ -0,0 +1,557 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019-2020 Synopsys, Inc. and/or its affiliates.
+ * Synopsys DesignWare MIPI DSI solution driver
+ *
+ * Author: Angelo Ribeiro 
+ * Author: Luis Oliveira 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DW_DPHY_LPCLK_CTRL 0x94
+#define DW_DPHY_RSTZ   0xA0
+#define DW_DPHY_IF_CFG 0xA4
+#define DW_DPHY_ULPS_CTRL  0xA8
+#define DW_DPHY_TX_TRIGGERS0xAC
+#define DW_DPHY_STATUS 0xB0
+#define DW_DPHY_TST_CTRL0  0xB4
+#define DW_DPHY_TST_CTRL1  0xB8
+#define DW_GEN3_IF_TESTER  0x3c
+#define DW_GEN3_IF_SOC_PLL 0x48
+#define DW_GEN3_IF_SOC_PLL_EN  0x4C
+
+#define DW_12BITS_DPHY_RDY_L0  0x507
+#define DW_12BITS_DPHY_RDY_L1  0x707
+#define DW_12BITS_DPHY_RDY_L2  0x907
+#define DW_12BITS_DPHY_RDY_L3  0xB07
+
+#define DW_LANE_MIN_KBPS   8
+#define DW_LANE_MAX_KBPS   25
+#define DW_DPHY_DIV_UPPER_LIMIT8000
+#define DW_DPHY_DIV_LOWER_LIMIT2000
+#define DW_MIN_OUTPUT_FREQ 80
+#define DW_LPHS_TIM_TRANSIONS  0x40
+
+enum dw_glueiftester {
+   GLUE_LOGIC = 0x4,
+   RX_PHY = 0x2,
+   TX_PHY = 0x1,
+   RESET = 0x0,
+};
+
+struct dw_range_dphy {
+   u32 freq;
+   u8 hs_freq_range;
+   u32 osc_freq_target;
+} dw_range_gen3[] = {
+   { 80, 0x00, 0x3f }, { 90, 0x10, 0x3f }, { 100, 0x20, 0x3f },
+   { 110, 0x30, 0x39 }, { 120, 0x01, 0x39 }, { 130, 0x11, 0x39 },
+   { 140, 0x21, 0x39 }, { 150, 0x31, 0x39 }, { 160, 0x02, 0x39 },
+   { 170, 0x12, 0x2f }, { 180, 0x22, 0x2f }, { 190, 0x32, 0x2f },
+   { 205, 0x03, 0x2f }, { 220, 0x13, 0x29 }, { 235, 0x23, 0x29 },
+   { 250, 0x33, 0x29 }, { 275, 0x04, 0x29 }, { 300, 0x14, 0x29 },
+   { 325, 0x25, 0x29 }, { 350, 0x35, 0x1f }, { 400, 0x05, 0x1f },
+   { 450, 0x16, 0x19 }, { 500, 0x26, 0x19 }, { 550, 0x37, 0x19 },
+   { 600, 0x07, 0x19 }, { 650, 0x18, 0x19 }, { 700, 0x28, 0x0f },
+   { 750, 0x39, 0x0f }, { 800, 0x09, 0x0f }, { 850, 0x19, 0x0f },
+   { 900, 0x29, 0x09 }, { 950, 0x3a, 0x09 }, { 1000, 0x0a, 0x09 },
+   { 1050, 0x1a, 0x09 }, { 1100, 0x2a, 0x09 }, { 1150, 0x3b, 0x09 },
+   { 1200, 0x0b, 0x09 }, { 1250, 0x1b, 0x09 }, { 1300, 0x2b, 0x09 },
+   { 1350, 0x3c, 0x03 }, { 1400, 0x0c, 0x03 }, { 1450, 0x1c, 0x03 },
+   { 1500, 0x2c, 0x03 }, { 1550, 0x3d, 0x03 }, { 1600, 0x0d, 0x03 },
+   { 1650, 0x1d, 0x03 }, { 1700, 0x2e, 0x03 }, { 1750, 0x3e, 0x03 },
+   { 1800, 0x0e, 0x03 }, { 1850, 0x1e, 0x03 }, { 1900, 0x2f, 0x03 },
+   { 1950, 0x3f, 0x03 }, { 2000, 0x0f, 0x03 }, { 2050, 0x40, 0x03 },
+   { 2100, 0x41, 0x03 }, { 2150, 0x42, 0x03 }, { 2200, 0x43, 0x03 },
+   { 2250, 0x44, 0x03 }, {  2300, 0x45, 0x01 }, { 2350, 0x46, 0x01 },
+   { 2400, 0x47, 0x01 }, {  2450, 0x48, 0x01 }, { 2500, 0x49, 0x01 }
+};
+
+struct dw_dsi_ipk {
+   void __iomem *base;
+   void __iomem *base_phy;
+   struct clk *pllref_clk;
+   struct dw_mipi_dsi *dsi;
+   u32 lane_min_kbps;
+   u32 lane_max_kbps;
+   int range;
+   int in_div;
+

[PATCH v3 4/4] MAINTAINERS: Add IPK MIPI DSI Host driver entry

Creates entry for Synopsys DesignWare IPK DRM driver and
adds myself as maintainer.

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sam Ravnborg 
Cc: Gustavo Pimentel 
Cc: Joao Pinto 
Signed-off-by: Angelo Ribeiro 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ad29107..9f4ee9c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5507,6 +5507,14 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 F: Documentation/devicetree/bindings/display/ste,mcde.txt
 F: drivers/gpu/drm/mcde/
 
+DRM DRIVER FOR SYNOPSYS DESIGNWARE IPK
+M: Angelo Ribeiro 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+F: drivers/gpu/drm/ipk/
+F: Documentation/devicetree/bindings/display/ipk/
+T: git git://anongit.freedesktop.org/drm/drm-misc
+
 DRM DRIVER FOR TDFX VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/tdfx/
-- 
2.7.4

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

Re: [PATCH] drm/mediatek: stop iterating dma addresses when sg_dma_len() == 0

2020-04-28 Thread Anand K. Mistry

On Sun, 26 Apr 2020 at 18:04, Chun-Kuang Hu  wrote:

> Hi, Anand:
>
> Anand K Mistry  於 2020年4月20日 週一 下午2:09寫道：
> >
> > If dma_map_sg() merges pages when creating the mapping, only the first
> > entries will have a valid sg_dma_address() and sg_dma_len(), followed by
> > entries with sg_dma_len() == 0.
> >
> > Signed-off-by: Anand K Mistry 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_drm_gem.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > index b04a3c2b111e09..f8fd8b98c30e3d 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > @@ -224,6 +224,9 @@ struct drm_gem_object
> *mtk_gem_prime_import_sg_table(struct drm_device *dev,
> >
> > expected = sg_dma_address(sg->sgl);
> > for_each_sg(sg->sgl, s, sg->nents, i) {
> > +   if (!sg_dma_len(s))
> > +   break;
>
> I think this should be 'continue'
>

scatterlist.h has the comment:
/*
 * These macros should be used after a dma_map_sg call has been done
 * to get bus addresses of each of the SG entries and their lengths.
 * You should only work with the number of sg entries dma_map_sg
 * returns, or alternatively stop on the first sg_dma_len(sg) which
 * is 0.
 */

So breaking on the first sg_dma_len(sg) == 0 appears to be (one of) the
documented approach.


> Regards,
> Chun-Kuang.
>
> > +
> > if (sg_dma_address(s) != expected) {
> > DRM_ERROR("sg_table is not contiguous");
> > ret = -EINVAL;
> > --
> > 2.26.1.301.g55bc3eb7cb9-goog
> >
> >
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/mediatek: cleanup coding style in mediatek a bit

2020-04-28 Thread Markus Elfring

> This code change is to make code bit more readable.
> Optimise array size align to HDMI macro define.
> Add check if len is overange.

I find it safer to handle also such source code adjustments
by a small patch series together with improved commit messages.

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

[PATCH v3 1/4] dt-bindings: display: Add IPK DSI subsystem bindings

Add dt-bindings for Synopsys DesignWare MIPI DSI Host and VPG (Video
Pattern Generator) support in the IPK display subsystem.

The Synopsys DesignWare IPK display video pipeline is composed by a DSI
controller (snps,dw-ipk-dsi) and a VPG (snps,dw-ipk-vpg) as DPI
stimulus. Typically is used the Raspberry Pi
(raspberrypi,7inch-touchscreen-panel) as DSI panel that requires a
I2C controller (snps,designware-i2c).

Reported-by: Rob Herring 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sam Ravnborg 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Gustavo Pimentel 
Cc: Joao Pinto 
Signed-off-by: Angelo Ribeiro 
---
Changes since v3:
  - Fixed dt-binding breaking on `make dt_binding_check`.

Changes since v2:
  - Fixed dt-bindings issues, see
https://patchwork.ozlabs.org/patch/1260819/.
---
 .../bindings/display/snps,dw-ipk-dsi.yaml  | 159 +
 .../bindings/display/snps,dw-ipk-vpg.yaml  |  73 ++
 2 files changed, 232 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/snps,dw-ipk-vpg.yaml

diff --git a/Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.yaml 
b/Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.yaml
new file mode 100644
index 000..af4b775
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.yaml
@@ -0,0 +1,159 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/snps,dw-ipk-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare IPK specific extensions for the Synopsys DSI host
+   controller.
+
+maintainers:
+  - Angelo Ribeiro 
+
+description: |
+  The Synopsys DesignWare IPK DSI controller uses the Synopsys DesignWare MIPI
+  DSI host controller.
+  For more info refer to
+  Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt.
+
+properties:
+  '#address-cells':
+const: 1
+
+  '#size-cells':
+const: 0
+
+  compatible:
+items:
+  - const: snps,dw-ipk-dsi
+  - const: snps,dw-mipi-dsi
+
+  reg:
+items:
+  - description: DW MIPI DSI Host registers
+  - description: DW MIPI DSI Phy test-chip registers
+minItems: 2
+
+  reg-names:
+items:
+ - const: dsi
+ - const: phy
+minItems: 2
+
+  clocks:
+items:
+  - description: Peripheral clock
+  - description: PLL clock
+  - description: Pixel clock
+minItems: 2
+
+  clock-names:
+items:
+  - const: pclk
+  - const: ref
+  - const: px_clk
+minItems: 2
+
+  resets:
+items:
+  - description: APB reset line
+minItems: 1
+
+  reset-names:
+items:
+  - const: apb
+minItems: 1
+
+  ports:
+type: object
+description: |
+  A port node containging a DSI input and outuput port nodes as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt and
+  Documentation/devicetree/bindings/graph.txt.
+properties:
+  port@0:
+type: object
+description: Input endpoint of the controller, connects to a DPI 
source.
+
+  port@1:
+type: object
+description: Output endpoint of the controller, connects to a panel or
+  a bridge input port.
+
+required:
+  - port@0
+  - port@1
+
+additionalProperties: false
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+  - resets
+  - reset-names
+  - ports
+
+examples:
+  - |
+dsi1: dw-ipk-dsi@2000 {
+compatible = "snps,dw-ipk-dsi";
+reg = <0x02000 0xfff>, <0x05000 0xfff>;
+reg-names = "dsi", "phy";
+clocks = <&apb_clk>, <&pll_clk>;
+clock-names = "pclk", "ref";
+resets = <&ipk_rst 1>;
+reset-names = "apb";
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+dsi1_in: endpoint {
+remote-endpoint = <&vbridge_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+dsi_out_port: endpoint {
+remote-endpoint = <&panel_dsi_port>;
+};
+};
+};
+};
+
+i2c: i2c@1000 {
+compatible = "snps,designware-i2c";
+reg = <0x01000 0x100>;
+clock-frequency = <40>;
+clocks = <&i2cclk>;
+interrupts = <0>;
+resets = <&ipk_rst 0>;
+reset-names = "i2c";
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+lcd@45 {
+compatible = "raspberrypi,7inch-touchscreen-panel";
+reg = <0x45>;
+
+port {
+panel_dsi_port: endpoint {
+remote-endpoint = <&dsi_out_port>;
+};
+

Re: [PATCH v7 06/12] ARM: DTS: omap4: add sgx gpu child node

2020-04-28 Thread H. Nikolaus Schaller

Hi Paul,

> Am 26.04.2020 um 14:50 schrieb Paul Cercueil :
> 
> Hi Nikolaus,
> 
> Le ven. 24 avril 2020 à 22:34, H. Nikolaus Schaller  a 
> écrit :
>> Add SGX GPU node with interrupt. Tested on PandaBoard ES.
>> Since omap4420/30/60 and omap4470 come with different SGX variants
>> we need to introduce a new omap4470.dtsi. If an omap4470 board
>> does not want to use SGX it is no problem to still include
>> omap4460.dtsi.
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
>> arch/arm/boot/dts/omap4.dtsi   | 11 ++-
>> arch/arm/boot/dts/omap4470.dts | 15 +++
>> 2 files changed, 21 insertions(+), 5 deletions(-)
>> create mode 100644 arch/arm/boot/dts/omap4470.dts
>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>> index 763bdea8c829..15ff3d7146af 100644
>> --- a/arch/arm/boot/dts/omap4.dtsi
>> +++ b/arch/arm/boot/dts/omap4.dtsi
>> @@ -389,7 +389,7 @@ abb_iva: regulator-abb-iva {
>>  status = "disabled";
>>  };
>> -target-module@5600 {
>> +sgx_module: target-module@5600 {
>>  compatible = "ti,sysc-omap4", "ti,sysc";
>>  reg = <0x5600fe00 0x4>,
>><0x5600fe10 0x4>;
>> @@ -408,10 +408,11 @@ target-module@5600 {
>>  #size-cells = <1>;
>>  ranges = <0 0x5600 0x200>;
>> -/*
>> - * Closed source PowerVR driver, no child device
>> - * binding or driver in mainline
>> - */
>> +gpu: gpu@0 {
>> +compatible = "ti,omap4-sgx540-120", 
>> "img,sgx540-120", "img,sgx540";
>> +reg = <0x0 0x200>;  /* 32MB */
>> +interrupts = ;
>> +};
>>  };
>>  /*
>> diff --git a/arch/arm/boot/dts/omap4470.dts b/arch/arm/boot/dts/omap4470.dts
>> new file mode 100644
>> index ..f29c581300bf
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/omap4470.dts

^^^ there is also a missing "i" in the file name

>> @@ -0,0 +1,15 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Device Tree Source for OMAP4470 SoC
>> + *
>> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>> + *
>> + * This file is licensed under the terms of the GNU General Public License
>> + * version 2.  This program is licensed "as is" without any warranty of any
>> + * kind, whether express or implied.
>> + */
>> +#include "omap4460.dtsi"
>> +
>> +&sgx {
> 
> Does this even compile?

Good question.

So far there is no well known eval board in mainline that #includes this .dtsi 
(because it is new) and therefore it passes any compile tests.

  DTC arch/arm/boot/dts/omap4470-test.dtb - due to target missing
Error: arch/arm/boot/dts/omap4470.dtsi:13.1-5 Label or path sgx not found

I have now added a dummy board (not to be mainlined) for my own compile test...

> 
> The node's handle is named sgx_module, not sgx.

Indeed. A fix is queued for v8.

BR and thanks,
Nikolaus

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

Re: [PATCH] drm/mediatek: stop iterating dma addresses when sg_dma_len() == 0

2020-04-28 Thread Anand K. Mistry

On Sun, 26 Apr 2020 at 18:04, Chun-Kuang Hu  wrote:
>
> Hi, Anand:
>
> Anand K Mistry  於 2020年4月20日 週一 下午2:09寫道：
> >
> > If dma_map_sg() merges pages when creating the mapping, only the first
> > entries will have a valid sg_dma_address() and sg_dma_len(), followed by
> > entries with sg_dma_len() == 0.
> >
> > Signed-off-by: Anand K Mistry 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_drm_gem.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > index b04a3c2b111e09..f8fd8b98c30e3d 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > @@ -224,6 +224,9 @@ struct drm_gem_object 
> > *mtk_gem_prime_import_sg_table(struct drm_device *dev,
> >
> > expected = sg_dma_address(sg->sgl);
> > for_each_sg(sg->sgl, s, sg->nents, i) {
> > +   if (!sg_dma_len(s))
> > +   break;
>
> I think this should be 'continue'

scatterlist.h has the comment:
/*
 * These macros should be used after a dma_map_sg call has been done
 * to get bus addresses of each of the SG entries and their lengths.
 * You should only work with the number of sg entries dma_map_sg
 * returns, or alternatively stop on the first sg_dma_len(sg) which
 * is 0.
 */

So breaking on the first sg_dma_len(sg) == 0 appears to be (one of)
the documented approach.

>
> Regards,
> Chun-Kuang.
>
> > +
> > if (sg_dma_address(s) != expected) {
> > DRM_ERROR("sg_table is not contiguous");
> > ret = -EINVAL;
> > --
> > 2.26.1.301.g55bc3eb7cb9-goog
> >
> >
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] dt-bindings: display: anx7814.txt: convert to yaml

2020-04-28 Thread Enric Balletbo i Serra

Hi Ricardo,

Thank you for your patch.

On 27/4/20 12:09, Ricardo Cañuelo wrote:
> This converts the Analogix ANX7814 bridge DT binding to yaml. Port
> definitions and descriptions were expanded, apart from that it's a
> direct translation from the original binding.
> 
> Signed-off-by: Ricardo Cañuelo 
> Acked-by: Sam Ravnborg 
> ---
> Changes in v3 (suggested by Sam Ravnborg):
>   - Rename example node i2c0 to i2c.
> 
> Changes in v2 (suggested by Enric Balletbo):
>   - File name change: use full compatible string.
>   - Binding description removed.
>   - #address-cells and #size-cells properties removed from ports node.
>   - Example node renamed: anx7814 -> bridge.
> 
> Tested with:
> make dt_binding_check ARCH=arm64 DT_SCHEMA_FILES=<.../analogix,anx7814.yaml>
> make dtbs_check ARCH=arm64 DT_SCHEMA_FILES=<.../analogix,anx7814.yaml>
> 
>  .../display/bridge/analogix,anx7814.yaml  | 124 ++
>  .../bindings/display/bridge/anx7814.txt   |  42 --
>  2 files changed, 124 insertions(+), 42 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/display/bridge/anx7814.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml 
> b/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
> new file mode 100644
> index ..13f0b52edefd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
> @@ -0,0 +1,124 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/analogix,anx7814.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analogix ANX7814 SlimPort (Full-HD Transmitter)
> +
> +maintainers:
> +  - Enric Balletbo i Serra 
> +
> +properties:
> +  compatible:
> +enum:
> +  - analogix,anx7808
> +  - analogix,anx7812
> +  - analogix,anx7814
> +  - analogix,anx7818
> +
> +  reg:
> +maxItems: 1
> +description: I2C address of the device.
> +
> +  interrupts:
> +maxItems: 1
> +description: Should contain the INTP interrupt.
> +
> +  hpd-gpios:
> +maxItems: 1
> +description: Which GPIO to use for hpd.
> +
> +  pd-gpios:
> +maxItems: 1
> +description: Which GPIO to use for power down.
> +
> +  reset-gpios:
> +maxItems: 1
> +description: Which GPIO to use for reset.
> +
> +  dvdd10-supply:
> +maxItems: 1
> +description: Regulator for 1.0V digital core power.
> +
> +  ports:
> +type: object
> +description:
> +  A node containing input and output port nodes with endpoint
> +  definitions as documented in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt
> +  Documentation/devicetree/bindings/graph.txt
> +
> +properties:
> +  port@0:
> +type: object
> +description: Video port for HDMI input.
> +
> +properties:
> +  reg:
> +const: 0
> +
> +  port@1:
> +type: object
> +description:
> +  Video port for SlimPort, DisplayPort, eDP or MyDP output.
> +
> +properties:
> +  reg:
> +const: 1
> +
> +required:
> +  - port@0
> +  - port@1
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts

See below ...

> +  - hpd-gpios
> +  - pd-gpios
> +  - reset-gpios

I know that these gpio attributes were required in the old binding and the
driver handles these gpios as required, but assuming that we should really
describe the hardware _not_ the driver, strictly talking, none of these gpios
are really required. The same happens with the interrupt, you can left the pin
floating and poll the registers.

So I am wondering if you should remove interrupts, *-gpios from required. Maybe
Rob Herring can give us more light on this?

Other than that:

Reviewed-by: Enric Balletbo i Serra 

Thanks,
 Enric

> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +#include 
> +
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +anx7814: bridge@38 {
> +compatible = "analogix,anx7814";
> +reg = <0x38>;
> +interrupt-parent = <&gpio0>;
> +interrupts = <99 IRQ_TYPE_LEVEL_LOW>;   /* INTP */
> +hpd-gpios = <&pio 36 GPIO_ACTIVE_HIGH>;
> +pd-gpios = <&pio 33 GPIO_ACTIVE_HIGH>;
> +reset-gpios = <&pio 98 GPIO_ACTIVE_HIGH>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +anx7814_in: endpoint {
> +remote-endpoint = <&hdmi0_out>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +anx

[PATCH] drm/amdgpu/smu10: remove duplicate assignment of smu10_hwmgr_funcs members

2020-04-28 Thread Jason Yan

The struct member 'asic_setup' was assigned twice, let's remove one:

static const struct pp_hwmgr_func smu10_hwmgr_funcs = {
..
.asic_setup = NULL,
..
.asic_setup = smu10_setup_asic_task,
..
};

This fixes the following coccicheck warning:

drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c:1357:52-53:
asic_setup: first occurrence line 1360, second occurrence line 1388

Signed-off-by: Jason Yan 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
index 1cc30f750c26..4f8c1b85e688 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
@@ -1357,7 +1357,6 @@ static int smu10_asic_reset(struct pp_hwmgr *hwmgr, enum 
SMU_ASIC_RESET_MODE mod
 static const struct pp_hwmgr_func smu10_hwmgr_funcs = {
.backend_init = smu10_hwmgr_backend_init,
.backend_fini = smu10_hwmgr_backend_fini,
-   .asic_setup = NULL,
.apply_state_adjust_rules = smu10_apply_state_adjust_rules,
.force_dpm_level = smu10_dpm_force_dpm_level,
.get_power_state_size = smu10_get_power_state_size,
-- 
2.21.1

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

[PATCH] drm/qxl: lost qxl_bo_kunmap_atomic_page in qxl_image_init_helper()

2020-04-28 Thread Vasily Averin

Signed-off-by: Vasily Averin 
---
 drivers/gpu/drm/qxl/qxl_image.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/qxl/qxl_image.c b/drivers/gpu/drm/qxl/qxl_image.c
index 43688ecdd8a0..7270da62fc29 100644
--- a/drivers/gpu/drm/qxl/qxl_image.c
+++ b/drivers/gpu/drm/qxl/qxl_image.c
@@ -212,6 +212,7 @@ qxl_image_init_helper(struct qxl_device *qdev,
break;
default:
DRM_ERROR("unsupported image bit depth\n");
+   qxl_bo_kunmap_atomic_page(qdev, image_bo, ptr);
return -EINVAL; /* TODO: cleanup */
}
image->u.bitmap.flags = QXL_BITMAP_TOP_DOWN;
-- 
2.17.1

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

[PATCH] drm/amd/display: remove duplicate assignment of dcn21_funcs members

2020-04-28 Thread Jason Yan

Fix the following coccicheck warning:

drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c:31:51-52:
exit_optimized_pwr_state: first occurrence line 86, second occurrence
line 92
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c:31:51-52:
optimize_pwr_state: first occurrence line 85, second occurrence line 91
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c:31:51-52:
set_cursor_attribute: first occurrence line 71, second occurrence line
89
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c:31:51-52:
set_cursor_position: first occurrence line 70, second occurrence line 88
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c:31:51-52:
set_cursor_sdr_white_level: first occurrence line 72, second occurrence
line 90

Signed-off-by: Jason Yan 
---
 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c
index 8410a6305a9a..fe64bcb49456 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c
@@ -85,11 +85,6 @@ static const struct hw_sequencer_funcs dcn21_funcs = {
.optimize_pwr_state = dcn21_optimize_pwr_state,
.exit_optimized_pwr_state = dcn21_exit_optimized_pwr_state,
.get_vupdate_offset_from_vsync = dcn10_get_vupdate_offset_from_vsync,
-   .set_cursor_position = dcn10_set_cursor_position,
-   .set_cursor_attribute = dcn10_set_cursor_attribute,
-   .set_cursor_sdr_white_level = dcn10_set_cursor_sdr_white_level,
-   .optimize_pwr_state = dcn21_optimize_pwr_state,
-   .exit_optimized_pwr_state = dcn21_exit_optimized_pwr_state,
.power_down = dce110_power_down,
 };
 
-- 
2.21.1

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

[PATCH v3 0/4] drm: Add support for IPK DSI Host Driver

Adds support for the display subsystem in the Synopsys
DesignWare IPK devices.

The display pipeline is limited and does not have access to memory, the
validation is done using a VPG (Video Pattern Generator), as DPI
stimulus for the DW MIPI DSI Host.

A Synopsys DesignWare MIPI DSI Host v1.40 is used in the IPK device, that
so far, is fully compatible with the driver dw-mipi-dsi.

To activate the VPG use the sysfs pattern variable, assigning values from
0 (shutdown) to 4. The usage of the VPG and the Synopsys DesignWare MIPI
DSI Host internal video generator is mutually exclusive.

The submission of this driver aims to be used as a work base for the
submission of enhancements over the Synopsys DesignWare MIPI DSI Host.

Angelo Ribeiro (4):
  dt-bindings: display: Add IPK DSI subsystem bindings
  drm: ipk: Add DRM driver for DesignWare IPK DSI
  drm: ipk: Add extensions for DW MIPI DSI Host driver
  MAINTAINERS: Add IPK MIPI DSI Host driver entry

 .../bindings/display/snps,dw-ipk-dsi.yaml  | 159 ++
 .../bindings/display/snps,dw-ipk-vpg.yaml  |  73 +++
 MAINTAINERS|   8 +
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/ipk/Kconfig|  22 +
 drivers/gpu/drm/ipk/Makefile   |   6 +
 drivers/gpu/drm/ipk/dw-drv.c   | 169 +++
 drivers/gpu/drm/ipk/dw-ipk.h   |  26 +
 drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c  | 557 +
 drivers/gpu/drm/ipk/dw-vpg.c   | 412 +++
 drivers/gpu/drm/ipk/dw-vpg.h   |  48 ++
 12 files changed, 1483 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/snps,dw-ipk-vpg.yaml
 create mode 100644 drivers/gpu/drm/ipk/Kconfig
 create mode 100644 drivers/gpu/drm/ipk/Makefile
 create mode 100644 drivers/gpu/drm/ipk/dw-drv.c
 create mode 100644 drivers/gpu/drm/ipk/dw-ipk.h
 create mode 100644 drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c
 create mode 100644 drivers/gpu/drm/ipk/dw-vpg.c
 create mode 100644 drivers/gpu/drm/ipk/dw-vpg.h

-- 
2.7.4

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

Re: [PATCH] drivers/video: cleanup coding style in video a bit

2020-04-28 Thread Markus Elfring

> Eliminate the magic numbers, add vender infoframe size macro
> like other hdmi modules.

How do you think about a wording variant like the following?

   Subject:
   [PATCH v2] video/hdmi: Use “HDMI_VENDOR_INFOFRAME_SIZE” in 
hdmi_vendor_infoframe_init()

   Change description:
   Adjust the usage of a “magic” number here by adding a macro for
   the vendor info frame size (similar to other video modules).


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

Re: [PATCH v1] staging: fbtft: fb_st7789v: enabled inversion

On 09/04/20, Dan Carpenter wrote:
> On Thu, Apr 09, 2020 at 11:24:05AM +0200, Oliver Graute wrote:
> > From: Oliver Graute 
> > 
> > Enable inversion mode
> > 
> > Signed-off-by: Oliver Graute 
> > ---
> >  drivers/staging/fbtft/fb_st7789v.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/staging/fbtft/fb_st7789v.c 
> > b/drivers/staging/fbtft/fb_st7789v.c
> > index 3c3f387936e8..84c5af2dc9a0 100644
> > --- a/drivers/staging/fbtft/fb_st7789v.c
> > +++ b/drivers/staging/fbtft/fb_st7789v.c
> > @@ -120,6 +120,10 @@ static int init_display(struct fbtft_par *par)
> > write_reg(par, PWCTRL1, 0xA4, 0xA1);
> >  
> > write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
> > +
> > +   /* enable inversion mode */
> > +   write_reg(par, 0x21);
> 
> Use the define and delete the comment.
> 
>   write_reg(par, MIPI_DCS_ENTER_INVERT_MODE);

ok, I'll do on next version

Best regards,

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

[PATCH] video: fbdev: w100fb: Fix a potential double free.

2020-04-28 Thread Christophe JAILLET

Some memory is vmalloc'ed in the 'suspend' function and freed in the
'resume' function.
However, it is also freed in the remove function.

In order to avoid a potential double free, set the corresponding pointer
to NULL once freed in the 'resume' function.

Fixes: aac51f09d96a ("[PATCH] w100fb: Rewrite for platform independence")
Signed-off-by: Christophe JAILLET 
---
 drivers/video/fbdev/w100fb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/fbdev/w100fb.c b/drivers/video/fbdev/w100fb.c
index 2d6e2738b792..d96ab28f8ce4 100644
--- a/drivers/video/fbdev/w100fb.c
+++ b/drivers/video/fbdev/w100fb.c
@@ -588,6 +588,7 @@ static void w100fb_restore_vidmem(struct w100fb_par *par)
memsize=par->mach->mem->size;
memcpy_toio(remapped_fbuf + (W100_FB_BASE-MEM_WINDOW_BASE), 
par->saved_extmem, memsize);
vfree(par->saved_extmem);
+   par->saved_extmem = NULL;
}
if (par->saved_intmem) {
memsize=MEM_INT_SIZE;
@@ -596,6 +597,7 @@ static void w100fb_restore_vidmem(struct w100fb_par *par)
else
memcpy_toio(remapped_fbuf + 
(W100_FB_BASE-MEM_WINDOW_BASE), par->saved_intmem, memsize);
vfree(par->saved_intmem);
+   par->saved_intmem = NULL;
}
 }
 
-- 
2.25.1

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

Re: [PATCH v8 05/10] drm: imx: Add i.MX 6 MIPI DSI host platform driver

2020-04-28 Thread Enric Balletbo i Serra

Hi Adrian

Thank you for your patch.

On 27/4/20 10:19, Adrian Ratiu wrote:
> This adds support for the Synopsis DesignWare MIPI DSI v1.01 host
> controller which is embedded in i.MX 6 SoCs.
> 
> Based on following patches, but updated/extended to work with existing
> support found in the kernel:
> 
> - drm: imx: Support Synopsys DesignWare MIPI DSI host controller
>   Signed-off-by: Liu Ying 
> 
> Cc: Fabio Estevam 
> Cc: Enric Balletbo Serra 
> Reviewed-by: Emil Velikov 
> Tested-by: Adrian Pop 
> Tested-by: Arnaud Ferraris 
> Signed-off-by: Sjoerd Simons 
> Signed-off-by: Martyn Welch 
> Signed-off-by: Adrian Ratiu 
> ---
> Changes since v7:
>   - Removed encoder helper ops and added drm_bridge (Laurent)
>   - Brought back drm_simple_encoder_init and dropped dependency on
>   external unify encoder creation patch (Laurent)
>   - Minor typo fixes
> 
> Changes since v6:
>   - Replaced custom noop encoder with the simple drm encoder (Enric)
>   - Added CONFIG_DRM_IMX6_MIPI_DSI depends on CONFIG_OF (Enric)
>   - Dropped imx_mipi_dsi_register() because now it only creates the
>   dummy encoder which can easily be done directly in imx_dsi_bind()
> 
> Changes since v5:
>   - Reword to remove unrelated device tree patch mention (Fabio)
>   - Move pllref_clk enable/disable to bind/unbind (Ezequiel)
>   - Fix freescale.com -> nxp.com email addresses (Fabio)
>   - Also added myself as module author (Fabio)
>   - Use DRM_DEV_* macros for consistency, print more error msg
> 
> Changes since v4:
>   - Split off driver-specific configuration of phy timings due
>   to new upstream API.
>   - Move regmap infrastructure logic to separate commit (Ezequiel)
>   - Move dsi v1.01 layout addition to a separate commit (Ezequiel)
>   - Minor warnings and driver name fixes
> 
> Changes since v3:
>   - Renamed platform driver to reflect it's i.MX6 only. (Fabio)
> 
> Changes since v2:
>   - Fixed commit tags. (Emil)
> 
> Changes since v1:
>   - Moved register definitions & regmap initialization into bridge
>   module. Platform drivers get the regmap via plat_data after
>   calling the bridge probe. (Emil)
> ---
>  drivers/gpu/drm/imx/Kconfig|   8 +
>  drivers/gpu/drm/imx/Makefile   |   1 +
>  drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c | 399 +
>  3 files changed, 408 insertions(+)
>  create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> 
> diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
> index 207bf7409dfba..0dffc72df7922 100644
> --- a/drivers/gpu/drm/imx/Kconfig
> +++ b/drivers/gpu/drm/imx/Kconfig
> @@ -39,3 +39,11 @@ config DRM_IMX_HDMI
>   depends on DRM_IMX
>   help
> Choose this if you want to use HDMI on i.MX6.
> +
> +config DRM_IMX6_MIPI_DSI
> + tristate "Freescale i.MX6 DRM MIPI DSI"
> + select DRM_DW_MIPI_DSI
> + depends on DRM_IMX
> + depends on OF
> + help
> +   Choose this if you want to use MIPI DSI on i.MX6.
> diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> index 21cdcc2faabc8..9a7843c593478 100644
> --- a/drivers/gpu/drm/imx/Makefile
> +++ b/drivers/gpu/drm/imx/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
>  obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
>  
>  obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
> +obj-$(CONFIG_DRM_IMX6_MIPI_DSI) += dw_mipi_dsi-imx6.o
> diff --git a/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c 
> b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> new file mode 100644
> index 0..492decc418bc3
> --- /dev/null
> +++ b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> @@ -0,0 +1,399 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * i.MX6 drm driver - MIPI DSI Host Controller
> + *
> + * Copyright (C) 2011-2015 Freescale Semiconductor, Inc.
> + * Copyright (C) 2019-2020 Collabora, Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "imx-drm.h"
> +
> +#define DSI_PWR_UP   0x04
> +#define RESET0
> +#define POWERUP  BIT(0)
> +
> +#define DSI_PHY_IF_CTRL  0x5c
> +#define PHY_IF_CTRL_RESET0x0
> +
> +#define DSI_PHY_TST_CTRL00x64
> +#define PHY_TESTCLK  BIT(1)
> +#define PHY_UNTESTCLK0
> +#define PHY_TESTCLR  BIT(0)
> +#define PHY_UNTESTCLR0
> +
> +#define DSI_PHY_TST_CTRL10x68
> +#define PHY_TESTEN   BIT(16)
> +#define PHY_UNTESTEN 0
> +#define PHY_TESTDOUT(n)  (((n) & 0xff) << 8)
> +#define PHY_TESTDIN(n)   (((n) & 0xff) << 0)
> +
> +struct imx_mipi_dsi {
> + struct drm_encoder encoder;
> + struct drm_bridge bridge;
> + struct device *dev;
> + struct regmap *mux_sel;
> + struct dw_mipi_ds

[PATCH v9 0/3] IT6505 cover letter

2020-04-28 Thread allen

The IT6505 is a high-performance DisplayPort 1.1a transmitter, fully compliant 
with DisplayPort 1.1a, HDCP 1.3 specifications. The IT6505 supports color depth 
of up to 36 bits (12 bits/color) and ensures robust transmission of 
high-quality uncompressed video content, along with uncompressed and compressed 
digital audio content.

This series contains document bindings, revert commit, add vendor prefix, 
Kconfig to control the function enable or not.

Allen Chen (1):
  WIP: drm/bridge: add it6505 driver

allen (2):
  dt-bindings: Add vendor prefix for ITE Tech. Inc.
  WIP: dt-bindings: Add binding for IT6505.

 .../bindings/display/bridge/ite,it6505.yaml|   91 +
 .../devicetree/bindings/vendor-prefixes.yaml   |2 +-
 drivers/gpu/drm/bridge/Kconfig |7 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/ite-it6505.c| 3136 
 5 files changed, 3236 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
 create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c

-- 
1.9.1

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

Re: [PATCH v2 04/91] firmware: rpi: Only create clocks device if we don't have a node for it

2020-04-28 Thread Nicolas Saenz Julienne

Hi Maxime,

On Fri, 2020-04-24 at 17:33 +0200, Maxime Ripard wrote:
> The firmware clocks driver was previously probed through a platform_device
> created by the firmware driver.
> 
> Since we will now have a node for that clocks driver, we need to create the
> device only in the case where there's no node for it already.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/firmware/raspberrypi.c | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> index da26a584dca0..1874f41b007c 100644
> --- a/drivers/firmware/raspberrypi.c
> +++ b/drivers/firmware/raspberrypi.c
> @@ -210,6 +210,15 @@ rpi_register_hwmon_driver(struct device *dev, struct
> rpi_firmware *fw)
>  
>  static void rpi_register_clk_driver(struct device *dev)
>  {
> + /*
> +  * Earlier DTs don't have a node for the firmware clocks but
> +  * rely on us creating a platform device by hand. If we do
> +  * have a node for the firmware clocks, just bail out here.
> +  */
> + if (of_get_compatible_child(dev->of_node,
> + "raspberrypi,firmware-clocks"))
> + return;
> +
>   rpi_clk = platform_device_register_data(dev, "raspberrypi-clk",
>   -1, NULL, 0);
>  }
> @@ -262,8 +271,12 @@ static int rpi_firmware_remove(struct platform_device
> *pdev)
>  
>   platform_device_unregister(rpi_hwmon);
>   rpi_hwmon = NULL;
> - platform_device_unregister(rpi_clk);
> - rpi_clk = NULL;
> +
> + if (rpi_clk) {

rpi_clk, being a static global variable, will be zeroed by default. So, if you
don't register the platform device, rpi_clk is going to be NULL, which you're
allowed to feed platform_device_unregister(), so no need to be extra careful.

Regards,
Nicolas

> + platform_device_unregister(rpi_clk);
> + rpi_clk = NULL;
> + }
> +
>   mbox_free_channel(fw->chan);
>  
>   return 0;



signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH net-next] ath11k: use GFP_ATOMIC under spin lock

2020-04-28 Thread Kalle Valo

Wei Yongjun  writes:

> A spin lock is taken here so we should use GFP_ATOMIC.
>
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
> Signed-off-by: Wei Yongjun 

Do note that ath11k patches go to my ath.git tree, not net-next. But no
need to resend because of this.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 3/3] drm/panel: simple: Add Newhaven ATXL#-CTP panel

Hi Sam,

Thanks for giving feedback. When I send out v2 I'll CC you on the rest of the 
series
to be sure you have visibility. My responses are below.

> On Mon, Apr 27, 2020 at 09:41:49AM +0100, Sam Ravnborg wrote:
> Hi Gareth.
> 
> Looking forward to see the other patches - they seem to be stuck awaiting
> approval.
> 
> A few comments in the following.
> 
>   Sam
> 
> On Mon, Apr 27, 2020 at 09:21:49AM +0100, Gareth Williams wrote:
> > This commit adds support for the Newhaven ATXL#-CTP panel used by the
> > Renesas RZ/N1 Demo Board.
> >
> > Signed-off-by: Gareth Williams 
> > ---
> >  drivers/gpu/drm/panel/panel-simple.c | 27
> +++
> >  1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 5a93c4e..0b57b0e 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -2021,6 +2021,30 @@ static const struct panel_desc
> newhaven_nhd_43_480272ef_atxl = {
> >  DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE,  };
> >
> > +static const struct display_timing
> newhaven_nhd_50_800480tf_atxl_timing = {
> > +   .pixelclock = { 3330, 3340, 3350 },
> > +   .hactive = { 800, 800, 800 },
> > +   .hfront_porch = { 40, 40, 40 },
> > +   .hback_porch = { 88, 88, 88 },
> > +   .hsync_len = { 1, 1, 1 },
> > +   .vactive = { 480, 480, 480 },
> > +   .vfront_porch = { 13, 13, 13 },
> > +   .vback_porch = { 32, 32, 32 },
> > +   .vsync_len = { 3, 3, 3 },
> > +   .flags = DISPLAY_FLAGS_HSYNC_HIGH |
> DISPLAY_FLAGS_VSYNC_HIGH, };
> > +
> > +static const struct panel_desc newhaven_nhd_50_800480tf_atxl = {
> > +   .timings = &newhaven_nhd_50_800480tf_atxl_timing,
> > +   .num_timings = 1,
> > +   .bpc = 8,
> > +   .size = {
> > +   .width = 400,
> > +   .height = 300,
> > +   },
> > +   .bus_flags = DRM_BUS_FLAG_DE_HIGH,
> Please add DRM_BUS_FLAG_PIXDATA too - as I assume this is an LVDS panel.

This is an RGB interface, however the manual lists that the rising edge is
being used so I will include the DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE
flag.

> 
> > +};
> For new panels .connector_type is mandatory.
Okay, I will include this in v2 of the series.

> 
> 
> > +
> >  static const struct display_timing nlt_nl192108ac18_02d_timing = {
> > .pixelclock = { 13000, 14835, 16300 },
> > .hactive = { 1920, 1920, 1920 },
> > @@ -2964,6 +2988,9 @@ static const struct of_device_id
> platform_of_match[] = {
> > .compatible = "newhaven,nhd-4.3-480272ef-atxl",
> > .data = &newhaven_nhd_43_480272ef_atxl,
> > }, {
> > +   .compatible = "newhaven,nhd-5.0-800480tf-atxl",
> > +   .data = &newhaven_nhd_50_800480tf_atxl,
> > +   }, {
> 
> I did not see the other patches - so this is maybe covered.
> But newhaven,nhd-5.0-800480tf-atxl must be documented in panel-
> simple.yaml before we can apply this.

I will include a separate documentation patch in v2 with you
on CC for this.


> 
>   Sam
> 
> > .compatible = "nlt,nl192108ac18-02d",
> > .data = &nlt_nl192108ac18_02d,
> > }, {
> > --
> > 2.7.4

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

[PATCH net-next] net: lpc-enet: fix error return code in lpc_mii_init()

2020-04-28 Thread Wei Yongjun

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: b7370112f519 ("lpc32xx: Added ethernet driver")
Signed-off-by: Wei Yongjun 
---
 drivers/net/ethernet/nxp/lpc_eth.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/nxp/lpc_eth.c 
b/drivers/net/ethernet/nxp/lpc_eth.c
index d20cf03a3ea0..311454d9b0bc 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -823,7 +823,8 @@ static int lpc_mii_init(struct netdata_local *pldat)
if (err)
goto err_out_unregister_bus;
 
-   if (lpc_mii_probe(pldat->ndev) != 0)
+   err = lpc_mii_probe(pldat->ndev);
+   if (err)
goto err_out_unregister_bus;
 
return 0;



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

Re: KASAN: use-after-free Read in vkms_dumb_create

2020-04-28 Thread Hillf Danton



Sun, 26 Apr 2020 20:48:12 -0700
> syzbot found the following crash on:
> 
> HEAD commit:c578ddb3 Merge tag 'linux-kselftest-5.7-rc3' of git://git...
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10fbf0d810
> kernel config:  https://syzkaller.appspot.com/x/.config?x=b7a70e992f2f9b68
> dashboard link: https://syzkaller.appspot.com/bug?extid=e3372a2afe1e7ef04bc7
> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1543833010
> 
> Bisection is inconclusive: the first bad commit could be any of:
> 
> 85b5bafb drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()
> dff1c703 drm/tinydrm: Use drm_fbdev_generic_setup()
> 23167fa9 drm/panel: simple: Add support for Rocktech RK070ER9427 LCD panel
> 9060d7f4 drm/fb-helper: Finish the generic fbdev emulation
> 2230ca12 dt-bindings: display: Document the EDT et* displays in one file.
> e896c132 drm/debugfs: Add internal client debugfs file
> 894a677f drm/cma-helper: Use the generic fbdev emulation
> aa7e6455 drm/panel: Add support for the EDT ETM0700G0BDH6
> 244007ec drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
> aad34de2 drm/panel: Add support for the EDT ETM0700G0EDH6
> 7a6aca49 dt-bindings: Add vendor prefix for DLC Display Co., Ltd.
> d536540f drm/fb-helper: Add generic fbdev emulation .fb_probe function
> 0ca0c827 drm/panel: simple: Add DLC DLC0700YZG-1 panel
> c76f0f7c drm: Begin an API for in-kernel clients
> 5ba57bab drm: vkms: select DRM_KMS_HELPER
> 5fa8e4a2 drm/panel: Make of_drm_find_panel() return an ERR_PTR() instead of 
> NULL
> 008095e0 drm/vc4: Add support for the transposer block
> c59eb3cf drm/panel: Let of_drm_find_panel() return -ENODEV when the panel is 
> disabled
> 1ebe99a7 drm/vc4: Call drm_atomic_helper_fake_vblank() in the commit path
> 2e64a174 drm/of: Make drm_of_find_panel_or_bridge() fail when the device is 
> disabled
> 1b9883ea drm/vc4: Support the case where the DSI device is disabled
> 6fb42b66 drm/atomic: Call fake_vblank() from the generic commit_tail() helpers
> b0b7aa40 dt-bindings: display: Add DT bindings for BOE HV070WSA-100 panel
> b25c60af drm/crtc: Add a generic infrastructure to fake VBLANK events
> 184d3cf4 drm/vc4: Use wait_for_flip_done() instead of wait_for_vblanks()
> ae8cf41b drm/panel: simple: Add support for BOE HV070WSA-100 panel to 
> simple-panel
> 814bde99 drm/connector: Make ->atomic_commit() optional
> 955f60db drm: Add support for extracting sync signal drive edge from videomode
> 3b39ad7a drm/panel: simple: Add newhaven, nhd-4.3-480272ef-atxl LCD
> 425132fd drm/connector: Pass a drm_connector_state to ->atomic_commit()
> a5d2ade6 drm/panel: simple: Add support for Innolux G070Y2-L01
> b82c1f8f drm/atomic: Avoid connector to writeback_connector casts
> 03fa9aa3 dt-bindings: Add DataImage, Inc. vendor prefix
> 73915b2b drm/writeback: Fix the "overview" section of the doc
> 97ceb1fb drm/panel: simple: Add support for DataImage SCF0700C48GGU18
> e22e9531 Merge drm-upstream/drm-next into drm-misc-next
> 3d5664f9 drm/panel: ili9881c: Fix missing assignment to error return ret
> a0120245 drm/crc: Only report a single overflow when a CRC fd is opened
> 7ad4e463 drm/panel: p079zca: Refactor panel driver to support multiple panels
> 8adbbb2e drm/stm: ltdc: rework reset sequence
> 48bd379a drm/panel: p079zca: Add variable unprepare_delay properties
> 7868e507 drm/stm: ltdc: filter mode pixel clock vs pad constraint
> 731edd4c dt-bindings: Add Innolux P097PFG panel bindings
> f8878bb2 drm: print plane state normalized zpos value
> ca52bea9 drm/atomic-helper: Use bitwise or for filling a bitmask
> de04a462 drm/panel: p079zca: Support Innolux P097PFG panel
> 2bb7a39c dt-bindings: Add vendor prefix for kingdisplay
> a65020d0 drm/v3d: Fix a grammar nit in the scheduler docs.
> 2dd4f211 drm/v3d: Add missing v3d documentation structure.
> ebc950fd dt-bindings: Add KINGDISPLAY KD097D04 panel bindings
> cd0e0ca6 drm/panel: type promotion bug in s6e8aa0_read_mtp_id()
> e0d01811 drm/v3d: Remove unnecessary dma_fence_ops.
> 624bb0c0 drm/v3d: Delay the scheduler timeout if we're still making progress.
> b6d83fcc drm/panel: p079zca: Use of_device_get_match_data()
> 408633d2 drm/v3d: use new return type vm_fault_t in v3d_gem_fault
> decac6b0 dt-bindings: display: sun4i-drm: Add R40 display engine compatible
> 0b7510d1 drm/tilcdc: Use drm_connector_has_possible_encoder()
> d978a94b drm/sun4i: Add R40 display engine compatible
> af11942e drm/sun4i: tcon-top: Cleanup clock handling
> f8222409 drm/msm: Use drm_connector_has_possible_encoder()
> 38cb8d96 drm: Add drm_connector_has_possible_encoder()
> da82107e drm/sun4i: tcon: Release node when traversing of graph
> 7a667775 dt-bindings: display: sun4i-drm: Add R40 TV TCON description
> 7b71ca24 drm/radeon: Use drm_connector_for_each_possible_encoder()
> 4a068c5c drm/sun4i: DW HDMI: Release nodes if error happens during CRTC search
> ddba766d drm/nouveau: Use

Re: [RESEND PATCH v3 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

2020-04-28 Thread Andy Shevchenko

On Mon, Apr 27, 2020 at 05:53:03PM +0300, Sakari Ailus wrote:
> Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> pixel formats denoted by fourccs. The fourcc encoding is the same for both
> so the same implementation can be used.

4cc is more generic than pixel format.

...

> +V4L2 and DRM FourCC code (pixel format)
> +---
> +
> +::
> +
> + %p4cc

Missed examples.

> +Print a FourCC code used by V4L2 or DRM, including format endianness and
> +its numerical value as hexadecimal.

...

> +static noinline_for_stack
> +char *fourcc_string(char *buf, char *end, const u32 *__fourcc,
> + struct printf_spec spec, const char *fmt)
> +{
> +#define FOURCC_HEX_CHAR_STR  "(xx)"
> +#define FOURCC_BIG_ENDIAN_STR" big-endian"
> +#define FOURCC_LITTLE_ENDIAN_STR " little-endian"
> +#define FOURCC_HEX_NUMBER" (0x01234567)"

Where are #undef:s?

> +#define FOURCC_STRING_MAX\
> + FOURCC_HEX_CHAR_STR FOURCC_HEX_CHAR_STR FOURCC_HEX_CHAR_STR \
> + FOURCC_HEX_CHAR_STR FOURCC_LITTLE_ENDIAN_STR FOURCC_HEX_NUMBER

> + struct printf_spec my_spec = {
> + .type = FORMAT_TYPE_UINT,
> + .field_width = 2,
> + .flags = SMALL,
> + .base = 16,
> + .precision = -1,
> + };

Seems like close enough to bus_spec.

> + char __s[sizeof(FOURCC_STRING_MAX)];
> + char *s = __s;
> + unsigned int i;
> + /*
> +  * The 31st bit defines the endianness of the data, so save its printing
> +  * for later.
> +  */
> + u32 fourcc = *__fourcc & ~BIT(31);
> + int ret;
> +
> + if (check_pointer(&buf, end, __fourcc, spec))
> + return buf;
> +
> + if (fmt[1] != 'c' || fmt[2] != 'c')
> + return error_string(buf, end, "(%p4?)", spec);
> +
> + for (i = 0; i < sizeof(fourcc); i++, fourcc >>= 8) {
> + unsigned char c = fourcc;
> +
> + /* Weed out spaces */
> + if (c == ' ')
> + continue;
> +
> + /* Print non-control characters as-is */
> + if (c > ' ') {
> + *s = c;
> + s++;
> + continue;
> + }

> + if (WARN_ON_ONCE(sizeof(__s) <
> +  (s - __s) + sizeof(FOURCC_HEX_CHAR_STR)))

Why WARN?!

> + break;
> +
> + *s = '(';
> + s++;
> + s = number(s, s + 2, c, my_spec);
> + *s = ')';
> + s++;
> + }
> +
> + ret = strscpy(s, *__fourcc & BIT(31) ? FOURCC_BIG_ENDIAN_STR
> +  : FOURCC_LITTLE_ENDIAN_STR,
> +   sizeof(__s) - (s - __s));

> + if (!WARN_ON_ONCE(ret < 0))

Ditto.

> + s += ret;

> + if (!WARN_ON_ONCE(sizeof(__s) <
> +   (s - __s) + sizeof(FOURCC_HEX_NUMBER))) {

Ditto.

> + *s = ' ';
> + s++;
> + *s = '(';
> + s++;
> + /* subtract parentheses and the space from the size */
> + special_hex_number(s, s + sizeof(FOURCC_HEX_NUMBER) - 3,
> +*__fourcc, sizeof(u32));
> + s += sizeof(u32) * 2 + 2 /* 0x */;
> + *s = ')';
> + s++;
> + *s = '\0';
> + }
> +
> + return string(buf, end, __s, spec);

This looks overengineered. Why everyone will need so long strings to be printed?

> +}

-- 
With Best Regards,
Andy Shevchenko


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

[PATCH v9 2/3] dt-bindings: Add binding for IT6505.

2020-04-28 Thread allen

Add a DT binding documentation for IT6505.

Acked-by: Sam Ravnborg 
Signed-off-by: Allen Chen 
Signed-off-by: Pi-Hsun Shih 
---
cros-ec does not have an associated driver that uses the standard Linux USB-C 
driver class.
extcon is used to model the Type-C connector.(crbug.com/982932)
---
 .../bindings/display/bridge/ite,it6505.yaml| 91 ++
 1 file changed, 91 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml

diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml 
b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
new file mode 100644
index ..13feeef
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ite,it6505.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ITE it6505 Device Tree Bindings
+
+maintainers:
+  - Allen Chen 
+
+description: |
+  The IT6505 is a high-performance DisplayPort 1.1a transmitter,
+  fully compliant with DisplayPort 1.1a, HDCP 1.3 specifications.
+  The IT6505 supports color depth of up to 36 bits (12 bits/color)
+  and ensures robust transmission of high-quality uncompressed video
+  content, along with uncompressed and compressed digital audio content.
+
+  Aside from the various video output formats supported, the IT6505
+  also encodes and transmits up to 8 channels of I2S digital audio,
+  with sampling rate up to 192kHz and sample size up to 24 bits.
+  In addition, an S/PDIF input port takes in compressed audio of up to
+  192kHz frame rate.
+
+  Each IT6505 chip comes preprogrammed with an unique HDCP key,
+  in compliance with the HDCP 1.3 standard so as to provide secure
+  transmission of high-definition content. Users of the IT6505 need not
+  purchase any HDCP keys or ROMs.
+
+properties:
+  compatible:
+const: ite,it6505
+
+  ovdd-supply:
+maxItems: 1
+description: I/O voltage
+
+  pwr18-supply:
+maxItems: 1
+description: core voltage
+
+  interrupts:
+maxItems: 1
+description: interrupt specifier of INT pin
+
+  reset-gpios:
+maxItems: 1
+description: gpio specifier of RESET pin
+
+  extcon:
+maxItems: 1
+description: extcon specifier for the Power Delivery
+
+  port:
+type: object
+description: A port node pointing to DPI host port node
+
+required:
+  - compatible
+  - ovdd-supply
+  - pwr18-supply
+  - interrupts
+  - reset-gpios
+  - extcon
+
+examples:
+  - |
+#include 
+
+i2c3 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+dp-bridge@5c {
+compatible = "ite,it6505";
+interrupts = <152 IRQ_TYPE_EDGE_FALLING 152 0>;
+reg = <0x5c>;
+pinctrl-names = "default";
+pinctrl-0 = <&it6505_pins>;
+ovdd-supply = <&mt6358_vsim1_reg>;
+pwr18-supply = <&it6505_pp18_reg>;
+reset-gpios = <&pio 179 1>;
+extcon = <&usbc_extcon>;
+
+port {
+it6505_in: endpoint {
+remote-endpoint = <&dpi_out>;
+};
+};
+};
+};
-- 
1.9.1

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

Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported

2020-04-28 Thread Peter Collingbourne

On Mon, Apr 27, 2020 at 1:47 PM Eric Anholt  wrote:
>
> On Mon, Apr 27, 2020 at 1:05 PM Peter Collingbourne  wrote:
> >
> > Render nodes are not just useful for devices supporting GPU hardware
> > acceleration. Even on devices that only support dumb frame buffers,
> > they are useful in situations where composition (using software
> > rasterization) and KMS are done in different processes with buffer
> > sharing being used to send frame buffers between them. This is the
> > situation on Android, where surfaceflinger is the compositor and the
> > composer HAL uses KMS to display the buffers. Thus it is beneficial
> > to expose render nodes on all devices that support buffer sharing.
> >
> > Because all drivers that currently support render nodes also support
> > buffer sharing, the DRIVER_RENDER flag is no longer necessary to mark
> > devices as supporting render nodes, so remove it and just rely on
> > the presence of a prime_handle_to_fd function pointer to determine
> > whether buffer sharing is supported.
>
> I'm definitely interested in seeing a patch like this land, as I think
> the current state is an ugly historical artifact.  We just have to be
> careful.
>
> Were there any instances of drivers with render engines exposing PRIME
> but not RENDER?  We should be careful to make sure that we're not
> exposing new privileges for those through adding render nodes.

These are the drivers that we'd be adding render nodes for with this change:

$ git grep -l prime_handle_to_fd (git grep -L DRIVER_RENDER (git grep
-l '\.driver_features'))
drivers/gpu/drm/arc/arcpgu_drv.c
drivers/gpu/drm/arm/display/komeda/komeda_kms.c
drivers/gpu/drm/arm/hdlcd_drv.c
drivers/gpu/drm/arm/malidp_drv.c
drivers/gpu/drm/armada/armada_drv.c
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
drivers/gpu/drm/imx/imx-drm-core.c
drivers/gpu/drm/ingenic/ingenic-drm.c
drivers/gpu/drm/mcde/mcde_drv.c
drivers/gpu/drm/mediatek/mtk_drm_drv.c
drivers/gpu/drm/meson/meson_drv.c
drivers/gpu/drm/mxsfb/mxsfb_drv.c
drivers/gpu/drm/pl111/pl111_drv.c
drivers/gpu/drm/qxl/qxl_drv.c
drivers/gpu/drm/rcar-du/rcar_du_drv.c
drivers/gpu/drm/rockchip/rockchip_drm_drv.c
drivers/gpu/drm/shmobile/shmob_drm_drv.c
drivers/gpu/drm/sti/sti_drv.c
drivers/gpu/drm/stm/drv.c
drivers/gpu/drm/tilcdc/tilcdc_drv.c
drivers/gpu/drm/tve200/tve200_drv.c
drivers/gpu/drm/xen/xen_drm_front.c
drivers/gpu/drm/zte/zx_drm_drv.c

Some of the drivers provide custom ioctls but they are already
protected from render nodes by not setting DRM_RENDER_ALLOW. Another
thing to check for is drivers providing custom fops that might expose
something undesirable in the render node:

$ git grep -L 'DEFINE_DRM_GEM_CMA_FOPS\|DEFINE_DRM_GEM_FOPS' (git grep
-l prime_handle_to_fd (git grep -L DRIVER_RENDER (git grep -l
'\.driver_features')))
drivers/gpu/drm/mediatek/mtk_drm_drv.c
drivers/gpu/drm/rockchip/rockchip_drm_drv.c
drivers/gpu/drm/xen/xen_drm_front.c

But looking at those drivers in detail, I see that each of them is
using the standard DRM fops handlers (which presumably already handle
render nodes correctly) with the exception of mmap, which they provide
wrappers for that mostly just wrap drm_gem_mmap.

So unless I'm missing something significant (which seems likely -- I'm
not a DRM expert), I don't see a problem so far.

> There's a UAPI risk I see here.  Right now, on a system with a single
> renderer GPU, we can just open /dev/dri/renderD128 and get the GPU for
> rendering, and various things are relying on that (such as libwaffle,
> used in piglit among other things)   Adding render nodes for kms-only
> drivers could displace the actual GPU to 129, and the question is
> whether this will be disruptive.  For Mesa, I think this works out,
> because kmsro should load on the kms device's node and then share
> buffers over to the real GPU that it digs around to find at init time.
> Just saying, I'm not sure I know all of the userspace well enough to
> say "this should be safe despite that"
>
> (And, maybe, if we decide that it's not safe enough, we could punt
> kms-only drivers to a higher starting number?)

Android (minigbm) similarly tries to open /dev/dri/renderD$N in a loop
with 128 <= N < 192 and assumes that the first non-blacklisted (i.e.
not vgem) one that it can open corresponds to the real GPU [1]. I
think that the risk of breaking something on Android is low since
Android's architecture basically already depends on there being a
render node, and it seems unlikely for a device to have more than one
GPU, one of which would be non-functional.

It's also worth bearing in mind that render nodes were added to vgem
in commit 3a6eb795 from 2018. To the extent that exposing additional
render nodes would lead to widespread breakage, this would seem to me
to be a likely way in which it could have happened (since I would
expect that it could cause many machines to go from ha

[PATCH] drm/panel: boe-tv101wum-n16: fine tune clock

2020-04-28 Thread David Lu

fix boe_tv105wum_nw0 display shift.

Signed-off-by: David Lu 
---
 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index f89861c8598a..46fe1805c588 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -697,15 +697,15 @@ static const struct panel_desc auo_b101uan08_3_desc = {
 };
 
 static const struct drm_display_mode boe_tv105wum_nw0_default_mode = {
-   .clock = 159260,
+   .clock = 159916,
.hdisplay = 1200,
.hsync_start = 1200 + 80,
.hsync_end = 1200 + 80 + 24,
.htotal = 1200 + 80 + 24 + 60,
.vdisplay = 1920,
-   .vsync_start = 1920 + 10,
-   .vsync_end = 1920 + 10 + 2,
-   .vtotal = 1920 + 10 + 2 + 14,
+   .vsync_start = 1920 + 20,
+   .vsync_end = 1920 + 20 + 4,
+   .vtotal = 1920 + 20 + 4 + 10,
.vrefresh = 60,
.type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
 };
-- 
2.17.1



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

Re: [PATCH 01/59] drm: Add devm_drm_dev_alloc macro

On Tue, Apr 21, 2020 at 10:32:45PM +0200, Sam Ravnborg wrote:
> Hi
> 
> > > Hm, I see the point of this (and the dev_field below, although I'd go
> > > with dev_member there for some consistency with other macros using
> > > offset_of or container_of), but I'm not sure about the dev_ prefix.
> > > Drivers use that sometimes for the struct device *, and usage for
> > > struct drm_device * is also very inconsistent. I've seen ddev, drm,
> > > dev and base (that one only for embedded structs ofc). So not sure
> > > which prefix to pick, aside from dev_ seems the most confusing. Got
> > > ideas?
> > 
> > We have pdev for the PCI device, dev for the abstract device, and things
> > like mdev for struct mga_device in mgag200. So I'd go with ddev. I don't
> > like drm, because it could be anything in DRM. I guess struct drm_driver
> > is more 'drm' than struct drm_device.
> > 
> > But all of this is bikeshedding. It's probably best to keep the patch
> > as-is, and maybe rename variables later if we ever find consent on the
> > naming.
> 
> bikeshedding - I know.
> But reading code is is quite natural for me that drm equals the central
> drm_device data structure. Maybe thats because this was is in the code
> I started looking at.
> 
> So as an example:
> 
>   drm_err(drm, "bla bla\n");
> 
> This parses nicely and is easy to type and get right.
> And matches nicely that drm_device => drm.
> But bikeshedding  - I will go to bed...
> (Whatever is the conclusion we should not hold back the patch in
> questions).

Ok, since we can't agree on dev vs ddev vs drm vs something else I just
left it as-is. We can always repaint this later on.

Thanks everyone for comments and review.
-Daniel
-- 
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 01/44] drivers/base: Always release devres on device_del

On Mon, Apr 06, 2020 at 03:55:28PM +0200, Daniel Vetter wrote:
> On Mon, Apr 6, 2020 at 3:38 PM Greg Kroah-Hartman
>  wrote:
> >
> > On Mon, Apr 06, 2020 at 02:32:51PM +0200, Daniel Vetter wrote:
> > > On Fri, Apr 3, 2020 at 3:58 PM Daniel Vetter  
> > > wrote:
> > > >
> > > > In drm we've added nice drm_device (the main gpu driver thing, which
> > > > also represents the userspace interfaces and has everything else
> > > > dangling off it) init functions using devres, devm_drm_dev_init and
> > > > soon devm_drm_dev_alloc (this patch series adds that).
> > > >
> > > > A slight trouble is that drm_device itself holds a reference on the
> > > > struct device it's sitting on top (for sysfs links and dmesg debug and
> > > > lots of other things), so there's a reference loop. For real drivers
> > > > this is broken at remove/unplug time, where all devres resources are
> > > > released device_release_driver(), before the final device reference is
> > > > dropped. So far so good.
> > > >
> > > > There's 2 exceptions:
> > > > - drm/vkms|vgem: Virtual drivers for which we create a fake/virtual
> > > >   platform device to make them look more like normal devices to
> > > >   userspace. These aren't drivers in the driver model sense, we simple
> > > >   create a platform_device and register it.
> > > >
> > > > - drm/i915/selftests, where we create minimal mock devices, and again
> > > >   the selftests aren't proper drivers in the driver model sense.
> > > >
> > > > For these two cases the reference loop isn't broken, because devres is
> > > > only cleaned up when the last device reference is dropped. But that's
> > > > not happening, because the drm_device holds that last struct device
> > > > reference.
> > > >
> > > > Thus far this wasn't a problem since the above cases simply
> > > > hand-rolled their cleanup code. But I want to convert all drivers over
> > > > to the devm_ versions, hence it would be really nice if these
> > > > virtual/fake/mock uses-cases could also be managed with devres
> > > > cleanup.
> > > >
> > > > I see three possible approaches:
> > >
> > > Restarting this at the top level, because the discussion thus far just
> > > ended in a long "you're doing it wrong", despite that I think we're
> > > doing what v4l is doing (plus/minus that we can't do an exact matching
> > > handling in drm because our uapi has a lot more warts, which we can't
> > > change because no breaking userspace).
> > >
> > > So which one of the three below is the right approach?
> > >
> > > Aside, looking at the v4l solution I think there's also a confusion
> > > about struct device representing a char device (which v4l directly
> > > uses as its userspace interface refcounted thing, and which drm does
> > > _not_ directly). And a struct device embedded into something like
> > > platform_device or a virtual device, where a driver can bind to. My
> > > question here is about the former, I don't care how cdev struct device
> > > are cleaned up one bit. Now if other subsystems relies on the devres
> > > cleanup behaviour we currently have because of such cdev usage, then
> > > yeah first approach doesn't work (and I have a big surprised that use
> > > case, but hey would actually learn something).
> > >
> > > End of aside, since again I want to figure out which of the tree
> > > approaches it the right one. Not about how wrong one of them is,
> > > ignoring the other three I laid out. And maybe there's even more
> > > options for this.
> >
> > Sorry, been swamped with other things, give me a few days to get back to
> > this, I need to dig into how you all are dealing with the virtual
> > drivers.
> 
> Sure, no problem.
> 
> > Doing this in the middle of the merge window is a bit rough :)
> 
> Ah I always forget ... we freeze drm at -rc6, so merge window is
> actually my most relaxed time since everyone is busy and no one has
> time to report drm bugs :-)

Hi Greg,

Since -rc3 is out, had any to ponder this? Otherwise we'll be right back
in the next merge window ...

Cheers, Daniel
-- 
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 11/59] drm/udl: Use devm_drm_dev_alloc

On Fri, Apr 24, 2020 at 04:55:56PM +0200, Sam Ravnborg wrote:
> Hi Daniel.
> 
> On Wed, Apr 15, 2020 at 09:39:46AM +0200, Daniel Vetter wrote:
> > Also init the fbdev emulation before we register the device, that way
> > we can rely on the auto-cleanup and simplify the probe error code even
> > more.
> > 
> > v2: Rebase on top of Thomas' patches to remove the return value from
> > drm_fbdev_generic_setup()
> 
> with the rebase the changelog in confusing as this patch does nothing of
> what is described in the changelog.
> Only the title (that is in convinently not available when replying to
> email) describes what this patch does.

Good point, I fixed that up while applying, thanks for taking a look.
-Daniel

> 
> With the changelog properly adjusted:
> Acked-by: Sam Ravnborg 
> 
> > 
> > Signed-off-by: Daniel Vetter 
> > Cc: Noralf Trønnes 
> > Cc: Dave Airlie 
> > Cc: Sean Paul 
> > Cc: Thomas Zimmermann 
> > Cc: Daniel Vetter 
> > Cc: Emil Velikov 
> > Cc: Sam Ravnborg 
> > Cc: Thomas Gleixner 
> > ---
> >  drivers/gpu/drm/udl/udl_drv.c | 26 +++---
> >  1 file changed, 7 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> > index 9cc6d075cb40..523f60e02a85 100644
> > --- a/drivers/gpu/drm/udl/udl_drv.c
> > +++ b/drivers/gpu/drm/udl/udl_drv.c
> > @@ -57,27 +57,20 @@ static struct udl_device *udl_driver_create(struct 
> > usb_interface *interface)
> > struct udl_device *udl;
> > int r;
> >  
> > -   udl = kzalloc(sizeof(*udl), GFP_KERNEL);
> > -   if (!udl)
> > -   return ERR_PTR(-ENOMEM);
> > -
> > -   r = drm_dev_init(&udl->drm, &driver, &interface->dev);
> > -   if (r) {
> > -   kfree(udl);
> > -   return ERR_PTR(r);
> > -   }
> > +   udl = devm_drm_dev_alloc(&interface->dev, &driver,
> > +struct udl_device, drm);
> > +   if (IS_ERR(udl))
> > +   return udl;
> >  
> > udl->udev = udev;
> > udl->drm.dev_private = udl;
> > -   drmm_add_final_kfree(&udl->drm, udl);
> >  
> > r = udl_init(udl);
> > -   if (r) {
> > -   drm_dev_put(&udl->drm);
> > +   if (r)
> > return ERR_PTR(r);
> > -   }
> >  
> > usb_set_intfdata(interface, udl);
> > +
> > return udl;
> >  }
> >  
> > @@ -93,17 +86,13 @@ static int udl_usb_probe(struct usb_interface 
> > *interface,
> >  
> > r = drm_dev_register(&udl->drm, 0);
> > if (r)
> > -   goto err_free;
> > +   return r;
> >  
> > DRM_INFO("Initialized udl on minor %d\n", udl->drm.primary->index);
> >  
> > drm_fbdev_generic_setup(&udl->drm, 0);
> >  
> > return 0;
> > -
> > -err_free:
> > -   drm_dev_put(&udl->drm);
> > -   return r;
> >  }
> >  
> >  static void udl_usb_disconnect(struct usb_interface *interface)
> > @@ -113,7 +102,6 @@ static void udl_usb_disconnect(struct usb_interface 
> > *interface)
> > drm_kms_helper_poll_fini(dev);
> > udl_drop_usb(dev);
> > drm_dev_unplug(dev);
> > -   drm_dev_put(dev);
> >  }
> >  
> >  /*
> > -- 
> > 2.25.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

[RFC 09/17] drm: panfrost: fix sg_table nents vs. orig_nents misuse

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/panfrost/panfrost_gem.c | 3 ++-
 drivers/gpu/drm/panfrost/panfrost_mmu.c | 4 +++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c 
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 17b654e..22fec7c 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -42,7 +42,8 @@ static void panfrost_gem_free_object(struct drm_gem_object 
*obj)
for (i = 0; i < n_sgt; i++) {
if (bo->sgts[i].sgl) {
dma_unmap_sg(pfdev->dev, bo->sgts[i].sgl,
-bo->sgts[i].nents, 
DMA_BIDIRECTIONAL);
+bo->sgts[i].orig_nents,
+DMA_BIDIRECTIONAL);
sg_free_table(&bo->sgts[i]);
}
}
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c 
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index ed28aeb..2d9b1f9 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -517,7 +517,9 @@ static int panfrost_mmu_map_fault_addr(struct 
panfrost_device *pfdev, int as,
if (ret)
goto err_pages;
 
-   if (!dma_map_sg(pfdev->dev, sgt->sgl, sgt->nents, DMA_BIDIRECTIONAL)) {
+   sgt->nents = dma_map_sg(pfdev->dev, sgt->sgl, sgt->orig_nents,
+   DMA_BIDIRECTIONAL);
+   if (!sgt->nents) {
ret = -EINVAL;
goto err_map;
}
-- 
1.9.1

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

[RFC 05/17] drm: exynos: fix sg_table nents vs. orig_nents misuse

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index fcee33a..e27715c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -396,7 +396,7 @@ static void g2d_userptr_put_dma_addr(struct g2d_data *g2d,
 
 out:
dma_unmap_sg(to_dma_dev(g2d->drm_dev), g2d_userptr->sgt->sgl,
-   g2d_userptr->sgt->nents, DMA_BIDIRECTIONAL);
+g2d_userptr->sgt->orig_nents, DMA_BIDIRECTIONAL);
 
pages = frame_vector_pages(g2d_userptr->vec);
if (!IS_ERR(pages)) {
@@ -511,8 +511,9 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct g2d_data 
*g2d,
 
g2d_userptr->sgt = sgt;
 
-   if (!dma_map_sg(to_dma_dev(g2d->drm_dev), sgt->sgl, sgt->nents,
-   DMA_BIDIRECTIONAL)) {
+   sgt->nents = dma_map_sg(to_dma_dev(g2d->drm_dev), sgt->sgl,
+   sgt->orig_nents, DMA_BIDIRECTIONAL)
+   if (!sgt->nents) {
DRM_DEV_ERROR(g2d->dev, "failed to map sgt with dma region.\n");
ret = -ENOMEM;
goto err_sg_free_table;
-- 
1.9.1

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

[RFC 02/17] drm: amdgpu: fix sg_table nents vs. orig_nents misuse

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 7 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 
 2 files changed, 8 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 43d8ed7..4df813e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -307,8 +307,9 @@ static struct sg_table *amdgpu_dma_buf_map(struct 
dma_buf_attachment *attach,
if (IS_ERR(sgt))
return sgt;
 
-   if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC))
+   sgt->nents = dma_map_sg_attrs(attach->dev, sgt->sgl, 
sgt->orig_nents,
+ dir, DMA_ATTR_SKIP_CPU_SYNC);
+   if (!sgt->nents)
goto error_free;
break;
 
@@ -349,7 +350,7 @@ static void amdgpu_dma_buf_unmap(struct dma_buf_attachment 
*attach,
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
 
if (sgt->sgl->page_link) {
-   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+   dma_unmap_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir);
sg_free_table(sgt);
kfree(sgt);
} else {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index d5543c2..5f31585 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1043,7 +1043,6 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
 {
struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
struct amdgpu_ttm_tt *gtt = (void *)ttm;
-   unsigned nents;
int r;
 
int write = !(gtt->userflags & AMDGPU_GEM_USERPTR_READONLY);
@@ -1059,8 +1058,9 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
 
/* Map SG to device */
r = -ENOMEM;
-   nents = dma_map_sg(adev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
-   if (nents == 0)
+   ttm->sg->nents = dma_map_sg(adev->dev, ttm->sg->sgl,
+   ttm->sg->orig_nents, direction);
+   if (ttm->sg->nents == 0)
goto release_sg;
 
/* convert SG to linear array of pages and dma addresses */
@@ -1091,7 +1091,7 @@ static void amdgpu_ttm_tt_unpin_userptr(struct ttm_tt 
*ttm)
return;
 
/* unmap the pages mapped to the device */
-   dma_unmap_sg(adev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
+   dma_unmap_sg(adev->dev, ttm->sg->sgl, ttm->sg->orig_nents, direction);
 
sg_free_table(ttm->sg);
 
-- 
1.9.1

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

[RFC 12/17] drm: tegra: fix sg_table nents vs. orig_nents misuse

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/tegra/gem.c   | 25 +
 drivers/gpu/drm/tegra/plane.c | 13 +++--
 2 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 6237681..5710ab4 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -98,8 +98,8 @@ static struct sg_table *tegra_bo_pin(struct device *dev, 
struct host1x_bo *bo,
 * the SG table needs to be copied to avoid overwriting any
 * other potential users of the original SG table.
 */
-   err = sg_alloc_table_from_sg(sgt, obj->sgt->sgl, 
obj->sgt->nents,
-GFP_KERNEL);
+   err = sg_alloc_table_from_sg(sgt, obj->sgt->sgl,
+obj->sgt->orig_nents, GFP_KERNEL);
if (err < 0)
goto free;
} else {
@@ -197,7 +197,7 @@ static int tegra_bo_iommu_map(struct tegra_drm *tegra, 
struct tegra_bo *bo)
bo->iova = bo->mm->start;
 
bo->size = iommu_map_sg(tegra->domain, bo->iova, bo->sgt->sgl,
-   bo->sgt->nents, prot);
+   bo->sgt->orig_nents, prot);
if (!bo->size) {
dev_err(tegra->drm->dev, "failed to map buffer\n");
err = -ENOMEM;
@@ -264,7 +264,7 @@ static struct tegra_bo *tegra_bo_alloc_object(struct 
drm_device *drm,
 static void tegra_bo_free(struct drm_device *drm, struct tegra_bo *bo)
 {
if (bo->pages) {
-   dma_unmap_sg(drm->dev, bo->sgt->sgl, bo->sgt->nents,
+   dma_unmap_sg(drm->dev, bo->sgt->sgl, bo->sgt->orig_nents,
 DMA_FROM_DEVICE);
drm_gem_put_pages(&bo->gem, bo->pages, true, true);
sg_free_table(bo->sgt);
@@ -290,9 +290,9 @@ static int tegra_bo_get_pages(struct drm_device *drm, 
struct tegra_bo *bo)
goto put_pages;
}
 
-   err = dma_map_sg(drm->dev, bo->sgt->sgl, bo->sgt->nents,
-DMA_FROM_DEVICE);
-   if (err == 0) {
+   bo->sgt->nents = dma_map_sg(drm->dev, bo->sgt->sgl, bo->sgt->orig_nents,
+   DMA_FROM_DEVICE);
+   if (bo->sgt->nents == 0) {
err = -EFAULT;
goto free_sgt;
}
@@ -571,7 +571,8 @@ int tegra_drm_mmap(struct file *file, struct vm_area_struct 
*vma)
goto free;
}
 
-   if (dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir) == 0)
+   sgt->nents = dma_map_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir);
+   if (sgt->nents == 0)
goto free;
 
return sgt;
@@ -590,7 +591,7 @@ static void tegra_gem_prime_unmap_dma_buf(struct 
dma_buf_attachment *attach,
struct tegra_bo *bo = to_tegra_bo(gem);
 
if (bo->pages)
-   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+   dma_unmap_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir);
 
sg_free_table(sgt);
kfree(sgt);
@@ -609,7 +610,7 @@ static int tegra_gem_prime_begin_cpu_access(struct dma_buf 
*buf,
struct drm_device *drm = gem->dev;
 
if (bo->pages)
-   dma_sync_sg_for_cpu(drm->dev, bo->sgt->sgl, bo->sgt->nents,
+   dma_sync_sg_for_cpu(drm->dev, bo->sgt->sgl, bo->sgt->orig_nents,
DMA_FROM_DEVICE);
 
return 0;
@@ -623,8 +624,8 @@ static int tegra_gem_prime_end_cpu_access(struct dma_buf 
*buf,
struct drm_device *drm = gem->dev;
 
if (bo->pages)
-   dma_sync_sg_for_device(drm->dev, bo->sgt->sgl, bo->sgt->nents,
-  DMA_TO_DEVICE);
+   dma_sync_sg_for_device(drm->dev, bo->sgt->sgl,
+  bo->sgt->orig_nents, DMA_TO_DEVICE);
 
return 0;
 }
diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
index 9ccfb56..3982bf8 100644
--- a/drivers/gpu/drm/tegra/plane.c
+++ b/drivers/gpu/drm/tegra/plane.c
@@ -130,9 +130,10 @@ static int tegra_dc_pin(struct tegra_dc *dc, struct 
tegra_plane_state *state)
}
 
if (sgt) {
-   err = dma_map_sg(dc->dev, sgt->sgl, sgt->nents,
-DMA_TO_DEVICE);
-   if (err == 0) {
+   sgt->nents = dma_map_sg(dc->dev, sgt->sgl,
+

[RFC 08/17] drm: msm: fix sg_table nents vs. orig_nents misuse

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/msm/msm_gem.c   | 8 
 drivers/gpu/drm/msm/msm_iommu.c | 3 ++-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 5a6a79f..54c3bbb 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -54,10 +54,10 @@ static void sync_for_device(struct msm_gem_object *msm_obj)
 
if (get_dma_ops(dev) && IS_ENABLED(CONFIG_ARM64)) {
dma_sync_sg_for_device(dev, msm_obj->sgt->sgl,
-   msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
+   msm_obj->sgt->orig_nents, DMA_BIDIRECTIONAL);
} else {
dma_map_sg(dev, msm_obj->sgt->sgl,
-   msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
+   msm_obj->sgt->orig_nents, DMA_BIDIRECTIONAL);
}
 }
 
@@ -67,10 +67,10 @@ static void sync_for_cpu(struct msm_gem_object *msm_obj)
 
if (get_dma_ops(dev) && IS_ENABLED(CONFIG_ARM64)) {
dma_sync_sg_for_cpu(dev, msm_obj->sgt->sgl,
-   msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
+   msm_obj->sgt->orig_nents, DMA_BIDIRECTIONAL);
} else {
dma_unmap_sg(dev, msm_obj->sgt->sgl,
-   msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
+   msm_obj->sgt->orig_nents, DMA_BIDIRECTIONAL);
}
 }
 
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index ad58cfe..b0ca084 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -43,7 +43,8 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
struct msm_iommu *iommu = to_msm_iommu(mmu);
size_t ret;
 
-   ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
+   ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->orig_nents,
+  prot);
WARN_ON(!ret);
 
return (ret == len) ? 0 : -EINVAL;
-- 
1.9.1

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

[RFC 03/17] drm: armada: fix sg_table nents vs. orig_nents misuse

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/armada/armada_gem.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 976685f..749647f 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -407,8 +407,10 @@ int armada_gem_pwrite_ioctl(struct drm_device *dev, void 
*data,
sg_set_page(sg, page, PAGE_SIZE, 0);
}
 
-   if (dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir) == 0) {
-   num = sgt->nents;
+   sgt->nents = dma_map_sg(attach->dev, sgt->sgl, sgt->orig_nents,
+   dir);
+   if (sgt->nents == 0) {
+   num = sgt->orig_nents;
goto release;
}
} else if (dobj->page) {
@@ -418,7 +420,9 @@ int armada_gem_pwrite_ioctl(struct drm_device *dev, void 
*data,
 
sg_set_page(sgt->sgl, dobj->page, dobj->obj.size, 0);
 
-   if (dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir) == 0)
+   sgt->nents = dma_map_sg(attach->dev, sgt->sgl, sgt->orig_nents,
+   dir);
+   if (sgt->nents == 0)
goto free_table;
} else if (dobj->linear) {
/* Single contiguous physical region - no struct page */
@@ -449,11 +453,11 @@ static void armada_gem_prime_unmap_dma_buf(struct 
dma_buf_attachment *attach,
int i;
 
if (!dobj->linear)
-   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+   dma_unmap_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir);
 
if (dobj->obj.filp) {
struct scatterlist *sg;
-   for_each_sg(sgt->sgl, sg, sgt->nents, i)
+   for_each_sg(sgt->sgl, sg, sgt->orig_nents, i)
put_page(sg_page(sg));
}
 
-- 
1.9.1

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

[RFC 01/17] drm: core: fix sg_table nents vs. orig_nents misuse

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/drm_cache.c| 2 +-
 drivers/gpu/drm/drm_gem_shmem_helper.c | 7 ---
 drivers/gpu/drm/drm_prime.c| 9 +
 3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 03e01b0..63bd497 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -127,7 +127,7 @@ static void drm_cache_flush_clflush(struct page *pages[],
struct sg_page_iter sg_iter;
 
mb(); /*CLFLUSH is ordered only by using memory barriers*/
-   for_each_sg_page(st->sgl, &sg_iter, st->nents, 0)
+   for_each_sg_page(st->sgl, &sg_iter, st->orig_nents, 0)
drm_clflush_page(sg_page_iter_page(&sg_iter));
mb(); /*Make sure that all cache line entry is flushed*/
 
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index df31e57..f47caa7 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -118,7 +118,7 @@ void drm_gem_shmem_free_object(struct drm_gem_object *obj)
} else {
if (shmem->sgt) {
dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl,
-shmem->sgt->nents, DMA_BIDIRECTIONAL);
+shmem->sgt->orig_nents, DMA_BIDIRECTIONAL);
sg_free_table(shmem->sgt);
kfree(shmem->sgt);
}
@@ -396,7 +396,7 @@ void drm_gem_shmem_purge_locked(struct drm_gem_object *obj)
WARN_ON(!drm_gem_shmem_is_purgeable(shmem));
 
dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl,
-shmem->sgt->nents, DMA_BIDIRECTIONAL);
+shmem->sgt->orig_nents, DMA_BIDIRECTIONAL);
sg_free_table(shmem->sgt);
kfree(shmem->sgt);
shmem->sgt = NULL;
@@ -623,7 +623,8 @@ struct sg_table *drm_gem_shmem_get_pages_sgt(struct 
drm_gem_object *obj)
goto err_put_pages;
}
/* Map the pages for use by the h/w. */
-   dma_map_sg(obj->dev->dev, sgt->sgl, sgt->nents, DMA_BIDIRECTIONAL);
+   sgt->nents = dma_map_sg(obj->dev->dev, sgt->sgl, sgt->orig_nents,
+   DMA_BIDIRECTIONAL);
 
shmem->sgt = sgt;
 
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 282774e..f3e2d2a 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -626,8 +626,9 @@ struct sg_table *drm_gem_map_dma_buf(struct 
dma_buf_attachment *attach,
else
sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
 
-   if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC)) {
+   sgt->nents = dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->orig_nents,
+ dir, DMA_ATTR_SKIP_CPU_SYNC);
+   if (!sgt->nents) {
sg_free_table(sgt);
kfree(sgt);
sgt = ERR_PTR(-ENOMEM);
@@ -652,7 +653,7 @@ void drm_gem_unmap_dma_buf(struct dma_buf_attachment 
*attach,
if (!sgt)
return;
 
-   dma_unmap_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
+   dma_unmap_sg_attrs(attach->dev, sgt->sgl, sgt->orig_nents, dir,
   DMA_ATTR_SKIP_CPU_SYNC);
sg_free_table(sgt);
kfree(sgt);
@@ -975,7 +976,7 @@ int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, 
struct page **pages,
 */
page_index = 0;
dma_index = 0;
-   for_each_sg(sgt->sgl, sg, sgt->nents, count) {
+   for_each_sg(sgt->sgl, sg, sgt->orig_nents, count) {
page_len = sg->length;
page = sg_page(sg);
dma_len = sg_dma_len(sg);
-- 
1.9.1

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

[RFC 04/17] drm: etnaviv: fix sg_table nents vs. orig_nents misuse

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index dc9ef30..a224a97 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -27,7 +27,8 @@ static void etnaviv_gem_scatter_map(struct etnaviv_gem_object 
*etnaviv_obj)
 * because display controller, GPU, etc. are not coherent.
 */
if (etnaviv_obj->flags & ETNA_BO_CACHE_MASK)
-   dma_map_sg(dev->dev, sgt->sgl, sgt->nents, DMA_BIDIRECTIONAL);
+   sgt->nents = dma_map_sg(dev->dev, sgt->sgl, sgt->orig_nents,
+   DMA_BIDIRECTIONAL);
 }
 
 static void etnaviv_gem_scatterlist_unmap(struct etnaviv_gem_object 
*etnaviv_obj)
@@ -51,7 +52,8 @@ static void etnaviv_gem_scatterlist_unmap(struct 
etnaviv_gem_object *etnaviv_obj
 * discard those writes.
 */
if (etnaviv_obj->flags & ETNA_BO_CACHE_MASK)
-   dma_unmap_sg(dev->dev, sgt->sgl, sgt->nents, DMA_BIDIRECTIONAL);
+   dma_unmap_sg(dev->dev, sgt->sgl, sgt->orig_nents,
+DMA_BIDIRECTIONAL);
 }
 
 /* called with etnaviv_obj->lock held */
@@ -405,7 +407,7 @@ int etnaviv_gem_cpu_prep(struct drm_gem_object *obj, u32 op,
 
if (etnaviv_obj->flags & ETNA_BO_CACHED) {
dma_sync_sg_for_cpu(dev->dev, etnaviv_obj->sgt->sgl,
-   etnaviv_obj->sgt->nents,
+   etnaviv_obj->sgt->orig_nents,
etnaviv_op_to_dma_dir(op));
etnaviv_obj->last_cpu_prep_op = op;
}
@@ -422,7 +424,7 @@ int etnaviv_gem_cpu_fini(struct drm_gem_object *obj)
/* fini without a prep is almost certainly a userspace error */
WARN_ON(etnaviv_obj->last_cpu_prep_op == 0);
dma_sync_sg_for_device(dev->dev, etnaviv_obj->sgt->sgl,
-   etnaviv_obj->sgt->nents,
+   etnaviv_obj->sgt->orig_nents,
etnaviv_op_to_dma_dir(etnaviv_obj->last_cpu_prep_op));
etnaviv_obj->last_cpu_prep_op = 0;
}
-- 
1.9.1

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

[RFC 11/17] drm: rockchip: fix sg_table nents vs. orig_nents misuse

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 0d18846..a024c71 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -37,7 +37,7 @@ static int rockchip_gem_iommu_map(struct rockchip_gem_object 
*rk_obj)
rk_obj->dma_addr = rk_obj->mm.start;
 
ret = iommu_map_sg(private->domain, rk_obj->dma_addr, rk_obj->sgt->sgl,
-  rk_obj->sgt->nents, prot);
+  rk_obj->sgt->orig_nents, prot);
if (ret < rk_obj->base.size) {
DRM_ERROR("failed to map buffer: size=%zd request_size=%zd\n",
  ret, rk_obj->base.size);
@@ -98,11 +98,11 @@ static int rockchip_gem_get_pages(struct 
rockchip_gem_object *rk_obj)
 * TODO: Replace this by drm_clflush_sg() once it can be implemented
 * without relying on symbols that are not exported.
 */
-   for_each_sg(rk_obj->sgt->sgl, s, rk_obj->sgt->nents, i)
+   for_each_sg(rk_obj->sgt->sgl, s, rk_obj->sgt->orig_nents, i)
sg_dma_address(s) = sg_phys(s);
 
-   dma_sync_sg_for_device(drm->dev, rk_obj->sgt->sgl, rk_obj->sgt->nents,
-  DMA_TO_DEVICE);
+   dma_sync_sg_for_device(drm->dev, rk_obj->sgt->sgl,
+  rk_obj->sgt->orig_nents, DMA_TO_DEVICE);
 
return 0;
 
@@ -351,7 +351,8 @@ void rockchip_gem_free_object(struct drm_gem_object *obj)
rockchip_gem_iommu_unmap(rk_obj);
} else {
dma_unmap_sg(drm->dev, rk_obj->sgt->sgl,
-rk_obj->sgt->nents, DMA_BIDIRECTIONAL);
+rk_obj->sgt->orig_nents,
+DMA_BIDIRECTIONAL);
}
drm_prime_gem_destroy(obj, rk_obj->sgt);
} else {
@@ -493,14 +494,14 @@ static unsigned long 
rockchip_sg_get_contiguous_size(struct sg_table *sgt,
struct sg_table *sg,
struct rockchip_gem_object *rk_obj)
 {
-   int count = dma_map_sg(drm->dev, sg->sgl, sg->nents,
+   int count = dma_map_sg(drm->dev, sg->sgl, sg->orig_nents,
   DMA_BIDIRECTIONAL);
if (!count)
return -EINVAL;
 
if (rockchip_sg_get_contiguous_size(sg, count) < attach->dmabuf->size) {
DRM_ERROR("failed to map sg_table to contiguous linear 
address.\n");
-   dma_unmap_sg(drm->dev, sg->sgl, sg->nents,
+   dma_unmap_sg(drm->dev, sg->sgl, sg->orig_nents,
 DMA_BIDIRECTIONAL);
return -EINVAL;
}
-- 
1.9.1

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

[RFC 07/17] drm: lima: fix sg_table nents vs. orig_nents misuse

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/lima/lima_gem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
index 5404e0d..3edd2ff 100644
--- a/drivers/gpu/drm/lima/lima_gem.c
+++ b/drivers/gpu/drm/lima/lima_gem.c
@@ -70,7 +70,7 @@ int lima_heap_alloc(struct lima_bo *bo, struct lima_vm *vm)
 
if (bo->base.sgt) {
dma_unmap_sg(dev, bo->base.sgt->sgl,
-bo->base.sgt->nents, DMA_BIDIRECTIONAL);
+bo->base.sgt->orig_nents, DMA_BIDIRECTIONAL);
sg_free_table(bo->base.sgt);
} else {
bo->base.sgt = kmalloc(sizeof(*bo->base.sgt), GFP_KERNEL);
@@ -80,7 +80,7 @@ int lima_heap_alloc(struct lima_bo *bo, struct lima_vm *vm)
}
}
 
-   dma_map_sg(dev, sgt.sgl, sgt.nents, DMA_BIDIRECTIONAL);
+   sgt.nents = dma_map_sg(dev, sgt.sgl, sgt.orig_nents, DMA_BIDIRECTIONAL);
 
*bo->base.sgt = sgt;
 
-- 
1.9.1

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

[RFC 10/17] drm: radeon: fix sg_table nents vs. orig_nents misuse

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/radeon/radeon_ttm.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 5d50c9e..4770880 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -481,7 +481,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm)
 {
struct radeon_device *rdev = radeon_get_rdev(ttm->bdev);
struct radeon_ttm_tt *gtt = (void *)ttm;
-   unsigned pinned = 0, nents;
+   unsigned pinned = 0;
int r;
 
int write = !(gtt->userflags & RADEON_GEM_USERPTR_READONLY);
@@ -522,8 +522,8 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm)
goto release_sg;
 
r = -ENOMEM;
-   nents = dma_map_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
-   if (nents == 0)
+   ttm->sg->nents = dma_map_sg(rdev->dev, ttm->sg->sgl,
+   if (ttm->sg->nents == 0)
goto release_sg;
 
drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
@@ -554,9 +554,9 @@ static void radeon_ttm_tt_unpin_userptr(struct ttm_tt *ttm)
return;
 
/* free the sg table and pages again */
-   dma_unmap_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
+   dma_unmap_sg(rdev->dev, ttm->sg->sgl, ttm->sg->orig_nents, direction);
 
-   for_each_sg_page(ttm->sg->sgl, &sg_iter, ttm->sg->nents, 0) {
+   for_each_sg_page(ttm->sg->sgl, &sg_iter, ttm->sg->orig_nents, 0) {
struct page *page = sg_page_iter_page(&sg_iter);
if (!(gtt->userflags & RADEON_GEM_USERPTR_READONLY))
set_page_dirty(page);
-- 
1.9.1

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

[RFC 00/17] DRM: fix struct sg_table nents vs. orig_nents misuse

Dear All,

During the Exynos DRM GEM rework and fixing the issues in the 
drm_prime_sg_to_page_addr_arrays() function [1] I've noticed that most
drivers in DRM framework incorrectly use nents and orig_nents entries of
the struct sg_table.

In case of the most DMA-mapping implementations exchanging those two
entries or using nents for all loops on the scatterlist is harmless,
because they both have the same value. There exists however a DMA-mapping
implementations, for which such incorrect usage breaks things. The nents
returned by dma_map_sg() might be lower than the nents passed as its
parameter and this is perfectly fine. DMA framework or IOMMU is allowed
to join consecutive chunks while mapping if such operation is supported
by the underlying HW (bus, bridge, IOMMU, etc). Example of the case
where dma_map_sg() might return 1 'DMA' chunk for the 4 'physical' pages
is described here [2]

The DMA-mapping framework documentation [3] states that dma_map_sg()
returns the numer of the created entries in the DMA address space.
However the subsequent calls to dma_sync_sg_for_{device,cpu} and
dma_unmap_sg must be called with the original number of entries passed to
dma_map_sg. The common pattern in DRM drivers were to assign the
dma_map_sg() return value to sg_table->nents and use that value for
the subsequent calls to dma_sync_sg_* or dma_unmap_sg functions. Also
the code iterated over nents times to access the pages stored in the
processed scatterlist, while it should use orig_nents as the numer of
the page entries.

I've tried to identify all such incorrect usage of sg_table->nents in the
DRM subsystem and this is a result of my research. It looks that the
incorrect pattern has been copied over the many drivers. Too bad in most
cases it even worked correctly if the system used simple, linear
DMA-mapping implementation, for which swapping nents and orig_nents
doesn't make any difference.

I wonder what to do to avoid such misuse in the future, as this case
clearly shows that the current sg_table structure is a bit hard to
understand. I have the following ideas and I would like to know your
opinion before I prepare more patches and check sg_table usage all over
the kernel:

1. introduce a dma_{map,sync,unmap}_sgtable() wrappers, which will use
   a proper sg_table entries and call respective DMA-mapping functions
   and adapt current code to it

2. rename nents and orig_nents to nr_pages, nr_dmas to clearly state
   which one refers to which part of the scatterlist; I'm open for
   other names for those entries

I will appreciate your comments.

Patches are based on top of Linux next-20200428. I've reduced the
recipients list mainly to mailing lists, the next version I will try to
send to the maintainers of the respective drivers.

Best regards,
Marek Szyprowski


References:

[1] https://lkml.org/lkml/2020/3/27/555 
[2] https://lkml.org/lkml/2020/3/29/65
[3] Documentation/DMA-API-HOWTO.txt


Patch summary:

Marek Szyprowski (17):
  drm: core: fix sg_table nents vs. orig_nents usage
  drm: amdgpu: fix sg_table nents vs. orig_nents usage
  drm: armada: fix sg_table nents vs. orig_nents usage
  drm: etnaviv: fix sg_table nents vs. orig_nents usage
  drm: exynos: fix sg_table nents vs. orig_nents usage
  drm: i915: fix sg_table nents vs. orig_nents usage
  drm: lima: fix sg_table nents vs. orig_nents usage
  drm: msm: fix sg_table nents vs. orig_nents usage
  drm: panfrost: fix sg_table nents vs. orig_nents usage
  drm: radeon: fix sg_table nents vs. orig_nents usage
  drm: rockchip: fix sg_table nents vs. orig_nents usage
  drm: tegra: fix sg_table nents vs. orig_nents usage
  drm: virtio: fix sg_table nents vs. orig_nents usage
  drm: vmwgfx: fix sg_table nents vs. orig_nents usage
  drm: xen: fix sg_table nents vs. orig_nents usage
  drm: host1x: fix sg_table nents vs. orig_nents usage
  dmabuf: fix sg_table nents vs. orig_nents usage

 drivers/dma-buf/heaps/heap-helpers.c |  7 ---
 drivers/dma-buf/udmabuf.c|  5 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c  |  7 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  |  8 
 drivers/gpu/drm/armada/armada_gem.c  | 14 -
 drivers/gpu/drm/drm_cache.c  |  2 +-
 drivers/gpu/drm/drm_gem_shmem_helper.c   |  7 ---
 drivers/gpu/drm/drm_prime.c  |  9 +
 drivers/gpu/drm/etnaviv/etnaviv_gem.c| 10 ++
 drivers/gpu/drm/exynos/exynos_drm_g2d.c  |  7 ---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   | 13 ++--
 drivers/gpu/drm/i915/gem/i915_gem_internal.c |  4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_region.c   |  4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c|  5 +++--
 drivers/gpu/drm/i915/gem/selftests/huge_pages.c  | 10 +-
 drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c |  5 +++--
 drivers/gpu/drm/i915/gt/intel_gg

[RFC 17/17] dmabuf: fix sg_table nents vs. orig_nents misuse

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/dma-buf/heaps/heap-helpers.c | 7 ---
 drivers/dma-buf/udmabuf.c| 5 +++--
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/dma-buf/heaps/heap-helpers.c 
b/drivers/dma-buf/heaps/heap-helpers.c
index 9f964ca..b923863 100644
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -144,8 +144,9 @@ struct sg_table *dma_heap_map_dma_buf(struct 
dma_buf_attachment *attachment,
 
table = &a->table;
 
-   if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
-   direction))
+   table->nents = dma_map_sg(attachment->dev, table->sgl,
+ table->orig_nents, direction);
+   if (!table->nents)
table = ERR_PTR(-ENOMEM);
return table;
 }
@@ -154,7 +155,7 @@ static void dma_heap_unmap_dma_buf(struct 
dma_buf_attachment *attachment,
   struct sg_table *table,
   enum dma_data_direction direction)
 {
-   dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
+   dma_unmap_sg(attachment->dev, table->sgl, table->orig_nents, direction);
 }
 
 static vm_fault_t dma_heap_vm_fault(struct vm_fault *vmf)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index acb26c6..ea0cf71 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -63,7 +63,8 @@ static struct sg_table *get_sg_table(struct device *dev, 
struct dma_buf *buf,
GFP_KERNEL);
if (ret < 0)
goto err;
-   if (!dma_map_sg(dev, sg->sgl, sg->nents, direction)) {
+   sg->nents = dma_map_sg(dev, sg->sgl, sg->orig_nents, direction);
+   if (!sg->nents) {
ret = -EINVAL;
goto err;
}
@@ -78,7 +79,7 @@ static struct sg_table *get_sg_table(struct device *dev, 
struct dma_buf *buf,
 static void put_sg_table(struct device *dev, struct sg_table *sg,
 enum dma_data_direction direction)
 {
-   dma_unmap_sg(dev, sg->sgl, sg->nents, direction);
+   dma_unmap_sg(dev, sg->sgl, sg->orig_nents, direction);
sg_free_table(sg);
kfree(sg);
 }
-- 
1.9.1

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

[RFC 13/17] drm: virtio: fix sg_table nents vs. orig_nents misuse

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/virtio/virtgpu_object.c | 11 ++-
 drivers/gpu/drm/virtio/virtgpu_vq.c |  8 
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 6ccbd01..12f6bee 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -73,7 +73,8 @@ void virtio_gpu_cleanup_object(struct virtio_gpu_object *bo)
if (shmem->pages) {
if (shmem->mapped) {
dma_unmap_sg(vgdev->vdev->dev.parent,
-shmem->pages->sgl, shmem->mapped,
+shmem->pages->sgl,
+shmem->pages->orig_nents,
 DMA_TO_DEVICE);
shmem->mapped = 0;
}
@@ -157,13 +158,13 @@ static int virtio_gpu_object_shmem_init(struct 
virtio_gpu_device *vgdev,
}
 
if (use_dma_api) {
-   shmem->mapped = dma_map_sg(vgdev->vdev->dev.parent,
+   shmem->pages->nents = dma_map_sg(vgdev->vdev->dev.parent,
   shmem->pages->sgl,
-  shmem->pages->nents,
+  shmem->pages->orig_nents,
   DMA_TO_DEVICE);
-   *nents = shmem->mapped;
+   *nents = shmem->mapped = shmem->pages->nents;
} else {
-   *nents = shmem->pages->nents;
+   *nents = shmem->pages->orig_nents;
}
 
*ents = kmalloc_array(*nents, sizeof(struct virtio_gpu_mem_entry),
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 9e663a5..661325b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -604,8 +604,8 @@ void virtio_gpu_cmd_transfer_to_host_2d(struct 
virtio_gpu_device *vgdev,
 
if (use_dma_api)
dma_sync_sg_for_device(vgdev->vdev->dev.parent,
-  shmem->pages->sgl, shmem->pages->nents,
-  DMA_TO_DEVICE);
+  shmem->pages->sgl,
+  shmem->pages->orig_nents, DMA_TO_DEVICE);
 
cmd_p = virtio_gpu_alloc_cmd(vgdev, &vbuf, sizeof(*cmd_p));
memset(cmd_p, 0, sizeof(*cmd_p));
@@ -1020,8 +1020,8 @@ void virtio_gpu_cmd_transfer_to_host_3d(struct 
virtio_gpu_device *vgdev,
 
if (use_dma_api)
dma_sync_sg_for_device(vgdev->vdev->dev.parent,
-  shmem->pages->sgl, shmem->pages->nents,
-  DMA_TO_DEVICE);
+  shmem->pages->sgl,
+  shmem->pages->orig_nents, DMA_TO_DEVICE);
 
cmd_p = virtio_gpu_alloc_cmd(vgdev, &vbuf, sizeof(*cmd_p));
memset(cmd_p, 0, sizeof(*cmd_p));
-- 
1.9.1

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

[RFC 15/17] drm: xen: fix sg_table nents vs. orig_nents misuse

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c 
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index f0b85e0..ba4bdc5 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -215,7 +215,7 @@ struct drm_gem_object *
return ERR_PTR(ret);
 
DRM_DEBUG("Imported buffer of size %zu with nents %u\n",
- size, sgt->nents);
+ size, sgt->orig_nents);
 
return &xen_obj->base;
 }
-- 
1.9.1

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

[RFC 06/17] drm: i915: fix sg_table nents vs. orig_nents misuse

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   | 13 +++--
 drivers/gpu/drm/i915/gem/i915_gem_internal.c |  4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_region.c   |  4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c|  5 +++--
 drivers/gpu/drm/i915/gem/selftests/huge_pages.c  | 10 +-
 drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c |  5 +++--
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 12 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.c  | 12 +++-
 drivers/gpu/drm/i915/i915_scatterlist.c  |  4 ++--
 drivers/gpu/drm/i915/selftests/scatterlist.c |  8 
 10 files changed, 41 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 7db5a79..d829852 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -36,21 +36,22 @@ static struct sg_table *i915_gem_map_dma_buf(struct 
dma_buf_attachment *attachme
goto err_unpin_pages;
}
 
-   ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL);
+   ret = sg_alloc_table(st, obj->mm.pages->orig_nents, GFP_KERNEL);
if (ret)
goto err_free;
 
src = obj->mm.pages->sgl;
dst = st->sgl;
-   for (i = 0; i < obj->mm.pages->nents; i++) {
+   for (i = 0; i < obj->mm.pages->orig_nents; i++) {
sg_set_page(dst, sg_page(src), src->length, 0);
dst = sg_next(dst);
src = sg_next(src);
}
 
-   if (!dma_map_sg_attrs(attachment->dev,
- st->sgl, st->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC)) {
+   st->nents = dma_map_sg_attrs(attachment->dev,
+st->sgl, st->orig_nents, dir,
+DMA_ATTR_SKIP_CPU_SYNC);
+   if (!st->nents) {
ret = -ENOMEM;
goto err_free_sg;
}
@@ -74,7 +75,7 @@ static void i915_gem_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
 
dma_unmap_sg_attrs(attachment->dev,
-  sg->sgl, sg->nents, dir,
+  sg->sgl, sg->orig_nents, dir,
   DMA_ATTR_SKIP_CPU_SYNC);
sg_free_table(sg);
kfree(sg);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c 
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index cbbff81..a8ebfdd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -73,7 +73,7 @@ static int i915_gem_object_get_pages_internal(struct 
drm_i915_gem_object *obj)
}
 
sg = st->sgl;
-   st->nents = 0;
+   st->nents = st->orig_nents = 0;
sg_page_sizes = 0;
 
do {
@@ -94,7 +94,7 @@ static int i915_gem_object_get_pages_internal(struct 
drm_i915_gem_object *obj)
 
sg_set_page(sg, page, PAGE_SIZE << order, 0);
sg_page_sizes |= PAGE_SIZE << order;
-   st->nents++;
+   st->nents = st->orig_nents = st->nents + 1;
 
npages -= 1 << order;
if (!npages) {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c 
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index 1515384..58ca560 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -53,7 +53,7 @@
GEM_BUG_ON(list_empty(blocks));
 
sg = st->sgl;
-   st->nents = 0;
+   st->nents = st->orig_nents = 0;
sg_page_sizes = 0;
prev_end = (resource_size_t)-1;
 
@@ -78,7 +78,7 @@
 
sg->length = block_size;
 
-   st->nents++;
+   st->nents = st->orig_nents = st->nents + 1;
} else {
sg->length += block_size;
sg_dma_len(sg) += block_size;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 5d5d7ee..851a732 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -80,7 +80,7 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
noreclaim |= __GFP_NORETRY | __GFP_NOWARN;
 
sg = st->sgl;
-   st->nents = 0;
+   st->nents = st->orig_nents = 0;
sg_page_sizes = 0;
for (i = 0; i <

[RFC 14/17] drm: vmwgfx: fix sg_table nents vs. orig_nents misuse

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in turn holds the result of the dma_map_sg call as stated
in include/linux/scatterlist.h. Adapt the code to obey those rules.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index bf0bc46..a5fd128 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -362,7 +362,7 @@ static void vmw_ttm_unmap_from_dma(struct vmw_ttm_tt 
*vmw_tt)
 {
struct device *dev = vmw_tt->dev_priv->dev->dev;
 
-   dma_unmap_sg(dev, vmw_tt->sgt.sgl, vmw_tt->sgt.nents,
+   dma_unmap_sg(dev, vmw_tt->sgt.sgl, vmw_tt->sgt.orig_nents,
DMA_BIDIRECTIONAL);
vmw_tt->sgt.nents = vmw_tt->sgt.orig_nents;
 }
@@ -449,10 +449,10 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
if (unlikely(ret != 0))
goto out_sg_alloc_fail;
 
-   if (vsgt->num_pages > vmw_tt->sgt.nents) {
+   if (vsgt->num_pages > vmw_tt->sgt.orig_nents) {
uint64_t over_alloc =
sgl_size * (vsgt->num_pages -
-   vmw_tt->sgt.nents);
+   vmw_tt->sgt.orig_nents);
 
ttm_mem_global_free(glob, over_alloc);
vmw_tt->sg_alloc_size -= over_alloc;
-- 
1.9.1

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

[RFC 16/17] drm: host1x: fix sg_table nents vs. orig_nents misuse