Re: [PATCH 0/6] TDA998x CEC support

[Hans Verkuil]

On 11/29/2017 08:41 AM, Hans Verkuil wrote:
> Hi Russell,
> 
> On 11/29/2017 12:17 AM, Russell King - ARM Linux wrote:
>> Hi,
>>
>> This patch series adds CEC support to the DRM TDA998x driver.  The
>> TDA998x family of devices integrate a TDA9950 CEC at a separate I2C
>> address from the HDMI encoder.
>>
>> Implementation of the CEC part is separate to allow independent CEC
>> implementations, or independent HDMI implementations (since the
>> TDA9950 may be a separate device.)
> 
> Thank you for this patch series! I assume you are testing this with a
> BeagleBone Black? If so, do you have a patch for the dts that hooks up the
> interrupt? If possible, I'd like to test this with my BBB.

BTW, I didn't see this patch series appear on dri-devel, even though it is
CC-ed there. Odd.

Regards,

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

Re: [PATCH 0/6] TDA998x CEC support

[Hans Verkuil]

Hi Russell,

On 11/29/2017 12:17 AM, Russell King - ARM Linux wrote:
> Hi,
> 
> This patch series adds CEC support to the DRM TDA998x driver.  The
> TDA998x family of devices integrate a TDA9950 CEC at a separate I2C
> address from the HDMI encoder.
> 
> Implementation of the CEC part is separate to allow independent CEC
> implementations, or independent HDMI implementations (since the
> TDA9950 may be a separate device.)

Thank you for this patch series! I assume you are testing this with a
BeagleBone Black? If so, do you have a patch for the dts that hooks up the
interrupt? If possible, I'd like to test this with my BBB.

Regards,

Hans

> 
>  drivers/gpu/drm/i2c/Kconfig   |   6 +
>  drivers/gpu/drm/i2c/Makefile  |   1 +
>  drivers/gpu/drm/i2c/tda9950.c | 507 
> ++
>  drivers/gpu/drm/i2c/tda998x_drv.c | 246 +++--
>  include/linux/platform_data/tda9950.h |  16 ++
>  5 files changed, 748 insertions(+), 28 deletions(-)
> 

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

Re: [PATCH 14/15] drm/zte: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Shawn Guo]

On Thu, Nov 23, 2017 at 09:05:01PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
> 
> Note that this replaces crtc_state->adjusted_mode usage with
> crtc_state->mode. The latter is the correct choice since that's the
> mode the user provided and it matches the plane crtc coordinates
> the user also provided.
> 
> Once everyone agrees on this we can move the clip handling into
> drm_atomic_helper_check_plane_state().
> 
> Cc: Laurent Pinchart 
> Cc: Shawn Guo 

Acked-by: Shawn Guo 

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

Re: [RFC][PATCH] drm: adv7511/33: Fix adv7511_cec_init() failure handling

[Archit Taneja]

On 11/29/2017 03:02 AM, John Stultz wrote:

On Sun, Nov 26, 2017 at 4:56 AM, Archit Taneja  wrote:


On 11/17/2017 04:29 AM, John Stultz wrote:

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 0e14f15..939c3b9 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1203,12 +1203,12 @@ static int adv7511_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
 #ifdef CONFIG_DRM_I2C_ADV7511_CEC
 ret = adv7511_cec_init(dev, adv7511, offset);
-   if (ret)
-   goto err_unregister_cec;
   #else
-   regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
-ADV7511_CEC_CTRL_POWER_DOWN);
+   ret = 1;
   #endif
+   if (ret)
+   regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL +
offset,
+ADV7511_CEC_CTRL_POWER_DOWN);



This would force CEC to be powered off even if adv7511_cec_init() returned
0, right?


I don't think so. The initent was its only powered off if
adv7511_cec_init returns an error or if  CONFIG_DRM_I2C_ADV7511_CEC is
not set.


Do we know why the call to adv7511_cec_init() is failing on the Hikey board?
If it's
because there isn't a "cec" clock specified in DT, it's not really a fatal
error, it
just means that the platform hasn't been set up to support CEC. In that


Yea. I believe this is the case w/ HiKey.  I don't have deeply
detailed docs on the board so I'm not sure if we will be able to
enable that or not (Xinliang/Guodong: Do you know if its possible?).
In the meantime though, we shouldn't regress.


case, we
should just power down the CEC block. So, if adv7511_cec_init() would return
a
-ENOENT, which we could use as a hint to power down CEC. So, maybe something
like this?:

#ifdef CONFIG_DRM_I2C_ADV7511_CEC
 ret = adv7511_cec_init(dev, adv7511, offset);
 if (ret && ret != -ENOENT)
 goto err_unregister_cec;
#endif
 if (ret)
 regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
 ADV7511_CEC_CTRL_POWER_DOWN);

Apart from this, we should also move adv7511_cec_init() up in the probe so
that
it's called before the drm_bridge is registered.


Hans has since reworked the patch w/ a new version. You might want to
check his patches and see if they fit what your imagining.


Yes, I saw Hans's patch after I wrote to you. That patch looks perfect. I'll
queue that to the drm-misc repo once it's rebased on 4.15-rc1.

Thanks,
Archit



thanks
-john



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/sun4i: use sun4i_tcon_of_table to check if a device node is a TCON

[Chen-Yu Tsai]

On Tue, Nov 28, 2017 at 6:01 PM, Maxime Ripard
 wrote:
> Hi,
>
> On Mon, Nov 27, 2017 at 04:46:32PM +0800, Chen-Yu Tsai wrote:
>> The sun4i DRM driver maintains a list of compatible strings it uses to
>> check if a device node within the display component graph is a TCON.
>> The TCON driver also has this list, used to bind the TCON driver to
>> the device. These two lists are identical.
>>
>> Instead of maintaining two identical lists, export the list from the
>> TCON driver for the DRM driver to use.
>>
>> Suggested-by: Rob Herring 
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  drivers/gpu/drm/sun4i/sun4i_drv.c  | 8 +---
>>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 +++-
>>  drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 ++
>>  3 files changed, 6 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
>> b/drivers/gpu/drm/sun4i/sun4i_drv.c
>> index 75c76cdd82bc..49215d91c853 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
>> @@ -187,13 +187,7 @@ static bool sun4i_drv_node_is_frontend(struct 
>> device_node *node)
>>
>>  static bool sun4i_drv_node_is_tcon(struct device_node *node)
>>  {
>> - return of_device_is_compatible(node, "allwinner,sun4i-a10-tcon") ||
>> - of_device_is_compatible(node, "allwinner,sun5i-a13-tcon") ||
>> - of_device_is_compatible(node, "allwinner,sun6i-a31-tcon") ||
>> - of_device_is_compatible(node, "allwinner,sun6i-a31s-tcon") ||
>> - of_device_is_compatible(node, "allwinner,sun7i-a20-tcon") ||
>> - of_device_is_compatible(node, "allwinner,sun8i-a33-tcon") ||
>> - of_device_is_compatible(node, "allwinner,sun8i-v3s-tcon");
>> + return !!of_match_node(sun4i_tcon_of_table, node);
>>  }
>>
>>  static int compare_of(struct device *dev, void *data)
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
>> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> index e122f5b2a395..a1ed462c2430 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> @@ -900,7 +900,8 @@ static const struct sun4i_tcon_quirks sun8i_v3s_quirks = 
>> {
>>   /* nothing is supported */
>>  };
>>
>> -static const struct of_device_id sun4i_tcon_of_table[] = {
>> +/* 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 
>> },
>>   { .compatible = "allwinner,sun5i-a13-tcon", .data = _a13_quirks 
>> },
>>   { .compatible = "allwinner,sun6i-a31-tcon", .data = _a31_quirks 
>> },
>> @@ -911,6 +912,7 @@ static const struct of_device_id sun4i_tcon_of_table[] = 
>> {
>>   { }
>>  };
>>  MODULE_DEVICE_TABLE(of, sun4i_tcon_of_table);
>> +EXPORT_SYMBOL(sun4i_tcon_of_table);
>>
>>  static struct platform_driver sun4i_tcon_platform_driver = {
>>   .probe  = sun4i_tcon_probe,
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
>> b/drivers/gpu/drm/sun4i/sun4i_tcon.h
>> index f61bf6d83b4a..839266a38505 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
>> @@ -197,4 +197,6 @@ void sun4i_tcon_mode_set(struct sun4i_tcon *tcon,
>>  void sun4i_tcon_set_status(struct sun4i_tcon *crtc,
>>  const struct drm_encoder *encoder, bool enable);
>>
>> +extern const struct of_device_id sun4i_tcon_of_table[];
>> +
>
> I'm not very fond of that approach. Maybe we can place the structure
> in the tcon header?

Doesn't that mean you get one copy of everything wherever they are referenced?
This is assuming the compiler trims unused ones from files that include the
header file.

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

Re: [PATCH 13/17] drm/sun4i: Add DE2 CSC library

[Chen-Yu Tsai]

On Wed, Nov 29, 2017 at 5:43 AM, Jernej Škrabec  wrote:
> Hi!
>
> Dne torek, 28. november 2017 ob 21:55:50 CET je Maxime Ripard napisal(a):
>> On Mon, Nov 27, 2017 at 09:57:46PM +0100, Jernej Skrabec wrote:
>> > DE2 have many CSC units - channel input CSC, channel output CSC and
>> > mixer output CSC and maybe more.
>> >
>> > Fortunately, they have all same register layout, only base offsets
>> > differs.
>> >
>> > Add support only for channel output CSC for now.
>> >
>> > Signed-off-by: Jernej Skrabec 
>> > ---
>> >
>> >  drivers/gpu/drm/sun4i/Makefile|  2 +-
>> >  drivers/gpu/drm/sun4i/sun8i_csc.c | 90
>> >  +++
>> >  drivers/gpu/drm/sun4i/sun8i_csc.h | 36 
>> >  3 files changed, 127 insertions(+), 1 deletion(-)
>> >  create mode 100644 drivers/gpu/drm/sun4i/sun8i_csc.c
>> >  create mode 100644 drivers/gpu/drm/sun4i/sun8i_csc.h
>> >
>> > diff --git a/drivers/gpu/drm/sun4i/Makefile
>> > b/drivers/gpu/drm/sun4i/Makefile index 70df480792f9..f82cc69ede72 100644
>> > --- a/drivers/gpu/drm/sun4i/Makefile
>> > +++ b/drivers/gpu/drm/sun4i/Makefile
>> > @@ -9,7 +9,7 @@ sun4i-drm-hdmi-y+= sun4i_hdmi_enc.o
>> >
>> >  sun4i-drm-hdmi-y   += sun4i_hdmi_i2c.o
>> >  sun4i-drm-hdmi-y   += sun4i_hdmi_tmds_clk.o
>> >
>> > -sun8i-mixer-y  += sun8i_mixer.o sun8i_layer.o 
>> > sun8i_scaler.o
>> > +sun8i-mixer-y  += sun8i_mixer.o sun8i_layer.o 
>> > sun8i_scaler.o
> sun8i_csc.o
>>
>> Please wrap that line.
>>
>> >  sun4i-tcon-y   += sun4i_crtc.o
>> >  sun4i-tcon-y   += sun4i_dotclock.o
>> >
>> > diff --git a/drivers/gpu/drm/sun4i/sun8i_csc.c
>> > b/drivers/gpu/drm/sun4i/sun8i_csc.c new file mode 100644
>> > index ..d48c28f8d568
>> > --- /dev/null
>> > +++ b/drivers/gpu/drm/sun4i/sun8i_csc.c
>> > @@ -0,0 +1,90 @@
>> > +/*
>> > + * Copyright (C) Jernej Skrabec 
>> > + *
>> > + * This program is free software; you can redistribute it and/or
>> > + * modify it under the terms of the GNU General Public License as
>> > + * published by the Free Software Foundation; either version 2 of
>> > + * the License, or (at your option) any later version.
>> > + */
>> > +
>> > +#include "sun8i_csc.h"
>> > +
>> > +static const u32 ccsc_base[2][2] = {
>> > +   {CCSC00_OFFSET, CCSC01_OFFSET},
>> > +   {CCSC10_OFFSET, CCSC11_OFFSET},
>> > +};
>> > +
>> > +/*
>> > + * Factors are in two's complement format, 10 bits for fractinal part.
>> > + * First tree values in each line are multiplication factor and last
>> > + * value is constant, which is added at the end.
>> > + */
>> > +static const u32 yuv2rgb[] = {
>> > +   0x04A8, 0x, 0x0662, 0xFFFC845A,
>> > +   0x04A8, 0xFE6F, 0xFCBF, 0x00021DF4,
>> > +   0x04A8, 0x0813, 0x, 0xFFFBAC4A,
>> > +};
>> > +
>> > +static const u32 yvu2rgb[] = {
>> > +   0x04A8, 0x0662, 0x, 0xFFFC845A,
>> > +   0x04A8, 0xFCBF, 0xFE6F, 0x00021DF4,
>> > +   0x04A8, 0x, 0x0813, 0xFFFBAC4A,
>> > +};
>> > +
>> > +static void sun8i_csc_set_coefficients(struct regmap *map, u32 base,
>> > +  enum sun8i_csc_mode mode)
>> > +{
>> > +   const u32 *table;
>> > +   int i, data;
>> > +
>> > +   switch (mode) {
>> > +   case SUN8I_CSC_MODE_YUV2RGB:
>> > +   table = yuv2rgb;
>> > +   break;
>> > +   case SUN8I_CSC_MODE_YVU2RGB:
>> > +   table = yvu2rgb;
>> > +   break;
>> > +   default:
>> > +   WARN(1, "Wrong CSC mode specified.");
>>
>> A hard warn is a bit overkill here. What about a dev_warn?
>
> dev_warn requires device, which is not available here and seems a bit overkill
> to have it as parameter just to print warning. What about DRM_WARN()?

dev_warn is just pr_warn that prefixes the device name to the message.
Not sure about DRM_WARN. If it's anything like DRM_DEBUG* then it probably
prefixes the function name.

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

[PATCH v1 2/2] drm/tinydrm: add driver for ST7735R panels

[David Lechner]

tation) {
+   default:
+   addr_mode = ST7735R_MX | ST7735R_MY;
+   break;
+   case 90:
+   addr_mode = ST7735R_MX | ST7735R_MV;
+   break;
+   case 180:
+   addr_mode = 0;
+   break;
+   case 270:
+   addr_mode = ST7735R_MY | ST7735R_MV;
+   break;
+   }
+   mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
+   mipi_dbi_command(mipi, MIPI_DCS_SET_PIXEL_FORMAT,
+MIPI_DCS_PIXEL_FMT_16BIT);
+   mipi_dbi_command(mipi, ST7735R_GAMCTRP1, 0x0f, 0x1a, 0x0f, 0x18, 0x2f,
+0x28, 0x20, 0x22, 0x1f, 0x1b, 0x23, 0x37, 0x00, 0x07,
+0x02, 0x10);
+   mipi_dbi_command(mipi, ST7735R_GAMCTRN1, 0x0f, 0x1b, 0x0f, 0x17, 0x33,
+0x2c, 0x29, 0x2e, 0x30, 0x30, 0x39, 0x3f, 0x00, 0x07,
+0x03, 0x10);
+   mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
+
+   msleep(100);
+
+   mipi_dbi_command(mipi, MIPI_DCS_ENTER_NORMAL_MODE);
+
+   msleep(10);
+
+   mipi->enabled = true;
+
+   if (fb)
+   fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
+
+   tinydrm_enable_backlight(mipi->backlight);
+}
+
+static void st7735r_pipe_disable(struct drm_simple_display_pipe *pipe)
+{
+   struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+   struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+
+   DRM_DEBUG_KMS("\n");
+
+   if (!mipi->enabled)
+   return;
+
+   tinydrm_disable_backlight(mipi->backlight);
+
+   mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_OFF);
+
+   mipi->enabled = false;
+}
+
+static const struct drm_simple_display_pipe_funcs st7735r_pipe_funcs = {
+   .enable = st7735r_pipe_enable,
+   .disable= st7735r_pipe_disable,
+   .update = tinydrm_display_pipe_update,
+   .prepare_fb = tinydrm_display_pipe_prepare_fb,
+};
+
+static const struct drm_display_mode st7735r_mode = {
+   TINYDRM_MODE(128, 160, 28, 35),
+};
+
+DEFINE_DRM_GEM_CMA_FOPS(st7735r_fops);
+
+static struct drm_driver st7735r_driver = {
+   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
+ DRIVER_ATOMIC,
+   .fops   = _fops,
+   TINYDRM_GEM_DRIVER_OPS,
+   .lastclose  = tinydrm_lastclose,
+   .name   = "st7735r",
+   .desc   = "Sitronix ST7735R",
+   .date   = "20171128",
+   .major  = 1,
+   .minor  = 0,
+};
+
+static const struct of_device_id st7735r_of_match[] = {
+   { .compatible = "sitronix,st7735r-jd-t18003-t01" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, st7735r_of_match);
+
+static const struct spi_device_id st7735r_id[] = {
+   { "st7735r-jd-t18003-t01", 0 },
+   { },
+};
+MODULE_DEVICE_TABLE(spi, st7735r_id);
+
+static int st7735r_probe(struct spi_device *spi)
+{
+   struct device *dev = >dev;
+   struct mipi_dbi *mipi;
+   struct gpio_desc *dc;
+   u32 rotation = 0;
+   int ret;
+
+   mipi = devm_kzalloc(dev, sizeof(*mipi), GFP_KERNEL);
+   if (!mipi)
+   return -ENOMEM;
+
+   mipi->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+   if (IS_ERR(mipi->reset)) {
+   DRM_DEV_ERROR(dev, "Failed to get gpio 'reset'\n");
+   return PTR_ERR(mipi->reset);
+   }
+
+   dc = devm_gpiod_get(dev, "dc", GPIOD_OUT_LOW);
+   if (IS_ERR(dc)) {
+   DRM_DEV_ERROR(dev, "Failed to get gpio 'dc'\n");
+   return PTR_ERR(dc);
+   }
+
+   mipi->backlight = tinydrm_of_find_backlight(dev);
+   if (IS_ERR(mipi->backlight))
+   return PTR_ERR(mipi->backlight);
+
+   device_property_read_u32(dev, "rotation", );
+
+   ret = mipi_dbi_spi_init(spi, mipi, dc);
+   if (ret)
+   return ret;
+
+   ret = mipi_dbi_init(>dev, mipi, _pipe_funcs,
+   _driver, _mode, rotation);
+   if (ret)
+   return ret;
+
+   spi_set_drvdata(spi, mipi);
+
+   return devm_tinydrm_register(>tinydrm);
+}
+
+static void st7735r_shutdown(struct spi_device *spi)
+{
+   struct mipi_dbi *mipi = spi_get_drvdata(spi);
+
+   tinydrm_shutdown(>tinydrm);
+}
+
+static struct spi_driver st7735r_spi_driver = {
+   .driver = {
+   .name = "st7735r",
+   .owner = THIS_MODULE,
+   .of_match_table = st7735r_of_match,
+   },
+   .id_table = st7735r_id,
+   .probe = st7735r_probe,
+   .shutdown = st7735r_shutdown,
+};
+module_spi_driver(st7735r_spi_driver);
+
+MODULE_DESCRIPTION("Sitronix ST7735R DRM driver");
+MODULE_AUTHOR("David Lechner <da...@lechnology.com>");
+MODULE_LICENSE("GPL");
-- 
2.7.4

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

[PATCH v1 1/2] dt-bindings: Add binding for Sitronix ST7735R display panels

[David Lechner]

This adds a new device tree binding for Sitronix ST7735R display panels,
such as the Adafruit 1.8" TFT.

Signed-off-by: David Lechner 
---
 .../bindings/display/sitronix,st7735r.txt  | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7735r.txt

diff --git a/Documentation/devicetree/bindings/display/sitronix,st7735r.txt 
b/Documentation/devicetree/bindings/display/sitronix,st7735r.txt
new file mode 100644
index 000..bbb8ba6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sitronix,st7735r.txt
@@ -0,0 +1,35 @@
+Sitronix ST7735R display panels
+
+This binding is for display panels using a Sitronix ST7735R controller in SPI
+mode.
+
+Required properties:
+- compatible:  "sitronix,st7735r-jd-t18003-t01"
+- dc-gpios:Display data/command selection (D/CX)
+- reset-gpios: Reset signal (RSTX)
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+- backlight:   phandle of the backlight device attached to the panel
+
+Example:
+
+   backlight: backlight {
+   compatible = "gpio-backlight";
+   gpios = < 44 GPIO_ACTIVE_HIGH>;
+   }
+
+   ...
+
+   display@0{
+   compatible = "sitronix,st7735r-jd-t18003-t01";
+   reg = <0>;
+   spi-max-frequency = <3200>;
+   dc-gpios = < 43 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 80 GPIO_ACTIVE_HIGH>;
+   rotation = <270>;
+   backlight = 
+   };
-- 
2.7.4

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

[PATCH v1 0/2] DRM driver for Sitronix ST7735R display panels

[David Lechner]

This series adds a new DRM/TinyDRM driver for Sitronix ST7735R, specifically
the Adafruit 1.8" TFT.

Nothing fancy here. Just mostly TinyDRM boilerplate with the init sequence from
the fbtft driver for the same panel.

I'm assuming that since it says so here[1], that the "R" suffix is important,
so I am including it in the driver name and device tree bindings.

[1]: https://github.com/notro/tinydrm/wiki/Development

David Lechner (2):
  dt-bindings: Add binding for Sitronix ST7735R display panels
  drm/tinydrm: add driver for ST7735R panels

 .../bindings/display/sitronix,st7735r.txt  |  35 +++
 MAINTAINERS|   6 +
 drivers/gpu/drm/tinydrm/Kconfig|  10 +
 drivers/gpu/drm/tinydrm/Makefile   |   1 +
 drivers/gpu/drm/tinydrm/st7735r.c  | 237 +
 5 files changed, 289 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7735r.txt
 create mode 100644 drivers/gpu/drm/tinydrm/st7735r.c

-- 
2.7.4

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

Re: [PATCH v3 2/5] drm/stm: dsi: Adjust dw_mipi_dsi_probe and remove

[Sean Paul]

On Tue, Nov 28, 2017 at 10:41:29AM -0800, Brian Norris wrote:
> Hi Nickey,
> 
> On Tue, Nov 28, 2017 at 07:20:03PM +0800, Nickey Yang wrote:
> > Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
> > parent driver might need to own this. Instead, let's return our
> 
> Other reviews have suggested this might be described as "SoC glue
> driver", not "parent driver". Also, the subject probably should include
> either "mipi" or "dw-mipi-dsi".
> 
> > 'dw_mipi_dsi' object and have callers pass that back to us for removal.
> > So adjust it.
> > 
> > Signed-off-by: Nickey Yang 
> > ---
> >  drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 8 +---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> So, you've split my patch in 2 and called it your own (see patch 1,
> which still has the 'From' (i.e., author) line as "Nickey Yang", not
> "Brian Norris"). You need to keep the author accurate. (It's good to add
> an additional 'Signed-off-by' of your own, but keep the author.)
> 

Also cc everyone who commented on the previous version of the patch so they
can review the new version. Laurent had questions about the patch, and was
not cc'd here.

Sean

> When developing in your local git tree, make sure that the 'Author' line
> is accurate in 'git log'. Then 'git format-patch + git send-email' will
> format things correctly, such that your email headers will say "From:
> Nickey Yang", but then git-send-email will make sure there's an
> additional line within the body of the email to attribute the author.
> 
> For example, see how this patch was sent by Doug in a later series, but has my
> authorship:
> 
> https://patchwork.kernel.org/patch/9188419/
> 
> The email header says:
> 
> From: Douglas Anderson 
> 
> but the body of the mail includes:
> 
> From: Brian Norris 
> 
> This ends up correctly-attributed in the mainline git tree:
> 
> commit 36b5d460261f16563f9196c49c936b3e17d237e3
> Author: Brian Norris 
> Date:   Mon Jun 20 10:56:42 2016 -0700
> 
> phy: rockchip-emmc: configure default output tap delay
> ...
> Signed-off-by: Brian Norris 
> Signed-off-by: Douglas Anderson 
> 
> 
> But more importantly: you can't split my patch in 2, because it makes
> the series non-bisectable. As you split it, patch 1 is making an API
> change, but it doesn't update the drivers that use that API. So the STM
> DSI driver doesn't compile if you apply only patch 1. That's discouraged
> within the Linux kernel.
> 
> So, let's make sure to keep this patch in 1 piece.
> 
> Brian
> 
> > 
> > diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
> > b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> > index e5b6310..80f9950 100644
> > --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> > +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> > @@ -66,6 +66,7 @@ enum dsi_color {
> >  struct dw_mipi_dsi_stm {
> > void __iomem *base;
> > struct clk *pllref_clk;
> > +   struct dw_mipi_dsi *dmd;
> >  };
> >  
> >  static inline void dsi_write(struct dw_mipi_dsi_stm *dsi, u32 reg, u32 val)
> > @@ -318,10 +319,11 @@ static int dw_mipi_dsi_stm_probe(struct 
> > platform_device *pdev)
> > dw_mipi_dsi_stm_plat_data.base = dsi->base;
> > dw_mipi_dsi_stm_plat_data.priv_data = dsi;
> >  
> > -   ret = dw_mipi_dsi_probe(pdev, _mipi_dsi_stm_plat_data);
> > -   if (ret) {
> > +   dsi->dmd = dw_mipi_dsi_probe(pdev, _mipi_dsi_stm_plat_data);
> > +   if (IS_ERR(dsi->dmd)) {
> > DRM_ERROR("Failed to initialize mipi dsi host\n");
> > clk_disable_unprepare(dsi->pllref_clk);
> > +   return PTR_ERR(dsi->dmd);
> > }
> >  
> > return ret;
> > @@ -332,7 +334,7 @@ static int dw_mipi_dsi_stm_remove(struct 
> > platform_device *pdev)
> > struct dw_mipi_dsi_stm *dsi = dw_mipi_dsi_stm_plat_data.priv_data;
> >  
> > clk_disable_unprepare(dsi->pllref_clk);
> > -   dw_mipi_dsi_remove(pdev);
> > +   dw_mipi_dsi_remove(dsi->dmd);
> >  
> > return 0;
> >  }
> > -- 
> > 1.9.1
> > 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/5] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

[Sean Paul]

On Tue, Nov 28, 2017 at 02:55:41PM -0800, Brian Norris wrote:
> Hi Nickey,
> 
> On Tue, Nov 28, 2017 at 12:48:43PM -0800, Matthias Kaehlcke wrote:
> > El Tue, Nov 28, 2017 at 07:20:05PM +0800 Nickey Yang ha dit:
> > 
> > > Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
> > > MIPI DSI host controller bridge.
> > > 
> > > v2:
> > >add err_pllref, remove unnecessary encoder.enable & disable
> > >correct spelling mistakes
> > > v3:
> > >call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind()
> > >fix typo, use of_device_get_match_data(),
> > >change some ‘bind()’ logic into 'probe()'
> > >add 'dev_set_drvdata()'
> 
> I believe the changelog normally goes below the "---", so it gets
> dropped when a maintainer applies a final version.
> 

We're kind of different in drm land. Some prefer to keep the changelog above the
fold and attribute the changes to reviewers so they get recognition for their
efforts.

At any rate, I'm just happy to see changelogs.

> > > 
> > > Signed-off-by: Nickey Yang 
> > > ---
> > >  drivers/gpu/drm/rockchip/Kconfig|2 +-
> > >  drivers/gpu/drm/rockchip/Makefile   |2 +-
> > >  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 1349 
> > > ---
> > >  drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c |  764 +
> > >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +-
> > >  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |2 +-
> > >  6 files changed, 768 insertions(+), 1353 deletions(-)
> > >  delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > >  create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
> > > 
> 
> ...
> 
> > > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> > > b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > > deleted file mode 100644
> > > index b15755b..000
> > > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > > +++ /dev/null
> > > @@ -1,1349 +0,0 @@
> 
> ...
> 
> > > -static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
> > > -struct mipi_dsi_device *device)
> > > -{
> > > - struct dw_mipi_dsi *dsi = host_to_dsi(host);
> > > -
> > > - if (device->lanes > dsi->pdata->max_data_lanes) {
> > > - DRM_DEV_ERROR(dsi->dev,
> > > -   "the number of data lanes(%u) is too many\n",
> > > -   device->lanes);
> > > - return -EINVAL;
> > > - }
> > > -
> > > - dsi->lanes = device->lanes;
> > > - dsi->channel = device->channel;
> > > - dsi->format = device->format;
> > > - dsi->mode_flags = device->mode_flags;
> > > - dsi->panel = of_drm_find_panel(device->dev.of_node);
> 
> IIUC, you're implicitly making a device tree binding change, because the
> original driver uses just of_drm_find_panel(), as above, but the common
> bridge driver is using drm_of_find_panel_or_bridge(), which puts a
> little more stringent requirements on the device tree.
> 
> I don't think that's necessarily a bad thing, and there isn't much in
> the way of "real" device trees that actually used the existing driver
> and binding (probably mostly test devices and prototypes), so maybe it's
> better to just make the switch and not worry about compatibility. But I
> just wanted to point that out, in case anyone else was interested or
> concerned.
> 
> > > - if (dsi->panel)
> > > - return drm_panel_attach(dsi->panel, >connector);
> > > -
> > > - return -EINVAL;
> > > -}
> > > -
> 
> ...
> 
> > > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c 
> > > b/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
> > > new file mode 100644
> > > index 000..c682ed2
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
> > > @@ -0,0 +1,764 @@
> 
> ...
> 
> > > +static int dw_mipi_dsi_phy_init(void *priv_data)
> > > +{
> > > + struct dw_mipi_dsi_rockchip *dsi = priv_data;
> > > + int ret, i, vco;
> > > +
> > > + vco = (dsi->lane_mbps < 200) ? 0 : (dsi->lane_mbps + 100) / 200;
> > 
> > Please add a clarifying comment as requested by Sean on
> > https://chromium-review.googlesource.com/#/c/chromiumos/third_party/kernel/+/780120/
> 
> FWIW, that code was already in the existing driver. Would be nice to
> improve anyway, of course.
> 

Yeah, not a showstopper, but it'd be nice to know what's going on here.

> ...
> 
> > > +static int
> > > +dw_mipi_dsi_get_lane_mbps(void *priv_data, struct drm_display_mode *mode,
> > > +   unsigned long mode_flags, u32 lanes, u32 format,
> > > +   unsigned int *lane_mbps)
> > > +{
> > > + struct dw_mipi_dsi_rockchip *dsi = priv_data;
> > > + int bpp;
> > > + unsigned long mpclk, tmp;
> > > + unsigned int target_mbps = 1000;
> > > + unsigned int max_mbps = dppa_map[ARRAY_SIZE(dppa_map) - 1].max_mbps;
> > > + unsigned long best_freq = 0;
> > > + unsigned long fvco_min, fvco_max, fin, fout;
> > > + unsigned int min_prediv, max_prediv;
> > > + unsigned 

[Bug 103838] Random segfaults in applications from radeonsi_dri.so

[bugzilla-daemon]

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

--- Comment #4 from Alex Ford  ---
Alright, I rebuilt mesa with debug symbols, and I got the following from gdb
(along with a bunch of useless stuff regarding threads)

dri2_allocate_textures (ctx=0x274f950, drawable=,
statts=, statts_count=2)
at
/var/tmp/portage/media-libs/mesa-17.3.0_rc5/work/mesa-17.3.0-rc5/src/gallium/state_trackers/dri/dri2.c:675


This is with mesa 17.3.0_rc5

-- 
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 v3 1/5] drm/bridge/synopsys: stop clobbering drvdata

[Sean Paul]

On Tue, Nov 28, 2017 at 07:20:02PM +0800, Nickey Yang wrote:

Looks like you paved the author. This should be From: Brian.

Sean

> Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
> parent driver might need to own this. Instead, let's return our
> 'dw_mipi_dsi' object and have callers pass that back to us for removal.
> 
> Signed-off-by: Brian Norris 
> Reviewed-by: Matthias Kaehlcke 
> Reviewed-by: Archit Taneja 
> Acked-by: Philippe Cornu 
> Link:https://patchwork.kernel.org/patch/10078493/
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 36 
> ++-
>  include/drm/bridge/dw_mipi_dsi.h  | 17 -
>  2 files changed, 24 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index d9cca4f..c39c7dc 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -922,8 +922,6 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge 
> *bridge)
>   dsi->bridge.of_node = pdev->dev.of_node;
>  #endif
>  
> - dev_set_drvdata(dev, dsi);
> -
>   return dsi;
>  }
>  
> @@ -935,23 +933,16 @@ static void __dw_mipi_dsi_remove(struct dw_mipi_dsi 
> *dsi)
>  /*
>   * Probe/remove API, used from platforms based on the DRM bridge API.
>   */
> -int dw_mipi_dsi_probe(struct platform_device *pdev,
> -   const struct dw_mipi_dsi_plat_data *plat_data)
> +struct dw_mipi_dsi *
> +dw_mipi_dsi_probe(struct platform_device *pdev,
> +   const struct dw_mipi_dsi_plat_data *plat_data)
>  {
> - struct dw_mipi_dsi *dsi;
> -
> - dsi = __dw_mipi_dsi_probe(pdev, plat_data);
> - if (IS_ERR(dsi))
> - return PTR_ERR(dsi);
> -
> - return 0;
> + return __dw_mipi_dsi_probe(pdev, plat_data);
>  }
>  EXPORT_SYMBOL_GPL(dw_mipi_dsi_probe);
>  
> -void dw_mipi_dsi_remove(struct platform_device *pdev)
> +void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
>  {
> - struct dw_mipi_dsi *dsi = platform_get_drvdata(pdev);
> -
>   mipi_dsi_host_unregister(>dsi_host);
>  
>   __dw_mipi_dsi_remove(dsi);
> @@ -961,31 +952,30 @@ void dw_mipi_dsi_remove(struct platform_device *pdev)
>  /*
>   * Bind/unbind API, used from platforms based on the component framework.
>   */
> -int dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder 
> *encoder,
> -  const struct dw_mipi_dsi_plat_data *plat_data)
> +struct dw_mipi_dsi *
> +dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
> +  const struct dw_mipi_dsi_plat_data *plat_data)
>  {
>   struct dw_mipi_dsi *dsi;
>   int ret;
>  
>   dsi = __dw_mipi_dsi_probe(pdev, plat_data);
>   if (IS_ERR(dsi))
> - return PTR_ERR(dsi);
> + return dsi;
>  
>   ret = drm_bridge_attach(encoder, >bridge, NULL);
>   if (ret) {
> - dw_mipi_dsi_remove(pdev);
> + dw_mipi_dsi_remove(dsi);
>   DRM_ERROR("Failed to initialize bridge with drm\n");
> - return ret;
> + return ERR_PTR(ret);
>   }
>  
> - return 0;
> + return dsi;
>  }
>  EXPORT_SYMBOL_GPL(dw_mipi_dsi_bind);
>  
> -void dw_mipi_dsi_unbind(struct device *dev)
> +void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi)
>  {
> - struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
> -
>   __dw_mipi_dsi_remove(dsi);
>  }
>  EXPORT_SYMBOL_GPL(dw_mipi_dsi_unbind);
> diff --git a/include/drm/bridge/dw_mipi_dsi.h 
> b/include/drm/bridge/dw_mipi_dsi.h
> index 9b30fec..d9c6d54 100644
> --- a/include/drm/bridge/dw_mipi_dsi.h
> +++ b/include/drm/bridge/dw_mipi_dsi.h
> @@ -10,6 +10,8 @@
>  #ifndef __DW_MIPI_DSI__
>  #define __DW_MIPI_DSI__
>  
> +struct dw_mipi_dsi;
> +
>  struct dw_mipi_dsi_phy_ops {
>   int (*init)(void *priv_data);
>   int (*get_lane_mbps)(void *priv_data, struct drm_display_mode *mode,
> @@ -29,11 +31,14 @@ struct dw_mipi_dsi_plat_data {
>   void *priv_data;
>  };
>  
> -int dw_mipi_dsi_probe(struct platform_device *pdev,
> -   const struct dw_mipi_dsi_plat_data *plat_data);
> -void dw_mipi_dsi_remove(struct platform_device *pdev);
> -int dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder 
> *encoder,
> -  const struct dw_mipi_dsi_plat_data *plat_data);
> -void dw_mipi_dsi_unbind(struct device *dev);
> +struct dw_mipi_dsi *dw_mipi_dsi_probe(struct platform_device *pdev,
> +   const struct dw_mipi_dsi_plat_data
> +   *plat_data);
> +void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi);
> +struct dw_mipi_dsi *dw_mipi_dsi_bind(struct platform_device *pdev,
> +  struct drm_encoder *encoder,
> +  const struct dw_mipi_dsi_plat_data
> +  

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

On 28 November 2017 at 10:40AM, Michel Dänzer wrote:

On 2017-11-28 06:43 AM, Christian Zigotzky wrote:

Is it better to enable SWIOTLB? Are there any advantages with SWIOTLB
enabled?

I doubt SWIOTLB provides any benefit for you.


Can you test if Christian's patch fixes the problem with SWIOTLB disabled?



Hi Michel,

Hardware 3D acceleration works with Christian's patch! I don't need to 
enable SWIOTLB anymore.


Thanks,
Christian

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

Re: [PATCH] MAINTAINERS: change maintainer for Rockchip drm drivers

[Doug Anderson]

Hi,

On Sun, Nov 26, 2017 at 6:22 PM, Sandy Huang  wrote:
> Hi Daniel,
> I register the account and get the drm-misc commit rights now, thanks.
>
>
> 在 2017/11/24 22:51, Daniel Vetter 写道:
>>
>> On Fri, Nov 24, 2017 at 09:28:59AM +0100, Heiko Stuebner wrote:
>>>
>>> Hi Daniel,
>>>
>>> [somehow my email address seems to have gotten lost, so
>>> only saw this by chance on the list itself now.
>>> I've also re-added Sandy to the recipients]
>>>
>>> Am Montag, 20. November 2017, 08:48:48 CET schrieb Daniel Vetter:

 On Mon, Nov 13, 2017 at 06:15:31PM +0800, Mark Yao wrote:
>
> For personal reasons, Mark Yao will leave rockchip,
> can not continue maintain drm/rockchip, Sandy Huang
> will take over the drm/rockchip.
>
> Cc: Sandy Huang 
> Cc: Heiko Stuebner 
>
> Signed-off-by: Mark Yao 


 Since rockchip is in drm-misc that means we need a new maintainer who
 also
 has drm-misc commit rights. Sandy doesn't yet, so if Sandy is going to
 be
 the new maintainer we need to fix that.

 Also, Heiko, are you interested in becoming co-maintainer? With commit
 rights and all.
>>>
>>>
>>> I always feel somewhat inadequate judging the fast-paced drm stuff, as in
>>> the past once I got my head wrapped around something, drm always
>>> somehow moved another mile already ;-) .
>>>
>>> But somewhere I read that drm-pace for big changes is supposed to slow a
>>> bit now that atomic modesetting is done in a lot of places, so we could
>>> give
>>> co-maintainership for the Rockchip-drm a try - with Sandy wearing the
>>> actual hat for big changes though ;-) .
>>
>>
>> Yeah I think on the modeset side it calmed down a lot. We're still
>> fine-tuning the helper libraries as we're figuring out better ways to
>> write drivers. But right now I think a lot of the action is all in details
>> not relevant for many drivers.
>>
>> If Sandy's ok with that too pls request an fd.o account for drm-misc and
>> set up the tooling per our quickstart guide:
>>
>> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html#quickstart
>>
>> Thanks, Daniel

I just got a bounced mail from Mark Yao's old email address and
noticed that linux-next still shows him as the maintainer.  It'd be
great if we could land the change to update the MAINTAINERS file.  :-P

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

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Doug Anderson]

Hi,

On Thu, Feb 9, 2017 at 11:44 PM, Chris Zhong  wrote:
>
> There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
> only one PHY can connect to DP controller at one time, the other should
> be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
> set this bit means enable PHY 1, clear this bit means enable PHY 0.
>
> If the board has 2 Type-C ports, the DP driver get the phy id from
> devm_of_phy_get_by_index, and then control this switch according to
> this id. But some others board only has one Type-C port, it may be PHY 0
> or PHY 1. The dts node id can not tell us the correct PHY id. Hence move
> this switch to PHY driver, the PHY driver can distinguish between PHY 0
> and PHY 1, and then write the correct register bit.
>
>
>
> Chris Zhong (4):
>   Documentation: bindings: add uphy-dp-sel for Rockchip USB Type-C PHY
>   arm64: dts: rockchip: add rockchip,uphy-dp-sel for Type-C phy
>   phy: rockchip-typec: support DP phy switch
>   drm/rockchip: cdn-dp: remove the DP phy switch
>
>  Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 5 +
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
>  drivers/gpu/drm/rockchip/cdn-dp-core.c   | 7 ---
>  drivers/phy/phy-rockchip-typec.c | 9 +
>  4 files changed, 16 insertions(+), 7 deletions(-)

What ever happened to this series?  It seemed like it just dropped on
the floor...

There was a bit of contention on patch #3
 about the fact that we
were specifying addresses in the device tree vs. hardcoding them in
the driver.  Any way we can just make a decision and go with it?


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

Re: [PATCH v3 4/5] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

[Brian Norris]

Hi Nickey,

On Tue, Nov 28, 2017 at 12:48:43PM -0800, Matthias Kaehlcke wrote:
> El Tue, Nov 28, 2017 at 07:20:05PM +0800 Nickey Yang ha dit:
> 
> > Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
> > MIPI DSI host controller bridge.
> > 
> > v2:
> >add err_pllref, remove unnecessary encoder.enable & disable
> >correct spelling mistakes
> > v3:
> >call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind()
> >fix typo, use of_device_get_match_data(),
> >change some ‘bind()’ logic into 'probe()'
> >add 'dev_set_drvdata()'

I believe the changelog normally goes below the "---", so it gets
dropped when a maintainer applies a final version.

> > 
> > Signed-off-by: Nickey Yang 
> > ---
> >  drivers/gpu/drm/rockchip/Kconfig|2 +-
> >  drivers/gpu/drm/rockchip/Makefile   |2 +-
> >  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 1349 
> > ---
> >  drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c |  764 +
> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +-
> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |2 +-
> >  6 files changed, 768 insertions(+), 1353 deletions(-)
> >  delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >  create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
> > 

...

> > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> > b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > deleted file mode 100644
> > index b15755b..000
> > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > +++ /dev/null
> > @@ -1,1349 +0,0 @@

...

> > -static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
> > -  struct mipi_dsi_device *device)
> > -{
> > -   struct dw_mipi_dsi *dsi = host_to_dsi(host);
> > -
> > -   if (device->lanes > dsi->pdata->max_data_lanes) {
> > -   DRM_DEV_ERROR(dsi->dev,
> > - "the number of data lanes(%u) is too many\n",
> > - device->lanes);
> > -   return -EINVAL;
> > -   }
> > -
> > -   dsi->lanes = device->lanes;
> > -   dsi->channel = device->channel;
> > -   dsi->format = device->format;
> > -   dsi->mode_flags = device->mode_flags;
> > -   dsi->panel = of_drm_find_panel(device->dev.of_node);

IIUC, you're implicitly making a device tree binding change, because the
original driver uses just of_drm_find_panel(), as above, but the common
bridge driver is using drm_of_find_panel_or_bridge(), which puts a
little more stringent requirements on the device tree.

I don't think that's necessarily a bad thing, and there isn't much in
the way of "real" device trees that actually used the existing driver
and binding (probably mostly test devices and prototypes), so maybe it's
better to just make the switch and not worry about compatibility. But I
just wanted to point that out, in case anyone else was interested or
concerned.

> > -   if (dsi->panel)
> > -   return drm_panel_attach(dsi->panel, >connector);
> > -
> > -   return -EINVAL;
> > -}
> > -

...

> > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c 
> > b/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
> > new file mode 100644
> > index 000..c682ed2
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
> > @@ -0,0 +1,764 @@

...

> > +static int dw_mipi_dsi_phy_init(void *priv_data)
> > +{
> > +   struct dw_mipi_dsi_rockchip *dsi = priv_data;
> > +   int ret, i, vco;
> > +
> > +   vco = (dsi->lane_mbps < 200) ? 0 : (dsi->lane_mbps + 100) / 200;
> 
> Please add a clarifying comment as requested by Sean on
> https://chromium-review.googlesource.com/#/c/chromiumos/third_party/kernel/+/780120/

FWIW, that code was already in the existing driver. Would be nice to
improve anyway, of course.

...

> > +static int
> > +dw_mipi_dsi_get_lane_mbps(void *priv_data, struct drm_display_mode *mode,
> > + unsigned long mode_flags, u32 lanes, u32 format,
> > + unsigned int *lane_mbps)
> > +{
> > +   struct dw_mipi_dsi_rockchip *dsi = priv_data;
> > +   int bpp;
> > +   unsigned long mpclk, tmp;
> > +   unsigned int target_mbps = 1000;
> > +   unsigned int max_mbps = dppa_map[ARRAY_SIZE(dppa_map) - 1].max_mbps;
> > +   unsigned long best_freq = 0;
> > +   unsigned long fvco_min, fvco_max, fin, fout;
> > +   unsigned int min_prediv, max_prediv;
> > +   unsigned int _prediv, uninitialized_var(best_prediv);
> > +   unsigned long _fbdiv, uninitialized_var(best_fbdiv);
> > +   unsigned long min_delta = ULONG_MAX;
> > +
> > +   dsi->format = format;
> > +   bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> > +   if (bpp < 0) {
> > +   DRM_DEV_ERROR(dsi->dev,
> > + "failed to get bpp for pixel format %d\n",
> > + dsi->format);
> > +   return bpp;
> > +   }
> > +
> > +   mpclk = DIV_ROUND_UP(mode->clock, MSEC_PER_SEC);
> > +   if (mpclk) {

Re: [PATCH] drm: fix amdkfd use-after-free GP fault

[Oded Gabbay]

It was sent to Dave Airle (drm maintainer) to be included in 4.15-rc2
or 4.15-rc3 (depends when Dave will send his drm fixes).

Oded

On Wed, Nov 29, 2017 at 12:41 AM, Randy Dunlap  wrote:
> On 11/13/2017 08:09 AM, Oded Gabbay wrote:
>> On Sat, Nov 11, 2017 at 8:16 AM, Randy Dunlap  wrote:
>>> From: Randy Dunlap 
>>>
>>> Fix GP fault caused by dev_info() reference to a struct device*
>>> after the device has been freed (use after free).
>>> kfd_chardev_exit() frees the device so 'kfd_device' should not
>>> be used after calling kfd_chardev_exit().
>>>
>>> To reproduce, just load the module and then unload it.
>>> Note that %RAX contains repeated 0x6b, which is use-after-free
>>> poisoning.
>>>
>>> [  946.645809] calling  kfd_module_init+0x0/0x1000 [amdkfd] @ 5785
>>> [  946.646025] CRAT table not found
>>> [  946.646027] Finished initializing topology ret=0
>>> [  946.646050] kfd kfd: Initialized module
>>> [  946.646058] initcall kfd_module_init+0x0/0x1000 [amdkfd] returned 0 
>>> after 233 usecs
>>> [  947.650189] general protection fault:  [#1] PREEMPT SMP
>>> [  947.650192] Modules linked in: amdkfd(-) amd_iommu_v2 dw_hdmi cec 
>>> rc_core mxm_wmi ttm dln2 gpio_max730x tps65218 lp3943 mcb crc4 fpga_mgr 
>>> fpga_bridge fmc fuse ctr ccm af_packet nf_log_ipv6 xt_pkttype nf_log_ipv4 
>>> nf_log_common xt_LOG xt_limit ip6t_REJECT nf_reject_ipv6 xt_tcpudp 
>>> nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 
>>> iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns 
>>> nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables 
>>> xt_conntrack nf_conntrack libcrc32c ip6table_filter ip6_tables x_tables 
>>> coretemp hwmon intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel 
>>> kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel 
>>> ghash_clmulni_intel pcbc aesni_intel uvcvideo videobuf2_vmalloc aes_x86_64 
>>> videobuf2_memops hid_generic videobuf2_v4l2
>>> [  947.650224]  crypto_simd snd_hda_codec_hdmi videobuf2_core usbmouse 
>>> videodev snd_hda_codec_realtek glue_helper usbhid media hid 
>>> snd_hda_codec_generic snd_hda_intel arc4 snd_hda_codec cryptd iwldvm 
>>> sdhci_pci snd_hda_core sdhci mmc_core mac80211 snd_hwdep iTCO_wdt snd_pcm 
>>> iTCO_vendor_support xhci_pci intel_cstate xhci_hcd i915 snd_seq 
>>> snd_seq_device ehci_pci snd_timer toshiba_acpi ehci_hcd snd usbcore iwlwifi 
>>> sparse_keymap e1000e cfg80211 input_leds ptp wmi sr_mod intel_uncore mei_me 
>>> lpc_ich led_class cdrom usb_common pps_core mei joydev intel_rapl_perf 
>>> mousedev evdev industrialio toshiba_bluetooth shpchp mac_hid rfkill 
>>> soundcore serio_raw pcspkr toshiba_haps battery video thermal ac button sg 
>>> autofs4 [last unloaded: radeon]
>>> [  947.650259] CPU: 3 PID: 5791 Comm: rmmod Not tainted 4.14.0-rc8 #4
>>> [  947.650260] Hardware name: TOSHIBA PORTEGE R835/Portable PC, BIOS 
>>> Version 4.10   01/08/2013
>>> [  947.650262] task: 97144a3f2840 task.stack: a51e409c4000
>>> [  947.650266] RIP: 0010:__dev_printk+0x29/0x90
>>> [  947.650267] RSP: 0018:a51e409c7e48 EFLAGS: 00010202
>>> [  947.650269] RAX: 6b6b6b6b6b6b6b6b RBX: 97a579c3 RCX: 
>>> 000100140013
>>> [  947.650270] RDX: a51e409c7e78 RSI: 97139e360558 RDI: 
>>> 97a579c3
>>> [  947.650271] RBP: a51e409c7e68 R08: 6b6b6b6b6b6b6b6b R09: 
>>> a51e409c7e78
>>> [  947.650272] R10: 9714465c44b8 R11: 9714465c55e8 R12: 
>>> 7fff874111f7
>>> [  947.650273] R13: 0800 R14: 006231c0 R15: 
>>> 00623010
>>> [  947.650275] FS:  7fe8a109d700() GS:97144fac() 
>>> knlGS:
>>> [  947.650276] CS:  0010 DS:  ES:  CR0: 80050033
>>> [  947.650277] CR2: 0062cc88 CR3: 00013fd43005 CR4: 
>>> 000606e0
>>> [  947.650279] Call Trace:
>>> [  947.650283]  ? kobject_cleanup+0x75/0x170
>>> [  947.650284]  _dev_info+0x57/0x60
>>> [  947.650288]  ? kfree+0xf5/0x140
>>> [  947.650295]  kfd_module_exit+0x37/0x39 [amdkfd]
>>> [  947.650299]  SyS_delete_module+0x14d/0x260
>>> [  947.650302]  ? exit_to_usermode_loop+0x60/0x87
>>> [  947.650305]  entry_SYSCALL_64_fastpath+0x1e/0xa9
>>> [  947.650307] RIP: 0033:0x7fe8a0beff97
>>> [  947.650308] RSP: 002b:7fff8740ffc8 EFLAGS: 0202 ORIG_RAX: 
>>> 00b0
>>> [  947.650310] RAX: ffda RBX: 0003 RCX: 
>>> 7fe8a0beff97
>>> [  947.650311] RDX: 7fe8a0c56920 RSI: 0800 RDI: 
>>> 00623228
>>> [  947.650312] RBP: 006231c0 R08: 7fe8a0ea3f20 R09: 
>>> 7fff8740ef41
>>> [  947.650313] R10: 2ef31b7d R11: 0202 R12: 
>>> 7fff8740efc0
>>> [  947.650314] R13:  R14: 006231c0 R15: 
>>> 00623010
>>> [  947.650316] Code: 00 00 55 49 89 d1 48 89 e5 53 48 89 fb 48 83 ec 18 48 
>>> 85 f6 74 5f 4c 8b 46 50 4d 85 c0 74 2b 48 8b 86 88 00 00 00 48 

Re: [GIT PULL] exynos-drm-next

[Inki Dae]

Hi Daniel,

2017년 11월 20일 16:33에 Daniel Vetter 이(가) 쓴 글:
> On Wed, Nov 15, 2017 at 10:26:45AM +0900, Inki Dae wrote:
>> Hi Dave,
>>
>> 2017년 11월 14일 13:22에 Dave Airlie 이(가) 쓴 글:
>>> On 26 October 2017 at 11:37, Inki Dae  wrote:
 Hi Dave,

Improving Exynos DRM HDMI and Mixer drivers and also adding
HDMI audio support.

Please kindly let me know if there is any problem.

Ps. we are reviewing IPP v2 driver[1] which controls post processor 
 devices
such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to 
 request
git pull one more time after review.
>>>
>>> Hi Inki,
>>>
>>> I dropped the ball a bit here, I do think the second pull with IPP is
>>> probably a bit late,
>>> I think I'd like more assurance that the UAPI for IPP is to be used in
>>> some upstream
>>> shipping project (forks of mpv not withstanding, unless this fork
>>> ships in some distro
>>> or product).
>>
>> I also commented same thing internally to author - Marek - of IPP v2 but I 
>> thought existing one is really ugly thing so may be better to change it as 
>> soon as possible before other users use this one.
>> Anyway, we will merge user space for IPP v2 to libdrm first, and then Linux 
>> platform. I hope IPPv2 would be merged as soon as possible in next turn.
> 
> Beyond what Daniel said we unfortunately don't have time machines, so
> fixing bad uapi isn't really possible. The problem is that even if you
> create ippv2, then people can still use ippv1, and it needs to keep
> working (almost) forever. So once a bad uapi is in, it's in, and there's

I'd like to make sure one thing. Yes, there may be some users who still use 
ippv1 but we should consider them even they aren't 'real user'? I.e., some test 
applications used internally.
As long as I know, only 'real user' who uses ippv1 would be me and my team. If 
we have to consider all users including in-house test applications then we may 
need to keep UAPI v1 and only change its implementation.

Thanks,
Inki Dae

> no good reason to add more uapi (since in 2 years you might again realize
> it's not a good idea) to "fix" that. You can't fix bad uapi.
> 
> That's why we have all these rules to make sure as little bad uapi as
> possible lands, since the cost is so bad.
> 
> So yeah unless you have new hw that needs it, or there's another clear
> need (performance, features), you're stuck with ippv1. "It's cleaner" is
> not a good reason to rev uapi, since our experience with all the uapi in
> drm clearly shows we can't predict the future :-)
> -Daniel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103808] [radeonsi, bisected] World of Warcraft scribbling all over screen

[bugzilla-daemon]

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

--- Comment #10 from Chris Rankin  ---
Agreed, WoW is now fixed. Thanks.

-- 
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 v6 6/7] efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation_quirk

[kbuild test robot]

Hi Hans,

I love your patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.15-rc1 next-20171128]
[cannot apply to linus/master]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-fbdev-Panel-orientation-connector-property-support/20171129-001142
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-kexec (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/video/fbdev/efifb.c: In function 'efifb_probe':
>> drivers/video/fbdev/efifb.c:339:7: error: 
>> 'DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP' undeclared (first use in this 
>> function); did you mean 'DRM_MODE_PRESENT_BOTTOM_FIELD'?
 case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
  ^~~~
  DRM_MODE_PRESENT_BOTTOM_FIELD
   drivers/video/fbdev/efifb.c:339:7: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/video/fbdev/efifb.c:342:7: error: 
>> 'DRM_MODE_PANEL_ORIENTATION_LEFT_UP' undeclared (first use in this 
>> function); did you mean 'DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP'?
 case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
  ^~
  DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP
>> drivers/video/fbdev/efifb.c:345:7: error: 
>> 'DRM_MODE_PANEL_ORIENTATION_RIGHT_UP' undeclared (first use in this 
>> function); did you mean 'DRM_MODE_PANEL_ORIENTATION_LEFT_UP'?
 case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
  ^~~
  DRM_MODE_PANEL_ORIENTATION_LEFT_UP

vim +339 drivers/video/fbdev/efifb.c

   157  
   158  static int efifb_probe(struct platform_device *dev)
   159  {
   160  struct fb_info *info;
   161  int err, orientation;
   162  unsigned int size_vmode;
   163  unsigned int size_remap;
   164  unsigned int size_total;
   165  char *option = NULL;
   166  
   167  if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || 
pci_dev_disabled)
   168  return -ENODEV;
   169  
   170  if (fb_get_options("efifb", ))
   171  return -ENODEV;
   172  efifb_setup(option);
   173  
   174  /* We don't get linelength from UGA Draw Protocol, only from
   175   * EFI Graphics Protocol.  So if it's not in DMI, and it's not
   176   * passed in from the user, we really can't use the framebuffer.
   177   */
   178  if (!screen_info.lfb_linelength)
   179  return -ENODEV;
   180  
   181  if (!screen_info.lfb_depth)
   182  screen_info.lfb_depth = 32;
   183  if (!screen_info.pages)
   184  screen_info.pages = 1;
   185  if (!fb_base_is_valid()) {
   186  printk(KERN_DEBUG "efifb: invalid framebuffer 
address\n");
   187  return -ENODEV;
   188  }
   189  printk(KERN_INFO "efifb: probing for efifb\n");
   190  
   191  /* just assume they're all unset if any are */
   192  if (!screen_info.blue_size) {
   193  screen_info.blue_size = 8;
   194  screen_info.blue_pos = 0;
   195  screen_info.green_size = 8;
   196  screen_info.green_pos = 8;
   197  screen_info.red_size = 8;
   198  screen_info.red_pos = 16;
   199  screen_info.rsvd_size = 8;
   200  screen_info.rsvd_pos = 24;
   201  }
   202  
   203  efifb_fix.smem_start = screen_info.lfb_base;
   204  
   205  if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE) {
   206  u64 ext_lfb_base;
   207  
   208  ext_lfb_base = (u64)(unsigned 
long)screen_info.ext_lfb_base << 32;
   209  efifb_fix.smem_start |= ext_lfb_base;
   210  }
   211  
   212  if (bar_resource &&
   213  bar_resource->start + bar_offset != efifb_fix.smem_start) {
   214  dev_info(_pci_dev->dev,
   215   "BAR has moved, updating efifb address\n");
   216  efifb_fix.smem_start = bar_resource->start + bar_offset;
   217  }
   218  
   219  efifb_defined.bits_per_pixel = screen_info.lfb_depth;
   220  efifb_defined.xres = screen_info.lfb_width;
   221  efifb_defined.yres = screen_info.lfb_height;
   222  efifb_fix.line_length = screen_info.lfb_linelength;
   223  
   224  /*   size_vmode -- th

[Bug 103962] (DC 4.15-rc1) [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disabled failed (scratch(0xC040)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #1 from taij...@posteo.de ---
Created attachment 135786
  --> https://bugs.freedesktop.org/attachment.cgi?id=135786=edit
relevant output of #lspci -vv

-- 
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 103962] (DC 4.15-rc1) [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disabled failed (scratch(0xC040)=0xCAFEDEAD)

[bugzilla-daemon]

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

Bug ID: 103962
   Summary: (DC 4.15-rc1) [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR*
KCQ disabled failed (scratch(0xC040)=0xCAFEDEAD)
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: taij...@posteo.de

Created attachment 135785
  --> https://bugs.freedesktop.org/attachment.cgi?id=135785=edit
relevant dmesg output

I am testing the new DC code with 4.15-rc1 on my Alienware 15R3 with an RX470
dGPU.

This machine has forever had the problem that pm will not turn the dGPU off
properly when it is not in use, thus causing heat and battery life issues. I
had hoped that maybe the DC code would help here, but it seems to just have
switched the kinds of error messages I get around. Here are the new ones, I
keep getting a bunch of:

[2.727021] [drm:dm_logger_write [amdgpu]] *ERROR*
hwss_edp_wait_for_hpd_ready: wait timed out!
[   20.520195] [drm:dm_logger_write [amdgpu]] *ERROR*
hwss_edp_wait_for_hpd_ready: wait timed out!

and

[   36.938909] [drm:dm_logger_write [amdgpu]] *ERROR*
hwss_edp_wait_for_hpd_ready: wait timed out!
[   37.087971] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 0
test failed (scratch(0xC040)=0xCAFEDEAD)
[   37.087981] [drm:amdgpu_resume_phase2 [amdgpu]] *ERROR* resume of IP block
 failed -22
[   37.087990] [drm:amdgpu_device_resume [amdgpu]] *ERROR* amdgpu_resume failed
(-22).
[   37.087993] snd_hda_intel :01:00.1: Start delayed initialization
[   37.091937] input: HDA ATI HDMI HDMI/DP,pcm=3 as
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input21
[   37.091967] input: HDA ATI HDMI HDMI/DP,pcm=7 as
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input22
[   37.092023] [drm:amdgpu_fill_buffer [amdgpu]] *ERROR* Trying to clear memory
with ring turned off.
[   37.103951] [drm:amdgpu_fill_buffer [amdgpu]] *ERROR* Trying to clear memory
with ring turned off.
[   37.103974] [drm:amdgpu_fill_buffer [amdgpu]] *ERROR* Trying to clear memory
with ring turned off.
[   37.104058] [drm:amdgpu_fill_buffer [amdgpu]] *ERROR* Trying to clear memory
with ring turned off.
[   37.125739] [drm:amdgpu_fill_buffer [amdgpu]] *ERROR* Trying to clear memory
with ring turned off.
[   37.248924] [drm:amdgpu_fill_buffer [amdgpu]] *ERROR* Trying to clear memory
with ring turned off.
[   37.248946] [drm:amdgpu_fill_buffer [amdgpu]] *ERROR* Trying to clear memory
with ring turned off.
[   37.249070] [drm:amdgpu_fill_buffer [amdgpu]] *ERROR* Trying to clear memory
with ring turned off.
[   42.269448] snd_hda_intel :01:00.1: Disabling via vga_switcheroo
[   42.269517] snd_hda_intel :01:00.1: Cannot lock devices!
[   42.447377] [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disabled failed
(scratch(0xC040)=0xCAFEDEAD)
[   42.599606] [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disabled failed
(scratch(0xC040)=0xCAFEDEAD)
[   42.749231] [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disabled failed
(scratch(0xC040)=0xCAFEDEAD)
[   42.899207] [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disabled failed
(scratch(0xC040)=0xCAFEDEAD)
[   43.047953] [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disabled failed
(scratch(0xC040)=0xCAFEDEAD)
[   43.197043] [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disabled failed
(scratch(0xC040)=0xCAFEDEAD)
[   43.344313] [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disabled failed
(scratch(0xC040)=0xCAFEDEAD)
[   43.491648] [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disabled failed
(scratch(0xC040)=0xCAFEDEAD)
[   43.491814] WARNING: CPU: 7 PID: 512 at
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:600
dm_suspend+0x4e/0x60 [amdgpu]
[   43.491815] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4
dns_resolver nfs lockd grace sunrpc fscache rfcomm ccm acpi_call(O) cmac bnep
arc4 ip6t_REJECT nf_reject_ipv6 xt_hl ip6t_rt joydev mousedev
snd_hda_codec_hdmi nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4
xt_multiport ath10k_pci rmi_smbus ath10k_core uvcvideo rmi_core
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core xt_limit ath
videodev xt_tcpudp snd_hda_codec_realtek btusb dell_wmi iTCO_wdt media btrtl
xt_addrtype fuse snd_hda_codec_generic iTCO_vendor_support mac80211 dell_smbios
wmi_bmof dell_wmi_descriptor intel_rapl nf_conntrack_ipv4 x86_pkg_temp_thermal
intel_powerclamp kvm_intel nf_defrag_ipv4 snd_hda_intel xt_conntrack kvm
snd_hda_codec snd_hda_core mei_me snd_hwdep nls_iso8859_1 nls_cp437 snd_pcm
[   43.491833]  input_leds irqbypass vfat snd_timer intel_cstate fat snd
processor_thermal_device cfg80211 psmouse led_class pcspkr i2c_i801
intel_rapl_perf mei soundcore intel_pch_thermal hci_uart intel_soc_dts_iosf wmi
btbcm btqca btintel int3403_thermal bluetooth 

[Bug 103915] Undertale crashes on startup (compiling shaders?)

[bugzilla-daemon]

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

--- Comment #5 from John Steele Scott  ---
Created attachment 135784
  --> https://bugs.freedesktop.org/attachment.cgi?id=135784=edit
apitrace of Undertale startup taken on box with Iris 540 & Mesa 17.2.4.

My attempts to take an apitrace in comment 4 were on the box with the RX 480.
Here's an apitrace of Undertale's startup taken on my laptop with the Iris 540.

Replaying this trace on the RX 480 does not cause a crash though.

Is this any use?

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

Re: [PATCH v2 11/18] drm/sun4i: Add A83T support

[Maxime Ripard]

On Tue, Nov 28, 2017 at 04:48:55PM +0100, Jernej Škrabec wrote:
> > On Mon, Nov 27, 2017 at 05:01:49PM +0100, Jernej Škrabec wrote:
> > > Dne ponedeljek, 27. november 2017 ob 16:41:35 CET je Maxime Ripard 
> napisal(a):
> > > > Add support for the A83T display pipeline.
> > > > 
> > > > Reviewed-by: Chen-Yu Tsai 
> > > > Signed-off-by: Maxime Ripard 
> > > > ---
> > > > 
> > > >  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
> > > >  drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
> > > >  drivers/gpu/drm/sun4i/sun4i_tcon.c| 5 +
> > > >  drivers/gpu/drm/sun4i/sun8i_mixer.c   | 4 
> > > >  4 files changed, 14 insertions(+)
> > > > 
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index
> > > > d4259a4f5171..d6b52e5c48c0 100644
> > > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > > 
> > > > @@ -93,6 +93,7 @@ Required properties:
> > > > * allwinner,sun6i-a31s-tcon
> > > > * allwinner,sun7i-a20-tcon
> > > > * allwinner,sun8i-a33-tcon
> > > > 
> > > > +   * allwinner,sun8i-a83t-tcon-lcd
> > > > 
> > > > * allwinner,sun8i-v3s-tcon
> > > >   
> > > >   - reg: base address and size of memory-mapped region
> > > >   - interrupts: interrupt associated to this IP
> > > > 
> > > > @@ -224,6 +225,7 @@ supported.
> > > > 
> > > >  Required properties:
> > > >- compatible: value must be one of:
> > > > +* allwinner,sun8i-a83t-de2-mixer
> > > 
> > > What will be the name of the second mixer, once support for HDMI is added?
> > > Should we start directly with 0 and 1 postfix ?
> > 
> > What are the differences exactly without the two mixers?
> 
> Mixer properties:
> - mixer index (0 or 1), important for determining CCSC base (see my patches)

Is that the only thing we need to determine?

> - number of VI planes (usually 1)

Usually or always?

> - number of UI planes (usually 1 or 3)

Same question.

> - writeback support (yes/no)
> - scale line buffer length (2048 or 4096)
> - smart backligth support (yes/no)
> 
> channel properties (for both, VI and UI):
> - scaler support (yes/no, usually yes)
> - overlay count (seems to be always 4)
> - VEP support (yes/no)
> 
> Those are properties found in BSP de_feat.c, so I guess that's enough to make 
> any kind of decision in the code.
> 
> Usually, but we can't count on that, first mixer has 1 VI and 3 UI planes and 
> second mixer has 1 VI and 1 UI plane.

Right. So that would be easy to support using a property as well. The
only difference would be the CSC base.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [RFC][PATCH] drm: adv7511/33: Fix adv7511_cec_init() failure handling

[John Stultz]

On Sun, Nov 26, 2017 at 4:56 AM, Archit Taneja  wrote:
>
> On 11/17/2017 04:29 AM, John Stultz wrote:
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> index 0e14f15..939c3b9 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> @@ -1203,12 +1203,12 @@ static int adv7511_probe(struct i2c_client *i2c,
>> const struct i2c_device_id *id)
>> #ifdef CONFIG_DRM_I2C_ADV7511_CEC
>> ret = adv7511_cec_init(dev, adv7511, offset);
>> -   if (ret)
>> -   goto err_unregister_cec;
>>   #else
>> -   regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
>> -ADV7511_CEC_CTRL_POWER_DOWN);
>> +   ret = 1;
>>   #endif
>> +   if (ret)
>> +   regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL +
>> offset,
>> +ADV7511_CEC_CTRL_POWER_DOWN);
>
>
> This would force CEC to be powered off even if adv7511_cec_init() returned
> 0, right?

I don't think so. The initent was its only powered off if
adv7511_cec_init returns an error or if  CONFIG_DRM_I2C_ADV7511_CEC is
not set.

> Do we know why the call to adv7511_cec_init() is failing on the Hikey board?
> If it's
> because there isn't a "cec" clock specified in DT, it's not really a fatal
> error, it
> just means that the platform hasn't been set up to support CEC. In that

Yea. I believe this is the case w/ HiKey.  I don't have deeply
detailed docs on the board so I'm not sure if we will be able to
enable that or not (Xinliang/Guodong: Do you know if its possible?).
In the meantime though, we shouldn't regress.

> case, we
> should just power down the CEC block. So, if adv7511_cec_init() would return
> a
> -ENOENT, which we could use as a hint to power down CEC. So, maybe something
> like this?:
>
> #ifdef CONFIG_DRM_I2C_ADV7511_CEC
> ret = adv7511_cec_init(dev, adv7511, offset);
> if (ret && ret != -ENOENT)
> goto err_unregister_cec;
> #endif
> if (ret)
> regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
> ADV7511_CEC_CTRL_POWER_DOWN);
>
> Apart from this, we should also move adv7511_cec_init() up in the probe so
> that
> it's called before the drm_bridge is registered.

Hans has since reworked the patch w/ a new version. You might want to
check his patches and see if they fit what your imagining.

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

Re: [Intel-gfx] [PATCH v6 6/7] efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation_quirk

[kbuild test robot]

Hi Hans,

I love your patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.15-rc1 next-20171128]
[cannot apply to linus/master]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-fbdev-Panel-orientation-connector-property-support/20171129-001142
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-s1-11282357 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/video/fbdev/efifb.c: In function 'efifb_probe':
   drivers/video/fbdev/efifb.c:339:7: error: 
'DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP' undeclared (first use in this function)
 case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
  ^~~~
   drivers/video/fbdev/efifb.c:339:7: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/video/fbdev/efifb.c:342:7: error: 
>> 'DRM_MODE_PANEL_ORIENTATION_LEFT_UP' undeclared (first use in this function)
 case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
  ^~
>> drivers/video/fbdev/efifb.c:345:7: error: 
>> 'DRM_MODE_PANEL_ORIENTATION_RIGHT_UP' undeclared (first use in this function)
 case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
  ^~~

vim +/DRM_MODE_PANEL_ORIENTATION_LEFT_UP +342 drivers/video/fbdev/efifb.c

   157  
   158  static int efifb_probe(struct platform_device *dev)
   159  {
   160  struct fb_info *info;
   161  int err, orientation;
   162  unsigned int size_vmode;
   163  unsigned int size_remap;
   164  unsigned int size_total;
   165  char *option = NULL;
   166  
   167  if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || 
pci_dev_disabled)
   168  return -ENODEV;
   169  
   170  if (fb_get_options("efifb", ))
   171  return -ENODEV;
   172  efifb_setup(option);
   173  
   174  /* We don't get linelength from UGA Draw Protocol, only from
   175   * EFI Graphics Protocol.  So if it's not in DMI, and it's not
   176   * passed in from the user, we really can't use the framebuffer.
   177   */
   178  if (!screen_info.lfb_linelength)
   179  return -ENODEV;
   180  
   181  if (!screen_info.lfb_depth)
   182  screen_info.lfb_depth = 32;
   183  if (!screen_info.pages)
   184  screen_info.pages = 1;
   185  if (!fb_base_is_valid()) {
   186  printk(KERN_DEBUG "efifb: invalid framebuffer 
address\n");
   187  return -ENODEV;
   188  }
   189  printk(KERN_INFO "efifb: probing for efifb\n");
   190  
   191  /* just assume they're all unset if any are */
   192  if (!screen_info.blue_size) {
   193  screen_info.blue_size = 8;
   194  screen_info.blue_pos = 0;
   195  screen_info.green_size = 8;
   196  screen_info.green_pos = 8;
   197  screen_info.red_size = 8;
   198  screen_info.red_pos = 16;
   199  screen_info.rsvd_size = 8;
   200  screen_info.rsvd_pos = 24;
   201  }
   202  
   203  efifb_fix.smem_start = screen_info.lfb_base;
   204  
   205  if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE) {
   206  u64 ext_lfb_base;
   207  
   208  ext_lfb_base = (u64)(unsigned 
long)screen_info.ext_lfb_base << 32;
   209  efifb_fix.smem_start |= ext_lfb_base;
   210  }
   211  
   212  if (bar_resource &&
   213  bar_resource->start + bar_offset != efifb_fix.smem_start) {
   214  dev_info(_pci_dev->dev,
   215   "BAR has moved, updating efifb address\n");
   216  efifb_fix.smem_start = bar_resource->start + bar_offset;
   217  }
   218  
   219  efifb_defined.bits_per_pixel = screen_info.lfb_depth;
   220  efifb_defined.xres = screen_info.lfb_width;
   221  efifb_defined.yres = screen_info.lfb_height;
   222  efifb_fix.line_length = screen_info.lfb_linelength;
   223  
   224  /*   size_vmode -- that is the amount of memory needed for the
   225   * used video mode, i.e. the minimum amount of
   226   * memory we need. */
   227  size_vmode = efifb_defined.yres * efifb_fix.line_length;
   228  
   229  /*   size_total -- al

Re: [PATCH 13/17] drm/sun4i: Add DE2 CSC library

[Maxime Ripard]

On Mon, Nov 27, 2017 at 09:57:46PM +0100, Jernej Skrabec wrote:
> DE2 have many CSC units - channel input CSC, channel output CSC and
> mixer output CSC and maybe more.
> 
> Fortunately, they have all same register layout, only base offsets
> differs.
> 
> Add support only for channel output CSC for now.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/sun4i/Makefile|  2 +-
>  drivers/gpu/drm/sun4i/sun8i_csc.c | 90 
> +++
>  drivers/gpu/drm/sun4i/sun8i_csc.h | 36 
>  3 files changed, 127 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun8i_csc.c
>  create mode 100644 drivers/gpu/drm/sun4i/sun8i_csc.h
> 
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 70df480792f9..f82cc69ede72 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -9,7 +9,7 @@ sun4i-drm-hdmi-y  += sun4i_hdmi_enc.o
>  sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
>  sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
>  
> -sun8i-mixer-y+= sun8i_mixer.o sun8i_layer.o 
> sun8i_scaler.o
> +sun8i-mixer-y+= sun8i_mixer.o sun8i_layer.o 
> sun8i_scaler.o sun8i_csc.o

Please wrap that line.

>  
>  sun4i-tcon-y += sun4i_crtc.o
>  sun4i-tcon-y += sun4i_dotclock.o
> diff --git a/drivers/gpu/drm/sun4i/sun8i_csc.c 
> b/drivers/gpu/drm/sun4i/sun8i_csc.c
> new file mode 100644
> index ..d48c28f8d568
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun8i_csc.c
> @@ -0,0 +1,90 @@
> +/*
> + * Copyright (C) Jernej Skrabec 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +#include "sun8i_csc.h"
> +
> +static const u32 ccsc_base[2][2] = {
> + {CCSC00_OFFSET, CCSC01_OFFSET},
> + {CCSC10_OFFSET, CCSC11_OFFSET},
> +};
> +
> +/*
> + * Factors are in two's complement format, 10 bits for fractinal part.
> + * First tree values in each line are multiplication factor and last
> + * value is constant, which is added at the end.
> + */
> +static const u32 yuv2rgb[] = {
> + 0x04A8, 0x, 0x0662, 0xFFFC845A,
> + 0x04A8, 0xFE6F, 0xFCBF, 0x00021DF4,
> + 0x04A8, 0x0813, 0x, 0xFFFBAC4A,
> +};
> +
> +static const u32 yvu2rgb[] = {
> + 0x04A8, 0x0662, 0x, 0xFFFC845A,
> + 0x04A8, 0xFCBF, 0xFE6F, 0x00021DF4,
> + 0x04A8, 0x, 0x0813, 0xFFFBAC4A,
> +};
> +
> +static void sun8i_csc_set_coefficients(struct regmap *map, u32 base,
> +enum sun8i_csc_mode mode)
> +{
> + const u32 *table;
> + int i, data;
> +
> + switch (mode) {
> + case SUN8I_CSC_MODE_YUV2RGB:
> + table = yuv2rgb;
> + break;
> + case SUN8I_CSC_MODE_YVU2RGB:
> + table = yvu2rgb;
> + break;
> + default:
> + WARN(1, "Wrong CSC mode specified.");

A hard warn is a bit overkill here. What about a dev_warn?

Looks good otherwise.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 08/17] drm/sun4i: Add support for DE2 VI planes

[Maxime Ripard]

Hi,

On Mon, Nov 27, 2017 at 09:57:41PM +0100, Jernej Skrabec wrote:
> This commit adds basic support for VI planes. They are meant for video
> overlay and because of that they support YUV formats too. However, using
> YUV planes is not straightforward, so only RGB support for now.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/sun4i/sun8i_layer.c |  40 +++---
>  drivers/gpu/drm/sun4i/sun8i_mixer.c | 144 
> +---
>  drivers/gpu/drm/sun4i/sun8i_mixer.h |  38 --
>  3 files changed, 196 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c 
> b/drivers/gpu/drm/sun4i/sun8i_layer.c
> index 49ccdd0149bd..e1b6ad82145e 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
> @@ -47,13 +47,22 @@ static int sun8i_mixer_layer_atomic_check(struct 
> drm_plane *plane,
>   true, true);
>  }
>  
> +static void sun8i_mixer_layer_enable(struct sun8i_layer *layer, bool enable)
> +{
> + struct sun8i_mixer *mixer = layer->mixer;
> +
> + if (layer->id < mixer->cfg->vi_num)
> + sun8i_mixer_vi_layer_enable(mixer, layer->id, enable);
> + else
> + sun8i_mixer_ui_layer_enable(mixer, layer->id, enable);
> +}
> +
>  static void sun8i_mixer_layer_atomic_disable(struct drm_plane *plane,
>  struct drm_plane_state 
> *old_state)
>  {
>   struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
> - struct sun8i_mixer *mixer = layer->mixer;
>  
> - sun8i_mixer_layer_enable(mixer, layer->id, false);
> + sun8i_mixer_layer_enable(layer, false);
>  }
>  
>  static void sun8i_mixer_layer_atomic_update(struct drm_plane *plane,
> @@ -63,14 +72,21 @@ static void sun8i_mixer_layer_atomic_update(struct 
> drm_plane *plane,
>   struct sun8i_mixer *mixer = layer->mixer;
>  
>   if (!plane->state->visible) {
> - sun8i_mixer_layer_enable(mixer, layer->id, false);
> + sun8i_mixer_layer_enable(layer, false);
>   return;
>   }
>  
> - sun8i_mixer_update_layer_coord(mixer, layer->id, plane);
> - sun8i_mixer_update_layer_formats(mixer, layer->id, plane);
> - sun8i_mixer_update_layer_buffer(mixer, layer->id, plane);
> - sun8i_mixer_layer_enable(mixer, layer->id, true);
> + if (layer->id < mixer->cfg->vi_num) {
> + sun8i_mixer_update_vi_layer_coord(mixer, layer->id, plane);
> + sun8i_mixer_update_vi_layer_formats(mixer, layer->id, plane);
> + sun8i_mixer_update_vi_layer_buffer(mixer, layer->id, plane);
> + } else {
> + sun8i_mixer_update_ui_layer_coord(mixer, layer->id, plane);
> + sun8i_mixer_update_ui_layer_formats(mixer, layer->id, plane);
> + sun8i_mixer_update_ui_layer_buffer(mixer, layer->id, plane);
> + }
> +
> + sun8i_mixer_layer_enable(layer, true);

So you can probably tell by the patches I had in my other serie, but
we should really split the UI and VI support in two files, especially
since it has pretty much no code path or data in common (if you
combine this patch with the YUV support).

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

[Bug 103808] [radeonsi, bisected] World of Warcraft scribbling all over screen

[bugzilla-daemon]

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

--- Comment #9 from Felix Hellmann  ---
Yeah WoW and PoE are also fixed here

-- 
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] drm/ttm: Use a static string instead of an array of char *

[Alex Deucher]

On Tue, Nov 28, 2017 at 2:37 PM, Christian König
 wrote:
> Am 28.11.2017 um 20:34 schrieb Joe Perches:
>>
>> Make the object a bit smaller by using a simple string instead
>> of a format string and array of char *.
>>
>> $ size drivers/gpu/drm/ttm/ttm_page_alloc_dma.o*
>> text   data bss dec hex filename
>> 88202164136   131723374
>> drivers/gpu/drm/ttm/ttm_page_alloc_dma.o.defconfig.new
>> 89102164136   1326233ce
>> drivers/gpu/drm/ttm/ttm_page_alloc_dma.o.defconfig.old
>>25383   50444384   3481187fb
>> drivers/gpu/drm/ttm/ttm_page_alloc_dma.o.allyesconfig.new
>>25797   54284384   356098b19
>> drivers/gpu/drm/ttm/ttm_page_alloc_dma.o.allyesconfig.old
>>
>> Miscellanea:
>>
>> o The h array had more entries than were emitted, all are now removed
>>
>> Signed-off-by: Joe Perches 
>
>
> Reviewed-by: Christian König 

Applied.  thanks!

Alex

>
>> ---
>>   drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 5 +
>>   1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>> index 6b2627fe9bc1..bda00b2ab51c 100644
>> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>> @@ -1244,15 +1244,12 @@ int ttm_dma_page_alloc_debugfs(struct seq_file *m,
>> void *data)
>>   {
>> struct device_pools *p;
>> struct dma_pool *pool = NULL;
>> -   char *h[] = {"pool", "refills", "pages freed", "inuse",
>> "available",
>> -"name", "virt", "busaddr"};
>> if (!_manager) {
>> seq_printf(m, "No pool allocator running.\n");
>> return 0;
>> }
>> -   seq_printf(m, "%13s %12s %13s %8s %8s %8s\n",
>> -  h[0], h[1], h[2], h[3], h[4], h[5]);
>> +   seq_printf(m, " pool  refills   pages freedinuse
>> available name\n");
>> mutex_lock(&_manager->lock);
>> list_for_each_entry(p, &_manager->pools, pools) {
>> struct device *dev = p->dev;
>
>
> ___
> 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 v3 4/5] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

[Matthias Kaehlcke]

El Tue, Nov 28, 2017 at 07:20:05PM +0800 Nickey Yang ha dit:

> Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
> MIPI DSI host controller bridge.
> 
> v2:
>add err_pllref, remove unnecessary encoder.enable & disable
>correct spelling mistakes
> v3:
>call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind()
>fix typo, use of_device_get_match_data(),
>change some ‘bind()’ logic into 'probe()'
>add 'dev_set_drvdata()'
> 
> Signed-off-by: Nickey Yang 
> ---
>  drivers/gpu/drm/rockchip/Kconfig|2 +-
>  drivers/gpu/drm/rockchip/Makefile   |2 +-
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 1349 
> ---
>  drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c |  764 +
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |2 +-
>  6 files changed, 768 insertions(+), 1353 deletions(-)
>  delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c
>  create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
> 
> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
> b/drivers/gpu/drm/rockchip/Kconfig
> index 0ccc762..9eb4795 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -7,7 +7,7 @@ config DRM_ROCKCHIP
>   select VIDEOMODE_HELPERS
>   select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
>   select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
> - select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
> + select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
>   select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
>   help
> Choose this option if you have a Rockchip soc chipset.
> diff --git a/drivers/gpu/drm/rockchip/Makefile 
> b/drivers/gpu/drm/rockchip/Makefile
> index a314e21..c05fe47 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -11,7 +11,7 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += 
> rockchip_drm_fbdev.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
> -rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi_rockchip.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
>  
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> deleted file mode 100644
> index b15755b..000
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ /dev/null
> @@ -1,1349 +0,0 @@
> -/*
> - * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - */
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include "rockchip_drm_drv.h"
> -#include "rockchip_drm_vop.h"
> -
> -#define DRIVER_NAME"dw-mipi-dsi"
> -
> -#define RK3288_GRF_SOC_CON6  0x025c
> -#define RK3288_DSI0_SEL_VOP_LIT  BIT(6)
> -#define RK3288_DSI1_SEL_VOP_LIT  BIT(9)
> -
> -#define RK3399_GRF_SOC_CON20 0x6250
> -#define RK3399_DSI0_SEL_VOP_LIT  BIT(0)
> -#define RK3399_DSI1_SEL_VOP_LIT  BIT(4)
> -
> -/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */
> -#define RK3399_GRF_SOC_CON22 0x6258
> -#define RK3399_GRF_DSI_MODE  0x
> -
> -#define DSI_VERSION  0x00
> -#define DSI_PWR_UP   0x04
> -#define RESET0
> -#define POWERUP  BIT(0)
> -
> -#define DSI_CLKMGR_CFG   0x08
> -#define TO_CLK_DIVIDSION(div)(((div) & 0xff) << 8)
> -#define TX_ESC_CLK_DIVIDSION(div)(((div) & 0xff) << 0)
> -
> -#define DSI_DPI_VCID 0x0c
> -#define DPI_VID(vid) (((vid) & 0x3) << 0)
> -
> -#define DSI_DPI_COLOR_CODING 0x10
> -#define EN18_LOOSELY BIT(8)
> -#define DPI_COLOR_CODING_16BIT_1 0x0
> -#define DPI_COLOR_CODING_16BIT_2 0x1
> -#define DPI_COLOR_CODING_16BIT_3 0x2
> -#define DPI_COLOR_CODING_18BIT_1 0x3
> -#define DPI_COLOR_CODING_18BIT_2 0x4
> -#define DPI_COLOR_CODING_24BIT   0x5
> -
> -#define DSI_DPI_CFG_POL  0x14
> -#define COLORM_ACTIVE_LOWBIT(4)
> -#define SHUTD_ACTIVE_LOW BIT(3)
> -#define HSYNC_ACTIVE_LOW BIT(2)
> 

Re: [Intel-gfx] [PATCH v6 5/7] drm/i915: Add "panel orientation" property to the panel connector, v6.

[kbuild test robot]

Hi Hans,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.15-rc1 next-20171128]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-fbdev-Panel-orientation-connector-property-support/20171128-225025
config: x86_64-randconfig-x012-201748 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_dsi.c: In function 
'intel_dsi_get_panel_orientation':
   drivers/gpu/drm/i915/intel_dsi.c:1672:21: error: storage size of 'plane' 
isn't known
 enum i9xx_plane_id plane;
^
>> drivers/gpu/drm/i915/intel_dsi.c:1672:21: error: unused variable 'plane' 
>> [-Werror=unused-variable]
   cc1: all warnings being treated as errors

vim +/plane +1672 drivers/gpu/drm/i915/intel_dsi.c

  1667  
  1668  static int intel_dsi_get_panel_orientation(struct intel_connector 
*connector)
  1669  {
  1670  struct drm_i915_private *dev_priv = 
to_i915(connector->base.dev);
  1671  int orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> 1672  enum i9xx_plane_id plane;
  1673  u32 val;
  1674  
  1675  if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
  1676  if (connector->encoder->crtc_mask == BIT(PIPE_B))
  1677  plane = PLANE_B;
  1678  else
  1679  plane = PLANE_A;
  1680  
  1681  val = I915_READ(DSPCNTR(plane));
  1682  if (val & DISPPLANE_ROTATE_180)
  1683  orientation = 
DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
  1684  }
  1685  
  1686  return orientation;
  1687  }
  1688  

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


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

Re: [PATCH 12/17] drm/sun4i: Add CCSC property to DE2 configuration

[Maxime Ripard]

On Mon, Nov 27, 2017 at 09:57:45PM +0100, Jernej Skrabec wrote:
> Base addresses of channel output CSC (CCSC) depends whether mixer in
> question is first or second and if it is second, if supports VEP or not.
> This new property will tell which set of base addresses to take.
> 
> 0 - first mixer or second mixer with VEP support
> 1 - second mixer without VEP support
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/sun4i/sun8i_mixer.c | 1 +
>  drivers/gpu/drm/sun4i/sun8i_mixer.h | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c 
> b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> index 7c9c87a0535b..2276eff8798d 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -622,6 +622,7 @@ static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = 
> {
>   .vi_num = 2,
>   .ui_num = 1,
>   .scaler_mask = 0x3,
> + .ccsc = 0,
>  };
>  
>  static const struct of_device_id sun8i_mixer_of_table[] = {
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h 
> b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> index 355a45e6cfb4..4fcf1653e345 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> @@ -136,6 +136,7 @@ struct sun8i_mixer_cfg {
>   int vi_num;
>   int ui_num;
>   int scaler_mask;
> + int ccsc;

Having some documentation for that one would be great too.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 12/17] drm/sun4i: Add CCSC property to DE2 configuration

[Maxime Ripard]

On Tue, Nov 28, 2017 at 08:02:26PM +0800, Icenowy Zheng wrote:
> 在 2017-11-28 04:57，Jernej Skrabec 写道：
> > Base addresses of channel output CSC (CCSC) depends whether mixer in
> > question is first or second and if it is second, if supports VEP or not.
> > This new property will tell which set of base addresses to take.
> > 
> > 0 - first mixer or second mixer with VEP support
> > 1 - second mixer without VEP support
> 
> Maxime,
> 
> I think here the ID of the mixer matters.
> 
> P.S. I didn't found any SoC with a second mixer with VEP currently

Then we'll have an allwinner,has-vep; property (or whatever) for all
those SoCs' mixer0. What's the big deal about it?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 11/17] drm/sun4i: Wire in DE2 scaler support

[Maxime Ripard]

On Mon, Nov 27, 2017 at 09:57:44PM +0100, Jernej Skrabec wrote:
> Calculate scaling parameters and call appropriate scaler set up
> function.
> 
> Signed-off-by: Jernej Skrabec 

I'm not sure there's been something wrong, but I didn't receive your
patch 10. I guess this one could be folded in patch 9.

> @@ -194,29 +195,34 @@ int sun8i_mixer_update_ui_layer_coord(struct 
> sun8i_mixer *mixer,
> int layer, struct drm_plane *plane)
>  {
>   struct drm_plane_state *state = plane->state;
> - u32 width, height, size;
> + u32 src_w, src_h, dst_w, dst_h;
> + u32 outsize, insize;
> + u32 hphase, vphase;
>  
> - DRM_DEBUG_DRIVER("Updating layer %d\n", layer);
> + DRM_DEBUG_DRIVER("Updating UI layer %d\n", layer);

And this would be part of the VI support patch 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 09/17] drm/sun4i: Add scaler library for DE2

[Maxime Ripard]

Hi,

On Mon, Nov 27, 2017 at 09:57:42PM +0100, Jernej Skrabec wrote:
> Scaler library currently supports scaling only RGB planes on VI planes.
> 
> Coefficients and algorithm which ones to select are taken from BSP driver.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/sun4i/Makefile   |   2 +-
>  drivers/gpu/drm/sun4i/sun8i_scaler.c | 667 
> +++
>  drivers/gpu/drm/sun4i/sun8i_scaler.h |  78 
>  3 files changed, 746 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun8i_scaler.c
>  create mode 100644 drivers/gpu/drm/sun4i/sun8i_scaler.h
> 
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 0c2f8c7facae..70df480792f9 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -9,7 +9,7 @@ sun4i-drm-hdmi-y  += sun4i_hdmi_enc.o
>  sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
>  sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
>  
> -sun8i-mixer-y+= sun8i_mixer.o sun8i_layer.o
> +sun8i-mixer-y+= sun8i_mixer.o sun8i_layer.o 
> sun8i_scaler.o
>  
>  sun4i-tcon-y += sun4i_crtc.o
>  sun4i-tcon-y += sun4i_dotclock.o
> diff --git a/drivers/gpu/drm/sun4i/sun8i_scaler.c 
> b/drivers/gpu/drm/sun4i/sun8i_scaler.c
> new file mode 100644
> index ..23525beceaa2
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun8i_scaler.c
> @@ -0,0 +1,667 @@
> +/*
> + * Copyright (C) 2017 Jernej Skrabec 
> + *
> + * Coefficients are taken from BSP driver, which is:
> + * Copyright (C) 2014-2015 Allwinner

Saying from which BSP you got them would be great for future reference

It looks good otherwise. I kind of hate those big array of
undocumented data, but there's nothing you can do about it either, so
we'll have to deal with it :)

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!

[bugzilla-daemon]

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

--- Comment #37 from taij...@posteo.de ---
OK, so on 4.15-rc1 with amdgpu.dc=1 the error has disappeared for me. Seems to
have been fixed.

-- 
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 10/17] drm/sun4i: Add scaler configuration to DE2 mixers

[Maxime Ripard]

Hi,

On Mon, Nov 27, 2017 at 09:57:43PM +0100, Jernej Skrabec wrote:
> No all SoCs support scaling on all channels. For example, V3s support
> scaling only on VI channels. Because of that, add additional
> configuration bitmask which tells which channel support scaler.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/sun4i/sun8i_mixer.c | 1 +
>  drivers/gpu/drm/sun4i/sun8i_mixer.h | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c 
> b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> index dc97351be973..291dd8806444 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -576,6 +576,7 @@ static int sun8i_mixer_remove(struct platform_device 
> *pdev)
>  static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
>   .vi_num = 2,
>   .ui_num = 1,
> + .scaler_mask = 0x3,
>  };
>  
>  static const struct of_device_id sun8i_mixer_of_table[] = {
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h 
> b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> index 572ef184a21a..ad5aef5846ae 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> @@ -139,6 +139,7 @@
>  struct sun8i_mixer_cfg {
>   int vi_num;
>   int ui_num;
> + int scaler_mask;

Can you add a comment there to explain what the scaler_mask is ?
(ideally in kerneldoc)

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 05/17] drm/sun4i: Reorder some code in DE2

[Maxime Ripard]

Hi,

On Mon, Nov 27, 2017 at 09:57:38PM +0100, Jernej Skrabec wrote:
> While DE2 driver works, parts of the code are not in optimal place. Reorder
> it so it will be easier to support multiple planes.
> 
> This commit doesn't do any functional change besides removing two not
> very useful debug messages.
> 
> Signed-off-by: Jernej Skrabec 

So I have the same feeling here that it could be split into several
patches, but you should at least explain why and how that code is more
optimal than it used to.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 02/17] drm/sun4i: Start using layer id in DE2 driver

[Maxime Ripard]

On Mon, Nov 27, 2017 at 09:57:35PM +0100, Jernej Skrabec wrote:
> Till now, plane selection was hardcoded to first overlay in first UI
> channel.
> 
> It turns out that overlays don't fit well in current DRM design, because
> they can't be blended together or scaled independetly when they are set
> to same channel.
> 
> Beause of that, always use only first overlay in each channel. This
> simplifies things, since layer parameter can be then used as channel
> selection.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/sun4i/sun8i_layer.c |  2 +-
>  drivers/gpu/drm/sun4i/sun8i_mixer.c | 31 +++
>  2 files changed, 12 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c 
> b/drivers/gpu/drm/sun4i/sun8i_layer.c
> index 23810ff72684..5b2d45a9db8a 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
> @@ -126,7 +126,7 @@ struct drm_plane **sun8i_layers_init(struct drm_device 
> *drm,
>   return ERR_CAST(layer);
>   };
>  
> - layer->id = i;
> + layer->id = mixer->cfg->vi_num + i;
>   planes[i] = >plane;
>   };

So we had pretty much the same intent here :)

But I really feel we should model the hardware and have both the
channel and layer IDs. Obviously, at (that patch) moment, we don't
have support for multiple layers per channel, but eventually we should
really model the hardware as much as possible.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH] staging/sm750fb: Add "port to atomic kms" to TODO

[Alex Deucher]

On Tue, Nov 28, 2017 at 6:47 AM, Daniel Vetter  wrote:
> fbdev is closed for new drivers, drm won't take anything but atomic
> drivers.
>
> Cc: Greg Kroah-Hartman 
> Cc: Sudip Mukherjee 
> Cc: Teddy Wang 
> Cc: Sudip Mukherjee 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Daniel Vetter 

Acked-by: Alex Deucher 

> ---
>  drivers/staging/sm750fb/TODO | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/TODO b/drivers/staging/sm750fb/TODO
> index a3a877d90066..f710ab15abfe 100644
> --- a/drivers/staging/sm750fb/TODO
> +++ b/drivers/staging/sm750fb/TODO
> @@ -6,8 +6,8 @@ TODO:
>  - check on hardware effects of removal of USE_HW_I2C and USE_DVICHIP (these 
> two
> are supposed to be sample code which is given here if someone wants to
> use those functionalities)
> -- move it to drivers/video/fbdev
> -- modify the code for drm framework
> +- must be ported to the atomic kms framework in the drm subsystem (which will
> +  give you a basic fbdev driver for free)
>
>  Please send any patches to
> Greg Kroah-Hartman 
> --
> 2.15.0
>
> ___
> 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 11/13] drm/vc4: use simpler remove_conflicting_framebuffers(NULL)

[Eric Anholt]

Michał Mirosław  writes:

> Use remove_conflicting_framebuffers(NULL) instead of open-coding it.
>
> Signed-off-by: Michał Mirosław 

Acked-by: Eric Anholt 


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/ttm: Use a static string instead of an array of char *

[Christian König]

Am 28.11.2017 um 20:34 schrieb Joe Perches:

Make the object a bit smaller by using a simple string instead
of a format string and array of char *.

$ size drivers/gpu/drm/ttm/ttm_page_alloc_dma.o*
text   data bss dec hex filename
88202164136   131723374 
drivers/gpu/drm/ttm/ttm_page_alloc_dma.o.defconfig.new
89102164136   1326233ce 
drivers/gpu/drm/ttm/ttm_page_alloc_dma.o.defconfig.old
   25383   50444384   3481187fb 
drivers/gpu/drm/ttm/ttm_page_alloc_dma.o.allyesconfig.new
   25797   54284384   356098b19 
drivers/gpu/drm/ttm/ttm_page_alloc_dma.o.allyesconfig.old

Miscellanea:

o The h array had more entries than were emitted, all are now removed

Signed-off-by: Joe Perches 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 5 +
  1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 6b2627fe9bc1..bda00b2ab51c 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -1244,15 +1244,12 @@ int ttm_dma_page_alloc_debugfs(struct seq_file *m, void 
*data)
  {
struct device_pools *p;
struct dma_pool *pool = NULL;
-   char *h[] = {"pool", "refills", "pages freed", "inuse", "available",
-"name", "virt", "busaddr"};
  
  	if (!_manager) {

seq_printf(m, "No pool allocator running.\n");
return 0;
}
-   seq_printf(m, "%13s %12s %13s %8s %8s %8s\n",
-  h[0], h[1], h[2], h[3], h[4], h[5]);
+   seq_printf(m, " pool  refills   pages freedinuse available   
  name\n");
mutex_lock(&_manager->lock);
list_for_each_entry(p, &_manager->pools, pools) {
struct device *dev = p->dev;


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

[PATCH] drm/ttm: Use a static string instead of an array of char *

[Joe Perches]

Make the object a bit smaller by using a simple string instead
of a format string and array of char *.

$ size drivers/gpu/drm/ttm/ttm_page_alloc_dma.o*
   textdata bss dec hex filename
   8820 2164136   131723374 
drivers/gpu/drm/ttm/ttm_page_alloc_dma.o.defconfig.new
   8910 2164136   1326233ce 
drivers/gpu/drm/ttm/ttm_page_alloc_dma.o.defconfig.old
  2538350444384   3481187fb 
drivers/gpu/drm/ttm/ttm_page_alloc_dma.o.allyesconfig.new
  2579754284384   356098b19 
drivers/gpu/drm/ttm/ttm_page_alloc_dma.o.allyesconfig.old

Miscellanea:

o The h array had more entries than were emitted, all are now removed

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 6b2627fe9bc1..bda00b2ab51c 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -1244,15 +1244,12 @@ int ttm_dma_page_alloc_debugfs(struct seq_file *m, void 
*data)
 {
struct device_pools *p;
struct dma_pool *pool = NULL;
-   char *h[] = {"pool", "refills", "pages freed", "inuse", "available",
-"name", "virt", "busaddr"};
 
if (!_manager) {
seq_printf(m, "No pool allocator running.\n");
return 0;
}
-   seq_printf(m, "%13s %12s %13s %8s %8s %8s\n",
-  h[0], h[1], h[2], h[3], h[4], h[5]);
+   seq_printf(m, " pool  refills   pages freedinuse 
available name\n");
mutex_lock(&_manager->lock);
list_for_each_entry(p, &_manager->pools, pools) {
struct device *dev = p->dev;
-- 
2.15.0

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

Re: [bug report] drm/vmwgfx: Initial DX support

[Thomas Hellstrom]

Hi, Dan.

Thanks for the report. I'll try to figure out a fix.

/Thomas



On 11/28/2017 03:30 PM, Dan Carpenter wrote:

Hello Thomas Hellstrom,

The patch d80efd5cb3de: "drm/vmwgfx: Initial DX support" from Aug 10,
2015, leads to the following static checker warning:

drivers/gpu/drm/vmwgfx/vmwgfx_so.c:335 vmw_view_add()
error: buffer overflow 'vmw_view_define_sizes' 3 <= 3

drivers/gpu/drm/vmwgfx/vmwgfx_so.c
   2709  static int vmw_cmd_dx_view_define(struct vmw_private *dev_priv,
   2710struct vmw_sw_context *sw_context,
   2711SVGA3dCmdHeader *header)
   2712  {
   2713  struct vmw_resource_val_node *ctx_node = 
sw_context->dx_ctx_node;
   2714  struct vmw_resource_val_node *srf_node;
   2715  struct vmw_resource *res;
   2716  enum vmw_view_type view_type;
   2717  int ret;
   2718  /*
   2719   * This is based on the fact that all affected define commands 
have
   2720   * the same initial command body layout.
   2721   */
   2722  struct {
   2723  SVGA3dCmdHeader header;
   2724  uint32 defined_id;
   2725  uint32 sid;
   2726  } *cmd;
   2727
   2728  if (unlikely(ctx_node == NULL)) {
   2729  DRM_ERROR("DX Context not set.\n");
   2730  return -EINVAL;
   2731  }
   2732
   2733  view_type = vmw_view_cmd_to_type(header->id);
 ^
view_type is set to vmw_view_max for unknown values.

   2734  cmd = container_of(header, typeof(*cmd), header);
   2735  ret = vmw_cmd_res_check(dev_priv, sw_context, vmw_res_surface,
   2736  user_surface_converter,
   2737  >sid, _node);
   2738  if (unlikely(ret != 0))
   2739  return ret;
   2740
   2741  res = vmw_context_cotable(ctx_node->res, 
vmw_view_cotables[view_type]);

^
but we use it without checking vmw_view_id_ok().

   2742  ret = vmw_cotable_notify(res, cmd->defined_id);
   2743  vmw_resource_unreference();
   2744  if (unlikely(ret != 0))
   2745  return ret;
   2746

regards,
dan carpenter



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

Re: [PATCH v3 2/5] drm/stm: dsi: Adjust dw_mipi_dsi_probe and remove

[Brian Norris]

Hi Nickey,

On Tue, Nov 28, 2017 at 07:20:03PM +0800, Nickey Yang wrote:
> Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
> parent driver might need to own this. Instead, let's return our

Other reviews have suggested this might be described as "SoC glue
driver", not "parent driver". Also, the subject probably should include
either "mipi" or "dw-mipi-dsi".

> 'dw_mipi_dsi' object and have callers pass that back to us for removal.
> So adjust it.
> 
> Signed-off-by: Nickey Yang 
> ---
>  drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)

So, you've split my patch in 2 and called it your own (see patch 1,
which still has the 'From' (i.e., author) line as "Nickey Yang", not
"Brian Norris"). You need to keep the author accurate. (It's good to add
an additional 'Signed-off-by' of your own, but keep the author.)

When developing in your local git tree, make sure that the 'Author' line
is accurate in 'git log'. Then 'git format-patch + git send-email' will
format things correctly, such that your email headers will say "From:
Nickey Yang", but then git-send-email will make sure there's an
additional line within the body of the email to attribute the author.

For example, see how this patch was sent by Doug in a later series, but has my
authorship:

https://patchwork.kernel.org/patch/9188419/

The email header says:

From: Douglas Anderson 

but the body of the mail includes:

From: Brian Norris 

This ends up correctly-attributed in the mainline git tree:

commit 36b5d460261f16563f9196c49c936b3e17d237e3
Author: Brian Norris 
Date:   Mon Jun 20 10:56:42 2016 -0700

phy: rockchip-emmc: configure default output tap delay
...
Signed-off-by: Brian Norris 
Signed-off-by: Douglas Anderson 


But more importantly: you can't split my patch in 2, because it makes
the series non-bisectable. As you split it, patch 1 is making an API
change, but it doesn't update the drivers that use that API. So the STM
DSI driver doesn't compile if you apply only patch 1. That's discouraged
within the Linux kernel.

So, let's make sure to keep this patch in 1 piece.

Brian

> 
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> index e5b6310..80f9950 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -66,6 +66,7 @@ enum dsi_color {
>  struct dw_mipi_dsi_stm {
>   void __iomem *base;
>   struct clk *pllref_clk;
> + struct dw_mipi_dsi *dmd;
>  };
>  
>  static inline void dsi_write(struct dw_mipi_dsi_stm *dsi, u32 reg, u32 val)
> @@ -318,10 +319,11 @@ static int dw_mipi_dsi_stm_probe(struct platform_device 
> *pdev)
>   dw_mipi_dsi_stm_plat_data.base = dsi->base;
>   dw_mipi_dsi_stm_plat_data.priv_data = dsi;
>  
> - ret = dw_mipi_dsi_probe(pdev, _mipi_dsi_stm_plat_data);
> - if (ret) {
> + dsi->dmd = dw_mipi_dsi_probe(pdev, _mipi_dsi_stm_plat_data);
> + if (IS_ERR(dsi->dmd)) {
>   DRM_ERROR("Failed to initialize mipi dsi host\n");
>   clk_disable_unprepare(dsi->pllref_clk);
> + return PTR_ERR(dsi->dmd);
>   }
>  
>   return ret;
> @@ -332,7 +334,7 @@ static int dw_mipi_dsi_stm_remove(struct platform_device 
> *pdev)
>   struct dw_mipi_dsi_stm *dsi = dw_mipi_dsi_stm_plat_data.priv_data;
>  
>   clk_disable_unprepare(dsi->pllref_clk);
> - dw_mipi_dsi_remove(pdev);
> + dw_mipi_dsi_remove(dsi->dmd);
>  
>   return 0;
>  }
> -- 
> 1.9.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103953] [DC] Polaris10: Missing modes when enabling DC

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #135754|text/x-log  |text/plain
  mime type||

-- 
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 103953] [DC] Polaris10: Missing modes when enabling DC

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #135753|text/x-log  |text/plain
  mime type||

-- 
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 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP

[Hyun Kwon]

> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, November 28, 2017 10:12 AM
> To: Hyun Kwon 
> Cc: Daniel Vetter ; Jani Nikula
> ; Sean Paul ; David
> Airlie ; dri-devel@lists.freedesktop.org; mon...@monstr.eu;
> Laurent Pinchart ; Satish Kumar
> Nagireddy ; Jeff Mouroux 
> Subject: Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP
> 
> On Tue, Nov 28, 2017 at 05:25:46PM +, Hyun Kwon wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > > Sent: Tuesday, November 28, 2017 6:44 AM
> > > To: Hyun Kwon 
> > > Cc: Daniel Vetter ; Jani Nikula
> > > ; Sean Paul ; David
> > > Airlie ; dri-devel@lists.freedesktop.org;
> > > mon...@monstr.eu; Laurent Pinchart
> > > ; Satish Kumar Nagireddy
> > > ; Jeff Mouroux 
> > > Subject: Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx
> > > Video IP
> > >
> > > On Mon, Nov 27, 2017 at 06:27:32PM -0800, Hyun Kwon wrote:
> > > > From: Jeffrey Mouroux 
> > > >
> > > > The Xilinx Video Mixer and Xilinx Video Framebuffer DMA IP
> > > > support video memory formats that are not represented in the
> > > > current DRM fourcc library.  This patch adds those missing
> > > > fourcc codes.
> > > >
> > > > Signed-off-by: Jeffrey Mouroux 
> > > > Signed-off-by: Hyun Kwon 
> > > > ---
> > > >  include/uapi/drm/drm_fourcc.h | 9 +
> > > >  1 file changed, 9 insertions(+)
> > > >
> > > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > b/include/uapi/drm/drm_fourcc.h
> > > > index 3ad838d..83806d5 100644
> > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > @@ -112,6 +112,13 @@ extern "C" {
> > > >  #define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y')
> > > /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> > > >
> > > >  #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V')
> > > /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > > > +#define DRM_FORMAT_VUY888  fourcc_code('V', 'U', '2', '4') /* 
> > > > [23:0]
> > > Cr:Cb:Y little endian */
> > > > +#define DRM_FORMAT_XVUYfourcc_code('X', 'V', '2', '4') /*
> [31:0]
> > > x:Cr:Cb:Y 8:8:8:8 little endian */
> > > > +#define DRM_FORMAT_XVUY2101010 fourcc_code('X', 'V', '3', '0')
> > > /* [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> > > > +
> > > > +/* Grey scale */
> > > > +#define DRM_FORMAT_Y8  fourcc_code('G', 'R', 'E', 'Y') /*
> 8-bit
> > > packed greyscale Y:Y:Y:Y 8:8:8:8 */
> > > > +#define DRM_FORMAT_Y10 fourcc_code('Y', '1', '0', ' ') /*
> > > 10-bit packed greyscale X:Y:Y:Y 2:10:10:10 */
> > >
> > > These don't make sense to me. What does it even mean to have Y
> > > replicated three or four times for each pixel?
> >
> > Each pixel has one Y component. The comment is to describe how
> components are stored in 32bit, but I agree it's confusing. Will describe 
> better.
> 
> For the 8 bit Y format you should then define it as 8 bits. Unless of
> course it really is defined as a 32bit word containing 4 pixels. The
> 10 bit case would be even funky since there would have to be two
> bits of padding after every 3 pixels.
> 
> So are these really defined as 32 bit wits 3 or 4 pixels and potentially
> a few bits of extra padding packed into each word? That seems rather
> nuts to me because you can't even byte address each pixel.
> 
> I think such crazyness has no business living right next to the
> sane formats, hence we should put all these into their own little
> section of the header, and the names should somehow reflect that
> they are in fact "special".

Make sense to have a separate section for this kind of formats. Repeating the 
cover letter message for more details:

---
This series is to add new drm formats needed by some Xilinx IPs.
Some formats have unique characteristics such as pixels not being
byte-aligned. For instance, some 10bit formats have 2bit padding
after every 3-10bit components:

32b[0]: 10b comp0 - 10b comp1 - 10b comp2 - 2b padding
32b[1]: 10b comp3 - 10b comp4 - 10b comp5 - 2b padding
...

To model this, additional information is added to struct drm_format_info.
The patch has been tested with downstream drivers as well as the downstream
user space component (ex, modified modetest).
---

Thanks,
-hyun

> 
> --
> Ville Syrjälä
> Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[Bug 103953] [DC] Polaris10: Missing modes when enabling DC

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #135752|text/x-log  |text/plain
  mime type||

-- 
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 103953] [DC] Polaris10: Missing modes when enabling DC

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #135751|text/x-log  |text/plain
  mime type||

-- 
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 0/3] Adding new drm formats needed by Xilinx IPs

[Hyun Kwon]

> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Tuesday, November 28, 2017 9:38 AM
> To: Hyun Kwon 
> Cc: Daniel Vetter ; mon...@monstr.eu; David Airlie
> ; ML dri-devel ; Daniel
> Vetter ; Jeff Mouroux ; Satish
> Kumar Nagireddy ; Laurent Pinchart
> 
> Subject: Re: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs
> 
> On 28 November 2017 at 17:26, Hyun Kwon  wrote:
> >
> >
> >> -Original Message-
> >> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> >> Sent: Tuesday, November 28, 2017 7:02 AM
> >> To: Daniel Vetter 
> >> Cc: Hyun Kwon ; mon...@monstr.eu; David Airlie
> >> ; ML dri-devel ; Daniel
> >> Vetter ; Jeff Mouroux ;
> >> Satish Kumar Nagireddy ; Laurent Pinchart
> >> 
> >> Subject: Re: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs
> >>
> >> On 28 November 2017 at 11:09, Daniel Vetter  wrote:
> >> > On Mon, Nov 27, 2017 at 06:27:30PM -0800, Hyun Kwon wrote:
> >> >> Hi,
> >> >>
> >> >> This series is to add new drm formats needed by some Xilinx IPs.
> >> >> Some formats have unique characteristics such as pixels not being
> >> >> byte-aligned. For instance, some 10bit formats have 2bit padding
> >> >> after every 3-10bit components:
> >> >>
> >> >>   32b[0]: 10b comp0 - 10b comp1 - 10b comp2 - 2b padding
> >> >>   32b[1]: 10b comp3 - 10b comp4 - 10b comp5 - 2b padding
> >> >>   ...
> >> >>
> >> >> To model this, additional information is added to struct
> >> drm_format_info.
> >> >> The patch has been tested with downstream drivers as well as the
> >> downstream
> >> >> user space component (ex, modified modetest).
> >> >>
> >> >> Thanks,
> >> >> hyun
> >> >>
> >> >> Jeffrey Mouroux (2):
> >> >>   uapi: drm: New fourcc codes needed by Xilinx Video IP
> >> >>   drm: fourcc: Update DRM Framework with new fourcc codes
> >> >>
> >> >> Satish Kumar Nagireddy (1):
> >> >>   drm: drm_fourcc: Add scaling and padding factor to drm_format_info
> >> >
> >> > We need the driver for this.
> >>
> >> To elaborate this in different light:
> >> Without an upstream user (both kernel and userspace) this will be in a
> >> perpetual broken state.
> >> If the Xilinx DRM driver is still far off, one could update any of the
> >> existing drivers - say i915 :-P
> >
> > Fair enough. This patch will have to wait until any client code can be
> upstreamed along with.
> >
> Humble suggestion: try to upstream the basic functionality of your
> driver as early as possible.
> DRM evolves rapidly, so any lingering work will require serious work
> to rebase and ensure it works.
> 
> Quick skim at the Xilinx repository shows that initial work was done
> as back as 2013 [2] :-\

Thanks for the suggestion, and I agree. Xilinx has more downstream stuff than 
what you can see from that repo.

Thanks,
-hyun

> 
> -Emil
> [1] https://github.com/Xilinx/linux-xlnx
> [2] https://github.com/Xilinx/linux-
> xlnx/commit/aa76be1358005c42fadb2c7e9ac58a71a141dd7b
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge/synopsis: stop clobbering drvdata

[Brian Norris]

Hi Laurent,

On Tue, Nov 28, 2017 at 02:51:46PM +0200, Laurent Pinchart wrote:
> Hi Brian,
> 
> Thank you for the patch.
> 
> I'd mention dw-mipi-dsi in the subject line as the directory contains the dw-
> hdmi driver as well that this patch doesn't touch.

Yep. Does it need another tag in the subject? e.g., '.../dw-mipi-dsi:'?

> On Tuesday, 28 November 2017 03:05:38 EET Brian Norris wrote:
> > Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
> > parent driver might need to own this.
> 
> By parent driver I assume you mean a glue driver that binds to the SoC-
> specific compatible string for the DSI transmitter.

Indeed. Nickey picked this up for his Rockchip driver submission, but
maybe we should reword the commit message a bit.

> > Instead, let's return our
> > 'dw_mipi_dsi' object and have callers pass that back to us for removal.
> > 
> > Signed-off-by: Brian Norris 
> 
> Wouldn't it be cleaner to embed the dw_mipi_dsi structure in the parent-
> specific data structure (struct dw_mipi_dsi_stm and struct 
> dw_mipi_dsi_rockchip when the "[PATCH v3 0/5] Update ROCKCHIP DSI driver that 
> uses dw-mipi-dsi bridge" patch series will land) instead of allocating it 
> dynamically ? We would then have a single object to track.

I suppose we could do that too. But that would require exposing the
whole layout of 'struct dw_mipi_dsi' to users. Do we want to sacrifice
the enforced separation for a little bit of nicer object handling?

Also, this was modeled a bit after the similar rework needed to untangle
the drvdata handling in the Rockchip analogix DP driver vs. the analogix
bridge DP code:

[PATCH v6 03/10] drm/bridge: analogix: Do not use device's drvdata
https://patchwork.kernel.org/patch/10015875/

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

Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP

[Ville Syrjälä]

On Tue, Nov 28, 2017 at 05:25:46PM +, Hyun Kwon wrote:
> 
> 
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Tuesday, November 28, 2017 6:44 AM
> > To: Hyun Kwon 
> > Cc: Daniel Vetter ; Jani Nikula
> > ; Sean Paul ; David
> > Airlie ; dri-devel@lists.freedesktop.org;
> > mon...@monstr.eu; Laurent Pinchart
> > ; Satish Kumar Nagireddy
> > ; Jeff Mouroux 
> > Subject: Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx
> > Video IP
> > 
> > On Mon, Nov 27, 2017 at 06:27:32PM -0800, Hyun Kwon wrote:
> > > From: Jeffrey Mouroux 
> > >
> > > The Xilinx Video Mixer and Xilinx Video Framebuffer DMA IP
> > > support video memory formats that are not represented in the
> > > current DRM fourcc library.  This patch adds those missing
> > > fourcc codes.
> > >
> > > Signed-off-by: Jeffrey Mouroux 
> > > Signed-off-by: Hyun Kwon 
> > > ---
> > >  include/uapi/drm/drm_fourcc.h | 9 +
> > >  1 file changed, 9 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/drm_fourcc.h
> > b/include/uapi/drm/drm_fourcc.h
> > > index 3ad838d..83806d5 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -112,6 +112,13 @@ extern "C" {
> > >  #define DRM_FORMAT_VYUY  fourcc_code('V', 'Y', 'U', 'Y')
> > /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> > >
> > >  #define DRM_FORMAT_AYUV  fourcc_code('A', 'Y', 'U', 'V')
> > /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > > +#define DRM_FORMAT_VUY888fourcc_code('V', 'U', '2', '4') /* 
> > > [23:0]
> > Cr:Cb:Y little endian */
> > > +#define DRM_FORMAT_XVUY  fourcc_code('X', 'V', '2', '4') /* 
> > > [31:0]
> > x:Cr:Cb:Y 8:8:8:8 little endian */
> > > +#define DRM_FORMAT_XVUY2101010   fourcc_code('X', 'V', '3', '0')
> > /* [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> > > +
> > > +/* Grey scale */
> > > +#define DRM_FORMAT_Y8fourcc_code('G', 'R', 'E', 'Y') /* 8-bit
> > packed greyscale Y:Y:Y:Y 8:8:8:8 */
> > > +#define DRM_FORMAT_Y10   fourcc_code('Y', '1', '0', ' ') /*
> > 10-bit packed greyscale X:Y:Y:Y 2:10:10:10 */
> > 
> > These don't make sense to me. What does it even mean to have Y
> > replicated three or four times for each pixel?
> 
> Each pixel has one Y component. The comment is to describe how components are 
> stored in 32bit, but I agree it's confusing. Will describe better.

For the 8 bit Y format you should then define it as 8 bits. Unless of
course it really is defined as a 32bit word containing 4 pixels. The
10 bit case would be even funky since there would have to be two
bits of padding after every 3 pixels.

So are these really defined as 32 bit wits 3 or 4 pixels and potentially
a few bits of extra padding packed into each word? That seems rather
nuts to me because you can't even byte address each pixel.

I think such crazyness has no business living right next to the
sane formats, hence we should put all these into their own little
section of the header, and the names should somehow reflect that
they are in fact "special".

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

Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

[SF Markus Elfring]

>> Additional improvement possibilities can be taken into account
>> after corresponding software development discussions, can't they?
> 
> Sure, but that is in contrary to all you replies.

Where do you see a contradiction in this case?


> I guess you are familiar with Documentation/process/submitting-patches.rst 
> chapter 8.

I hope so in principle.


> No matter that patch was generated or suggested by a tool, you sent
> it and normal review procedure follows.

This is generally fine.


> And here you ignored _all_ suggestions

I did not integrate a few of them for my commit message so far
because it seems that there are open issues for further clarification.

Do you want that I send a second approach for this software module
before your own evolving update suggestion?


> and concentrate solely on improving Coccinelle scripts.

I hope not.


> On kernel related lists suggestions to patch itself are discussed.

This is usual.


> Whenever you take them into account while developing Coccinelle
> is up to you (on the Cocci list).

This is also happening, isn't it?

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

Re: [PATCH v6 2/2] staging: ion: create one device entry per heap

[Greg KH]

On Tue, Nov 28, 2017 at 05:37:53PM +, Mark Brown wrote:
> On Tue, Nov 28, 2017 at 06:28:38PM +0100, Greg KH wrote:
> > On Tue, Nov 28, 2017 at 05:12:23PM +, Mark Brown wrote:
> 
> > > I think it's reasonable to ask for userspace, I'm querying why it needs
> > > to specifically be Android.
> 
> > Does anyone other than Android use this interface?
> 
> There's plenty of other userspaces that have the same requirements for
> allocation for applications like video capture, I believe some of them
> have actually moved to ION already and they're certainly where some of
> the requirements here are coming from.

Then the Kconfig option should start to describe some of this :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs

[Hyun Kwon]

> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Tuesday, November 28, 2017 7:02 AM
> To: Daniel Vetter 
> Cc: Hyun Kwon ; mon...@monstr.eu; David Airlie
> ; ML dri-devel ; Daniel
> Vetter ; Jeff Mouroux ;
> Satish Kumar Nagireddy ; Laurent Pinchart
> 
> Subject: Re: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs
> 
> On 28 November 2017 at 11:09, Daniel Vetter  wrote:
> > On Mon, Nov 27, 2017 at 06:27:30PM -0800, Hyun Kwon wrote:
> >> Hi,
> >>
> >> This series is to add new drm formats needed by some Xilinx IPs.
> >> Some formats have unique characteristics such as pixels not being
> >> byte-aligned. For instance, some 10bit formats have 2bit padding
> >> after every 3-10bit components:
> >>
> >>   32b[0]: 10b comp0 - 10b comp1 - 10b comp2 - 2b padding
> >>   32b[1]: 10b comp3 - 10b comp4 - 10b comp5 - 2b padding
> >>   ...
> >>
> >> To model this, additional information is added to struct
> drm_format_info.
> >> The patch has been tested with downstream drivers as well as the
> downstream
> >> user space component (ex, modified modetest).
> >>
> >> Thanks,
> >> hyun
> >>
> >> Jeffrey Mouroux (2):
> >>   uapi: drm: New fourcc codes needed by Xilinx Video IP
> >>   drm: fourcc: Update DRM Framework with new fourcc codes
> >>
> >> Satish Kumar Nagireddy (1):
> >>   drm: drm_fourcc: Add scaling and padding factor to drm_format_info
> >
> > We need the driver for this.
> 
> To elaborate this in different light:
> Without an upstream user (both kernel and userspace) this will be in a
> perpetual broken state.
> If the Xilinx DRM driver is still far off, one could update any of the
> existing drivers - say i915 :-P

Fair enough. This patch will have to wait until any client code can be 
upstreamed along with.

Thanks,
-hyun

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

Re: [PATCH v2 01/18] dt-bindings: panel: lvds: Document power-supply property

[Rob Herring]

Please CC DT list.

On Mon, Nov 27, 2017 at 9:41 AM, Maxime Ripard
 wrote:
> The power-supply property is used by a vast majority of panels, including
> panel-simple. Let's document it as a common property
>
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 ++
>  Documentation/devicetree/bindings/display/panel/panel-lvds.txt   | 1 +
>  2 files changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.txt 
> b/Documentation/devicetree/bindings/display/panel/panel-common.txt
> index ec52c472c845..125ea68052af 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
> +++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt
> @@ -78,6 +78,12 @@ used for panels that implement compatible control signals.
>while active. Active high reset signals can be supported by inverting the
>GPIO specifier polarity flag.
>
> +Power
> +-
> +
> +- power-supply: many display panels need an additional power supply in
> +  order to be fully powered-up. For such panels, power-supply contains
> +  a phandle to the regulator powering the panel.
>
>  Backlight
>  -
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt 
> b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> index b938269f841e..250850a2150b 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> @@ -32,6 +32,7 @@ Optional properties:
>  - label: See panel-common.txt.
>  - gpios: See panel-common.txt.
>  - backlight: See panel-common.txt.
> +- power-supply: See panel-common.txt.

simple-panel.txt should do the same.

Really, I'd like to see panel-common.txt and simple-panel.txt merged
and simple-panel.txt removed altogether. But there are a lot of
references back to simple-panel.txt. A given panel still needs to say
what common properties it uses or doesn't use. Omitting a property
like power-supply is ambiguous and can either mean "I only have 1
supply" or "I haven't thought about supplies yet there are more than
1".

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

Re: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs

[Emil Velikov]

On 28 November 2017 at 17:26, Hyun Kwon  wrote:
>
>
>> -Original Message-
>> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
>> Sent: Tuesday, November 28, 2017 7:02 AM
>> To: Daniel Vetter 
>> Cc: Hyun Kwon ; mon...@monstr.eu; David Airlie
>> ; ML dri-devel ; Daniel
>> Vetter ; Jeff Mouroux ;
>> Satish Kumar Nagireddy ; Laurent Pinchart
>> 
>> Subject: Re: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs
>>
>> On 28 November 2017 at 11:09, Daniel Vetter  wrote:
>> > On Mon, Nov 27, 2017 at 06:27:30PM -0800, Hyun Kwon wrote:
>> >> Hi,
>> >>
>> >> This series is to add new drm formats needed by some Xilinx IPs.
>> >> Some formats have unique characteristics such as pixels not being
>> >> byte-aligned. For instance, some 10bit formats have 2bit padding
>> >> after every 3-10bit components:
>> >>
>> >>   32b[0]: 10b comp0 - 10b comp1 - 10b comp2 - 2b padding
>> >>   32b[1]: 10b comp3 - 10b comp4 - 10b comp5 - 2b padding
>> >>   ...
>> >>
>> >> To model this, additional information is added to struct
>> drm_format_info.
>> >> The patch has been tested with downstream drivers as well as the
>> downstream
>> >> user space component (ex, modified modetest).
>> >>
>> >> Thanks,
>> >> hyun
>> >>
>> >> Jeffrey Mouroux (2):
>> >>   uapi: drm: New fourcc codes needed by Xilinx Video IP
>> >>   drm: fourcc: Update DRM Framework with new fourcc codes
>> >>
>> >> Satish Kumar Nagireddy (1):
>> >>   drm: drm_fourcc: Add scaling and padding factor to drm_format_info
>> >
>> > We need the driver for this.
>>
>> To elaborate this in different light:
>> Without an upstream user (both kernel and userspace) this will be in a
>> perpetual broken state.
>> If the Xilinx DRM driver is still far off, one could update any of the
>> existing drivers - say i915 :-P
>
> Fair enough. This patch will have to wait until any client code can be 
> upstreamed along with.
>
Humble suggestion: try to upstream the basic functionality of your
driver as early as possible.
DRM evolves rapidly, so any lingering work will require serious work
to rebase and ensure it works.

Quick skim at the Xilinx repository shows that initial work was done
as back as 2013 [2] :-\

-Emil
[1] https://github.com/Xilinx/linux-xlnx
[2] 
https://github.com/Xilinx/linux-xlnx/commit/aa76be1358005c42fadb2c7e9ac58a71a141dd7b
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 2/2] staging: ion: create one device entry per heap

[Mark Brown]

On Tue, Nov 28, 2017 at 06:28:38PM +0100, Greg KH wrote:
> On Tue, Nov 28, 2017 at 05:12:23PM +, Mark Brown wrote:

> > I think it's reasonable to ask for userspace, I'm querying why it needs
> > to specifically be Android.

> Does anyone other than Android use this interface?

There's plenty of other userspaces that have the same requirements for
allocation for applications like video capture, I believe some of them
have actually moved to ION already and they're certainly where some of
the requirements here are coming from.


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

[Bug 103743] Nier:Automata - "if" in fragment shader incorrectly evaluated, causes artifacts

[bugzilla-daemon]

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

--- Comment #11 from Philip Rebohle  ---
Created attachment 135781
  --> https://bugs.freedesktop.org/attachment.cgi?id=135781=edit
Frame 2800 with patched LLVM

-- 
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 103743] Nier:Automata - "if" in fragment shader incorrectly evaluated, causes artifacts

[bugzilla-daemon]

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

--- Comment #10 from Philip Rebohle  ---
Created attachment 135780
  --> https://bugs.freedesktop.org/attachment.cgi?id=135780=edit
Frame 2320 with patched LLVM

-- 
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 103743] Nier:Automata - "if" in fragment shader incorrectly evaluated, causes artifacts

[bugzilla-daemon]

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

--- Comment #9 from Philip Rebohle  ---
Thanks for looking into this. While these two patches certainly improve the
situation significantly, they don't fix the issue entirely.

The remaining artifacts are hardly noticable in the original apitrace, so I
created another one (2.9G, bz2-compressed):
https://mega.nz/#!FHxSgZjL!0MzRQhI6W6Lk0beTv9LrPxDWjNTQveDuXVq3Mz2s7-M

Note that my original workaround still works with the LLVM patches applied.

Tested with updated LLVM-git, revision accb337c76e.

-- 
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 v6 2/2] staging: ion: create one device entry per heap

[Greg KH]

On Tue, Nov 28, 2017 at 05:12:23PM +, Mark Brown wrote:
> On Tue, Nov 28, 2017 at 06:08:22PM +0100, Greg KH wrote:
> > On Tue, Nov 28, 2017 at 04:26:20PM +, Mark Brown wrote:
> > > On Tue, Nov 28, 2017 at 02:32:17PM +0100, Greg KH wrote:
> 
> > > > call you added?  What did you do to test this out?  Where are the AOSP
> > > > patches to use this?  Happen to have a VTS test for it?
> 
> > > Do we need to convert Android for this to be accepted?  The single
> > > device is being kept around for it and the use case was from non-Android
> > > users wasn't it?
> 
> > So we are just going to add kernel features with no userspace users of
> > it at all?  Why would we do that?  How was it even tested?
> 
> I think it's reasonable to ask for userspace, I'm querying why it needs
> to specifically be Android.

Does anyone other than Android use this interface?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP

[Hyun Kwon]

> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, November 28, 2017 6:44 AM
> To: Hyun Kwon 
> Cc: Daniel Vetter ; Jani Nikula
> ; Sean Paul ; David
> Airlie ; dri-devel@lists.freedesktop.org;
> mon...@monstr.eu; Laurent Pinchart
> ; Satish Kumar Nagireddy
> ; Jeff Mouroux 
> Subject: Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx
> Video IP
> 
> On Mon, Nov 27, 2017 at 06:27:32PM -0800, Hyun Kwon wrote:
> > From: Jeffrey Mouroux 
> >
> > The Xilinx Video Mixer and Xilinx Video Framebuffer DMA IP
> > support video memory formats that are not represented in the
> > current DRM fourcc library.  This patch adds those missing
> > fourcc codes.
> >
> > Signed-off-by: Jeffrey Mouroux 
> > Signed-off-by: Hyun Kwon 
> > ---
> >  include/uapi/drm/drm_fourcc.h | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h
> b/include/uapi/drm/drm_fourcc.h
> > index 3ad838d..83806d5 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -112,6 +112,13 @@ extern "C" {
> >  #define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y')
> /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> >
> >  #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V')
> /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > +#define DRM_FORMAT_VUY888  fourcc_code('V', 'U', '2', '4') /* [23:0]
> Cr:Cb:Y little endian */
> > +#define DRM_FORMAT_XVUYfourcc_code('X', 'V', '2', '4') /* 
> > [31:0]
> x:Cr:Cb:Y 8:8:8:8 little endian */
> > +#define DRM_FORMAT_XVUY2101010 fourcc_code('X', 'V', '3', '0')
> /* [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> > +
> > +/* Grey scale */
> > +#define DRM_FORMAT_Y8  fourcc_code('G', 'R', 'E', 'Y') /* 8-bit
> packed greyscale Y:Y:Y:Y 8:8:8:8 */
> > +#define DRM_FORMAT_Y10 fourcc_code('Y', '1', '0', ' ') /*
> 10-bit packed greyscale X:Y:Y:Y 2:10:10:10 */
> 
> These don't make sense to me. What does it even mean to have Y
> replicated three or four times for each pixel?

Each pixel has one Y component. The comment is to describe how components are 
stored in 32bit, but I agree it's confusing. Will describe better.

> 
> >
> >  /*
> >   * 2 plane RGB + A
> > @@ -140,6 +147,8 @@ extern "C" {
> >  #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1')
> /* 2x1 subsampled Cb:Cr plane */
> >  #define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4')
> /* non-subsampled Cr:Cb plane */
> >  #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2')
> /* non-subsampled Cb:Cr plane */
> > +#define DRM_FORMAT_XV15fourcc_code('X', 'V', '1', '5')
> /* 2x2 subsampled Cr:Cb plane 2:10:10:10 */
> > +#define DRM_FORMAT_XV20fourcc_code('X', 'V', '2', '0')
> /* 2x1 subsampled Cr:Cb plane 2:10:10:10 */
> 
> Huh. Where are the Cb:Cr in that 2:10:10:10 layout?
> 
> Better docs please.

Sure. Will add more details on how components are laid out.

Thanks,
-hyun

> 
> >
> >  /*
> >   * 3 plane YCbCr
> > --
> > 2.7.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> --
> Ville Syrjälä
> Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 2/2] staging: ion: create one device entry per heap

[Mark Brown]

On Tue, Nov 28, 2017 at 06:08:22PM +0100, Greg KH wrote:
> On Tue, Nov 28, 2017 at 04:26:20PM +, Mark Brown wrote:
> > On Tue, Nov 28, 2017 at 02:32:17PM +0100, Greg KH wrote:

> > > call you added?  What did you do to test this out?  Where are the AOSP
> > > patches to use this?  Happen to have a VTS test for it?

> > Do we need to convert Android for this to be accepted?  The single
> > device is being kept around for it and the use case was from non-Android
> > users wasn't it?

> So we are just going to add kernel features with no userspace users of
> it at all?  Why would we do that?  How was it even tested?

I think it's reasonable to ask for userspace, I'm querying why it needs
to specifically be Android.


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

Re: [PATCH v6 2/2] staging: ion: create one device entry per heap

[Greg KH]

On Tue, Nov 28, 2017 at 04:26:20PM +, Mark Brown wrote:
> On Tue, Nov 28, 2017 at 02:32:17PM +0100, Greg KH wrote:
> 
> > Where is the documentation for the new sysfs files and the new ioctl
> 
> Didn't see any sysfs files in there?

New struct devices were created and registered.  Why would that happen
if there was not a need for sysfs files? :)

> > call you added?  What did you do to test this out?  Where are the AOSP
> > patches to use this?  Happen to have a VTS test for it?
> 
> Do we need to convert Android for this to be accepted?  The single
> device is being kept around for it and the use case was from non-Android
> users wasn't it?

So we are just going to add kernel features with no userspace users of
it at all?  Why would we do that?  How was it even tested?

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

Re: [Intel-gfx] [PATCH v6 5/7] drm/i915: Add "panel orientation" property to the panel connector, v6.

[kbuild test robot]

Hi Hans,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.15-rc1 next-20171128]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-fbdev-Panel-orientation-connector-property-support/20171128-225025
config: i386-randconfig-x074-201748 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_dsi.c: In function 
'intel_dsi_get_panel_orientation':
>> drivers/gpu/drm/i915/intel_dsi.c:1672:21: error: storage size of 'plane' 
>> isn't known
 enum i9xx_plane_id plane;
^
   drivers/gpu/drm/i915/intel_dsi.c:1672:21: warning: unused variable 'plane' 
[-Wunused-variable]

vim +1672 drivers/gpu/drm/i915/intel_dsi.c

  1667  
  1668  static int intel_dsi_get_panel_orientation(struct intel_connector 
*connector)
  1669  {
  1670  struct drm_i915_private *dev_priv = 
to_i915(connector->base.dev);
  1671  int orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> 1672  enum i9xx_plane_id plane;
  1673  u32 val;
  1674  
  1675  if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
  1676  if (connector->encoder->crtc_mask == BIT(PIPE_B))
  1677  plane = PLANE_B;
  1678  else
  1679  plane = PLANE_A;
  1680  
  1681  val = I915_READ(DSPCNTR(plane));
  1682  if (val & DISPPLANE_ROTATE_180)
  1683  orientation = 
DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
  1684  }
  1685  
  1686  return orientation;
  1687  }
  1688  

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


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

[Bug 103697] [regression] shared memory size 64k -> 32k?

[bugzilla-daemon]

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

--- Comment #4 from O Heid  ---
Many thanks for your consideration - That would be great!
Our application is real time image processing and display. The main computing
effort is delay-and-sum beamforming.
Source and destination data sets are much larger than LDS so we need to do
block processing. This causes additional LDS <-> GPURAM traffic essentially
inversely proportional to block (LDS) size. A 32k vs 64k limit (and thus twice
the RAM traffic) therefore causes quite a performance hit.
Anyway: Mesa's OpenGL performance on AMD Radeons is quite amazing. Great job!

-- 
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 v6 2/2] staging: ion: create one device entry per heap

[Mark Brown]

On Tue, Nov 28, 2017 at 02:32:17PM +0100, Greg KH wrote:

> Where is the documentation for the new sysfs files and the new ioctl

Didn't see any sysfs files in there?

> call you added?  What did you do to test this out?  Where are the AOSP
> patches to use this?  Happen to have a VTS test for it?

Do we need to convert Android for this to be accepted?  The single
device is being kept around for it and the use case was from non-Android
users wasn't it?


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

[Bug 100726] [REGRESSION][BISECTED] Severe flickering with an R9 290

[bugzilla-daemon]

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

--- Comment #8 from Michel Dänzer  ---
(In reply to hiwatari.seiji from comment #7)
> Are you sure, that b7d91c915290ab0bfbab84a0fb9c9eae57816982 is definitely
> not the cause?

At least 99% sure. Pure merge commits are almost never a correct bisection
result.


> - For me, when booting the machine (BIOS) - the screen resolution of GRUB is
> quite random. Sometimes, it's using the native screen resolution, sometimes
> it is using a very reduced resolution. Sometimes, it's only displaying on
> one of the two screens, sometimes it's displaying on both. But that wasn't a
> problem before linux-4.9.

This is before the Linux kernel is even loaded, so it can hardly be directly
related to 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

Re: [PATCH 01/17] drm/sun4i: Refactor DE2 code

[Maxime Ripard]

Hi,

On Mon, Nov 27, 2017 at 09:57:34PM +0100, Jernej Skrabec wrote:
> Since the time initial DE2 driver was written, some knowledge was gained
> what setting are really necessary and what most of the magic values
> mean.
> 
> This commit renames some of the macro names to better fit the real
> meaning, replace default values with self explaining macros where
> possible and removes settings which are not really needed.
> 
> Signed-off-by: Jernej Skrabec 

While those changes are quite welcome, it should be split in a number
of patches...

> ---
>  drivers/gpu/drm/sun4i/sun8i_mixer.c | 65 
> +++--
>  drivers/gpu/drm/sun4i/sun8i_mixer.h | 31 --
>  2 files changed, 47 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c 
> b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> index cb193c5f1686..015943c0ed5a 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -44,7 +44,8 @@ void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
>   /* Currently the first UI channel is used */
>   int chan = mixer->cfg->vi_num;
>  
> - DRM_DEBUG_DRIVER("Enabling layer %d in channel %d\n", layer, chan);
> + DRM_DEBUG_DRIVER("%sabling layer %d in channel %d\n",
> +  enable ? "En" : "Dis", layer, chan);
>  
>   if (enable)
>   val = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN;
> @@ -55,15 +56,14 @@ void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
>  SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
>  SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val);
>  
> - /* Set the alpha configuration */
> - regmap_update_bits(mixer->engine.regs,
> -SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
> -SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK,
> -SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_DEF);
> + if (enable)
> + val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(chan);
> + else
> + val = 0;
> +
>   regmap_update_bits(mixer->engine.regs,
> -SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
> -SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK,
> -SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_DEF);
> +SUN8I_MIXER_BLEND_PIPE_CTL,
> +SUN8I_MIXER_BLEND_PIPE_CTL_EN(chan), val);

... For example, this part right here will remove the alpha setup
part, without any justification in the commit log ...

>  }
>  
>  static int sun8i_mixer_drm_format_to_layer(struct drm_plane *plane,
> @@ -71,15 +71,15 @@ static int sun8i_mixer_drm_format_to_layer(struct 
> drm_plane *plane,
>  {
>   switch (format) {
>   case DRM_FORMAT_ARGB:
> - *mode = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_ARGB;
> + *mode = SUN8I_MIXER_FBFMT_ARGB;
>   break;
>  
>   case DRM_FORMAT_XRGB:
> - *mode = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_XRGB;
> + *mode = SUN8I_MIXER_FBFMT_XRGB;
>   break;
>  
>   case DRM_FORMAT_RGB888:
> - *mode = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_RGB888;
> + *mode = SUN8I_MIXER_FBFMT_RGB888;
>   break;
>  
>   default:
> @@ -107,7 +107,7 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer 
> *mixer,
> state->crtc_h));
>   DRM_DEBUG_DRIVER("Updating blender size\n");
>   regmap_write(mixer->engine.regs,
> -  SUN8I_MIXER_BLEND_ATTR_INSIZE(0),
> +  SUN8I_MIXER_BLEND_ATTR_INSIZE(chan),

I guess that one is fixing a bug too.

>SUN8I_MIXER_SIZE(state->crtc_w,
> state->crtc_h));
>   regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_OUTSIZE,
> @@ -173,6 +173,7 @@ int sun8i_mixer_update_layer_formats(struct sun8i_mixer 
> *mixer,
>   return ret;
>   }
>  
> + val <<= SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_OFFSET;
>   regmap_update_bits(mixer->engine.regs,
>  SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
>  SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK, val);
> @@ -247,6 +248,7 @@ static int sun8i_mixer_bind(struct device *dev, struct 
> device *master,
>   struct sun8i_mixer *mixer;
>   struct resource *res;
>   void __iomem *regs;
> + int plane_cnt;
>   int i, ret;
>  
>   /*
> @@ -325,27 +327,26 @@ static int sun8i_mixer_bind(struct device *dev, struct 
> device *master,
>   regmap_write(mixer->engine.regs, SUN8I_MIXER_GLOBAL_CTL,
>SUN8I_MIXER_GLOBAL_CTL_RT_EN);
>  
> - /* Initialize blender */
> - regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_FCOLOR_CTL,
> -  

Re: [PATCH v2 11/18] drm/sun4i: Add A83T support

[Maxime Ripard]

On Tue, Nov 28, 2017 at 07:50:19PM +0800, Icenowy Zheng wrote:
> 在 2017-11-28 17:02，Maxime Ripard 写道：
> > Hi,
> > 
> > On Mon, Nov 27, 2017 at 05:01:49PM +0100, Jernej Škrabec wrote:
> > > Dne ponedeljek, 27. november 2017 ob 16:41:35 CET je Maxime Ripard
> > > napisal(a):
> > > > Add support for the A83T display pipeline.
> > > >
> > > > Reviewed-by: Chen-Yu Tsai 
> > > > Signed-off-by: Maxime Ripard 
> > > > ---
> > > >  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
> > > >  drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
> > > >  drivers/gpu/drm/sun4i/sun4i_tcon.c| 5 +
> > > >  drivers/gpu/drm/sun4i/sun8i_mixer.c   | 4 
> > > >  4 files changed, 14 insertions(+)
> > > >
> > > > diff --git 
> > > > a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index
> > > > d4259a4f5171..d6b52e5c48c0 100644
> > > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > > @@ -93,6 +93,7 @@ Required properties:
> > > > * allwinner,sun6i-a31s-tcon
> > > > * allwinner,sun7i-a20-tcon
> > > > * allwinner,sun8i-a33-tcon
> > > > +   * allwinner,sun8i-a83t-tcon-lcd
> > > > * allwinner,sun8i-v3s-tcon
> > > >   - reg: base address and size of memory-mapped region
> > > >   - interrupts: interrupt associated to this IP
> > > > @@ -224,6 +225,7 @@ supported.
> > > >
> > > >  Required properties:
> > > >- compatible: value must be one of:
> > > > +* allwinner,sun8i-a83t-de2-mixer
> > > 
> > > What will be the name of the second mixer, once support for HDMI is
> > > added?
> > > Should we start directly with 0 and 1 postfix ?
> > 
> > What are the differences exactly without the two mixers?
> > 
> > I was hoping to be able to cover them all using properties, indices
> > are usually pretty badly received in compatibles.
> 
> 1. VEP is only available on the VI channel in mixer0. (VEP may mean
> Video Enhance Processor)
> 2. Smart Backlight is only available in mixer0's on SoCs with LCD.
> 3. Writeback function is only available in mixer0.

Then yeah, we can totally support that using properties.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH v2 00/18] drm/sun4i: Add A83t LVDS support

[Maxime Ripard]

Hi Jernej,

On Mon, Nov 27, 2017 at 05:20:52PM +0100, Jernej Škrabec wrote:
> Hi,
> 
> Dne ponedeljek, 27. november 2017 ob 16:41:24 CET je Maxime Ripard napisal(a):
> > Hi,
> > 
> > Here is an attempt at supporting the LVDS output in our DRM driver. This
> > has been tested on the A83T (with DE2), but since everything is basically
> > in the TCON, it should also be usable on the older SoCs with minor
> > modifications.
> > 
> > This was the occasion to refactor a bunch of things. The most notable ones
> > would be the documentation, and split of the UI layers in the mixer code,
> 
> I'm just about to send my series of patches which would add full support for 
> UI and VI planes (multi planes, HW scaling, all color formats). It would 
> clash 
> with your patches 6, 7 and 8.
> 
> Preview of my work as a single patch can be seen here:
> https://github.com/jernejsk/linux-1/commit/
> 8fdef3b510b567bfe81c87b0c3e73ddcf4f5b711
> 
> How would you like to handle that? Some changes are similar, but I don't see 
> a 
> point rebasing my patches atop of yours.
> 
> Since I'm almost done, I will just send them and we can discuss them then.

Yeah, I had a quick look at it and it doesn't look like it conflicts
too much. I'll have a closer look as soon as I can, but I guess we can
just go in parallel and whoever hits first wins.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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 v6 6/7] efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation_quirk

[kbuild test robot]

Hi Hans,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.15-rc1 next-20171128]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-fbdev-Panel-orientation-connector-property-support/20171128-225025
config: i386-randconfig-x003-201748 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/video/fbdev/efifb.c: In function 'efifb_probe':
>> drivers/video/fbdev/efifb.c:340:7: error: 
>> 'DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP' undeclared (first use in this 
>> function); did you mean 'DRM_MODE_PRESENT_BOTTOM_FIELD'?
 case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
  ^~~~
  DRM_MODE_PRESENT_BOTTOM_FIELD
   drivers/video/fbdev/efifb.c:340:7: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/video/fbdev/efifb.c:343:7: error: 
>> 'DRM_MODE_PANEL_ORIENTATION_LEFT_UP' undeclared (first use in this 
>> function); did you mean 'DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP'?
 case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
  ^~
  DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP
>> drivers/video/fbdev/efifb.c:346:7: error: 
>> 'DRM_MODE_PANEL_ORIENTATION_RIGHT_UP' undeclared (first use in this 
>> function); did you mean 'DRM_MODE_PANEL_ORIENTATION_LEFT_UP'?
 case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
  ^~~
  DRM_MODE_PANEL_ORIENTATION_LEFT_UP

vim +340 drivers/video/fbdev/efifb.c

   158  
   159  static int efifb_probe(struct platform_device *dev)
   160  {
   161  struct fb_info *info;
   162  int err, orientation;
   163  unsigned int size_vmode;
   164  unsigned int size_remap;
   165  unsigned int size_total;
   166  char *option = NULL;
   167  
   168  if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || 
pci_dev_disabled)
   169  return -ENODEV;
   170  
   171  if (fb_get_options("efifb", ))
   172  return -ENODEV;
   173  efifb_setup(option);
   174  
   175  /* We don't get linelength from UGA Draw Protocol, only from
   176   * EFI Graphics Protocol.  So if it's not in DMI, and it's not
   177   * passed in from the user, we really can't use the framebuffer.
   178   */
   179  if (!screen_info.lfb_linelength)
   180  return -ENODEV;
   181  
   182  if (!screen_info.lfb_depth)
   183  screen_info.lfb_depth = 32;
   184  if (!screen_info.pages)
   185  screen_info.pages = 1;
   186  if (!fb_base_is_valid()) {
   187  printk(KERN_DEBUG "efifb: invalid framebuffer 
address\n");
   188  return -ENODEV;
   189  }
   190  printk(KERN_INFO "efifb: probing for efifb\n");
   191  
   192  /* just assume they're all unset if any are */
   193  if (!screen_info.blue_size) {
   194  screen_info.blue_size = 8;
   195  screen_info.blue_pos = 0;
   196  screen_info.green_size = 8;
   197  screen_info.green_pos = 8;
   198  screen_info.red_size = 8;
   199  screen_info.red_pos = 16;
   200  screen_info.rsvd_size = 8;
   201  screen_info.rsvd_pos = 24;
   202  }
   203  
   204  efifb_fix.smem_start = screen_info.lfb_base;
   205  
   206  if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE) {
   207  u64 ext_lfb_base;
   208  
   209  ext_lfb_base = (u64)(unsigned 
long)screen_info.ext_lfb_base << 32;
   210  efifb_fix.smem_start |= ext_lfb_base;
   211  }
   212  
   213  if (bar_resource &&
   214  bar_resource->start + bar_offset != efifb_fix.smem_start) {
   215  dev_info(_pci_dev->dev,
   216   "BAR has moved, updating efifb address\n");
   217  efifb_fix.smem_start = bar_resource->start + bar_offset;
   218  }
   219  
   220  efifb_defined.bits_per_pixel = screen_info.lfb_depth;
   221  efifb_defined.xres = screen_info.lfb_width;
   222  efifb_defined.yres = screen_info.lfb_height;
   223  efifb_fix.line_length = screen_info.lfb_linelength;
   224  
   225  /*   size_vmode -- that is the amount of memory needed for the
   226   * used video mode, i

[PATCH libdrm] amdgpu: Add explicit dependency test.

[Andrey Grodzovsky]

The test is as following:

1) Create context A & B
2) Send a command submission using context A which fires up a compute shader.
3) The shader wait a bit and then write a value to a memory location.
4) Send a command submission using context B which writes another value to the 
same memory location, but having an explicit dependency on the first command 
submission.
5) Wait with the CPU for both submissions to finish and inspect the written 
value.

Test passes if the value seen in the memory location after both submissions is 
from command B.

Signed-off-by: Andrey Grodzovsky 
---
 tests/amdgpu/amdgpu_test.c |  18 
 tests/amdgpu/basic_tests.c | 264 +
 2 files changed, 282 insertions(+)

diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index 50da17c..8fa3399 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -49,6 +49,7 @@
 #include "CUnit/Basic.h"
 
 #include "amdgpu_test.h"
+#include "amdgpu_internal.h"
 
 /* Test suit names */
 #define BASIC_TESTS_STR "Basic Tests"
@@ -401,9 +402,20 @@ static int amdgpu_find_device(uint8_t bus, uint16_t dev)
 
 static void amdgpu_disable_suits()
 {
+   amdgpu_device_handle device_handle;
+   uint32_t major_version, minor_version, family_id;
int i;
int size = sizeof(suites_active_stat) / sizeof(suites_active_stat[0]);
 
+   if (amdgpu_device_initialize(drm_amdgpu[0], _version,
+  _version, _handle))
+   return;
+
+   family_id = device_handle->info.family_id;
+
+   if (amdgpu_device_deinitialize(device_handle))
+   return;
+
/* Set active status for suits based on their policies */
for (i = 0; i < size; ++i)
if (amdgpu_set_suite_active(suites_active_stat[i].pName,
@@ -420,6 +432,12 @@ static void amdgpu_disable_suits()
 
if (amdgpu_set_test_active(BO_TESTS_STR, "Metadata", CU_FALSE))
fprintf(stderr, "test deactivation failed - %s\n", 
CU_get_error_msg());
+
+
+   /* This test was ran on GFX8 and GFX9 only */
+   if (family_id < AMDGPU_FAMILY_VI || family_id > AMDGPU_FAMILY_RV)
+   if (amdgpu_set_test_active(BASIC_TESTS_STR, "Sync dependency 
Test", CU_FALSE))
+   fprintf(stderr, "test deactivation failed - %s\n", 
CU_get_error_msg());
 }
 
 /* The main() function for setting up and running the tests.
diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index e7f48e3..a78cf52 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -50,6 +50,7 @@ static void amdgpu_command_submission_multi_fence(void);
 static void amdgpu_command_submission_sdma(void);
 static void amdgpu_userptr_test(void);
 static void amdgpu_semaphore_test(void);
+static void amdgpu_sync_dependency_test(void);
 
 static void amdgpu_command_submission_write_linear_helper(unsigned ip_type);
 static void amdgpu_command_submission_const_fill_helper(unsigned ip_type);
@@ -63,6 +64,7 @@ CU_TestInfo basic_tests[] = {
{ "Command submission Test (Multi-Fence)", 
amdgpu_command_submission_multi_fence },
{ "Command submission Test (SDMA)", amdgpu_command_submission_sdma },
{ "SW semaphore Test",  amdgpu_semaphore_test },
+   { "Sync dependency Test",  amdgpu_sync_dependency_test },
CU_TEST_INFO_NULL,
 };
 #define BUFFER_SIZE (8 * 1024)
@@ -226,6 +228,60 @@ CU_TestInfo basic_tests[] = {
 */
 #  define PACKET3_DMA_DATA_SI_CP_SYNC (1 << 31)
 
+
+#define PKT3_CONTEXT_CONTROL   0x28
+#define CONTEXT_CONTROL_LOAD_ENABLE(x) (((unsigned)(x) & 0x1) << 31)
+#define CONTEXT_CONTROL_LOAD_CE_RAM(x) (((unsigned)(x) & 0x1) << 28)
+#define CONTEXT_CONTROL_SHADOW_ENABLE(x)   (((unsigned)(x) & 0x1) << 31)
+
+#define PKT3_CLEAR_STATE   0x12
+
+#define PKT3_SET_SH_REG0x76
+#definePACKET3_SET_SH_REG_START
0x2c00
+
+#definePACKET3_DISPATCH_DIRECT 0x15
+
+
+/* gfx 8 */
+#define mmCOMPUTE_PGM_LO   
 0x2e0c
+#define mmCOMPUTE_PGM_RSRC1
 0x2e12
+#define mmCOMPUTE_TMPRING_SIZE 
 0x2e18
+#define mmCOMPUTE_USER_DATA_0  
 0x2e40
+#define mmCOMPUTE_USER_DATA_1  
 0x2e41
+#define mmCOMPUTE_RESOURCE_LIMITS  
 0x2e15
+#define mmCOMPUTE_NUM_THREAD_X 
 0x2e07
+
+
+
+#define SWAP_32(num) ((num>>24)&0xff) | \
+   ((num<<8)&0xff) | \
+   ((num>>8)&0xff00) | \
+   ((num<<24)&0xff00)
+
+
+/* 

Re: [Intel-gfx] [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()

[Ville Syrjälä]

On Mon, Nov 27, 2017 at 11:57:46AM -0500, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
> 
> Getting ready to remove pci_get_bus_and_slot() function in favor of
> pci_get_domain_bus_and_slot().
> 
> Extract the domain number from drm_device and pass it into
> pci_get_domain_bus_and_slot() function.
> 
> Signed-off-by: Sinan Kaya 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9f45cfe..5a8cb79 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -419,7 +419,10 @@ static int i915_getparam(struct drm_device *dev, void 
> *data,
>  
>  static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
>  {
> - dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> + int domain = pci_domain_nr(dev_priv->drm.pdev->bus);
> +
> + dev_priv->bridge_dev =
> + pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 0));

Maybe just pci_get_slot(pdev->bus, PCI_DEVFN(0, 0)) ?

I guess if we want to be pedantic we could go for:

bus = pci_find_host_bridge(pdev->bus)->bus;
pci_get_slot(bus, PCI_DEVFN(0, 0))

but I think the GPU should always be on the root bus, so the simpler
form should be fine.

>   if (!dev_priv->bridge_dev) {
>   DRM_ERROR("bridge device not found\n");
>   return -1;
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[radeon-alex:amd-staging-drm-next 151/475] sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function 'readl'; did you mean 'vread'?

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   f3769c94f4e6a794dbb72601936199d9b258f7b7
commit: 0bd599b1f523598c05f13a4a562884e82a378c2c [151/475] ASoC: AMD: enable 
ACP3x drivers build
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 0bd599b1f523598c05f13a4a562884e82a378c2c
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   In file included from sound/soc/amd/raven/acp3x-pcm-dma.c:26:0:
   sound/soc/amd/raven/acp3x.h: In function 'rv_readl':
>> sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function 
>> 'readl'; did you mean 'vread'? [-Werror=implicit-function-declaration]
 return readl(base_addr - ACP3x_PHY_BASE_ADDRESS);
^
vread
   sound/soc/amd/raven/acp3x.h: In function 'rv_writel':
>> sound/soc/amd/raven/acp3x.h:33:2: error: implicit declaration of function 
>> 'writel'; did you mean 'vwrite'? [-Werror=implicit-function-declaration]
 writel(val, base_addr - ACP3x_PHY_BASE_ADDRESS);
 ^~
 vwrite
   sound/soc/amd/raven/acp3x-pcm-dma.c: In function 'acp3x_audio_probe':
>> sound/soc/amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of 
>> function 'devm_ioremap'; did you mean 'devm_kmemdup'? 
>> [-Werror=implicit-function-declaration]
 adata->acp3x_base = devm_ioremap(>dev, res->start,
 ^~~~
 devm_kmemdup
   sound/soc/amd/raven/acp3x-pcm-dma.c:638:20: warning: assignment makes 
pointer from integer without a cast [-Wint-conversion]
 adata->acp3x_base = devm_ioremap(>dev, res->start,
   ^
   cc1: some warnings being treated as errors

vim +28 sound/soc/amd/raven/acp3x.h

4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27  25  
4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27  26  static inline u32 
rv_readl(void __iomem *base_addr)
4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27  27  {
4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 @28return readl(base_addr 
- ACP3x_PHY_BASE_ADDRESS);
4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27  29  }
4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27  30  
4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27  31  static inline void 
rv_writel(u32 val, void __iomem *base_addr)
4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27  32  {
4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 @33writel(val, base_addr - 
ACP3x_PHY_BASE_ADDRESS);

:: The code at line 28 was first introduced by commit
:: 4eafb0d45ea9ed3fa7f53794c85f831659851d20 ASoC: AMD: add ACP3.0 PCI driver

:: TO: Maruthi Srinivas Bayyavarapu 
:: CC: Alex Deucher 

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


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

[Bug 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.

[bugzilla-daemon]

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

--- Comment #30 from FFAB  ---
Created attachment 135768
  --> https://bugs.freedesktop.org/attachment.cgi?id=135768=edit
dmesg_20171127_4_15-rc1_iommu-soft.txt, boot kernel parameter iommu=soft

-- 
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 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.

[bugzilla-daemon]

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

FFAB  changed:

   What|Removed |Added

 Attachment #135447|0   |1
is obsolete||
 Attachment #135448|0   |1
is obsolete||

--- Comment #29 from FFAB  ---
Created attachment 135767
  --> https://bugs.freedesktop.org/attachment.cgi?id=135767=edit
dmesg_20171127_4_15-rc1.txt, boot without workaround

-- 
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 0/3] Adding new drm formats needed by Xilinx IPs

[Emil Velikov]

On 28 November 2017 at 11:09, Daniel Vetter  wrote:
> On Mon, Nov 27, 2017 at 06:27:30PM -0800, Hyun Kwon wrote:
>> Hi,
>>
>> This series is to add new drm formats needed by some Xilinx IPs.
>> Some formats have unique characteristics such as pixels not being
>> byte-aligned. For instance, some 10bit formats have 2bit padding
>> after every 3-10bit components:
>>
>>   32b[0]: 10b comp0 - 10b comp1 - 10b comp2 - 2b padding
>>   32b[1]: 10b comp3 - 10b comp4 - 10b comp5 - 2b padding
>>   ...
>>
>> To model this, additional information is added to struct drm_format_info.
>> The patch has been tested with downstream drivers as well as the downstream
>> user space component (ex, modified modetest).
>>
>> Thanks,
>> hyun
>>
>> Jeffrey Mouroux (2):
>>   uapi: drm: New fourcc codes needed by Xilinx Video IP
>>   drm: fourcc: Update DRM Framework with new fourcc codes
>>
>> Satish Kumar Nagireddy (1):
>>   drm: drm_fourcc: Add scaling and padding factor to drm_format_info
>
> We need the driver for this.

To elaborate this in different light:
Without an upstream user (both kernel and userspace) this will be in a
perpetual broken state.
If the Xilinx DRM driver is still far off, one could update any of the
existing drivers - say i915 :-P

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

[Bug 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.

[bugzilla-daemon]

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

--- Comment #28 from FFAB  ---
Upstream kernel test - kernel 4.15-rc1

Installation, on which upstream kernel was installed:

ubuntu 16.04.3, kernel4.10.0-40, updated 2017-11-27

1. booting without any workaround parameters
2. booting with kernel parameter iommu=soft

boot-time 50sec (message sound),
black screen
remote-login (ssh) o.k.

attachments: dmesg_20171127_4_15-rc1.txt,  
dmesg_20171127_4_15-rc1_iommu-soft.txt

-- 
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 103697] [regression] shared memory size 64k -> 32k?

[bugzilla-daemon]

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

--- Comment #3 from Nicolai Hähnle  ---
Bas explained what's going on correctly. We could consider raising the limit
for compute shaders though. May ask what your use case is?

-- 
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: [Nouveau] [PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci warnings (fwd)

[Julia Lawall]

On Tue, 28 Nov 2017, Karol Herbst wrote:

> Hi julia,
>
> I think it would be better to extract the assignment out of the if
> clause. Then you'll get something like this:
>
> memory = ...;
> if (IS_ERR(memory)) {
> 
> }
>
> so, to answer your question: no, it isn't necessary.

Will someone take care of it?  I'm just the 0-day proxy :)

julia

> On Tue, Nov 28, 2017 at 1:56 PM, Julia Lawall  wrote:
> > This is a false positive, but I wonder if it is really necessary to put
> > the assignment in the conditional test expression.
> >
> > julia
> >
> > -- Forwarded message --
> > Date: Tue, 28 Nov 2017 13:23:36 +0800
> > From: kbuild test robot 
> > To: kbu...@01.org
> > Cc: Julia Lawall 
> > Subject: [PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci warnings
> >
> > CC: kbuild-...@01.org
> > CC: linux-ker...@vger.kernel.org
> > TO: Ben Skeggs 
> > CC: David Airlie 
> > CC: dri-devel@lists.freedesktop.org
> > CC: nouv...@lists.freedesktop.org
> > CC: linux-ker...@vger.kernel.org
> >
> > drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c:109:5-11: inconsistent 
> > IS_ERR and PTR_ERR on line 110.
> > drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c:109:5-11: inconsistent 
> > IS_ERR and PTR_ERR on line 111.
> >
> >  PTR_ERR should access the value just tested by IS_ERR
> >
> > Semantic patch information:
> >  There can be false positives in the patch case, where it is the call to
> >  IS_ERR that is wrong.
> >
> > Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
> >
> > Fixes: 920d2b5ef215 ("drm/nouveau/mmu: define user interfaces to mmu vmm 
> > opertaions")
> > Signed-off-by: Fengguang Wu 
> > ---
> >
> > Please take the patch only if it's a positive warning. Thanks!
> >
> >  uvmm.c |5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c
> > @@ -107,8 +107,9 @@ nvkm_uvmm_mthd_map(struct nvkm_uvmm *uvm
> > return ret;
> >
> > if (IS_ERR((memory = nvkm_umem_search(client, handle {
> > -   VMM_DEBUG(vmm, "memory %016llx %ld\n", handle, 
> > PTR_ERR(memory));
> > -   return PTR_ERR(memory);
> > +   VMM_DEBUG(vmm, "memory %016llx %ld\n", handle,
> > + PTR_ERR((memory = nvkm_umem_search(client, 
> > handle;
> > +   return PTR_ERR((memory = nvkm_umem_search(client, handle)));
> > }
> >
> > mutex_lock(>mutex);
> > ___
> > Nouveau mailing list
> > nouv...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci warnings (fwd)

[Karol Herbst]

Hi julia,

I think it would be better to extract the assignment out of the if
clause. Then you'll get something like this:

memory = ...;
if (IS_ERR(memory)) {

}

so, to answer your question: no, it isn't necessary.

On Tue, Nov 28, 2017 at 1:56 PM, Julia Lawall  wrote:
> This is a false positive, but I wonder if it is really necessary to put
> the assignment in the conditional test expression.
>
> julia
>
> -- Forwarded message --
> Date: Tue, 28 Nov 2017 13:23:36 +0800
> From: kbuild test robot 
> To: kbu...@01.org
> Cc: Julia Lawall 
> Subject: [PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci warnings
>
> CC: kbuild-...@01.org
> CC: linux-ker...@vger.kernel.org
> TO: Ben Skeggs 
> CC: David Airlie 
> CC: dri-devel@lists.freedesktop.org
> CC: nouv...@lists.freedesktop.org
> CC: linux-ker...@vger.kernel.org
>
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c:109:5-11: inconsistent IS_ERR 
> and PTR_ERR on line 110.
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c:109:5-11: inconsistent IS_ERR 
> and PTR_ERR on line 111.
>
>  PTR_ERR should access the value just tested by IS_ERR
>
> Semantic patch information:
>  There can be false positives in the patch case, where it is the call to
>  IS_ERR that is wrong.
>
> Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
>
> Fixes: 920d2b5ef215 ("drm/nouveau/mmu: define user interfaces to mmu vmm 
> opertaions")
> Signed-off-by: Fengguang Wu 
> ---
>
> Please take the patch only if it's a positive warning. Thanks!
>
>  uvmm.c |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c
> @@ -107,8 +107,9 @@ nvkm_uvmm_mthd_map(struct nvkm_uvmm *uvm
> return ret;
>
> if (IS_ERR((memory = nvkm_umem_search(client, handle {
> -   VMM_DEBUG(vmm, "memory %016llx %ld\n", handle, 
> PTR_ERR(memory));
> -   return PTR_ERR(memory);
> +   VMM_DEBUG(vmm, "memory %016llx %ld\n", handle,
> + PTR_ERR((memory = nvkm_umem_search(client, 
> handle;
> +   return PTR_ERR((memory = nvkm_umem_search(client, handle)));
> }
>
> mutex_lock(>mutex);
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP

[Ville Syrjälä]

On Mon, Nov 27, 2017 at 06:27:32PM -0800, Hyun Kwon wrote:
> From: Jeffrey Mouroux 
> 
> The Xilinx Video Mixer and Xilinx Video Framebuffer DMA IP
> support video memory formats that are not represented in the
> current DRM fourcc library.  This patch adds those missing
> fourcc codes.
> 
> Signed-off-by: Jeffrey Mouroux 
> Signed-off-by: Hyun Kwon 
> ---
>  include/uapi/drm/drm_fourcc.h | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3ad838d..83806d5 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -112,6 +112,13 @@ extern "C" {
>  #define DRM_FORMAT_VYUY  fourcc_code('V', 'Y', 'U', 'Y') /* 
> [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
>  
>  #define DRM_FORMAT_AYUV  fourcc_code('A', 'Y', 'U', 'V') /* 
> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> +#define DRM_FORMAT_VUY888fourcc_code('V', 'U', '2', '4') /* [23:0] 
> Cr:Cb:Y little endian */
> +#define DRM_FORMAT_XVUY  fourcc_code('X', 'V', '2', '4') /* [31:0] 
> x:Cr:Cb:Y 8:8:8:8 little endian */
> +#define DRM_FORMAT_XVUY2101010   fourcc_code('X', 'V', '3', '0') /* 
> [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> +
> +/* Grey scale */
> +#define DRM_FORMAT_Y8fourcc_code('G', 'R', 'E', 'Y') /* 
> 8-bit packed greyscale Y:Y:Y:Y 8:8:8:8 */
> +#define DRM_FORMAT_Y10   fourcc_code('Y', '1', '0', ' ') /* 
> 10-bit packed greyscale X:Y:Y:Y 2:10:10:10 */

These don't make sense to me. What does it even mean to have Y
replicated three or four times for each pixel?

>  
>  /*
>   * 2 plane RGB + A
> @@ -140,6 +147,8 @@ extern "C" {
>  #define DRM_FORMAT_NV61  fourcc_code('N', 'V', '6', '1') /* 2x1 
> subsampled Cb:Cr plane */
>  #define DRM_FORMAT_NV24  fourcc_code('N', 'V', '2', '4') /* 
> non-subsampled Cr:Cb plane */
>  #define DRM_FORMAT_NV42  fourcc_code('N', 'V', '4', '2') /* 
> non-subsampled Cb:Cr plane */
> +#define DRM_FORMAT_XV15  fourcc_code('X', 'V', '1', '5') /* 2x2 
> subsampled Cr:Cb plane 2:10:10:10 */
> +#define DRM_FORMAT_XV20  fourcc_code('X', 'V', '2', '0') /* 2x1 
> subsampled Cr:Cb plane 2:10:10:10 */

Huh. Where are the Cb:Cr in that 2:10:10:10 layout?

Better docs please.

>  
>  /*
>   * 3 plane YCbCr
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

[Joe Perches]

On Tue, 2017-11-28 at 11:23 +0100, Ladislav Michl wrote:
> I do not follow. This is OMAP framebuffer driver, so in this case, there
> is zero variation. Could you, please, review following patch and verify
> is it satisfies your automated static code analysis test?

Obviously a better patch.

I suggest submitting it properly and letting the 0-day
build bot have a go at it.

cheers, Joe

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

Re: [PATCH] drm/amd/display: Fix potential NULL pointer dereferences in amdgpu_dm_atomic_commit_tail

[Andrey Grodzovsky]

Reviewed-by: Andrey Grodzovsky 

Thanks,

Andrey

On 11/27/2017 09:57 AM, Gustavo A. R. Silva wrote:

dm_new_crtc_state->stream and disconnected_acrtc are being dereferenced
before they are null checked, hence there is a potential null pointer
dereference.

Fix this by null checking such pointers before they are dereferenced.

Addresses-Coverity-ID: 1423745 ("Dereference before null check")
Addresses-Coverity-ID: 1423833 ("Dereference before null check")
Fixes: e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_types and amdgpu_dm")
Fixes: 54d765752467 ("drm/amd/display: Unify amdgpu_dm state variable namings.")
Signed-off-by: Gustavo A. R. Silva 
---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +++-
  1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 889ed24..3bdd137 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4190,6 +4190,9 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
  
  		dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
  
+		if (!dm_new_crtc_state->stream)

+   continue;
+

update_stream_scaling_settings(_new_con_state->base.crtc->mode,
dm_new_con_state, (struct dc_stream_state 
*)dm_new_crtc_state->stream);
  
@@ -4197,9 +4200,6 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state)

WARN_ON(!status);
WARN_ON(!status->plane_count);
  
-		if (!dm_new_crtc_state->stream)

-   continue;
-
/*TODO How it works with MPO ?*/
if (!dc_commit_planes_to_stream(
dm->dc,
@@ -4332,9 +4332,11 @@ void dm_restore_drm_connector_state(struct drm_device 
*dev,
return;
  
  	disconnected_acrtc = to_amdgpu_crtc(connector->encoder->crtc);

-   acrtc_state = to_dm_crtc_state(disconnected_acrtc->base.state);
+   if (!disconnected_acrtc)
+   return;
  
-	if (!disconnected_acrtc || !acrtc_state->stream)

+   acrtc_state = to_dm_crtc_state(disconnected_acrtc->base.state);
+   if (!acrtc_state->stream)
return;
  
  	/*


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

[bug report] drm/vmwgfx: Initial DX support

[Dan Carpenter]

Hello Thomas Hellstrom,

The patch d80efd5cb3de: "drm/vmwgfx: Initial DX support" from Aug 10,
2015, leads to the following static checker warning:

drivers/gpu/drm/vmwgfx/vmwgfx_so.c:335 vmw_view_add()
error: buffer overflow 'vmw_view_define_sizes' 3 <= 3

drivers/gpu/drm/vmwgfx/vmwgfx_so.c
  2709  static int vmw_cmd_dx_view_define(struct vmw_private *dev_priv,
  2710struct vmw_sw_context *sw_context,
  2711SVGA3dCmdHeader *header)
  2712  {
  2713  struct vmw_resource_val_node *ctx_node = 
sw_context->dx_ctx_node;
  2714  struct vmw_resource_val_node *srf_node;
  2715  struct vmw_resource *res;
  2716  enum vmw_view_type view_type;
  2717  int ret;
  2718  /*
  2719   * This is based on the fact that all affected define commands 
have
  2720   * the same initial command body layout.
  2721   */
  2722  struct {
  2723  SVGA3dCmdHeader header;
  2724  uint32 defined_id;
  2725  uint32 sid;
  2726  } *cmd;
  2727  
  2728  if (unlikely(ctx_node == NULL)) {
  2729  DRM_ERROR("DX Context not set.\n");
  2730  return -EINVAL;
  2731  }
  2732  
  2733  view_type = vmw_view_cmd_to_type(header->id);
^
view_type is set to vmw_view_max for unknown values.

  2734  cmd = container_of(header, typeof(*cmd), header);
  2735  ret = vmw_cmd_res_check(dev_priv, sw_context, vmw_res_surface,
  2736  user_surface_converter,
  2737  >sid, _node);
  2738  if (unlikely(ret != 0))
  2739  return ret;
  2740  
  2741  res = vmw_context_cotable(ctx_node->res, 
vmw_view_cotables[view_type]);
   
^
but we use it without checking vmw_view_id_ok().

  2742  ret = vmw_cotable_notify(res, cmd->defined_id);
  2743  vmw_resource_unreference();
  2744  if (unlikely(ret != 0))
  2745  return ret;
  2746  

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

Re: [Intel-gfx] [PATCH] drm: Fix modifiers_property kernel-doc comment

[Hans de Goede]

Hi,

On 28-11-17 11:28, Daniel Vetter wrote:

On Sat, Nov 25, 2017 at 08:27:31PM +0100, Hans de Goede wrote:

This fixes the following make kerneldocs messages:

./include/drm/drm_mode_config.h:772: warning: No description found for 
parameter 'modifiers_property'
./include/drm/drm_mode_config.h:772: warning: Excess struct member 'modifiers' 
description in 'drm_mode_config'

Signed-off-by: Hans de Goede 


Reviewed-by: Daniel Vetter 

Pls push to drm-misc-next, thanks.


Ville Syrjälä has already fixed this, but I missed that because the
fix was not yet in dinq when I prepared my panel-orientation patch
series.

Regards,

Hans




-Daniel


---
  include/drm/drm_mode_config.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 3716e6b8fed5..cb9ffbda36cc 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -759,7 +759,7 @@ struct drm_mode_config {
bool allow_fb_modifiers;
  
  	/**

-* @modifiers: Plane property to list support modifier/format
+* @modifiers_property: Plane property to list support modifier/format
 * combination.
 */
struct drm_property *modifiers_property;
--
2.14.3

___
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

Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

[Ladislav Michl]

On Tue, Nov 28, 2017 at 11:50:14AM +0100, SF Markus Elfring wrote:
> >> How will this aspect evolve further?
> > 
> > I do not follow.
> 
> Interesting …
> 
> > This is OMAP framebuffer driver, so in this case, there is zero variation.
> 
> How much are you interested to compare differences in build results
> also for this software module because of varying parameters?
> 
> Which parameters were applied for your size comparisons so far?

It was just omap2plus_defconfig build using gcc-7.2.0

> > Could you, please, review following patch
> 
> I assume that other OMAP developers are in a better position to decide
> about the deletion of extra memory allocations (instead of keeping
> questionable error messages).
> 
> > and verify is it satisfies your automated static code analysis test?
> 
> I am not going to “verify” your update suggestion by my evolving approaches
> around the semantic patch language (Coccinelle software) at the moment.

As you are sending patches as Markus Elfring I would expect you take
Coccinelle's suggestion into account and actually try to understand code
before sending patch. That suggestion may lead to actual bug in code
which your patch just leaves unnoticed as it is not apparent from
the patch itself (no, not talking about this very patch it all started
with)

That said, I'm considering Markus Elfring being a human. If you do not like
reactions to your patches or are interested only in improving tool that
generates them, it would be better to just setup a "tip bot for Markus
Elfring" and let it send patches automatically. This way noone is going
to waste time on them as it would be clear those are purely machine only
generated and there's no point to reply.

The way you are sending patches makes impression (at least to me), that
you spent some time on fixing issue Coccinelle found and not just shut
the warning up.

> But I thank you for this contribution.
> How will further feedback evolve for such an idea?

And the idea is?

> Regards,
> Markus

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

Re: [PATCH v2 11/18] drm/sun4i: Add A83T support

[Icenowy Zheng]

在 2017-11-28 17:02，Maxime Ripard 写道：

Hi,

On Mon, Nov 27, 2017 at 05:01:49PM +0100, Jernej Škrabec wrote:
Dne ponedeljek, 27. november 2017 ob 16:41:35 CET je Maxime Ripard 
napisal(a):

> Add support for the A83T display pipeline.
>
> Reviewed-by: Chen-Yu Tsai 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
>  drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
>  drivers/gpu/drm/sun4i/sun4i_tcon.c| 5 +
>  drivers/gpu/drm/sun4i/sun8i_mixer.c   | 4 
>  4 files changed, 14 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index
> d4259a4f5171..d6b52e5c48c0 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -93,6 +93,7 @@ Required properties:
> * allwinner,sun6i-a31s-tcon
> * allwinner,sun7i-a20-tcon
> * allwinner,sun8i-a33-tcon
> +   * allwinner,sun8i-a83t-tcon-lcd
> * allwinner,sun8i-v3s-tcon
>   - reg: base address and size of memory-mapped region
>   - interrupts: interrupt associated to this IP
> @@ -224,6 +225,7 @@ supported.
>
>  Required properties:
>- compatible: value must be one of:
> +* allwinner,sun8i-a83t-de2-mixer

What will be the name of the second mixer, once support for HDMI is 
added?

Should we start directly with 0 and 1 postfix ?


What are the differences exactly without the two mixers?

I was hoping to be able to cover them all using properties, indices
are usually pretty badly received in compatibles.


1. VEP is only available on the VI channel in mixer0. (VEP may mean
Video Enhance Processor)
2. Smart Backlight is only available in mixer0's on SoCs with LCD.
3. Writeback function is only available in mixer0.




>  static const struct of_device_id sun8i_mixer_of_table[] = {
>{
> +  .compatible = "allwinner,sun8i-a83t-de2-mixer",
> +  .data = _v3s_mixer_cfg,
> +  },
> +  {

Maybe you want to squash 12 patch since this works only by luck.


Yeah, I totally meant to do that :)

Thanks!
Maxime

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

Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

[Ladislav Michl]

On Tue, Nov 28, 2017 at 12:04:04AM -0800, Joe Perches wrote:
> On Tue, 2017-11-28 at 08:41 +0100, SF Markus Elfring wrote:
> > > > It seems that I got no responses so far for clarification requests
> > > > according to the documentation in a direction I hoped for.
> > > 
> > > That's because you are pretty unresponsive to direction.
> > 
> > From which places did you get this impression?
> 
> How many times have I told you to include the reason for
> your patches in
> your proposed commit message?  Too often.
> 
> For instance, specific to this patch:
> 
> Many people do not know that a generic kmalloc does a
> dump_stack() on OOM.  That information should be part
> of the commit message.
> 
> Also removing the printk code reduces overall code size.
> The actual size reduction should be described in the
> commit message too.

Could we, please, return one step back and reevaluate need for
kmalloc. That would eliminate original "problem" as well.

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

Re: [PATCH] drm/i915/guc: Fix doc reference to intel_guc_fw.c

[Jonathan Neuschäfer]

On Tue, Nov 28, 2017 at 09:51:13AM +0100, Michal Wajdeczko wrote:
> On Tue, 28 Nov 2017 07:50:52 +0100, Jonathan Neuschäfer
>  wrote:
> 
> > Sphinx complains that it can't find intel_guc_loader.c, and rightly so:
> > The file has been renamed.
> > 
> > Fixes: e8668bbcb0f9 ("drm/i915/guc: Rename intel_guc_loader.c to
> > intel_guc_fw.c")
> > Cc: Michal Wajdeczko 
> > Signed-off-by: Jonathan Neuschäfer 
> > ---
> >  Documentation/gpu/i915.rst | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> > index 2e7ee0313c1c..e21698e16534 100644
> > --- a/Documentation/gpu/i915.rst
> > +++ b/Documentation/gpu/i915.rst
> > @@ -341,10 +341,10 @@ GuC
> >  GuC-specific firmware loader
> >  
> > -.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
> > +.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
> > :doc: GuC-specific firmware loader
> > -.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
> > +.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
> > :internal:
> > GuC-based command submission
> 
> + Ville
> 
> Well, this will fix sphinx error, but in my opinion it will not make
> i915 documentation any better. See my earlier patch/comments in [1].

Thanks for the pointer.

Hmm, right, given that there's no "DOC:" line in intel_guc_fw.c anymore,
the ":doc:" directive above is not useful.

As a tiny step towards more complete documentation (and to keep people
from patching this spot again ;), IMHO it makes sense to do this (it's
of course up to the maintainers whether they agree):

---
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 2e7ee0313c1c..e94d3ac2bdd0 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -341,10 +341,7 @@ GuC
 GuC-specific firmware loader
 
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
-   :doc: GuC-specific firmware loader
-
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
:internal:
 
 GuC-based command submission
---

> So maybe better to wait for other comments which way to go.

Makes sense.


Thanks,
Jonathan Neuschäfer

> 
> Thanks for the patch,
> Michal
> 
> [1] https://patchwork.freedesktop.org/patch/188424/


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

Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

[Ladislav Michl]

On Tue, Nov 28, 2017 at 11:15:37AM +0100, SF Markus Elfring wrote:
> >>> Many people do not know that a generic kmalloc does a
> >>> dump_stack() on OOM.
> >>
> >> This is another interesting information, isn't it?
> >>
> >> It is expected that the function “devm_kzalloc” has got a similar property.
> > 
> > 
> > You don't have to expect this.  Go look at the definition of devm_kzalloc
> > and see whether it has the property or not.
> 
> I find that the corresponding documentation of these programming interfaces
> is incomplete for a desired format which could be different than C source 
> code.
> 
> https://elixir.free-electrons.com/linux/v4.15-rc1/source/include/linux/device.h#L657
> https://elixir.free-electrons.com/linux/v4.15-rc1/source/drivers/base/devres.c#L763
> https://www.kernel.org/doc/html/latest/driver-api/basics.html#c.devm_kmalloc
> 
> Can the Coccinelle software help more to determine desired function 
> properties?
> 
> 
> >> For which hardware and software combinations would you like to see
> >> facts there?
> > 
> > This is not for Joe to decide,
> 
> This view is fine in principle.
> 
> 
> > it's for the person who receives the patch to decide.
> 
> I am curious on further comments from these contributors.
> 
> 
> > You could start with the ones for which the code actually compiles,
> > using the standard make file and no special options, and a
> > recent version of gcc.
> 
> The variation space could become too big to handle for me (alone).
> How will this aspect evolve further?

I do not follow. This is OMAP framebuffer driver, so in this case, there
is zero variation. Could you, please, review following patch and verify
is it satisfies your automated static code analysis test?

diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c 
b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
index 7a75dfda9845..6be13a106ece 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
@@ -3976,52 +3976,33 @@ static const struct dispc_features omap54xx_dispc_feats 
= {
.has_writeback  =   true,
 };
 
-static int dispc_init_features(struct platform_device *pdev)
+static const struct dispc_features* dispc_get_features(void)
 {
-   const struct dispc_features *src;
-   struct dispc_features *dst;
-
-   dst = devm_kzalloc(>dev, sizeof(*dst), GFP_KERNEL);
-   if (!dst) {
-   dev_err(>dev, "Failed to allocate DISPC Features\n");
-   return -ENOMEM;
-   }
-
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP24xx:
-   src = _dispc_feats;
-   break;
+   return _dispc_feats;
 
case OMAPDSS_VER_OMAP34xx_ES1:
-   src = _rev1_0_dispc_feats;
-   break;
+   return _rev1_0_dispc_feats;
 
case OMAPDSS_VER_OMAP34xx_ES3:
case OMAPDSS_VER_OMAP3630:
case OMAPDSS_VER_AM35xx:
case OMAPDSS_VER_AM43xx:
-   src = _rev3_0_dispc_feats;
-   break;
+   return _rev3_0_dispc_feats;
 
case OMAPDSS_VER_OMAP4430_ES1:
case OMAPDSS_VER_OMAP4430_ES2:
case OMAPDSS_VER_OMAP4:
-   src = _dispc_feats;
-   break;
+   return _dispc_feats;
 
case OMAPDSS_VER_OMAP5:
case OMAPDSS_VER_DRA7xx:
-   src = _dispc_feats;
-   break;
+   return _dispc_feats;
 
default:
-   return -ENODEV;
+   return NULL;
}
-
-   memcpy(dst, src, sizeof(*dst));
-   dispc.feat = dst;
-
-   return 0;
 }
 
 static irqreturn_t dispc_irq_handler(int irq, void *arg)
@@ -4078,9 +4059,9 @@ static int dispc_bind(struct device *dev, struct device 
*master, void *data)
 
spin_lock_init(_lock);
 
-   r = dispc_init_features(dispc.pdev);
-   if (r)
-   return r;
+   dispc.feat = dispc_get_features();
+   if (!dispc.feat)
+   return -ENODEV;
 
dispc_mem = platform_get_resource(dispc.pdev, IORESOURCE_MEM, 0);
if (!dispc_mem) {
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c 
b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
index 48c6500c24e1..9a255ffe77c5 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
@@ -887,58 +887,37 @@ static const struct dss_features dra7xx_dss_feats = {
.num_ports  =   ARRAY_SIZE(dra7xx_ports),
 };
 
-static int dss_init_features(struct platform_device *pdev)
+static const struct dss_features* dss_get_features(void)
 {
-   const struct dss_features *src;
-   struct dss_features *dst;
-
-   dst = devm_kzalloc(>dev, sizeof(*dst), GFP_KERNEL);
-   if (!dst) {
-   dev_err(>dev, "Failed to allocate local DSS Features\n");
-   return -ENOMEM;
-   }
-
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP24xx:
- 

AW: [PATCH 4/5] ARM: dts: Add support for emtrion emCON-MX6 series

[Türk , Jan]

Hi Rob,

thanks for your feedback, the changes will be included in V2 of the 
patch-series.

Jan
> Von: Rob Herring
> Gesendet: Sonntag, 26. November 2017 20:24
> On Thu, Nov 23, 2017 at 01:55:54PM +0100, Jan Tuerk wrote:
> > This patch adds support for the emtrion GmbH emCON-MX6 modules.
> > They are available with imx.6 Solo, Dual-Lite, Dual and Quad
> > equipped with Memory from 512MB to 2GB (configured by U-Boot).
 [...]
> > + {
> > +   clock-frequency = <10>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_i2c3>;
> > +   status = "okay";
> > +
> > +   sgtl5000: sgtl5000@0a {
>
> audio-codec@a
>
> same errors repeat below.
changed for v2
>
> > +   compatible = "fsl,sgtl5000";
> > +   reg = <0x0a>;
> > +   clocks = <>;
> > +   VDDA-supply = <>;
> > +   VDDIO-supply = <>;
> > +   };
> > +
> > +   boardID: pca8754a@3A {
>
> ...@3a
changed in V2
>
> > +   compatible = "nxp,pca8574";
> > +   reg = <0x3A>;
>
> 0x3a
>
> > +   gpio-controller;
> > +   #gpio-cells = <1>;
> > +   };
> > +
> > +   captouch: edt-ft5x06@38 {
>
> touchscreen@38

>
> > +   reg = <0x38>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_irq_touch2 _emcon_gpio4>;
> > +   interrupt-parent = <>;
> > +   interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
> > +   compatible = "edt,edt-ft5406";
> > +   wake-gpios = < 3 GPIO_ACTIVE_HIGH>;
> > +   wakeup-source;
> > +   };
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > +_encoder {
> > +   status = "okay";
> > +};
> > +
[...]
> > +
> > +   rgb_panel: panel {
> > +   backlight = <_backlight>;
> > +   power-supply = <_prallel_disp>;
> > +   port {
> > +   rgb_panel_in: endpoint {
> > +   remote-endpoint = <_encoder_out>;
> > +   };
> > +   };
> > +   };
> > +
> > +   rgb_backlight: rgb_backlight {
>
> rgb-backlight {
[...]
> > +
> > +   lvds_backlight: lvds_backlight {
>
> lvds-backlight {

Ok, I'll change that in V2

[...]
> > +
> > + {
> > +   clock-frequency = <10>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_i2c1>;
> > +   status = "okay";
> > +
> > +   rtc: rtc@68 {
> > +   compatible = "dallas,ds1307";
> > +   reg = <0x68>;
> > +   };
> > +
> > +   da9063: da9063@58 {
>
> pmic@38
changed
>
> > +   compatible = "dlg,da9063";
> > +   reg = <0x58>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_pmic>;
> > +   interrupt-parent = <>;
> > +
[]
> > +
> > +   mdio {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   ksz9031: phy {
>
> phy@0
>
> Building with W=2 or W=1 will tell you this.
thanks for the hint, it will be also included in v2
>
> > +   reg = <0>;
> > +   compatible = "ethernet-phy-ieee802.3-c22";
> > +   interrupt-parent = <>;
> > +   interrupts = <30 IRQ_TYPE_EDGE_FALLING>;
> > +   rxdv-skew-ps = <480>;
> > +   txen-skew-ps = <480>;
[...]

emtrion GmbH
Kreativpark - Alter Schlachthof 45
76131 Karlsruhe
GERMANY
http://www.emtrion.de
___

Amtsgericht Mannheim
HRB 110 300
Geschäftsführer: Dieter Baur, Ramona Maurer
___
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 12/17] drm/sun4i: Add CCSC property to DE2 configuration

[Icenowy Zheng]

在 2017-11-28 04:57，Jernej Skrabec 写道：

Base addresses of channel output CSC (CCSC) depends whether mixer in
question is first or second and if it is second, if supports VEP or 
not.

This new property will tell which set of base addresses to take.

0 - first mixer or second mixer with VEP support
1 - second mixer without VEP support


Maxime,

I think here the ID of the mixer matters.

P.S. I didn't found any SoC with a second mixer with VEP currently

Thanks!



Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/sun4i/sun8i_mixer.c | 1 +
 drivers/gpu/drm/sun4i/sun8i_mixer.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 7c9c87a0535b..2276eff8798d 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -622,6 +622,7 @@ static const struct sun8i_mixer_cfg 
sun8i_v3s_mixer_cfg = {

.vi_num = 2,
.ui_num = 1,
.scaler_mask = 0x3,
+   .ccsc = 0,


Jernej, the lowlevel_sun8iw8/de_feat.c in the BSP DE2 source code
claims that V3/V3s have no VEP support even for mixer0.


 };

 static const struct of_device_id sun8i_mixer_of_table[] = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index 355a45e6cfb4..4fcf1653e345 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -136,6 +136,7 @@ struct sun8i_mixer_cfg {
int vi_num;
int ui_num;
int scaler_mask;
+   int ccsc;
 };

 struct sun8i_mixer {

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

Re: [GIT PULL] exynos-drm-next

[Marek Szyprowski]

Hi Daniel,

On 2017-11-20 08:33, Daniel Vetter wrote:

On Wed, Nov 15, 2017 at 10:26:45AM +0900, Inki Dae wrote:

2017년 11월 14일 13:22에 Dave Airlie 이(가) 쓴 글:

On 26 October 2017 at 11:37, Inki Dae  wrote:

Improving Exynos DRM HDMI and Mixer drivers and also adding
HDMI audio support.

Please kindly let me know if there is any problem.

Ps. we are reviewing IPP v2 driver[1] which controls post processor devices
such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to request
git pull one more time after review.

I dropped the ball a bit here, I do think the second pull with IPP is
probably a bit late,
I think I'd like more assurance that the UAPI for IPP is to be used in
some upstream
shipping project (forks of mpv not withstanding, unless this fork
ships in some distro
or product).

I also commented same thing internally to author - Marek - of IPP v2 but I 
thought existing one is really ugly thing so may be better to change it as soon 
as possible before other users use this one.
Anyway, we will merge user space for IPP v2 to libdrm first, and then Linux 
platform. I hope IPPv2 would be merged as soon as possible in next turn.

Beyond what Daniel said we unfortunately don't have time machines, so
fixing bad uapi isn't really possible. The problem is that even if you
create ippv2, then people can still use ippv1, and it needs to keep
working (almost) forever. So once a bad uapi is in, it's in, and there's
no good reason to add more uapi (since in 2 years you might again realize
it's not a good idea) to "fix" that. You can't fix bad uapi.

That's why we have all these rules to make sure as little bad uapi as
possible lands, since the cost is so bad.

So yeah unless you have new hw that needs it, or there's another clear
need (performance, features), you're stuck with ippv1. "It's cleaner" is
not a good reason to rev uapi, since our experience with all the uapi in
drm clearly shows we can't predict the future :-)


I generally agree that UAPI interface has to be stable and well designed.

There are however some 'features' IPPv1 uapi that really allows us to
obsolete it:

1. IPP API can be optional in Exynos DRM, so userspace should not rely that
it is always available and should have a software fallback in case it is not
available.

2. The only mode which was initially semi-working was memory-to-memory. The
remaining modes (lcd-writeback and output) were never operational (both in
mainline and even vendor kernels).

3. IPP mainline uapi compatibility for memory-to-memory got broken very
early by commit 083500baefd5f4c215a5a93aef2492c1aa775828 ("drm: remove
DRM_FORMAT_NV12MT", which removed the support for tiled formats, the main
feature which made this api somehow useful on Exynos platforms (video codec
that time produced only tiled frames, to implement xvideo or any other
video overlay, one has to detile them for proper display).

4. Broken drivers. Especially once support for IOMMU has been added, it
revealed that drivers don't configure DMA operations properly and in many
cases operate outside the provided buffers trashing memory around.

5. Need for external patches. Although IPP uapi has been used in some
vendor kernels, but in such cases there were additional patches applied
(like reverting mentioned 083500baefd5 patch) what means that those
userspace apps which might use it, still won't work with the mainline
version.

Right, as you already said we don't have time machines, so we cannot change
it, but IPP extension should never have been merged to mainline in that
form.

We can however obsolete it now as it is really non-functional and frankly
speaking dead-code. If you agree with the above than at least the first
patch can be merged, which clearly marks that Exynos IPP is broken and
ever really functional. I bet no one will complain. Then we can continue
the discussion about IPPv2 uapi/patches.

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

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

Re: [PATCH v6 1/2] staging: ion: reorder include

[Greg KH]

On Tue, Nov 28, 2017 at 02:34:00PM +0100, Benjamin Gaignard wrote:
> 2017-11-28 14:20 GMT+01:00 Greg KH :
> > On Mon, Nov 06, 2017 at 04:59:44PM +0100, Benjamin Gaignard wrote:
> >> Put include in alphabetic order
> >
> > Why???
> 
> Mainly because the next patch in the series adds new includes and I have
> decide to split clean-up and new feature patches

That's fine, but this really isn't needed for any type of "clean-up" at
all.  But oh well, if you all like it that way, I'm not going to
complain that much :)

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