Re: [linux-sunxi] Preferring cursor plane over overlay plane

[Maxime Ripard]

On Mon, Mar 26, 2018 at 11:01:53PM +0800, Chen-Yu Tsai wrote:
> On Mon, Mar 26, 2018 at 10:45 PM, Maxime Ripard
>  wrote:
> > On Mon, Mar 26, 2018 at 10:22:45PM +0800, Chen-Yu Tsai wrote:
> >> On Mon, Mar 26, 2018 at 10:14 PM, Joonas Kylmälä  
> >> wrote:
> >> > Hi DRM subsystem developers,
> >> >
> >> > I ran into this patch where overlay plane was switched to cursor plane
> >> > because there was no proper cursor plane available on the display
> >> > hardware: . Can we discuss whether
> >> > to have a policy of using a normal plane for cursor plane in case a
> >> > dedicated HW cursor plane is missing?
> >> >
> >> > Daniel Vetter suggests that it might be fine to use normal plane for
> >> > cursor plane because how to use the plane would be only "a hint to
> >> > userspace" (see the email linked).
> >> >
> >> > My motivation for having this discussion is that the newer Allwinner
> >> > SoCs don't have dedicated HW cursor plane and the sun4i DRM driver
> >> > currently uses the extra planes as overlay planes which makes moving the
> >> > cursor on Xfce4 DE a terrible experience. To have better cursor moving
> >> > experience one overlay plane would need to be sacrificed.
> >>
> >> If you look at the development history, we've never supported cursor 
> >> planes.
> >
> > X can use an overlay to put the cursor though.
> >
> >> At the beginning we supported one main plane and one overlay plane. That 
> >> was
> >> it. The Display Engine 1.0 does have support for an extra hardware cursor,
> >> but we haven't done the work to support it yet. I don't know about the
> >> Display Engine 2.0 though.
> >
> > An issue with supporting the hardware cursor we have is that as far as
> > I understood, the cursor plane in DRM has the assumption that it would
> > be an ARGB format. In the first display engine, the format is actually
> > an 8-bit palette with 1 bit of alpha iirc.
> 
> Looks like it's 32x32 pixels with an 8-bit (max) palette, with full RGBA
> for the colors in the palette. I don't see the 1 bit alpha you mentioned.
> Looks like this needs some extra work for building the palette and copying
> the cursor image.

Indeed, you're right. I'm still not sure how it could be turned into
something useful though.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Andrzej Hajda]

On 27.03.2018 08:15, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 03/27/2018 01:22 AM, Rob Herring wrote:
>> On Tue, Mar 20, 2018 at 02:43:33PM +0200, Laurent Pinchart wrote:
>>> Hi Jacopo,
>>>
>>> (CC'ing Rob)
>>>
>>> Thank you for the patch.
>>>
>>> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
 Document Thine THC63LVD1024 LVDS decoder device tree bindings.

 Signed-off-by: Jacopo Mondi 
 Reviewed-by: Andrzej Hajda 
 Reviewed-by: Niklas Söderlund 
 ---
  .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
 +++
  1 file changed, 66 insertions(+)
  create mode 100644
 Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt

 diff --git
 a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 new file mode 100644
 index 000..8225c6a
 --- /dev/null
 +++
 b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 @@ -0,0 +1,66 @@
 +Thine Electronics THC63LVD1024 LVDS decoder
 +---
 +
 +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
 streams
 +to parallel data outputs. The chip supports single/dual input/output 
 modes,
 +handling up to two two input LVDS stream and up to two digital CMOS/TTL
 outputs.
 +
 +Single or dual operation modes, output data mapping and DDR output modes
 are
 +configured through input signals and the chip does not expose any control
 bus.
 +
 +Required properties:
 +- compatible: Shall be "thine,thc63lvd1024"
 +
 +Optional properties:
 +- vcc-supply: Power supply for TTL output and digital circuitry
 +- cvcc-supply: Power supply for TTL CLOCKOUT signal
 +- lvcc-supply: Power supply for LVDS inputs
 +- pvcc-supply: Power supply for PLL circuitry
>>> As explained in a comment to one of the previous versions of this series, 
>>> I'm 
>>> tempted to make vcc-supply mandatory and drop the three other power 
>>> supplies 
>>> for now, as I believe there's very little chance they will be connected to 
>>> separately controllable regulators (all supplies use the same voltage). In 
>>> the 
>>> very unlikely event that this occurs in design we need to support in the 
>>> future, the cvcc, lvcc and pvcc supplies can be added later as optional 
>>> without breaking backward compatibility.
>> I'm okay with that.
>>
>>> Apart from that,
>>>
>>> Reviewed-by: Laurent Pinchart 
>>>
 +- pdwn-gpios: Power down GPIO signal. Active low
>> powerdown-gpios is the semi-standard name.
>>
> right, I've also noticed it. If possible please avoid shortenings in
> property names.

It is not shortening, it just follow pin name from decoder's datasheet.

>
 +- oe-gpios: Output enable GPIO signal. Active high
 +
> And this one is also a not ever met property name, please consider to
> rename it to 'enable-gpios', for instance display panels define it.


Again, it follows datasheet naming scheme. Has something changed in DT
conventions?

Regards
Andrzej

>
 +The THC63LVD1024 video port connections are modeled according
 +to OF graph bindings specified by
 Documentation/devicetree/bindings/graph.txt
> [snip]
>
 +
 +  port@2{
 +  reg = <2>;
 +
 +  lvds_dec_out_2: endpoint {
 +  remote-endpoint = <&adv7511_in>;
 +  };
 +
> Drop a surplus empty line above.
>
 +  };
 +
> Drop a surplus empty line above.
>
 +  };
 +  };
> --
> With best wishes,
> Vladimir
>
>
>

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

Re: [PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Andrzej Hajda]

On 27.03.2018 08:24, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 03/16/2018 05:16 PM, Jacopo Mondi wrote:
>> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
>> output converter.
>>
>> Signed-off-by: Jacopo Mondi 
>> Reviewed-by: Andrzej Hajda 
>> Reviewed-by: Niklas Söderlund 
>> ---
>>  drivers/gpu/drm/bridge/Kconfig|   6 +
>>  drivers/gpu/drm/bridge/Makefile   |   1 +
>>  drivers/gpu/drm/bridge/thc63lvd1024.c | 255 
>> ++
>>  3 files changed, 262 insertions(+)
>>  create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index 3b99d5a..5815a20 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -92,6 +92,12 @@ config DRM_SII9234
>>It is an I2C driver, that detects connection of MHL bridge
>>and starts encapsulation of HDMI signal.
>>  
>> +config DRM_THINE_THC63LVD1024
>> +tristate "Thine THC63LVD1024 LVDS decoder bridge"
>> +depends on OF
>> +---help---
>> +  Thine THC63LVD1024 LVDS/parallel converter driver.
>> +
>>  config DRM_TOSHIBA_TC358767
>>  tristate "Toshiba TC358767 eDP bridge"
>>  depends on OF
>> diff --git a/drivers/gpu/drm/bridge/Makefile 
>> b/drivers/gpu/drm/bridge/Makefile
>> index 373eb28..fd90b16 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>>  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
>>  obj-$(CONFIG_DRM_SII902X) += sii902x.o
>>  obj-$(CONFIG_DRM_SII9234) += sii9234.o
>> +obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
>>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
>> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
>> b/drivers/gpu/drm/bridge/thc63lvd1024.c
>> new file mode 100644
>> index 000..02a54c2
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
>> @@ -0,0 +1,255 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
>> + *
>> + * Copyright (C) 2018 Jacopo Mondi 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +enum {
>> +THC63_LVDS_IN0,
>> +THC63_LVDS_IN1,
>> +THC63_DIGITAL_OUT0,
>> +THC63_DIGITAL_OUT1,
>> +};
>> +
>> +static const char * const thc63_reg_names[] = {
>> +"vcc", "lvcc", "pvcc", "cvcc",
>> +};
>> +
>> +struct thc63_dev {
>> +struct device *dev;
>> +
>> +struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
>> +
>> +struct gpio_desc *pdwn;
>> +struct gpio_desc *oe;
>> +
>> +struct drm_bridge bridge;
>> +struct drm_bridge *next;
>> +};
>> +
>> +static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
>> +{
>> +return container_of(bridge, struct thc63_dev, bridge);
>> +}
>> +
>> +static int thc63_attach(struct drm_bridge *bridge)
>> +{
>> +struct thc63_dev *thc63 = to_thc63(bridge);
>> +
>> +return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
>> +}
>> +
>> +static void thc63_enable(struct drm_bridge *bridge)
>> +{
>> +struct thc63_dev *thc63 = to_thc63(bridge);
>> +struct regulator *vcc;
>> +int i;
> unsigned int i;

Why? You are introducing silly bug this way, see few lines below.

>
>> +
>> +for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
>> +vcc = thc63->vccs[i];
>> +if (!vcc)
>> +continue;
>> +
>> +if (regulator_enable(vcc))
>> +goto error_vcc_enable;
>> +}
>> +
>> +if (thc63->pdwn)
>> +gpiod_set_value(thc63->pdwn, 0);
>> +
>> +if (thc63->oe)
>> +gpiod_set_value(thc63->oe, 1);
>> +
>> +return;
>> +
>> +error_vcc_enable:
>> +dev_err(thc63->dev, "Failed to enable regulator %s\n",
>> +thc63_reg_names[i]);
>> +
>> +for (i = i - 1; i >= 0; i--) {

Here, the loop will not end if you define i unsigned.

I know one can change the loop, to make it working with unsigned. But
this clearly shows that using unsigned is more risky.
What are advantages of unsigned vs int in this case. Are there some
guidelines/discussions about it?

Regards
Andrzej

>> +vcc = thc63->vccs[i];
>> +if (!vcc)
>> +continue;
>> +
>> +regulator_disable(vcc);
>> +}
>> +}
>> +
>> +static void thc63_disable(struct drm_bridge *bridge)
>> +{
>> +struct thc63_dev *thc63 = to_thc63(bridge);
>> +struct regulator *vcc;
>> +int i;
>> +
>> +if (thc63->oe)
>> +gpiod_set_value(thc63->oe, 0);
>> +
>> +if (thc63->pdwn)
>> +gpiod_set_value(thc63->pdwn, 1);
>> +
>> +for (i = ARRAY_SIZE(thc63->vccs) - 1; i >= 0; i--) {
>> +vcc = thc63->vccs[i];
>> +if (!vcc)
>> +

Re: [PATCH] drm/syncobj: Stop reusing the same struct file for all syncobj -> fd

[Greg KH]

On Mon, Mar 26, 2018 at 12:00:37PM -0700, Jason Ekstrand wrote:
> From: Chris Wilson 
> 
> The vk cts test:
> dEQP-VK.api.external.semaphore.opaque_fd.export_multiple_times_temporary
> 
> triggers a lot of
> VFS: Close: file count is 0
> 
> Dave pointed out that clearing the syncobj->file from
> drm_syncobj_file_release() was sufficient to silence the test, but that
> opens a can of worm since we assumed that the syncobj->file was never
> unset. Stop trying to reuse the same struct file for every fd pointing
> to the drm_syncobj, and allocate one file for each fd instead.
> 
> v2: Fixup return handling of drm_syncobj_fd_to_handle
> v2.1: [airlied: fix possible syncobj ref race]
> v2.2: [jekstrand: back-port to 4.14]
> 
> Reported-by: Dave Airlie 
> Signed-off-by: Chris Wilson 
> Tested-by: Dave Airlie 
> Reviewed-by: Daniel Vetter 
> Signed-off-by: Dave Airlie 
> Signed-off-by: Jason Ekstrand 
> Tested-by: Clayton Craft 
> ---
> 
> The back-port from 4.15 to 4.14 was non-trivial.  It'd be good if Chris and
> maybe Daniel could do a quick re-review.

Now queued up, thanks.

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

Re: [PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[jacopo mondi]

HI Vladimir,

On Tue, Mar 27, 2018 at 09:24:28AM +0300, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 03/16/2018 05:16 PM, Jacopo Mondi wrote:
> > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> > output converter.
> >
> > Signed-off-by: Jacopo Mondi 
> > Reviewed-by: Andrzej Hajda 
> > Reviewed-by: Niklas Söderlund 
> > ---
> >  drivers/gpu/drm/bridge/Kconfig|   6 +
> >  drivers/gpu/drm/bridge/Makefile   |   1 +
> >  drivers/gpu/drm/bridge/thc63lvd1024.c | 255 
> > ++
> >  3 files changed, 262 insertions(+)
> >  create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 3b99d5a..5815a20 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -92,6 +92,12 @@ config DRM_SII9234
> >   It is an I2C driver, that detects connection of MHL bridge
> >   and starts encapsulation of HDMI signal.
> >
> > +config DRM_THINE_THC63LVD1024
> > +   tristate "Thine THC63LVD1024 LVDS decoder bridge"
> > +   depends on OF
> > +   ---help---
> > + Thine THC63LVD1024 LVDS/parallel converter driver.
> > +
> >  config DRM_TOSHIBA_TC358767
> > tristate "Toshiba TC358767 eDP bridge"
> > depends on OF
> > diff --git a/drivers/gpu/drm/bridge/Makefile 
> > b/drivers/gpu/drm/bridge/Makefile
> > index 373eb28..fd90b16 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> >  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
> >  obj-$(CONFIG_DRM_SII902X) += sii902x.o
> >  obj-$(CONFIG_DRM_SII9234) += sii9234.o
> > +obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
> >  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> >  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> >  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> > diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
> > b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > new file mode 100644
> > index 000..02a54c2
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > @@ -0,0 +1,255 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
> > + *
> > + * Copyright (C) 2018 Jacopo Mondi 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +enum {
> > +   THC63_LVDS_IN0,
> > +   THC63_LVDS_IN1,
> > +   THC63_DIGITAL_OUT0,
> > +   THC63_DIGITAL_OUT1,
> > +};
> > +
> > +static const char * const thc63_reg_names[] = {
> > +   "vcc", "lvcc", "pvcc", "cvcc",
> > +};
> > +
> > +struct thc63_dev {
> > +   struct device *dev;
> > +
> > +   struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
> > +
> > +   struct gpio_desc *pdwn;
> > +   struct gpio_desc *oe;
> > +
> > +   struct drm_bridge bridge;
> > +   struct drm_bridge *next;
> > +};
> > +
> > +static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
> > +{
> > +   return container_of(bridge, struct thc63_dev, bridge);
> > +}
> > +
> > +static int thc63_attach(struct drm_bridge *bridge)
> > +{
> > +   struct thc63_dev *thc63 = to_thc63(bridge);
> > +
> > +   return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
> > +}
> > +
> > +static void thc63_enable(struct drm_bridge *bridge)
> > +{
> > +   struct thc63_dev *thc63 = to_thc63(bridge);
> > +   struct regulator *vcc;
> > +   int i;
>
> unsigned int i;
>
> > +
> > +   for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> > +   vcc = thc63->vccs[i];
> > +   if (!vcc)
> > +   continue;
> > +
> > +   if (regulator_enable(vcc))
> > +   goto error_vcc_enable;
> > +   }
> > +
> > +   if (thc63->pdwn)
> > +   gpiod_set_value(thc63->pdwn, 0);
> > +
> > +   if (thc63->oe)
> > +   gpiod_set_value(thc63->oe, 1);
> > +
> > +   return;
> > +
> > +error_vcc_enable:
> > +   dev_err(thc63->dev, "Failed to enable regulator %s\n",
> > +   thc63_reg_names[i]);
> > +
> > +   for (i = i - 1; i >= 0; i--) {
> > +   vcc = thc63->vccs[i];
> > +   if (!vcc)
> > +   continue;
> > +
> > +   regulator_disable(vcc);
> > +   }
> > +}
> > +
> > +static void thc63_disable(struct drm_bridge *bridge)
> > +{
> > +   struct thc63_dev *thc63 = to_thc63(bridge);
> > +   struct regulator *vcc;
> > +   int i;
> > +
> > +   if (thc63->oe)
> > +   gpiod_set_value(thc63->oe, 0);
> > +
> > +   if (thc63->pdwn)
> > +   gpiod_set_value(thc63->pdwn, 1);
> > +
> > +   for (i = ARRAY_SIZE(thc63->vccs) - 1; i >= 0; i--) {
> > +   vcc = thc63->vccs[i];
> > +   if (!vcc)
> > +   continue;
> > +
> > +   if (regulator_disable(vcc))
> > +   dev_dbg(thc63->dev,
> > +   "Failed to disable regulator %s\n",
> > +   thc63_reg_names[i]);
> 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Andrzej,

On Tue, Mar 27, 2018 at 09:12:46AM +0200, Andrzej Hajda wrote:
> On 27.03.2018 08:15, Vladimir Zapolskiy wrote:
> > Hi Jacopo,
> >
> > On 03/27/2018 01:22 AM, Rob Herring wrote:
> >> On Tue, Mar 20, 2018 at 02:43:33PM +0200, Laurent Pinchart wrote:
> >>> Hi Jacopo,
> >>>
> >>> (CC'ing Rob)
> >>>
> >>> Thank you for the patch.
> >>>
> >>> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
>  Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> 
>  Signed-off-by: Jacopo Mondi 
>  Reviewed-by: Andrzej Hajda 
>  Reviewed-by: Niklas Söderlund 
>  ---
>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
>  +++
>   1 file changed, 66 insertions(+)
>   create mode 100644
>  Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> 
>  diff --git
>  a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>  b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>  new file mode 100644
>  index 000..8225c6a
>  --- /dev/null
>  +++
>  b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>  @@ -0,0 +1,66 @@
>  +Thine Electronics THC63LVD1024 LVDS decoder
>  +---
>  +
>  +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
>  streams
>  +to parallel data outputs. The chip supports single/dual input/output 
>  modes,
>  +handling up to two two input LVDS stream and up to two digital CMOS/TTL
>  outputs.
>  +
>  +Single or dual operation modes, output data mapping and DDR output modes
>  are
>  +configured through input signals and the chip does not expose any 
>  control
>  bus.
>  +
>  +Required properties:
>  +- compatible: Shall be "thine,thc63lvd1024"
>  +
>  +Optional properties:
>  +- vcc-supply: Power supply for TTL output and digital circuitry
>  +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>  +- lvcc-supply: Power supply for LVDS inputs
>  +- pvcc-supply: Power supply for PLL circuitry
> >>> As explained in a comment to one of the previous versions of this series, 
> >>> I'm
> >>> tempted to make vcc-supply mandatory and drop the three other power 
> >>> supplies
> >>> for now, as I believe there's very little chance they will be connected to
> >>> separately controllable regulators (all supplies use the same voltage). 
> >>> In the
> >>> very unlikely event that this occurs in design we need to support in the
> >>> future, the cvcc, lvcc and pvcc supplies can be added later as optional
> >>> without breaking backward compatibility.
> >> I'm okay with that.
> >>
> >>> Apart from that,
> >>>
> >>> Reviewed-by: Laurent Pinchart 
> >>>
>  +- pdwn-gpios: Power down GPIO signal. Active low
> >> powerdown-gpios is the semi-standard name.
> >>
> > right, I've also noticed it. If possible please avoid shortenings in
> > property names.
>
> It is not shortening, it just follow pin name from decoder's datasheet.
>
> >
>  +- oe-gpios: Output enable GPIO signal. Active high
>  +
> > And this one is also a not ever met property name, please consider to
> > rename it to 'enable-gpios', for instance display panels define it.
>
>
> Again, it follows datasheet naming scheme. Has something changed in DT
> conventions?

Seconded. My understanding is that the property name should reflect
what reported in the the chip manual. For THC63LVD1024 the enable and
power down pins are named 'OE' and 'PDWN' respectively.

Thanks
   j

>
> Regards
> Andrzej
>
> >
>  +The THC63LVD1024 video port connections are modeled according
>  +to OF graph bindings specified by
>  Documentation/devicetree/bindings/graph.txt
> > [snip]
> >
>  +
>  +port@2{
>  +reg = <2>;
>  +
>  +lvds_dec_out_2: endpoint {
>  +remote-endpoint = <&adv7511_in>;
>  +};
>  +
> > Drop a surplus empty line above.
> >
>  +};
>  +
> > Drop a surplus empty line above.
> >
>  +};
>  +};
> > --
> > With best wishes,
> > Vladimir
> >
> >
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

[Christian König]

Am 26.03.2018 um 17:42 schrieb Jerome Glisse:

On Mon, Mar 26, 2018 at 10:01:21AM +0200, Daniel Vetter wrote:

On Thu, Mar 22, 2018 at 10:58:55AM +0100, Christian König wrote:

Am 22.03.2018 um 08:18 schrieb Daniel Vetter:
[SNIP]
Key take away from that was that you can't take any locks from neither the
MMU notifier nor the shrinker you also take while calling kmalloc (or
simpler speaking get_user_pages()).

Additional to that in the MMU or shrinker callback all different kinds of
locks might be held, so you basically can't assume that you do thinks like
recursive page table walks or call dma_unmap_anything.

That sounds like a design bug in mmu_notifiers, since it would render them
useless for KVM. And they were developed for that originally. I think I'll
chat with Jerome to understand this, since it's all rather confusing.

Doing dma_unmap() during mmu_notifier callback should be fine, it was last
time i check. However there is no formal contract that it is ok to do so.


As I said before dma_unmap() isn't the real problem here.

The issues is more that you can't take a lock in the MMU notifier which 
you would also take while allocating memory without GFP_NOIO.


That makes it rather tricky to do any command submission, e.g. you need 
to grab all the pages/memory/resources prehand, then make sure that you 
don't have a MMU notifier running concurrently and do the submission.


If any of the prerequisites isn't fulfilled we need to restart the 
operation.



[SNIP]
A slightly better solution is using atomic counter:
   driver_range_start() {
 atomic_inc(&mydev->notifier_count);

...

Yeah, that is exactly what amdgpu is doing now. Sorry if my description 
didn't made that clear.



I would like to see driver using same code, as it means one place to fix
issues. I had for a long time on my TODO list doing the above conversion
to amd or radeon kernel driver. I am pushing up my todo list hopefully in
next few weeks i can send an rfc so people can have a real sense of how
it can look.


Certainly a good idea, but I think we might have that separate to HMM.

TTM suffered really from feature overload, e.g. trying to do everything 
in a single subsystem. And it would be rather nice to have coherent 
userptr handling for GPUs as separate feature.


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

Re: [PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Geert Uytterhoeven]

Hi Andrzej,

On Tue, Mar 27, 2018 at 9:28 AM, Andrzej Hajda  wrote:
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c

>>> +static void thc63_enable(struct drm_bridge *bridge)
>>> +{
>>> +struct thc63_dev *thc63 = to_thc63(bridge);
>>> +struct regulator *vcc;
>>> +int i;
>> unsigned int i;
>
> Why? You are introducing silly bug this way, see few lines below.
>
>>
>>> +
>>> +for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
>>> +vcc = thc63->vccs[i];
>>> +if (!vcc)
>>> +continue;
>>> +
>>> +if (regulator_enable(vcc))
>>> +goto error_vcc_enable;
>>> +}
>>> +
>>> +if (thc63->pdwn)
>>> +gpiod_set_value(thc63->pdwn, 0);
>>> +
>>> +if (thc63->oe)
>>> +gpiod_set_value(thc63->oe, 1);
>>> +
>>> +return;
>>> +
>>> +error_vcc_enable:
>>> +dev_err(thc63->dev, "Failed to enable regulator %s\n",
>>> +thc63_reg_names[i]);
>>> +
>>> +for (i = i - 1; i >= 0; i--) {
>
> Here, the loop will not end if you define i unsigned.

True.

> I know one can change the loop, to make it working with unsigned. But
> this clearly shows that using unsigned is more risky.
> What are advantages of unsigned vs int in this case. Are there some
> guidelines/discussions about it?

Some people consider signed integers harmful, as they may be converted
silently by the compiler to the "larger" unsigned type when needed.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 07/23] drm: Make the fb refcount handover less magic

[Daniel Vetter]

On Thu, Mar 22, 2018 at 05:22:57PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Instead of assigning the plane->fb pointer and clearing the fb pointer
> to hand over the reference, let's just do it by grabbing another
> referece for plane->fb and let fb keep its original one.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_plane.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index bedceca7dd06..008f9456a5e8 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -1084,8 +1084,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>   plane->old_fb = NULL;
>   } else {
>   plane->fb = fb;
> - /* Unref only the old framebuffer. */
> - fb = NULL;
> + drm_framebuffer_get(fb);
>   }
>  
>  out:
> -- 
> 2.16.1
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

[Daniel Vetter]

On Tue, Mar 27, 2018 at 09:35:17AM +0200, Christian König wrote:
> Am 26.03.2018 um 17:42 schrieb Jerome Glisse:
> > On Mon, Mar 26, 2018 at 10:01:21AM +0200, Daniel Vetter wrote:
> > > On Thu, Mar 22, 2018 at 10:58:55AM +0100, Christian König wrote:
> > > > Am 22.03.2018 um 08:18 schrieb Daniel Vetter:
> > > > [SNIP]
> > > > Key take away from that was that you can't take any locks from neither 
> > > > the
> > > > MMU notifier nor the shrinker you also take while calling kmalloc (or
> > > > simpler speaking get_user_pages()).
> > > > 
> > > > Additional to that in the MMU or shrinker callback all different kinds 
> > > > of
> > > > locks might be held, so you basically can't assume that you do thinks 
> > > > like
> > > > recursive page table walks or call dma_unmap_anything.
> > > That sounds like a design bug in mmu_notifiers, since it would render them
> > > useless for KVM. And they were developed for that originally. I think I'll
> > > chat with Jerome to understand this, since it's all rather confusing.
> > Doing dma_unmap() during mmu_notifier callback should be fine, it was last
> > time i check. However there is no formal contract that it is ok to do so.
> 
> As I said before dma_unmap() isn't the real problem here.
> 
> The issues is more that you can't take a lock in the MMU notifier which you
> would also take while allocating memory without GFP_NOIO.
> 
> That makes it rather tricky to do any command submission, e.g. you need to
> grab all the pages/memory/resources prehand, then make sure that you don't
> have a MMU notifier running concurrently and do the submission.
> 
> If any of the prerequisites isn't fulfilled we need to restart the
> operation.

Yeah we're hitting all that epic amount of fun now, after a chat with
Jerome yesterady. I guess we'll figure out what we're coming up with.

> > [SNIP]
> > A slightly better solution is using atomic counter:
> >driver_range_start() {
> >  atomic_inc(&mydev->notifier_count);
> ...
> 
> Yeah, that is exactly what amdgpu is doing now. Sorry if my description
> didn't made that clear.
> 
> > I would like to see driver using same code, as it means one place to fix
> > issues. I had for a long time on my TODO list doing the above conversion
> > to amd or radeon kernel driver. I am pushing up my todo list hopefully in
> > next few weeks i can send an rfc so people can have a real sense of how
> > it can look.
> 
> Certainly a good idea, but I think we might have that separate to HMM.
> 
> TTM suffered really from feature overload, e.g. trying to do everything in a
> single subsystem. And it would be rather nice to have coherent userptr
> handling for GPUs as separate feature.

TTM suffered from being a midlayer imo, not from doing too much. HMM is
apparently structured like a toolbox (despite its documentation claiming
otherwise), so you can pick&choose freely.
-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: [Intel-gfx] [PATCH 15/23] drm: Stop updating plane->crtc/fb/old_fb on atomic drivers

[Daniel Vetter]

On Thu, Mar 22, 2018 at 05:23:05PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Stop playing around with plane->crtc/fb/old_fb with atomic
> drivers. Make life a lot simpler when we don't have to do the
> magic old_fb vs. fb dance around plane updates. That way we
> can't risk plane->fb getting out of sync with plane->state->fb
> and we're less likely to leak any refcounts as well.
> 
> Signed-off-by: Ville Syrjälä 

What's the reason for this patch being in the middle of the patch series?
I figured it's savest if we put this at the end? If you need parts of this
here, we definitely need to split out the WARN_ON hunk, since you haven't
fixed up everything yet at this point here.
-Daniel

> ---
>  drivers/gpu/drm/drm_atomic.c| 55 
> -
>  drivers/gpu/drm/drm_atomic_helper.c | 15 +-
>  drivers/gpu/drm/drm_crtc.c  |  8 --
>  drivers/gpu/drm/drm_fb_helper.c |  7 -
>  drivers/gpu/drm/drm_framebuffer.c   |  5 
>  drivers/gpu/drm/drm_plane.c | 14 ++
>  drivers/gpu/drm/drm_plane_helper.c  |  4 ++-
>  include/drm/drm_atomic.h|  3 --
>  8 files changed, 24 insertions(+), 87 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 7d25c42f22db..b16cc37e2adf 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -692,6 +692,11 @@ drm_atomic_get_plane_state(struct drm_atomic_state 
> *state,
>  
>   WARN_ON(!state->acquire_ctx);
>  
> + /* the legacy pointers should never be set */
> + WARN_ON(plane->fb);
> + WARN_ON(plane->old_fb);
> + WARN_ON(plane->crtc);
> +
>   plane_state = drm_atomic_get_existing_plane_state(state, plane);
>   if (plane_state)
>   return plane_state;
> @@ -2021,45 +2026,6 @@ int drm_atomic_set_property(struct drm_atomic_state 
> *state,
>   return ret;
>  }
>  
> -/**
> - * drm_atomic_clean_old_fb -- Unset old_fb pointers and set plane->fb 
> pointers.
> - *
> - * @dev: drm device to check.
> - * @plane_mask: plane mask for planes that were updated.
> - * @ret: return value, can be -EDEADLK for a retry.
> - *
> - * Before doing an update &drm_plane.old_fb is set to &drm_plane.fb, but 
> before
> - * dropping the locks old_fb needs to be set to NULL and plane->fb updated. 
> This
> - * is a common operation for each atomic update, so this call is split off 
> as a
> - * helper.
> - */
> -void drm_atomic_clean_old_fb(struct drm_device *dev,
> -  unsigned plane_mask,
> -  int ret)
> -{
> - struct drm_plane *plane;
> -
> - /* if succeeded, fixup legacy plane crtc/fb ptrs before dropping
> -  * locks (ie. while it is still safe to deref plane->state).  We
> -  * need to do this here because the driver entry points cannot
> -  * distinguish between legacy and atomic ioctls.
> -  */
> - drm_for_each_plane_mask(plane, dev, plane_mask) {
> - if (ret == 0) {
> - struct drm_framebuffer *new_fb = plane->state->fb;
> - if (new_fb)
> - drm_framebuffer_get(new_fb);
> - plane->fb = new_fb;
> - plane->crtc = plane->state->crtc;
> -
> - if (plane->old_fb)
> - drm_framebuffer_put(plane->old_fb);
> - }
> - plane->old_fb = NULL;
> - }
> -}
> -EXPORT_SYMBOL(drm_atomic_clean_old_fb);
> -
>  /**
>   * DOC: explicit fencing properties
>   *
> @@ -2280,9 +2246,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   unsigned int copied_objs, copied_props;
>   struct drm_atomic_state *state;
>   struct drm_modeset_acquire_ctx ctx;
> - struct drm_plane *plane;
>   struct drm_out_fence_state *fence_state;
> - unsigned plane_mask;
>   int ret = 0;
>   unsigned int i, j, num_fences;
>  
> @@ -2322,7 +2286,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
>  
>  retry:
> - plane_mask = 0;
>   copied_objs = 0;
>   copied_props = 0;
>   fence_state = NULL;
> @@ -2393,12 +2356,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   copied_props++;
>   }
>  
> - if (obj->type == DRM_MODE_OBJECT_PLANE && count_props &&
> - !(arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)) {
> - plane = obj_to_plane(obj);
> - plane_mask |= (1 << drm_plane_index(plane));
> - plane->old_fb = plane->fb;
> - }
>   drm_mode_object_put(obj);
>   }
>  
> @@ -2419,8 +2376,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   }
>  
>  out:
> - drm_atomic_clean_old_fb(dev, plane_mask, ret);
> -
>   complete_crtc_signaling(dev, state, fence_state, num_fences, !ret);
>  
>  

Re: [PATCHv2 6/7] cec-pin-error-inj.rst: document CEC Pin Error Injection

[Jani Nikula]

On Wed, 21 Mar 2018, Mauro Carvalho Chehab  wrote:
> Please notice that all debugfs/sysfs entries should *also* be
> documented at the standard way, e. g. by adding the corresponding
> documentation at Documentation/ABI.
>
> Please see Documentation/ABI/README.
>
> Additionally, there are a few minor nitpicks on this patch.
> See below.
>
> The remaining patches looked ok on my eyes.
>
> I'll wait for a v3 with the debugfs ABI documentation in order to merge
> it. Feel free to put it on a separate patch.

debugfs ABI? Sounds like an oxymoron to me.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/10] drm/sun4i: Disable YUV channel when using the frontend and set interlace

[Paul Kocialkowski]

Hi,

On Fri, 2018-03-23 at 10:55 +0100, Maxime Ripard wrote:
> On Wed, Mar 21, 2018 at 04:28:56PM +0100, Paul Kocialkowski wrote:
> > The YUV channel was only disabled in
> > sun4i_backend_update_layer_formats,
> > which is not called when the frontend is selected.
> > 
> > Thus, creating a layer with a YUV format handled by the backend and
> > then
> > switching to a format that requires the frontend would keep the YUV
> > channel enabled for the layer.
> > 
> > This explicitly disables the YUV channel for the layer when using
> > the
> > frontend as well. It also sets the relevant interlace bit, which was
> > missing in the frontend path as well.
> 
> This should be part of a separate patch. Usually, if you write "it
> also does..." at the end of your commit log, it's a pretty good
> indication that it should be another patch :)

I must say, I figured that this part was missing in the frontend path by
chance and couldn't really test the feature, so I'm also tempted to drop
it altogether. What do you think?

Also, is interlacing actually used on any of the video outputs we
support? Perhaps RGB?

> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/gpu/drm/sun4i/sun4i_backend.c | 17 -
> >  drivers/gpu/drm/sun4i/sun4i_backend.h |  3 ++-
> >  drivers/gpu/drm/sun4i/sun4i_layer.c   |  2 +-
> >  3 files changed, 19 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> > b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > index e07a33adc51d..b98dafda52f8 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > @@ -294,8 +294,10 @@ int sun4i_backend_update_layer_formats(struct
> > sun4i_backend *backend,
> >  }
> >  
> >  int sun4i_backend_update_layer_frontend(struct sun4i_backend
> > *backend,
> > -   int layer, uint32_t fmt)
> > +   int layer, struct drm_plane
> > *plane,
> > +   uint32_t fmt)
> >  {
> > +   bool interlaced = false;
> 
> There's no need to pass the full drm_plane pointer, you can just pass
> a boolean to tell if it is interlaced or not.

Yes that'll do just as well.

Thanks,

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

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: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

[Christian König]

Am 27.03.2018 um 09:53 schrieb Daniel Vetter:

[SNIP]

[SNIP]
A slightly better solution is using atomic counter:
driver_range_start() {
  atomic_inc(&mydev->notifier_count);

...

Yeah, that is exactly what amdgpu is doing now. Sorry if my description
didn't made that clear.


I would like to see driver using same code, as it means one place to fix
issues. I had for a long time on my TODO list doing the above conversion
to amd or radeon kernel driver. I am pushing up my todo list hopefully in
next few weeks i can send an rfc so people can have a real sense of how
it can look.

Certainly a good idea, but I think we might have that separate to HMM.

TTM suffered really from feature overload, e.g. trying to do everything in a
single subsystem. And it would be rather nice to have coherent userptr
handling for GPUs as separate feature.

TTM suffered from being a midlayer imo, not from doing too much.


Yeah, completely agree.

midlayers work as long as you concentrate on doing exactly one things in 
your midlayer. E.g. in the case of TTM the callback for BO move handling 
is well justified.


Only all the stuff around it like address space handling etc... is 
really wrong designed and should be separated (which is exactly what DRM 
MM did, but TTM still uses this in the wrong way).



HMM is apparently structured like a toolbox (despite its documentation claiming
otherwise), so you can pick&choose freely.


That sounds good, but I would still have a better feeling if userptr 
handling would be separated. That avoids mangling things together again.


Christian.


-Daniel


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

Re: [PATCHv2 6/7] cec-pin-error-inj.rst: document CEC Pin Error Injection

[Wolfram Sang]

> > I'll wait for a v3 with the debugfs ABI documentation in order to merge
> > it. Feel free to put it on a separate patch.
> 
> debugfs ABI? Sounds like an oxymoron to me.

Heh, thought the same :)



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

Re: [PATCH 04/10] drm/sun4i: Explicitly list and check formats supported by the backend

[Paul Kocialkowski]

Hi,

On Fri, 2018-03-23 at 11:03 +0100, Maxime Ripard wrote:
> On Wed, Mar 21, 2018 at 04:28:58PM +0100, Paul Kocialkowski wrote:
> > In order to check whether the backend supports a specific format, an
> > explicit list and a related helper are introduced.
> > 
> > They are then used to determine whether the frontend should be used
> > for
> > a layer, when the format is not supported by the backend.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/gpu/drm/sun4i/sun4i_backend.c | 48
> > ++-
> >  drivers/gpu/drm/sun4i/sun4i_backend.h |  1 +
> >  2 files changed, 48 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> > b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > index 274a1db6fa8e..7703ba989743 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > @@ -172,6 +172,39 @@ static int
> > sun4i_backend_drm_format_to_layer(u32 format, u32 *mode)
> > return 0;
> >  }
> >  
> > +static const uint32_t sun4i_backend_formats[] = {
> > +   /* RGB */
> > +   DRM_FORMAT_ARGB,
> > +   DRM_FORMAT_RGBA,
> > +   DRM_FORMAT_ARGB1555,
> > +   DRM_FORMAT_RGBA5551,
> > +   DRM_FORMAT_RGB565,
> > +   DRM_FORMAT_RGB888,
> > +   DRM_FORMAT_XRGB,
> > +   DRM_FORMAT_BGRX,
> > +   DRM_FORMAT_ARGB,
> > +   /* YUV422 */
> > +   DRM_FORMAT_YUYV,
> > +   DRM_FORMAT_YVYU,
> > +   DRM_FORMAT_UYVY,
> > +   DRM_FORMAT_VYUY,
> 
> Ordering them by alphabetical order would be better.

Frankly I find it a lot harder to read when the formats are not grouped
by "family". This is the drm_fourcc enumeration order, which has some
kind of logic behind it. What is the advantage of alphabetical ordering
here?

> > +};
> > +
> > +bool sun4i_backend_format_is_supported(uint32_t fmt)
> > +{
> > +   bool found = false;
> > +   unsigned int i;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(sun4i_backend_formats); i++) {
> > +   if (sun4i_backend_formats[i] == fmt) {
> > +   found = true;
> > +   break;
> 
> return true?

Definitely.

> > +   }
> > +   }
> > +
> > +   return found;
> > +}
> > +
> >  int sun4i_backend_update_layer_coord(struct sun4i_backend *backend,
> >  int layer, struct drm_plane
> > *plane)
> >  {
> > @@ -436,15 +469,28 @@ static bool
> > sun4i_backend_plane_uses_frontend(struct drm_plane_state *state)
> >  {
> > struct sun4i_layer *layer = plane_to_sun4i_layer(state-
> > >plane);
> > struct sun4i_backend *backend = layer->backend;
> > +   struct drm_framebuffer *fb = state->fb;
> >  
> > if (IS_ERR(backend->frontend))
> > return false;
> >  
> > +   /*
> > +* Let's pretend that every format is either supported by
> > the backend or
> > +* the frontend. This is not true in practice, as some
> > tiling modes are
> > +* not supported by either. There is still room to check
> > this later in
> > +* the atomic check process.
> 
> Then I guess there these tiling modes will not be exposed and we won't
> ever get that far, wouldn't we?

This comment is indeed a bit irrelevant at this stage given that the
tiling modifier was not introduced yet. So in practice, this never
happens with this patch. I should probably move it to a subsequent one.

> > +*/
> > +   if (!sun4i_backend_format_is_supported(fb->format->format))
> > +   return true;
> 
> Even though there's a comment, this is not really natural. We are
> checking whether the frontend supports the current plane_state, so it
> just makes more sense to check whether the frontend supports the
> format, rather than if the backend doesn't support them.

The rationale behind this logic is that we should try to use the backend
first and only use the frontend as a last resort. Some formats are
supported by both and checking that the backend supports a format first
ensures that we don't bring up the frontend without need.

Cheers,

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

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: [Intel-gfx] [PATCH 08/23] drm: Use plane->state->fb over plane->fb

[Daniel Vetter]

On Thu, Mar 22, 2018 at 05:22:58PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Stop looking at plane->fb on atomic drivers. Use plane->state->fb
> instead.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_atomic_helper.c |  2 +-
>  drivers/gpu/drm/drm_crtc.c  | 11 +--
>  drivers/gpu/drm/drm_plane.c | 19 ++-
>  3 files changed, 24 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 1b39ebf2be2e..0e806f070d00 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2659,7 +2659,7 @@ int drm_atomic_helper_disable_plane(struct drm_plane 
> *plane,
>   goto fail;
>   }
>  
> - if (plane_state->crtc && (plane == plane->crtc->cursor))
> + if (plane_state->crtc && plane_state->crtc->cursor == plane)
>   plane_state->state->legacy_cursor_update = true;
>  
>   ret = __drm_atomic_helper_disable_plane(plane, plane_state);
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 537ffaab855c..a231dd5dce16 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -597,13 +597,20 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>   /* If we have a mode we need a framebuffer. */
>   /* If we pass -1, set the mode with the currently bound fb */
>   if (crtc_req->fb_id == -1) {
> - if (!plane->fb) {
> + struct drm_framebuffer *old_fb;
> +
> + if (plane->state)
> + old_fb = plane->state->fb;
> + else
> + old_fb = plane->fb;
> +
> + if (!old_fb) {
>   DRM_DEBUG_KMS("CRTC doesn't have current FB\n");
>   ret = -EINVAL;
>   goto out;
>   }
>  
> - fb = plane->fb;
> + fb = old_fb;
>   /* Make refcounting symmetric with the lookup path. */
>   drm_framebuffer_get(fb);
>   } else {
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 008f9456a5e8..035054455301 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -792,7 +792,11 @@ static int drm_mode_cursor_universal(struct drm_crtc 
> *crtc,
>   fb = NULL;
>   }
>   } else {
> - fb = plane->fb;
> + if (plane->state)
> + fb = plane->state->fb;
> + else
> + fb = plane->fb;
> +
>   if (fb)
>   drm_framebuffer_get(fb);
>   }
> @@ -934,7 +938,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>   struct drm_mode_crtc_page_flip_target *page_flip = data;
>   struct drm_crtc *crtc;
>   struct drm_plane *plane;
> - struct drm_framebuffer *fb = NULL;
> + struct drm_framebuffer *fb = NULL, *old_fb;
>   struct drm_pending_vblank_event *e = NULL;
>   u32 target_vblank = page_flip->sequence;
>   struct drm_modeset_acquire_ctx ctx;
> @@ -1012,7 +1016,12 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>   if (ret)
>   goto out;
>  
> - if (plane->fb == NULL) {
> + if (plane->state)
> + old_fb = plane->state->fb;
> + else
> + old_fb = plane->fb;
> +
> + if (old_fb == NULL) {
>   /* The framebuffer is currently unbound, presumably
>* due to a hotplug event, that userspace has not
>* yet discovered.
> @@ -1027,7 +1036,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>   goto out;
>   }
>  
> - if (crtc->state) {
> + if (plane->state) {
>   const struct drm_plane_state *state = plane->state;
>  
>   ret = drm_framebuffer_check_src_coords(state->src_x,
> @@ -1042,7 +1051,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>   if (ret)
>   goto out;
>  
> - if (plane->fb->format != fb->format) {
> + if (old_fb->format != fb->format) {
>   DRM_DEBUG_KMS("Page flip is not allowed to change frame buffer 
> format.\n");
>   ret = -EINVAL;
>   goto out;
> -- 
> 2.16.1
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 14/23] drm/atmel-hlcdc: Stop using plane->fb

[Daniel Vetter]

On Thu, Mar 22, 2018 at 05:23:04PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> We want to get rid of plane->fb on atomic drivers. Stop looking at it.
> 
> Cc: Boris Brezillon 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index e18800ed7cd1..0dd9fb617c28 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -819,16 +819,6 @@ static void atmel_hlcdc_plane_atomic_disable(struct 
> drm_plane *p,
>   atmel_hlcdc_layer_read_reg(&plane->layer, ATMEL_HLCDC_LAYER_ISR);
>  }
>  
> -static void atmel_hlcdc_plane_destroy(struct drm_plane *p)
> -{
> - struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
> -
> - if (plane->base.fb)
> - drm_framebuffer_put(plane->base.fb);
> -
> - drm_plane_cleanup(p);
> -}

This looks like refcount leak duct-tape due to lack of
drm_atomic_helper_shutdown() in atmel. If you just apply this I think
you'll start leaking.

We need a patch here to add the shutdown call instead.
-Daniel

> -
>  static int atmel_hlcdc_plane_atomic_set_property(struct drm_plane *p,
>struct drm_plane_state *s,
>struct drm_property *property,
> @@ -1038,7 +1028,7 @@ static void 
> atmel_hlcdc_plane_atomic_destroy_state(struct drm_plane *p,
>  static const struct drm_plane_funcs layer_plane_funcs = {
>   .update_plane = drm_atomic_helper_update_plane,
>   .disable_plane = drm_atomic_helper_disable_plane,
> - .destroy = atmel_hlcdc_plane_destroy,
> + .destroy = drm_plane_cleanup,
>   .reset = atmel_hlcdc_plane_reset,
>   .atomic_duplicate_state = atmel_hlcdc_plane_atomic_duplicate_state,
>   .atomic_destroy_state = atmel_hlcdc_plane_atomic_destroy_state,
> -- 
> 2.16.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [RFC PATCH 2/3] drm: bridge: panel: allow override of the bus format

[jacopo mondi]

HI Laurent, Peter,

On Mon, Mar 26, 2018 at 10:03:31PM +0300, Laurent Pinchart wrote:
> Hi Peter,
>
> (CC'ing Jacopo Mondi)
>
> On Sunday, 25 March 2018 15:01:11 EEST Peter Rosin wrote:
> > On 2018-03-20 14:56, Laurent Pinchart wrote:
> > > Hi Peter,
> > >
> > > Thank you for the patch.
> > >
> > > On Sunday, 18 March 2018 00:15:24 EET Peter Rosin wrote:
> > >> Useful if the bridge does some kind of conversion of the bus format.
> > >>
> > >> Signed-off-by: Peter Rosin 
> > >> ---
> > >>
> > >>  drivers/gpu/drm/bridge/panel.c | 22 +-
> > >>  include/drm/drm_bridge.h   |  1 +
> > >>  2 files changed, 22 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/bridge/panel.c
> > >> b/drivers/gpu/drm/bridge/panel.c index 6d99d4a3beb3..ccef0283ff41 100644
> > >> --- a/drivers/gpu/drm/bridge/panel.c
> > >> +++ b/drivers/gpu/drm/bridge/panel.c
> > >> @@ -22,6 +22,7 @@ struct panel_bridge {
> > >>  struct drm_connector connector;
> > >>  struct drm_panel *panel;
> > >>  u32 connector_type;
> > >> +u32 bus_format;
> > >>  };
> > >>
> > >>  static inline struct panel_bridge *
> > >> @@ -40,8 +41,15 @@ static int panel_bridge_connector_get_modes(struct
> > >> drm_connector *connector) {
> > >>  struct panel_bridge *panel_bridge =
> > >>  drm_connector_to_panel_bridge(connector);
> > >>
> > >> +int ret;
> > >> +
> > >> +ret = drm_panel_get_modes(panel_bridge->panel);
> > >> +
> > >> +if (panel_bridge->bus_format)
> > >> +
> > >> drm_display_info_set_bus_formats(&connector->display_info,
> > >> + 
> > >> &panel_bridge->bus_format, 1);
> > >
> > > While I agree with the problem statement and, to some extent, the DT
> > > bindings, I don't think this is the right implementation. You've
> > > correctly noted that display controller shouldn't blindly use the formats
> > > reported by the panel through the connector formats, and that hacking the
> > > panel driver to override the formats isn't a good idea, so I wouldn't
> > > override the formats reported by the connector. I would instead extend
> > > the drm_bridge API to report formats at bridge inputs. This would be more
> > > generic and allow each bridge to configure itself according to the next
> > > bridge in the chain.
> > >
> > > I'm not sure whether this API extension should be in the form of a new
> > > bridge function, or if the formats should be stored in the drm_bridge
> > > structure directly as done for connectors in the display info structure.
> > > I'm tempted by the former, but I'm open to discussions.
> >
> > Ok, I can look into that, but let me check if I got this right. From the
> > very little of the code that I have looked at, I have gathered that display
> > controllers handle bridges explicitly, right?
>
> That's correct, yes. Or, rather, they handle the first bridge in the chain,
> and then other bridges are handled recursively.
>
> > If so, by extending the bridge (with either a new function or new data) you
> > impose changes to all display controllers wanting to handle this new bridge
> > input-format. If so, I assume I can leave out the changes to all display
> > controllers that I do not care about. Correct?
>
> That's correct.
>
> > Also, don't hold your breath waiting for a v2, but I'll try to get to it :-)
>
> I won't hold my breath, but Jacopo might :-) He has a similar issue to solve
> (reporting the LVDS modes supported by the bridge).
>

I was not :) I jumped late on this, as I restarted the DRM bridge work
yesterday. Peter, can I summarize you my current use case? (which is
quite similar to yours actually)

At the R-Car DU (Display Unit) output, we have an LVDS encoder
connected to a 'transparent' LVDS bridge that converts the input LVDS
stream into digital RGB output to be then HDMI encoded by another
component.

The 'transparent LVDS decoder', for which I'm now writing a driver,
should report what pixel bus format it accepts as input as the DU LVDS
encoder can output an LVDS stream with several different component ordering
schemes. I was about to come up with a proposal last week but you beat
me at time, so I'm happy to base my work on what comes out from this
series.

 Laurent: On the THC63LVD driver
Laurent: at the same time I would not block the THC63LVD1024 driver. I
can extend bindings to include the "mode map" configuration property,
and squash my Eagle DTS patch on top of Niklas' one. Then make the newly
introduced driver use whatever API comes out from this series with an
incremental patch. Does this work for you? It is true, though, that
we're anyway late for v4.17 and I could send one single series based
on some future version of this and that includes all (bridge driver
and bindings, DU LVDS changes and Eagle DTS), but I feel it's easier
if we got the bridge driver accepted first, and then develop on top of
that.

Thanks
   j

> > >> -  

Re: [PATCH 02/10] drm/sun4i: Disable YUV channel when using the frontend and set interlace

[Maxime Ripard]

On Tue, Mar 27, 2018 at 10:00:43AM +0200, Paul Kocialkowski wrote:
> Hi,
> 
> On Fri, 2018-03-23 at 10:55 +0100, Maxime Ripard wrote:
> > On Wed, Mar 21, 2018 at 04:28:56PM +0100, Paul Kocialkowski wrote:
> > > The YUV channel was only disabled in
> > > sun4i_backend_update_layer_formats,
> > > which is not called when the frontend is selected.
> > > 
> > > Thus, creating a layer with a YUV format handled by the backend and
> > > then
> > > switching to a format that requires the frontend would keep the YUV
> > > channel enabled for the layer.
> > > 
> > > This explicitly disables the YUV channel for the layer when using
> > > the
> > > frontend as well. It also sets the relevant interlace bit, which was
> > > missing in the frontend path as well.
> > 
> > This should be part of a separate patch. Usually, if you write "it
> > also does..." at the end of your commit log, it's a pretty good
> > indication that it should be another patch :)
> 
> I must say, I figured that this part was missing in the frontend path by
> chance and couldn't really test the feature, so I'm also tempted to drop
> it altogether. What do you think?

If you haven't been able to test it, then yeah, don't submit it.

> Also, is interlacing actually used on any of the video outputs we
> support? Perhaps RGB?

Composite would be a better guess :)

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [PATCH] drm/scheduler: fix param documentation

[Daniel Vetter]

On Mon, Mar 26, 2018 at 08:51:14PM +0530, Nayan Deshmukh wrote:
> Signed-off-by: Nayan Deshmukh 

You might want to add a kerneldoc page in Documentation/gpu/scheduler.rst,
which pulls in all the nice kerneldoc you have here + has a short intro
text what this is all about.

Cheers, Daniel

> ---
>  drivers/gpu/drm/scheduler/gpu_scheduler.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
> b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> index 0d95888ccc3e..1d368bc66ac2 100644
> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> @@ -117,8 +117,9 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
>   * @schedThe pointer to the scheduler
>   * @entity   The pointer to a valid drm_sched_entity
>   * @rq   The run queue this entity belongs
> - * @kernel   If this is an entity for the kernel
>   * @jobs The max number of jobs in the job queue
> + * @guilty  atomic_t set to 1 when a job on this queue
> + *  is found to be guilty causing a timeout
>   *
>   * return 0 if succeed. negative error code on failure
>  */
> -- 
> 2.14.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH 1/6] drm/tinydrm: Use gem_free_object_unlocked

[Daniel Vetter]

On Thu, Mar 22, 2018 at 02:46:45PM +0100, Noralf Trønnes wrote:
> 
> Den 22.03.2018 11.51, skrev Daniel Vetter:
> > tinydrm doesn't use dev->struct_mutex and therefore has no need to use
> > gem_free_object.
> > 
> > Signed-off-by: Daniel Vetter 
> > Cc: "Noralf Trønnes" 
> > ---
> 
> Acked-by: Noralf Trønnes 

Thanks for your ack, applied. Somehow something is wrong with my mailer
and ate the other 5 patches. Even in the resend. I'll try again.
-Daniel

> 
> >   drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 2 +-
> >   include/drm/tinydrm/tinydrm.h   | 2 +-
> >   2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c 
> > b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> > index 4c6616278c48..24a33bf862fa 100644
> > --- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> > +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> > @@ -91,7 +91,7 @@ EXPORT_SYMBOL(tinydrm_gem_cma_prime_import_sg_table);
> >* GEM object state and frees the memory used to store the object itself 
> > using
> >* drm_gem_cma_free_object(). It also handles PRIME buffers which has the 
> > kernel
> >* virtual address set by tinydrm_gem_cma_prime_import_sg_table(). Drivers
> > - * can use this as their &drm_driver->gem_free_object callback.
> > + * can use this as their &drm_driver->gem_free_object_unlocked callback.
> >*/
> >   void tinydrm_gem_cma_free_object(struct drm_gem_object *gem_obj)
> >   {
> > diff --git a/include/drm/tinydrm/tinydrm.h b/include/drm/tinydrm/tinydrm.h
> > index 07a9a11fe19d..77a93ec577fd 100644
> > --- a/include/drm/tinydrm/tinydrm.h
> > +++ b/include/drm/tinydrm/tinydrm.h
> > @@ -41,7 +41,7 @@ pipe_to_tinydrm(struct drm_simple_display_pipe *pipe)
> >* the &drm_driver structure.
> >*/
> >   #define TINYDRM_GEM_DRIVER_OPS \
> > -   .gem_free_object= tinydrm_gem_cma_free_object, \
> > +   .gem_free_object_unlocked = tinydrm_gem_cma_free_object, \
> > .gem_print_info = drm_gem_cma_print_info, \
> > .gem_vm_ops = &drm_gem_cma_vm_ops, \
> > .prime_handle_to_fd = drm_gem_prime_handle_to_fd, \
> 

-- 
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 00/23] drm: Eliminate plane->fb/crtc usage for atomic drivers

[Daniel Vetter]

On Thu, Mar 22, 2018 at 05:22:50PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> I really just wanted to fix i915 to re-enable its planes afer load
> detection (a two line patch). This is what I actually ended up with
> after I ran into a framebuffer refcount leak with said two line patch.
> 
> I've tested this on a few i915 boxes and so far it's looking
> good. Everything else is just compile tested.
> 
> Entire series available here:
> git://github.com/vsyrjala/linux.git plane_fb_crtc_nuke
> 
> Cc: Alex Deucher 
> Cc: amd-...@lists.freedesktop.org
> Cc: Benjamin Gaignard 
> Cc: Boris Brezillon 
> Cc: ch...@chris-wilson.co.uk
> Cc: "Christian König" 
> Cc: Daniel Vetter 
> Cc: Dave Airlie 
> Cc: David Airlie 
> Cc: "David (ChunMing) Zhou" 
> Cc: Eric Anholt 
> Cc: freedr...@lists.freedesktop.org
> Cc: Gerd Hoffmann 
> Cc: Harry Wentland 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Kyungmin Park 
> Cc: linux-arm-...@vger.kernel.org
> Cc: Maarten Lankhorst 
> Cc: martin.pe...@free.fr
> Cc: Rob Clark 
> Cc: Seung-Woo Kim 
> Cc: Shawn Guo 
> Cc: Sinclair Yeh 
> Cc: Thomas Hellstrom 
> Cc: Vincent Abriou 
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: VMware Graphics 
> 
> Ville Syrjälä (23):
>   Revert "drm/atomic-helper: Fix leak in disable_all"
>   drm/atomic-helper: Make drm_atomic_helper_disable_all() update the
> plane->fb pointers
>   drm: Clear crtc->primary->crtc when disabling the crtc via setcrtc()
>   drm/atomic-helper: WARN if legacy plane fb pointers are bogus when
> committing duplicated state
>   drm: Add local 'plane' variable for primary/cursor planes
>   drm: Adjust whitespace for legibility
>   drm: Make the fb refcount handover less magic
>   drm: Use plane->state->fb over plane->fb
>   drm/i915: Stop consulting plane->fb
>   drm/msm: Stop consulting plane->fb
>   drm/sti: Stop consulting plane->fb
>   drm/vmwgfx: Stop consulting plane->fb
>   drm/zte: Stop consulting plane->fb
>   drm/atmel-hlcdc: Stop using plane->fb
>   drm: Stop updating plane->crtc/fb/old_fb on atomic drivers
>   drm/amdgpu/dc: Stop updating plane->fb
>   drm/i915: Stop updating plane->fb/crtc
>   drm/exynos: Stop updating plane->crtc
>   drm/msm: Stop updating plane->fb/crtc
>   drm/virtio: Stop updating plane->fb
>   drm/vc4: Stop updating plane->fb/crtc
>   drm/i915: Restore planes after load detection
>   drm/i915: Make force_load_detect effective even w/ DMI quirks/hotplug

Ok, I reviewed the core patches, looks all good.

Also starting auditing all the drivers. I think there's some small
oversights in there, and I need to update my grep foo a bit, but by and
large looks all reasonable.

Imo we should start merging, that will also make the auditing easier.
-Daniel

> 
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 -
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c   | 12 +---
>  drivers/gpu/drm/drm_atomic.c  | 55 ++--
>  drivers/gpu/drm/drm_atomic_helper.c   | 79 
> ++-
>  drivers/gpu/drm/drm_crtc.c| 51 ++-
>  drivers/gpu/drm/drm_fb_helper.c   |  7 --
>  drivers/gpu/drm/drm_framebuffer.c |  5 --
>  drivers/gpu/drm/drm_plane.c   | 64 +++---
>  drivers/gpu/drm/drm_plane_helper.c|  4 +-
>  drivers/gpu/drm/exynos/exynos_drm_plane.c |  2 -
>  drivers/gpu/drm/i915/intel_crt.c  |  6 ++
>  drivers/gpu/drm/i915/intel_display.c  |  9 +--
>  drivers/gpu/drm/i915/intel_fbdev.c|  2 +-
>  drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c |  3 +-
>  drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c|  2 -
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c|  2 -
>  drivers/gpu/drm/sti/sti_plane.c   |  9 +--
>  drivers/gpu/drm/vc4/vc4_crtc.c|  3 -
>  drivers/gpu/drm/virtio/virtgpu_display.c  |  2 -
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |  6 +-
>  drivers/gpu/drm/zte/zx_vou.c  |  2 +-
>  include/drm/drm_atomic.h  |  3 -
>  22 files changed, 143 insertions(+), 187 deletions(-)
> 
> -- 
> 2.16.1
> 

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

[PATCH 3/5] drm/udl: Get rid of dev->struct_mutex usage

[Daniel Vetter]

It's only used to protect our page list, and only when we know we have
a full reference. This means none of these code paths can ever race
with the final unref, and hence we do not need dev->struct_mutex
serialization and can simply switch to our own locking.

For more context the only magic the locked gem_free_object provides is
that it prevents concurrent final unref (and destruction) of gem
objects while anyone is holding dev->struct_mutex. This was used by
i915 (and other drivers) to implement eviction handling with less
headaches.

Signed-off-by: Daniel Vetter 
Cc: Dave Airlie 
---
 drivers/gpu/drm/udl/udl_dmabuf.c | 5 +++--
 drivers/gpu/drm/udl/udl_drv.c| 2 +-
 drivers/gpu/drm/udl/udl_drv.h| 2 ++
 drivers/gpu/drm/udl/udl_gem.c| 5 +++--
 drivers/gpu/drm/udl/udl_main.c   | 2 ++
 5 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_dmabuf.c b/drivers/gpu/drm/udl/udl_dmabuf.c
index 2867ed155ff6..0a20695eb120 100644
--- a/drivers/gpu/drm/udl/udl_dmabuf.c
+++ b/drivers/gpu/drm/udl/udl_dmabuf.c
@@ -76,6 +76,7 @@ static struct sg_table *udl_map_dma_buf(struct 
dma_buf_attachment *attach,
struct udl_drm_dmabuf_attachment *udl_attach = attach->priv;
struct udl_gem_object *obj = to_udl_bo(attach->dmabuf->priv);
struct drm_device *dev = obj->base.dev;
+   struct udl_device *udl = dev->dev_private;
struct scatterlist *rd, *wr;
struct sg_table *sgt = NULL;
unsigned int i;
@@ -112,7 +113,7 @@ static struct sg_table *udl_map_dma_buf(struct 
dma_buf_attachment *attach,
return ERR_PTR(-ENOMEM);
}
 
-   mutex_lock(&dev->struct_mutex);
+   mutex_lock(&udl->gem_lock);
 
rd = obj->sg->sgl;
wr = sgt->sgl;
@@ -137,7 +138,7 @@ static struct sg_table *udl_map_dma_buf(struct 
dma_buf_attachment *attach,
attach->priv = udl_attach;
 
 err_unlock:
-   mutex_unlock(&dev->struct_mutex);
+   mutex_unlock(&udl->gem_lock);
return sgt;
 }
 
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 3c45a3064726..9ef515df724b 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -53,7 +53,7 @@ static struct drm_driver driver = {
.unload = udl_driver_unload,
 
/* gem hooks */
-   .gem_free_object = udl_gem_free_object,
+   .gem_free_object_unlocked = udl_gem_free_object,
.gem_vm_ops = &udl_gem_vm_ops,
 
.dumb_create = udl_dumb_create,
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 2a75ab80527a..55c0cc309198 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -54,6 +54,8 @@ struct udl_device {
struct usb_device *udev;
struct drm_crtc *crtc;
 
+   struct mutex gem_lock;
+
int sku_pixel_limit;
 
struct urb_list urbs;
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index dee6bd9a3dd1..9a15cce22cce 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -214,9 +214,10 @@ int udl_gem_mmap(struct drm_file *file, struct drm_device 
*dev,
 {
struct udl_gem_object *gobj;
struct drm_gem_object *obj;
+   struct udl_device *udl = dev->dev_private;
int ret = 0;
 
-   mutex_lock(&dev->struct_mutex);
+   mutex_lock(&udl->gem_lock);
obj = drm_gem_object_lookup(file, handle);
if (obj == NULL) {
ret = -ENOENT;
@@ -236,6 +237,6 @@ int udl_gem_mmap(struct drm_file *file, struct drm_device 
*dev,
 out:
drm_gem_object_put(&gobj->base);
 unlock:
-   mutex_unlock(&dev->struct_mutex);
+   mutex_unlock(&udl->gem_lock);
return ret;
 }
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index f1ec4528a73e..d518de8f496b 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -324,6 +324,8 @@ int udl_driver_load(struct drm_device *dev, unsigned long 
flags)
udl->ddev = dev;
dev->dev_private = udl;
 
+   mutex_init(&udl->gem_lock);
+
if (!udl_parse_vendor_descriptor(dev, udl->udev)) {
ret = -ENODEV;
DRM_ERROR("firmware not recognized. Assume incompatible 
device\n");
-- 
2.16.2

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

[PATCH 5/5] drm/omapdrm: Switch to gem_free_object_unlocked

[Daniel Vetter]

The only thing that omap_gem_free_object does that might need the
magic protection of struct_mutex (of keeping all objects alive if that
lock is held, even if the last reference is gone) is the mm_list
manipulation.

But that is already protected by the separate omapdrm->list_lock,
which means struct_mutex is an entirely internal lock for omapdrm.
Everything else is just releasing resources, which is all protected
already by the various subsystems and allocators.

To make this even more obvious we could do an
s/dev->struct_mutex/omapdrm->gem_lock/ like I've done for udl. But
since omapdrm is a lot bigger and a lot more active I'll refrain from
that - this is better done by omapdrm developers at some suitable time
in the future.

Signed-off-by: Daniel Vetter 
Cc: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 3f40f7af3285..6d52877ed25a 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -490,7 +490,7 @@ static struct drm_driver omap_drm_driver = {
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = omap_gem_prime_export,
.gem_prime_import = omap_gem_prime_import,
-   .gem_free_object = omap_gem_free_object,
+   .gem_free_object_unlocked = omap_gem_free_object,
.gem_vm_ops = &omap_gem_vm_ops,
.dumb_create = omap_gem_dumb_create,
.dumb_map_offset = omap_gem_dumb_map_offset,
-- 
2.16.2

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

[PATCH 4/5] drm/omapdrm: Fix mm_list locking

[Daniel Vetter]

- None of the list walkings where protected.

- Switch to a mutex since the list walking could potentially take a
  very long time.

Only thing we need to be careful with here is that while we walk the
list we cant unreference any gem objects, since the final unref would
result in a recursive deadlock. But the only functions that walk the
list is the device resume and debugfs dumping, so all safe.

Signed-off-by: Daniel Vetter 
Cc: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_debugfs.c |  2 ++
 drivers/gpu/drm/omapdrm/omap_drv.c |  2 +-
 drivers/gpu/drm/omapdrm/omap_drv.h |  2 +-
 drivers/gpu/drm/omapdrm/omap_gem.c | 11 +++
 4 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_debugfs.c 
b/drivers/gpu/drm/omapdrm/omap_debugfs.c
index b42e286616b0..84da7a5b84f3 100644
--- a/drivers/gpu/drm/omapdrm/omap_debugfs.c
+++ b/drivers/gpu/drm/omapdrm/omap_debugfs.c
@@ -37,7 +37,9 @@ static int gem_show(struct seq_file *m, void *arg)
return ret;
 
seq_printf(m, "All Objects:\n");
+   mutex_lock(&priv->list_lock);
omap_gem_describe_objects(&priv->obj_list, m);
+   mutex_unlock(&priv->list_lock);
 
mutex_unlock(&dev->struct_mutex);
 
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 3632854c2b91..3f40f7af3285 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -537,7 +537,7 @@ static int omapdrm_init(struct omap_drm_private *priv, 
struct device *dev)
priv->omaprev = soc ? (unsigned int)soc->data : 0;
priv->wq = alloc_ordered_workqueue("omapdrm", 0);
 
-   spin_lock_init(&priv->list_lock);
+   mutex_init(&priv->list_lock);
INIT_LIST_HEAD(&priv->obj_list);
 
/* Allocate and initialize the DRM device. */
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 6eaee4df4559..f27c8e216adf 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -71,7 +71,7 @@ struct omap_drm_private {
struct workqueue_struct *wq;
 
/* lock for obj_list below */
-   spinlock_t list_lock;
+   struct mutex list_lock;
 
/* list of GEM objects: */
struct list_head obj_list;
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 0faf042b82e1..183447572e90 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1001,6 +1001,7 @@ int omap_gem_resume(struct drm_device *dev)
struct omap_gem_object *omap_obj;
int ret = 0;
 
+   mutex_lock(&priv->list_lock);
list_for_each_entry(omap_obj, &priv->obj_list, mm_list) {
if (omap_obj->block) {
struct drm_gem_object *obj = &omap_obj->base;
@@ -1012,10 +1013,12 @@ int omap_gem_resume(struct drm_device *dev)
omap_obj->roll, true);
if (ret) {
dev_err(dev->dev, "could not repin: %d\n", ret);
+   mutex_unlock(&priv->list_lock);
return ret;
}
}
}
+   mutex_unlock(&priv->list_lock);
 
return 0;
 }
@@ -1085,9 +1088,9 @@ void omap_gem_free_object(struct drm_gem_object *obj)
 
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
 
-   spin_lock(&priv->list_lock);
+   mutex_lock(&priv->list_lock);
list_del(&omap_obj->mm_list);
-   spin_unlock(&priv->list_lock);
+   mutex_unlock(&priv->list_lock);
 
/* this means the object is still pinned.. which really should
 * not happen.  I think..
@@ -1206,9 +1209,9 @@ struct drm_gem_object *omap_gem_new(struct drm_device 
*dev,
goto err_release;
}
 
-   spin_lock(&priv->list_lock);
+   mutex_lock(&priv->list_lock);
list_add(&omap_obj->mm_list, &priv->obj_list);
-   spin_unlock(&priv->list_lock);
+   mutex_unlock(&priv->list_lock);
 
return obj;
 
-- 
2.16.2

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

[PATCH 2/5] drm/rockchip: fixup comment for gem_free_object_unlocked

[Daniel Vetter]

Just want to clean out all grep hits. gem_free_object is deprecated.

Signed-off-by: Daniel Vetter 
Cc: Sandy Huang 
Cc: "Heiko Stübner" 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 074db7a92809..a8db758d523e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -357,8 +357,8 @@ rockchip_gem_create_object(struct drm_device *drm, unsigned 
int size,
 }
 
 /*
- * rockchip_gem_free_object - (struct drm_driver)->gem_free_object callback
- * function
+ * rockchip_gem_free_object - (struct drm_driver)->gem_free_object_unlocked
+ * callback function
  */
 void rockchip_gem_free_object(struct drm_gem_object *obj)
 {
-- 
2.16.2

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

[PATCH 1/5] staging/vboxvideo: Use gem_free_object_unlocked

[Daniel Vetter]

vboxvideo doesn't use dev->struct_mutex and therefore has no need to use
gem_free_object.

Signed-off-by: Daniel Vetter 
Cc: Greg Kroah-Hartman 
Cc: Hans de Goede 
Cc: Michael Thayer 
Cc: Colin Ian King 
Cc: Daniel Vetter 
Cc: Stephen Rothwell 
---
 drivers/staging/vboxvideo/vbox_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vboxvideo/vbox_drv.c 
b/drivers/staging/vboxvideo/vbox_drv.c
index e18642e5027e..f6d26beffa54 100644
--- a/drivers/staging/vboxvideo/vbox_drv.c
+++ b/drivers/staging/vboxvideo/vbox_drv.c
@@ -242,7 +242,7 @@ static struct drm_driver driver = {
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
 
-   .gem_free_object = vbox_gem_free_object,
+   .gem_free_object_unlocked = vbox_gem_free_object,
.dumb_create = vbox_dumb_create,
.dumb_map_offset = vbox_dumb_mmap_offset,
.dumb_destroy = drm_gem_dumb_destroy,
-- 
2.16.2

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

Re: [PATCH 05/10] drm/sun4i: Explicitly list and check formats supported by the frontend

[Paul Kocialkowski]

Hi,

On Fri, 2018-03-23 at 11:06 +0100, Maxime Ripard wrote:
> On Wed, Mar 21, 2018 at 04:28:59PM +0100, Paul Kocialkowski wrote:
> > In order to check whether the frontend supports a specific format,
> > an
> > explicit list and a related helper are introduced.
> > 
> > They are then used to determine whether the frontend can actually
> > support
> > the requested format when it was selected to be used.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/gpu/drm/sun4i/sun4i_backend.c  |  5 
> >  drivers/gpu/drm/sun4i/sun4i_frontend.c | 44
> > ++
> >  drivers/gpu/drm/sun4i/sun4i_frontend.h |  1 +
> >  3 files changed, 50 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> > b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > index 7703ba989743..1fad0714c70e 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > @@ -532,6 +532,11 @@ static int sun4i_backend_atomic_check(struct
> > sunxi_engine *engine,
> > struct drm_format_name_buf format_name;
> >  
> > if (sun4i_backend_plane_uses_frontend(plane_state))
> > {
> > +   if (!sun4i_frontend_format_is_supported(fb-
> > >format->format)) {
> > +   DRM_DEBUG_DRIVER("Frontend plane
> > check failed\n");
> > +   return -EINVAL;
> > +   }
> > +
> 
> So you're checking if the frontend doesn't support it and if the
> backend doesn't support it. Who supports it then? :)

That's the case case where the format is not supported by either of the
hardware blocks. For instance, requesting ARGB with tiling will fail,
although ARGB without tiling will work. It seems that modetest assumes
that modifiers only apply to YUV (in which case there are no unsupported
cases), but I think userspace might still request RGB+tiling
combinations. I don't currently see a way to report to which format the
tiling applies (thus we have to expect that it can come with any of the
supported formats).

> Like I was saying, this should be moved to the previous patch, within
> sun4i_backend_plane_uses_frontend.

If we get both tests (no backend support and frontend support) into one
function, we cannot detect that the format is actually unsupported and
return an error in the atomic check.

> > +static const uint32_t sun4i_frontend_formats[] = {
> > +   /* RGB */
> > +   DRM_FORMAT_XRGB,
> > +   DRM_FORMAT_BGRX,
> > +   /* YUV444 */
> > +   DRM_FORMAT_YUV444,
> > +   DRM_FORMAT_YVU444,
> > +   /* YUV422 */
> > +   DRM_FORMAT_YUYV,
> > +   DRM_FORMAT_YVYU,
> > +   DRM_FORMAT_UYVY,
> > +   DRM_FORMAT_VYUY,
> > +   DRM_FORMAT_NV16,
> > +   DRM_FORMAT_NV61,
> > +   DRM_FORMAT_YUV422,
> > +   DRM_FORMAT_YVU422,
> > +   /* YUV420 */
> > +   DRM_FORMAT_NV12,
> > +   DRM_FORMAT_NV21,
> > +   DRM_FORMAT_YUV420,
> > +   DRM_FORMAT_YVU420,
> > +   /* YUV411 */
> > +   DRM_FORMAT_YUV411,
> > +   DRM_FORMAT_YVU411,
> > +};
> 
> I think this list should reflect what the driver currently supports,
> not what the hardware supports.

This list is not indended to reflect what the driver supports, but only
what the backend can support (to correctly select whether a
format/modifier couple should go to the frontend or backend)!

The complete list that is reported to userspace for global driver
support is sun4i_layer_formats in sun4i_layer.c.

Cheers,

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

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: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

[Daniel Vetter]

On Tue, Mar 27, 2018 at 10:06:04AM +0200, Christian König wrote:
> Am 27.03.2018 um 09:53 schrieb Daniel Vetter:
> > [SNIP]
> > > > [SNIP]
> > > > A slightly better solution is using atomic counter:
> > > > driver_range_start() {
> > > >   atomic_inc(&mydev->notifier_count);
> > > ...
> > > 
> > > Yeah, that is exactly what amdgpu is doing now. Sorry if my description
> > > didn't made that clear.
> > > 
> > > > I would like to see driver using same code, as it means one place to fix
> > > > issues. I had for a long time on my TODO list doing the above conversion
> > > > to amd or radeon kernel driver. I am pushing up my todo list hopefully 
> > > > in
> > > > next few weeks i can send an rfc so people can have a real sense of how
> > > > it can look.
> > > Certainly a good idea, but I think we might have that separate to HMM.
> > > 
> > > TTM suffered really from feature overload, e.g. trying to do everything 
> > > in a
> > > single subsystem. And it would be rather nice to have coherent userptr
> > > handling for GPUs as separate feature.
> > TTM suffered from being a midlayer imo, not from doing too much.
> 
> Yeah, completely agree.
> 
> midlayers work as long as you concentrate on doing exactly one things in
> your midlayer. E.g. in the case of TTM the callback for BO move handling is
> well justified.
> 
> Only all the stuff around it like address space handling etc... is really
> wrong designed and should be separated (which is exactly what DRM MM did,
> but TTM still uses this in the wrong way).

Yeah the addres space allocator part of ttm really is backwards and makes
adding quick driver hacks and heuristics for better allocations schemes
really hard to add. Same for tuning how/what exactly you evict.

> > HMM is apparently structured like a toolbox (despite its documentation 
> > claiming
> > otherwise), so you can pick&choose freely.
> 
> That sounds good, but I would still have a better feeling if userptr
> handling would be separated. That avoids mangling things together again.

Jerome said he wants to do at least one prototype conversion of one of the
"I can't fault" userptr implementation over to the suitable subset of HMM
helpers. I guess we'll see once he's submitting the patches, but it
sounded exactly like what the doctor ordered :-)
-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 v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Sergei Shtylyov]

Hello!

On 3/27/2018 10:33 AM, jacopo mondi wrote:
[...]

Document Thine THC63LVD1024 LVDS decoder device tree bindings.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Niklas Söderlund 
---
  .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
  1 file changed, 66 insertions(+)
  create mode 100644
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt

diff --git
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..8225c6a
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,66 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two two input LVDS stream and up to two digital CMOS/TTL
outputs.
+
+Single or dual operation modes, output data mapping and DDR output modes
are
+configured through input signals and the chip does not expose any control
bus.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024"
+
+Optional properties:
+- vcc-supply: Power supply for TTL output and digital circuitry
+- cvcc-supply: Power supply for TTL CLOCKOUT signal
+- lvcc-supply: Power supply for LVDS inputs
+- pvcc-supply: Power supply for PLL circuitry

As explained in a comment to one of the previous versions of this series, I'm
tempted to make vcc-supply mandatory and drop the three other power supplies
for now, as I believe there's very little chance they will be connected to
separately controllable regulators (all supplies use the same voltage). In the
very unlikely event that this occurs in design we need to support in the
future, the cvcc, lvcc and pvcc supplies can be added later as optional
without breaking backward compatibility.

I'm okay with that.


Apart from that,

Reviewed-by: Laurent Pinchart 


+- pdwn-gpios: Power down GPIO signal. Active low

powerdown-gpios is the semi-standard name.


right, I've also noticed it. If possible please avoid shortenings in
property names.


It is not shortening, it just follow pin name from decoder's datasheet.




+- oe-gpios: Output enable GPIO signal. Active high
+

And this one is also a not ever met property name, please consider to
rename it to 'enable-gpios', for instance display panels define it.



Again, it follows datasheet naming scheme. Has something changed in DT
conventions?


Seconded. My understanding is that the property name should reflect
what reported in the the chip manual. For THC63LVD1024 the enable and
power down pins are named 'OE' and 'PDWN' respectively.


   But don't we need the vendor prefix in the prop names then, like 
"renesas,oe-gpios" then?



Thanks
j


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

Re: [PATCH 06/10] drm/sun4i: Move and extend format-related helpers and tables

[Paul Kocialkowski]

Hi,

On Fri, 2018-03-23 at 11:13 +0100, Maxime Ripard wrote:
> On Wed, Mar 21, 2018 at 04:29:00PM +0100, Paul Kocialkowski wrote:
> > This moves the various helpers and tables related to format
> > detection
> > and conversion to a dedicated file, while adding a bunch of new
> > helpers
> > (especially for YUV and tiling support) along the way.
> 
> The addition of new helpers should be in a separate patch.

Fair enough.

> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/gpu/drm/sun4i/Makefile|   1 +
> >  drivers/gpu/drm/sun4i/sun4i_backend.c |  54 ++
> >  drivers/gpu/drm/sun4i/sun4i_format.c  | 193
> > ++
> >  drivers/gpu/drm/sun4i/sun4i_format.h  |  35 ++
> >  4 files changed, 235 insertions(+), 48 deletions(-)
> >  create mode 100644 drivers/gpu/drm/sun4i/sun4i_format.c
> >  create mode 100644 drivers/gpu/drm/sun4i/sun4i_format.h
> > 
> > diff --git a/drivers/gpu/drm/sun4i/Makefile
> > b/drivers/gpu/drm/sun4i/Makefile
> > index 582607c0c488..c89c42ff803e 100644
> > --- a/drivers/gpu/drm/sun4i/Makefile
> > +++ b/drivers/gpu/drm/sun4i/Makefile
> > @@ -4,6 +4,7 @@ sun4i-frontend-y+= sun4i_frontend.o
> >  
> >  sun4i-drm-y+= sun4i_drv.o
> >  sun4i-drm-y+= sun4i_framebuffer.o
> > +sun4i-drm-y+= sun4i_format.o
> >  
> >  sun4i-drm-hdmi-y   += sun4i_hdmi_ddc_clk.o
> >  sun4i-drm-hdmi-y   += sun4i_hdmi_enc.o
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> > b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > index 1fad0714c70e..e8af9f3cf20b 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > @@ -29,6 +29,7 @@
> >  #include "sun4i_drv.h"
> >  #include "sun4i_frontend.h"
> >  #include "sun4i_layer.h"
> > +#include "sun4i_format.h"
> >  #include "sunxi_engine.h"
> >  
> >  struct sun4i_backend_quirks {
> > @@ -36,50 +37,6 @@ struct sun4i_backend_quirks {
> > bool needs_output_muxing;
> >  };
> >  
> > -static const u32 sunxi_rgb2yuv_coef[12] = {
> > -   0x0107, 0x0204, 0x0064, 0x0108,
> > -   0x3f69, 0x3ed6, 0x01c1, 0x0808,
> > -   0x01c1, 0x3e88, 0x3fb8, 0x0808
> > -};
> > -
> > -static const u32 sunxi_bt601_yuv2rgb_coef[12] = {
> > -   0x04a7, 0x1e6f, 0x1cbf, 0x0877,
> > -   0x04a7, 0x, 0x0662, 0x3211,
> > -   0x04a7, 0x0812, 0x, 0x2eb1,
> > -};
> > -
> > -static inline bool sun4i_backend_format_is_planar_yuv(uint32_t
> > format)
> > -{
> > -   switch (format) {
> > -   case DRM_FORMAT_YUV411:
> > -   case DRM_FORMAT_YUV422:
> > -   case DRM_FORMAT_YUV444:
> > -   return true;
> > -   default:
> > -   return false;
> > -   }
> > -}
> > -
> > -static inline bool sun4i_backend_format_is_packed_yuv422(uint32_t
> > format)
> > -{
> > -   switch (format) {
> > -   case DRM_FORMAT_YUYV:
> > -   case DRM_FORMAT_YVYU:
> > -   case DRM_FORMAT_UYVY:
> > -   case DRM_FORMAT_VYUY:
> > -   return true;
> > -
> > -   default:
> > -   return false;
> > -   }
> > -}
> > -
> > -static inline bool sun4i_backend_format_is_yuv(uint32_t format)
> > -{
> > -   return sun4i_backend_format_is_planar_yuv(format) ||
> > -   sun4i_backend_format_is_packed_yuv422(format);
> > -}
> > -
> >  static void sun4i_backend_apply_color_correction(struct
> > sunxi_engine *engine)
> >  {
> > int i;
> > @@ -259,7 +216,7 @@ static int
> > sun4i_backend_update_yuv_format(struct sun4i_backend *backend,
> >SUN4I_BACKEND_ATTCTL_REG0_LAY_YUVEN,
> >SUN4I_BACKEND_ATTCTL_REG0_LAY_YUVEN);
> >  
> > -   if (sun4i_backend_format_is_packed_yuv422(format))
> > +   if (sun4i_format_is_packed_yuv422(format))
> > val |= SUN4I_BACKEND_IYUVCTL_FBFMT_PACKED_YUV422;
> > else
> > DRM_DEBUG_DRIVER("Unknown YUV format\n");
> > @@ -310,7 +267,7 @@ int sun4i_backend_update_layer_formats(struct
> > sun4i_backend *backend,
> > DRM_DEBUG_DRIVER("Switching display backend interlaced mode
> > %s\n",
> >  interlaced ? "on" : "off");
> >  
> > -   if (sun4i_backend_format_is_yuv(fb->format->format))
> > +   if (sun4i_format_is_yuv(fb->format->format))
> > return sun4i_backend_update_yuv_format(backend,
> > layer, plane);
> >  
> > ret = sun4i_backend_drm_format_to_layer(fb->format->format, 
> > &val);
> > @@ -404,7 +361,7 @@ int sun4i_backend_update_layer_buffer(struct
> > sun4i_backend *backend,
> >  */
> > paddr -= PHYS_OFFSET;
> >  
> > -   if (sun4i_backend_format_is_yuv(fb->format->format))
> > +   if (sun4i_format_is_yuv(fb->format->format))
> > return sun4i_backend_update_yuv_buffer(backend, fb,
> > paddr);
> >  
> > /* Write the 32 lower bits of the address (in bits) */
> > @@ -549,10 +506,11 @@ static int sun4i_backend_atomic_check(struct
> > sunxi_engine *engine,
> >

Re: [PATCH 8/8] drm/arm/malidp: Added the late system pm functions

[Daniel Vetter]

On Mon, Mar 26, 2018 at 06:03:20PM +0100, Ayan Kumar Halder wrote:
> malidp_pm_suspend_late checks if the runtime status is not suspended
> and if so, invokes malidp_runtime_pm_suspend which disables the
> display engine/core interrupts and the clocks. It sets the runtime status
> as suspended. Subsequently, malidp_pm_resume_early will invoke
> malidp_runtime_pm_resume which enables the clocks and the interrupts
> (previously disabled) and sets the runtime status as active.
> 
> Signed-off-by: Ayan Kumar Halder 
> Change-Id: I5f8c3d28f076314a1c9da2a46760a9c37039ccda

Why exactly do you need late/early hooks? If you have dependencies with
other devices, pls consider adding device_links instead. This here
shouldn't be necessary.
-Daniel
> ---
>  drivers/gpu/drm/arm/malidp_drv.c | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index bd44a6d..f6124d8 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -766,8 +766,25 @@ static int __maybe_unused malidp_pm_resume(struct device 
> *dev)
>   return 0;
>  }
>  
> +static int __maybe_unused malidp_pm_suspend_late(struct device *dev)
> +{
> + if (!pm_runtime_status_suspended(dev)) {
> + malidp_runtime_pm_suspend(dev);
> + pm_runtime_set_suspended(dev);
> + }
> + return 0;
> +}
> +
> +static int __maybe_unused malidp_pm_resume_early(struct device *dev)
> +{
> + malidp_runtime_pm_resume(dev);
> + pm_runtime_set_active(dev);
> + return 0;
> +}
> +
>  static const struct dev_pm_ops malidp_pm_ops = {
>   SET_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend, malidp_pm_resume) \
> + SET_LATE_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend_late, 
> malidp_pm_resume_early) \
>   SET_RUNTIME_PM_OPS(malidp_runtime_pm_suspend, malidp_runtime_pm_resume, 
> NULL)
>  };
>  
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Vladimir Zapolskiy]

Hi Sergei,

On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> Hello!
> 
> On 3/27/2018 10:33 AM, jacopo mondi wrote:
> [...]
>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>>>
>>> Signed-off-by: Jacopo Mondi 
>>> Reviewed-by: Andrzej Hajda 
>>> Reviewed-by: Niklas Söderlund 
>>> ---
>>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
>>> +++
>>>   1 file changed, 66 insertions(+)
>>>   create mode 100644
>>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> new file mode 100644
>>> index 000..8225c6a
>>> --- /dev/null
>>> +++
>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> @@ -0,0 +1,66 @@
>>> +Thine Electronics THC63LVD1024 LVDS decoder
>>> +---
>>> +
>>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
>>> streams
>>> +to parallel data outputs. The chip supports single/dual input/output 
>>> modes,
>>> +handling up to two two input LVDS stream and up to two digital CMOS/TTL
>>> outputs.
>>> +
>>> +Single or dual operation modes, output data mapping and DDR output 
>>> modes
>>> are
>>> +configured through input signals and the chip does not expose any 
>>> control
>>> bus.
>>> +
>>> +Required properties:
>>> +- compatible: Shall be "thine,thc63lvd1024"
>>> +
>>> +Optional properties:
>>> +- vcc-supply: Power supply for TTL output and digital circuitry
>>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>>> +- lvcc-supply: Power supply for LVDS inputs
>>> +- pvcc-supply: Power supply for PLL circuitry
>> As explained in a comment to one of the previous versions of this 
>> series, I'm
>> tempted to make vcc-supply mandatory and drop the three other power 
>> supplies
>> for now, as I believe there's very little chance they will be connected 
>> to
>> separately controllable regulators (all supplies use the same voltage). 
>> In the
>> very unlikely event that this occurs in design we need to support in the
>> future, the cvcc, lvcc and pvcc supplies can be added later as optional
>> without breaking backward compatibility.
> I'm okay with that.
>
>> Apart from that,
>>
>> Reviewed-by: Laurent Pinchart 
>>
>>> +- pdwn-gpios: Power down GPIO signal. Active low
> powerdown-gpios is the semi-standard name.
>
 right, I've also noticed it. If possible please avoid shortenings in
 property names.
>>>
>>> It is not shortening, it just follow pin name from decoder's datasheet.
>>>

>>> +- oe-gpios: Output enable GPIO signal. Active high
>>> +
 And this one is also a not ever met property name, please consider to
 rename it to 'enable-gpios', for instance display panels define it.
>>>
>>>
>>> Again, it follows datasheet naming scheme. Has something changed in DT
>>> conventions?
>>
>> Seconded. My understanding is that the property name should reflect
>> what reported in the the chip manual. For THC63LVD1024 the enable and
>> power down pins are named 'OE' and 'PDWN' respectively.
> 
> But don't we need the vendor prefix in the prop names then, like 
> "renesas,oe-gpios" then?
> 

Seconded, with a correction to "thine,oe-gpios".

If vendor agnostic properties are supposed to be used, then please follow
the referenced by Rob semi-standard notations.

--
With best wishes,
Vladimir
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH][next] drm/amd/pp: Fix spelling mistake: "suppported" -> "supported"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in pr_warn warning message text

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c
index 0f2851b5b368..308bff2b5d1d 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c
@@ -46,7 +46,7 @@ int psm_init_power_state_table(struct pp_hwmgr *hwmgr)
  sizeof(struct pp_power_state);
 
if (table_entries == 0 || size == 0) {
-   pr_warn("Please check whether power state management is 
suppported on this asic\n");
+   pr_warn("Please check whether power state management is 
supported on this asic\n");
return 0;
}
 
-- 
2.15.1

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

Re: [PATCH 1/5] staging/vboxvideo: Use gem_free_object_unlocked

[Greg Kroah-Hartman]

On Tue, Mar 27, 2018 at 10:23:52AM +0200, Daniel Vetter wrote:
> vboxvideo doesn't use dev->struct_mutex and therefore has no need to use
> gem_free_object.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Greg Kroah-Hartman 
> Cc: Hans de Goede 
> Cc: Michael Thayer 
> Cc: Colin Ian King 
> Cc: Daniel Vetter 
> Cc: Stephen Rothwell 
> ---
>  drivers/staging/vboxvideo/vbox_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)


Reviewed-by: Greg Kroah-Hartman 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Andrzej Hajda]

On 27.03.2018 09:36, Geert Uytterhoeven wrote:
> Hi Andrzej,
>
> On Tue, Mar 27, 2018 at 9:28 AM, Andrzej Hajda  wrote:
 --- /dev/null
 +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
 +static void thc63_enable(struct drm_bridge *bridge)
 +{
 +struct thc63_dev *thc63 = to_thc63(bridge);
 +struct regulator *vcc;
 +int i;
>>> unsigned int i;
>> Why? You are introducing silly bug this way, see few lines below.
>>
 +
 +for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
 +vcc = thc63->vccs[i];
 +if (!vcc)
 +continue;
 +
 +if (regulator_enable(vcc))
 +goto error_vcc_enable;
 +}
 +
 +if (thc63->pdwn)
 +gpiod_set_value(thc63->pdwn, 0);
 +
 +if (thc63->oe)
 +gpiod_set_value(thc63->oe, 1);
 +
 +return;
 +
 +error_vcc_enable:
 +dev_err(thc63->dev, "Failed to enable regulator %s\n",
 +thc63_reg_names[i]);
 +
 +for (i = i - 1; i >= 0; i--) {
>> Here, the loop will not end if you define i unsigned.
> True.
>
>> I know one can change the loop, to make it working with unsigned. But
>> this clearly shows that using unsigned is more risky.
>> What are advantages of unsigned vs int in this case. Are there some
>> guidelines/discussions about it?
> Some people consider signed integers harmful, as they may be converted
> silently by the compiler to the "larger" unsigned type when needed.

Wow, it sounds crazy, shall we expect gigantic patchsets, converting all
occurrences of int to "unsigned int" ? :)
I know both types have their pros and cons and can behave unexpectedly
in corner cases, but I do not see why unsigned should be preferred over
signed in general, or in this particular case.
I guess there were somewhere discussion about it, could you point me to
it if possible, to avoid unnecessary noise in this thread.

Regards
Andrzej

>
> Gr{oetje,eeting}s,
>
> Geert
>

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

Re: [PATCH 07/10] drm/sun4i: Add support for YUV formats through the frontend

[Paul Kocialkowski]

Hi,

On Fri, 2018-03-23 at 11:30 +0100, Maxime Ripard wrote:
> On Wed, Mar 21, 2018 at 04:29:01PM +0100, Paul Kocialkowski wrote:
> > The frontend supports many YUV formats as input and also contains a
> > color-space converter (CSC) block that can convert YUV input into
> > RGB output. It also allows scaling between the input and output for
> > every possible combination of supported formats.
> > 
> > This adds support for all the (untiled) YUV video formats supported
> > by
> > the frontend, with associated changes in the backend and layer
> > management.
> > 
> > A specific dumb GEM create function translates a hardware
> > constraint,
> > that the stride must be an even number, when allocating dumb
> > (linear)
> > buffers.
> 
> This should be in a separate, potentially preliminary, patch.

Sure thing.

> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/gpu/drm/sun4i/sun4i_backend.c  |  10 +-
> >  drivers/gpu/drm/sun4i/sun4i_drv.c  |  11 +-
> >  drivers/gpu/drm/sun4i/sun4i_drv.h  |   4 +
> >  drivers/gpu/drm/sun4i/sun4i_frontend.c | 234
> > -
> >  drivers/gpu/drm/sun4i/sun4i_frontend.h |  48 ++-
> >  drivers/gpu/drm/sun4i/sun4i_layer.c|  34 +++--
> >  6 files changed, 293 insertions(+), 48 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> > b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > index e8af9f3cf20b..3de7f3a427c3 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > @@ -500,6 +500,11 @@ static int sun4i_backend_atomic_check(struct
> > sunxi_engine *engine,
> > layer_state->uses_frontend = true;
> > num_frontend_planes++;
> > } else {
> > +   if (sun4i_format_is_yuv(fb->format-
> > >format)) {
> > +   DRM_DEBUG_DRIVER("Plane FB format
> > is YUV\n");
> > +   num_yuv_planes++;
> > +   }
> > +
> > layer_state->uses_frontend = false;
> > }
> >  
> > @@ -510,11 +515,6 @@ static int sun4i_backend_atomic_check(struct
> > sunxi_engine *engine,
> > if (fb->format->has_alpha)
> > num_alpha_planes++;
> >  
> > -   if (sun4i_format_is_yuv(fb->format->format)) {
> > -   DRM_DEBUG_DRIVER("Plane FB format is
> > YUV\n");
> > -   num_yuv_planes++;
> > -   }
> > -
> 
> Why is this needed?

I forgot to comment on this in the commit message. We only need to count
YUV planes when they come directly to the backend, not when they are
piped through the frontend (which outputs RGB, not YUV, to the
frontend).

> > DRM_DEBUG_DRIVER("Plane zpos is %d\n",
> >  plane_state->normalized_zpos);
> >  
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
> > b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > index 3957c2ff6870..d374bb61c565 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > @@ -42,7 +42,7 @@ static struct drm_driver sun4i_drv_driver = {
> > .minor  = 0,
> >  
> > /* GEM Operations */
> > -   .dumb_create= drm_gem_cma_dumb_create,
> > +   .dumb_create= drm_sun4i_gem_dumb_create,
> > .gem_free_object_unlocked = drm_gem_cma_free_object,
> > .gem_vm_ops = &drm_gem_cma_vm_ops,
> >  
> > @@ -60,6 +60,15 @@ static struct drm_driver sun4i_drv_driver = {
> > /* Frame Buffer Operations */
> >  };
> >  
> > +int drm_sun4i_gem_dumb_create(struct drm_file *file_priv,
> > + struct drm_device *drm,
> > + struct drm_mode_create_dumb *args)
> > +{
> > +   args->pitch = ALIGN(DIV_ROUND_UP(args->width * args->bpp,
> > 8), 2);
> > +
> > +   return drm_gem_cma_dumb_create_internal(file_priv, drm,
> > args);
> > +}
> > +
> >  static void sun4i_remove_framebuffers(void)
> >  {
> > struct apertures_struct *ap;
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h
> > b/drivers/gpu/drm/sun4i/sun4i_drv.h
> > index 5750b8ce8b31..47969711a889 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_drv.h
> > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
> > @@ -23,4 +23,8 @@ struct sun4i_drv {
> > struct list_headtcon_list;
> >  };
> >  
> > +int drm_sun4i_gem_dumb_create(struct drm_file *file_priv,
> > + struct drm_device *drm,
> > + struct drm_mode_create_dumb *args);
> > +
> 
> I'm not sure this is needed, you just need to move the function before
> the structure definition.

Well, the sun4i_drv_driver definition is kind of at the start of the
file, so it felt better readability-wise to keep functions below it
instead of having the structure definition in a sandwich of functions.

> >  #endif /* _SUN4I_DRV_H_ */
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c
> > b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> > index 2dc33383be22..d

Re: [PATCH 09/10] drm/sun4i: Add a dedicated ioctl call for allocating tiled buffers

[Paul Kocialkowski]

On Fri, 2018-03-23 at 11:48 +0100, Maxime Ripard wrote:
> Hi,
> 
> On Wed, Mar 21, 2018 at 04:29:03PM +0100, Paul Kocialkowski wrote:
> > This introduces a dedicated ioctl for allocating tiled buffers in
> > the
> > Allwinner MB32 format, that comes with a handful of specific
> > constraints. In particular, the stride of the buffers is expected to
> > be
> > aligned to 32 bytes.
> 
> You should have more details here. What are those constraints, what is
> the expected user? Can you use it only for the scanout, like the dumb
> buffers, or also for the other devices in the system?

Agreed.

> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/gpu/drm/sun4i/sun4i_drv.c | 96
> > +++
> >  drivers/gpu/drm/sun4i/sun4i_drv.h |  2 +
> >  include/uapi/drm/sun4i_drm.h  | 42 +
> >  3 files changed, 140 insertions(+)
> >  create mode 100644 include/uapi/drm/sun4i_drm.h
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
> > b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > index d374bb61c565..e9cb03d34b44 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > @@ -21,11 +21,18 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include "sun4i_drv.h"
> >  #include "sun4i_frontend.h"
> >  #include "sun4i_framebuffer.h"
> >  #include "sun4i_tcon.h"
> > +#include "sun4i_format.h"
> > +
> > +static const struct drm_ioctl_desc sun4i_drv_ioctls[] = {
> > +   DRM_IOCTL_DEF_DRV(SUN4I_GEM_CREATE_TILED,
> > drm_sun4i_gem_create_tiled,
> > + DRM_AUTH | DRM_RENDER_ALLOW),
> 
> Why do you need DRM_RENDER_ALLOW? as far as I know, this is only
> useful for render-nodes.

It's probably undeeded indeed.

> > +};
> >  
> >  DEFINE_DRM_GEM_CMA_FOPS(sun4i_drv_fops);
> >  
> > @@ -34,6 +41,8 @@ static struct drm_driver sun4i_drv_driver = {
> >  
> > /* Generic Operations */
> > .lastclose  = drm_fb_helper_lastclose,
> > +   .ioctls = sun4i_drv_ioctls,
> > +   .num_ioctls = ARRAY_SIZE(sun4i_drv_ioctls),
> > .fops   = &sun4i_drv_fops,
> > .name   = "sun4i-drm",
> > .desc   = "Allwinner sun4i Display
> > Engine",
> > @@ -69,6 +78,93 @@ int drm_sun4i_gem_dumb_create(struct drm_file
> > *file_priv,
> > return drm_gem_cma_dumb_create_internal(file_priv, drm,
> > args);
> >  }
> >  
> > +int drm_sun4i_gem_create_tiled(struct drm_device *drm, void *data,
> > +  struct drm_file *file_priv)
> > +{
> > +   struct drm_sun4i_gem_create_tiled *args = data;
> > +   struct drm_gem_cma_object *cma_obj;
> > +   struct drm_gem_object *gem_obj;
> > +   uint32_t luma_stride, chroma_stride;
> > +   uint32_t luma_height, chroma_height;
> > +   int ret;
> > +
> > +   if (!sun4i_format_supports_tiling(args->format))
> > +   return -EINVAL;
> > +
> > +   memset(args->pitches, 0, sizeof(args->pitches));
> > +   memset(args->offsets, 0, sizeof(args->offsets));
> > +
> > +   /* Stride and height are aligned to 32 bytes for MB32 tiled
> > format. */
> > +   luma_stride = ALIGN(args->width, 32);
> > +   luma_height = ALIGN(args->height, 32);
> > +
> > +   if (sun4i_format_is_semiplanar(args->format)) {
> > +   chroma_stride = luma_stride;
> > +
> > +   if (sun4i_format_is_yuv420(args->format))
> > +   chroma_height = ALIGN(DIV_ROUND_UP(args-
> > >height, 2), 32);
> > +   else if (sun4i_format_is_yuv422(args->format))
> > +   chroma_height = luma_height;
> > +   else
> > +   return -EINVAL;
> > +
> > +   args->pitches[0] = luma_stride;
> > +   args->pitches[1] = chroma_stride;
> > +
> > +   args->offsets[0] = 0;
> > +   args->offsets[1] = luma_stride * luma_height;
> > +
> > +   args->size = luma_stride * luma_height +
> > +chroma_stride * chroma_height;
> > +   } else if (sun4i_format_is_planar(args->format)) {
> > +   if (sun4i_format_is_yuv411(args->format)) {
> > +   chroma_stride = ALIGN(DIV_ROUND_UP(args-
> > >width, 4), 32);
> > +   chroma_height = luma_height;
> > +   } if (sun4i_format_is_yuv420(args->format)) {
> > +   chroma_stride = ALIGN(DIV_ROUND_UP(args-
> > >width, 2), 32);
> > +   chroma_height = ALIGN(DIV_ROUND_UP(args-
> > >height, 2), 32);
> > +   } else if (sun4i_format_is_yuv422(args->format)) {
> > +   chroma_stride = ALIGN(DIV_ROUND_UP(args-
> > >width, 2), 32);
> > +   chroma_height = luma_height;
> > +   } else {
> > +   return -EINVAL;
> > +   }
> > +
> > +   args->pitches[0] = luma_stride;
> > +   args->pitches[1] = chroma_stride;
> > +   args->pitches[2] = chroma_stride;
> > +
> > +   args->offsets[0] = 0;
> > +   args->offsets[1] = 

Re: [PATCH 02/10] drm/sun4i: Disable YUV channel when using the frontend and set interlace

[Paul Kocialkowski]

Hi,

On Tue, 2018-03-27 at 10:17 +0200, Maxime Ripard wrote:
> On Tue, Mar 27, 2018 at 10:00:43AM +0200, Paul Kocialkowski wrote:
> > Hi,
> > 
> > On Fri, 2018-03-23 at 10:55 +0100, Maxime Ripard wrote:
> > > On Wed, Mar 21, 2018 at 04:28:56PM +0100, Paul Kocialkowski wrote:
> > > > The YUV channel was only disabled in
> > > > sun4i_backend_update_layer_formats,
> > > > which is not called when the frontend is selected.
> > > > 
> > > > Thus, creating a layer with a YUV format handled by the backend
> > > > and
> > > > then
> > > > switching to a format that requires the frontend would keep the
> > > > YUV
> > > > channel enabled for the layer.
> > > > 
> > > > This explicitly disables the YUV channel for the layer when
> > > > using
> > > > the
> > > > frontend as well. It also sets the relevant interlace bit, which
> > > > was
> > > > missing in the frontend path as well.
> > > 
> > > This should be part of a separate patch. Usually, if you write "it
> > > also does..." at the end of your commit log, it's a pretty good
> > > indication that it should be another patch :)
> > 
> > I must say, I figured that this part was missing in the frontend
> > path by
> > chance and couldn't really test the feature, so I'm also tempted to
> > drop
> > it altogether. What do you think?
> 
> If you haven't been able to test it, then yeah, don't submit it.

Alright, noted.

> > Also, is interlacing actually used on any of the video outputs we
> > support? Perhaps RGB?
>
> Composite would be a better guess :)

Oh and I was wondering what CVBS was about. Now I know!
It seems that we don't support it for now apparently, anyway.

Thanks,

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

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 02/10] drm/sun4i: Disable YUV channel when using the frontend and set interlace

[Chen-Yu Tsai]

On Tue, Mar 27, 2018 at 4:44 PM, Paul Kocialkowski
 wrote:
> Hi,
>
> On Tue, 2018-03-27 at 10:17 +0200, Maxime Ripard wrote:
>> On Tue, Mar 27, 2018 at 10:00:43AM +0200, Paul Kocialkowski wrote:
>> > Hi,
>> >
>> > On Fri, 2018-03-23 at 10:55 +0100, Maxime Ripard wrote:
>> > > On Wed, Mar 21, 2018 at 04:28:56PM +0100, Paul Kocialkowski wrote:
>> > > > The YUV channel was only disabled in
>> > > > sun4i_backend_update_layer_formats,
>> > > > which is not called when the frontend is selected.
>> > > >
>> > > > Thus, creating a layer with a YUV format handled by the backend
>> > > > and
>> > > > then
>> > > > switching to a format that requires the frontend would keep the
>> > > > YUV
>> > > > channel enabled for the layer.
>> > > >
>> > > > This explicitly disables the YUV channel for the layer when
>> > > > using
>> > > > the
>> > > > frontend as well. It also sets the relevant interlace bit, which
>> > > > was
>> > > > missing in the frontend path as well.
>> > >
>> > > This should be part of a separate patch. Usually, if you write "it
>> > > also does..." at the end of your commit log, it's a pretty good
>> > > indication that it should be another patch :)
>> >
>> > I must say, I figured that this part was missing in the frontend
>> > path by
>> > chance and couldn't really test the feature, so I'm also tempted to
>> > drop
>> > it altogether. What do you think?
>>
>> If you haven't been able to test it, then yeah, don't submit it.
>
> Alright, noted.
>
>> > Also, is interlacing actually used on any of the video outputs we
>> > support? Perhaps RGB?
>>
>> Composite would be a better guess :)
>
> Oh and I was wondering what CVBS was about. Now I know!
> It seems that we don't support it for now apparently, anyway.

You could also try adding interlaced modes to HDMI.

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

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Vladimir,

On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
> Hi Sergei,
>
> On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> > Hello!
> >
> > On 3/27/2018 10:33 AM, jacopo mondi wrote:
> > [...]
> >>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >>>
> >>> Signed-off-by: Jacopo Mondi 
> >>> Reviewed-by: Andrzej Hajda 
> >>> Reviewed-by: Niklas Söderlund 
> >>> ---
> >>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
> >>> +++
> >>>   1 file changed, 66 insertions(+)
> >>>   create mode 100644
> >>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> new file mode 100644
> >>> index 000..8225c6a
> >>> --- /dev/null
> >>> +++
> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> @@ -0,0 +1,66 @@
> >>> +Thine Electronics THC63LVD1024 LVDS decoder
> >>> +---
> >>> +
> >>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert 
> >>> LVDS
> >>> streams
> >>> +to parallel data outputs. The chip supports single/dual input/output 
> >>> modes,
> >>> +handling up to two two input LVDS stream and up to two digital 
> >>> CMOS/TTL
> >>> outputs.
> >>> +
> >>> +Single or dual operation modes, output data mapping and DDR output 
> >>> modes
> >>> are
> >>> +configured through input signals and the chip does not expose any 
> >>> control
> >>> bus.
> >>> +
> >>> +Required properties:
> >>> +- compatible: Shall be "thine,thc63lvd1024"
> >>> +
> >>> +Optional properties:
> >>> +- vcc-supply: Power supply for TTL output and digital circuitry
> >>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> >>> +- lvcc-supply: Power supply for LVDS inputs
> >>> +- pvcc-supply: Power supply for PLL circuitry
> >> As explained in a comment to one of the previous versions of this 
> >> series, I'm
> >> tempted to make vcc-supply mandatory and drop the three other power 
> >> supplies
> >> for now, as I believe there's very little chance they will be 
> >> connected to
> >> separately controllable regulators (all supplies use the same 
> >> voltage). In the
> >> very unlikely event that this occurs in design we need to support in 
> >> the
> >> future, the cvcc, lvcc and pvcc supplies can be added later as optional
> >> without breaking backward compatibility.
> > I'm okay with that.
> >
> >> Apart from that,
> >>
> >> Reviewed-by: Laurent Pinchart 
> >>
> >>> +- pdwn-gpios: Power down GPIO signal. Active low
> > powerdown-gpios is the semi-standard name.
> >
>  right, I've also noticed it. If possible please avoid shortenings in
>  property names.
> >>>
> >>> It is not shortening, it just follow pin name from decoder's datasheet.
> >>>
> 
> >>> +- oe-gpios: Output enable GPIO signal. Active high
> >>> +
>  And this one is also a not ever met property name, please consider to
>  rename it to 'enable-gpios', for instance display panels define it.
> >>>
> >>>
> >>> Again, it follows datasheet naming scheme. Has something changed in DT
> >>> conventions?
> >>
> >> Seconded. My understanding is that the property name should reflect
> >> what reported in the the chip manual. For THC63LVD1024 the enable and
> >> power down pins are named 'OE' and 'PDWN' respectively.
> >
> > But don't we need the vendor prefix in the prop names then, like
> > "renesas,oe-gpios" then?
> >
>
> Seconded, with a correction to "thine,oe-gpios".
>

mmm, okay then...

A grep for that semi-standard properties names in Documentation/
returns only usage examples and no actual definitions, so I assume this
is why they are semi-standard. Seems like there is some tribal knowledge
involved in defining what is semi-standard and what's not, or are those
properties documented somewhere?

Thanks
   j


> If vendor agnostic properties are supposed to be used, then please follow
> the referenced by Rob semi-standard notations.
>
> --
> With best wishes,
> Vladimir


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

[Bug 105760] [4.17-drm-wip] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105760

Bug ID: 105760
   Summary: [4.17-drm-wip] RIP:
smu7_populate_single_firmware_entry.isra.6+0x57/0xc0
[amdgpu] RSP: a17901efb930
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: taij...@posteo.de

Created attachment 138374
  --> https://bugs.freedesktop.org/attachment.cgi?id=138374&action=edit
recovered journal of boot attempt

I am trying out the linux-4.17-drm-next kernel line from
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.17-wip and with the
latest build (commit 576e538e5fe6ac103cde6b269c6210985b026689) my systemc no
longer boots to the graphical target and instead hard freezes after loading the
initramfs. A recovered journal is attached.

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

Re: [PATCH][next] drm/amd/pp: Fix spelling mistake: "suppported" -> "supported"

[Zhu, Rex]

Applied and thanks.


Best Regards

Rex


From: Colin King 
Sent: Tuesday, March 27, 2018 4:32 PM
To: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); David Airlie; 
Zhu, Rex; Quan, Evan; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org
Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
Subject: [PATCH][next] drm/amd/pp: Fix spelling mistake: "suppported" -> 
"supported"

From: Colin Ian King 

Trivial fix to spelling mistake in pr_warn warning message text

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c
index 0f2851b5b368..308bff2b5d1d 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c
@@ -46,7 +46,7 @@ int psm_init_power_state_table(struct pp_hwmgr *hwmgr)
   sizeof(struct pp_power_state);

 if (table_entries == 0 || size == 0) {
-   pr_warn("Please check whether power state management is 
suppported on this asic\n");
+   pr_warn("Please check whether power state management is 
supported on this asic\n");
 return 0;
 }

--
2.15.1

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

Re: [PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Geert Uytterhoeven]

Hi Andrezj,

On Tue, Mar 27, 2018 at 10:36 AM, Andrzej Hajda  wrote:
> On 27.03.2018 09:36, Geert Uytterhoeven wrote:
>> On Tue, Mar 27, 2018 at 9:28 AM, Andrzej Hajda  wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> +static void thc63_enable(struct drm_bridge *bridge)
> +{
> +struct thc63_dev *thc63 = to_thc63(bridge);
> +struct regulator *vcc;
> +int i;
 unsigned int i;
>>> Why? You are introducing silly bug this way, see few lines below.
>>>
> +
> +for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> +vcc = thc63->vccs[i];
> +if (!vcc)
> +continue;
> +
> +if (regulator_enable(vcc))
> +goto error_vcc_enable;
> +}
> +
> +if (thc63->pdwn)
> +gpiod_set_value(thc63->pdwn, 0);
> +
> +if (thc63->oe)
> +gpiod_set_value(thc63->oe, 1);
> +
> +return;
> +
> +error_vcc_enable:
> +dev_err(thc63->dev, "Failed to enable regulator %s\n",
> +thc63_reg_names[i]);
> +
> +for (i = i - 1; i >= 0; i--) {
>>> Here, the loop will not end if you define i unsigned.
>> True.
>>
>>> I know one can change the loop, to make it working with unsigned. But
>>> this clearly shows that using unsigned is more risky.
>>> What are advantages of unsigned vs int in this case. Are there some
>>> guidelines/discussions about it?
>> Some people consider signed integers harmful, as they may be converted
>> silently by the compiler to the "larger" unsigned type when needed.
>
> Wow, it sounds crazy, shall we expect gigantic patchsets, converting all
> occurrences of int to "unsigned int" ? :)

No we shall not.

> I know both types have their pros and cons and can behave unexpectedly
> in corner cases, but I do not see why unsigned should be preferred over
> signed in general, or in this particular case.

When looping over array indices, and comparing with ARRAY_SIZE (which
is unsigned), using "unsigned int" is preferred.

However, in this case the error code relies on the index becoming negative,
so a signed integer should be used.

> I guess there were somewhere discussion about it, could you point me to
> it if possible, to avoid unnecessary noise in this thread.

Not here, but Google pointed me to
http://blog.robertelder.org/signed-or-unsigned/

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[bug report] drm/vmwgfx: Cursor update fixes

[Dan Carpenter]

Hello Thomas Hellstrom,

The patch 25db875401c8: "drm/vmwgfx: Cursor update fixes" from Jan
16, 2018, leads to the following static checker warning:

drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:513 
vmw_du_cursor_plane_atomic_check()
info: return a literal instead of 'ret'

drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
   493  int vmw_du_cursor_plane_atomic_check(struct drm_plane *plane,
   494   struct drm_plane_state *new_state)
   495  {
   496  int ret = 0;
   497  struct vmw_surface *surface = NULL;
   498  struct drm_framebuffer *fb = new_state->fb;
   499  
   500  struct drm_rect src = drm_plane_state_src(new_state);
   501  struct drm_rect dest = drm_plane_state_dest(new_state);
   502  
   503  /* Turning off */
   504  if (!fb)
   505  return ret;
^^
This would be more clear if it were "return 0;"

   506  
   507  ret = drm_plane_helper_check_update(plane, new_state->crtc, fb,
   508  &src, &dest,
   509  DRM_MODE_ROTATE_0,
   510  DRM_PLANE_HELPER_NO_SCALING,
   511  DRM_PLANE_HELPER_NO_SCALING,
   512  true, true, 
&new_state->visible);
   513  if (!ret)
   514  return ret;

Same here.  With the current code, it almost looks like that the if
statement is reversed.  As a newbie to this subsystem but with a bit of
kernel experience, it would take me a while to figure out if the if
statement is deliberate or a bug.

   515  
   516  /* A lot of the code assumes this */
   517  if (new_state->crtc_w != 64 || new_state->crtc_h != 64) {
   518  DRM_ERROR("Invalid cursor dimensions (%d, %d)\n",
   519new_state->crtc_w, new_state->crtc_h);
   520  ret = -EINVAL;
   521  }
   522  
   523  if (!vmw_framebuffer_to_vfb(fb)->dmabuf)
   524  surface = vmw_framebuffer_to_vfbs(fb)->surface;
   525  
   526  if (surface && !surface->snooper.image) {
   527  DRM_ERROR("surface not suitable for cursor\n");
   528  ret = -EINVAL;
   529  }
   530  
   531  return ret;
   532  }

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

[PATCH] gpu: drm: nouveau: Use list_for_each_entry_from_reverse

[Arushi Singhal]

It's better to use "list_for_each_entry_from_reverse" for iterating list
than "for loop" as it makes the code more clear to read.
This patch replace "for loop" with "list_for_each_entry_from_reverse"
and remove "cstate" variable as it is redundant in the code.

Signed-off-by: Arushi Singhal 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
index 81c3567..5e56f74 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
@@ -113,7 +113,6 @@ nvkm_cstate_find_best(struct nvkm_clk *clk, struct 
nvkm_pstate *pstate,
 {
struct nvkm_device *device = clk->subdev.device;
struct nvkm_volt *volt = device->volt;
-   struct nvkm_cstate *cstate;
int max_volt;
 
if (!pstate || !start)
@@ -133,13 +132,12 @@ nvkm_cstate_find_best(struct nvkm_clk *clk, struct 
nvkm_pstate *pstate,
max_volt = min(max_volt,
   nvkm_volt_map(volt, volt->max2_id, clk->temp));
 
-   for (cstate = start; &cstate->head != &pstate->list;
-cstate = list_prev_entry(cstate, head)) {
-   if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp))
+   list_for_each_entry_from_reverse(start, &pstate->list, head) {
+   if (nvkm_cstate_valid(clk, start, max_volt, clk->temp))
break;
}
 
-   return cstate;
+   return start;
 }
 
 static struct nvkm_cstate *
-- 
2.7.4

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

Re: [PATCH] gpu: drm: nouveau: Use list_for_each_entry_from_reverse

[Ben Skeggs]

On 27 March 2018 at 19:11, Arushi Singhal
 wrote:
> It's better to use "list_for_each_entry_from_reverse" for iterating list
> than "for loop" as it makes the code more clear to read.
> This patch replace "for loop" with "list_for_each_entry_from_reverse"
> and remove "cstate" variable as it is redundant in the code.
I would prefer to also see "start" renamed to "cstate" with this change.

Ben.

>
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> index 81c3567..5e56f74 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> @@ -113,7 +113,6 @@ nvkm_cstate_find_best(struct nvkm_clk *clk, struct 
> nvkm_pstate *pstate,
>  {
> struct nvkm_device *device = clk->subdev.device;
> struct nvkm_volt *volt = device->volt;
> -   struct nvkm_cstate *cstate;
> int max_volt;
>
> if (!pstate || !start)
> @@ -133,13 +132,12 @@ nvkm_cstate_find_best(struct nvkm_clk *clk, struct 
> nvkm_pstate *pstate,
> max_volt = min(max_volt,
>nvkm_volt_map(volt, volt->max2_id, clk->temp));
>
> -   for (cstate = start; &cstate->head != &pstate->list;
> -cstate = list_prev_entry(cstate, head)) {
> -   if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp))
> +   list_for_each_entry_from_reverse(start, &pstate->list, head) {
> +   if (nvkm_cstate_valid(clk, start, max_volt, clk->temp))
> break;
> }
>
> -   return cstate;
> +   return start;
>  }
>
>  static struct nvkm_cstate *
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [bug report] drm/vmwgfx: Cursor update fixes

[Daniel Vetter]

On Tue, Mar 27, 2018 at 12:05:38PM +0300, Dan Carpenter wrote:
> Hello Thomas Hellstrom,
> 
> The patch 25db875401c8: "drm/vmwgfx: Cursor update fixes" from Jan
> 16, 2018, leads to the following static checker warning:
> 
>   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:513 
> vmw_du_cursor_plane_atomic_check()
>   info: return a literal instead of 'ret'
> 
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
>493  int vmw_du_cursor_plane_atomic_check(struct drm_plane *plane,
>494   struct drm_plane_state 
> *new_state)
>495  {
>496  int ret = 0;
>497  struct vmw_surface *surface = NULL;
>498  struct drm_framebuffer *fb = new_state->fb;
>499  
>500  struct drm_rect src = drm_plane_state_src(new_state);
>501  struct drm_rect dest = drm_plane_state_dest(new_state);
>502  
>503  /* Turning off */
>504  if (!fb)
>505  return ret;
> ^^
> This would be more clear if it were "return 0;"
> 
>506  
>507  ret = drm_plane_helper_check_update(plane, new_state->crtc, 
> fb,
>508  &src, &dest,
>509  DRM_MODE_ROTATE_0,
>510  
> DRM_PLANE_HELPER_NO_SCALING,
>511  
> DRM_PLANE_HELPER_NO_SCALING,
>512  true, true, 
> &new_state->visible);
>513  if (!ret)
>514  return ret;
> 
> Same here.  With the current code, it almost looks like that the if
> statement is reversed.  As a newbie to this subsystem but with a bit of
> kernel experience, it would take me a while to figure out if the if
> statement is deliberate or a bug.

It is a bug, drm_plane_helper_check_update returns negative errno's on
failure. Also, this code should use drm_atomic_helper_check_plane_state,
not the legacy wrapper, since vmwgfx is an atomic driver (but maybe that's
fixed in -next already).
-Daniel
> 
>515  
>516  /* A lot of the code assumes this */
>517  if (new_state->crtc_w != 64 || new_state->crtc_h != 64) {
>518  DRM_ERROR("Invalid cursor dimensions (%d, %d)\n",
>519new_state->crtc_w, new_state->crtc_h);
>520  ret = -EINVAL;
>521  }
>522  
>523  if (!vmw_framebuffer_to_vfb(fb)->dmabuf)
>524  surface = vmw_framebuffer_to_vfbs(fb)->surface;
>525  
>526  if (surface && !surface->snooper.image) {
>527  DRM_ERROR("surface not suitable for cursor\n");
>528  ret = -EINVAL;
>529  }
>530  
>531  return ret;
>532  }
> 
> regards,
> dan carpenter
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH 1/5] staging/vboxvideo: Use gem_free_object_unlocked

[Daniel Vetter]

On Tue, Mar 27, 2018 at 10:34:07AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Mar 27, 2018 at 10:23:52AM +0200, Daniel Vetter wrote:
> > vboxvideo doesn't use dev->struct_mutex and therefore has no need to use
> > gem_free_object.
> > 
> > Signed-off-by: Daniel Vetter 
> > Cc: Greg Kroah-Hartman 
> > Cc: Hans de Goede 
> > Cc: Michael Thayer 
> > Cc: Colin Ian King 
> > Cc: Daniel Vetter 
> > Cc: Stephen Rothwell 
> > ---
> >  drivers/staging/vboxvideo/vbox_drv.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 
> Reviewed-by: Greg Kroah-Hartman 

You'll pick this up or ack for stuffing into drm-misc (but only for 4.18)?
There's no other patches that need this (we still have some drivers using
the gem_free_object hook which won't be easy to convert to the _unlocked
variant), so doesn't matter which tree.
-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] drm/amd/pp: silence a static checker warning

[rezhu]

Applied. Thanks.

Best Regards

Rex

On 2018年03月26日 11:30, Huang Rui wrote:

On Fri, Mar 23, 2018 at 02:39:03PM +0300, Dan Carpenter wrote:

This has a static checker warning because "frev" and "crev" can be
uninitialized if "info" is NULL.  I just changed the order of the checks
so that we check "info" first.

Signed-off-by: Dan Carpenter 

Reviewed-by: Huang Rui 


diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
index 75a465f771f0..7b26607c646a 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
@@ -319,13 +319,13 @@ static int smu8_get_system_info_data(struct pp_hwmgr 
*hwmgr)
GetIndexIntoMasterTable(DATA, IntegratedSystemInfo),
&size, &frev, &crev);
  
-	if (crev != 9) {

-   pr_err("Unsupported IGP table: %d %d\n", frev, crev);
+   if (info == NULL) {
+   pr_err("Could not retrieve the Integrated System Info 
Table!\n");
return -EINVAL;
}
  
-	if (info == NULL) {

-   pr_err("Could not retrieve the Integrated System Info 
Table!\n");
+   if (crev != 9) {
+   pr_err("Unsupported IGP table: %d %d\n", frev, crev);
return -EINVAL;
}
  
___

amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


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

Re: [PATCH 02/10] drm/sun4i: Disable YUV channel when using the frontend and set interlace

[Maxime Ripard]

On Tue, Mar 27, 2018 at 10:44:19AM +0200, Paul Kocialkowski wrote:
> > > Also, is interlacing actually used on any of the video outputs we
> > > support? Perhaps RGB?
> >
> > Composite would be a better guess :)
> 
> Oh and I was wondering what CVBS was about. Now I know!
> It seems that we don't support it for now apparently, anyway.

What do you mean? We do support it.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [PATCH 02/10] drm/sun4i: Disable YUV channel when using the frontend and set interlace

[Paul Kocialkowski]

On Tue, 2018-03-27 at 11:18 +0200, Maxime Ripard wrote:
> On Tue, Mar 27, 2018 at 10:44:19AM +0200, Paul Kocialkowski wrote:
> > > > Also, is interlacing actually used on any of the video outputs
> > > > we
> > > > support? Perhaps RGB?
> > > 
> > > Composite would be a better guess :)
> > 
> > Oh and I was wondering what CVBS was about. Now I know!
> > It seems that we don't support it for now apparently, anyway.
> 
> What do you mean? We do support it.

Sorry, I think I was remembering the status for A10/A20 only. Glad to
see that it works on A13!

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

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 v3] drm/xen-front: Add support for Xen PV display frontend

[Oleksandr Andrushchenko]

Hi, Daniel!

On 03/26/2018 03:46 PM, Oleksandr Andrushchenko wrote:

On 03/26/2018 11:18 AM, Daniel Vetter wrote:

On Fri, Mar 23, 2018 at 05:54:49PM +0200, Oleksandr Andrushchenko wrote:
My apologies, but I found a few more things that look strange and 
should
be cleaned up. Sorry for this iterative review approach, but I 
think we're

slowly getting there.

Thank you for reviewing!

Cheers, Daniel


---
+static int xen_drm_drv_dumb_create(struct drm_file *filp,
+    struct drm_device *dev, struct drm_mode_create_dumb *args)
+{
+    struct xen_drm_front_drm_info *drm_info = dev->dev_private;
+    struct drm_gem_object *obj;
+    int ret;
+
+    ret = xen_drm_front_gem_dumb_create(filp, dev, args);
+    if (ret)
+    goto fail;
+
+    obj = drm_gem_object_lookup(filp, args->handle);
+    if (!obj) {
+    ret = -ENOENT;
+    goto fail_destroy;
+    }
+
+    drm_gem_object_unreference_unlocked(obj);
You can't drop the reference while you keep using the object, 
someone else

might sneak in and destroy your object. The unreference always must be
last.

Will fix, thank you

+
+    /*
+ * In case of CONFIG_DRM_XEN_FRONTEND_CMA gem_obj is constructed
+ * via DRM CMA helpers and doesn't have ->pages allocated
+ * (xendrm_gem_get_pages will return NULL), but instead can 
provide

+ * sg table
+ */
+    if (xen_drm_front_gem_get_pages(obj))
+    ret = xen_drm_front_dbuf_create_from_pages(
+    drm_info->front_info,
+    xen_drm_front_dbuf_to_cookie(obj),
+    args->width, args->height, args->bpp,
+    args->size,
+    xen_drm_front_gem_get_pages(obj));
+    else
+    ret = xen_drm_front_dbuf_create_from_sgt(
+    drm_info->front_info,
+    xen_drm_front_dbuf_to_cookie(obj),
+    args->width, args->height, args->bpp,
+    args->size,
+    xen_drm_front_gem_get_sg_table(obj));
+    if (ret)
+    goto fail_destroy;
+
The above also has another race: If you construct an object, then 
it must
be fully constructed by the time you publish it to the wider world. 
In gem
this is done by calling drm_gem_handle_create() - after that 
userspace can

get at your object and do nasty things with it in a separate thread,
forcing your driver to Oops if the object isn't fully constructed yet.

That means you need to redo this code here to make sure that the gem
object is fully set up (including pages and sg tables) _before_ 
anything

calls drm_gem_handle_create().

You are correct, I need to rework this code

This probably means you also need to open-code the cma side, by first
calling drm_gem_cma_create(), then doing any additional setup, and 
finally
doing the registration to userspace with drm_gem_handle_create as 
the very

last thing.
Although I tend to avoid open-coding, but this seems the necessary 
measure

here
Alternativet is to do the pages/sg setup only when you create an fb 
(and

drop the pages again when the fb is destroyed), but that requires some
refcounting/locking in the driver.
Not sure this will work: nothing prevents you from attaching 
multiple FBs to

a single dumb handle
So, not only ref-counting should be done here, but I also need to 
check if

the dumb buffer,
we are attaching to, has been created already

No, you must make sure that no dumb buffer can be seen by anyone else
before it's fully created. If you don't register it in the file_priv idr
using drm_gem_handle_create, no one else can get at your buffer. 
Trying to

paper over this race from all the other places breaks the gem core code
design, and is also much more fragile.

Yes, this is what I implement now, e.g. I do not create
any dumb handle until GEM is fully created. I was just
saying that alternative way when we do pages/sgt on FB
attach will not work in my case

So, I will rework with open-coding some stuff from CMA helpers

Aside: There's still a lot of indirection and jumping around which 
makes

the code a bit hard to follow.
Probably I am not sure of which indirection we are talking about, 
could you

please
specifically mark those annoying you?

I think it's the same indirection we talked about last time, it still
annoys me. But it's still ok if you prefer this way I think :-)

Ok, probably this is because I'm looking at the driver
from an editor, but you are from your mail client ;)

+
+static void xen_drm_drv_release(struct drm_device *dev)
+{
+    struct xen_drm_front_drm_info *drm_info = dev->dev_private;
+    struct xen_drm_front_info *front_info = drm_info->front_info;
+
+    drm_atomic_helper_shutdown(dev);
+    drm_mode_config_cleanup(dev);
+
+    xen_drm_front_evtchnl_free_all(front_info);
+    dbuf_free_all(&front_info->dbuf_list);
+
+    drm_dev_fini(dev);
+    kfree(dev);
+
+    /*
+ * Free now, as this release could be not due to rmmod, but
+ * due to the backend disconnect, making drm_info hang in
+ * memory until rmmod
+ */
+    devm_kfre

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Vladimir Zapolskiy]

Hi Jacopo,

On 03/27/2018 11:57 AM, jacopo mondi wrote:
> Hi Vladimir,
> 
> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
>> Hi Sergei,
>>
>> On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
>>> Hello!
>>>
>>> On 3/27/2018 10:33 AM, jacopo mondi wrote:
>>> [...]
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Niklas Söderlund 
> ---
>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
> +++
>   1 file changed, 66 insertions(+)
>   create mode 100644
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> new file mode 100644
> index 000..8225c6a
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> @@ -0,0 +1,66 @@
> +Thine Electronics THC63LVD1024 LVDS decoder
> +---
> +
> +The THC63LVD1024 is a dual link LVDS receiver designed to convert 
> LVDS
> streams
> +to parallel data outputs. The chip supports single/dual input/output 
> modes,
> +handling up to two two input LVDS stream and up to two digital 
> CMOS/TTL
> outputs.
> +
> +Single or dual operation modes, output data mapping and DDR output 
> modes
> are
> +configured through input signals and the chip does not expose any 
> control
> bus.
> +
> +Required properties:
> +- compatible: Shall be "thine,thc63lvd1024"
> +
> +Optional properties:
> +- vcc-supply: Power supply for TTL output and digital circuitry
> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> +- lvcc-supply: Power supply for LVDS inputs
> +- pvcc-supply: Power supply for PLL circuitry
 As explained in a comment to one of the previous versions of this 
 series, I'm
 tempted to make vcc-supply mandatory and drop the three other power 
 supplies
 for now, as I believe there's very little chance they will be 
 connected to
 separately controllable regulators (all supplies use the same 
 voltage). In the
 very unlikely event that this occurs in design we need to support in 
 the
 future, the cvcc, lvcc and pvcc supplies can be added later as optional
 without breaking backward compatibility.
>>> I'm okay with that.
>>>
 Apart from that,

 Reviewed-by: Laurent Pinchart 

> +- pdwn-gpios: Power down GPIO signal. Active low
>>> powerdown-gpios is the semi-standard name.
>>>
>> right, I've also noticed it. If possible please avoid shortenings in
>> property names.
>
> It is not shortening, it just follow pin name from decoder's datasheet.
>
>>
> +- oe-gpios: Output enable GPIO signal. Active high
> +
>> And this one is also a not ever met property name, please consider to
>> rename it to 'enable-gpios', for instance display panels define it.
>
>
> Again, it follows datasheet naming scheme. Has something changed in DT
> conventions?

 Seconded. My understanding is that the property name should reflect
 what reported in the the chip manual. For THC63LVD1024 the enable and
 power down pins are named 'OE' and 'PDWN' respectively.
>>>
>>> But don't we need the vendor prefix in the prop names then, like
>>> "renesas,oe-gpios" then?
>>>
>>
>> Seconded, with a correction to "thine,oe-gpios".
>>
> 
> mmm, okay then...
> 
> A grep for that semi-standard properties names in Documentation/
> returns only usage examples and no actual definitions, so I assume this
> is why they are semi-standard.

Here we have to be specific about a particular property, let it be 'oe-gpios'
vs. 'enable-gpios' and let's collect some statistics:

% grep -Hr oe-gpios Documentation/devicetree/bindings/* | wc -l
0

$ grep -Hr enable-gpios Documentation/devicetree/bindings/* | wc -l
86

While 'thine,oe-gpios' would be correct, I see no reason to introduce a vendor
specific property to define a pin with a common and well understood purpose.

If you go forward with the vendor specific prefix, apparently you can set the 
name
to 'thine,oe-gpio' (single) or even to 'thine,oe', or does the datasheet names
the pin as "OE GPIO" or "OE connected to a GPIO"? I guess no.

Standards do not define '-gpios' suffix, but partially the description is found
in Documentation/bindings/gpio/gpio.txt, still it is not a section i

Re: [Intel-gfx] [PATCH 15/23] drm: Stop updating plane->crtc/fb/old_fb on atomic drivers

[Ville Syrjälä]

On Tue, Mar 27, 2018 at 09:57:41AM +0200, Daniel Vetter wrote:
> On Thu, Mar 22, 2018 at 05:23:05PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Stop playing around with plane->crtc/fb/old_fb with atomic
> > drivers. Make life a lot simpler when we don't have to do the
> > magic old_fb vs. fb dance around plane updates. That way we
> > can't risk plane->fb getting out of sync with plane->state->fb
> > and we're less likely to leak any refcounts as well.
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> What's the reason for this patch being in the middle of the patch series?
> I figured it's savest if we put this at the end? If you need parts of this
> here, we definitely need to split out the WARN_ON hunk, since you haven't
> fixed up everything yet at this point here.

Yeah, the ordering is probably not great. I think I had some idea why
I had to do "cleanup drivers a bit, do core/helper stuff, cleanup some
more drivers, do other core/helper stuff". But I can't even recall that
reason now. Most likely I had just managed to confuse myself by that
time.

> -Daniel
> 
> > ---
> >  drivers/gpu/drm/drm_atomic.c| 55 
> > -
> >  drivers/gpu/drm/drm_atomic_helper.c | 15 +-
> >  drivers/gpu/drm/drm_crtc.c  |  8 --
> >  drivers/gpu/drm/drm_fb_helper.c |  7 -
> >  drivers/gpu/drm/drm_framebuffer.c   |  5 
> >  drivers/gpu/drm/drm_plane.c | 14 ++
> >  drivers/gpu/drm/drm_plane_helper.c  |  4 ++-
> >  include/drm/drm_atomic.h|  3 --
> >  8 files changed, 24 insertions(+), 87 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 7d25c42f22db..b16cc37e2adf 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -692,6 +692,11 @@ drm_atomic_get_plane_state(struct drm_atomic_state 
> > *state,
> >  
> > WARN_ON(!state->acquire_ctx);
> >  
> > +   /* the legacy pointers should never be set */
> > +   WARN_ON(plane->fb);
> > +   WARN_ON(plane->old_fb);
> > +   WARN_ON(plane->crtc);
> > +
> > plane_state = drm_atomic_get_existing_plane_state(state, plane);
> > if (plane_state)
> > return plane_state;
> > @@ -2021,45 +2026,6 @@ int drm_atomic_set_property(struct drm_atomic_state 
> > *state,
> > return ret;
> >  }
> >  
> > -/**
> > - * drm_atomic_clean_old_fb -- Unset old_fb pointers and set plane->fb 
> > pointers.
> > - *
> > - * @dev: drm device to check.
> > - * @plane_mask: plane mask for planes that were updated.
> > - * @ret: return value, can be -EDEADLK for a retry.
> > - *
> > - * Before doing an update &drm_plane.old_fb is set to &drm_plane.fb, but 
> > before
> > - * dropping the locks old_fb needs to be set to NULL and plane->fb 
> > updated. This
> > - * is a common operation for each atomic update, so this call is split off 
> > as a
> > - * helper.
> > - */
> > -void drm_atomic_clean_old_fb(struct drm_device *dev,
> > -unsigned plane_mask,
> > -int ret)
> > -{
> > -   struct drm_plane *plane;
> > -
> > -   /* if succeeded, fixup legacy plane crtc/fb ptrs before dropping
> > -* locks (ie. while it is still safe to deref plane->state).  We
> > -* need to do this here because the driver entry points cannot
> > -* distinguish between legacy and atomic ioctls.
> > -*/
> > -   drm_for_each_plane_mask(plane, dev, plane_mask) {
> > -   if (ret == 0) {
> > -   struct drm_framebuffer *new_fb = plane->state->fb;
> > -   if (new_fb)
> > -   drm_framebuffer_get(new_fb);
> > -   plane->fb = new_fb;
> > -   plane->crtc = plane->state->crtc;
> > -
> > -   if (plane->old_fb)
> > -   drm_framebuffer_put(plane->old_fb);
> > -   }
> > -   plane->old_fb = NULL;
> > -   }
> > -}
> > -EXPORT_SYMBOL(drm_atomic_clean_old_fb);
> > -
> >  /**
> >   * DOC: explicit fencing properties
> >   *
> > @@ -2280,9 +2246,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > unsigned int copied_objs, copied_props;
> > struct drm_atomic_state *state;
> > struct drm_modeset_acquire_ctx ctx;
> > -   struct drm_plane *plane;
> > struct drm_out_fence_state *fence_state;
> > -   unsigned plane_mask;
> > int ret = 0;
> > unsigned int i, j, num_fences;
> >  
> > @@ -2322,7 +2286,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
> >  
> >  retry:
> > -   plane_mask = 0;
> > copied_objs = 0;
> > copied_props = 0;
> > fence_state = NULL;
> > @@ -2393,12 +2356,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > copied_props++;
> > }
> >  
> > -   if (obj->type == DRM_MODE_OBJECT_PLANE && count_props &&
> > -   !(arg->flags & DRM_MODE_ATOMI

Re: [PATCH v2 2/5] drm: bridge: add API to query the expected input formats of bridges

[jacopo mondi]

Hi Peter,
   thanks for the patches

On Mon, Mar 26, 2018 at 11:24:44PM +0200, Peter Rosin wrote:
> Bridges may affect the required bus output format of the encoder, in
> which case it may be wrong to use the output format of the panel or
> connector as is. Add infrastructure to address this problem.

Bridges not only affect the format expected by the connector at the
end of the display pipeline, they may perform encoding/decoding
between protocols and their accepted input formats may be unrelated to
the connector at the end of the pipeline as there may an arbitrary
number of bridges in between.

Eg.

ENCODERCONNECTOR
  | |
|DU LVDS| ->lvds-> |THC63| ->rgb-> |ADV7511| ->hdmi-> |HDMI connector|

The fact that THC63 wants a specific LVDS input format is unrelated to
the format required by the HDMI connector at the end of the pipeline.

I would just state here that bridges need a way to report their
accepted media bus formats, and this patch extends the DRM Bridge APIs
to implement that.

>
> Signed-off-by: Peter Rosin 
> ---
>  drivers/gpu/drm/drm_bridge.c | 32 
>  include/drm/drm_bridge.h | 18 ++
>  2 files changed, 50 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 1638bfe9627c..f85e61b7416e 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -348,6 +348,38 @@ void drm_bridge_enable(struct drm_bridge *bridge)
>  }
>  EXPORT_SYMBOL(drm_bridge_enable);
>
> +/**
> + * drm_bridge_input_formats - get the expected bus input format of the bridge

I may be biased by the V4L2 APIs, but this seems to me very much like
similar to g_fmt/s_fmt callbacks we have there. Bridges have an input and
an output formats, and that calls for something that takes that into
account, as well as they may have different input ports with different
accepted formats but I would for now simplify this to just 'g_fmt()'

> + * @bridge: bridge control structure
> + * @bus_formats: where to store a pointer to the bus input formats
> + *
> + * Calls the &drm_bridge_funcs.input_formats op for the frist bridge in the
> + * chain that has registered this op.

I'm not sure passing the call down the pipeline is desirable. Each
component should make sure its output format is accepted as the next
bridge input format, passing the call to the next bridge is not
different that getting to the connector at the end of the pipeline and
return to the initial caller its supported format. Do you agree with this?

> + *
> + * Note that the bridge passed should normally be the bridge closest to the
> + * encoder, but possibly the bridge closest to an intermediate bridge in
> + * convoluted cases.
> + *

As I see this, any bridge in the arbitrary long pipeline should call
this operation on next bridge if it supports different output formats.
Ie. I would not name here the encoder nor refer to the bridge position
in the pipeline.

> + * RETURNS:
> + * The number of bus input formats the bridge accepts. Zero means that
> + * the chain of bridges are not converting the bus format and that the
> + * format of the drm_connector should be used.

How do we get to the connector format from a bridge that has maybe
other components in between in the pipeline?

If a bridge do not report any supported format, it won't implement
this callback and things will work as they work today.

> + */
> +int drm_bridge_input_formats(struct drm_bridge *bridge,
> +  const u32 **bus_formats)
> +{
> + int ret = 0;
> +
> + if (!bridge)
> + return 0;
> +
> + if (bridge->funcs->input_formats)
> + ret = bridge->funcs->input_formats(bridge, bus_formats);
> +
> + return ret ?: drm_bridge_input_formats(bridge->next, bus_formats);

See my comment on the call propagation down in the pipeline.

> +}
> +EXPORT_SYMBOL(drm_bridge_input_formats);
> +
>  #ifdef CONFIG_OF
>  /**
>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 682d01ba920c..ae8d3c4af0b8 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -220,6 +220,22 @@ struct drm_bridge_funcs {
>* The enable callback is optional.
>*/
>   void (*enable)(struct drm_bridge *bridge);
> +
> + /**
> +  * @input_formats:
> +  *
> +  * The callback reports the expected bus input formats of the bridge.
> +  *
> +  * The @input_formats callback is optional. The bridge is assumed to
> +  * not convert the bus format if the callback is not installed.
> +  *
> +  * RETURNS:
> +  *
> +  * Zero if the bridge does not convert the bus format, otherwise the
> +  * number of bus input formats returned in &bus_formats.
> +  */
> + int (*input_formats)(struct drm_bridge *b

Re: [PATCH v3] drm/xen-front: Add support for Xen PV display frontend

[Daniel Vetter]

On Tue, Mar 27, 2018 at 11:34 AM, Oleksandr Andrushchenko
 wrote:
> Hi, Daniel!
>
>
> On 03/26/2018 03:46 PM, Oleksandr Andrushchenko wrote:
>>
>> On 03/26/2018 11:18 AM, Daniel Vetter wrote:
>>>
>>> On Fri, Mar 23, 2018 at 05:54:49PM +0200, Oleksandr Andrushchenko wrote:
>
> My apologies, but I found a few more things that look strange and
> should
> be cleaned up. Sorry for this iterative review approach, but I think
> we're
> slowly getting there.

 Thank you for reviewing!
>
> Cheers, Daniel
>
>> ---
>> +static int xen_drm_drv_dumb_create(struct drm_file *filp,
>> +struct drm_device *dev, struct drm_mode_create_dumb *args)
>> +{
>> +struct xen_drm_front_drm_info *drm_info = dev->dev_private;
>> +struct drm_gem_object *obj;
>> +int ret;
>> +
>> +ret = xen_drm_front_gem_dumb_create(filp, dev, args);
>> +if (ret)
>> +goto fail;
>> +
>> +obj = drm_gem_object_lookup(filp, args->handle);
>> +if (!obj) {
>> +ret = -ENOENT;
>> +goto fail_destroy;
>> +}
>> +
>> +drm_gem_object_unreference_unlocked(obj);
>
> You can't drop the reference while you keep using the object, someone
> else
> might sneak in and destroy your object. The unreference always must be
> last.

 Will fix, thank you
>>
>> +
>> +/*
>> + * In case of CONFIG_DRM_XEN_FRONTEND_CMA gem_obj is constructed
>> + * via DRM CMA helpers and doesn't have ->pages allocated
>> + * (xendrm_gem_get_pages will return NULL), but instead can
>> provide
>> + * sg table
>> + */
>> +if (xen_drm_front_gem_get_pages(obj))
>> +ret = xen_drm_front_dbuf_create_from_pages(
>> +drm_info->front_info,
>> +xen_drm_front_dbuf_to_cookie(obj),
>> +args->width, args->height, args->bpp,
>> +args->size,
>> +xen_drm_front_gem_get_pages(obj));
>> +else
>> +ret = xen_drm_front_dbuf_create_from_sgt(
>> +drm_info->front_info,
>> +xen_drm_front_dbuf_to_cookie(obj),
>> +args->width, args->height, args->bpp,
>> +args->size,
>> +xen_drm_front_gem_get_sg_table(obj));
>> +if (ret)
>> +goto fail_destroy;
>> +
>
> The above also has another race: If you construct an object, then it
> must
> be fully constructed by the time you publish it to the wider world. In
> gem
> this is done by calling drm_gem_handle_create() - after that userspace
> can
> get at your object and do nasty things with it in a separate thread,
> forcing your driver to Oops if the object isn't fully constructed yet.
>
> That means you need to redo this code here to make sure that the gem
> object is fully set up (including pages and sg tables) _before_
> anything
> calls drm_gem_handle_create().

 You are correct, I need to rework this code
>
> This probably means you also need to open-code the cma side, by first
> calling drm_gem_cma_create(), then doing any additional setup, and
> finally
> doing the registration to userspace with drm_gem_handle_create as the
> very
> last thing.

 Although I tend to avoid open-coding, but this seems the necessary
 measure
 here
>
> Alternativet is to do the pages/sg setup only when you create an fb
> (and
> drop the pages again when the fb is destroyed), but that requires some
> refcounting/locking in the driver.

 Not sure this will work: nothing prevents you from attaching multiple
 FBs to
 a single dumb handle
 So, not only ref-counting should be done here, but I also need to check
 if
 the dumb buffer,
 we are attaching to, has been created already
>>>
>>> No, you must make sure that no dumb buffer can be seen by anyone else
>>> before it's fully created. If you don't register it in the file_priv idr
>>> using drm_gem_handle_create, no one else can get at your buffer. Trying
>>> to
>>> paper over this race from all the other places breaks the gem core code
>>> design, and is also much more fragile.
>>
>> Yes, this is what I implement now, e.g. I do not create
>> any dumb handle until GEM is fully created. I was just
>> saying that alternative way when we do pages/sgt on FB
>> attach will not work in my case

 So, I will rework with open-coding some stuff from CMA helpers

> Aside: There's still a lot of indirection and jumping around which
> makes
> the code a bit hard to follow.

 Probably I am not sure of which indirection we are talking about, could
 you
 please
 specifically mark those annoying you?
>>>
>>> I think it's the same indirection we talked a

Re: [PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Vladimir Zapolskiy]

Hi Andrzej,

On 03/27/2018 10:28 AM, Andrzej Hajda wrote:
> On 27.03.2018 08:24, Vladimir Zapolskiy wrote:
>> Hi Jacopo,
>>
>> On 03/16/2018 05:16 PM, Jacopo Mondi wrote:
>>> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
>>> output converter.
>>>
>>> Signed-off-by: Jacopo Mondi 
>>> Reviewed-by: Andrzej Hajda 
>>> Reviewed-by: Niklas Söderlund 
>>> ---
>>>  drivers/gpu/drm/bridge/Kconfig|   6 +
>>>  drivers/gpu/drm/bridge/Makefile   |   1 +
>>>  drivers/gpu/drm/bridge/thc63lvd1024.c | 255 
>>> ++
>>>  3 files changed, 262 insertions(+)
>>>  create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
>>>
>>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>>> index 3b99d5a..5815a20 100644
>>> --- a/drivers/gpu/drm/bridge/Kconfig
>>> +++ b/drivers/gpu/drm/bridge/Kconfig
>>> @@ -92,6 +92,12 @@ config DRM_SII9234
>>>   It is an I2C driver, that detects connection of MHL bridge
>>>   and starts encapsulation of HDMI signal.
>>>  
>>> +config DRM_THINE_THC63LVD1024
>>> +   tristate "Thine THC63LVD1024 LVDS decoder bridge"
>>> +   depends on OF
>>> +   ---help---
>>> + Thine THC63LVD1024 LVDS/parallel converter driver.
>>> +
>>>  config DRM_TOSHIBA_TC358767
>>> tristate "Toshiba TC358767 eDP bridge"
>>> depends on OF
>>> diff --git a/drivers/gpu/drm/bridge/Makefile 
>>> b/drivers/gpu/drm/bridge/Makefile
>>> index 373eb28..fd90b16 100644
>>> --- a/drivers/gpu/drm/bridge/Makefile
>>> +++ b/drivers/gpu/drm/bridge/Makefile
>>> @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>>>  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
>>>  obj-$(CONFIG_DRM_SII902X) += sii902x.o
>>>  obj-$(CONFIG_DRM_SII9234) += sii9234.o
>>> +obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
>>>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>>>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>>>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
>>> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
>>> b/drivers/gpu/drm/bridge/thc63lvd1024.c
>>> new file mode 100644
>>> index 000..02a54c2
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
>>> @@ -0,0 +1,255 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
>>> + *
>>> + * Copyright (C) 2018 Jacopo Mondi 
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +enum {
>>> +   THC63_LVDS_IN0,
>>> +   THC63_LVDS_IN1,
>>> +   THC63_DIGITAL_OUT0,
>>> +   THC63_DIGITAL_OUT1,
>>> +};
>>> +
>>> +static const char * const thc63_reg_names[] = {
>>> +   "vcc", "lvcc", "pvcc", "cvcc",
>>> +};
>>> +
>>> +struct thc63_dev {
>>> +   struct device *dev;
>>> +
>>> +   struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
>>> +
>>> +   struct gpio_desc *pdwn;
>>> +   struct gpio_desc *oe;
>>> +
>>> +   struct drm_bridge bridge;
>>> +   struct drm_bridge *next;
>>> +};
>>> +
>>> +static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
>>> +{
>>> +   return container_of(bridge, struct thc63_dev, bridge);
>>> +}
>>> +
>>> +static int thc63_attach(struct drm_bridge *bridge)
>>> +{
>>> +   struct thc63_dev *thc63 = to_thc63(bridge);
>>> +
>>> +   return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
>>> +}
>>> +
>>> +static void thc63_enable(struct drm_bridge *bridge)
>>> +{
>>> +   struct thc63_dev *thc63 = to_thc63(bridge);
>>> +   struct regulator *vcc;
>>> +   int i;
>> unsigned int i;
> 
> Why? You are introducing silly bug this way, see few lines below.

You see that the comment was too terse to describe the context in full.
Thank you for exposing a flaw.

>>
>>> +
>>> +   for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
>>> +   vcc = thc63->vccs[i];
>>> +   if (!vcc)
>>> +   continue;
>>> +
>>> +   if (regulator_enable(vcc))
>>> +   goto error_vcc_enable;
>>> +   }
>>> +
>>> +   if (thc63->pdwn)
>>> +   gpiod_set_value(thc63->pdwn, 0);
>>> +
>>> +   if (thc63->oe)
>>> +   gpiod_set_value(thc63->oe, 1);
>>> +
>>> +   return;
>>> +
>>> +error_vcc_enable:
>>> +   dev_err(thc63->dev, "Failed to enable regulator %s\n",
>>> +   thc63_reg_names[i]);
>>> +
>>> +   for (i = i - 1; i >= 0; i--) {
> 
> Here, the loop will not end if you define i unsigned.
> 
> I know one can change the loop, to make it working with unsigned. But
> this clearly shows that using unsigned is more risky.
> What are advantages of unsigned vs int in this case. Are there some
> guidelines/discussions about it?
> 

The reason is pretty simple, like Geert said it might be a personal reason,
but a code pattern 

int i;
...
for (i = 0; i < ARRAY_SIZE(...); i++)

is my own red rag, because I've seen the pattern so many times, and every
time here a compiler produces a W=12 (or -Wsign-compare) warning like
the next one:

drivers/gpu/drm/bridge/thc63lvd10

Re: [PATCH 8/8] drm/arm/malidp: Added the late system pm functions

[Ayan Halder]

On Tue, Mar 27, 2018 at 10:29:03AM +0200, Daniel Vetter wrote:
> On Mon, Mar 26, 2018 at 06:03:20PM +0100, Ayan Kumar Halder wrote:
> > malidp_pm_suspend_late checks if the runtime status is not suspended
> > and if so, invokes malidp_runtime_pm_suspend which disables the
> > display engine/core interrupts and the clocks. It sets the runtime status
> > as suspended. Subsequently, malidp_pm_resume_early will invoke
> > malidp_runtime_pm_resume which enables the clocks and the interrupts
> > (previously disabled) and sets the runtime status as active.
> >
> > Signed-off-by: Ayan Kumar Halder 
> > Change-Id: I5f8c3d28f076314a1c9da2a46760a9c37039ccda
>
> Why exactly do you need late/early hooks? If you have dependencies with
> other devices, pls consider adding device_links instead. This here
> shouldn't be necessary.
> -Daniel
We need to late/early hooks to disable malidp interrupts and the
clocks.
> > ---
> >  drivers/gpu/drm/arm/malidp_drv.c | 17 +
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> > b/drivers/gpu/drm/arm/malidp_drv.c
> > index bd44a6d..f6124d8 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -766,8 +766,25 @@ static int __maybe_unused malidp_pm_resume(struct 
> > device *dev)
> > return 0;
> >  }
> >
> > +static int __maybe_unused malidp_pm_suspend_late(struct device *dev)
> > +{
> > +   if (!pm_runtime_status_suspended(dev)) {
> > +   malidp_runtime_pm_suspend(dev);
> > +   pm_runtime_set_suspended(dev);
> > +   }
> > +   return 0;
> > +}
> > +
> > +static int __maybe_unused malidp_pm_resume_early(struct device *dev)
> > +{
> > +   malidp_runtime_pm_resume(dev);
> > +   pm_runtime_set_active(dev);
> > +   return 0;
> > +}
> > +
> >  static const struct dev_pm_ops malidp_pm_ops = {
> > SET_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend, malidp_pm_resume) \
> > +   SET_LATE_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend_late, 
> > malidp_pm_resume_early) \
> > SET_RUNTIME_PM_OPS(malidp_runtime_pm_suspend, malidp_runtime_pm_resume, 
> > NULL)
> >  };
> >
> > --
> > 2.7.4
> >
> > ___
> > 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
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/simple-kms-helper: Plumb plane state to the enable hook

[Ville Syrjälä]

On Sat, Mar 24, 2018 at 12:26:32PM -0500, David Lechner wrote:
> On 03/22/2018 03:27 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > We'll need access to the plane state during .atomic_enable().
> > 
> 
> Some more details in the commit message would be useful. It is
> not clear to me why this change is being made.

"tinydrm enable hook wants to play around with the new fb in
.atomic_enable(), thus we'll need access to the plane state."

Better? Worse?

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

Re: [PATCH v3] drm/xen-front: Add support for Xen PV display frontend

[Oleksandr Andrushchenko]

On 03/27/2018 12:50 PM, Daniel Vetter wrote:

On Tue, Mar 27, 2018 at 11:34 AM, Oleksandr Andrushchenko
 wrote:

Hi, Daniel!


On 03/26/2018 03:46 PM, Oleksandr Andrushchenko wrote:

On 03/26/2018 11:18 AM, Daniel Vetter wrote:

On Fri, Mar 23, 2018 at 05:54:49PM +0200, Oleksandr Andrushchenko wrote:

My apologies, but I found a few more things that look strange and
should
be cleaned up. Sorry for this iterative review approach, but I think
we're
slowly getting there.

Thank you for reviewing!

Cheers, Daniel


---
+static int xen_drm_drv_dumb_create(struct drm_file *filp,
+struct drm_device *dev, struct drm_mode_create_dumb *args)
+{
+struct xen_drm_front_drm_info *drm_info = dev->dev_private;
+struct drm_gem_object *obj;
+int ret;
+
+ret = xen_drm_front_gem_dumb_create(filp, dev, args);
+if (ret)
+goto fail;
+
+obj = drm_gem_object_lookup(filp, args->handle);
+if (!obj) {
+ret = -ENOENT;
+goto fail_destroy;
+}
+
+drm_gem_object_unreference_unlocked(obj);

You can't drop the reference while you keep using the object, someone
else
might sneak in and destroy your object. The unreference always must be
last.

Will fix, thank you

+
+/*
+ * In case of CONFIG_DRM_XEN_FRONTEND_CMA gem_obj is constructed
+ * via DRM CMA helpers and doesn't have ->pages allocated
+ * (xendrm_gem_get_pages will return NULL), but instead can
provide
+ * sg table
+ */
+if (xen_drm_front_gem_get_pages(obj))
+ret = xen_drm_front_dbuf_create_from_pages(
+drm_info->front_info,
+xen_drm_front_dbuf_to_cookie(obj),
+args->width, args->height, args->bpp,
+args->size,
+xen_drm_front_gem_get_pages(obj));
+else
+ret = xen_drm_front_dbuf_create_from_sgt(
+drm_info->front_info,
+xen_drm_front_dbuf_to_cookie(obj),
+args->width, args->height, args->bpp,
+args->size,
+xen_drm_front_gem_get_sg_table(obj));
+if (ret)
+goto fail_destroy;
+

The above also has another race: If you construct an object, then it
must
be fully constructed by the time you publish it to the wider world. In
gem
this is done by calling drm_gem_handle_create() - after that userspace
can
get at your object and do nasty things with it in a separate thread,
forcing your driver to Oops if the object isn't fully constructed yet.

That means you need to redo this code here to make sure that the gem
object is fully set up (including pages and sg tables) _before_
anything
calls drm_gem_handle_create().

You are correct, I need to rework this code

This probably means you also need to open-code the cma side, by first
calling drm_gem_cma_create(), then doing any additional setup, and
finally
doing the registration to userspace with drm_gem_handle_create as the
very
last thing.

Although I tend to avoid open-coding, but this seems the necessary
measure
here

Alternativet is to do the pages/sg setup only when you create an fb
(and
drop the pages again when the fb is destroyed), but that requires some
refcounting/locking in the driver.

Not sure this will work: nothing prevents you from attaching multiple
FBs to
a single dumb handle
So, not only ref-counting should be done here, but I also need to check
if
the dumb buffer,
we are attaching to, has been created already

No, you must make sure that no dumb buffer can be seen by anyone else
before it's fully created. If you don't register it in the file_priv idr
using drm_gem_handle_create, no one else can get at your buffer. Trying
to
paper over this race from all the other places breaks the gem core code
design, and is also much more fragile.

Yes, this is what I implement now, e.g. I do not create
any dumb handle until GEM is fully created. I was just
saying that alternative way when we do pages/sgt on FB
attach will not work in my case

So, I will rework with open-coding some stuff from CMA helpers


Aside: There's still a lot of indirection and jumping around which
makes
the code a bit hard to follow.

Probably I am not sure of which indirection we are talking about, could
you
please
specifically mark those annoying you?

I think it's the same indirection we talked about last time, it still
annoys me. But it's still ok if you prefer this way I think :-)

Ok, probably this is because I'm looking at the driver
from an editor, but you are from your mail client ;)

+
+static void xen_drm_drv_release(struct drm_device *dev)
+{
+struct xen_drm_front_drm_info *drm_info = dev->dev_private;
+struct xen_drm_front_info *front_info = drm_info->front_info;
+
+drm_atomic_helper_shutdown(dev);
+drm_mode_config_cleanup(dev);
+
+xen_drm_front_evtchnl_free_all(front_info);
+dbuf_free_all(&front_info->dbuf_list);
+
+drm_dev_fini(dev);
+kfree(dev);
+
+/*
+ * Free now, as this release could be not due to rmmod, but
+ * due to the ba

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Vladimir,

On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 03/27/2018 11:57 AM, jacopo mondi wrote:
> > Hi Vladimir,
> >
> > On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
> >> Hi Sergei,
> >>
> >> On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> >>> Hello!
> >>>
> >>> On 3/27/2018 10:33 AM, jacopo mondi wrote:
> >>> [...]
> > Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >
> > Signed-off-by: Jacopo Mondi 
> > Reviewed-by: Andrzej Hajda 
> > Reviewed-by: Niklas Söderlund 
> > 
> > ---
> >   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
> > +++
> >   1 file changed, 66 insertions(+)
> >   create mode 100644
> > Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > new file mode 100644
> > index 000..8225c6a
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > @@ -0,0 +1,66 @@
> > +Thine Electronics THC63LVD1024 LVDS decoder
> > +---
> > +
> > +The THC63LVD1024 is a dual link LVDS receiver designed to convert 
> > LVDS
> > streams
> > +to parallel data outputs. The chip supports single/dual 
> > input/output modes,
> > +handling up to two two input LVDS stream and up to two digital 
> > CMOS/TTL
> > outputs.
> > +
> > +Single or dual operation modes, output data mapping and DDR output 
> > modes
> > are
> > +configured through input signals and the chip does not expose any 
> > control
> > bus.
> > +
> > +Required properties:
> > +- compatible: Shall be "thine,thc63lvd1024"
> > +
> > +Optional properties:
> > +- vcc-supply: Power supply for TTL output and digital circuitry
> > +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> > +- lvcc-supply: Power supply for LVDS inputs
> > +- pvcc-supply: Power supply for PLL circuitry
>  As explained in a comment to one of the previous versions of this 
>  series, I'm
>  tempted to make vcc-supply mandatory and drop the three other power 
>  supplies
>  for now, as I believe there's very little chance they will be 
>  connected to
>  separately controllable regulators (all supplies use the same 
>  voltage). In the
>  very unlikely event that this occurs in design we need to support in 
>  the
>  future, the cvcc, lvcc and pvcc supplies can be added later as 
>  optional
>  without breaking backward compatibility.
> >>> I'm okay with that.
> >>>
>  Apart from that,
> 
>  Reviewed-by: Laurent Pinchart 
> 
> > +- pdwn-gpios: Power down GPIO signal. Active low
> >>> powerdown-gpios is the semi-standard name.
> >>>
> >> right, I've also noticed it. If possible please avoid shortenings in
> >> property names.
> >
> > It is not shortening, it just follow pin name from decoder's datasheet.
> >
> >>
> > +- oe-gpios: Output enable GPIO signal. Active high
> > +
> >> And this one is also a not ever met property name, please consider to
> >> rename it to 'enable-gpios', for instance display panels define it.
> >
> >
> > Again, it follows datasheet naming scheme. Has something changed in DT
> > conventions?
> 
>  Seconded. My understanding is that the property name should reflect
>  what reported in the the chip manual. For THC63LVD1024 the enable and
>  power down pins are named 'OE' and 'PDWN' respectively.
> >>>
> >>> But don't we need the vendor prefix in the prop names then, like
> >>> "renesas,oe-gpios" then?
> >>>
> >>
> >> Seconded, with a correction to "thine,oe-gpios".
> >>
> >
> > mmm, okay then...
> >
> > A grep for that semi-standard properties names in Documentation/
> > returns only usage examples and no actual definitions, so I assume this
> > is why they are semi-standard.
>
> Here we have to be specific about a particular property, let it be 'oe-gpios'
> vs. 'enable-gpios' and let's collect some statistics:
>
> % grep -Hr oe-gpios Documentation/devicetree/bindings/* | wc -l
> 0
>
> $ grep -Hr enable-gpios Documentation/devicetree/bindings/* | wc -l
> 86
>
> While 'thine,oe-gpios' would be correct, I see no reason to introduce a vendor
> specific property to define a pin with a common and well understood purpose.
>
> If you go forward with

Re: [PATCH v2 4/5] drm: bridge: lvds-encoder: allow specifying the input bus format

[jacopo mondi]

Hi Peter, Laurent,
   thanks for the patches,

On Mon, Mar 26, 2018 at 11:24:46PM +0200, Peter Rosin wrote:
> If the bridge changes the bus format, allow this to be described in
> the bridge, instead of providing false information about the bus
> format of the connector or panel.
>
> Signed-off-by: Peter Rosin 
> ---
>  .../bindings/display/bridge/lvds-transmitter.txt   |  6 ++
>  drivers/gpu/drm/bridge/lvds-encoder.c  | 25 
> ++
>  2 files changed, 31 insertions(+)
>
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt 
> b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> index 50220190c203..8d40a2069252 100644
> --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> @@ -30,6 +30,12 @@ Required properties:
>device-specific version corresponding to the device first
>followed by the generic version.
>
> +Optional properties:
> +
> +- interface-pix-fmt:
> +  List of valid input bus formats of the encoder. Recognized bus formats
> +  are listed in ../bus-format.txt
> +

This comments applies here and to [3/5] as well.

Are we sure we want the supported bridge input format defined in DT
bindings?

Again, I may be biased, but as I see this, each bridge driver should
list its supported formats with MEDIA_BUS_FMT_ fourcc codes and return
the currently 'active' one when requested by the preceding bridge.

I understand for this driver, being compatible with both a generic lvds
encoder and a specific chip, the supported input formats are
different, but I would have used the 'of_device_id.data' field for
this and leave this out from DT bindings.

This makes the translation routine here implemented not required if
I'm not wrong...

Thanks
   j

>  Required nodes:
>
>  This device has two video ports. Their connections are modeled using the OF
> diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c 
> b/drivers/gpu/drm/bridge/lvds-encoder.c
> index 75b0d3f6e4de..b78619b5560a 100644
> --- a/drivers/gpu/drm/bridge/lvds-encoder.c
> +++ b/drivers/gpu/drm/bridge/lvds-encoder.c
> @@ -9,6 +9,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include 
> @@ -16,6 +17,8 @@
>  struct lvds_encoder {
>   struct drm_bridge bridge;
>   struct drm_bridge *panel_bridge;
> + int num_bus_formats;
> + u32 *bus_formats;
>  };
>
>  static int lvds_encoder_attach(struct drm_bridge *bridge)
> @@ -28,8 +31,22 @@ static int lvds_encoder_attach(struct drm_bridge *bridge)
>bridge);
>  }
>
> +static int lvds_encoder_input_formats(struct drm_bridge *bridge,
> +   const u32 **bus_formats)
> +{
> + struct lvds_encoder *lvds_encoder = container_of(bridge,
> +  struct lvds_encoder,
> +  bridge);
> +
> + if (lvds_encoder->num_bus_formats)
> + *bus_formats = lvds_encoder->bus_formats;
> +
> + return lvds_encoder->num_bus_formats;
> +}
> +
>  static struct drm_bridge_funcs funcs = {
>   .attach = lvds_encoder_attach,
> + .input_formats = lvds_encoder_input_formats,
>  };
>
>  static int lvds_encoder_probe(struct platform_device *pdev)
> @@ -39,6 +56,7 @@ static int lvds_encoder_probe(struct platform_device *pdev)
>   struct device_node *panel_node;
>   struct drm_panel *panel;
>   struct lvds_encoder *lvds_encoder;
> + int ret;
>
>   lvds_encoder = devm_kzalloc(&pdev->dev, sizeof(*lvds_encoder),
>   GFP_KERNEL);
> @@ -79,6 +97,12 @@ static int lvds_encoder_probe(struct platform_device *pdev)
>   if (IS_ERR(lvds_encoder->panel_bridge))
>   return PTR_ERR(lvds_encoder->panel_bridge);
>
> + ret = drm_of_bus_formats(pdev->dev.of_node, "interface-pix-fmt",
> +  &lvds_encoder->bus_formats);
> + if (ret < 0)
> + return ret;
> + lvds_encoder->num_bus_formats = ret;
> +
>   /* The panel_bridge bridge is attached to the panel's of_node,
>* but we need a bridge attached to our of_node for our user
>* to look up.
> @@ -96,6 +120,7 @@ static int lvds_encoder_remove(struct platform_device 
> *pdev)
>  {
>   struct lvds_encoder *lvds_encoder = platform_get_drvdata(pdev);
>
> + kfree(lvds_encoder->bus_formats);
>   drm_bridge_remove(&lvds_encoder->bridge);
>
>   return 0;
> --
> 2.11.0
>


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

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Vladimir Zapolskiy]

Hi Jacopo,

On 03/27/2018 01:10 PM, jacopo mondi wrote:
> Hi Vladimir,
> 
> On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
>> Hi Jacopo,
>>
>> On 03/27/2018 11:57 AM, jacopo mondi wrote:
>>> Hi Vladimir,
>>>
>>> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
 Hi Sergei,

 On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> Hello!
>
> On 3/27/2018 10:33 AM, jacopo mondi wrote:
> [...]
>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>>>
>>> Signed-off-by: Jacopo Mondi 
>>> Reviewed-by: Andrzej Hajda 
>>> Reviewed-by: Niklas Söderlund 
>>> 
>>> ---
>>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
>>> +++
>>>   1 file changed, 66 insertions(+)
>>>   create mode 100644
>>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> new file mode 100644
>>> index 000..8225c6a
>>> --- /dev/null
>>> +++
>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> @@ -0,0 +1,66 @@
>>> +Thine Electronics THC63LVD1024 LVDS decoder
>>> +---
>>> +
>>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert 
>>> LVDS
>>> streams
>>> +to parallel data outputs. The chip supports single/dual 
>>> input/output modes,
>>> +handling up to two two input LVDS stream and up to two digital 
>>> CMOS/TTL
>>> outputs.
>>> +
>>> +Single or dual operation modes, output data mapping and DDR output 
>>> modes
>>> are
>>> +configured through input signals and the chip does not expose any 
>>> control
>>> bus.
>>> +
>>> +Required properties:
>>> +- compatible: Shall be "thine,thc63lvd1024"
>>> +
>>> +Optional properties:
>>> +- vcc-supply: Power supply for TTL output and digital circuitry
>>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>>> +- lvcc-supply: Power supply for LVDS inputs
>>> +- pvcc-supply: Power supply for PLL circuitry
>> As explained in a comment to one of the previous versions of this 
>> series, I'm
>> tempted to make vcc-supply mandatory and drop the three other power 
>> supplies
>> for now, as I believe there's very little chance they will be 
>> connected to
>> separately controllable regulators (all supplies use the same 
>> voltage). In the
>> very unlikely event that this occurs in design we need to support in 
>> the
>> future, the cvcc, lvcc and pvcc supplies can be added later as 
>> optional
>> without breaking backward compatibility.
> I'm okay with that.
>
>> Apart from that,
>>
>> Reviewed-by: Laurent Pinchart 
>>
>>> +- pdwn-gpios: Power down GPIO signal. Active low
> powerdown-gpios is the semi-standard name.
>
 right, I've also noticed it. If possible please avoid shortenings in
 property names.
>>>
>>> It is not shortening, it just follow pin name from decoder's datasheet.
>>>

>>> +- oe-gpios: Output enable GPIO signal. Active high
>>> +
 And this one is also a not ever met property name, please consider to
 rename it to 'enable-gpios', for instance display panels define it.
>>>
>>>
>>> Again, it follows datasheet naming scheme. Has something changed in DT
>>> conventions?
>>
>> Seconded. My understanding is that the property name should reflect
>> what reported in the the chip manual. For THC63LVD1024 the enable and
>> power down pins are named 'OE' and 'PDWN' respectively.
>
> But don't we need the vendor prefix in the prop names then, like
> "renesas,oe-gpios" then?
>

 Seconded, with a correction to "thine,oe-gpios".

>>>
>>> mmm, okay then...
>>>
>>> A grep for that semi-standard properties names in Documentation/
>>> returns only usage examples and no actual definitions, so I assume this
>>> is why they are semi-standard.
>>
>> Here we have to be specific about a particular property, let it be 'oe-gpios'
>> vs. 'enable-gpios' and let's collect some statistics:
>>
>> % grep -Hr oe-gpios Documentation/devicetree/bindings/* | wc -l
>> 0
>>
>> $ grep -Hr enable-gpios Documentation/devicetree/bindings/* | wc -l
>> 86
>>
>> While 'thine,oe-gpios' would be correct, I see no reason to introduce a 
>> vendor
>> specific property to d

Re: [PATCH 8/8] drm/arm/malidp: Added the late system pm functions

[Daniel Vetter]

On Tue, Mar 27, 2018 at 11:59 AM, Ayan Halder  wrote:
> On Tue, Mar 27, 2018 at 10:29:03AM +0200, Daniel Vetter wrote:
>> On Mon, Mar 26, 2018 at 06:03:20PM +0100, Ayan Kumar Halder wrote:
>> > malidp_pm_suspend_late checks if the runtime status is not suspended
>> > and if so, invokes malidp_runtime_pm_suspend which disables the
>> > display engine/core interrupts and the clocks. It sets the runtime status
>> > as suspended. Subsequently, malidp_pm_resume_early will invoke
>> > malidp_runtime_pm_resume which enables the clocks and the interrupts
>> > (previously disabled) and sets the runtime status as active.
>> >
>> > Signed-off-by: Ayan Kumar Halder 
>> > Change-Id: I5f8c3d28f076314a1c9da2a46760a9c37039ccda
>>
>> Why exactly do you need late/early hooks? If you have dependencies with
>> other devices, pls consider adding device_links instead. This here
>> shouldn't be necessary.
>> -Daniel
> We need to late/early hooks to disable malidp interrupts and the
> clocks.

Yes, but why this ordering constraint? Why can't you just disable the
interrupts/clocks in the normal suspend code. I see that the patch
does this, I want to understand why it does it.
-Daniel

>> > ---
>> >  drivers/gpu/drm/arm/malidp_drv.c | 17 +
>> >  1 file changed, 17 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
>> > b/drivers/gpu/drm/arm/malidp_drv.c
>> > index bd44a6d..f6124d8 100644
>> > --- a/drivers/gpu/drm/arm/malidp_drv.c
>> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
>> > @@ -766,8 +766,25 @@ static int __maybe_unused malidp_pm_resume(struct 
>> > device *dev)
>> > return 0;
>> >  }
>> >
>> > +static int __maybe_unused malidp_pm_suspend_late(struct device *dev)
>> > +{
>> > +   if (!pm_runtime_status_suspended(dev)) {
>> > +   malidp_runtime_pm_suspend(dev);
>> > +   pm_runtime_set_suspended(dev);
>> > +   }
>> > +   return 0;
>> > +}
>> > +
>> > +static int __maybe_unused malidp_pm_resume_early(struct device *dev)
>> > +{
>> > +   malidp_runtime_pm_resume(dev);
>> > +   pm_runtime_set_active(dev);
>> > +   return 0;
>> > +}
>> > +
>> >  static const struct dev_pm_ops malidp_pm_ops = {
>> > SET_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend, malidp_pm_resume) \
>> > +   SET_LATE_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend_late, 
>> > malidp_pm_resume_early) \
>> > SET_RUNTIME_PM_OPS(malidp_runtime_pm_suspend, 
>> > malidp_runtime_pm_resume, NULL)
>> >  };
>> >
>> > --
>> > 2.7.4
>> >
>> > ___
>> > 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
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH xserver 3/3] modesetting/drmmode: Use drmModeGetFB2

[Daniel Stone]

Hi Emil,

On 26 March 2018 at 16:22, Emil Velikov  wrote:
> On 23 March 2018 at 13:50, Daniel Stone  wrote:
>> Much like AddFB -> AddFB2, GetFB2 lets us get multiple buffers back as
>> well as modifier information. This lets us use -background none with
>> multiplanar formats, or modifiers which can't be inferred via a magic
>> side channel.
>>
> AFAICT there's nothing special (or wrong) with the new API.
>
> The flags field is a bit of an open question - should Xserver or
> libdrm manage the value passed to the kernel?
> Analogously - should we pass the flags back to the user (drmModeFB2::flags)?
>
> Current design seems perfectly fine IMHO, although others might disagree.

Thanks for looking at this! I think the flags question is a good one,
and that we should probably make the field RW: userspace declaring
what it supports (analagous to AddFB2), and the kernel overwriting
that with the intersection of what userspace and the kernel support
(not analogous, but since it's a getter rather than an add ...).

>> @@ -1090,31 +1094,63 @@ create_pixmap_for_fbcon(drmmode_ptr drmmode, 
>> ScrnInfoPtr pScrn, int fbcon_id)
>>  if (pixmap)
>>  return pixmap;
>>
>> -fbcon = drmModeGetFB(drmmode->fd, fbcon_id);
>> -if (fbcon == NULL)
>> -return NULL;
>> +fbcon2 = drmModeGetFB2(drmmode->fd, fbcon_id);
>> +if (fbcon2) {
> Declare and initialize fbcon2 in one go - C99 feature that everyone
> has (even the people who use MSVC to build Xserver & friends).
> Then wrap the whole fbcon2 hunk in a #ifdef HAVE_GETFB2 + add a
> configure/meson check.

Sure; the only reason I didn't add an ifdef check is because there's
no version released with it yet.

> Alternatively add a weak drmModeGetFB2 function which returns NULL and
> forget all the above ;-)

If you have a good suggestion for implementing weak symbols then I'm
all ears, but last I saw from the Mesa experience no-one could figure
out how to do it properly.

>> +width = fbcon2->width;
>> +height = fbcon2->height;
>> +memcpy(handles, fbcon2->handles, sizeof(handles));
>> +memcpy(strides, fbcon2->pitches, sizeof(strides));
>> +memcpy(offsets, fbcon2->offsets, sizeof(offsets));
>> +modifier = fbcon2->modifier;
>> +switch (fbcon2->pixel_format) {
>> +case DRM_FORMAT_RGB565:
>> +depth = 16;
> Missing bpp?

Correct.

> Idea: Instead of introducing another format <> {depth, bpp} mapping,
> might as well add some helpers?

I can only see that mapping inside drmmode_create_bo, which is
different as it creates everything with an alpha channel, i.e.
s/XRGB/ARGB/. Are there some others I'm missing?

>> +break;
>> +case DRM_FORMAT_XRGB:
>> +depth = 24;
>> +bpp = 32;
>> +break;
>> +case DRM_FORMAT_XRGB2101010:
>> +depth = 30;
>> +bpp = 32;
>> +default:
>> +break;
> Error instead of silently continuing?

Sure.

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

Re: [PATCH] gpu: drm: nouveau: Use list_for_each_entry_from_reverse

[Arushi Singhal]

On Tue, Mar 27, 2018 at 2:44 PM, Ben Skeggs  wrote:

> On 27 March 2018 at 19:11, Arushi Singhal
>  wrote:
> > It's better to use "list_for_each_entry_from_reverse" for iterating list
> > than "for loop" as it makes the code more clear to read.
> > This patch replace "for loop" with "list_for_each_entry_from_reverse"
> > and remove "cstate" variable as it is redundant in the code.
> I would prefer to also see "start" renamed to "cstate" with this change.
>
Hello Ben

Yes, using cstate is more accurate, as most of the functions are using
"cstate" variable.

Best
Arushi

>
> Ben.
>
> >
> > Signed-off-by: Arushi Singhal 
> > ---
> >  drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 8 +++-
> >  1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> > index 81c3567..5e56f74 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> > @@ -113,7 +113,6 @@ nvkm_cstate_find_best(struct nvkm_clk *clk, struct
> nvkm_pstate *pstate,
> >  {
> > struct nvkm_device *device = clk->subdev.device;
> > struct nvkm_volt *volt = device->volt;
> > -   struct nvkm_cstate *cstate;
> > int max_volt;
> >
> > if (!pstate || !start)
> > @@ -133,13 +132,12 @@ nvkm_cstate_find_best(struct nvkm_clk *clk, struct
> nvkm_pstate *pstate,
> > max_volt = min(max_volt,
> >nvkm_volt_map(volt, volt->max2_id,
> clk->temp));
> >
> > -   for (cstate = start; &cstate->head != &pstate->list;
> > -cstate = list_prev_entry(cstate, head)) {
> > -   if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp))
> > +   list_for_each_entry_from_reverse(start, &pstate->list, head) {
> > +   if (nvkm_cstate_valid(clk, start, max_volt, clk->temp))
> > break;
> > }
> >
> > -   return cstate;
> > +   return start;
> >  }
> >
> >  static struct nvkm_cstate *
> > --
> > 2.7.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105733

--- Comment #4 from Allan  ---
If you set amdgpu.dc=1 as a boot parameter and then try openning pavucontrol,
the screen hungs with artifacts (mouse cursor keeps moving) and you get this
error :


```
[  125.640254] amdgpu :0e:00.0: GPU fault detected: 147 0x04f00402
[  125.640259] amdgpu :0e:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x001C389E
[  125.640262] amdgpu :0e:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x04004002
[  125.640264] amdgpu :0e:00.0: VM fault (0x02, vmid 2) at page 1849502,
read from 'TC1' (0x54433100) (4)
[  125.640641] amdgpu :0e:00.0: GPU fault detected: 147 0x05004802
[  125.640643] amdgpu :0e:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x001C38A0
[  125.640644] amdgpu :0e:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x04048002
[  125.640646] amdgpu :0e:00.0: VM fault (0x02, vmid 2) at page 1849504,
read from 'TC4' (0x54433400) (72)
```

I'm using kernel 4.15.

Then when you request a poweroff from ssh the call trace appears again and
hungs the system, then you have to do a hard reset.

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

Re: [bug report] drm/vmwgfx: Cursor update fixes

[Thomas Hellstrom]

Hi!

Thanks for the comments, I'll take a closer look.

/Thomas



On 03/27/2018 11:16 AM, Daniel Vetter wrote:

On Tue, Mar 27, 2018 at 12:05:38PM +0300, Dan Carpenter wrote:

Hello Thomas Hellstrom,

The patch 25db875401c8: "drm/vmwgfx: Cursor update fixes" from Jan
16, 2018, leads to the following static checker warning:

drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:513 
vmw_du_cursor_plane_atomic_check()
info: return a literal instead of 'ret'

drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
493  int vmw_du_cursor_plane_atomic_check(struct drm_plane *plane,
494   struct drm_plane_state *new_state)
495  {
496  int ret = 0;
497  struct vmw_surface *surface = NULL;
498  struct drm_framebuffer *fb = new_state->fb;
499
500  struct drm_rect src = drm_plane_state_src(new_state);
501  struct drm_rect dest = drm_plane_state_dest(new_state);
502
503  /* Turning off */
504  if (!fb)
505  return ret;
 ^^
This would be more clear if it were "return 0;"

506
507  ret = drm_plane_helper_check_update(plane, new_state->crtc, fb,
508  &src, &dest,
509  DRM_MODE_ROTATE_0,
510  
DRM_PLANE_HELPER_NO_SCALING,
511  
DRM_PLANE_HELPER_NO_SCALING,
512  true, true, 
&new_state->visible);
513  if (!ret)
514  return ret;

Same here.  With the current code, it almost looks like that the if
statement is reversed.  As a newbie to this subsystem but with a bit of
kernel experience, it would take me a while to figure out if the if
statement is deliberate or a bug.

It is a bug, drm_plane_helper_check_update returns negative errno's on
failure. Also, this code should use drm_atomic_helper_check_plane_state,
not the legacy wrapper, since vmwgfx is an atomic driver (but maybe that's
fixed in -next already).
-Daniel

515
516  /* A lot of the code assumes this */
517  if (new_state->crtc_w != 64 || new_state->crtc_h != 64) {
518  DRM_ERROR("Invalid cursor dimensions (%d, %d)\n",
519new_state->crtc_w, new_state->crtc_h);
520  ret = -EINVAL;
521  }
522
523  if (!vmw_framebuffer_to_vfb(fb)->dmabuf)
524  surface = vmw_framebuffer_to_vfbs(fb)->surface;
525
526  if (surface && !surface->snooper.image) {
527  DRM_ERROR("surface not suitable for cursor\n");
528  ret = -EINVAL;
529  }
530
531  return ret;
532  }

regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel&d=DwIBAg&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=EmKCi9L_95tppMT-q6ky7JkUBYYdk22nnaoiRUQRZ3c&s=acr_OiqUZeMipWTzfnf3FAppMYvjv-tetZPy2bYXVxg&e=



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

[Bug 105729] AMD Radeon flickering on Gnome Wayland after wake from suspend

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105729

--- Comment #2 from Jan Vlug  ---
> I believe it's the same,
> flickering when mouse movement occurs. However it's not flickering, it's
> more like it's locking the framebuffer and preventing any draws. Try running
> glxgears and moving your cursor in circles. I can get the gear to stop
> turning completely if I move my mouse quickly enough. Do we have the same
> bug? 

No it is different. When I start glxgears, there is no flickering as long as
the mouse pointer stays in the area with the gears. The gears spin without
disruption. However, as soon as the pointer leaves the gear area (i.e. touches
a window decoration) I see the flickering.

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

[Bug 105747] TOPAZ: ring buffers not getting initialized with the amd-staging-drm-next branch

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105747

Nayan Deshmukh  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #5 from Nayan Deshmukh  ---
It is working alright. Sorry for the unnecessary noise.

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

Re: [PATCH v2 2/5] drm: bridge: add API to query the expected input formats of bridges

[jacopo mondi]

Hi Peter,

On Tue, Mar 27, 2018 at 02:12:42PM +0200, Peter Rosin wrote:
> Hi Jacopo,
>
> Thanks for the feedback!
>
> On 2018-03-27 11:47, jacopo mondi wrote:
> > Hi Peter,
> >thanks for the patches
> >
> > On Mon, Mar 26, 2018 at 11:24:44PM +0200, Peter Rosin wrote:
> >> Bridges may affect the required bus output format of the encoder, in
> >> which case it may be wrong to use the output format of the panel or
> >> connector as is. Add infrastructure to address this problem.
> >
> > Bridges not only affect the format expected by the connector at the
> > end of the display pipeline, they may perform encoding/decoding
> > between protocols and their accepted input formats may be unrelated to
> > the connector at the end of the pipeline as there may an arbitrary
> > number of bridges in between.
> >
> > Eg.
> >
> > ENCODERCONNECTOR
> >   | |
> > |DU LVDS| ->lvds-> |THC63| ->rgb-> |ADV7511| ->hdmi-> |HDMI connector|
> >
> > The fact that THC63 wants a specific LVDS input format is unrelated to
> > the format required by the HDMI connector at the end of the pipeline.
> >
> > I would just state here that bridges need a way to report their
> > accepted media bus formats, and this patch extends the DRM Bridge APIs
> > to implement that.
>
> Yes, I can add some words, but I would like to clear up the naming
> before re-spinning.
>
> >>
> >> Signed-off-by: Peter Rosin 
> >> ---
> >>  drivers/gpu/drm/drm_bridge.c | 32 
> >>  include/drm/drm_bridge.h | 18 ++
> >>  2 files changed, 50 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >> index 1638bfe9627c..f85e61b7416e 100644
> >> --- a/drivers/gpu/drm/drm_bridge.c
> >> +++ b/drivers/gpu/drm/drm_bridge.c
> >> @@ -348,6 +348,38 @@ void drm_bridge_enable(struct drm_bridge *bridge)
> >>  }
> >>  EXPORT_SYMBOL(drm_bridge_enable);
> >>
> >> +/**
> >> + * drm_bridge_input_formats - get the expected bus input format of the 
> >> bridge
> >
> > I may be biased by the V4L2 APIs, but this seems to me very much like
> > similar to g_fmt/s_fmt callbacks we have there. Bridges have an input and
>
> g_fmt/s_fmt says nothing to me. Graphics format? Source Format? I have
> no idea if those guesses are even close? So, that seems like poor naming
> to me. The only reason I see to go that way is for the sake of consistency.
>

Sorry, I wasn't clear here.

To me this operation seems like a "get format" and I see space for
future implementation of "set format" operations  and also
"enum_formats" to implement format negotiation between bridges...


> > an output formats, and that calls for something that takes that into
> > account, as well as they may have different input ports with different
> > accepted formats but I would for now simplify this to just 'g_fmt()'
>
> You mean rename the function to drm_bridge_g_fmt(), right?

Yeah, something like "drm_bridge_get_format(next_bridge)"

>
> As indicated above, I'm not that fond of it, but don't really care
> either. Maintainers?
>

I do not care much about the name too ofc, I think the real meat is
below...

> >> + * @bridge: bridge control structure
> >> + * @bus_formats: where to store a pointer to the bus input formats
> >> + *
> >> + * Calls the &drm_bridge_funcs.input_formats op for the frist bridge in 
> >> the
> >> + * chain that has registered this op.
> >
> > I'm not sure passing the call down the pipeline is desirable. Each
> > component should make sure its output format is accepted as the next
> > bridge input format, passing the call to the next bridge is not
> > different that getting to the connector at the end of the pipeline and
> > return to the initial caller its supported format. Do you agree with this?
>
> Not passing down the call does one of two things. Either all bridges have
> to implement the call or all users have to walk the pipeline "manually".
> I don't like either or those options, so I still think it is good to
> pass the call down the pipeline.
>
> *time passes*
>
> Oh, you do not think it is useful for the bridge to have a callback but
> still report "no format change", and that the call down to pipeline
> should only happen for bridges that have not implemented the op. But I
> do think that is useful, see below.
>
> >> + *
> >> + * Note that the bridge passed should normally be the bridge closest to 
> >> the
> >> + * encoder, but possibly the bridge closest to an intermediate bridge in
> >> + * convoluted cases.
> >> + *
> >
> > As I see this, any bridge in the arbitrary long pipeline should call
> > this operation on next bridge if it supports different output formats.
> > Ie. I would not name here the encoder nor refer to the bridge position
> > in the pipeline.
>
> Ok, I can change that, it just seemed like a convoluted case to me.
> I mean, if this was a real issue and complicated pipelines were

Re: [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[kbuild test robot]

Hi Matt,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.16-rc7 next-20180326]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/matthew-s-atwood-intel-com/drm-dp-Correctly-mask-DP_TRAINING_AUX_RD_INTERVAL-values-for-DP-1-4/20180324-035824
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-federa-25 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/include/dpcd_defs.h:29:0,
from 
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:42:
>> include/drm/drm_dp_helper.h:67:45: error: expected identifier before numeric 
>> constant
# define DPCD_REV_100x10
^
   drivers/gpu/drm/amd/amdgpu/../display/include/dpcd_defs.h:32:2: note: in 
expansion of macro 'DPCD_REV_10'
 DPCD_REV_10 = 0x10,
 ^~~
--
   In file included from 
drivers/gpu//drm/amd/amdgpu/../display/include/dpcd_defs.h:29:0,
from 
drivers/gpu//drm/amd/amdgpu/../display/dc/core/dc_link.c:42:
>> include/drm/drm_dp_helper.h:67:45: error: expected identifier before numeric 
>> constant
# define DPCD_REV_100x10
^
   drivers/gpu//drm/amd/amdgpu/../display/include/dpcd_defs.h:32:2: note: in 
expansion of macro 'DPCD_REV_10'
 DPCD_REV_10 = 0x10,
 ^~~

vim +67 include/drm/drm_dp_helper.h

63  
64  /* AUX CH addresses */
65  /* DPCD */
66  #define DP_DPCD_REV 0x000
  > 67  # define DPCD_REV_100x10
68  # define DPCD_REV_110x11
69  # define DPCD_REV_120x12
70  # define DPCD_REV_130x13
71  # define DPCD_REV_140x14
72  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Preferring cursor plane over overlay plane

[Joonas Kylmälä]

Hi DRM subsystem developers,

I ran into this patch where overlay plane was switched to cursor plane
because there was no proper cursor plane available on the display
hardware: . Can we discuss whether
to have a policy of using a normal plane for cursor plane in case a
dedicated HW cursor plane is missing?

Daniel Vetter suggests that it might be fine to use normal plane for
cursor plane because how to use the plane would be only "a hint to
userspace" (see the email linked).

My motivation for having this discussion is that the newer Allwinner
SoCs don't have dedicated HW cursor plane and the sun4i DRM driver
currently uses the extra planes as overlay planes which makes moving the
cursor on Xfce4 DE a terrible experience. To have better cursor moving
experience one overlay plane would need to be sacrificed.

Also, I probably missed some recipients for this email so please forward
it to the recipients you think might be interested about this.

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

[PATCH v2 4/5] drm: bridge: lvds-encoder: allow specifying the input bus format

[Peter Rosin]

If the bridge changes the bus format, allow this to be described in
the bridge, instead of providing false information about the bus
format of the connector or panel.

Signed-off-by: Peter Rosin 
---
 .../bindings/display/bridge/lvds-transmitter.txt   |  6 ++
 drivers/gpu/drm/bridge/lvds-encoder.c  | 25 ++
 2 files changed, 31 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt 
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index 50220190c203..8d40a2069252 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -30,6 +30,12 @@ Required properties:
   device-specific version corresponding to the device first
   followed by the generic version.
 
+Optional properties:
+
+- interface-pix-fmt:
+  List of valid input bus formats of the encoder. Recognized bus formats
+  are listed in ../bus-format.txt
+
 Required nodes:
 
 This device has two video ports. Their connections are modeled using the OF
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c 
b/drivers/gpu/drm/bridge/lvds-encoder.c
index 75b0d3f6e4de..b78619b5560a 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -16,6 +17,8 @@
 struct lvds_encoder {
struct drm_bridge bridge;
struct drm_bridge *panel_bridge;
+   int num_bus_formats;
+   u32 *bus_formats;
 };
 
 static int lvds_encoder_attach(struct drm_bridge *bridge)
@@ -28,8 +31,22 @@ static int lvds_encoder_attach(struct drm_bridge *bridge)
 bridge);
 }
 
+static int lvds_encoder_input_formats(struct drm_bridge *bridge,
+ const u32 **bus_formats)
+{
+   struct lvds_encoder *lvds_encoder = container_of(bridge,
+struct lvds_encoder,
+bridge);
+
+   if (lvds_encoder->num_bus_formats)
+   *bus_formats = lvds_encoder->bus_formats;
+
+   return lvds_encoder->num_bus_formats;
+}
+
 static struct drm_bridge_funcs funcs = {
.attach = lvds_encoder_attach,
+   .input_formats = lvds_encoder_input_formats,
 };
 
 static int lvds_encoder_probe(struct platform_device *pdev)
@@ -39,6 +56,7 @@ static int lvds_encoder_probe(struct platform_device *pdev)
struct device_node *panel_node;
struct drm_panel *panel;
struct lvds_encoder *lvds_encoder;
+   int ret;
 
lvds_encoder = devm_kzalloc(&pdev->dev, sizeof(*lvds_encoder),
GFP_KERNEL);
@@ -79,6 +97,12 @@ static int lvds_encoder_probe(struct platform_device *pdev)
if (IS_ERR(lvds_encoder->panel_bridge))
return PTR_ERR(lvds_encoder->panel_bridge);
 
+   ret = drm_of_bus_formats(pdev->dev.of_node, "interface-pix-fmt",
+&lvds_encoder->bus_formats);
+   if (ret < 0)
+   return ret;
+   lvds_encoder->num_bus_formats = ret;
+
/* The panel_bridge bridge is attached to the panel's of_node,
 * but we need a bridge attached to our of_node for our user
 * to look up.
@@ -96,6 +120,7 @@ static int lvds_encoder_remove(struct platform_device *pdev)
 {
struct lvds_encoder *lvds_encoder = platform_get_drvdata(pdev);
 
+   kfree(lvds_encoder->bus_formats);
drm_bridge_remove(&lvds_encoder->bridge);
 
return 0;
-- 
2.11.0

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

[PATCH] drm/atmel-hlcdc: add command line option to specify preferred depth

[Peter Rosin]

I have an sama5d31-based system with 64MB of memory and a 1920x1080
LVDS display wired for 16-bpp. When I enable legacy fbdev support,
the contiguous memory allocator invariably fails with the order-11
allocation for a 1920x1080@24-bpp buffer (~6MB). But this HW can never
make any good use of RGB888, so that is a wasted attempt anyway that
would also waste precious memory should it succeed.

Sure, I could rewrite user-space to go directly to KMS etc, and that
makes the (attempted) order-11 allocation go away, replacing it with
one order-10 allocation per application restart for a 1920x1080@16-bpp
buffer (<4MB). But after a few restarts, order-10 allocations start to
fail as well, which is only to be expected AFAIU.

So, I'd rather not change user-space (which was originally written
to target a smaller display) so that I at the same time get the
benefit of an early pre-allocated fbdev frame-buffer that can be
reused over and over. But to do that I need to tell the driver that
16-bpp is the preferred depth. Add a module parameter to do just that.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

I found some inspiration regarding naming and implementation here:
https://patchwork.kernel.org/patch/9848631/

I have found no feedback on that patch though, which makes me wonder if
I'm perhaps barking up the wronig tree?

Cheers,
Peter

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index c1ea5c36b006..f0148627c221 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -29,6 +29,11 @@
 
 #define ATMEL_HLCDC_LAYER_IRQS_OFFSET  8
 
+static int atmel_hlcdc_preferred_depth __read_mostly;
+
+MODULE_PARM_DESC(preferreddepth, "Set preferred bpp");
+module_param_named(preferreddepth, atmel_hlcdc_preferred_depth, int, 0400);
+
 static const struct atmel_hlcdc_layer_desc atmel_hlcdc_at91sam9n12_layers[] = {
{
.name = "base",
@@ -590,6 +595,7 @@ static int atmel_hlcdc_dc_modeset_init(struct drm_device 
*dev)
dev->mode_config.min_height = dc->desc->min_height;
dev->mode_config.max_width = dc->desc->max_width;
dev->mode_config.max_height = dc->desc->max_height;
+   dev->mode_config.preferred_depth = 24;
dev->mode_config.funcs = &mode_config_funcs;
 
return 0;
@@ -658,7 +664,7 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
 
platform_set_drvdata(pdev, dev);
 
-   drm_fb_cma_fbdev_init(dev, 24, 0);
+   drm_fb_cma_fbdev_init(dev, atmel_hlcdc_preferred_depth, 0);
 
drm_kms_helper_poll_init(dev);
 
@@ -756,6 +762,16 @@ static int atmel_hlcdc_dc_drm_probe(struct platform_device 
*pdev)
struct drm_device *ddev;
int ret;
 
+   switch (atmel_hlcdc_preferred_depth) {
+   case 0: /* driver default */
+   case 8:
+   case 16:
+   case 24:
+   break;
+   default:
+   return -EINVAL;
+   }
+
ddev = drm_dev_alloc(&atmel_hlcdc_dc_driver, &pdev->dev);
if (IS_ERR(ddev))
return PTR_ERR(ddev);
-- 
2.11.0

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

Re: [PATCH] gpu: host1x: Fix compiler errors

[Emil Goode]

Hello,

On Mon, Mar 26, 2018 at 04:57:34PM +0200, Thierry Reding wrote:
> On Mon, Mar 26, 2018 at 04:44:14PM +0200, Emil Goode wrote:
> > The compiler is complaining with the following errors:
> > 
> > drivers/gpu/host1x/cdma.c:94:48: error:
> > passing argument 3 of ‘dma_alloc_wc’ from incompatible pointer type
> > [-Werror=incompatible-pointer-types]
> > 
> > drivers/gpu/host1x/cdma.c:113:48: error:
> > passing argument 3 of ‘dma_alloc_wc’ from incompatible pointer type
> > [-Werror=incompatible-pointer-types]
> > 
> > The expected pointer type of the third argument to dma_alloc_wc() is
> > dma_addr_t but phys_addr_t is passed. Fix this by adding casts to the
> > expected pointer type.
> > 
> > Signed-off-by: Emil Goode 
> > ---
> >  drivers/gpu/host1x/cdma.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> What compiler do you use? I do regular builds and check for warnings and
> errors, and this one is new to me.
> 
> Thierry
>

I use gcc version 6.3.0 cross compiler for armhf supplied with Debian Stretch.

Best regards,

Emil

> > 
> > diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
> > index 28541b280739..5e8b321a751e 100644
> > --- a/drivers/gpu/host1x/cdma.c
> > +++ b/drivers/gpu/host1x/cdma.c
> > @@ -91,8 +91,8 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
> >  
> > size = iova_align(&host1x->iova, size);
> >  
> > -   pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
> > - GFP_KERNEL);
> > +   pb->mapped = dma_alloc_wc(host1x->dev, size,
> > + (dma_addr_t *)&pb->phys, GFP_KERNEL);
> > if (!pb->mapped)
> > return -ENOMEM;
> >  
> > @@ -110,8 +110,8 @@ static int host1x_pushbuffer_init(struct push_buffer 
> > *pb)
> > if (err)
> > goto iommu_free_iova;
> > } else {
> > -   pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
> > - GFP_KERNEL);
> > +   pb->mapped = dma_alloc_wc(host1x->dev, size,
> > + (dma_addr_t *)&pb->phys, GFP_KERNEL);
> > if (!pb->mapped)
> > return -ENOMEM;
> >  
> > -- 
> > 2.11.0
> > 


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

Re: [PATCH v6] ARM: dts: wheat: Fix ADV7513 address usage

[Simon Horman]

On Mon, Mar 26, 2018 at 10:04:24AM +0100, Kieran Bingham wrote:
> Hi Simon,
> 
> On 26/03/18 09:31, Simon Horman wrote:
> > On Fri, Mar 23, 2018 at 09:16:13PM +, Kieran Bingham wrote:
> >> Hi Simon,
> >>
> >> On 23/03/18 08:51, Simon Horman wrote:
> >>> On Thu, Mar 22, 2018 at 09:30:40PM +, Kieran Bingham wrote:
>  The r8a7792 Wheat board has two ADV7513 devices sharing a single I2C
>  bus, however in low power mode the ADV7513 will reset it's slave maps to
>  use the hardware defined default addresses.
> 
>  The ADV7511 driver was adapted to allow the two devices to be registered
>  correctly - but it did not take into account the fault whereby the
>  devices reset the addresses.
> 
>  This results in an address conflict between the device using the default
>  addresses, and the other device if it is in low-power-mode.
> 
>  Repair this issue by moving both devices away from the default address
>  definitions.
> >>>
> >>> Hi Kierean,
> >>>
> >>> as this is a fix
> >>> a) Does it warrant a fixes tag?
> >>>Fixes: f6eea82a87db ("ARM: dts: wheat: add DU support")
> >>> b) Does it warrant being posted as a fix for v4.16;
> >>> c) or v4.17?
> >>
> >> Tricky one, yes it could but this DTS fix, will only actually 'fix' the 
> >> issue if
> >> the corresponding driver updates to allow secondary addresses to be parsed 
> >> are
> >> also backported.
> >>
> >> It should be safe to back port the dts fix without the driver updates, but 
> >> the
> >> addresses specified by this patch will simply be ignored.
> > 
> > In that case I think its safe to add the fixes tag and take the DTS patch
> > via the renesas tree. Perhaps applying it for v4.18 and allowing automatic
> > backporting to take its course is the cleanest option.
> > 
> >> Thus if this is marked with the fixes tag the corresponding patch "drm: 
> >> adv7511:
> >> Add support for i2c_new_secondary_device" should also be marked.
> >>
> >> It looks like that patch has yet to be picked up by the DRM subsystem, so 
> >> how
> >> about I bundle both of these two patches together in a repost along with 
> >> the
> >> fixes tag.
> >>
> >> In fact, I don't think the ADV7511 dt-bindings update has made any progress
> >> either. (dt-bindings: adv7511: Extend bindings to allow specifying slave 
> >> map
> >> addresses). The media tree variants for the adv7604 have already been 
> >> picked up
> >> by Mauro I believe though.
> >>
> >> I presume it would be acceptable for this dts patch (or rather all three 
> >> patches
> >> mentioned) to get integrated through the DRM tree ?
> > 
> > Unless there is a strong reason I would prefer the dts patch to go via
> > my tree. The reason is to avoid merge conflicts bubbling up to Linus,
> > which really is something best avoided.
> 
> That's perfectly fine with me.
> 
> Feel free to add:
> 
> Fixes: f6eea82a87db ("ARM: dts: wheat: add DU support")
> 
> as you suggested when you apply, or alternatively let me know if you need a 
> repost.

Thanks, applied for v4.18 with the fixes tag.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/5] drm: bridge: add API to query the expected input formats of bridges

[Peter Rosin]

Bridges may affect the required bus output format of the encoder, in
which case it may be wrong to use the output format of the panel or
connector as is. Add infrastructure to address this problem.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/drm_bridge.c | 32 
 include/drm/drm_bridge.h | 18 ++
 2 files changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 1638bfe9627c..f85e61b7416e 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -348,6 +348,38 @@ void drm_bridge_enable(struct drm_bridge *bridge)
 }
 EXPORT_SYMBOL(drm_bridge_enable);
 
+/**
+ * drm_bridge_input_formats - get the expected bus input format of the bridge
+ * @bridge: bridge control structure
+ * @bus_formats: where to store a pointer to the bus input formats
+ *
+ * Calls the &drm_bridge_funcs.input_formats op for the frist bridge in the
+ * chain that has registered this op.
+ *
+ * Note that the bridge passed should normally be the bridge closest to the
+ * encoder, but possibly the bridge closest to an intermediate bridge in
+ * convoluted cases.
+ *
+ * RETURNS:
+ * The number of bus input formats the bridge accepts. Zero means that
+ * the chain of bridges are not converting the bus format and that the
+ * format of the drm_connector should be used.
+ */
+int drm_bridge_input_formats(struct drm_bridge *bridge,
+const u32 **bus_formats)
+{
+   int ret = 0;
+
+   if (!bridge)
+   return 0;
+
+   if (bridge->funcs->input_formats)
+   ret = bridge->funcs->input_formats(bridge, bus_formats);
+
+   return ret ?: drm_bridge_input_formats(bridge->next, bus_formats);
+}
+EXPORT_SYMBOL(drm_bridge_input_formats);
+
 #ifdef CONFIG_OF
 /**
  * of_drm_find_bridge - find the bridge corresponding to the device node in
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 682d01ba920c..ae8d3c4af0b8 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -220,6 +220,22 @@ struct drm_bridge_funcs {
 * The enable callback is optional.
 */
void (*enable)(struct drm_bridge *bridge);
+
+   /**
+* @input_formats:
+*
+* The callback reports the expected bus input formats of the bridge.
+*
+* The @input_formats callback is optional. The bridge is assumed to
+* not convert the bus format if the callback is not installed.
+*
+* RETURNS:
+*
+* Zero if the bridge does not convert the bus format, otherwise the
+* number of bus input formats returned in &bus_formats.
+*/
+   int (*input_formats)(struct drm_bridge *bridge,
+const u32 **bus_formats);
 };
 
 /**
@@ -263,6 +279,8 @@ void drm_bridge_mode_set(struct drm_bridge *bridge,
struct drm_display_mode *adjusted_mode);
 void drm_bridge_pre_enable(struct drm_bridge *bridge);
 void drm_bridge_enable(struct drm_bridge *bridge);
+int drm_bridge_input_formats(struct drm_bridge *bridge,
+const u32 **bus_formats);
 
 #ifdef CONFIG_DRM_PANEL_BRIDGE
 struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
-- 
2.11.0

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

[PATCH] drm/mxsfb: add poll_changed event handler to set_par on startup

[Michael Grzeschik]

We move drm_kms_helper_poll_init behind the drm_fbdev_cma_init so the
set_par will be called and fb will be active.

Signed-off-by: Michael Grzeschik 
---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 1207ffe362505..a047a729af6b8 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -94,6 +94,7 @@ void mxsfb_disable_axi_clk(struct mxsfb_drm_private *mxsfb)
 
 static const struct drm_mode_config_funcs mxsfb_mode_config_funcs = {
.fb_create  = drm_gem_fb_create,
+   .output_poll_changed= drm_fb_helper_output_poll_changed,
.atomic_check   = drm_atomic_helper_check,
.atomic_commit  = drm_atomic_helper_commit,
 };
@@ -221,8 +222,6 @@ static int mxsfb_load(struct drm_device *drm, unsigned long 
flags)
goto err_irq;
}
 
-   drm_kms_helper_poll_init(drm);
-
mxsfb->fbdev = drm_fbdev_cma_init(drm, 32,
  drm->mode_config.num_connector);
if (IS_ERR(mxsfb->fbdev)) {
@@ -232,6 +231,8 @@ static int mxsfb_load(struct drm_device *drm, unsigned long 
flags)
goto err_cma;
}
 
+   drm_kms_helper_poll_init(drm);
+
platform_set_drvdata(pdev, drm);
 
drm_helper_hpd_irq_event(drm);
-- 
2.16.1

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

[PATCH v2 0/5] allow override of bus format in bridges

[Peter Rosin]

Hi!

[I got to v2 sooner than expected]

I have an Atmel sama5d31 hooked up to an lvds encoder and then
on to an lvds panel. Which seems like something that has been
done one or two times before...

The problem is that the bus_format of the SoC and the panel do
not agree. The SoC driver (atmel-hlcdc) can handle the
rgb444, rgb565, rgb666 and rgb888 bus formats. The hardware is
wired for the rgb565 case. The lvds encoder supports rgb888 on
its input side with the LSB wires for each color simply pulled
down internally in the encoder in my case which means that the
rgb565 bus_format is the format that works best. And the panel
is expecting lvds (vesa-24), which is what the encoder outputs.

The reason I "blame" the bus_format of the drm_connector is that
with the below DT snippet, things do not work *exactly* due to
that. At least, it starts to work if I hack the panel-lvds driver
to report the rgb565 bus_format instead of vesa-24.

panel: panel {
compatible = "panel-lvds";

width-mm = <304>;
height-mm = <228;

data-mapping = "vesa-24";

panel-timing {
// 1024x768 @ 60Hz (typical)
clock-frequency = <5214 6500 7110>;
hactive = <1024>;
vactive = <768>;
hfront-porch = <48 88 88>;
hback-porch = <96 168 168>;
hsync-len = <32 64 64>;
vfront-porch = <8 13 14>;
vback-porch = <8 13 14>;
vsync-len = <8 12 14>;
};

port {
panel_input: endpoint {
remote-endpoint = <&lvds_encoder_output>;
};
};
};

lvds-encoder {
compatible = "ti,ds90c185", "lvds-encoder";

ports {
#address-cells = <1>;
#size-cells = <0>;

port@0 {
reg = <0>;

lvds_encoder_input: endpoint {
remote-endpoint = <&hlcdc_output>;
};
};

port@1 {
reg = <1>;

lvds_encoder_output: endpoint {
remote-endpoint = <&panel_input>;
};
};
};
};

But, instead of perverting the panel-lvds driver with support
for a totally fake non-lvds bus_format, I intruduce an API that allows
display controller drivers to query the required bus_format of any
intermediate bridges, and match up with that instead of the formats
given by the drm_connector. I trigger this with this addition to the
lvds-encoder DT node:

interface-pix-fmt = "rgb565";

Naming is hard though, so I'm not sure if that's good?

I threw in the first patch, since that is the actual lvds encoder
I have in this case.

Suggestions welcome.

Cheers,
Peter

Changes since v1 https://lkml.org/lkml/2018/3/17/221
- Add a proper bridge API to query the bus_format instead of abusing
  the ->get_modes part of the code. This is cleaner but requires
  changes to all display controller drivers wishing to participate.
- Add patch to adjust the atmel-hlcdc driver according to the above.
- Hook the new info into the bridge local to the lvds-encoder instead
  of messing about with new interfaces for the panel-bridge driver.
- Add patch with a DT parsing function of bus_formats in a central place.
- Rephrase the addition of ti,ds90c185 to the lvds-transmitter binding.

Peter Rosin (5):
  dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185
  drm: bridge: add API to query the expected input formats of bridges
  drm: of: add display bus-format parser
  drm: bridge: lvds-encoder: allow specifying the input bus format
  drm/atmel-hlcdc: take bridges into account when selecting output
format

 .../bindings/display/bridge/lvds-transmitter.txt   | 14 -
 .../devicetree/bindings/display/bus-format.txt | 35 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 49 --
 drivers/gpu/drm/bridge/lvds-encoder.c  | 25 +
 drivers/gpu/drm/drm_bridge.c   | 32 
 drivers/gpu/drm/drm_of.c   | 59 ++
 include/drm/drm_bridge.h   | 18 +++
 include/drm/drm_of.h   |  9 
 8 files changed, 237 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/bus-format.txt

-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.o

Re: [PATCH] drm/mxsfb: add poll_changed event handler to set_par on startup

[Michael Grzeschik]

On Mon, Mar 26, 2018 at 06:17:44PM +0200, Michael Grzeschik wrote:
> We move drm_kms_helper_poll_init behind the drm_fbdev_cma_init so the
> set_par will be called and fb will be active.
> 

As this commit message is not very informative and digging deeper into
the stubs I came up with another Idea.

By default drm_kms_helper_hotplug_event could call
drm_fb_helper_output_poll_changed if no other output_poll_changed was
registered.

I will send another patch.

> Signed-off-by: Michael Grzeschik 
> ---
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 1207ffe362505..a047a729af6b8 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -94,6 +94,7 @@ void mxsfb_disable_axi_clk(struct mxsfb_drm_private *mxsfb)
>  
>  static const struct drm_mode_config_funcs mxsfb_mode_config_funcs = {
>   .fb_create  = drm_gem_fb_create,
> + .output_poll_changed= drm_fb_helper_output_poll_changed,
>   .atomic_check   = drm_atomic_helper_check,
>   .atomic_commit  = drm_atomic_helper_commit,
>  };
> @@ -221,8 +222,6 @@ static int mxsfb_load(struct drm_device *drm, unsigned 
> long flags)
>   goto err_irq;
>   }
>  
> - drm_kms_helper_poll_init(drm);
> -
>   mxsfb->fbdev = drm_fbdev_cma_init(drm, 32,
> drm->mode_config.num_connector);
>   if (IS_ERR(mxsfb->fbdev)) {
> @@ -232,6 +231,8 @@ static int mxsfb_load(struct drm_device *drm, unsigned 
> long flags)
>   goto err_cma;
>   }
>  
> + drm_kms_helper_poll_init(drm);
> +
>   platform_set_drvdata(pdev, drm);
>  
>   drm_helper_hpd_irq_event(drm);
> -- 
> 2.16.1
> 
> 
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


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

Re: [PATCH v2 4/5] drm: bridge: lvds-encoder: allow specifying the input bus format

[Peter Rosin]

Hi Jacopo,

Thanks for you feedback!

On 2018-03-27 12:27, jacopo mondi wrote:
> Hi Peter, Laurent,
>thanks for the patches,
> 
> On Mon, Mar 26, 2018 at 11:24:46PM +0200, Peter Rosin wrote:
>> If the bridge changes the bus format, allow this to be described in
>> the bridge, instead of providing false information about the bus
>> format of the connector or panel.
>>
>> Signed-off-by: Peter Rosin 
>> ---
>>  .../bindings/display/bridge/lvds-transmitter.txt   |  6 ++
>>  drivers/gpu/drm/bridge/lvds-encoder.c  | 25 
>> ++
>>  2 files changed, 31 insertions(+)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt 
>> b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
>> index 50220190c203..8d40a2069252 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
>> @@ -30,6 +30,12 @@ Required properties:
>>device-specific version corresponding to the device first
>>followed by the generic version.
>>
>> +Optional properties:
>> +
>> +- interface-pix-fmt:
>> +  List of valid input bus formats of the encoder. Recognized bus formats
>> +  are listed in ../bus-format.txt
>> +
> 
> This comments applies here and to [3/5] as well.

I'm not sure how the below comments apply to [3/5]? I guess you are
suggesting that [3/5] should be dropped?

> Are we sure we want the supported bridge input format defined in DT
> bindings?

Yes, I'm pretty sure. In my case, it has to be specified manually
*somewhere* (at least I think it has to, but what do I know?). The
bridge is the best position, if you ask me.

> Again, I may be biased, but as I see this, each bridge driver should
> list its supported formats with MEDIA_BUS_FMT_ fourcc codes and return
> the currently 'active' one when requested by the preceding bridge.

In my case this is not possible, the bridge supports maximum rgb888
input, but since it cannot know how much of that is actually wired,
the actual format needs to be provided manually somewhere. In my
case, I know that I want to send rgb565 to the bridge. Sure, the
wiring between the encoder and the bridge chip could be seen as
another "bridge" that goes from rgb565 to rgb888, but adding some
extra layer to the model for this step seems like over-engineering
to me. Especially when the binding for the generic lvds-transmitter
bridge needs to specify the input format anyway. At least, that's
the right thing to do if you ask me. How else should it know what
format to request?

> I understand for this driver, being compatible with both a generic lvds
> encoder and a specific chip, the supported input formats are
> different, but I would have used the 'of_device_id.data' field for
> this and leave this out from DT bindings.

No, the lvds-transmitter accepts parallel input and spits out lvds,
just like the specific chip I'm using. I do not *need* to specify the
specific chip, and the driver does nothing special for it. It is just
good practice to specify the details when they are readily available.

> This makes the translation routine here implemented not required if
> I'm not wrong...

I think you are.

Cheers,
Peter

> Thanks
>j
> 
>>  Required nodes:
>>
>>  This device has two video ports. Their connections are modeled using the OF
>> diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c 
>> b/drivers/gpu/drm/bridge/lvds-encoder.c
>> index 75b0d3f6e4de..b78619b5560a 100644
>> --- a/drivers/gpu/drm/bridge/lvds-encoder.c
>> +++ b/drivers/gpu/drm/bridge/lvds-encoder.c
>> @@ -9,6 +9,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>>  #include 
>> @@ -16,6 +17,8 @@
>>  struct lvds_encoder {
>>  struct drm_bridge bridge;
>>  struct drm_bridge *panel_bridge;
>> +int num_bus_formats;
>> +u32 *bus_formats;
>>  };
>>
>>  static int lvds_encoder_attach(struct drm_bridge *bridge)
>> @@ -28,8 +31,22 @@ static int lvds_encoder_attach(struct drm_bridge *bridge)
>>   bridge);
>>  }
>>
>> +static int lvds_encoder_input_formats(struct drm_bridge *bridge,
>> +  const u32 **bus_formats)
>> +{
>> +struct lvds_encoder *lvds_encoder = container_of(bridge,
>> + struct lvds_encoder,
>> + bridge);
>> +
>> +if (lvds_encoder->num_bus_formats)
>> +*bus_formats = lvds_encoder->bus_formats;
>> +
>> +return lvds_encoder->num_bus_formats;
>> +}
>> +
>>  static struct drm_bridge_funcs funcs = {
>>  .attach = lvds_encoder_attach,
>> +.input_formats = lvds_encoder_input_formats,
>>  };
>>
>>  static int lvds_encoder_probe(struct platform_device *pdev)
>> @@ -39,6 +56,7 @@ static int lvds_encoder_probe(struct platform_device *pdev)
>>  struct device_node *panel_node;
>>  struct drm_panel *panel;
>>  struc

Re: [PATCH v2 2/5] drm: bridge: add API to query the expected input formats of bridges

[Peter Rosin]

Hi Jacopo,

Thanks for the feedback!

On 2018-03-27 11:47, jacopo mondi wrote:
> Hi Peter,
>thanks for the patches
> 
> On Mon, Mar 26, 2018 at 11:24:44PM +0200, Peter Rosin wrote:
>> Bridges may affect the required bus output format of the encoder, in
>> which case it may be wrong to use the output format of the panel or
>> connector as is. Add infrastructure to address this problem.
> 
> Bridges not only affect the format expected by the connector at the
> end of the display pipeline, they may perform encoding/decoding
> between protocols and their accepted input formats may be unrelated to
> the connector at the end of the pipeline as there may an arbitrary
> number of bridges in between.
> 
> Eg.
> 
> ENCODERCONNECTOR
>   | |
> |DU LVDS| ->lvds-> |THC63| ->rgb-> |ADV7511| ->hdmi-> |HDMI connector|
> 
> The fact that THC63 wants a specific LVDS input format is unrelated to
> the format required by the HDMI connector at the end of the pipeline.
> 
> I would just state here that bridges need a way to report their
> accepted media bus formats, and this patch extends the DRM Bridge APIs
> to implement that.

Yes, I can add some words, but I would like to clear up the naming
before re-spinning.

>>
>> Signed-off-by: Peter Rosin 
>> ---
>>  drivers/gpu/drm/drm_bridge.c | 32 
>>  include/drm/drm_bridge.h | 18 ++
>>  2 files changed, 50 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>> index 1638bfe9627c..f85e61b7416e 100644
>> --- a/drivers/gpu/drm/drm_bridge.c
>> +++ b/drivers/gpu/drm/drm_bridge.c
>> @@ -348,6 +348,38 @@ void drm_bridge_enable(struct drm_bridge *bridge)
>>  }
>>  EXPORT_SYMBOL(drm_bridge_enable);
>>
>> +/**
>> + * drm_bridge_input_formats - get the expected bus input format of the 
>> bridge
> 
> I may be biased by the V4L2 APIs, but this seems to me very much like
> similar to g_fmt/s_fmt callbacks we have there. Bridges have an input and

g_fmt/s_fmt says nothing to me. Graphics format? Source Format? I have
no idea if those guesses are even close? So, that seems like poor naming
to me. The only reason I see to go that way is for the sake of consistency.

> an output formats, and that calls for something that takes that into
> account, as well as they may have different input ports with different
> accepted formats but I would for now simplify this to just 'g_fmt()'

You mean rename the function to drm_bridge_g_fmt(), right?

As indicated above, I'm not that fond of it, but don't really care
either. Maintainers?

>> + * @bridge: bridge control structure
>> + * @bus_formats: where to store a pointer to the bus input formats
>> + *
>> + * Calls the &drm_bridge_funcs.input_formats op for the frist bridge in the
>> + * chain that has registered this op.
> 
> I'm not sure passing the call down the pipeline is desirable. Each
> component should make sure its output format is accepted as the next
> bridge input format, passing the call to the next bridge is not
> different that getting to the connector at the end of the pipeline and
> return to the initial caller its supported format. Do you agree with this?

Not passing down the call does one of two things. Either all bridges have
to implement the call or all users have to walk the pipeline "manually".
I don't like either or those options, so I still think it is good to
pass the call down the pipeline.

*time passes*

Oh, you do not think it is useful for the bridge to have a callback but
still report "no format change", and that the call down to pipeline
should only happen for bridges that have not implemented the op. But I
do think that is useful, see below.

>> + *
>> + * Note that the bridge passed should normally be the bridge closest to the
>> + * encoder, but possibly the bridge closest to an intermediate bridge in
>> + * convoluted cases.
>> + *
> 
> As I see this, any bridge in the arbitrary long pipeline should call
> this operation on next bridge if it supports different output formats.
> Ie. I would not name here the encoder nor refer to the bridge position
> in the pipeline.

Ok, I can change that, it just seemed like a convoluted case to me.
I mean, if this was a real issue and complicated pipelines were
common, something along the lines of this patch series would be
available already. Right? I guess not, but how the &#/%# have people
been coping?

>> + * RETURNS:
>> + * The number of bus input formats the bridge accepts. Zero means that
>> + * the chain of bridges are not converting the bus format and that the
>> + * format of the drm_connector should be used.
> 
> How do we get to the connector format from a bridge that has maybe
> other components in between in the pipeline?
> 
> If a bridge do not report any supported format, it won't implement
> this callback and things will work as they work today.

Unless the bridge optiona

Re: [PATCH v6] ARM: dts: wheat: Fix ADV7513 address usage

[Simon Horman]

On Fri, Mar 23, 2018 at 09:16:13PM +, Kieran Bingham wrote:
> Hi Simon,
> 
> On 23/03/18 08:51, Simon Horman wrote:
> > On Thu, Mar 22, 2018 at 09:30:40PM +, Kieran Bingham wrote:
> >> The r8a7792 Wheat board has two ADV7513 devices sharing a single I2C
> >> bus, however in low power mode the ADV7513 will reset it's slave maps to
> >> use the hardware defined default addresses.
> >>
> >> The ADV7511 driver was adapted to allow the two devices to be registered
> >> correctly - but it did not take into account the fault whereby the
> >> devices reset the addresses.
> >>
> >> This results in an address conflict between the device using the default
> >> addresses, and the other device if it is in low-power-mode.
> >>
> >> Repair this issue by moving both devices away from the default address
> >> definitions.
> > 
> > Hi Kierean,
> > 
> > as this is a fix
> > a) Does it warrant a fixes tag?
> >Fixes: f6eea82a87db ("ARM: dts: wheat: add DU support")
> > b) Does it warrant being posted as a fix for v4.16;
> > c) or v4.17?
> 
> Tricky one, yes it could but this DTS fix, will only actually 'fix' the issue 
> if
> the corresponding driver updates to allow secondary addresses to be parsed are
> also backported.
> 
> It should be safe to back port the dts fix without the driver updates, but the
> addresses specified by this patch will simply be ignored.

In that case I think its safe to add the fixes tag and take the DTS patch
via the renesas tree. Perhaps applying it for v4.18 and allowing automatic
backporting to take its course is the cleanest option.

> Thus if this is marked with the fixes tag the corresponding patch "drm: 
> adv7511:
> Add support for i2c_new_secondary_device" should also be marked.
> 
> It looks like that patch has yet to be picked up by the DRM subsystem, so how
> about I bundle both of these two patches together in a repost along with the
> fixes tag.
> 
> In fact, I don't think the ADV7511 dt-bindings update has made any progress
> either. (dt-bindings: adv7511: Extend bindings to allow specifying slave map
> addresses). The media tree variants for the adv7604 have already been picked 
> up
> by Mauro I believe though.
> 
> I presume it would be acceptable for this dts patch (or rather all three 
> patches
> mentioned) to get integrated through the DRM tree ?

Unless there is a strong reason I would prefer the dts patch to go via
my tree. The reason is to avoid merge conflicts bubbling up to Linus,
which really is something best avoided.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/5] dt-bindings: display: bridge: lvds-transmitter: add ti, ds90c185

[Peter Rosin]

Start list of actual chips compatible with "lvds-encoder".

Signed-off-by: Peter Rosin 
---
 .../devicetree/bindings/display/bridge/lvds-transmitter.txt   | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt 
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index fd39ad34c383..50220190c203 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -22,7 +22,13 @@ among others.
 
 Required properties:
 
-- compatible: Must be "lvds-encoder"
+- compatible: Must be one or more of the following
+  - "ti,ds90c185" for the TI DS90C185 FPD-Link Serializer
+  - "lvds-encoder" for a generic LVDS encoder device
+
+  When compatible with the generic version, nodes must list the
+  device-specific version corresponding to the device first
+  followed by the generic version.
 
 Required nodes:
 
-- 
2.11.0

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

[PATCH v2 3/5] drm: of: add display bus-format parser

[Peter Rosin]

Add a common API to parse display bus format strings into fourcc codes.

Signed-off-by: Peter Rosin 
---
 .../devicetree/bindings/display/bus-format.txt | 35 +
 drivers/gpu/drm/drm_of.c   | 59 ++
 include/drm/drm_of.h   |  9 
 3 files changed, 103 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bus-format.txt

diff --git a/Documentation/devicetree/bindings/display/bus-format.txt 
b/Documentation/devicetree/bindings/display/bus-format.txt
new file mode 100644
index ..590e6c73f3dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bus-format.txt
@@ -0,0 +1,35 @@
+Bus formats in the display pipe
+===
+
+Various encoders in display controllers output the pixels in different
+formats. Circuits handling display connectors and hardwired panels also
+expect pixel input in various formats. We call these formats bus formats.
+
+Some bus formats are:
+
+Parallel
+
+
+rgb888
+   8 parallel lines for red, green and blue respectively. There are
+   also lines for the pixel-clock, horizontal-sync, vertical-sync
+   and data-enable.
+
+rgb666
+   Same as rgb888, but with 6 lines per color.
+
+rgb565
+   Same as rgb888, but with 6 green lines and 5 red and blue lines.
+
+rgb444
+   Same as rgb888, but with 4 lines per color.
+
+
+LVDS
+
+
+jeida-18
+jeida-24
+vesa-24
+   These are LVDS bus formats, see the data-mapping property in
+   panel/panel-lvds.txt for a description of these bus formats.
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 4c191c050e7d..5f65471225bb 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -262,3 +262,62 @@ int drm_of_find_panel_or_bridge(const struct device_node 
*np,
return ret;
 }
 EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
+
+/*
+ * drm_of_bus_formats - parse list of bus format strings into drm fourcc
+ * @np: device tree node containing bus format property
+ * @propname: name of bus format property
+ * @bus_formats: array of parsed fourcc codes
+ *
+ * On success, @bus_formats points to a location where the actual drm
+ * fourcc codes are.
+ * WARNING: The caller is responsible for freeing this memory with kfree.
+ *
+ * Returns the number of parsed bus format entries, or one of the standard
+ * error codes on failure.
+ */
+int drm_of_bus_formats(const struct device_node *np, const char *propname,
+  u32 **bus_formats)
+{
+   int num_bus_formats = of_property_count_strings(np, propname);
+   const char *fmt;
+   int ret;
+   int i;
+
+   if (num_bus_formats <= 0)
+   return num_bus_formats;
+
+   *bus_formats = kmalloc(num_bus_formats * sizeof(**bus_formats),
+  GFP_KERNEL);
+   if (!*bus_formats)
+   return -ENOMEM;
+
+   for (i = 0; i < num_bus_formats; ++i) {
+   ret = of_property_read_string_index(np, propname, i, &fmt);
+   if (ret < 0)
+   return ret;
+
+   if (!strcmp(fmt, "rgb444")) {
+   *bus_formats[i] = MEDIA_BUS_FMT_RGB444_1X12;
+   } else if (!strcmp(fmt, "rgb565")) {
+   *bus_formats[i] = MEDIA_BUS_FMT_RGB565_1X16;
+   } else if (!strcmp(fmt, "rgb666")) {
+   *bus_formats[i] = MEDIA_BUS_FMT_RGB666_1X18;
+   } else if (!strcmp(fmt, "rgb888")) {
+   *bus_formats[i] = MEDIA_BUS_FMT_RGB888_1X24;
+   } else if (!strcmp(fmt, "jeida-18")) {
+   *bus_formats[i] = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG;
+   } else if (!strcmp(fmt, "jeida-24")) {
+   *bus_formats[i] = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA;
+   } else if (!strcmp(fmt, "vesa-24")) {
+   *bus_formats[i] = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG;
+   } else {
+   kfree(*bus_formats);
+   *bus_formats = NULL;
+   return -EINVAL;
+   }
+   }
+
+   return num_bus_formats;
+}
+EXPORT_SYMBOL_GPL(drm_of_bus_formats);
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index b93c239afb60..ccacddc03a2e 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -33,6 +33,8 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
int port, int endpoint,
struct drm_panel **panel,
struct drm_bridge **bridge);
+int drm_of_bus_formats(const struct device_node *np, const char *propname,
+  u32 **bus_formats);
 #else
 static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
  struct device_node *port)
@@ -69,6 +71,13 @@ static inline int dr

[PATCH v2 5/5] drm/atmel-hlcdc: take bridges into account when selecting output format

[Peter Rosin]

Bridges may affect the required bus output format of the encoder, in
which case it may be wrong to use the output format of the panel or
connector as is. So, examine if any of the intermediate bridges needs
specific bus formats (if there are intermediate bridges).

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 49 --
 1 file changed, 46 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index d73281095fac..920eb16c0213 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -226,6 +226,45 @@ static void atmel_hlcdc_crtc_atomic_enable(struct drm_crtc 
*c,
 #define ATMEL_HLCDC_RGB888_OUTPUT  BIT(3)
 #define ATMEL_HLCDC_OUTPUT_MODE_MASK   GENMASK(3, 0)
 
+/* We know that our connectors will only ever have one encoder. Find it. */
+static struct drm_encoder *atmel_hlcdc_encoder(struct drm_connector *connector)
+{
+   struct drm_encoder *encoder;
+   int i;
+
+   for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
+   if (!connector->encoder_ids[i])
+   break;
+
+   encoder = drm_encoder_find(connector->dev, NULL,
+  connector->encoder_ids[i]);
+   if (encoder)
+   return encoder;
+   }
+
+   return NULL;
+}
+
+static int atmel_hlcdc_output_formats(struct drm_connector *connector,
+ const u32 **bus_formats)
+{
+   struct drm_encoder *encoder = atmel_hlcdc_encoder(connector);
+   int num_bus_formats;
+
+   if (!encoder)
+   return 0;
+
+   if (encoder->bridge) {
+   num_bus_formats = drm_bridge_input_formats(encoder->bridge,
+  bus_formats);
+   if (num_bus_formats)
+   return num_bus_formats;
+   }
+
+   *bus_formats = connector->display_info.bus_formats;
+   return connector->display_info.num_bus_formats;
+}
+
 static int atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
 {
unsigned int output_fmts = ATMEL_HLCDC_OUTPUT_MODE_MASK;
@@ -238,15 +277,19 @@ static int atmel_hlcdc_crtc_select_output_mode(struct 
drm_crtc_state *state)
crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc);
 
for_each_new_connector_in_state(state->state, connector, cstate, i) {
-   struct drm_display_info *info = &connector->display_info;
+   int num_bus_formats;
+   const u32 *bus_formats;
unsigned int supported_fmts = 0;
int j;
 
+   num_bus_formats = atmel_hlcdc_output_formats(connector,
+&bus_formats);
+
if (!cstate->crtc)
continue;
 
-   for (j = 0; j < info->num_bus_formats; j++) {
-   switch (info->bus_formats[j]) {
+   for (j = 0; j < num_bus_formats; j++) {
+   switch (bus_formats[j]) {
case MEDIA_BUS_FMT_RGB444_1X12:
supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
break;
-- 
2.11.0

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

Re: [PATCH v2 2/5] drm: bridge: add API to query the expected input formats of bridges

[Peter Rosin]

On 2018-03-27 11:47, jacopo mondi wrote:
>> + * RETURNS:
>> + * The number of bus input formats the bridge accepts. Zero means that
>> + * the chain of bridges are not converting the bus format and that the
>> + * format of the drm_connector should be used.
> 
> How do we get to the connector format from a bridge that has maybe
> other components in between in the pipeline?

Forgot to write something here in my previous reply, sorry...

The chain of bridges do not end with the connector in the in-kernel
representation, IIUC. So, I think it is up to the caller to find the
format desired by the connector. See patch [5/5] for an example.

Maybe the connector should be passed in as an argument?

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

Re: [PATCH libdrm 1/2] intel: Do not use libpciaccess on Android

[Tomasz Figa]

On Wed, Mar 21, 2018 at 2:36 AM, Emil Velikov  wrote:
> From: Tomasz Figa 
>
> This patch makes the code not rely anymore on libpciaccess when compiled
> for Android to eliminate ioperm() and iopl() syscalls required by that
> library. As a side effect, the mappable aperture size is hardcoded to 64
> MiB on Android, however nothing seems to rely on this value anyway, as
> checked be grepping relevant code in drm_gralloc and Mesa.
>
> Cc: John Stultz 
> Cc: Rob Herring 
> Cc: John Stultz 
> Cc: Tomasz Figa 
> Signed-off-by: Tomasz Figa 
> [Emil Velikov: rebase against master]
> Signed-off-by: Emil Velikov 
> ---
> Tomasz, I've taken the liberty of pulling the patch from the Android
> tree. Hope you don't mind.

Thanks Emil for digging it up. I have no objections.

For reference, we used this as a quick hack before moving build of
graphics components to Chrome OS side. After that, for short time, we
had libpciaccess being built with autotools (and some small patch
disabling port IO related stuff). Eventually we got rid of it
completely, as Mesa stopped using libdrm_intel for i965 (and we don't
use i915).

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

[PATCH] gpu: host1x: Fix compiler errors

[Emil Goode]

The compiler is complaining with the following errors:

drivers/gpu/host1x/cdma.c:94:48: error:
passing argument 3 of ‘dma_alloc_wc’ from incompatible pointer type
[-Werror=incompatible-pointer-types]

drivers/gpu/host1x/cdma.c:113:48: error:
passing argument 3 of ‘dma_alloc_wc’ from incompatible pointer type
[-Werror=incompatible-pointer-types]

The expected pointer type of the third argument to dma_alloc_wc() is
dma_addr_t but phys_addr_t is passed. Fix this by adding casts to the
expected pointer type.

Signed-off-by: Emil Goode 
---
 drivers/gpu/host1x/cdma.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index 28541b280739..5e8b321a751e 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -91,8 +91,8 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
 
size = iova_align(&host1x->iova, size);
 
-   pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
- GFP_KERNEL);
+   pb->mapped = dma_alloc_wc(host1x->dev, size,
+ (dma_addr_t *)&pb->phys, GFP_KERNEL);
if (!pb->mapped)
return -ENOMEM;
 
@@ -110,8 +110,8 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
if (err)
goto iommu_free_iova;
} else {
-   pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
- GFP_KERNEL);
+   pb->mapped = dma_alloc_wc(host1x->dev, size,
+ (dma_addr_t *)&pb->phys, GFP_KERNEL);
if (!pb->mapped)
return -ENOMEM;
 
-- 
2.11.0

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

[Bug 100069] Dirt: Showdown bad performance with enabled advanced lightning

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100069

--- Comment #8 from Gregor Münch  ---
All graphic options are set to the maximum possible value including MSAA.

Its not only about low performance, once advanced lightning is set, the graphic
is also seriously bugged, including wrong textures.

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

[Bug 100069] Dirt: Showdown bad performance with enabled advanced lightning

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100069

--- Comment #9 from Gregor Münch  ---
Found YouTube video on Nvidia showing same settings, including advanced
lightning working flawless and good speed. https://youtu.be/hP4V5W-IRJ0?t=4m49s


However in a phoronix article, Michael is showing ingame pictures showing cars
with obviously missing textures. (Yet he claims that the game is looking good
and the same for both vendors) it's the same kind of corruption I see with
activated advanced lightning btw. Though I additionally see over bright lights.
https://www.phoronix.com/scan.php?page=article&item=dirt-showdown-linux&num=4
The performance with catalyst was still way better than Mesa.

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

[PATCH] drm/vmwgfx: Fix vmw_du_cursor_plane_atomic_check

[Thomas Hellstrom]

Use the correct helper and also return early on helper
success rather than on helper failure.

Also explicitly return 0 in the case of no fb.

Signed-off-by: Thomas Hellstrom 
Reported-by: Dan Carpenter 
Reported-by: Daniel Vetter 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 3628a9fe705f..0f7dc9ea2657 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -494,23 +494,23 @@ int vmw_du_cursor_plane_atomic_check(struct drm_plane 
*plane,
 struct drm_plane_state *new_state)
 {
int ret = 0;
+   struct drm_crtc_state *crtc_state = NULL;
struct vmw_surface *surface = NULL;
struct drm_framebuffer *fb = new_state->fb;
 
-   struct drm_rect src = drm_plane_state_src(new_state);
-   struct drm_rect dest = drm_plane_state_dest(new_state);
-
/* Turning off */
if (!fb)
-   return ret;
+   return 0;
 
-   ret = drm_plane_helper_check_update(plane, new_state->crtc, fb,
-   &src, &dest,
-   DRM_MODE_ROTATE_0,
-   DRM_PLANE_HELPER_NO_SCALING,
-   DRM_PLANE_HELPER_NO_SCALING,
-   true, true, &new_state->visible);
-   if (!ret)
+   if (new_state->crtc)
+   crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
+  new_state->crtc);
+
+   ret = drm_atomic_helper_check_plane_state(new_state, crtc_state,
+ DRM_PLANE_HELPER_NO_SCALING,
+ DRM_PLANE_HELPER_NO_SCALING,
+ true, true);
+   if (ret)
return ret;
 
/* A lot of the code assumes this */
-- 
2.14.3

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

[git pull] amdkfd next 4.17

[Oded Gabbay]

Hi Dave,

Last pull for 4.17. Highlights:

- GPUVM support for dGPUs
- KFD events support for dGPUs
- Fix live-lock situation when restoring multiple evicted processes
- Fix VM page table allocation on large-bar systems
- Fix for build failure on frv architecture

The following changes since commit 33d009cd889490838c5db9b9339856c9e3d3facc:

  Merge branch 'drm-next-4.17' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2018-03-26 10:01:11 +1000)

are available in the Git repository at:

  git://people.freedesktop.org/~gabbayo/linux tags/drm-amdkfd-next-2018-03-27

for you to fetch changes up to 1679ae8f8f4148766423066aeb3dbb0a985a373a:

  drm/amdkfd: Use ordered workqueue to restore processes (2018-03-23 15:30:36 
-0400)


Arnd Bergmann (1):
  drm/amdkfd: fix uninitialized variable use

Felix Kuehling (15):
  drm/amdgpu: Move KFD-specific fields into struct amdgpu_vm
  drm/amdgpu: Fix initial validation of PD BO for KFD VMs
  drm/amdgpu: Add helper to turn an existing VM into a compute VM
  drm/amdgpu: Add kfd2kgd interface to acquire an existing VM
  drm/amdkfd: Create KFD VMs on demand
  drm/amdkfd: Remove limit on number of GPUs
  drm/amdkfd: Aperture setup for dGPUs
  drm/amdkfd: Add per-process IDR for buffer handles
  drm/amdkfd: Allocate CWSR trap handler memory for dGPUs
  drm/amdkfd: Add TC flush on VMID deallocation for Hawaii
  drm/amdkfd: Add ioctls for GPUVM memory management
  drm/amdkfd: Kmap event page for dGPUs
  drm/amdkfd: Add module option for testing large-BAR functionality
  drm/amdgpu: Fix acquiring VM on large-BAR systems
  drm/amdkfd: Use ordered workqueue to restore processes

Oak Zeng (1):
  drm/amdkfd: Populate DRM render device minor

Oded Gabbay (1):
  drm/amdkfd: add missing include of mm.h

 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h |  28 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c  |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c  |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c   | 249 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  73 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  10 +
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   | 532 +
 drivers/gpu/drm/amd/amdkfd/kfd_crat.c  |   5 +-
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  |  22 +-
 drivers/gpu/drm/amd/amdkfd/kfd_events.c|  31 +-
 drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c   |  59 ++-
 drivers/gpu/drm/amd/amdkfd/kfd_module.c|  11 +-
 drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c|  37 ++
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h  |  39 +-
 drivers/gpu/drm/amd/amdkfd/kfd_process.c   | 334 -
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c  |   4 +
 drivers/gpu/drm/amd/amdkfd/kfd_topology.h  |   1 +
 drivers/gpu/drm/amd/include/kgd_kfd_interface.h|   4 +
 include/uapi/linux/kfd_ioctl.h | 122 -
 19 files changed, 1398 insertions(+), 165 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105712] intel-gpu-overlay is showing insane power consumption amounts

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105712

--- Comment #9 from Chris Wilson  ---
Created attachment 138378
  --> https://bugs.freedesktop.org/attachment.cgi?id=138378&action=edit
Use setlocale("C") around strtod

Please try the attached patch.

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

Re: [PATCH 06/10] drm/sun4i: Move and extend format-related helpers and tables

[Maxime Ripard]

On Tue, Mar 27, 2018 at 10:27:44AM +0200, Paul Kocialkowski wrote:
> > > +bool sun4i_format_is_rgb(uint32_t format);
> > > +bool sun4i_format_is_yuv(uint32_t format);
> > > +bool sun4i_format_is_yuv411(uint32_t format);
> > > +bool sun4i_format_is_yuv420(uint32_t format);
> > > +bool sun4i_format_is_yuv422(uint32_t format);
> > > +bool sun4i_format_is_yuv444(uint32_t format);
> > > +bool sun4i_format_is_packed(uint32_t format);
> > > +bool sun4i_format_is_semiplanar(uint32_t format);
> > > +bool sun4i_format_is_planar(uint32_t format);
> > > +bool sun4i_format_supports_tiling(uint32_t format);
> > 
> > If we're going to add so many of them, then we should really consider
> > to move them to drm_fourcc.c instead. Every one has some variation of
> > some of these functions, we don't really need to duplicate it all the
> > time.
> 
> Should I try to get that through in this patchset and have sun4i-drm
> be their first user? Also, does introducing such a change require
> identifying duplicates of these functions in each DRM driver's
> codebase?

I guess converting at least one of them would prove how usable it
would be to other drivers, but I won't ask you to convert all of them
as part of this serie :)

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [PATCH 09/10] drm/sun4i: Add a dedicated ioctl call for allocating tiled buffers

[Maxime Ripard]

On Tue, Mar 27, 2018 at 10:41:38AM +0200, Paul Kocialkowski wrote:
> > > +int drm_sun4i_gem_create_tiled(struct drm_device *dev, void *data,
> > > +struct drm_file *file_priv);
> > 
> > Do you need it to be non-static, and part of the header as well?
> 
> Here as well, I just find that it looks more readable that way, below
> the drm driver structure definition instead of above it.

But it also creates a global symbol for no particular reason, while
we're doing the function-first-structure-later pattern pretty much
everywhere else in the kernel.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

[PULL] drm-intel-next-fixes

[Joonas Lahtinen]

Hi Dave,

Two human-reported bugs to close for display and a more rare fix
that could result in GPU hang.

There was some unclarity about the GVT pull, so I'm not including
it here.

Happy Easter holidays!

Regards, Joonas

drm-intel-next-fixes-2018-03-27:
- Display fixes for booting with MST hub lid closed and display
  freezing after hibernation (fd.o bugs 105470 & 105196)
- Fix for a very rare interrupt handling race resulting in GPU hang

The following changes since commit 33d009cd889490838c5db9b9339856c9e3d3facc:

  Merge branch 'drm-next-4.17' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2018-03-26 10:01:11 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2018-03-27

for you to fetch changes up to 300efa9eea451bdcf3b5a1eb29e06e85bb2c:

  drm/i915: Fix hibernation with ACPI S0 target state (2018-03-27 11:20:06 
+0300)


- Display fixes for booting with MST hub lid closed and display
  freezing after hibernation (fd.o bugs 105470 & 105196)
- Fix for a very rare interrupt handling race resulting in GPU hang


Chris Wilson (2):
  drm/i915: Specify which engines to reset following semaphore/event lockups
  drm/i915/execlists: Use a locked clear_bit() for synchronisation with 
interrupt

Dhinakaran Pandiyan (1):
  drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.

Imre Deak (1):
  drm/i915: Fix hibernation with ACPI S0 target state

 drivers/gpu/drm/i915/i915_drv.c| 22 ++
 drivers/gpu/drm/i915/i915_drv.h|  2 +-
 drivers/gpu/drm/i915/intel_ddi.c   |  7 ++-
 drivers/gpu/drm/i915/intel_hangcheck.c |  4 ++--
 drivers/gpu/drm/i915/intel_lrc.c   | 21 -
 5 files changed, 23 insertions(+), 33 deletions(-)

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