Re: [PATCH v1 1/3] drm/tegra: plane: Fix RGB565 plane format on older Tegra's

[Dmitry Osipenko]

On 15.03.2018 13:27, Thierry Reding wrote:
> On Thu, Mar 15, 2018 at 04:00:23AM +0300, Dmitry Osipenko wrote:
>> Simplify opaque format adjustment by removing format checking. There are
>> only 4 formats that require the adjustment and so this way is less error
>> prone, avoiding mishandling native formats, like in this case RGB565 is
>> the format that was erroneously treated as invalid.
>>
>> Fixes: ebae8d07435a ("drm/tegra: dc: Implement legacy blending")
>> Signed-off-by: Dmitry Osipenko 
>> ---
>>  drivers/gpu/drm/tegra/dc.c| 11 ++-
>>  drivers/gpu/drm/tegra/plane.c | 21 ++---
>>  drivers/gpu/drm/tegra/plane.h |  2 +-
>>  3 files changed, 9 insertions(+), 25 deletions(-)
> 
> I've applied a slightly different version of this which doesn't rework
> as much of the surrounding code and is therefore easier to backport to
> v4.16.

Okay. Please don't forget to push the modified patch, I don't see it in the FDO 
git.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 2/3] drm/tegra: plane: Correct legacy blending

[Dmitry Osipenko]

On 15.03.2018 13:29, Thierry Reding wrote:
> On Thu, Mar 15, 2018 at 04:00:24AM +0300, Dmitry Osipenko wrote:
>> Keep old 'dependent' state of unaffected planes, this way new state takes
>> into account current state of unaffected planes.
>>
>> Fixes: ebae8d07435a ("drm/tegra: dc: Implement legacy blending")
>> Signed-off-by: Dmitry Osipenko 
>> ---
>>  drivers/gpu/drm/tegra/plane.c | 15 ++-
>>  1 file changed, 6 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
>> index fc37dcf8c458..3c0cb6a04c66 100644
>> --- a/drivers/gpu/drm/tegra/plane.c
>> +++ b/drivers/gpu/drm/tegra/plane.c
>> @@ -287,13 +287,11 @@ unsigned int tegra_plane_format_adjust(unsigned int 
>> opaque)
>>  return opaque;
>>  }
>>  
>> -unsigned int tegra_plane_get_overlap_index(struct tegra_plane *plane,
>> -   struct tegra_plane *other)
>> +static unsigned int tegra_plane_get_overlap_index(struct tegra_plane *plane,
>> +  struct tegra_plane *other)
> 
> I'd prefer this to be a separate patch to keep the diff down to make
> this easier to apply to v4.16. I can do that when I apply, no need to
> resend.

Okay. But now I'm thinking that it's probably not really worth to backport this
patch at all because it doesn't fix blending entirely, but only makes it good
enough to show cursor plane properly. I'll send V2.

>>  {
>>  unsigned int index = 0, i;
>>  
>> -WARN_ON(plane == other);
>> -
> 
> Why would this need to go away? We still shouldn't be called with plane
> == other because that makes no sense.
This can't ever happen because we are skipping 'plane' in 
for_each_plane_in_state().
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle

[Jacopo Mondi]

The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS
decoder, connected to the on-chip LVDS encoder output on one side
and to HDMI encoder ADV7511w on the other one.

As the decoder does not need any configuration it has been so-far
omitted from DTS. Now that a driver is available, describe it in DT
as well.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
---
 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 +++---
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts 
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index c0fd144..69f43b8 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -42,6 +42,33 @@
};
};
};
+
+   thc63lvd1024: lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   thc63lvd1024_in_0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2{
+   reg = <2>;
+
+   thc63lvd1024_out_2: endpoint {
+   remote-endpoint = <_in>;
+   };
+
+   };
+
+   };
+   };
 };
 
  {
@@ -98,7 +125,7 @@
port@0 {
reg = <0>;
adv7511_in: endpoint {
-   remote-endpoint = <_out>;
+   remote-endpoint = <_out_2>;
};
};
 
@@ -152,8 +179,8 @@
 
ports {
port@1 {
-   endpoint {
-   remote-endpoint = <_in>;
+   lvds0_out: endpoint {
+   remote-endpoint = <_in_0>;
};
};
};
-- 
2.7.4

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

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #58 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
Please try following to see if it helps avoiding the hang = 

R600_DEBUG=notiling,norbplus

try with GALLIUM_DDEBUG=flush to see if it makes a difference (flushes after
each draw call)

try running programs that can be used without X: like KMS cube

Andrey

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

Re: [Intel-gfx] [PATCH 2/3] drm: Make sure at least one plane supports the fb format

[Ville Syrjälä]

On Thu, Mar 15, 2018 at 07:48:02PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 15, 2018 at 10:42:17AM -0700, Eric Anholt wrote:
> > Ville Syrjala  writes:
> > 
> > > From: Ville Syrjälä 
> > >
> > > To make life easier for drivers, let's have the core check that the
> > > requested pixel format is supported by at least one plane when creating
> > > a new framebuffer.
> > >
> > > This eases the burden on drivers by making sure they'll never get
> > > requests to create fbs with unsupported pixel formats. Thanks to the
> > > new .fb_modifier() hook this check can now be done whether the request
> > > specifies the modifier directly or driver has to deduce it from the
> > > gem bo tiling (or via any other method really).
> > >
> > > v0: Accept anyformat if the driver doesn't do planes (Eric)
> > > s/planes_have_format/any_plane_has_format/ (Eric)
> > > Check the modifier as well since we already have a function
> > > that does both
> > > v3: Don't do the check in the core since we may not know the
> > > modifier yet, instead export the function and let drivers
> > > call it themselves
> > > v4: Unexport the functiona and put the format_default check back
> > > since this will again be called by the core, ie. undo v3 ;)
> > >
> > > Cc: Eric Anholt 
> > > Testcase: igt/kms_addfb_basic/expected-formats
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/drm_framebuffer.c | 30 ++
> > >  1 file changed, 30 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> > > b/drivers/gpu/drm/drm_framebuffer.c
> > > index 21d3d51eb261..e618a6b728d4 100644
> > > --- a/drivers/gpu/drm/drm_framebuffer.c
> > > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > > @@ -152,6 +152,26 @@ static int fb_plane_height(int height,
> > >   return DIV_ROUND_UP(height, format->vsub);
> > >  }
> > >  
> > > +static bool any_plane_has_format(struct drm_device *dev,
> > > +  u32 format, u64 modifier)
> > > +{
> > > + struct drm_plane *plane;
> > > +
> > > + drm_for_each_plane(plane, dev) {
> > > + /*
> > > +  * In case the driver doesn't really do
> > > +  * planes we have to accept any format here.
> > > +  */
> > > + if (plane->format_default)
> > > + return true;
> > > +
> > > + if (drm_plane_check_pixel_format(plane, format, modifier) == 0)
> > > + return true;
> > > + }
> > > +
> > > + return false;
> > > +}
> > 
> > This drm_plane_check_pixel_format() will always fail for VC4's SAND
> > modifiers or VC5's UIF modifiers, where we're using the middle 48 bits
> > as a bit of metadata (like how we have horizontal stride passed outside
> > of the modifier) and you can't list all of the possible values in an
> > array on the plane.
> 
> Hmm. drm_atomic_plane_check() etc. call this thing as well. How does
> that manage to work currently?

Maybe it doesn't. I added the modifier checks in

commit 23163a7d4b032489d375099d56571371c0456980
Author: Ville Syrjälä 
AuthorDate: Fri Dec 22 21:22:30 2017 +0200
Commit: Ville Syrjälä 
CommitDate: Mon Feb 26 16:29:47 2018 +0200

drm: Check that the plane supports the request format+modifier combo

Maybe that broke vc4?

Hmm. So either we need to stop checking against the modifiers array and
rely purely or .format_mod_supported(), or we need to somehow get the
driver to reduce the modifier to its base form. I guess we could make
.fb_modifier() do that and call it also for addfb with modifiers. And
I'd need to undo some of the modifier[0] vs. deduced modifier changes
I did to framebuffer_check(), and we'd need to preserve the original
modifier in the request for .fb_create(). Oh, but that wouldn't allow
returning a non-base modifier from .fb_modifuer() for the !modifiers
case. This is turning slightly more tricky than I had hoped...

I guess relying on .format_mod_supported() might be what we need to 
do. Unfortunately it does mean that the .format_mod_supported()
implementations must be prepared for modifiers that were not
registered with the plane. Which does feel quite a bit more
fragile.

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

[PATCH] drm: dw-hdmi-i2s: Remove owner assignment from platform_driver

[Fabio Estevam]

From: Fabio Estevam 

platform_driver does not need to set the owner field, as this will
be populated by the driver core.

Generated by scripts/coccinelle/api/platform_no_drv_owner.cocci.

Signed-off-by: Fabio Estevam 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
index 3b7e5c5..8f9c8a6 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -152,7 +152,6 @@ static struct platform_driver snd_dw_hdmi_driver = {
.remove = snd_dw_hdmi_remove,
.driver = {
.name = DRIVER_NAME,
-   .owner = THIS_MODULE,
},
 };
 module_platform_driver(snd_dw_hdmi_driver);
-- 
2.7.4

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

Re: [PATCH v2] drm/tegra: plane: Keep 'dependent' blending state of unaffected planes

[Thierry Reding]

On Thu, Mar 15, 2018 at 05:24:31PM +0300, Dmitry Osipenko wrote:
> This way new state takes into account the current state of unaffected
> (by the atomic commit) planes.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
> 
> v2: Dropped unrelated 'cleanup' changes and fixed
> s/state->dependent[i]/state->dependent[index]/ typo.
> 
>  drivers/gpu/drm/tegra/plane.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)

I've amended the commit in drm/tegra/fixes to match this v2.

Thanks,
Thierry


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

Re: [PATCH libdrm] tests/exynos: remove dead condition

[Eric Engestrom]

On Wednesday, 2018-03-14 14:48:37 +0900, Seung-Woo Kim wrote:
> There is already condition checking input values between 2 and 4096
> so condition checking 0 is always false. Remove the dead condition.
> 
> Signed-off-by: Seung-Woo Kim 

Indeed, good catch :)
Reviewed-by: Eric Engestrom 

... and pushed, thanks!

> ---
>  tests/exynos/exynos_fimg2d_perf.c |7 ---
>  1 files changed, 0 insertions(+), 7 deletions(-)
> 
> diff --git a/tests/exynos/exynos_fimg2d_perf.c 
> b/tests/exynos/exynos_fimg2d_perf.c
> index a2d5c19..97691a7 100644
> --- a/tests/exynos/exynos_fimg2d_perf.c
> +++ b/tests/exynos/exynos_fimg2d_perf.c
> @@ -274,13 +274,6 @@ int main(int argc, char **argv)
>   goto out;
>   }
>  
> - if (bufw == 0 || bufh == 0) {
> - fprintf(stderr, "error: buffer width/height should be 
> non-zero.\n");
> - ret = -1;
> -
> - goto out;
> - }
> -
>   fd = drmOpen("exynos", NULL);
>   if (fd < 0) {
>   fprintf(stderr, "error: failed to open drm\n");
> -- 
> 1.7.4.1
> 
> ___
> 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

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

[Jacopo Mondi]

Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
output converter.

Signed-off-by: Jacopo Mondi 
---
 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..067f231
--- /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;
+
+   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 %u\n", 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 %u\n", i);
+   }
+}
+
+struct drm_bridge_funcs thc63_bridge_func = {
+   .attach = thc63_attach,
+   .enable = thc63_enable,
+   .disable = thc63_disable,
+};
+
+static int thc63_parse_dt(struct thc63_dev *thc63)
+{
+   struct device_node *thc63_out;
+   struct device_node *remote;
+   int ret = 0;
+
+   thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
+ THC63_DIGITAL_OUT0, -1);
+   if (!thc63_out) {
+   dev_err(thc63->dev, "Missing endpoint in Port@%u\n",
+   THC63_DIGITAL_OUT0);
+   return -ENODEV;
+  

[PATCH v5 0/3] drm: Add Thine THC63LVD1024 LVDS decoder bridge

[Jacopo Mondi]

Hi,
   v5 with a few small changes compared to v4 and with Andrzej tag added to
all patches in the series.

I fixed punctuation in the bindings and added a statement to clarify
the chip does not expose any control bus but it is instead configured by input
signals.

Minor changes in the driver, with the regulator name printed out in error path
of enable/disable routines instead of its index.

Branch for testing available at
git://jmondi.org v3m/v4.16-rc3/lvds-bridge-v5

Thanks
   j

v4 -> v5:
- Fix punctuation in bindings documentation
- Add small statement to bindings document to clarify the chip has no
  control bus
- Print regulator name in enable/disable routines error path
- Add Andrzej Reviewed-by tag

v3 -> v4:
- Rename permutations of "pdwn" to just "pdwn" everywhere in the series
- Improve power enable/disable routines as suggested by Andrzej and Sergei
- Change "pdwn" gpio initialization to use the logical output level
- Change Kconfig description

v2 -> v3:
- Drop support for "lvds-decoder" and make the driver THC63LVD1024 specific
-- Rework bindings to describe multiple input/output ports
-- Rename driver and remove "lvds-decoder" references
-- Rework Eagle DTS to use new bindings

v1 -> v2:
- Drop support for THC63LVD1024


Jacopo Mondi (3):
  dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
  drm: bridge: Add thc63lvd1024 LVDS decoder driver
  arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle

 .../bindings/display/bridge/thine,thc63lvd1024.txt |  66 ++
 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts |  33 ++-
 drivers/gpu/drm/bridge/Kconfig |   6 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/thc63lvd1024.c  | 257 +
 5 files changed, 360 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c

--
2.7.4

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

Re: [PATCH v1 2/3] drm/tegra: plane: Correct legacy blending

[Dmitry Osipenko]

On 15.03.2018 15:42, Dmitry Osipenko wrote:
> On 15.03.2018 13:29, Thierry Reding wrote:
>> On Thu, Mar 15, 2018 at 04:00:24AM +0300, Dmitry Osipenko wrote:
>>> Keep old 'dependent' state of unaffected planes, this way new state takes
>>> into account current state of unaffected planes.
>>>
>>> Fixes: ebae8d07435a ("drm/tegra: dc: Implement legacy blending")
>>> Signed-off-by: Dmitry Osipenko 
>>> ---
>>>  drivers/gpu/drm/tegra/plane.c | 15 ++-
>>>  1 file changed, 6 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
>>> index fc37dcf8c458..3c0cb6a04c66 100644
>>> --- a/drivers/gpu/drm/tegra/plane.c
>>> +++ b/drivers/gpu/drm/tegra/plane.c
>>> @@ -287,13 +287,11 @@ unsigned int tegra_plane_format_adjust(unsigned int 
>>> opaque)
>>> return opaque;
>>>  }
>>>  
>>> -unsigned int tegra_plane_get_overlap_index(struct tegra_plane *plane,
>>> -  struct tegra_plane *other)
>>> +static unsigned int tegra_plane_get_overlap_index(struct tegra_plane 
>>> *plane,
>>> + struct tegra_plane *other)
>>
>> I'd prefer this to be a separate patch to keep the diff down to make
>> this easier to apply to v4.16. I can do that when I apply, no need to
>> resend.
> 
> Okay. But now I'm thinking that it's probably not really worth to backport 
> this
> patch at all because it doesn't fix blending entirely, but only makes it good
> enough to show cursor plane properly. I'll send V2.

Ah, didn't notice that I don't have to re-send. I've spotted other problem in
the patch, so will just send V2 ;)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Jacopo Mondi]

Document Thine THC63LVD1024 LVDS decoder device tree bindings.

Signed-off-by: Jacopo Mondi 
---
 .../bindings/display/bridge/thine,thc63lvd1024.txt | 63 ++
 1 file changed, 63 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..0936bde
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,63 @@
+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.
+
+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
+- pdwn-gpios: Power down GPIO signal. Active low.
+- oe-gpios: Output enable GPIO signal. Active high.
+
+The THC63LVD1024 video port connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+Required video port nodes:
+- Port@0: First LVDS input port
+- Port@2: First digital CMOS/TTL parallel output
+
+Optional video port nodes:
+- Port@1: Second LVDS input port
+- Port@3: Second digital CMOS/TTL parallel output
+
+Example:
+
+
+   thc63lvd1024: lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+
+   vcc-supply = <_lvds_vcc>;
+   lvcc-supply = <_lvds_lvcc>;
+
+   pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   lvds_dec_in_0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2{
+   reg = <2>;
+
+   lvds_dec_out_2: endpoint {
+   remote-endpoint = <_in>;
+   };
+
+   };
+
+   };
+   };
-- 
2.7.4

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

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

[Jacopo Mondi]

Document Thine THC63LVD1024 LVDS decoder device tree bindings.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
---
 .../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
+- pdwn-gpios: Power down GPIO signal. Active low
+- oe-gpios: Output enable GPIO signal. Active high
+
+The THC63LVD1024 video port connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+Required video port nodes:
+- Port@0: First LVDS input port
+- Port@2: First digital CMOS/TTL parallel output
+
+Optional video port nodes:
+- Port@1: Second LVDS input port
+- Port@3: Second digital CMOS/TTL parallel output
+
+Example:
+
+
+   thc63lvd1024: lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+
+   vcc-supply = <_lvds_vcc>;
+   lvcc-supply = <_lvds_lvcc>;
+
+   pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   lvds_dec_in_0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2{
+   reg = <2>;
+
+   lvds_dec_out_2: endpoint {
+   remote-endpoint = <_in>;
+   };
+
+   };
+
+   };
+   };
-- 
2.7.4

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

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

[Jacopo Mondi]

Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
output converter.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/Kconfig|   6 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/thc63lvd1024.c | 257 ++
 3 files changed, 264 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..36069a0
--- /dev/null
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -0,0 +1,257 @@
+// 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;
+
+   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]);
+   }
+}
+
+struct drm_bridge_funcs thc63_bridge_func = {
+   .attach = thc63_attach,
+   .enable = thc63_enable,
+   .disable = thc63_disable,
+};
+
+static int thc63_parse_dt(struct thc63_dev *thc63)
+{
+   struct device_node *thc63_out;
+   struct device_node *remote;
+   int ret = 0;
+
+   thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
+ THC63_DIGITAL_OUT0, -1);
+   if (!thc63_out) {
+   

[PATCH v4 0/3] drm: Add Thine THC63LVD1024 LVDS decoder bridge

[Jacopo Mondi]

Hello,
   this new version fixes comments received from Andrzej and Sergei on the
preceding v3.

Mostly, I cleaned up the mess with the powerdown GPIO names, and I'm now using
pdwn everywhere. The regulator enabling routine has been improved as suggested
by Sergei and Andrzej and I've changed Kconfig symbol documentation for
consistency with other ones. Also, fix gpio initialization to comply with the
APIs that work on logical level even at gpio request time.

Branch for testing available at
git://jmondi.org v3m/v4.16-rc3/lvds-bridge-v4

Thanks
   j

v3 -> v4:
- Rename permutations of "pdwn" to just "pdwn" everywhere in the series
- Improve power enable/disable routines as suggested by Andrzej and Sergei
- Change "pdwn" gpio initialization to use the logical output level
- Change Kconfig description

v2 -> v3:
- Drop support for "lvds-decoder" and make the driver THC63LVD1024 specific
-- Rework bindings to describe multiple input/output ports
-- Rename driver and remove "lvds-decoder" references
-- Rework Eagle DTS to use new bindings

v1 -> v2:
- Drop support for THC63LVD1024

Jacopo Mondi (3):
  dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
  drm: bridge: Add thc63lvd1024 LVDS decoder driver
  arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle

 .../bindings/display/bridge/thine,thc63lvd1024.txt |  63 +
 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts |  33 ++-
 drivers/gpu/drm/bridge/Kconfig |   6 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/thc63lvd1024.c  | 255 +
 5 files changed, 355 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c

--
2.7.4

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

RE: [Intel-gfx] [PATCH 1/1] intel: align reuse buffer's size on page size instead

[Xiong, James]

Thanks for the review, Chris. Sorry for the late response.

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
>Chris Wilson
>Sent: Saturday, March 3, 2018 1:46 AM
>To: Xiong, James ; dri-devel@lists.freedesktop.org; 
>intel-...@lists.freedesktop.org
>Cc: Xiong, James 
>Subject: Re: [Intel-gfx] [PATCH 1/1] intel: align reuse buffer's size on page 
>size instead
>
>Quoting James Xiong (2018-03-02 17:53:04)
>> From: "Xiong, James" 
>> 
>> With gem_reuse enabled, when a buffer size is different than the sizes 
>> of buckets, it is aligned to the next bucket's size, which means about 
>> 25% more memory than the requested is allocated in the worst senario. 
>> For example:
>> 
>> Orignal sizeActual
>> 32KB+1Byte  40KB
>>.
>>.
>>.
>>8MB+1Byte   10MB
>>.
>>.
>>.
>>96MB+1Byte  112MB
>> 
>> This is very memory expensive and make the reuse feature less 
>> favorable than it deserves to be.
>> 
>> This commit aligns the reuse buffer size on page size instead, the 
>> buffer whose size falls between bucket[n] and bucket[n+1] is put in 
>> bucket[n] when it's done; And when searching for a cached buffer for 
>> reuse, it goes through the cached buffers list in the bucket until a 
>> cached buffer, whose size is larger than or equal to the requested 
>> size, is found.
>> 
>> Performed gfxbench tests, the performances and reuse ratioes (reuse 
>> count/allocation count) were same as before, saved memory usage by 1% 
>> ~ 7%(gl_manhattan: peak allocated memory size was reduced from 
>> 448401408 to 419078144).
>
>Apart from GL doesn't use this... And what is the impact on !llc, where buffer 
>reuse is more important? (Every new buffer requires clflushing.)
The test was run against a Gen9 that doesn't support LLC. Please let me know if 
you have some performance tests for me to run.
>
>
>
>> Signed-off-by: Xiong, James 
>> ---
>>  intel/intel_bufmgr_gem.c | 180 
>> +--
>>  libdrm_lists.h   |   6 ++
>>  2 files changed, 101 insertions(+), 85 deletions(-)
>> 
>> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 
>> 386da30..5b2d0d0 100644
>> --- a/intel/intel_bufmgr_gem.c
>> +++ b/intel/intel_bufmgr_gem.c
>> @@ -402,11 +402,10 @@ 
>> drm_intel_gem_bo_bucket_for_size(drm_intel_bufmgr_gem *bufmgr_gem,  {
>> int i;
>>  
>> -   for (i = 0; i < bufmgr_gem->num_buckets; i++) {
>> -   struct drm_intel_gem_bo_bucket *bucket =
>> -   _gem->cache_bucket[i];
>> -   if (bucket->size >= size) {
>> -   return bucket;
>> +   for (i = 0; i < bufmgr_gem->num_buckets - 1; i++) {
>> +   if (size >= bufmgr_gem->cache_bucket[i].size &&
>> +   size < bufmgr_gem->cache_bucket[i+1].size) {
>> +   return _gem->cache_bucket[i];
>
>Are your buckets not ordered correctly?
The order is the same as before, so are the buckets' sizes.
>
>Please reduce this patch to a series of small functional changes required to 
>bring into effect having mixed, page-aligned bo->size within a bucket.
Will do.
>-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 2/3] drm/tegra: plane: Correct legacy blending

[Dmitry Osipenko]

On 15.03.2018 15:42, Dmitry Osipenko wrote:
> On 15.03.2018 13:29, Thierry Reding wrote:
>> On Thu, Mar 15, 2018 at 04:00:24AM +0300, Dmitry Osipenko wrote:
>>> Keep old 'dependent' state of unaffected planes, this way new state takes
>>> into account current state of unaffected planes.
>>>
>>> Fixes: ebae8d07435a ("drm/tegra: dc: Implement legacy blending")
>>> Signed-off-by: Dmitry Osipenko 
>>> ---
>>>  drivers/gpu/drm/tegra/plane.c | 15 ++-
>>>  1 file changed, 6 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
>>> index fc37dcf8c458..3c0cb6a04c66 100644
>>> --- a/drivers/gpu/drm/tegra/plane.c
>>> +++ b/drivers/gpu/drm/tegra/plane.c
>>> @@ -287,13 +287,11 @@ unsigned int tegra_plane_format_adjust(unsigned int 
>>> opaque)
>>> return opaque;
>>>  }
>>>  
>>> -unsigned int tegra_plane_get_overlap_index(struct tegra_plane *plane,
>>> -  struct tegra_plane *other)
>>> +static unsigned int tegra_plane_get_overlap_index(struct tegra_plane 
>>> *plane,
>>> + struct tegra_plane *other)
>>
>> I'd prefer this to be a separate patch to keep the diff down to make
>> this easier to apply to v4.16. I can do that when I apply, no need to
>> resend.
> 
> Okay. But now I'm thinking that it's probably not really worth to backport 
> this
> patch at all because it doesn't fix blending entirely, but only makes it good
> enough to show cursor plane properly. I'll send V2.

Ah, didn't notice that I don't have to re-send. I've spotted other problem in
the patch, so will just send V2 ;)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 11/16] treewide: simplify Kconfig dependencies for removed archs

[Kalle Valo]

Arnd Bergmann  writes:

> A lot of Kconfig symbols have architecture specific dependencies.
> In those cases that depend on architectures we have already removed,
> they can be omitted.
>
> Signed-off-by: Arnd Bergmann 

[...]

>  drivers/net/wireless/cisco/Kconfig   |  2 +-

Acked-by: Kalle Valo 

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

[PATCH v2 5/6] drm/i915: Remove the blob->data casts

[Ville Syrjala]

From: Ville Syrjälä 

Now that blob->data is void* again we don't need to cast it.

v2: Rebase

Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_color.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 89ab0f70aa22..92f148832a89 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -153,8 +153,7 @@ static void ilk_load_csc_matrix(struct drm_crtc_state 
*crtc_state)
ilk_load_ycbcr_conversion_matrix(intel_crtc);
return;
} else if (crtc_state->ctm) {
-   struct drm_color_ctm *ctm =
-   (struct drm_color_ctm *)crtc_state->ctm->data;
+   struct drm_color_ctm *ctm = crtc_state->ctm->data;
const u64 *input;
u64 temp[9];
 
@@ -262,8 +261,7 @@ static void cherryview_load_csc_matrix(struct 
drm_crtc_state *state)
uint32_t mode;
 
if (state->ctm) {
-   struct drm_color_ctm *ctm =
-   (struct drm_color_ctm *) state->ctm->data;
+   struct drm_color_ctm *ctm = state->ctm->data;
uint16_t coeffs[9] = { 0, };
int i;
 
@@ -330,7 +328,7 @@ static void i9xx_load_luts_internal(struct drm_crtc *crtc,
}
 
if (blob) {
-   struct drm_color_lut *lut = (struct drm_color_lut *) blob->data;
+   struct drm_color_lut *lut = blob->data;
for (i = 0; i < 256; i++) {
uint32_t word =
(drm_color_lut_extract(lut[i].red, 8) << 16) |
@@ -400,8 +398,7 @@ static void bdw_load_degamma_lut(struct drm_crtc_state 
*state)
   PAL_PREC_SPLIT_MODE | PAL_PREC_AUTO_INCREMENT);
 
if (state->degamma_lut) {
-   struct drm_color_lut *lut =
-   (struct drm_color_lut *) state->degamma_lut->data;
+   struct drm_color_lut *lut = state->degamma_lut->data;
 
for (i = 0; i < lut_size; i++) {
uint32_t word =
@@ -435,8 +432,7 @@ static void bdw_load_gamma_lut(struct drm_crtc_state 
*state, u32 offset)
   offset);
 
if (state->gamma_lut) {
-   struct drm_color_lut *lut =
-   (struct drm_color_lut *) state->gamma_lut->data;
+   struct drm_color_lut *lut = state->gamma_lut->data;
 
for (i = 0; i < lut_size; i++) {
uint32_t word =
@@ -568,7 +564,7 @@ static void cherryview_load_luts(struct drm_crtc_state 
*state)
}
 
if (state->degamma_lut) {
-   lut = (struct drm_color_lut *) state->degamma_lut->data;
+   lut = state->degamma_lut->data;
lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
for (i = 0; i < lut_size; i++) {
/* Write LUT in U0.14 format. */
@@ -583,7 +579,7 @@ static void cherryview_load_luts(struct drm_crtc_state 
*state)
}
 
if (state->gamma_lut) {
-   lut = (struct drm_color_lut *) state->gamma_lut->data;
+   lut = state->gamma_lut->data;
lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
for (i = 0; i < lut_size; i++) {
/* Write LUT in U0.10 format. */
-- 
2.16.1

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

Re: [PATCH 2/3] drm: Make sure at least one plane supports the fb format

[Eric Anholt]

Ville Syrjala  writes:

> From: Ville Syrjälä 
>
> To make life easier for drivers, let's have the core check that the
> requested pixel format is supported by at least one plane when creating
> a new framebuffer.
>
> This eases the burden on drivers by making sure they'll never get
> requests to create fbs with unsupported pixel formats. Thanks to the
> new .fb_modifier() hook this check can now be done whether the request
> specifies the modifier directly or driver has to deduce it from the
> gem bo tiling (or via any other method really).
>
> v0: Accept anyformat if the driver doesn't do planes (Eric)
> s/planes_have_format/any_plane_has_format/ (Eric)
> Check the modifier as well since we already have a function
> that does both
> v3: Don't do the check in the core since we may not know the
> modifier yet, instead export the function and let drivers
> call it themselves
> v4: Unexport the functiona and put the format_default check back
> since this will again be called by the core, ie. undo v3 ;)
>
> Cc: Eric Anholt 
> Testcase: igt/kms_addfb_basic/expected-formats
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_framebuffer.c | 30 ++
>  1 file changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index 21d3d51eb261..e618a6b728d4 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -152,6 +152,26 @@ static int fb_plane_height(int height,
>   return DIV_ROUND_UP(height, format->vsub);
>  }
>  
> +static bool any_plane_has_format(struct drm_device *dev,
> +  u32 format, u64 modifier)
> +{
> + struct drm_plane *plane;
> +
> + drm_for_each_plane(plane, dev) {
> + /*
> +  * In case the driver doesn't really do
> +  * planes we have to accept any format here.
> +  */
> + if (plane->format_default)
> + return true;
> +
> + if (drm_plane_check_pixel_format(plane, format, modifier) == 0)
> + return true;
> + }
> +
> + return false;
> +}

This drm_plane_check_pixel_format() will always fail for VC4's SAND
modifiers or VC5's UIF modifiers, where we're using the middle 48 bits
as a bit of metadata (like how we have horizontal stride passed outside
of the modifier) and you can't list all of the possible values in an
array on the plane.


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: Reduce object size of DRM_ERROR and DRM_DEBUG uses

[Ville Syrjälä]

On Thu, Mar 15, 2018 at 08:44:05AM -0700, Joe Perches wrote:
> On Thu, 2018-03-15 at 17:37 +0200, Ville Syrjälä wrote:
> > On Thu, Mar 15, 2018 at 08:17:53AM -0700, Joe Perches wrote:
> > > On Thu, 2018-03-15 at 17:05 +0200, Ville Syrjälä wrote:
> > > > On Thu, Mar 15, 2018 at 03:04:52PM +0100, Maarten Lankhorst wrote:
> > > > > Op 15-03-18 om 14:30 schreef Ville Syrjälä:
> > > > > > On Tue, Mar 13, 2018 at 03:02:15PM -0700, Joe Perches wrote:
> > > > > > > drm_printk is used for both DRM_ERROR and DRM_DEBUG with 
> > > > > > > unnecessary
> > > > > > > arguments that can be removed by creating separate functins.
> > > > > > > 
> > > > > > > Create specific functions for these calls to reduce x86/64 
> > > > > > > defconfig
> > > > > > > size by ~20k.
> > > > > > > 
> > > > > > > Modify the existing macros to use the specific calls.
> > > > > > > 
> > > > > > > new:
> > > > > > > $ size -t drivers/gpu/drm/built-in.a | tail -1
> > > > > > > 1876562 44542 995 1922099  1d5433 (TOTALS)
> > > > > > > 
> > > > > > > old:
> > > > > > > $ size -t drivers/gpu/drm/built-in.a | tail -1
> > > > > > > 1897565 44542 995 1943102  1da63e (TOTALS)
> > > > > > > 
> > > > > > > Miscellanea:
> > > > > > > 
> > > > > > > o intel_display requires a change to use the specific calls.
> > > > > > 
> > > > > > How much would we lose if we move the (drm_debug) outside the
> > > > > > functions again?
> > > 
> > > again?
> > 
> > We used to do that. Someone changed it a while back, unintentially
> > I believe.
> > 
> > > 
> > > > > >  I'm somewhat concerned about all the function call
> > > > > > overhead when debugs aren't even enabled.
> > > 
> > > Perhaps better to have compilation elimination
> > > of the entire debug output instead.
> > 
> > That would require every bug reporter to recompile the kernel first.
> > So this is not a solution we would ever seriously consider.
> > 
> > Not sure if it would be possible to use the alternatives thing to
> > eliminate the function calls unless the user boots wih drm.debug!=0?
> > 
> > > 
> > > I think you are discussing a different issue and
> > > this discussion should not block this patch as
> > > this patch has no impact other than code size
> > > reduction.
> > 
> > But what is the goal of the code size reduction?
> 
> Smaller code.
> 
> > I assume the main
> > goal is to make better use of the instruction cache to make the
> > code faster. If there's a tradeoff between smaller and slightly
> > faster vs. larger and a singificantly faster I tend to think we
> > should go for the latter option.
> 
> There's no trade-off in this patch for faster/larger.
> This patch is simply smaller.  Smaller is better.

This feels a bit like saying pink is better than red because it's
more pink.

That said, I'm not arguing against this patch as such. Making things
smaller "just because" usually doesn't cause problems. But I was
hoping that we might be after some more tangible gains here, and
thus pointed out that there may be a better way to achieve even
bigger gains.

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

Re: [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

[Joe Perches]

On Thu, 2018-03-15 at 18:14 +0200, Ville Syrjälä wrote:
> > There's no trade-off in this patch for faster/larger.
> > This patch is simply smaller.  Smaller is better.
> 
> This feels a bit like saying pink is better than red because it's
> more pink.

Silly.  If you can't say smaller total object code that
performs the same task identically is better, I think
we can't discuss much of anything about code together.

Any printk related mechanism is not fast-path so any
icache dilution isn't an issue.

> That said, I'm not arguing against this patch as such. Making things
> smaller "just because" usually doesn't cause problems.

It seems more like you haven't read the patch.

>  But I was
> hoping that we might be after some more tangible gains here, and
> thus pointed out that there may be a better way to achieve even
> bigger gains.

Sure, it's just any such a discussion should not affect
this patch being applied.

This patch reduces the argument count of the drm_printk
(now drm_dbg) call and so is faster to execute even if
the emit test is internal to the drm_dbg function.

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

Re: [PATCH] [v3] gpu: ipu-v3: prg: avoid possible array underflow

[Philipp Zabel]

Hi Arnd,

On Thu, 2018-03-15 at 17:19 +0100, Arnd Bergmann wrote:
> gcc-8 reports that we access an array with a negative index
> in an error case:
> 
> drivers/gpu/ipu-v3/ipu-prg.c: In function 'ipu_prg_channel_disable':
> drivers/gpu/ipu-v3/ipu-prg.c:252:43: error: array subscript -22 is below 
> array bounds of 'struct ipu_prg_channel[3]' [-Werror=array-bounds]
> 
> This moves the range check in front of the first time that
> variable gets used.
> 
> Signed-off-by: Arnd Bergmann 

thank you, I've replaced v2 with this version in imx-drm/fixes.

regards
Philipp

> 
> v1: Originally sent on Dec 4, 2017.
> v2: Sent again on Jan 16, after no reply, Phillipp said it was merged
> v3: Ran into a related problem with CONFIG_UBSAN, sent again fixing both
> ---
>  drivers/gpu/ipu-v3/ipu-prg.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
> index 97b99500153d..83f9dd934a5d 100644
> --- a/drivers/gpu/ipu-v3/ipu-prg.c
> +++ b/drivers/gpu/ipu-v3/ipu-prg.c
> @@ -250,10 +250,14 @@ void ipu_prg_channel_disable(struct ipuv3_channel 
> *ipu_chan)
>  {
>   int prg_chan = ipu_prg_ipu_to_prg_chan(ipu_chan->num);
>   struct ipu_prg *prg = ipu_chan->ipu->prg_priv;
> - struct ipu_prg_channel *chan = >chan[prg_chan];
> + struct ipu_prg_channel *chan;
>   u32 val;
>  
> - if (!chan->enabled || prg_chan < 0)
> + if (prg_chan < 0)
> + return;
> +
> + chan = >chan[prg_chan];
> + if (!chan->enabled)
>   return;
>  
>   pm_runtime_get_sync(prg->dev);
> @@ -280,13 +284,15 @@ int ipu_prg_channel_configure(struct ipuv3_channel 
> *ipu_chan,
>  {
>   int prg_chan = ipu_prg_ipu_to_prg_chan(ipu_chan->num);
>   struct ipu_prg *prg = ipu_chan->ipu->prg_priv;
> - struct ipu_prg_channel *chan = >chan[prg_chan];
> + struct ipu_prg_channel *chan;
>   u32 val;
>   int ret;
>  
>   if (prg_chan < 0)
>   return prg_chan;
>  
> + chan = >chan[prg_chan];
> +
>   if (chan->enabled) {
>   ipu_pre_update(prg->pres[chan->used_pre], *eba);
>   return 0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198985] BUG: KASAN: use-after-free in amdgpu_job_free_cb+0x26/0xb0 [amdgpu]

[bugzilla-daemon]

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

--- Comment #4 from Fredrik (fred...@planet-express.se) ---
I've applied the patch you mentioned above. Is this related or should I open a
new bug?: 

[56091.713961]
==
[56091.714058] BUG: KASAN: use-after-free in
dc_create_stream_for_sink+0x73/0x440 [amdgpu]
[56091.714062] Read of size 8 at addr 88092d66fc68 by task X/490

[56091.714066] CPU: 11 PID: 490 Comm: X Not tainted 4.15.9 #21
[56091.714068] Hardware name: System manufacturer System Product Name/PRIME
X370-PRO, BIOS 3803 01/22/2018
[56091.714069] Call Trace:
[56091.714075]  dump_stack+0x46/0x5a
[56091.714080]  print_address_description+0x82/0x2c0
[56091.714084]  kasan_report+0x289/0x380
[56091.714175]  ? dc_create_stream_for_sink+0x73/0x440 [amdgpu]
[56091.714265]  dc_create_stream_for_sink+0x73/0x440 [amdgpu]
[56091.714357]  create_stream_for_sink+0xe5/0x7c0 [amdgpu]
[56091.714451]  ? fill_stream_properties_from_drm_display_mode+0x400/0x400
[amdgpu]
[56091.714454]  ? kasan_kmalloc+0xb0/0xf0
[56091.714458]  ? drm_legacy_ioremapfree+0xd0/0xd0
[56091.714461]  ? drm_atomic_commit+0x2d/0xb0
[56091.714465]  ? drm_atomic_helper_legacy_gamma_set+0x190/0x1e0
[56091.714469]  ? drm_mode_gamma_set_ioctl+0x28a/0x320
[56091.714473]  ? drm_atomic_get_connector_state+0xaa/0x2a0
[56091.714565]  dm_update_crtcs_state+0x1d2/0x5e0 [amdgpu]
[56091.714569]  ? drm_atomic_get_crtc_state+0x76/0x1d0
[56091.714660]  ? dc_resource_state_copy_construct+0x199/0x1d0 [amdgpu]
[56091.714759]  amdgpu_dm_atomic_check+0x24b/0x6d0 [amdgpu]
[56091.714764]  ? __radix_tree_replace+0x95/0x150
[56091.714766]  ? node_tag_clear+0x66/0xb0
[56091.714859]  ? dm_update_planes_state.part.28+0x1150/0x1150 [amdgpu]
[56091.714862]  ? __mutex_lock_interruptible_slowpath+0x1/0x10
[56091.714865]  ? __fprop_inc_percpu_max+0x180/0x180
[56091.714869]  drm_atomic_check_only+0x6b8/0x940
[56091.714872]  ? drm_legacy_ioremapfree+0xd0/0xd0
[56091.714876]  ? drm_atomic_set_crtc_for_connector+0x1d0/0x1d0
[56091.714878]  ? drm_mode_object_get+0x51/0x70
[56091.714882]  drm_atomic_commit+0x2d/0xb0
[56091.714886]  drm_atomic_helper_legacy_gamma_set+0x190/0x1e0
[56091.714889]  ? drm_atomic_helper_update_plane+0x1a0/0x1a0
[56091.714892]  drm_mode_gamma_set_ioctl+0x28a/0x320
[56091.714896]  ? drm_crtc_enable_color_mgmt+0x140/0x140
[56091.714899]  ? drm_legacy_ioremapfree+0xd0/0xd0
[56091.714902]  ? drm_lease_owner+0x15/0x30
[56091.714905]  ? drm_crtc_enable_color_mgmt+0x140/0x140
[56091.714908]  drm_ioctl_kernel+0xaf/0x120
[56091.714911]  drm_ioctl+0x4bf/0x570
[56091.714915]  ? drm_crtc_enable_color_mgmt+0x140/0x140
[56091.714917]  ? drm_ioctl_kernel+0x120/0x120
[56091.714922]  ? set_current_blocked+0x20/0x20
[56091.714924]  ? get_signal+0x5c8/0x760
[56091.714927]  ? memset+0x2d/0x50
[56091.714930]  ? fpstate_init+0x6c/0x80
[56091.714933]  ? fpu__initialize+0x1c/0x50
[56091.714936]  ? __fpu__restore_sig+0x327/0x510
[56091.714940]  do_vfs_ioctl+0x155/0x920
[56091.714943]  ? ioctl_preallocate+0x140/0x140
[56091.714945]  ? recalc_sigpending_tsk+0x95/0xa0
[56091.714948]  ? recalc_sigpending+0x12/0x20
[56091.714950]  ? do_sigaltstack+0x1d0/0x270
[56091.714955]  ? SyS_futex+0x1be/0x250
[56091.714959]  ? __rcu_read_unlock+0x76/0xa0
[56091.714961]  ? __fget+0xc2/0x100
[56091.714964]  SyS_ioctl+0x47/0x90
[56091.714967]  ? do_vfs_ioctl+0x920/0x920
[56091.714970]  do_syscall_64+0xf3/0x2b0
[56091.714974]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[56091.714976] RIP: 0033:0x7f3385a95397
[56091.714978] RSP: 002b:7ffe5b715608 EFLAGS: 0246 ORIG_RAX:
0010
[56091.714982] RAX: ffda RBX: 55cc1d92d2a0 RCX:
7f3385a95397
[56091.714984] RDX: 7ffe5b715640 RSI: c02064a5 RDI:
000c
[56091.714985] RBP: 7ffe5b715640 R08: 55cc1d92d960 R09:
55cc1d92db60
[56091.714987] R10: 0001 R11: 0246 R12:
c02064a5
[56091.714989] R13: 000c R14: 55cc1d92b130 R15:
55cc1d92d760

[56091.714992] Allocated by task 490:
[56091.714996]  kasan_kmalloc+0xb0/0xf0
[56091.715086]  dc_sink_create+0x41/0x140 [amdgpu]
[56091.715178]  create_stream_for_sink+0x6a7/0x7c0 [amdgpu]
[56091.715270]  dm_update_crtcs_state+0x1d2/0x5e0 [amdgpu]
[56091.715362]  amdgpu_dm_atomic_check+0x24b/0x6d0 [amdgpu]
[56091.715365]  drm_atomic_check_only+0x6b8/0x940
[56091.715367]  drm_atomic_commit+0x2d/0xb0
[56091.715370]  drm_atomic_connector_commit_dpms+0x1ea/0x210
[56091.715373]  drm_mode_obj_set_property_ioctl+0x2fb/0x410
[56091.715376]  drm_mode_connector_property_set_ioctl+0xb5/0xf0
[56091.715378]  drm_ioctl_kernel+0xaf/0x120
[56091.715381]  drm_ioctl+0x4bf/0x570
[56091.715383]  do_vfs_ioctl+0x155/0x920
[56091.715385]  SyS_ioctl+0x47/0x90
[56091.715387]  do_syscall_64+0xf3/0x2b0
[56091.715390]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2

[56091.715392] Freed by task 112:
[56091.715395]  kasan_slab_free+0x7c/0xe0
[56091.715397]  kfree+0x91/0x1a0

Re: rfc: remove print_vma_addr ? (was Re: [PATCH 00/16] remove eight obsolete architectures)

[Joe Perches]

On Thu, 2018-03-15 at 10:08 -0700, Matthew Wilcox wrote:
> On Thu, Mar 15, 2018 at 09:56:46AM -0700, Joe Perches wrote:
> > I have a patchset that creates a vsprintf extension for
> > print_vma_addr and removes all the uses similar to the
> > print_symbol() removal.
> > 
> > This now avoids any possible printk interleaving.
> > 
> > Unfortunately, without some #ifdef in vsprintf, which
> > I would like to avoid, it increases the nommu kernel
> > size by ~500 bytes.
> > 
> > Anyone think this is acceptable?
[]
> This doesn't feel like a huge win since it's only called ~once per
> architecture.  I'd be more excited if it made the printing of the whole
> thing standardised; eg we have a print_fault() function in mm/memory.c
> which takes a suitable set of arguments.

Sure but perhaps that's not feasible as the surrounding output
is per-arch specific.

What could be a standardized fault message here?

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

rfc: remove print_vma_addr ? (was Re: [PATCH 00/16] remove eight obsolete architectures)

[Joe Perches]

On Thu, 2018-03-15 at 10:48 +0100, Geert Uytterhoeven wrote:
> Hi David,
> 
> On Thu, Mar 15, 2018 at 10:42 AM, David Howells  wrote:
> > Do we have anything left that still implements NOMMU?
> 
> Sure: arm, c6x, m68k, microblaze, and  sh.

I have a patchset that creates a vsprintf extension for
print_vma_addr and removes all the uses similar to the
print_symbol() removal.

This now avoids any possible printk interleaving.

Unfortunately, without some #ifdef in vsprintf, which
I would like to avoid, it increases the nommu kernel
size by ~500 bytes.

Anyone think this is acceptable?

Here's the overall patch, but I have it as a series
---
 Documentation/core-api/printk-formats.rst |  9 +
 arch/arm64/kernel/traps.c | 13 +++
 arch/mips/mm/fault.c  | 16 -
 arch/parisc/mm/fault.c| 15 
 arch/riscv/kernel/traps.c | 11 +++---
 arch/s390/mm/fault.c  |  7 ++--
 arch/sparc/mm/fault_32.c  |  8 ++---
 arch/sparc/mm/fault_64.c  |  8 ++---
 arch/tile/kernel/signal.c |  9 ++---
 arch/um/kernel/trap.c | 13 +++
 arch/x86/kernel/signal.c  | 10 ++
 arch/x86/kernel/traps.c   | 18 --
 arch/x86/mm/fault.c   | 12 +++
 include/linux/mm.h|  1 -
 lib/vsprintf.c| 58 ++-
 mm/memory.c   | 33 --
 16 files changed, 112 insertions(+), 129 deletions(-)

diff --git a/Documentation/core-api/printk-formats.rst 
b/Documentation/core-api/printk-formats.rst
index 934559b3c130..10a91da1bc83 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -157,6 +157,15 @@ DMA address types dma_addr_t
 For printing a dma_addr_t type which can vary based on build options,
 regardless of the width of the CPU data path.
 
+VMA name and address
+
+
+::
+
+   %pav[hexstart+hexsize] or ?[0+0] if unavailable
+
+For any address, print the vma's name and its starting address and size
+
 Passed by reference.
 
 Raw buffer as an escaped string
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 2b478565d774..48edf812ce8b 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -242,13 +242,14 @@ void arm64_force_sig_info(struct siginfo *info, const 
char *str,
if (!show_unhandled_signals_ratelimited())
goto send_sig;
 
-   pr_info("%s[%d]: unhandled exception: ", tsk->comm, task_pid_nr(tsk));
if (esr)
-   pr_cont("%s, ESR 0x%08x, ", esr_get_class_string(esr), esr);
-
-   pr_cont("%s", str);
-   print_vma_addr(KERN_CONT " in ", regs->pc);
-   pr_cont("\n");
+   pr_info("%s[%d]: unhandled exception: %s, ESR 0x%08x, %s in 
%pav\n",
+   tsk->comm, task_pid_nr(tsk),
+   esr_get_class_string(esr), esr,
+   str, >pc);
+   else
+   pr_info("%s[%d]: unhandled exception: %s in %pav\n",
+   tsk->comm, task_pid_nr(tsk), str, >pc);
__show_regs(regs);
 
 send_sig:
diff --git a/arch/mips/mm/fault.c b/arch/mips/mm/fault.c
index 4f8f5bf46977..ce7bf077a0f5 100644
--- a/arch/mips/mm/fault.c
+++ b/arch/mips/mm/fault.c
@@ -213,14 +213,14 @@ static void __kprobes __do_page_fault(struct pt_regs 
*regs, unsigned long write,
tsk->comm,
write ? "write access to" : "read access from",
field, address);
-   pr_info("epc = %0*lx in", field,
-   (unsigned long) regs->cp0_epc);
-   print_vma_addr(KERN_CONT " ", regs->cp0_epc);
-   pr_cont("\n");
-   pr_info("ra  = %0*lx in", field,
-   (unsigned long) regs->regs[31]);
-   print_vma_addr(KERN_CONT " ", regs->regs[31]);
-   pr_cont("\n");
+   pr_info("epc = %0*lx in %pav\n",
+   field,
+   (unsigned long)regs->cp0_epc,
+   >cp0_epc);
+   pr_info("ra  = %0*lx in %pav\n",
+   field,
+   (unsigned long)regs->regs[31],
+   >regs[31]);
}
current->thread.trap_nr = (regs->cp0_cause >> 2) & 0x1f;
info.si_signo = SIGSEGV;
diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
index e247edbca68e..877cea702714 100644
--- a/arch/parisc/mm/fault.c
+++ b/arch/parisc/mm/fault.c
@@ -240,17 +240,14 @@ show_signal_msg(struct pt_regs *regs, unsigned long 

[PATCH v2] drm/tegra: plane: Keep 'dependent' blending state of unaffected planes

[Dmitry Osipenko]

This way new state takes into account the current state of unaffected
(by the atomic commit) planes.

Signed-off-by: Dmitry Osipenko 
---

v2: Dropped unrelated 'cleanup' changes and fixed
s/state->dependent[i]/state->dependent[index]/ typo.

 drivers/gpu/drm/tegra/plane.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
index fc37dcf8c458..0784422cc5a2 100644
--- a/drivers/gpu/drm/tegra/plane.c
+++ b/drivers/gpu/drm/tegra/plane.c
@@ -315,9 +315,6 @@ void tegra_plane_check_dependent(struct tegra_plane *tegra,
unsigned int zpos[2];
unsigned int i;
 
-   for (i = 0; i < 3; i++)
-   state->dependent[i] = false;
-
for (i = 0; i < 2; i++)
zpos[i] = 0;
 
@@ -331,6 +328,8 @@ void tegra_plane_check_dependent(struct tegra_plane *tegra,
 
index = tegra_plane_get_overlap_index(tegra, p);
 
+   state->dependent[index] = false;
+
/*
 * If any of the other planes is on top of this plane and uses
 * a format with an alpha component, mark this plane as being
-- 
2.16.1

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

Re: [PATCH v1 1/3] drm/tegra: plane: Fix RGB565 plane format on older Tegra's

[Dmitry Osipenko]

On 15.03.2018 15:48, Dmitry Osipenko wrote:
> On 15.03.2018 13:27, Thierry Reding wrote:
>> On Thu, Mar 15, 2018 at 04:00:23AM +0300, Dmitry Osipenko wrote:
>>> Simplify opaque format adjustment by removing format checking. There are
>>> only 4 formats that require the adjustment and so this way is less error
>>> prone, avoiding mishandling native formats, like in this case RGB565 is
>>> the format that was erroneously treated as invalid.
>>>
>>> Fixes: ebae8d07435a ("drm/tegra: dc: Implement legacy blending")
>>> Signed-off-by: Dmitry Osipenko 
>>> ---
>>>  drivers/gpu/drm/tegra/dc.c| 11 ++-
>>>  drivers/gpu/drm/tegra/plane.c | 21 ++---
>>>  drivers/gpu/drm/tegra/plane.h |  2 +-
>>>  3 files changed, 9 insertions(+), 25 deletions(-)
>>
>> I've applied a slightly different version of this which doesn't rework
>> as much of the surrounding code and is therefore easier to backport to
>> v4.16.
> 
> Okay. Please don't forget to push the modified patch, I don't see it in the 
> FDO git.

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

Re: [PATCH 00/16] remove eight obsolete architectures

[Hannes Reinecke]

On 03/15/2018 10:42 AM, David Howells wrote:
> Do we have anything left that still implements NOMMU?
> 
RISC-V ?
(evil grin :-)

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle

[Jacopo Mondi]

The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS
decoder, connected to the on-chip LVDS encoder output on one side
and to HDMI encoder ADV7511w on the other one.

As the decoder does not need any configuration it has been so-far
omitted from DTS. Now that a driver is available, describe it in DT
as well.

Signed-off-by: Jacopo Mondi 
---
 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 +++---
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts 
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index c0fd144..69f43b8 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -42,6 +42,33 @@
};
};
};
+
+   thc63lvd1024: lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   thc63lvd1024_in_0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2{
+   reg = <2>;
+
+   thc63lvd1024_out_2: endpoint {
+   remote-endpoint = <_in>;
+   };
+
+   };
+
+   };
+   };
 };
 
  {
@@ -98,7 +125,7 @@
port@0 {
reg = <0>;
adv7511_in: endpoint {
-   remote-endpoint = <_out>;
+   remote-endpoint = <_out_2>;
};
};
 
@@ -152,8 +179,8 @@
 
ports {
port@1 {
-   endpoint {
-   remote-endpoint = <_in>;
+   lvds0_out: endpoint {
+   remote-endpoint = <_in_0>;
};
};
};
-- 
2.7.4

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

Re: [PATCH 2/3] drm: Make sure at least one plane supports the fb format

[Ville Syrjälä]

On Thu, Mar 15, 2018 at 10:42:17AM -0700, Eric Anholt wrote:
> Ville Syrjala  writes:
> 
> > From: Ville Syrjälä 
> >
> > To make life easier for drivers, let's have the core check that the
> > requested pixel format is supported by at least one plane when creating
> > a new framebuffer.
> >
> > This eases the burden on drivers by making sure they'll never get
> > requests to create fbs with unsupported pixel formats. Thanks to the
> > new .fb_modifier() hook this check can now be done whether the request
> > specifies the modifier directly or driver has to deduce it from the
> > gem bo tiling (or via any other method really).
> >
> > v0: Accept anyformat if the driver doesn't do planes (Eric)
> > s/planes_have_format/any_plane_has_format/ (Eric)
> > Check the modifier as well since we already have a function
> > that does both
> > v3: Don't do the check in the core since we may not know the
> > modifier yet, instead export the function and let drivers
> > call it themselves
> > v4: Unexport the functiona and put the format_default check back
> > since this will again be called by the core, ie. undo v3 ;)
> >
> > Cc: Eric Anholt 
> > Testcase: igt/kms_addfb_basic/expected-formats
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_framebuffer.c | 30 ++
> >  1 file changed, 30 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> > b/drivers/gpu/drm/drm_framebuffer.c
> > index 21d3d51eb261..e618a6b728d4 100644
> > --- a/drivers/gpu/drm/drm_framebuffer.c
> > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > @@ -152,6 +152,26 @@ static int fb_plane_height(int height,
> > return DIV_ROUND_UP(height, format->vsub);
> >  }
> >  
> > +static bool any_plane_has_format(struct drm_device *dev,
> > +u32 format, u64 modifier)
> > +{
> > +   struct drm_plane *plane;
> > +
> > +   drm_for_each_plane(plane, dev) {
> > +   /*
> > +* In case the driver doesn't really do
> > +* planes we have to accept any format here.
> > +*/
> > +   if (plane->format_default)
> > +   return true;
> > +
> > +   if (drm_plane_check_pixel_format(plane, format, modifier) == 0)
> > +   return true;
> > +   }
> > +
> > +   return false;
> > +}
> 
> This drm_plane_check_pixel_format() will always fail for VC4's SAND
> modifiers or VC5's UIF modifiers, where we're using the middle 48 bits
> as a bit of metadata (like how we have horizontal stride passed outside
> of the modifier) and you can't list all of the possible values in an
> array on the plane.

Hmm. drm_atomic_plane_check() etc. call this thing as well. How does
that manage to work currently?

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

Re: [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

[Joe Perches]

On Thu, 2018-03-15 at 17:37 +0200, Ville Syrjälä wrote:
> On Thu, Mar 15, 2018 at 08:17:53AM -0700, Joe Perches wrote:
> > On Thu, 2018-03-15 at 17:05 +0200, Ville Syrjälä wrote:
> > > On Thu, Mar 15, 2018 at 03:04:52PM +0100, Maarten Lankhorst wrote:
> > > > Op 15-03-18 om 14:30 schreef Ville Syrjälä:
> > > > > On Tue, Mar 13, 2018 at 03:02:15PM -0700, Joe Perches wrote:
> > > > > > drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary
> > > > > > arguments that can be removed by creating separate functins.
> > > > > > 
> > > > > > Create specific functions for these calls to reduce x86/64 defconfig
> > > > > > size by ~20k.
> > > > > > 
> > > > > > Modify the existing macros to use the specific calls.
> > > > > > 
> > > > > > new:
> > > > > > $ size -t drivers/gpu/drm/built-in.a | tail -1
> > > > > > 1876562   44542 995 1922099  1d5433 (TOTALS)
> > > > > > 
> > > > > > old:
> > > > > > $ size -t drivers/gpu/drm/built-in.a | tail -1
> > > > > > 1897565   44542 995 1943102  1da63e (TOTALS)
> > > > > > 
> > > > > > Miscellanea:
> > > > > > 
> > > > > > o intel_display requires a change to use the specific calls.
> > > > > 
> > > > > How much would we lose if we move the (drm_debug) outside the
> > > > > functions again?
> > 
> > again?
> 
> We used to do that. Someone changed it a while back, unintentially
> I believe.
> 
> > 
> > > > >  I'm somewhat concerned about all the function call
> > > > > overhead when debugs aren't even enabled.
> > 
> > Perhaps better to have compilation elimination
> > of the entire debug output instead.
> 
> That would require every bug reporter to recompile the kernel first.
> So this is not a solution we would ever seriously consider.
> 
> Not sure if it would be possible to use the alternatives thing to
> eliminate the function calls unless the user boots wih drm.debug!=0?
> 
> > 
> > I think you are discussing a different issue and
> > this discussion should not block this patch as
> > this patch has no impact other than code size
> > reduction.
> 
> But what is the goal of the code size reduction?

Smaller code.

> I assume the main
> goal is to make better use of the instruction cache to make the
> code faster. If there's a tradeoff between smaller and slightly
> faster vs. larger and a singificantly faster I tend to think we
> should go for the latter option.

There's no trade-off in this patch for faster/larger.
This patch is simply smaller.  Smaller is better.

Your faster/larger should be a different patch proposal.

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

[PATCH] drm/amdkfd: fix uninitialized variable use

[Arnd Bergmann]

When CONFIG_ACPI is disabled, we never initialize the acpi_table
structure in kfd_create_crat_image_virtual:

drivers/gpu/drm/amd/amdkfd/kfd_crat.c: In function 
'kfd_create_crat_image_virtual':
drivers/gpu/drm/amd/amdkfd/kfd_crat.c:888:40: error: 'acpi_table' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]

The undefined behavior also happens for any other acpi_get_table()
failure, but then the compiler can't warn about it.

This adds an error check that prevents the structure from
being used in error, avoiding both the undefined behavior and
the warning about it.

Fixes: 520b8fb755cc ("drm/amdkfd: Add topology support for CPUs")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
index 7493f47e7fe1..d85112224f1d 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
@@ -882,7 +882,7 @@ static int kfd_create_vcrat_image_cpu(void *pcrat_image, 
size_t *size)
crat_table->length = sizeof(struct crat_header);
 
status = acpi_get_table("DSDT", 0, _table);
-   if (status == AE_NOT_FOUND)
+   if (status != AE_OK)
pr_warn("DSDT table not found for OEM information\n");
else {
crat_table->oem_revision = acpi_table->revision;
-- 
2.9.0

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

Re: [maintainer-tools PATCH] doc: how to become a drm-intel committer

[Daniel Vetter]

On Thu, Mar 15, 2018 at 4:32 PM, Jani Nikula  wrote:
> On Thu, 15 Mar 2018, Daniel Vetter  wrote:
>> On Wed, Mar 14, 2018 at 05:11:02PM +0200, Jani Nikula wrote:
>>> Until now, the drm-intel commit access have been handed out ad hoc,
>>> without transparency, consistency, or fairness. With pressure to add
>>> more committers, this is no longer tenable, if it ever was. Document the
>>> requirements and expectations around becoming a drm-intel committer.
>>>
>>> The Linux kernel operates in a model where, by and large, only
>>> maintainers commit patches. Maintainer teams are no longer rare, but the
>>> drm-intel and drm-misc maintainer/committer model is definitely an
>>> outlier.
>>>
>>> The drm-intel maintainers believe that a reasonable level of experience
>>> and track record of working on the driver, as well as actively engaging
>>> in the community upstream, are necessary before becoming a
>>> committer. While the requirements outlined here may seem strict in
>>> contrast with many projects, they are extremely liberal by kernel
>>> standards.
>>>
>>> Finally, no rules are carved in stone. We fully expect the requirements
>>> to be adjusted later. However, it will be much easier to start strict
>>> and relax the requirements later than the other way round.
>>>
>>> Cc: Gustavo Padovan 
>>> Cc: Maarten Lankhorst 
>>> Cc: Sean Paul 
>>> Cc: Dave Airlie 
>>> Cc: dim-to...@lists.freedesktop.org
>>> Cc: dri-devel@lists.freedesktop.org
>>> Cc: intel-...@lists.freedesktop.org
>>> Signed-off-by: Jani Nikula 
>>> Signed-off-by: Joonas Lahtinen 
>>> Signed-off-by: Rodrigo Vivi 
>>
>> I've chatted for a few hours with Joonas, and I think before we can
>> discuss the proposed document here itself, we first need to reach some
>> agreement on why we even have commit rights. I think there's a very wide
>> range of answers to that questions, and of course with different goals you
>> end up with completely different rules about how to handle commit rights.
>>
>> Joonas suggested we first discuss this internally, perhaps with the
>> maintainers, Kimmo and me.
>
> Fine. I would rather have discussed this transparently out in the
> open. That was, after all, the purpose of sending this out.

This was more or less Joonas' requests after our long discussion (he
did take a quick look at my reply before I sent it out). We can also
have the discussion here, I do have the draft still lying around
somewhere.
-Daniel
-- 
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

[Bug 199123] kernel 4.16rc5 doesnt boot on ryzen 5 2400g due to an amdgpu change

[bugzilla-daemon]

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

--- Comment #6 from david becerra (davidbecerrapor...@gmail.com) ---
(In reply to Harry Wentland from comment #5)
> Created attachment 274755 [details]
> [PATCH] drm/amd/display: Refine disable VGA
> 
> The patch Alex posted might not be enough. Attached patch might be more
> robust.

this patch doesnt seem to work :(
but have in mind that when i applied the patch it said something about a hunk
and offsets
im using the manjaro pkgbuild adding your patch btw

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

Re: fbcon non-desktop display use

[Keith Packard]

Charles Lohr  writes:

> Even if the vive is the only device connected, it will still not permit it
> to be operated.  See https://github.com/linux-sunxi/linux-sunxi/issues/291
> for dri with a lot of debugging turned on.

Oh, it's not supposed to do that. I had intended to write the code so
that if the only device available was a non-desktop device that it would
go ahead and use it. The X server patches did that, but the kernel ones
did not. It looks like that would be an easy patch -- just skip the
non_desktop check in the !strict case for drm_connector_enabled.

However, your patch is a good addition as it will allow you to also
enable the HMD when other monitors are connected.

> I can understand that most users would probably prefer that the vive isn't
> automatically used if no other displays are available, however, the current
> behavior prevents use of the vive on all devices that use fbdev for their
> primary output.

That was definitely not my intention, and thanks for discovering this!

> I've never sent an email to the kernel devel list, so I'm still a little
> nervous.  Especially because this is against a different branch, and I'm
> starting to think that I should be messaging there, but this is something
> that really needs to go upstream.

We'll get it sorted out; I'm not sure what Dave's preference is these
days anyways.

Aside from some minor formatting issues, this patch looks good to me.

> Signed-off-by:

You'll need to add your name and email address here.

> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> b/drivers/gpu/drm/drm_fb_helper.c
> index 035784ddd..8bfaf79ff 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -55,6 +55,11 @@ MODULE_PARM_DESC(drm_fbdev_overalloc,
>  "Overallocation of the fbdev buffer (%) [default="
>  __MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]");
>
> +static bool drm_fbdev_permit_non_desktop;
> +module_param(drm_fbdev_permit_non_desktop, bool, 0644);
> +MODULE_PARM_DESC(drm_fbdev_permit_non_desktop,
> +   "Allow the framebuffer to use non-desktop displays
> [default=off]");
> +

Your email client appears to be wrapping long lines, which breaks the patch.


>  static LIST_HEAD(kernel_fb_helper_list);
>  static DEFINE_MUTEX(kernel_fb_helper_lock);
>
> @@ -2109,7 +2114,7 @@ static bool drm_connector_enabled(struct
> drm_connector *connector, bool strict)
>  {
> bool enable;
>
> -   if (connector->display_info.non_desktop)
> +   if (connector->display_info.non_desktop &&
> !drm_fbdev_permit_non_desktop)

If you added '&& strict' here, it will use the HMD if there aren't any
desktop monitors connected.

-- 
-keith


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

Re: [Intel-gfx] [PATCH 2/3] drm: Make sure at least one plane supports the fb format

[Ville Syrjälä]

On Thu, Mar 15, 2018 at 08:03:44PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 15, 2018 at 07:48:02PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 15, 2018 at 10:42:17AM -0700, Eric Anholt wrote:
> > > Ville Syrjala  writes:
> > > 
> > > > From: Ville Syrjälä 
> > > >
> > > > To make life easier for drivers, let's have the core check that the
> > > > requested pixel format is supported by at least one plane when creating
> > > > a new framebuffer.
> > > >
> > > > This eases the burden on drivers by making sure they'll never get
> > > > requests to create fbs with unsupported pixel formats. Thanks to the
> > > > new .fb_modifier() hook this check can now be done whether the request
> > > > specifies the modifier directly or driver has to deduce it from the
> > > > gem bo tiling (or via any other method really).
> > > >
> > > > v0: Accept anyformat if the driver doesn't do planes (Eric)
> > > > s/planes_have_format/any_plane_has_format/ (Eric)
> > > > Check the modifier as well since we already have a function
> > > > that does both
> > > > v3: Don't do the check in the core since we may not know the
> > > > modifier yet, instead export the function and let drivers
> > > > call it themselves
> > > > v4: Unexport the functiona and put the format_default check back
> > > > since this will again be called by the core, ie. undo v3 ;)
> > > >
> > > > Cc: Eric Anholt 
> > > > Testcase: igt/kms_addfb_basic/expected-formats
> > > > Signed-off-by: Ville Syrjälä 
> > > > ---
> > > >  drivers/gpu/drm/drm_framebuffer.c | 30 ++
> > > >  1 file changed, 30 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> > > > b/drivers/gpu/drm/drm_framebuffer.c
> > > > index 21d3d51eb261..e618a6b728d4 100644
> > > > --- a/drivers/gpu/drm/drm_framebuffer.c
> > > > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > > > @@ -152,6 +152,26 @@ static int fb_plane_height(int height,
> > > > return DIV_ROUND_UP(height, format->vsub);
> > > >  }
> > > >  
> > > > +static bool any_plane_has_format(struct drm_device *dev,
> > > > +u32 format, u64 modifier)
> > > > +{
> > > > +   struct drm_plane *plane;
> > > > +
> > > > +   drm_for_each_plane(plane, dev) {
> > > > +   /*
> > > > +* In case the driver doesn't really do
> > > > +* planes we have to accept any format here.
> > > > +*/
> > > > +   if (plane->format_default)
> > > > +   return true;
> > > > +
> > > > +   if (drm_plane_check_pixel_format(plane, format, 
> > > > modifier) == 0)
> > > > +   return true;
> > > > +   }
> > > > +
> > > > +   return false;
> > > > +}
> > > 
> > > This drm_plane_check_pixel_format() will always fail for VC4's SAND
> > > modifiers or VC5's UIF modifiers, where we're using the middle 48 bits
> > > as a bit of metadata (like how we have horizontal stride passed outside
> > > of the modifier) and you can't list all of the possible values in an
> > > array on the plane.
> > 
> > Hmm. drm_atomic_plane_check() etc. call this thing as well. How does
> > that manage to work currently?
> 
> Maybe it doesn't. I added the modifier checks in
> 
> commit 23163a7d4b032489d375099d56571371c0456980
> Author: Ville Syrjälä 
> AuthorDate: Fri Dec 22 21:22:30 2017 +0200
> Commit: Ville Syrjälä 
> CommitDate: Mon Feb 26 16:29:47 2018 +0200
> 
> drm: Check that the plane supports the request format+modifier combo
> 
> Maybe that broke vc4?
> 
> Hmm. So either we need to stop checking against the modifiers array and
> rely purely or .format_mod_supported(), or we need to somehow get the
> driver to reduce the modifier to its base form. I guess we could make
> .fb_modifier() do that and call it also for addfb with modifiers. And
> I'd need to undo some of the modifier[0] vs. deduced modifier changes
> I did to framebuffer_check(), and we'd need to preserve the original
> modifier in the request for .fb_create(). Oh, but that wouldn't allow
> returning a non-base modifier from .fb_modifuer() for the !modifiers
> case. This is turning slightly more tricky than I had hoped...
> 
> I guess relying on .format_mod_supported() might be what we need to 
> do. Unfortunately it does mean that the .format_mod_supported()
> implementations must be prepared for modifiers that were not
> registered with the plane. Which does feel quite a bit more
> fragile.

And that last apporach would be annoying for i915. So I think the other
apporach is better.

Fortunately it seems your SAND modifiers aren't upstream yet so I didn't
break them :) I had a quick look at your github and it looks like the
first apporach would work.

Something like this is what I had in mind. Loosk 

[PATCH] fbdev: aty: fix missing indentation in if statement

[Colin King]

From: Colin Ian King 

There is a missing indentation following an if statement, fix this.

Detected by Coccinelle:
drivers/video/fbdev/aty/mach64_ct.c:183:2-15: code aligned with
following code on line 184

Signed-off-by: Colin Ian King 
---
 drivers/video/fbdev/aty/mach64_ct.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/aty/mach64_ct.c 
b/drivers/video/fbdev/aty/mach64_ct.c
index 7d3bd723d3d5..74a62aa193c0 100644
--- a/drivers/video/fbdev/aty/mach64_ct.c
+++ b/drivers/video/fbdev/aty/mach64_ct.c
@@ -180,7 +180,7 @@ static int aty_dsp_gt(const struct fb_info *info, u32 bpp, 
struct pll_ct *pll)
dsp_on = ((multiplier << vshift) + divider) / divider;
tmp = ((ras_multiplier << xshift) + ras_divider) / ras_divider;
if (dsp_on < tmp)
-   dsp_on = tmp;
+   dsp_on = tmp;
dsp_on = dsp_on + (tmp * 2) + (pll->xclkpagefaultdelay << 
xshift);
}
 
-- 
2.15.1

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

Re: fbcon non-desktop display use

[Daniel Vetter]

On Thu, Mar 15, 2018 at 9:03 PM, Charles Lohr  wrote:
> To try to address both concerns, it feels easiest to do not in-line.
>
> 1) Just for background: The H3, and many other ARM systems use the
> framebuffer for all video access, 3D accelerated as well as X11. If we
> want to permit HMD (headmount display) or other non-desktop displays
> on these devices are going to be used at all, it seems DRM must be set
> up for them.  I don't think of this as a "feature".

There's no open source 3D stack using fbdev. And I really don't care
much about the others from an upstream pov.

> 2) Although I "wish" there was a way to permit non-desktop use with
> multiple displays, I am having difficulty finding a specific need to
> be able to turn it on/off.  All applications I can imagine with the
> HMD currently would involve the HMD being the only connected device.
> I am still "submitting" the patch with the parameter, however, if you
> folks decide not to accept it, I intend to re-submit with just the &&
> strict fix (which I just tested and it's good!) -- unless you (Keith)
> are willing to put forward the && strict as a patch.

I guess we can do that, but I'll defer to Keith/Dave on this since I'm
firmly meh for trying to get HMDs to show up on fbcon. Doesn't make
sense to me.
-Daniel

> 3) I am trying "plain text mode" for my patch, so hopefully it doesn't
> truncate the lines.  Also, I misunderstood "Signed-off-by" Thanks!
>
> Signed-off-by: Charles Lohr 
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 035784ddd..e14624d0f 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -55,6 +55,11 @@ MODULE_PARM_DESC(drm_fbdev_overalloc,
>  "Overallocation of the fbdev buffer (%) [default="
>  __MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]");
>
> +static bool drm_fbdev_permit_non_desktop;
> +module_param(drm_fbdev_permit_non_desktop, bool, 0644);
> +MODULE_PARM_DESC(drm_fbdev_permit_non_desktop,
> +   "Allow the framebuffer to use non-desktop displays
> [default=off]");
> +
>  static LIST_HEAD(kernel_fb_helper_list);
>  static DEFINE_MUTEX(kernel_fb_helper_lock);
>
> @@ -2109,7 +2114,7 @@ static bool drm_connector_enabled(struct
> drm_connector *connector, bool strict)
>  {
> bool enable;
>
> -   if (connector->display_info.non_desktop)
> +   if (connector->display_info.non_desktop &&
> !drm_fbdev_permit_non_desktop && strict)
> return false;
>
> if (strict)
>
> On Thu, Mar 15, 2018 at 2:30 PM, Keith Packard  wrote:
>> Charles Lohr  writes:
>>
>>> Even if the vive is the only device connected, it will still not permit it
>>> to be operated.  See https://github.com/linux-sunxi/linux-sunxi/issues/291
>>> for dri with a lot of debugging turned on.
>>
>> Oh, it's not supposed to do that. I had intended to write the code so
>> that if the only device available was a non-desktop device that it would
>> go ahead and use it. The X server patches did that, but the kernel ones
>> did not. It looks like that would be an easy patch -- just skip the
>> non_desktop check in the !strict case for drm_connector_enabled.
>>
>> However, your patch is a good addition as it will allow you to also
>> enable the HMD when other monitors are connected.
>>
>>> I can understand that most users would probably prefer that the vive isn't
>>> automatically used if no other displays are available, however, the current
>>> behavior prevents use of the vive on all devices that use fbdev for their
>>> primary output.
>>
>> That was definitely not my intention, and thanks for discovering this!
>>
>>> I've never sent an email to the kernel devel list, so I'm still a little
>>> nervous.  Especially because this is against a different branch, and I'm
>>> starting to think that I should be messaging there, but this is something
>>> that really needs to go upstream.
>>
>> We'll get it sorted out; I'm not sure what Dave's preference is these
>> days anyways.
>>
>> Aside from some minor formatting issues, this patch looks good to me.
>>
>>> Signed-off-by:
>>
>> You'll need to add your name and email address here.
>>
>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>>> b/drivers/gpu/drm/drm_fb_helper.c
>>> index 035784ddd..8bfaf79ff 100644
>>> --- a/drivers/gpu/drm/drm_fb_helper.c
>>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>>> @@ -55,6 +55,11 @@ MODULE_PARM_DESC(drm_fbdev_overalloc,
>>>  "Overallocation of the fbdev buffer (%) [default="
>>>  __MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]");
>>>
>>> +static bool drm_fbdev_permit_non_desktop;
>>> +module_param(drm_fbdev_permit_non_desktop, bool, 0644);
>>> +MODULE_PARM_DESC(drm_fbdev_permit_non_desktop,
>>> +   "Allow the framebuffer to use non-desktop displays
>>> [default=off]");
>>> +
>>
>> Your email client appears to be wrapping long 

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

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

--- Comment #39 from sh...@tuta.io ---
I booted the stock kernel with nosmp few times. One time - gray, other times -
black. I wonder if the initialization code could be preempted and the race
still occurs on a single CPU. Otherwise, it may be a race with GPU. Maybe need
to wait for a previous command to complete.

What to try next?

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

[Bug 105533] [r600g] Trying UVD causes my system crash and hang on RV730

[bugzilla-daemon]

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

Bug ID: 105533
   Summary: [r600g] Trying UVD causes my system crash and hang on
RV730
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ken20...@ukr.net
QA Contact: dri-devel@lists.freedesktop.org

Trying UVD causes my system crash and hang on my RV730. Unfortunately I was not
able to get any backtrace logs after rebooting cause it is not saves.

I tried:

mpv -vo vdpau -hwdec=vdpau
mpt -vo vaapi -hwdec=vaapi

it starts to play for a second but then display becomes black and only hardware
reset can reanimate my system.

Kubuntu 18.04
Linux: 4.15.0-12-generic x86_64
mesa-vdpau-drivers: 18.0.0~rc4-1ubuntu3
libva2: 2.1.0-1

$ lspci | grep -i vga
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV730
XT [Radeon HD 4670]

$ glxinfo | grep -i version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Version: 18.0.0
Max core profile version: 3.3
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0
OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.0.0-rc4
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.0 Mesa 18.0.0-rc4
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 18.0.0-rc4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

-- 
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 105532] Broken map generation in Northgard game

[bugzilla-daemon]

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

Bug ID: 105532
   Summary: Broken map generation in Northgard game
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: alexan...@tsoy.me
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 138148
  --> https://bugs.freedesktop.org/attachment.cgi?id=138148=edit
northgard_screenshot.png

Map generation is broken in Northgard game in single player mode. See
screenshot. Game developers describe map generation process as follows [1]:
"The game rendering seems to be working fine, only map generation seems to be
broken on some drivers. This involves rendering 2D vectorized shapes and then
reading back the resulting graphics buffer. Nothing fancy, but we had some
issues in OpenGL with some Intel HD drivers on Windows in the past. Using
DirectX (same code, just different driver) did fix the issue for these users."

Map generation is working fine with llvmpipe driver
(LIBGL_ALWAYS_SOFTWARE=true).

OpenGL renderer string: AMD Radeon (TM) R9 380 Series (TONGA / DRM 3.19.0 /
4.14.26-gentoo, LLVM 6.0.0)

[1]
http://steamcommunity.com/app/466560/discussions/0/1698293255121560931/?ctp=4#c1698293255133166837

-- 
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 105532] Broken map generation in Northgard game

[bugzilla-daemon]

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

--- Comment #1 from Alexander Tsoy  ---
Also very often map generation process just hangs or repeat many times
(according to the progress bar).

-- 
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 1/8] clk: Add clk_bulk_alloc functions

[Stephen Boyd]

Quoting Marek Szyprowski (2018-02-20 01:36:03)
> Hi Robin,
> 
> On 2018-02-19 17:29, Robin Murphy wrote:
> >
> > Seeing how every subsequent patch ends up with the roughly this same 
> > stanza:
> >
> > x = devm_clk_bulk_alloc(dev, num, names);
> > if (IS_ERR(x)
> >     return PTR_ERR(x);
> > ret = devm_clk_bulk_get(dev, x, num);
> >
> > I wonder if it might be better to simply implement:
> >
> > int devm_clk_bulk_alloc_get(dev, , num, names)
> >
> > that does the whole lot in one go, and let drivers that want to do 
> > more fiddly things continue to open-code the allocation.
> >
> > But perhaps that's an abstraction too far... I'm not all that familiar 
> > with the lie of the land here.
> 
> Hmmm. This patchset clearly shows, that it would be much simpler if we
> get rid of clk_bulk_data structure at all and let clk_bulk_* functions
> to operate on struct clk *array[]. Typically the list of clock names
> is already in some kind of array (taken from driver data or statically
> embedded into driver), so there is little benefit from duplicating it
> in clk_bulk_data. Sadly, I missed clk_bulk_* api discussion and maybe
> there are other benefits from this approach.
> 
> If not, I suggest simplifying clk_bulk_* api by dropping clk_bulk_data
> structure and switching to clock ptr array:
> 
> int clk_bulk_get(struct device *dev, int num_clock, struct clk *clocks[],
>               const char *clk_names[]);
> int clk_bulk_prepare(int num_clks, struct clk *clks[]);
> int clk_bulk_enable(int num_clks, struct clk *clks[]);
> ...
> 

If you have an array of pointers to names of clks then we can put the
struct clk pointers adjacent to them at the same time. I suppose the
problem there is that some drivers want to mark that array of pointers
to names as const. And then we can't update the clk pointers next to
them.

This is the same design that regulators has done so that's why it's
written like this for clks. Honestly, we're talking about a handful of
pointers here so I'm not sure it really matters much. Just duplicate the
pointer and be done if you want to mark the array of names as const or
have your const 'setup' structure point to the bulk_data array that you
define statically non-const somewhere globally.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105534] amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it

[bugzilla-daemon]

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

Bug ID: 105534
   Summary: amdgpu cannot set 2560x1440@60 mode even though
monitor,gpu and motherboard support it
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: philipmor...@gmail.com

Hardware:
Raven Ridge 2200G
Asrock A320M-HDV. Manual states max resolution for DVI 1920x1200@60 which is
single link, however the board's DVI socket is clearly dual link.
Monex WQHD which is known to work @ 2560x1440@60 with reduced blanking since it
works on Intel Haswell with the i915 drivers. This monitor has only one input,
which is dual link DVI. See below for edid-decode output.
Dual channel DVI-D cable.
This is a dual monitor setup. The other monitor is 1920x1080 over VGA/D-SUB.

Software:
ubuntu bionic beaver with linux kernel 4.16.0-rc5+ and
ppa:oibaf/graphics-drivers
/lib/firmware/amdgpu/raven_gpu_info.bin is present (316 bytes).
No customisation of xorg configuration files.

Possibly related bug reports:
https://bugs.freedesktop.org/show_bug.cgi?id=102820
https://bugs.freedesktop.org/show_bug.cgi?id=104412

$ xrandr --newmode "2560x1440_60R"  241.50  2560 2608 2640 2720  1440 1443 1448
1481 +hsync -vsync
$ xrandr --addmode HDMI-A-2  "2560x1440_60R"
$ xrandr --output HDMI-A-2 --mode "2560x1440_60R" --verbose
crtc 1: 2560x1440_60R  59.95 +0+0 "HDMI-A-2"
xrandr: Configure crtc 1 failed
crtc 0: disable
crtc 1: disable
crtc 2: disable
crtc 3: disable
screen 0: revert
crtc 0: revert
crtc 1: revert
crtc 2: revert
crtc 3: revert
$ xrandr
Screen 0: minimum 320 x 200, current 4480 x 1440, maximum 16384 x 16384
DisplayPort-0 connected primary 1920x1080+2560+360 (normal left inverted right
x axis y axis) 478mm x 269mm
   1920x1080 60.00*+
   1680x1050 59.95  
   1280x1024 75.02  
   1440x900  74.9859.89  
   1280x960  60.00  
   1280x800  59.81  
   1152x864  75.00  
   1280x720  60.00  
   1152x720  59.97  
   1024x768  75.0370.0760.00  
   832x624   74.55  
   800x600   72.1975.0060.3256.25  
   640x480   75.0072.8166.6759.94  
   720x400   70.08  
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
HDMI-A-1 disconnected (normal left inverted right x axis y axis)
HDMI-A-2 connected (normal left inverted right x axis y axis)
   2560x1440_60R  59.95  

I've been running with drm.debug=0xf and searching log files but am unable to
find any helpful error message.

$ edid-decode /sys/class/drm/card0-HDMI-A-3/edid
Extracted contents:
header:  00 ff ff ff ff ff ff 00
serial number:   12 ed fa 00 00 00 00 00 28 15
version: 01 03
basic params:a5 3c 22 78 22
chroma info: 6f b1 a7 55 4c 9e 25 0c 50 54
established: 00 00 00
standard:01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:56 5e 00 a0 a0 a0 29 50 30 20 35 00 55 50 21 00 00 1a
descriptor 2:00 00 00 fc 00 51 48 44 32 37 30 0a 20 20 20 20 20 20
descriptor 3:00 00 00 fc 00 0a 20 20 20 20 20 20 20 20 20 20 20 20
descriptor 4:00 00 00 fc 00 0a 20 20 20 20 20 20 20 20 20 20 20 20
extensions:  00
checksum:8a

Manufacturer: DWM Model fa Serial Number 0
Made week 40 of 2011
EDID version: 1.3
Digital display
DFP 1.x compatible TMDS
Maximum image size: 60 cm x 34 cm
Gamma: 2.20
DPMS levels: Off
Supported color formats: RGB 4:4:4
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed mode: Clock 241.500 MHz, 597 mm x 336 mm
   2560 2608 2640 2720 hborder 0
   1440 1443 1448 1481 vborder 0
   +hsync -vsync 
Monitor name: QHD270
Checksum: 0x8a (valid)
EDID block does NOT conform to EDID 1.3!
Digital display field contains garbage: 24
Missing monitor ranges

-- 
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/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[matthew . s . atwood]

From: Matt Atwood 

DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.

With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.

To avoid breaking panels that are not spec compiant we now warn on
invalid values.

V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes
V5: typo
V6: print statement revisions, DP_REV to DPCD_REV, comment correction
V7: typo
V8: Style

Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/drm_dp_helper.c | 22 ++
 include/drm/drm_dp_helper.h |  6 ++
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..6bee2df 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,32 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
 
 void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+ DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
+ rd_interval);
+
+   if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DPCD_REV_14)
udelay(100);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
 void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+ DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
+ rd_interval);
+
+   if (rd_interval == 0)
udelay(400);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..8c59ce4 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,11 @@
 /* AUX CH addresses */
 /* DPCD */
 #define DP_DPCD_REV 0x000
+# define DPCD_REV_100x10
+# define DPCD_REV_110x11
+# define DPCD_REV_120x12
+# define DPCD_REV_130x13
+# define DPCD_REV_140x14
 
 #define DP_MAX_LINK_RATE0x001
 
@@ -118,6 +123,7 @@
 # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
 
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */
 
 #define DP_ADAPTER_CAP 0x00f   /* 1.2 */
 # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
-- 
2.7.4

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

[PULL] drm-intel-fixes

[Rodrigo Vivi]

Hi Dave,

Sorry for the last minute and for sending 2 pull requests
in a short time, but we just got a pull request from GVT.

It passes our CI-fast-feedback and the full run is still
running.

Please if we still have time please consider pulling it,
otherwise this will be part of next regular one.

Here goes drm-intel-fixes-2018-03-15:

Only GVT fixes:
- Two warnings fix for runtime pm and usr copy (Xiong, Zhenyu)
- OA context fix for vGPU profiling (Min)
- privilege batch buffer reloc fix (Fred)

Thanks,
Rodrigo.

The following changes since commit 0c8efd610b58cb23cefdfa12015799079aef94ae:

  Linux 4.16-rc5 (2018-03-11 17:25:09 -0700)

are available in the git repository at:

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

for you to fetch changes up to 05b429a8eed83084a8a7fc04c97120a5ba07b5be:

  Merge tag 'gvt-fixes-2018-03-15' of https://github.com/intel/gvt-linux into 
drm-intel-fixes (2018-03-15 15:37:57 -0700)


Only GVT fixes:
- Two warnings fix for runtime pm and usr copy (Xiong, Zhenyu)
- OA context fix for vGPU profiling (Min)
- privilege batch buffer reloc fix (Fred)


Chris Wilson (2):
  drm/i915: Only prune fences after wait-for-all
  drm/i915: Kick the rps worker when changing the boost frequency

Min He (1):
  drm/i915/gvt: keep oa config in shadow ctx

Mustamin B Mustaffa (1):
  drm/i915: Enable VBT based BL control for DP

Rodrigo Vivi (1):
  Merge tag 'gvt-fixes-2018-03-15' of https://github.com/intel/gvt-linux 
into drm-intel-fixes

Xiong Zhang (1):
  drm/i915/gvt: Add runtime_pm_get/put into gvt_switch_mmio

Zhenyu Wang (1):
  drm/i915/gvt: fix user copy warning by whitelist workload rb_tail field

fred gao (1):
  drm/i915/gvt: Correct the privilege shadow batch buffer address

 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  8 
 drivers/gpu/drm/i915/gvt/mmio_context.c |  2 +
 drivers/gpu/drm/i915/gvt/scheduler.c| 71 +++--
 drivers/gpu/drm/i915/gvt/scheduler.h|  5 +++
 drivers/gpu/drm/i915/i915_gem.c | 16 ++--
 drivers/gpu/drm/i915/i915_sysfs.c   | 10 -
 drivers/gpu/drm/i915/intel_dp.c | 10 ++---
 7 files changed, 105 insertions(+), 17 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105018] Kernel panic when waking up after screen goes blank.

[bugzilla-daemon]

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

--- Comment #22 from L.S.S.  ---
It seems some of the patches (1, 2, and 4) have entered the 4.16 kernel, from
what I can tell when building the kernel for Manjaro, where these three patches
got rejected, and the exact code changes were found in the original kernel code
files.

However, after some testing I found out that the patch 3 (which is not
included) is still needed for 4.16 to fix this the problem, as I can still
crash the system without it.

-- 
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 105534] amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|NEW |RESOLVED

--- Comment #1 from Alex Deucher  ---
Please attach your dmesg output.  Note that Raven does not support dual-link
DVI.  There is only a single digital encoder connected to each connector on the
motherboards.  You need two encoders (one for each link) per connector to run
dual link DVI.  You need to use native DP or HDMI for high res modes.

-- 
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: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Rodrigo Vivi]

On Thu, Mar 15, 2018 at 02:08:51PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
> 
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
> 
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
> 
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
> V4: style changes
> V5: typo
> V6: print statement revisions, DP_REV to DPCD_REV, comment correction
> V7: typo
> V8: Style

thanks :)

> 
> Signed-off-by: Matt Atwood 

Reviewed-by: Rodrigo Vivi 



> ---
>  drivers/gpu/drm/drm_dp_helper.c | 22 ++
>  include/drm/drm_dp_helper.h |  6 ++
>  2 files changed, 24 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..6bee2df 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -119,18 +119,32 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
> link_status[DP_LINK_STATUS_SI
>  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>  
>  void drm_dp_link_train_clock_recovery_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> +   DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
> +   rd_interval);
> +
> + if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DPCD_REV_14)
>   udelay(100);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>  
>  void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) 
> {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> +   DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
> +   rd_interval);
> +
> + if (rd_interval == 0)
>   udelay(400);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>  
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index da58a42..8c59ce4 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -64,6 +64,11 @@
>  /* AUX CH addresses */
>  /* DPCD */
>  #define DP_DPCD_REV 0x000
> +# define DPCD_REV_100x10
> +# define DPCD_REV_110x11
> +# define DPCD_REV_120x12
> +# define DPCD_REV_130x13
> +# define DPCD_REV_140x14
>  
>  #define DP_MAX_LINK_RATE0x001
>  
> @@ -118,6 +123,7 @@
>  # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher 
> */
>  
>  #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> +# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */
>  
>  #define DP_ADAPTER_CAP   0x00f   /* 1.2 */
>  # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm 5/5] intel: purge cached bucket when its cached buffer is evicted

[James Xiong]

From: "Xiong, James" 

Previously when a cached MRU buffer was found to be evicted by kernel,
the bucket was emptied. The new implementation purged these buffers that
were freed before the evicted one.

Signed-off-by: Xiong, James 
---
 intel/intel_bufmgr_gem.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index e3d5a8d..69b361b 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -684,22 +684,20 @@ drm_intel_gem_bo_madvise(drm_intel_bo *bo, int madv)
 madv);
 }
 
-/* drop the oldest entries that have been purged by the kernel */
+/* drop the entries that are older than the given time */
 static void
 drm_intel_gem_bo_cache_purge_bucket(drm_intel_bufmgr_gem *bufmgr_gem,
-   struct drm_intel_gem_bo_bucket *bucket)
+   struct drm_intel_gem_bo_bucket *bucket,
+   time_t time)
 {
-   while (!DRMLISTEMPTY(>head)) {
-   drm_intel_bo_gem *bo_gem;
-
-   bo_gem = DRMLISTENTRY(drm_intel_bo_gem,
- bucket->head.next, head);
-   if (drm_intel_gem_bo_madvise_internal
-   (bufmgr_gem, bo_gem, I915_MADV_DONTNEED))
-   break;
-
-   DRMLISTDEL(_gem->head);
-   drm_intel_gem_bo_free(_gem->bo);
+   drm_intel_bo_gem *bo_gem, *temp;
+   DRMLISTFOREACHENTRYSAFE(bo_gem, temp, >head, head) {
+   if (bo_gem->free_time >= time) {
+   drm_intel_gem_bo_madvise_internal
+   (bufmgr_gem, bo_gem, I915_MADV_DONTNEED);
+   DRMLISTDEL(_gem->head);
+   drm_intel_gem_bo_free(_gem->bo);
+   }
}
 }
 
@@ -753,9 +751,10 @@ retry:
if (bo_gem) {
if (!drm_intel_gem_bo_madvise_internal
(bufmgr_gem, bo_gem, I915_MADV_WILLNEED)) {
-   drm_intel_gem_bo_free(_gem->bo);
drm_intel_gem_bo_cache_purge_bucket(bufmgr_gem,
-   bucket);
+   bucket,
+   
bo_gem->free_time);
+   drm_intel_gem_bo_free(_gem->bo);
return NULL;
}
 
-- 
2.7.4

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

[Bug 105401] Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed

[bugzilla-daemon]

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

Timothy Pearson  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEEDINFO|RESOLVED

--- Comment #5 from Timothy Pearson  ---
Was able to test on Polaris.  Looks like the new version fixed things.

-- 
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 libdrm 4/5] intel: get a cached buffer by size for reuse

[James Xiong]

From: "Xiong, James" 

Previously all cached buffers in a given bucket were same sized,
when reusing, the MRU buffer at the tail was poped out. With the
new implementation, we go through the buffer list in a reverse
order to search for a MRU buffer with a suitable size.

Signed-off-by: Xiong, James 
---
 intel/intel_bufmgr_gem.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index f8317a4..e3d5a8d 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -723,10 +723,14 @@ retry:
 * of the list, as it will likely be hot in the GPU
 * cache and in the aperture for us.
 */
-   bo_gem = DRMLISTENTRY(drm_intel_bo_gem,
- bucket->head.prev, head);
-   DRMLISTDEL(_gem->head);
-   bo_gem->bo.align = alignment;
+   DRMLISTFOREACHENTRYREVERSE(temp_bo_gem, >head, 
head) {
+   if (temp_bo_gem->bo.size >= size) {
+   bo_gem = temp_bo_gem;
+   DRMLISTDEL(_gem->head);
+   bo_gem->bo.align = alignment;
+   break;
+   }
+   }
} else {
assert(alignment == 0);
 /* For non-render-target BOs (where we're probably
@@ -736,12 +740,13 @@ retry:
 * allocating a new buffer is probably faster than
 * waiting for the GPU to finish.
 */
-   bo_gem = DRMLISTENTRY(drm_intel_bo_gem,
- bucket->head.next, head);
-   if (!drm_intel_gem_bo_busy(_gem->bo)) {
-   DRMLISTDEL(_gem->head);
-   } else {
-   bo_gem = NULL;
+   DRMLISTFOREACHENTRY(temp_bo_gem, >head, head) {
+   if (temp_bo_gem->bo.size >= size &&
+   !drm_intel_gem_bo_busy(_bo_gem->bo)) {
+   bo_gem = temp_bo_gem;
+   DRMLISTDEL(_gem->head);
+   break;
+   }
}
}
 
-- 
2.7.4

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

[PATCH libdrm 2/5] intel: reorganize internal function

[James Xiong]

From: "Xiong, James" 

split drm_intel_gem_bo_alloc_internal, and add a function to
search for a suitable buffer for given size for reuse.

Signed-off-by: Xiong, James 
---
 intel/intel_bufmgr_gem.c | 141 ---
 1 file changed, 73 insertions(+), 68 deletions(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 386da30..2fcb0a0 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -704,6 +704,71 @@ drm_intel_gem_bo_cache_purge_bucket(drm_intel_bufmgr_gem 
*bufmgr_gem,
}
 }
 
+static drm_intel_bo_gem *
+drm_intel_gem_bo_cached_for_size(drm_intel_bufmgr_gem *bufmgr_gem,
+unsigned long size,
+uint32_t tiling_mode,
+unsigned long stride,
+unsigned long alignment,
+bool for_render)
+{
+   struct drm_intel_gem_bo_bucket *bucket =
+   drm_intel_gem_bo_bucket_for_size(bufmgr_gem, size);
+
+if (bucket != NULL) {
+   drm_intel_bo_gem *bo_gem, *temp_bo_gem;
+retry:
+   bo_gem = NULL;
+   if (for_render) {
+   /* Allocate new render-target BOs from the tail (MRU)
+* of the list, as it will likely be hot in the GPU
+* cache and in the aperture for us.
+*/
+   bo_gem = DRMLISTENTRY(drm_intel_bo_gem,
+ bucket->head.prev, head);
+   DRMLISTDEL(_gem->head);
+   bo_gem->bo.align = alignment;
+   } else {
+   assert(alignment == 0);
+/* For non-render-target BOs (where we're probably
+* going to map it first thing in order to fill it
+* with data), check if the last BO in the cache is
+* unbusy, and only reuse in that case. Otherwise,
+* allocating a new buffer is probably faster than
+* waiting for the GPU to finish.
+*/
+   bo_gem = DRMLISTENTRY(drm_intel_bo_gem,
+ bucket->head.next, head);
+   if (!drm_intel_gem_bo_busy(_gem->bo)) {
+   DRMLISTDEL(_gem->head);
+   } else {
+   bo_gem = NULL;
+   }
+   }
+
+   if (bo_gem) {
+   if (!drm_intel_gem_bo_madvise_internal
+   (bufmgr_gem, bo_gem, I915_MADV_WILLNEED)) {
+   drm_intel_gem_bo_free(_gem->bo);
+   drm_intel_gem_bo_cache_purge_bucket(bufmgr_gem,
+   bucket);
+   return NULL;
+   }
+
+   if (drm_intel_gem_bo_set_tiling_internal(_gem->bo,
+tiling_mode,
+stride)) {
+   drm_intel_gem_bo_free(_gem->bo);
+   goto retry;
+   }
+   }
+
+   return bo_gem;
+   }
+
+   return NULL;
+}
+
 static drm_intel_bo *
 drm_intel_gem_bo_alloc_internal(drm_intel_bufmgr *bufmgr,
const char *name,
@@ -715,81 +780,21 @@ drm_intel_gem_bo_alloc_internal(drm_intel_bufmgr *bufmgr,
 {
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bufmgr;
drm_intel_bo_gem *bo_gem;
-   unsigned int page_size = getpagesize();
int ret;
-   struct drm_intel_gem_bo_bucket *bucket;
-   bool alloc_from_cache;
-   unsigned long bo_size;
bool for_render = false;
 
if (flags & BO_ALLOC_FOR_RENDER)
for_render = true;
 
-   /* Round the allocated size up to a power of two number of pages. */
-   bucket = drm_intel_gem_bo_bucket_for_size(bufmgr_gem, size);
-
-   /* If we don't have caching at this size, don't actually round the
-* allocation up.
-*/
-   if (bucket == NULL) {
-   bo_size = size;
-   if (bo_size < page_size)
-   bo_size = page_size;
-   } else {
-   bo_size = bucket->size;
-   }
+   /* first align the size on page boundary */
+   size = ALIGN(size, getpagesize());
 
pthread_mutex_lock(_gem->lock);
/* Get a buffer out of the cache if available */
-retry:
-   alloc_from_cache = false;
-   if (bucket != NULL && !DRMLISTEMPTY(>head)) {
-   if (for_render) {
-  

[PATCH libdrm 0/5] improve reuse implementation

[James Xiong]

From: "Xiong, James" 

With gem_reuse enabled, when a buffer size is different than
the sizes of buckets, it is aligned to the next bucket's size,
which means about 25% more memory than the requested is allocated
in the worst senario. For example:

Orignal sizeActual
32KB+1Byte  40KB
.
.
.
8MB+1Byte   10MB
.
.
.
96MB+1Byte  112MB

This is very memory expensive and make the reuse feature less
favorable than it deserves to be.

This series aligns the reuse buffer size on page size instead to
save memory. Performed gfxbench tests on Gen9 without LLC, the
performances and reuse ratioes (reuse count/allocation count) were
same as before, saved memory usage by 1% ~ 7%(gl_manhattan: peak
allocated memory size was reduced from 448401408 to 419078144).

v2: split the patch to a series of small functional changes (Chris)

Xiong, James (5):
  drm: add a macro DRMLISTFOREACHENTRYREVERSE
  intel: reorganize internal function
  intel: get a cached bucket by size
  intel: get a cached buffer by size for reuse
  intel: purge cached bucket when its cached buffer is evicted

 intel/intel_bufmgr_gem.c | 180 +--
 libdrm_lists.h   |   6 ++
 2 files changed, 100 insertions(+), 86 deletions(-)

-- 
2.7.4

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

[PATCH libdrm 3/5] intel: get a cached bucket by size

[James Xiong]

From: "Xiong, James" 

cached buckets are sorted by size in increasing order, each now
contains cached buffers with different sizes. A buffer with size
>= buckets[n].size and < buckets[n+1].size is put in bucket n
for future reuse.

Signed-off-by: Xiong, James 
---
 intel/intel_bufmgr_gem.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 2fcb0a0..f8317a4 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -402,11 +402,10 @@ drm_intel_gem_bo_bucket_for_size(drm_intel_bufmgr_gem 
*bufmgr_gem,
 {
int i;
 
-   for (i = 0; i < bufmgr_gem->num_buckets; i++) {
-   struct drm_intel_gem_bo_bucket *bucket =
-   _gem->cache_bucket[i];
-   if (bucket->size >= size) {
-   return bucket;
+   for (i = 0; i < bufmgr_gem->num_buckets - 1; i++) {
+   if (size >= bufmgr_gem->cache_bucket[i].size &&
+   size < bufmgr_gem->cache_bucket[i+1].size) {
+   return _gem->cache_bucket[i];
}
}
 
-- 
2.7.4

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

[PATCH libdrm 1/5] drm: add a macro DRMLISTFOREACHENTRYREVERSE

[James Xiong]

From: "Xiong, James" 

it goes through DRMLIST in a reverse order

Signed-off-by: Xiong, James 
---
 libdrm_lists.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libdrm_lists.h b/libdrm_lists.h
index 8926d8d..400c731 100644
--- a/libdrm_lists.h
+++ b/libdrm_lists.h
@@ -101,6 +101,12 @@ typedef struct _drmMMListHead
 (__item) = DRMLISTENTRY(typeof(*__item),  \
 (__item)->__head.next, __head))
 
+#define DRMLISTFOREACHENTRYREVERSE(__item, __list, __head) 
\
+   for ((__item) = DRMLISTENTRY(typeof(*__item), (__list)->prev, __head); \
+&(__item)->__head != (__list);\
+(__item) = DRMLISTENTRY(typeof(*__item),  \
+(__item)->__head.prev, __head))
+
 #define DRMLISTFOREACHENTRYSAFE(__item, __temp, __list, __head)
\
for ((__item) = DRMLISTENTRY(typeof(*__item), (__list)->next, __head), \
 (__temp) = DRMLISTENTRY(typeof(*__item),  \
-- 
2.7.4

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

Re: [PATCH v2] drm/nouveau/secboot: remove VLA usage

[Ben Skeggs]

On 14 March 2018 at 21:08, Thierry Reding  wrote:
> On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wvla, remove VLA. In this particular
>> case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local
>> variable cmdline_size. Also, remove cmdline_size as it is not
>> actually useful anymore.
>>
>> The use of stack Variable Length Arrays needs to be avoided, as they
>> can be a vector for stack exhaustion, which can be both a runtime bug
>> or a security flaw. Also, in general, as code evolves it is easy to
>> lose track of how big a VLA can get. Thus, we can end up having runtime
>> failures that are hard to debug.
>>
>> Also, fixed as part of the directive to remove all VLAs from
>> the kernel: https://lkml.org/lkml/2018/3/7/621
>>
>> Signed-off-by: Gustavo A. R. Silva 
>> ---
>> Changes in v2:
>>  - Use sizeof(buf) instead of NVKM_MSGQUEUE_CMDLINE_SIZE. This change
>>is based on the feedback provided by David Laight. Thanks David.
>>
>>  drivers/gpu/drm/nouveau/nvkm/subdev/secboot/ls_ucode_msgqueue.c | 7 +++
>>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> Reviewed-by: Thierry Reding 
Thanks everyone.  I've taken the patch in my tree.

Ben.

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

[git pull] drm fixes for 4.16-rc6

[Dave Airlie]

Hi Linus,

i915 has a backlight fix for some panels, a pm and a fencing fix,
along with some GVT fixes.
amdgpu has a backlight fix across suspend/resume, an object
destruction ordering issue fix, and a displayport fix
nouveau has two backlight fixes, and a fix for some lockups.

Pretty quiet week, seems like everyone was fixing backlights.

Dave.

The following changes since commit 0c8efd610b58cb23cefdfa12015799079aef94ae:

  Linux 4.16-rc5 (2018-03-11 17:25:09 -0700)

are available in the Git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.16-rc6

for you to fetch changes up to 3a1b5de36fdf403d1b004e537dc13997633d65df:

  Merge tag 'drm-intel-fixes-2018-03-15' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2018-03-16
12:51:35 +1000)


i915, amd and nouveau fixes


Alex Deucher (1):
  drm/amdgpu: save/restore backlight level in legacy dce code

Chris Wilson (2):
  drm/i915: Only prune fences after wait-for-all
  drm/i915: Kick the rps worker when changing the boost frequency

Christian König (2):
  drm/amdgpu: fix prime teardown order
  drm/radeon: fix prime teardown order

Dave Airlie (4):
  Merge branch 'drm-fixes-4.16' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2018-03-14' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge branch 'linux-4.16' of git://github.com/skeggsb/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2018-03-15' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Karol Herbst (1):
  drm/nouveau/bl: fix backlight regression

Lukas Wunner (1):
  drm/nouveau/bl: Fix oops on driver unbind

Michel Dänzer (1):
  drm/amdgpu/dce: Don't turn off DP sink when disconnected

Min He (1):
  drm/i915/gvt: keep oa config in shadow ctx

Mustamin B Mustaffa (1):
  drm/i915: Enable VBT based BL control for DP

Māris Nartišs (1):
  drm/nouveau/mmu: ALIGN_DOWN correct variable

Rodrigo Vivi (1):
  Merge tag 'gvt-fixes-2018-03-15' of
https://github.com/intel/gvt-linux into drm-intel-fixes

Xiong Zhang (1):
  drm/i915/gvt: Add runtime_pm_get/put into gvt_switch_mmio

Zhenyu Wang (1):
  drm/i915/gvt: fix user copy warning by whitelist workload rb_tail field

fred gao (1):
  drm/i915/gvt: Correct the privilege shadow batch buffer address

 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 31 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c|  2 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  2 +
 drivers/gpu/drm/amd/amdgpu/atombios_encoders.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/atombios_encoders.h |  5 ++
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |  8 +++
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |  8 +++
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  |  8 +++
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  |  8 +++
 drivers/gpu/drm/i915/gvt/cmd_parser.c  |  8 +++
 drivers/gpu/drm/i915/gvt/mmio_context.c|  2 +
 drivers/gpu/drm/i915/gvt/scheduler.c   | 71 --
 drivers/gpu/drm/i915/gvt/scheduler.h   |  5 ++
 drivers/gpu/drm/i915/i915_gem.c| 16 --
 drivers/gpu/drm/i915/i915_sysfs.c  | 10 +++-
 drivers/gpu/drm/i915/intel_dp.c| 10 ++--
 drivers/gpu/drm/nouveau/nouveau_backlight.c| 14 ++---
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c  |  2 +-
 drivers/gpu/drm/radeon/radeon_gem.c|  2 -
 drivers/gpu/drm/radeon/radeon_object.c |  2 +
 21 files changed, 169 insertions(+), 50 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105515] hw_init of IP block failed

[bugzilla-daemon]

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

--- Comment #5 from Edward Kigwana  ---
With options amdgpu dpm=0 I can at leave get something. If I do not provide any
arguments, the system locks up instantly so without a serial console it is
going to be a a beast to capture that.

If you need it, I can try the options that follow since they seemed to work but
they did not cause a lock up so I am afraid the options really masked the core
issue.

options msi=1 exp_hw_support=0 ppfeaturemask=0

-- 
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 105515] hw_init of IP block failed

[bugzilla-daemon]

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

--- Comment #4 from Edward Kigwana  ---
Created attachment 138150
  --> https://bugs.freedesktop.org/attachment.cgi?id=138150=edit
dmesg

Full dmesg output

-- 
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 v4 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[jacopo mondi]

Hi Andrzej,
thanks for your patience in reviewing this series

On Thu, Mar 15, 2018 at 02:37:00PM +0100, Andrzej Hajda wrote:
> On 15.03.2018 11:56, Jacopo Mondi wrote:
> > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> > output converter.
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  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..067f231
> > --- /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;
> > +
> > +   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 %u\n", i);
>
> It would be better to use supply or regulator name instead of index.
>

Yeah, now it's easy as I have the array with names in the driver
global scope...

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

[PATCH] [v3] gpu: ipu-v3: prg: avoid possible array underflow

[Arnd Bergmann]

gcc-8 reports that we access an array with a negative index
in an error case:

drivers/gpu/ipu-v3/ipu-prg.c: In function 'ipu_prg_channel_disable':
drivers/gpu/ipu-v3/ipu-prg.c:252:43: error: array subscript -22 is below array 
bounds of 'struct ipu_prg_channel[3]' [-Werror=array-bounds]

This moves the range check in front of the first time that
variable gets used.

Signed-off-by: Arnd Bergmann 

v1: Originally sent on Dec 4, 2017.
v2: Sent again on Jan 16, after no reply, Phillipp said it was merged
v3: Ran into a related problem with CONFIG_UBSAN, sent again fixing both
---
 drivers/gpu/ipu-v3/ipu-prg.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
index 97b99500153d..83f9dd934a5d 100644
--- a/drivers/gpu/ipu-v3/ipu-prg.c
+++ b/drivers/gpu/ipu-v3/ipu-prg.c
@@ -250,10 +250,14 @@ void ipu_prg_channel_disable(struct ipuv3_channel 
*ipu_chan)
 {
int prg_chan = ipu_prg_ipu_to_prg_chan(ipu_chan->num);
struct ipu_prg *prg = ipu_chan->ipu->prg_priv;
-   struct ipu_prg_channel *chan = >chan[prg_chan];
+   struct ipu_prg_channel *chan;
u32 val;
 
-   if (!chan->enabled || prg_chan < 0)
+   if (prg_chan < 0)
+   return;
+
+   chan = >chan[prg_chan];
+   if (!chan->enabled)
return;
 
pm_runtime_get_sync(prg->dev);
@@ -280,13 +284,15 @@ int ipu_prg_channel_configure(struct ipuv3_channel 
*ipu_chan,
 {
int prg_chan = ipu_prg_ipu_to_prg_chan(ipu_chan->num);
struct ipu_prg *prg = ipu_chan->ipu->prg_priv;
-   struct ipu_prg_channel *chan = >chan[prg_chan];
+   struct ipu_prg_channel *chan;
u32 val;
int ret;
 
if (prg_chan < 0)
return prg_chan;
 
+   chan = >chan[prg_chan];
+
if (chan->enabled) {
ipu_pre_update(prg->pres[chan->used_pre], *eba);
return 0;
-- 
2.9.0

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

[Bug 199123] kernel 4.16rc5 doesnt boot on ryzen 5 2400g due to an amdgpu change

[bugzilla-daemon]

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

--- Comment #3 from david becerra (davidbecerrapor...@gmail.com) ---
(In reply to Michel Dänzer from comment #2)
> Can you bisect?

i cant do the process, but im 99% sure the bad commit is:
https://github.com/torvalds/linux/commit/65307f2e05100be34698bcf7545285dd1cf6ff2c

ironic because it was supposed to FIX black screens

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

Re: [PATCH 00/16] remove eight obsolete architectures

[David Howells]

Do we have anything left that still implements NOMMU?

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

Re: [PATCH 1/4] dma-buf: add optional invalidate_mappings callback

[Christian König]

Am 15.03.2018 um 10:20 schrieb Daniel Vetter:

On Tue, Mar 13, 2018 at 06:20:07PM +0100, Christian König wrote:
[SNIP]
Take a look at the DOT graphs for atomic I've done a while ago. I think we
could make a formidable competition for who's doing the worst diagrams :-)


Thanks, going to give that a try.


[SNIP]
amdgpu: Expects that you never hold any of the heavywheight locks while
waiting for a fence (since gpu resets will need them).

i915: Happily blocks on fences while holding all kinds of locks, expects
gpu reset to be able to recover even in this case.


In this case I can comfort you, the looks amdgpu needs to grab during 
GPU reset are the reservation lock of the VM page tables. I have strong 
doubt that i915 will ever hold those.


Could be that we run into problems because Thread A hold lock 1 tries to 
take lock 2, then i915 holds 2 and our reset path needs 1.



[SNIP]

Yes, except for fallback paths and bootup self tests we simply never wait
for fences while holding locks.

That's not what I meant with "are you sure". Did you enable the
cross-release stuff (after patching the bunch of leftover core kernel
issues still present), annotate dma_fence with the cross-release stuff,
run a bunch of multi-driver (amdgpu vs i915) dma-buf sharing tests and
weep?


Ok, what exactly do you mean with cross-release checking?


I didn't do the full thing yet, but just within i915 we've found tons of
small little deadlocks we never really considered thanks to cross release,
and that wasn't even including the dma_fence annotation. Luckily nothing
that needed a full-on driver redesign.

I guess I need to ping core kernel maintainers about cross-release again.
I'd much prefer if we could validate ->invalidate_mapping and the
locking/fence dependency issues using that, instead of me having to read
and understand all the drivers.

[SNIP]

I fear that with the ->invalidate_mapping callback (which inverts the
control flow between importer and exporter) and tying dma_fences into all
this it will be a _lot_ worse. And I'm definitely too stupid to understand
all the dependency chains without the aid of lockdep and a full test suite
(we have a bunch of amdgpu/i915 dma-buf tests in igt btw).


Yes, that is also something I worry about.

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

Re: [PATCH 00/16] remove eight obsolete architectures

[Arnd Bergmann]

On Thu, Mar 15, 2018 at 10:42 AM, David Howells  wrote:
> Do we have anything left that still implements NOMMU?

Yes, plenty. I was wondering the same thing, but it seems that the architectures
we remove are almost completely representative of what we support overall,
except that they are all not licensed to 3rd parties, unlike many of the ones we
keep.

I've made an overview of the remaining architectures for my own reference[1].
The remaining NOMMU architectures are:

- arch/arm has ARMv7-M (Cortex-M microcontroller), which is actually
gaining traction
- arch/sh has an open-source J2 core that was added not that long ago,
it seems to
  be the only SH compatible core that anyone is working on.
- arch/microblaze supports both MMU/NOMMU modes (most use an MMU)
- arch/m68k supports several NOMMU targets, both the coldfire SoCs and the
  classic processors
- c6x has no MMU

   Arnd

[1] 
https://docs.google.com/spreadsheets/d/1QxMvW5jpVG2jb4RM9CQQl27-wVpNYOa-_3K2RVKifb0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/3] drm/tegra: plane: Fix RGB565 plane format on older Tegra's

[Thierry Reding]

On Thu, Mar 15, 2018 at 04:00:23AM +0300, Dmitry Osipenko wrote:
> Simplify opaque format adjustment by removing format checking. There are
> only 4 formats that require the adjustment and so this way is less error
> prone, avoiding mishandling native formats, like in this case RGB565 is
> the format that was erroneously treated as invalid.
> 
> Fixes: ebae8d07435a ("drm/tegra: dc: Implement legacy blending")
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/gpu/drm/tegra/dc.c| 11 ++-
>  drivers/gpu/drm/tegra/plane.c | 21 ++---
>  drivers/gpu/drm/tegra/plane.h |  2 +-
>  3 files changed, 9 insertions(+), 25 deletions(-)

I've applied a slightly different version of this which doesn't rework
as much of the surrounding code and is therefore easier to backport to
v4.16.

Thierry


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

Re: [PATCH] kthread: finer-grained lockdep/cross-release completion

[Daniel Vetter]

On Wed, Dec 20, 2017 at 2:14 AM, Byungchul Park  wrote:
> On 12/19/2017 6:59 PM, Daniel Vetter wrote:
>>
>> On Mon, Dec 18, 2017 at 09:42:13AM -0800, Linus Torvalds wrote:
>>>
>>> On Sun, Dec 17, 2017 at 11:11 PM, Daniel Vetter  wrote:


 This didn't seem to have made it into -rc4. Anything needed to get it
 going?
>>>
>>>
>>> Do you actually see the problem in -rc4?
>>>
>>> Because we ended up removing the cross-release checking due to other
>>> developers complaining. It seemed to need a lot more work before it
>>> was ready.
>>>
>>> So I suspect the patch is simply not relevant any more (even if it's
>>> not necessarily wrong either).
>>
>>
>> Awww ... I like the cross release stuff, it's catching lots of good bugs
>> for us - writing a gpu memory manager that's supposed to interface with
>> the core one ain't the simplest thing to get right. That's also why we're
>> going around and fixing up fallout (we've worked on the worker annotations
>> for 4.14 too). I guess next release, hopefully.
>>
>> I think between 4.14 and 4.15 attemps cross-release spotted around 5 or so
>> genuine deadlocks in i915 code. And at least right now, with the current
>> set of fixups our CI runs are splat-free. So at least a Kconfig option
>> would be nice, to be able to enable it easily when you want to.
>>
>> Wrt us not noticing: Getting the patches in through normal means takes too
>> long, so we constantly carry arounda  bunch of fixup patches to address
>> serious issues that block CI (no lockdep is no good CI). That's why we
>> won't immediately notice when an issue is resolved some other way.
>
>
> Hello Ingo and Linus,
>
> IMO, taking it off by default is enough. What fs folk actually
> wanted is not to remove whole stuff but make it off by default.
>
> Cross-release logic itself makes sense. Please consider it back
> and apply my patch making it off by default.
>
> I will do what I can do for the classification in layered fs.

Is there any progress on getting cross-release enabled again?
-Daniel
-- 
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 1/4] dma-buf: add optional invalidate_mappings callback

[Daniel Vetter]

On Thu, Mar 15, 2018 at 10:56 AM, Christian König
 wrote:
> Am 15.03.2018 um 10:20 schrieb Daniel Vetter:
>>
>> On Tue, Mar 13, 2018 at 06:20:07PM +0100, Christian König wrote:
>> [SNIP]
>> Take a look at the DOT graphs for atomic I've done a while ago. I think we
>> could make a formidable competition for who's doing the worst diagrams :-)
>
>
> Thanks, going to give that a try.
>
>> [SNIP]
>> amdgpu: Expects that you never hold any of the heavywheight locks while
>> waiting for a fence (since gpu resets will need them).
>>
>> i915: Happily blocks on fences while holding all kinds of locks, expects
>> gpu reset to be able to recover even in this case.
>
>
> In this case I can comfort you, the looks amdgpu needs to grab during GPU
> reset are the reservation lock of the VM page tables. I have strong doubt
> that i915 will ever hold those.

Ah good, means that very likely there's at least no huge fundamental
design issue that we run into.

> Could be that we run into problems because Thread A hold lock 1 tries to
> take lock 2, then i915 holds 2 and our reset path needs 1.

Yeah that might happen, but lockdep will catch those, and generally
those cases can be fixed with slight reordering or re-annotating of
the code to avoid upsetting lockdep. As long as we don't have a
full-on functional dependency (which is what I've feared).

>> [SNIP]
>>>
>>> Yes, except for fallback paths and bootup self tests we simply never wait
>>> for fences while holding locks.
>>
>> That's not what I meant with "are you sure". Did you enable the
>> cross-release stuff (after patching the bunch of leftover core kernel
>> issues still present), annotate dma_fence with the cross-release stuff,
>> run a bunch of multi-driver (amdgpu vs i915) dma-buf sharing tests and
>> weep?
>
>
> Ok, what exactly do you mean with cross-release checking?

Current lockdep doesn't spot deadlocks like the below:

thread A: holds mutex, waiting for completion.

thread B: acquires mutex before it will ever signal the completion A
is waiting for

->deadlock

cross-release lockdep support can catch these through new fancy
annotations. Similar waiter/signaller annotations exists for waiting
on workers and anything else, and it would be a perfect fit for
waiter/signaller code around dma_fence.

lwn has you covered a usual: https://lwn.net/Articles/709849/

Cheers, Daniel

>> I didn't do the full thing yet, but just within i915 we've found tons of
>> small little deadlocks we never really considered thanks to cross release,
>> and that wasn't even including the dma_fence annotation. Luckily nothing
>> that needed a full-on driver redesign.
>>
>> I guess I need to ping core kernel maintainers about cross-release again.
>> I'd much prefer if we could validate ->invalidate_mapping and the
>> locking/fence dependency issues using that, instead of me having to read
>> and understand all the drivers.
>
> [SNIP]
>>
>> I fear that with the ->invalidate_mapping callback (which inverts the
>> control flow between importer and exporter) and tying dma_fences into all
>> this it will be a _lot_ worse. And I'm definitely too stupid to understand
>> all the dependency chains without the aid of lockdep and a full test suite
>> (we have a bunch of amdgpu/i915 dma-buf tests in igt btw).
>
>
> Yes, that is also something I worry about.
>
> Regards,
> Christian.



-- 
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 v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Andrzej Hajda]

On 14.03.2018 11:09, jacopo mondi wrote:
> Hi Andrzej,
> thanks for review
>
> On Wed, Mar 14, 2018 at 09:42:36AM +0100, Andrzej Hajda wrote:
>> On 13.03.2018 15:30, Jacopo Mondi wrote:
>>> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
>>> output decoder.
>> IMO converter suits here better, but it is just suggestion.
>>
>>> Signed-off-by: Jacopo Mondi 
>>> ---
>>>  drivers/gpu/drm/bridge/Kconfig|   7 +
>>>  drivers/gpu/drm/bridge/Makefile   |   1 +
>>>  drivers/gpu/drm/bridge/thc63lvd1024.c | 241 
>>> ++
>>>  3 files changed, 249 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..facf6bd 100644
>>> --- a/drivers/gpu/drm/bridge/Kconfig
>>> +++ b/drivers/gpu/drm/bridge/Kconfig
>>> @@ -92,6 +92,13 @@ 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
>>> +   select DRM_PANEL_BRIDGE
>> You don't use PANEL_BRIDGE, it should be possible to drop the select.
>>
> Ack
>
>>> +   ---help---
>>> + Thine THC63LVD1024 LVDS decoder bridge driver.
>> Decoder to what?
>> Maybe it would be better to say it is LVDS/parallel or LVDS/RGB
>> converter or bridge.
> "LVDS to digital CMOS/TTL parallel data converter" as the manual
> describes the chip?

Should work, unless we want some consistency in interface names, we have
already: parallel / DPI / RGB. I am little bit confused about relations
between them so I do not want to enforce any.


>
>>> +
>>>  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..4b059c0
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
>>> @@ -0,0 +1,241 @@
>>> +// 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 
>>> +
>>> +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 *pwdn;
>>> +   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;
>>> +   unsigned int i;
>>> +   int ret;
>>> +
>>> +   for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
>>> +   vcc = thc63->vccs[i];
>>> +   if (vcc) {
>>> +   ret = regulator_enable(vcc);
>>> +   if (ret)
>>> +   goto error_vcc_enable;
>>> +   }
>>> +   }
>>> +
>>> +   if (thc63->pwdn)
>>> +   gpiod_set_value(thc63->pwdn, 0);
>>> +
>>> +   if (thc63->oe)
>>> +   gpiod_set_value(thc63->oe, 1);
>>> +
>>> +   return;
>>> +
>>> +error_vcc_enable:
>>> +   dev_err(thc63->dev, "Failed to enable regulator %u\n", i);
>>> +}
>>> +
>>> +static void thc63_disable(struct drm_bridge *bridge)
>>> +{
>>> +   struct thc63_dev *thc63 = to_thc63(bridge);
>>> +   struct regulator *vcc;
>>> +   unsigned int i;
>>> +   int ret;
>>> +
>>> +   for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
>>> +   vcc = thc63->vccs[i];
>>> +   if (vcc) {
>>> +   ret = regulator_disable(vcc);
>>> +   if (ret)
>>> +

Re: [PATCH v1 2/3] drm/tegra: plane: Correct legacy blending

[Thierry Reding]

On Thu, Mar 15, 2018 at 04:00:24AM +0300, Dmitry Osipenko wrote:
> Keep old 'dependent' state of unaffected planes, this way new state takes
> into account current state of unaffected planes.
> 
> Fixes: ebae8d07435a ("drm/tegra: dc: Implement legacy blending")
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/gpu/drm/tegra/plane.c | 15 ++-
>  1 file changed, 6 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
> index fc37dcf8c458..3c0cb6a04c66 100644
> --- a/drivers/gpu/drm/tegra/plane.c
> +++ b/drivers/gpu/drm/tegra/plane.c
> @@ -287,13 +287,11 @@ unsigned int tegra_plane_format_adjust(unsigned int 
> opaque)
>   return opaque;
>  }
>  
> -unsigned int tegra_plane_get_overlap_index(struct tegra_plane *plane,
> -struct tegra_plane *other)
> +static unsigned int tegra_plane_get_overlap_index(struct tegra_plane *plane,
> +   struct tegra_plane *other)

I'd prefer this to be a separate patch to keep the diff down to make
this easier to apply to v4.16. I can do that when I apply, no need to
resend.

>  {
>   unsigned int index = 0, i;
>  
> - WARN_ON(plane == other);
> -

Why would this need to go away? We still shouldn't be called with plane
== other because that makes no sense.

Thierry


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

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

[jacopo mondi]

HI Andrezej,

On Thu, Mar 15, 2018 at 10:44:42AM +0100, Andrzej Hajda wrote:
> On 14.03.2018 11:09, jacopo mondi wrote:
> > Hi Andrzej,
> > thanks for review
> >
> > On Wed, Mar 14, 2018 at 09:42:36AM +0100, Andrzej Hajda wrote:
> >> On 13.03.2018 15:30, Jacopo Mondi wrote:
> >>> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> >>> output decoder.
> >> IMO converter suits here better, but it is just suggestion.
> >>
> >>> Signed-off-by: Jacopo Mondi 
> >>> ---
> >>>  drivers/gpu/drm/bridge/Kconfig|   7 +
> >>>  drivers/gpu/drm/bridge/Makefile   |   1 +
> >>>  drivers/gpu/drm/bridge/thc63lvd1024.c | 241 
> >>> ++
> >>>  3 files changed, 249 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..facf6bd 100644
> >>> --- a/drivers/gpu/drm/bridge/Kconfig
> >>> +++ b/drivers/gpu/drm/bridge/Kconfig
> >>> @@ -92,6 +92,13 @@ 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
> >>> + select DRM_PANEL_BRIDGE
> >> You don't use PANEL_BRIDGE, it should be possible to drop the select.
> >>
> > Ack
> >
> >>> + ---help---
> >>> +   Thine THC63LVD1024 LVDS decoder bridge driver.
> >> Decoder to what?
> >> Maybe it would be better to say it is LVDS/parallel or LVDS/RGB
> >> converter or bridge.
> > "LVDS to digital CMOS/TTL parallel data converter" as the manual
> > describes the chip?
>
> Should work, unless we want some consistency in interface names, we have
> already: parallel / DPI / RGB. I am little bit confused about relations
> between them so I do not want to enforce any.

config DRM_THINE_THC63LVD1024
tristate "Thine THC63LVD1024 LVDS decoder bridge"
depends on OF
---help---
  Thine THC63LVD1024 LVDS/parallel converter driver.

I guess this is consistent with other symbol descriptions I found

>

[snip]
>
> >>> +
> >>> +static int thc63_gpio_init(struct thc63_dev *thc63)
> >>> +{
> >>> + thc63->pwdn = devm_gpiod_get_optional(thc63->dev, "pwdn",
> >>> +   GPIOD_OUT_LOW);
> >> Shouldn't be GPIOD_OUT_HIGH - bridge initially disabled?
> > No, the PWDN gpio is active low, it puts the chip in power down mode
> > when the physical line level is set to 0.
> >
> > That's another confusing thing, when requesting the GPIO, the actual
> > physical line value has to be provided, while when "set_value()" the
> > logical one is requested, iirc.
>
> I think it is opposite, only *raw* functions uses physical level. Other
> uses logical level.
>
> >
> > Being the GPIO defined as active low, in power enable we set it to
> > "logical inactive" == "physical 1", while during power disable it has
> > to be set to "logical active" == "physical 0"
> >
> > Not the right place to complain here, but imo that's not consistent.
> > Or have I misinterpreted the APIs? I cannot do much test, as in my setup
> > the PWDN pin is hardwired to +vcc (through a physical switch, not
> > controlled through a GPIO though).
>
> devm_gpiod_get_optional calls (indirectly) gpiod_configure_flags, which
> calls gpiod_direction_output which uses logical levels.

I clearly mis-interpreted the APIs.

I'll fix and I'm sending v4 out shortly.

Thanks
   j

>
> Regards
> Andrzej
>
> >
> > Thanks
> >j
> >
> >> Regards
> >> Andrzej
> >>> + if (IS_ERR(thc63->pwdn)) {
> >>> + dev_err(thc63->dev, "Unable to get GPIO \"pwdn\"\n");
> >>> + return PTR_ERR(thc63->pwdn);
> >>> + }
> >>> +
> >>> + thc63->oe = devm_gpiod_get_optional(thc63->dev, "oe", GPIOD_OUT_LOW);
> >>> + if (IS_ERR(thc63->oe)) {
> >>> + dev_err(thc63->dev, "Unable to get GPIO \"oe\"\n");
> >>> + return PTR_ERR(thc63->oe);
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int thc63_regulator_init(struct thc63_dev *thc63)
> >>> +{
> >>> + struct regulator **reg;
> >>> + int i;
> >>> +
> >>> + reg = >vccs[0];
> >>> + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++, reg++) {
> >>> + *reg = devm_regulator_get_optional(thc63->dev,
> >>> +thc63_reg_names[i]);
> >>> + if (IS_ERR(*reg)) {
> >>> + if (PTR_ERR(*reg) == -EPROBE_DEFER)
> >>> + return -EPROBE_DEFER;
> >>> + *reg = NULL;
> >>> + }
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int thc63_probe(struct platform_device *pdev)
> >>> +{
> >>> + struct thc63_dev *thc63;
> >>> + int ret;
> >>> +
> >>> + thc63 = devm_kzalloc(>dev, sizeof(*thc63), GFP_KERNEL);
> >>> + if (!thc63)
> >>> + return -ENOMEM;
> >>> +
> >>> + thc63->dev = >dev;
> >>> + 

Re: [PATCH 00/16] remove eight obsolete architectures

[Geert Uytterhoeven]

Hi David,

On Thu, Mar 15, 2018 at 10:42 AM, David Howells  wrote:
> Do we have anything left that still implements NOMMU?

Sure: arm, c6x, m68k, microblaze, and  sh.

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: [PATCH 00/16] remove eight obsolete architectures

[Arnd Bergmann]

On Thu, Mar 15, 2018 at 10:59 AM, Hannes Reinecke  wrote:
> On 03/15/2018 10:42 AM, David Howells wrote:
>> Do we have anything left that still implements NOMMU?
>>
> RISC-V ?
> (evil grin :-)

Is anyone producing a chip that includes enough of the Privileged ISA spec
to have things like system calls, but not the MMU parts?

I thought at least initially the kernel only supports hardware that has a rather
complete feature set.

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

Re: [PATCH v1 3/3] drm/tegra: dc: Dedicate overlay plane to cursor on older Tegra's

[Thierry Reding]

On Thu, Mar 15, 2018 at 04:00:25AM +0300, Dmitry Osipenko wrote:
> Older Tegra's do not support RGBA format for the cursor, but instead
> overlay plane could be used for it. Since there is no much use for the
> overlays on a regular desktop and HW-accelerated cursor is much better
> than a SW cursor, let's dedicate one overlay plane to the mouse cursor.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/gpu/drm/tegra/dc.c | 28 +++-
>  1 file changed, 23 insertions(+), 5 deletions(-)

Applied. I'm not entirely happy that we need to sacrifice one of the
overlay windows for this, but you're right, it's probably okay given
how little planes are used on a regular desktop.

We could always provide a module parameter to switch this on and off
if that's ever something we want.

Applied, thanks.

Thierry


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

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

On 12.03.2018 11:41, Roger Quadros wrote:
> Andrezej,
>
> Why don't you have any of the USB maintainers in to/cc?
>
> Greg Kroah-Hartman  (supporter:USB SUBSYSTEM)
> Felipe Balbi  (maintainer:USB GADGET/PERIPHERAL SUBSYSTEM)

Serious omission, sorry for that.

>
> On 12/03/18 09:02, Andrzej Hajda wrote:
>> On 09.03.2018 11:24, Roger Quadros wrote:
>>> Hi,
>>>
>>> On 27/02/18 09:11, Andrzej Hajda wrote:
 These bindings allow to describe most known standard USB connectors
 and it should be possible to extend it if necessary.
 USB connectors, beside USB can be used to route other protocols,
 for example UART, Audio, MHL. In such case every device passing data
 through the connector should have appropriate graph bindings.

 Signed-off-by: Andrzej Hajda 
 ---
 v4:
 - improved 'type' description (Rob),
 - improved description of 2nd example (Rob).
 v3:
 - removed MHL port (samsung connector will have separate bindings),
 - added 2nd example for USB-C,
 - improved formatting.
 v2:
 - moved connector type(A,B,C) to compatible string (Rob),
 - renamed size property to type (Rob),
 - changed type description to be less confusing (Laurent),
 - removed vendor specific compatibles (implied by graph port number),
 - added requirement of connector being a child of IC (Rob),
 - removed max-mode (subtly suggested by Rob, it should be detected anyway
   by USB Controller in runtime, downside is that device is not able to
   report its real capabilities, maybe better would be to make it 
 optional(?)),
 - assigned port numbers to data buses (Rob).

 Regards
 Andrzej
 ---
  .../bindings/connector/usb-connector.txt   | 75 
 ++
  1 file changed, 75 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/connector/usb-connector.txt

 diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
 b/Documentation/devicetree/bindings/connector/usb-connector.txt
 new file mode 100644
 index ..e1463f14af38
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> Should this lie in  bindings/usb/connector?


I guess this is question for DT people. For me both locations are OK.

>
 @@ -0,0 +1,75 @@
 +USB Connector
 +=
 +
 +USB connector node represents physical USB connector. It should be
 +a child of USB interface controller.
 +
 +Required properties:
 +- compatible: describes type of the connector, must be one of:
 +"usb-a-connector",
 +"usb-b-connector",
 +"usb-c-connector".
>>> compatible should be just "usb-connector"
>>>
>>> Type should be a property
>>>
>>> type: type of usb connector "A", "B", "AB", "C"
>>> AB is for dual-role connectors.
>> I have proposed such property (and size also) in my first RFC [1]. Rod
>> did not like it :)
>>
>> [1]: https://marc.info/?l=devicetree=150660411515233=2
>>
> This is what Rob says here https://patchwork.kernel.org/patch/9976043/
> "We did "type" for hdmi-connector, but I think I'd really prefer 
> compatible be used to distinguish as least where it may matter to s/w. 
> In the HDMI case, they all are pretty much the same, just different 
> physical size."
>
> So the question is. Does it matter to this particular software implementation
> if it is type A,B,C connector?
> If yes, how?

IMHO both approaches can work from S/W POV. As I understood it moving
usb type to compatible was rather matter of devicetree guidelines I am
not aware of. Again question to Rob.

>
> Type A will never have any alternate function. It is always dedicated to USB.
>
> Also does the size "full", "micro", "mini" matter to software?
>
>>> micro super-speed and high-speed connectors are different. How do you 
>>> differentiate that?
>> I am aware of it, and property differentiating it was also in my earlier
>> iterations.
>> If there will be need to differentiate such connectors, adding property
>> max-speed or max-mode would do the thing.
> USB controller binding (bindings/usb/generic.txt) has the speed.
> I don't think there is any value for replicating it for the connector. Maybe 
> it could
> be added later if needed.
>
 +
 +Optional properties:
 +- label: symbolic name for the connector,
>>> Why do you need label? We can't maintain consistency as people will put 
>>> creative names there.
>>> Device/bus driver could generate a valid label.
>> It follows convention for other connectors: HDMI, DVI, 
>>
 +- type: size of the connector, should be specified in case of USB-A, USB-B
 +  non-fullsize connectors: "mini", "micro".
>>> type is misleading. Type is usually A/B/C. It should be size here instead.
>> As you can see in discussion for previous iterations it follows
>> convention already 

[Bug 103370] `vblank_mode=0 DRI_PRIME=1 glxgears` will introduce GPU lock up on Intel Graphics [8086:5917] + AMD Graphics [1002:6665] (rev c3)

[bugzilla-daemon]

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

Shih-Yuan Lee  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #46 from Shih-Yuan Lee  ---
The Linux kernel of Comment 45 is 4.15.0-10.11 from Ubuntu 18.04.
When I tried a later version 4.15.0-12.13, I can not reduplicate this issue on
Ubuntu 18.04.
4.15.0-12.13 contains the following commit.

commit 239b5f64e12b1f09f506c164dff0374924782979
Author: Alex Deucher 
Date:   Tue Nov 21 12:09:38 2017 -0500

drm/radeon: Add dpm quirk for Jet PRO (v2)

Fixes stability issues.

v2: clamp sclk to 600 Mhz

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103370
Acked-by: Christian König 
Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org

diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index ee3e742..97a0a63 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2984,6 +2984,11 @@ static void si_apply_state_adjust_rules(struct
radeon_device *rdev,
(rdev->pdev->device == 0x6667)) {
max_sclk = 75000;
}
+   if ((rdev->pdev->revision == 0xC3) ||
+   (rdev->pdev->device == 0x6665)) {
+   max_sclk = 6;
+   max_mclk = 8;
+   }
} else if (rdev->family == CHIP_OLAND) {
if ((rdev->pdev->revision == 0xC7) ||
(rdev->pdev->revision == 0x80) ||

-- 
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 105515] hw_init of IP block failed

[bugzilla-daemon]

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

--- Comment #2 from Edward Kigwana  ---
After lots of wrangling, I got it to work with the following module options:

options amdgpu si_support=0 cik_support=0 msi=1 exp_hw_support=0
ppfeaturemask=0 dpm=0 powerplay=0

As a side not adding si support results in guaranteed panic / lockup, not some
code gets called when it should not. cik support has no impact. I had to add
the last two to finally get into X. So something is clearly still busted.

-- 
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] kthread: finer-grained lockdep/cross-release completion

[Peter Zijlstra]

On Thu, Mar 15, 2018 at 11:31:57AM +0100, Daniel Vetter wrote:
> Is there any progress on getting cross-release enabled again?

Not yet, I'm still fighting the meltdown/spectre induced backlog.

We'll get to it eventually.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdkfd: add missing include of mm.h

[Alex Deucher]

On Thu, Mar 15, 2018 at 4:10 AM, Oded Gabbay  wrote:
> This patch fixes kernel build in ARCH=frv
>
> Signed-off-by: Oded Gabbay 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> index d7509b706b26..ad7292fc454c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> @@ -26,6 +26,7 @@
>  #define AMDGPU_AMDKFD_H_INCLUDED
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> --
> 2.14.3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/sun4i: backend: Check that we only have a single YUV plane

[Chen-Yu Tsai]

On Fri, Mar 2, 2018 at 3:18 AM, Maxime Ripard  wrote:
> Just like for the frontend, a single plane can use a YUV format. Make sure
> we have that constraint covered in our atomic_check.

It might be worth mentioning that this is a precursor patch for YUV support.

> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_backend.c | 49 ++--
>  drivers/gpu/drm/sun4i/sun4i_backend.h | 18 ++-
>  2 files changed, 65 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index 092ade4ff6a5..486dfd357920 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -42,6 +42,38 @@ static const u32 sunxi_rgb2yuv_coef[12] = {
> 0x01c1, 0x3e88, 0x3fb8, 0x0808
>  };
>
> +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;
> @@ -330,6 +362,7 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
> *engine,
> unsigned int num_planes = 0;
> unsigned int num_alpha_planes = 0;
> unsigned int num_frontend_planes = 0;
> +   unsigned int num_yuv_planes = 0;
> unsigned int current_pipe = 0;
> unsigned int i;
>
> @@ -362,6 +395,11 @@ static int sun4i_backend_atomic_check(struct 
> sunxi_engine *engine,
> if (fb->format->has_alpha)
> num_alpha_planes++;
>
> +   if (sun4i_backend_format_is_yuv(fb->format->format)) {
> +   DRM_DEBUG_DRIVER("Plane FB format is YUV\n");
> +   num_yuv_planes++;
> +   }
> +
> DRM_DEBUG_DRIVER("Plane zpos is %d\n",
>  plane_state->normalized_zpos);
>
> @@ -430,13 +468,20 @@ static int sun4i_backend_atomic_check(struct 
> sunxi_engine *engine,
> s_state->pipe = current_pipe;
> }
>
> +   /* We can only have a single YUV plane at a time */
> +   if (num_yuv_planes > SUN4I_BACKEND_NUM_YUV_PLANES) {
> +   DRM_DEBUG_DRIVER("Too many planes with YUV, rejecting...\n");
> +   return -EINVAL;
> +   }
> +
> if (num_frontend_planes > SUN4I_BACKEND_NUM_FRONTEND_LAYERS) {
> DRM_DEBUG_DRIVER("Too many planes going through the frontend, 
> rejecting\n");
> return -EINVAL;
> }
>
> -   DRM_DEBUG_DRIVER("State valid with %u planes, %u alpha, %u video\n",
> -num_planes, num_alpha_planes, num_frontend_planes);
> +   DRM_DEBUG_DRIVER("State valid with %u planes, %u alpha, %u video, %u 
> YUV\n",
> +num_planes, num_alpha_planes, num_frontend_planes,
> +num_yuv_planes);
>
> return 0;
>  }
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h 
> b/drivers/gpu/drm/sun4i/sun4i_backend.h
> index 52e77591186a..316f2179e9e1 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
> @@ -72,6 +72,7 @@
>  #define SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(x)   ((x) << 15)
>  #define SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL_MASK  GENMASK(11, 10)
>  #define SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL(x)((x) 
> << 10)
> +#define SUN4I_BACKEND_ATTCTL_REG0_LAY_YUVENBIT(2)
>  #define SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOENBIT(1)
>
>  #define SUN4I_BACKEND_ATTCTL_REG1(l)   (0x8a0 + (0x4 * (l)))
> @@ -110,7 +111,23 @@
>  #define SUN4I_BACKEND_SPREN_REG0x900
>  #define SUN4I_BACKEND_SPRFMTCTL_REG0x908
>  #define SUN4I_BACKEND_SPRALPHACTL_REG  0x90c
> +
>  #define SUN4I_BACKEND_IYUVCTL_REG  0x920
> +#define SUN4I_BACKEND_IYUVCTL_FBFMT_MASK   GENMASK(14, 12)
> +#define SUN4I_BACKEND_IYUVCTL_FBFMT_PACKED_YUV444  (4 << 12)
> +#define SUN4I_BACKEND_IYUVCTL_FBFMT_PACKED_YUV422  (3 << 12)
> +#define SUN4I_BACKEND_IYUVCTL_FBFMT_PLANAR_YUV444  

[PATCH 3/8] drm/sun4i: Add support for A80 TCONs

[Chen-Yu Tsai]

The Allwinner A80 SoC has 2 documented TCONs. The display pipeline
diagram from the user manual shows a third TCON, but it's missing
an interrupt line, and its registers are not explained either.
It's also not used in Allwinner's vendor BSP.

The first TCON only has channel 0, for LCD panel output. The TCON
hardware setup is peculiar in that the eDP reset must also be
deasserted to allow access to the TCON. How the eDP module is wired
in the SoC itself is never explained.

The second TCON only has channel 1, and its output is connected to
the HDMI encoder block.

This patch adds a "needs_edp_reset" field to the tcon quirks structure,
and adds quirks and compatible strings for the 2 documented TCONs.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 27 +++
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  1 +
 2 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index d4a29847dadd..b4cef03861f7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -855,6 +855,7 @@ static int sun4i_tcon_bind(struct device *dev, struct 
device *master,
struct sunxi_engine *engine;
struct device_node *remote;
struct sun4i_tcon *tcon;
+   struct reset_control *edp_rstc;
bool has_lvds_rst, has_lvds_alt, can_lvds;
int ret;
 
@@ -879,6 +880,20 @@ static int sun4i_tcon_bind(struct device *dev, struct 
device *master,
return PTR_ERR(tcon->lcd_rst);
}
 
+   if (tcon->quirks->needs_edp_reset) {
+   edp_rstc = devm_reset_control_get_shared(dev, "edp");
+   if (IS_ERR(edp_rstc)) {
+   dev_err(dev, "Couldn't get edp reset line\n");
+   return PTR_ERR(edp_rstc);
+   }
+
+   ret = reset_control_deassert(edp_rstc);
+   if (ret) {
+   dev_err(dev, "Couldn't deassert edp reset line\n");
+   return ret;
+   }
+   }
+
/* Make sure our TCON is reset */
ret = reset_control_reset(tcon->lcd_rst);
if (ret) {
@@ -1176,6 +1191,16 @@ static const struct sun4i_tcon_quirks sun8i_v3s_quirks = 
{
.has_channel_0  = true,
 };
 
+static const struct sun4i_tcon_quirks sun9i_a80_tcon_lcd_quirks = {
+   .has_channel_0  = true,
+   .needs_edp_reset = true,
+};
+
+static const struct sun4i_tcon_quirks sun9i_a80_tcon_tv_quirks = {
+   .has_channel_1  = true,
+   .needs_edp_reset = true,
+};
+
 /* sun4i_drv uses this list to check if a device node is a TCON */
 const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun4i-a10-tcon", .data = _a10_quirks },
@@ -1187,6 +1212,8 @@ const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun8i-a83t-tcon-lcd", .data = 
_a83t_lcd_quirks },
{ .compatible = "allwinner,sun8i-a83t-tcon-tv", .data = 
_a83t_tv_quirks },
{ .compatible = "allwinner,sun8i-v3s-tcon", .data = _v3s_quirks },
+   { .compatible = "allwinner,sun9i-a80-tcon-lcd", .data = 
_a80_tcon_lcd_quirks },
+   { .compatible = "allwinner,sun9i-a80-tcon-tv", .data = 
_a80_tcon_tv_quirks },
{ }
 };
 MODULE_DEVICE_TABLE(of, sun4i_tcon_of_table);
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index abdc6ad6b384..c4979559b591 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -176,6 +176,7 @@ struct sun4i_tcon_quirks {
boolhas_channel_1;  /* a33 does not have channel 1 */
boolhas_lvds_alt;   /* Does the LVDS clock have a parent other than 
the TCON clock? */
boolneeds_de_be_mux; /* sun6i needs mux to select backend */
+   boolneeds_edp_reset; /* a80 edp reset needed for tcon0 access */
boolsupports_lvds;   /* Does the TCON support an LVDS output? */
 
/* callback to handle tcon muxing options */
-- 
2.16.2

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

[PATCH 6/8] ARM: dts: sun9i: Add device nodes for documented display pipelines for A80

[Chen-Yu Tsai]

The Allwinner A80 SoC has 3 display pipelines, of which some parts are
documented:

  - 3x display front ends (FE), documented
  - 2x display enhancement units (DEU), undocumented
  - 3x display back ends (BE), documented
  - 2x dynamic range controller (DRC), undocumented
  - 2x LCDC/TCONs, documented
  - 1x LCDC/TCON, undocumented, and probably not useable
  - 1x HDMI transmitter, undocumented but DesignWare compatible
  - 1x MERGE block, function unknown

This patch adds device nodes for the first 2 documented pipelines:

FE0 - DEU0 - - BE0 - DRC0 - TCON0
x
FE1 - DEU1 - - BE1 - DRC1 - TCON1

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun9i-a80.dtsi | 381 +++
 1 file changed, 381 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 82a770a5ba46..6fdb4eaa2e04 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -248,6 +248,12 @@
};
};
 
+   de: display-engine {
+   compatible = "allwinner,sun9i-a80-display-engine";
+   allwinner,pipelines = <>, <>;
+   status = "disabled";
+   };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -523,6 +529,381 @@
#reset-cells = <1>;
};
 
+   fe0: display-frontend@310 {
+   compatible = "allwinner,sun9i-a80-display-frontend";
+   reg = <0x0310 0x4>;
+   interrupts = ;
+   clocks = <_clocks CLK_BUS_FE0>, <_clocks CLK_FE0>,
+<_clocks CLK_DRAM_FE0>;
+   clock-names = "ahb", "mod",
+ "ram";
+   resets = <_clocks RST_FE0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   fe0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   fe0_out_deu0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_in_fe0>;
+   };
+   };
+   };
+   };
+
+   fe1: display-frontend@314 {
+   compatible = "allwinner,sun9i-a80-display-frontend";
+   reg = <0x0314 0x4>;
+   interrupts = ;
+   clocks = <_clocks CLK_BUS_FE1>, <_clocks CLK_FE1>,
+<_clocks CLK_DRAM_FE1>;
+   clock-names = "ahb", "mod",
+ "ram";
+   resets = <_clocks RST_FE0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   fe1_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   fe1_out_deu1: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_in_fe1>;
+   };
+   };
+   };
+   };
+
+   be0: display-backend@320 {
+   compatible = "allwinner,sun9i-a80-display-backend";
+   reg = <0x0320 0x4>;
+   interrupts = ;
+   clocks = <_clocks CLK_BUS_BE0>, <_clocks CLK_BE0>,
+<_clocks CLK_DRAM_BE0>;
+   clock-names = "ahb", "mod",
+ "ram";
+   resets = <_clocks RST_BE0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   be0_in: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   be0_in_deu0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_out_be0>;
+   };
+
+   be0_in_deu1: endpoint@1 {
+

[PATCH 4/8] drm/sun4i: Add compatible strings for the A80 display pipeline

[Chen-Yu Tsai]

This patch adds compatible strings for the remaining documented
components of the Allwinner A80 display pipeline.

Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 671d75c76ad0..3346c1e2a7a0 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -191,7 +191,7 @@ DRC
 ---
 
 The DRC (Dynamic Range Controller), found in the latest Allwinner SoCs
-(A31, A23, A33), allows to dynamically adjust pixel
+(A31, A23, A33, A80), allows to dynamically adjust pixel
 brightness/contrast based on histogram measurements for LCD content
 adaptive backlight control.
 
@@ -201,6 +201,7 @@ Required properties:
 * allwinner,sun6i-a31-drc
 * allwinner,sun6i-a31s-drc
 * allwinner,sun8i-a33-drc
+* allwinner,sun9i-a80-drc
   - reg: base address and size of the memory-mapped region.
   - interrupts: interrupt associated to this IP
   - clocks: phandles to the clocks feeding the DRC
@@ -227,6 +228,7 @@ Required properties:
 * allwinner,sun6i-a31-display-backend
 * allwinner,sun7i-a20-display-backend
 * allwinner,sun8i-a33-display-backend
+* allwinner,sun9i-a80-display-backend
   - reg: base address and size of the memory-mapped region.
   - interrupts: interrupt associated to this IP
   - clocks: phandles to the clocks feeding the frontend and backend
@@ -283,6 +285,7 @@ Required properties:
 * allwinner,sun6i-a31-display-frontend
 * allwinner,sun7i-a20-display-frontend
 * allwinner,sun8i-a33-display-frontend
+* allwinner,sun9i-a80-display-frontend
   - reg: base address and size of the memory-mapped region.
   - interrupts: interrupt associated to this IP
   - clocks: phandles to the clocks feeding the frontend and backend
@@ -339,6 +342,7 @@ Required properties:
 * allwinner,sun8i-a83t-display-engine
 * allwinner,sun8i-h3-display-engine
 * allwinner,sun8i-v3s-display-engine
+* allwinner,sun9i-a80-display-engine
 
   - allwinner,pipelines: list of phandle to the display engine
 frontends (DE 1.0) or mixers (DE 2.0) available.
-- 
2.16.2

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

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

[Robin Murphy]

On 12/03/18 10:41, Roger Quadros wrote:
[...]

@@ -0,0 +1,75 @@
+USB Connector
+=
+
+USB connector node represents physical USB connector. It should be
+a child of USB interface controller.
+
+Required properties:
+- compatible: describes type of the connector, must be one of:
+"usb-a-connector",
+"usb-b-connector",
+"usb-c-connector".

compatible should be just "usb-connector"

Type should be a property

type: type of usb connector "A", "B", "AB", "C"
AB is for dual-role connectors.


I have proposed such property (and size also) in my first RFC [1]. Rod
did not like it :)

[1]: https://marc.info/?l=devicetree=150660411515233=2



This is what Rob says here https://patchwork.kernel.org/patch/9976043/
"We did "type" for hdmi-connector, but I think I'd really prefer
compatible be used to distinguish as least where it may matter to s/w.
In the HDMI case, they all are pretty much the same, just different
physical size."

So the question is. Does it matter to this particular software implementation
if it is type A,B,C connector?
If yes, how?

Type A will never have any alternate function. It is always dedicated to USB.


In USB spec terms, at least. In reality there are things like the cool 
trick Rockchip SoCs do whereby they can expose the debug UART Rx/Tx 
through the OTG port's D+/D- pins, and that is on a type A connector in 
many products. I'm guessing that's probably beyond the scope of this 
binding, though.



Also does the size "full", "micro", "mini" matter to software?


If it means the user can look in sysfs to easily correlate logical ports 
with physical connectors that's certainly handy (e.g. on something like 
Odroid-XU where the two USB3 ports are brought out to an A and a 
micro-AB connector respectively).


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

[PATCH 7/8] ARM: dts: sun9i: Add pinmux settings for LCD0 RGB888 output.

[Chen-Yu Tsai]

The A80 supports RGB888 with H/V sync from LCD0. Add a pinmux setting
for the needed pins.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun9i-a80.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 6fdb4eaa2e04..25591d6883ef 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -953,6 +953,17 @@
function = "i2c3";
};
 
+   lcd0_rgb888_pins: lcd0-rgb888-pins {
+   pins = "PD0", "PD1", "PD2", "PD3",
+  "PD4", "PD5", "PD6", "PD7",
+  "PD8", "PD9", "PD10", "PD11",
+  "PD12", "PD13", "PD14", "PD15",
+  "PD16", "PD17", "PD18", "PD19",
+  "PD20", "PD21", "PD22", "PD23",
+  "PD24", "PD25", "PD26", "PD27";
+   function = "lcd0";
+   };
+
mmc0_pins: mmc0-pins {
pins = "PF0", "PF1" ,"PF2", "PF3",
   "PF4", "PF5";
-- 
2.16.2

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

[PATCH 8/8] ARM: dts: sun9i: cubieboard4: Enable VGA display output

[Chen-Yu Tsai]

The Cubieboard4 has a dumb VGA DAC connected to the output of LCD0,
providing VGA output through the onboard VGA connector. The DDC lines
are connected to i2c3.

The VGA DAC is a GM7123, which is compatible with Analog Devices'
ADV7123, except it only takes 3.3V power, and has a lower standby power
consumption. The datasheet found online lists "Chengdu GoldTel Electronical
Technology Co., Ltd." as its designer. The company changed its name in
2014 to "Chengdu Corpro Technology Co., Ltd.". Their website lists similar
ICs, but not actually the GM7123.

Enable the display pipeline with the VGA DAC and connector, and i2c3
for DDC.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 68 +
 1 file changed, 68 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts 
b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index 31b06ecbc306..85da85faf869 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -74,6 +74,52 @@
};
};
 
+   vga-connector {
+   compatible = "vga-connector";
+   label = "vga";
+   ddc-i2c-bus = <>;
+
+   port {
+   vga_con_in: endpoint {
+   remote-endpoint = <_dac_out>;
+   };
+   };
+   };
+
+   vga-dac {
+   compatible = "corpro,gm7123", "adi,adv7123", "dumb-vga-dac";
+   vdd-supply = <_dcdc1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   vga_dac_in: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_vga>;
+   };
+   };
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   vga_dac_out: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_con_in>;
+   };
+   };
+   };
+   };
+
wifi_pwrseq: wifi-pwrseq {
compatible = "mmc-pwrseq-simple";
clocks = <_rtc 1>;
@@ -83,6 +129,16 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
@@ -402,6 +458,18 @@
 
 #include "axp809.dtsi"
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgb888_pins>;
+};
+
+_out {
+   tcon0_out_vga: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_dac_in>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_ph_pins>;
-- 
2.16.2

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

[PATCH 5/8] drm/sun4i: Add driver support for A80 display pipeline

[Chen-Yu Tsai]

This patch adds support for the compatible strings of the A80 display
pipeline.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c |  7 +++
 drivers/gpu/drm/sun4i/sun4i_drv.c | 12 ++--
 drivers/gpu/drm/sun4i/sun6i_drc.c |  1 +
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 092ade4ff6a5..ed36240048d5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -793,6 +793,9 @@ static const struct sun4i_backend_quirks 
sun7i_backend_quirks = {
 static const struct sun4i_backend_quirks sun8i_a33_backend_quirks = {
 };
 
+static const struct sun4i_backend_quirks sun9i_backend_quirks = {
+};
+
 static const struct of_device_id sun4i_backend_of_table[] = {
{
.compatible = "allwinner,sun4i-a10-display-backend",
@@ -814,6 +817,10 @@ static const struct of_device_id sun4i_backend_of_table[] 
= {
.compatible = "allwinner,sun8i-a33-display-backend",
.data = _a33_backend_quirks,
},
+   {
+   .compatible = "allwinner,sun9i-a80-display-backend",
+   .data = _backend_quirks,
+   },
{ }
 };
 MODULE_DEVICE_TABLE(of, sun4i_backend_of_table);
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index a0f43b81c64c..7f0705ef9f4e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -176,7 +176,13 @@ static bool sun4i_drv_node_is_frontend(struct device_node 
*node)
of_device_is_compatible(node, 
"allwinner,sun5i-a13-display-frontend") ||
of_device_is_compatible(node, 
"allwinner,sun6i-a31-display-frontend") ||
of_device_is_compatible(node, 
"allwinner,sun7i-a20-display-frontend") ||
-   of_device_is_compatible(node, 
"allwinner,sun8i-a33-display-frontend");
+   of_device_is_compatible(node, 
"allwinner,sun8i-a33-display-frontend") ||
+   of_device_is_compatible(node, 
"allwinner,sun9i-a80-display-frontend");
+}
+
+static bool sun4i_drv_node_is_deu(struct device_node *node)
+{
+   return of_device_is_compatible(node, "allwinner,sun9i-a80-deu");
 }
 
 static bool sun4i_drv_node_is_supported_frontend(struct device_node *node)
@@ -257,7 +263,8 @@ static int sun4i_drv_add_endpoints(struct device *dev,
 * enabled frontend supported by the driver, we add it to our
 * component list.
 */
-   if (!sun4i_drv_node_is_frontend(node) ||
+   if (!(sun4i_drv_node_is_frontend(node) ||
+ sun4i_drv_node_is_deu(node)) ||
(sun4i_drv_node_is_supported_frontend(node) &&
 of_device_is_available(node))) {
/* Add current component */
@@ -361,6 +368,7 @@ static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun8i-a83t-display-engine" },
{ .compatible = "allwinner,sun8i-h3-display-engine" },
{ .compatible = "allwinner,sun8i-v3s-display-engine" },
+   { .compatible = "allwinner,sun9i-a80-display-engine" },
{ }
 };
 MODULE_DEVICE_TABLE(of, sun4i_drv_of_table);
diff --git a/drivers/gpu/drm/sun4i/sun6i_drc.c 
b/drivers/gpu/drm/sun4i/sun6i_drc.c
index 09bba853e2a4..b5e071a49045 100644
--- a/drivers/gpu/drm/sun4i/sun6i_drc.c
+++ b/drivers/gpu/drm/sun4i/sun6i_drc.c
@@ -101,6 +101,7 @@ static const struct of_device_id sun6i_drc_of_table[] = {
{ .compatible = "allwinner,sun6i-a31-drc" },
{ .compatible = "allwinner,sun6i-a31s-drc" },
{ .compatible = "allwinner,sun8i-a33-drc" },
+   { .compatible = "allwinner,sun9i-a80-drc" },
{ }
 };
 MODULE_DEVICE_TABLE(of, sun6i_drc_of_table);
-- 
2.16.2

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

[PATCH 1/8] drm/sun4i: Add compatible strings for A80 TCONs

[Chen-Yu Tsai]

The A80 has 2 or 3 TCONs. The documentation and vendor kernel are very
vague about the third TCON, to the point that it might not exist.

In the documentation, the first TCON is missing channel 1, and the
second is missing channel 0. However the vendor kernel seems to be
able to use them regardless. Here we model them like the old TCONs.

An oddity is that TCON0 requires the reset control for the eDP block
to be deasserted, for any register access to stick.

This patch adds compatible strings for TCON0 and TCON1, with TCON0
requiring an extra "edp" reset control.

Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 8bdef4920edc..c05cbcdde4d7 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -146,13 +146,16 @@ Required properties:
* allwinner,sun8i-a83t-tcon-lcd
* allwinner,sun8i-a83t-tcon-tv
* allwinner,sun8i-v3s-tcon
+   * allwinner,sun9i-a80-tcon-lcd
+   * allwinner,sun9i-a80-tcon-tv
  - reg: base address and size of memory-mapped region
  - interrupts: interrupt associated to this IP
  - clocks: phandles to the clocks feeding the TCON.
- 'ahb': the interface clocks
-   - 'tcon-ch0': The clock driving the TCON channel 0, except for A83T TV TCON
+   - 'tcon-ch0': The clock driving the TCON channel 0, if supported
  - resets: phandles to the reset controllers driving the encoder
-   - "lcd": the reset line for the TCON channel 0
+   - "lcd": the reset line for the TCON
+   - "edp": the reset line for the eDP block (A80 only)
 
  - clock-names: the clock names mentioned above
  - reset-names: the reset names mentioned above
@@ -171,7 +174,9 @@ Required properties:
   channel the endpoint is associated to. If that property is not
   present, the endpoint number will be used as the channel number.
 
-On SoCs other than the A33 and V3s, there is one more clock required:
+For TCONs with channel 0, there is one more clock required:
+   - 'tcon-ch0': The clock driving the TCON channel 0
+For TCONs with channel 1, there is one more clock required:
- 'tcon-ch1': The clock driving the TCON channel 1
 
 When TCON support LVDS (all TCONs except TV TCON on A83T and those found
-- 
2.16.2

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

[PATCH 2/8] drm/sun4i: Add DT binding for Detail Enhancement Unit in Allwinner A80 SoC

[Chen-Yu Tsai]

The display pipeline on the A80 SoC has what is called the Detail
Enhancement Unit, or DEU for short, block in between the display
frontend and backend. This unit can sharpen images in both luma
and chroma channels. It seems to also do colorspace conversion.

This patch adds the device tree binding for this hardware block.

Signed-off-by: Chen-Yu Tsai 
---
 .../bindings/display/sunxi/sun4i-drm.txt   | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index c05cbcdde4d7..671d75c76ad0 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -248,6 +248,28 @@ On the A33, some additional properties are required:
   - resets and reset-names need to have a phandle to the SAT bus
 resets, whose name will be "sat"
 
+DEU
+---
+
+The DEU (Detail Enhancement Unit), found in the Allwinner A80 SoC,
+can sharpen the display content in both luma and chroma channels.
+
+Required properties:
+  - compatible: value must be one of:
+* allwinner,sun9i-a80-deu
+  - reg: base address and size of the memory-mapped region.
+  - interrupts: interrupt associated to this IP
+  - clocks: phandles to the clocks feeding the DEU
+* ahb: the DEU interface clock
+* mod: the DEU module clock
+* ram: the DEU DRAM clock
+  - clock-names: the clock names mentioned above
+  - resets: phandles to the reset line driving the DEU
+
+- ports: A ports node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt. The
+  first port should be the input endpoints, the second one the outputs
+
 Display Engine Frontend
 ---
 
-- 
2.16.2

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

[PATCH 0/8] ARM: sun9i: a80: Add display support

[Chen-Yu Tsai]

Hi everyone,

This series adds basic support for the display pipelines found on the
Allwinner A80 SoC. Currently only parallel RGB output via TCON0 is
supported. TCON1 drives the HDMI encoder, which I've not been able to
get working yet.

Patch 1 adds device tree bindings for the TCONs on the A80. In
particular, TCON0 requires the eDP reset control in addition to its own.

Patch 2 adds a device tree binding for the Detail Enhancement Unit found
only on the A80.

Patch 3 adds driver support for the TCONs.

Patch 4 adds compatible strings to the device tree bindings for all the 
remaining peripherals covered by this series.

Patch 5 adds support for the compatible strings from the previous patch
to the sun4i-drm driver.

Patch 6 adds the display pipeline device nodes to the A80 .dtsi file.

Patch 7 adds a pinmux setting for RGB888 output for TCON0.

Patch 8 enables VGA output on the Cubieboard4 via an external DAC and
an I2C bus from the SoC for DDC.


I've had these patches for quite some time now, rebasing them as more
features were added to sun4i-drm. Please have a look.


Regards
ChenYu


Chen-Yu Tsai (8):
  drm/sun4i: Add compatible strings for A80 TCONs
  drm/sun4i: Add DT binding for Detail Enhancement Unit in Allwinner A80
SoC
  drm/sun4i: Add support for A80 TCONs
  drm/sun4i: Add compatible strings for the A80 display pipeline
  drm/sun4i: Add driver support for A80 display pipeline
  ARM: dts: sun9i: Add device nodes for documented display pipelines for
A80
  ARM: dts: sun9i: Add pinmux settings for LCD0 RGB888 output.
  ARM: dts: sun9i: cubieboard4: Enable VGA display output

 .../bindings/display/sunxi/sun4i-drm.txt   |  39 +-
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts|  68 
 arch/arm/boot/dts/sun9i-a80.dtsi   | 392 +
 drivers/gpu/drm/sun4i/sun4i_backend.c  |   7 +
 drivers/gpu/drm/sun4i/sun4i_drv.c  |  12 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  27 ++
 drivers/gpu/drm/sun4i/sun4i_tcon.h |   1 +
 drivers/gpu/drm/sun4i/sun6i_drc.c  |   1 +
 8 files changed, 541 insertions(+), 6 deletions(-)

-- 
2.16.2

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

[Bug 105515] hw_init of IP block failed

[bugzilla-daemon]

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

--- Comment #3 from Alex Deucher  ---
Please attach your full dmesg output.

-- 
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 v4 2/3] drm/panel: support Innolux P097PFG panel

[Lin Huang]

Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, it reuse
the Innolux P079ZCA panel driver.

Change-Id: I97923aa3735f707332681691b0231c9421b427d0
Signed-off-by: Lin Huang 
---
Changes in v2:
- None
Changes in v3:
- None
Changes in v4:
- download panel initial code 

 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 192 +-
 1 file changed, 187 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 2075a9d..883b279 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -20,6 +20,15 @@
 
 #include 
 
+struct panel_init_cmd {
+   int len;
+   const char *data;
+};
+
+#define _INIT_CMD(...) { \
+   .len = sizeof((char[]){__VA_ARGS__}), \
+   .data = (char[]){__VA_ARGS__} }
+
 struct panel_desc {
const struct drm_display_mode *modes;
unsigned int bpc;
@@ -30,6 +39,7 @@ struct panel_desc {
 
unsigned long flags;
enum mipi_dsi_pixel_format format;
+   const struct panel_init_cmd *init_cmds;
unsigned int lanes;
 };
 
@@ -88,9 +98,12 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
return err;
}
 
+   /* p097pfg: t15 */
+   msleep(100);
+
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
 
-   /* T8: 80ms - 1000ms */
+   /* p079zca: t8*/
msleep(80);
 
regulator_disable(innolux->avee);
@@ -124,13 +137,43 @@ static int innolux_panel_prepare(struct drm_panel *panel)
if (err < 0)
goto disable_avdd;
 
-   /* T2: 15ms - 1000ms */
-   usleep_range(15000, 16000);
+   /* p079zca: t2 (20ms), p097pfg: t4 (15ms) */
+   usleep_range(2, 21000);
 
gpiod_set_value_cansleep(innolux->enable_gpio, 1);
 
-   /* T4: 15ms - 1000ms */
-   usleep_range(15000, 16000);
+   /* p079zca: t4, p097pfg: t5 */
+   usleep_range(2, 21000);
+
+   if (innolux->desc->init_cmds) {
+   const struct panel_init_cmd *cmds =
+   innolux->desc->init_cmds;
+   int i;
+
+   for (i = 0; cmds[i].len != 0; i++) {
+   const struct panel_init_cmd *cmd = [i];
+
+   err = mipi_dsi_generic_write(innolux->link, cmd->data,
+cmd->len);
+   if (err < 0) {
+   dev_err(panel->dev,
+   "failed to write command %d\n", i);
+   goto poweroff;
+   }
+
+   /*
+* Included by random guessing, because without this
+* (or at least, some delay), the panel sometimes
+* didn't appear to pick up the command sequence.
+*/
+   err = mipi_dsi_dcs_nop(innolux->link);
+   if (err < 0) {
+   dev_err(panel->dev,
+   "failed to send DCS nop: %d\n", err);
+   goto poweroff;
+   }
+   }
+   }
 
err = mipi_dsi_dcs_exit_sleep_mode(innolux->link);
if (err < 0) {
@@ -213,6 +256,142 @@ static const struct panel_desc innolux_p079zca_panel_desc 
= {
.lanes = 4,
 };
 
+static const struct drm_display_mode innolux_p097pfg_mode = {
+   .clock = 229000,
+   .hdisplay = 1536,
+   .hsync_start = 1536 + 100,
+   .hsync_end = 1536 + 100 + 24,
+   .htotal = 1536 + 100 + 24 + 100,
+   .vdisplay = 2048,
+   .vsync_start = 2048 + 100,
+   .vsync_end = 2048 + 100 + 2,
+   .vtotal = 2048 + 100 + 2 + 18,
+   .vrefresh = 60,
+};
+
+static const struct panel_init_cmd innolux_p097pfg_init_cmds[] = {
+   /* page 0 */
+   _INIT_CMD(0xF0, 0x55, 0xAA, 0x52, 0x08, 0x00),
+   _INIT_CMD(0xB1, 0xE8, 0x11),
+   _INIT_CMD(0xB2, 0x25, 0x02),
+   _INIT_CMD(0xB5, 0x08, 0x00),
+   _INIT_CMD(0xBC, 0x0F, 0x00),
+   _INIT_CMD(0xB8, 0x03, 0x06, 0x00, 0x00),
+   _INIT_CMD(0xBD, 0x01, 0x90, 0x14, 0x14),
+   _INIT_CMD(0x6F, 0x01),
+   _INIT_CMD(0xC0, 0x03),
+   _INIT_CMD(0x6F, 0x02),
+   _INIT_CMD(0xC1, 0x0D),
+   _INIT_CMD(0xD9, 0x01, 0x09, 0x70),
+   _INIT_CMD(0xC5, 0x12, 0x21, 0x00),
+   _INIT_CMD(0xBB, 0x93, 0x93),
+
+   /* page 1 */
+   _INIT_CMD(0xF0, 0x55, 0xAA, 0x52, 0x08, 0x01),
+   _INIT_CMD(0xB3, 0x3C, 0x3C),
+   _INIT_CMD(0xB4, 0x0F, 0x0F),
+   _INIT_CMD(0xB9, 0x45, 0x45),
+   _INIT_CMD(0xBA, 0x14, 0x14),
+   _INIT_CMD(0xCA, 0x02),
+   _INIT_CMD(0xCE, 0x04),
+   _INIT_CMD(0xC3, 0x9B, 0x9B),
+   _INIT_CMD(0xD8, 0xC0, 0x03),
+   _INIT_CMD(0xBC, 0x82, 0x01),
+   _INIT_CMD(0xBD, 0x9E, 0x01),
+

[PATCH v4 3/3] dt-bindings: Add INNOLUX P097PFG panel bindings

[Lin Huang]

From: huang lin 

The Innolux P097PFG panel is 9.7" panel with 1536X2048
resolution, it reuse P079ZCA panel driver, so improve
p079ZCA dt-binding to support P097PFG.

Change-Id: I8704914898fe53b734d31fbe646df8aa5fd8b30d
Signed-off-by: Lin Huang 
---
Changes in v2:
- None
Changes in v3:
- None
Changes in v4:
- None

 .../devicetree/bindings/display/panel/innolux,p079zca.txt | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
index d0f5516..8cadd8c 100644
--- a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
@@ -1,13 +1,18 @@
 Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
+Innolux P097PFG 9.7" 1536x2048 TFT LCD panel
 
 Required properties:
-- compatible: should be "innolux,p079zca"
+- compatible: should be should be one of the following.
+-"innolux,p079zca" for Innolux 7.9" P079ZCA 768*1024 panel
+-"innolux,p097pfg" for Innolux 9.7" P097PFG 1536*2048 panel
 - reg: DSI virtual channel of the peripheral
-- power-supply: phandle of the regulator that provides the supply voltage
 - enable-gpios: panel enable gpio
 
 Optional properties:
 - backlight: phandle of the backlight device attached to the panel
+- power-supply: phandle of the regulator that provides the supply voltage
+- avdd-supply: phandle of the regulator that provides positive voltage
+- avee-supply: phandle of the regulator that provides negative voltage
 
 Example:
 
@@ -16,6 +21,8 @@ Example:
compatible = "innolux,p079zca";
reg = <0>;
power-supply = <...>;
+   avdd-supply = <...>;
+   avee-supply = <...>;
backlight = <>;
enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
};
-- 
2.7.4

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

Re: [PATCH] drm/i915: drop various VLAs in i915_debugfs.c

[Salvatore Mesoraca]

2018-03-14 13:17 GMT+01:00 Jani Nikula :
> Thanks for your patch. However, Chris beat you to it with:
>
> 7aa0b14ede64 ("drm/i915: Remove variable length arrays from sseu debugfs
> printers")

I didn't notice it :)

> as well as adding -Wvla to our subdir-ccflags-y to prevent more from
> cropping up:
>
> c5c2b11894f4 ("drm/i915: Warn against variable length arrays")

Great!
Best regards,

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

[PATCH] drm/i915/pmu: Work around compiler warnings on some kernel configs

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Arnd Bergman reports:
"""
The conditional spinlock confuses gcc into thinking the 'flags' value
might contain uninitialized data:

drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read':
arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]

The code is correct, but it's easy to see how the compiler gets confused
here. This avoids the problem by pulling the lock outside of the function
into its only caller.
"""

On deeper look it seems this is caused by paravirt spinlocks
implementation when CONFIG_PARAVIRT_DEBUG is set, which by being
complicated, manages to convince gcc locked parameter can be changed
externally (impossible).

Work around it by removing the conditional locking parameters altogether.
(It was never the most elegant code anyway.)

Slight penalty we now pay is an additional irqsave spin lock/unlock cycle
on the event enable path. But since enable is not a fast path, that is
preferrable to the alternative solution which was doing MMIO under irqsave
spinlock.

Signed-off-by: Tvrtko Ursulin 
Reported-by: Arnd Bergmann 
Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Imre Deak 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: David Airlie 
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/i915/i915_pmu.c | 32 +---
 1 file changed, 13 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 4bc7aefa9541..11fb76bd3860 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -412,7 +412,7 @@ static u64 __get_rc6(struct drm_i915_private *i915)
return val;
 }
 
-static u64 get_rc6(struct drm_i915_private *i915, bool locked)
+static u64 get_rc6(struct drm_i915_private *i915)
 {
 #if IS_ENABLED(CONFIG_PM)
unsigned long flags;
@@ -428,8 +428,7 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
locked)
 * previously.
 */
 
-   if (!locked)
-   spin_lock_irqsave(>pmu.lock, flags);
+   spin_lock_irqsave(>pmu.lock, flags);
 
if (val >= i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 0;
@@ -438,12 +437,10 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
locked)
val = i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
}
 
-   if (!locked)
-   spin_unlock_irqrestore(>pmu.lock, flags);
+   spin_unlock_irqrestore(>pmu.lock, flags);
} else {
struct pci_dev *pdev = i915->drm.pdev;
struct device *kdev = >dev;
-   unsigned long flags2;
 
/*
 * We are runtime suspended.
@@ -452,10 +449,8 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
locked)
 * on top of the last known real value, as the approximated RC6
 * counter value.
 */
-   if (!locked)
-   spin_lock_irqsave(>pmu.lock, flags);
-
-   spin_lock_irqsave(>power.lock, flags2);
+   spin_lock_irqsave(>pmu.lock, flags);
+   spin_lock(>power.lock);
 
if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
i915->pmu.suspended_jiffies_last =
@@ -465,14 +460,13 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
locked)
  i915->pmu.suspended_jiffies_last;
val += jiffies - kdev->power.accounting_timestamp;
 
-   spin_unlock_irqrestore(>power.lock, flags2);
+   spin_unlock(>power.lock);
 
val = jiffies_to_nsecs(val);
val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
 
-   if (!locked)
-   spin_unlock_irqrestore(>pmu.lock, flags);
+   spin_unlock_irqrestore(>pmu.lock, flags);
}
 
return val;
@@ -481,7 +475,7 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
locked)
 #endif
 }
 
-static u64 __i915_pmu_event_read(struct perf_event *event, bool locked)
+static u64 __i915_pmu_event_read(struct perf_event *event)
 {
struct drm_i915_private *i915 =
container_of(event->pmu, typeof(*i915), pmu.base);
@@ -519,7 +513,7 @@ static u64 __i915_pmu_event_read(struct perf_event *event, 
bool locked)
   

fbcon non-desktop display use

[Charles Lohr]

There was a patch submitted by Keith Packard which prevents fbcon from
using non-desktop displays, but this breaks vive, and other HMD
development/use on embedded and other fbdev systems (
https://patchwork.kernel.org/patch/10053989/ ).

Even if the vive is the only device connected, it will still not permit it
to be operated.  See https://github.com/linux-sunxi/linux-sunxi/issues/291
for dri with a lot of debugging turned on.

I can understand that most users would probably prefer that the vive isn't
automatically used if no other displays are available, however, the current
behavior prevents use of the vive on all devices that use fbdev for their
primary output.

This patch allows enabling of non-desktop devices both as a kernel command
line as well as by setting /sys/module/drm_kms_helper/par
ameters/drm_fbdev_permit_non_desktop.

I've never sent an email to the kernel devel list, so I'm still a little
nervous.  Especially because this is against a different branch, and I'm
starting to think that I should be messaging there, but this is something
that really needs to go upstream.

Signed-off-by:

diff --git a/drivers/gpu/drm/drm_fb_helper.c
b/drivers/gpu/drm/drm_fb_helper.c
index 035784ddd..8bfaf79ff 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -55,6 +55,11 @@ MODULE_PARM_DESC(drm_fbdev_overalloc,
 "Overallocation of the fbdev buffer (%) [default="
 __MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]");

+static bool drm_fbdev_permit_non_desktop;
+module_param(drm_fbdev_permit_non_desktop, bool, 0644);
+MODULE_PARM_DESC(drm_fbdev_permit_non_desktop,
+   "Allow the framebuffer to use non-desktop displays
[default=off]");
+
 static LIST_HEAD(kernel_fb_helper_list);
 static DEFINE_MUTEX(kernel_fb_helper_lock);

@@ -2109,7 +2114,7 @@ static bool drm_connector_enabled(struct
drm_connector *connector, bool strict)
 {
bool enable;

-   if (connector->display_info.non_desktop)
+   if (connector->display_info.non_desktop &&
!drm_fbdev_permit_non_desktop)
return false;

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

[PATCH v1 2/3] drm/tegra: plane: Correct legacy blending

[Dmitry Osipenko]

Keep old 'dependent' state of unaffected planes, this way new state takes
into account current state of unaffected planes.

Fixes: ebae8d07435a ("drm/tegra: dc: Implement legacy blending")
Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/tegra/plane.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
index fc37dcf8c458..3c0cb6a04c66 100644
--- a/drivers/gpu/drm/tegra/plane.c
+++ b/drivers/gpu/drm/tegra/plane.c
@@ -287,13 +287,11 @@ unsigned int tegra_plane_format_adjust(unsigned int 
opaque)
return opaque;
 }
 
-unsigned int tegra_plane_get_overlap_index(struct tegra_plane *plane,
-  struct tegra_plane *other)
+static unsigned int tegra_plane_get_overlap_index(struct tegra_plane *plane,
+ struct tegra_plane *other)
 {
unsigned int index = 0, i;
 
-   WARN_ON(plane == other);
-
for (i = 0; i < 3; i++) {
if (i == plane->index)
continue;
@@ -310,18 +308,15 @@ unsigned int tegra_plane_get_overlap_index(struct 
tegra_plane *plane,
 void tegra_plane_check_dependent(struct tegra_plane *tegra,
 struct tegra_plane_state *state)
 {
-   struct drm_plane_state *old, *new;
+   struct drm_plane_state *new;
struct drm_plane *plane;
unsigned int zpos[2];
unsigned int i;
 
-   for (i = 0; i < 3; i++)
-   state->dependent[i] = false;
-
for (i = 0; i < 2; i++)
zpos[i] = 0;
 
-   for_each_oldnew_plane_in_state(state->base.state, plane, old, new, i) {
+   for_each_new_plane_in_state(state->base.state, plane, new, i) {
struct tegra_plane *p = to_tegra_plane(plane);
unsigned index;
 
@@ -331,6 +326,8 @@ void tegra_plane_check_dependent(struct tegra_plane *tegra,
 
index = tegra_plane_get_overlap_index(tegra, p);
 
+   state->dependent[i] = false;
+
/*
 * If any of the other planes is on top of this plane and uses
 * a format with an alpha component, mark this plane as being
-- 
2.16.1

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

Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

[hl]

Hi Emil,


On Wednesday, March 14, 2018 08:02 PM, Emil Velikov wrote:

Hi Lin,

On 14 March 2018 at 09:12, Lin Huang  wrote:

From: huang lin 

Refactor Innolux P079ZCA panel driver, let it support
multi panel.

Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
Signed-off-by: Lin Huang 
---
Changes in v2:
- Change regulator property name to meet the panel datasheet
Changes in v3:
- this patch only refactor P079ZCA panel to support multi panel, support 
P097PFG panel in another patch
Changes in v4:
- Modify the patch which suggest by Thierry


Thanks for splitting this up. I think there's another piece that fell
through the cracks.
I'm not deeply familiar with the driver, so just sharing some quick notes.



  struct innolux_panel {
 struct drm_panel base;
 struct mipi_dsi_device *link;
+   const struct panel_desc *desc;

 struct backlight_device *backlight;
-   struct regulator *supply;
+   struct regulator *vddi;
+   struct regulator *avdd;
+   struct regulator *avee;

These two seem are new addition, as opposed to a dummy refactor.
Are they optional, does one need them for the existing panel (separate
patch?) or only for the new one (squash with the new panel code)?



 struct gpio_desc *enable_gpio;

 bool prepared;
@@ -77,9 +93,9 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
 /* T8: 80ms - 1000ms */
 msleep(80);

-   err = regulator_disable(innolux->supply);
-   if (err < 0)
-   return err;

Good call on dropping the early return here.



@@ -207,19 +248,28 @@ static const struct drm_panel_funcs innolux_panel_funcs = 
{
-   innolux->supply = devm_regulator_get(dev, "power");
-   if (IS_ERR(innolux->supply))
-   return PTR_ERR(innolux->supply);
+   innolux = devm_kzalloc(dev, sizeof(*innolux), GFP_KERNEL);
+   if (!innolux)
+   return -ENOMEM;
+
+   innolux->desc = desc;
+   innolux->vddi = devm_regulator_get(dev, "power");
+   innolux->avdd = devm_regulator_get(dev, "avdd");
+   innolux->avee = devm_regulator_get(dev, "avee");


AFAICT devm_regulator_get returns a pointer which is unsuitable to be
passed into regulator_{enable,disable}.
Hence, the IS_ERR check should stay. If any of the regulators are
optional, you want to call regulator_{enable,disable} only as
applicable.


devm_regulator_get() will use dummy_regulator if there not regulator pass to 
driver,
so it not affect regulator_{enable, disable}. These three regulator are 
optional,
the p079zca will use "power" and p097pgf will use "avdd" and "avee",
so i think it better not to check ERR here.




@@ -318,5 +377,6 @@ static struct mipi_dsi_driver innolux_panel_driver = {
  module_mipi_dsi_driver(innolux_panel_driver);

  MODULE_AUTHOR("Chris Zhong ");
+MODULE_AUTHOR("Lin Huang ");

I don't think refactoring existing code classify as being the module author.
Then again, I could be wrong.

HTH
Emil






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